Technical Due Diligence for iGaming Platforms: What to Verify Before a Deal

A polished demo tells you that a platform can present a successful journey. Technical due diligence asks whether the buyer can own, operate and change that platform after the transaction, and what evidence supports the answer. For iGaming, the most consequential surprises often sit behind the interface: incomplete money records, a provider account that cannot move, a deployment only one person understands, or backups that nobody has restored.

This guide is for an investment lead, acquiring CTO or operator reviewing a target. The useful output is a bounded assessment of the asset, its operating dependencies and the cost of resolving material risks. It should help the decision team distinguish a condition that must be resolved before closing from work that can be funded after closing, and from uncertainty that still needs investigation.

Define the deal and the boundary of the review

Start with the proposed transaction. Buying a company, buying source code and licensing a hosted platform give you different assets and responsibilities. Record the entities, brands, jurisdictions, product modules, repositories, environments, data sets and supplier relationships included in the review. Identify what remains with the seller. A wallet owned by a separate group company is a different dependency from a wallet included in the acquisition.

Translate the investment thesis into questions that can be tested. If the plan depends on launching another brand, examine tenant separation and the contractual right to launch it. If it depends on replacing a supplier, trace that supplier's data, state and operating role. Appoint a technical review owner; a fractional CTO can fill that role where the buyer lacks an internal lead, provided responsibility and potential conflicts are clear.

Agree access and test boundaries before collecting evidence. Use approved, read-only access where possible; minimise player data, redact secrets and control retention of copied material. Destructive tests, payment attempts and recovery exercises need explicitly agreed environments and operational safeguards. A data-room invitation does not authorise experimenting on live player accounts.

• Supplied: a claim or document from management, not yet corroborated.
• Observed: behaviour or records inspected directly, with the environment and sample recorded.
• Verified within scope: a claim tested against agreed evidence and acceptance criteria.
• Not tested: access, time or dependencies prevented a conclusion.

Keep an evidence index with dates, versions, the period reviewed, sampling choices and limitations. A missing record is a review limitation or control concern to investigate; it is not proof that every transaction is wrong. Equally, an unanswered question is not a clean bill of health.

Follow money through records, including the awkward cases

Choose a small set of journeys because they expose different state transitions, not merely because they are easy to demonstrate. Include a deposit, a casino round or sports bet, a withdrawal, a reversal or settlement correction, and an operation whose provider response was delayed. Walk each one from the player request through internal records to the external provider's record. Explain each system's role using the platform's core modules, then inspect the actual implementation.

For each sample, identify the business operation, external reference, internal postings, currency, restricted funds, timestamps and final state. Check how a duplicate callback is distinguished from a separate legitimate operation, and what happens when the system cannot yet establish the external result. A successful HTTP response or a correct balance on one screen does not establish that the money history can be reconstructed.

Reconciliation should explain differences between internal and external records for an agreed population and cut-off. Separate genuine mismatches from timing differences, fees and currency treatment; record pending cases, their age and the owner of resolution. Ask whether operations can quantify unexplained differences and correct them through an auditable process. Do not demand that every asynchronous system has identical totals at every instant.

Consider this hypothetical finding: the withdrawal screen shows a completed payout, but the reviewer cannot connect it to a unique provider payment and the corresponding ledger entries. The problem is not cosmetic. It leaves the buyer unable to establish whether that payment happened once and how it affected funds. Record which records could not be linked and whether the gap may be in the system, the extract or the access provided. Request wider evidence before extending the conclusion to the entire wallet.

Connect the source code to the system that actually runs

Map the critical paths before judging the architectural style. Locate the authority for balances, bet status, player eligibility, provider state and administrative actions. Identify shared databases, synchronous dependencies and background workers that can block those paths. A monolith with understandable boundaries may be easier to acquire than a distributed system whose financial state depends on undocumented conventions. The platform architecture review should explain those dependencies, rather than reward a fashionable diagram.

Then connect repository access to the deployed asset. Select an approved commit, inspect its build inputs and pipeline, and build in an isolated environment. Compare the resulting release information with deployment manifests, artifact identifiers and configuration records for the system under review. Record required external services and credentials without copying secrets into the report. Do not assume that owning a repository means you can deploy the current product.

Inspect dependency inventories, including transitive packages and commercial components. NIST's SBOM guidance describes a software bill of materials as a record of components and their relationships, complementary to vulnerability management. Check which build an inventory represents and what it omits; a package list does not establish licensing rights or eliminate security risk.

Review critical implementation and tests together: wallet transitions, permission checks, settlement corrections and recovery paths deserve more attention than an aggregate test-coverage percentage. Ask who owns the code, whether contributor assignments and third-party licences support the proposed use, and which cloud accounts, registries, domains and signing keys the operating model requires. Have legal specialists assess rights and transfer terms. Technical access can demonstrate possession; it cannot by itself establish ownership.

Check security and regulatory dependencies in context

Start with actions that could expose player data, move funds or alter a result. Trace who can approve payouts, change settlement inputs, impersonate support users and modify permissions. Review separation of roles, authentication of provider messages, replay handling, secret management and tenant boundaries. An authorised test should include denied actions as well as permitted ones: can an administrator for one brand reach another brand's player or payment?

Use the security architecture review to connect controls to these paths. Examine the scope, version, date and unresolved findings of prior penetration tests; relate significant later changes to that scope. NIST's final SSDF 1.1 provides a framework for secure development practices. Use it to organise evidence about how software is built and maintained, rather than treat it as a certification of this platform.

