Field note

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.

May 26, 2026 · Navin Agrawal · Architecture · 3 min read

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

Visual brief

Visual brief

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

As of May 2026

I keep coming back to one thought experiment on the BRICS payments debate. If local-currency corridors become mainstream, how would cross-border payment architecture actually change? Not geopolitics, and not SWIFT is dead. The practical question is simpler.

When a US company pays a supplier in a BRICS country, does the payment still default to USD correspondent banking, or does the payment hub choose the corridor before release? That single decision, made before money moves, is where the architecture changes.

Today that supplier payment usually starts in ERP or treasury. The payment hub validates the instruction, treasury funds USD or books FX, SWIFTNet carries the bank message, and correspondent accounts and local clearing get the money to the supplier. That path does not vanish. What a mature local-currency corridor adds is a decision before release: should this payment use SWIFTNet and USD correspondent banking, CIPS and RMB settlement, SPFS messaging, a BRICS Pay bridge in the corridors where trials have started, or a PSP route? That is not a new button in the portal. It is middleware, policy, liquidity, and evidence.

BRICS does not need to kill SWIFT to change cross-border architecture (as of May 2026): a mature local-currency corridor adds a routing decision before release rather than a new button in the portal; the choice is between SWIFTNet and USD correspondent banking, CIPS and RMB settlement, Russia's SPFS messaging, a BRICS Pay bridge in the corridors where trials have started, or a PSP route; the work is corridor eligibility rules, ISO 20022 mapping across networks, FX source and quote age, and sanctions and capital-control evidence; and USD correspondent banking stays the fallback, with fewer payments routing to it when a local-currency corridor has better liquidity, legal coverage, and settlement reach.
The corridor decision sits before release. Everything downstream is orchestration, translation, evidence, and reconciliation.

What the corridor decision needs

The decision layer is not glamorous. It needs corridor eligibility rules, ISO 20022 mapping across networks that do not share a dialect, an FX source with a quote age you can defend, local-currency liquidity actually positioned where the payment lands, sanctions and capital-control evidence captured at decision time, message acknowledgment and status tracking, and one case ID that survives from initiation to settlement.

Where the systems actually stand

CIPS is live for RMB cross-border clearing and SPFS is Russia’s financial-messaging alternative to SWIFT, both real and in use. BRICS Pay, with its DCMS messaging layer, is still in trials rather than a production rail, so it is a design target, not a default. Blockchain may appear in CBDC or tokenized settlement corridors, but it is not the answer to most of this. The near-term work is payment orchestration, message translation, evidence, and reconciliation.

The new step

Route then release

a mature local-currency corridor adds a routing decision before release, not a new button in the portal.

The default

USD holds

USD correspondent banking stays the fallback - fewer payments route to it when a corridor has better reach.

The hard part

Evidence

explaining why this currency, this message network, this FX source, and this path before money left the bank.

BRICS does not need to kill SWIFT to matter. The shift is fewer payments defaulting to USD routing when a local-currency corridor has better liquidity, legal coverage, and settlement reach.

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.

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.

API governance is payment architecture, not a footnote

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.

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.