Skip to main content
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.
The FXOrder is a coordination record that binds a custodian’s existing compliance stack to an atomic cross-border settlement. Nothing on it replaces a compliance function the custodian already operates — KYC, sanctions, Travel Rule transmission, STR filing, retention all run where they run today. The FXOrder gives them hooks that let DvP refuse to execute when a step hasn’t run.

​
Reporting lifecycle of an FXOrder

Reporting artefacts accrue to an FXOrder as it moves through its status states. This section walks a concrete example — Acme Corp. (JP) paying Hanguk Partners Ltd. (KR) 100,000 USDCx — from custodian pre-flight through compliance archive, showing which attestations fire at each transition and which custodian system produces them.

​
The example

intentId:     550e8400-e29b-41d4-a716-446655440099
createdAt:    2026-04-19T09:00:00Z
expiresAt:    2026-04-19T09:15:00Z

sender:
  Acme Corp. (JP) — account JP-ACCT-SENDER-001
  originatingVASP: Nihon Custody Co.   (JP-VASP-0001)

receiver:
  Hanguk Partners Ltd. (KR) — account KR-ACCT-RECEIVER-001
  beneficiaryVASP: Hanguk Digital Asset Services (KR-VASP-0001)

sourceAsset:  JPYSC0, sourceAmountMax = 12,000,000
targetAsset:  USDCx, targetAmount = 100,000   (receiver-fixed)

compliance:
  KYC_VERIFIED (Persona, expires 2027-04-19)
  SANCTIONS_CLEARED (Chainalysis, list OFAC-2026-04-18, 09:00:00Z)
  riskRating = LOW, pepStatus = NOT_PEP
  jurisdictionSender = JP, jurisdictionReceiver = KR
  purposeCode = GDDS
A realistic cross-border institutional flow: well above FATF USD 1K threshold, so Travel Rule applies.

​
What fires at each status

StatusWhat fires in the reporting lifecycle
(pre-intent)Custodian’s existing KYC / sanctions / risk checks run off-ledger
PENDINGFXOrder created with ComplianceInfo; IVMS 101 snapshotted from the KYC file
QUOTEDQuote + MM info populated. No compliance activity.
EXECUTINGAttestations accrue: TravelRuleAttestation, ComplianceAlert (if any) + STRFiling resolution, ComplianceClearance
SETTLEDDvP gate passes → tokens move atomically → accounting + compliance archive
1

Pre-flight (off-ledger)

Nothing has touched Musubi yet. Nihon Custody’s existing stack runs the checks it always did: Persona confirms Acme’s KYC is current, Chainalysis confirms sanctions screening is within 24h, the cross-border consent record for the JP→KR corridor is valid, internal risk assessment holds riskRating = LOW.This is what every licensed EPI provider already does for any outbound transfer to another VASP. Musubi asks for nothing new at this stage.
2

FXOrderProposal → FXOrder (status = PENDING)

The operator drafts FXOrderProposal with compliance metadata pulled from Nihon Custody’s systems: KYC status + provider + expiry from Persona; sanctions status + list version from Chainalysis; risk rating from the internal assessment; IVMS 101 originator built from Acme’s KYC file. Nihon Custody exercises AcceptOrderProposal → the co-signed FXOrder is created.All example fields above are now populated on-ledger. QuoteInfo, MarketMakerInfo, SettlementInfo remain empty until later stages.Statutes engaged: APTCP Art. 4 / SFIA Art. 5-2(1) (KYC attestation); APTCP Art. 10-5 / SFIA Art. 5-2(5) (IVMS); APPI Art. 28 / PIPA Art. 28-8 (cross-border consent).
3

PENDING → QUOTED → EXECUTING

The operator broadcasts an anonymised RFQ to market makers, who see currency pair + amount but not identity. A market maker quotes 11,200,000 JPYSC0 for the 100,000 USDCx target. Acme accepts → AcceptQuote populates QuoteInfo and MarketMakerInfo and updates sourceAsset with the quoted cost. BeginExecution transitions the FXOrder to EXECUTING.No compliance activity fires here. Market makers never see IVMS 101 — Canton sub-transaction privacy keeps it on the custodians’ participants.
4

