DEV Community: arun rajkumar

Open Banking vs Card Rails: Latency, Cost, and Developer Experience

arun rajkumar — Wed, 10 Jun 2026 08:08:10 +0000

I've integrated both. Cards and open banking. In production. Moving real money for real UK merchants.

So when developers ask me "which is actually better to build on?" I don't give them the marketing answer. I give them the three numbers that decide it: how much it costs, how fast the money moves, and how much of your life you lose to the integration.

Let me walk through all three. Honestly. Including where cards still win.

1. Cost — and why it's not close

Here's the part nobody at the card networks wants in a headline.

A UK card payment costs you somewhere between 1.5% and 3%+ per transaction once you stack interchange, scheme fees, and your processor's margin. The "0.2% debit interchange cap" everyone quotes is the floor of the floor — it's not what lands on your statement.

An open banking payment costs roughly 0.1%–1.0%, or a flat 20p–50p. No interchange. No scheme fee. Because there's no scheme. The customer authorises the payment inside their own banking app and the bank moves the money directly.

The concrete version: a local garage takes £500 for a repair. A 1.5% card fee costs them £7.50. The same payment over open banking can cost around 10p. (Noda)

That's not a rounding difference. That's the difference between a payments line item you tolerate and one you forget exists.

And there's a second-order cost cards carry that nobody puts in the pricing table: chargebacks. £20 a pop, plus the engineering time to fight them, plus the fraud surface you have to defend. Open banking payments are bank-authenticated at source. There's no card number to steal and no "I didn't authorise this" dispute when the customer tapped approve in their own banking app. The fraud surface is smaller, so the price can be lower. The two facts are connected.

2. Latency — settlement, not the spinner

This is where developers get the comparison wrong, so let me split it cleanly.

Authorisation latency — the spinner the user stares at — is comparable. Both flows take a few seconds. A card auth round-trips the network; an open banking payment redirects the user to their bank's SCA and back. From the user's chair, both feel like "tap, wait, done."

Settlement latency is where they diverge violently.

A card payment authorises instantly but settles in ~2 business days. The money is promised, then it sits in limbo, then it arrives — minus fees, and reversible for months.

An open banking payment runs over Faster Payments. Settlement is near-instant — seconds to minutes — straight bank-to-bank, 24/7. There's no two-day float, no "pending payout" dashboard, no reconciling Tuesday's sales against Thursday's deposit. (Payop)

If you've ever written reconciliation code, you already feel why this matters. Half the complexity in payments tooling exists to model the gap between "authorised" and "settled." Close that gap to near-zero and a whole category of state machine — pending, settling, settled, partially-reversed — collapses into one event: paid.

3. Developer experience — where I'll be honest both ways

Let me give cards their due first.

Card SDKs are mature. Stripe's docs are art. The card flow is a solved, copy-paste problem with twenty years of Stack Overflow behind it. If you're doing global, card-first commerce, that maturity is worth real money. I'd still reach for cards there.

Open banking is younger, and the early ecosystem was genuinely painful — you were integrating against dozens of bank APIs, each with its own quirks, its own auth dance, its own downtime. That's the part that earned open banking its "hard to build on" reputation a few years ago.

But that reputation is now outdated, and here's why: the bank-by-bank mess is exactly what a good PISP abstracts away. You don't integrate 40 banks. You integrate one API that speaks Payment Initiation, handles SCA, manages the consent lifecycle, and fans out to Faster Payments for you.

In practice, the flow is short:

// 1. Create a payment — you describe intent, not card mechanics
const payment = await atoa.processPayment({
  amount: 4999,            // £49.99 in minor units
  currency: 'GBP',
  reference: 'order_10472',
  redirectUrl: 'https://yourapp.com/return',
});

// 2. Send the customer to their bank to authorise (SCA happens here)
redirect(payment.authorisationUrl);

// 3. The bank moves the money over Faster Payments.
//    You get told when it's actually settled — not "authorised, check back Thursday."

// Webhook: the event you actually care about is real, not a promise
app.post('/webhooks/atoa', (req, res) => {
  const event = verify(req);              // verify signature
  if (event.type === 'payment.completed') {
    fulfilOrder(event.data.reference);    // money is already in the bank
  }
  res.sendStatus(200);
});

Notice what's missing from that code. No card object. No PCI scope to inherit. No tokenisation vault to secure. No requires_capture → capture two-step. No chargeback webhook to handle. You describe a payment, the customer approves it in their bank, the money arrives, you fulfil. The thing you're modelling is the thing that actually happens.

That's the DX argument in one sentence: open banking lets you write code that matches reality instead of code that models a 1970s settlement delay.

The honest scorecard

	Card rails	Open banking
Cost per txn	1.5%–3%+	0.1%–1% / 20p–50p
Settlement	~2 business days	Near-instant (Faster Payments)
Chargebacks	Yes, £20+ each	Structurally absent
PCI scope	Yours to carry	Not your problem
SDK maturity	Excellent, 20 yrs	Younger, but abstracted
Best for	Global, card-first	UK consumers, instant settlement

Cards aren't dead. If your customers are international and card-native, build on cards. I mean that.

But if you're a UK SaaS, marketplace, or merchant tool charging UK consumers — you're paying card prices and eating card latency for an experience your users don't need. The numbers back the switch, and they're moving in one direction: UK open banking payments are up 53% year on year, with nearly 1 in 3 adults already using it. (Open Banking Ltd)

Try it yourself

The fastest way to feel the difference is to build it. Atoa's sandbox gives you a real Payment Initiation API, real Faster Payments settlement, and webhooks that fire when money actually moves — not when it's promised. docs.atoa.me

Spin up a test payment. Watch it settle in seconds instead of days. Then look at what you'd have paid in card fees for the same transaction.

That second number is the one that changes your mind.

Have you shipped both card and open banking flows in production? I want to hear where the DX actually broke down for you — the messy bits, not the brochure version.

OpenBanking #Payments #Fintech #API #BuildInPublic

I Replaced Scrum, Jira, and Our Wiki With 12 AI Agents on a Mac Mini

arun rajkumar — Mon, 08 Jun 2026 16:33:49 +0000

A survey last week put it at 54%. More than half the code shipped today is AI-generated.

In my own work the number is probably higher. AI writes the first draft. AI estimates the work. AI generates the tests. I've written before about the dangerous 20% — the edge cases, the illegal state transitions, the judgment AI quietly skips. That 20% is why I still need senior engineers.

But there's a second 20% problem nobody talks about. Not in the code. Around it.

Sprints. Story points. Standups. Jira boards no one updates. Confluence pages that went stale the day they were written. Every one of those tools assumes a human does the work and another human tracks the work.

That's not my team anymore.

So I stopped bending fifteen-year-old process around an AI-native team. I built my own way of working and open-sourced it. It runs on a Mac mini in the corner of my room. This is what's inside.

Your whole org as a grove. Each repo is a tree, each feature a branch, each teammate present in the world. More on this below — but yes, that's the actual dashboard.

The thing that finally broke me: the wiki

Here's the moment it clicked.

A new feature needed context. I opened our wiki. The page was six months old. It described an architecture we'd refactored twice since. The "source of truth" was confidently, completely wrong — and three engineers had made decisions based on it that week.

Documentation lies the moment you stop maintaining it. And nobody maintains it, because maintaining it is the busywork we all silently agree to skip.

Source code doesn't lie. It can't. It's the thing that actually runs.

So the first rule of the system I built: the code is the wiki. Knowledge is extracted from the repository — the call graph, the module boundaries, the patterns, the history — and indexed continuously. When an agent or a human asks "how does settlement work?", the answer is reconstructed from what's true right now, not from a page someone wrote last quarter and abandoned.

No Confluence. No Notion graveyard. The only document that's allowed to be authoritative is the one that compiles.

Nobody wrote this wiki. A baseline scan read the repositories and produced it — 19 live features across 4 repos, each one traceable to the code that backs it.

And you don't even open the dashboard to read it. Ask in Slack, in plain English — "are we progressing on the P3 backlog item? what's the go-live date?" — and a bot answers from the live BUD: status, assignee, target date, a link back to the source. Not a number someone typed into a board last Tuesday. The thing that's actually true, right now.

The same emoji-react, thread-reply Slack you already live in — except the answers come from the source of truth, not from memory.

So "the code is the wiki" isn't a slogan — it's an architecture. Knowledge lives in four layers that stay in sync on their own:

The repos themselves — source code plus a per-repo CLAUDE.md, synced on every PR merge to main.
Agent skills — org standards, design guidelines, API patterns; synced on change.
The central store — BUDs, enterprise rules, architecture decisions; real-time.
Vector search — semantic search across all of it, auto-indexed.

Two things make this more than a fancy grep. It indexes code locations, so any knowledge captured during development points back to the exact file and symbol it came from — and it links across repos, so a frontend call is connected to the backend handler it actually hits, not left as two disconnected facts in two different wikis. And it never goes stale: after every PR merge, the affected feature is updated with the new commit history and the new code locations automatically, so the next agent that touches it inherits the current truth, not last month's.

That's the whole pitch against Confluence — auto-synced from source instead of hand-maintained, semantically searchable instead of keyword-matched, always current with daily staleness detection, and wired straight into the agents' prompts so they're never reasoning from a stale page.

Agent-Driven Development, in one table

I call the methodology Agent-Driven Development (ADD). The simplest way to explain it is to put it next to the thing it replaces.

Agile ceremony	What it assumed	Agent-Driven Development
Sprint planning	Humans do all the work, so plan their hours	Agents draft; humans decide what's worth building
Story points / planning poker	Gut-feel proxy for time	AI-PERT + Monte Carlo → real P50/P70/P85 dates
Jira tickets	Work scattered across a board	One BUD per feature: spec + tech plan + tests + history
Confluence / wiki	Someone keeps docs current (nobody does)	Knowledge syncs from the source code
Daily standup	Humans report status out loud	A Status Agent reads the PRs and tells you what moved
Retrospective	A meeting you forget by Friday	A Learning Agent mines the actual diffs and incidents

The pattern underneath all six rows is the same: let the machines handle the noise, so humans spend their judgment where judgment actually matters.

The 12 agents

Here's the whole cycle on one diagram before I break it down — twelve agents around a loop, with a human reviewing at the centre and at every gate.

Chat Intake (Triage) → BUD → Design → Tech Architecture (Tech Lead reviews; Smart Assignment picks the dev) → Development (AI + Human) → Test Generation → Testing (QA) → UAT & Deploy (Status) → Feature → Learning & Skills. An external bug reopens the feature. The loop never pretends it's a straight line.

ADD runs a feature from a chat message to production through a chain of specialised agents. Each owns one phase. A human reviews and decides at every gate — this is human-in-the-loop by design, not lights-out automation.

It starts in Slack. You drop a request; the Intake agent doesn't just file it — it checks for existing features and BUDs so you don't build a duplicate, then asks the questions a good PM would: who is this for, why now, what's the timeline.

"Change the notification icon to modern design?" → the agent checks for duplicates, then interrogates the intent before a single line is written.

From there, every feature moves through the same seven-phase lifecycle, each phase a tab on its BUD:

Slack idea → Intake → Requirements → Design → Tech Spec
   → Development → Code Review → Testing → Prod
        ↑ estimation, status, learning and skills run alongside ↑

Every phase can run on an agent — or you flip it off and drive it yourself from your local AI via MCP. "Stage agents are off, you're driving this BUD" is a real toggle, per phase, per assignee. That's what human-in-the-loop actually looks like.

Around that spine sit the agents that kill the ceremonies:

Estimation — AI-PERT + Monte Carlo instead of story points (below).
Status — reads the PRs so you never run another standup.
Learning — mines the real diffs and incidents when a BUD closes.
Skills — profiles who's strong at what from git history, and feeds it back into estimation and routing.

The agents do the busywork. You do the deciding. That division is the whole philosophy.

The standup reads the work, not the people

I haven't run a status standup in months. The Standup Agent does it at 08:30 on a cron — but the interesting part is where it reads from. It doesn't ask anyone "what did you do yesterday." It reads what actually happened.

Hooks and an MCP server in each dev's local setup post the real signal back to the BUD: the prompts, the commits, the sessions. A TODO gets auto-claimed when work starts on it and auto-marked done when the agent finishes the code — so the board reflects reality without anyone updating it. The agent then aggregates the git, PR, bug and chat activity into a summary with risk flags on anything lagging.

Four file-level TODOs, all ticked by the work itself. PR #50 merged, 4 commits, 2 files, 5 sessions, 0 errors — captured from hooks, not typed into a board. The status is a side effect of building, not a separate chore.

