Project Agorá: The Largest BIS Experiment Merging Tokenized Deposits and Wholesale CBDC

Project Agorá, launched in April 2024 by the BIS Innovation Hub, is its largest public-private collaboration, testing a multi-currency unified ledger for wholesale cross-border payments. It builds on the BIS’s « unified ledger » concept, exploring how tokenization and programmability can modernize correspondent banking without replacing the two-tier monetary system (commercial banks and central banks).

This initiative is strictly experimental, producing a technical prototype concluding with a lessons-learned report in the first half of 2026. The project involves seven core central banks (Bank of England, Eurosystem via Banque de France, Bank of Japan, Bank of Korea, Bank of Mexico, Swiss National Bank, and the New York Fed) and over 40 private financial institutions coordinated by the Institute of International Finance (IIF). The key mechanics involve creating a shared, programmable digital infrastructure where traditional sequential processes—messaging, compliance, reconciliation, and settlement—merge into one atomic operation via tokenization and smart contracts.

Tokenization creates digital representations of claims on commercial banks (tokenized bank deposits) and tokenized wholesale central bank money (tokenized reserves), which serves as the ultimate safe settlement asset. Both coexist on a technology-neutral unified ledger supporting multi-currency operations 24/7.

Atomic settlement, guaranteed by smart contracts, ensures payments execute fully or not at all, eliminating reversal risks common in current correspondent banking. Compliance (AML/CFT, sanctions) is embedded directly into the platform using privacy-preserving techniques. The structure maintains the two-tier system, with commercial banks handling credit/liquidity and central banks providing final settlement safety.

Objectives include faster, cheaper, and more transparent payments; reduced operational and compliance costs; and revitalized correspondent banking corridors. Insights gained will inform future central bank decisions. As of April 2026, the project is in the user testing phase, which feeds into the mid-2026 report detailing the technical blueprint and feasibility assessment. Unlike related projects such as mBridge (which focuses on direct CBDC-to-CBDC settlement), Agorá focuses on upgrading correspondent banking using tokenized commercial deposits alongside wholesale central bank money, emphasizing greater private sector integration and programmability. It explicitly avoids geopolitical considerations seen in other multi-CBDC endeavors. Project Agorá’s central focus is achieving atomic, efficient, and compliant cross-border wholesale payments anchored by the safety of central bank money.

Project Agorá’s transaction flow is designed to transform traditional correspondent banking into a single, programmable, atomic process on a unified ledger. As of April 2026, the project remains in the prototype/testing phase (user testing began in January 2026), so no production-level implementation exists. The full technical blueprint and lessons-learned report are scheduled for release in the first half of 2026. All details below are drawn from official BIS descriptions, ECB presentations, and public speeches—there is no single public “step-by-step code” or exhaustive runtime diagram yet, but the conceptual mechanics are clear and consistent across sources.

The flow you quoted is the high-level simplified version. Here is a detailed, expanded transaction flow that incorporates the project’s three-layer architecture (ledger, tokenisation, atomic settlement), the role of smart contracts, compliance integration, and how it preserves the two-tier monetary system (commercial banks handle customer relationships and credit; central banks provide the final safe settlement asset).

Project Agorá Transaction Flow (Detailed Step-by-Step)

Overall Architecture (Three Layers)

1. Ledger Layer — A permissioned distributed ledger (DLT) acts as the single source of truth for records. Each participating jurisdiction runs a node. It operates 24/7 and supports immutable, verifiable transaction history.
2. Tokenisation Layer — Creates programmable digital representations (“tokens”) of:
   • Commercial bank money (tokenised customer deposits — the credit/liquidity layer that maintains depositor-bank relationships).
   • Wholesale central bank money (tokenised reserves — the risk-free final settlement asset issued and anchored by each central bank).
     Tokens embed rules (via smart contracts) for ownership, transfer, conditions, and compliance. Assets in traditional systems are “locked” as collateral to back the tokens.
3. Atomic Settlement Layer — Smart contracts bundle everything into one indivisible operation. Multiple actions are conditional on each other and execute synchronously (or not at all).

Detailed Cross-Border Payment Flow (e.g., Company A in Country X pays Company B in Country Y)

1. Initiation on the Ledger
   • Payer (Company A) instructs its bank (Payer’s Bank) via existing channels.
   • Payer’s Bank locks the required funds in its traditional system and issues/mints the corresponding tokenised commercial bank deposit on the Agorá unified ledger.
   • The transaction request (including amount, currencies, beneficiary details) is submitted directly to the programmable ledger platform. No separate SWIFT-style messaging is sent in parallel. ecb.europa.eu
