Automating Regulatory Compliance: How to Integrate Veriff & Sumsub into Legacy Stacks

If you run an iGaming operation on a ten-year-old backend, you’re probably stuck in the most annoying middle ground imaginable.

Regulators expect real-time risk controls, video KYC, sanctions screening, device checks, and flawless audit trails. Players expect one-minute onboarding from a phone. Meanwhile your core platform is a mix of old PHP, stored procedures, and “don’t touch that table or payments will die.”

That’s exactly where modern KYC vendors like Veriff and Sumsub live: they give you sleek, automated KYC compliance out of the box, but your stack wasn’t built with their APIs in mind.

The good news: you don’t have to rebuild everything to plug them in. You just need to bolt a modern KYC layer onto your legacy stack in a way that your regulators, your players, and your dev team can all live with.

That’s what this piece is about.

Why automated KYC compliance is now a core product feature

For iGaming, KYC is no longer an “operations thing” that happens in the background.

Regulators are tightening:

• Strict verification before deposits or withdrawals
• Source of funds checks on higher tiers
• Per-GEO rules for what constitutes “verified”
• Sanctions and PEP screening expectations
• Fast reaction to self-exclusion and fraud signals

Players are less patient than ever:

• They abandon at the first sign of friction
• They expect mobile-first, camera-based onboarding
• They don’t want to email PDFs into a support void

And from the business side, manual KYC review:

• Doesn’t scale
• Is error-prone
• Is impossible to audit properly at volume

Automated KYC compliance is basically the only sane answer: you let tools like Veriff and Sumsub do what they’re good at, while your platform focuses on player wallets, game logic, bonuses, and reporting.

The trick is wiring it all together without rewriting the core.

The reality: modern KYC tools, very old backends

Here’s the pattern I keep seeing in iGaming:

• Core platform: monolith, built years ago, maybe half-documented, tightly coupled to one big database.
• KYC today: manual uploads, back-office staff eyeballing documents, maybe a homegrown “document review” page.
• New requirement: integrate Veriff or Sumsub, handle callbacks, drive player status, and make regulators happy.

Veriff and Sumsub give you:

• Hosted KYC flows (web + mobile SDKs)
• Document recognition and liveness checks
• AML watchlist screening
• Webhooks for status updates
• Nice dashboards for manual review

Your legacy stack gives you:

• A fragile registration and wallet flow
• Player tables nobody wants to touch
• Limited or no event system
• Tight coupling between “verified” and every other aspect of the platform

So the question becomes: where do you plug modern APIs into a system that was never designed for them?

The answer is almost always: in a thin, purpose-built integration layer that sits between your old backend and the KYC vendors.

Step 1: Map the KYC journey before you touch any APIs

Before a single line of integration work, you need a clear picture of where KYC actually lives in your player journey.

A simple mapping makes everything easier:

Stage	Example trigger	What KYC must do	Where it runs
Registration	New account created	Optional or basic ID validation (by GEO)	Veriff / Sumsub
First deposit	Player tries to deposit over threshold	Full KYC, face + document	Veriff / Sumsub
High-risk behavior	Multiple cards, VPN, high bets	Enhanced checks, manual review	Sumsub / Veriff + staff
Withdrawal	Payout above X, or to new method	Verify identity + payment method ownership	KYC + payment checks
Ongoing monitoring	Sanctions updates, PEP list changes	Re-screen existing players as needed	Vendor’s AML engine

Two things matter most:

1. What conditions in your legacy system should trigger KYC?
2. What statuses or flags from Veriff/Sumsub must feed back into your player record?

Once you have that, you can design the integration as a workflow instead of a pile of API calls.

Step 2: Introduce a KYC orchestration layer

You do not want your old backend calling Veriff or Sumsub directly from random parts of the code. That’s how you end up with:

• Hard-coded vendor logic everywhere
• No clean way to switch providers later
• A nightmare to debug when something breaks

Instead, you introduce a KYC orchestration layer – a small service (or module, if you can’t do services yet) that:

• Receives “KYC needed” events from the legacy platform
• Decides which provider to call based on GEO, risk, and rules
• Starts verification sessions with Veriff / Sumsub
• Listens for webhooks from those providers
• Updates the legacy platform with clean, simple statuses

Think of it as a translator and traffic cop between “old world” and “new world.”

What the orchestration layer owns

