Where the UKGC's FRA Check Belongs in Your Deposit Flow

The UKGC's Financial Risk Assessment (FRA) belongs on the deposit event itself, not on a standalone screen a player has to clear before they can pay. That's the sequencing decision that decides whether financial risk assessment gambling product design reads as part of checkout or as a wall in front of it. Luminbrane has worked on deposit flows for UKGC-licensed operators and platform providers, and the pattern holds regardless of stack: attach the check to the transaction, hold only the transaction while the credit reference agency (CRA) lookup runs, and instrument the pause so a false positive never gets logged, or felt, as a broken payment.

• Short answer: Trigger the FRA check on the in-progress deposit, not on a gate before it; hold the transaction, not the account.
• First step: Design the held-transaction state, its own status, its own timeout, its own support macro, before the compliance ticket gets anywhere near a sprint.
• The goal: A pause invisible to the 97 percent of players it barely touches, and a supported, well-instrumented path for the small minority it doesn't.

Tips: Give the FRA-paused state its own row in your transaction status table from the first migration; teams that reuse "pending" or "failed" spend the next two quarters untangling support tickets from real payment failures.

Key takeaways

The core argument here is simple: an FRA check behaves like a live-ops feature, not a compliance form. It has a trigger, a transient state, a population it affects unevenly, thresholds that move, and a failure mode that looks exactly like a bug if nobody tells support otherwise. Treat it that way from the first design doc and the build gets smaller, not bigger.

Point	Detail
Attachment point	The FRA check should trigger on the deposit event itself, not as a standalone screen placed before it.
Account state	While the CRA lookup runs, the account stays fully active; only the deposit itself is briefly held.
Who it touches	Gambling Commission pilot data shows 97 percent of assessments were frictionless, and only 0.1 percent needed a non-frictionless review.
Rollout thresholds	Stage one applies at £5,000 per 24 hours for players 25 and over and £2,500 per 24 hours for under-25s, with a much lower final threshold already signalled.
Instrumentation	Treat the FRA as a live-ops feature with its own dashboard and rollback switch, so a false positive reads as a paused deposit rather than a broken one.

Contents

• Where in the deposit sequence does the financial risk assessment check actually attach?
• What state is the account in while the CRA lookup runs?
• How many players actually get diverted, and what happens to them?
• Why does blanket friction backfire, and what does proportionate friction look like instead?
• How should the stage-one and final thresholds shape your build plan?
• How do you instrument this so a false positive doesn't read as a broken deposit?
• What do support and live ops need in place before this ships?
• Frequently asked questions
• Sources

Where in the deposit sequence does the financial risk assessment check actually attach?

Most teams picking up this ticket for the first time reach for the wrong mental model. They picture the FRA as a gate: a page sitting between login and the deposit form, checked once, cleared once, forgotten. That model is wrong for two reasons. It adds a step every player has to pass through even though the vast majority will never come near a threshold, and it decouples the check from the thing it's actually assessing, which is a specific deposit at a specific moment, not a player's general fitness to gamble.

The better model, and the one the payments side of this industry has already converged on, is to attach the check to the deposit event itself. Yaspa's analysis makes the point plainly: a check that rides on an in-progress deposit feels like part of the transaction, because it is part of the transaction. The player has already committed to paying; the system briefly holds that specific payment while a CRA lookup runs in the background, then either releases it or routes it into a review path. Nothing about the rest of the session changes.

This matters for your build plan in a concrete way. If the FRA is a pre-deposit gate, you're building a new screen, a new routing decision in the navigation, and a new reason for a player to abandon before they've even reached checkout. If the FRA is attached to the deposit event, you're extending your existing payment state machine with one intermediate state and a callback from your CRA integration. The second is a smaller build, a smaller QA surface, and a UX that doesn't add friction where none needs to exist.

It also changes what "done" looks like for the ticket. A pre-deposit gate is a UI project: design the screen, wire the routing, ship it. A deposit-attached check is a payments project: it touches your wallet or transaction ledger, your callback handling from the CRA provider, your retry and timeout logic, and your reconciliation between what the player tried to deposit and what actually landed. If your operator runs a single wallet across casino and sportsbook, that ledger complexity is already a live concern, and the FRA state needs to sit inside it cleanly rather than as a bolt-on that only one vertical's checkout path knows about.

The sequencing decision, in short, is not a detail to leave to whichever team happens to pick up the ticket. It's the decision that determines whether this ships as payments work extending an existing state machine, or as payments work plus a new pre-checkout screen that most players never needed and that adds a measurable drop-off point to a funnel that didn't have one before.