Pre-DvP attestations accrue

Most of the reporting work lands at this stage. In order:
  • Threshold monitoring. The operator’s monitoring converts 100,000 USDCx against the captured mid-market rate (≈ ¥11.2M / ₩135M) and raises a ComplianceAlert(alertType = TRAVEL_RULE, severity = INFO). No BLOCK alert in this example — LOW risk, sanctions clear — so no STRFiling is required.
  • Travel Rule transmission. Nihon Custody fires its existing CODE client with the IVMS 101 payload, receives a provider message ID back, and posts TravelRuleAttestation(intentId, provider = "CODE", providerMessageId = "code-tx-abc", payloadHash = sha256(canonical IVMS), transmittedAt = 09:00:30). This is the net-new Musubi integration touch point; the CODE integration itself is unchanged.
  • VASP whitelist. RegisteredVASP entries for JP-VASP-0001 and KR-VASP-0001 already exist — the operator maintains them continuously, not per-intent.
  • Compliance officer clearance. The officer reviews the open intent, confirms alerts resolved (INFO doesn’t require resolution), KYC verified, sanctions cleared → dual-signs ComplianceClearance(intentId, expiresAt = 09:10:00).
5

ExecuteSettlement (EXECUTING → SETTLED)

The DvP gate runs atomically. For this intent every check passes:
  • ComplianceClearance bound to intentId, within 1h freshness ✓
  • JP-VASP-0001 and KR-VASP-0001 both in the active RegisteredVASP set ✓
  • KYC not expired (2027-04-19) ✓
  • Sanctions within 24h freshness (screened 09:00:00, settling 09:00:45) ✓
  • Cross-border + above threshold → TravelRuleAttestation bound, payloadHash matches canonical IVMS, within 24h ✓
DvP fires. All four legs move atomically; SettlementInfo is written with transactionHash, settledAt, and actualSourceAmount = 11,200,000.A missing or stale attestation aborts the settlement atomically — FXOrder remains in EXECUTING and no tokens move. Pre-Musubi a miss was a post-facto policy violation; on Musubi the DvP simply does not happen.
6

After settlement

Nihon Custody’s accounting subscribes to Canton / PQS events on the FXOrder, consumes SettlementInfo + transactionHash, and reconciles Acme’s book balance from JPYSC0 → USDCx against the settlement proof hash. The compliance archive captures a snapshot — FXOrder + IVMS 101 + all attestations + settlement hash — into the SHA-256 payload chain for retention. The regulator dossier endpoint /compliance/orders/{intent_id} can re-emit the full audit trail on demand.
Almost every activity above uses infrastructure the custodian already operates. Net-new integration surface is narrow: one HTTP client against the Musubi institution API, one Canton / PQS event listener feeding internal accounting, and one attestation webhook firing from the tail of the custodian’s existing compliance pipeline. KYC / sanctions / Travel Rule / STR vendor integrations are unchanged.

​
What the FXOrder deliberately doesn’t carry

  • Raw KYC documents or customer file scans — stays in the custodian KYC platform
  • Provider API payloads (Chainalysis hit details, CODE envelope wrapper, Travel Rule message bodies) — stays with the provider
  • Fiat FX reports (BOJ FEFTA Art. 55, BOK FETA business reports) — handled by the institution’s own designated FX bank; Musubi never touches fiat
  • Cross-border PII consent mechanics (revocation workflow, data-subject access log) — see Privacy
  • 10-year retention specifics + payload hash chain — see Audit Trail

​
Why there’s no MT103

Musubi is EPI-to-EPI exchange between licensed VASPs under JP PSA Art. 62-3 and KR SFIA — not a SWIFT bank wire. No statute we operate under requires MT103 on-ledger; every MT103 field duplicates data already carried by FXOrder.intentId (unique reference), ComplianceInfo.purposeCode (ISO 20022 purpose), and FXOrder.memo (remittance info). IVMS 101 carries the FATF Travel Rule PII. If a fiat-edge bank downstream requests MT103 on export, the backend synthesises it from those fields — not the core protocol’s concern.

​
Reference

For the full field-level schema and statute-by-field citations (JP / KR / FATF), see the FXOrder reference.