Withdrawal speed is a retention metric, not a payments one
The slow mode in your withdrawal distribution is queue time, not rails. Clients rarely complain about it; they quietly withdraw more next time and then stop trading.
Withdrawal speed is the most reliable retention signal a broker has, and one of the least instrumented. It is reported as an average when the distribution is bimodal, and the slow mode is entirely manual queue time rather than anything to do with the rails.
The distribution is two distributions
Withdrawals that pass every automated check settle in minutes. Withdrawals that touch a human wait for the next time that human works the queue. There is almost nothing in between, which makes the mean a number that describes no actual withdrawal.
t_slow ≈ t_queue_wait + t_review + t_railWhen a client complains that withdrawals are slow, they are almost never describing the payment rail. They are describing how long your queue sat unworked.
What pushes a withdrawal into the slow mode
| Trigger | Share of manual reviews | Genuinely needs a person? |
|---|---|---|
| Amount above threshold | High | Sometimes |
| First withdrawal on the account | High | Usually |
| Different method from deposit | Medium | Yes |
| Open compliance item | Medium | Yes |
| Profit above a ratio of deposit | Medium | Rarely |
| Round-number amount | Low | No |
Thresholds that were never re-baselined
A manual-review threshold set at a fixed amount when the book was smaller will, as average account size grows, gradually capture a larger share of withdrawals until most of them are being reviewed. Nobody changed anything; the distribution moved underneath a static rule. The symptom is a review queue that grows faster than headcount with no policy change to explain it.
Why it shows up in retention before it shows up anywhere else
A slow withdrawal is the moment a client tests whether their money is really theirs. The behavioural response is rarely a complaint; it is a reduction in balance. Clients who experience one slow withdrawal frequently withdraw more of their equity on the next attempt, which reads in the data as deleveraging rather than as dissatisfaction.
- 01Withdrawal takes 40 hoursQueue, not rail
- 02Client does not complainNo ticket, no signal
- 03Next withdrawal is largerTesting, quietly
- 04Trading size fallsLooks like risk aversion
- 05Account goes quietRecorded as churn, cause unknown
| Same-day cohort | Over-24h cohort | |
|---|---|---|
| Accounts | 1,120 | 318 |
| Withdrew again within 30 days | 22% | 47% |
| Average share of equity withdrawn | 31% | 68% |
| Still trading at 90 days | 81% | 54% |
Illustrative figures, chosen to show the mechanism. Your own numbers will differ.
The tractable part
- Measure the two modes separately and never report the mean.
- Re-baseline every fixed-amount threshold against the current distribution, not the one it was set for.
- Instrument queue wait separately from review time, because they have different fixes.
- Join withdrawal latency to the same client’s trading behaviour over the following ninety days.
Only the last of those is difficult, and only because it requires payments data and trading data to be joined per client over time. That join is also the one that turns withdrawal speed from an operational metric into a retention argument the board understands.