# Playtech procurement pack

Review path: /review/playtech

Primary procurement model: Modular PAM / API platform

This is an editable procurement record, not a readiness score, contract commitment, market permission or launch approval.

## Recorded position

| Field | Current position |
|---|---|
| Named product or module records | 5 |
| Product responsibility kinds | Player account management · Sportsbook · Compliance · Live casino · Remote game server |
| Recorded permission markets | Alberta · Denmark · Malta (MGA) · Michigan · New Jersey · Pennsylvania · UK (UKGC) · West Virginia |
| Recorded permission kinds | B2B supplier approval · Operator licence · Product / transaction approval |
| Pricing transparency | Not recorded |
| Operational history | Incident history unavailable for a complete count |
| Included deployment records | 0 |
| Included current-live deployment records | 0 |
| Interpretation boundary | These are records included in this review. Counts, zero values and empty lists do not establish absence, package inclusion, the supplying entity, market availability or a current deployment. |

## Applicable procurement scopes

| Scope | Inclusion basis |
|---|---|
| Turnkey iGaming platform | Turnkey |
| Modular PAM / API platform | SaaS / PAM category · PAM / API |
| Sportsbook platform | Recorded sportsbook capability |
| Casino game aggregator | Game aggregator |

## Product and responsibility map

| ID | Product or decision subject | Kind | State | Recorded position | Responsibility | Boundary | Accept when |
|---|---|---|---|---|---|---|---|
| product:playtech:player-account-management | IMS / PAM+ · Player account management | Player account management | recorded | IMS / PAM+ is recorded for Playtech as player account management. The record establishes the named product-to-provider relationship only. | Player-account identity, lifecycle, authentication, profile state and the account services assigned to the PAM. | Wallet authority, KYC coverage, bonus ownership, omnichannel continuity or inclusion of every adjacent service. | An account-state and data-authority model with registration, restriction, closure, recovery, audit and migration tests. |
| product:playtech:sportsbook | Playtech Sports · Sportsbook | Sportsbook | recorded | Playtech Sports is recorded for Playtech as sportsbook. The record establishes the named product-to-provider relationship only. | The bet and market lifecycle assigned to the named sportsbook product, including its connected operating components. | Trading ownership, event volume, PAM inclusion, market permission, latency or operator-specific configuration. | Bet-state tests covering offer, acceptance, rejection, cash-out, cancellation, settlement, correction and resettlement. |
| product:playtech:compliance | BetBuddy · Compliance | Compliance | recorded | BetBuddy is recorded for Playtech as compliance. The record establishes the named product-to-provider relationship only. | Control workflows, rules, evidence capture, review queues and compliance administration. | Legal compliance, regulator acceptance, complete market coverage or the operating effectiveness of a control. | A jurisdiction-specific control map with owners, evidence output, exceptions, overrides and retention rules. |
| product:playtech:live-casino | Playtech Live · Live casino | Live casino | recorded | Playtech Live is recorded for Playtech as live casino. The record establishes the named product-to-provider relationship only. | Live-table sessions, streams, game state and the integration path for the named live-casino product. | Studio ownership, table inventory, language coverage, market approval or operator-specific availability. | Table and stream acceptance covering session continuity, limits, result state, interruption, fallback and dispute evidence. |
| product:playtech:remote-game-server | Playtech Casino · Remote game server | Remote game server | recorded | Playtech Casino is recorded for Playtech as remote game server. The record establishes the named product-to-provider relationship only. | Game hosting, session and round-state processing for content served through the named RGS. | Game ownership, title certification, market approval, operator entitlement or wallet authority. | Round-lifecycle tests for start, debit, result, credit, retry, idempotency, recovery and immutable history. |

## Five priority questions and acceptance gates

### 1. TK-03 — Wallet and control authority

