# iGaming platform RFP response matrix

Use one row per atomic requirement. Keep every ID unchanged across the supplier response, evidence, evaluation, acceptance test, and contract schedule.

## 1. Legal entities, licence route, and product scope

Establish who contracts, who supplies each module, who operates, and which authorisation supports the exact launch.

**Gate:** Do not advance a proposal with an ambiguous authorisation route or operator-of-record role.

| ID | Priority | Requirement | Buyer acceptance criterion | Supplier response | Delivery status | Product / module | Legal entity | Jurisdiction | Assumptions / dependencies | Supplier owner | Acceptance result | One-off cost | Recurring / pass-through cost | Evidence status | Evidence / record | Contract status | Contract schedule | Buyer decision |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| LG-01 | Gate | Name every contracting, supplying, hosting, support, payment, and operating legal entity in the proposed structure. | The answer uses full legal names and company identifiers, and distinguishes group brands from contracting entities. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| LG-02 | Gate | Map legal entity × product or module × jurisdiction × credential, including status, scope, source, and checked date. | Each row supports the proposed activity and exposes any product, entity, or market limitation; the buyer can verify the source independently. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| LG-03 | Gate | Identify the operator of record, licence holder, party named in player terms, holder of player funds, and owner of regulatory reporting for each market. | No responsibility is implied by the labels white-label, turnkey, managed, or licensed; every role is assigned in the responsibility schedule. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| LG-04 | Must | List buyer licences, market access, product approvals, registrations, policies, and third-party appointments that remain prerequisites to launch. | The supplier separates its deliverables from buyer and regulator dependencies, with an owner and decision date for each dependency. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| LG-05 | Must | Provide corporate-registration evidence, ownership or control details, signatory authority, and the proposed contracting chain. | The entities in the proposal, credentials, invoices, data-processing terms, and contract schedules reconcile. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| LG-06 | Must | Explain any reliance on affiliates, partners, resellers, sublicences, market-access counterparties, or third-party operating structures. | The underlying agreement, permission, duration, termination exposure, and replacement plan are disclosed for each dependency. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |

**Requested evidence**

- Regulator records or credential certificates for the named entity and product
- Corporate registry extracts and group/entity diagram
- Draft operating, responsibility, and licence-scope schedule
- Copies or scoped summaries of agreements relied on for third-party authorisation

## 2. Implementation, milestones, dependencies, and acceptance

Turn a launch estimate into a scoped delivery plan that the buyer can test, govern, and remedy.

**Gate:** Do not approve an unsupported headline launch date.

| ID | Priority | Requirement | Buyer acceptance criterion | Supplier response | Delivery status | Product / module | Legal entity | Jurisdiction | Assumptions / dependencies | Supplier owner | Acceptance result | One-off cost | Recurring / pass-through cost | Evidence status | Evidence / record | Contract status | Contract schedule | Buyer decision |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| IM-01 | Gate | Define the implementation baseline: products, markets, brands, channels, environments, integrations, data migration, custom work, and exclusions. | The delivery plan and price use the same baseline, and every excluded item has an owner or later decision point. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| IM-02 | Gate | Provide a milestone plan with deliverables, entry criteria, owners, dependencies, dates, and buyer decision deadlines. | The plan identifies the critical path and separates supplier work from buyer, regulator, content, payment, and other third-party work. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| IM-03 | Must | Include licensing, payments, game or sportsbook approvals, front end, data migration, security review, testing, training, and operational readiness in the critical path. | No launch-critical dependency sits outside the integrated plan merely because another party owns it. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| IM-04 | Gate | Define objective acceptance criteria, test data, evidence, defect severity, retest rules, and acceptance authority for each deliverable. | Payment is tied to accepted deliverables where appropriate, and silence or production use does not create accidental acceptance. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| IM-05 | Must | State the re-planning, cure, fee, service-credit, and termination consequences for supplier-caused delay or failed acceptance. | The contract distinguishes supplier delay, buyer delay, dependency delay, and mutually agreed change, with evidence and notice rules. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| IM-06 | Must | Document pilot, migration rehearsal, cutover, rollback, go/no-go authority, hypercare, and transition into business-as-usual support. | Named people own each decision, rollback is practical, and open defects have an agreed treatment before launch. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |

