What stays the same
| Existing system | Role unchanged |
|---|---|
| Treasury / payments | Decides who to pay, how much, and when — before anything reaches Musubi |
| FX risk policy | Cost guard (source_amount_max), acceptable slippage, approved counterparties |
| KYC/AML process | Your compliance team runs this on your customers and counterparties as today |
| Custodian relationship | Your custodian holds the stablecoins and co-signs every settlement |
| Counterparty directory | Receiver institution + custodian Party IDs come from your existing counterparty records |
| Accounting / general ledger | Consumes settlement confirmations and reconciles like any other settled transfer |
Architecture
Your custodian participates in every settlement — their co-signature is one of four required for the atomic DvP. You don’t need to run your own Canton participant if your custodian’s infrastructure handles it; standing up your own backend is optional for institutions with custom treasury automation.The three pages in this section
Onboard
Credentials, custodian coordination, KYC/AML reference setup, (optional) backend deployment, connectivity test.
Console
How your treasury team creates orders, reviews competing quotes, and tracks settlements in the Musubi console.
Statements
Settlement confirmations, FX execution reports, month-end reconciliation — the download path for accounting and compliance.
Programmatic Access
Webhook + REST + SSE for institutions wiring Musubi into a TMS / ERP (Kyriba, SAP, Oracle) or custom treasury automation.