Buyer architecture and acceptance framework

iGaming platform architecture

A buyer-owned map for deciding where player, wallet, payment, game, wager, control, and reporting truth lives—and for proving that the complete platform survives retries, dependency failure, recovery, and supplier exit without contradictory state.

Start with systems of record Download acceptance CSV

8 authority boundaries5 lifecycle flows4 architecture modes25 acceptance controlsUpdated 2026-08-13

Architecture is a responsibility model, not a box diagram

A component list does not establish transaction authority, recovery, regulatory accountability, or exit rights. Accept the proposed design only after the named systems, legal entities, interfaces, controls, and failure paths pass one integrated test pack.

Architecture diligence sequence

Build the decision from state outward

Run this sequence on the exact products, entities, regions, and third parties in the proposal. A reference architecture is useful only when it survives that scope.

Step 1
Draw authority before components
For each state, name the one system allowed to finalize it. A box labelled PAM, wallet, aggregator, or data warehouse is not yet an authority decision.
Step 2
Trace five complete lifecycles
Follow identity, money, game, wager, and exit events from initial request through failure, recovery, reconciliation, and terminal state.
Step 3
Assign four ownership roles
Record who decides, who delivers, who produces evidence, and who has final escalation authority. Do not compress those into one vague ‘shared’ owner.
Step 4
Translate topology into consequences
Compare modular, monolithic, headless, and hybrid delivery by control, operational burden, failure domains, and exit—not by architecture label.
Step 5
Test failure and recovery
Set RTO, RPO, idempotency, ordering, audit, data-residency, reconciliation, and failover acceptance criteria at the player-journey level.
Step 6
Move accepted proof into schedules
Attach interfaces, ownership, service targets, evidence, remedies, data rights, and exit duties to named contract schedules before award.

System-of-record map

The authoritative system is the component allowed to finalize a state—not merely the component that displays or caches it. Record write authority, replicas, reconciliation, recovery, and change ownership for every row.

Swipe horizontally to view all columns.

Authoritative record, prohibited split, and acceptance evidence for each iGaming platform state domain
State domain	Required authority	Split-brain condition to reject	Acceptance evidence
Player identity and account state	The PAM record that owns player ID, account lifecycle, verification state, restrictions, and closure state.	A CRM, front end, KYC vendor, or support tool cannot independently create a second account state.	Create, restrict, reopen, merge, and close test accounts; reconcile every replica to one immutable player ID and ordered state history.
Consent, limits, and self-exclusion	One control record owns the effective policy, jurisdiction, channel, start time, end time, and change reason.	A channel cache or third-party tool cannot permit play after the authoritative restriction is effective.	Apply changes during active sessions and prove propagation, enforcement, timestamps, acknowledgements, and regulator-facing history.
Wallet and player balances	A double-entry or equivalently reconstructable ledger owns available, reserved, pending, bonus, restricted, and withdrawable balances.	The cashier, game aggregator, sportsbook, and bonus engine cannot each maintain an unreconciled balance truth.	Rebuild every balance from entries, replay duplicate requests, force timeouts, and reconcile all subledgers to the general ledger.
Payments and settlement	A payment transaction record owns instruction, processor reference, state transitions, fees, reversals, chargebacks, and settlement batch.	A PSP callback cannot credit funds without a durable mapping to the player ledger and settlement record.	Run approved, declined, pending, duplicated, reversed, chargeback, and late-callback cases through ledger and settlement reconciliation.
Casino round and game outcome	The approved game or RGS record owns round ID, wager, outcome, contribution, status, and finality while the wallet owns money movement.	The aggregator and PAM cannot finalize different round outcomes or post an outcome twice.	Test open rounds, duplicate callbacks, rollback, timeout, late completion, jackpot contribution, and post-migration round settlement.
Sportsbook wager and liability	The sportsbook owns wager, selection, odds, acceptance, cashout, result, void, settlement, resettlement, and liability state.	Front-end display, trading tools, and PAM cannot disagree on whether a wager was accepted or settled.	Trace a wager from quote to resettlement, including price change, partial cashout, abandoned request, result correction, and wallet postings.
Bonus and promotional entitlement	One promotion ledger owns grant, eligibility snapshot, wagering contribution, expiry, conversion, forfeiture, and financial effect.	CRM eligibility and wallet bonus value cannot drift or apply different terms to the same grant.	Replay qualification events and prove one grant, correct contribution, deterministic expiry, wallet reconciliation, and a full terms snapshot.
Audit, reporting, and regulatory records	An append-only event and reporting lineage ties every submitted value to source transactions, transformations, version, and approval.	A dashboard total or warehouse extract cannot become regulatory truth without reproducible lineage and correction history.	Reproduce selected reports from raw records, trace adjustments, verify time zones and cut-offs, and demonstrate correction without destructive overwrite.

