Privacy Model

Musubi enforces privacy at the settlement network protocol level — not through field masking or access control, but by physically limiting which data reaches each participant’s infrastructure. Each participant sees only the contracts and transactions they are authorized to see.

Data Visibility by Role

Data	Sender Institution	Sender Custodian	Market Maker	Receiver Custodian	Receiver Institution
Order details (amount, currency, expiry)	Full	Full	Amount + currency only	After settlement	After settlement
Sender identity	Self	Visible	Never	After settlement	After settlement
Receiver identity	Visible	Visible	Never	Self	Self
Competing MM quotes	Visible	Visible	Own quotes only	Not visible	Not visible
FX rate negotiation	Visible	Visible	Own quotes only	Not visible	Not visible
Settlement confirmation	Visible	Visible	Visible	Visible	Visible
Transaction hash	Visible	Visible	Visible	Visible	Visible
Other participants’ orders	Never	Never	Never	Never	Never

Anonymized Quote Requests

When an institution creates an FX order, Musubi broadcasts a quote request to market makers. This request is deliberately stripped of identifying information:

Included	NOT Included
Source currency (e.g., JPYSC0)	Sender institution identity
Source amount (e.g., 10,000,000)	Receiver institution identity
Target currency (e.g., USDCx)	Custodian identities
Expiry deadline	Contract identifiers
	Intent signatures

Market makers price based on flow characteristics (currency pair, size, market conditions) — not client identity. This anonymity is maintained throughout the entire lifecycle:

Before quoting: anonymous request
During quoting: MM doesn’t know who’s asking
After winning: MM sees swap amounts and settlement proof, but still not sender/receiver identity
After settlement: MM’s record contains trade economics only

This is protocol-level privacy, not application-level masking. The market maker’s settlement node physically does not receive sender/receiver identity data — it is not transmitted, not stored, and cannot be extracted.

No Shared Ledger

Unlike public blockchains, there is no global state that all participants can read:

Each participant’s node stores only contracts they are party to
There is no way to enumerate other participants or their activity
There is no shared transaction history
Each participant’s database contains only their own data

An institution cannot see another institution’s orders. A market maker cannot see another market maker’s quotes or win rate. A custodian cannot see orders they don’t custody.

No Backend-to-Backend Communication

All cross-party coordination flows through the settlement network protocol: No participant’s backend makes direct API calls to another participant’s backend. There is no service mesh, no message queue, no shared database between participants. The settlement network is the only communication channel, and it enforces visibility rules at the protocol level.

Post-Settlement Visibility

After settlement completes, each party sees a scoped view of the result:

Party	What They See in the Settlement Record
Sender Institution	Full order lifecycle, all timestamps, settlement proof
Sender Custodian	Full order lifecycle, all timestamps, settlement proof
Market Maker	Swap amounts, rate, settlement proof. No sender/receiver identity.
Receiver Custodian	Settlement details, amounts, sender/receiver identities, proof
Receiver Institution	Settlement details, amounts, proof (first notification in the entire flow)

Overview

Security & Privacy

Technical

Data Visibility by Role

Anonymized Quote Requests

No Shared Ledger

No Backend-to-Backend Communication

Post-Settlement Visibility

​Data Visibility by Role

​Anonymized Quote Requests

​No Shared Ledger

​No Backend-to-Backend Communication

​Post-Settlement Visibility

Data Visibility by Role

Anonymized Quote Requests

No Shared Ledger

No Backend-to-Backend Communication

Post-Settlement Visibility