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.