And because the Design Agent generates wireframes from your project's design system extracted out of the code — the real CSS tokens, not a guess — what it produces is on-brand by construction. Same with the tech spec: it's written against your actual architecture and tokens, so "follows the brand guidelines" stops being a review comment and becomes the default.

The quality loop that reassigns itself

This is the part I'm proudest of, because it's where most teams quietly accumulate debt.

The Test Plan Agent auto-generates the test plan from the BUD's acceptance criteria and the code — Playwright e2e, unit and integration, security, and the manual UAT cases a human still has to sign off. An MCP token wires your QA automation repo in, so test commits flow straight back to the BUD.

24 test cases for one small feature — and notice the manual ones marked "neither can ship as silent regressions, require human sign-off." The agent writes the tests; it doesn't get to wave them through.

Code review is auto-triggered against your org's rules and submitted back on the PR. And here's the loop that closes itself: testing has a bug threshold — complexity × a configurable multiplier. Cross it, and the work auto-reassigns. The original developer moves to bug review, QA rotates to the next waiting BUD, and each bug is auto-classified as a missed feature versus a development bug so it takes the right fix path. Quality debt doesn't pile up quietly, because the system reacts to it before a human notices.

The BUD: one document instead of three tools

Every feature lives in a single markdown document called a BUD — Business Understanding Document. Spec, technical spec, test plan, and decision history, all in one place, vector-indexed so any agent can pull it as context.

# BUD-241 · Idempotent webhook handler for refunds

## Intent
Bank sends the same refund webhook up to 3x. We must process once.

## Acceptance criteria
- Duplicate webhook IDs are a no-op (return 200, no state change)
- A refund on an already-refunded txn is rejected, not retried
- Illegal transition complete → pending is impossible

## Tech plan
- Dedup key: (provider, webhook_id) unique in Postgres
- Reuse shared `refundGuard` util — do NOT reinvent

## History
- 2026-06-05 design approved (human gate)
- 2026-06-05 estimation: P70 = 2 days

That's the whole feature. No ticket in Jira, no spec in Confluence, no test plan in a Google Doc that nobody opens. One file. It travels with the code, and it's the context every agent reads before it touches anything.

Killing story points with statistics

Story points always bothered me. They're a proxy for time that we then pretend isn't a proxy for time, and they don't compose across a team where one person knows a module cold and another has never opened it.

ADD replaces them with AI-PERT plus a Monte Carlo simulation.

For each phase the model generates optimistic / likely / pessimistic estimates — classic PERT — but weighted by a per-developer, per-module skill score (0–1.0, derived from git and BUD history), current load, and backlog depth. Then 10,000 simulated runs turn that distribution into dates with confidence intervals:

Feature: Idempotent refund webhooks
  P50  →  Jun 9   (50% chance done by)
  P70  →  Jun 10  (70% chance done by)
  P85  →  Jun 12  (85% chance done by)

"85% confident by the 12th" is the shape a stakeholder actually wants. It's also honest in a way "8 points" never was — it shows you the uncertainty instead of hiding it inside a fake integer.

Where do those skill scores come from? Git history. The system reads who has actually shipped what, per module, and builds a profile — expertise you can see instead of guess at.

Five developers, eighteen modules, scored from real commits. This is what feeds estimation and routing — not a manager's hunch about who "knows the auth code."

Is the skill-score input perfect? No. It's derived from who happened to touch what, so it can encode bias. That's one of the two things I most want feedback on.

And the loop closes itself. When a BUD ships, the Learning Agent writes the retrospective from the actual diffs — including an estimated-vs-actual table that tells you exactly where the model was wrong, so the next estimate is better.

No retro meeting. The agent reads the merges and the timeline and hands you the drift — Design −25%, Development +603% — so estimation actually learns.

The part that sounds whimsical and isn't: the virtual world

The whole organisation renders as a living 3D world — and it's multiplayer. Not a dashboard you look at. A place your team is actually in, together.

Each repository is a tree. Each feature is a branch. Each agent is an orchardist tending the grove. A feature in progress is a branch growing; a merged one bears fruit; a stalled one needs pruning. Health is visible at a glance: a thriving tree versus one quietly dying.

And every teammate is there with you. You walk around with WASD, sprint, jump, orbit the camera over the grove. Your colleagues are avatars with their own houses, present in real time. You can wave, cheer, greet, invite someone over. It sounds like a game because part of it is one — but the effect is presence. A standup is people reading status out loud. This is people standing in the same place, looking at the same living map of the work.

Your team, present. Move, sprint, wave, cheer, invite. The status bar is real controls, not decoration.

It started as a visualisation. It became the most honest org chart I've ever had — because it's drawn from the code, not from a slide. Here's a walkthrough.

Shipping quality is the game

Here's the part I didn't expect to care about and now love.

The world is gamified — but it rewards the right thing. You earn XP and Skill Points, level up, unlock vehicles, upgrade your house. Crucially, the economy is tuned to quality, not output. Ship a BUD to production: +1 SP. Give a code review: +0.25. Quality score above 80%: +0.5. Bug found in testing: −0.25. Bug found in production: −1. And the points for shipping don't pay out until the BUD actually reaches CLOSED — through testing, UAT, prod. You don't get rewarded for the green checkmark. You get rewarded for the thing surviving contact with reality.

Read the numbers: a production bug costs you more than shipping earns. That's the whole point. In a world where AI can churn out code that passes tests, the scoreboard has to reward what AI is bad at — code that holds up.

That ties straight back to where I started. AI nails the 80%. The 20% — the part that doesn't blow up in production — is what we actually want to incentivise. So that's what the game scores.

It runs on a Mac mini, and your data never leaves it

This is the part I care about most, and the part most "AI dev platform" pitches skip.

Bodhiorchard is self-hosted by design. Postgres with pgvector, your repositories, the embeddings, and the full audit log live on your hardware. For me, that hardware is a Mac mini. No repo content is shipped to anyone's cloud. For a regulated shop — and I lead engineering at an FCA-authorised fintech, so this is not theoretical for me — that's the difference between "interesting demo" and "allowed to exist."

Inference is your choice. It runs on Claude Code today; Ollama and OpenAI are on the roadmap for fully air-gapped setups. The agent layer is engine-independent — swapping the model is API rewiring, not a redeploy.

The stack, for the curious:

Backend   FastAPI · Python 3.12
Frontend  Vue 3 · PlayCanvas (the 3D world)
Data      Postgres + pgvector · Redis
Agents    Local MCP server (read + bounded write tools)
License   Apache 2.0

It's also built for real orgs, not just a solo demo: detailed roles and permissions, multi-org support out of the box, and capacity planning baked into triage and assignment — the Triage Agent defers work when the team is full, and Smart Assignment balances by real-time utilisation rather than who shouts loudest. So the "self-hosted toy" worry doesn't really hold; it'll sit inside an org's access model on day one.

Honest status, because HN will ask anyway

I'd rather tell you this up front than have you find it.

What's live today: the platform, the BUD lifecycle, the MCP write-path, repository and code-graph indexing, skill profiling, and the 3D living-tree dashboard. The agents are real and they work with a human in the loop at every gate.

What I'm still building: the fully autonomous execution loop. The direction I'm taking it is deliberately narrow — auto mode first for small, low-risk BUDs, where one agent chain runs tech spec → code → code review → test → deploy end to end, then stops and waits for a human to approve the release. Not "point the swarm at production and walk away." Lights-out on the small stuff, a human gate where it counts. That's the active work, not a shipped claim. So today this is agents-assisted, human-in-the-loop, and anyone who tells you their agent swarm ships production code fully unattended is selling something.

This is an independent project. I built it solo, on my own time, not affiliated with any employer — the fintech is where I felt the pain, not the thing that owns the code.

You don't have to start from zero

If you're on Jira today, you don't throw your backlog away. Connect Jira Cloud and import your existing issues straight into BUDs — point Bodhiorchard at the work you already have and watch the grove fill in.

The on-ramp is a migration, not a rewrite. Your tickets become BUDs; the agents take it from there.

There's also a cross-repo graph view — bus-factor analysis, threat detection, BUD-stage filtering across every repo — for when you want the dependency map instead of the grove. Same data, different lens.

What I actually want from you

Not stars. Feedback. Two questions I'm genuinely stuck on:

Does "the BUD is the single source of truth" survive contact with your reality? Or does real-world ticketing always sprawl back across five tools no matter what you do?
Where would self-hosted + bring-your-own-inference actually change your mind versus a hosted SaaS PM tool — and where is it just more ops burden you don't want?

The full methodology is written up at bodhiorchard.ai — the twelve agents, the manifesto, the Agile-vs-ADD table, all of it. The repo has six demo videos and four sample repositories you can point it at: https://github.com/mickyarun/bodhiorchard

I spent fifteen years being told the ceremony was the engineering. Sprints felt broken long before AI. AI just made it impossible to keep pretending.

So I replaced them. If you've killed a ceremony and lived to tell the tale — which one did you kill first?

I'm Arun — CTO & Co-Founder of Atoa, a UK open banking payments platform, and the solo author of Bodhiorchard. I write about what building with AI is actually like, not what the conference slides say. Find me on X @mickyarun.

How We Hire for the 20% AI Can't Do (And Why We Stopped Asking Candidates to Code From Scratch)

arun rajkumar — Tue, 02 Jun 2026 14:43:11 +0000

A few weeks ago I published a piece called "AI Agents Are Great at 80% of Our Code. The Other 20% Is Why We Still Need Seniors."

It got 25 reactions and 34 comments. Several of those comments asked the same question in different words:

"How do you actually measure that 20% when you're hiring?"

Fair question. I dodged it in the first article because I didn't have a clean answer yet. Now I do. Or at least, we have a process that's working better than anything we tried before.

This is that answer.

The old interview was broken before AI made it obvious

For years, we ran the standard playbook. Whiteboard problem. Timed coding exercise. "Build a REST endpoint in 45 minutes." You know the drill.

Here's what that interview actually tested: can this person write syntactically correct code under pressure, from memory, with someone watching?

That's a real skill. It's just not the skill that matters anymore.

AI handles the code-writing part. I don't mean it handles it perfectly — I wrote a whole article about the 20% it gets wrong. But the 80% that is boilerplate, CRUD, API wrappers, standard patterns? An agent will generate that in seconds. Clean. Typed. Probably with better variable names than I'd pick.

So if I'm hiring someone and my interview tests whether they can do what an agent already does faster — what exactly am I learning?

That they can type under pressure. Great. So can the agent. And it doesn't get nervous.

The interview we actually run now

We stopped asking candidates to write code from scratch. Instead, we hand them code an AI agent already wrote.

The code looks fine. It passes the tests we included. The variable names are clean. The types are correct. A junior looking at it would say "ship it."

But it's wrong.

Not wrong in a way that crashes. Wrong in a way that costs money three weeks later. Wrong in a way that only someone who thinks about consequences would catch.

Here's the shape of it. We give candidates a webhook handler for processing payment confirmations. The handler works. It receives the event, updates the database, returns a 200. Clean code.

What's missing: idempotency. If the bank retries the webhook — and banks always retry — the handler processes the payment twice. The customer gets charged twice. We get an FCA complaint. The code is correct. The system is broken.

Or we show them a payment flow with state transitions. pending to authorised to settled. Looks right. But there's a path where a payment can go from settled back to pending. That's an illegal state transition. In our domain, that means money that was already in a merchant's account could theoretically get pulled back without a refund record. No test catches it because no test was written for a transition that shouldn't exist.

We ask candidates to review this code. Not write it. Review it.

The ones who have the 20% find these things. Not always immediately. Sometimes they stare at it for five minutes and then say "wait — what happens if this gets called twice?" That moment is worth more than any algorithm they could whiteboard.

It's not what they'd change. It's why.

We added a second part to the interview. Once a candidate identifies issues in the AI-generated code, we ask them to walk us through a PR rejection.

Not "what would you change." We already know what needs to change. We want to hear why they'd reject it.

This is where you separate pattern-matchers from engineers.

A pattern-matcher says: "There's no idempotency key. You should add one." Correct. Also surface-level. They've seen the pattern before and recognized its absence. That's good, but it's not enough.

An engineer says: "There's no idempotency key, which means a network retry from the bank will double-process the payment. The customer sees two debits. Your support team gets a ticket. You file a dispute with the acquiring bank. The refund takes 5-7 business days. And if this happens at volume, you've got a regulatory reporting obligation."

