# Client-money segregation

> Design client-money controls across bank accounts, platform ledgers, funding, withdrawals, settlement, reconciliation, breaks, and insolvency scenarios.

Client-money protection requires more than separate wallet fields. The legal account structure, bank
mandate, double-entry ledger, payment approvals, daily reconciliation, and insolvency treatment must
work as one control system.

<Callout type="warn" title="Ledger balance is not a bank deposit">
  MyStocks sub-account wallets are USD ledger balances. Your customer terms must not describe them as
  individually titled bank accounts, deposits, or universally protected balances unless the relevant
  legal and banking arrangements expressly support that statement.
</Callout>

## Money path

<FlowDiagram
  nodes={[
    { label: 'Customer payment', sublabel: 'verified source account' },
    { label: 'Approved collection account', sublabel: 'client-money designation' },
    { label: 'Master control account', sublabel: 'partner funding reference', tone: 'accent' },
    { label: 'Sub-account ledger', sublabel: 'customer USD entitlement' },
    { label: 'Order escrow', sublabel: 'reserved, not withdrawable' },
    { label: 'Settlement / payout', sublabel: 'authorised destination', tone: 'success' },
  ]}
/>

## Segregation layers

| Layer | Required control |
| --- | --- |
| Legal | Written classification of client money, trust/segregation terms, permitted use, and insolvency treatment |
| Banking | Appropriately titled accounts, restricted signatories, no unauthorised set-off, and approved counterparties |
| Ledger | Separate customer liabilities, partner corporate funds, fees, escrow, unsettled cash, and adjustments |
| Payments | Verified source/destination, maker-checker approval, limits, sanctions screening, and reference uniqueness |
| Reconciliation | Bank-to-control-account and control-account-to-sub-ledger comparison at least daily |
| Assurance | Exception aging, management review, access recertification, and independent testing |

## Ledger invariants

The following must always be demonstrable:

```text
client bank cash + valid settlement receivables
  >= total customer cash liabilities

master wallet allocation
  = sum(sub-account available + reserved + unsettled) + partner residual

every external movement
  = authorised request + unique reference + immutable ledger entries
```

Do not use customer money for operating expenses, credit exposure, unrelated settlement, another
customer's shortfall, or treasury investment unless a specific lawful mandate and disclosure permit it.

## Funding controls

1. Accept funds only through approved rails and identify the originating customer or partner.
2. Reject, return, or review unidentified and unexpected third-party payments.
3. Credit the API ledger only after the legally defined receipt/clearing event.
4. Store amount, currency, applied FX, external reference, bank timestamp, and approver.
5. Ensure retries cannot double-credit; use a durable idempotency and payment-reference control.

For production partner float, `POST /topup` creates a pending treasury request. It must not be treated as
cash until approved and reconciled. See [Fund flow](/partners/docs/fund-flow).

## Withdrawal controls

- Calculate available cash after reservations, unsettled proceeds, fees, restrictions, and minimum balance rules.
- Pay only to an account whose ownership and change history have been verified.
- Apply cooling-off or step-up authentication after sensitive destination changes where appropriate.
- Separate request, approval, dispatch, and reconciliation duties.
- Fail closed on uncertain status; never convert a timeout into a second payout automatically.
- Return rejected or cancelled amounts through compensating ledger entries, not record deletion.

## Daily reconciliation and breaks

| Break type | Immediate response |
| --- | --- |
| Bank cash below ledger liability | Stop withdrawals and new funding credits; escalate as critical |
| Unmatched bank receipt | Hold in suspense; do not guess the customer |
| Duplicate credit or payout | Freeze affected amount and start recovery workflow |
| Settlement timing difference | Record dated receivable/payable and confirm against broker statement |
| FX or fee mismatch | Preserve original calculation, post an approved adjustment, and notify if material |
| Stale exception | Escalate by age and value; include in daily management attestation |

## Evidence required before production

- Legal opinion or counsel-approved analysis of client-money status in every operating jurisdiction.
- Bank account letters, titles, mandates, set-off treatment, and authorised signatory register.
- End-to-end ledger diagram and chart of accounts.
- Daily reconciliation procedure with named preparer, reviewer, cut-off, and escalation SLA.
- Maker-checker evidence for treasury and large payments.
- Tested shortfall, bank failure, cyber-fraud, and orderly wind-down playbooks.

## Reference standards

- [CPMI-IOSCO Principles for financial market infrastructures](https://www.bis.org/cpmi/publ/d101.htm)
- [CPMI-IOSCO principle catalogue](https://www.bis.org/pfmi/help/principleid.htm)