Forex and CFD brokerages adding crypto settlement inherit a problem their fiat operations never posed: the client money account is a private key, and whoever controls that key controls the balance. Under FCA CASS 7, MAS Payment Services Act segregation rules, and the client asset provisions of MiCA (Markets in Crypto-Assets Regulation), segregation is a legal test about control, not a bookkeeping entry. A broker that holds a single signing key over a pooled USDT wallet has, in practice, taken custody — with all the licensing, capital and audit consequences that follow.
Why USDT settlement changes the client money question
Most brokers arrive at crypto settlement for a narrow reason: clients in Latin America, Southeast Asia and the Gulf want to fund and withdraw in USDT rather than wait three days for a correspondent bank. The commercial case is straightforward. Same-day settlement on Tron or Ethereum, no intermediary bank cutting the relationship, and a materially lower cost per withdrawal.
The operational case is less straightforward. A fiat client money account sits at a credit institution that is itself regulated, audited and subject to a trust or acknowledgement letter. The bank is the segregation mechanism. On-chain there is no bank. The address is the account, and the signing arrangement is the segregation mechanism. If the broker's treasury team can move client USDT with one approval, the segregation exists only as policy — not as an enforceable control.
Auditors have begun to test this directly. The question in a CASS audit or an ISAE 3402 engagement is no longer "can you produce a reconciliation". It is "demonstrate that no single individual, and no single system, can unilaterally transfer client assets". A screenshot of a wallet balance does not answer that.
Who signs a withdrawal, and in what order
The design question for a brokerage COO is sequencing. A withdrawal request originates in the client portal, but the signing authority must sit outside the system that generated the request. Otherwise a compromise of the trading platform is a compromise of the treasury.
A defensible sequence for a broker settling client withdrawals in USDT looks approximately like this. First, the request is raised in the CRM or client portal and matched against the client's ledger balance and available margin. Second, a compliance check runs — sanctions screening against the destination address, Travel Rule data collection where the counterparty is a regulated VASP (virtual asset service provider), and a check that the withdrawal address matches a previously whitelisted destination with an enforced time delay on new additions. Third, the transaction enters a policy engine that evaluates it against pre-set rules: amount thresholds, destination chain, daily aggregate limits, time-of-day windows. Fourth, and only then, does signing occur.
The signing step is where MPC (multi-party computation) and TSS (threshold signature schemes) change the audit picture. Under a threshold scheme, the private key is never assembled. Key shares are generated independently and held by separate parties, and a signature is produced collaboratively without any party ever seeing the full key. A 3-of-3 arrangement — for example, two shares held by the custody technology provider and one retained by the broker — means the broker cannot move client funds alone and neither can the provider. Neither party is a custodian in the sense the regulation contemplates, because neither has unilateral control.
This is the substantive difference from multisig, which brokers often encounter first. Multisig achieves a similar governance outcome but does so on-chain, with the quorum logic written into the contract or script. That makes it chain-specific, visible to observers, more expensive in gas, and unavailable in equivalent form across every network a broker might need. A treasury settling in USDT on Tron, Ethereum and Solana simultaneously will find that multisig means three different implementations with three different failure modes. Threshold signatures produce a standard single-signature transaction on any supported chain, which keeps the operational model uniform across 10 or more networks.
What changes for the auditor
Split keys change the evidence an auditor collects. Under a single-key model, the control is procedural — a policy document stating who may initiate transfers, plus logs. The auditor tests whether the policy was followed. Under a threshold model, the control is cryptographic. The auditor tests whether the threshold is enforceable at all, which is a stronger assertion and a shorter test.
Three artefacts matter. The first is the key generation ceremony record: evidence that shares were created independently and that no party observed the others. The second is the policy engine configuration and its change history — who approved a limit increase, when, and under what dual-control. The third is the signing log, which should show which shares participated in each signature and which human or service approvals preceded it.
A SOC 2 Type II report from the custody technology provider covers the provider's side of that boundary. It does not cover the broker's own approval workflow, and auditors are increasingly explicit about the split. Brokers should expect to produce their own control narrative for everything upstream of the signature.
What to watch next
Three developments bear on broker crypto settlement over the next twelve months. MiCA's transitional grandfathering periods continue to expire across EU member states, and firms that assumed a national exemption applied should confirm their status; the treatment of non-custodial architectures as CASP-exempt turns on demonstrable absence of control, not on labelling. Separately, the ongoing questions around USDT availability on EU venues under MiCA's e-money token rules make chain and stablecoin diversification a planning item rather than an optimisation — brokers settling exclusively in USDT to EU clients should model USDC and EURC alternatives now.
Third, FCA and MAS consultations on client asset rules for digital assets are converging on control-based tests. Firms that have already implemented threshold signing with documented approval sequencing will find those consultations confirmatory. Firms relying on a single key and a policy document will find them expensive.
Brokerage treasury teams designing client withdrawal flows under CASS, MiCA or MAS segregation rules can review Vaultody's MPC architecture and compliance documentation to see how threshold signing maps to auditable control boundaries.
Copy link