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.

Your compliance obligations as a licensed custodian don’t change on Musubi. KYC, sanctions screening, Travel Rule transmission, STR filing, and retention all run where they run today — in the vendors and processes you already operate. What Musubi adds is a small set of on-FXOrder attestations whose presence lets DvP refuse to settle when a compliance step hasn’t run.

​
What you attest to on the FXOrder

Every field below is on ComplianceInfo on the FXOrder at the moment of order creation. They are snapshotted from your existing systems — not re-verified by Musubi.
AttestationSource in your stackWhere on the FXOrder
KYC status + provider + expiryYour KYC vendor (Persona, Sumsub, Jumio, etc.)kycStatus, kycProvider, kycExpiresAt
Sanctions status + provider + list version + freshnessYour sanctions vendor (Chainalysis, Elliptic, TRM, etc.)sanctionsStatus, sanctionsProvider, sanctionsListVersion, sanctionsFreshnessWindow
Risk rating + PEP statusYour risk-scoring + PEP screening processriskRating, pepStatus, pepCheckedAt
Jurisdiction + purpose codeInstitutional client recordjurisdictionSender, jurisdictionReceiver, purposeCode
IVMS 101 originator / beneficiary identityYour KYC filesender.originator, receiver.beneficiary
Cross-border PII consentYour onboarding / consent workflowsender.crossBorderConsent, receiver.crossBorderConsent
Field-level types and statute citations: FXOrder Reference. Lifecycle view of when each field populates and which gate enforces it: Reporting.

​
What stays in your existing stack

Musubi does not integrate with any of the following. They continue to run exactly as they do today for your non-Musubi flows:
  • KYC vendor — Persona, Sumsub, Jumio, in-house, etc.
  • Sanctions vendor — Chainalysis, Elliptic, TRM Labs, etc.
  • Travel Rule provider — CODE, VerifyVASP, Notabene, TRUST, Sygna — whichever your jurisdiction requires. The IVMS 101 payload on the FXOrder is Musubi-internal; transmission over a regulated Travel Rule network for your KoFIU / JVCEA / FATF filing remains your responsibility on your existing client.
  • STR filing pipeline — your existing JAFIC / KoFIU submission workflow for BLOCK-severity alerts.
  • Compliance archive + retention — your existing archive; Musubi retains an on-ledger copy independently for 10 years, but does not replace your internal archive.
The attestation fields above are metadata describing what your stack has done, not replacements for doing it.

​
How your co-signature becomes the audit artifact

You are a signatory on the FXOrder template. When you exercise AcceptQuote, the resulting co-signed contract captures quote_accepted_at — a cryptographically-bound timestamp of the exact moment you authorized asset movement at the selected rate. Later, when ExecuteSettlement fires, the settlementInfo is written to the same record under the same signature chain. A regulator querying the audit trail sees one signed contract covering your authorization decision, the rate you approved, the compliance attestations you witnessed, and the settlement proof — not four disconnected systems to reconcile. For the full accretion + retention + dossier-retrieval model, see Audit Trail.

​
Whitelist model

Your existing withdrawal whitelist model applies unchanged:
  • Whitelist the Musubi settlement address — the only destination that receives assets during DvP.
  • No other outbound destinations are reachable through Musubi’s settlement flow.
  • One-time setup, not per-transaction.
Your whitelist authorization and your per-trade co-signature form a two-layer defense: the whitelist controls where assets can go; the co-signature controls when and how much.