Category: ISO-20022-to-blockchain messaging spec / Travel Rule and payment-instruction interoperability infrastructure / docs-first compliance and remittance standard
Summary: pacs.crypto is best cataloged as docs-first financial-messaging interoperability infrastructure rather than as a Travel Rule network, bank integration vendor, or generic compliance API. Its primary materials are a GitHub README plus raw OpenAPI specifications that adapt ISO 20022 payment structures — especially pacs.008 and adjacent status/cancellation semantics — to blockchain transfers, Travel Rule records, structured remittance data, and bank-to-VASP instruction flows. The clearest categorization clue is that pacs.crypto is defining message formats and operational interfaces that can sit above or alongside existing networks such as TRISA or TRP instead of replacing those networks or operating as a service provider itself.
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 off-chain 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 RemittanceInformation26 off-chain 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.