**Requested evidence**

- Integrated project plan and responsibility matrix
- Acceptance-test plan and example acceptance certificate
- Environment, migration, cutover, rollback, and hypercare runbooks
- Redacted delivery history for projects comparable in scope, with assumptions stated

## 3. Pricing, total cost, and pass-through fees

Compare complete economics against one scope instead of comparing unlike headline rates.

**Gate:** No commercial ranking until all proposals have been modelled on the same assumptions and three scenarios.

| ID | Priority | Requirement | Buyer acceptance criterion | Supplier response | Delivery status | Product / module | Legal entity | Jurisdiction | Assumptions / dependencies | Supplier owner | Acceptance result | One-off cost | Recurring / pass-through cost | Evidence status | Evidence / record | Contract status | Contract schedule | Buyer decision |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| PR-01 | Gate | Itemise setup, configuration, custom development, integrations, migration, platform, hosting, minimums, revenue share, usage, third-party, support, and exit charges. | Every charge has a unit, trigger, frequency, currency, tax treatment, responsible entity, and included volume or service level. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| PR-02 | Gate | Define every commercial measure, including the revenue base, deductions, netting, reporting source, dispute process, and invoice timing. | The buyer can independently reproduce a sample invoice from operational data and the contractual definitions. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| PR-03 | Must | Disclose pass-through costs, supplier mark-ups, rebates, credits, foreign-exchange rules, taxes, minimums, and third-party price-change exposure. | The contract states which changes can be passed through, what evidence is supplied, and whether the buyer receives corresponding rebates or credits. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| PR-04 | Gate | Price downside, baseline, and growth scenarios using the buyer's stated brands, markets, modules, volumes, payment mix, support, and term. | The same workbook and assumptions are used for every supplier, with one-off, recurring, variable, and contingent costs separated. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| PR-05 | Must | State out-of-scope rates, change-control pricing, indexation, tier resets, ramp periods, minimum-commitment treatment, and audit rights. | No material price adjustment can be applied without a defined formula, evidence, notice, and buyer remedy. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| PR-06 | Must | Include termination, parallel run, data export, migration assistance, knowledge transfer, account transfer, and deletion charges. | Exit costs are priced or capped before signature and feed the same total-cost model as implementation and operation. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |

**Requested evidence**

- Completed pricing workbook with all assumptions unlocked and visible
- Draft order form, fee schedule, and revenue or usage definitions
- Sample invoice and reconciliation file
- Third-party quotes or rate cards supporting material pass-through charges

## 4. SLA measurement, exclusions, remedies, and service history

Separate advertised availability from a measurable contractual commitment and observed operating evidence.

**Gate:** An uptime percentage without component scope, formula, exclusions, reporting, and remedy does not pass.

| ID | Priority | Requirement | Buyer acceptance criterion | Supplier response | Delivery status | Product / module | Legal entity | Jurisdiction | Assumptions / dependencies | Supplier owner | Acceptance result | One-off cost | Recurring / pass-through cost | Evidence status | Evidence / record | Contract status | Contract schedule | Buyer decision |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| SL-01 | Gate | Define each measured component, service boundary, formula, data source, measurement interval, reporting owner, and dispute process. | The measure covers the buyer-critical journey and cannot be satisfied while a material dependent component is unavailable. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| SL-02 | Must | State service windows, maintenance allowances, exclusions, force-majeure treatment, third-party dependencies, and degraded-service rules. | Exclusions are narrow, evidenced, time-bounded, and do not remove failures that the supplier can control or mitigate. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| SL-03 | Gate | Define severity by user and business impact, with acknowledgement, update, workaround, restoration, resolution, and root-cause targets. | Severity cannot be unilaterally downgraded without evidence and the response clock is clear across support hours and time zones. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| SL-04 | Must | Set recovery point and recovery time objectives for each critical service, plus backup, failover, restoration, and disaster-recovery test obligations. | The objectives match the architecture and the supplier supplies dated test results, findings, remediation, and next-test dates. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| SL-05 | Gate | Set credits, fee-at-risk, cure plans, escalation, and termination rights for missed targets, repeated breach, or a material incident. | Remedies are claimable from supplier reporting, are not the sole remedy for severe failures, and address patterns as well as single months. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| SL-06 | Must | Provide a defined-period service history: measured results, severity-one and severity-two incidents, impact, cause, restoration, and corrective actions. | Advertised, proposed contractual, and observed measures are labelled separately and use comparable component definitions. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |

**Requested evidence**

- Draft SLA with formula, exclusions, severity matrix, reporting, and remedies
- Redacted monthly service reports and raw measurement examples
- Incident register, representative post-incident reviews, and corrective-action closure evidence
- Backup restoration, failover, and disaster-recovery test reports

## 5. Player data, controller roles, access, and export

Make lawful roles, operational access, permitted uses, portability, and post-exit handling explicit.

**Gate:** Do not select a platform until the buyer has proved that a complete, usable export can be obtained and reconciled.

| ID | Priority | Requirement | Buyer acceptance criterion | Supplier response | Delivery status | Product / module | Legal entity | Jurisdiction | Assumptions / dependencies | Supplier owner | Acceptance result | One-off cost | Recurring / pass-through cost | Evidence status | Evidence / record | Contract status | Contract schedule | Buyer decision |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| DT-01 | Gate | Map controller, joint-controller, and processor roles by data flow, purpose, legal entity, product, and jurisdiction. | The data terms match the actual operating model, player terms, integrations, support access, and regulatory responsibilities. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| DT-02 | Gate | Define permitted and prohibited supplier uses of player, transaction, behavioural, support, derived, aggregated, and model-training data. | Use is limited to agreed purposes; sale, cross-client activation, marketing, and training use require explicit treatment rather than silence. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| DT-03 | Must | Document residency, transfers, retention, legal holds, deletion, backups, subprocessors, and access locations for every material dataset. | Requirements are mapped to the proposed hosting and support model and changes follow contractual notice and control procedures. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| DT-04 | Must | Specify buyer access to player, wallet, ledger, bet, game, payment, bonus, consent, KYC, AML, safer-gambling, support, and audit records. | APIs, streams, reports, audit logs, latency, history, rate limits, schemas, environments, and access costs are stated per record type. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| DT-05 | Gate | Define full and incremental export content, format, schema, identifiers, frequency, encryption, delivery method, validation, and cost. | The export supports reconciliation and migration without relying on undocumented supplier transformation or manual reconstruction. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| DT-06 | Gate | Run a representative test export and reconciliation before signature, then repeat it on a contractual schedule and before exit. | The buyer receives the test files, schema, reconciliation result, exceptions, remediation plan, and repeat-test right. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |

**Requested evidence**

- Data-flow map, role matrix, processing terms, and records of processing
- Data dictionary, API or stream documentation, and representative audit logs
- Sample full and incremental export plus reconciliation report
- Retention, deletion, backup, residency, transfer, and subprocessor schedules

## 6. Front-end, integration, and IP rights

Separate supplier technology from buyer assets and secure the practical controls needed to operate, change, and leave.

**Gate:** Do not rely on words such as custom, headless, owned, or open API without a deliverable-and-rights map.

| ID | Priority | Requirement | Buyer acceptance criterion | Supplier response | Delivery status | Product / module | Legal entity | Jurisdiction | Assumptions / dependencies | Supplier owner | Acceptance result | One-off cost | Recurring / pass-through cost | Evidence status | Evidence / record | Contract status | Contract schedule | Buyer decision |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| IP-01 | Gate | Classify supplier background technology, buyer materials, custom code, configuration, adapters, content, design, data, and documentation. | Ownership, licence scope, territory, duration, transfer, modification, sublicensing, and post-termination use are stated for each class. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| IP-02 | Gate | Assign control of source repositories, build and deployment pipelines, domains, certificates, app-store accounts, analytics, tags, cloud accounts, and secrets. | The buyer has the access needed for its operating model and a documented transfer or continuity path for supplier-controlled accounts. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| IP-03 | Must | Define delivery, documentation, support, reuse, maintenance, escrow, and continuity rights for custom work and buyer-funded integrations. | The rights support the buyer's intended operation and exit; any supplier reuse or third-party restriction is explicit and priced. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| IP-04 | Must | Document API coverage, authentication, environments, limits, service levels, versioning, deprecation, backward compatibility, and change notice. | Critical integrations can be built and maintained against stable documentation, with enough notice and support to adopt breaking changes. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| IP-05 | Must | List every integration, adapter, configuration set, theme, rule, report, and operational document needed to run or migrate the service. | The responsibility and portability of each asset are assigned; no critical asset exists only in an individual or supplier-controlled workspace. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| IP-06 | Should | Define product-roadmap governance, custom-change control, security patches, regression testing, and compatibility of custom work with upgrades. | The buyer can assess the cost and operational impact of a change before approval and is protected from avoidable customisation dead ends. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |

**Requested evidence**

- Architecture, asset-control, and IP classification diagrams
- Repository, deployment, account, domain, and certificate access matrix
- API specification, change log, versioning policy, and sandbox access
- Draft IP, licence, custom-development, escrow, and change-control schedules

## 7. Security, audit, subprocessors, and hosting

Validate the controls and infrastructure that apply to the proposed service—not a group-wide badge without scope.

**Gate:** Security evidence must name the relevant entity, product, systems, locations, period, exclusions, and unresolved findings.

| ID | Priority | Requirement | Buyer acceptance criterion | Supplier response | Delivery status | Product / module | Legal entity | Jurisdiction | Assumptions / dependencies | Supplier owner | Acceptance result | One-off cost | Recurring / pass-through cost | Evidence status | Evidence / record | Contract status | Contract schedule | Buyer decision |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| SC-01 | Gate | Provide current independent audit or certification reports with entity, service, system, location, period, exclusions, exceptions, and remediation scope. | Coverage maps to the proposed service and material exceptions have owners, deadlines, compensating controls, and closure evidence. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| SC-02 | Must | Provide recent penetration-test scope and results for relevant applications, APIs, infrastructure, and tenant boundaries, plus remediation status. | Testing is independent, critical paths are in scope, material findings are retested, and residual risk is disclosed. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| SC-03 | Must | Describe identity, privileged access, multifactor authentication, least privilege, segregation, joiner-mover-leaver, logging, and review controls. | Supplier, buyer, support, and emergency access are separated and produce retained, buyer-accessible audit evidence where required. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| SC-04 | Must | Describe encryption in transit and at rest, key ownership and rotation, secrets management, backups, immutability, and restoration controls. | Algorithms, key boundaries, access, rotation, backup scope, retention, and restore testing match the proposed architecture. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| SC-05 | Gate | Define security-incident detection, severity, notice, updates, evidence preservation, regulator and player support, forensics, and post-incident review. | Notification starts from a clear trigger, is time-bounded, and gives the buyer the information and cooperation needed to meet its obligations. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| SC-06 | Gate | Map hosting regions, availability zones, tenant model, dependencies, failover, backup, recovery objectives, capacity, and disaster-recovery testing. | The design, SLA, data-location commitments, test evidence, and business-continuity plan describe the same production service. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| SC-07 | Must | Provide the subprocessor and material technology-supplier register, services, data, locations, assurance, change notice, objection, and replacement process. | The buyer can evaluate changes before they take effect and has a proportionate remedy if an unacceptable dependency cannot be replaced. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |

**Requested evidence**

- Scoped audit, certification, penetration-test, and remediation records
- Security architecture, access-control, encryption, key, backup, and logging descriptions
- Incident-response and business-continuity plans plus exercise reports
- Hosting, data-location, technology-dependency, and subprocessor registers

## 8. Game, sportsbook, and PSP approvals

Replace catalogue totals with an executable launch matrix for the exact brand, market, entity, and commercial setup.

**Gate:** A global game, event, integration, or payment count is not evidence that an item can launch in the target setup.

