Cross-Border 2026: ISO 20022, Open Finance and Tokenised Deposits in Corporate Treasury

TL;DR. How ISO 20022, A2A, open finance under PSD3/FiDA, and tokenised deposits are reshaping cross-border corporate treasury alongside SWIFT in 2026.

Key takeaways

01. From cards to A2A — the open finance shift. The card rails are not going away.
02. ISO 20022 as the lingua franca across rails. The reason multi-rail is workable at all is that the message format is now consistent across rails.
03. Tokenised deposits and stable rails. The wholesale settlement leg is where the rail story gets interesting.
04. The autonomous treasury stack. Above the rail layer sits the orchestration layer.

Executive Summary. Cross-border corporate treasury in 2026 is a multi-rail engineering problem before it is a relationship-management problem. PSD3 and the Financial Data Access (FiDA) regulation widen the open-banking perimeter into corporate treasury data; the November 2026 SWIFT MT/MX cut-over makes CBPR+-compliant pacs.008 the only viable cross-border interbank format; tokenised deposits and regulated stablecoin rails handle the wholesale settlement leg in near T+0 inside permissioned networks. The CIB that wins in this cycle is not the one that picks a single rail; it is the one that engineers the orchestration layer that binds them. This article walks the four-rail architecture (A2A under PSD3, SWIFT CBPR+, bank-issued tokenised deposits, regulated stablecoins) — what each rail does well, where the credit-exposure boundaries fall, and what the policy-as-code orchestration layer above them must enforce so the corporate sees one payment and the supervisor sees one auditable trail.

A European industrial corporate pays a Brazilian supplier EUR 4.2 million on a Wednesday morning. The treasury workstation does not pick a bank. It picks a rail — a sequence of rails. The customer-facing instruction lands on an A2A pain.001 message routed through an open finance provider under PSD3. The bank legs it across two correspondent jurisdictions on tokenised deposits inside a CIB private network. The long tail — a USD 80,000 invoice clean-up to a sub-supplier without a tokenised-deposit relationship — still rides SWIFT CBPR+ as a pacs.008. The customer sees one payment. The architecture sees four rails. ISO 20022 is the only reason it holds together.

This is the operating model Mastercard describes when it talks about the evolution from open banking to open finance — data and payments fused into one orchestration layer, with the rail chosen by the system, not the customer. The interesting question for senior banking technologists is not which rail wins. It is how the orchestration layer is engineered, governed, and reconciled.

01. From cards to A2A — the open finance shift #

The card rails are not going away. They are being reframed.

Through 2025 and into 2026, PSD3 and the Financial Data Access (FiDA) regulation extended the open-banking obligation beyond payment accounts into pensions, mortgages, savings, insurance and corporate treasury data. The corporate treasury implication is direct: a CIB relationship manager can now consume a corporate's full liquidity picture across multiple banks through one API contract, on the corporate's instruction.

Two operators are visibly building the orchestration layer corporates will consume. Nexi has extended its acquiring footprint into A2A initiation across SEPA Instant and pan-European RTGS corridors, ISO 20022 native end-to-end. Mastercard's open finance platform — anchored on its acquisition of Aiia and Finicity — provides the data-aggregation and consent layer underneath, with payment initiation surfacing through the same API estate that previously served card authorisations.

The shift matters for three reasons:

Unit economics. A2A initiated under PSD3 strips interchange out of the payment. For high-ticket B2B flows, the saving is material; for low-ticket consumer flows, the merchant cost stack collapses.
Data quality. A2A under ISO 20022 carries structured remittance data that cards never could. Auto-reconciliation rates above 95% are now table-stakes.
Risk model. A2A is a credit transfer, not a card authorisation. The fraud surface, chargeback model, and dispute model are all different. Corporate treasury teams need to understand the customer protection layer is being rebuilt, not inherited.

The CIB selling a multi-rail proposition in 2026 is selling orchestration — not access. Access is now regulated.