2. Tokenised Deposits Move Between Commercial Banks
   • The tokenised deposit (representing the payer’s claim) is transferred programmatically on the ledger.
   • If needed, a correspondent-bank corridor or vehicle currency (for multi-currency pairs) is handled within the same ledger environment.
   • All participating commercial banks (payer’s, payee’s, and any intermediaries) have their tokenised positions visible and updatable on the shared ledger. This replaces sequential account updates across siloed systems. bis.org
3. Smart Contracts Handle All Checks and Logic in Parallel
   • A smart contract (or set of smart contracts) orchestrates the entire chain simultaneously:
     • Pre-validation & availability checks (sufficient tokenised funds/reserves).
     • Compliance & integrity checks (AML/CFT, sanctions screening, KYC — performed via shared protocols on the ledger; data privacy is preserved through design).
     • FX conversion (if required, using atomic PvP — payment-vs-payment).
     • Reconciliation & netting (any imbalances are resolved instantly).
     • Conditional logic (e.g., “release only if collateral is posted” or other programmable business rules).
   • Because everything runs on one programmable platform, duplication is eliminated and false positives are reduced. Checks are a “collective effort” rather than sequential hand-offs.
   • This is the key innovation vs. today’s “happy path” (multiple sequential information checks with potential rollbacks) or “refund path” (costly manual fixes). ecb.europa.eu
4. If Conditions Are Met, Atomic Settlement Occurs in Tokenised Central Bank Money
   • The smart contract triggers atomic execution: all legs (deposit transfer + any FX + compliance confirmation + final settlement) happen synchronously and indivisibly.
   • Final settlement always uses tokenised wholesale central bank money (reserves issued by the relevant central banks). This provides risk-free finality and preserves monetary policy transmission.
   • The payee’s bank receives the tokenised commercial bank deposit (or equivalent), which it can then redeem/unlock into its customer’s account.
   • If any condition fails at any point, the entire transaction rolls back atomically — no partial settlement, no Herstatt risk, no need for refunds or manual reconciliation. bis.org
5. Depositor-Bank Relationships and Two-Tier Structure Remain Intact
   • Customers (payer and payee) continue to interact only with their own commercial banks.
   • Banks retain credit intermediation, liquidity provision, and customer-facing services.
   • Central banks remain the ultimate providers of safe settlement money.
   • The ledger simply makes the existing two-tier system more efficient and programmable. bis.org

Visual Contrast (Traditional vs. Agorá)

• Traditional (Sequential): Payer’s bank → multiple payment systems/correspondent banks → payee’s bank. Each hop involves separate messaging, individual compliance checks, account updates, and possible delays/rollbacks (as shown in ECB “happy path” and “failure” diagrams).
• Agorá (Atomic): Payer’s bank → unified ledger (Agorá platform) → payee’s bank. One smart-contract-orchestrated transaction with synchronous settlement in central bank money. Correspondent corridors, if used, operate inside the ledger rather than as external chains. ecb.europa.eu

This flow is still experimental. The upcoming mid-2026 BIS report will publish the exact prototype design, test results, and legal/regulatory analysis across the seven jurisdictions. In the meantime, the mechanics above represent the current public understanding of how Agorá aims to deliver faster, cheaper, more transparent wholesale cross-border payments while maintaining stability and trust.

Project Agorá and mBridge are both BIS Innovation Hub-originated experiments using distributed ledger technology (DLT) for faster, cheaper wholesale cross-border payments, but they differ fundamentally in architecture, assets, and focus.

As of April 10, 2026, mBridge is a live, operational multi-CBDC platform (handed over to central banks in October 2024, now China-led in practice) with real-world volume exceeding $55 billion across 4,000+ transactions. Project Agorá remains in the experimental prototype/testing phase (user testing began January 2026; full lessons-learned report due in the first half of 2026).

Bridge enables direct CBDC-to-CBDC settlements (pure central-bank-issued digital money). Agorá tests a tokenized unified ledger that integrates commercial bank deposits with tokenized wholesale central bank money while explicitly preserving the traditional two-tier monetary system and correspondent banking model.

bis.orgHere is a detailed mechanical comparison:

1. Core Purpose and Scope

• mBridge: Creates a shared multi-CBDC platform for instant, peer-to-peer cross-border payments and PvP (payment-vs-payment) FX settlements. Goal: Bypass correspondent banking/SWIFT entirely using direct CBDC transfers. Focus on efficiency, 24/7 availability, and sanctions-resilient trade (e.g., energy/commodities). bis.org
• Project Agorá: Tests a programmable unified ledger to improve (not replace) correspondent banking. It tokenizes both commercial bank deposits and central bank reserves on one platform for atomic, streamlined wholesale payments. Goal: Reduce sequential steps, compliance duplication, and liquidity traps while maintaining depositor-bank relationships and the two-tier system. gftn.co

2. Assets and Backing