Same observation. Completely different depth. The first person knows the pattern. The second person knows what happens downstream when the pattern is missing.

That downstream awareness — the ability to trace a bug forward through the business — is the 20%.

Hire for intent, not resumes

Our interview process changed because our hiring philosophy changed first.

We don't hire resumes. We hire intent. Let me give you three examples.

One developer's resume listed one skill under "Technical Proficiency": Googling. I'm not paraphrasing. That's what it said. B.Sc. No fancy internships. No side projects on GitHub. Just someone who was honest about what they knew and relentless about learning what they didn't. Today they own our merchant-facing app. The whole thing.

Another cold-messaged us asking for a job. No referral. No warm intro. Just a direct message. In the interview, they were quiet. Not shy — quiet. Listened more than they talked. When they did talk, they went straight to the solution. No preamble, no hedging, no "well it depends." Just: here's the problem, here's how I'd fix it, here's what could go wrong.

A third started as an intern. They're now building our Open Banking integration end-to-end. Not assisting. Not maintaining. Building.

The common thread isn't a degree or a tech stack or years of experience. It's three things: curiosity, ownership, and willingness to be wrong.

The first didn't pretend they knew things they didn't. The second didn't try to impress with volume — they impressed with clarity. The third didn't wait for someone to assign harder problems — they grew into them because the problems were there and they weren't afraid to try.

None of them would have passed the old coding interview particularly well. All of them are exactly the kind of engineer you want reviewing an AI agent's output.

The 20% isn't just code — it's design thinking

Here's something most "AI and hiring" articles miss: the 20% that matters isn't only about catching bugs in payment logic. It's about knowing how to think about problems that don't have a spec yet.

Before Atoa, I spent years in design thinking — working with clients who were showcasing products at CES. One project sticks with me. A world-leading chocolate manufacturer wanted to launch a series of chocolates based on human emotions — Anger, Disgust, Sad, Happy, Wimpy. The brief: build software that captures a person's emotion in real-time, recommends the matching chocolate, and makes it go viral on social media.

Now imagine the marketing manager walks into your office and drops this on your desk. The brief is: make it viral. Which platform do you build on? Where does the experience live? What's the feature that makes someone want to share it?

Assume technically anything is possible. The technology isn't the constraint. Your thinking is.

Here's the filter: if your first answer is "I'll build a mobile app and a web app" — that's a straight reject. Not because mobile and web are wrong technologies. But because you jumped to how before you thought about why. You're solving for delivery before you've solved for virality. You're thinking like a developer when the brief asked you to think like a designer.

The interesting answers start with questions. Who's the audience? Where do they already spend time? What makes someone stop scrolling and share something? What's the 3-second hook? How does the chocolate brand benefit from every share? What's the mechanic that makes this grow without paid media?

Now here's my challenge to you: how would you approach this? Drop it in the comments. Not the tech stack — the thinking. How do you decompose this brief into something that actually goes viral?

There's no single right answer. That's the point. This is a design thinking exercise — the kind of problem where the 20% lives. The brief is intentionally vague. The constraints are real. And the interesting part isn't the technology you pick. It's how you think about a problem before you write a single line of code.

No AI agent is writing a spec for that. No benchmark captures the ability to look at a brief like "emotion-based chocolate recommendation engine for CES" and turn it into a system. That's design thinking. The ability to hold a vague, human problem in your head and translate it into technical architecture — while keeping the user experience front and centre.

I look for this in interviews too. Not the ability to solve a well-defined problem. The ability to define the problem in the first place. When I ask a candidate "how would you approach this?" and they immediately start writing code — that tells me something. When they first ask "who's using this, where, and what does success look like?" — that tells me something very different.

The 20% is judgment about code. But it's also judgment about products, users, and what should exist in the world. AI can generate solutions. It can't ask the right question.

What the 20% actually looks like in an interview

Here's what I'm watching for when a candidate reviews code. It's not a checklist — it's a set of signals.

Do they think about what shouldn't happen?

Most engineers think about the happy path. The payment goes through. The webhook fires. The database updates. Done.

The 20% engineers think about the unhappy path first. What happens when the webhook fires twice? What happens when the database write succeeds but the response times out? What happens when the bank says "yes" and our system says "no" and now the money exists in a state neither side agrees on?

If a candidate's first instinct is "how does this work?" — that's fine. If their first instinct is "how does this break?" — that's the signal.

Do they ask about failure modes before writing anything?

We've started noticing this in walkthroughs. Some candidates immediately start typing fixes. Others ask questions first. "What's the retry policy on these webhooks?" "Is there a dead letter queue?" "What happens to in-flight payments if this service goes down?"

The ones who ask first are almost always better engineers. Not because asking is inherently better than doing. But because in the 20% territory — the code that handles edge cases, race conditions, regulatory requirements — the cost of building the wrong thing is higher than the cost of asking one more question.

Can they explain a tradeoff they made, not just what they chose?

This is the question I ask every candidate, regardless of seniority: "Tell me about a technical decision where you chose the worse option on purpose."

The interesting candidates have an answer. "We chose synchronous calls between two services because the audit trail was easier to reason about, even though async would have been more resilient." "We kept a manual process instead of automating it because the edge cases weren't well understood yet and we didn't want to automate the wrong thing."

The 20% is full of decisions like this. The right answer isn't always the technically superior one. Sometimes the right answer is the one that's easier to debug at 2am, or the one that produces a cleaner audit trail, or the one that a new engineer can understand without reading three pages of context.

The junior training pipeline problem

Here's the question that kept me up after the first article: if AI handles 80% of the code, how do juniors ever build the judgment that makes seniors valuable?

The 80% used to be the training ground. You learn to write CRUD endpoints. You learn to wire up a database. You learn to handle HTTP errors. You make mistakes in the boring code, you get them caught in review, and slowly you develop an instinct for the less boring code.

If an agent writes all of that for you on day one, what are you actually learning?

This is a real problem. And "just let them use AI" isn't the answer, because using AI well requires the judgment you're supposed to be building.

I'll be honest — I've had to let someone go because of this exact gap. They were using AI for everything. But they were using the default model in Cursor while the rest of the team had moved to Opus for anything that touched critical code. They weren't thinking about which tool to use when. They were just pressing tab and shipping. The code looked fine. The judgment wasn't there. And in a payment system, that's not a skill gap you can coach around — it's a risk.

At Atoa, we pair juniors with seniors on the hard problems. Not the 80% problems. The 20% ones. The payment state machine that handles twelve edge cases. The webhook handler that has to be idempotent across retries, timeouts, and partial failures. The reconciliation logic where our system says one thing and the bank says another.

The senior doesn't watch the output. They watch the process. They're looking for two things.

First: "What did you skip?" Not what did you get wrong — what did you not even consider? That gap is where the learning lives. A junior who writes a webhook handler and doesn't think about idempotency hasn't made a mistake. They have a blind spot. Mistakes you can catch in tests. Blind spots you can only catch by asking the right question at the right time. That's what the senior is there for.

Second: "What happens when this fails?" Not "did you handle the error." Did you think about what the system does when this component fails? Does the rest of the pipeline stall? Does the customer see a broken state? Does the merchant lose money? The junior doesn't need to have the answer. They need to have the habit of asking the question.

The painful lessons still happen. They just happen faster because the senior is there to compress the feedback loop from "you'll figure this out in three years" to "let me show you why this matters right now."

The best hire isn't the best coder anymore

Three years ago I'd have hired the candidate who wrote the cleanest code the fastest. That person is still good. They're just not rare anymore. An AI agent writes clean code fast. That's table stakes.

The hire I'm looking for now is the person who reads an AI agent's clean, well-typed, properly structured code — and says "this will break in production, and here's exactly how."

That person can tell an agent what it got wrong. More importantly, they can explain why it matters. Not just "add an idempotency key" but "add an idempotency key because the bank will retry, and without it, this elegant code will charge a customer twice."

The 20% was never about writing harder code. It's about knowing which code is dangerous.

We changed our interview because the job changed. The job isn't writing code anymore. The job is judgment.

And judgment is the one thing you can't generate with a prompt.

This is a sequel to AI Agents Are Great at 80% of Our Code. The Other 20% Is Why We Still Need Seniors. If you're building a team that works with AI agents, I'd love to hear how your hiring process has changed. Drop a comment or find me on X @mickyarun.

AI Agents Are Great at 80% of Our Code. The Other 20% Is Why We Still Need Seniors.

arun rajkumar — Thu, 28 May 2026 06:20:38 +0000

We let AI agents loose on a payment platform. They crushed the boring stuff. Then they silently broke the stuff that matters.

A survey came out last week. 54% of all code is now AI-generated. Up from 28% last year.

I read that number and thought: yeah, that tracks. We're probably in that range too.

But here's the thing nobody's asking — which 54%?

Not all code carries equal weight. A CRUD endpoint for fetching merchant details? Low risk. The webhook handler that transitions a payment from pending to complete? That's someone's rent. Someone's payroll. Get that wrong and money moves where it shouldn't, or worse, money doesn't move at all.

I'm the CTO of a payment platform. FCA-authorised, processing real money, real merchants, real consequences. We run NestJS microservices, Docker, Traefik — the usual stack. And we've been using AI agents aggressively for over a year now.

I'm not here to tell you AI is dangerous. It's not.

I'm here to tell you it's dangerous when you forget what it's actually good at.

The 80% Where AI Agents Are Genuinely Brilliant

Let me give credit where it's due. AI agents have made our team faster in ways that would have seemed absurd two years ago.

API scaffolding. Generating service boilerplate. Writing Zod validation schemas. Spinning up new endpoints. Creating test stubs. Refactoring imports. Migrating patterns across repos.

We run multiple microservices. When we need a new service, an agent can scaffold the entire thing — module structure, base configuration, Docker setup, Traefik labels — in minutes. What used to be a half-day of copy-paste-and-tweak is now a conversation.

When we overhauled our env management across all repos, AI agents did the grunt work. They mapped every .env file, found naming conflicts, identified common variables, and generated a unified Zod schema. What would have taken a team days of grep-and-spreadsheet work took hours.

For this 80% of the codebase — the predictable, pattern-following, structurally repetitive code — AI agents are the best junior developers money can buy. Tireless. Cheap. No ego. Almost never make a mistake on the stuff they're good at.

An army of juniors sitting at your terminal.

Then You Hit the Other 20%

Here's where it gets interesting.

We had an agent build out a webhook handler. Webhooks in payments are critical — they're how you know a payment succeeded, failed, or needs attention. The agent wrote the handler. It looked clean. Tests passed.

But it silently ignored the edge cases.

Status transitions have rules. A payment can go from pending to complete. It cannot go from complete back to pending. When a human developer builds this, they think about the illegal transitions because they've seen what happens when money moves backwards. They build the guard because they've felt the pain of not having it.

The agent didn't care about that. It built the happy path beautifully and treated the edge cases like they didn't exist.

When we do this work manually, this type of error never happens. A senior developer who has worked in payments for years doesn't forget the impossible transitions. It's not in their code — it's in their bones.

The Pattern I Keep Seeing

This isn't a one-off. After months of working with AI agents on a regulated payment stack, one pattern is consistent:

AI agents optimise for completion, not correctness.

They want to finish the feature. Get to the green checkmark. And to get there efficiently, they take shortcuts that look reasonable on the surface.

The agent builds what should happen. It rarely builds what should not happen. In payments, the negative cases are where all the real risk lives. What happens when a webhook arrives twice? What happens when a refund is requested on an already-refunded transaction? What happens when the bank returns an unexpected status code? The agent doesn't think about any of that unless you explicitly tell it to.

Then there's the reusability problem. We have shared utility packages. Helper functions. Common patterns that the team has standardised on over years. The agent doesn't care. It writes its own version from scratch. It works, but now you have two implementations of the same logic — one tested and trusted in production, one freshly generated and untested. The agent is focused on completing this feature, not maintaining the architecture.

And the subtlest one — agents seem to optimise for fewer back-and-forth turns. It looks like they're saving cost, saving context. Complex validation? Skip it, the basic case works. Error handling for a rare edge case? Not worth the tokens. The result is code that passes every test you wrote but fails on the scenarios you didn't think to test — because those are exactly the scenarios the agent also didn't think about.

Juniors Don't Ship Products. They Write Code.

Here's the frame that made this click for me.

Claude — or any coding agent — is the best junior developer money can buy. An army of juniors. Tireless, cheap, no ego, near-zero error rate on routine work.

But juniors don't ship products. They write code.

