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:
- What conditions in your legacy system should trigger KYC?
- 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:
- Legacy backend writes a record to a simple table or sends a basic HTTP call like “KYC required for player X, scenario Y.”
- The KYC layer picks up that request.
- It creates a verification session with Veriff or Sumsub.
- It returns a URL or token that the frontend can use to show the verification flow.
- When the vendor finishes, it sends a webhook to the KYC layer.
- 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
approvedto 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_standardRED→failedYELLOW→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:
pendingat registration: allow low deposits, no withdrawalspendingat high deposit: force KYC completion before acceptingin_review: pause withdrawals and certain bonusesfailed: 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.