What state is the account in while the CRA lookup runs?

The account itself does not change state at all. Login still works, browsing still works, existing balance and history stay visible. The only thing that changes is the specific deposit the player just submitted, and it moves through a short, predictable sequence.

1. Deposit submitted. The player confirms an amount and payment method as normal; nothing on screen signals that anything unusual is about to happen.
2. Threshold check. The system checks the submitted deposit against the age-banded rolling thresholds. Below threshold, the deposit proceeds exactly as it would without an FRA in place at all.
3. CRA lookup triggered. Above threshold, the deposit enters a held state and a lookup goes to the credit reference agency. This is the moment that needs its own status in your data model, distinct from "processing," "declined," or "failed."
4. Frictionless resolution. For the large majority of held deposits, the lookup returns with nothing to report, no document upload, no impact on the player's credit file, and the deposit releases automatically. Gambling Commission pilot data puts this at 97 percent of assessments, well ahead of the 80 percent the white paper had assumed.
5. Review routing, where needed. The small remainder routes into a light-touch or enhanced review path, a different product problem from the held-deposit state, covered in the next section.

The practical point is in step 3. Teams that skip designing a dedicated held state end up reusing whatever status their payment provider returns for "processing," the same status a slow card authorisation or a delayed bank transfer produces. Support then can't tell, at a glance, whether a stuck deposit is an FRA pause that will clear on its own or a genuine payment problem that needs escalating. That ambiguity is the single most avoidable cause of a bad player experience here, and it's fixed entirely at the data model level, before a screen gets designed.

Because resolution happens for the overwhelming majority of held deposits without any player-visible step, the interface work is smaller than it first appears: a short, honest "confirming your payment" state, with a sensible timeout and a fallback message if it runs long. The complexity lives in the state machine and the support tooling around it, not in a page a designer needs weeks on.

Tips: Set a hard timeout on the held state, even though the CRA lookup itself rarely needs one; a state that can wait indefinitely will eventually wait indefinitely, and that support ticket writes itself.

How many players actually get diverted, and what happens to them?

Not every held deposit is the same event, and treating them as one undifferentiated "verification pending" screen wastes the fact that the Commission's own pilot data splits the population into three genuinely different paths.

The first and by far the largest group never notices anything happened: the deposit was held, checked, and released, typically fast enough that a well-designed processing state covers it entirely. The second, smaller group needs a light-touch step, information the player can usually supply themselves without documents. The third and smallest group needs an enhanced, document-based review, the kind of process that takes real time and needs its own communication plan.

Path	Share	What the player experiences
Frictionless	97% of assessments	Deposit briefly held, then released automatically; no player action required
Any FRA step at all	Under 3% of active accounts	The player sees something ranging from a light-touch ask to a full review
Enhanced review	0.1% of assessments	Document-based review; the only path that meaningfully resembles a KYC upload flow

These figures come from the Gambling Commission's post-pilot analysis, which also makes an important scope point: the assessment checks financial difficulty markers such as insolvency or default records, not income or general affordability of the player's spend. That distinction matters for anyone drafting player-facing copy, because "we're checking whether you can afford this" is not what's happening, and saying so invites a fight the check was never designed to have.

The design implication is that a single generic interstitial serves the frictionless path fine and badly under-serves the other two. The light-touch path needs a short, specific ask, confirm income source, confirm employment status, that doesn't feel like a demand for a bank statement. The enhanced review path needs the same document-upload discipline your KYC (know your customer) and AML (anti-money laundering) flows already use, because it is, functionally, the same kind of task: collect documents, track status, communicate turnaround honestly.

Building one screen for all three paths creates the worst version of each: frictionless players see a step implying more scrutiny than they're actually under, and enhanced-review players get an interface too thin for what's being asked of them. Splitting the three paths at the design stage, even though only one in a thousand deposits reaches the third, is what keeps that 0.1 percent from becoming a support and retention problem out of proportion to its size.

Why does blanket friction backfire, and what does proportionate friction look like instead?

Applying the same check to every player who crosses a number, regardless of context, is the version of this feature that pushes legitimate high-volume players toward operators who don't ask. That's the uncomfortable part of this brief: proportionate, well-designed friction protects your licence; blanket, context-blind friction can cost you the players you least want to lose.

The case for proportionality over blanket triggers is made well by operators quoted in iGaming Business's coverage of regulated UX: a check that fires identically for every player who crosses a threshold, whether it's a high-volume matched bettor with a documented income history or a first-time depositor spending well above their usual pattern, treats two very different risk profiles as the same event. Players with nothing to hide, who move a lot of money because that's simply how their play works, notice when a legitimate site starts treating a normal Tuesday like a red flag.