• mBridge: Uses wholesale CBDCs issued directly by each participating central bank (1:1 backed by their reserves). Commercial banks hold and transfer these CBDCs on the platform. No tokenized commercial bank deposits. bis.org
• Project Agorá: Combines two tokenized forms of money on a single ledger:
  • Tokenized commercial bank deposits (representing claims on commercial banks — the credit/liquidity layer).
  • Tokenized wholesale central bank money (reserves issued by central banks for final settlement).
    Tokens are programmable and backed by locked traditional assets. ledgerinsights.com

3. Technology and Settlement Mechanics

• mBridge:
  • Custom permissioned DLT called mBridge Ledger (mBL) — EVM-compatible, supports smart contracts in Solidity.
  • Each central bank runs a validating node; commercial banks run ordinary nodes.
  • Atomic PvP for FX; real-time peer-to-peer.
  • Compliance/screening handled off-platform or via integrated checks.
• Project Agorá:
  • Unified programmable ledger (technology-neutral DLT focus; not specified as a single custom chain).
  • Smart contracts orchestrate the entire process atomically (messaging + compliance + FX + settlement in parallel).
  • Integrates tokenized deposits and central bank money for synchronous execution.
  • « Integrity by design » embeds AML/CFT/sanctions screening on-ledger with privacy techniques. bis.org

4. Transaction Flow (Detailed Comparison)

Both achieve atomic settlement (all-or-nothing), but the steps and layers differ: mBridge Flow (CBDC-Direct):

1. Commercial bank requests CBDC issuance (manual or automatic via domestic systems).
2. Initiator selects currency/amount/counterparty and performs off-bridge compliance.
3. For simple payments: Push request → payee confirms → smart contract executes transfer.
4. For FX PvP: Three-phase (initiate/commit/execute) atomic swap of two CBDCs.
5. Settlement is final in the receiver’s CBDC wallet. Redemption back to domestic systems if needed. bis.org

Project Agorá Flow (Tokenized Unified Ledger):

1. Payer instructs bank → bank locks funds and mints tokenized commercial bank deposit on the ledger.
2. Tokenized deposit moves programmatically between commercial banks on the shared ledger.
3. Smart contracts run all checks in parallel: availability, compliance (AML/sanctions), FX (if needed), reconciliation.
4. If conditions met → atomic settlement in tokenized wholesale central bank money (final, risk-free).
5. Payee’s bank receives tokenized deposit, which unlocks to the beneficiary. Two-tier structure (customer commercial bank central bank) remains intact. gftn.co

Key Flow Difference: mBridge is a direct CBDC bridge (central banks issue, banks transact in CBDCs). Agorá keeps commercial bank money central and uses tokenized CB money only for final settlement.5. Governance, Participants, and Neutrality

• mBridge: Central-bank governed (now fully independent of BIS). Core: China (PBOC), Hong Kong, Thailand, UAE, Saudi Arabia. 30+ observers. China-dominant volume (~95% e-CNY). reuters.com
• Project Agorá: BIS-led public-private partnership. 7 central banks (Bank of England, Banque de France/Eurosystem, Bank of Japan, Bank of Korea, Bank of Mexico, Swiss National Bank, New York Fed). 40+ commercial banks/fintechs (via IIF). Western/G7 reserve-currency focus. bis.org

6. Current Status (April 2026)

• mBridge: Fully operational MVP since mid-2024. Live real-value transactions; rapid scaling post-BIS handover. Government use cases (e.g., UAE wholesale dirham). theblock.co
• Project Agorá: Prototype built; user testing underway (launched January 2026, ~6 months expected). Lessons report in H1 2026. Still experimental — no live production. reuters.com

Key Takeaways and Relationship

• Complementary, Not Direct Competitors: mBridge is a ready-to-use CBDC bridge for direct central-bank digital settlements (ideal for multipolar/de-dollarization flows). Agorá is a next-generation correspondent-banking upgrade that keeps commercial banks central while adding tokenization and programmability. reuters.com
• Geopolitical Nuance: mBridge (post-handover) aligns with BRICS+ momentum; Agorá anchors major Western reserve currencies.
• Shared Strengths: Both eliminate sequential delays, enable 24/7 atomic PvP, reduce costs, and use DLT for transparency.

In the context of our earlier discussion, mBridge provides the direct CBDC plumbing that BRICS-style systems could parallel, while Agorá offers a tokenized evolution of traditional banking rails that BIS-neutral central banks are prototyping. The mid-2026 Agorá report will likely clarify further technical overlaps or distinctions.

Project Agorá and mBridge both address AML/CFT (anti-money laundering/countering the financing of terrorism), sanctions screening, and KYC (know-your-customer) compliance in cross-border wholesale payments, but their approaches differ significantly in integration, responsibility, and efficiency.

