ISO 20022 and Tokenized Settlement

ISO 20022 and tokenised settlement are often discussed separately, because they sit in different parts of the payment stack. ISO 20022 is a messaging and data standard for financial communication. Tokenised settlement is an architectural shift in how value moves on the ledger. The two are more tightly linked than the separate conversations suggest: ISO 20022's rich, structured data model provides the vocabulary on which tokenised settlement can express compliance, identity, purpose and reconciliation data natively, and tokenised settlement is the environment in which ISO 20022's expressiveness finally pays off. This article examines the relationship and sets out what it means for firms building modern settlement infrastructure.

ISO 20022 replaced the SWIFT MT message family as the dominant messaging standard for cross-border payments and high-value settlement. Most major real-time gross settlement systems completed their ISO 20022 migration by November 2025, including TARGET2, CHAPS and the cross-border MT migration on the SWIFT network. The migration was not a cosmetic upgrade. It moved payment messaging from a compressed, positional format designed for low-bandwidth telex-era networks to a richly structured XML-based format designed for modern, data-driven financial operations.

The difference matters in three concrete ways. Payment messages now carry structured identifiers for the originator, the ultimate debtor, the beneficiary, the ultimate creditor and every intermediary in the chain. They carry structured remittance information, purpose codes, regulatory reporting fields and category purpose codes. They support linked sets of related messages — the initiation, the settlement and the return — in a way that legacy MT messaging approximated but did not make native. And they permit extensions for new asset classes, new participant types and new regulatory regimes without breaking the base schema.

For operators accustomed to decoding free-text fields and heuristically matching beneficiary names across correspondents, the change is transformative. Reconciliation becomes deterministic rather than probabilistic. Compliance controls operate on structured fields rather than on parsed free text. Reporting derives from the message itself rather than from an assembled view reconstructed from partial data. Our more detailed introduction to the standard, ISO 20022: what banks need to know, goes into the specifics.

The headline story is substantially complete. Cross-border SWIFT messaging transitioned from MT to ISO 20022 during the migration window that closed in November 2025. TARGET2 migrated in 2022 with subsequent consolidation. CHAPS migrated. Fedwire migrated. Most national RTGS systems are now on ISO 20022 or have firm dates for completion. Domestic instant payment schemes — including newer schemes built from inception on ISO 20022, such as Raast in Pakistan — have been ISO 20022-native from the outset.

What is still outstanding is the depth of usage. Many institutions have completed the technical migration — they can send and receive ISO 20022 messages — without fully exploiting the data that the messages can carry. Free-text remittance information, unstructured beneficiary detail and minimal use of structured purpose codes are still common. The next several years of the standard's evolution will be about moving from migration to richness, and firms that build natively on structured data acquire a competitive advantage over those that treat ISO 20022 as a message-format upgrade to their existing workflows.

Interoperability with legacy formats remains a practical concern. A payment chain that crosses from an ISO 20022-native leg into a legacy leg at any point degrades data to the lowest common denominator. Bridge infrastructure is built on the assumption that richness will be asymmetric across corridors for the foreseeable future, and that compliance and reconciliation logic must handle both richly-populated and sparsely-populated messages without losing its audit trail.

Tokenised settlement moves value on a shared ledger rather than through a chain of bilateral book entries. The ledger records the state change — a decrease in one participant's tokenised balance, an increase in another's — together with metadata that describes the transaction. The quality of that metadata determines what the settlement layer can do.

ISO 20022 provides the vocabulary. A tokenised payment transaction that carries ISO 20022-structured originator, beneficiary, remittance, purpose, tax and regulatory data inherits the same compliance and reconciliation affordances as an ISO 20022 RTGS message, but with the added property that the data lives on the ledger rather than in a separate messaging layer. Supervisors and counterparties can operate on the same data model across legacy messaging and tokenised settlement, which reduces the integration cost for every participant in the ecosystem.

The enabling relationship runs in both directions. ISO 20022's richness pays off most strongly in settings where the messaging and the settlement are tightly linked — where compliance checks, reconciliation and reporting all operate on the same canonical record. Legacy settlement environments, where a SWIFT message and a central-bank book entry are separate events connected by process, do not fully exploit the richness. Tokenised settlement environments, where the transaction and the data are a single record on a shared ledger, do. The same structural case is made in our pillar on RTGS on DLT.