Five lifecycle flows to prove end to end

Each flow crosses component and often supplier boundaries. Test its invariant under interruption and recovery; a successful happy-path demo is not acceptance.

FLOW-01

Registration to permitted play

Registration request received → Account is permitted or blocked with a recorded reason

1Create one player ID and jurisdiction context
2Capture consent and age or identity evidence
3Run KYC, sanctions, fraud, geolocation, and duplicate-account controls
4Apply limits, exclusions, risk state, and product permissions
5Expose the same effective state to every channel and product

Invariant

No product accepts play until all mandatory controls resolve to the same effective account state.

Failure test

Change a restriction during an active session and prove that stale channels fail closed within the contracted propagation time.

FLOW-02

Deposit to spendable balance

Deposit instruction created → Funds are credited, rejected, reversed, or held with one reconcilable state

1Create an idempotent payment instruction
2Screen method, player, instrument, limits, and source-of-funds rules
3Persist processor responses and asynchronous callbacks
4Post balanced ledger entries only at the approved state transition
5Reconcile processor, cashier, wallet, settlement, and finance totals

Invariant

One external payment produces at most one financial effect, and every financial effect has one external transaction lineage.

Failure test

Deliver the success callback twice after a client timeout, then reverse it after cut-off; the ledger and settlement batch must remain balanced.

FLOW-03

Casino wager to final round

Game session and round opened → Round is final, rolled back, or held in an explicit exception queue

1Bind session, player, game, version, market, and currency
2Reserve or debit the wager with a stable round ID
3Receive and validate outcome and game-state transitions
4Credit winnings, jackpot, bonus, and tax effects once
5Close or roll back the round and reconcile RGS, aggregator, and wallet

Invariant

A round cannot be both settled and rolled back, and replay cannot change its net ledger effect.

Failure test

Interrupt between wager debit and result callback, replay all messages out of order, and prove deterministic recovery without a stranded balance.

FLOW-04

Sportsbook quote to resettlement

Bet request created from a priced selection → Wager is rejected, settled, voided, cashed out, or resettled with complete lineage

1Snapshot selection, price, limits, market state, and request time
2Accept or reject and reserve liability atomically
3Expose one wager state to player, trading, support, and PAM
4Apply cashout, result, settlement, void, and correction events in order
5Reconcile liabilities and every wallet posting through the settlement tail

Invariant

The accepted terms remain immutable; later corrections append new events and never rewrite the original wager.

Failure test

Force a price change, acceptance timeout, partial cashout, result correction, and resettlement; player display, liability, and ledger must converge.

FLOW-05

Withdrawal to account closure

Withdrawal or closure request received → Funds and account are released, held, rejected, or closed with retained evidence

1Freeze the relevant balance and open withdrawal controls
2Resolve KYC, AML, bonus, chargeback, affordability, and method rules
3Send one payout instruction and track asynchronous outcome
4Reconcile fees, rejects, returns, reversals, and settlement
5Close or restrict the account while preserving obligations, access, and retention

Invariant

Closure never destroys open financial obligations, audit evidence, disputes, or required player access.

Failure test

Close an account with an open wager, pending withdrawal, unsettled chargeback, and active self-exclusion; every obligation must retain an owner and terminal path.