02. ISO 20022 as the lingua franca across rails #

The reason multi-rail is workable at all is that the message format is now consistent across rails.

The BIS Committee on Payments and Market Infrastructures (CPMI) made the architectural case clear in its ISO 20022 harmonisation requirements for enhancing cross-border payments. The November 2025 cut-over to CBPR+ closed the MT103 / MT202 era for cross-border interbank messaging. From that point, every major rail — SWIFT, FedNow, SEPA Instant, RTP, and the major instant payment systems in Asia and Latin America — speaks the same pacs.008 / pacs.009 / pain.001 grammar.

The practical consequence for corporate treasury:

Routing is data-driven. The treasury workstation can read a pain.001 once and decide the rail per payment based on corridor, ticket size, cut-off, and counterparty relationship — without re-mapping the message.
Remittance data survives the hop. Structured remittance fields (<RmtInf><Strd>) carry through correspondent legs without truncation. Auto-reconciliation rates climb because the data is no longer lost at the rail boundary.
Sanctions screening becomes auditable. Structured <Dbtr> / <Cdtr> / <DbtrAgt> / <CdtrAgt> fields with LEI references replace free-text name screening. Hit rates fall. Investigation queues shrink.

The diagram below traces a single pain.001 through the bank's ingress, into the policy-as-code orchestrator, and out to whichever rail the corridor and ticket size demand — one message, many rails, no re-mapping.

flowchart LR
    Corp[Corporate ERP] -->|pain.001 ISO 20022| Ingress[Bank Ingress<br/>schema-validate]
    Ingress --> Router{Orchestrator<br/>policy-as-code}
    Router -->|high-value cross-border| Swift[SWIFT CBPR+<br/>pacs.008]
    Router -->|domestic instant| A2A[A2A / Open Finance<br/>PSD3 / FedNow / SEPA Inst]
    Router -->|in-network corridor| Token[Tokenised Deposit<br/>permissioned ledger]
    Swift --> Settle[Settlement<br/>pacs.002 status]
    A2A --> Settle
    Token --> Settle
    Settle --> Recon[Auto-reconciliation<br/>structured RmtInf]

The cost of this consistency is engineering discipline. ISO 20022 is permissive. Two banks can be fully CBPR+ compliant and still produce pacs.008 messages that differ in field usage, character set, and remittance-data structure. The CIB that wins on cross-border in 2026 enforces a stricter message profile than the standard requires — and rejects on parse, not on settlement.

03. Tokenised deposits and stable rails #

The wholesale settlement leg is where the rail story gets interesting.

The 2026 picture, captured well in the Trade Treasury Payments analysis of automation, contingency rails, ISO 20022 and stablecoins, splits the wholesale settlement layer into two structurally different models.

Bank-issued tokenised deposits. A commercial bank issues a tokenised liability on a permissioned ledger — JPM Coin, HSBC's Orion-linked deposit token, the major European CIB equivalents. The token is a direct claim on the issuing bank. Settlement is near T+0 inside the network. Compliance is the issuing bank's responsibility. The rail is fully regulated, fully traceable, and constrained to participants the issuer has on-boarded.

Integrated stablecoin rails. A regulated stablecoin — fully reserved, audited, and operating under MiCA or the equivalent regional regime — settles a corridor where bank-issued tokenised deposits do not yet reach. The token is a claim on the reserve, not on a bank balance sheet. Compliance is shared between the issuer, the on-ramp, and the off-ramp.

The two models are not competing. They are stacked. A CIB cross-border product in 2026 typically uses bank-issued tokenised deposits for the in-network leg and a regulated stablecoin for the corridor where the in-network rail terminates. The corporate sees one ISO 20022 payment. The settlement story underneath is multi-token.