The difference between code and a product is judgment. Knowing which transitions are illegal. Knowing that the retry logic has a specific backoff curve because you've been burned by what happens when it doesn't. Knowing that the webhook handler needs idempotency because banks sometimes send the same notification three times.

That knowledge doesn't come from training data. It comes from years of operating a system, debugging at 2am, explaining to a merchant why their settlement was delayed.

The most dangerous mistake a CTO can make in 2026 is buying AI to replace senior engineers. The right move is buying AI to enable them.

Replace your senior with AI? You get speed plus silent disasters.

Enable your senior with AI? You get an architect with an army.

What We Actually Do About It

I'm not writing this to complain about AI. I'm writing this because we've built a system that works, and it might help you too.

The first thing we did was make our architecture machine-readable. We extract design patterns and architecture rules into formats that agents can consume. When an agent works on our codebase, it doesn't just see code — it sees boundaries, patterns, rules about what belongs where. Not documentation nobody reads. Lints and constraints that the agent can't ignore.

Then we invested heavily in testing the negative cases. Every PR — human or AI — runs through the same suite. But we specifically built tests for the stuff agents skip: illegal state transitions, duplicate webhook handling, idempotency checks. If the agent silently drops a negative case, the tests catch it before it ships.

And seniors still review everything that touches money. No AI-generated payment logic ships without a senior looking at it. Not because we don't trust AI — because we know exactly where it's blind. The review isn't checking syntax. It's checking judgment. Did the agent handle the ambiguous bank status? Did it respect our existing retry logic? Did it use the shared utility or reinvent the wheel?

This problem bothered me enough that I started building Bodhi Orchard — an open-source agentic development framework. The core idea: don't just let agents write code. Feed them the full context — architecture, design patterns, test plans, existing utilities — so they stop making the same blind-spot mistakes. Human decisions over human busywork, with guardrails that actually enforce quality.

The Real Question for 2026

The survey says 54% of code is AI-generated. I believe it.

But here's my question: what percentage of bugs in 2026 will be AI-generated?

And more importantly — who's going to find them?

Not the agents. They wrote the bugs in the first place. Not the juniors — they won't know enough to spot what's missing.

It's going to be the seniors. The architects. The people who've operated these systems long enough to know where the bodies are buried.

The 80% is solved. AI won. Celebrate that.

Now invest in the humans who understand the other 20%. Because that's where your product lives or dies.

I'm Arun, CTO & Co-Founder of Atoa — a UK open banking payment platform. I write about what it's actually like to build fintech with AI, not what the conference slides say it's like. If this resonated, follow me here or on X @mickyarun.

And if you're curious about building AI-native development with proper guardrails, check out Bodhi Orchard.

Your Payment API Wasn't Built for AI Agents. Open Banking Might Be the Fix.

arun rajkumar — Wed, 27 May 2026 11:09:19 +0000

Stripe just shipped an Agentic Commerce Suite. PayPal launched Agent Ready. Visa predicts millions of consumers will use AI agents to complete purchases by the 2026 holiday season. Mastercard introduced Agent Pay with its own verification layer. Google launched the Agent Payments Protocol with 60+ partners.

Everyone is scrambling to make payments work for AI agents.

And I keep looking at all of it thinking: you're bolting agent support onto a stack that was designed for a human staring at a checkout page. That's not an integration. That's a retrofit.

I run payments infrastructure. Our platform processes open banking payments for UK merchants — the kind where money moves directly from the customer's bank account, no card network in between. And from where I sit, the agentic payments conversation has a blind spot the size of Visa's interchange fee.

Let me explain.

The card stack assumes a human is present

Here's what happens when you process a card payment today:

User types card number into a form (or taps a saved card)
Your frontend collects PAN data, sends it to a tokenisation layer
The token goes to an acquirer, who talks to the card network, who talks to the issuing bank
3D Secure kicks in — the user gets a push notification or SMS OTP
The issuing bank authorises (or declines)
Settlement happens days later

That flow was designed around one assumption: a human is sitting at a screen, ready to respond to authentication challenges.

Now replace the human with an AI agent.

The agent doesn't have eyes to read an OTP. It can't tap "approve" on a banking app push notification. It can't solve a CAPTCHA. It can't parse a 3DS iframe that renders differently on every issuing bank's domain.

So what do the card networks do? They build workarounds. Stripe's agentic suite generates virtual cards. Mastercard's Agent Pay pre-registers agents and skips some auth steps. Everyone is finding clever ways to route around the authentication wall that they built.

That's the tell. When your entire ecosystem is engineering around its own security layer, the architecture has a problem.

Open banking was built for machines talking to machines

Open banking works differently. There's no card number. No PAN. No tokenisation vault. No 3DS iframe.

Here's the flow:

Your app (or agent) calls a payment initiation API
The API returns a redirect URL to the customer's bank
The customer authenticates directly with their bank (biometrics, app-based SCA)
The bank confirms the payment
Money moves. Settlement is instant or same-day.

Notice what's different. The payment API is a clean, stateless request-response interface. The authentication happens on the bank's side, not inside your checkout flow. Your code never sees a card number, never handles an OTP, never renders an auth challenge.

For a human using a checkout page, this is a nice UX improvement. For an AI agent calling a payment API, this is a structural advantage.

The agent makes an API call. It gets back a payment URL. It hands that URL to the human for one-time bank authentication. Done. The agent doesn't need to handle auth. The bank does. The separation of concerns is clean.

And with VRPs (Variable Recurring Payments) now live in the UK, it gets even better. The human authenticates once, sets spending limits, and the agent can initiate payments within those limits without any further human interaction. No virtual cards. No pre-registered agent identities. Just an API call against a mandate.

That's not a workaround. That's the architecture actually working as designed.

What breaks when agents use card APIs

I've been watching developers try to build agentic payment flows on card rails. Here's what keeps going wrong:

PCI scope explosion. If your agent is generating virtual cards, storing card tokens, or managing card-on-file relationships, your PCI compliance surface just grew. AI agents that handle card data need the same compliance posture as any system that touches PANs. That's not a small thing. That's SOC2 scope, penetration testing, quarterly scans — all for an agent that could've made a bank-to-bank API call instead.

Authentication is the bottleneck. 3D Secure was designed as a human-in-the-loop check. Every attempt to skip it for agents either weakens security (bad) or creates a parallel auth system (complex and fragile). Open banking's approach — SCA happens at the bank, not at your checkout — means the agent never needs to authenticate. It just calls the API.

Settlement lag creates state management nightmares. Card payments settle in days. When an agent is orchestrating a multi-step workflow (compare prices → select vendor → pay → confirm delivery), it needs to know whether payment actually landed. With cards, you get an authorisation that might reverse, a settlement that arrives Tuesday, and a chargeback window that stays open for months. With open banking, payment confirmation is real-time. The state machine is simpler because the money actually moved.

Micro-payments don't work on card rails. AI agents generate hundreds of micro-transactions per session. The interchange fee floor on card payments makes sub-pound transactions economically absurd. Open banking's fee structure is flat or percentage-based without the card network's minimum — which is why it actually works for the agentic pattern of many small, frequent payments.

What I'd actually build

If I were starting an agentic commerce integration today for UK customers, here's the architecture I'd reach for:

For one-off agent-initiated purchases: Open banking payment initiation. The agent creates a payment request via API, gets a consent URL, passes it to the user. One SCA event, then the money moves. No card data anywhere in the stack.

Agent → Payment API (create payment request)
      → User gets bank auth link
      → User approves in banking app (biometrics)
      → Webhook confirms payment
      → Agent continues workflow

For recurring agent-managed spending: VRP mandates. User sets up a mandate once — monthly cap, per-transaction cap, approved merchant. The agent calls the payment API within those bounds. No re-authentication. No virtual cards. No 3DS.

User → Sets up VRP mandate (one-time SCA)
Agent → Calls payment API within mandate limits
      → Instant confirmation via webhook
      → No further user interaction needed

For the auth layer: Don't build one. Seriously. The bank handles it. Your agent's job is to orchestrate the payment flow, not to authenticate the user. That's separation of concerns, and it's the right call whether you're building for agents or humans.

The real question no one's asking

Everyone is asking "how do we make card payments work for AI agents?"

I think that's the wrong question.

The right question is: why are we starting with the payment rail that requires the most human interaction, then engineering the human out?

Open banking was built on the premise that software talks to bank APIs. The authentication layer lives at the bank. The payment instruction is a clean API call. Settlement is immediate. There's no card number to protect, no 3DS challenge to render, no interchange fee eating your margin on micro-transactions.

It wasn't designed for AI agents. But its architecture fits the agentic pattern better than anything the card networks are retrofitting.

Sometimes the future doesn't come from the company with the biggest R&D budget. Sometimes it comes from the infrastructure that was built on the right abstraction in the first place.

The UK has live open banking rails, live VRPs, and an FCA that's actively building the regulatory framework for what comes next. If you're a developer building agentic commerce for UK customers, you have a head start. Use it.

I'm Arun, CTO at Atoa. We build open banking payment infrastructure for UK merchants. If you want to see what the API looks like: docs.atoa.me

Try the sandbox → docs.atoa.me

FCA Just Rewrote the Open Banking Playbook for 2026. Here's What UK Payment Developers Actually Need to Know

arun rajkumar — Wed, 13 May 2026 10:08:03 +0000

I'm the CTO of an FCA-authorised Payment Institution. I spend most of my week either writing payments code or reading FCA / PSR consultation papers so my team doesn't have to.

2026 is the year that work stopped being optional for everyone else.

Three things shifted in the first half of the year, and if you ship anything that touches UK payments — checkouts, wallets, invoicing, recurring billing — at least two of them affect your roadmap. Most developer threads I read are still pattern-matching open banking onto "OAuth, but for banks." The actual changes are more interesting than that, and a lot more consequential.

Here's the part I wish someone had handed me as a one-pager.

1. Variable Recurring Payments went from "spec" to "shipping"

The FCA confirmed that the first commercial Variable Recurring Payments (VRPs) under the UK Payments Initiative scheme started flowing in Q1 2026. Phase 1 covers utilities, financial services top-ups, and payments to local and central government. (FCA / PSR joint statement on open banking pricing models)

For developers, this is the line where open banking stops being a one-off-payment toy and starts looking like a real subscription rail.

What changes in your code:

Consent has duration now. A VRP consent is the closest thing UK open banking has ever had to "card-on-file." The user authorises a mandate — amount caps per period, total cap, expiry — and you can initiate payments against it without a fresh SCA dance every time. That's a different state machine than single-payment PIS.
You need to store mandate IDs, not card tokens. The shape of the entity you persist is closer to a Direct Debit instruction than a Stripe payment_method. Caps, frequency, last-used timestamp, status, revocation timestamp.
Revocation is bank-side, not app-side. Users can kill a VRP mandate inside their banking app and you get a webhook telling you it's gone. If your retry logic assumes the mandate is still good because the user didn't cancel in your UI, you'll log a lot of 401s.
Pricing is now regulated. The FCA / PSR joint statement in 2026 explicitly addressed VRP pricing models. Translation: this is no longer a back-room commercial conversation between ASPSPs and TPPs. The rate card has rails.

If you're SaaS-billed-monthly and your customers are UK consumers, this is the first year where "switch from cards to open banking" is a real engineering conversation, not a 2027 prediction.

2. The FCA is getting actual rule-making powers over open banking

The other big shift: the Data (Use and Access) Act gives the FCA new statutory powers to set open banking rules directly, rather than acting through the legacy CMA-mandated framework. The FCA has said it will consult on the long-term regulatory framework before the end of 2026, with workshops over the summer and autumn. (FCA: Open banking — a year of progress)

A developer-facing translation:

The Open Banking Implementation Entity (OBIE) era is winding down. A "Future Entity" is being stood up — the FCA wrote to trade associations in late 2025 and expected the process to kick off around February 2026. (Open banking — process to establish a Future Entity)
The Open Banking Standard you've been integrating against will get formalised into FCA rules instead of CMA orders. Same spec, harder enforcement, broader scope.
Expect new categories of regulated activity to land in scope: open finance (savings, pensions, investments, insurance) is being framed as the next phase, and the FCA published a vision paper for it. (FCA: vision for open finance)

If you're betting on open banking, you're now betting on a rail with a clearer regulator on top of it. That tends to be good for serious builders and bad for people who were treating PISP authorisation as optional.

3. The architecture decision hasn't changed, but the stakes have

The architectural choice for any UK payment developer is still binary, and it's the same one I wrote about in What Developers Get Wrong About PSD2 a few weeks ago:

