A2A tokenization on Fabric: two European banks, one Saudi bank

Section 01

A three-bank corridor between the euro area and the Kingdom of Saudi Arabia

A German mid-market exporter of precision machine tools instructs its house bank in Munich to pay EUR 4,820,000 to a contracting authority in Riyadh in respect of a desalination project milestone. The originator's bank lacks a direct correspondent account in Saudi riyal; it relies on a Paris-based affiliate that runs a SAR nostro at the Riyadh receiver. All three banks are members of the same permissioned Fabric network.

The transfer is to be effected as an on-ledger token movement settled in commercial bank money, with the corresponding fiat positions flattened end-of-day through the existing real-time gross settlement (RTGS) systems on each side. The corridor is denominated in EUR and SAR. The Saudi riyal has been pegged to the U.S. dollar at SAR 3.75 = USD 1 since 1986, and the EUR/SAR cross is a function of the ECB euro reference rate against the dollar. For this paper we take an indicative EUR/SAR mid of 4.0825 and apply a 6 bp spread to the taker, yielding a SAR-side notional of approximately SAR 19,683,765.

Section 02

Network topology: organizations, peers, orderers, certificate authorities

Each participating bank operates a single Fabric organization with two endorsing peers (active/standby) and one Fabric CA. The orderer set is operated jointly across all three banks plus two independent technical operators. Peers expose the Fabric Gateway service over mTLS to the bank's payment hub. The deployment runs on Hyperledger Fabric 2.5.x LTS — the long-term-support line maintained by IBM and the Linux Foundation.

World state is kept in CouchDB on each peer to permit rich JSON queries against payment metadata. Container images are pinned by sha256 digest and signed with cosign; chaincode is packaged as the lifecycle v2 external builder artefact and approved per the channel's lifecycle endorsement policy.

Section 03

Identity, MSP, and the chain of trust

Every actor on a Fabric network — peer, orderer, client, or chaincode caller — authenticates with an X.509 certificate issued by an organization's Membership Service Provider. Each bank operates an isolated Fabric CA whose root certificate is configured in the channel's MSP stanza. There is no cross-signed root: the consortium trusts each bank's CA explicitly, and revocation is propagated through periodic CRL updates committed by the channel administrators via the UpdateConfig transaction path.

Within each bank, identities are partitioned by Organizational Unit: the peer OU for nodes, the client OU for the payment hub gateway, the admin OU for lifecycle operations, and a custom treasury OU that gates the Mint and Redeem functions of the token contract. Operators carry an additional role=approver attribute used by the dual-control logic in the chaincode.

Private keys are generated and held in FIPS 140-2 Level 3 HSMs and presented to Fabric via the PKCS#11 BCCSP. Treasury operators authenticate via smart-card-backed certificates with a 12-hour validity, regenerated by an online enrolment service that consults the bank's identity-and-access-management directory before signing.

Section 04

Channels, private data collections, and confidentiality boundaries

Channels in Fabric are independent ledgers — each is a separate sequence of blocks ordered by the same orderer set but isolated at the gossip layer. We provision four channels: one shared corridor channel for all three organizations and three bilateral channels for nostro reconciliation between each pair of banks.

The shared eursar-corridor channel carries the EUR/SAR token contract, the FX oracle contract, and the netting contract. The three bilateral channels — de-fr-bilateral, fr-sa-bilateral, and de-sa-bilateral — carry position reconciliation and bilateral repo traffic that should not be visible to the third party.

Even on the shared corridor channel, Travel Rule data and the underlying ISO 20022 message body never reach the third bank's ledger. We use a private data collection named PDC_TR whose policy restricts visibility to the originating and beneficiary organizations only. The hash of the private data is committed to the public channel ledger so the liquidity bank can verify integrity without seeing personal data.

# collections_config.json — registered at chaincode install
[
  {
    "name": "PDC_TR_DE_SA",
    "policy": "OR('Org1MSP.member','Org3MSP.member')",
    "requiredPeerCount": 1,
    "maxPeerCount": 2,
    "blockToLive": 1095,           # ~3 years; AML retention minimum
    "memberOnlyRead": true,
    "memberOnlyWrite": true,
    "endorsementPolicy": {
      "signaturePolicy": "AND('Org1MSP.peer','Org3MSP.peer')"
    }
  }
]