The board-level question is the same one operational-risk committees have been asking since the first programmable-liquidity pilots: who carries the credit exposure on the token, and for how long? Tokenised deposits give a clean answer — the issuing bank, until burn. Integrated stablecoin rails give a more nuanced one — the reserve, subject to the audit cycle and redemption guarantee. A treasury team that does not document the answer per rail per corridor is carrying unmeasured credit risk on its balance sheet.

04. The autonomous treasury stack #

Above the rail layer sits the orchestration layer. Above the orchestration layer sits the agent layer.

I have set out the architecture in detail in The Autonomous Treasury Index 2026: Programmable Liquidity and Tokenised Deposits. The short version: agentic treasury in 2026 is the orchestration layer, expressed as policy-as-code, with bounded agents executing within it.

The stack is:

Rail layer. SWIFT CBPR+, instant A2A, tokenised deposits, regulated stablecoins. Each rail has a published profile, cut-off table, cost curve, and settlement-finality model.
Orchestration layer. ISO 20022 in, ISO 20022 out. Rail decision per payment based on corridor, ticket, cut-off, counterparty relationship, and policy. Policy is versioned, signed, and auditable.
Agent layer. Bounded treasury agents execute the orchestration policy with tool-call boundaries, audit logs, and kill switches. The agent does not pick the rail. The policy picks the rail. The agent runs the policy.
Reconciliation layer. ISO 20022 pacs.008 / pacs.002 / camt.054 messages reconcile against the original pain.001 instruction, with structured remittance data closing the loop without manual intervention.

The CIB selling this stack in 2026 is selling four things at once — and pricing them separately. The corporate buying it is buying optionality across rails, with one message standard, one policy layer, one reconciliation feed. That is the architectural shift. Everything else is implementation detail.

FAQ #

Is "open finance" just rebranded open banking? No. Open banking under PSD2 covered payment accounts. PSD3 and the Financial Data Access (FiDA) regulation extend the data-sharing obligation into pensions, mortgages, savings, insurance, and corporate treasury data. The corporate-treasury implication is direct: a CIB relationship manager can now consume a corporate's full liquidity picture across multiple banks through one API contract, on the corporate's instruction, not just its payment-account history.

Why is the orchestration layer the architectural focus, not the rail? Because rails are now commoditising. SWIFT CBPR+ pacs.008, A2A under PSD3, tokenised deposits, and regulated stablecoins all carry the same ISO 20022 grammar at the message level. What differentiates a 2026 CIB is the policy-as-code engine that selects the rail per payment based on corridor, ticket size, settlement-finality requirement, and counterparty relationship — and that records the choice in audit telemetry the supervisor will ask for. Without that engine, multi-rail is just optionality with no governance.