Become an FCA-authorised PISP yourself. Months of compliance work. A regulated entity. Ongoing capital requirements. Direct ASPSP relationships. Worth it if payments is your business.
Integrate against an authorised provider. Days, not months. One API. Webhook semantics that don't change every time a CMA9 bank updates their consent flow.

What 2026 changes is the cost of getting this wrong. With VRPs going live, open finance on the roadmap, and the FCA now sitting on direct rule-making powers, the compliance surface is going to grow. If you've shipped a bank-by-bank integration, that surface grows linearly with every spec revision. We learned this running payments services across the CMA9 — every quarter, something changes.

If you're not a payments company, don't become one by accident.

What the integration actually looks like

Same minimal pattern as a single-payment PIS, slightly different envelope for VRP. A mandate creation against Atoa looks roughly like this:

// 1. Create a VRP mandate
const mandate = await fetch('https://api.atoa.me/v1/mandates', {
  method: 'POST',
  headers: {
    'Authorization': `Bearer ${ATOA_API_KEY}`,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    reference: subscription.id,
    period: 'monthly',
    max_amount_per_period: 4999,   // £49.99 cap per month
    max_total_amount: 599999,       // £5,999.99 lifetime cap
    expires_at: '2027-05-13',
    redirect_url: 'https://app.example.com/mandates/return',
  }),
}).then(r => r.json());

// 2. Send the customer to mandate.authorisation_url
return res.redirect(mandate.authorisation_url);

// 3. Later, charge against the mandate without re-authing the user
const payment = await fetch(`https://api.atoa.me/v1/mandates/${mandate.id}/payments`, {
  method: 'POST',
  headers: {
    'Authorization': `Bearer ${ATOA_API_KEY}`,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    amount: 4999,
    currency: 'GBP',
    reference: invoice.id,
  }),
}).then(r => r.json());

The user does SCA once, when the mandate is created. Every subsequent charge is a single API call. No 3DS dialogs. No saved-card vault. No PAN data on your servers.

This is the thing developers don't realise until they ship it: the new open banking rail isn't a worse Stripe — it's a different shape, and once VRPs are live, that shape covers most of the cases card-on-file used to.

What I'd do this quarter

If you're shipping UK payments in 2026, three concrete moves:

Add VRP to your payments roadmap, even if you don't ship it this quarter. The schema you'd need to model mandates is going to land in your codebase eventually. Sketch the data model now while you're still designing.
Decide whether you're integrating directly or through an aggregator before the FCA consultation lands. The new rules will reset the bar for "compliant" — if you're piecing together bank integrations, you've now got a regulatory clock on top of an engineering one.
Subscribe to the FCA consultation feed. Genuinely. The 2026 papers will set the rails for the next five years. (FCA: vision for open finance)

This is the moment open banking stops being "the alternative" and starts being "the rail." If you're a developer shipping UK payments, the bet you're being asked to make this year is whether you want to build on the rail before it's mainstream, or after.

I'd build on it now.

If you want to try the API and skip the regulatory headache, the sandbox is open: docs.atoa.me.

Payment Webhooks Will Lie To You. Here's How We Built Ones That Don't (in NestJS)

arun rajkumar — Wed, 29 Apr 2026 11:48:31 +0000

A payment webhook fires once. You miss it. The customer thinks they paid. Your dashboard says they didn't.

Welcome to my Tuesday morning, two years ago.

I've shipped four payment webhook systems in my career. The first three taught me everything I now refuse to do again. The fourth — the one running inside Atoa today — handles open banking payment notifications across our Node.js services without a single missed event in the last 14 months.

Here's the boring, opinionated, production-tested pattern.

The lie webhooks tell you

Every payment platform sells webhooks the same way:

"We'll notify your endpoint the moment the payment status changes."

What they don't sell you on:

Webhooks retry. Sometimes 8 times. Sometimes never.
Webhooks arrive out of order. failed can land before pending.
Webhooks lie about idempotency. Two succeeded events for the same payment is normal, not a bug.
Webhooks drop. Network blip, your pod restart, a bad DNS lookup — one missed delivery and your reconciliation is wrong.

If your webhook handler is a 30-line controller that updates a row in your database, you don't have a payment system. You have a hope.

The four-layer pattern

Every webhook flow we run at Atoa has four layers. Skip any one and you'll be reconciling spreadsheets at midnight.

1. Verify the signature before you parse the body

The most common bug I see in code reviews from junior devs: parsing the JSON before checking the HMAC.

// webhook.controller.ts
@Post('atoa')
async handle(
  @Headers('x-atoa-signature') signature: string,
  @RawBody() body: Buffer,        // raw, not parsed
) {
  if (!this.crypto.verify(body, signature, this.secret)) {
    throw new UnauthorizedException();
  }

  const event = JSON.parse(body.toString());
  await this.queue.enqueue(event);
  return { received: true };
}

Two non-negotiables:

Use the raw body for HMAC verification. NestJS's default JSON parser will mutate whitespace and break your signature check. Enable rawBody: true on the app.
Reject before you do anything else. No DB hits, no logging the payload at info level, nothing.

2. Acknowledge fast. Process slow.

The webhook controller does two things: verify, enqueue. That's it.

async handle(...) {
  // verify (above)
  await this.queue.enqueue('payment.webhook', event);
  return { received: true };  // 200 within ~50ms
}

If your handler takes 8 seconds because you're hitting Stripe + your DB + sending an email, the sender will time out and retry. Now you have two events. Then four. Then the on-call engineer.

We use BullMQ on Redis. You can use SQS, NATS, Kafka — pick your poison. The point is: the HTTP response is decoupled from the work.

3. Idempotency keys are not optional

Every event has an event_id. Before you do anything in your worker:

@Processor('payment.webhook')
export class WebhookProcessor {
  async process(job: Job<WebhookEvent>) {
    const { event_id, payment_id, status } = job.data;

    const seen = await this.events.firstSeen(event_id);
    if (!seen) {
      this.logger.log(`Duplicate event ${event_id} — skipping`);
      return;
    }

    await this.applyStatus(payment_id, status, event_id);
  }
}

firstSeen is a write to a Postgres table with event_id as the primary key. If the insert succeeds, this is the first time we've seen this event. If it conflicts, we've processed it before. No race conditions, no Redis dance — just let the database do the work it's good at.

4. State machines, not status updates

This is the one that took me three failed payment systems to learn.

A payment doesn't have a "status field." It has a state machine. Some transitions are legal. Most aren't.

const ALLOWED: Record<PaymentStatus, PaymentStatus[]> = {
  initiated: ['authorising', 'failed'],
  authorising: ['succeeded', 'failed'],
  succeeded: [],            // terminal
  failed: [],               // terminal
};

async applyStatus(id: string, next: PaymentStatus, eventId: string) {
  const payment = await this.payments.findById(id);
  if (!ALLOWED[payment.status].includes(next)) {
    this.logger.warn(`Illegal transition: ${payment.status} → ${next}`);
    return;       // do not update, do not throw — this is normal
  }
  await this.payments.transition(id, next, eventId);
}

Why this matters: when failed arrives before pending (and it will), your code shouldn't downgrade a succeeded payment to failed. With a state machine, the invalid transition is dropped. The reconciler picks it up later. The customer's payment stays correct.

What we'd never do again

Three patterns I see in the wild that I had to unlearn:

Polling instead of webhooks. "We'll just check the status every 30 seconds." Sure — and you'll burn rate limits, miss the 5-second window where a customer is staring at the spinner, and pay for compute that does nothing 99% of the time.
Replaying webhooks by re-running the handler. If the handler does five things, replaying it does five things again. Idempotency keys mean replays are free.
Logging the full payload at info level. PSD2 says your logs are PII now. Log the event_id and the status. Nothing else.

Where this gets you

We process open banking payment notifications across dozens of UK merchants on this exact pattern. Zero missed events in 14 months. Reconciliation runs once a day and finds nothing to reconcile.

The pattern doesn't care which payment provider you use. Stripe, GoCardless, Atoa — same four layers.

If you want to see what these webhooks look like on the open banking side, our API docs walk through the full payment lifecycle and the webhook events we fire: docs.atoa.me. Sandbox is free, no card needed.

Build the boring layers first. Sleep through Tuesday mornings.

Arun is co-founder & CTO of Atoa, a UK open banking payments platform. He's @mickyarun on X and dev.to. Driven by passion.

I Asked Three Coding Agents to Build My Son's Cricket Coach a Website. The Result Wasn't Decided by the Model — It Was Decided by Taste.

arun rajkumar — Tue, 28 Apr 2026 08:51:56 +0000

TL;DR — Codex GPT-5.5, Claude Opus 4.7, Gemini 3.1 Pro. Same prompt. Same 18 photos. Five total runs across different effort budgets. The one that won wasn't the prettiest. It was the one that understood the job: parents in Bengaluru enquire on WhatsApp, not contact forms.

My son's cricket coach asked me for a website.

Saturday afternoon. He runs Bangalore Royal Cricket Academy — a small but seriously good cricket academy for kids. He had two phone numbers, a folder of 18 WhatsApp photos taken by parents, and a single line of brief: "Like a real cricket academy, parents should be able to call or WhatsApp from their phone."

I'm a CTO. I'm in the trenches with AI coding agents most weeks. This felt like a clean, low-stakes test.

So I gave the exact same prompt and the exact same 18 photos to three coding agents:

OpenAI Codex (GPT-5.5, medium effort)
Anthropic Claude Opus 4.7 (low effort, then re-run on medium)
Google Gemini 3.1 Pro (low effort, then re-run on high)

Five outputs. One Saturday. Five very different opinions on what "a cricket academy website" actually is.

I went in expecting a verdict on visual quality. I didn't get one. I got something more interesting.

The setup

The prompt was deliberately short:

Build a single-page website for Bangalore Royal Cricket Academy. Brand line: "Nurturing champions, one delivery at a time." Programs: Summer Camp, Weekday Batch, Weekend Batch, Intensive (elite). Two phone numbers. The photos are in /photos for website. Parents should be able to contact us easily from their phone.

That's it. No design system. No colour palette. No mention of WhatsApp by name. No mention of tests, deployment, SEO meta, or Cloudflare. Whatever each agent decided "easily contact us from their phone" meant — that was on the agent.

What I got back, in five outputs

1. Claude Opus 4.7, low effort

Single-file HTML, Tailwind via CDN, Bebas Neue display font, royal navy + gold palette.

The headline made me sit up: "CHAMPIONS ARE / BUILT HERE." with the second half in gold. It was the only one of the five where the hero felt like it belonged on a printed flyer the coach would hand out at a school. Visually polished.

Engineering-wise, thin: no tests, no OG tags beyond a <meta description>, photos referenced as img-01.jpg…img-18.jpg, all 14 used in a uniform 4-column grid. Tel: links only. No WhatsApp.

2. Claude Opus 4.7, medium effort

Same starting point, completely different output.

<section id="top" class="relative h-screen min-h-[640px] w-full overflow-hidden">
  <div class="absolute inset-0">
    <img src="assets/photos/brca-01.jpeg" alt="" class="kenburns" />
    <div class="absolute inset-0 bg-gradient-to-b from-navy-deep/85 via-navy/70 to-navy-deep/95"></div>
  </div>
  ...
</section>

Full-screen hero with a Ken Burns animation on the image. A scroll indicator with an animated dot inside a mouse outline. A gold cricket-seam pattern divider between sections — actual dashed lines that look like ball stitching. Two-image collage in the about section with offset margins. CSS-columns masonry gallery using all 15 photos. Inline-SVG favicon as a data URI (one fewer request). OG tags. theme-color. WhatsApp deep-link button on the contact section.

<a href="https://wa.me/917337726777?text=Hi%20BRCA%2C%20I%27d%20like%20to%20know%20more%20about%20your%20programs."
   target="_blank" rel="noopener"
   class="bg-gold text-navy font-semibold px-6 py-3.5 rounded-md">
  💬 Message us on WhatsApp
</a>

This was the prettiest output of the five. By a clear margin. Bebas Neue + Inter, Ken Burns, gold seam, masonry — the only one I'd let near a printer.

Still Tailwind via CDN. Still no test suite. Still no automated deploy. Photos renamed semantically (brca-01.jpeg).

3. Codex GPT-5.5, medium effort

Vanilla HTML + 800-line vanilla CSS + 16 lines of vanilla JS. White-and-navy local-business layout. Numbered "01–04" feature blocks. WhatsApp green CTAs in the contact section.

It looks less editorial than Claude-medium. It also does five things none of the others did.

