iGaming platform vendor due diligence is the verification step between “we like this vendor” and “we’ll sign a five-year contract with this vendor”. Done well, it surfaces risks that change the recommendation or the contract terms. Done badly, it produces post-signing surprises that cost millions to resolve. This guide is the structured framework Jadex sees produce reliable verification: four domains, specific activities, clear red flags, and the questions vendors who pass real due diligence answer honestly.

Why due diligence is the most under-invested stage

By the time an operator reaches due diligence, they’ve typically spent 3-4 months on the selection process and emotionally committed to a preferred vendor. The shortlisted vendors all passed RFP scrutiny, scored well on the evaluation rubric, and demonstrated convincingly in panels. Operators routinely compress due diligence to 2-3 weeks under commercial pressure, treating it as a formality before the “real” negotiation begins.

This is structurally wrong. Due diligence is where vendor claims get verified against reality. A vendor who scores 4.2 on the evaluation rubric may have material risks that didn’t surface in pitches and proposals — financial fragility, regulatory exposure, customer concentration, technical debt the vendor downplayed. Operators who skip or compress due diligence sign with the vendor who pitched best, not the vendor who fits best.

A proper due diligence cycle takes 4-6 weeks for each shortlisted vendor and runs in parallel where possible. The selection context for where this sits in the overall process is covered in our how to choose a casino software provider guide, and the criteria that fed the shortlist sit in our casino platform evaluation criteria guide.

Domain 1: Technical due diligence

Technical due diligence verifies the platform delivers what the vendor claimed during evaluation. Vendor RFP responses and demos are necessarily curated. Technical due diligence opens the bonnet.

Architecture review. Sit with the vendor’s engineering team — not their sales engineers — for a detailed walkthrough of the platform architecture. Genuine questions: how does the wallet service handle concurrent transactions across jurisdictions? How is the event-driven layer implemented? What’s the deployment architecture for regional data residency? Sales engineers can answer the script. Engineering teams can answer the follow-up.

Integration testing. A sandbox environment with realistic data and the operator’s actual integration scope — not the vendor’s demo environment. Test the integrations that matter (CRM, payment, KYC, BI tooling) under conditions resembling production. Document where integration is straightforward and where the vendor’s claimed flexibility hits actual constraints.

Security audit. Independent security assessment of the platform’s posture, ideally by the operator’s internal security team or a third-party firm. Verify penetration testing cadence, vulnerability management practices, security incident history. ISO 27001 certification is the baseline expectation for serious platform vendors.

Performance verification. Load testing against the operator’s projected traffic with peak scenarios modelled (jackpot events, sportsbook major events, promotional pushes). Latency under load tells a different story than latency at normal volumes. Several platform vendors look acceptable at 10x normal load and fall over at 100x.

Code quality assessment. Where the operator has rights to source code review (often only granted under NDA at this stage), sample the codebase. Quality signals: test coverage, documentation completeness, deprecation hygiene, third-party dependency management. Operators without engineering depth can hire a code-review firm for a focused assessment.

Domain 2: Regulatory due diligence

Regulatory due diligence verifies the vendor’s compliance posture across the operator’s target jurisdictions. Critical for operators under UKGC, MGA, Gibraltar GGC, or regulated US state frameworks where platform compliance failures create direct licensing risk for the operator.

Certification verification. Request original certification documentation, not vendor summaries. Verify certifications are current, valid in target jurisdictions, and cover the specific platform components the operator will use. Certifications often have scope limitations vendors gloss over.

Audit history review. The vendor’s regulatory audit findings over the past 3-5 years. Independent audit firms, regulator findings, internal audit findings. Patterns matter more than individual findings — a vendor with recurring AML or RG findings has structural issues.

Compliance change management assessment. When UKGC publishes a new RG requirement, how does it propagate through the vendor’s platform to operator deployments? Configuration-driven (fast, low-risk) or code-driven (slower, requires deployment)? How quickly have past regulatory changes been absorbed? Critical context covered in our responsible gambling technology trends guide.

Jurisdictional capability verification. If the operator plans to expand into new jurisdictions during the contract term, verify the vendor’s roadmap for those jurisdictions and recent track record entering new markets. Promises of “we’ll be certified in market X by quarter Y” need history of similar promises being met.

Data protection and residency. GDPR compliance posture, data residency capabilities, breach notification procedures, data portability rights. Particularly important for operators in multiple EU jurisdictions or under California’s CCPA equivalents.

Domain 3: Financial due diligence

Financial due diligence assesses whether the vendor will exist in its current form over the contract term. Most established platform vendors are commercially stable, but stability isn’t universal.

Financial position review. Audited financials for the past 3-5 years where available. Revenue trajectory, profitability or path to profitability, debt position, cash runway. Vendors typically share this under NDA in late-stage due diligence.

Customer concentration. What percentage of vendor revenue comes from the top three customers? Top ten? A vendor where a single customer represents 30%+ of revenue has structural risk — the customer’s departure (or commercial dispute) materially affects vendor viability.

Ownership stability. Ownership history over the past 5 years, recent M&A activity, expected M&A activity, leadership tenure. Ownership changes during a contract term often trigger commercial repricing, roadmap shifts, or service-level degradation.

Contract terms review. Independent legal review of the proposed contract, focusing on early termination, IP and data ownership, source code escrow, SLA structure with meaningful penalties, multi-jurisdiction expansion terms, and assignment provisions if the vendor is acquired.

Insurance and liability. Vendor’s professional indemnity insurance limits, cyber liability coverage, business interruption coverage. These should align with the operator’s commercial scale, not vendor convenience.

