UK RTS 12 Gross Deposit Limits: Database Migration Before 30 June 2026

The deposit-limit subsystem on a typical UKGC-licensed iGaming platform checks the player's available headroom by reading what the wallet currently holds against the limit. Deposit £500, withdraw £300, and the system credits £300 back against the daily allowance because the wallet went down. That pattern is correct under a net deposit limit. It is wrong, on every withdrawal-followed-by-redeposit, under what RTS 12B will require from 30 June 2026.

The new wording defines a deposit limit as gross by minimum and by default per the UKGC consultation response on Proposal 1. The cap applies to money put into the account. Withdrawals, refunds, voided transactions, and game returns do not reduce it. A player who deposits £500 and withdraws £300 has used £500 of their gross daily allowance, not £200. Net deposit limits remain a permitted product but cannot be called or labelled a "deposit limit" under the new wording, and gross must be presented at no less than equal prominence in the same UI per RTS 12B's prominence clause.

Three things this article does that the law-firm coverage of the rule does not. It translates RTS 12B into the data model layer where the bug actually lives. It walks the migration from a balance-derived running counter to an events-of-record table with the SQL written out. And it specifies the PSP webhook contract the deposit-limit subsystem needs from upstream payment service providers before cutover, because the platform cannot count what the PSP does not tell it. The parallel UKGC build landing in the same window is frictionless affordability under LCCP 3.4.4, with its own Stage 1 and Stage 2 deadlines.

What "gross" means in your data model

The regulation reads as one sentence. The data model has to read three things off that sentence.

First, the unit of accumulation is a deposit event, not a balance delta. A deposit is committed once the funds have cleared the operator's PSP and been credited to the player's gambling account. From that point, the deposit's contribution to the gross counter is fixed for the period. Reversal flows that happen later, whether refund, chargeback, void, or partial refund, do not subtract from the counter even if they zero out the wallet.

Second, the period restarts on a calendar boundary keyed to the player's local time at the operator. Daily means a 24-hour window from the player's set start point; weekly is seven days; monthly is calendar-month. The boundary is whatever the operator publishes to the player at limit-set time. The player's CET versus the operator's UTC is a quiet bug source. Get it documented per player at limit-set time and store the timezone string with the limit record.

Third, the most-restrictive rule applies when more than one limit is set. From the UKGC RTS 12 standard page: a player who set both a £10 daily and a £100 weekly cap may deposit £10 per day and £70 per week. The bug pattern operators hit here is querying limits in priority order rather than running every active limit per deposit attempt. Under the priority pattern, a daily cap might pass while the weekly is silently breached because the daily check returned first and the weekly was never queried.

Net deposit limits, stake limits, and loss limits all remain permitted products under RTS 12. The terminology lock-in is what changes. Anything labelled "deposit limit" in the customer journey from 30 June 2026 must compute as gross. A net product can keep computing the way it always did, but the customer-facing label is now "net deposit limit" and the gross variant must appear with at least equal prominence in the same screen per the UKGC consultation response Annex 2.

Why the running-counter pattern breaks under RTS 12B

The shape of the pattern that breaks is consistent across legacy platforms: the deposit-limit check reads a "remaining" value computed at request time as limit - (sum of period deposits) + (sum of period withdrawals). Or more often, it reads the player's wallet balance against a high-water mark and infers what the player has spent. Both patterns implicitly net withdrawals against deposits, which is the definition of the net product, not the gross product.

Three bugs surface immediately under the new rule.

The first is the withdrawal-redeposit cycle. A player with a £500 daily gross cap deposits £500 at noon, plays through £200, withdraws £300 of remaining funds at 2pm, and tries to deposit again at 3pm. Under the legacy net-counter pattern, the system computes 500 - 500 + 300 = 300 of headroom and accepts a £300 deposit. Total deposited that day: £800, against a £500 gross cap. The rule is breached. The audit log shows two clean deposit events plus a clean withdrawal event in between, and the regulator can compute the breach trivially from the same log the operator handed over.

The second bug is the refund flow. A player deposits £200, the deposit settles, a fraud rule reverses it ten minutes later, the player retries with a new card, and deposits £200 again. The legacy pattern subtracts the refund and sees only £200 used. The gross definition counts the original deposit because the funds settled, even though they were later reversed. Whether refunds count toward the gross is the part of the data model the operator has to commit a position on, and the safer reading of RTS 12B is that they do, because the wording locks the limit to "amount deposited" not "amount retained", per Bird & Bird's analysis of the operator-facing impact.

The third bug is silent precedence on simultaneous limits. The operator that wrote a "first matching limit applies" rule, rather than "every active limit must pass", will see weekly caps slipping past daily-cap checks on rare deposit-pattern combinations. The pattern is observable only at the audit layer and only after the period closes, which is the worst possible failure mode for a regulator-facing system.