Responsibility matrix: four owners, not one RACI shortcut

The legal entity that supplies a component may differ from the party making the policy decision, retaining evidence, or commanding an incident. Replace the role labels below with named entities and people before award.

Swipe horizontally to view all columns.

Decision, delivery, evidence, escalation and acceptance ownership by platform activity
Activity	Decision owner	Delivery owner	Evidence owner	Escalation owner	Accept when
Player account and control-state model	Operator compliance and product	PAM supplier	PAM supplier	Operator compliance lead	One schema and responsibility map covers every state, override, propagation target, and regulator-facing record.
Wallet, money movement, and reconciliation	Operator finance	PAM or wallet supplier	Supplier plus PSP and sportsbook/content counterparties	Operator finance controller	Ledger ownership, posting rules, control totals, break handling, settlement cut-offs, and sign-off are named per rail and vertical.
API and event integration	Operator architecture	Party building each adapter	Every interface owner	Joint architecture authority	Each interface has an owner, consumer, contract version, SLO, replay rule, monitoring, runbook, and retirement plan.
Security and privileged access	Operator security	Each hosting and service owner	Control operator	Joint incident commander	Identity, approval, logging, emergency access, key rotation, revocation, and evidence retention are testable across all environments.
Availability, recovery, and dependency continuity	Operator service owner	Each component owner	Supplier SRE or operations	Named cross-supplier incident commander	Journey RTO/RPO decomposes into component targets, recovery order, dependency assumptions, exercise evidence, and remedies.
Regulatory reporting and change approval	Operator compliance	Reporting and source-system owners	Reporting owner	Operator compliance officer	Every value has source lineage, transformation version, cut-off, approval, correction method, retention, and change notification.
Data residency, privacy, and retention	Operator privacy and legal	Each processor and host	Supplier privacy and security owners	Operator privacy lead	Dataset, purpose, role, region, subprocessor, transfer route, encryption, retention, deletion, legal hold, and export are mapped.
Exit, transition, and stranded obligations	Operator executive sponsor	Incumbent and successor owners	Incumbent supplier	Contract governance board	Data, interfaces, open balances, rounds, wagers, disputes, credentials, access, deletion, costs, and settlement tail have tested handover criteria.

Modular, monolith, headless, and hybrid consequences

None is automatically superior. The buying decision is which control the operator gains, which operational duty it accepts, and which proof makes the trade-off supportable.

Modular

PAM, wallet, sportsbook, content, payments, CRM, and reporting can be replaced or scaled separately only if their contracts and state boundaries are explicit.

Control gained

Component choice, phased replacement, and independent scaling.

Risk accepted

More distributed failure modes, version combinations, reconciliation work, and multi-party incident ownership.

Proof before award

Interface inventory, compatibility matrix, state-authority map, end-to-end SLOs, and a tested component-replacement path.

Monolith

One release and data model can simplify transaction consistency, while change cadence and exit depend heavily on one supplier boundary.

Control gained

Fewer runtime interfaces and one primary operational owner.

Risk accepted

Large blast radius, coupled releases, constrained component choice, and potentially expensive data or front-end separation.

Proof before award

Failure-domain evidence, release rollback, complete export, tested restore, customisation boundaries, and priced transition assistance.

Headless

The operator controls experience and orchestration, but must own session, cache, accessibility, privacy, and failure behaviour across APIs.

Control gained

Front-end roadmap, channel consistency, experimentation, and brand-specific journeys.

Risk accepted

The operator becomes responsible for more integration code, client security, latency, compatibility, and degraded-state design.

Proof before award

API contracts, reference flows, accessibility baseline, performance budgets, token model, compatibility policy, and front-end source/IP rights.

Hybrid

Packaged journeys and operator-owned components coexist, so every boundary needs a named authority and change owner.

Control gained

Selective customisation without rebuilding every regulated or transactional flow.

Risk accepted

Duplicated session, content, identity, analytics, and release responsibilities can create hidden split-brain behaviour.

Proof before award

