Picture the trade every broker eventually sees. A client holds $10,000 in their account and opens a large position. It moves against them: floating loss, $4,000. While the position is still open, a withdrawal request arrives for $9,500. If your system checks the request against balance — which hasn't yet realized the loss — the request looks fine. Pay it, and watch what happens next: the position closes at a loss the account can no longer cover, the client walks away whole, and the negative balance belongs to you. The client has, in effect, cashed out from under the market — and handed you the bill.
This is not exotic fraud; it is an obvious play against any broker whose withdrawal logic is naive. The defence is a single, precise rule enforced by software at request time.
The Rule: Withdrawable = Free Equity, Not Balance
The correct measure of "money that is really free" starts from equity — balance plus or minus the floating P&L of open positions — not balance alone. Equity is the truth of the account right now: it already contains the loss (or gain) the market is currently holding over every open trade. Then subtract what is already spoken for: pending withdrawal requests that have been submitted but not yet paid. What remains is free equity, and in the Singuard Broker CRM it is the ceiling on every withdrawal request:
- Withdrawable = equity − pending requests. In the scenario above, the client's equity is $6,000, so a $9,500 request is refused at the point of entry — not discovered in review, not paid and regretted.
- Pending requests count immediately. Without this, a client could file three $5,000 requests against $6,000 of equity and hope two get processed by different agents. Each request reduces the ceiling for the next, so the race simply doesn't exist.
- The client sees the honest number. The portal shows withdrawable funds computed this way, so clients aren't invited to request money that isn't free — which converts a fraud vector into a UX non-event.
The precondition, of course, is that equity is current. Because balances and equity stream from the trading platform into the CRM live — with a polling backstop for gap recovery — the free-equity check runs against the market as it is now, not as it was at last night's export. A stack that reconciles nightly cannot enforce this rule; by the time it knows the equity, the payout is gone.
Identity First: No Verified ID, No Payout
Before any withdrawal reaches human review, one gate is absolute: the client's identity is verified. No approved KYC, no payout — ever, regardless of amount, seniority or how insistent the ticket is. This closes the standard laundering-and-theft pattern (deposit by one identity or stolen instrument, withdraw as another) and it is enforced by the system rather than the reviewer's memory: unverified clients cannot submit a payable request in the first place. Documents themselves are handled with matching discipline — uploaded privately, never on a public link, reviewed per-document with reasons recorded, exactly as described in the KYC & AML workflow article.
Reviewed by Your Team, Paid Exactly Once
What survives both gates — free equity sufficient, identity verified — lands in the payments queue of the ops desk, scoped so only the payments role sees it. Staff approve with the eligibility already computed and visible, then mark paid. And the final guarantee is idempotency: a payout marked paid is terminally paid — a duplicated processor callback or a second click cannot send the money twice, the same exactly-once discipline that governs deposits (see why deposits can never double). Every state change — requested, approved, paid, by whom, when — is written to the permanent audit log.
The three gates, in order: free equity caps the request at entry, verified identity gates the queue, and human approval releases the payment — once. Software enforces the first two so your team only ever reviews requests that are already legitimate.
Why This Protects Clients Too
It is worth saying plainly: the free-equity rule is not adversarial toward clients. A broker that leaks money through withdrawal exploits recovers it the ugly way — wider spreads, slower payouts for everyone, aggressive clawbacks, or insolvency. Honest clients are the beneficiaries of a firm that cannot be drained: their withdrawals are fast because the illegitimate ones never enter the queue, and the visible, honest "withdrawable" number in the portal means no client is surprised by a rejection they couldn't predict. Fast payouts for honest clients are one of the strongest retention signals a broker has — and they are only affordable when the book is protected by rule, not by review-time heroics.
The Checklist for Your Own Stack
If you run — or are choosing — a broker stack, test it against four questions. Does withdrawable compute from live equity, not balance? Are pending requests subtracted immediately? Can an unverified client submit a payable request? Can any sequence of retries or clicks pay a request twice? In the Singuard Broker CRM the answers are yes, yes, no and no, out of the box, wired into the same 24-hour bundle as the rest of the money rails — you can try the full request-review-pay loop in the live demo.
"A withdrawal checked against free equity protects the trader and the book at once. It's the quiet rule that keeps brokers solvent."
— Roman Onta, Executive Director, Broker CRM & UI/UX
Key Takeaways
- Withdrawals must check free equity — equity minus pending requests — never raw balance, or open losses can be cashed out.
- The check is only as good as the data: live equity streaming from the platform makes it enforceable at request time.
- Identity is an absolute gate: no verified KYC, no payout — enforced by the system, not reviewer memory.
- Approved payouts are paid exactly once, audit-logged — and honest clients get faster payouts because the book is safe.
Frequently Asked Questions
Why Not Just Make Clients Close All Positions Before Withdrawing?
Forcing flat books punishes active traders and drives them to competitors. The free-equity rule achieves the same protection without the friction: clients withdraw what is genuinely free while their positions stay open, and the market's claim on the rest is respected automatically.
What Does the Client See When a Request Exceeds Free Equity?
They see it before it happens: the portal displays withdrawable funds as equity minus pending requests, so an excessive request is prevented at entry with a clear number, rather than rejected later with an explanation nobody enjoys writing.
Does This Work with Platforms Other Than eTrader?
Yes. The CRM streams balances natively from eTrader and bridges in one click to MT4, MT5, cTrader, DXtrade, NinjaTrader, Match-Trader and TradeLocker, applying the same free-equity and ID-first gates across them — see what a forex CRM does for the architecture.