| ID | Priority | Requirement | Buyer acceptance criterion | Supplier response | Delivery status | Product / module | Legal entity | Jurisdiction | Assumptions / dependencies | Supplier owner | Acceptance result | One-off cost | Recurring / pass-through cost | Evidence status | Evidence / record | Contract status | Contract schedule | Buyer decision |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| PA-01 | Gate | Build a launch matrix by market, legal entity, brand, product, supplier, credential or approval, status, owner, dependency, cost, and target date. | Every launch-critical row is either ready with scoped evidence or has an owned approval and activation path in the implementation plan. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| PA-02 | Gate | For casino, list required studios and titles by market, permitted entity, certification or approval, RTP or configuration, device, restriction, and commercial route. | The proposed launch set—not the supplier's global catalogue—is confirmed, priced, approved, and technically available for the target setup. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| PA-03 | Gate | For sportsbook, define feeds, trading and risk model, markets and event types, integrity controls, settlement and void rules, restrictions, and approvals. | The exact managed or operator-controlled scope, data dependencies, pricing, jurisdictional constraints, and incident responsibilities are documented. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| PA-04 | Gate | For payments, map PSP, method, acquiring or merchant entity, country, currency, flow, settlement, reserve, chargeback, refund, reporting, and approval status. | Each required deposit and withdrawal flow has confirmed onboarding ownership, technical availability, settlement economics, and operational controls. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| PA-05 | Must | Assign content, feed, and PSP contracting, certification, onboarding, integration, testing, monitoring, support, invoicing, and replacement responsibilities. | The responsibility schedule and pricing model capture every party needed for the launch and ongoing service. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| PA-06 | Must | Label each item as production-ready for the proposed scope, requiring configuration, requiring contracting or approval, in development, roadmap, or unavailable. | Roadmap and unapproved items are treated as unavailable for the award decision unless the buyer explicitly accepts that gap. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |

**Requested evidence**

- Market-by-entity launch matrix with dated approval evidence
- Exact title, studio, feed, event, and PSP availability extracts for the proposed scope
- Sample content, trading, settlement, payment, and reconciliation reports
- Draft third-party responsibility, commercial, approval, and replacement schedules

## 9. Support, escalation, and operating governance

Define how the buyer, supplier, and third parties will operate the service from launch through incidents and change.

**Gate:** Support is not 24/7 merely because a contact channel is open; roles, authority, response, and escalation must be explicit.

| ID | Priority | Requirement | Buyer acceptance criterion | Supplier response | Delivery status | Product / module | Legal entity | Jurisdiction | Assumptions / dependencies | Supplier owner | Acceptance result | One-off cost | Recurring / pass-through cost | Evidence status | Evidence / record | Contract status | Contract schedule | Buyer decision |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| SU-01 | Gate | State support hours, time zones, languages, channels, response coverage, monitoring coverage, and any after-hours restrictions by service tier. | The proposed tier covers the buyer's operating hours and critical services without relying on unpriced or undefined escalation. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| SU-02 | Gate | Assign L1, L2, and L3 responsibilities across buyer, supplier, content, payment, data, hosting, and other third parties. | A single operating matrix defines intake, diagnosis, ownership, hand-off, communication, workaround, resolution, and closure. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| SU-03 | Must | Provide severity, escalation, duty-manager, executive escalation, regulator-support, and emergency-change paths with named roles and authority. | Contacts are maintained, tested, and empowered to make time-critical decisions; escalation does not reset the service clock. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| SU-04 | Must | Define monitoring, alerting, ticketing, status communication, incident, problem, release, change, and maintenance processes. | The buyer receives timely operational visibility and can audit ticket, incident, change, and service-performance records. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| SU-05 | Must | Scope implementation support, launch hypercare, training, runbooks, knowledge transfer, service transition, and refresher training. | Deliverables, audiences, timing, acceptance, materials, recordings, environments, and extra charges are stated. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| SU-06 | Should | Define service reviews, roadmap and capacity governance, risk and action logs, change prioritisation, and standard versus premium account-management scope. | Meeting cadence, participants, inputs, decisions, records, and pricing match the level of governance assumed in the proposal. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |

**Requested evidence**

- Support handbook, service catalogue, tier comparison, and escalation matrix
- Cross-party operating and responsibility model
- Sample ticket, incident, change, maintenance, and service-review reports
- Hypercare, training, knowledge-transfer, and governance plans

