Deposit and withdrawal approvals: a workflow that leaves a trail

A withdrawal request comes in on Friday evening. On Monday morning someone in finance approves it from a spreadsheet and sends the transfer. A week later the head of operations asks three questions. Did the client have open positions that needed that margin? Was the bank account in the client's name? Who checked? Nobody has a written answer.

The short answer: a sound approval workflow rests on five decisions you write down in advance. Which transactions need a human decision. Who may approve, and who must not. What the reviewer checks. What each status and rejection reason means. What gets recorded and reconciled against the money itself.

QUANTIX publishes this guide, and we sell a brokerage CRM and back office that handles deposits and withdrawals, so we have a commercial interest in the subject. The workflow below works in any system; QUANTIX appears only in the last section. This is not legal advice: the rules on handling client money come from your regulator and your compliance officer.

Deposits and withdrawals carry different risks

Many teams treat deposits and withdrawals as two sides of one process. They are not. Each carries a different risk, so each needs a different control.

	Deposit	Withdrawal
Direction	Into the brokerage	Out to the client
Main risk	Crediting a balance before the money has arrived, or from an account that is not the client's	Paying money you cannot recover to the wrong person or account
Core control	No credit without independent confirmation of receipt	A recorded human decision before money leaves

A deposit error can usually be corrected with a reversing entry. A withdrawal, once it has left your bank account or wallet, may never come back. That is why withdrawals deserve most of the control effort.

Decide which transactions need a human decision

Not every deposit needs a staff approval. What decides it is where the confirmation comes from.

• Processor deposits. Confirmation comes from the payment processor through a webhook. A manual approval adds delay without adding information. Have the team review the exceptions instead: failed transactions and anything pending for too long.
• Manual deposits (bank transfer, crypto address). Nobody confirms receipt except your own staff, once they see the funds in the bank statement or the wallet. A screenshot from the client is not confirmation.
• Withdrawals. Many brokerages choose to put every withdrawal request in front of a person, whatever the amount.

Then write down what moves a request to a higher level of review. Common triggers: the client's first withdrawal, payout details changed recently, a KYC file that is incomplete or expired, an amount above a limit your policy sets, and a withdrawal that follows a recent deposit with little trading in between. These thresholds are policy, set by your compliance officer. They are not judgement calls made at the screen.

Who approves, and who must not

Two rules. Whoever creates a transaction does not approve it. Whoever benefits from the decision does not make it.

• Sales is often measured on deposits, so sales staff should not hold rights to approve manual deposits or withdrawals. They see the status and keep the client informed.
• Finance reviews and approves, then executes the payment.
• Compliance receives the cases your policy escalates and decides them.
• Dealing is consulted on open positions and margin before a large withdrawal, when needed.

The most sensitive right in this workflow is the manual deposit a staff member records from the customer record. It creates a tradable balance without any processor involved. Limit it to very few people, and require a written reference for every entry, such as the bank transfer reference.

In a small team, one person may have to enter and approve. Compensate with review after the fact: the owner or a manager goes through the list of manual entries and approved withdrawals every day or every week.

What the reviewer checks before approving a withdrawal

A short, fixed checklist beats one experienced employee's memory. Before any withdrawal is approved:

1. Identity. Is the KYC file approved and in date? Designing that stage is covered in our guide to the KYC review workflow.
2. Payout destination. Is the bank account or wallet in the client's own name? Many brokerages apply a "closed loop" rule: deposited amounts go back to the method they came from first. If you adopt it, put it in the policy and tell clients before they deposit.
3. Recent changes. Have the payout details, email or phone number changed recently? If so, confirm with the client through a channel you already had on file, not through the message that asked for the payout.
4. Margin. Does the client have open positions? A withdrawal should not take margin those positions need.
5. Uncleared deposits. Does the balance include money whose receipt has not been confirmed?
6. Activity pattern. A deposit followed quickly by a withdrawal with little trading, or several accounts paying out to the same destination. Neither proves anything. Both are reasons to escalate to compliance.

Statuses and reasons a client can understand