As of April 2026, mBridge is a live operational multi-CBDC platform (handed over to central banks in late 2024), while Project Agorá remains in the experimental prototype/user-testing phase (with its full lessons-learned report due in H1 2026).

mBridge relies on off-platform, bank-led compliance with certification attached to transactions. Agorá tests on-ledger, programmable “integrity by design” that embeds and automates compliance via smart contracts to reduce duplication. Both prioritize regulatory compliance and privacy, but Agorá is designed to make compliance more efficient and atomic within a unified ledger.Here is a detailed mechanical comparison:

1. Location and Integration of Compliance Checks

• mBridge: Off-bridge (off-platform). Commercial banks perform all AML/CFT/sanctions screening, KYC, and related checks in their own domestic systems before submitting a transaction. The platform only receives a simple pass/fail certification attached to the transaction. No compliance logic runs on the mBridge Ledger itself. Central banks can monitor transactions and balances in real-time for their issued CBDC, and they retain discretion over issuance/redemption to enforce domestic rules. bis.org
• Project Agorá: On-ledger and programmable (“integrity by design”). Compliance is embedded directly into the unified ledger via smart contracts. All checks (AML/CFT, sanctions screening, KYC attestations) run in parallel with payment availability, FX, and reconciliation. Verifiable attestations of compliance (e.g., “this party has passed KYC/AML screening”) are recorded and shared securely on the ledger. This eliminates sequential hand-offs. bis.org

2. Screening Process and Automation

• mBridge: Banks handle screening independently (using their existing tools and data). The platform supports transaction-specific certification (a binary output) and can incorporate LEIs (Legal Entity Identifiers) to aid identification. No automated on-platform screening or machine-learning integration in the core design. Future enhancements (e.g., compliance proofs from related BIS projects like Mandala) have been suggested but are not part of the current live MVP. bis.org
• Project Agorá: Smart contracts orchestrate parallel, automated checks across the entire chain. This includes privacy-preserving techniques (e.g., federated learning or zero-knowledge-style attestations) to reduce false positives and duplication. The ledger records and maintains verifiable attestations of prior compliance processes, allowing downstream parties to rely on them without re-screening. gftn.co

3. Privacy and Data Sharing

• mBridge: Strict need-to-know: Data is shared only with the transacting parties and their respective central banks. No broader data-sharing on the platform. Privacy is maintained through the decentralized node structure (each central bank runs its own validating node). eco.unicamp.br
• Project Agorá: Also privacy-focused but leverages programmable tokens and on-ledger techniques for selective disclosure. Compliance attestations are verifiable without revealing underlying sensitive data. This aligns with BIS-wide privacy-enhancing experiments (e.g., Project Aurora/Hertha) and aims to balance transparency for regulators with confidentiality. bis.org

4. Roles and Responsibilities

• mBridge: Commercial banks bear primary responsibility for compliance (obliged by the rulebook). Central banks oversee monitoring and can enforce via CBDC controls. The platform itself is “compliance-neutral” — it facilitates certification but does not perform or enforce checks. eco.unicamp.br
• Project Agorá: Shared and automated across commercial banks, central banks, and the ledger. Banks still perform initial KYC/AML, but the platform streamlines verification and reduces redundant work. Central banks participate in governance and prototype testing of regulatory gaps (e.g., settlement finality + compliance across seven jurisdictions). committees.parliament.uk

5. Efficiency, Risks, and Sanctions Handling

• mBridge: Maintains traditional duplication risks (each bank screens separately), but the certification model ensures clear accountability. Sanctions compliance is enforced via bank-level checks and central-bank discretion; the platform itself is not designed for evasion (BIS explicitly stated it cannot be used by sanctioned entities). omfif.org
• Project Agorá: Explicitly targets reduced duplication and lower compliance costs (a major pain point in correspondent banking). Atomic execution means failed compliance halts the entire transaction instantly (no partial settlement or manual refunds). It is actively analyzing legal/regulatory gaps in AML/sanctions across jurisdictions to support a compliant infrastructure. iif.com

Key Takeaways

• mBridge is more decentralized and bank-centric in compliance — practical for a live multi-CBDC system with diverse jurisdictions, but it preserves some of the sequential inefficiencies of traditional rails.
• Agorá is more integrated and programmable — aiming to make compliance part of the atomic flow on a unified ledger, which could dramatically cut costs and delays once scaled (still experimental).
• Both systems are built to meet (or exceed) international standards (FATF, CPMI) while preserving central-bank sovereignty. Neither is a sanctions-evasion tool; mBridge’s governance and Agorá’s Western/G7 focus reinforce this. bis.org

In the context of our earlier discussion, mBridge’s off-bridge model aligns with its role as a direct CBDC bridge (practical for BRICS+ flows), while Agorá’s on-ledger approach represents a next-generation upgrade to correspondent banking with deeper compliance automation. The H1 2026 Agorá report will likely provide even more granular prototype details on these mechanics.