Component	Responsibility
KYC rules engine	Decide when and what level of KYC is required
Provider router	Choose Veriff or Sumsub based on GEO/risk
Session manager	Create and track verification sessions
Webhook handler	Receive status updates from both providers
Status normalizer	Convert provider codes to your internal statuses
Audit logger	Store decisions, timestamps, and reference IDs

Your old backend never has to know about Veriff’s status codes or Sumsub’s JSON structure. It just deals in a few internal KYC states like pending, verified, failed, and maybe enhanced_review.

Step 3: Connecting a legacy backend to the orchestration layer

If your platform is truly “legacy,” you probably don’t have Kafka and microservices. That’s fine. You just need stable touch points.

A practical pattern looks like this:

1. Legacy backend writes a record to a simple table or sends a basic HTTP call like “KYC required for player X, scenario Y.”
2. The KYC layer picks up that request.
3. It creates a verification session with Veriff or Sumsub.
4. It returns a URL or token that the frontend can use to show the verification flow.
5. When the vendor finishes, it sends a webhook to the KYC layer.
6. The KYC layer sends a clear update back into the old backend: player_id = 123, status = verified, level = standard.

A simple request from legacy to KYC layer might look like this:

{
  "player_id": 12345,
  "scenario": "first_deposit_over_threshold",
  "country": "DE",
  "risk_score": 42
}

And a response:

{
  "kyc_session_id": "k-session-88df2d",
  "provider": "veriff",
  "verification_url": "https://magic-url-for-player",
  "status": "pending"
}

The legacy backend stores kyc_session_id and status in its own schema. That’s all it needs.

Step 4: Using Veriff in a legacy environment

Let’s walk through a concrete example using Veriff in this orchestrated model.

1. Trigger from legacy backend

Player from a regulated GEO hits the deposit button for 500 EUR. Your legacy code checks a simple rule and decides: KYC required.

Instead of trying to talk to Veriff directly, it sends:

{
  "player_id": 12345,
  "scenario": "high_value_deposit",
  "country": "ES"
}

to your KYC orchestration API.

2. Orchestration layer creates Veriff session

The orchestration layer choses Veriff (say, for EU flows) and calls Veriff’s API to create a session with the needed configuration (documents, liveness, etc.).

Veriff responds with a session ID and a URL or token.

The orchestration layer passes that back to the legacy backend, which then:

• Stores kyc_session_id
• Exposes the URL to the frontend so the player can complete the flow

No direct Veriff calls from the legacy code, no vendor-specific logic scattered around.

3. Webhook from Veriff

When the player finishes or abandons, Veriff sends a webhook to your KYC orchestration endpoint.

Webhook payload example (simplified):

{
  "sessionId": "k-session-88df2d",
  "status": "approved",
  "reason": null
}

The orchestration layer:

• Maps Veriff’s approved to your internal "verified_standard"
• Logs all relevant details for audits
• Calls back into the legacy backend with a very simple message:

{
  "kyc_session_id": "k-session-88df2d",
  "player_id": 12345,
  "status": "verified_standard"
}

Your old platform just flips player.kyc_status and allows the deposit to proceed. It does not need to understand the full Veriff universe.

Step 5: Integrating Sumsub and supporting multiple vendors

Most serious operators don’t want to be married to one KYC provider forever. GEO rules change, pricing changes, coverage changes. Sometimes one provider is simply better for a region or document set.

That’s where the orchestration layer really earns its keep.

You can define routing rules like:

Condition	Provider
Country in EU, normal risk	Veriff
Country in LATAM, normal risk	Sumsub
VIP tier, enhanced due diligence	Sumsub
Fallback when primary fails	Other

To the legacy backend, nothing changes. It still says:

{
  "player_id": 12345,
  "scenario": "registration",
  "country": "BR"
}

The KYC layer decides “BR goes to Sumsub,” creates the session, and sends back:

{
  "kyc_session_id": "sumsub-44c2",
  "provider": "sumsub",
  "verification_url": "https://sumsub-url",
  "status": "pending"
}

When Sumsub calls back on completion, you normalize their statuses exactly the same way:

• GREEN → verified_standard
• RED → failed
• YELLOW → enhanced_review

So the legacy backend always sees a consistent internal vocabulary. Veriff vs Sumsub is an implementation detail hidden behind the orchestration layer.

