pacs.crypto
- Name: pacs.crypto
- URL: https://github.com/tomalaerts-dev/pacs.crypto
- Category: ISO-20022-to-crypto messaging standard / Travel Rule and payment-instruction schema layer
- Summary: pacs.crypto is a message-format note, not a network. The useful part is that it maps ISO 20022 payment and Travel Rule structures onto crypto transfers, status flows, remittance data, and bank-to-VASP handoffs without pretending to solve transport, PKI, or counterparty discovery.
- What it does:
- Defines a Travel Rule and remittance-information API that models originator, beneficiary, remittance, and reporting fields directly on pacs.008.001.14 while adding blockchain-specific chain, token, wallet, and attestation fields
- Defines a blockchain payment-instruction API that lets a bank or treasury instruct a VASP to execute token transfers using ISO-20022-shaped payment data, quote flows, status requests, cancellations, and settlement reporting
- Ships self-contained HTML simulators for both specifications so implementers can explore endpoint behavior without standing up a server
- Positions the Travel Rule API as compatible with structured remittance exchange, letting blockchain payments carry invoice and payment-purpose context offchain in a form more familiar to banking and ERP systems
- Explicitly supports both full-custody and delegated-signing models in the instruction API, including unsigned transaction return and later signed-transaction resubmission
- Reuses adjacent ISO 20022 idioms such as pacs.002-style status alignment, pacs.028-style status requests, and camt.056/camt.029-style cancellation semantics so the blockchain workflow fits more naturally into existing treasury or bank-processing stacks
- Key claims:
- The README describes pacs.crypto as a proposed family of open specifications bridging ISO 20022 standards to crypto-asset payments and repeatedly says it is a community proposal rather than a finished standard
- The project says its Travel Rule API keeps data structures modeled directly on pacs.008.001.14, which is important because the main claimed advantage is lower translation friction for banks and institutions already using ISO 20022 fields internally
- The Travel Rule materials say the API is transport-agnostic and can sit alongside TRISA, TRP, OpenVASP, or direct bilateral deployments, which strongly suggests pacs.crypto should be cataloged as a message-format layer rather than as a network or counterparty-discovery service
- The Travel Rule spec also says it carries structured
RemittanceInformation26offchain so invoice references and payment-purpose data are not lost when value moves over blockchain rails - The raw Travel Rule OpenAPI description spends substantial space arguing that the design is not a sanctions pre-clearance channel and that callback or rejection fields must not be repurposed for tipping-off sensitive compliance findings, which is an unusually operational and compliance-aware part of the project’s identity
- The instruction API says a bank or treasury can submit ISO-20022-shaped instructions to a VASP for onchain execution, including quote locking, slippage controls, ramp instructions, finality semantics, and delegated signing support
- The instruction spec explicitly maintains dual-layer status with both ISO-style and blockchain-specific statuses, which is a strong clue that the project is meant to plug into existing treasury and bank back-office systems instead of creating an entirely crypto-native operational vocabulary
- Across the materials, the project is careful to describe what it does not define — discovery, PKI/CA model, legal agreements, or transport network membership — which is the clearest evidence that it is standardizing the payload and workflow layer rather than presenting itself as a full network operator
- Whitepaper: No canonical standalone pacs.crypto whitepaper or litepaper surfaced in this pass. The clearest current source of truth was the main repository README together with the raw OpenAPI specifications for the Travel Rule and instruction APIs; see
../../whitepapers/pacs-crypto-primary-sources-2026-05-03.md. - Sources:
- https://github.com/tomalaerts-dev/pacs.crypto
- https://raw.githubusercontent.com/tomalaerts-dev/pacs.crypto/main/README.md
- https://raw.githubusercontent.com/tomalaerts-dev/pacs.crypto/main/travel-rule-api-v3.yaml
- https://raw.githubusercontent.com/tomalaerts-dev/pacs.crypto/main/instruction-api-v1.yaml
Internal linkages
- Best adjacent reads: trisa, travel-rule-protocol, and notabene.
Control surface
-
pacs.crypto is narrow by design.
-
The leverage comes back in transport choice, PKI and directory policy, which fields counterparties actually require, and how VASPs turn status or rejection callbacks into real compliance gating.
-
Treat it as a schema layer that plugs into stronger operator stacks, not as a network center of gravity.
-
Last reviewed: 2026-06-08 UTC