Payments10 min read

ISO 20022 and TradFi-DeFi Convergence: What Payment Orchestration Must Handle

TradFi-DeFi convergence breaks at the settlement layer, not the data layer. SEPA Credit Transfers settle through deferred net settlement with T+1 finality confirmed by a clearing and settlement mechanism. On-chain transactions settle through atomic gross settlement with finality determined by block confirmation depth. These are not just different speeds. They are different assumptions about finality, reversibility, and recovery that a payment orchestration layer must resolve explicitly before it can handle either model correctly.

ISO 20022 provides a common data language for both worlds. The message structure that carries a pacs.008 SEPA Credit Transfer can, with extensions, carry an on-chain transfer instruction. The BankTransactionCode taxonomy classifies traditional payment types; the standard is being extended to cover tokenized asset movements. Data format is a solved problem. The orchestration model is not.

Two Settlement Models, Two Finality Assumptions

Deferred net settlement works by accumulating offsetting obligations across participants throughout the day and netting them at defined clearing windows. A pacs.008 submitted at 09:00 may not settle until the 14:00 clearing cycle. During that window, the payment is a claim, not a settled transfer. The claim can be rejected (pacs.002 negative acknowledgment), recalled (camt.056 cancellation request), or returned after settlement (pacs.004 R-transaction). Finality is irrevocable only after the clearing window closes.

The orchestration layer must track this lifecycle. A payment that has been submitted but not settled is in a known intermediate state: SUBMITTED_TO_CLEARING. A payment that has settled is SETTLED. A payment that has been returned is RETURNED. The ledger must treat these states distinctly: do not mark the debit as final until settlement is confirmed, because the R-transaction window is still open.

On-chain settlement is atomic and final at confirmation. When a transaction is included in a confirmed block on a deterministic chain, it is settled. There is no intermediary. There is no clearing window. There is no mechanism to reverse it through a structured R-transaction process. Only the originator can initiate a new compensating transaction, which appears in the ledger as a separate entry, not as a reversal of the original.

The finality assumption is different in kind, not in degree. TradFi settlement finality is a legal construct: the clearing agreement, the rules of the payment scheme, and the applicable regulation (PSD2 Art. 80-81 on settlement finality) define when a payment is irrevocable. On-chain settlement finality is a mathematical construct: it is the probability that the block containing the transaction will be reorganized out of the canonical chain. For practical purposes, finality is reached after a defined number of block confirmations, but that number varies by chain, by block time, and by the institution's risk appetite.

Where the Orchestration Layer Must Adapt

A payment orchestration layer designed exclusively for SEPA has five built-in assumptions: settlement is batched, finality comes from a clearing network, R-transactions are the reversal mechanism, timelines are measured in hours, and counterparty identification is via IBAN. Each assumption breaks for on-chain settlement.

Batching vs. atomicity. SEPA batch submission requires collecting transfers, constructing a pacs.008 bulk message, and submitting within the clearing window. On-chain submission requires signing a transaction and broadcasting it. The orchestration layer must distinguish between these submission models by instrument type. A single orchestration framework that treats all payment submissions as queue-based batch submissions will introduce unnecessary latency for on-chain transfers and incorrect lifecycle management for SEPA transfers.

Finality confirmation. For SEPA, finality confirmation arrives as a camt.054 credit notification or a pacs.002 positive acknowledgment from the clearing network. For on-chain transfers, finality confirmation requires monitoring the chain until the target block depth is reached. The orchestration layer must poll or subscribe to chain state, a mechanism that has no analogue in SEPA processing. The timeout model is also different: SEPA has defined clearing windows and explicit rejection messages. An on-chain transaction that is not confirmed in a reasonable time is not rejected; it is still pending, potentially stuck in the mempool, and requires manual intervention or rebroadcasting with higher fees.

Reversal mechanism. When a SEPA payment must be reversed after settlement, the standard mechanism is pacs.004 (Payment Return) or camt.056 (Cancellation Request), both of which result in a structured R-transaction with a defined reason code, a defined timeline, and a defined ledger treatment (correction entry per HGB §239). For on-chain transfers, reversal is a new transaction: debit the recipient, credit the sender, reference the original transaction in metadata. The reversal is not standardized, not automatically classified, and not subject to a scheme-defined deadline. The orchestration layer must handle both reversal models with different journaling logic.

Counterparty identification. SEPA uses IBAN as the primary account identifier. On-chain transfers use a cryptographic address (public key hash). An orchestration layer processing both must resolve the address model: is a blockchain address a first-class account identifier stored in the ledger, or is it a property of a customer's CDD record? The answer affects customer deduplication, transaction monitoring, and sanctions screening, all of which operate on the IBAN model and must be adapted for address-based identification.

ISO 20022 as the Bridge

ISO 20022's extensibility makes it the natural data bridge between settlement models. The pacs message types (pacs.008 for credit transfers, pacs.004 for returns) are already used for SEPA. The same message structures, with local instrument codes that identify the settlement model, can carry on-chain transfer instructions.