What does not break, and is worth flagging because it is sometimes overcorrected: wallet-balance enforcement on play-through is unchanged. The gross counter governs what the player can put in; it does not constrain what the player can stake out of an existing balance. The deposit-limit subsystem and the wagering-limit subsystem are separate problems and should not be conflated under the migration.

Events-table as the deposit-of-record

The architectural answer is to make the deposit event the canonical record and compute the gross counter as a query against it. A platform that already runs a separate deposit_events log can usually wire the new check in days. A platform whose only deposit record is a wallet ledger entry, with credits and debits intermixed and no event-type discrimination, has the bigger lift.

The minimum schema:

CREATE TABLE deposit_events (
  id              BIGSERIAL PRIMARY KEY,
  player_id       BIGINT NOT NULL,
  amount_minor    BIGINT NOT NULL,         -- pence; never null
  currency        CHAR(3) NOT NULL,
  occurred_at     TIMESTAMPTZ NOT NULL,    -- PSP settlement time, not request time
  psp_reference   TEXT NOT NULL,           -- idempotency key from PSP
  source_psp      TEXT NOT NULL,           -- e.g. 'worldpay', 'trustly'
  status          TEXT NOT NULL,           -- 'settled' | 'reversed' | 'pending'
  reversed_at     TIMESTAMPTZ NULL,        -- nullable; reversal does NOT delete the row
  reversal_reason TEXT NULL,
  CONSTRAINT psp_ref_unique UNIQUE (source_psp, psp_reference)
);
 
CREATE INDEX idx_dep_player_time ON deposit_events (player_id, occurred_at DESC);

Three properties of this schema map onto the rule. Reversals do not delete rows; they mark status and stamp reversed_at. The gross-counter query reads WHERE status IN ('settled', 'reversed') AND occurred_at >= :period_start. The unique constraint on (source_psp, psp_reference) prevents double-counting under PSP webhook retry storms, which is where the second-largest class of deposit-limit bugs lives behind net-vs-gross logic.

The gross check at deposit-attempt time:

SELECT COALESCE(SUM(amount_minor), 0) AS used
FROM deposit_events
WHERE player_id = :pid
  AND occurred_at >= :period_start
  AND occurred_at <  :period_end
  AND status IN ('settled', 'reversed');

Run this query for every active limit period (daily, weekly, monthly) and reject the attempt if any of them exceeds its cap. The ordering of the checks is irrelevant; all of them have to pass. That is the "most restrictive applies" rule expressed as code rather than as policy.

The operational details that often go missing on first migration:

• The period-start calculation needs the player's set timezone, not the server's. Store the player's chosen timezone on the limit record itself; do not infer it from request headers.
• Pending deposits should count toward an in-flight sub-counter so a player cannot fire ten parallel deposit attempts in the same second and have all of them pass the check before any of them settle. Treat the in-flight count as a soft reservation that is reconciled when the PSP webhook confirms or rejects.
• A limit decrease takes effect immediately per RTS 12. A limit increase has a 24-hour cooling-off per the same standard, per the Lexology summary of the October 2025 phase. Store requested_at, effective_from, previous_value, and new_value on the limit-change record, and have the deposit check read whichever value is currently in force.
• Multi-currency operators normalize to a stored player-currency at deposit time. Cross-currency limits are not a regulator-supported product; pick one currency per active limit and document the conversion path.

The migration from a net-style running counter is a dual-write window. For four to eight weeks before cutover, write every deposit and reversal to both the legacy ledger and the new deposit_events table. Run the gross query against the new table in shadow mode and log mismatches against the legacy net check. The mismatches are exactly the bugs the new rule is meant to surface, and the log is the operator-side proof that the migration was correct on the dataset that matters: real production deposits.

The PSP webhook contract you need before cutover

The deposit-limit subsystem is downstream of the PSP. It can only count what the PSP tells it has happened. The general-purpose webhook reliability and idempotency design sets the contract; this section is the RTS 12B-specific overlay. In practice the platform integrates with multiple PSPs across the cashier. Worldpay or Nuvei carry the card book on UKGC-licensed brands. Trustly or Brite handle open-banking deposits. Paysafe brings Skrill, Neteller, and paysafecard wallet flows. Adyen sits in the orchestration or fallback slot. Each PSP emits deposit events on a slightly different shape, and the migration is the moment to lock the contract.

Five fields are non-negotiable for gross counting:

1. Settlement timestamp. The time the PSP committed the deposit to the operator's account, not the time the player tapped pay. The gross counter buckets against this timestamp into the player's period.
2. Final amount in minor units after FX and after any PSP-side fee deduction. The gross counter reads what actually credited the player's wallet.
3. PSP transaction reference plus PSP identifier. The unique pair forms the idempotency key that prevents double-counting when the webhook retries.
4. Final settlement status. A binary outcome: settled or rejected. Pending events are not gross-counted; reversals after settlement are gross-counted because the deposit happened.
5. Reversal events as separate webhooks. A subsequent reversal arrives as its own event referencing the original PSP transaction reference. The platform marks the original row reversed and does not subtract from the counter.

Two fields that operators frequently want but should not depend on:

• The PSP's own deposit-attempt counter for the player. Different PSPs increment differently, and routing across multiple PSPs makes the per-PSP counter useless for a player-level gross.
• A category classification of the deposit (top-up, recurring, bonus reversal). Categories are operator-side concepts and the PSP cannot reliably inform them. Track category in the operator's own deposit ledger if needed.

The webhook delivery semantics matter as much as the field set. Specify at-least-once delivery with idempotency on the (source_psp, psp_reference) pair. Do not specify exactly-once delivery; it is not a property the major PSPs offer, and pretending it is produces silent double-counting under retry storms after a PSP outage. The UNIQUE constraint in the schema above is the platform's defense against this regardless of what the PSP claims at the integration call.

Operators with PSP relationships predating the new rule will find that their integration agreements lack explicit "settled deposits regardless of subsequent reversal" framing. The clean fix on the next contract renewal cycle is a one-paragraph rider that defines the deposit event the PSP will emit, the fields it must carry, and the at-least-once delivery semantic. PSPs that handle multiple UKGC-licensed merchants will not push back on the rider; they have to support the same shape for every operator with the same migration deadline.

Retention, audit, and the rollout window before 30 June 2026

UKGC retention sits at the LCCP and gambling-AML layer rather than at RTS 12 itself. The applicable floor for transaction records, including deposit events and limit-change history, is five years from the end of the customer relationship under the operator's AML obligations. Some operators retain longer for litigation hold or contractual reasons; five years is the regulator floor.

What the deposit-limit migration adds to the retention question is the reproducibility obligation. The events table is the regulator's audit surface. The operator must be able to reproduce, for any given deposit, the period the deposit fell into, the gross used at deposit time, the active limits at deposit time, and the cooling-off status of any limit changes during the period. That requires storing limit changes as their own event log, not as in-place updates on a player record.

The minimum retention contract:

• Deposit events: five years post-relationship, immutable, append-only, with reversal as a distinct status update on the same row.
• Limit changes: five years post-relationship, with requested_at, effective_from, previous_value, new_value, and the cooling-off audit trail.
• Deposit-rejection events (limit hit, cooling-off active, currency mismatch, etc.): five years, with a machine-readable rejection reason for regulator queries.
• Decline copy shown to the player at the cashier: log the exact text shown so a regulator complaint can be reconciled against the player's actual experience, not a re-rendered version.

The rollout window from May 2026 to 30 June 2026 is six weeks of deployment time. The mandatory build is the gross-counter check, the PSP webhook contract, and the dual-write data path. The customer-facing changes from the October 2025 RTS 12 phase one should already be in production: the prompt at registration, the homepage link to limit setting, the six-monthly review reminder, the immediate-decrease and 24-hour-cooling-off-increase processing all bedded in over the autumn. Operators that missed that deadline are running parallel work streams and the engineering capacity for the database migration is competing with the customer-journey build.

The cutover question on the day is when to switch the gross check from shadow mode to enforcement. The cleaner answer is a feature flag per player, with a controlled rollout to a high-volume cohort first whose deposit shapes will surface any remaining edge cases, followed by a full-population flip ahead of 30 June. The risk of a flip-day enforcement switch with no shadow window is that limit-blocked deposits in the first hours after cutover will be the result of the new logic rather than of legitimate cap hits, and customer support will not have the playbook for telling the difference.

The two things to verify before declaring the migration complete:

• The shadow-mode mismatch log shows zero divergence between the new gross query and the legacy net query for players whose deposit pattern in the period is purely additive, with no withdrawals. If that case diverges, the new query has a bug and it has to be fixed before cutover.
• The shadow-mode mismatch log shows the expected divergence for players who withdrew during a period and then redeposited. The expected divergence is exactly the bug class the rule is closing, and seeing it in the log is the proof that the new logic does what the regulation requires.

When both of those hold, the migration is correct on the dataset that matters and the cutover risk is implementation-side rather than logic-side. From 1 July 2026, the deposit-limit subsystem is what the regulator will audit against, and the events table is the artifact that proves compliance. Build it that way and the audit is a query rather than an investigation.