- Procurement context: Turnkey iGaming platform
- Current state: unknown
- Recorded position: Playtech: Reporting & BI is not confirmed for this profile. This is not a statement that the capability is unavailable.
- Question: Which system is authoritative for identity, balances, bonus liability, limits, exclusions, transaction history and regulatory reporting?
- Request: System-of-record map; wallet sequences; control precedence; reconciliation output; access model; witnessed failure and replay tests.
- Accept when: One authority is named for every state, conflict resolution is deterministic, and debit, credit, rollback, limit and exclusion tests reconcile end to end.
- Stop when: Competing systems can independently alter player eligibility or financial state without a deterministic authority, audit trail and reconciliation path.
- Contract destination: Architecture, controls and reconciliation schedules

| Owner | Supplier response | Exception | Sign-off |
|---|---|---|---|
|  |  |  |  |

### 2. PAM-02 — Interface contract

- Procurement context: Modular PAM / API platform
- Current state: unknown
- Recorded position: Playtech: Headless API is not confirmed for this profile. This is not a statement that the capability is unavailable.
- Question: Can the PAM operate as a modular service across the required synchronous APIs, events, exports and administrative workflows?
- Request: Versioned specifications; event catalogue; idempotency and ordering rules; error model; limits; sandbox parity; deprecation policy; sample logs.
- Accept when: Buyer tests cover success, duplicate, late, out-of-order, timeout, partial-failure and version-change paths with deterministic recovery.
- Stop when: A critical state transition depends on a private manual process, undocumented interface, non-replayable event or change policy the buyer cannot test.
- Contract destination: API, event and lifecycle schedule

| Owner | Supplier response | Exception | Sign-off |
|---|---|---|---|
|  |  |  |  |

### 3. SB-04 — Feed and event integrity

- Procurement context: Sportsbook platform
- Current state: unknown
- Recorded position: Playtech: incident history unavailable for a complete count. This does not establish poor reliability.
- Question: How are event identity, feed conflict, latency, suspension, correction and abandonment controlled across suppliers?
- Request: Feed inventory; event mapping; freshness thresholds; conflict precedence; monitoring; suspension tests; correction workflow and audit output.
- Accept when: The system detects stale or conflicting data, suspends deterministically, records overrides and reconciles every correction to bets and balances.
- Stop when: A feed failure or event-identity conflict can continue accepting bets without a bounded automated or supervised control.
- Contract destination: Data feeds, integrity and monitoring schedule

| Owner | Supplier response | Exception | Sign-off |
|---|---|---|---|
|  |  |  |  |

### 4. AGG-06 — Commercial chain

- Procurement context: Casino game aggregator
- Current state: unknown
- Recorded position: Playtech: commercial terms are not recorded for this profile. This does not imply a price level.
- Question: Are aggregator fees, studio charges, minimums, jackpots, promotional tools, certification, data and exit treatment comparable?
- Request: Per-studio and platform rate card; calculation basis; minimums; pass-throughs; excluded tools; content removal; data retention; direct-integration exit plan.
- Accept when: Every scenario reconciles invoice logic to wallet and game data, while content continuity, data access and transition rights survive termination.
- Stop when: A material studio charge, calculation basis, minimum, liability, content-removal consequence or exit restriction remains undefined.
- Contract destination: Content charges, settlement and exit schedules

| Owner | Supplier response | Exception | Sign-off |
|---|---|---|---|
|  |  |  |  |

### 5. PAM-04 — Cross-supplier controls

- Procurement context: Modular PAM / API platform
- Current state: unknown
- Recorded position: Playtech: Anti-fraud is not confirmed for this profile. This is not a statement that the capability is unavailable.
- Question: Do limits, exclusions, AML actions, fraud decisions and responsible-gambling controls propagate across every connected product?
- Request: Control precedence; event timing; fail-closed rules; product acknowledgements; exception queues; audit output; multi-product test results.
- Accept when: A control change reaches and is enforced by every required product within an agreed bound, with deterministic treatment during dependency failure.
- Stop when: A launch product can accept activity after a mandatory player restriction because propagation, acknowledgement or fail-closed behaviour is unresolved.
- Contract destination: Player-protection and financial-crime control schedule

| Owner | Supplier response | Exception | Sign-off |
|---|---|---|---|
|  |  |  |  |