The corridor channel's endorsement policy for the token contract is AND(OutOf(2,'Org1MSP.peer','Org2MSP.peer','Org3MSP.peer')): any two of three banks must endorse a transfer. This is enforced by the Validation System Chaincode at commit time, after the orderer has cut the block but before the peers update world state.

Section 05

Go chaincode: state model, endorsement, and dual control

Three chaincodes are deployed on the corridor channel: cbm-token implements per-currency commercial bank money tokens; fx-oracle publishes EUR/SAR mid prices signed by the liquidity provider; and a2a-router orchestrates the atomic delivery-versus-payment construct that ties a debit on one currency to a credit on the other. All three are written in Go against the contract-api-go v1 framework.

// cbm-token/contract.go — relevant excerpts

type TokenContract struct { contractapi.Contract }

type Account struct {
    Owner    string  `json:"owner"`     // MSP-id::CN
    Currency string  `json:"ccy"`       // "EUR" | "SAR"
    Balance  uint64  `json:"bal"`       // minor units
    Frozen   bool    `json:"frozen"`
}

func (t *TokenContract) Transfer(
    ctx contractapi.TransactionContextInterface,
    from, to, ccy string, amount uint64, ref string,
) error {

    // 1. caller must own the debit account
    caller, _ := cid.GetID(ctx.GetClientIdentity())
    if caller != from && !hasAttr(ctx, "treasury") {
        return errors.New("unauthorized debit")
    }

    // 2. travel-rule witness must be present in transient map
    tMap, _ := ctx.GetStub().GetTransient()
    trHash, ok := tMap["travel_rule_hash"]
    if !ok { return errors.New("missing travel-rule witness") }

    // 3. atomic debit/credit against world state
    src, _ := getAccount(ctx, from, ccy)
    dst, _ := getAccount(ctx, to,   ccy)
    if src.Frozen || dst.Frozen { return errors.New("frozen") }
    if src.Balance < amount   { return errors.New("insufficient") }
    src.Balance -= amount; dst.Balance += amount
    putAccount(ctx, src); putAccount(ctx, dst)

    // 4. emit event for off-chain payment hub
    ev := TransferEvent{From: from, To: to, Ccy: ccy, Amt: amount,
        Ref: ref, TRHash: hex.EncodeToString(trHash)}
    payload, _ := json.Marshal(ev)
    return ctx.GetStub().SetEvent("Transfer", payload)
}

The a2a-router chaincode composes a Transfer on the EUR token and a Transfer on the SAR token in a single proposal, both conditional on a fresh fx-oracle reading whose timestamp is within 90 seconds. Because Fabric processes each transaction atomically against the read-write set produced by endorsing peers, both legs either commit together or neither does — the multi-version concurrency control (MVCC) layer rejects the entire proposal if any read key has been written between simulation and commit.

Section 06

Token model: account-based vs. UTXO via the Fabric Token SDK

Fabric supports two practical token implementation patterns. The minimal account-based model keeps a single composite-key entry per (owner,ccy) pair in world state. It is simple and readable, but serializes all transfers from a given account, which becomes a contention bottleneck under load. For the corridor we use the Fabric Token SDK maintained by IBM Research, which implements a UTXO-style fungible token on top of Fabric.

Each EUR-CBM note is an unspent output bound to its owner's identity by a Pedersen commitment; transfers consume one or more notes and produce new ones. The SDK supports two drivers: fabtoken (plaintext, suitable for consortium settings where amounts may be visible inside the channel) and zkat (zero-knowledge based on Idemix and bulletproofs, hiding amounts and owner identities from non-participants). We deploy the fabtoken driver on the corridor channel because the consortium has agreed that bilateral amounts are visible to all three members in exchange for simpler audit. The zkat driver is reserved for future expansion where additional banks join and amount confidentiality becomes commercially necessary.