Project Aurora is a BIS Innovation Hub (Nordic Centre-led) initiative focused on using data, advanced analytics, privacy-enhancing technologies (PETs), artificial intelligence/machine learning (AI/ML), and network analysis to combat cross-border money laundering and financial crime through collaborative analysis and learning (CAL).

It directly addresses the core challenge in payments compliance: how to achieve a holistic, network-wide view of suspicious activity across institutions and borders without sharing raw sensitive data, thereby balancing effectiveness with privacy and data protection.

Launched as a proof-of-concept (PoC) in the early 2020s, Aurora is highly relevant to our ongoing discussion of compliance mechanics in Project Agorá (on-ledger programmable “integrity by design”) and mBridge (off-platform bank certification). It provides the BIS’s experimental foundation for privacy-preserving collaborative AML tools that could enhance either system. A related follow-on project, Project Hertha (London Centre + Bank of England), builds explicitly on Aurora’s findings for real-time retail payments.

Phase 1 (Concluded 2023): Core Mechanics and Key Findings

Phase 1 was a technical PoC using synthetic transaction data (no real customer data) to simulate collaborative AML across banks, payment service providers, fintechs, central banks, and regulators.

Mechanics:

• Collaborative Analysis and Learning (CAL): Institutions contribute insights or trained models (not raw data) in a federated or secure multi-party setup.
• Privacy-Enhancing Technologies (PETs): These enable secure computation—e.g., homomorphic encryption, secure multi-party computation, or differential privacy—so participants analyze combined data without ever exposing underlying transactions or personal information.
• AI/ML + Network Analysis: Models detect complex laundering networks (e.g., layered accounts across borders) that siloed rule-based systems miss. Synthetic data embedded realistic illicit patterns for testing.
• Flow: Banks simulate isolated monitoring → national/cross-border CAL layer applies PET-protected analytics → shared insights (e.g., flagged networks) are produced without central data pooling. bis.org

Outcomes (per the 2023 BIS report):

• CAL + PETs detected up to 3× more complex money laundering schemes than traditional siloed/rule-based approaches.
• False positives reduced by up to 80%.
• Proved that a holistic network view is feasible while upholding privacy, data protection, and information security—aligning with FATF and G20 recommendations. bis.org

Challenges identified: Legal/regulatory hurdles, technical/operational issues, and data standards.

Phase 1 concluded PETs hold “great promise” for scaling CAL in AML/fraud prevention.

Phase 2 (Launched July 2025): Current Status and Focus (as of April 2026)Building directly on Phase 1, Phase 2 shifts toward real-world application. An open call for case studies ran from 7 July to 18 August 2025, inviting submissions on PETs in multi-party collaborative analytics for money laundering, fraud, and other financial crime. Selected participants joined a “PET Deep Dive” workshop in Stockholm (7–8 October 2025).

bis.orgObjectives and Mechanics in Phase 2:

• Develop public-private awareness, governance, and learning initiatives.
• Deliver iterative real-world PoCs that could scale to pilots.
• Explore specific use-cases: How PETs + advanced analytics improve information-sharing effectiveness; privacy protections vs. potential intrusions; and enabling factors for adoption.
• Emphasis on behavioral/network-based detection in fragmented payment ecosystems. bis.org

As of April 2026, Phase 2 is ongoing (no final public report or pilot results detailed yet), with further initiatives and publications expected throughout the year.Project Hertha (2025): Direct Extension of AuroraHertha (completed/reported around June 2025) explicitly builds on Aurora by testing transaction analytics in real-time retail payment systems while using the minimum set of data points to protect privacy.

• Mechanics: Applied modern AI to a large synthetic dataset (1.8 million accounts, 308 million transactions) representing a single jurisdiction’s retail ecosystem. Focused on network-wide pattern detection (e.g., coordinated criminal activity across accounts) as a supplement to individual bank/PSP monitoring.
• Outcomes: Detected 12% more illicit accounts; 26% improvement in spotting previously unseen patterns. Highlighted the need for labelled training data, robust feedback loops, and explainable AI.
• Relevance: Demonstrates Aurora’s CAL/PET concepts in a live retail context—exactly the kind of privacy-first analytics that could integrate into tokenized ledgers or CBDC bridges. bis.org

Relation to mBridge, Agorá, and Broader Compliance Context

