pacs.crypto Control Room: Watching an ISO 20022 Crypto Payment End to End

A work-in-progress look at the pacs.crypto Control Room: a bank-to-VASP walkthrough that follows one crypto payment from Travel Rule submission to a camt.053-style creditor statement, built on the open pacs.crypto specification family with Tom Alaerts (ex-SWIFT).

I have been working with Tom Alaerts, the ex-SWIFT standards expert behind the pacs.crypto initiative, on an open specification family that bridges ISO 20022 to crypto asset payments. This post shares a current work in progress from that collaboration: the pacs.crypto Control Room, a demo cockpit that walks one payment across the full bank-to-VASP lifecycle. The demo video above shows it in action.

What pacs.crypto is

pacs.crypto is a proposed family of open API specifications and message standards, offered as a community proposal rather than a finished standard. Each specification takes a well-defined ISO 20022 message or component and extends it purposefully for the blockchain context: chain identification, token identification, wallet address handling, and bridge transfers, while preserving the data model and regulatory alignment ISO 20022 already provides.

The family currently spans five specifications: FATF Travel Rule compliance, structured payment instructions with returns and reversals as compensating transactions, blockchain account reporting, exception and investigation flows aligned with camt.110/camt.111, and own-account liquidity management. The v1.3 release also introduced optional debtor and creditor agents for corporate self-hosting flows and a SELF_CUSTODY model.

What the Control Room shows

Specifications are read by architects. Payments people want to see the message flow. The Control Room is a presenter-grade walkthrough that follows a single payment between an instructing bank and a receiving VASP across roughly a dozen scripted steps:

  1. Compliance first. The Travel Rule record is submitted before any execution happens, and the receiving VASP accepts on the same record. One linked object, one record_id, many readers, zero duplication. The beneficiary side is never handed a fresh copy of the payload to reconcile.
  2. Instruction. Fee quote, then the payment instruction is submitted. The commercial payment identifiers stay visible while execution moves to the chain adapter.
  3. Settlement. The adapter broadcasts to the chain, and confirmations accumulate toward an explicit finality threshold. Depth-based finality is treated as a first-class, auditable claim: the payment is not final until it crosses the threshold, and the demo refuses to call it done early.
  4. Reporting. Finality evidence (transaction hash, block reference, confirmation depth) feeds a credit notification and finally a creditor statement, a camt.053 analogue any bank would recognize: opening to closing balance, one credit entry, every line traceable back to the original instruction and the Travel Rule record the flow started with.

The right-hand side of the screen keeps a traceability spine: one payment, the same identifiers reused across every surface, never re-sent. That is the linked-context discipline the specification family is built around.

Demo posture, honestly stated

This is a work in progress and a reference demo, not a product. The walkthrough runs in a mock mode that needs no server and no funded chain, and it can switch to a local live API mode where the same shell calls a local reference server and exercises real validation and lifecycle handling, including against a public testnet. Party names are illustrative. Nothing here claims production readiness or live payment decisioning.

Why it matters

Banks processing pacs.008 today should not need a custom translation layer for every crypto-native counterparty, and structured payment data should not be lost at the crypto conversion point. If the industry can watch an ISO 20022-shaped crypto payment move end to end, with compliance in front and finality treated as evidence rather than vibes, the conversation about production adoption gets a lot more concrete.

The specification family and its design arguments are public in the pacs.crypto repository. Feedback, challenge, and contributions are welcome. More on this as the work progresses.

Topics: ISO 20022, Payments, Stablecoins, Crypto, Compliance, Innovation