Status names vary between systems. What matters is that each status has one meaning and everyone knows who acts next.

Status	What it means	Who acts next
Pending	Request received, not yet reviewed	Finance
Escalated	Needs a compliance decision (internal only)	Compliance
More information needed	A document or detail is missing	Client
Completed	Payment sent, or deposit confirmed	Nobody
Failed	Rejected by the processor or bank	Finance
Cancelled	Withdrawn by the client, or declined for a recorded reason	Nobody

Write a standard list of rejection reasons, each with ready-made client wording in every language you serve. For example: the bank account is not in the client's name, the KYC file has expired, free margin is insufficient because of open positions, or the payout details are incomplete.

One point needs care. If your team suspects the funds are linked to criminal activity, Recommendation 20 of the Financial Action Task Force (FATF) calls for a prompt report to the financial intelligence unit, and Recommendation 21 prohibits telling the client that a report has been made ("tipping off"). So a finance agent should not explain a hold to the client in their own words. They escalate to the compliance officer and use neutral wording that compliance has approved in advance.

The record every decision must leave

Every approval or rejection must be able to answer later: who requested it, who approved it, when, the amount, the method, the destination, the status before and after, and why. A free-text note on the customer record is not enough. You need an audit trail that stores before-and-after values and can be filtered and exported.

FATF Recommendation 11 asks firms to keep transaction records for at least five years, so they can answer requests from the authorities quickly. Your national rules may require longer, so build your retention policy on the longest period that applies to you.

Reconcile every day: the ledger against the money

Approval is not the last step. Every working day, finance compares the transaction ledger with bank statements, processor reports and wallets. Three breaks need attention the same day:

• Completed in the ledger, nowhere in the bank. Possibly a manual deposit entered by mistake.
• Money in the bank with no ledger entry. Find out who sent it before you credit any account.
• Pending longer than the method's stated processing time.

Then ask four questions every week. How many withdrawals are waiting, and how old is the oldest? How many manual deposits were recorded, by whom, and does each have a reference? Which rejection reasons come up most often? Is any reconciliation break still open?

What this guide does not cover

This guide does not cover choosing payment gateways, rules on segregating client money from company money, card chargeback disputes, tax, or the requirements of a particular regulator. Those belong to your compliance officer, legal adviser and accountant. For where the deposit sits in the whole client journey, see our guide from first lead to first deposit. Payments also appear as one item in the brokerage launch technology checklist.

Where QUANTIX fits

In QUANTIX payments and operations, approvals run on the same customer record that sales and compliance use, as the platform overview explains. Specifically:

• Payment methods are manual (bank transfer, crypto address, custom instructions per currency) or processor-backed, each with minimum and maximum amounts, fees and processing time. Clients see only the methods that match their account currency.
• Processor webhooks move deposits to completed automatically. Manual methods wait for staff approval in the CRM and back office.
• Staff review and approve withdrawal requests in the CRM, and the client is notified at each stage.
• The transaction ledger uses pending, completed, failed and cancelled statuses, with creator and payment-method filters and export.
• Authorised staff can record a manual deposit from the customer record, and it is audited like any other change. The audit trail covers more than 70 event types with before-and-after values.
• The permission matrix (19 modules, 6 actions, 4 data scopes) decides who sees transactions and who approves them. You can add your own roles, such as a finance role, next to the ready-made ones.
• Notification triggers cover deposit requested, deposit received, withdrawal requested, withdrawal completed and high-risk transactions, as described on the automation and integrations page.

Four payment processors are integrated: PayMesh, PGPay, CoinGate and Transak. Connecting another is assessed after a technical evaluation as custom development under a separate scope. Processor accounts, fees and banking relationships are agreements between your brokerage and each provider. The amount limits, closed-loop rule and escalation levels described above are your policy decisions. To be clear: QUANTIX provides operations and compliance tooling; using it does not make your firm compliant or give it a licence.

To see the workflow run on your own cases, book a private demo and bring your current withdrawal policy and the rejection reasons your team uses today.