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

# Settlement Flow

> How a cross-border FX trade works on Musubi, from initiation to settlement.

A cross-border payment on Musubi follows the same pattern as an RFQ on a trading venue, followed by CLS-style PvP settlement. The entire process completes in approximately 15 seconds.

## The Trade in Six Steps

<Steps>
  <Step title="Initiate Payment Intent">
    Your treasury or payments team submits a payment intent: "Deliver 100,000 USDCx to Receiver Institution via their custodian."

    The intent optionally specifies a maximum source amount the sender will pay (cost guard — your cap on the FX cost).

    **TradFi parallel**: Initiating a cross-border wire with your correspondent bank, except you're specifying the exact terms upfront.
  </Step>

  <Step title="Market Makers Compete">
    Musubi broadcasts an **anonymized Request for Quote (RFQ)** to registered market makers. They see only the currency pair, amount, and deadline — not who you are or who you're paying.

    Multiple market makers submit competing quotes with their offered FX rate, the USDCx amount they'll deliver, and how long their quote is valid (typically 30 seconds).

    **TradFi parallel**: An electronic RFQ on a multi-dealer platform (like Tradeweb or Bloomberg RFQ), except the dealers never see your identity.
  </Step>

  <Step title="Best Execution Selection">
    You review the competing quotes and select the best one. Musubi validates that the selected quote meets your cost guard (if set).

    **TradFi parallel**: Best execution obligation — you're selecting from competitive bids, with a documented audit trail of all quotes received.
  </Step>

  <Step title="Custodian Authorization">
    Your custodian co-signs the trade. This is a dual-authorization gate: you selected the quote, but your custodian must confirm before any assets move. Neither party can act alone.

    **TradFi parallel**: Treasury initiates the payment, operations confirms it. Same dual-control principle, enforced cryptographically rather than by procedure.
  </Step>

  <Step title="Atomic Settlement">
    Musubi executes a Delivery-vs-Payment (DvP) swap in a single transaction:

    | Leg | Movement                                        |
    | --- | ----------------------------------------------- |
    | 1   | Your JPYSC0 moves from your custodian to Musubi |
    | 2   | Market maker's USDCx moves to Musubi            |
    | 3   | USDCx is delivered to the receiver's custodian  |
    | 4   | JPYSC0 is delivered to the market maker         |

    All four legs succeed atomically, or all four roll back. There is never a state where one side has delivered and the other hasn't.

    **TradFi parallel**: CLS Bank's Payment-vs-Payment (PvP) mechanism, where both currency legs settle simultaneously. The critical difference: CLS takes hours within its settlement window; this takes \~4 seconds.
  </Step>

  <Step title="Confirmation & Reconciliation">
    All parties receive a settlement confirmation with a single cryptographic transaction hash covering all four legs. This hash is your settlement proof for reconciliation.

    The receiver institution sees the settlement for the first time at this point — no pre-approval was needed, just like receiving a traditional wire.

    **TradFi parallel**: SWIFT MT103/MT202 confirmation, except the proof is cryptographic and covers the complete atomic transaction, not just your leg.
  </Step>
</Steps>

## Correspondent Banking vs. Musubi

<Tabs>
  <Tab title="Today: Correspondent Banking">
    ```mermaid actions=false theme={null}
    graph LR
      A[Your Bank] --> B[Your Correspondent — JP]
      B --> C[Intermediary Bank]
      C --> D[Receiver's Correspondent — KR]
      D --> E[Receiver's Bank]
    ```

    **Time:** 1-3 business days | **FX:** Bank's internal rate (opaque) | **Risk:** Herstatt risk | **Proof:** SWIFT messages at each hop
  </Tab>

  <Tab title="Musubi">
    ```mermaid actions=false theme={null}
    graph LR
      A[Your Institution] --> B[Your Custodian]
      B -->|atomic swap| C[Receiver's Custodian]
      C --> D[Receiver Institution]
    ```

    **Time:** \~15 seconds | **FX:** Competitive RFQ (transparent) | **Risk:** None — atomic DvP | **Proof:** Single transaction hash
  </Tab>
</Tabs>

## Timing

| Phase                 | Duration         | What Happens                                   |
| --------------------- | ---------------- | ---------------------------------------------- |
| Intent to first quote | \~8 seconds      | RFQ broadcast, market makers price and respond |
| Quote selection       | \~3 seconds      | You review, select, custodian authorizes       |
| Atomic settlement     | \~4 seconds      | Four-leg DvP executes                          |
| **Total**             | **\~15 seconds** | **Order to settlement confirmation**           |

## What Happens on Failure

If any leg of the atomic settlement fails, **the entire transaction rolls back**. No partial settlement is possible.

| Scenario                                 | Result                                                  |
| ---------------------------------------- | ------------------------------------------------------- |
| No market maker quotes before expiry     | Order expires. No assets move.                          |
| Quote expires before settlement starts   | Order expires. No assets move.                          |
| DvP transaction reverts during execution | All four legs roll back atomically. No assets move.     |
| Market maker lacks sufficient liquidity  | Settlement cannot proceed. Order fails. No assets move. |

Your assets remain with your custodian in every failure scenario. There is no "stuck in transit" state.