Client funds security: controls for trading platforms

Could an attacker move client money with one production credential? They should not be able to. Client funds security starts with separating authority: no single compromised account, service or operator should be able to initiate, approve and reconcile a material transfer.

The right design depends on where funds sit, who can move them and how quickly they must be available. A broker sending frequent payments faces different operating constraints from a firm holding assets with a third-party custodian. In both cases, controls need to cover the ledger, payment path and people who can change the rules.

Map the money and the authority

Separate the ledger from the payment rail

Draw the path from client instruction to bank, custodian or wallet, including every service that can create or amend a payment. Keep the client sub-ledger separate from the general ledger and from the service that submits external transfers. A database permission that allows a trading service to alter both a balance and a withdrawal record defeats that separation, even if the user interface has an approval screen.

Use immutable or append-only records for balance-affecting events, with corrections posted as new entries rather than edits. Record the instruction, account, amount, currency, beneficiary, approver and external payment reference.

Reconcile internal balances to bank or custodian records at a frequency matched to the movement rate. An intraday payment stream may justify checks every 5 to 15 minutes; a low-volume account may use scheduled reconciliation, with daily confirmation as a minimum operational control.

Choose a custody pattern deliberately

Keeping funds in an operating account gives fast access but puts more risk on online credentials and internal controls. A segregated account can reduce commingling risk, but does not by itself prevent a compromised payment administrator from sending money out. Third-party custody can move key management outside the broker's production environment, at the cost of dependency on the custodian's hours, service levels and release process.

For digital assets, a common pattern is a limited hot balance for routine withdrawals, with the larger reserve in offline or separately administered storage. For fiat, use bank account permissions, payment limits and independent approval rather than assuming the bank's login controls are enough. Teams comparing platform and provider models can use Trading Technology's infrastructure coverage as context, but must verify each provider's actual control boundary.

Compare controls by transfer speed and failure mode

Constrain signing and approval

Multi-factor authentication is a baseline, not a complete transfer control. Prefer phishing-resistant security keys for privileged users, short-lived access tokens for services and separate roles for payment creation, approval and policy administration.

Use a hardware security module or managed key service where signing keys must remain protected from application servers. Set quorum rules so that a single administrator cannot lower the threshold and approve a payment in the same session.

The following are typical market ranges, not audited company results or service guarantees. Actual timings depend on bank cut-offs, asset type, compliance checks and staffing.

Set limits by account, currency, beneficiary and time window. A sensible policy might combine a per-payment cap with a daily aggregate cap, then route exceptions to two people who do not administer the payment system. Keep emergency override access, but seal it with separate credentials, an alert to named responders and a post-use review.

Make changes harder than routine payments

Beneficiary changes, API key creation, withdrawal-limit increases and MFA resets are high-risk transactions. Require a second channel to verify a new beneficiary, using contact details already on file rather than details supplied in the change request. Apply a hold to the first payment, and alert an independent operations mailbox or on-call rota. Review changes to roles and limits as carefully as cash movements.

• Block direct database changes to balances and payment destinations.
• Alert on new administrator sessions, disabled alerts and failed approval attempts.
• Use separate credentials for production deployment and payment approval.
• Revoke access promptly when staff leave or change roles, and review dormant accounts regularly.

Detect problems and preserve a recovery path

Controls should produce evidence that operations can use during an incident. Log authentication, policy changes, payment instructions, approvals and external acknowledgements to a separate, access-restricted destination.

Keep timestamps synchronised and include stable transaction identifiers so investigators can link a client instruction to a bank or custodian reference. Avoid putting secrets, full payment credentials or unnecessary personal data in logs.

Alert on behaviour, not just system failure. Useful triggers include a beneficiary change followed by a withdrawal, an unusual payment size, repeated rejected approvals, an off-hours transfer, or a sudden change in reconciliation breaks. Route alerts to someone who can freeze the relevant channel. Define which operator can pause payments, how that pause is confirmed, and which checks are required before release resumes.

Test restoration of the ledger and payment configuration from backups, not just database availability. A recovery that restores balances but loses the latest payment instructions can create duplicate transfers.

Keep a runbook for freezing outbound payments, contacting the bank or custodian, reconciling in-flight transactions and communicating with affected teams. Exercise it at least quarterly for high-volume operations, including a scenario where the primary identity service is unavailable.

1. Run a small, controlled payment through the full approval and reconciliation path after material changes.
2. Verify that alerts reach the on-call person and that the payment can be stopped before external settlement.
3. Record recovery time, unresolved breaks and any manual access used during the exercise.

Operate the controls as production systems

Security degrades when limits, roles and exception queues become permanent workarounds. Assign owners to payment policies, reconcile access reviews with HR changes, and require a change ticket for adjustments to signing thresholds or account destinations. Track failed reconciliations by age and value, not only by count. An unexplained small break can signal a wider data or integration fault.

Use a short control inventory that names the asset, system owner, privileged roles, transfer limit, approval path, reconciliation source and recovery action. Review it after a new payment rail, platform migration, acquisition or material incident. Independent testing should include a compromised service credential and a social-engineering attempt against an approver, not only a vulnerability scan.

These controls do not replace jurisdiction-specific client-money rules, custody obligations or a bank's contractual requirements. This advice does not apply unchanged where regulation or a mandated custodian prescribes the account structure and approval process; those requirements take precedence, and a prop firm holding no client assets needs a different funds threat model.

#client money protection #brokerage security #funds segregation #withdrawal controls #key management #payment security #trading platform infrastructure #financial reconciliation