Domain 4: Reference verification

Reference verification is where the gap between vendor positioning and operational reality most consistently surfaces. Done properly, it changes recommendations.

Vendor-supplied references. Speak to 3-5 current customers the vendor provides as references. Useful but inherently filtered — vendors offer happy customers. Ask specific questions: where did the implementation surprise you? Where does the platform constrain you? How responsive is support when something breaks? What would you do differently?

Migrated-away references. The most valuable reference type and the hardest to find. Operators who have migrated away from the vendor’s platform. Vendors don’t provide these. Operators find them through industry networks, peer conversations at conferences (SBC Events, ICE, G2E), and direct LinkedIn outreach to former customers. Even a brief conversation produces information worth more than five vendor-supplied references.

Active sandbox testing. The operator’s actual technical team using the platform sandbox for 2-3 weeks with realistic workflows. Tests that the platform works for the operator’s specific use cases, not generic demonstrations. Surfaces operational friction that vendor demos hide.

Working session observation. Spend a day in the vendor’s office observing how their teams actually work. How is engineering organised? How do support tickets flow? What’s the cultural temperature? Working session observation reveals organisational health that documentation cannot.

Peer operator conversations. Informal conversations with operators in similar profile who have evaluated or used the vendor. Industry networks are surprisingly open to these conversations — most operators have been on the receiving end of bad vendor choices and willingly share what they learned.

Red flags surfaced during due diligence

Specific findings that should change the recommendation or contract terms:

Architectural rigidity beyond claimed. The vendor positions as “flexible and customisable” but technical due diligence reveals that key customisations require vendor engineering time the operator must purchase. Negotiate explicit customisation rights and pricing into contract or downgrade the recommendation.

Compliance theatre rather than substance. The vendor has certifications but the underlying processes show patchy execution. Recurring audit findings, slow change management, regulatory exposure the vendor downplays. Material risk — escalate.

Customer concentration above 25%. A vendor where one customer represents over a quarter of revenue is structurally fragile. Either negotiate explicit business continuity provisions or downgrade recommendation.

Migrated-away reference patterns. Multiple migrated-away customers citing the same complaint (poor support escalation, slow roadmap, contract rigidity) suggest structural issues rather than individual customer disputes. Material — change recommendation if pattern is consistent.

Engineering team turnover. High recent turnover in the vendor’s engineering or platform teams signals organisational health issues. Verify through LinkedIn and through peer conversations.

Aggressive contract terms despite stated flexibility. Vendor states “we’re flexible on contract terms” then proposes terms heavily favouring the vendor. Either the flexibility is real (negotiate) or the flexibility is rhetorical (downgrade).

Translating findings into contract provisions

Due diligence findings should produce specific contract provisions, not generic risk acknowledgements. Examples:

• Customer concentration risk → contractual commitment to maintain certain service levels even if vendor’s largest customer departs
• Architectural rigidity → specific customisation rights with capped vendor labour costs
• Compliance change management concerns → SLA commitments on regulatory update propagation timelines
• Engineering turnover risk → key-person provisions or source code escrow with broader trigger conditions
• Ownership change risk → assignment provisions giving operator early termination rights on material ownership changes
• Performance verification concerns → SLA penalties with material commercial weight, not just service credits

The translation happens at contract negotiation (Stage 7 of selection). Due diligence findings need to be specific enough to feed contract clauses, not abstract enough to be ignored.

FAQ

What is iGaming platform vendor due diligence?

Vendor due diligence is the verification step between shortlisting and contract negotiation. It covers four domains: technical due diligence (verifying platform architecture and integration claims), regulatory due diligence (confirming compliance posture), financial due diligence (assessing vendor viability), and reference verification (validating operational claims with actual customers). Its purpose is to verify rather than evaluate — separating vendor positioning from operational reality before signing a multi-year contract.

How long should iGaming platform vendor due diligence take?

A proper due diligence cycle takes 4-6 weeks per shortlisted vendor, often running in parallel across vendors. Operators who compress to 2-3 weeks consistently produce post-signing surprises that cost more to resolve than the time saved. The cost of a bad vendor decision over 5 years dwarfs the cost of an additional month of due diligence.

What are the most useful reference customers for vendor due diligence?

Migrated-away references — customers who have left the vendor’s platform — are the most valuable reference type. Vendors don’t provide these; operators find them through industry networks, conference conversations, and LinkedIn outreach. Vendor-supplied references are useful but inherently filtered. Active sandbox testing by the operator’s own team and working session observation in the vendor’s office also produce information vendor pitches cannot.

What red flags during due diligence should change a vendor recommendation?

Six findings should change recommendations: architectural rigidity beyond what was claimed, compliance theatre (certifications without substance), customer concentration above 25%, consistent migrated-away reference complaints, recent engineering team turnover, and aggressive contract terms contradicting claimed flexibility. Individual concerns may be manageable; patterns of these findings together signal structural issues worth changing direction over.

How do due diligence findings feed into contract negotiation?

Due diligence findings should translate to specific contract provisions. Customer concentration risk becomes service-level commitments. Architectural rigidity becomes customisation rights with capped vendor labour costs. Compliance change concerns become SLA commitments on regulatory update propagation. Engineering turnover concerns become source code escrow with broader trigger conditions. Findings that don’t translate into provisions get lost in execution.

Next step

If you’re running due diligence on shortlisted casino platform vendors, speak to Jadex’s iGaming engineering team. We’ve supported operators through technical due diligence, sandbox testing, and verification activities across multiple platform vendor evaluations. See our full iGaming development capability.