• mBridge (off-platform compliance): Banks certify AML/sanctions checks domestically before submitting transactions. Aurora/Hertha-style PETs + CAL could upgrade this by enabling cross-border collaborative insights without raw data sharing—e.g., shared network flags across CBDC nodes while preserving mBridge’s decentralized certification model.
• Project Agorá (on-ledger programmable compliance): Aurora’s “integrity by design” philosophy aligns perfectly with Agorá’s smart-contract-orchestrated parallel checks and privacy-preserving attestations. PET-enabled CAL could be embedded as on-ledger modules for real-time, multi-party AML without duplicating effort.
• BRICS/mBridge overlap: While Aurora is BIS-neutral (no sanctioned jurisdictions), its PET/CAL tools offer a blueprint for privacy-compliant de-dollarization rails—e.g., enhancing BRICS Unit or Bridge compliance without centralized data risks.
• Overall BISIH Theme: Aurora sits alongside Mandala, Raven, and others in the Hub’s financial-integrity portfolio, feeding into Agorá’s regulatory-gap analysis and mBridge’s post-handover evolution.

In short, Project Aurora (and its Hertha extension) is the BIS’s practical demonstration that privacy and powerful AML detection are not mutually exclusive—they can be enhanced through PETs and collaborative tech. Phase 2’s real-world focus as of April 2026 makes it a key watchpoint for how these tools could mature into production use across systems like Agorá or mBridge. Official BIS pages and the 2023 Phase 1 report remain the primary sources; further Phase 2 outputs are expected later in 2026.

Privacy-Enhancing Technologies (PETs) are a broad category of tools, techniques, and methods designed to protect the privacy and confidentiality of sensitive data while still enabling its collection, analysis, sharing, or use for valuable purposes (such as statistical insights, machine learning, or collaborative decision-making).

They operationalize core data-protection principles by minimizing personal data exposure, maximizing security/confidentiality, and/or empowering individuals/institutions to control what is revealed.

developer.mastercard.comIn the context of BIS Innovation Hub projects like Project Aurora (and its extension, Project Hertha), PETs are central to enabling Collaborative Analysis and Learning (CAL)—where multiple institutions (banks, fintechs, regulators, or even cross-border entities) jointly analyze data for anti-money laundering (AML), fraud detection, or financial-crime prevention without ever sharing raw sensitive information. Phase 1 of Aurora (concluded 2023) demonstrated that PETs combined with AI/ML and network analysis could detect up to 3× more complex money-laundering schemes than traditional siloed/rule-based approaches, while reducing false positives by up to 80%.

Phase 2 (launched July 2025, ongoing as of April 2026) focuses on real-world case studies and deployment.

PETs address the core tension in finance/compliance: regulators and institutions need richer, network-wide data views to fight crime effectively, but privacy laws (GDPR, data-protection rules), competition concerns, and security risks prohibit raw data sharing. PETs make this possible in a privacy-preserving way, which is why they are directly relevant to compliance mechanics in Project Agorá (on-ledger programmable attestations) and mBridge (cross-border CBDC certification).Core Categories and Mechanics of PETsBIS and other authorities (OECD, UN, etc.) classify PETs in various ways, but the most relevant ones for financial-crime prevention (as prioritized in Aurora’s open call and Phase 1 PoC) fall into these groups. Below are the priority techniques explicitly highlighted by BIS, with detailed mechanics, trade-offs, and AML examples.

bis.org

1. Differential Privacy (DP) and Local Differential Privacy (LDP)
   • Mechanics: Mathematically guarantees that the output of a query/analysis on a dataset is statistically similar whether or not any single individual’s data is included. It adds carefully calibrated “noise” (random perturbations) to the data, query results, or model outputs. In LDP, noise is added locally (at the data-owner’s side) before any sharing.
   • How it works in practice: For a transaction dataset, a bank adds noise to its local records → shares only the noisy aggregate or model update. The noise level is tuned via a “privacy budget” (ε parameter) to balance utility vs. protection.
   • AML/Finance Example: In Aurora Phase 1, LDP was applied to transaction-flow data (non-PII) so banks could contribute to network-mapping ML models without revealing exact flows.
   • Pros: Strong mathematical privacy guarantees; scalable for aggregates.
   • Cons: Noise can degrade model accuracy (trade-off with utility); harder for very small datasets.
   • Aurora Use: Combined with other PETs for non-sensitive transaction data.
2. Homomorphic Encryption (HE) — Partial or Full
   • Mechanics: Allows computations (addition, multiplication, or even complex functions) directly on encrypted data without decrypting it first. The result, when decrypted, matches what would have been computed on plaintext. “Partial” HE supports limited operations (e.g., addition only); “full” (FHE) supports any computation but is more computationally intensive.
   • How it works in practice: Bank A encrypts its data with a public key → sends ciphertext to a central server or peer → computations (e.g., ML training) run on ciphertext → only the final encrypted result is returned and decrypted by the authorized party.
   • AML/Finance Example: In Aurora, HE protected personally identifiable information (PII) like account identifiers during cross-border CAL, enabling secure model training on encrypted transaction networks.
   • Pros: Strong confidentiality; data never exposed in usable form.
   • Cons: High computational overhead (slower processing, higher resource use—though improving rapidly with hardware acceleration).
   • Aurora Use: Primary PET for sensitive PII data in the PoC.
