Swift's Shared Ledger Is Live And Three Vendors Are Racing To Wire Banks In: The Commitment Lifecycle, Self-Signing Key Custody And ISO 20022 Mapping, In Code

Javier Pérez-Tasso used Sibos's opening day to say the words the industry had been waiting for: Swift's ledger is live and in use by some of the largest institutions in the world, and by the end of the year at least 19 banks will be using it across five major currencies for 24/7 payments in tokenised deposits, with delivery-versus-payment and payment-versus-payment coming soon. Citi's Jane Fraser set the tone with a railway-gauge analogy - 'you can't just have a new system and an old system that are competing against each other' - and a warning: 'If we break trust, that is a huge problem for the macro, for the markets, for everywhere.' The IMF's Dan Katz argued the biggest near-term gains from AI would come from agents improving the payment system we already have: optimising fees, automating mechanics, cutting compliance cost.

The architecture, as documented by the analysts tracking it, is deliberately conservative. The ledger runs on Hyperledger Besu - a permissioned, EVM-compatible network - and acts as an orchestration layer for interbank payment commitments rather than a settlement layer: tokenised deposits remain liabilities on each bank's own balance sheet and final settlement still happens over existing RTGS infrastructure. There are no gas fees or validator rewards. The MVP went live in July; the 17 pilot banks span ANZ, BNP Paribas, BNY, Citi, DBS, First Abu Dhabi Bank, FirstRand, HSBC, Itaú Unibanco, Lloyds, Mashreq, MUFG, OCBC, Standard Chartered, UBS, UOB and Wells Fargo. And in one week three vendors announced ways in: Chainlink's Runtime Environment, with a self-signing model in which banks retain control of the cryptographic keys that authorise transactions; Oracle's EVM platform hosting Swift's commitment contracts linked to Oracle Banking Payments with ISO 20022 support; and IBM's Digital Asset Haven for 24/7 asset movement.

1. The Commitment State Machine

The single most important design decision is that the commitment on the ledger and the customer-facing money movement in your core are different objects with different finality. The state machine below is what our settlement workflows carry: it distinguishes ledger commitment from interbank settlement, and it models the failure cases - counterparty rejection, settlement shortfall at RTGS open - explicitly.

from enum import Enum
from dataclasses import dataclass, field
from decimal import Decimal

class State(str, Enum):
    DRAFT = "draft"                    # built from pacs.008, not yet signed
    SIGNED = "signed"                  # signed in our HSM, not yet submitted
    COMMITTED = "committed"            # accepted on the ledger; counterparty can credit
    CREDITED = "credited"              # beneficiary bank confirmed customer credit (24/7)
    SETTLING = "settling"              # interbank obligation queued for RTGS window
    SETTLED = "settled"                # RTGS finality reached (T2 hours)
    REJECTED = "rejected"              # counterparty or ledger rejected
    SHORTFALL = "shortfall"            # RTGS settlement failed; obligation outstanding

TRANSITIONS = {
    State.DRAFT: {State.SIGNED},
    State.SIGNED: {State.COMMITTED, State.REJECTED},
    State.COMMITTED: {State.CREDITED, State.REJECTED},
    State.CREDITED: {State.SETTLING},
    State.SETTLING: {State.SETTLED, State.SHORTFALL},
    State.SHORTFALL: {State.SETTLING},                 # retry next window
}

@dataclass
class Commitment:
    uetr: str                            # ISO 20022 end-to-end reference, reused as ledger id
    debtor_bank: str
    creditor_bank: str
    currency: str
    amount: Decimal
    value_time: str                      # ISO timestamp; 24/7, not a business date
    state: State = State.DRAFT
    history: list = field(default_factory=list)

    def move(self, new: State, evidence: str) -> None:
        if new not in TRANSITIONS.get(self.state, set()):
            raise ValueError("illegal transition " + self.state + " -> " + new)
        self.history.append((self.state, new, evidence))
        self.state = new

2. Self-Signing: Keys That Never Leave The Bank

Chainlink's pitch - and the reason bank security teams will accept any of these middleware layers - is that the middleware transports and orchestrates but the bank signs. Whatever vendor you choose, the shape should be the same: the commitment payload is canonicalised inside your perimeter, signed by a key in your HSM under your policy (dual control above a threshold, per-currency limits), and only the signed payload leaves. The middleware never sees a private key, and cannot originate a commitment you did not sign.

import hashlib, json

class SigningService:
    """Runs inside the bank. The HSM holds the key; this service enforces policy."""
    def __init__(self, hsm, policy, audit):
        self.hsm, self.policy, self.audit = hsm, policy, audit

    def canonical(self, c) -> bytes:
        body = {"uetr": c.uetr, "debtor": c.debtor_bank, "creditor": c.creditor_bank,
                "ccy": c.currency, "amt": str(c.amount), "value_time": c.value_time}
        return json.dumps(body, sort_keys=True, separators=(",", ":")).encode()

    def sign(self, c, approvals: list) -> dict:
        payload = self.canonical(c)
        digest = hashlib.sha256(payload).hexdigest()
        self.policy.check(c, approvals)            # limits, dual control, sanctions status, liquidity
        sig = self.hsm.sign(key_id="swift-ledger-" + c.currency, digest=digest)
        self.audit.append({"uetr": c.uetr, "digest": digest, "approvals": approvals})
        c.move("signed", "digest:" + digest)
        # Only payload + signature go to the middleware / ledger client.
        return {"payload": payload.decode(), "signature": sig, "key_id": "swift-ledger-" + c.currency}

