Skip to main content

Documentation Index

Fetch the complete documentation index at: https://musubinetwork.com/llms.txt

Use this file to discover all available pages before exploring further.

Status: this page is undergoing external legal review. Content is subject to change — in particular as the Korean Digital Asset Basic Act (디지털자산기본법) moves through the National Assembly, several of the SFIA-era rules cited here will be superseded or augmented.
Every settled FXOrder on Musubi leaves a complete, cryptographically-chained regulatory record. This page describes how that record is built up as the order moves through its lifecycle, how regulators retrieve it, which parts are independently verifiable, and how long it’s retained. For the field-level schema, see the FXOrder reference.

​
How the audit trail accretes

The record grows as the order transitions through its status states. We’ll use the same example as the Reporting page — Acme Corp. (JP) paying Hanguk Partners Ltd. (KR) 100,000 USDCx — to show what lands on-ledger at each stage.
1

FXOrder created (status = PENDING)

The operator drafts an FXOrderProposal with compliance metadata pulled from Nihon Custody’s existing systems; Nihon Custody exercises AcceptOrderProposal and the co-signed FXOrder is committed to the ledger.Now on-record: intentId, timestamps, SenderInfo (including full IVMS 101 originator + crossBorderConsent), ReceiverInfo, SourceAsset, TargetAsset, ComplianceInfo (KYC, sanctions, risk, jurisdictions, purpose). QuoteInfo, MarketMakerInfo, SettlementInfo are placeholder until later stages.Counterparty visibility: the receiver’s custodian sees the IVMS payload via Canton sub-transaction privacy. Market makers see only the anonymised quote request.
2

Pre-DvP attestations accrue (status = EXECUTING)

Separate attestation contracts bind to intentId as the custodian’s compliance pipeline emits them:
  • ComplianceAlert records threshold / velocity / sanctions-hit events. For the example, the ≈ ¥11.2M / ₩135M transaction raises a TRAVEL_RULE alert at INFO severity. No BLOCK alert (LOW risk, sanctions clear), so no STRFiling is needed.
  • TravelRuleAttestation records the transmission: provider (CODE), provider message ID, SHA-256 of the canonical IVMS payload, and transmittedAt.
  • RegisteredVASP entries for the originating and beneficiary VASPs — already on-ledger, maintained continuously by the operator.
  • ComplianceClearance — dual-signed by operator + compliance officer, attesting alerts resolved / KYC verified / sanctions cleared. Short TTL (default 1h).
3

Atomic settlement (status = SETTLED)

ExecuteSettlement validates every attestation, then fires the four-leg DvP atomically. SettlementInfo is written with transactionHash, settledAt, and actualSourceAmount.The transactionHash is a single cryptographic proof covering all four legs — independently verifiable by any party to the trade, and the definitive reconciliation reference.
4

Archived

The settled intent is serialised into the compliance_archive table: FXOrder + IVMS 101 + every attestation + settlement hash. Each row carries a payload_sha256 and a prev_row_sha256 pointing at the previous archive row, forming a tamper-evident chain. Any retroactive modification breaks the chain downstream and surfaces at the next integrity check.From this point, the record is available on demand via the regulator dossier endpoint below.

​
The regulator dossier endpoint

The full per-intent audit record is retrievable at: 
GET /compliance/orders/{intent_id}
Response is a ComplianceSnapshot containing, in compact shape: 
{
  "intent_id": "550e8400-e29b-41d4-a716-446655440099",
  "kyc_status": "KYC_VERIFIED",
  "kyc_verified_at": "2026-04-19T02:00:00Z",
  "sanctions_status": "SANCTIONS_CLEARED",
  "sanctions_list_version": "OFAC-2026-04-18",
  "jurisdiction_sender": "JP",
  "jurisdiction_receiver": "KR",
  "purpose_code": "GDDS",
  "risk_rating": "LOW",
  "pep_status": "NOT_PEP",
  "originator": { /* IVMS 101 originator */ },
  "originating_vasp": { /* VASPIdentifier */ },
  "beneficiary": { /* IVMS 101 beneficiary */ },
  "beneficiary_vasp": { /* VASPIdentifier */ },
  "cross_border_consent_originator": { /* ConsentRecord */ },
  "cross_border_consent_beneficiary": { /* ConsentRecord */ },
  "alerts": [ /* ComplianceAlert[] */ ],
  "str_filings": [ /* STRFiling[] */ ],
  "clearance": { /* ComplianceClearance */ }
}
Regulator requests are typically serviced inside the statutory 72h SLA. See the FXOrder reference for the shape of each nested record.

​
Independently-verifiable cryptographic proofs

Three things can be verified without access to Musubi’s running systems:
  • intentSignature — the sender’s off-chain signature over the intent payload. A regulator holding the FXOrder record can verify it against the sender institution’s published public key, confirming authorship of the exact order contents (amount, currency, counterparty).
  • transactionHash — the atomic DvP proof. Covers all four settlement legs and binds the four-party multisig into a single settlement reference, verifiable against the Canton participant logs.
  • payload_sha256 chain — any regulator holding a snapshot of the archive can re-hash each row and confirm that prev_row_sha256 matches the prior row’s payload_sha256 end-to-end. A broken chain points at the first tampered row.

​
Retention windows

JurisdictionMinimum retentionStatute
Japan7 yearsAPTCP Art. 7 (取引記録の保存)
Japan7 years (crypto exchange records)PSA Art. 63-13
South Korea5 years minimumSFIA Art. 5-4
FATF5 yearsRec 11
Musubi archives to the longer of JP / KR / FATF windows for simplicity — effectively a 10-year retention in production operations.

​
What the audit trail doesn’t carry

  • Raw KYC documents or customer file scans — stays in the custodian’s KYC platform
  • Provider API payloads (Chainalysis hit details, CODE envelope wrapper bytes) — stays with the provider
  • Data-subject access workflow + consent revocation mechanics — see Privacy
  • FXOrder reference — field-level schema + JP / KR / FATF statute citations for every field.
  • Reporting — lifecycle walkthrough of which attestations fire, in order.
  • Compliant Payments — the compliance thesis at a glance.