pacs.crypto primary sources — 2026-05-03

Project status in this pass

  • No canonical standalone pacs.crypto whitepaper or litepaper surfaced.
  • The clearest current source of truth is the main GitHub repository README plus raw OpenAPI specifications for the Travel Rule and payment-instruction APIs.
  • The materials consistently frame pacs.crypto as a community proposal for ISO-20022-aligned blockchain message formats and workflows rather than as a finished standard, managed network, or compliance vendor product.

Primary-source snapshots

1) Repository README

  • URL: https://raw.githubusercontent.com/tomalaerts-dev/pacs.crypto/main/README.md
  • Key excerpt:
    • The README says pacs.crypto is an open specification family bridging ISO 20022 standards to crypto-asset payments, covering FATF Travel Rule compliance, structured payment instructions, and blockchain account reporting.
    • It says each specification preserves ISO 20022 field semantics while adding blockchain-specific token, chain, wallet-address, and bridge-transfer handling.
    • It also explicitly says the project is a community proposal rather than a finished standard.

2) Travel Rule & Remittance Information API

  • URL: https://raw.githubusercontent.com/tomalaerts-dev/pacs.crypto/main/travel-rule-api-v3.yaml
  • Key excerpt:
    • The OpenAPI document says the API serves both Travel Rule compliance and commercial structured-remittance exchange for blockchain transfers.
    • It emphasizes that the data model mirrors pacs.008.001.14 closely enough that banks can source the necessary fields directly from existing back-office payment pipelines without extra transformation.
    • It also states that the spec defines an API format and REST interface, not a Travel Rule network or transport protocol, and says it can be carried over existing channels such as TRISA or TRP.

3) Travel Rule design boundaries

  • URL: https://raw.githubusercontent.com/tomalaerts-dev/pacs.crypto/main/travel-rule-api-v3.yaml
  • Key excerpt:
    • The spec says the callback and rejection paths are for data-quality acknowledgement, not sanctions pre-clearance or sanctions-hit notification.
    • It argues that communicating sanctions findings to the sending side would create tipping-off risk and explicitly warns implementers not to repurpose the existing fields for that use.
    • This is useful evidence that pacs.crypto is trying to define operationally realistic compliance message behavior, not just a field schema.

4) Blockchain Payment Instruction API

  • URL: https://raw.githubusercontent.com/tomalaerts-dev/pacs.crypto/main/instruction-api-v1.yaml
  • Key excerpt:
    • The document says it is the second specification in the pacs.crypto family and lets a bank or corporate treasury instruct a VASP to execute blockchain token transfers using pacs.008-shaped payment data.
    • It supports both full custody and delegated signing, quote flows, ramp instructions, slippage control, expiry windows, finality reporting, and deterministic mapping between ISO-style statuses and blockchain-specific statuses.
    • It repeatedly frames the goal as making blockchain execution fit into bank treasury and back-office systems that already understand ISO 20022 idioms.

Working conclusion

pacs.crypto is best cataloged as docs-first interoperability and control-plane standardization for regulated crypto payments. The deciding evidence in this pass was the combination of ISO-20022-native data modeling, explicit coexistence with existing Travel Rule networks, structured remittance support, bank-to-VASP instruction flows, and unusually detailed reasoning about operational status, sanctions boundaries, and treasury-system compatibility.