IPTF
concept hybrid I2I

Private ISO 20022 Messaging & Settlement

Coordinate private ERC-20 settlements between banks using ISO 20022 as the instruction layer. The ISO message binds to the on-chain cash leg, while the cash leg itself settles privately via a shielded mechanism (privacy L2, shielded pool, or confidential token) with regulator-only visibility.

CR
Medium
Censorship Resistance
O
Partial
Open Source
P
Full
Privacy
S
Medium
Security
CROPS context
Censorship Resistance
Reaches high when settlement runs on a single-chain shielded pool without a trusted relayer or gatekeeper. Drops to low when the private rail is operator-controlled or depends on a proprietary coprocessor with no open submission path.
Open Source
ISO 20022 schemas are open and widely adopted. SWIFT infrastructure is licensed and proprietary. The settlement rail determines overall openness: an open shielded pool improves the score, a proprietary FHE coprocessor degrades it. Reaches yes only when every component, including the ISO extension carriers and the settlement rail, is open-source.
Privacy
Cash-leg amounts and counterparties are hidden on-chain. The ISO instruction layer is off-chain and covered by existing bank-to-bank confidentiality practice. Metadata at intermediaries (correspondent banks that pass the message without understanding the extension) may still leak timing or existence.
Security
Rides on the settlement rail's cryptography (zero-knowledge proofs, FHE, threshold keys) and on signing conventions agreed between banks. Reaches high when signing algorithms, PKI, and the ISO extension registration are formally published and jointly governed.
Works best when
Institutions already exchange ISO 20022 messages (pacs.008, pacs.009, pacs.002, camt.\*).
On-chain settlement (ERC-20, tokenized deposits) must link to existing ISO or correspondent banking workflows.
Regulators require selective audit, not full transparency.
Avoid when
Institutions are not ISO-native (retail or DeFi-native apps).
Privacy is not a requirement and a public stablecoin is acceptable.
Intent

Coordinate private ERC-20 settlements between banks using ISO 20022 as the instruction layer. The ISO message binds to the on-chain cash leg, while the cash leg itself settles privately via a shielded mechanism (privacy L2, shielded pool, or confidential token) with regulator-only visibility.

Components
  • ISO 20022 schema and envelopes: pacs.008, pacs.009, pacs.002, camt.* messages plus the <SplmtryData> extension mechanism used to carry commitments and proofs.
  • Message commitment C_msg: hash of the canonical ISO message used to bind the settlement on-chain to the off-chain instruction.
  • Private settlement rail: a shielded pool, a confidential token layer, or a privacy L2 that performs the cash-leg transfer with amounts and counterparties hidden on-chain.
  • Rollup or validium anchor for minimal on-chain metadata (message type, coarse time bucket, status).
  • Off-chain services: ISO parsing and canonicalization (XML to canonical JSON), KMS for bank and regulator keys, and a selective-disclosure service.
  • Settlement controller: optional permissioned actor that authorizes confidential transfers on a permissioned confidential-token rail.

The shielded pool details live in pattern-shielding; the privacy L2 option in pattern-privacy-l2s; DvP coupling in pattern-dvp-erc7573.

Protocol
1
[user] Bank A issues an ISO 20022 message (e.g., `pacs.008` for a customer credit transfer) to Bank B.
2
[user] Off-chain, both banks compute `C_msg` from the canonical form of the ISO message.
3
[contract] Minimal ISO metadata and `C_msg` are anchored on a rollup or validium.
4
[contract] Variant A: the cash-leg ERC-20 is wrapped into a shielded pool and held as notes. A shielded transfer executes from Bank A's note to Bank B's note with `C_msg` bound inside the spend circuit.
5
[contract] Variant B: a confidential ERC-20 with encrypted balances executes a confidential transfer authorized by the settlement controller, referencing `C_msg`.
6
[contract] Variant C: both cash legs are temporarily bridged to a shared privacy L2. A single shielded DvP or PvP transaction referencing `C_msg` executes, then assets bridge back to their origin chains.
7
[regulator] The supervisor holds view keys for scoped audits (amounts, parties, routes as needed) and can decrypt selected fields or inspect shielded transfers.
Guarantees & threat model

Guarantees:

  • Privacy: cash-leg amounts and counterparties are hidden on-chain.
  • Integrity and linkage: settlement references C_msg so the cash leg is cryptographically tied to the ISO instruction.
  • Auditability: regulators can decrypt selected fields or use view keys to audit shielded transfers.
  • Interoperability: ISO schema provides consistent mapping across banks and corridors.

Threat model:

  • Settlement rail soundness (zero-knowledge proof system, FHE scheme, or confidential VM).
  • Signing-convention agreement between banks. Algorithm choice, PKI, and canonicalization (full ISO hash versus reduced settlement tuple) must be jointly specified.
  • Cross-chain atomicity under partition. Variants A and B can strand one leg if the two sides sit on different chains without an atomic bridge; variant C mitigates via single-domain execution but introduces bridge risk.
  • Intermediate-correspondent exposure. Non-participating intermediaries pass the message unchanged but cannot verify the proof in transit, so they must trust endpoints to catch invalid extensions.
  • Regulator key custody. Compromised view keys expose historical audit scope.
Trade-offs
  • The private rails in variants A and B add infra complexity (shielded circuits or confidential VM) and require key governance.
  • Cross-chain atomicity requires zk-SPV-style bridges or single-domain execution. Two-chain designs without an atomic bridge can fail partially.
  • Incremental rollout via <SplmtryData> "can ignore" semantics works but limits correspondent-chain visibility until endpoints upgrade.
  • Formalizing the extension requires a Change Request to the relevant ISO SEG to register an Extension MessageDefinition for proof data as a first-class component; without this, adoption remains bilateral.
Post-quantum
high risk
Vector: Cash-leg settlement rail typically uses EC-based zero-knowledge proofs (Groth16, PLONK/KZG) or pairing-based threshold encryption, all broken by CRQC. HNDL risk is high because correspondent-banking payloads are archived for years.
Mitigation: Migrate the settlement rail to STARK-based shielded pools with hash commitments; use lattice-based threshold encryption for any encrypted message envelopes.
Example
  • Bank A issues pacs.008 to pay 10m EURC from DEUTDEFFXXX to BNPAFRPPXXX.
  • Off-chain, both banks compute C_msg from the canonical ISO message.
  • Variant A: EURC is wrapped into a shielded pool and a note-to-note transfer bound to C_msg executes.
  • Variant B: a confidential-token transfer with encrypted state references C_msg.
  • Variant C: both legs bridge to a shared privacy L2, a single shielded DvP executes referencing C_msg, and assets bridge out.
  • The supervisor later audits via view keys and selective disclosure.