What agentic delivery changes in fintech and payments

Most writing about agentic development quietly assumes a forgiving domain. A change goes out, something is wrong, you notice, you roll back, and the cost is an apologetic message in a channel. That assumption is doing an enormous amount of work, and in payments it does not hold.

A payment is an instruction to move somebody else’s money. Once it settles, there is no revert. You can issue a compensating transaction, which is a different event with its own record, its own fees, and its own customer-visible consequences. The distinction between undo and compensate is the single most important thing to hold onto when deciding how much of this to adopt and where.

What actually changes

Three things shift in a way that is specific to this domain rather than general.

The blast radius is denominated in currency. Elsewhere a bad change costs availability or reputation. Here it can cost a determinate sum of somebody’s money, and the sum is usually knowable in advance. That is unusually good news for risk assessment: you can often say what the worst case costs, which makes the autonomy conversation quantitative rather than a matter of temperament.

Reconciliation is the real test suite. Payments teams already run a mechanism that compares what your system believes against what the processor, the scheme, or the bank believes. That mechanism is a correctness oracle that most industries do not have, and it is criminally underused as a verification surface. If your ledger and the processor’s disagree, something is wrong, and no amount of passing unit tests changes that.

Speed of production stops mattering earlier than usual. In most domains, faster code generation moves the constraint to review. Here it frequently moves the constraint to a scheme certification window, a bank’s release calendar, or a change advisory board that meets on Tuesdays. Doubling generation throughput against a monthly certification cycle achieves very little, and teams discover this after the pilot rather than before.

Idempotency is the property to encode first

If you write one machine-checkable criterion into your definition of done this quarter, make it this one: every operation that moves money is idempotent under retry, and the idempotency key is derived from the request rather than generated by the caller.

The reason is specific to how generated code fails. An agent producing a payment endpoint will produce something that works. It will handle the happy path, return sensible errors, and pass its tests. What it will not reliably produce, unprompted, is correct behaviour when the same request arrives twice because a mobile client retried on a flaky connection. That is not a bug an agent is uniquely prone to; it is a bug everyone is prone to, and the difference is volume. Thirty payment-adjacent changes a week, each with a small chance of getting retry semantics subtly wrong, is a different risk profile from four.

Weak:   "The refund endpoint works correctly."
Better: Given a settled charge, when a refund is requested twice
with the same idempotency key, then exactly one refund
exists and both responses carry the same refund id.
And: a retry after a timeout returns the original result
rather than creating a second refund.
And: a different key against the same charge is rejected
if the total would exceed the original amount.

Use reconciliation as the verification surface

The most valuable thing a payments team can do with an agentic pipeline is not to generate more code. It is to close the loop between a change and the reconciliation result that would reveal the change was wrong.

Most teams already have the pieces. There is a daily or intraday process that compares internal records against an external source of truth and produces a break report. Somebody reads it. If the number of breaks is normal, they move on.

The connection that is usually missing is the one back to changes. When break volume moves, which changes shipped into that window, against which criteria, touching which paths? That is a join between your reconciliation output and your delivery record, and it is the single highest-value piece of instrumentation available in this domain, because it turns a financial control into a correctness signal with a feedback loop attached.

What PCI DSS actually asks of you

I want to be careful here, because this is where vendor writing usually overclaims. No tool makes an organisation compliant with anything. Compliance is the outcome of a programme, and it is assessed against your environment by somebody qualified to assess it.

What is fair to say is that the card data security standard asks a set of questions about change control that an agentic pipeline has to be able to answer, and that the answers get harder when the volume of changes rises and the author is not a person.

The questions are the ordinary ones: was the change authorised, was it reviewed by somebody other than the author, was it tested before production, can it be rolled back, and is there a record. A pipeline that can produce, for any change touching the cardholder data environment, the ticket that authorised it, the criteria it was built against, the evidence those criteria were evaluated, and the identity of an independent approver, is in a substantially better position than one relying on a naming convention and someone’s memory.

The segregation question is the one that gets genuinely harder, and it deserves an honest answer rather than a reassuring one. If an engineer writes the prompt and then approves the result, that is self-approval with an intermediary, whatever the identity in the commit says. In a cardholder data environment I would not try to argue otherwise. A second human on anything touching that scope is the defensible position, and the throughput gain has to come from everywhere else.

The scope boundary is the design decision

The most useful architectural move in this domain predates agents and is now worth considerably more: keep the cardholder data environment small, and keep agents outside it.

If tokenisation means your application handles tokens rather than card numbers, then the overwhelming majority of your codebase is not in scope, and the overwhelming majority of your agentic throughput is uncontroversial. The scope boundary becomes the autonomy boundary, and it is a boundary your auditors already understand and have already assessed.

Teams that have not done this work end up debating agent policy across an entire monolith, which is a much harder conversation with a much worse outcome.

Where this breaks down

Compensating transactions are not rollbacks and treating them as such is how you get a second incident. A revert restores code. It does not unsend a payout, unfire a webhook to a merchant, or unemail a customer about a refund that will not arrive. Any autonomy argument that leans on reversibility has to be explicit about which layer is reversible.

Reconciliation as a correctness oracle has latency. A break report that arrives the next morning is a slow feedback loop, and thirty changes will have merged in the meantime. It narrows the search rather than preventing the fault, and teams that expect prevention will be disappointed.

The certification calendar is not negotiable by engineering. If your release cadence is set by a scheme, a partner bank, or a regulator’s window, then delivery throughput improvements land in a queue. This is worth measuring before a pilot, because it determines whether the pilot can show anything at all.

Money-movement code is often the oldest code you have. The batch settlement core, the file format nobody has changed since 2011, the reconciliation job with a comment explaining a workaround for a system that no longer exists. Agents perform worst exactly where documentation and tests are thinnest, which in this domain is exactly where the risk is highest. That is an argument for raising the criteria bar in that path, not for avoiding it, but it does mean the easy wins are elsewhere.

And a fraud model is not a code change. A meaningful share of what a payments organisation ships is model behaviour rather than deterministic logic, and none of the criteria machinery in this series evaluates whether a scoring change is correct. That needs its own evaluation discipline and this is not it.

The takeaway

Payments is not a domain where you go slowly because it is scary. It is a domain where the reversibility assumption behind most agentic advice is false, and where you get an unusually good correctness oracle for free in exchange.

Start outside the scope boundary, where most of the work is and most of the throughput is uncontroversial. Encode idempotency as a machine-checkable criterion on every money-moving path. Join your reconciliation breaks back to the changes that entered the window, because that loop is the highest-value instrumentation available to you. Keep a second human on anything inside cardholder data scope and stop arguing about it.

If you take one thing into next week: work out what fraction of your codebase is actually in scope. In most payments organisations the honest answer is smaller than the policy behaves as though it is, and shrinking the gap is worth more than any tooling decision.