Proposal: add ISO 20022 ↔ Canton Settlement Adapter

Development Fund Proposal Submission

Proposal file: /proposals/proposal-iso-20022-canton-settlement-adapter.md

Summary

This proposal requests funding for the ISO 20022 ↔ Canton Settlement Adapter, an open-source, bidirectional library that lets banks, PSPs, and custodians initiate and reconcile settlement on Canton straight from their existing payment systems, without a core-banking rewrite.

Canton's own documentation states there is no native ISO 20022 capability, and that integrators "must build an intermediary translation layer" themselves. With JPM Coin (Kinexys), DTCC tokenized Treasuries, and Visa (Super Validator) all live in 2026, that layer is the last step missing for institutional adoption. Today it is rebuilt privately by each institution, or it blocks onboarding.

We build it once, as a public good: standardized ISO 20022 messages (pacs.008, pacs.002, camt.05x) translate into CIP-56 token transfers and atomic DvP via the CIP-0103 dApp / JSON Ledger API, and back again.

In short:

• The institutional pipeline already speaks ISO 20022; Canton speaks CIP-56 / CIP-0103.
• This proposal delivers the reusable mapping layer plus a public conformance suite that bridges the two, instead of many fragmented private integrations.

It is not a message bus and not a new rail. Translation happens at the edge; Canton's private, atomically-composable settlement stays native.

What this delivers

• a published, versioned mapping standard (pacs.008 → CIP-56 transfer/DvP) plus a public golden-vector conformance suite;
• a working PoC at Milestone 1: a real pacs.008 drives a CIP-56 transfer on DevNet and returns a pacs.002 (open-source, CI-green, recorded demo);
• the reverse path: pacs.002 status and camt.05x statements generated from on-ledger events, with idempotent reconciliation keyed by MsgId/EndToEndId;
• atomic DvP via CIP-56 allocations (securities-vs-cash);
• a reusable JVM library plus CIP-0103 integration layer and a complete reference integration;
• security and data handling (no PII on-ledger, schema validation, signing via the institution's CIP-0103 provider, full audit trail);
• a clear party / instrument resolution model (IBAN/BIC/LEI → Canton party; currency → CIP-56 InstrumentId).

Disclosed Contracts and createdEventBlob Handling

The adapter does not fake or manually serialize createdEventBlob.

It reuses the existing token-standard registry choice-context mechanism: it queries the registry off-ledger API (e.g. POST /registry/transfer-instruction/v1/transfer-factory) for factoryId, choiceContextData, and disclosedContracts. Where a createdEventBlob has to be (re)fetched, it is read from the participant via the JSON Ledger API active-contracts query with includeCreatedEventBlob=true (or equivalent gRPC), cached by contract id, and attached to the submission.

The transfer is then exercised through the normal CIP-0103 / JSON Ledger API command path, the same way a compliant wallet does. No protocol or CIP-56/CIP-0112 changes are required.

Checklist

• [x] Proposal file added under /proposals/
• [x] Milestones and funding amounts defined (1,400,000 CC across 4 milestones, ~6 months)
• [x] Acceptance criteria included (adoption- and demonstration-based)
• [x] Alignment with Canton priorities described

Notes for Reviewers

This proposal is intentionally narrow and single-objective: v1 covers pacs.008 / pacs.002 / camt.05x plus DvP only; all other ISO 20022 message types are explicitly deferred / out of scope.

The main points:

• No competing work, real gap. There is no native ISO 20022 layer on Canton, and no other proposal builds one. #139 (FX Settlement) only claims compatibility. Canton's own docs say every integrator must build this layer themselves, so we build it once, as a public good, instead of many fragmented private versions.
• Force-multiplier, zero protocol risk. Every external payment expressed as a CIP-56 transfer makes the already-funded CIP-56 / CIP-0103 standards more valuable. It is purely additive: no protocol, ledger-contract, or CIP-56/CIP-0112 changes. It reuses the standard as-is and translates only at the edge, so Canton stays the private, composable settlement layer rather than a message bus.
• Plays to Canton's unique edge. Atomic, privacy-preserving DvP is exactly what legacy ISO 20022 rails cannot do, so this routes real institutional flows (the pipeline already runs on ISO 20022) onto Canton's core strength.
• De-risked, not a paper idea. A real pacs.008 → CIP-56 transfer → pacs.002 lands on DevNet at Milestone 1, and a public conformance suite makes "adopted" objective rather than aspirational.