iGaming wallet reconciliation should prove that every accepted deposit, withdrawal, wager, win, adjustment and product transfer reaches one authoritative player balance exactly once. The useful delivery artifact is a wallet control pack that joins the ledger model, transaction-state contract, product-wallet interfaces, liability reports, exception workflow and release evidence before a platform launch or replacement.
For an operator CTO, platform owner, finance lead or procurement team, the decision is larger than choosing a payment screen or database. The buyer needs to know which system may change money state, what a timeout means, how a game or sportsbook wallet returns funds, how a correction is approved and which evidence closes a daily mismatch.
Give one ledger authority the right to change money state
An iGaming wallet needs one authoritative ledger that records accepted money movements while every other balance remains a derived or operational view. A payment processor, PAM, sportsbook, RGS, bonus service and reporting warehouse can each hold relevant state, but none should silently correct the source ledger from its own copy.
The UK Gambling Commission’s remote gambling equipment guidance separates account management, settling, transaction records, data storage and external interfaces. It also describes shadow accounts that track chip or token balances when funds move into a hosted product. The guidance applies in its Great Britain context, but its component model exposes the procurement question clearly: which component owns each movement, and which components only report it?
Draw an authority map before defining endpoints. Name the owner for available cash, restricted incentive value, pending deposits, pending withdrawals, funds committed to games, unsettled sports bets, manual adjustments and chargebacks. Define whether each value is a posted balance, hold, product balance or accounting liability. A field called balance without that meaning is not a contract.
Make every movement an explicit transaction state
Every wallet instruction should move through a small, documented state machine instead of being inferred from network success. Requested, accepted, denied, pending, posted, reversed and cancelled are examples, not a universal mandatory vocabulary; the final states must match the operator, payment and product contracts.
GLI-19 Interactive Gaming Systems Version 3.0 says its applicable automated financial transactions should confirm or deny each request with the transaction type and value. Its player-account records include a transaction type, timestamp, unique transaction ID, amount, balance before and after, fees, handling user where applicable, status, payment method and authorization reference. GLI is a technical baseline that a jurisdiction may adopt or adapt, not a substitute for the applicable rules.
Bind each business instruction to a stable transaction key. A repeated request with the same key should resolve to the recorded outcome instead of creating another movement. A timeout should remain unknown until a state query or callback proves what happened. Store the external processor reference separately so one deposit can be traced across the processor, wallet and player statement without pretending those systems share one identifier.
Reconcile product wallets without creating a second truth
Product wallet reconciliation should match every transfer into a game or betting product with the activity and return that follow it. The contract must cover opening transfer, wagers or stakes, wins, refunds, voids, interrupted funds, fees where applicable and closing transfer.
GLI-19 describes a gaming credit meter that may receive funds from the player account and return them when play ends. The Commission’s RTS 1 customer account information says account history in its scope should clearly show movement into and out of gambling products. Together, those sources support a practical acceptance rule: product activity and wallet transfers need stable references that can be joined without guessing from timestamps or rounded totals.
The operator ledger should not overwrite a supplier record to make totals agree. Compare the two views, classify each difference and route it to an exception state. Typical classes include missing callback, duplicate request, late settlement, unresolved interrupted round, currency or precision mismatch, incorrect product reference and approved manual adjustment. The platform migration guide covers the separate one-time decision of moving this authority between platforms; the live wallet contract must keep proving it after cutover.
Derive player balances and statements from posted meaning
Player-visible balances and statements should express the same transaction meaning as the authoritative ledger. A fast balance cache can serve the interface, but it needs a provable relationship to posted entries and holds rather than an independent update path.
RTS 1 requires a current account balance for customers in its scope, easy access to at least three months of account and gambling history, at least 12 months on request, and an account-level net-deposit view. The history includes deposits, withdrawals, product movements, relevant bonus information, bets, results and winnings. The Commission’s RTS 2 displaying transactions separately requires clear information about transaction value and, for applicable casino sessions, the current net position.
Create a statement mapping for each transaction class. Name the player label, sign, currency, event time, posting time, status, product reference and reversal link. Keep restricted incentive value distinguishable from cash. The existing Wizards bonus engine requirements guide covers eligibility and wagering rules; the wallet must preserve the resulting value and restrictions without taking ownership of campaign logic.
Reconcile wallet data to customer funds liabilities
Wallet reconciliation and customer funds safeguarding are connected but different control questions. The wallet proves the player’s account state; the operator’s finance process proves the liability and asset position required by the applicable market.
The Commission’s customer funds segregation guidance says its licence condition applies to most remote operators holding customer funds but not to the listed B2B and ancillary licence types. It defines relevant customer funds and requires affected licensees to keep them in separate client accounts. It also says funds in transit to a consumer remain within the customer-funds definition until received. Those are Great Britain rules within their stated scope, not universal accounting advice.
New Jersey provides a different concrete example. The Division of Gaming Enforcement’s consolidated Chapter 69 regulations require the separate account described there to cover daily ending cashable player balances, funds on game and pending withdrawals, and require the casino licensee to have access to account and transaction data for that check. A platform buyer can therefore require configurable liability reports and retained evidence without claiming that one market’s calculation applies everywhere.
Control reversals, adjustments and disputes as new events
Reversals and adjustments should add an authorized, traceable event rather than erase the original transaction. The correction needs its own reference, reason, approver, before-and-after balance, affected liability period and link to the event it changes.
GLI-19 includes manual adjustments among player-account transactions and calls for authorization procedures that make account changes auditable. Build separate permissions for support investigation, finance correction, fraud action and system recovery. A user who can view a dispute should not automatically be able to change a balance, and a technical retry should not become a manual financial adjustment.
Design the dispute view around evidence, not editable fields. It should join the player instruction, processor response, ledger events, product events, statement entry and prior operator decisions. If an incident affects wallet integrity, the iGaming incident response guide explains how to preserve one evidence and recovery route before containment changes the scene.
Accept the wallet through mismatch and recovery tests
Wallet acceptance should prove negative paths and reconciliation recovery, not only a successful deposit and wager. Build tests that create duplicate callbacks, timeouts after posting, out-of-order events, denied deposits, partial withdrawals, late product settlement, interrupted games, chargebacks, currency precision differences and unauthorized adjustments.
For each test, retain the starting state, request key, external references, ordered ledger events, displayed balance, statement result, product result, liability-report effect, alerts, exception status and final reviewer decision. Require the reconciliation job to identify the planned mismatch and close it only through the approved path. A test that ends with equal totals but cannot explain how they became equal has not proved control.
The acceptance schedule should also cover backup restoration and reporting cutoffs. Rebuild balances from the retained ledger, replay derived views without repeating external movements, and show how a late event enters the correct accounting period. Record any allowed timing difference explicitly rather than hiding it inside a daily aggregate.
Make the wallet control pack a procurement deliverable
The wallet control pack should be accepted before launch and revised whenever the ledger, payment methods, product-wallet model, currencies or liability rules change. It gives engineering, finance, compliance, support and suppliers one contract for the same money state.
Require the authority map, account and hold model, transaction-state definitions, idempotency rules, product-transfer contract, player-statement mapping, liability reports, reconciliation schedules, exception ownership, adjustment permissions, retention rules and exact-release test evidence. Name which unresolved mismatch, missing reference or untested recovery path blocks launch.
Frequently asked questions
What should be the source of truth for an iGaming wallet?
An iGaming wallet should have one authoritative ledger for accepted financial movements, with every displayed balance derived from posted entries and explicit holds. Product wallets, payment processors and reporting stores can hold operational views, but they should not independently rewrite the player balance.
Which transaction states should an iGaming wallet expose?
The wallet contract should expose the states the business can act on, such as requested, accepted, denied, pending, posted, reversed and cancelled. Each transition needs a stable transaction reference, timestamp, reason, balance effect and named authority.
How should an operator reconcile an RGS shadow wallet?
Reconcile an RGS or shadow wallet by matching opening transfer, wagers, wins, refunds, interrupted funds and closing transfer to the operator ledger. Any mismatch should enter a controlled exception queue without either side silently changing the other record.
How should wallet APIs handle retries and duplicate callbacks?
Wallet APIs should bind every business instruction to a stable idempotency or transaction key and return the recorded result for a duplicate request. A timeout is not proof of failure, so the caller should query the authoritative state before issuing a new movement.
How are customer funds liabilities different from wallet balances?
A player-visible wallet balance is an account view, while customer funds liability is an operator accounting and safeguarding obligation defined by the applicable market. The two should reconcile through controlled reports, but one should not be treated as automatic proof of the other.
What evidence should a wallet platform vendor deliver?
A wallet platform vendor should deliver the authority map, transaction-state contract, product-transfer rules, retry and reversal behavior, access controls, player-statement mapping, liability reports, reconciliation jobs, exception workflow and test evidence for the exact release.
If you are commissioning or replacing an iGaming wallet, talk to Wizards about turning transaction boundaries, product transfers and liability reporting into a testable platform reconciliation pack.
