The Payment Stack: How a Single Transaction Is Encapsulated, Cleared and Settled Across Four Layers

A stack, not a pipeline

It is tempting to picture a payment as a pipe: money goes in one end and comes out the other. The reality is closer to the OSI model that any computer scientist will recognise. A payment is a payload that gets wrapped in successive headers as it moves down through layers of infrastructure, and unwrapped as it moves up at the receiving end. Each layer trusts the layer below to do its job and exposes a clean interface to the layer above. Crucially, each layer has its own addressing, its own rulebook, its own settlement asset and its own risk profile.

There are, broadly, four of them.

The single most important idea here is encapsulation. When you tap a card in a London shop, that instruction is a Layer 1 event. The acquirer and issuer do not move any money at that moment; they exchange a promise. That promise is later bundled with thousands of others and handed down to Layer 2, where the two banks' net obligations are settled in central bank money. If the buyer's and seller's banks sit in different countries but share a currency, Layer 3 takes over. If they sit in different currencies, the obligation is wrapped once more for Layer 4, where it becomes a foreign-exchange settlement problem. Each descent adds a header — a new set of identifiers, a new rulebook, a new clearing and settlement cycle — and each layer is blind to the detail above it. The card scheme does not care which RTGS system ultimately settles the bank-to-bank leg; the RTGS system does not care that the underlying event was a coffee.

The vertical journey: tokenisation, authorisation, clearing, settlement, dispute

Before walking across the layers, it is worth walking down a single transaction, because the lifecycle of one card payment contains the whole logic of the stack in miniature. Five things happen, and they happen at different speeds and in different places.

Tokenisation comes first and is purely about protecting the instrument. Under the EMVCo network-tokenisation framework, the real card number (the PAN) is replaced by a surrogate token that is useless if intercepted and can be scoped to a single merchant or device. The merchant never holds the PAN; the token travels instead, and only the token service provider can map it back. Tokenisation is the modern answer to the fact that the retail edge is where fraud concentrates.

Authorisation is a real-time promise, not a movement of money. In milliseconds, the acquirer routes a request — historically an ISO 8583 message, increasingly ISO 20022 — to the issuer, which checks the token, the available balance or credit line, velocity rules and fraud scores, then approves or declines. Strong Customer Authentication may be invoked. When the merchant sees "approved", no funds have moved; an obligation has been created and a hold placed.

Clearing is the reconciliation step. Authorisations are batched and presented; the scheme calculates what every issuer owes every acquirer. This is where the gross flow of individual transactions is compressed into a small number of net positions. Clearing produces the instruction; it does not move the money.

Settlement is the only step where money actually changes hands, and it happens one layer down. The net positions from clearing are discharged across settlement accounts — ultimately in central bank money at Layer 2. This is why authorisation and settlement are decoupled: the customer experiences an instant decision, but the banks settle hours or days later, in bulk, on a different rail.

Disputes are the one place value flows backwards. A chargeback reverses a settled transaction under scheme rules, reallocating liability between issuer and acquirer. It is the retail edge's consumer-protection mechanism — and, notably, the feature that account-to-account rails still struggle to replicate, because an instant credit transfer is designed to be irrevocable.

The lesson generalises: across the whole stack, the promise and the money travel separately. Authorisation, clearing and settlement are distinct functions, often on distinct infrastructure, with distinct timing. Most operational and risk failures in payments live in the gap between them.

Layer 1 — the instrument and the retail edge

This is the layer customers actually touch: cards, wallets, Open Banking account-to-account payments, and domestic instant schemes such as India's UPI. The core players are the four-party card networks (Visa, Mastercard) and, increasingly, the bank-direct A2A ecosystem built on Open Banking APIs. The dominant risks here are fraud and credit risk — the issuer is extending value before it settles, and the network is the most attractive target for attackers — which is precisely why tokenisation, SCA and real-time scoring all live at this edge. Layer 1 is overwhelmingly real-time: the customer expects a sub-second decision. But it is real-time only in authorisation. The money still drops down to slower, deferred plumbing beneath.

Layer 2 — national interbank settlement

Beneath every domestic payment scheme sits the question: how do two banks actually settle in central bank money? Two models dominate.

Deferred Net Settlement (DNS) accumulates obligations across a cycle and settles the net at defined windows — efficient on liquidity, because banks only fund their net position, but it means that between windows banks build up uncollateralised exposure to one another. That exposure is settlement risk, and it is the reason DNS systems require loss-sharing arrangements and collateral pools.

