Unknown block type:
SchoolHeaderUnknown block type:
SchoolNavFinance Management
Wallets, deposits, withdrawals and reconciliation
What actually goes wrong
Eight things that make month end take a week
None of them are the accounting. All of them are the plumbing.
A brokerage moves money in six directions at once: card deposits, bank transfers, crypto, internal transfers between wallets and trading accounts, partner payouts and withdrawals back out again. Each provider reports in its own format, on its own schedule, with its own reference — and none of them know about each other.
What that produces is not usually theft. It is a finance team that cannot close the month because four hundred rows almost match, a client who was credited twice, and a withdrawal that went out because somebody was covering the desk and did not know the limit. Every failure below has the same shape: money moved, and the record of why lagged behind it.
-
01
A deposit landed and the client waited twenty minutes for it.
Gateway callbacks credit the wallet as the provider confirms, not when somebody next opens the dashboard. The client sees the balance move while they are still in the app, which is the only moment when that fact is worth anything to them or to you.
-
02
A withdrawal was approved by somebody covering the desk.
Approval limits sit on the operator rather than the department, and tiers escalate by amount, destination and risk. A stand-in never inherits a colleague’s ceiling, and the payout that needed two signatures does not go out on one because the second person was at lunch.
-
03
The PSP statement almost matched the ledger.
Every movement carries the provider’s own reference from the moment it is created, so reconciliation has something exact to match on instead of a date and an amount that four transactions share. What does not match is a short list of exceptions rather than a morning of eyes down a spreadsheet.
-
04
Somebody adjusted a balance and nobody knew why.
Manual adjustments require a reason from a list your finance team controls, an approval at the right level, and they land in the trail with the operator and the time. A year of adjustments becomes something you can read a pattern out of rather than a column that makes auditors uneasy.
-
05
The client disputed the conversion rate.
Multi-currency wallets hold the currency the client funded in, and every conversion records the rate used, its source and the moment it was taken. A dispute three months later has an answer with a timestamp rather than a recollection of roughly what the market was doing.
-
06
An internal transfer went missing between two accounts.
Wallet to trading account, account to account, wallet to wallet: every internal movement is a recorded transaction with both ends on it, not a pair of adjustments that happen to net to zero. If one leg fails, the movement fails rather than half completing and leaving the difference to be found later.
-
07
The chargeback arrived four months after the deposit.
Deposits keep their provider reference, their client, their device and their approval trail for as long as retention rules require. When a chargeback lands, the evidence is assembled from the record rather than reconstructed from a payment dashboard that only keeps ninety days.
-
08
Finance and the desk were reading different numbers.
The ledger the console runs on is the ledger the reports are built from. There is no export standing between the two, so a report never disagrees with the screen it came from and nobody spends the first week of the month deciding which version to believe.
What is in it
Money in, money moved, money out, money matched
Four things a back office does all day, and what the module brings to each of them.
-
Stage one
Deposits
Whatever rails you run, they land in the same ledger and credit on the provider’s confirmation rather than on somebody noticing. Failed and pending payments stay visible instead of disappearing, because the deposit that did not arrive is the one the client is about to call about.
- Cards, bank transfer, e-wallets and crypto
- Instant credit on gateway callback
- Provider reference held on every row
- Pending and failed payments visible
- Per-method limits and fees
- First-deposit flagging for the desk
- Chargeback evidence retained
-
Stage two
Wallets and transfers
The wallet sits between the payment rails and the trading accounts, which is what lets a client fund once and allocate afterwards. Every internal movement is a single transaction with both legs on it, so nothing half-completes and quietly becomes a reconciliation problem.
- Multi-currency wallets per client
- Wallet to trading account transfers
- Account to account movements
- FX conversion with the rate recorded
- Credit and bonus handling
- Holds and partial releases
- Full statement per wallet
-
Stage three
Withdrawals
Released on approval rules rather than out of an inbox. Tiers escalate by amount, destination and risk, KYC and account state are checked before anything leaves, and a payout that fails a check stops with a reason on it rather than being quietly retried.
- Approval tiers by amount and destination
- Limits on the operator, not the department
- Four-eyes above a threshold
- KYC and restriction checks before release
- Return to source enforcement
- Batch payouts to partners
- Rejection with a structured reason
-
Stage four
Reconciliation
The part that decides how long month end takes. Provider statements are matched against the ledger on the reference each row has carried since it was created, and what is left is an exception list a person can actually work through before lunch.
- Statement import per provider
- Matching on the provider reference
- Exception queue for the unmatched
- Manual adjustments with a required reason
- Daily and monthly close positions
- Client money segregation reporting
- Export to your accounting system
Who signs in
One ledger, six levels of reach
What an operator may move, approve or only look at is set before the first payout, not after one.
- Payments operations. The day’s queue: pending deposits, withdrawals waiting on a check, failed payments to chase. Everything they touch carries the reference reconciliation will need later.
- Finance. The ledger, the close positions and the exception list, with approval limits set per operator so covering for a colleague never comes with a larger ceiling attached to it.
- Support. Whether a deposit arrived and where a withdrawal has got to — enough to answer the call, without the ability to move anything at all.
- Sales. Funding activity on their own book and first deposits as they land. The number, not the rails, and nothing from another desk’s clients.
- Compliance. Source of funds, return-to-source enforcement and every manual adjustment with the reason behind it, read across the whole book and changed nowhere.
- Management and auditors. Close positions, segregation reporting and the full movement trail, exported from the same screen rather than requested from another team.
Money moving is easy. What costs you the month is the record of why it moved.
Questions about the module
Before you move the ledger
What a finance team wants settled before client money runs through something new.
-
Cards, bank transfer, the major e-wallets and crypto, wired to your own merchant accounts rather than ours, so settlement goes where it already goes and the commercial terms stay yours. Anything we do not ship a connector for goes through the open API on the same shape, which matters in markets where the provider that actually converts is a local one nobody outside that country has heard of. Whichever rail a payment takes, it lands in the same ledger carrying the provider’s own reference.
-
On rules rather than on whoever opens the queue. Tiers escalate by amount, destination and risk; four-eyes can be required above a threshold; and KYC status, account restrictions and return-to-source rules are checked before anything is released. The important detail is that limits sit on the operator rather than the department, so a stand-in covering a colleague on leave does not inherit a ceiling they were never given — which is how most of the payouts that should not have gone out actually went out.
-
Importing the provider statement and working an exception list. Because every movement has carried that provider’s own reference since the moment it was created, matching is exact rather than a guess made from a date and an amount that four transactions happen to share. What does not match surfaces as a short queue with the reason it did not, and manual adjustments to clear it require a reason from a list your team controls plus an approval at the right level. Most desks find the daily close is minutes and the month is an afternoon.
-
Yes. Wallets are per currency, so a client funds in what they actually hold and converts when they choose to rather than at the moment of deposit. Every conversion records the rate used, where it came from and the second it was taken, which turns a dispute months later into a lookup instead of an argument. Trading accounts can be denominated separately again, and the transfer between wallet and account records both legs as one movement.
-
It does, and through the same approval machinery. Rebates calculated in the IB module arrive as payable amounts, run through the same tiers and checks a client withdrawal does, and go out as a batch rather than as forty individual transfers somebody keys in on the last Friday of the month. The partner sees what they are owed and what has been paid in their own portal, which removes most of the mail a partnerships desk answers.
-
Yes, and on the shape your accountants asked for rather than ours. Close positions, movement detail and client money segregation figures export on a schedule or on demand, and the export itself is logged with the operator who ran it. Because the figures come off the same ledger the console runs on, the version finance takes to the accountant is the version the desk was looking at that morning — which removes the reconciliation between two internal systems that most brokerages quietly do before the real one starts.