Client funds security starts with control of money movement

A firewall does not make a client-money system secure.

Security starts with knowing where each balance exists, who can change it and how a payment leaves the firm. A broker may hold money in segregated bank accounts while its platform tracks customer entitlements in an internal ledger. A prop firm usually trades its own capital, but may also handle client deposits or payouts under a different legal and operational model. Map those arrangements before choosing controls. The rules differ by jurisdiction and business model, so involve compliance and treasury early.

Draw the full path from deposit to withdrawal: payment provider, bank or custodian, internal ledger, trading platform, back office and general ledger. Mark where money is held, where balances are calculated, and which systems can initiate or approve transfers.

This map is also useful when reviewing vendors and integrations. Trading Technology covers the platform and provider layer where these dependencies often meet.

Start with the money map

Write down the data and actions that could create a loss. These include changing a beneficiary, releasing a withdrawal, editing a client balance, modifying settlement instructions, and issuing a privileged API credential. Include indirect routes: a compromised email account can be enough to request a beneficiary change, while a service account may have permission to submit payments without a human login.

Separate the ledgers in your design. The trading platform's view of a client's equity is not proof that the corresponding funds are present at a bank or custodian. Reconcile the internal record against external statements and payment-provider records.

Document how you handle pending card payments, chargebacks, unsettled trades, fees, currency conversion and funds in transit. Define which source is authoritative for each balance and who resolves differences.

Keep the map current. Update it when you add a payment rail, change a banking partner, introduce a new legal entity or allow a vendor to initiate transactions. An interface diagram that omits credentials and approval paths is incomplete.

Make every movement require separate authority

Build controls around the transaction, not just the user account. A person who can create a beneficiary should not be able to approve a payment to it. The person who releases a batch should not be able to alter its source data.

Use role-based permissions, separate production access from routine operations, and require a second authorised person for high-risk actions. Two people using the same shared login do not provide two-person control.

Set thresholds according to risk and workflow. A small routine withdrawal may use automated checks, while a new beneficiary or unusually large payout should trigger stronger verification and human review.

A short cooling period after beneficiary changes can reduce the chance that an attacker immediately drains an account. Avoid thresholds that staff can bypass through multiple smaller transfers: aggregate activity by client, beneficiary and time window.

• Require multi-factor authentication for payment administration, privileged access and remote access. Prefer phishing-resistant methods for administrators where supported.
• Use allowlisted bank details and verify changes through a separate, known channel. Do not rely on the contact details in the change request.
• Record who requested, changed, approved and released each payment, with timestamps and the values before and after each change.
• Apply transaction limits to staff and service accounts. Make temporary permission grants expire automatically.

Automation reduces manual handling but does not remove the need for controls. A service that submits a payment should have narrowly scoped credentials, a limit and a monitoring owner. Keep approval rules outside the application path where practical, so one compromised platform component cannot both alter a withdrawal and authorise it.

Protect credentials and signing keys

Prioritise accounts that can move money or change the rules governing movement. Administrators should use named accounts, separate from everyday email and browsing. Remove access promptly when roles change or staff leave. Review privileged access at a regular interval and after reorganisations; a dormant account with payment permissions is still an active route into the system.

Store secrets in a managed secrets service or hardware security module rather than source code, configuration files or shared documents. Limit which workloads can request each secret.

Rotate credentials after suspected exposure and when staff or vendors with access change. Rotation alone is not a fix if the same broad permissions remain in place. For signing keys, define who can authorise use, how backups are protected and how revocation works during an incident.

Keep production and test environments separate. Test systems should use synthetic balances and credentials that cannot reach live payment rails.

If vendors need support access, use time-limited accounts, approved sessions and recorded activity. Network restrictions can reduce exposure, but they do not replace identity controls: an attacker using a valid account may already be inside the permitted network.

Reconcile continuously and alert on exceptions

Reconciliation is a security control because it can expose unauthorised or erroneous movement before an unexplained difference becomes a loss. Match transactions using stable identifiers, not only amount and date.

Track the age and owner of each break. Alert on failed or delayed feeds as well as mismatched balances; a missing statement can otherwise make a dashboard look quiet.

The figures below are typical operating ranges, not regulatory standards or audited results. Actual intervals depend on payment rails, transaction volume, bank reporting and the firm's risk model.

Alert on behaviour, not just fixed amounts. A series of withdrawals below a limit, a beneficiary change followed by a payout, or an administrator signing in from an unusual location may matter more than one large transaction. Route alerts to an owner who can act, and measure time to acknowledge and contain them. Too many low-value alerts train staff to ignore the channel.

Practise containment and recovery

Prepare for compromised credentials, a malicious insider, a payment-provider outage and ransomware that affects the ledger or back office. Decide in advance who can pause withdrawals, revoke credentials, contact banks and preserve evidence. A documented emergency process should not depend on access to the systems an attacker may have locked.

Run exercises with operations, engineering, treasury, compliance and communications. Test both the technical steps and the approval chain. Verify that backups are isolated from production credentials, that restore procedures preserve transaction ordering, and that staff can reconcile activity created during an outage. Recovery that restores an old database without accounting for payments already released can create duplicate or missing balances.

• Pause affected payment routes and revoke exposed keys or sessions. Keep unaffected services available where safe.
• Contact banks and payment providers using pre-verified emergency details. Ask them to hold or trace suspect transactions.
• Preserve logs, access records and approval evidence before systems are rebuilt or cleaned.
• Reconcile all activity from the last confirmed position before resuming payouts. Require an authorised sign-off and record unresolved exceptions.

Review incidents and near misses for control failures, not only individual mistakes. Measure whether alerts arrived, whether the right person acted and whether the firm could establish its true position. The mistake most readers will still make after reading this is treating a well-designed control as proof that it is operating.

#client money controls #brokerage payment security #funds reconciliation #withdrawal approval workflow #trading platform access control #custody security #payment fraud prevention #financial services incident response