Keep regulatory dependencies tied to the relevant entity, activity, jurisdiction and software version. Verify what a supplied licence, test report or certificate actually covers and which changes require specialist review. For example, the Great Britain Gambling Commission has a change-of-corporate-control procedure for operating-licence holders that are companies limited by shares. An operational platform alone does not establish that the business can continue under a new ownership arrangement.

The technical reviewer should identify mismatched versions, missing evidence and operating dependencies, then send legal interpretation and transaction-specific obligations to qualified advisers. Do not turn one jurisdiction's procedure into a global rule, or treat an old certificate as proof that every current integration is compliant.

Rehearse recovery and challenge the capacity claim

A backup job marked successful is evidence that a job ran. Ask for evidence that the platform can be restored. In an agreed isolated environment, restore the required databases, application configuration, key access and processing checkpoints. Check that the restored application can account for balances, outstanding reservations and provider operations around the recovery cut-off. Prevent replayed jobs from issuing real payments or contacting live players.

Record both the permitted loss of recent data, expressed as a recovery point objective, and the target time to resume the required service, expressed as a recovery time objective. Compare those targets with a measured exercise that includes dependencies and operator decisions. A database restoration time is not the same as a verified return to financial operations. If an exercise cannot be run, inspect previous evidence and mark the untested parts explicitly.

For capacity, request the assumptions behind the claim: workload mix, concurrency, transaction rates, data volume, tenant distribution, infrastructure and supplier limits. Compare a representative load test with current operating telemetry. Inspect tail latency and failed or delayed work, including the queue backlog after a peak. A headline request rate says little if it measures cached pages while settlement workers fall behind.

Review incidents and on-call practice alongside the measurements. Who can stop a harmful release, reconcile unknown operations and recover when a provider is unavailable? Select a consequential incident and follow its corrective actions into deployed changes or tested procedures. An excellent dashboard does not substitute for an operator who knows which state is safe to resume.

Find out whether people and providers survive the handover

Make a dependency map for the first day after closing. For each payment, gaming, sportsbook, identity or hosting provider, record the contracting entity, account ownership, data access, termination terms and any relevant assignment or change-of-control conditions. Confirm interpretations with the commercial and legal teams. These terms vary; continued API access today is not proof of continued rights after the transaction.

Use the provider evaluation guide to examine service boundaries, failure behaviour and exit requirements. Check whether the buyer can retrieve the records needed for reconciliation and obtain operational support. A supplier's uptime promise does not measure the availability of the buyer's complete deposit or bet journey.

Ask people to walk through real work: a recent product change from request to deployment, a production incident and a provider reconciliation. Compare the walkthrough with records. Identify undocumented decisions, privileged access held by one person and skills the buyer must retain or replace. Avoid equating headcount, commit counts or the number of tickets closed with an ability to maintain the system.

The handover plan needs named roles, access transfer, documentation and supervised practice. Include the work that remains with the seller and the conditions for ending that support. Where continuity depends on a specific person or supplier, state the dependency and the fallback, rather than assume goodwill will cover the gap.

Turn findings into decisions and work that can be verified

Each material finding should explain what could happen, why the evidence supports it and how much of the platform was examined. Keep impact separate from confidence: an untested recovery path may have high potential impact but little direct evidence of failure. A reproducible defect has stronger evidence, but its importance still depends on the affected money, users and operating controls.

• Claim and scope: the behaviour reviewed, the affected version and the sample or population.
• Evidence and limits: what was observed, what corroborates it and what remains unknown.
• Consequence: the plausible financial, operational or security effect, with assumptions stated.
• Action and closure: containment, the accountable owner, the proposed fix and the evidence required to close the finding.

For the hypothetical withdrawal finding, closure might require linking the original samples, resolving the unexplained records, testing duplicate and unknown-result handling, and demonstrating the reconciliation procedure. A promise to add logging would not answer the original question. Allow the seller to correct factual errors and supply contrary evidence; record unresolved disagreements.

Group decisions into matters to resolve before closing, funded post-close work, risks explicitly accepted by the decision team, and questions that require more investigation. The buyer and its advisers set transaction conditions. The reviewer supplies the technical evidence and consequences, rather than mechanically convert a severity label into a purchase-price adjustment.

Build remediation estimates from defined work, dependencies, assumptions and verification effort. The GAO Cost Estimating and Assessment Guide supports that estimating discipline; it is not an iGaming price benchmark. Explain ranges and uncertainty, including supplier lead times, migration and retaining essential staff. Date the report and identify changes that would invalidate its conclusions, such as a new release, supplier replacement or materially different transaction scope.

For follow-through, use the guide on when an iGaming company needs a fractional CTO to define technical leadership after the review, and the guide on integrating a dedicated product team to plan delivery and knowledge transfer. The review is useful when its evidence survives the handover and its findings become owned, verifiable work.

• A bounded evidence pack: included assets, versions, access limitations, sampled journeys and an index linking conclusions to records.
• A critical-path assessment: money traceability, permission boundaries, deployed-source linkage, recovery and capacity, with tested and untested parts distinguished.
• A continuity map: people, accounts, provider contracts, rights and operating dependencies that the buyer must retain, transfer or replace.
• A decision and remediation register: consequences, confidence, owners, dependencies, estimated work and explicit evidence for closing each material finding.