The BankTransactionCode taxonomy provides a classification framework. PMNT/RCDT/ESCT identifies an incoming SEPA Credit Transfer. A new code, PMNT/RCDT/TKNZ (tokenized incoming credit transfer) or equivalent, under development in ISO 20022 extension working groups, would identify an incoming on-chain transfer using the same Domain/Family/SubFamily structure. The AML engine, the reconciliation engine, and the reporting pipeline that already consume BankTransactionCodes can process tokenized transfers without a separate code path, once the code set is extended.

The $27.5 billion in tokenized real-world assets on-chain as of Q1 2026, up 30% in three months, represents a volume that no institution can process manually through separate workflows. The pressure to integrate token transfers into standard payment pipelines is already present. The data standard is ready. The orchestration model needs to catch up.

Exactly-Once Semantics Across Settlement Models

Exactly-once execution is harder to guarantee when the payment crosses settlement models. A hybrid payment (initiate on-chain, confirm off-chain, settle the net in fiat) creates a multi-step workflow where each step has a different idempotency and reversal model.

Consider: a customer initiates a EUR 50,000 on-chain transfer from their tokenized euro deposit to a counterparty's tokenized account. The receiving institution wants fiat settlement. The workflow:

Debit the customer's tokenized account (on-chain, atomic, irreversible once confirmed)
Submit a fiat Credit Transfer to the counterparty's institution (SEPA, batched, reversible via R-transaction)
Receive settlement confirmation from the clearing network
Credit the counterparty's fiat account

If step 2 fails after step 1 commits, the compensation is not a reversal of step 1. It is a new on-chain credit to return funds. If step 3 fails after step 2 submits, the orchestration layer must wait for either settlement confirmation or an R-transaction, then credit or debit accordingly. The compensation model requires tracking the settlement state of both legs independently.

A durable execution engine journals every step before execution. If the engine crashes between step 1 and step 2, it replays the journal on restart and picks up at step 2. If step 2 produces an R-transaction (the SEPA payment is returned), the engine executes the compensation handler: a new on-chain credit to the originator, recorded as a correction entry in the ledger. The complete sequence, both legs, the failure, and the compensation, exists in one journal with one correlation ID.

Trade-offs

Dual-model payment orchestration introduces operational complexity that purely SEPA-focused systems avoid.

Failure mode multiplication. Each settlement model has its own failure modes. A system handling both must handle both sets: SEPA R-transactions, clearing network outages, and batch submission failures on one side; mempool congestion, reorg risk, node connectivity issues, and address resolution failures on the other. The operations team must be trained and tooled for both.

Latency asymmetry. On-chain settlement for some instruments takes seconds. SEPA settlement takes hours. A system that presents both as "payment" must make the latency difference explicit to customers and to the downstream systems that depend on settlement confirmation. Treating on-chain settlement as a fast SEPA analogue, using the same expected settlement time in downstream systems, will produce incorrect reporting and incorrect capital calculations.

Regulatory classification. The legal classification of an on-chain transfer differs from a SEPA transfer in ways that affect the applicable regulatory treatment. Under MiCAR, transfers of EMTs carry specific AML obligations. Under PSD2, transfers of fiat carry different obligations. A payment that crosses models (fiat in, token out, or token in, fiat out) must be correctly classified for each leg independently. The compliance pipeline must handle composite regulatory classification, not a single category per transaction.

Fernel Context

Fernel's payment orchestration uses ISO 20022 native message models for SEPA payment types, with BankTransactionCodes stored natively rather than translated to proprietary codes. The durable execution engine journals every payment workflow step, including the settlement lifecycle states SUBMITTED_TO_CLEARING, SETTLED_PENDING, and SETTLED_AVAILABLE, before execution. Extending the same orchestration model to cover on-chain settlement requires adding a new settlement adapter (chain monitoring, address resolution, confirmation tracking) without modifying the workflow engine or the ledger. The journal model is settlement-model-agnostic by design: each step carries its own input/output record regardless of whether the underlying operation is a SEPA submission or a chain broadcast.

Sources:

Money20/20 Europe 2026, The New Intersection of Money: Where TradFi and DeFi Converge, co-authored by Scarlett Sieber et al.
Cambridge Centre for Alternative Finance, Tokenized RWA Q1 2026: $27.5 billion on-chain, +30% in 3 months
ISO 20022 pacs.008.001.11 (Credit Transfer), pacs.004.001.11 (Payment Return): message structure specifications
ISO 20022 BankTransactionCode External Code Sets, Domain/Family/SubFamily taxonomy
PSD2, Directive 2015/2366, Art. 80-81 (Settlement finality and irrevocability)
MiCAR, Regulation (EU) 2023/1114, Art. 83 (AML obligations for tokenized transfer instruments)
EPC SCT Inst Rulebook (v2024.1): SEPA Instant Credit Transfer settlement model and timing