Real-Time Gross Settlement (RTGS) settles each payment individually and immediately in central bank money, eliminating interbank exposure entirely — but demanding that banks hold or borrow far more intraday liquidity. The trade-off between the two is the foundational tension of the layer: speed and risk-elimination on one side, liquidity cost on the other.

In the UK the layer is unusually legible: Faster Payments for retail-instant, Bacs for bulk direct debits and credits, CHAPS for high-value RTGS, and image clearing for cheques. In the US it is ACH (deferred), Fedwire (RTGS) and FedNow (instant). The settlement asset in every case is central bank money, which is why participation is tiered: a handful of direct participants hold settlement accounts at the central bank, and everyone else reaches the rail indirectly through them. Tiering is itself an encapsulation — the indirect participant's payment is wrapped inside its sponsor's settlement.

Layer 3 — the regional, single-currency layer

Some payments cross borders without crossing currencies. A euro payment from a German payer to a Spanish payee is "cross-border" geographically but stays inside one currency area, so it does not need the heavy machinery of Layer 4. The Eurosystem built this layer deliberately: SEPA harmonises credit transfers and direct debits across the bloc, T2 (the consolidated RTGS platform that replaced TARGET2 in 2023) settles high-value euro flows in central bank money, and TIPS provides 24/7 instant settlement. Layer 3 is effectively a national interbank layer scaled up to a currency union — a regional central bank infrastructure into which national flows are encapsulated. Pan-regional ACH arrangements elsewhere aim at the same shape.

Layer 4 — cross-currency and the global edge

Everything becomes harder the moment two currencies are involved, because there is no single central bank and no single settlement asset. Historically the answer is correspondent banking: a bank holds an account (a nostro) with a partner abroad and offers one in return (a vostro), and value moves by debiting and crediting these mirrored balances. The instruction that coordinates all this is a message, not money — and that messaging layer is SWIFT. It is worth stating plainly because it is so often misunderstood: SWIFT does not move funds or settle anything. It carries standardised instructions between institutions. As of 22 November 2025, those cross-border instructions must use ISO 20022 (the pacs and camt messages, with pacs.008 replacing the venerable MT103), ending a two-decade migration toward richer, structured data — and a further mandate in November 2026 will retire fully unstructured postal addresses in favour of structured or hybrid formats.

The deep risk at this layer is one of timing. A foreign-exchange trade has two legs in two currencies that settle in two time zones through two separate national systems. If one party pays away its leg and the counterparty fails before paying the other, the first party can lose the entire principal. This is Herstatt risk, named for the 1974 collapse of Bankhaus Herstatt, which was closed by German regulators after taking in Deutschmarks but before paying out the corresponding dollars. Solving it is the entire reason CLS exists.

CLS — eliminating settlement risk through payment-versus-payment

CLS (originally Continuous Linked Settlement) is the utility that removes Herstatt risk from the bulk of the global FX market. Its mechanism is payment-versus-payment (PvP): the two currency legs of a trade settle simultaneously across accounts held with CLS, or neither settles at all. Principal risk is eliminated by construction.

The scale is systemic. CLS settles 18 of the world's most-traded currencies, with an average daily value of roughly USD 7.9 trillion in the first half of 2025 for its 76 settlement members and over 37,000 third-party participants — figures that make it one of the most concentrated points in the entire financial system. It is designated a systemically important financial market utility and overseen by a cooperative of central banks. Beyond risk elimination, CLS delivers enormous liquidity efficiency: by multilaterally netting gross instructions it compresses payment values by around 96%, so that members fund only about 1% of gross value to settle the whole day. Because PvP is hard to extend to thinly traded currencies, CLS also runs CLSNet, a bilateral netting calculation service covering more than 120 currencies, for flows that cannot reach the PvP service. The 2025 update to the FX Global Code formalised this hierarchy as a "settlement risk waterfall", placing PvP at the top and netting beneath it. CLS, in short, is the answer that the cross-currency layer evolved to give to the timing problem that the layer itself created.

The Bank for International Settlements — the layer above the layers

If CLS is infrastructure, the Bank for International Settlements (BIS) is the institution that writes the rules the infrastructure must follow and coordinates the central banks that own the settlement assets. Often called the central bank of central banks, the BIS hosts the Committee on Payments and Market Infrastructures (CPMI), whose Principles for Financial Market Infrastructures are the global rulebook that every systemically important system — RTGS operators, central counterparties, CLS itself — is expected to meet. In stack terms, the BIS is the governance and standards layer sitting above all four operational layers.