Section 07

Full transaction lifecycle — 16 steps end-to-end

A complete EUR→SAR cross-border payment from a Munich corporate client to a Riyadh beneficiary moves through 16 distinct steps across three Fabric organizations, the Raft ordering service, two RTGS systems, and two core banking integrations. The on-ledger portion completes in under one second under normal network conditions. Steps 15–16 involve off-ledger RTGS net settlement at end-of-day.

Section 08

Ordering and consensus: Raft today, SmartBFT tomorrow

The corridor uses the standard etcd/Raft ordering service that ships with Fabric 2.5. Raft is a crash-fault-tolerant protocol: with five orderer nodes, the cluster tolerates two simultaneous node failures and continues to make progress as long as three nodes remain reachable. It does not tolerate Byzantine behaviour — a malicious orderer could in principle withhold or reorder transactions within the batch timeout window, though it cannot forge endorsements or alter committed state.

To mitigate this, orderers are physically distributed across three bank-operated sites (Munich, Paris, Riyadh) and two technically independent operators (a Frankfurt colocation facility and a Bahrain regional data centre). No single jurisdiction or operator can unilaterally censor the channel. Orderer logs are mirrored to immutable WORM storage at each site for after-the-fact audit.

Fabric 3.x introduces a SmartBFT consensus plug-in (SBFT-CHS), which provides full Byzantine fault tolerance at the orderer layer. The consortium has agreed an upgrade path: once Fabric 3.x reaches IBM enterprise support GA and a six-month parallel-run window has been completed on a staging channel, the corridor will migrate to SmartBFT. In the interim, Raft is acceptable because the threat model assumes Byzantine endorsing peers, not Byzantine orderers — endorsement by the 2-of-3 bank policy is the cryptographic anchor.

Section 09

Embedding ISO 20022 pacs.008 in chaincode state

The corridor speaks ISO 20022 internally — both sides are migrating their cross-border traffic to the MX standard ahead of SWIFT's MT discontinuation milestones. The full pacs.008.001.10 message is written into the private data collection so that compliance and auditors at the originating and beneficiary banks can reconstruct the regulated payment context, while the public corridor ledger stores only the SHA-256 hash for integrity-witnessing.

<!-- pacs.008.001.10 — abbreviated -->
<FIToFICstmrCdtTrf>
  <GrpHdr>
    <MsgId>BHDLDE2M-20260421-887412</MsgId>
    <CreDtTm>2026-04-21T10:14:02.244+02:00</CreDtTm>
    <NbOfTxs>1</NbOfTxs>
    <SttlmInf><SttlmMtd>CLRG</SttlmMtd>
      <ClrSys><Prtry>FABRIC-EURSAR-CORRIDOR</Prtry></ClrSys>
    </SttlmInf>
  </GrpHdr>
  <CdtTrfTxInf>
    <PmtId><EndToEndId>PAY-IN-2026-04-21-887412</EndToEndId>
            <UETR>5e9c4e8a-2f1b-4b3a-9d0e-1c8f4a7b6d52</UETR></PmtId>
    <IntrBkSttlmAmt Ccy="EUR">4820000.00</IntrBkSttlmAmt>
    <ChrgBr>SHAR</ChrgBr>
    <Dbtr><Nm>Präzision Werkzeug GmbH</Nm>
          <PstlAdr><Ctry>DE</Ctry></PstlAdr></Dbtr>
    <DbtrAcct><Id><IBAN>DE89370400440532013000</IBAN></Id></DbtrAcct>
    <DbtrAgt><FinInstnId><BICFI>BHDLDE2M</BICFI></FinInstnId></DbtrAgt>
    <CdtrAgt><FinInstnId><BICFI>ALMDSARI</BICFI></FinInstnId></CdtrAgt>
    <Cdtr><Nm>Saudi Water Authority</Nm>
          <PstlAdr><Ctry>SA</Ctry></PstlAdr></Cdtr>
    <CdtrAcct><Id><Othr><Id>SA0380000000608010167519</Id></Othr></Id></CdtrAcct>
    <RmtInf><Ustrd>Desalination plant — milestone 3 of 7</Ustrd></RmtInf>
  </CdtTrfTxInf>