Journey-by-journey ownership, routing and fallback rules, shared design tokens, release coordination, and cross-boundary acceptance tests.

Buyer acceptance inventory

25 controls for authority, recovery, audit, residency, and ownership

Add buyer and supplier owners, environment, result, exception, remedy, and contract schedule in the CSV. A control passes only on scoped evidence from the proposed architecture.

Download CSV

Swipe horizontally to view all columns.

Architecture acceptance controls, evidence, tests and failure conditions
ID	Domain	Control	Evidence required	Acceptance test	Fail when
SOR-01	System of record	Name one authoritative player ID and account-state record.	Entity and state schema, write-path diagram, state history sample.	Create, restrict, merge, reopen, and close accounts across every channel.	Two components can independently finalize different account states.
SOR-02	System of record	Name the authoritative consent, limit, and self-exclusion state.	Policy/version fields, propagation SLO, acknowledgement and audit records.	Apply a restriction during active sessions and verify fail-closed enforcement.	Any product accepts play after the restriction is effective.
SOR-03	System of record	Use one reconstructable wallet ledger for all monetary states.	Ledger schema, posting rules, sample journal, reconciliation output.	Rebuild balances from entries and reconcile all subledgers.	A balance depends on an editable aggregate or unreconciled replica.
SOR-04	System of record	Map each external payment to one ledger effect and settlement record.	Payment state machine, processor mapping, chargeback and settlement files.	Run success, decline, pending, duplicate, reversal, and chargeback cases.	A callback can create an unmatched or duplicate financial effect.
SOR-05	System of record	Separate casino round authority from wallet posting authority.	Round state machine, stable IDs, rollback rules, open-round report.	Replay outcome and rollback callbacks around a forced timeout.	A round can be finalized twice or remain financially stranded.
SOR-06	System of record	Preserve immutable sportsbook wager terms and append later state events.	Wager/event schema, liability model, settlement and correction lineage.	Execute price change, timeout, cashout, void, and resettlement.	Original accepted terms can be overwritten or wallet state diverges.
SOR-07	System of record	Bind every bonus financial effect to one entitlement and terms snapshot.	Grant ID, eligibility snapshot, contribution ledger, expiry rules.	Replay qualification and expiry events across wallet and CRM.	One event grants twice or terms cannot be reconstructed.
SOR-08	System of record	Provide reproducible lineage for audit and regulatory reporting.	Source mapping, transformation versions, approvals, correction history.	Rebuild selected report totals from source transactions.	A reported value cannot be traced or requires destructive correction.
FLOW-01	Lifecycle flow	Gate play on one effective registration and control state.	End-to-end onboarding trace and blocked-state propagation evidence.	Complete and interrupt registration in every mandatory control state.	A mandatory unresolved state permits play.
FLOW-02	Lifecycle flow	Make deposit processing idempotent and financially reconcilable.	Instruction IDs, callback logs, ledger entries, settlement control totals.	Duplicate a late success callback and then reverse the payment.	One external payment changes balance more than once.
FLOW-03	Lifecycle flow	Recover casino rounds deterministically after partial failure.	Round trace, replay output, wallet journal, exception-queue record.	Interrupt after debit and replay messages out of order.	Round and wallet fail to converge without manual balance editing.
FLOW-04	Lifecycle flow	Keep sportsbook display, liability, and ledger aligned through correction.	Wager timeline, liability changes, player display, wallet journal.	Run partial cashout followed by result correction and resettlement.	Any view retains a contradictory final state.
FLOW-05	Lifecycle flow	Preserve open obligations through withdrawal and closure.	Closure checklist, holds, open-item inventory, retention and payout records.	Close an account with open wagers, withdrawal, dispute, and restriction.	An obligation loses ownership, evidence, or a terminal path.
OPS-01	Resilience	Set journey-level RTO and decompose it into component recovery order.	Journey SLO, dependency map, recovery runbook, timed exercise output.	Fail a critical component and time recovery of the complete journey.	Component recovery meets target while the player journey remains unusable.
OPS-02	Resilience	Set RPO by dataset and prove restore without financial inconsistency.	Backup policy, replication lag, restore logs, post-restore reconciliation.	Restore to the declared point and reconcile wallet, payments, rounds, and wagers.	Declared RPO cannot be demonstrated or creates unreconciled transactions.
OPS-03	Transaction safety	Define idempotency scope, key, replay window, and stored outcome.	Contract fields, retention policy, duplicate test output.	Repeat identical and conflicting requests before and after timeout.	Replay creates a second effect or returns a contradictory outcome.
OPS-04	Audit	Use immutable audit events with actor, reason, before/after state, and time.	Audit schema, access controls, retention, export, and sample investigation.	Trace a privileged override from approval to downstream financial impact.	An override can be hidden, edited, or detached from its approver.
OPS-05	Data residency	Map storage, processing, backups, support access, and transfers by dataset.	Data map, regions, subprocessors, transfer basis, deletion and restore paths.	Trace one player record through primary, replica, logs, backup, and support tooling.	A copy, transfer, or recovery location is absent from the approved map.
OPS-06	Time and ordering	Standardize event time, processing time, sequence, and clock-drift handling.	Timestamp contract, sequence rules, time-sync monitoring, late-event policy.	Inject late, duplicated, and out-of-order financial events across a cut-off.	Final state changes with delivery order or local time zone.
OPS-07	Reconciliation	Reconcile independent control totals with a bounded exception queue.	Control-total definitions, frequency, thresholds, queue, owners, sign-off.	Seed missing, duplicate, delayed, and amount-mismatch records.	A break is silently netted, overwritten, or has no accountable owner.
OPS-08	Change and failover	Prove compatibility, rollback, and state convergence during release or failover.	Compatibility matrix, deployment plan, rollback criteria, failover rehearsal.	Run mixed versions, rollback after writes, and fail back to the primary.	Rollback loses accepted writes or requires undocumented manual repair.
OWN-01	Responsibility	Assign decision, delivery, evidence, and escalation ownership per component.	Signed responsibility matrix using named legal entities and roles.	Walk one change, incident, evidence request, and unresolved exception.	Any critical action has two final owners or no final owner.
OWN-02	Responsibility	Assign privileged-access approval, operation, review, and revocation.	Role matrix, approval records, emergency path, access-review output.	Grant emergency access, execute an override, and revoke automatically.	One party can approve and conceal its own privileged action.
OWN-03	Responsibility	Name cross-supplier incident authority and communication rules.	Incident RACI, severity model, contacts, decision log, notification templates.	Run an exercise where the failing dependency owner is initially unknown.	Diagnosis or player protection waits for contractual blame allocation.
OWN-04	Responsibility	Assign exit ownership for data, access, open items, and deletion.	Exit schedule, inventory, formats, timing, fees, acceptance, deletion proof.	Execute a sample export and transfer open balances, rounds, and wagers.	A supplier exit strands a financial, regulatory, or player obligation.

Architecture decision gates

Do not average these into a feature score. An unresolved authority, recovery, ownership, or exit gate makes the proposal ineligible until the buyer explicitly changes the requirement.

Every player, financial, game, wager, control, and reporting state has one authoritative record.
All five lifecycle flows converge after timeout, duplicate, reordering, dependency failure, and restore.
Journey RTO and dataset RPO are demonstrated in a timed exercise, not inferred from component marketing.
Decision, delivery, evidence, and escalation ownership are assigned to named legal entities and roles.
The operator can reconstruct balances, rounds, wagers, controls, and regulatory reports from retained records.
Data locations, transfers, subprocessors, support access, backups, deletion, and legal holds are mapped by dataset.
The selected topology has an accepted change, rollback, component-replacement, and full-platform exit path.

Continue from architecture to proof

Test every interface with the API acceptance pack, then carry wallet, resilience, migration, and contractual controls into the corresponding buyer tools.

API integration checklist Wallet protocol tests Reliability evidence Implementation plan Migration acceptance RFP security and hosting controls