3. Secure Multi-Party Computation (SMPC or MPC)
   • Mechanics: Multiple parties jointly compute a function over their private inputs without any party learning the others’ inputs (or anything beyond the final output). It uses cryptographic protocols (e.g., secret sharing, garbled circuits) to split data into shares that are meaningless alone.
   • How it works in practice: Each participant holds a “share” of the data; computations occur on shares across parties; only the aggregate result is reconstructed.
   • AML/Finance Example: Banks could jointly compute risk scores or network mappings for suspicious flows without any bank seeing another’s full transaction data.
   • Pros: Enables true multi-party collaboration with no trusted intermediary.
   • Cons: Communication overhead; scalability challenges for very large datasets.
   • Aurora Relevance: BIS explicitly lists it as a priority; complements HE in hybrid setups. bis.org
4. Zero-Knowledge Proofs (ZKP)
   • Mechanics: One party (prover) convinces another (verifier) that a statement is true without revealing any underlying information beyond the truth of the statement. Common variants: zk-SNARKs (succinct, non-interactive) or zk-STARKs.
   • How it works in practice: “I know a valid KYC check was performed on this customer” (proof) without sharing the customer’s documents or identity details.
   • AML/Finance Example: Attestations in compliance workflows (e.g., “this transaction passed sanctions screening” in a ledger like Agorá).
   • Pros: Minimal data leakage; efficient for verification.
   • Cons: Complex setup for some variants; proof generation can be compute-heavy.
   • Aurora Relevance: Prioritized for record-linking and verification use cases. bis.org
5. Trusted Execution Environments (TEE) / Confidential Computing
   • Mechanics: Hardware-based secure enclaves (e.g., Intel SGX, AMD SEV) create isolated “black-box” environments where code and data run encrypted in memory; even the host OS/cloud provider cannot access them.
   • How it works in practice: Sensitive computations run inside the enclave; results are attested (cryptographically verified) before release.
   • AML/Finance Example: Secure joint analytics on payment data across institutions.
   • Pros: Strong hardware-rooted security; good performance.
   • Cons: Relies on trusted hardware manufacturers; potential side-channel attacks.
   • Aurora Relevance: Listed as a priority blended solution. bis.org

Supporting/Complementary Techniques (often used with the above in Aurora):

• Federated Learning: Train ML models locally on private data; share only model updates (not raw data). Aurora tested this for decentralized CAL.
• Synthetic Data: Generate artificial datasets that statistically mirror real data for safe testing/training. Used in Aurora Phase 1 as a baseline.

How PETs Work Together in Practice (Aurora Example)

In Aurora Phase 1, the PoC combined PETs in hybrid setups (e.g., HE for PII + LDP for transaction flows) across simulated centralized/decentralized/hybrid CAL arrangements. Banks contributed privacy-protected insights → ML/graph neural networks analyzed networks → results showed superior detection without raw data exposure. This directly informs “integrity by design” in Agorá and potential enhancements to mBridge’s off-platform certification.

Challenges and Trade-Offs

• Performance: Many PETs (especially HE/FHE) add computational cost—though hardware and optimizations are rapidly improving.
• Utility vs. Privacy: Stronger privacy often means slightly less accurate models (the “privacy budget” trade-off).
• Legal/Regulatory: Need for clear governance, standards (e.g., ISO for HE), and alignment with FATF/GDPR. Aurora Phase 1 and Phase 2 explicitly address these.
• Scalability: Real-time vs. batch; cross-border legal hurdles remain.

In summary, PETs are not a single tool but a toolkit that makes privacy-preserving collaboration practical for high-stakes domains like AML. In the BIS ecosystem, they bridge the gap between siloed data (current reality) and powerful network-wide insights (future of compliance). Phase 2 case studies and the upcoming Agorá report will likely showcase further real-world maturation.

Project Mandala is a BIS Innovation Hub (Singapore Centre) proof-of-concept initiative exploring compliance-by-design for cross-border payments and digital asset transfers. It addresses one of the biggest frictions in global finance: disparate jurisdiction-specific regulatory requirements (e.g., AML/CFT, sanctions screening, capital flow management or CFM measures) that create duplication, delays, false positives, and high compliance costs.

Launched in 2023, the project encodes these rules directly into a common, decentralized protocol so compliance checks happen automatically, in real time, with cryptographic proofs—rather than through sequential, manual, or siloed processes. It builds explicitly on lessons from Project Dunbar (an earlier mCBDC experiment) and aligns with G20/FSB goals for faster, safer cross-border payments.

Current Status (as of April 2026)

