# Light & Wonder (iGaming) procurement pack

Review path: /review/light-and-wonder

Primary procurement model: Casino game aggregator

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 | 4 |
| Product responsibility kinds | Game aggregator · Remote game server · Player account management · Engagement tool |
| Recorded permission markets | Alberta · Denmark · Malta (MGA) · Michigan · New Jersey · Pennsylvania · UK (UKGC) · West Virginia |
| Recorded permission kinds | B2B supplier 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 |
|---|---|
| Modular PAM / API platform | PAM / API |
| Casino game aggregator | Game aggregator category · Game aggregator |

## Product and responsibility map

| ID | Product or decision subject | Kind | State | Recorded position | Responsibility | Boundary | Accept when |
|---|---|---|---|---|---|---|---|
| product:light-and-wonder:game-aggregator | OpenGaming (OGS) · Game aggregator | Game aggregator | recorded | OpenGaming (OGS) is recorded for Light & Wonder (iGaming) as game aggregator. The record establishes the named product-to-provider relationship only. | The integration and routing layer between an operator platform and multiple game-content connections. | A current title count, commercial entitlement, certification, market availability or one uniform integration path. | A supplier-title-market route matrix with launch, rollback, round-state and reconciliation acceptance. |
| product:light-and-wonder:remote-game-server | Playzido · Remote game server | Remote game server | recorded | Playzido is recorded for Light & Wonder (iGaming) 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. |
| product:light-and-wonder:player-account-management | Player Account Management (PAM / OPS) · Player account management | Player account management | recorded | Player Account Management (PAM / OPS) is recorded for Light & Wonder (iGaming) 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:light-and-wonder:engagement-tool | ELEVATE · Engagement tool | Engagement tool | recorded | ELEVATE is recorded for Light & Wonder (iGaming) as engagement tool. The record establishes the named product-to-provider relationship only. | A bounded player-engagement mechanic such as tournaments, jackpots, missions or in-session prompts. | Promotion approval, prize funding, fairness, wallet treatment or inclusion in the core platform contract. | Mechanic-specific rules, eligibility, funding, tie, cancellation, dispute and accounting tests. |

## Five priority questions and acceptance gates

### 1. PAM-02 — Interface contract

- Procurement context: Modular PAM / API platform
- Current state: unknown
- Recorded position: Light & Wonder (iGaming): 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 |
|---|---|---|---|
|  |  |  |  |

### 2. AGG-03 — Release inventory

- Procurement context: Casino game aggregator
- Current state: unknown
- Recorded position: Light & Wonder (iGaming): Live casino is not confirmed for this profile. This is not a statement that the capability is unavailable.
- Question: Can the buyer identify exactly which game binary, math, certificate, metadata, configuration and jurisdiction rule is live?
- Request: Immutable game/version IDs; certificates; RTP and configuration variants; release manifests; change notifications; disable and rollback workflow.
- Accept when: The live inventory reconciles to approved versions, changes are buyer-gated, and a single game or version can be disabled and rolled back safely.
- Stop when: The aggregator cannot produce a version-level live inventory or can change regulated game configuration without an accepted buyer release control.
- Contract destination: Game inventory, release and change schedule

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

### 3. PAM-03 — Ledger and reconciliation

- Procurement context: Modular PAM / API platform
- Current state: unknown
- Recorded position: Light & Wonder (iGaming): Reporting & BI is not confirmed for this profile. This is not a statement that the capability is unavailable.
- Question: How do product, payment and bonus postings become one authoritative financial record?
- Request: Wallet protocols; journal model; idempotency retention; round and payment lifecycle; daily control totals; unmatched-item ageing and correction workflow.
- Accept when: All enabled transaction types post exactly once, preserve history, close to signed totals and expose every exception with an owner and ageing state.
- Stop when: The operator cannot independently reconcile balances and liabilities or recover a partial posting without direct database intervention.
- Contract destination: Wallet, accounting and reconciliation schedule

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

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

- Procurement context: Modular PAM / API platform
- Current state: unknown
- Recorded position: Light & Wonder (iGaming): 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 |
|---|---|---|---|
|  |  |  |  |

### 5. PAM-05 — Change isolation

- Procurement context: Modular PAM / API platform
- Current state: unknown
- Recorded position: Light & Wonder (iGaming): no bounded deployment record is included in this review. This does not mean that the provider has no deployments.
- Question: Can either party upgrade a component without silently breaking events, reports, integrations or control semantics?
- Request: Compatibility policy; contract tests; schema registry; feature flags; release rings; rollback; end-of-life notices; dependency inventory.
- Accept when: Backward-compatibility and breaking-change rules are automated, release evidence is visible, and rollback preserves transaction and audit continuity.
- Stop when: The supplier can impose a breaking interface or data change without a tested migration path, adequate notice and buyer-controlled release gate.
- Contract destination: Change, compatibility and release schedule

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