Keeping client money separate from a broker’s own operating cash is a cornerstone of investor protection. Traders usually see the effect — the balance on their account — but not the plumbing behind it. This article steps through how typical brokers and custodians use banking structures, ledger design, database rules, cryptography and operational controls to make client funds distinct from the firm’s working capital, with concrete examples you can follow even if you’re not an engineer.
Trading carries risk. This article is educational and not personal advice. Always confirm details with any broker you use.
Why segregation matters (brief reminder)
Segregation prevents the firm’s creditors from taking clients’ assets if the broker gets into trouble, makes it harder for the firm to spend client money for day‑to‑day operations, and creates auditable trails regulators or independent auditors can check. In practice that protection is delivered by a mix of legal arrangements (custodial and bank accounts) and technology controls inside the broker’s systems and the custodians that hold the actual cash or securities.
The end‑to‑end approach: banks, custodians and the broker’s ledger
A secure segregation model has three layers: the external custody/banking layer, the broker’s internal ledger and the operational controls that link them.
At the banking/custody layer, client deposits are usually held in accounts that are explicitly identified as customer or trust accounts at regulated banks or independent custodians. Some models keep each client’s funds in separate bank accounts; others use omnibus accounts (one pooled account held by the broker or custodian) but enforce segregation in the broker’s internal records and contracts with the bank or custodian. Both approaches can be compliant; the technical work then focuses on ensuring bookkeeping and controls never treat pooled money as fungible for the firm’s own use.
Inside the broker’s systems, the broker maintains a customer ledger — a database representation of every client’s balance and positions — that is logically separated from the firm’s operational accounts. The ledger is the authoritative source for client entitlements. All movement of value in or out of the bank/custodian must be reflected in this ledger with matching journal entries and reconciliation. If the database and bank records disagree, automated alerts and human exception processes kick in.
Database and ledger design: how separation is enforced technically
Most modern brokers use a set of engineering patterns and accounting practices to keep client funds segregated in their systems. Here are the core concepts, described in plain language.
Separation of schemas and tables. Client balances and firm cash are stored in different database structures or schemas. For example, customer_balances and customer_transactions tables are distinct from firm_treasury and firm_payments tables. This keeps the data models simple to audit and reduces risk of accidental joins that mix categories.
Double‑entry accounting at the database level. Every financial event is represented by at least two ledger entries so that assets and liabilities remain balanced. If a client deposit arrives at the bank, the system creates a credit to the client balance and a corresponding debit to the broker’s bank account control record for client funds. Double entry makes it possible to detect mismatches quickly.
Immutable transaction journal. All operations that change money create an append‑only transaction log. Each log entry includes a timestamp, user or system actor, reference IDs (bank transaction id, clearing reference), and before/after balances. That journal is the single source of truth for reconciliations and audits.
Transaction atomicity and consistency. Systems use database transactions or equivalent mechanisms so a single business operation (deposit, trade settlement, withdrawal) either completes fully or not at all. This prevents partial updates that would leave client balances inconsistent with bank records.
Role separation and safeguards in code. Application logic prevents payment flows that would move money from client ledgers to firm operational ledgers without explicit, auditable authorization and process. Critical paths, such as clearing a withdrawal or sweeping cash to an operational account, require multiple system checks and human approvals where appropriate.
Idempotency and id linking. External messages (bank notifications, exchange settlement receipts) are processed once using idempotency keys so the same message can’t be applied multiple times and accidentally credit a client twice.
Example (deposit flow): a client wires money to the broker’s customer bank account. The bank posts the incoming wire and emits a confirmation with a bank reference. The broker’s ingestion service picks up that confirmation, creates a customer_transaction record (credit) and a bank_control record update (debit), writes the transaction to the immutable journal, and flags the reconciliation engine. If anything fails, the system rolls back and the operation is retried using the same idempotency key.
Access controls, cryptographic protections and key management
Data and operational access must be tightly controlled so that separation isn’t broken by people or credentials.
Role‑based access control (RBAC) and least privilege. Engineers, traders, reconciliation staff and finance teams get only the access they need. No one person should be able to both initiate a client withdrawal and toggle the firm’s account that pays for operating costs.
Encryption and HSMs. Sensitive financial records are encrypted at rest and in transit. For crypto custodians, private keys are usually stored in hardware security modules (HSMs) or multi‑party computation (MPC) setups so a single human cannot sign an outgoing transfer. The same approach applies to credentials and API keys that can move money.
Privileged access monitoring and just‑in‑time elevation. When an operator needs elevated rights to perform an unusual action, the system requires an explicit approval workflow that is logged and timebound.
Reconciliation, monitoring and auditability
Segregation only works if you prove it every day. Robust brokers run continuous and independent reconciliations.
Three‑way reconciliation. The typical reconciliation compares (1) the bank/custodian statement for the broker’s client accounts, (2) the broker’s bank control records, and (3) the sum of all client ledger balances in the database. These three must match (allowing for timing differences). Any discrepancy triggers automated investigation workflows.
Daily and intraday checks. Many brokers run end‑of‑day reports and intraday checks for high‑value flows. They record residual interest (the firm’s permitted buffer in client accounts) and alert when that buffer falls below thresholds.
Audit trail and immutable logs. The append‑only transaction journal, combined with bank statements and custodian confirmations, creates a complete audit trail. Independent auditors or regulators can perform surprise audits, and the system stores the evidence needed to trace a dollar from bank account to client ledger entry to withdrawal.
Example (reconciliation failure): if the bank shows $1,000,000 in the client trust account but the broker’s ledger reports only $990,000, the reconciliation engine isolates the unmatched bank credits and checks the ingestion logs. If a wire confirmation was missed, ingestion retries; if there was an accounting posting error, the system creates a flagged corrective journal entry and records the reason and approver.
Operational controls and separation in business processes
A secure technical design must be backed by operational rules that prevent misuse.
Segregation of duties in operations. Finance teams that reconcile client balances should be different from those that approve vendor payments. Treasury operations that manage the firm’s operating account should be separate from client‑facing account servicing teams.
Bank mandates and custodial agreements. Banks and custodians sign contracts that explicitly prohibit the use of client money for the firm’s obligations and that define the scope of the account (omnibus vs individually segregated). The IT architecture enforces the corresponding flows.
Legal residual interest and controls. Some business models allow the firm to hold a limited residual interest (a buffer of its own funds in the client account) for operational reasons. That is tracked explicitly in the ledger and governed by policies; changes require senior approvals and are visible in reconciliation reports.
Scheduled and surprise audits. Independent auditors verify system controls, reconciliation procedures and the integrity of custody. Regulatory examiners may request electronic evidence drawn from the immutable journals and reconciliation outputs.
Omnibus accounts vs individually segregated accounts — the technical tradeoffs
Brokers choose one of two common custody models and the choice affects how segregation is implemented technically.
Under individually segregated accounts, each client’s money is held in a distinct bank/custody account. The database mappings are one‑to‑one and the reconciliation is simple at the bank level, but this model adds operational overhead and bank fees for many small accounts.
Under the omnibus model, many clients’ cash or assets sit in a pooled account held by the custodian; the broker keeps client‑level accounting internally. Omnibus is operationally efficient and reduces on‑chain fees in the crypto world, but it puts more emphasis on the broker’s internal ledger, reconciliation and contractual protections with the custodian. Technically, omnibus setups require rigorous internal controls, frequent reconciliations and strong contractual guarantees from the custodian.
Concrete example (crypto): a custodian using an omnibus model may hold many customers’ tokens in the same set of cold wallets and represent ownership via internal database balances. To reduce single‑wallet risk, the custodian will spread holdings across multiple wallets, use batched withdrawals and cryptographically sign outgoing transactions only under multi‑party approval. Customers are told in the custody agreement that assets are pooled but that contractual and technological safeguards prevent re‑use.
Special notes on blockchain custody and proof‑of‑reserves
For crypto assets, custody adds new technical layers: private keys, on‑chain transactions and the possibility of publishing cryptographic proofs.
Hardware and signing policies. Cold storage, threshold signatures, and multi‑sig arrangements are used to make it practically impossible for a single compromised system to drain funds.
Proof‑of‑reserves and cryptographic audits. Some custodians publish periodic cryptographic proofs that reserves exceed liabilities, or allow auditors to perform attestations without revealing sensitive details. Methods range from Merkle‑tree proofs to zk‑based approaches. These can be a
References
- https://databento.com/compliance/segregated-accounts
- https://www.sandhillglobaladvisors.com/blog/the-importance-of-segregated-assets-at-brokerage-firms/
- https://www.investopedia.com/terms/s/segregation.asp
- https://www.adan.eu/wp-content/uploads/2024/10/2024-09-Segregation-of-funds-.pdf
- https://www.fia.org/sites/default/files/2025-10/FIA%20Customer%20Funds%20FAQ%20October%202025_0.pdf
- https://www.dre.ca.gov/files/pdf/re13.pdf
- https://www.buildium.com/blog/what-you-didnt-know-about-trust-accounting/
- https://www.morganlewis.com/-/media/files/publication/outside-publication/article/2021/2021_fund_management_unitedstates.pdf
- https://www.finra.org/investors/insights/if-brokerage-firm-closes-its-doors
- https://www.fidelitydigitalassets.com/research-and-insights/omnibus-model-custody