Specific ways ISO 20022 enables tokenised settlement include: first, structured identity fields that support Travel Rule-compliant data transmission for VASP-to-VASP transfers without separate off-chain protocols; second, structured purpose codes that let smart contracts or settlement rules route transactions based on declared purpose; third, regulatory reporting fields that make end-of-period submissions a derived view rather than a reconstructed one; and fourth, extensibility that lets new asset classes — tokenised deposits, tokenised securities, regulated stablecoins — carry asset-specific metadata without forking the schema.

The compliance layer benefits most visibly. An ISO 20022 tokenised transaction carries the fields needed for sanctions screening, KYC assertion checks, Travel Rule transmission and AML monitoring in structured form, which lets controls operate on the transaction at the point of settlement rather than after the fact. Bridge's identity platform, its Travel Rule service and its KYC-as-a-service are designed around this principle: the settlement flow and the compliance flow share the same structured data model end-to-end.

Some tokenisation stacks, particularly those grown from public-chain conventions, do not use ISO 20022 natively. Transactions on these stacks carry asset transfer data and minimal metadata, with additional context supplied by off-chain identity protocols, bespoke memo conventions or application-layer workflows. This is workable for use cases that do not require deep compliance and regulatory interoperability, but it imposes friction when tokenised infrastructure interacts with the regulated payment system.

The friction shows up in three places. Compliance controls have to reconstruct structured data from unstructured or partial inputs, which increases cost and reduces reliability. Interoperability with legacy systems requires translation layers that lose data in one direction or the other. Reporting to regulators requires separate processes that run parallel to the settlement flow, which adds operational cost and increases the risk of divergence between the settlement record and the reported view.

For tokenised infrastructure that serves regulated financial use cases — institutional settlement, cross-border corridors, central-bank and commercial-bank money, tokenised securities — ISO 20022 is the pragmatic default. The alternative is to replicate the same expressiveness in a bespoke format, which is both expensive and unnecessary when the standard exists. For tokenised infrastructure that serves narrower use cases — on-chain gaming, retail token transfers that do not touch the regulated rails — the trade-offs differ, but those use cases are not the focus of this article.

Bridge's settlement infrastructure uses ISO 20022 as the canonical data model for payment transactions end-to-end. On the messaging side, the infrastructure emits and consumes ISO 20022 pain, pacs and camt messages for integration with RTGS systems, correspondent banks and scheme operators. On the tokenised side, the ledger records transactions with ISO 20022-aligned fields for originator, beneficiary, remittance information, purpose and regulatory data, with extensions for tokenised asset identifiers, compliance assertions and settlement metadata specific to DLT-based flows.

The practical consequence for a firm integrating with Bridge is that a single data model supports both the legacy and the tokenised legs of any flow. A cross-border corridor that uses a stablecoin leg in the middle, a legacy correspondent leg on one side and a Raast payout on the other — each ISO 20022-native in its own way — operates from a single end-to-end transaction record rather than a chain of reconciled fragments. This is what makes the combination of ISO 20022 and tokenised settlement more than the sum of its parts.

Raast, Pakistan's instant payment scheme, is a useful illustration. The scheme is ISO 20022-native from inception, and Bridge's Raast integration inherits that structure into the broader corridor flow. A UAE-to-Pakistan payment that settles with a stablecoin leg and pays out via Raast carries consistent data through every stage of the flow, which is the property that delivers the compliance and reconciliation benefits.

For use cases where tokenised securities rather than tokenised cash are the primary asset, the same data model extends to the securities metadata. Bridge's tokenisation platform applies ISO 20022-aligned structures to issuance, transfer and servicing of tokenised securities, which lets the cash leg and the asset leg share a consistent compliance surface.

Two trends define the near-term evolution of the ISO 20022-and-tokenisation relationship. The first is richness: as more institutions move from technical migration to full data usage, the benefit-per-transaction of ISO 20022-native settlement compounds. The second is convergence between the legacy and the tokenised rails: ISO 20022 gives the two rails a common vocabulary, which shortens the distance between them and makes hybrid flows more operationally tractable than they were when the messaging and the ledger were separate worlds.

Firms building modern settlement infrastructure should treat ISO 20022 as the canonical data model and tokenisation as the settlement substrate, with compliance and reporting derived from both rather than built alongside. That is the architecture that delivers the cost, speed and transparency improvements the modernisation agenda has been promising for the last decade, and it is the architecture that Bridge infrastructure is designed to support.

If you are evaluating how ISO 20022 and tokenised settlement fit together for your institution — whether you are a bank working through the data-richness phase, a fintech building a new corridor, or a market participant preparing for tokenised asset flows — Bridge's settlement platform is designed around this combined architecture. Reach out via our contact page to arrange a technical review.