• One key per currency, with limits enforced in policy before the HSM is asked to sign.
• Dual control is a policy input, not a UI feature: the approvals list carries signed attestations from two identities above the threshold.
• The audit record stores the digest, not the payload, so you can prove what was signed without duplicating payment data.

3. ISO 20022 In, Commitment Out

Banks already produce pacs.008 credit transfers with a UETR, debtor and creditor agents, amount and settlement information. Oracle's approach - commitment contracts beside a payments engine that speaks ISO 20022 - is the right shape: the commitment is derived from the message you already have, and the UETR ties ledger, message and core together end to end.

from decimal import Decimal

def commitment_from_pacs008(msg: dict) -> Commitment:
    tx = msg["FIToFICstmrCdtTrf"]["CdtTrfTxInf"]
    amt = tx["IntrBkSttlmAmt"]
    return Commitment(
        uetr=tx["PmtId"]["UETR"],
        debtor_bank=tx["DbtrAgt"]["FinInstnId"]["BICFI"],
        creditor_bank=tx["CdtrAgt"]["FinInstnId"]["BICFI"],
        currency=amt["Ccy"],
        amount=Decimal(amt["value"]),
        value_time=msg["FIToFICstmrCdtTrf"]["GrpHdr"]["CreDtTm"],   # timestamp, not IntrBkSttlmDt
    )

# Status back to the customer channel uses pacs.002 with the same UETR:
# COMMITTED -> ACSP (accepted, settlement in process)
# CREDITED  -> ACCC (accepted, credit to creditor account completed)
# SETTLED   -> ACSC (accepted, settlement completed)
STATUS_MAP = {"committed": "ACSP", "credited": "ACCC", "settled": "ACSC", "rejected": "RJCT"}

4. Operating 24/7 Against A Settlement System That Is Not

The hard operational problem is not the ledger; it is that commitments accumulate through the night and weekend while the interbank obligation cannot reach finality until the RTGS window opens. That means a bilateral exposure ledger per counterparty and currency, hard caps, and a liquidity forecast for the next window - the same controls we described for Pontes, now with a live network to run them against.

from collections import defaultdict
from decimal import Decimal

class ExposureBook:
    def __init__(self, caps: dict):
        self.caps = caps                      # (counterparty, ccy) -> Decimal cap
        self.net = defaultdict(Decimal)       # (counterparty, ccy) -> net owed to us (+) / by us (-)

    def can_commit(self, c) -> bool:
        key = (c.creditor_bank, c.currency)
        projected = self.net[key] - c.amount   # we will owe them until RTGS settles
        return abs(projected) <= self.caps.get(key, Decimal("0"))

    def record(self, c, direction: int) -> None:
        self.net[(c.creditor_bank if direction < 0 else c.debtor_bank, c.currency)] += direction * c.amount

    def next_window_funding(self, ccy: str) -> Decimal:
        # Sum of what we owe across counterparties in this currency at the next RTGS open.
        return -sum(v for (cp, k), v in self.net.items() if k == ccy and v < 0)

“The ledger is live; the clock is the problem. Every design decision in a Swift-ledger integration is really a decision about what your bank is willing to owe, to whom, between Friday night and Monday morning.”

Choosing A Way In

• Chainlink CRE: strongest on the self-signing model and on connecting to other chains and DTCC's collateral work; evaluate its key-custody boundary against your HSM policy.
• Oracle: the natural fit for banks on Oracle Banking Payments - commitment contracts beside the ISO 20022 engine you already run.
• IBM Digital Asset Haven: aimed at 24/7 movement of tokenised assets beyond payments; relevant when DvP arrives.
• Direct: a Besu client of your own. Most control, most work, and the option that keeps the vendor layer thin if the ledger's APIs stabilise.

The Bottom Line

Swift's shared ledger is live, heading for 19 banks and five currencies by year-end with DvP and PvP to follow, built as a permissioned Besu orchestration layer for signed interbank commitments while RTGS keeps finality - and Chainlink, Oracle and IBM have opened a middleware race to connect banks to it. The integration that survives your security and treasury reviews has four parts: a commitment state machine that separates ledger commitment from settlement finality, a signing service whose keys never leave your HSM and whose policy runs before the signature, a mapping from the pacs.008 you already produce keyed on UETR, and an exposure book with caps and next-window funding for the hours when the ledger is awake and T2 is not. That is the settlement workflow architecture we build for banks in London, and this Sibos turned it from a pilot into a production requirement.

References & Further Reading

• The Fintech Times - Sibos 2026 day one: Fraser tells Miami to move fast without breaking trust (28 September 2026). thefintechtimes.com/sibos-2026-day-one-fraser-tells-miami-to-move-fast-without-breaking-trust
• Blockchain Payment Flow Analysis - Deep dive: three vendors race to wire 17 banks into Swift ledger (Sibos 2026). github.com/Ricosworks1/blockchain-payment-flow-analysis/releases/tag/deep-dive-swift-ledger-vendor-race-sibos-2026-sept-2026
• Chainlink - Sibos 2026 recap: connecting global finance to onchain markets. chain.link/blog/sibos-2026-recap
• Swift - Sibos 2026 Miami. swift.com/news-events/events/sibos-2026-miami
• Hyperledger Besu - documentation. besu.hyperledger.org
• ISO 20022 - message definitions (pacs.008, pacs.002). iso20022.org/iso-20022-message-definitions
• BIS Innovation Hub - Project Agorá: tokenised deposits and cross-border payments. bis.org/about/bisih/topics/fmis/agora.htm

Code in this guide is illustrative and supplied without warranty. Review and test it before production use. Nothing here is investment advice. Important information