Step 6: Handling timeouts, manual review, and failed checks

Real life is messy. Players abandon flows, documents are blurry, networks glitch, and some cases truly require human judgment.

Your automated KYC compliance design has to account for that, or operations will drown.

A useful state model looks like this:

Internal status	Meaning	Typical action
pending	KYC session created, player not finished	Allow limited actions, nudge player to complete
in_review	Provider or internal staff reviewing	Freeze risky actions (large deposits/withdrawals)
verified_standard	Normal KYC passed	Full access allowed for that jurisdiction’s rules
verified_enhanced	Extra checks passed (source of funds, etc.)	Higher limits allowed
failed	KYC failed (fraud, mismatch, non-cooperation)	Lock wallet, notify risk/compliance
expired	Session expired without completion	Restrict until player re-starts KYC

The orchestration layer manages these transitions, not the legacy backend. The old system just applies business rules based on whatever status it sees.

For example:

• pending at registration: allow low deposits, no withdrawals
• pending at high deposit: force KYC completion before accepting
• in_review: pause withdrawals and certain bonuses
• failed: hard block and flag account for compliance

This split keeps your old code relatively simple while your compliance logic shifts into a place where it’s easier to evolve.

Step 7: Keeping regulators happy – logs and audit trails

Regulators don’t just care that you “do KYC.” They care that you can prove it, explain it, and reproduce it on request.

Your automated KYC compliance setup should automatically generate the audit trail as a side effect of normal operation.

At a minimum, you want your KYC orchestration layer to log:

Field	Purpose
player_id	Who this decision belongs to
kyc_session_id	Reference with Veriff/Sumsub
provider	Veriff or Sumsub
scenario	Why KYC was triggered
request_timestamp	When you asked for KYC
decision_timestamp	When you got a final answer
final_status	Internal status after mapping
country / GEO	Jurisdiction context
risk_flags	Any risk indicators in play
operator_overrides	If human changed anything

When a regulator asks “why did you allow this VIP to withdraw 20k on that day?”, you want to be able to show:

• The KYC was triggered automatically when they crossed threshold X
• The check passed through Veriff or Sumsub with certain outcomes
• Risk rules and limits were enforced based on those outcomes

The legacy backend doesn’t need to hold all that detail. The orchestration layer can store it in a more modern form (separate DB, even a warehouse), as long as IDs align.

Step 8: Integrating without breaking your existing platform

This is usually the scariest part for operators: how to integrate Veriff and Sumsub without accidentally blocking deposits for two days.

A few pragmatic steps:

• Start with one GEO or one cohort. For example, new registrations in one regulated market.
• Wire in the orchestration layer and feature-flag its use.
• Keep your existing manual KYC path as a backup for a while.
• Shadow mode: for a short time, run automated KYC in parallel with manual checks to validate outcomes.
• Only once you see stability do you expand to more GEOs, higher limits, and more scenarios.

From the legacy backend’s perspective, it can literally be as small as:

• “When this condition is true, call the KYC API and use its answer. Otherwise, do what we did before.”

You grow from there instead of flipping the entire company to a brand-new process overnight.

What “good” looks like when it’s working?

When automated KYC compliance is integrated properly into a legacy iGaming stack, you see clear patterns:

From operations:

• Fewer manual KYC tickets per new player
• Faster handling of edge cases (providers surface good reasons)
• Clearer separation between compliance work and support work

From players:

• Shorter verification times
• Less confusion around “what happens next”
• Fewer abandoned registrations because of clunky document upload flows

From compliance and management:

• Crisp dashboards of KYC statuses by GEO, product, and tier
• Readable audit logs when regulators ask questions
• Ability to adjust rules across markets without editing old core code

And from tech:

• Legacy backend remains mostly untouched where it matters
• Vendor routing can change without rewrites
• You can add new providers or scenarios by extending the orchestration layer, not rebuilding the platform

In other words, Veriff and Sumsub become plug-ins to your compliance workflow, not invasive surgery on your older stack.

Underneath all the acronyms and vendor promises, that’s the real job here: turn automated KYC compliance into a predictable, trackable, API-driven workflow that wraps around your legacy system instead of fighting it.

The only real question is whether you want your KYC layer to feel like a bolt-on band-aid… or a quiet piece of infrastructure that just keeps you compliant, day after day, while your core platform keeps doing what it’s always done best.