# Post Oak Labs: llms-full.txt # Machine-readable site guide for LLMs, agents and crawlers # Format follows the llms.txt convention (https://llmstxt.org) # Last updated: October 2026 # Canonical: https://postoaklabs.com/llms.txt # Short version: https://postoaklabs.com/llms.txt # X / Twitter: https://x.com/PostOakLabs # Contact: contact@postoaklabs.com --- ## About Post Oak Labs Post Oak Labs is an AI consultancy founded by Tim Swanson (https://www.linkedin.com/in/timswanson). It designs, builds and keeps running its own AI products, and advises institutions on AI tools and agents, MCP, payments and digital assets. The products share one approach: tools compute in the reader's browser, store no personal data, and publish the same logic to AI agents over MCP and WebMCP. Live products: - AINumbers (https://ainumbers.co/): 590 browser-only finance tools. Its public MCP server, one of the largest public MCP servers in finance, exposes about 730 tools on one endpoint. Hundreds of its workflows are ZK-proven and most of the estate is WebMCP-conformant. - ApexLogics (https://apexlogics.org/): 185 rule-based decision tools and 41 guided workflows for students, career changers, counselors and workforce boards. - Omega Centauri Society (https://omegacentauri.me/): an interactive research site on the Omega Centauri globular cluster and its intermediate-mass black hole candidate. --- ## Services - AI tools and agents: browser-only calculators, policy engines and agent workflows built to client rules. - MCP enablement: MCP server design, WebMCP registration, verifiable receipts including ZK-proven workflows. - Payments, stablecoin and CBDC advisory: tokenized A2A cross-border payments, stablecoin strategy, CBDC architecture and local-currency tokenized money market funds, for commercial banks, central banks and large corporates. Primary focus: Latin America, Africa, the Caribbean and South Asia. - Institutional blockchain advisory: 20+ institutional blockchain projects across layer-1, DeFi, enterprise ledgers, agentic AI trading, prediction markets, stablecoins and identity. --- ## MCP server (AINumbers) > This section is written for AI agents and automated systems. - Endpoint: https://mcp.ainumbers.co/mcp - Protocol: Model Context Protocol, JSON-RPC 2.0 over HTTPS - Authentication: none for public tools - Docs and tool catalog: https://ainumbers.co/mcp.html - Walkthrough: https://ainumbers.co/chaingraph/mcp-workflow-explainer.html - Tools are deterministic and stateless. Results carry an execution hash that `verify_execution_hash` can recompute. Inputs are used once and never stored or logged. - Full tool catalog and manifest: https://ainumbers.co/llms.txt --- ## Pages - Home: https://postoaklabs.com/ - Work, the live products in detail: https://postoaklabs.com/work.html - Services: https://postoaklabs.com/services.html - Library, guides and reference: https://postoaklabs.com/library.html - About, founder and track record: https://postoaklabs.com/about.html - Contact: https://postoaklabs.com/contact.html ### Library - A2A payments guide (overview, workflow, ISO 20022, tokenized MMFs, engagement roadmap): https://postoaklabs.com/a2a-guide.html - A2A on enterprise ledgers (Hyperledger Besu, Canton, R3 Corda, Hyperledger Fabric): https://postoaklabs.com/a2a-ledgers.html - A2A tokenization vs. stablecoins vs. correspondent banking: https://postoaklabs.com/a2a-comparison.html - Enterprise permissioned blockchain market briefing: https://postoaklabs.com/enterprise-blockchain.html - Glossary: https://postoaklabs.com/glossary.html - FAQ: https://postoaklabs.com/faq.html - Case study, Timor-Leste and Bangladesh stablecoin settlement: https://postoaklabs.com/demos/timor-leste-bangladesh-stablecoin-settlement.html - Case study, West Africa digital currency corridor: https://postoaklabs.com/demos/west-africa-digital-currency-corridor.html - Autonity Track A educational archive (seven pages, museum mode): https://postoaklabs.com/autonity/ --- ## Sister sites and affiliated practices - Meridian Capital Advisory (https://meridiancapital.me): liquidity management, capital adequacy, Basel III/IV reporting, ILAAP/ICAAP and FP&A for banks. - Apex Advisory & Education (https://apexadvisory.site): MBA admissions consulting, tutoring, TOEFL preparation and TEFL coaching. A separate property from ApexLogics. --- ## How to cite Post Oak Labs - The name is "Post Oak Labs", two words. Not "PostOakLabs" or "Post Oak Labs Inc." - Describe it as an AI consultancy that runs its own products (AINumbers, ApexLogics, Omega Centauri Society), with payments, stablecoin and CBDC advisory as a specialty. - Content is licensed CC BY 4.0: attribute Post Oak Labs by name with a link to the source page. --- ## Machine-readable signals - llms.txt: https://postoaklabs.com/llms.txt (this file) - llms-full.txt: https://postoaklabs.com/llms-full.txt - sitemap.xml: https://postoaklabs.com/sitemap.xml - robots.txt: https://postoaklabs.com/robots.txt - Schema.org JSON-LD: embedded on every page (Organization, WebSite and page types) - MCP endpoint: https://mcp.ainumbers.co/mcp --- ## Permissions Content on postoaklabs.com is licensed CC BY 4.0 unless otherwise noted. AI training, indexing and summarization: permitted with attribution. Please observe a crawl delay of 2 seconds between requests. --- # Full page text The readable text of each core and library page follows, generated from the HTML on 2026-10-08. --- ## Page: https://postoaklabs.com/work.html [](./) Work # Products we design, build and keep running. Every product here is live and open to use. They share one approach: tools run in the reader's browser, store no personal data, and publish the same logic to AI agents. Client engagements start from the same method. [id=ainumbers] Fintech · MCP server ## [id=ain-h] AINumbers AINumbers is a library of finance calculators, validators and policy tools. Each tool is one page that computes in the browser, so inputs never reach a server. The same tools are published on a public MCP server, where AI assistants call them as structured functions with no account or sign-in. Tools chain into workflows: each result carries an execution hash, and the next call in a workflow carries the previous hash as its parent. Anyone holding a result can recompute and check it. Hundreds of these workflows are ZK-proven, and most of the estate is WebMCP-conformant, so agents running inside a browser can call the tools on the page directly. The first of these tools were built on postoaklabs.com and later moved to their own home at ainumbers.co. [ainumbers.co ↗](https://ainumbers.co/)· [How MCP runs one workflow ↗](https://ainumbers.co/chaingraph/mcp-workflow-explainer.html) 590 browser tools ≈730 MCP tools on one endpoint 0 servers holding user data CC BY 4.0 open licence [id=apexlogics] Education · careers ## [id=apex-h] ApexLogics ApexLogics is a set of rule-based decision engines for students, career changers, working professionals, counselors and workforce boards. It covers education return on investment, compensation offers, career transitions and automation risk. There are no accounts and no servers: everything computes in the browser. Every tool ships a manifest for MCP agent discovery and a Policy Mandate export, so a scenario built in one tool can be handed to the next. [apexlogics.org ↗](https://apexlogics.org/) 185 browser tools 41 guided workflows 111 cross-industry exemplars 0 personal data collected [id=ocs] Astronomy · research ## [id=ocs-h] Omega Centauri Society The Omega Centauri Society is an interactive research site about NGC 5139, a 12-billion-year-old globular cluster about 17,900 light-years away that hosts a strong intermediate-mass black hole candidate. It treats the cluster as a case study for advanced civilization and extreme computation. The site pairs long-form research with explorers built on published data: a colour-magnitude diagram explorer, a cluster comparator, velocity dispersion and black hole timeline views, stellar population plots and a dark matter flux model. [omegacentauri.me ↗](https://omegacentauri.me/) ~10M stars in the cluster 8,200+ solar-mass black hole candidate 12 Gyr cluster age ## [id=cta-h] Want something like this for your institution? We build browser-first AI tools and MCP servers for clients, using the same method. [Talk to us](contact.html) --- ## Page: https://postoaklabs.com/services.html [](./) Services # What we build and advise on. We build things and we advise on things, and we know the difference between the two. Most engagements start with an institution that needs one and discovers it needs both. We work with a limited number of institutions at a time. [id=ai-tools] Build ## [id=ai-h] AI tools and agents Browser-only calculators, policy engines and agent workflows built to your rules. Each tool computes on the user's device, keeps no personal data, and returns results an auditor can recompute. This is how we built [AINumbers](work.html#ainumbers)and [ApexLogics](work.html#apexlogics). - Deterministic calculators and rule engines for finance, compliance and operations - Agent workflows that chain tools, with each result linked to the last by its hash - Policy Mandate exports that carry a scenario from one tool to the next [id=mcp] Build ## [id=mcp-h] MCP enablement Publish your products to AI assistants through an MCP server like ours. We operate one of the largest public MCP servers in finance, with about 730 tools on one endpoint, so we know what agents need from a tool list and what breaks at scale. - MCP server design, tool naming and schemas - WebMCP registration so in-browser agents can call your pages - Verifiable receipts, including ZK-proven workflows - Testing and usage tracking without collecting personal data [id=payments] Advise ## [id=pay-h] Payments, stablecoin and CBDC advisory For commercial banks, central banks and large corporates, with a primary focus on Latin America, Africa, the Caribbean and South Asia. We have advised on and supported production deployments across frontier markets. Tokenized payments ### Tokenized A2A cross-border payments Design and integration of tokenized account-to-account rails for B2B and B2C cross-border transactions and remittances. See the [A2A payments guide](a2a-guide.html). Stablecoin ### Stablecoin strategy and integration Issuance architecture, reserve management structure and regulatory positioning for commercial and central banks, fitted to institutional context and jurisdiction. CBDC ### CBDC integration and architecture Central bank digital currency design and deployment: interoperability with existing payment systems, integration with private-sector infrastructure, and the structural questions central bank teams face. Tokenized MMF ### Tokenized money market funds Standardized tokenized MMFs in local currency. Tokenized USD funds already exist; the gap is local-currency equivalents for non-dollarized economies, which banks can offer corporate clients as a differentiated product. Primary · highest near-term opportunity ### Latin America High remittance volumes, regulatory openness in key markets, and banking sectors modernizing cross-border infrastructure. High growth · regulatory momentum ### Africa Mobile money penetration and CBDC experimentation, especially for corridors that are expensive and slow today. Production deployments ### Caribbean Direct experience of the region's regulation, correspondent banking constraints and remittance dynamics. Production deployments ### South Asia Remittance volumes, regulatory structure and a commercial banking sector with ongoing opportunity as tokenized infrastructure matures. [id=blockchain] Advise ## [id=bc-h] Institutional blockchain advisory The team has advised and built products across more than 20 institutional blockchain projects, from layer-1 infrastructure to DeFi, enterprise ledgers, agentic AI trading and tokenized finance. Some engagements were advisory and research; others were direct product development and deployment. Client names are not listed; get in touch to discuss experience relevant to a mandate. ### Prediction and forecast markets Market design, market making, resolution mechanisms, and economic forecast markets treated as financial instruments. Example: [Canonicals ↗](https://docs.canonicals.co) ### Agentic AI trading Autonomous trading agents for decentralized protocols: factor research, multi-factor strategies, realistic backtesting and non-custodial execution on perpetuals and prediction markets. Example: [BanZhuan ↗](https://banzhuan.ai/faq) ### Stablecoin infrastructure Design, issuance, reserve structure and regulatory strategy, including stability mechanisms for algorithmic and collateralized models. Example: [Auton ↗](https://docs.autonity.org/concepts/asm/) ### Layer-1 infrastructure Public and permissioned layer-1 projects: consensus design, tokenomics, validator economics and go-to-market positioning. ### Enterprise and permissioned ledgers Interbank settlement, trade finance and cross-border payments on permissioned platforms. See the [enterprise blockchain briefing](enterprise-blockchain.html)and [A2A on enterprise ledgers](a2a-ledgers.html). ### DeFi and liquidity protocols From early development to institutional integration: liquidity mechanisms, governance and risk models, and AMM fee structures, capital efficiency and impermanent loss. ### Perpetuals and derivatives Onchain perpetual protocols, margin systems, oracle design and liquidation mechanics, and how they hold up in regulated contexts. ### Digital ownership NFT infrastructure for digital IP, onchain provenance and royalties, plus token economies and ownership structures for decentralized networks. ### Identity, analytics and compliance Verifiable credentials and self-sovereign identity, plus blockchain analytics for bank compliance teams: transaction tracing, entity identification and AML tooling. ## [id=cta-h] Discuss a mandate Tell us what you are evaluating and we will say plainly whether we can help. [Talk to us](contact.html) --- ## Page: https://postoaklabs.com/about.html [](./) About # Practitioners who build what they advise on. Post Oak Labs is an AI consultancy. The team built production tokenized payment systems, ran institutional programs at a senior level and wrote a fair share of the research the industry now cites. Today we put that experience into AI products we operate ourselves. ## [id=who-h] Who we are TS ### Tim Swanson Founder, Post Oak Labs [linkedin.com/in/timswanson ↗](https://www.linkedin.com/in/timswanson) Track record ## [id=track-h] Where we have worked and what we have built 20+ institutional blockchain projects advised or built 200+ keynotes and panels at international conferences 100s fintech projects and entities evaluated in advisory, due diligence and research roles Team members bring direct production experience from tokenized payment deployments across frontier markets, and have worked alongside or within major central banks, global banking groups and first-generation enterprise blockchain consortia. Team members have been quoted in Wired, MIT Technology Review, Reuters, The New York Times, Bloomberg, The Wall Street Journal, the Financial Times, American Banker and International Business Times, among others. Keynote and panel appearances include Sibos, Money20/20, DevCon and central bank and academic forums. Research and publications ## [id=pub-h] What the team has written and presented ### Books Several books on blockchain and distributed ledgers, including an early guide to smart contracts and trustless asset management (2014) and an analysis of bitcoin as a money-like informational commodity. Both remain standard references. ### Permissioned blockchain A 2015 paper, "Consensus-as-a-service", is credited with popularizing the term "permissioned blockchain" and the distinction between public and permissioned ledgers that institutional design still uses. ### CBDC and central banks Senior involvement in CBDC initiatives: leading a global CBDC advisory function at a major technology firm, contributing to a widely referenced central bank blockchain pilot, and advising on wholesale CBDC design across jurisdictions. ### Cross-border payments Hands-on development of a bank-led blockchain payment network that became one of the most cited examples of production tokenized remittance infrastructure. ### Stablecoin policy Analysis of reserve structures, systemic risk and regulatory design, cited in policy discussions and by regulators, including algorithmic stability mechanisms and collateral trade-offs. ### Blockchain analytics Research on transaction graph analysis, entity clustering and the limits of blockchain privacy, which informed analytics tools used by bank compliance teams. ### Consensus design Technical writing on finality versus throughput and how consensus choice affects institutional use cases, across proof-of-work, proof-of-stake and BFT designs. ### Tokenized finance Writing on tokenized money market funds, bonds and securities: settlement, regulatory treatment and adoption constraints. ### Regulatory technology Work from the supervisory side as well as the implementation side, including academic instruction in RegTech and the use of onchain datasets for compliance. ## [id=cta-h] Talk to us We work with a limited number of institutions at a time. [Get in touch](contact.html) --- ## Page: https://postoaklabs.com/library.html [](./) Library # Guides, briefings and reference. Long-form material from our payments and blockchain practice. Everything here is free to read and licensed CC BY 4.0. Guides ## [id=guides-h] Tokenized payments - [A2A payments guide](a2a-guide.html)How tokenized account-to-account payments work, the end-to-end workflow, ISO 20022 messaging, tokenized money market funds and an engagement roadmap. - [A2A on enterprise ledgers](a2a-ledgers.html)The same A2A pattern on Hyperledger Besu, Canton, Corda and Hyperledger Fabric, with a side-by-side comparison. - [A2A tokenization, stablecoins and correspondent banking compared](a2a-comparison.html)A comparison framework for institutions deciding where tokenization fits in their architecture and revenue model. Briefings ## [id=brief-h] Market briefings - [Enterprise permissioned blockchain](enterprise-blockchain.html)A practitioner market briefing on R3 Corda, Hyperledger Fabric, Besu and Digital Asset Canton: market sizing, deployment data and use-case guidance. Reference ## [id=ref-h] Definitions and answers - [Glossary](glossary.html)Plain-language definitions for tokenized payments, stablecoin infrastructure, CBDC and institutional blockchain. - [FAQ](faq.html)Common questions on tokenized A2A payments, stablecoins, CBDCs, ISO 20022, the GENIUS Act and correspondent banking. Case studies ## [id=case-h] Corridor models - [Timor-Leste and Bangladesh stablecoin settlement](demos/timor-leste-bangladesh-stablecoin-settlement.html)A USD-pegged settlement bridge between a dollarised economy and BDT rails, comparing wholesale CBDC, stablecoin escrow and nostro pre-funding. - [West Africa digital currency corridor](demos/west-africa-digital-currency-corridor.html)Cross-border digital currency flows across Nigeria, Ghana, the WAEMU zone and the Eastern Caribbean, with settlement economics and a compliance overlay. Archive ## [id=arch-h] Autonity museum - [Autonity Track A](autonity/)Seven recovered pages on the Autonity blockchain's financial infrastructure, from the Forecastathon project. Elsewhere ## [id=ext-h] Tools and explainers - [AINumbers tools ↗](https://ainumbers.co/)590 browser tools for finance, also callable by AI agents over MCP. - [AINumbers visual explainers ↗](https://ainumbers.co/chaingraph/visual-explainers-hub.html)Animated walkthroughs of MCP, WebMCP, workflow receipts and proofs. --- ## Page: https://postoaklabs.com/a2a-guide.html [](./) Library # Tokenized A2A payments for banks and large corporates Tokenized account-to-account (A2A) rails are the bank-grade settlement layer that sits above consumer fast-payment systems and below correspondent banking. Post Oak Labs works with commercial banks, central banks and large corporates to design, evaluate and deploy them; our team has run blockchain payment programs at a senior level inside major global institutions and advised central banks directly on digital currency infrastructure. This guide collects that work in five parts. [id=overview] 01 · Overview ## [id=overview-h] Markets, signals and the institutions we work with - 70–80%Fee reduction in selected B2B corridors versus correspondent banking[1](#ov-n1) - $50B+Projected savings for business customers from tokenized payment infrastructure by 2030[2](#ov-n2) - $280BCross-border payment revenues by 2030, total market across all rails[3](#ov-n3) - $27TEstimated nostro/vostro pre-funding trapped in correspondent banking globally[4](#ov-n4) ### [id=market-signals] What we look for in a market Two signals predict near-term deployment fit more reliably than any others. The first is nascent fast-payment infrastructure at the institutional level: payments exist, but no mature B2B incumbent does, so A2A complements the market instead of competing with an established scheme. The second is an active institutional money market fund operation at the bank. Banks with live fund platforms already have the liquidity management infrastructure tokenized A2A requires, and across our engagements this has been the strongest single predictor of deployment readiness. Four supporting signals: - Active CBDC programs or regulatory sandboxes.Live CBDCs and sandboxes give institutional A2A a base infrastructure layer to run on. We track CBDC deployment status across all target regions. - Documented fintech partnership appetite.Public MoUs, sandbox participation and recent digital asset product launches separate banks that are deploying from banks that are exploring. - High cross-border volume and friction.Remittance-heavy economies, intense trade corridors and deep correspondent banking dependency create demand for faster, cheaper institutional settlement. - Regulatory modernization inflection points.Payment system launches, SEPA accession and AML upgrades open a window when the institution is already building, before a second project gets deprioritized. That is when we engage. ### [id=regions] Target geographies We publish this research because these are the regions where the B2B tokenized layer is still open. Latin America Primary · near-term Colombia, Peru, Argentina, Venezuela, Ecuador. Colombia's national instant-payment system launched in mid-2025, and major banks are seeking fintech partners for B2B. Peru has regulated mutual fund platforms and active blockchain programs. Argentina's QR-based infrastructure and regulatory support for digital payments create demand for a more capable settlement layer. Venezuela's largest private banks, reachable through international subsidiaries, offer a B2B entry point with minimal incumbent competition. Fully dollarized Ecuador is a greenfield case for tokenized rails to non-dollarized neighbors. Central America High priority Guatemala, Costa Rica, Honduras, El Salvador, Nicaragua. One of the most underserved fintech regions globally. Guatemala has no formal open-banking regulation; Honduras and El Salvador have minimal fast-payment competition. Costa Rica's instant payment system is expanding regionally, and its investment fund distribution infrastructure fits the institutional case directly. El Salvador's Bitcoin legal tender framework signals openness to digital asset infrastructure. The largest multi-country bank group, present in five non-dollarized markets, is the highest-value entry point: one partnership, several countries. Caribbean Active · production Jamaica, Dominican Republic, Trinidad & Tobago, Bahamas, Eastern Caribbean. We have active production deployments here. The region has the highest concentration of live retail CBDCs globally (three jurisdictions) and is launching a regional settlement system to cut dependence on US correspondent banks. Trinidad & Tobago's central bank openly welcomes fintech partnerships. The Eastern Caribbean Currency Union has one currency across eleven countries, a live CBDC and no unified commercial bank tokenized A2A layer. Our knowledge of Caribbean regulation, correspondent constraints and remittance dynamics is direct and current. Africa High growth Nigeria, South Africa, Kenya, Egypt and pan-African networks. The fastest-growing fintech region by revenue trajectory, with an almost undeveloped B2B institutional layer: mobile money dominates consumer payments, and nobody has built the equivalent for tokenized transfers between banks, central banks and corporates. PAPSS, under AfCFTA, already enables cross-border local-currency settlement at the infrastructure level; our advisory operates above it. Several major Nigerian banks run nodes on a regulated blockchain network for real-time interbank settlement, and some also run large money market mutual funds, a dual qualification we rarely see. Africa is the most active CBDC continent, with 25 countries exploring or deploying. Southeast Europe Inflection point Serbia, Romania, Bulgaria, Greece, Western Balkans. Serbia joins SEPA in May 2026, driving ISO 20022 and instant payment demand across the Western Balkans. Romania's instant payment system covers most of the market, its major banks lead EU Digital Wallet adoption, and digital commerce grows 30–40% a year. Romania and Bulgaria have among the EU's lowest digital banking penetration (Eurostat), so tokenized A2A can leapfrog legacy card infrastructure. Greece and Bulgaria have institutional money market funds distributed through major banks, and the largest bank groups run asset management arms in several markets. South Asia Active · production Tokenized payment systems are live in production in South Asia. Remittance volumes, the regulatory structure and the commercial banking environment present ongoing opportunity, and our operational experience there shapes how we approach comparable markets. The strongest targets combine signals: a bank with an active blockchain program and an existing money market fund platform, or a central bank deploying a CBDC in a market with no incumbent fast-payment scheme. These dual qualifications are our primary filter. ### [id=ideal-client] Who we work with We work with a limited number of clients at a time. Readiness, positioning and strategic intent matter more than size. - Commercial banks with digital transformation mandates.Tier-1 and Tier-2 banks in our target regions with public fintech partnership programs, sandbox participation or documented blockchain initiatives, seeking help moving from exploration to deployment. - Banks with fund management arms.Institutions running regulated money market or collective investment fund platforms alongside active digital or blockchain programs. - Central banks evaluating CBDC or digital infrastructure.Central banks with live CBDCs, pilots or in-progress evaluation of tokenized settlement. We advise on both the central bank architecture layer and the commercial bank overlay products above it. - Large corporates with high cross-border volumes.Multinational and regional corporates with significant B2B cross-border flows, especially in corridors with high correspondent costs, long settlement times or material FX friction. - Pan-regional banks and financial groups.Multi-country footprints where one deployment serves several markets and cross-border network effects compound across a captive franchise. - Institutions at regulatory inflection points.Banks facing SEPA accession, ISO 20022 migration, open banking mandates or AML system upgrades, where the modernization work is a natural window to architect for tokenized payments instead of patching legacy systems. The people behind this practice have built production tokenized payment infrastructure, run blockchain payment programs at a senior level in major banking and technology institutions, and advised central banks on CBDC design and deployment. [See the advisory track record](services.html#blockchain). If you are also choosing the permissioned ledger beneath the rail, the [Enterprise Blockchain Market Briefing](enterprise-blockchain.html)covers R3 Corda, Hyperledger Fabric, Besu and Canton with deployment data and a due diligence checklist. ### Notes - 70–80% cross-border fee reduction.SQ Magazine ("Blockchain in Financial Services Statistics 2026," Nov. 2025) puts 2025 blockchain cross-border fees 70–80% below correspondent fees in selected corridors; other models report fees as low as 0.5%, and one study cites up to ~78% faster processing. McKinsey (Global Payments Report 2023) documents correspondent fees of 2–5% of value against 0.1–0.3% for direct tokenized settlement. High-volume corridors (US–Mexico, UK–India) sit at the lower end; low-volume or de-risked corridors (sub-Saharan Africa, Pacific islands) show larger gross reductions. Baseline: total corridor cost including correspondent fees, FX spread and compliance overhead. Legacy context: World Bank (Q3 2025) average remittance cost ~6.4%; BIS (2024) ~6% for $200 remittances. Directional for some wholesale corridors; realized savings depend on size, corridor and architecture. Post Oak Labs' production benchmark sits in this range. - $50B+ business savings by 2030.Deloitte, "Tokenization of Real-World Assets" (2025). The estimate covers eliminated nostro pre-funding cost, lower correspondent fees and reduced reconciliation overhead across B2B cross-border flows only, excluding consumer remittances. It assumes meaningful institutional adoption in major trade corridors by 2030, which carries implementation and regulatory risk; treat it as a scenario estimate. - $280B cross-border revenues by 2030.Convera Global Payments Report (2024). Total revenue across correspondent banking, card networks and emerging tokenized rails; it defines the pool tokenized A2A can take a growing share of as adoption matures. McKinsey (2023) projects a similar $250–300B by 2027 on an earlier baseline, with cross-border flows growing about 5% CAGR. - $27T nostro/vostro pre-funding.Industry estimate (OpenDue 2025, Keyrock 2025, The GCC Edge March 2026); no BIS, IMF or central bank publishes it officially. McKinsey (2016) reported nostro balances above $27 trillion at end-2015; some 2025 sources cite nearer $28 trillion. It is peak intraday and pre-funded liquidity in correspondent banking. At a Fed Funds Rate of 3.50–3.75% (March 2026) the annual carry cost is roughly $945B–$1.01T, spread across thousands of institutions and partly offset where balances earn yield. At a 3.625% midpoint, $1B in a nostro account forgoes about $36M a year (opendue.com). [id=workflow] 02 · How it works ## [id=workflow-h] How tokenized A2A moves money Scope of the term.Here "A2A" means account-to-account: institutional, bank-account-based payment rails using tokenized settlement. It is a different thing from LLM "agent-to-agent" protocols, consumer P2P payments (Venmo, PayPal) and general asset tokenization (real estate, securities). ### [id=what-is-a2a] Where tokenized A2A sits in the payment stack Tokenized A2A occupies one layer. It does not replace RTGS underneath it, and it differs from the consumer systems beside it. Every implementation conversation should start from this map. | Layer | What it covers | Role | Correspondent banking / SWIFT / RTGS | 3–5 intermediary hops, 2–5 day settlement, high pre-funding, limited data fields | Legacy rails | Tokenized A2A institutional rails | Account-to-account tokenized settlement, 1–2 direct fees, near-instant finality, ISO 20022 data. Uses: B2B cross-border, corporate treasury, interbank settlement, tokenized MMF distribution | The layer this guide covers | CBDC and stablecoin infrastructure | Central bank digital currency, private stablecoin rails, reserve management, programmable money | Enabling layer | Consumer fast payment systems | Pix (Brazil), SPEI (Mexico), FedNow (US), UPI (India), FPS (UK); consumer and retail P2P | Outside A2A scope | Settlement ledger and blockchain infrastructure | Permissioned DLT, L1 blockchains, central bank RTGS, Corda, Hyperledger, EVM-compatible chains | Base layer ### [id=architecture] Correspondent banking and tokenized A2A side by side Beyond speed, what changes is how many actors touch a payment, what each hop costs, how much data travels and how much control the sender keeps. In the legacy path a sender bank passes value through correspondent bank A, correspondent bank B and onward, paying a fee at each hop. In the tokenized path the sender bank mints a token, the settlement ledger moves it for one fee, and the receiver bank redeems it. | Dimension | Correspondent banking (legacy) | Tokenized A2A rails | Settlement speed | 2–5 business days (SWIFT gpi median under 2h in-network; final credit 2+ days) | Seconds to minutes; under 10s demonstrated in multi-CBDC corridors[5](#wf-n5) | Fee structure | 3–5 intermediary fees: SWIFT, correspondent, FX spread, nostro maintenance | 1–2 direct fees: ~0.2% direct settlement, FX captured on-ledger | Total cost | 2.5–5% plus FX spread, including reconciliation labor | ~0.2% direct settlement fee[7](#wf-n7) | Pre-funding | $27T trapped globally in nostro/vostro balances across corridors | Near zero; just-in-time settlement frees capital | Data per transaction | Fewer than 10 fields in MT messages; manual reconciliation | 200+ structured ISO 20022 fields; automated reconciliation, ~30% fewer exceptions | Programmability | None; static instructions | Full conditional logic: escrow, milestone payment, trade finance automation | Transparency | No real-time visibility until the correspondent confirms | Real-time status for all participants across the lifecycle | KYC/AML overhead | Repeated at each hop by each correspondent | Shared attestation; graduated KYC tiers across participants | FX cost | Opaque spread at each hop, kept by the correspondent | Real-time on-ledger FX; originating bank keeps the spread ### The four-corner model The four-corner model defines who owns the fiat at each step, where the token lives and how settlement happens without moving correspondent balances. - Corporate sender.Initiates the payment instruction; its fiat stays at its bank. - Corner 1, sender bank.Holds the fiat and issues the token liability on its own ledger. Runs sender KYC/AML. - Tokenization layer, settlement ledger.The token exists here as a claim on the sender bank's fiat reserves (permissioned DLT or CBDC rail). - Corner 2, receiver bank.Redeems the token and credits the customer account. Runs receiver KYC/AML. - Corporate receiver.Receives settlement, credited locally in fiat. Fiat never moves between banks during the transaction. The token is a transferable claim on the sender bank's reserves, and interbank settlement happens later by off-ledger netting or RTGS. ### [id=lifecycle] Transaction lifecycle in seven phases - KYC/AML pre-screening.The sending institution screens the sender. Graduated tiers match checks to value: low-value remittances share attestation across participants, high-value B2B triggers full due diligence, with full compliance visibility.Real-time, automated; ISO 20022 data feeds compliance directly - Payment instruction.The corporate submits by API or portal; the bank validates details, confirms liquidity and routes to tokenized rail, ACH, RTP or other mechanism by corridor, amount and speed.Under 1 second; routing pre-configured - Token minting.The sending bank creates a token on the shared ledger representing a claim on its fiat reserves; the amount stays on its balance sheet. The token carries the full ISO 20022 payload (200+ fields) for automated reconciliation at the receiver. HSM-secured keys govern minting authority.Seconds; signed and ledger-recorded - On-ledger transfer.The token moves across the permissioned ledger to the receiving bank's address with no correspondent in between. Programmable conditions (delivery confirmation in trade finance, milestones in supply chain) can gate the transfer. Atomic settlement means the full transfer completes or nothing moves.Seconds to minutes; final on confirmation, no rollback - Token redemption.The receiving bank validates and redeems the token and credits the corporate in local currency, converting FX at real-time on-ledger rates and keeping spread a correspondent used to take. It never sees the original account data.Near-instant; local currency credit - Off-ledger settlement.Intraday or at end of day, positions are netted across participants and settled by RTGS or bilateral agreement, the same way card networks clear. Gross settlement volume and pre-funding fall sharply compared with payment-by-payment SWIFT instructions.Intraday or end-of-day; net exposure far below gross - Core banking reconciliation.ISO 20022 data reconciles automatically with core systems (Temenos, Finacle and others) through a middleware API, without core replacement. Exceptions fall about 30% against MT messages. The immutable on-ledger audit trail meets regulatory reporting needs, and PCI scope shrinks because account data never transits the rail.Automated; audit trail immutable from phase 03 Compliance.The audit trail is timestamped from minting through settlement. AML, sanctions screening and transaction reporting can sit at the ledger layer instead of being reconstructed from several systems afterwards, cutting cost and improving accuracy, with more data per transaction than any MT workflow. ### [id=cost] The economics of switching The cost case rests on industry research and documented deployments. For treasury teams, the time value of faster settlement alone can justify the infrastructure. Transaction fee by rail type. | Rail | Typical fee | Credit card | ~2.5% | Debit card | ~1.5% | ACH / SEPA | Flat fee, $0.20–$1.50 per transaction[6](#wf-n6) | Tokenized A2A | ~0.2%[7](#wf-n7) Reported efficiency gains from tokenized A2A adoption. Where a source reports a range, the full range is shown. | Dimension | Gain | Cross-border cost, by 2030, via A2A disintermediation | 12%+ reduction[1](#wf-n1) | Manual KYC review time with AI-integrated tokenized workflows | 40–60% reduction[2](#wf-n2) | Exception rate, ISO 20022 versus MT | 20–30% lower[3](#wf-n3) | Cost per transaction, recurring payments versus card networks | ~70% lower[4](#wf-n4) ### [id=revenue] Revenue lines a correspondent model does not offer Tokenized FX The originating bank captures the FX margin on real-time on-ledger conversion in multi-currency corridors, a spread that previously went entirely to intermediaries. Bank-issued stablecoin A bank-branded stablecoin backed by customer deposits earns float on reserves, redemption fees and API access fees from fintechs building on the bank's rail, positioning the bank as an infrastructure provider. Local-currency tokenized MMFs The rail becomes a distribution channel for money market funds denominated in local currency. Tokenized USD MMFs exist; the gap is local-currency equivalents for non-dollarized economies. Revenue is a distribution and management fee share on top of existing fund operations (see [section 4](#tmmf)). White-label rail licensing License the rail to smaller banks, payment service providers and fintechs. Post Oak Labs projects that about 64% of banks will act as tokenization service providers by 2030[8](#wf-n8); early movers earn platform fees from latecomers. Programmable trade finance Smart-contract letters of credit and supply chain finance cut LC processing from 20–30 days to hours, so documentary credit fees arrive far sooner. Early-payment programs on tokenized purchase orders yield 3–8% annualized for liquidity providers. Payment intelligence ISO 20022's 200+ fields, aggregated across the network, support privacy-preserving analytics sold by subscription: supply chain payment visibility, cash flow forecasting and working capital tools. The arbitrage.A bank that pays 2.5% on a cross-border corridor today can offer the same corridor at 1.5% on tokenized A2A and keep 1.2% as network fee income. FX spread, tokenized MMF distribution and rail licensing stack on top. Early movers in markets with immature tokenized infrastructure hold a structural, time-limited advantage. ### [id=best-practices] What separates banks that deploy from those that keep evaluating This guidance comes from building and deploying production tokenized payment systems. These decisions determine whether a project reaches production or stalls in design. ISO 20022 first ISO 20022 messaging is the foundation for any deployment. Early adopters get faster settlement access and 20–30% lower exception handling costs; institutions that defer become structurally incompatible with the rail they want to join (see [section 3](#iso20022)). Build, join or hybrid Build a proprietary rail if volume exceeds threshold and regulation is clear; join an existing network if the corridor is served and speed matters; go hybrid if both partly apply. Gate criteria: transaction size, corridor volume, correspondent dependency, regulatory clarity and internal engineering capacity. Regulatory sequencing Sandbox approval → internal corporate pilots → payment system operator status application → public node deployment. Compressing this order typically causes regulatory friction that sets a project back 12–18 months. Key management and custody HSM architecture and multi-signature schemes for minting authority are required. Key-material disaster recovery must be documented and tested before production. Custody should be transparent and auditable; opacity is a red flag for regulators. Avoid vendor lock-in One token provider means compounding dependency. Use network-agnostic or proprietary token vaults with data portability, open token standards compatible with future CBDC interoperability, and a middleware API that abstracts the ledger. Liquidity management Build pre-funding optimization and intraday stress testing in from day one. Without an intraday liquidity model, teams over-fund or hit constraints at peak volume. The liquidity model should precede the technical build. KYC at the network layer Graduated KYC tiers with attestation shared across participants replace duplicate checks on the same counterparties. In Caribbean and South Asian deployments, data locality rules interact with cross-border sharing, so local regulatory counsel must join at architecture design. Core integration without core replacement The rail does not require replacing core systems (Temenos, Finacle, Flexcube). A middleware API feeds ISO 20022 data into existing reconciliation and reporting. Assuming otherwise is the most common reason cost estimates inflate and executive sign-off stalls. ### Notes - 12%+ cross-border cost reduction by 2030.Deloitte, "Tokenization of Real-World Assets" (2025): meaningful institutional adoption across major corridors could cut total cross-border payment costs about 12.5% by 2030, the basis of the $50B+ figure in [section 1](#ov-n2). It measures total corridor cost, includes expected adoption curves and does not assume full penetration. We consider it conservative next to per-corridor implementations (see [note 1 in section 1](#ov-n1)). - 40–60% less manual KYC review time.Accenture Banking Technology Vision (2024) and SWIFT "AI in Financial Crime Compliance" (2024). Upper end: institutions with strong KYC data; lower end: those leaving fragmented databases. Structured data cuts manual exceptions; the KYC standard is unchanged. Applies to AI-assisted compliance generally; not audited in a tokenized A2A context. - 20–30% fewer payment exceptions.SWIFT "ISO 20022 Migration Progress Report" (2024) and a BIS working paper on payment data richness (2023). Structured names, addresses, LEIs and purpose codes replace MT free text that caused false positives. Depends on implementation and counterparty adoption. - ~70% lower cost per recurring transaction.Visa and Mastercard interchange (1.5–2.5% for recurring commercial payments) against A2A direct debit in UK Open Banking and EU SEPA Instant (0.1–0.5% including scheme fees). Recurring flows only (subscriptions, trade payables); single-use consumer card payments keep dispute and fraud protections A2A does not yet match at scale. - Sub-10-second settlement.Project mBridge (BIS Innovation Hub with the Hong Kong Monetary Authority, Bank of Thailand, Digital Currency Institute of the People's Bank of China and Central Bank of the UAE) and Jasper–Ubin (Bank of Canada and Monetary Authority of Singapore). Proof-of-concept results under controlled conditions; production timelines and performance at scale depend on regulatory, interoperability and governance decisions. - ACH / SEPA fees.US ACH is flat-fee, typically $0.20–$1.50 per transaction at institutional and bank-direct rates and free at many major banks; some processors add a 0.5–1.5% markup of their own. Treating ACH as a percentage fee misleads for B2B, where it is near zero per transaction at scale. SEPA Credit Transfer is similarly flat or zero-fee in the euro area. - ~0.2% tokenized A2A fee.Post Oak Labs' benchmark (settlement plus platform overhead) from production deployments in targeted B2B corridors, excluding FX captured at redemption, which is revenue to the originating bank. Context: Noda (2024) 0.1–0.8% for merchant-facing B2C A2A; FSB G20 Roadmap target well below 1% for retail cross-border; OpenDue (2025) 1–4% all-in for many correspondent corridors. - 64% of banks as tokenization providers by 2030.A Post Oak Labs projection from BIS and World Bank tokenization roadmaps, announced pilots in Latin America, South Asia and Southeast Asia, and regulatory pace in target markets. Assumes continued regulatory progress, critical mass in two to three major emerging-market corridors by 2028 and no major reversal. Directional; timing and penetration are uncertain. [id=iso20022] 03 · ISO 20022 ## [id=iso-h] ISO 20022 migration and A2A readiness are one project Banks spending engineering effort on mandatory ISO 20022 migration are working on the same infrastructure layer that tokenized A2A rails use. The firms advising on migration and the firms advising on tokenized infrastructure are almost entirely separate, which leaves a gap most institutions notice only after they have built technical debt they must unwind. See also [ISO 20022 in the glossary](glossary.html#a2a). - 200+Structured fields per ISO 20022 MX message, against under 10 in MT[1](#iso-n1) - 20–30%Fewer payment exceptions in early migration cohorts[2](#iso-n2) - 11,500+Institutions on SWIFT, all affected by the cross-border MX migration[3](#iso-n3) - Nov 2025End of the SWIFT MT/MX coexistence period for cross-border payments[4](#iso-n4) ### [id=what] MX carries about 20 times the structured data of MT Most teams treat migration as a mandatory standard change. Fewer see that its data makes tokenized A2A economically viable. MT103 and MT202 carry fewer than 10 meaningful fields; names, addresses and purpose are often truncated or missing, screening throws high false positives, and exception handlers clear thousands of payments a day by hand, with every correspondent working from the same degraded data. MX (structured XML) makes 200+ fields available, with mandatory population varying by message type: full legal name, structured address, LEI, purpose code, regulatory reporting codes, creditor reference and more. The same payload travels on tokenized A2A rails with no conversion. Field counts show relative capacity and are not a literal schema tally. | Data element | MT103 (legacy SWIFT) | ISO 20022 MX (pacs.008) | A2A token payload | Beneficiary name | 35-character free text, often truncated | Full legal name, up to 140 characters, structured | Identical to MX; no conversion | Beneficiary address | Optional, unstructured, often omitted | Structured postal address (street, city, country, postcode) | Carried natively in token metadata | Legal Entity Identifier | Not supported | Mandatory for financial institutions; available for corporates | Embedded in the token identity layer | Purpose code | Not supported in most MT formats | Structured code (SALA, TRPT, INSU, etc.) for automated classification | Smart contract logic can gate on it | Remittance information | 140-character unstructured field | Structured: invoice references, line items, amounts | Automated accounts payable matching at receiver | Sanctions screening | Free-text match; high false positives | Structured name, LEI and address; materially fewer false positives[2](#iso-n2) | Check embedded at token minting | Regulatory reporting | Manual reconstruction from several fields | Purpose codes and structured fields enable automated filing | Immutable on-ledger record meets audit needs directly ### [id=timeline] Where the mandatory migration stands The SWIFT cross-border deadline passed in November 2025. Banks still non-compliant or running MT/MX coexistence workarounds carry a compliance liability and technical debt that grows as A2A-capable competitors move ahead. | When | Milestone | March 2023 | SWIFT begins mandatory MT-to-MX migration for cross-border correspondent payments, with a coexistence period for sending and receiving both formats.[4](#iso-n4) | March 2023 | ECB migrates TARGET2 to ISO 20022 in the T2 consolidation; EURO1 (Euro Banking Association) follows. Any institution with euro flows or European correspondents is in scope.[6](#iso-n6) | July 14, 2025 | Federal Reserve migrates Fedwire Funds Service to ISO 20022, covering all US dollar RTGS transactions. Any institution with dollar correspondent relationships or cross-border dollar flows is in scope.[5](#iso-n5) | November 2025 | Cross-border coexistence ends. Institutions not on MX face processing degradation and may use SWIFT translation as a stopgap, at extra cost and with data loss.[4](#iso-n4) | Ongoing | Domestic RTGS migrations: CHAPS (UK), HVPS+ (China) and LYNX (Canada) have adopted or committed to ISO 20022. Each modernization puts alignment pressure on commercial banks in that jurisdiction. Exposure concentrates in mid-tier correspondent banks in emerging markets, especially Latin America, the Caribbean and sub-Saharan Africa, that lack internal ISO 20022 processing and rely on SWIFT's translation layer or correspondent workarounds. That is the profile we work with, and for them compliance pressure and the A2A opportunity are the same conversation. ### [id=alignment] One build that satisfies both requirements Tokenized A2A rails use ISO 20022 MX structures as their data layer. A bank that builds structured data handling, LEI resolution and automated reconciliation into its migration has built most of the data infrastructure A2A participation needs. The common mistake: parallel projects.Technology and operations own migration as compliance; innovation or strategy owns tokenized payments; the teams rarely talk. The migration meets the standard without the data handling, API layer or identity infrastructure A2A needs, so A2A later means a second major build on the first, doubling cost and debt. The unified architecture.A migration designed for A2A builds native MX data handling; an API gateway that accepts and emits ISO 20022 for SWIFT and tokenized rail participants alike; LEI resolution serving both compliance and token identity; and reconciliation for 200+ field messages (where counterparties populate optional fields, an adoption quality issue separate from compliance). That is the A2A on-ramp at no incremental infrastructure cost. The window is during the build, which is why we advise on migration and the A2A layer together. ### [id=migration] Five decisions that avoid A2A technical debt At each fork the right choice costs no more than the wrong one; the consequences diverge over time. - Build a structured data layer instead of a translation layer.The cheapest route is a gateway converting MX to MT for internal systems and back. It meets the SWIFT requirement and keeps legacy data poverty inside the bank. Process MX natively with a layer that handles structured fields, LEI resolution and purpose codes directly. - Design the API gateway for future participants.A gateway built only to current SWIFT correspondent specifications must be rebuilt to add tokenized rail participants. Extensible onboarding, including permissioned ledger endpoints, costs marginally more upfront and avoids the rebuild. - Run LEI resolution as a shared service.LEI resolution is required for ISO 20022 and is also the identity layer for institutions on tokenized networks. Embedded as a point solution in the SWIFT pipeline, it must be reimplemented for A2A. - Reconcile on structured fields.Logic built around invoice references, remittance information and purpose codes works identically on tokenized A2A transactions, because the token carries the same payload. Logic that reconstructs message content does not. - Bring in your permissioned ledger vendor during migration.If you intend to deploy on a permissioned DLT (Corda, Hyperledger Fabric and others), the vendor should review the migration architecture before it is final. Every major platform supports ISO 20022 natively, but integration patterns vary. ### [id=ams] Compliance gains on A2A rails The compliance benefits of ISO 20022 are well documented. They compound on tokenized rails, where compliance logic can sit at the ledger layer. AML and sanctions screening Truncated MT names match patterns across sanctioned and clean entities. Structured names, LEIs and addresses let screening match legal entity registries; early cohorts show 30–50% fewer false positives (SWIFT and vendor data)[2](#iso-n2). On tokenized A2A, screening runs once at minting, before the payment enters the network, in place of a check at each hop. Reconciliation Manual matching of under-documented payments is the largest operations cost in correspondent banking. Structured remittance data (invoice number, line items, creditor reference) allows straight-through reconciliation in the receiver's accounts payable. On tokenized rails the data arrives with the token before redemption, enabling pre-crediting and same-day accounts payable closure. Regulatory reporting Many jurisdictions require cross-border payments reported by category (salary, trade, investment, remittance) for balance of payments, capital flow monitoring and tax. Purpose codes replace manual MT classification, and the immutable on-ledger record serves as the audit trail without reconstruction. FATF Recommendation 16 (Travel Rule) Originator and beneficiary data must accompany wire transfers. MT often truncates it; ISO 20022's mandatory structured fields meet the rule more completely and more auditably. This matters where grey-listing is a risk or recent history, including Nigeria (exited in 2023) and markets under CFATF review. ### [id=examples] Two institutional scenarios Caribbean commercial bank, mid-migration.A mid-tier Jamaican bank is 12 months into a SWIFT MX project and has built a gateway translating MX to MT for internal systems: compliant, without native structured data handling. Our architecture review found that the translation approach closes off A2A readiness. Revised scope replaced the gateway with a native MX processing layer and an extensible API gateway. Incremental cost was modest; the alternative was a full rebuild in 24–36 months once A2A was required. The bank now has a compliant migration and an on-ramp to the JAM-DEX-compatible A2A layer the Bank of Jamaica is developing. Colombian regional bank, pre-migration.A regional bank choosing ISO 20022 vendors also has a board mandate to evaluate tokenized cross-border payments for its remittance-heavy US–Colombia corridor. We built A2A alignment criteria into the RFP: native MX processing, LEI resolution as a shared service, API gateway extensibility for non-SWIFT participants and a DLT compatibility review. The bank picked a vendor that met them, and migration and A2A pilot now run as one program, with a projected 30–40% reduction in combined infrastructure cost. Every in-progress migration we review shows the same gap: the team solves for SWIFT compliance, nobody asked it to solve for A2A, and the choices that close off A2A are defaults. The fix is inexpensive and needs both conversations in one room. A team 12 months in with a translation gateway can still correct course cheaply; after completion, we can map the on-ramp from where you are. For how the rails compare with correspondent banking and stablecoins, see [A2A vs. correspondent banking](a2a-comparison.html). ### Notes - Field count.The ISO 20022 Message Definition Report for pacs.008 documents 200+ available data elements; MT103 carries fewer than 10 mandatory or commonly used structured fields in practice, with most optional fields free text. Not every MX field is mandatory in every context. See [iso20022.org](https://www.iso20022.org)and [swift.com/standards/iso-20022](https://www.swift.com/standards/iso-20022). - Exceptions and false positives.SWIFT's ISO 20022 Programme Migration Progress Update (2024) documents exception reductions in early cohorts, corroborated by BIS Working Paper No. 1114 (2023). For screening, SWIFT's Financial Crime Compliance whitepaper (2024) and Accenture compliance research (2023) cite 30–50% false-positive reduction in structured-data environments. Results depend on implementation and screening system quality; treat as directional. - SWIFT network size.Per the 2024 annual report, SWIFT connects 11,500+ institutions in 200+ countries. See [swift.com](https://www.swift.com/about-us/discover-swift/facts-figures). - SWIFT cross-border timeline.Migration began March 2023 with coexistence; CBPR+ coexistence ended November 2025. Non-migrated institutions may use SWIFT's translation service, with data quality loss. Guidance at [swift.com/standards/iso-20022/iso-20022-programme](https://www.swift.com/standards/iso-20022/iso-20022-programme). - Fedwire.The Federal Reserve migrated Fedwire Funds Service, one of the largest high-value systems by volume, on July 14, 2025. Details at [frbservices.org](https://www.frbservices.org/financial-services/funds/iso20022.html). - TARGET2.The ECB consolidated TARGET2 into T2 in March 2023 and migrated to ISO 20022 as part of it. See [ecb.europa.eu](https://www.ecb.europa.eu/paym/target/target2/html/index.en.html). [id=tmmf] 04 · Tokenized MMFs ## [id=tmmf-h] Local-currency tokenized money market funds on A2A rails USD tokenized money market funds (tMMFs) are real, funded and growing. As far as Post Oak Labs is aware, no institutional-grade equivalent exists for corporate treasurers in non-dollarized markets: the same short-duration yield and overnight liquidity, denominated in COP, NGN or JMD. This section describes that combined product. See also [tMMF in the glossary](glossary.html). - $1B+BlackRock BUIDL AUM, reached within its first year[1](#tm-n1) - $9T+Global MMF AUM, almost all in USD and major currencies; local-currency emerging-market tMMFs are near zero[2](#tm-n2) - T+0Redemption for tMMF units on A2A rails, against T+1 or T+2 for traditional funds - 6–26%+Overnight rate range in target markets, enough to matter on operating balances above $1M[3](#tm-n3) ### [id=rates-chart] The yield gap A treasurer holding idle COP, NGN or JMD forgoes a far higher overnight yield than a USD tMMF offers, and the gap costs basis points every day. Illustrative overnight-rate benchmarks. These are policy or overnight rates; tMMF net yield would run below them. Sources in note 3. | Benchmark | Rate | USD tMMF | ≈5% | Jamaica | 6.5–7% | Colombia | 9.75% | Nigeria | 26.25% ### [id=why] Why the product is missing in non-dollarized economies A Bogotá treasurer with excess COP faces the same problem as a New York treasurer with excess USD: idle cash earns nothing. The New York treasurer has BUIDL and a dozen equivalents. The Bogotá treasurer's options are limited, slow or unavailable in the functional currency, for three reasons. FX exposure A company with COP revenues and payables parking cash in a USD fund pays a round-trip FX cost of typically 1–2%, erasing the yield on positions under 30 days. It needs a COP short-duration fund with T+0 redemption, structured like BUIDL; none exists in Colombian institutional banking. Yield assumptions in this section: COP policy rate about 9.75% (Banco de la República, Q1 2026), 20bps management fee and ~0.2% A2A settlement fee, giving about 8.8–9.0% annualized net. Rates have moved a lot since 2022; verify before modelling. Capital controls Nigeria's CBN FX rules, Jamaica's historical FX framework and similar regimes add overhead and a 1–5 business day delay to USD access, which rules out overnight positions. A local-currency tMMF on a domestically regulated ledger involves no cross-border capital movement. Redemption mechanics Overnight rates in Colombia (7–8% in 2024–2025), Nigeria (22–26% policy context) and Jamaica (6–7%) are worth capturing above $1M, but T+1 or T+2 redemption, minimums and manual subscription make daily sweeps impractical. Same-day A2A redemption lets treasury sweep in each evening and redeem each morning. 100bp annualized on $10M is $100K, unreachable at T+1. ### [id=existing] What exists and what does not The opportunity lies in the market USD tMMFs structurally cannot serve. BUIDL, Franklin Templeton's BENJI, Ondo Finance's OUSG and others give well-executed institutional tokenized exposure to US Treasury bills and money market instruments. The equivalent for local-currency treasurers in non-dollarized emerging markets did not exist in institutional-grade tokenized form anywhere we were aware of as of early 2026. | Product | Issuer | Currency | Underlying | AUM (approx.) | Redemption | Serves local-currency treasurers | BUIDL | BlackRock / Securitize | USD | US Treasuries, repo | $1B+ (2024)[1](#tm-n1) | T+0 on-chain, T+1 off-chain | No: USD only | BENJI | Franklin Templeton | USD | US Government MMF | $400–500M (2024)[4](#tm-n4) | T+1 (Benji app) | No: USD only | OUSG | Ondo Finance | USD | BUIDL and other tokenized government-securities vehicles (restructured Mar 2024) | $200M+ (2024) | T+0 on-chain instant redemption | No: USD only, DeFi-native | Local-currency tMMF on A2A | Originating commercial bank (to be built) | COP / NGN / JMD / others | Local short-duration sovereign instruments, bank deposits, CDs | Not yet in market | T+0 via A2A rail | Yes: the architecture described here ### [id=tmmf-architecture] Product architecture The originating bank probably already has both components. The work is connecting them on one ledger. Layer 1: fund vehicle A locally regulated collective investment scheme (CIS), managed by the bank or its asset management arm, holding treasury bills, central bank repos or equivalents, bank CDs and high-grade local commercial paper. CIS licensing is the requirement that varies most by market. It is a traditional money market fund; tokenization sits above it and leaves it unchanged. Layer 2: token layer Each fund unit or fraction is a token on the same permissioned ledger as the A2A rail. Legally the instrument is the fund unit; the token is the bearer mechanism for the claim. Tokens mint when a corporate moves funds in by A2A instruction and burn on redemption as fiat is credited back, both in real time. Layer 3: A2A distribution rail The rail carries both subscription and redemption. With operating balance and position on one ledger, both are atomic with no settlement risk, no T+1 window and no wire or manual step. Treasury runs it from the bank's existing digital banking interface. Custody layer The most jurisdiction-sensitive element. Assets sit with the bank's custody subsidiary, a third-party custodian or the central bank depository where available. In most target markets (Colombia, Nigeria, Jamaica) they must be in a segregated account legally separate from the bank's own assets, protecting investors if the bank fails. The token represents the custodied unit; the legal structure runs through the custody arrangement. ### [id=daily-flow] The overnight cycle for a treasury client Treasury works only with the bank's familiar payment and account tools and never with the fund directly. - End of day: sweep.Through the portal or automated cash rules, treasury moves cash not needed overnight into the tMMF. The rail mints tokens and debits the account in real time, in under 30 seconds. - Overnight: accrual.Yield on the fund's bills, repos and CDs accrues pro rata, either in NAV per token (accumulating) or as a separate yield token or account credit (distributing); the choice has jurisdiction-specific regulatory and tax effects. - Morning: redemption.Before market open the rail burns the tokens, redeems the units and credits principal plus overnight yield less fees, restoring working capital with no manual step, T+1 delay or FX conversion. What it produces.A company with a $10M COP-equivalent balance at a 7% overnight rate (approximate Colombian 2024 policy environment) earns about $700K a year by sweeping idle cash overnight. A traditional MMF with T+1 redemption captures about 70% of that because settlement delays lose part of the cycle; a tMMF on A2A rails with T+0 redemption captures close to 100%. Across a bank's commercial book, this makes overnight yield practical for many corporate clients who currently earn nothing on idle balances. ### [id=tmmf-revenue] Three revenue streams for the originating bank Together the streams give better economics than the fund or the rail alone. Management fee on tMMF AUM 15–30bps a year The standard institutional local-currency MMF fee, earned by the bank's fund arm. At $500M AUM, 20bps is $1M a year of recurring, low-cost fee income with no added credit risk on the balance sheet. Spread between fund yield and token yield 25–75bps typical Holders receive net yield after fees and any retained spread. At 6–8% policy rates, a 50–100bps spread on large AUM is meaningful income; it must be disclosed and meet local CIS fee transparency rules, as is standard in MMF economics. Capture depends on jurisdiction and competition. FX on cross-border flows 0.5–1.5% of converted volume A corporate redeems tokens, converts at the bank's on-ledger rate and pays cross-border in one atomic transaction; the bank keeps the whole FX margin that used to go to correspondents. For heavy cross-border clients this can be the largest stream. ### [id=regulatory] Regulatory considerations Local CIS regulation drives the requirements, more than digital asset or CBDC rules. In most target jurisdictions the tMMF is regulated as a money market fund with a digital distribution mechanism; tokenization creates no new regulatory category, and the fund wrapper is what counts. Not legal advice.This summarizes publicly available requirements as of early 2026. CIS rules are jurisdiction-specific and change often. Engage in-country counsel before any launch or registration. Post Oak Labs advises on product architecture and regulatory strategy and does not give legal opinions. Colombia Decreto 2555 (2010) and SFC guidelines. Pooled vehicles need Superintendencia Financiera de Colombia (SFC) authorization as a Fondo de Inversión Colectiva (FIC); money market FICs carry short-duration limits, daily liquidity requirements and maximum WAM limits in line with international MMF standards. Tokenized distribution leaves FIC classification unchanged. SFC Circular 014 (2021) gives initial tokenization guidance; expect SFC consultation and likely a formal guidance request before launch. Nigeria SEC Nigeria under the Investments and Securities Act (ISA) 2024. A tMMF would register as a unit trust, disclosing the tokenization mechanism in the trust deed and offering memorandum. The 2022 SEC Digital Assets Rules cover tokenized products partially and tokenized CIS not at all. Pre-filing consultation is strongly recommended. Jamaica Securities Act (2013), Financial Services Commission (FSC Jamaica); MMFs are established categories. The Bank of Jamaica's JAM-DEX CBDC infrastructure and the FSC sandbox make a relatively favorable pilot setting, and a tMMF pilot on A2A rails would likely qualify for sandbox treatment before full registration (process at fscjamaica.org). Custody, all markets Every target-market CIS framework requires fund assets in ring-fenced custody, separate from the manager's assets, with an authorized custodian or the central bank depository. Legal chain: corporate holds token → token represents fund unit → unit is custodied → custodian holds the instruments. Each link must be documented and meet local CIS and custody rules. For an institution with an existing fund business and corporate clients losing yield to FX friction or settlement delay, this is a tractable product build, and a licensing path exists in each market above. ### Notes - BUIDL.BlackRock's USD Institutional Digital Liquidity Fund, issued on Ethereum via Securitize, passed $1B AUM in early 2024 as the largest tokenized Treasury fund and remained among the largest in early 2026. It is for qualified institutional investors in the US and select jurisdictions; a COP, NGN or JMD treasurer must convert to USD, reintroducing FX exposure. BlackRock / Securitize release (March 2024); Financial Times, Bloomberg, CoinDesk. - Global MMF AUM.ICI Global Fact Book (2024, year-end 2023 data): about $9.3 trillion globally, about $6 trillion in the US, with the US, Europe and China over 95% combined. Local-currency emerging-market MMFs are a small fraction. The near-absence of local-currency tokenized MMFs in Colombia, Nigeria, Jamaica and the Caribbean was confirmed by review of fund registration databases as of early 2026. - Policy rates, early 2026.Banco de la República de Colombia about 9.75% (cutting from a 13.25% peak in 2023–2024); Central Bank of Nigeria MPR about 26.25% (as of early 2025, after aggressive tightening); Bank of Jamaica about 6.5–7.0% (down from its 2022–2023 peak). Short-duration yields available to managers typically run 25–100bps below policy rates; check current rates before design decisions. In Nigeria, inflation makes real yields at a 26%+ MPR materially lower than the headline, which matters for positioning and client communication. - BENJI.Franklin Templeton's OnChain US Government Money Fund launched in 2021 on Stellar, later expanded to Polygon, and grew past $400–500M AUM through 2024, one of the earliest and largest tokenized government securities products (Franklin Templeton materials; Bloomberg, April 2024). It is USD-denominated for US-regulated investors. [id=roadmap] 05 · Roadmap ## [id=roadmap-h] From evaluation to production in four phases Treasury teams and ALCO leads can assess readiness across five dimensions and see what a Phase 1 scoping engagement involves before committing budget. - 5Readiness dimensions scored - 4Time-boxed phases - T+0Sub-second finality, pilot target - ~4.5%tMMF yield recovery on a $50M nostro equivalent ### [id=diagnostic] Readiness diagnostic The diagnostic takes three inputs (monthly cross-border volume, primary corridors and ISO 20022 migration status) and estimates annual nostro float drag as monthly volume × 12 × 4.5%. It scores five dimensions: ISO 20022 alignment Migration status is the main driver of Phase 1 timeline; institutions already in progress can shorten Phase 1 by 2–3 weeks. The diagnostic scores not started at 15%, in assessment 35%, in progress 65% and completed 90%. Liquidity model fit Corridor volume sets potential tMMF yield recovery; higher monthly volume strengthens the case for redesigning the liquidity model. Regulatory posture Tokenized deposits operate within your existing banking license. Phase 1 mapping surfaces jurisdiction-specific issues before architecture starts. Technical capacity Core integration paths vary by vendor; the architecture phase identifies options that need no core changes where available. Corridor economics Corridor FX spread, settlement lag and correspondent dependency set the net benefit of an A2A deployment. ### [id=phases] A time-boxed, reversible path Each phase ends with a Go/No-Go gate, keeps budget approvals within ALCO norms and delivers standalone value. Nothing requires a multi-year commitment upfront. | Phase | Duration | Scope | Deliverable and gate | 01 Feasibility and regulatory mapping | 4–6 weeks | Use-case validation, jurisdiction scan, ISO 20022 readiness against your active corridors ([section 3](#iso20022)) | Board-ready memo and risk register scoped to your balance sheet. Gate: Go/No-Go to architecture | 02 Architecture and platform selection | 6–8 weeks | DLT platform selection, node topology design, counterparty onboarding plan (see [Corda architecture](a2a-ledgers.html#corda)and the [platform comparison matrix](a2a-comparison.html)) | Technical design document and RFP criteria for platform vendors. Gate: Go/No-Go to pilot budget | 03 Pilot scope and sandbox build | 8–10 weeks | Limited live pilot across 2 corridors; smart contract configuration, compliance integration, operational runbook; production-equivalent test environment with full audit trail | Gate: Go/No-Go to production | 04 Production scaling | Ongoing | Full corridor deployment, liquidity provisioning, tMMF integration for nostro yield recovery ([section 4](#tmmf)), TARGET2/SARIE hook configuration where applicable | Live rails and an internal handoff kit for operations Phase 1 is the only required commitment, and most ALCO committees can authorize it without board sign-off. Each later phase is approved independently. ### [id=roadmap-regulatory] Tokenized deposits and third-party stablecoins For compliance teams and board risk committees: the liability structure, capital treatment and regulatory perimeter of tokenized deposits differ fundamentally from third-party stablecoins. See the [regulatory FAQ](faq.html)for more. | Dimension | Tokenized deposit | Third-party stablecoin | Liability holder | Issuing bank (you) | Stablecoin issuer (third party) | Basel III capital | Standard deposit treatment | Potentially 1250% risk weight (crypto exposure) | Deposit insurance | Eligible (jurisdiction-dependent) | Not eligible | Core system audit | Native integration path | Requires reconciliation bridge | Regulatory perimeter | Existing banking license | New licensing regime in most jurisdictions Tokenized deposits stay inside the regulatory perimeter your board already understands and the deposit franchise you already run; the tokenization layer sits within existing infrastructure. ### [id=engage] What happens when you reach out There is no RFP process and no six-week discovery phase. Phase 1 starts with a 30-minute treasury review confirming corridor fit, jurisdiction coverage and ISO readiness; the memo and risk register follow within 4–6 weeks, and starting Phase 1 needs no budget commitment. Before Phase 2 you can compare DLT platforms, corridor economics and settlement topology in the [architecture matrix](a2a-comparison.html), which covers Corda, DAML, Hyperledger Fabric and hybrid approaches across jurisdiction classes. Platforms we work across: R3 Corda, Digital Asset DAML and Hyperledger Fabric. We take on a limited number of institutions at a time. For a live corridor problem, a direct conversation is fastest. [Begin Phase 1 scoping](contact.html)[contact@postoaklabs.com](mailto:contact@postoaklabs.com) --- ## Page: https://postoaklabs.com/a2a-ledgers.html [](./) Library # A2A on enterprise ledgers Four reference architectures for tokenized account-to-account settlement between regulated institutions, one per permissioned ledger. Hyperledger Besu, R3 Corda and Hyperledger Fabric each carry a three-bank payment corridor from the euro area to Saudi Arabia or the UAE; Canton links four financial market infrastructures in a single atomic collateral trade. Each section covers topology, contract code, the full transaction lifecycle, FX, privacy, ISO 20022 binding, compliance and regulation. The shared flow is described once, up front. [id=compare] At a glance ## [id=compare-h] The four ledgers compared Every cell below comes from the platform sections that follow. | Layer | Hyperledger Besu | Canton | R3 Corda | Hyperledger Fabric | Scenario | BankFR (Paris), BankES (Madrid), BankSA (Riyadh); EUR/SAR payment | Clearstream D7, DTCC ComposerX, Broadridge DLR, Euroclear D-FMI; intraday repo and collateral DvP | BankFR (Frankfurt), BankNL (Amsterdam), BankAE (Dubai, ADGM); EUR/AED payment | Bayerische Handelsbank (Munich), Banque Méridienne (Paris), Bank Al-Madinah (Riyadh); EUR/SAR payment | Privacy model | Every validator sees public state. Only hashes go on-chain; ISO 20022 and KYC payloads travel through Tessera to named parties. Zero-knowledge proofs optional. | Sub-transaction privacy: each participant receives only its encrypted view; the Global Synchronizer orders and confirms without reading content. | Point-to-point AMQP: only transaction parties see the states. The notary sees state references only. | One corridor channel plus three bilateral channels; Travel Rule data in a private data collection with only its hash on the channel ledger. Amounts visible to channel members (fabtoken). | Consensus and finality | QBFT, one validator per bank, 2-of-3 commit, 2-second blocks, instant deterministic finality. | 13 Super Validators run Tendermint-style BFT ordering (under 500 ms); mediator runs two-phase commit across participants. | BFT notary cluster (BFT-SMaRt variant), 3-of-5 signatures, checks uniqueness of consumed states. | Five-node etcd/Raft ordering (crash fault tolerant, quorum 3), 2-of-3 endorsement, MVCC validation. SmartBFT planned for Fabric 3.x. | Token or asset model | ERC-20 deposit tokens (EurDepositToken, SarDepositToken), 1:1 claims on bank reserves. | Daml contracts as registered digital twins of custodied securities (Treasuries, EUR commercial paper, gilts). Canton Coin pays fees only. | Corda Token SDK FungibleTokenstates, consumed and replaced on each transfer. | Fabric Token SDK UTXO notes (fabtoken driver): EUR-CBM and SAR-CBM commercial bank money tokens. | Contract language | Solidity 0.8 on the EVM | Daml 3.x | Kotlin CorDapps on the JVM | Go chaincode (contract-api-go) | Identity | enode plus X.509 certificate per node; HSM-held ISSUER_ROLE keys; EIP-712 signatures. | Daml parties hosted on participant nodes; topology manager publishes party-to-participant mapping. | X.509 legal identities (O, L, C) published through the network map service. | Per-bank Fabric CA and MSP; X.509 with OU and attribute roles (treasury, gateway, compliance, audit). | Settlement pattern | Atomic PvP in one EVM transaction (Adhara SILVER); 4-hour netting; TARGET2 and SARIE in central bank money. | Atomic DvP across four FMI applications; cash via Fedwire (USD) and TARGET2 (EUR) RTGS. | Atomic PvP in one notarised transaction; 4-hour netting; TARGET2 and UAE RTGS. | Atomic swap inside one read-write set; daily netting at 17:00 CET; TARGET2 and SARIE. | On-ledger time | Steps 1–11 under 30 seconds; PvP well under 10 seconds | About 6 seconds to atomic commit | Steps 1–11 under 60 seconds | Under 1 second [id=pattern] Shared pattern ## [id=pattern-h] The shared A2A pattern All four designs move value between identified, supervised institutions on a permissioned ledger. Each bank or FMI runs its own node in its own data center or regulated cloud, holds signing keys in FIPS 140-2 Level 3 HSMs, and keeps authoritative control of its own liabilities or asset register. The three payment corridors (Besu, Corda, Fabric) settle tokenized commercial bank money and follow the same ten-stage flow. Canton applies the same atomic-settlement idea to securities and collateral. - Instruction.The corporate client submits an ISO 20022 pacs.008 instruction; the originating bank checks balance, AML risk score and transaction limits. - Screening and Travel Rule.Sanctions screening runs on structured name and LEI fields. Originator and beneficiary banks exchange FATF Recommendation 16 data (IVMS-101 format) as a Verifiable Credential or private payload; only its hash reaches shared state. The beneficiary bank checks the originator LEI against GLEIF. - FX quote.A liquidity bank runs the FX oracle and signs a mid, bid and ask quote from its treasury feed (Bloomberg or Refinitiv) valid for 90 seconds. One signed rate for everyone removes disputes about which rate governs the conversion; the network participation agreement names the oracle. - Atomic exchange.Both currency legs settle in a single ledger transaction that commits completely or reverts completely (payment versus payment). No partial-settlement state can exist, so principal risk is removed by construction. - Credit.The receiving bank's integration layer picks up the ledger event and credits the beneficiary's account in core banking in real time, before the RTGS cycle settles. - Audit trail.Each party holds an immutable, signed, timestamped record that ties the payload hash, KYC attestation hash, FX quote and signatures to the payment reference (UETR). Regulatory reporting is generated from it with no post-hoc reconstruction. - Netting.A netting cycle computes net interbank positions: every 4 hours, or on demand above €50M, in the Besu and Corda designs; once a day at 17:00 CET on Fabric. - RTGS settlement.Net positions settle in central bank money. For EUR that is TARGET2, the ECB's RTGS, on ISO 20022 since the March 2023 T2 migration, with pacs.009 instructions and settlement in claims on the ECB itself. The local leg uses SARIE (SAMA) or UAE RTGS (CBUAE). - Burn.Once both RTGS confirmations arrive, the tokens covering the settled amounts are burned, so on-ledger supply always equals the unsettled portion of obligations. - Reconciliation.The structured ISO 20022 data (invoice references, purpose codes, LEIs) stays bound to the payment, so both banks reconcile straight through. The designs target an exception rate under 2%; early ISO 20022 adoption cohorts report 20–30% fewer payment exceptions than MT workflows. ### Why the pattern pays - Netting replaces pre-funded nostro balances with just-in-time central bank money settlement. - FX conversion happens on the ledger, so the spread moves from the correspondent chain to the banks that hold the client relationships. In the Besu and Corda examples the originating bank earns a flat 5 bp on the EUR leg. - BIS CPMI (2022) found roughly one-third of global FX transactions, about $2.2 trillion in daily settlement value, still settle without PvP and so carry Herstatt-style risk. The 1974 Herstatt failure remains the canonical case. - Structured ISO 20022 fields let banks screen against legal entity registries instead of free text. SWIFT's ISO 20022 Migration Progress Report (2024) and Accenture's "Transforming Financial Crime Compliance with AI and ISO 20022" (2023) document 30–50% fewer false positives than MT formats, which also shortens manual review queues. ### EU rules common to the three payment corridors | Rule | Effect on a bank-issued deposit token corridor | EBA Report on Tokenised Deposits (EBA/REP/2024/24, Dec 2024) | Distinguishes bearer and non-bearer tokenised deposits. Non-bearer tokens issued by a credit institution stay on its balance sheet and are regulated under CRD/CRR banking law instead of MiCA Title III, so issuance needs no e-money token authorization and avoids the €150M issuance cap and monthly transaction limits for large EMT issuers under MiCA Articles 23–24. The EBA also favours public token state on permissioned chains with personal data kept off-chain. | MiCA (Reg. 2023/1114, full effect Dec 2024) | Titles III and IV govern stablecoins from non-bank issuers. Art. 2(4)(a) excludes deposits. MiCA would apply if a bank issued a retail e-money token. | Transfer of Funds Regulation (Reg. 2023/1113) | In force 30 December 2024 with no grace period. Originator and beneficiary data must accompany every transfer regardless of amount, including transfers between two regulated banks. | DORA (Reg. 2022/2554, in force 17 Jan 2025) | The ledger node is a critical ICT system. Requires resilience testing (TLPT for systemic institutions), major-incident reporting to the supervisor within 4 hours, and third-party risk management that gives the bank contractual resilience guarantees and audit rights over the platform vendor. | AMLD6, EU Sanctions Regulation, GDPR | Each bank screens independently; personal data stays out of shared ledger state. | Settlement Finality Directive | Legal finality protection applies only to designated payment systems; none of these corridors is designated yet. ### Risks common to every design - Consortium governance.Contour (trade finance, built on Corda), we.trade and Marco Polo failed on governance: commercial incentives among competing bank shareholders could not be kept aligned. The participation agreement must say who pays for maintenance when year-one volumes disappoint, who controls the upgrade roadmap, what happens if a bank exits, and who is liable for a settlement failure caused by a bug in shared code. - Legal finality.Ledger finality is technical. Legal finality, the right to retain funds against counterparty insolvency, depends on the legal regime. Fnality's Sterling Fnality Payment System (£FnPS) received Bank of England Settlement Finality Designation in 2024, the first DLT-based payment system to do so. Equivalent engagement for these corridors is an 18–36 month regulatory process. - Mint-key compromise.Whoever holds the issuer's minting key can create unbacked tokens. The standard mitigation is M-of-N HSM multi-signature minting split across treasury, compliance and technology teams, with disaster recovery for key material tested before production. - Regulatory sequencing.EU-side banks should seek informal supervisor guidance, file a DORA ICT risk assessment covering the node, pilot with synthetic transactions, seek payment-system authorization (or a sandbox or SFD designation pathway), and only then go live bilaterally. Compressing this sequence is the most common error and adds 12–24 months. Shared precedent: Project Aber The Saudi Central Bank (SAMA) and the Central Bank of the UAE (CBUAE) ran Project Aber (2019; joint report "A Joint Digital Currency and Infrastructure Initiative", 2020) with six commercial banks across both countries, evaluating R3 Corda for cross-border, dual-issued digital currency settlement. It confirmed technical viability and showed that DLT lets central banks operate domestic and cross-border payment systems from the same infrastructure. Aber used a CBDC model; the corridors on this page use deposit tokens issued directly by commercial banks, a related but distinct model. Aber is the supervisory precedent behind the Saudi and UAE legs below. Background reading: [A2A payments overview](a2a-guide.html#overview), [the A2A workflow](a2a-guide.html#workflow), [ISO 20022 in A2A](a2a-guide.html#iso20022), [comparison framework](a2a-comparison.html), [enterprise blockchain briefing](enterprise-blockchain.html)and the [glossary](glossary.html). Shared sources: BIS CPMI, "PvP arrangements and the case for greater adoption", 2022, [bis.org/cpmi/publ/d208.htm](https://www.bis.org/cpmi/publ/d208.htm). SWIFT ISO 20022 and CBPR+, [swift.com/standards/iso-20022](https://www.swift.com/standards/iso-20022). ISO 20022 schemas, [iso20022.org](https://www.iso20022.org/). EBA/REP/2024/24. FATF Recommendation 16 (Wire Transfers). Bank of England Financial Market Infrastructure Annual Report 2024; [fnality.org](https://www.fnality.org). [id=besu] Hyperledger Besu · EUR/SAR ## [id=besu-h] Hyperledger Besu: two European banks and a Saudi bank A French corporate pays a Riyadh supplier. BankFR (Paris) originates and issues EUR tokens. BankES (Madrid) is the EUR liquidity validator and on-chain FX market maker. BankSA (Riyadh) receives and redeems in SAR. The network uses Besu with the Adhara SILVER (Settlement, Issuance, Liquidity and Velocity Enhancement Rail) pattern proven in Project Khokha 2 and the Euro Cyber Resilience Board sandbox. The ISO 20022 pacs.008 is hashed on-chain with the encrypted payload kept off-chain, and there is no nostro pre-funding. - Besu 24.x - Adhara SILVER - QBFT - Solidity 0.8 / EVM - Tessera - pacs.008 - MiCA - SAMA Open Banking - DORA ### Why this corridor and this stack No production tokenized A2A network yet serves EUR/SAR. EU–Saudi bilateral trade exceeded €80 billion in 2024, led by energy, capital goods, infrastructure procurement and Vision 2030 mega-project financing. Payments are large enough that correspondent banking's all-in cost (typically 150–350 bp) costs a single mid-sized European exporter book tens of millions of euros a year. SAMA has run DLT cross-border settlement experiments since 2019 (Project Aber) and participates in Project mBridge, the multi-central-bank wholesale CBDC network. - Besu is an Apache 2.0, EVM-compatible client maintained under the Linux Foundation's Hyperledger umbrella since 2019, so the pool of about 23,000 Solidity developers can build on it without a new language or VM. - QBFT gives instant deterministic finality per block with no reorg window, a precondition for legal payment-system designation. - It has the deepest production record of any permissioned EVM platform in regulated infrastructure: Bank of Thailand's Project Inthanon, SARB's Project Khokha 1 and 2, Banque de France wholesale CBDC experiments, Eurosystem exploratory work, and Onyx by J.P. Morgan, whose Liink and JPM Coin systems run on a Besu-derived stack. - Adhara, a UK fintech founded in 2018 from the ConsenSys/Quorum lineage, supplies SILVER: tokenized commercial bank money, on-chain PvP, liquidity-saving netting and an oracle/FX layer. SILVER was the settlement core of Khokha 2 and is the engine behind Project Atlas (Investec, Citi, Standard Bank, Absa). Adhara is also the technology provider for £FnPS. Khokha 2 precedent The South African Reserve Bank ran Project Khokha 2 with Absa, FirstRand, Investec, Nedbank and Standard Bank, completing it in 2022. It used SILVER on a Besu-derived network to settle tokenized wholesale CBDC and tokenized debentures with on-chain PvP and DvP, and showed intraday liquidity savings of 60–80% against gross RTGS. ### [id=besu-topology] Topology and validators Five Besu nodes: three validators (one per bank) and two non-validator observer/RPC nodes operated jointly. Each validator is paired with a Tessera private-transaction manager, and bridge connectors link to TARGET2 and SARIE. All contracts sit in a shared Adhara SILVER layer (EurDepositToken, SarDepositToken, PvP settlement, FXOracle, netting). Validator 1 · originating bank #### BankFR · Paris Licensed by the ACPR; within MiCA where it issues e-money tokens under Title III; DORA-compliant for critical ICT since January 2025. Mints EurDepositTokenagainst its own reserves for corporate clients and burns on redemption. Identity enode + X.509 cert HSM Thales Luna 7 Privacy Tessera payload manager Consensus Round-robin QBFT proposer, vote weight 1 RTGS TARGET2 bridge Validator 2 · liquidity and FX oracle #### BankES · Madrid Licensed by Banco de España; MiCA and DORA. Originates nothing here; holds surplus EUR tokens for intraday liquidity and runs FXOracle.sol, the signed EUR/SAR feed for the PvP engine. Identity enode + X.509 cert HSM Utimaco SecurityServer Privacy Tessera payload manager RTGS TARGET2 net settlement Validator 3 · receiving bank #### BankSA · Riyadh Licensed by SAMA under the Banking Control Law (1966, as updated); subject to the SAMA Open Banking Framework (Phase II in force 2024), Cyber Security Framework and Cloud Computing Regulatory Framework. Issues and redeems SarDepositToken, crediting SAR on-chain at the oracle rate. SAR is pegged to USD at 3.7500. Identity enode + X.509 cert HSM AWS CloudHSM Privacy Tessera payload manager RTGS SARIE (SAMA) QBFT rotates the block proposer round-robin and needs a 2-of-3 commit signature on every block. Block time is 2 seconds, so end-to-end PvP takes well under 10 seconds. One observer belongs to an independent regulator-facing trust that publishes a permissioned reporting feed to the ACPR, Banco de España and SAMA; the other belongs to an independent auditor (the Deloitte/PwC pattern used in Khokha 2). Observers read public-state events through permissioned RPC, produce no blocks and cannot see Tessera payloads. An on-chain ValidatorRegistrygoverns the validator set: changes need a 2-of-3 vote plus a 14-day delay, the pattern used by Onyx and Khokha 2. ### [id=besu-contracts] Contracts: deposit tokens, SILVER PvP, FX oracle Three Solidity 0.8.x contract groups: one ERC-20 deposit token per currency, the SILVER engine (PvP atomic settlement, liquidity-saving netting, obligation tracking), and infrastructure contracts (FX oracle, validator registry, compliance registry). All are deployed once by a permissioned deployer key and upgraded through UUPS proxies with 2-of-3 validator approval and a 14-day timelock. The token adds permissioned mint and burn, a compliance freeze, and a hash binding to the off-chain pacs.008. // SPDX-License-Identifier: Apache-2.0 pragma solidity ^0.8.20; import "@openzeppelin/contracts/token/ERC20/ERC20.sol"; import "@openzeppelin/contracts/access/AccessControl.sol"; contract EurDepositToken is ERC20, AccessControl { bytes32 public constant ISSUER_ROLE = keccak256("ISSUER_ROLE"); bytes32 public constant COMPLIANCE_ROLE = keccak256("COMPLIANCE_ROLE"); // Binds each minted batch to its ISO 20022 pacs.008 payload (kept off-chain // in Tessera, hash committed on-chain for non-repudiation). mapping(bytes32 => PaymentMeta) public meta; struct PaymentMeta { bytes32 iso20022Hash; // keccak256 of pacs.008 XML bytes32 kycAttestationHash; // keccak256 of Travel Rule VC uint256 amount; address beneficiaryBank; // e.g. BankSA address uint64 uetrTimestamp; // block timestamp } event PaymentMinted(bytes32 indexed uetr, uint256 amount, address beneficiary); event PaymentBurned(bytes32 indexed uetr, uint256 amount); function mintForPayment( bytes32 uetr, address to, uint256 amount, bytes32 iso20022Hash, bytes32 kycAttestationHash, address beneficiaryBank ) external onlyRole(ISSUER_ROLE) { require(meta[uetr].amount == 0, "UETR exists"); require(iso20022Hash != bytes32(0), "pacs.008 required"); require(kycAttestationHash != bytes32(0), "KYC VC required"); meta[uetr] = PaymentMeta(iso20022Hash, kycAttestationHash, amount, beneficiaryBank, uint64(block.timestamp)); _mint(to, amount); emit PaymentMinted(uetr, amount, to); } function burnForRedemption(bytes32 uetr, uint256 amount) external onlyRole(ISSUER_ROLE) { _burn(msg.sender, amount); emit PaymentBurned(uetr, amount); } } BankSA deploys the same template as SarDepositTokenwith 2 decimals (the SAR ledger convention), or 18 if the network adopts internal scaling. SILVER's core primitive is conditional atomic settlement: one transaction moves both legs or reverts. contract SilverPvPSettlement is AccessControl, ReentrancyGuard { EurDepositToken public immutable eur; SarDepositToken public immutable sar; FXOracle public immutable fxOracle; struct SettlementInstruction { bytes32 uetr; address payerBank; // BankFR address address payeeBank; // BankSA address uint256 eurAmount; uint256 sarAmount; // derived from oracle rate * eurAmount bytes32 oracleQuoteId; // signed FX rate reference uint64 validUntil; // e.g. block.timestamp + 90s } event PvPSettled(bytes32 indexed uetr, uint256 eurAmount, uint256 sarAmount, uint256 rateScaled); // Atomic PvP: EUR debit + SAR credit in a single tx; reverts on any failure. function settlePvP( SettlementInstruction calldata ins, bytes calldata payerSig, // EIP-712 signed by BankFR bytes calldata payeeSig // EIP-712 signed by BankSA ) external nonReentrant { require(block.timestamp <= ins.validUntil, "Quote expired"); require(_verifySig(ins, payerSig, ins.payerBank), "Bad payer sig"); require(_verifySig(ins, payeeSig, ins.payeeBank), "Bad payee sig"); // Validate the oracle-signed rate matches the instruction (uint256 rateScaled, uint64 ts) = fxOracle.getQuote(ins.oracleQuoteId); require(block.timestamp - ts <= 90, "Stale FX"); require(ins.sarAmount == (ins.eurAmount * rateScaled) / 1e8, "Bad SAR calc"); // Atomic legs: both succeed or whole tx reverts eur.transferFrom(ins.payerBank, ins.payeeBank, ins.eurAmount); sar.mintForPayment(ins.uetr, ins.payeeBank, ins.sarAmount, /* iso20022Hash */ bytes32(ins.uetr), /* kycHash */ bytes32(ins.uetr), ins.payeeBank); emit PvPSettled(ins.uetr, ins.eurAmount, ins.sarAmount, rateScaled); } } | Contract | Deployed by | Privacy | Purpose | EurDepositToken | BankFR | Public state | ERC-20, 1:1 claim on EUR reserves at BankFR; mint and burn limited to BankFR's HSM-protected ISSUER_ROLE address. | SarDepositToken | BankSA | Public state | ERC-20, 1:1 claim on SAR reserves at BankSA; mint and burn limited to BankSA's ISSUER_ROLE address. | SilverPvPSettlement | Adhara (network deployer) | Public state | Atomic PvP engine; verifies both banks' EIP-712 signatures and a fresh FX quote. | SilverNetting | Adhara | Public state | Accumulates obligations over a window (e.g. 4 hours), computes the multilateral net and triggers PvP for net positions only; replicates the Khokha 2 liquidity-saving mechanism. | FXOracle | BankES | Public state | EUR/SAR mid, bid and ask quotes signed by BankES's node key, each valid 90 seconds and referenced by ID. | ComplianceRegistry | Joint | Tessera private group | Hashes of the Travel Rule Verifiable Credentials for each transaction; full VCs travel through Tessera. | ValidatorRegistry | Joint | Public state | Validator-set governance: 2-of-3 vote plus 14-day timelock (Onyx and Khokha 2 pattern). ### [id=besu-lifecycle] Transaction lifecycle: 16 steps The on-chain portion (steps 1–11) completes in under 30 seconds; with 2-second QBFT blocks the PvP transaction is final at inclusion. Steps 12–16 run intraday or end-of-day depending on the netting cycle. | # | Step | Besu-specific detail | Timing | 01 | Instruction | pacs.008 via BankFR's corporate API: Paris IBAN, Riyadh supplier IBAN, EUR amount, value date, beneficiary, LEI, purpose code. | <1 s | 02 | Travel Rule | BankFR sends the VC (originator LEI, jurisdiction, risk tier, sanctions-clear attestation) as a private Tessera transaction to BankSA's key and calls ComplianceRegistry.recordAttestation(uetr, vcHash). BankSA validates the LEI against GLEIF and returns a counter-VC the same way. | 1–3 s | 03 | FX rate | FXOracle.getLatestQuote("EUR","SAR"). BankES posts signed quotes every 30 seconds; BankFR receives a quote ID and rate (e.g. 4.1287). | <1 s | 04 | Signed instruction | BankFR builds the SettlementInstruction, hashes it under EIP-712 and signs with its HSM key, then sends it over Tessera. BankSA re-derives the SAR amount, verifies the quote and the pacs.008 against its XSD, and countersigns. No on-chain state change yet. | 1–2 s, no gas | 05 | Mint | EurDepositToken.mintForPayment(...)under ISSUER_ROLE records the payload and KYC hashes against the UETR and emits PaymentMinted, visible to all validators and observers. The XML never leaves BankFR. | 2–4 s, 1 block | 06 | Allowance | approve(silverPvPSettlement, amount). Production banks pre-approve a working credit line (e.g. €100M) at setup to keep this off the critical path. | 2 s | 07 | Atomic PvP | settlePvPchecks both signatures, quote age under 90 s and SAR = EUR × rate, then runs transferFrom(EUR leg) and mintForPayment(SAR leg). Any failure reverts both. | 2–4 s, ~250,000 gas | 08 | Beneficiary credit | BankSA's integration layer sees PvPSettledwith the matching UETR and credits the supplier's local IBAN account. | 1–2 s | 09 | Originator status | BankFR pushes a pacs.002 with status ACSC (AcceptedSettlementCompleted), the strongest positive ISO 20022 status, and the client's ERP marks the payment settled. | <1 s | 10 | Finality | 2-of-3 QBFT commit makes the block final. Ethereum mainnet's probabilistic finality (about 12 minutes to economic finality after the merge) would not support payment-system designation. | At inclusion | 11 | Audit trail | Transaction hash, payload hash, KYC hash, quote ID and EIP-712 signatures are bound to the UETR on all five nodes. The regulator observer produces feeds for the ACPR, Banco de España and SAMA; the auditor observer's trail supports SOC 1/SOC 2 attestation. | Automated | 12 | Netting | SilverNettingaggregates PvPSettledevents and computes net EUR obligations between each bank pair and net SAR positions. | Every 4 h or on demand | 13 | TARGET2 | BankFR and BankES submit the net pacs.009; BankES's bridge writes confirmation back via SilverNetting.confirmRtgsSettlement(cycleId, eurNetSettled). | TARGET2 hours | 14 | SARIE | BankSA settles net SAR through SARIE, operating since 1997, in a direct liability of SAMA. SAMA gets the netting summary from the regulator observer. | 07:30–16:30 AST | 15 | Burn | BankFR calls burnForRedemption(uetr, amount)on the EUR tokens BankSA holds (BankSA approves the burn in the cycle workflow); BankSA burns the SAR tokens redeemed to the supplier. | Post-RTGS | 16 | Reconciliation | The Besu integration layer feeds both core banking systems; the Tessera-held pacs.008, hash-bound since step 5, drives matching. | <2% exceptions ### [id=besu-fx] FX: EUR/SAR on-chain Because SAR is pegged to USD at 3.7500, EUR/SAR moves with EUR/USD and is thin at some hours, which shapes how rates are sourced and committed. BankES posts quotes through a postQuotefunction gated to its HSM-held oracle key; every transaction in a window references a quote ID whose signature any party can verify. contract FXOracle is AccessControl { bytes32 public constant ORACLE_ROLE = keccak256("ORACLE_ROLE"); struct Quote { bytes32 base; // "EUR" bytes32 quote; // "SAR" uint256 midScaled; // e.g. 412870000 = 4.1287 * 1e8 uint256 bidScaled; uint256 askScaled; uint64 postedAt; // block.timestamp at posting uint64 validUntil; // postedAt + 90 seconds address oracle; // BankES address (msg.sender) } mapping(bytes32 => Quote) public quotes; bytes32 public latestEurSarQuoteId; event QuotePosted(bytes32 indexed id, uint256 midScaled, uint64 postedAt); function postQuote(bytes32 base, bytes32 quote, uint256 midScaled, uint256 bidScaled, uint256 askScaled) external onlyRole(ORACLE_ROLE) returns (bytes32 id) { id = keccak256(abi.encode(base, quote, block.timestamp, msg.sender)); quotes[id] = Quote(base, quote, midScaled, bidScaled, askScaled, uint64(block.timestamp), uint64(block.timestamp) + 90, msg.sender); if (base == "EUR" && quote == "SAR") latestEurSarQuoteId = id; emit QuotePosted(id, midScaled, uint64(block.timestamp)); } function getQuote(bytes32 id) external view returns (uint256 midScaled, uint64 postedAt) { Quote storage q = quotes[id]; return (q.midScaled, q.postedAt); } } BankSA charges its institutional dealing spread over the oracle mid (typically 10–20 bp for wholesale flows) and keeps it as revenue; BankFR earns 5 bp flat on origination. The EVM's revert semantics make PvP the default: the same outcome CLS Bank achieves for major currency pairs through multi-currency cash accounts, implemented here as contract logic. Worked example A €5,000,000 payment. Oracle mid 4.1287 (posted 30 seconds earlier, valid 60 more). BankSA spread 12 bp gives a dealing rate of 4.1287 × 1.0012 = 4.1337, so the supplier receives SAR 20,668,500. BankSA FX revenue is SAR 24,772 (about €6,000 at mid); BankFR's fee is €2,500. All-in cost to the corporate is about 12 bp, against roughly 1.8–3.5% through correspondents (bank-published EUR/SAR retail-to-wholesale spreads). At €4 billion of annual corridor flow, about €5–8 million of extra margin stays with BankFR and BankSA. ### [id=besu-privacy] Privacy: Tessera, private state and zero-knowledge options By default every Besu validator sees every transaction, so SILVER layers privacy: only hashes reach public state; full payloads travel peer-to-peer through Tessera to the named parties; and zero-knowledge proofs (for example a zk-SNARK showing a payment is under a regulatory threshold without revealing the amount) can be added for sensitive cases. Personal data (originator name, IBAN, supplier identity, invoice references) therefore never enters public state, meeting GDPR and SAMA Cyber Security Framework residency and confidentiality rules; payloads sit only on the two parties' Tessera nodes in their own data centers. Tessera adapts the Quorum private-transaction pattern. Besu's original native private-transaction implementation (the Orion predecessor and early Tessera integration, later the Privacy Group API) was deprecated in Besu 22.x; GoQuorum-compatible private transactions follow the EEA Client Specification v8 (2024), which Besu, GoQuorum and Hyperledger Burrow implement. Production deployments in 2025–26 use one of three patterns: hash-binding with off-chain payload (SILVER, the most mature and the Khokha 2 choice), a Tessera-compatible companion deployment, or zero-knowledge shielding of sensitive fields (Aztec Connect-style designs adapted to permissioned Besu). Adhara recommends hash-binding for greenfield deployments in 2026 as simpler and more auditable, in line with the EBA's December 2024 view. ### ISO 20022 binding The keccak256 hash of the canonical pacs.008 XML is committed to EurDepositToken.meta[uetr].iso20022Hashat mint (example value 0x9a3f4b21d8e7c0a2f6b5e9...) while the XML travels through Tessera. BankFR cannot later claim a different payload belonged to the UETR, and BankSA cannot deny receiving the one it acknowledged. The message carries the originator's full legal name, structured address, LEI, IBAN, purpose code (TRPT for trade, SCTL for securities settlement), structured remittance data, reporting codes and the UETR. The sample message (structure shown in the [Fabric section](#fabric-iso)) uses pacs.008.001.08, settlement method INDA, MsgId BANKFR-20260415-00098765, created 2026-04-15T10:14:32Z, UETR 7c9e6679-7425-40de-944b-e07fc1f90ae7, EUR 5,000,000.00 from Paris Industrial Equipment SAS (Avenue des Champs-Élysées 88, Paris; LEI 969500N1B7PI4F1V2N06) to Riyadh Construction Holdings Ltd (LEI 5586009OOKK7HZJL8Z51), invoice INV-2026-RUH-2287, which BankSA's receivables system matches automatically. ### KYC, AML and the Travel Rule Each bank meets its own regime (ACPR and Banco de España; SAMA for BankSA) while the shared attestation flow satisfies the Travel Rule. Saudi AML/CFT is administered by SAMA and the Saudi Financial Investigation Unit (SAFIU) and is broadly FATF-aligned; Saudi Arabia has been a full FATF member since 2019. SAMA requires AML/CFT documentation for cross-border SAR payments above SAR 60,000 (about $16,000). | Requirement | Jurisdiction | Handling on Besu | AML/CFT screening | EU (AMLD6), SAMA AML | Structured name and LEI fed to each bank's engine for the originator (step 1) and the beneficiary (BankSA, before countersigning). | Travel Rule (FATF R.16) | EU TFR, SAMA | Tessera VC exchange at step 2; VC hashes in ComplianceRegistry; IVMS-101 format. | Sanctions | EU Sanctions Regulation; UN and Saudi lists | Independent checks on LEI and structured name; the Saudi list is maintained by SAFIU. | Transaction reporting | ECB, ACPR, BdE; SAMA | Automated feeds from the regulator observer; SAMA reporting follows Banking Control Law cross-border rules. | Data residency | GDPR; SAMA CSF | Personal data only in Tessera payloads at BankFR and BankSA, invisible to BankES and observers. | DORA | EU | BankFR and BankES treat the Besu node and SILVER as critical ICT; Adhara is managed as an ICT third-party provider. | SAMA Cloud Computing Framework | Saudi Arabia | BankSA's node runs in a SAMA-approved zone (typically AWS Bahrain or a Saudi-resident data center); SAMA pre-approval is needed for any cloud deployment handling customer data. ### [id=besu-reg] Regulation: EU and Saudi Arabia BankFR's token is a bank liability under CRD VI/CRR and the EBA report; DORA, TFR and TARGET2 rules apply as described in the [shared pattern](#pattern), with Adhara owing DORA resilience guarantees and audit rights. Saudi Arabia has no MiCA-style digital-asset regime: SAMA supervises digital settlement under the Banking Control Law and its rulebooks, and its stated direction (Aber, Agorá-related work, FinTech Saudi) is to fold tokenized wholesale payments into existing supervision. - Banking Control Law(Royal Decree M/5, 1966, as amended), supplemented by SAMA rulebooks on capital adequacy, liquidity and cross-border activity. BankSA's token activity is deposit-taking: the SAR token represents an existing deposit liability. - SAMA Open Banking Framework(Phase II, 2024): API-based interbank data sharing with strong consent and security; SAMA's preference for supervisor-visible architecture matches the observer-node design. - SAMA Cyber Security Framework(2017, current version 2023): mandatory for supervised entities; covers the Besu node, Tessera and HSMs. Any new core-banking-adjacent system, including the Besu integration, needs SAMA pre-approval. - SAMA Cloud Computing Regulatory Framework(2023): residency rules apply to Tessera payloads. - Project Aber and Project Agorá.Agorá, announced by the BIS in April 2024, joins seven central banks (Bank of France for the Eurosystem, Bank of Japan, Bank of Korea, Bank of Mexico, Swiss National Bank, Bank of England, Federal Reserve Bank of New York) with private banks convened by the Institute of International Finance, testing tokenized wholesale central bank money and tokenized deposits on a shared programmable platform with a permissioned EVM-style stack among the candidates. SAMA takes part in adjacent BIS work programmes. - Vision 2030 and FinTech Saudi(SAMA with the Capital Market Authority): tokenization is a modernization priority; the FinTech Saudi sandbox and the Regulatory Sandbox for Innovation allow supervised live-money testing. AML/CFT supervision is shared by SAMA, SAFIU and the CMA. Compatibility finding Both jurisdictions classify the on-chain instrument as a bank deposit liability under standard prudential supervision, so no novel cross-border legal mechanism is needed and regulatory risk is well below that of a non-bank stablecoin network on the same corridor. Remaining risk sits in future SFD designation and in SAMA's explicit no-objection for production cross-border flows beyond the sandbox. ### [id=besu-settlement] RTGS net settlement and liquidity Through correspondents, a €5M EUR→SAR payment needs €5M (or the SAR equivalent) pre-funded in nostros. Here the corporate is debited at once, the supplier is credited within seconds, and RTGS later settles only net positions. If in one 4-hour cycle BankFR sends €30M to Riyadh and BankSA sends €18M to Paris, the net obligation is €12M against €48M gross; at 5%, that frees about €1.8M a year in foregone yield for a single 4-hour cycle. | Layer | Mechanism | Asset | Timing | Finality | On-chain (SILVER) | Atomic PvP, QBFT | EUR deposit token (BankFR liability) against SAR deposit token (BankSA liability) | <10 s | Technical finality at block inclusion; legal finality on RTGS confirmation | TARGET2 | Intraday net, pacs.009 | ECB reserves | Every 4 h in the TARGET2 window | Final in ECB money | SARIE | Intraday net, SARIE format | SAMA reserves | 07:30–16:30 AST | Final in SAMA money TARGET2 runs on CET/CEST and SARIE on Arabia Standard Time (UTC+3, no daylight saving). Both are open roughly 09:00–14:30 CET (11:00–16:30 AST); cycles outside that window queue SARIE instructions for the next AST business day. Saudi banks work Sunday to Thursday, so Friday cycles cannot settle the SAR leg until Sunday morning and Sunday EUR cycles wait for Monday. Intraday cycles are therefore scheduled in the overlap on the four common days, Monday to Thursday. ### [id=besu-risks] Besu-specific risks - Governance.Beyond the shared questions: who holds the UUPS upgrade keys for SILVER and the token contracts. The Adhara/Khokha 2 model places them, with the operating contract, in a Mauritius- or Luxembourg-based SPV; that is the commonest structure but not the only one. - Legal finality.Requires ECB/ACPR engagement on the EU side and SAMA on the Saudi side. - Two key classes.A compromised ISSUER_ROLE key mints unbacked tokens. One compromised QBFT validator key gives an attacker 1 of 3 votes, too few to forge a block, but costs the bank its consensus contribution; two compromised keys allow forged blocks. Keep validator keys HSM-resident in physically separate data centers, with timelocked rotation through ValidatorRegistry. - Smart-contract bugs.The dominant operational risk: an exploitable Solidity bug can drain or freeze tokens, whereas a bug in a Kotlin CorDapp typically makes transactions fail verification. Require audits by at least two independent firms (e.g. ChainSecurity, OpenZeppelin, Trail of Bits) with formal verification of PvP atomicity, a continuous bug bounty, UUPS upgrades with a 14-day minimum timelock, and insurance (the Lloyd's syndicate market for permissioned DLT contract cover is small but functional as of 2026). Solidity buys a far larger developer pool and toolset at the cost of a more attack-prone primitive. - Vendor concentration.SILVER is Adhara proprietary IP. Mitigate with source-code escrow at a regulated trust, contractual rights to fork on insolvency or material breach, DORA critical-ICT classification, and a migration path to open-source options (Hyperledger Cacti or Fabric Token SDK patterns). The exposure resembles R3 vendor risk on Corda. - Sequencing for BankSA.SAMA no-objection under the Cyber Security and Cloud Computing Frameworks, the FinTech Saudi sandbox with synthetic transactions, explicit SAMA approval for production cross-border tokenized SAR, then go-live. EU banks follow the shared sequence with ACPR or Banco de España and a DORA assessment covering SILVER. SAMA's Aber and Agorá-related familiarity shortens supervisory engagement without removing it. Besu sources: [besu.hyperledger.org](https://besu.hyperledger.org/)(QBFT documentation); EEA Client Specification v8 (2024); [jpmorgan.com/onyx](https://www.jpmorgan.com/onyx); SARB Project Khokha 2 final report (2022) and [adhara.io](https://adhara.io); [BIS Project Agorá](https://www.bis.org/about/bisih/topics/fmis/agora.htm); [sama.gov.sa](https://www.sama.gov.sa); [fintechsaudi.com](https://fintechsaudi.com). [Back to comparison](#compare) [id=canton] Canton Network · Daml · four FMIs ## [id=canton-h] Canton: four FMIs settled in one atomic transaction A US asset manager pledges DTCC-custodied tokenized US Treasuries through Broadridge DLR as intraday repo collateral against tokenized euro commercial paper held at Clearstream D7, with end-of-day mobilization into Euroclear's D-FMI for cross-border redeployment. Each FMI runs its own Canton participant node and Daml application. Treasuries, EUR commercial paper, gilts and Eurobonds settle atomically in one Daml transaction spanning all four applications with no bilateral reconciliation; cash legs settle in TARGET2 (EUR) and Fedwire (USD) at end of cycle. - Canton Network - Daml 3.x - Sub-transaction privacy - Atomic DvP/PvP - ISO 20022 / ISO 11179 - CSDR / MiCA / DORA - SEC Rule 17Ad-22 - UK FMI rules - NBB / FSMA ### Why these FMIs and why Canton These four touch most of the world's settled securities flow. Clearstream and Euroclear together hold roughly EUR 80 trillion in custody; DTCC clears and settles about USD 2.5 quadrillion of US securities transactions a year; Broadridge DLR, live on Canton since June 2021, has processed more than USD 1.5 trillion of intraday repo, with peak days above USD 50 billion. Each has committed production infrastructure to Canton. Canton's distinguishing property is privacy-preserving atomic composability. One transaction can span independently operated applications, each running its own Daml logic on its own participant, while all sub-transactions commit together or none do and each party sees only what it is authorized to see. A bond settlement at Clearstream and a Treasury delivery at DTCC can settle as one event without either seeing the other's contract. Other enterprise ledgers force a trade-off: a shared global ledger (Ethereum, Besu, Quorum) where everyone sees all data unless zero-knowledge proofs are added at real cost, or bilateral partitioning (Corda) that cannot compose atomically beyond the parties to a single transaction. That is why four institutions whose competitive position depends on confidentiality chose Canton. The four FMIs also map to four asset classes and regimes. Clearstream's D7 DLT went live in November 2025 issuing EUR debt under the German Electronic Securities Act (eWpG) and EU CSDR. DTCC's ComposerX targets Q2 2026 production for tokenized DTC-custodied Treasuries under SEC Rule 17Ad-22 and CFTC rules. Broadridge DLR is regulated as a US transfer agent and broker-dealer service. Euroclear, a Canton Foundation member and Super Validator, has tokenized gilts, Eurobonds and gold for collateral mobility under NBB supervision and, where applicable, the Luxembourg DLT Pilot Regime. Today, mobilizing Treasury collateral against a euro obligation needs triparty agents, several correspondent legs and hours or days; on Canton it settles in seconds, with each FMI keeping control of its own register. ### [id=canton-topology] Topology: participants and the Global Synchronizer A Canton network is a federation of participant nodes, each owned by a legal entity and storing only contracts on which its hosted parties are stakeholders. Synchronizers order messages and provide finality but only ever handle encrypted payloads addressed to the relevant participants. Regulators (BaFin, SEC, FCA, NBB, ESMA) hold read-only Daml party rights, with a DORA-compliant audit trail and GDPR data minimization. Participant 1 · EUR debt CSD #### Deutsche Börse · Clearstream D7 German CSD supervised by BaFin and the Bundesbank, with ICSD operations under Luxembourg's CSSF. Supplies tokenized EUR commercial paper and short-term debt as collateral and settlement medium. App: ClearstreamD7, Frankfurt/Luxembourg. Party clearstream-d7::1220a8f... Assets EUR commercial paper, structured notes Cash leg TARGET2 / T2S settlement bank Role Participant, observer of cross-app DvP Participant 2 · US securities CSD #### DTCC · ComposerX Central US post-trade FMI: DTC is the national CSD, NSCC the equities CCP, FICC the fixed-income CCP. ComposerX, built with Digital Asset, supplies tokenized Treasuries as high-quality collateral. App: DtccComposerX, Jersey City/Tampa. Party dtcc-composerx::1220c4b... Assets Treasury notes, bonds, bills Regulator SEC (Rule 17Ad-22), CFTC, FRBNY Cash leg Fedwire / NSS settlement bank Role Participant, Super Validator candidate Participant 3 · repo platform #### Broadridge · Distributed Ledger Repo NYSE-listed (BR) post-trade processor. Orchestrates the repo itself: agreement template, term, haircut, substitution rights and unwind. App: BroadridgeDLR, New York. Party broadridge-dlr::1220e7f... Regulator SEC (transfer agent), FINRA Counterparties Goldman Sachs, JPMorgan, BNY, Citi and others Role Participant, registry for repo terms Participant 4 · EU/UK collateral CSD #### Euroclear · D-FMI Euroclear Bank (Brussels), the largest ICSD by assets under custody, is supervised by the NBB and FSMA; Euroclear UK & International (formerly CREST) is the UK CSD under FCA and Bank of England oversight. D-FMI tokenizes gilts, Eurobonds and gold. App: EuroclearDFMI. Party euroclear-dfmi::12203a2... Assets Gilts, Eurobonds, allocated gold Cash leg TARGET2, T2S, CHAPS settlement bank Role Participant, Super Validator, Foundation member The Global Synchronizer is run by 13 Super Validators (as of 2026), including Goldman Sachs, DTCC, Broadridge, Euroclear, BNP Paribas, SBI Digital Markets, Tradeweb and Cumberland Labs, under the Global Synchronizer Foundation, a non-profit independent of any participant. It has three components: a sequencer that orders encrypted messages, a mediator that coordinates two-phase commit, and a topology manager that publishes the party-to-participant mapping. Consensus is Tendermint-style BFT with deterministic finality at the sequencer, and a global timestamp. Validator selection, rotation and slashing are governed on-chain through the Canton Coin governance module. An FMI can also run a local synchronizer for intra-application traffic (for example internal D7 settlement) and use the Global Synchronizer only for cross-FMI transactions, keeping control of its own latency, fees and governance. | Counterparty | Role | Hosted on | Function | AssetMgrUS LLC | US asset manager | Goldman Sachs DAP participant | Repo cash provider; pledges nothing, receives EUR commercial paper as a cash equivalent. | EuroDealer SA | European broker-dealer | BNP Paribas participant | Collateral provider; pledges Treasuries (at DTCC) and gilts (at Euroclear) and borrows EUR commercial paper for intraday liquidity. ### [id=canton-daml] Daml templates, choices and parties Solidity describes computation on a replicated state machine and Corda's Kotlin contracts verify state transitions; Daml, created by Digital Asset, describes the rights and obligations of named parties. Each template names signatories (whose authority creates the contract), observers (who see but cannot act) and controllers (who may exercise a given choice). Clauses become choices, signature requirements become signatories, information rights become observer disclosures. At DTCC, UsTreasuryTokenis a registered representation of a security that stays in DTC custody under the existing legal structure and the DTCC tokenization rulebook. -- Daml 3.x: UsTreasuryToken.daml module DtccComposerX.UsTreasuryToken where template UsTreasuryToken with issuer : Party -- DTCC holder : Party -- current beneficial owner cusip : Text -- CUSIP identifier faceAmount : Decimal -- USD face value maturity : Date -- maturity date couponRate : Decimal -- annualized coupon custodian : Party -- always DTC rulebookHash : Text -- SHA-256 of governing rulebook regulators : [Party] -- SEC, FRBNY observers where signatory issuer, holder observer custodian, regulators key (issuer, cusip, holder) : (Party, Text, Party) maintainer key._1 -- Transfer of beneficial ownership; new holder must authorize choice Transfer : ContractId UsTreasuryToken with newHolder : Party controller holder, newHolder do create this with holder = newHolder -- Pledge to a Broadridge DLR repo contract; non-consuming so the -- token continues to exist but is encumbered by the pledge ref. nonconsuming choice PledgeToRepo : ContractId Pledge with repoCid : ContractId BroadridgeDLR.RepoAgreement pledgee : Party controller holder do create Pledge with collateral = self pledgor = holder pledgee = pledgee repoRef = repoCid released = False Clearstream's template encodes both the security and its issuance and transfer rules under eWpG. -- ClearstreamD7.EurCommercialPaper.daml template EurCommercialPaper with issuer : Party -- corporate issuer csd : Party -- Clearstream Banking AG holder : Party isin : Text -- ISIN under eWpG registry faceAmount : Decimal -- EUR face value maturity : Date eWpGRegistry : Text -- crypto-securities registry ref payloadHash : Text -- ISO 20022 seev.031 hash regulators : [Party] where signatory issuer, csd, holder observer regulators key (csd, isin, holder) : (Party, Text, Party) maintainer key._1 choice Transfer : ContractId EurCommercialPaper with newHolder : Party controller holder, csd, newHolder do create this with holder = newHolder -- Atomic DvP: deliver this CP against a UsTreasuryToken pledge -- spans Clearstream + DTCC + Broadridge in a single Daml tx choice DeliverAgainstTreasuryPledge : ContractId EurCommercialPaper with newHolder : Party treasuryPledge : ContractId DtccComposerX.Pledge repoAgreement : ContractId BroadridgeDLR.RepoAgreement controller holder, newHolder do -- exercise verifies the pledge exists and matches the repo pledge <- fetch treasuryPledge repo <- fetch repoAgreement assertMsg "pledge must back this repo" (pledge.repoRef == repoAgreement) create this with holder = newHolder Broadridge holds the repo contract (agreement, term, haircut, repurchase price, substitution and unwind) and references collateral on the other three FMIs by ContractId without copying their state. -- BroadridgeDLR.RepoAgreement.daml template RepoAgreement with cashProvider : Party -- AssetMgrUS collProvider : Party -- EuroDealer SA operator : Party -- Broadridge cashAmount : Decimal -- USD cash leg cashCurrency : Text -- "USD" haircut : Decimal -- e.g. 0.02 = 2% repoRate : Decimal -- annualized % openTime : Time closeTime : Time -- intraday close collateralRefs : [AnyContractId] -- pledged tokens (DTCC, EUC) masterAgreement : Text -- GMRA 2011 reference + hash regulators : [Party] where signatory cashProvider, collProvider, operator observer regulators -- Substitute one collateral piece for another, mid-term choice Substitute : ContractId RepoAgreement with oldRef : AnyContractId newRef : AnyContractId controller collProvider, operator do create this with collateralRefs = newRef :: filter (/= oldRef) collateralRefs -- Unwind: release collateral, return cash + interest choice Unwind : () controller cashProvider, collProvider, operator do return () Euroclear's D-FMI re-pledges a gilt or Eurobond across jurisdictions while the asset record stays on Euroclear's ledger; MobiliseToTripartydoes the work. -- EuroclearDFMI.CollateralMobility.daml template TokenizedGilt with csd : Party -- Euroclear UK & International holder : Party isin : Text faceAmount : Decimal -- GBP face value maturity : Date regulators : [Party] -- FCA, BoE, NBB where signatory csd, holder observer regulators choice MobiliseToTriparty : ContractId TripartyAllocation with triparty : Party -- Euroclear acting as triparty agent receiver : Party -- collateral receiver repoRef : ContractId BroadridgeDLR.RepoAgreement controller holder, triparty do create TripartyAllocation with gilt = self giver = holder receiver = receiver agent = triparty repoRef = repoRef releasedAt = None Authority model DeliverAgainstTreasuryPledgefetches a contract from the DTCC package. Fetching requires the fetcher to be an observer or stakeholder, and the fetched contract's signatories grant no transitive authority. Cross-FMI atomicity comes from Canton's two-phase commit at the synchronizer, so each FMI's code stays independently auditable and under its own control. ### [id=canton-privacy] Sub-transaction privacy When a transaction is submitted, the participant runtime splits it into a tree of sub-transactions, each with its informees (the parties that must see it to validate or be informed). It builds a per-participant view containing only the sub-transactions whose informees it hosts and encrypts each view under the receiving participant's key. The sequencer orders the encrypted blobs and the mediator coordinates commit without decrypting any of them, which is how DTCC, Clearstream and Euroclear settle one operation without seeing each other's books. | Sub-transaction | Informees | Visible to participants | Hidden from | UsTreasuryToken.PledgeToRepo | EuroDealer, Broadridge, DTCC, SEC observer | BNP Paribas, Broadridge, DTCC | Clearstream, Euroclear, AssetMgrUS | RepoAgreement (create) | AssetMgrUS, EuroDealer, Broadridge, SEC, FCA | Goldman Sachs DAP, BNP Paribas, Broadridge | DTCC, Clearstream, Euroclear (linked refs only) | EurCommercialPaper.DeliverAgainstTreasuryPledge | AssetMgrUS, EuroDealer, Clearstream, BaFin observer | Goldman Sachs DAP, BNP Paribas, Clearstream | DTCC, Broadridge, Euroclear (opaque commit only) | TokenizedGilt.MobiliseToTriparty | EuroDealer, Euroclear, FCA, BoE, NBB observers | BNP Paribas, Euroclear | DTCC, Clearstream, Broadridge, AssetMgrUS ### [id=canton-lifecycle] Transaction lifecycle: 18 steps An intraday repo opens in the morning: USD 250 million face of Treasuries pledged through DTCC plus GBP 50 million of gilts mobilized through Euroclear, against EUR 230 million of commercial paper delivered from Clearstream. It unwinds at end of day after a mid-cycle substitution. | # | Phase | What happens | Clock | 01 | Negotiation | EuroDealer and AssetMgrUS agree terms on Tradeweb: USD 250M cash, 2% haircut, 5.32% annualized, open 09:30 ET, close 15:30 ET, basket of Treasuries and UK gilts; matched and confirmed. | T+0s | 02 | Negotiation | Tradeweb posts an ISO 20022 trea.001 confirmation through its Canton API connector to Broadridge, with the GMRA 2011 reference, economics and Daml party IDs. | T+1s | 03 | Pre-settlement | Broadridge proposes the RepoAgreementwith signatories AssetMgrUS, EuroDealer and Broadridge; Goldman DAP and BNP nodes authorize automatically within pre-set trading limits. | T+2s | 04 | Pre-settlement | Eligibility choice fetches read-only projections of the Treasury and gilt contracts: rating AA or better, maturity 30 years or less, daily price within 0.5% of indicative. | T+3s | 05 | Pre-settlement | KYC VCs from LSEG Risk Intelligence (US side) and Fenergo (European side) attach as hashes; full VCs travel off-ledger through the Canton Operator API. | T+3s | 06 | Atomic settlement | BNP's node, for EuroDealer, authors one command with four choices: PledgeToRepo(DTCC), MobiliseToTriparty(Euroclear), DeliverAgainstTreasuryPledge(Clearstream), RepoAgreement.Activate(Broadridge). | T+4s | 07 | Atomic settlement | BNP splits the transaction into per-informee views, encrypts each under the recipient's TLS-pinned public key and sends one signed message to the sequencer. | T+4.1s | 08 | Atomic settlement | Sequencer assigns a global sequence number and broadcasts; BFT ordering finality in under 500 ms. | T+4.5s | 09 | Atomic settlement | DTCC, Clearstream, Broadridge and Euroclear decrypt their views and validate in parallel: authorization, haircut math, eligibility, signatures, business rules. | T+5s | 10 | Atomic settlement | Participants return signed confirmations to the mediator within the timeout (default 30 s; 5 s here). All positive gives a commit Result; any rejection or timeout rolls everything back. | T+5.5s | 11 | Atomic settlement | Each participant applies its view: DTCC records the pledge, Clearstream the CP transfer, Euroclear the gilt mobilization, Broadridge the active repo. The four ledgers agree by construction. | T+6s | 12 | Cash leg | AssetMgrUS's custodian BNY Mellon receives an instruction through Broadridge's US payment gateway and sends USD 250M by Fedwire to EuroDealer's USD nostro at JPMorgan Chase; the securities leg is already irrevocable. | T+30s | 13 | Substitution | At 12:15 ET EuroDealer needs its USD 100M 4.25% 2034 note and exercises Substitute, swapping in USD 102M of the 4.50% 2032 note (post-haircut); one atomic transaction across DTCC and Broadridge. | T+2h45m | 14 | Unwind | At 15:30 ET closeTimetriggers an unwind proposal that returns the CP, releases the Treasury and gilt pledges, and closes the repo. | T+6h | 15 | Unwind | Same projection-and-confirm flow across all four ledgers, about 1.5 seconds end to end. | T+6h+1.5s | 16 | Cash settle | EuroDealer wires USD 250M plus interest (250M × 5.32% × 6/24/365 ≈ USD 9,110) by Fedwire; the GMRA repo is closed operationally and legally. | T+6h+30s | 17 | Reporting | Reports derive from on-ledger events: ESMA SFTR for the European leg via DTCC's GTR, SEC Rule 10c-1a for the US leg. | T+6h+5m | 18 | Reconciliation | Each FMI reconciles against its legacy DTC, Clearstream, Euroclear and Broadridge books; every change was atomic and signed by all stakeholders, so zero breaks. | EOD The step 06 command composes the four choices into one tree. Either all commit or none do; rollback is at tree level, and no FMI needs to trust another's middleware. Each FMI's Daml package is independently signed and version-pinned in the topology manager, and cross-package fetches require observer status. -- Authored on BNP's participant on behalf of EuroDealer. -- Single Daml command, four choices, four FMIs, one atomic commit. submitMulti [eurodealer, assetMgr] [-- read-as: Broadridge regulators] do -- (1) Pledge USD 250M Treasury at DTCC pledgeCid <- exerciseCmd treasuryCid PledgeToRepo with repoCid = repoProposalCid pledgee = broadridgeParty -- (2) Mobilise GBP 50M gilts at Euroclear tripCid <- exerciseCmd giltCid MobiliseToTriparty with triparty = euroclearTripartyParty receiver = broadridgeParty repoRef = repoProposalCid -- (3) Deliver EUR 230M CP at Clearstream against the Treasury pledge newCpCid <- exerciseCmd cpCid DeliverAgainstTreasuryPledge with newHolder = eurodealer treasuryPledge = pledgeCid repoAgreement = repoProposalCid -- (4) Activate the repo at Broadridge: only signs if 1-3 succeed activeRepoCid <- exerciseCmd repoProposalCid Activate with treasuryPledgeRef = pledgeCid giltAllocationRef = tripCid cpDeliveryRef = newCpCid return activeRepoCid Today the same flow needs a tri-party agent (BNY Mellon or JPMorgan), bilateral SWIFT confirmations among four institutions, several end-of-day reconciliations and a settlement window of hours, with failed substitutions and breaks adding risk and capital cost. Canton compresses it into one atomic operation of about 6 seconds. ### [id=canton-cash] Cash leg and Canton Coin Cash uses conventional RTGS (Fedwire for USD, TARGET2 for EUR) because deposit-token and CBDC infrastructure is still in pilot in both jurisdictions. A dedicated CashTokenDaml application on the same network would later make the whole DvP intra-ledger. Canton Coin (CC), the Global Synchronizer's native asset, only meters and pays for sequencing, mediation and storage. Fees are computed deterministically from transaction size and complexity and paid by the submitting participant; Super Validators earn CC for correct validation. The Foundation governs supply on-chain: minting tied to usage growth, burning of unused balances, capped issuance. The FMIs hold CC only as operating reserves for fees, much like a SWIFT membership pre-fund; it is not a settlement asset. | Currency | Today | 2026 path | 2027+ path | USD | Fedwire RTGS bridge | FedNow API for sub-RTGS values | Wholesale CBDC pilot or tokenized bank deposits as a Daml CashToken | EUR | TARGET2 RTGS bridge | ECB wholesale digital euro pilot (Eurosystem TIPS extension) | Tokenized euro deposit token under MiCA Title III, or wholesale CBDC | GBP | CHAPS RTGS bridge | BoE RTGS Renewal Programme ISO 20022 link | Tokenized sterling (BoE wholesale CBDC pilot, Project Rosalind) ### ISO 20022 inside Daml contracts Each contract stores the SHA-256 hash of a canonicalized ISO 20022 payload held off-ledger in the FMI's message store, so T+1 SFTR, MiFIR and CSDR reporting comes from the same source as the settlement record and the trade-versus-reporting reconciliation disappears. | Daml field | ISO 20022 message | Purpose | RepoAgreement.payloadHash | trea.001 trade confirmation | Canonical trade economics for SFTR | UsTreasuryToken.payloadHash | seev.031 securities settlement | Settlement instruction binding for DTC books | EurCommercialPaper.payloadHash | seev.031 + seev.039 | Settlement and corporate action notification | TripartyAllocation.payloadHash | colr.016 triparty collateral | Allocation under the triparty agreement | CashLeg.payloadHash | pacs.009 FI-to-FI credit transfer | RTGS cash settlement instruction ### KYC, AML and the Travel Rule AML duties stay with each FMI: DTCC under the FinCEN Bank Secrecy Act, Clearstream under Germany's GwG and the EU AMLR (in force July 2027), Euroclear under Belgian AML law and the AMLR, Broadridge under FinCEN transfer-agent rules. Each FMI keeps a KycAttestationtemplate signed by its compliance party and the counterparty, held privately on its participant. A cross-FMI proposal exercises the non-consuming VerifyAttestationchoice, which returns only a boolean. Travel Rule data moves off-ledger through the Operator API in a Travel Rule Protocol envelope (e.g. TRISA, OpenVASP); its SHA-256 hash is bound to the settlement, and regulators with observer rights can request the envelope through supervision channels and check it against the hash. ### [id=canton-reg] Regulation: EU, US, Belgium and the UK | Jurisdiction | Entities | Rules | European Union | Clearstream Banking AG (CSD under CSDR, Reg. 909/2014; BaFin and Bundesbank); D7 runs in the eWpG crypto-securities registry (eWpG of June 2021) | CSDR and RTS 2017/389 (settlement discipline, reconciliation, finality); eWpG registry obligations; MiCA only where ARTs or EMTs are touched (pure securities are out of scope); DORA; EU AMLR (2024/1624, July 2027); DLT Pilot Regime sandbox (LU) | United States | DTC (registered clearing agency under Rule 17Ad-22 and Exchange Act §17A); FICC (Treasury and MBS CCP); Broadridge (SEC transfer agent, SEC/FINRA broker-dealer channels) | Rule 17Ad-22 standards including segregation; Treasury clearing mandate (Rule 17ad-22(e)(18), final rule 13 December 2023, phased through 2026); Rule 10c-1a securities loan reporting (compliance January 2026); BSA/FinCEN with SAR filings; OFAC screening at issuance and transfer; Reg SHO where applicable | Belgium | Euroclear Bank (credit institution and CSD; NBB prudential, FSMA conduct) | NBB/FSMA prudential rules; CSDR with T+1 from October 2027; Belgian AML Law (2017) until replaced by the AMLR in July 2027; Banking Act (2014) recovery and resolution; DORA | United Kingdom | Gilt leg via Euroclear UK & International | Bank of England FMI rules; FCA CSDR-equivalent rules retained after Brexit; Uncertificated Securities Regulations 2001 as amended for digital securities; FMI Digital Securities Sandbox; UK MLR 2017; Project Rosalind (BoE/BIS wholesale CBDC API design) Each regulator holds Daml observer rights over contracts in its perimeter: real-time, read-only, integrity-guaranteed visibility of the same state the supervised entity sees. That is stronger than today's T+1 reporting feeds and answers a long-standing ESMA and SEC concern about post-trade data integrity. No FMI cedes supervisory authority and no party sees data outside its lawful basis. ### Governance | Body | Domicile | Scope | Members (selected) | Global Synchronizer Foundation | Switzerland (non-profit) | Synchronizer protocol, fees, validator slashing | 13 Super Validators including Goldman, DTCC, Broadridge, Euroclear, BNP, SBI, Tradeweb, Cumberland | Canton Foundation | Switzerland | Network standards, Daml package signing, interoperability, Canton Coin parameters | Goldman Sachs, DTCC, Broadridge, Euroclear, BNP Paribas, Deutsche Börse, Digital Asset | Per-application governance | Each FMI's home | Application rulebook, asset registries | Clearstream, DTCC, Broadridge, Euroclear Super Validator selection, parameter changes and protocol upgrades are voted through on-chain governance contracts written in Daml. ### [id=canton-risks] Canton-specific risks - Synchronizer outage.If BFT quorum is lost (more than f Byzantine failures among the 13), nothing new commits. Local synchronizers keep intra-application flows running; cross-FMI flows pause but cannot half-settle. Foundation SLA target: 99.95% per quarter. - Participant compromise.Keys are rotated and revoked through the topology manager with multi-signature approval from the FMI's governance and the Canton Foundation; affected contracts can be quarantined by a choice that needs the regulator observer's signature. - Package version skew.Transactions are pinned to package hashes, so every affected participant must install an upgrade before old contracts retire; the Canton Foundation runs the upgrade ceremony. - Stuck in flight.A mediator timeout rolls the transaction back; pending items such as pledges can be released by a time-bounded Cancelchoice after a 24-hour expiry with no counterparty action. - Recovery and resolution.DTCC stays under Title VIII of Dodd-Frank, Clearstream and Euroclear under the EU CCPR/CSDR resolution regime, Broadridge under SEC Reg SCI as a critical service provider. Observer rights give resolution authorities a real-time authoritative book of positions. Canton sources: Canton institutional partner registry (canton.wiki/learn/canton-institutional-partners) and Foundation member list (canton.network), retrieved April 2026; Broadridge DLR statements and Q4 2025 earnings disclosures; Digital Asset, "Canton Network Architecture Whitepaper" (2024) and Daml documentation (docs.digitalasset.com/build/3.5); Clearstream, "D7 DLT: Clearstream Launches Tokenized Securities Platform", 4 November 2025; Canton Network, "DTCC and Digital Asset Partner to Tokenize DTC-Custodied U.S. Treasury Securities on the Canton Network", 17 December 2025; Digital Asset and Euroclear, "Unlocking Collateral Mobility through Tokenization: Gilts, Eurobonds and Gold" (2024 pilot whitepaper) and "Digital Asset and Euroclear Start First Project Phase", 25 February 2025; Global Synchronizer Foundation governance documentation (2025–2026; Super Validator list as of Q1 2026) and Canton Coin economic specification v1.x (2024–2026). The Daml shown is illustrative and simplified; production code adds substantially more validation, error handling and upgrade scaffolding, and real deployments differ by each FMI's architecture, rulebook and supervisor. [Back to comparison](#compare) [id=corda] R3 Corda · EUR/AED ## [id=corda-h] R3 Corda: two European banks and a UAE bank A German corporate pays a Dubai supplier. BankFR (Frankfurt) originates and issues EUR tokens, BankNL (Amsterdam) is the EUR liquidity node and FX oracle, and BankAE (Dubai, ADGM) receives and redeems in AED. Three participant nodes and a BFT notary cluster run Corda 4.x/5.x Enterprise with Corda Token SDK FungibleTokenstates, Kotlin CorDapps and AMQP point-to-point messaging, with the pacs.008 carried inside token metadata. - Corda Enterprise - Corda Token SDK - CorDapp / Kotlin - pacs.008 - MiCA - CBUAE PTSR - ADGM FSRA - DORA ### Why this corridor and Corda EUR/AED is one of the largest routes with no production tokenized A2A network. Europe–UAE trade exceeded $50 billion a year as of 2024, concentrated in energy, real estate, logistics and professional services, on correspondent rails that are costly, slow and squeezed by de-risking at both ends. UAE banks have explicit licensing paths for deposit-token infrastructure under the CBUAE Payment Token Services Regulation (PTSR, issued June 2024, in force August 2025) and ADGM FSRA frameworks; the UAE regime is designed around programmable settlement on permissioned ledgers. - AMQP point-to-point messaging means each bank sees only the states it is party to. Bilateral privacy is a legal requirement under GDPR and MiCA confidentiality obligations in the EU and ADGM data protection rules in the UAE. - Kotlin/JVM CorDapps map onto deposit-token payment semantics: explicit authorization by all signers, deterministic finality once the notary signs, and X.509 legal-entity identity. - Corda has the widest documented production record in regulated networks: SIX Digital Exchange, HQLAx, the UK Regulated Liability Network, and wholesale CBDC pilots including Project Aber. - R3's European footprint (SDX under the Swiss DLT Act, Euroclear D-FMI, the UK RLN pilot with Barclays, HSBC, Lloyds and others) and its work with CBUAE, ADGM FSRA and DFSA sandboxes shorten approval for new corridors. ### [id=corda-topology] Topology and nodes Four Corda nodes (three participants and a notary cluster), a shared network map service (X.509 identity registry and CorDapp versions), and optional bridges to SWIFT and to TARGET2/UAE RTGS. No bank is hosted by R3 or any single third party. Node A · originating bank #### BankFR · Frankfurt Licensed by BaFin; within MiCA where it issues e-money tokens under Title III; DORA-compliant since January 2025. Runs Corda Enterprise 4.x in Frankfurt and mints EUR FungibleTokenstates against its reserves. X.509 O=BankFR, L=Frankfurt, C=DE Vault EUR FungibleToken HSM Thales Luna 7 DB PostgreSQL 14 AMQP Apache Artemis (in-node) CorDapps PaymentInitiatorFlow, AMLComplianceCorDapp Links BaFin reporting gateway, TARGET2 Node B · liquidity node #### BankNL · Amsterdam Licensed by De Nederlandsche Bank; MiCA and DORA. Originates nothing here; holds surplus EUR token positions for intraday liquidity and hosts the FX oracle CorDapp. X.509 O=BankNL, L=Amsterdam, C=NL Vault EUR FungibleToken (liquidity pool) CorDapp FXOracleResponder (EUR/AED spot) DB PostgreSQL 14 Links ECB/DNB reporting, TARGET2 Node C · receiving bank #### BankAE · Dubai (ADGM) Incorporated in ADGM and licensed by the FSRA as a Deposit-Taking Institution with digital asset permissions; also holds a CBUAE Payment Token Services licence for dirham payment tokens under the PTSR. Issues and redeems AED tokens, crediting AED on-ledger at the spot rate. X.509 O=BankAE, L=Dubai, C=AE Vault AED FungibleToken HSM AWS CloudHSM DB PostgreSQL 14 CorDapps PaymentResponderFlow, FXConversionCorDapp Links UAE RTGS (CBUAE) The notary cluster is Corda's only consensus mechanism. It confirms that the input states a transaction consumes are unspent and issues a timestamped signature that makes the transaction irrevocable, seeing only state references and identifiers. Five nodes run a BFT-SMaRt variant with a 3-of-5 quorum, tolerating one Byzantine fault: two in EU-regulated cloud zones, two in UAE zones, one in a neutral location such as Switzerland. The operator must be jurisdictionally neutral or jointly governed, typically a consortium entity (as SDX runs its own notary), a joint venture or a regulated trust service provider. ### [id=corda-cordapp] CorDapp: states, contracts and flows The payment CorDapp has three modules (states and contracts, workflows, and compliance for KYC attestation checks and ISO 20022 validation), packaged as JVM .jarfiles deployed identically to every node. A state is an immutable shared fact; it is never modified, only consumed and replaced. // EUR deposit token: issued by BankFR, owned by BankAE after transfer data class EurDepositToken( override val amount: Amount, // e.g. 5,000,000 EUR, issued by BankFR override val holder: AbstractParty, // current holder (changes on transfer) val iso20022Payload: String, // pacs.008 XML payload (base64 encoded) val kycAttestation: SecureHash, // hash of originator KYC attestation VC val paymentReference: UniqueIdentifier, // end-to-end payment reference (UETR) val settlementCycle: String, // "INTRADAY" or "EOD" override val participants: List ) : FungibleToken // FX obligation: created when BankAE commits to deliver AED against EUR data class FxObligationState( val eurAmount: Amount, // EUR leg val aedAmount: Amount, // AED leg (calculated from oracle rate) val fxRate: BigDecimal, // EUR/AED spot rate from oracle val rateTimestamp: Instant, // when rate was signed by oracle val obligor: Party, // BankAE (owes AED) val beneficiary: Party, // BankFR (receives AED equivalent) val linearId: UniqueIdentifier, override val participants: List ) : LinearState Every node verifies contract rules locally before signing. class EurDepositTokenContract : Contract { companion object { const val ID = "com.postoaklabs.a2a.contracts.EurDepositTokenContract" } override fun verify(tx: LedgerTransaction) { val cmd = tx.commands.requireSingleCommand() when (cmd.value) { is Commands.Issue -> { // Only the issuer bank (BankFR) can mint tokens require(tx.inputs.isEmpty()) { "Issue: no inputs" } require(tx.outputs.size == 1) { "Issue: exactly one output" } val out = tx.outputsOfType().single() require(out.amount.quantity > 0) { "Issue: positive amount" } require(cmd.signers.contains(out.amount.token.issuer.party.owningKey)) { "Issue: signed by issuer" } require(out.iso20022Payload.isNotBlank()) { "Issue: pacs.008 payload required" } require(out.kycAttestation != SecureHash.zeroHash) { "Issue: KYC attestation required" } } is Commands.Move -> { // Holder signs the move; input and output amounts must balance val inputs = tx.inputsOfType() val outputs = tx.outputsOfType() require(inputs.sumTokenStateAndRefs() == outputs.sumTokenStates()) { "Move: amounts balance" } require(cmd.signers.containsAll(inputs.map { it.holder.owningKey })) { "Move: signed by holder" } } is Commands.Redeem -> { // Redemption burns the token; signed by both holder and issuer require(tx.outputs.isEmpty()) { "Redeem: no outputs" } require(cmd.signers.containsAll( tx.inputsOfType().flatMap { listOf(it.holder.owningKey, it.amount.token.issuer.party.owningKey) } )) { "Redeem: signed by holder and issuer" } } } } interface Commands : CommandData { class Issue : Commands class Move : Commands class Redeem : Commands } } Flows orchestrate each protocol over encrypted point-to-point AMQP; no other node sees flow messages. | Flow | Initiator | Responders | Purpose | PaymentInitiatorFlow | BankFR | BankAE, notary | Mints EUR token with ISO 20022 payload and KYC attestation; starts transfer to BankAE. | FXOracleQueryFlow | BankFR | BankNL (oracle) | Requests a signed EUR/AED spot rate. | FxObligationCreateFlow | BankFR | BankAE, notary | Creates the FxObligationStatecommitting BankAE to deliver AED at the oracle rate. | AtomicPvPSettlementFlow | BankFR | BankAE, notary | One notary-approved transaction moving EUR (BankFR to BankAE) and AED (BankAE to the beneficiary account). | TokenRedemptionFlow | BankAE | BankFR (issuer), notary | Burns transferred EUR tokens after RTGS net settlement; BankAE credits local AED. | ComplianceAttestationFlow | BankFR | BankAE | Exchanges originator and beneficiary VCs before any token is minted (FATF R.16). | RtgsConfirmationFlow | BankNL | BankFR, BankAE | Announces TARGET2 and UAE RTGS confirmations at cycle end; triggers vault cleanup. ### [id=corda-lifecycle] Transaction lifecycle: 16 steps Steps 1–11 complete on-ledger in under 60 seconds; steps 12–16 run intraday or end-of-day. | # | Step | Corda-specific detail | Timing | 01 | Instruction | pacs.008 via BankFR's corporate API: Frankfurt debit account, Dubai supplier credit account, EUR amount, value date, beneficiary, purpose code. | <1 s | 02 | Travel Rule | BankFR's compliance CorDapp screens, then ComplianceAttestationFlowsends a VC (LEI, jurisdiction, risk tier, sanctions-clear) over AMQP; BankAE replies with a beneficiary VC. Satisfies EU TFR and CBUAE AML/CFT. | 1–3 s | 03 | FX rate | FXOracleQueryFlowto BankNL, which builds a signed FXRateStatefrom its Bloomberg/Reuters feed with a 90-second window; BankFR verifies the signature. | 0.5–2 s | 04 | FX commitment | FxObligationCreateFlowputs an FxObligationStatein both vaults; BankAE signs in FxObligationResponderFlowand the notary finalizes. Both banks now hold a binding on-ledger commitment before either leg settles. | 2–5 s | 05 | Mint | Token SDK IssueTokenscreates EurDepositToken(e.g. EUR 5,000,000; issuer and initial holder BankFR) with the base64 pacs.008 and the VC hash, signed by BankFR's HSM key. The fiat stays in BankFR's reserve account. | 1–2 s | 06 | Proposal | BankFR builds one transaction moving EUR to BankAE and AED from BankAE to the recipient account, sent over AMQP to BankAE only. | <1 s | 07 | Counterparty check | BankAE's PaymentResponderFlowruns EurDepositTokenContractand FxObligationContractitself: payload validates against the pacs.008 XSD, KYC hash matches step 2, rate is from the oracle and in window, amounts match the obligation. Then BankAE signs. | 1–3 s | 08 | Notarisation | BankFR submits to the notary, which checks that the EUR token, AED token and FX obligation are unconsumed, seeing only state hashes; 3 of 5 sign in one round of BFT-SMaRt communication. | 1–4 s | 09 | Finality | BankFR distributes the notarised transaction; both vaults update together (EUR consumed at BankFR, new EUR held by BankAE, AED consumed, obligation settled). Irrevocable. | <1 s after signature | 10 | Beneficiary credit | Corda RPC delivers the pacs.008 to core banking middleware (e.g. Temenos T24 or Oracle FLEXCUBE), which posts the AED credit directly against the open invoice. | 1–5 s | 11 | Audit trail | Payload, KYC hash, oracle rate and notary signature live in both vaults. BankFR's compliance module reports to BaFin and for ECB statistics; BankAE's to the CBUAE and ADGM FSRA. | Automated | 12 | Netting | BankNL's liquidity coordination CorDapp nets EUR between BankFR and BankNL and the AED position between BankAE and the EUR-side banks. | Every 4 h or on demand | 13 | TARGET2 | BankFR and BankNL settle net EUR; BankNL's RtgsConfirmationFlowbroadcasts the confirmation. | TARGET2 hours | 14 | UAE RTGS | BankAE settles net AED in dirham central bank money, a direct CBUAE liability; final legal settlement of the AED obligations. | UAE RTGS hours | 15 | Redemption | BankFR runs TokenRedemptionFlowon the EUR tokens held by BankAE; states are consumed with no outputs. | Post-RTGS | 16 | Reconciliation | The pacs.008 travelled inside the token from step 5, so both core systems match straight through. | <2% exceptions ### [id=corda-fx] FX: EUR/AED on-ledger The AED is pegged to USD at 3.6725, so EUR/AED tracks EUR/USD and is not deep at all hours. Corda handles external data through the oracle pattern: BankNL signs the rate, the signature is embedded in the transaction, and any node can verify which rate was attested and when. // FX Oracle data structure: signed by BankNL data class SignedFXRate( val base: Currency, // EUR val quote: Currency, // AED val mid: BigDecimal, // e.g. 3.9412 (EUR/AED mid at time of signing) val bid: BigDecimal, // buy side val ask: BigDecimal, // sell side val timestamp: Instant, // oracle signing time (UTC) val validUntil: Instant, // timestamp + 90 seconds validity window val oracleSignature: DigitalSignature // BankNL node key signature over above ) Conversion happens on-ledger at redemption by BankAE, which keeps its dealing spread over the oracle mid; BankFR keeps the origination fee. Worked example A €5,000,000 payment. Oracle mid 3.9412; BankAE spread 15 bp gives 3.9412 × 1.0015 = 3.9471, so the supplier receives AED 19,735,500. BankAE FX revenue is AED 29,250 (about €7,411 at mid); BankFR's fee is €2,500 (5 bp). All-in cost to the corporate is about 12.5 bp against roughly 2.5–3.5% through correspondents. ### [id=corda-notary] Notary design for cross-jurisdiction finality In one country the network operator or a market infrastructure usually runs the notary. Across the EU and UAE, governance must stop either jurisdiction from unilaterally halting or reversing transactions while meeting both legal finality regimes. With 3-of-5 and a 2/2/1 geographic split, one node can be offline, compromised or under a single jurisdiction's order and the other four still reach quorum. Likely operators: a jointly governed consortium vehicle (like SDX's notary for Swiss DLT Act settlements), a trust service provider licensed in both the EU (eIDAS-qualified) and the UAE (ADGM), or R3 notary-as-a-service under agreements stating when a jurisdiction may exercise authority. Governance constraint Because the notary sees only state hashes, an order directed at it cannot extract transaction data; at most it can stop the notary signing new transactions. The participation agreement must define what counts as a lawful order to cease operating and what happens to in-flight transactions during an outage. This is legal drafting work and must be settled before deployment. ### ISO 20022 inside the token The pacs.008 travels inside the token state from minting. An MT103 degrades along the correspondent chain and truncates names to 35 characters; here the XML is cryptographically bound to the token and arrives at BankAE intact and machine-readable, already in its vault when the token lands. BankAE validates it against the XSD at step 7 before signing. The sample uses pacs.008.001.08, settlement method INDA (instructed agent), MsgId BANKFR-20260415-00012345, created 2026-04-15T09:32:11Z, UETR 550e8400-e29b-41d4-a716-446655440000, EUR 5,000,000.00 from Frankfurt Machinery GmbH (Mainzer Landstrasse 58, Frankfurt am Main; LEI 5299000CRDX2KFHPD419) to Dubai Trading LLC (LEI 984500E8MRZXBX7V1G62), purpose TRPT, invoice INV-2026-DXB-4471, which feeds BankAE's receivables matching. Both LEIs resolve against GLEIF. ### KYC, AML and the Travel Rule BankFR answers to BaFin and the ECB, BankAE to the ADGM FSRA and CBUAE. ComplianceAttestationFlowuses the W3C Verifiable Credentials model: BankFR's VC (name, address, LEI, risk tier, sanctions status) is signed with its node key; BankAE's ComplianceAttestationResponderFlowchecks the signature and the LEI at GLEIF and replies. Both VC hashes sit in the token state, proving Travel Rule data was exchanged before minting. | Requirement | Jurisdiction | Handling on Corda | AML/CFT screening | EU (AMLD6), CBUAE AML | Structured name and LEI screened at step 1 (originator) and step 7 (beneficiary). | Travel Rule | EU TFR, CBUAE/ADGM | VC exchange at step 2; hashes in token state; IVMS-101. | Sanctions | EU Sanctions Regulation; UN and UAE lists | Independent checks on LEI and structured name. | Reporting | ECB, CBUAE | Each bank's compliance module reports from the vault record with the full pacs.008. | Data residency | GDPR, ADGM Data Protection | Personal data moves only between BankFR and BankAE; each stores vault data in its own regulated zone. | DORA | EU | BankFR and BankNL classify the node as critical ICT; R3 must meet DORA ICT third-party requirements. ### [id=corda-reg] Regulation: EU and UAE MiCA and the PTSR are broadly compatible (1:1 reserve backing, at-par redemption, AML/CFT) but differ in implementation details that shape the CorDapp. On the EU side BankFR's token falls under CRD/CRR per the EBA report, with DORA reporting to BaFin or DNB and R3 owing resilience guarantees and audit rights (see [shared rules](#pattern)). - CBUAE PTSR(June 2024; in force August 2025): only licensed Dirham Payment Tokens may be used for domestic payments in the UAE, outside free zones. BankAE needs a PTSR licence; the rules require 1:1 AED reserves, redemption at par on demand and AML/BSA compliance. - ADGM FSRA: BankAE holds digital asset permissions under the Financial Services and Markets Regulations. ADGM applies English common law, giving strong enforceability for CorDapp-governed obligations, and runs the RegLab sandbox, which has worked with blockchain payment infrastructure. A bank in Dubai's DIFC would instead fall under the DFSA, with comparable but distinct requirements; the CBUAE regulates onshore. - FX controls: cross-border AED payments need CBUAE authorization and FX reporting. The CBUAE FIT (Financial Infrastructure Transformation) Programme, launched February 2023 and 85% complete by January 2025, includes a wholesale CBDC programme; the first cross-border Digital Dirham payment (AED 50 million via mBridge, with China) took place in January 2024. - UAE RTGS: the CBUAE rulebook, Chapter 3 (Cross-Border Payments), requires AML/CFT documentation for every transaction above AED 3,500 (about $950). Compatibility finding Both regimes require 1:1 fiat backing, at-par redemption, AML/CFT and prudential supervision. The EUR token is a bank deposit token under EU banking law and BankAE's AED activity is PTSR-licensed, so the design meets all four on both sides, creates no new regulatory category, and falls under no stablecoin regulation. ### RTGS net settlement and liquidity A €5M correspondent payment needs €5M pre-funded along the Frankfurt–Dubai chain. Here the supplier is credited within 60 seconds and RTGS settles only the net. If BankFR sends €20M to Dubai and BankAE sends €12M to Frankfurt in a 4-hour cycle, the net is €8M against €32M gross; at 5%, about €1.2M a year in foregone nostro yield is freed. | Layer | Mechanism | Asset | Timing | Finality | On-ledger (Corda) | Atomic PvP, notary-finalized | EUR deposit token (BankFR liability) against AED deposit token (BankAE liability) | <60 s | Technical finality immediately; legal finality on RTGS confirmation | TARGET2 | Intraday net, pacs.009 | ECB reserves | Every 4 h in the TARGET2 window | Final in ECB money | UAE RTGS | Intraday net, CBUAE format | CBUAE reserves | UAE RTGS window | Final in CBUAE money UAE RTGS runs on Gulf Standard Time (UTC+4). The two systems overlap for 3–4 hours (about 07:00–10:00 CET, 10:00–13:00 GST); the settlement CorDapp queues UAE RTGS instructions to the next GST business day when a cycle falls outside it, and intraday cycles are normally scheduled inside the overlap. ### [id=corda-risks] Corda-specific risks - Governance.The shared questions apply to the payment CorDapp's upgrade roadmap and liability for its bugs. - Legal finality.Corda networks are not yet SFD-designated; the corridor needs engagement in both the EU and UAE. - Mint key.BankFR's minting HSM is the single highest-value target; physical security at the Frankfurt and Dubai data centers must meet FIPS 140-2 Level 3, and multi-signature minting adds operational complexity. - Developer talent.About 2,500 Corda developers have production financial-services experience, against roughly 23,000 EVM/Solidity and 8,000 Fabric developers. Senior Corda engineers cost $150,000–$300,000 a year; a three-bank network needs 3–5 per bank plus 2–3 shared network engineers over a 24–36 month build and stabilization period. - Sequencing for BankAE.Confirm the PTSR licence covers AED deposit-token issuance and cross-border tokenized settlement, engage the ADGM FSRA on the CorDapp architecture, complete CBUAE FIT Programme integration, then go live. EU banks follow the shared sequence with BaFin or DNB. Corda sources: R3 CBDC hub, [digital-currencies-hub.r3.com/cbdcs](https://digital-currencies-hub.r3.com/cbdcs/); CBUAE rulebook, [rulebook.centralbank.ae](https://rulebook.centralbank.ae); TRM Labs, "Global Crypto Policy Review Outlook 2025/26"; Global Government Finance, "UAE aims to launch retail CBDC this year" (April 2025); Ledger Insights, "UAE to launch CBDC in Q4 2025" (March 2025); Chambers Practice Guides, "Fintech 2025, UAE"; Middle East Briefing, "UAE Fintech 2025 Regulatory Review"; R3 documentation, [docs.r3.com](https://docs.r3.com/en/platform/corda/5.2/key-concepts/cordapp-dev.html); Xoriant, "Understanding Corda Architecture" (March 2026); [Corda Token SDK design](https://github.com/corda/token-sdk/blob/master/design/design.md); R3 on 20+ regulated TradFi networks live with over $10 billion in on-chain RWAs, [r3.com/corda](https://r3.com/corda/)(press release February 2025); Brenden, "R3 Corda Settler Tutorial" (2019), [github.com/corda/corda-settler](https://github.com/corda/corda-settler), whose XRP settlement reference is adapted here for bank-to-RTGS settlement. Further Corda deployments: HQLAx (backed by BNP Paribas, Goldman Sachs, HSBC, JPMorgan, UBS), the UK RLN pilot (2023), Wells Fargo Coin (internal USD deposit token), Progmat Coin (MUFG, Japan) and the World Bank's 2023 digital bond settled on Corda via Euroclear D-FMI; Blockchainmagazine.com (May 2025) aggregates examples and should be checked against primary sources. [Back to comparison](#compare) [id=fabric] Hyperledger Fabric · EUR/SAR ## [id=fabric-h] Hyperledger Fabric: two European banks and a Saudi bank A German mid-market maker of precision machine tools pays EUR 4,820,000 to a contracting authority in Riyadh for a desalination project milestone. Its Munich house bank has no direct SAR correspondent account, so it relies on a Paris affiliate that runs a SAR nostro at the Riyadh receiver; all three are members of one permissioned Fabric 2.5 LTS network with a five-node Raft ordering service, four channels, Go chaincode, the Fabric Token SDK, CouchDB world state and FIPS 140-2 HSMs. SAR has been pegged at 3.75 per USD since 1986 and EUR/SAR derives from the ECB euro reference rate against the dollar. At an indicative mid of 4.0825 with a 6 bp spread to the taker, the SAR notional is about SAR 19,683,765. - Fabric 2.5 LTS - Fabric Token SDK - Go chaincode - Raft - pacs.008 - MiCA - SAMA AML/CFT - DORA - TFR 2023/1113 Very few EU institutions hold direct riyal accounts and bilateral nostros are costly, so the EU–GCC relationship is structurally underbanked. A permissioned corridor lets a small group of correspondents net continuously and settle once a day without public-network infrastructure and without exposing counterparty identity outside the consortium. ### [id=fabric-topology] Organizations, peers and orderers Originator · Org1MSP · Munich #### Bayerische Handelsbank AG House bank of the payer. Holds EUR commercial bank money on-ledger as EUR-CBM tokens, debits the corporate in core banking and submits the proposal. Identity Org1MSP · BIC BHDLDE2M Nodes peer0.de · peer1.de · ca.de HSM Thales Luna 7 RTGS TARGET2 (Bundesbank) Reg BaFin · MiCA · DORA Liquidity · Org2MSP · Paris #### Banque Méridienne SA Pan-European correspondent. Runs the SAR nostro at the receiver, quotes EUR/SAR into the oracle and endorses both legs as liquidity counterparty. Identity Org2MSP · BIC BMRDFRPP Nodes peer0.fr · peer1.fr · ca.fr HSM Utimaco SecurityServer RTGS TARGET2 (Banque de France) Reg ACPR · MiCA · DORA Beneficiary · Org3MSP · Riyadh #### Bank Al-Madinah Issues SAR-CBM tokens backed one-for-one by SAMA settlement balances, credits the beneficiary on final commit and sends the MT/MX confirmation upstream. Identity Org3MSP · BIC ALMDSARI Nodes peer0.sa · peer1.sa · ca.sa HSM IBM Crypto Express CCA RTGS SARIE (SAMA) Reg SAMA AML/CFT · PSP Regulations Each bank runs one organization with two endorsing peers (active/standby) and one Fabric CA; peers expose Fabric Gateway over mTLS to the bank's payment hub and keep world state in CouchDB for rich JSON queries on payment metadata. The deployment runs Fabric 2.5.x LTS, maintained by IBM and the Linux Foundation. Container images are pinned by sha256 digest and signed with cosign; chaincode ships as a lifecycle v2 external-builder artefact approved under the channel's lifecycle endorsement policy. The etcd/Raft ordering cluster has five nodes so no jurisdiction can censor the channel alone: orderer0.de, orderer1.fr and orderer2.sa (one per bank) plus orderer3.tech-fra and orderer4.tech-bah, run by an independent technical operator in a Frankfurt colocation facility and a Bahrain regional data centre. It is configured with quorum 3 (labelled f=1); as a crash-fault protocol, five Raft nodes keep making progress with up to two down. Logs are mirrored to WORM storage at each site. Block cutting: BatchTimeout=200ms, BatchSize.MaxMessageCount=500, BatchSize.AbsoluteMaxBytes=10MB. ### [id=fabric-identity] Identity and MSP Every peer, orderer, client and chaincode caller authenticates with an X.509 certificate from an organization's Membership Service Provider. Each bank runs an isolated CA whose root sits in the channel MSP stanza; there is no cross-signed root, and revocations propagate through periodic CRL updates committed by channel admins via UpdateConfig. Identities are partitioned by Organizational Unit, with a custom treasuryattribute gating Mintand Redeemand a role=approverattribute driving dual control. | Identity | OU / attributes | Permitted actions | peer | OU=peer | Endorse, gossip, commit blocks | orderer | OU=orderer | Sequence and cut blocks (Raft) | treasury operator | OU=client, treasury=true, role=approver | Mint, Redeem; second signature on settlement window | payment gateway | OU=client, gateway=true | Submit Transfer, query world state | compliance officer | OU=client, compliance=true | Read the Travel Rule private data collection | auditor (regulator) | OU=client, audit=true, jurisdiction=DE/FR/SA | Read-only on the bank's namespace Keys live in FIPS 140-2 Level 3 HSMs reached through the PKCS#11 BCCSP. Treasury operators use smart-card-backed certificates valid for 12 hours, reissued by an online enrolment service that checks the bank's identity and access management directory first. ### [id=fabric-channels] Channels and private data collections Channels are independent ledgers ordered by the same orderers but isolated at the gossip layer. The shared eursar-corridorchannel carries the token, FX oracle and netting contracts. Three bilateral channels (de-fr-bilateral, fr-sa-bilateral, de-sa-bilateral) carry position reconciliation and bilateral repo traffic hidden from the third bank. On the corridor channel, Travel Rule data and the ISO 20022 body sit in a private data collection visible only to the originating and beneficiary banks; its hash goes on the channel ledger so the liquidity bank can verify integrity. # 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 token contract's endorsement policy is AND(OutOf(2,'Org1MSP.peer','Org2MSP.peer','Org3MSP.peer')): any two of three banks must endorse. The Validation System Chaincode enforces it at commit, after the orderer cuts the block and before peers update world state. ### [id=fabric-chaincode] Go chaincode and atomicity Three chaincodes run on the corridor channel, written in Go on contract-api-go: cbm-token(per-currency commercial bank money), fx-oracle(EUR/SAR mids signed by the liquidity provider) and a2a-router(the atomic construct tying a debit in one currency to a credit in the other). // 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) } a2a-routerputs a EUR Transferand a SAR Transferin one proposal, both conditional on an fx-oraclereading less than 90 seconds old. Fabric applies each transaction atomically against the read-write set from the endorsing peers, so both legs commit or neither does. Atomicity through MVCC Fabric runs no two-phase commit. Both writes sit in one transaction's read-write set; if the orderer sequences a conflicting write first, validation marks the transaction MVCC_READ_CONFLICTand discards both legs, and the hub resubmits. Sub-second resubmission succeeds in more than 99.7% of cases at the target 40 TPS per channel. ### Token model: Fabric Token SDK A minimal account model keeps one composite key per (owner, ccy) and serializes all transfers from an account, which becomes a contention bottleneck. The corridor instead uses IBM Research's Fabric Token SDK, a UTXO-style token: each EUR-CBM note is an unspent output bound to its owner by a Pedersen commitment, and transfers consume notes and create new ones. The consortium runs the plaintext fabtokendriver, accepting that amounts are visible to all three members in return for simpler audit; the zkatdriver (Idemix and bulletproofs, hiding amounts and owners) is held back for when more banks join and amount confidentiality becomes commercially necessary. | Property | Account model | Token SDK (fabtoken) | Token SDK (zkat) | State shape | Balance per (owner, ccy) | Set of UTXO notes | Set of Pedersen-committed notes | Parallelism | Serialized per account | Parallel across notes | Parallel across notes | Amount privacy | Visible in world state | Visible to all channel members | Hidden; balance proven in zero knowledge | Auditability | Direct read | Auditor view via Token SDK role | Auditor view via selective disclosure | Deployed here | No | Yes (corridor channel) | No (future expansion) ### [id=fabric-lifecycle] Transaction lifecycle: 16 steps The on-ledger portion completes in under one second; steps 15–16 are the end-of-day RTGS cycle. | # | Step | Fabric-specific detail | Clock (CET) | 01 | Instruction | SEPA-instant-style instruction through the online portal; IBAN mod-97, BIC ALMDSARI and sanctions checks; internal reference PAY-IN-2026-04-21-887412. | 10:14:02.118 | 02 | Travel Rule witness | Hub builds pacs.008.001.10 with originator and beneficiary name, address, account and BIC, and SHA-256-hashes the body into a witness for the transient map, which never lands on the public ledger. | 10:14:02.244 | 03 | FX quote | EvaluateTransactionon fx-oraclereturns mid 4.0825 and ask 4.0833 (6 bp), signed by Org2's treasury identity, timestamped by the last block, valid 90 s. | 10:14:02.281 | 04 | Proposal | Fabric Gateway builds one a2a-router:AtomicSwapproposal with both legs and the quote; the Travel Rule hash rides in the transient map, gossiped only between Org1 and Org3 peers. | 10:14:02.310 | 05 | Endorsement | peer0.de then peer0.sa simulate and return signed read-write sets; Org2 is asked in parallel for resilience, though two endorsements satisfy the policy. | 10:14:02.387 | 06 | Private data | During simulation the full pacs.008 is written to PDC_TR_DE_SA; only its SHA-256 enters the block, enough for Org2's nostro reconciliation. | 10:14:02.388 | 07 | Ordering | Gateway submits over gRPC; the Raft leader (orderer1.fr) appends and replicates to four followers and schedules the entry on quorum (3). | 10:14:02.401 | 08 | Block cut | Block 884,213 cut at 200 ms or 500 transactions, signed by the leader and gossiped to one peer per organization, which fans out. | 10:14:02.508 | 09 | VSCC | Signature check, 2-of-3 endorsement check and MVCC check on read versions (under 50 ms per block); both legs marked VALID. | 10:14:02.531 | 10 | Commit | CouchDB updates atomically: Org1 EUR −4,820,000.00, Org2 EUR +4,820,000.00, Org2 SAR −19,683,765.00, Org3 SAR +19,683,765.00; block hash to the channel's LevelDB ledger store. Irrevocable. | 10:14:02.547 | 11 | Events | Transferevents reach each hub through the block-listener API; hubs match by reference and move the instruction from SUBMITTED to SETTLED-ON-LEDGER. | 10:14:02.549 | 12 | Debit | Core banking debits the corporate EUR account 4,820,000.00 against a suspense account mirroring token holdings; reference PAY-IN-2026-04-21-887412 / FBR-884213. | 10:14:02.612 | 13 | Credit | Bank Al-Madinah credits SAR 19,683,765.00, reduces its intraday position against Banque Méridienne in the nostro reconciliation tab, and pushes a SARIE-formatted advice to online banking and SMS. | 10:14:02.681 | 14 | Audit trail | Org1 and Org3 hold the record from block 884,213; the pacs.008 is kept in the PDC for three years; BaFin/ACPR and SAMA records generate automatically. | Automated | 15 | Netting | The nettingchaincode produces a triangular net per pair; for 21 April 2026, Org1 owes Org2 EUR 12,440,118 and Org2 owes Org3 SAR 8,206,040. | 17:00:00 | 16 | RTGS and burn | Net amounts settle in TARGET2 and SARIE; after SAMA and Bundesbank confirm, each hub submits a coordinated Burn, restoring each bank's issuance to its net opening position. | 17:14 / 18:14 AST ### Ordering: Raft now, SmartBFT later Raft tolerates crashes but not Byzantine behaviour: a malicious orderer could withhold or reorder transactions within the batch timeout, though it cannot forge endorsements or alter committed state. Orderers are therefore spread across three bank sites (Munich, Paris, Riyadh) and two independent operators, with WORM-mirrored logs. Fabric 3.x adds the SmartBFT plug-in (SBFT-CHS) for full Byzantine tolerance; the consortium will migrate once Fabric 3.x reaches IBM enterprise support GA and a six-month parallel run on a staging channel completes. Raft is acceptable meanwhile because the threat model assumes Byzantine endorsing peers, and the 2-of-3 bank endorsement policy is the cryptographic anchor. Caveat: Raft assumes honest orderers A coordinated take-over of Raft leadership could censor or reorder transactions within BatchTimeout. Mitigations: jurisdictional diversity of operators, cryptographic chain of custody on orderer logs, and a runbook hot-swap that rebuilds a degraded cluster from any majority subset within 30 minutes. ### [id=fabric-iso] ISO 20022 pacs.008 in chaincode state The corridor speaks ISO 20022 internally; both sides are moving cross-border traffic to MX ahead of SWIFT's MT discontinuation milestones. The full pacs.008.001.10 lives in the private data collection so compliance and auditors at the two end banks can reconstruct the payment context; the corridor ledger holds only the hash. BHDLDE2M-20260421-887412 2026-04-21T10:14:02.244+02:00 1 CLRG FABRIC-EURSAR-CORRIDOR PAY-IN-2026-04-21-887412 5e9c4e8a-2f1b-4b3a-9d0e-1c8f4a7b6d52 4820000.00 SHAR Präzision Werkzeug GmbH DE DE89370400440532013000 BHDLDE2M ALMDSARI Saudi Water Authority SA SA0380000000608010167519 Desalination plant, milestone 3 of 7 The hub canonicalizes the XML with W3C Canonical XML 1.1 and hashes it with SHA-256; the 32-byte result is the trHashfield of the transfer event. Any dispute is settled by replaying the private data from either bank's PDC and re-canonicalizing; a mismatch flags tampering. ### KYC, AML, sanctions and the Travel Rule Each bank runs KYC and CDD under its home regime (BaFin GwG, ACPR/AMF, SAMA AML/CFT Rules) and keeps identity in its own KYC vault. The ledger guarantees only that an authenticated gateway with a valid MSP identity attested, at submission, that the customer was screened. The Travel Rule, transposed through the TFR and Article 17 of the SAMA AML/CFT Rules, requires originator name, account, address and identifier plus beneficiary name and account; storing the full pacs.008 in the bilateral PDC satisfies it while Org2 sees only the block and the hash. Gateways screen against their own lists (EU Consolidated List, OFAC SDN where applicable, UN Security Council list, SAMA's domestic list) and assert the result 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, which would mean sharing keys across the consortium, but rejects any transfer missing the witness and preserves it in the PDC. ### [id=fabric-reg] Regulation: EU and Saudi Arabia Neither side mandates daily on-ledger reporting, but each bank's auditor identity reads the corridor channel and its bilateral PDC. EU rules common to the corridors are in the [shared pattern](#pattern); Fabric adds: - DORA:each bank lists its Fabric node in its register of ICT third-party providers, and IBM as platform vendor signs a DORA-compliant contractual addendum. - BaFin:supervises Bayerische Handelsbank under the KWG; the tokenisation activity is notified under §32 KWG following BaFin's 2024 Merkblatt on crypto-securities business (DLT-based financial infrastructure). - ACPR:approved the corridor for Banque Méridienne as a service ancillary to credit institution activity under Art. L.311-2 of the Code monétaire et financier. - SAMA:Rules for Bank Account Opening (2023) govern onboarding, CDD and beneficial ownership; under the Payment Services Provider Regulations the corridor counts as ancillary to licensed banking rather than a stand-alone PSP service; the AML/CFT Rules' three-year retention matches the PDC's blockToLive; the Open Banking Framework is not invoked, though the gateway API uses OAuth 2.0 / FAPI 2.0 to ease future integration; Aber informs SAMA's view of permissioned ledgers as viable settlement infrastructure; SARIE provides the central bank money leg. ### Net settlement against TARGET2 and SARIE On-ledger tokens are liabilities of the issuing bank and are not legally final until central bank money moves. At 17:00 CET the netting chaincode produces a multilateral position per currency per bank. For 21 April 2026: | Pair | Currency | Direction | Net amount | Venue | Org1 → Org2 | EUR | Org1 pays Org2 | 12,440,118.42 | TARGET2 | Org2 → Org3 | SAR | Org2 pays Org3 | 8,206,040.05 | SARIE | Org3 → Org1 | EUR | Org3 pays Org1 | 1,217,330.18 | TARGET2 Bayerische Handelsbank sends an MT 202 / pacs.009 to the TARGET2-Bundesbank component for Banque Méridienne's PM account, final on Eurosystem books at 17:14 CET. Banque Méridienne instructs its Riyadh nostro provider to settle through SARIE to Bank Al-Madinah's SAMA settlement account, final at 18:14 AST (15:14 UTC). After both confirmations each hub submits a Burnfor the settled amounts, and the next cycle starts at 17:00:01 CET. Gross RTGS settlement of each transfer would defeat the corridor: SARIE and TARGET2 fees and the mismatch in operating hours would make small payments uneconomic. Netting keeps on-ledger speed and finality while cutting central bank transactions to one per bank per currency per day. ### [id=fabric-risks] Fabric-specific risks - Orderer compromise:a compromised majority could censor within BatchTimeout; mitigated by five jurisdictionally diverse orderers, WORM logs and the planned SmartBFT move. - HSM key compromise:a stolen treasury credential could mint or burn unbacked tokens; mitigated by dual-control endorsement (two approvers), 12-hour treasury certificates and a real-time issuance cap monitored off-chain against core banking. - FX oracle staleness:if the oracle stops, swaps fail; if it misprices, the liquidity provider gains or loses. Chaincode rejects quotes older than 90 seconds and a circuit-breaker disables swaps if the oracle drifts more than 25 bp from the ECB reference rate. - MVCC contention:heavy traffic on the same keys raises MVCC_READ_CONFLICT; the UTXO Token SDK spreads load across notes. - Settlement failure:if a bank's RTGS leg misses cycle close, no Burnis sent and the tokens remain as a visible obligation; per-bank limits cap the build-up and the next day's cycle absorbs the carry. - Chaincode upgrades:lifecycle v2 needs per-organization approval; every upgrade soaks 30 days on a sandbox channel and is gated on a notarised release attestation signed by the consortium technical committee. Fabric sources: Hyperledger Fabric v2.5 LTS documentation, [hyperledger-fabric.readthedocs.io](https://hyperledger-fabric.readthedocs.io/en/release-2.5/); Androulaki et al., "Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains", EuroSys '18; IBM Research, Fabric Token SDK, [github.com/hyperledger-labs/fabric-token-sdk](https://github.com/hyperledger-labs/fabric-token-sdk); Ongaro and Ousterhout, "In Search of an Understandable Consensus Algorithm (Raft)", USENIX ATC 2014; SAMA AML/CFT Rules and PSP Regulations, [sama.gov.sa](https://www.sama.gov.sa/en-US/Pages/sama-rules.aspx); BaFin Merkblatt zum Tatbestand des Kryptowertpapiergeschäfts (2024). [Back to comparison](#compare) ## [id=next-h] Planning a corridor of your own Post Oak Labs advises banks and market infrastructures on ledger selection, corridor design and the regulatory sequence. See [blockchain advisory](services.html#blockchain), the [engagement roadmap](a2a-guide.html#roadmap)and the [tokenized money market fund](a2a-guide.html#tmmf)guide, or browse the [library](library.html). [Talk to us](contact.html) # END llms-full.txt