A threshold-only trigger is not the same thing as a proportionate one, and building only the threshold is the version of this feature most likely to need rebuilding within a year.

What proportionate friction looks like in practice is behaviour-based routing layered on top of the threshold, not instead of it. A player who reliably deposits near the threshold every week, with a stable pattern and no other risk markers, is a different case from a player whose deposit volume just tripled in 72 hours with no history to explain it. Both might cross the same raw number. Only one of them needs the same scrutiny a bonus abuse or account-takeover signal would trigger elsewhere in your risk stack, the same kind of layered, behaviour-aware thinking behind bonus abuse control after the UKGC's 10x cap.

Building that layer costs more up front than a flat threshold check. It means your risk model needs deposit history, not just a single deposit amount, and your product team needs to define what "established pattern" means in a way compliance will sign off on. But a check that reads as arbitrary to the players least likely to be the problem has a cost too: it's the friction that starts a legitimate, high-value player comparing your deposit flow to an unlicensed competitor's, and that's a comparison flat-threshold friction alone cannot win.

The honest scope note: a pure threshold trigger isn't wrong, and for a stage-one build it may be all the timeline allows. But if the roadmap only ever has room for the threshold and never for the behavioural layer on top of it, say so explicitly to whoever owns the risk model, because that gap is exactly what turns into a rebuild once account managers start hearing about players who left over it.

How should the stage-one and final thresholds shape your build plan?

Build for the final thresholds, not the stage-one ones, because the direction of travel is already public and re-architecting a held-deposit state twice costs more than building it once for the tighter numbers from the start.

Stage one, targeting the largest operators first, sets the trigger at £5,000 per 24 hours for players 25 and over and £2,500 per 24 hours for under-25s. The age-based split is confirmed by iGaming Business's coverage of the phased rollout, which also notes stage one deliberately targets the largest operators first, and that around 0.5 percent of customers are affected at this stage.

Stage	Age band	Threshold	Note
Stage one	25 and over	£5,000 per 24 hours	Largest operators first
Stage one	Under 25	£2,500 per 24 hours	Same rolling 24-hour window
Final stage (signalled)	25 and over	£1,000 and £3,000	Two tiers, consistent with a light-touch/enhanced split
Final stage (signalled)	Under 25	£750 and £2,000	Same two-tier pattern, lower band

The numbers are worth sitting with. Stage one's £2,500 threshold for under-25s is already a fraction of stage one's £5,000 for the over-25 band, and the final-stage figures the Commission has signalled sit lower again in both bands, in what looks like a two-tier structure rather than a single trigger point. That shape lines up with the frictionless, light-touch and enhanced paths already covered above: the final thresholds don't just move the line, they add a second one.

For a build plan, that has one clear implication: don't hardcode a single threshold value anywhere in the codebase. The threshold, the age bands, and the number of tiers all need to live in configuration your compliance team can change without a deploy, because they are going to change, on a timeline the Commission controls and your roadmap doesn't. Building the held-deposit state, the review routing, and the instrumentation around a single hardcoded stage-one number is the version of this project that gets rebuilt from the state machine up the day the final thresholds land.

This is structurally the same lesson as any staged regulatory rollout: the compliance date isn't the finish line, and treating it as one is how teams end up doing the same work twice, the same argument behind giving certification its own lane on the roadmap rather than bolting it onto whatever sprint happens to be free when the deadline gets close.

How do you instrument this so a false positive doesn't read as a broken deposit?

An FRA pause and a genuine payment failure look identical to a player staring at a spinner, and they need to look completely different in your dashboards, or the first spike in held deposits during a promotion or big sporting weekend will read as an incident instead of what it actually is: the feature working as designed.

Build these as first-class, separately reported metrics rather than sub-states of your existing payment failure tracking:

• Held-deposit rate, tracked separately from decline and failure rates, so a rise in FRA holds during a high-volume period doesn't trigger the same alert as a payment provider outage.
• Time-in-held-state, split by resolution path, because a frictionless hold that takes eight seconds and an enhanced review that takes two days are not comparable numbers and should never share a chart.
• Drop-off during the pause, measuring how many players abandon the session while a deposit is held versus how many wait it out; this is the number that tells you whether your held-deposit UI is doing its job.
• Review-path volume over time, reported by tier rather than as one aggregate "FRA events" number, so a shift in the mix, more enhanced reviews than usual, for instance, is visible as a pattern rather than buried in a total.
• False-positive signal, built from cases where a held deposit resolved frictionlessly but the player contacted support anyway, which tells you your held-state UI, not your compliance logic, needs work.