One. It picked 6 photos out of 18 and renamed them by content:

brca-team-ground.jpeg
brca-trophy-team.jpeg
brca-trophy-presentation.jpeg
brca-young-achievers.jpeg
brca-coaching-moment.jpeg
brca-floodlight-batch.jpeg

That's editorial judgement encoded in code output. It chose; it didn't dump everything into a grid.

Two. It wrote a _headers file:

/*
  X-Content-Type-Options: nosniff
  Referrer-Policy: strict-origin-when-cross-origin
  Permissions-Policy: camera=(), microphone=(), geolocation=()

/assets/*
  Cache-Control: public, max-age=31536000, immutable

Security headers and cache rules. I didn't ask for them.

Three. It wrote a real test suite using node:test:

test('home page exposes call and WhatsApp enrollment links', async () => {
  const html = await text('index.html');
  assert.match(html, /href="tel:\+917337726777"/);
  assert.match(html, /href="tel:\+917337736777"/);
  assert.match(html, /https:\/\/wa\.me\/917337726777/);
  assert.match(html, /https:\/\/wa\.me\/917337736777/);
});

test('referenced local assets and Cloudflare Pages config exist', async () => {
  const imageRefs = [...html.matchAll(/src="([^"]+\.(?:jpg|jpeg|png|webp))"/gi)]
    .map(m => m[1]);
  assert.ok(imageRefs.length >= 6, 'at least six academy photos are used');
  for (const ref of imageRefs) {
    assert.ok(existsSync(new URL(ref, root)), `${ref} exists`);
  }
});

Three tests. They assert brand text, both phone numbers, both WhatsApp links, security file existence, responsive CSS, and that every referenced image actually exists on disk. That last one is the one I respect most. It catches the single most common silent break in a static site.

Four. Every primary CTA is a wa.me deep link with prefilled message text:

<a class="contact-link whatsapp"
   href="https://wa.me/917337726777?text=Hi%20BRCA%2C%20I%20would%20like%20to%20know%20more%20about%20cricket%20training."
   target="_blank" rel="noopener">
  <span>WhatsApp</span>
  <strong>7337726777</strong>
</a>

Not just wa.me/91…. Pre-filled message text. Parent taps. Message lands. Zero typing.

Five. It deployed it. It opened my browser, walked me through a Cloudflare OAuth handshake, then pushed the build to Cloudflare Pages. The .wrangler/cache/pages.json left behind:

{ "account_id": "...", "project_name": "brca-academy" }

Most coding agents stop at "here's the HTML." Codex stopped at a live URL. That distinction — treating "build a website" as a unit of work that includes shipping, not just generating markup — is what made me rate it the most production-ready output of the five.

4. Gemini 3.1 Pro, low effort

Dark slate background. Electric blue + amber accents. 60 lines of vanilla JS with an IntersectionObserver scroll-reveal effect.

It looked like a SaaS analytics dashboard. Wrong audience by about ten years. Photos referenced as photo_1.jpeg…photo_18.jpeg. Tel: only.

5. Gemini 3.1 Pro, high effort

Palette fixed: navy + amber. Playfair Display + Outfit for typography. About section with an image collage and an "Elite Training Facility" badge. Wider elite-program card with a dedicated highlights box. Mobile menu with hamburger.

Visually, a different website from the low-effort version. Genuinely better.

What it still didn't have:

WhatsApp deep links. Anywhere. Tel: only.
OG tags or theme-color.
A test suite.
A deployment config.
Semantic photo names — still img1.jpeg through img8.jpeg.

More budget bought better visuals. It didn't buy better judgement about what a Bengaluru cricket academy website is for.

What actually decided it

Not the prettiest hero. Not the cleverest animation.

This:

In Bengaluru, parents enquire on WhatsApp. Not email. Not contact forms. Not phone calls until they've messaged first.

The single biggest conversion lever for an Indian local business website is wa.me deep linking with prefilled message text. Parent opens the page. Parent taps the button. WhatsApp opens with "Hi BRCA, I would like to know more about cricket training" already typed. They send. Coach gets a notification.

Codex did this on every primary CTA. Claude-medium did it as one button at the bottom of the contact section. Claude-low, Gemini-low, and Gemini-high didn't do it at all.

That single decision was worth more than the prettiest hero in the comparison.

The thing I wasn't expecting

I went in assuming effort budget would be the variable that explained quality differences.

Compare what happened when I doubled the effort budget on each model:

Claude (low → medium): The visual quality jumped from "pretty" to "editorial-grade". It added Ken Burns animation, masonry gallery, OG tags, a theme-color, semantic photo names, and a WhatsApp button. It also renamed photos from img-XX.jpg to brca-XX.jpeg. The model used the extra budget to upgrade both taste and product judgement.

Gemini (low → high): The visual quality jumped. The palette got fixed. The typography got upgraded. The layout got more sophisticated.

It still didn't add WhatsApp.

It still didn't write tests.

It still didn't deploy.

It still left photos as img1.jpeg.

More budget didn't teach the model what the website was for. It only taught it to make the wrong website prettier.

The headline isn't Codex won because GPT-5.5 is the best model. The headline is:

Effort budget isn't the variable that explains output quality. Taste is.

Codex on a single medium run produced more production-ready output than Gemini on high. Claude on medium produced the most beautiful site in the lineup. Gemini on high produced a much-improved-but-still-fundamentally-misjudged website.

The extra budget surfaced what each model already understood about the job. It didn't change what the model thought the job was.

Sidebar: Two paths to a Cloudflare token

Worth mentioning because it's the kind of thing CTOs care about.

When each agent needed to deploy to Cloudflare Pages, they took one of two paths:

Path A — silent OAuth. Codex (medium) and Gemini (low) opened my browser, walked me through Cloudflare's OAuth flow, and got a session. Fast. Smooth. I never saw the token. The agent now has access to my entire Cloudflare account for the duration of that session.

Path B — paste-your-own-token. Claude (at every effort level) and Gemini (at medium effort) said: "Go to Cloudflare → My Profile → API Tokens → Create Token with these specific scopes — Account: Cloudflare Pages: Edit — and paste it here. I won't see your account session." More friction at install time. Also more control: the token is scoped, I can see exactly what I gave the agent, I can rotate or revoke it without touching my main session.

Both are defensible. Path A optimises for time-to-deploy. Path B optimises for credential hygiene.

If you're a solo developer building a side project, Path A is probably fine. If you're running production infrastructure for a fintech and an AI agent is asking for credentials, Path B is the only answer. The fact that two of three agents converge to Path B at higher effort levels — Claude always, Gemini at medium and above — suggests their "thoughtful" mode is more security-aware. Codex stayed silent-OAuth even at medium. Worth knowing.

What this means for picking a coding agent in 2026

Three takeaways, none of them about benchmarks.

One. Test the agent on a job, not on a problem. "Build a website" and "build a website that converts WhatsApp leads for an Indian local business" are different evaluations. The first is a syntax exercise. The second tells you whether the agent can read the room.

Two. Effort budgets are amplifiers, not teachers. They make a model more of what it already is. If a model doesn't understand the job at low effort, high effort will produce a more polished version of the wrong thing.

Three. Production scaffolding is the cheapest signal of seriousness. Tests. Headers. OG meta. A 404.html. Curated photos with content-aware filenames. None of these were in my prompt. The agent that wrote all of them on its own is the one I trust with code I can't review line by line.

Coda — what actually shipped

I have to be honest about something the single-shot benchmark couldn't capture.

Codex won my engineering eval. That stands. It's the one I'd hand a junior dev and say "ship it."

But the one I reached for next was Claude.

Two more prompts with the medium-effort Claude — "add a persistent WhatsApp floating button," "add a three-card contact section like a real local business, with primary office / coaching desk / WhatsApp" — and a bit of browser automation to handle the Cloudflare deploy and DNS, and the site went live at brca.in.

That's the version the coach is using today. WhatsApp floating button. Three contact cards. A "Free trial session available" pill the coach asked for after the first parent enquiry. A schedule strip. Custom domain. Live HTTPS.

Why Claude, not Codex — given my own engineering verdict?

Because the single-shot test answers "which agent has the best instincts." The shipping test answers "which agent do I want as a collaborator."

Those are different questions. They had different answers for me.

Claude was the one I wanted to keep editing. The Bebas Neue + gold-seam aesthetic, the masonry gallery, the Ken Burns hero — those are the parts of the design I didn't want to throw away. Codex's output was more correct. Claude's output was the one I had a relationship with.

That's a real signal. Worth saying out loud.

The closer

The coach got a website. Parents got a WhatsApp button. The site is live at brca.in.

The first parent message landed in the inbox before sundown. "Hi BRCA, I would like to know more about cricket training."

The one-shot finding holds: at first contact, taste decided the comparison. Codex's instinct for what an Indian local business website needed to do was sharper than any other model in the lineup.

But the part of the comparison nobody benchmarks is the part that matters most after the demo: which agent do you actually want to keep working with.

For me, on this job — it was Claude.

Champions are built here. Apparently websites too.

Site live at brca.in. Drop a comment if you'd like the source code for all five runs — happy to share the GitHub repo.

What I'd love to know: which agent are you reaching for in 2026 — and what's the smallest job you've used to test whether it actually understands the room? Reply below.

Your Agent Doesn't Need a Better Model — It Needs a Context Layer

arun rajkumar — Fri, 24 Apr 2026 12:49:42 +0000

We stopped trying to find a better model.

We built a better context surface. Different problem. Different fix.

Here's the story of how we got there, and why I think most teams in 2026 are optimising the wrong side of the equation.

The 1,200-line PR

A few months ago, one of our engineers asked an AI agent to help add a new refund flow to our merchant service. The agent returned a PR. 1,200 lines. It compiled. The tests passed.

It also did three things we'd explicitly decided, months earlier, to never do in this codebase:

It created a new service-to-service HTTP client instead of using our internal ServiceBus abstraction.
It persisted refund state in the merchant service's own database instead of emitting a domain event for the ledger service to consume.
It wrote a retry loop with setTimeout instead of using our @Retryable decorator, which has backoff policies tied to our SLOs.

None of this is in the agent's training data. Nothing in the README told it either. And the reviewer — doing the review at 6pm on a Friday — skimmed the diff, saw green CI, and approved.

Two weeks later we had a duplicate-refund incident. One hour of debugging to find the cause. Not a bug in the agent's code. A design-pattern violation the agent had no way to know existed.

The realisation

Here's the uncomfortable part.

The agent didn't do anything wrong. It did exactly what a capable junior engineer would have done if dropped into the repo for the first time with no context. Which is: it solved the immediate problem with reasonable-looking code, using the patterns it had seen in its training data.

Our new hires did the same thing. I went back and checked. In the six months before that incident, we'd had three separate PRs from three different people — two human, one AI — all creating bespoke HTTP clients instead of using ServiceBus. All of them reviewed by people who knew better but missed it under time pressure.

The bug wasn't the model. The bug was that the knowledge of which patterns we'd consciously chosen to standardise lived nowhere an agent could read it, and only half-lived in the heads of senior engineers who weren't always in the review.

So we stopped chasing model quality and started building the thing that was actually missing: a context layer.

What "context layer" actually means

The phrase gets thrown around loosely since MCP took off, so let me be concrete.

In our stack, a context layer is:

A single, versioned source of truth for architectural decisions, design patterns, and merchant-domain invariants.
Structured as machine-readable documents (MDX with frontmatter, not free-form Confluence pages).
Served over MCP so the same corpus is queryable by every AI tool on the team — Claude, Cursor, Copilot, our internal agents.
Enforced by CI through design-pattern lints that fail the build when any PR — human-authored or AI-authored — violates a recorded pattern.

The enforcement layer is what most teams skip. The context on its own is a wiki nobody reads. The lints on their own are arbitrary rules nobody remembers the reason for. Pairing them is where the leverage lives.

The three files that made it work

Here's the minimum structure we settled on, with real examples from our monorepo.

1. `adr/*.mdx` — architectural decisions, machine-readable

---
id: ADR-0047
title: "Service-to-service communication goes through ServiceBus"
status: accepted
date: 2025-11-12
tags: [microservices, inter-service, nestjs]
supersedes: null
lint_rule: no-direct-http-client
---

## Context
15 NestJS microservices. Two years ago, every service had its own
Axios instance. Retry semantics drifted. Timeouts drifted. Tracing
headers got dropped. Incidents had no consistent trail.

## Decision
All service-to-service calls go through @atoa/service-bus, which
wraps Axios with retries, circuit breaking, OpenTelemetry tracing,
and our standard auth header injection.

## Rationale
- Retry policies live in one place, tied to SLOs.
- Every call is traced by default.
- Failures surface consistently in Grafana.

## Enforcement
eslint rule: no-direct-http-client (see lint-rules/)
CI gate: fail on import of 'axios' or 'node:http' in service code.

Every ADR has a lint_rule pointer. No ADR ships without one, unless explicitly marked advisory.

2. `lint-rules/no-direct-http-client.ts` — the actual enforcement

import { TSESTree, TSESLint } from '@typescript-eslint/utils';

const BANNED = ['axios', 'node:http', 'node:https', 'undici'];
const ALLOWED_PATHS = [
  'libs/service-bus/',
  'libs/http-primitives/',
];

export const rule: TSESLint.RuleModule<'useServiceBus', []> = {
  meta: {
    type: 'problem',
    messages: {
      useServiceBus:
        'Direct HTTP clients are banned. Use @atoa/service-bus. See ADR-0047.',
    },
    schema: [],
  },
  defaultOptions: [],
  create(ctx) {
    const filename = ctx.getFilename();
    if (ALLOWED_PATHS.some((p) => filename.includes(p))) return {};

    return {
      ImportDeclaration(node: TSESTree.ImportDeclaration) {
        if (BANNED.includes(node.source.value)) {
          ctx.report({ node, messageId: 'useServiceBus' });
        }
      },
    };
  },
};

Nothing clever. The point is: when an agent (or a human) ships the banned pattern, the PR cannot land. Not "a reviewer will notice." The build fails. Every time.

3. `context.mcp.json` — what we expose to every tool

{
  "name": "atoa-engineering-context",
  "version": "1.4.0",
  "resources": [
    { "uri": "adr://*", "description": "Architectural decisions with enforcement status" },
    { "uri": "pattern://*", "description": "Approved design patterns with code examples" },
    { "uri": "domain://merchant", "description": "Merchant domain invariants and flows" },
    { "uri": "domain://payments", "description": "Payment flow state machines" }
  ],
  "tools": [
    {
      "name": "check_pattern",
      "description": "Given a code snippet, return any ADR violations it would trigger"
    },
    {
      "name": "find_precedent",
      "description": "Search for prior implementations of a similar pattern in our codebase"
    }
  ]
}

Every AI tool our team uses mounts this MCP server. When an engineer asks Claude to "add a refund flow," the model has the ADRs in retrieval before it starts writing code. When it asks "how have we handled async retries in the past," find_precedent returns the real decorator, not something that looks plausible.

The agent stopped hallucinating patterns not because the model got smarter. Because we gave it somewhere to look.

What happened in the last 30 days

We've been running this layer across the full engineering team — 18 people, mix of AI-heavy and AI-light workflows — for just under a quarter now. Last month's numbers:

23 pattern violations caught by design-pattern lints before merge. 14 from human-authored PRs. 9 from AI-authored PRs. The ratio surprised me. I'd expected AI to dominate the violation list. It did not.
2 architectural regressions avoided that would previously have shipped. One was a would-be duplicate-refund bug in the same area as the Friday-night incident. The lint caught what the reviewer under time pressure would have missed.
Onboarding time for a new engineer down from 2 weeks to 4 days on the local-dev side, which is a separate story, but the context layer helped here too. New hires read the ADR corpus once, then let the MCP server answer their day-to-day "does this already exist?" questions.
Zero arguments in code review about "is this the right pattern." When a disagreement happens, the question becomes "is there an ADR for this?" If yes, the lint decides. If no, we write the ADR.

That last one is the quiet win. Code review time on architectural questions dropped by roughly a third, because we stopped relitigating decisions we'd already made.

The part most teams get wrong

Two patterns I see repeatedly on teams that try to build this and don't get the leverage:

1. Context without enforcement. A beautiful ADR wiki nobody reads. Every violation still ships because there's no gate. This is where most teams stop because the wiki felt like the real deliverable. It is not. The lint is the real deliverable.

2. Enforcement without context. A forest of lint rules nobody understands. The first time someone hits a red CI gate with a rule they've never seen, they open a Slack channel and ask why. If the lint points to an ADR with a clear rationale, the question answers itself. If it points to a rule that just says "forbidden," you've built a political problem disguised as infrastructure.

Pairing them is not optional. Either one alone is worse than nothing.

What this means for "model quality" debates in 2026

Every week there's a new "is Claude 4.6 better than Opus 4.5 at code" thread. I read them. I have opinions. But in terms of what actually moved the needle on our shipping velocity this quarter — it wasn't the model.

It was the retrieval surface.

The model doesn't need to be smarter. It needs to read the right thing before it answers. And once the context layer is good enough, the difference between "good model" and "great model" collapses, because both are now looking at the same authoritative source.

For 2026, if I had to pick one place to invest a quarter of engineering time to improve AI-native development, it wouldn't be better prompts. It wouldn't be a new IDE extension. It would be this:

Write down the patterns you've actually chosen. Make them machine-readable. Serve them over MCP. Enforce them in CI. Stop relying on tribal knowledge to survive code review.

The agent isn't the bottleneck. The knowledge surface is.

I'm Arun, CTO and co-founder at Atoa — we build open banking payments for the UK. We run 15 NestJS microservices in production and I write about the things we've learned the hard way. Find me on X @mickyarun if you want to argue about any of this.

What Developers Get Wrong About PSD2 and Payment Initiation

arun rajkumar — Wed, 22 Apr 2026 06:16:57 +0000

I've spent UK FinTech Week (April 20–24) reading developer threads about open banking. Same misconceptions every time.

PSD2 is "just OAuth for banks." Payment Initiation Services are "basically a bank transfer." The whole open banking stack is "Stripe with worse DX."

None of that is right. And the gap matters, because the developers carrying these assumptions are the ones building the next wave of UK checkouts. If you're shipping payments code in 2026, here's what I'd want you to know before you write the first line.

1. PSD2 is not OAuth

The flow looks like OAuth. It is not OAuth.

OAuth gives an app permission to read or write data on behalf of a user. PSD2's Payment Initiation Service (PIS) gives a regulated third party — the PISP — the legal right to instruct a payment from the user's bank account, with the bank legally obligated to execute it.

That is a fundamentally different contract.

The bank is not "letting your app do something." The bank is being compelled by regulation to act on a payment instruction from a licensed PISP, after Strong Customer Authentication (SCA) has been completed. The user authenticates inside their banking app — biometrics, PIN, or device binding — and the bank moves the money. No card network. No tokenisation. No 3DS dance.

If you treat PIS like OAuth, you'll over-engineer the consent layer and under-engineer the settlement layer. They're different problems.

2. "Just hit the bank API" is not a real architecture

I see a lot of "we'll integrate directly with each bank's API." Sure. There are 9 CMA9 banks in the UK alone. Add the building societies, the challenger banks, and the EU PSD2 obligations if you're cross-border.

Each bank exposes a slightly different flavour of the Open Banking Standard. Different consent expiry rules. Different ASPSP redirect quirks. Different webhook delivery patterns. Different rate limits.

We learned this the hard way running 15 microservices for UK payment flows. Bank-by-bank integration is not a feature. It is a maintenance liability that grows linearly with every new bank you add and exponentially with every spec revision the OBIE pushes.

The architectural choice is binary: become an FCA-authorised PISP yourself (months of compliance work, a regulated entity, ongoing capital requirements), or integrate against an aggregator who's already done it.

If you're not building a payments company, do not become a PISP. Use one.

3. SCA is not a checkbox

Strong Customer Authentication is the single biggest thing developers underestimate.

You don't add SCA to a payment flow. SCA is the payment flow.

Every payment initiation in the UK requires two of three factors: knowledge (PIN), possession (device), inherence (biometrics). The user has to authenticate inside their bank, on every payment, unless an exemption applies — and the exemption rules are tighter than most teams realise. Low-value contactless. Recurring TPP-managed VRPs. Trusted beneficiaries. That's mostly it.

If your UX assumes "save the bank, charge silently next time" the way Stripe lets you save a card — you're going to ship a flow the bank will block.

This is also why commercial Variable Recurring Payments (cVRP) is the most-watched topic at UK FinTech Week this week. UK Finance proposed the cVRP Wave 2 commercial model earlier this month. cVRP is the legitimate, regulator-blessed answer to "how do I take recurring open banking payments without making the user re-auth every time." It's coming. Build for it.

4. The webhook is the source of truth, not the redirect

This one breaks junior payments code more than anything else.

The user completes authentication in their bank. The bank redirects them back to your redirectUrl. Your app shows "Payment successful."

Wrong. The redirect is a UX hint. It is not a payment confirmation.

The actual payment status — COMPLETED, PENDING, FAILED, CANCELLED — comes from a server-to-server webhook the PISP fires once the bank has settled (or refused) the payment instruction. Sometimes that's instant. Sometimes there's a delay if the bank is doing fraud checks. Sometimes the user closes the browser before the redirect fires but the payment still completes.

If your fulfilment logic depends on the redirect, you will eventually ship orders for payments that never landed, or refuse orders for payments that actually did. We had to retrofit this in our merchant app early on. Webhook-first, redirect-second. Always.

5. Open banking is not "Stripe but cheaper"

I'll be opinionated here because I think the framing matters.

Stripe is a magnificent product. It abstracts card networks beautifully. It is also, structurally, a card-rails product paying Visa and Mastercard interchange on every transaction. That's why UK card processing costs sit at 1.5–2.9%. The interchange is a tax built into the rail.

Open banking is a different rail. There is no interchange. The money moves over Faster Payments (UK) or SEPA Instant (EU). The cost structure is fundamentally different — flat fee, not percentage. Atoa is roughly half the cost of cards because we're not paying Visa for the privilege of moving the money.

The right mental model is not "Stripe alternative." It is "second payment rail, with different economics, different latency, different UX, different fraud profile, different settlement guarantees."

For high-ticket B2B invoices, open banking is dramatically better. For impulse e-commerce, cards still win on conversion friction. For UK SaaS doing recurring billing, cVRP is about to flip the calculus. Pick the rail that fits the use case. Don't pick the rail that fits last year's mental model.

TL;DR for developers shipping in 2026

PSD2 is not OAuth. Don't integrate banks directly. SCA isn't optional. Webhooks are the source of truth. Open banking is its own rail, not a Stripe replacement.

If you're at UK FinTech Week this week and want to see this in code, the Atoa sandbox takes 5 minutes to set up. We've spent years getting the integration down to a single API call so you don't have to relearn what we already did wrong.

Try it: docs.atoa.me

What's the misconception about open banking you keep hearing from your engineering team?

Arun Rajkumar is Co-Founder & CTO of Atoa, an FCA-authorised UK open banking payments platform. He writes about CTO lessons, microservices, and what we're learning building a payments rail outside the card networks.

We Built an Open-Source Coding Exam Platform Because Every Vendor Let Us Down

arun rajkumar — Sat, 11 Apr 2026 01:05:35 +0000

Every year, our team visits engineering colleges across India to hire freshers. The first round is always an online coding test — 300+ students, one shot at finding the ones who can actually think.

We tried Coderbyte. Fifty concurrent user limit. So we'd split students into batches, stagger timings, juggle schedules between college coordinators and our engineers.

We tried HackerRank's community edition. Different tool, different headache.

Every vendor had a ceiling — concurrency limits, inflexible problem formats, generic DSA questions that tested memorization over problem-solving. And the pricing? Designed for companies ten times our size.

I was ranting about this to my engineering team. Out loud. In our standup. Trying to find yet another vendor to evaluate.

My engineers — most of them freshers themselves just a couple years ago — went quiet. Said nothing for a few days.

Then they shipped a product. Two engineers. One weekend. AI-assisted development. And two days of intensive testing before it went live.

What They Built

A full-stack, self-hosted coding exam platform. Not a toy. Not a prototype. A production system we ran 300+ students through this hiring season.

Here's what's under the hood:

Monaco Editor — the same engine that powers VS Code. Syntax highlighting, autocomplete, multi-language support. Students write real code, not paste answers into a textarea.

Judge0 Sandboxed Execution — every submission runs inside a sandboxed Judge0 instance. Test cases execute in parallel with automatic batching. Students get instant, per-test-case verdicts.

ICPC-Style Scoring — not just pass/fail. Penalty points for wrong attempts. Time-based ranking. Race-condition-safe writes to the database. The leaderboard feels like a competitive programming contest, not a homework checker.

Live Leaderboard — backed by a PostgreSQL materialized view that refreshes after every accepted submission. O(1) rank queries. Students watch themselves climb in real-time.

API-Based Challenges — beyond traditional stdin/stdout problems, we built support for API-format challenges where students interact with real endpoints. This lets us test how candidates think about integration, not just algorithms.

Server-Synced Timer — the countdown runs on server time, not the client clock. No inspect-element tricks. Configurable start/end windows with server-enforced access guards.

Autosave — code drafts are debounce-saved to the server every few seconds. Browser crash? Tab closed? The student picks up right where they left off.

White-Label Ready — app name, logo, brand colors, copyright — all configurable via environment variables. Zero code changes. We use it as our own branded platform; anyone can make it theirs.

Architecture at a Glance

The platform is a monorepo with two core applications:

client/   → Vue 3 SPA (student exam UI + admin panel)
server/   → NestJS REST API (auth, exam logic, code execution, scoring)

In production, the server compiles and serves the client's static build directly — no separate web server or CDN needed.

The submission flow works like this:

Student writes code in the Monaco editor and hits Submit
The Vue client POSTs to the API with the code and language
The SubmissionsService fetches all test cases and sends batch requests to Judge0, automatically chunking to stay within limits
The server polls Judge0 tokens until all results resolve
The ScoringService applies the ICPC penalty formula and updates the score using a pessimistic database lock
The LeaderboardService refreshes the materialized view
Results return to the client with per-test-case verdicts and an updated leaderboard

All of this happens in seconds, even under load.

The Tech Stack

Frontend: Vue 3 (Composition API), Vite 8, TypeScript 5.9, Pinia 3 for state, Monaco Editor 0.55, Brotli compression

Backend: NestJS 11, TypeScript 5.7, TypeORM 0.3, Passport JWT, Swagger/OpenAPI docs, rate limiting via @nestjs/throttler

Database: PostgreSQL 17 for the application, PostgreSQL 16 + Redis 7.2 for Judge0's internal queue

Infrastructure: Docker Compose orchestrates six services — app, app-db, judge0-server, judge0-worker, judge0-db, and judge0-redis. Multi-stage Dockerfile produces a minimal Node 22-alpine image running as a non-root user.

Features That Matter

Here's what we built because we needed it, not because a product manager spec'd it:

Multiple concurrent exams — run several exams at once; students pick which to enter
Mixed formats — MCQs alongside coding problems in the same exam
Admin panel — create exams, duplicate them, manage problems with visible/hidden test cases, configure weights
Safe Exam Browser detection — a composable detects whether students are in a locked-down browser
Built-in API docs — interactive API reference baked right into the student UI for API-format challenges
QA role opt-in — students can flag interest in QA engineering during registration
Run mode — execute code against sample inputs without scoring; lets students experiment before committing

Why Open Source?

We're a fintech startup. Thirty-odd people. We didn't build this to sell it.

We built it because we were tired of bending our hiring process around someone else's product limitations. And once we had it, we realized every small company visiting colleges faces the exact same problem.

Here's the thing that makes this story worth telling: two engineers built this in a weekend, with AI doing the heavy lifting on scaffolding, boilerplate, and iteration. Then two days of intensive testing to harden it for production. That's the power of AI-assisted development — it doesn't replace engineers, it turns two of them into ten.

In the AI era, expensive hiring software shouldn't be a gate that keeps small teams from finding great talent. If two engineers with AI tools can build a platform that handles 300+ concurrent students with ICPC scoring and sandboxed execution in a weekend, there's no reason that capability should be locked behind enterprise pricing.

The whole thing is AGPL-3.0 licensed. Fork it, brand it, run it on your own infrastructure — just keep your modifications open too.

Getting Started

The fastest path is Docker Compose:

cp .env.example .env
# Set DB_PASSWORD, JWT_SECRET, ADMIN_SETUP_KEY
docker compose up --build

Six services start in dependency order. The app waits for the database health check, runs migrations automatically, and you're live.

For local development without Docker, you'll need PostgreSQL 17 and a Judge0 instance. The README walks through every step — database creation, migrations, environment variables, and running the frontend and backend separately.

What's Next

We're cleaning up a few things before the public launch:

Finishing the test suite (Jest is installed and configured, specs are being added)
Polishing the contributor docs
Adding a demo mode so people can try it without setting up Judge0

If you're interested, follow me here — I'll drop the GitHub link as soon as the repo goes public.

The Bigger Lesson

I went looking for a vendor. My team handed me a product.

Two engineers. One weekend of building. Two days of intensive testing. Powered by AI-assisted development. A platform that replaced two commercial tools and produced measurably better candidate quality in round two.

That's what happens when you hire people for intent over resumes — and then get out of their way.

Built with Vue 3, NestJS, PostgreSQL, Judge0, and a healthy disregard for vendor lock-in.

Star the repo when it drops. Or better yet — fork it and run your own hiring season on it.

Open Banking Was Built for the Wrong Future — and That's Why It's Perfect for AI Agents

arun rajkumar — Tue, 07 Apr 2026 19:35:42 +0000

Visa announced infrastructure for AI agents to make payments without asking you first.

GoCardless shipped an MCP server in February so developers can talk to their payment platform in natural language.

I build open banking payment infrastructure for the UK. I've been watching both of these announcements very closely.

And I have a counterintuitive take: the payment rail everyone called "too complicated for normal users" might be the only one that actually works for AI agents.

The Problem With Cards and AI Agents

When an AI agent needs to make a payment on your behalf, the obvious infrastructure is what already exists. Cards. Stored credentials. The same rails your Netflix subscription uses.

Here's the problem.

Card authorisation is broad. When you give Stripe a card token, you're essentially giving that token permission to charge whatever you've authorised — subject to 3DS, fraud rules, and limits. But the authorisation scope isn't bound to a specific action.

For an AI agent, that's dangerous.

You want an agent to book a flight. It has your card token. Nothing technically stops it from booking the wrong flight, adding seat upgrades you didn't ask for, or — if the prompt is maliciously crafted — doing something you absolutely didn't intend.

Visa understands this. Their Trusted Agent Protocol exists precisely to solve it: a way for merchants to verify that an agent is legitimate and acting within its authorised scope. It's clever engineering. But it's being bolted onto rails that weren't designed for it.

Open banking wasn't designed for AI agents either. But its constraints happen to be exactly the right shape.

What Open Banking Consent Actually Looks Like

When a customer pays via open banking — the way Atoa processes payments — here's what actually happens under the hood:

1. Merchant creates a payment consent object
   → amount: £49.99
   → merchant: Atoa test merchant
   → purpose: "Coffee subscription - April"

2. Customer is redirected to their bank
   → Bank shows: "Atoa wants to take £49.99 from your account"
   → Customer approves or declines
   → Bank issues a single-use authorisation code

3. Atoa exchanges the code for the payment
   → One payment. Specific amount. Specific purpose.
   → The authorisation is consumed. It cannot be reused.

Every payment is its own consent event. Every consent is scoped to a specific amount and purpose. You can't overcharge. You can't quietly add extras. You can't reuse the authorisation.

For a human user, this is friction. That's why open banking adoption was slow. Nobody wants to log into their banking app every time they buy something.

For an AI agent, this friction is a feature.

Why the Consent Model Fits AI Agents

Think about what you actually want when an AI agent makes a payment on your behalf.

You want:

It to charge exactly the amount you authorised
The scope to be limited to what you asked it to do
The ability to revoke access without cancelling your card
A clear audit trail showing what was authorised and when
The payment to fail loudly if anything is out of scope — not silently proceed

Open banking gives you all of that by default.

Cards give you none of it by default, and you have to engineer it in.

The FCA even made it better recently. They removed the 90-day re-authentication requirement that was causing 20-40% customer drop-off for third-party payment providers. Persistent consent — once granted to an agent — can now remain valid without forcing a re-authentication loop.

That's a massive unlock for agentic payment flows.

The Real Engineering Challenge: Consent Lifecycle for Agents

Here's where it gets genuinely hard.

When a human completes an open banking payment, the flow is synchronous: they go to the bank, they approve, they come back. Done.

When an AI agent initiates a payment, the flow might look like this:

User: "Book the Bangalore to London flight if the price drops below £600"

Agent: [Monitors prices for 3 days]
Agent: [Price hits £598 on a Wednesday morning]
Agent: [Attempts to initiate payment]
         → But the user's open banking consent was granted for a specific session
         → That session token expired 6 hours ago
         → Payment fails

Result: Agent missed the window. User wakes up to a "couldn't book your flight" message.
        Price is now £640.

Consent that's synchronous and session-bound doesn't work for agents that act asynchronously.

This is the real engineering problem. Not "can AI agents make payments?" — they clearly can. But "what does the consent model look like for an agent that might act hours or days after the user gave permission?"

There are a few approaches:

Option 1: Pre-authorised payment mandates
Open banking supports Variable Recurring Payments (VRPs) — essentially mandates where the user sets a maximum amount and time window, and the payment provider can initiate within those bounds without re-authentication.

// Conceptual structure of a VRP mandate for an agent
interface AgentPaymentMandate {
  agentId: string;
  maxAmountPence: number;      // Agent cannot exceed this
  validUntil: Date;           // Time-bounded consent
  allowedMerchants: string[]; // Scope: only these merchants
  purpose: string;            // What this mandate is for
  requiresConfirmation: boolean; // Some actions still need approval
}

The agent operates within a pre-defined envelope. The user sets the boundaries once. The agent acts within them.

Option 2: Payment intent + human gate
Agent identifies a payment opportunity, creates a payment intent, notifies the user. User approves in one tap. Agent executes.

This is the pattern we're building toward at Atoa — merchant describes what they need in natural language, agent proposes the payment, human approves in one tap, open banking rails execute it.

// What an agent workflow might look like
const intent = await paymentAgent.proposePayment({
  merchant: 'flight-booking-service',
  amount: 59800, // £598.00 in pence
  reason: 'BLR→LHR flight, price hit target of £600',
  expiresAt: new Date(Date.now() + 30 * 60 * 1000), // 30 min window
});

// User gets notified: "Your agent wants to book your flight for £598. Approve?"
// One tap. Payment executes.

Option 3: Programmatic consent with audit trail
For fully autonomous agents — the Visa Intelligent Commerce model — the agent holds delegated credentials scoped to specific actions, with every payment logged against the authorisation that permitted it.

We're not here yet in open banking. But the architecture exists to get there.

What We're Thinking About at Atoa

We build open banking payment infrastructure. POS terminals, payment links, invoicing, online checkouts. Everything goes through bank payment rails.

We're thinking about this differently to most — our payment surfaces each have different agent-readiness, and that's shaped how we're approaching the consent problem. When Visa announced Intelligent Commerce, our first question wasn't "can we compete with this?" It was: "which of our surfaces are ready right now, and which ones need the architecture to change?"

Here's our honest assessment:

Pay by Link — probably the most agent-ready thing we have. An agent could generate a payment link, send it to a customer, and monitor completion. The consent event is triggered by the link recipient, not the agent. The agent just facilitates.

Payment Pages — also strong. A merchant's agent could build and publish a payment page with specific parameters. No card infrastructure needed.

POS Terminal — hardest. The consent flow requires physical presence for SCA. An agent isn't physically present. This one needs new thinking.

Invoicing — interesting. An agent managing a merchant's books could issue invoices and track payment status. The open banking payment confirmation is machine-readable. This is real today.

The shape of "agentic commerce" looks different for each surface. There's no one-size-fits-all answer.

The Question Every Open Banking Developer Should Be Asking

GoCardless shipping an MCP server tells you something important: payment infrastructure companies are now thinking about developers' AI workflows as a first-class use case.

Not just "can humans use our API?" but "can an AI agent use our API safely?"

That's a different design question. An API designed for humans assumes there's a human reading error messages, handling edge cases, making judgment calls. An API designed for agents needs those things to be machine-readable, scoped, and predictable.

Open banking has a head start here. The consent model is explicit. The amounts are bounded. The authorisation chain is auditable. Every payment has a "why" attached to it.

The engineers who figure out the consent lifecycle problem — how do you grant an agent payment permissions that are time-bounded, amount-bounded, and purpose-bounded, without requiring the human to be present at the moment of execution — will be building the infrastructure that the next decade of agentic commerce runs on.

That's the problem I'm thinking about.

What's your take — does the card world catch up to open banking here, or does the consent model give open banking a structural advantage in the agent era?

Arun Rajkumar is CTO & Co-Founder of Atoa, an FCA-authorised open banking payments platform in the UK. He writes about payments, fintech engineering, and building for the UK from India. @mickyarun