Payments
Clients forgive a slow deposit. They talk about a slow withdrawal.
The outbound path is the one your clients describe to other people. It deserves the same engineering as the inbound path, and usually gets a spreadsheet instead.
See it live
The screen a payout actually goes through
Destination, amount and approval state, on the same mobile flow a client uses to request money back — the far end of the four gates below.
Four gates
Every request passes the same four checks, in the same order
Validate
Is this destination usable at all
Bank details and wallet addresses are checked for format and network before anything else happens. A withdrawal that fails at the provider two hours later should have failed here in two seconds.
Match
Does it match how the money arrived
Returning funds to the instrument they came from is the default. Where a client asks for something different, the mismatch is raised as a decision rather than processed quietly.
Authorise
Is anyone required to say yes
Below the threshold it proceeds. Above it, approval routes to the people your policy names, with two-person sign-off where the amount warrants it.
Send
In a batch, on a schedule
Approved requests join the next run rather than each triggering a separate manual transfer, and a single bad destination does not stall the rest of the batch.
Speed is a control decision
Reviewing everything is not the same as reviewing carefully
Auto-approve the boring ones
A returning client, a known destination, an amount inside their normal range and no monitoring flags — this describes most withdrawals, and holding them for manual review buys nothing.
Spend the attention where it counts
Review capacity is finite. Routing every request through a human means the genuinely unusual one gets the same thirty seconds as the ninety routine ones ahead of it.
Tell the client what is happening
A withdrawal that is under review is not a withdrawal that has disappeared. Clients are told the state and the expected timing, which removes most of the support contact entirely.
FAQ
Withdrawals: common questions
6 short answers to what teams ask before a demo.
Yes, within rules you define — destination already known, amount inside the client's normal range, no monitoring flags raised. This is what most withdrawals look like, and routing all of them through a human queue slows the unusual ones down rather than catching more of them.
Format and network are checked before the request is accepted, so an address on the wrong network or a malformed bank detail fails immediately rather than at the provider hours later. Known-good destinations are remembered for the client.
It is the default, because it is what most regulators expect and what most fraud attempts try to avoid. Where a client legitimately needs a different destination, the mismatch is surfaced for a decision rather than silently allowed or silently blocked.
It is isolated and the rest of the run completes. The failed item returns to the queue with its reason attached, rather than the whole batch being rolled back and re-assembled by hand.
Whoever your policy names, by threshold. Above an amount you set, two people are required and the same person cannot both request and approve. Every approval is attributable and stays in the record.
The approval queue your team works in sits in BrokerOS, alongside the client record. PayVault is what enforces the thresholds, validates the destination and executes the payment once the decision is made.
Still have a question?
A specialist will answer it directly, with your set-up in mind.
Ask a specialistHow long does a withdrawal take you today?
Tell us the median and the worst case, and we will show you which part of the path is actually costing the time.