The point of separating these from standard payment monitoring isn't just cleaner dashboards. It's that whoever is on call needs to look at a spike and know, in seconds, whether it's a compliance event, expected and self-resolving, or a payments incident that needs escalation. Collapsing the two into one alert stream guarantees on-call misreads one as the other, in whichever direction costs more that week.

Tips: Ship the held-deposit and false-positive metrics before you ship the feature itself; retrofitting observability after the first live incident means guessing at data you never captured.

If your team doesn't have this instrumentation layer built yet, it's the same kind of architecture and analytics work covered under product and architecture consulting, and it's worth scoping before the FRA ships rather than after the first false alarm.

What do support and live ops need in place before this ships?

Shipping the held-deposit state and the review routing is only half the project. The other half is making sure the humans around the feature, support agents and whoever owns CRM and retention messaging, know what they're looking at before a player calls in confused about a deposit that hasn't cleared.

Before this goes live, make sure the following are in place:

• A support macro for the held state, written in plain language a first-line agent can send without escalating, explaining that the deposit is being confirmed and giving an honest expected timeframe rather than a vague "please wait."
• A separate macro for enhanced review, since that path involves documents and real turnaround time, and conflating it with the frictionless macro sets an expectation support then has to walk back.
• CRM suppression on held accounts, so a retention email or deposit-bonus push doesn't land in a player's inbox while their last deposit is sitting in review; that collision reads as the company not knowing what it just did to the player, which is worse than the pause itself.
• A rollback switch treated as seriously as any other live-ops flag, not a config value nobody remembers exists. If the CRA integration degrades or the review queue backs up, whoever's on call needs a fast, tested way to widen thresholds or pause enhanced routing without a deploy.
• A clear owner for the review queue, so enhanced-review cases don't sit unassigned; the Commission's own numbers show this queue is small, which makes it easy to under-resource precisely because it rarely comes up.

That rollback switch deserves the same discipline behind feature flags and what actually counts as a minor update: a flag that changes compliance behaviour, even one that's off 99.9 percent of the time, is not a minor toggle, and it needs the testing, audit trail, and sign-off that any change to a regulated flow requires.

None of this is compliance theatre. It's the difference between an FRA rollout support can operate calmly and one where every held deposit becomes an escalation because nobody outside engineering knew the feature existed until a player complained about it.

Frequently asked questions

What is a UKGC Financial Risk Assessment (FRA)? A Financial Risk Assessment (FRA) is a UKGC requirement that checks a player's deposit activity against financial difficulty markers, such as insolvency or default records held by a credit reference agency (CRA), rather than their income or general ability to afford their spend. It triggers when deposits cross age-banded thresholds within a rolling period, and for the large majority of players it resolves automatically without any document request.

When do the stage-one FRA thresholds apply, and to whom? Stage one applies £5,000 per 24 hours for players aged 25 and over and £2,500 per 24 hours for under-25s, and it targets the largest operators first before extending further down the market. Around 0.5 percent of customers are affected at this stage.

Does an FRA check affect a player's credit score? No. The Commission's own definition of a frictionless check is explicit that it carries no credit score impact and requires no documents from the player. The lookup checks for financial difficulty markers, not creditworthiness in the sense a lender would use it.

What percentage of players actually get diverted to a full financial risk assessment? Gambling Commission pilot data shows 97 percent of assessments were frictionless, under 3 percent of active accounts triggered any step at all, and only 0.1 percent needed a full, document-based enhanced review.

Should the deposit be blocked while the FRA check runs? Only the specific deposit that crosses the threshold is held, not the account. Everything else, login, browsing, existing balance, keeps working normally while the CRA lookup runs, and for the vast majority of players the hold resolves before it's ever noticeable.

What happens to your build when the UKGC lowers the thresholds further? If you've built the threshold and age bands as configuration rather than hardcoded values, and built the held-deposit state around a two-tier review model rather than a single pass/fail check, a lower threshold is a config change. If you've hardcoded stage-one numbers, it's a rebuild of the state machine, which is the outcome worth designing against now.

Sources

• Gambling Commission
• iGaming Business
• Gambling Commission
• Yaspa
• iGaming Business

Recommended

• Single Wallet for Casino and Sportsbook: What It Costs
• Bonus Abuse Control After the UKGC's 10x Cap
• Certification Needs Its Own Lane on Your Roadmap
• Feature Flags Don't Make an Update Minor