• Phase 1 (completed October 2024): Successful PoC proving technical feasibility. Report published 28 October 2024 (« Project Mandala: Streamlining cross-border transaction compliance »). Focused on bilateral use cases between four jurisdictions. bis.org
• Phase 2 (launched November 2025, ongoing): Expanded scope to empirically evaluate benefits, broaden use cases, explore programmable compliance for digital assets (CBDCs, tokenized deposits), and test interoperability with other platforms. No production rollout yet—it remains experimental. bis.org

Phase 1 Participants (BISIH Singapore + central banks): Reserve Bank of Australia (RBA), Bank of Korea (BOK), Bank Negara Malaysia (BNM), Monetary Authority of Singapore (MAS), plus financial institutions.
Phase 2 Participants (expanded): Adds Banque de France, Reserve Bank of India (RBI), Central Bank of Kuwait, Bangko Sentral ng Pilipinas (BSP).

Core Mechanics: Compliance-by-Design ArchitectureMandala creates a decentralized peer-to-peer (P2P) network of nodes operated by commercial banks, central banks, and regulators. Each node runs three integrated components:

1. Policy Ingestion & Rules Engine
   • Jurisdiction-specific rules (sanctions lists, CFM thresholds, AML/CFT measures) are ingested from a standardized, machine-readable policy repository.
   • The rules engine standardizes inputs/outputs across borders, identifies applicable rules for a transaction (based on type, amount, jurisdictions, etc.), and generates a pre-validation checklist.
   • No central authority controls it—rules are queried and applied via P2P messaging. bis.org
2. Proof Engine
   • Automatically executes the checks and generates cryptographic proofs of compliance.
   • These proofs travel with the transaction (attached to a DLT-based digital asset or embedded in legacy messaging like ISO 20022 fields).
   • Downstream parties (e.g., beneficiary bank or regulator) can verify the proof instantly without re-performing the checks. bis.org
3. P2P Messaging Layer
   • Encrypted, low-latency communication (built with libp2p, QUIC, Kademlia).
   • Supports integration with settlement systems (e.g., wCBDC) or existing rails (e.g., SWIFT/ISO 20022). bis.org

Cryptographic Tools (Ties Directly to PETs):
Mandala heavily leverages the privacy-enhancing technologies (PETs) we discussed earlier:

• Zero-Knowledge Proofs (ZKPs) (e.g., ZK-STARK for scalability, ZK-SNARK via RISC Zero + Groth16 for on-chain verification) for non-interactive checks (public sanctions lists).
• Multi-Party Computation (MPC) (including private set intersection and homomorphic encryption) for interactive/private data (CFM thresholds, private sanctions lists).
• Additional: Secure comparisons, digital signatures, hashing (optimized SHA256 via FPGA/GPU).

This ensures privacy by design—no raw sensitive data is shared, yet compliance is verifiable and auditable.

Simplified Transaction Flow

1. Originating bank initiates transaction with details (jurisdictions, amount, type).
2. Rules engine queries/applies relevant rules via P2P.
3. Proof engine runs parallel checks (ZKP for public data; MPC for private).
4. Cryptographic proof set (with compliance check identifier) is generated and signed.
5. Beneficiary bank (or smart contract) verifies the proof instantly.
6. If valid → settlement proceeds (atomic with digital asset or messaging). Central banks get real-time monitoring/notifications for oversight (e.g., CFM dashboards).
   • Failure halts the process cleanly—no partial execution. bis.org

Tested Use Cases (Phase 1):

• Cross-border lending (Singapore–Malaysia): Loan drawdown/repayment with automated sanctions + CFM.
• Capital investment financing (South Korea–Australia): Securities acquisition with netting thresholds and reporting.

Both showed reduced manual work, real-time regulator visibility, and privacy preservation.

Key Benefits and Relation to Our Earlier Discussion

• Efficiency: Automates what is currently sequential and duplicative; enables straight-through processing and pre-validation.
• Real-Time Oversight: Central banks/regulators monitor without compromising privacy.
• Interoperability: Designed as a foundational compliance layer for any digital assets (CBDCs, tokenized deposits) or legacy systems—could plug into mBridge (enhancing its off-platform certification with on-protocol proofs) or Project Agorá (complementing its on-ledger programmable compliance).
• Privacy & PETs Synergy: Directly applies Aurora-style PETs (ZKP/MPC) at the transaction-protocol level, making compliance proactive rather than reactive.

In short, Mandala shifts compliance from a post-transaction burden to an embedded, verifiable feature of the payment itself. Phase 2 (ongoing) will test broader scalability and real-world utility. Like Agorá and Aurora, it remains experimental—focused on public goods rather than any specific geopolitical system (e.g., no sanctioned jurisdictions). Official resources: BIS project page, the October 2024 report, and technical explainer video. Developments in Phase 2 will likely appear in future BIS updates or the 2026 work programme.