</FIToFICstmrCdtTrf>

The hub canonicalises the XML per W3C Canonical XML 1.1, hashes it with SHA-256, and that 32-byte hash is what the chaincode persists on the public ledger as the trHash field of the transfer event. Any subsequent dispute can be resolved by replaying the private data from either bank's PDC and re-canonicalising — a hash mismatch flags tampering.

Section 10

KYC, AML, sanctions, and the FATF Travel Rule

Each bank performs KYC and CDD on its own customer at onboarding under its home regime: BaFin GwG for Germany, ACPR/AMF for France, and SAMA AML/CFT Rules for Saudi Arabia. The corridor ledger does not store customer identity directly — identity remains in each bank's internal KYC vault. What the ledger guarantees is that an authenticated bank gateway, holding a valid MSP identity, has attested at the moment of submission that the underlying customer has been screened.

The FATF Travel Rule (Recommendation 16, transposed into the EU's Transfer of Funds Regulation 2023/1113 and the SAMA AML/CFT Rules Article 17) requires the originator's name, account, address, and identifier, plus the beneficiary's name and account, to travel with the payment. We satisfy this by storing the full pacs.008 in the bilateral private data collection between originator and beneficiary banks. The liquidity provider (Org2) sees only the public block and the hash — sufficient for nostro reconciliation without unnecessary exposure to the underlying parties' personal data.

Sanctions screening is performed by each bank's gateway against its own list (EU Consolidated List, OFAC SDN where applicable, UN Security Council list, SAMA's domestic list). The screening result is asserted in the transient map as a signed JSON Web Token whose subject is the customer's hashed identifier. The chaincode does not validate the JWT contents — that would require sharing keys across the consortium — but it rejects any transfer whose transient map lacks the witness, and the witness is preserved in the PDC for audit.

Section 11

Regulatory framing: European Union and the Kingdom of Saudi Arabia

The corridor operates across two distinct regulatory jurisdictions. The EU side is governed by the consolidated CRR/CRD framework plus the MiCA, DORA, and TFR regulations. The Saudi side is governed by SAMA's licensing and AML/CFT framework. Neither side currently mandates daily on-ledger reporting, but each bank's auditor identity has read-only access to the corridor channel and to the bank's bilateral PDC.

Section 12

Net settlement against TARGET2 and SARIE

On-ledger transfers move commercial bank money tokens: a liability of the issuing bank denominated in fiat. They are not final in the legal sense until the corresponding central-bank-money settlement has occurred between the banks. The corridor flattens this through end-of-day net settlement against TARGET2 for the EUR leg and SARIE for the SAR leg.

At 17:00 CET the netting chaincode produces a multilateral net position per currency per bank. For 21 April 2026, after netting all corridor flows:

EUR leg: Bayerische Handelsbank submits an MT 202 / pacs.009 to the TARGET2-Bundesbank component for credit to Banque Méridienne's TARGET2 PM account. Settlement is final on the books of the Eurosystem at 17:14 CET — a direct claim on the ECB itself, the highest-quality settlement asset available.

SAR leg: Banque Méridienne instructs its Riyadh nostro provider to settle through SARIE — the Saudi Arabian Riyal Interbank Express, operated by SAMA — for credit to Bank Al-Madinah's SAMA settlement account. Final at 18:14 AST (15:14 UTC).

Once SAMA and Bundesbank confirmations are received, each hub submits a Burn proposal to the corridor: the EUR-CBM and SAR-CBM tokens corresponding to the net amounts settled are removed from world state, restoring the per-bank token issuance to its net opening position. The cycle then begins again at 17:00:01 CET.

Section 13

Operational risks and what we have done about them

Any production deployment of a permissioned Fabric corridor in a regulated cross-border context faces a set of well-understood technical and governance risks. The following are the six most material risks for this architecture, together with their mitigations.

References

References, standards, and further reading