Field note

API governance is payment architecture, not a footnote

A duplicate API call looks harmless until two payments clear and operations is left explaining the gap. The same error behaves differently on every rail - ACH hides it until batch, RTP and FedNow clear it instantly and final, wire forces a manual recall. On a multi-rail platform, governance is the architecture.

Jan 5, 2026 · Navin Agrawal · Architecture · 3 min read

API governance is payment architecture, not a footnote

Visual brief

Visual brief

API governance is payment architecture, not a footnote

As of January 2026

A duplicate API call looks harmless until two payments clear and operations is left explaining the gap. On a multi-rail platform, the same error behaves differently on every rail - which is why API governance is payment architecture, not a security footnote.

ACH tolerates batch. RTP and FedNow do not. Wire is high value and low forgiveness. A gateway that treats all of them the same is a gateway that will let a duplicate through on the one rail that cannot take it back.

How the same mistake plays out tells you why the gateway matters. On ACH, a duplicate hides until batch reconciliation and returns later in the cycle. On RTP, it clears instantly and is final, so recovery means return requests and counterparty coordination. On FedNow, it posts immediately and forces a return workflow while treasury adjusts intraday buffers. On wire, it triggers manual recalls and cutoffs that can turn a single slip into a full day of escalation. One duplicate, four different incidents.

API governance is payment architecture, not a footnote (as of January 2026): on ACH a duplicate stays hidden until batch reconciliation and returns later in the cycle; on RTP and FedNow it clears instantly and final, so recovery depends on return requests and counterparty coordination; on wire a duplicate triggers manual recalls and cutoffs that can turn a slip into a full day of escalation; and the way to govern it is idempotency keys, signed short-lived requests, rail-scoped tokens, rate limits with burst budgets, and versioning with deprecation windows.
The same duplicate is four different incidents across rails. The gateway has to know which rail it is talking to.

ACH

Batch-hidden

a duplicate stays hidden until batch reconciliation, then returns later in the cycle.

RTP / FedNow

Instant, final

clears immediately and is final, so recovery depends on return requests and counterparty coordination.

Wire

Manual recall

a duplicate triggers manual recalls and cutoffs, turning a slip into a full day of escalation.

The fragile space

A multi-rail platform lives where the rails disagree. ACH forgives a batch delay. RTP and FedNow do not. Wire punishes the smallest slip. One gateway has to respect all three.

Five rules to anchor on

Put idempotency keys at both the gateway and the ledger so one request means exactly one payment. Sign requests with a nonce and a short expiry to kill replays. Scope tokens by rail and function, never shared across rails. Set rate limits with burst budgets per client and per rail. Version with deprecation windows and schema tests so a contract change does not become an outage. None of these is exotic. Skipping any of them is how a duplicate becomes a cleared payment on the rail that cannot take it back.

Was this useful?

Choose once.

Filed under

Architecture
Share
Back to Field Notes

Related Posts

View All Posts »
A multi-rail exception mesh, not best-effort dedupe

A multi-rail exception mesh, not best-effort dedupe

A duplicate payment in production is not an edge case. It is the control plane showing you what you never modeled. A retried request can land as a final success on one rail and a settlement reject on another, look clean on the dashboard, and still move two accounts twice. Best-effort dedupe is not a control.

BRICS does not need to kill SWIFT to change cross-border architecture

BRICS does not need to kill SWIFT to change cross-border architecture

The interesting BRICS payments question is not geopolitics. It is architecture: when a US company pays a supplier in a BRICS country, does the payment still default to USD correspondent banking, or does the hub choose the corridor before release? A mature local-currency corridor adds a routing decision, and that decision is middleware, policy, liquidity, and evidence rather than a new button in the portal.

A name check just became a priced control

A name check just became a priced control

The Fed's 2026 pricing notice introduces Payee Name Verification at two cents a transaction, starting on FedACH. It works by comparing a submitted payee name against names previously seen on that account. From an architect's view that is not a yes-or-no check - it is a new control point that reshapes routing, exceptions, and reconciliation.

Payroll virtual accounts break on the real-world edge cases

Payroll virtual accounts break on the real-world edge cases

A clean virtual-account hierarchy looks simple until an HCM client asks you to reverse payroll for 200 employees across three states from three weeks ago. Multi-entity payroll is where account architecture meets 50 sets of wage law - and where instant rails do not yet fit.