Skip to main content
Musubi targets a specific regulatory category: cross-border VASP-to-VASP FX settlement under JP PSA / APTCP / APPI and KR SFIA / PIPA. In that category, compliance-at-the-edges — the permissionless-chain model where KYC happens at the exchange deposit boundary — is insufficient for what auditors and regulators actually expect of a regulated transfer. The architectural choice to carry compliance attestations on-chain, bound atomically to settlement, is what this page explains.

​
Compliance attestations on-ledger

A Musubi FXOrder doesn’t re-perform KYC or sanctions screening. Those run in the custodian’s existing stack — Persona, Chainalysis, CODE / Notabene — exactly as they always have. What Musubi captures on-ledger is an attestation that those checks ran, bound to the specific intent. Four concrete things fall out of that design:
  1. Atomic refusal-to-settle. ExecuteSettlement validates every required attestation before firing the four-leg DvP. A missing or stale gate aborts the transaction atomically: no tokens move, no partial state, no post-facto cleanup. Pre-chain, a missed compliance check was a policy violation to chase down. On-chain, the DvP simply does not happen.
  2. Cryptographic dual-control. Regulators require separation of duties for clearance decisions (operations + compliance officer). Procedural dual-control can be bypassed — a rogue operator back-dates a sign-off, an audit trail gets reconstructed. Dual signature on a Canton contract cannot. ComplianceClearance requires both signatures on the same transaction; neither party can unilaterally ratify.
  3. Single canonical dossier. /compliance/orders/{intent_id} returns the full cryptographically-linked record in one retrieval: FXOrder + IVMS 101 + every attestation + settlement hash. Traditional compliance reconstructs this from five disparate systems (KYC vendor, sanctions feed, Travel Rule log, STR portal, accounting), each with its own audit trail quality. Regulators asking “what happened on intent X?” get one answer, not five.
  4. Counterparty visibility with privacy. Canton sub-transaction privacy lets the beneficiary VASP see the IVMS 101 payload the sender transmitted, while the market maker never sees identity data. This is a native Canton primitive — approximating it on a transparent ledger requires ZK proofs, off-chain coordination, and new trust assumptions.
The compliance work is the same as any licensed EPI / VASP custodian does today. Musubi only adds the attestation layer so the DvP refuses to execute without it.

​
Canton architectural fit

On-chain compliance for regulated financial infrastructure isn’t a novel pattern — it’s the established use case Canton was built for. Deployed Canton systems using the same model:
  • Digital Asset × DTCC Project Ion — US securities clearing + settlement
  • Goldman Sachs DAP — tokenized bond issuance with regulatory compliance
  • HSBC Orion — tokenized gold with UK FCA reporting
  • Deutsche Börse Clearstream D7 — tokenized securities with CSDR compliance
  • Progmat (Mitsubishi UFJ Trust / Datachain) — JP stablecoin platform with EPI provider integration
Common pattern across all of them:
  • Compliance attestations as separate on-ledger contracts, bound to a transaction intent
  • Dual-signature for regulated actions (operator + officer, or equivalent)
  • Observer visibility for regulators and counterparties via Canton sub-transaction privacy
  • Multi-party DvP with atomic settlement
  • Gate logic in the settlement choice validating attestations before tokens move
Where Musubi makes stronger-than-default choices:
  • Custodian co-signs the FXOrder itself rather than observing + off-chain sign-off. Cryptographically enforces custodian authorization of every intent.
  • Full IVMS 101 inline on every intent. Daml Finance typically references PII off-ledger; Musubi inlines because the counterparty VASP needs to receive the payload via sub-transaction privacy, and the payload_sha256 chain in the compliance archive needs something canonical to hash.
  • Per-intent cross-border PII consent record. Less common in Canton financial contracts; captured per-transfer to satisfy a strict reading of JP APPI Art. 28 / KR PIPA Art. 28-8.
These choices are specific to cross-border VASP-to-VASP FX — not general Canton idioms.

​
When this model isn’t right

Worth naming: the on-chain attestation pattern has costs. It works where:
  • Participants are licensed VASPs / EPI providers — attestations are the custodian’s own representation, not a generic claim
  • Settlement is bilateral or small-set counterparty — Canton’s privacy model assumes known parties, not anonymous pool
  • The regulatory regime expects bank-grade audit trails — FATF Rec 16 Travel Rule, FSC / JFSA supervisory reporting
It’s less appropriate for pure retail payments, permissionless DeFi, or use cases where edge compliance is the accepted model. Those workloads have a different architecture — and that architecture has its own valid reasons. Related reading: Compliant Payments for the compliance thesis; FXOrder Reference for every on-ledger field with statutory basis; Trust Model for the party trust boundaries.