> ## Documentation Index
> Fetch the complete documentation index at: https://musubinetwork.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Integration Overview

> Three things Musubi adds to your treasury workflow — Onboard, Console, Statements.

Musubi fits alongside your existing treasury operation. Your payment flow, counterparty directory, FX risk policy, and accounting system all stay where they are. Musubi adds three things: an **Onboard** path to get connected, a **Console** where your treasury team initiates orders and tracks settlements, and **Statements** your accounting team downloads on its usual cadence.

## 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          |
| **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

```mermaid actions=false theme={null}
graph LR
  subgraph Your Institution
    TP[Treasury / payments]
    TP -->|initiate orders| MB[Musubi backend<br/>REST + SSE]
    MB -->|statements| ACCT[Accounting / GL]
  end

  subgraph Your Custodian
    CC[Custodian<br/>co-signs every trade]
  end

  MB <-->|Canton protocol| SN[Settlement network]
  CC <-->|Canton protocol| SN
```

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

<CardGroup cols={2}>
  <Card title="Onboard" icon="check" href="/institution/integration/onboard">
    Credentials, custodian coordination, (optional) backend deployment, connectivity test.
  </Card>

  <Card title="Console" icon="desktop" href="/institution/integration/console">
    How your treasury team creates orders, reviews competing quotes, and tracks settlements in the Musubi console.
  </Card>

  <Card title="Statements" icon="download" href="/institution/integration/statements">
    Settlement confirmations, FX execution reports, month-end reconciliation — the download path for accounting.
  </Card>

  <Card title="Programmatic Access" icon="code" href="/institution/integration/programmatic-access">
    Webhook + REST + SSE for institutions wiring Musubi into a TMS / ERP (Kyriba, SAP, Oracle) or custom treasury automation.
  </Card>
</CardGroup>

For most institutions, Onboard + Console + Statements covers the integration. Programmatic Access is the path for institutions with downstream systems that initiate orders or reconcile accounts automatically.