## 10. Term, renewal, minimums, and exclusivity

Expose lock-in, timing, volume, price, scope, and suspension mechanics before commercial award.

**Gate:** The buyer must be able to model when obligations start, change, renew, and end under every scenario.

| ID | Priority | Requirement | Buyer acceptance criterion | Supplier response | Delivery status | Product / module | Legal entity | Jurisdiction | Assumptions / dependencies | Supplier owner | Acceptance result | One-off cost | Recurring / pass-through cost | Evidence status | Evidence / record | Contract status | Contract schedule | Buyer decision |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| CT-01 | Gate | Define signature, effective, implementation, acceptance, launch, billing, minimum-commitment, initial-term, renewal, and expiry dates. | No fee, minimum, renewal, or notice period starts from an ambiguous event or before the corresponding service is accepted. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| CT-02 | Must | State ramp periods, minimum fees or volumes, tiers, shortfall treatment, carry-forward, credits, true-ups, and consequences of market delay. | Downside, delayed-launch, baseline, and growth outcomes can be reproduced in the commercial model. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| CT-03 | Gate | Set renewal mechanics, notice windows, price review, indexation, currency, foreign-exchange, tax, third-party change, and rejection or termination rights. | Dates and formulas are explicit, reminders are operationally manageable, and material changes give the buyer a proportionate remedy. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| CT-04 | Gate | Define exclusivity by product, module, content, payment method, jurisdiction, channel, brand, entity, duration, performance condition, and exception. | There is no implied group-wide or future-market restriction, and failure to perform releases the affected exclusivity. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| CT-05 | Must | Define assignment, change of control, subcontracting, affiliate use, novation, divestment, new-brand, and new-jurisdiction rights. | The contract supports foreseeable corporate and operating changes without unpriced consent leverage or accidental termination. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| CT-06 | Gate | Limit suspension rights by trigger, affected service, notice, cure, proportionality, regulatory need, player protection, data access, and continuity. | Suspension is no broader or longer than necessary and preserves access needed to protect players, reconcile funds, and comply with obligations. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |

**Requested evidence**

- Term sheet and draft order form with a single date and notice table
- Scenario model for ramp, minimums, renewals, delayed launch, and price change
- Exact exclusivity, assignment, affiliate, and change-of-control drafting
- Suspension process and continuity protections

## 11. Termination, migration, data access, and continuity

Design the exit while both parties still want the deal, then test whether it is operationally credible.

**Gate:** Do not sign without a costed, timed, tested path to protect players, obtain data and assets, and continue or wind down service.

| ID | Priority | Requirement | Buyer acceptance criterion | Supplier response | Delivery status | Product / module | Legal entity | Jurisdiction | Assumptions / dependencies | Supplier owner | Acceptance result | One-off cost | Recurring / pass-through cost | Evidence status | Evidence / record | Contract status | Contract schedule | Buyer decision |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| EX-01 | Gate | Define termination rights, triggers, notice, cure, insolvency, regulatory failure, security event, repeated SLA breach, illegality, and force-majeure longstop. | Critical failures create usable rights and the buyer is not forced to remain solely because migration is operationally impossible. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| EX-02 | Must | State fees, refunds, prepaid amounts, minimums, work in progress, disputes, player balances, reserves, settlements, and in-flight transactions on exit. | Financial treatment is defined for normal expiry, buyer convenience, supplier breach, regulatory exit, and insolvency scenarios. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| EX-03 | Gate | Set transition period, service levels, change limits, parallel run, migration support, knowledge transfer, named resources, rates, and cooperation with a successor. | The period and resource commitment match a realistic migration plan and cannot be withheld because the supplier is being replaced. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| EX-04 | Gate | Define full and incremental exports, schemas, identifiers, history, media, documents, audit records, delivery timing, encryption, validation, and reconciliation. | The buyer can run parallel validation, correct exceptions, and receive final deltas before service and access end. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| EX-05 | Gate | List code, configuration, domains, certificates, accounts, credentials, content, integrations, reports, runbooks, and other assets to transfer or continue. | Each asset has an owner, transfer mechanism, dependency, delivery format, date, cost, and fallback if direct transfer is impossible. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| EX-06 | Must | Define post-exit access, retention, legal hold, return, deletion, backup expiry, deletion certificate, audit, confidentiality, and residual licences. | The schedule preserves required records and access while creating a verifiable end state for data and supplier rights. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| EX-07 | Gate | Run a tabletop exit before signature using a named scenario, successor, timeline, data set, asset list, responsibilities, and continuity constraints. | Gaps become contract actions with owners and dates; the exit schedule is updated before award rather than deferred to termination. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |

**Requested evidence**

- Draft termination, exit, migration, assistance, and continuity schedule
- Representative full and incremental exports plus reconciliation results
- Transferable asset, account, credential, integration, and documentation register
- Tabletop-exit record, risk log, remediation actions, and costed transition plan

## 12. Player protection, financial crime, wallet, and control testing

Prove that the proposed configuration can identify players, protect them, control financial crime and fraud, account for money, and produce the required evidence.

**Gate:** Do not accept a control catalogue or demonstration in place of end-to-end tests in the proposed jurisdiction, product configuration, integrations, and responsibility model.

| ID | Priority | Requirement | Buyer acceptance criterion | Supplier response | Delivery status | Product / module | Legal entity | Jurisdiction | Assumptions / dependencies | Supplier owner | Acceptance result | One-off cost | Recurring / pass-through cost | Evidence status | Evidence / record | Contract status | Contract schedule | Buyer decision |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| RC-01 | Gate | Define the KYC journey for age, identity, address, document and liveness checks, duplicate accounts, verification failure, retry, manual review, and account restriction. | Each jurisdiction and player path has configured rules, data sources, decision owners, time limits, fallback handling, retained evidence, and passed positive, negative, unavailable-source, and manual-review tests. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| RC-02 | Gate | Define AML controls for customer risk rating, sanctions and PEP screening, transaction monitoring, source-of-funds or wealth review, case management, escalation, and regulatory reporting. | Rules, thresholds, lists, refresh timing, alerts, evidence, analyst permissions, decision records, filing responsibilities, and test cases match the proposed entities, markets, products, and payment flows. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| RC-03 | Gate | Define responsible-gambling controls for self-exclusion, limits, time-outs, reality checks, risk detection, intervention, marketing suppression, and return-to-play handling. | Controls propagate across the required brands, products, channels, wallets, CRM, and support tools within defined times, block prohibited activity, retain an audit trail, and pass jurisdiction-specific journey tests. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| RC-04 | Must | Define fraud controls for account takeover, device and identity linkage, payment abuse, chargebacks, bonus abuse, multi-accounting, collusion, and suspicious withdrawal changes. | Signals, rule ownership, automated and manual actions, customer impact, false-positive review, overrides, evidence retention, and cross-system escalation are documented and tested with representative scenarios. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| RC-05 | Gate | Define the authoritative wallet and ledger treatment for available, pending, restricted, bonus, reserved, settled, reversed, adjusted, and written-off balances. | Every money movement has balanced entries, immutable identifiers, actor and reason, idempotency and failure handling, and passed reconciliation across platform, games, sportsbook, PSP, bank, and finance records. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| RC-06 | Must | Provide operational, financial, compliance, and regulator reports plus the underlying event and decision audit trail for the proposed scope. | Definitions, cut-off times, time zones, corrections, lineage, access, retention, delivery, sign-off, and submission ownership are fixed, and sample reports reconcile to source transactions and control decisions. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| RC-07 | Gate | Run a buyer-witnessed pre-production control test pack and define regression tests for rule, integration, data-source, product, and jurisdiction changes. | Approved scripts cover success, rejection, timeout, partial failure, manual override, downstream propagation, reconciliation, reporting, and audit evidence; defects are remediated and retested before go-live. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |

**Requested evidence**

- Jurisdiction-by-entity control and responsibility matrix
- KYC, AML, responsible-gambling, and fraud rule catalogues with approved test cases
- Wallet and ledger specification plus end-to-end reconciliation results
- Sample reports, audit-trail exports, witnessed test record, defects, and retest evidence