Client funds security fails at the seams between systems

Client funds security is the set of controls that prevents unauthorised movement, exposure or loss of money held for clients.

That definition is too narrow for trading infrastructure. Funds can be correctly segregated at a bank and still be exposed through an over-privileged operator account, a replayed payment instruction or a ledger that cannot explain a balance break. Security depends on the full chain from client record to bank movement, including the people and recovery processes around it.

Start with the ledger, not the payment screen

A payment provider's dashboard is not the system of record. The broker's ledger must represent each client obligation and each movement, with an auditable link to the source instruction and settlement event. For a client-money business, legal segregation at the bank and accurate internal allocation are separate controls. A spreadsheet export or a pooled balance in a payments console does not replace either one.

Use double-entry postings and make the balance equation testable: opening obligation plus receipts, less withdrawals and permitted charges, equals closing obligation. Reconcile that obligation against bank and processor statements at least daily, with intraday checks for higher-volume payment flows. Set an owner and an escalation threshold for every break. A tolerance that silently absorbs unexplained differences turns a detection control into a way to hide errors.

Keep trading, treasury and client-money permissions distinct. A trading service should not be able to change beneficiary details, and a payout service should not be able to edit the ledger to make a withdrawal appear valid. The boundary between these systems is a recurring theme in Trading Technology's broker infrastructure coverage.

Payment rails are an attack surface

Teams often secure the client portal but trust messages arriving from a bank, processor or internal queue. Webhooks can be duplicated, delayed or delivered out of order.

Treat every callback as an untrusted event: verify its signature, check its timestamp and reference, enforce idempotency, and reconcile its status against the provider's API or statement. A valid signature proves who sent a message, not that the payment should be released.

Withdrawal controls need to cover the full lifecycle. Require step-up authentication for sensitive changes, bind approval to the amount and destination, and apply a cooling period after a beneficiary is added or edited. A changed destination followed by a large payout should trigger a separate review, not pass because the same logged-in session initiated both actions.

• Use unique payment references and reject duplicate instruction IDs.
• Apply limits by client, destination, currency and time window, with a documented exception path.
• Keep processor credentials out of application logs and rotate them after staff or supplier access changes.

Do not confuse friction with security. A blanket delay on every withdrawal can push legitimate clients towards support channels and manual overrides. Target checks at higher-risk changes and amounts, then measure false positives and queue age so controls do not create an unmonitored bypass.

Privileged access is where tidy diagrams fail

Production access tends to grow through incidents, vendor support and temporary fixes. Shared administrator accounts erase attribution.

Long-lived API keys turn a leaked build variable into persistent access. A role labelled "operations" that can edit a client record, approve a withdrawal and change a limit combines duties that should be separated.

Use named accounts, phishing-resistant multifactor authentication for administrators, and just-in-time elevation with a ticket or incident reference. Restrict vendor access to named people, approved time windows and specific services.

Record privileged sessions or commands where the platform supports it, and send logs to storage that the production administrator cannot alter. Review service identities as carefully as human accounts; give each one a narrow scope, owner and expiry or rotation schedule.

Access reviews should test effective permissions, not merely ask managers to confirm a list. Compare identity-provider groups with cloud roles, database grants, deployment permissions and payment-provider access.

Remove dormant accounts and stale tokens as part of the review. A quarterly review can be a reasonable starting point, but teams with frequent role changes should automate checks between reviews.

Detection and recovery need money-aware controls

Security alerts should describe financial consequences, not just infrastructure events. Alert on unusual beneficiary changes, withdrawals outside a client's normal pattern, repeated failed approvals, ledger adjustments and breaks between bank cash and client obligations.

Route high-severity alerts to an on-call role with authority to pause payouts. A notification that nobody can act on is not a control.

The figures below are typical operating ranges used for planning, not regulatory safe harbours. Local rules, payment cut-offs and the firm's risk profile may require tighter controls.

For ledger writes, a low recovery point objective is only credible if acknowledged postings are durably committed or replicated. Backups alone do not prove recoverability. Restore them into an isolated environment, verify ledger totals and transaction order, and rehearse the credentials needed to bring the payment path back without re-opening compromised access.

Test the failure path, not just the control

Run exercises that follow a realistic compromise from detection to containment: a stolen operator session, a payment-provider key exposed in a deployment, or a corrupted reconciliation feed. Practise disabling payout credentials, pausing withdrawals, preserving evidence and notifying the right internal owners. Define in advance who can authorise a restart and what evidence must be checked before payments resume.

For brokers, client-money obligations and regulatory reporting shape the response. For prop firms using their own capital, the legal treatment may differ, but treasury access and payout integrity still matter.

Do not label a trading firm's funds as client money without checking the actual arrangement. Engineers, compliance and finance should agree which ledger is authoritative, which movements require dual approval and how an incident affects client access.

Track whether the controls work under normal operating pressure: time to detect a suspicious payout, time to revoke credentials, age of unresolved reconciliation breaks, and the share of restores that pass validation. Keep the metrics tied to named owners. A policy that nobody can demonstrate during an incident is documentation, not operational security.

• Stop using shared administrator or payment-provider accounts.
• Stop approving withdrawals from the same session that changed the destination.
• Stop treating a successful backup job as proof of a tested restore.

#broker disaster recovery #trading platform security #privileged access management #client funds security #broker custody controls #segregated client money #payment operations #ledger reconciliation