Where does the credit-exposure boundary fall on a tokenised-deposit leg? Bank-issued tokenised deposits on a permissioned ledger are a direct claim on the issuing bank — credit exposure ends at burn. Regulated stablecoin rails (MiCA-supervised in the EU, the Bank of England's discussion-paper regime in the UK, analogues elsewhere) are a claim on the reserve, with the exposure window subject to the audit cycle and the redemption-guarantee terms. A treasury team that does not document the answer per rail per corridor is carrying unmeasured credit risk on its balance sheet.

What happens to SWIFT in this architecture? SWIFT does not disappear — it anchors the long tail. Corridors where bank-issued tokenised deposits do not yet reach (most emerging-market sub-supplier relationships, most low-frequency / low-ticket cross-border flow), and corridors where the corporate or the bank requires the CBPR+ correspondent-banking audit trail, continue on SWIFT pacs.008. The 2026 architecture is "SWIFT + new rails", not "new rails instead of SWIFT".

What does the corporate buy when it buys this stack? Optionality across rails, with one message standard (ISO 20022), one policy layer (the orchestration engine), and one reconciliation feed (pacs.002 status + camt.054 confirmation + structured camt.053 statements). The corporate is not paying for four separate rail connections. It is paying for the orchestration layer that makes four rails behave as one operationally — and the audit trail that lets it answer "which rail did that EUR 4.2 m payment ride, and why?" the morning after the next supervisory request.

Conclusion #

Cross-border corporate treasury in 2026 is a multi-rail engineering problem. ISO 20022 is the grammar that makes multi-rail tractable. PSD3 and FiDA widen the data perimeter and force open finance into the corporate treasury workflow. Tokenised deposits and regulated stablecoins handle the wholesale settlement leg. SWIFT still anchors the long tail.

The CIB that wins is the one that builds the orchestration layer — not the one that picks a single rail and bets the franchise on it. The corporate treasury team that wins is the one that documents the credit exposure per rail per corridor, enforces a stricter ISO 20022 profile than the regulator requires, and treats the rail decision as policy, not as a per-payment judgment call.

The interesting work is in the orchestration layer. Build it carefully.

References #

Bank for International Settlements, Committee on Payments and Market Infrastructures (2023). Harmonised ISO 20022 data requirements for enhancing cross-border payments (CPMI Papers No. 230). Available at: https://www.bis.org/cpmi/publ/d230.htm

Bank for International Settlements (2024). Project Agorá: cross-border payments with tokenised commercial bank deposits and central bank money. BIS Innovation Hub. Available at: https://www.bis.org/about/bisih/topics/fmis/agora.htm

Bank of England (2023). Regulatory regime for systemic payment systems using stablecoins and related service providers — Discussion Paper. Available at: https://www.bankofengland.co.uk/paper/2023/dp/regulatory-regime-for-systemic-payment-systems-using-stablecoins-and-related-service-providers

European Commission (2023). Proposal for a Directive on payment services and electronic money services (PSD3). Available at: https://finance.ec.europa.eu/regulation-and-supervision/financial-services-legislation/implementing-and-delegated-acts/payment-services-directive_en

European Parliament and Council (2023). Regulation (EU) 2023/1114 on markets in crypto-assets (MiCA). Available at: https://eur-lex.europa.eu/eli/reg/2023/1114/oj

Financial Action Task Force (2023). International standards on combating money laundering and the financing of terrorism — Recommendation 16 on wire transfers. Available at: https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Fatf-recommendations.html

International Organization for Standardization (2020). ISO 17442 Financial services — Legal entity identifier (LEI). Available at: https://www.gleif.org/en/about-lei/iso-17442-the-lei-code-structure

SWIFT (2024). Cross-Border Payments and Reporting Plus (CBPR+) usage guidelines. Available at: https://www.swift.com/standards/iso-20022/iso-20022-programme

Last reviewed 2026-06-24.

Republish this article

Cross-Border 2026: ISO 20022, Open Finance and Tokenised Deposits in Corporate Treasury

How ISO 20022, A2A, open finance under PSD3/FiDA, and tokenised deposits are reshaping cross-border corporate treasury alongside SWIFT in 2026.

This article is licensed under Creative Commons Attribution 4.0 International. Republication requires attribution to the canonical URL.

Cross-Border 2026: ISO 20022, Open Finance and Tokenised Deposits in Corporate Treasury

How ISO 20022, A2A, open finance under PSD3/FiDA, and tokenised deposits are reshaping cross-border corporate treasury alongside SWIFT in 2026.

Originally published at https://sebastienrousseau.com/2026-06-24-cross-border-iso-20022-open-finance-tokenised-deposits-treasury-2026/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER

Cross-Border 2026: ISO 20022, Open Finance and Tokenised Deposits in Corporate Treasury

01. From cards to A2A — the open finance shift #

02. ISO 20022 as the lingua franca across rails #

03. Tokenised deposits and stable rails #

04. The autonomous treasury stack #

FAQ #

Conclusion #

References #

Format for Medium

Format for Mastodon

Copy formatted for LinkedIn

BibTeX

RIS

Vancouver

Chicago

APA

Republish this article