The BIS also runs the Innovation Hub, which is actively prototyping the next generation of the cross-border layer, and its three flagship projects map neatly onto the themes above. Project Nexus standardises how national instant-payment systems interlink, so that each system makes one connection to a shared scheme rather than a fragile web of bilateral links; with India, Malaysia, the Philippines, Singapore and Thailand as founding members and a dedicated scheme organisation now established, it targets live operation around mid-2027. Project Agorá explores tokenisation, bringing tokenised commercial-bank deposits and wholesale central bank money onto a shared programmable platform with central banks across Europe, Japan, Korea and the United States and a large group of private banks. And Project mBridge, the multi-CBDC platform, illustrates the geopolitics of the top of the stack: the BIS handed management to the participating central banks (China, Hong Kong, Thailand, the UAE and Saudi Arabia) in late 2024. Together these projects represent three competing answers to the same Layer 4 problem — interlink the rails, tokenise the assets, or rebuild settlement in central bank digital money.

Where risk lives, and the real-time versus deferred dilemma

Read the stack vertically and a pattern emerges: risk changes character as you climb. At the retail edge, the dominant risks are fraud and the issuer's credit exposure. At the national layer, they become settlement and liquidity risk, governed by the choice between deferred-net and real-time-gross designs. At the cross-currency layer, they become FX settlement (Herstatt) risk, addressed by PvP. The same payment carries different dangers depending on which layer you observe it from — which is exactly why an institution must know precisely which layer it occupies and what it is implicitly trusting the layers around it to absorb.

The real-time-versus-deferred dilemma threads through every layer and never fully resolves. Instant, gross, 24/7 settlement removes the accumulated exposure of settlement windows but demands liquidity be available continuously, including overnight and at weekends when funding markets are thin. Deferred net settlement is liquidity-light but rebuilds exposure between cycles. As instant rails spread up the stack — TIPS regionally, Nexus across borders — that tension migrates upward with them, and the liquidity question that was once a domestic treasury problem becomes a global one.

Implications for Digital Bank Expert's clients

For any institution modernising its payment estate, the practical takeaway is to design for the stack rather than for a single rail. Three threads matter most right now. First, ISO 20022 has become the common language across all four layers — domestic RTGS, SEPA, and now cross-border as of the November 2025 cutover — and the structured-address mandate arriving in November 2026 makes data quality a settlement-blocking issue rather than a cosmetic one. Second, tokenisation is appearing simultaneously at both edges of the stack: network tokens at the retail layer and tokenised deposits at the wholesale layer through work like Project Agorá, which means the same architectural concept now has to be reasoned about end to end. Third, a design decision at one layer ripples upward: choosing an instant rail at Layer 1 imposes a real-time liquidity obligation that someone, somewhere up the stack, has to fund.

This is the work we do at Digital Bank Expert — helping issuers, acquirers, processors and infrastructure operators understand exactly where they sit in the stack, what they are encapsulating, and what they are trusting the layers around them to deliver. The institutions that treat payments as a layered architecture, rather than a pipe, are the ones that will navigate the next decade of instant, tokenised, ISO-native infrastructure without discovering their risks the hard way.

Bibliography

• Bank for International Settlements, Committee on Payments and Market Infrastructures & IOSCO (2012). Principles for Financial Market Infrastructures (PFMI). https://www.bis.org/cpmi/publ/d101.htm
• Bank for International Settlements (2024). Project Nexus: enabling instant cross-border payments (and 2025 update). https://www.bis.org/about/bisih/topics/fmis/nexus.htm
• Bank for International Settlements (2024). Project Agorá: central banks and banking sector embark on major project to explore tokenisation of cross-border payments. https://www.bis.org/about/bisih/topics/fmis/agora.htm
• Bank for International Settlements (2024). BIS to step away from Project mBridge.https://www.bis.org/about/bisih/topics/cbdc/mcbdc_bridge.htm
• CLS Group (2025). CLSSettlement and the payment-versus-payment model / Statement on the updated FX Global Code. https://www.cls-group.com
• Global Foreign Exchange Committee (2025). FX Global Code (Principle 35, settlement-risk waterfall). https://www.globalfxc.org
• European Central Bank. TARGET Services — T2 and TIPS.https://www.ecb.europa.eu/paym/target/html/index.en.html
• European Payments Council. SEPA Credit Transfer & SCT Inst rulebooks.https://www.europeanpaymentscouncil.eu
• SWIFT (2025). ISO 20022 for financial institutions — CBPR+ and the end of MT/MX coexistence (22 November 2025). https://www.swift.com/standards/iso-20022
• EMVCo. EMV Payment Tokenisation Specification. https://www.emvco.com
• Bank of England. CHAPS, RTGS and the UK payment landscape. https://www.bankofengland.co.uk/payment-and-settlement