Customers only: preview

Connecting player protection to decision workflows: an architecture review

A reference design for current account checks, decision gates, evidence trails and human review across iGaming operational systems.

For Compliance officers, CTOs and operational risk leads

A risk indicator on one screen is not an effective control if another system can proceed without checking it. The architectural question is where the decision is enforced, which account state it uses and what evidence survives the handover.

Executive summary

Player protection, AML and KYC share account context but have different objectives and decision processes. A unified workspace should make those distinctions visible while ensuring that relevant restrictions are enforced at the point of action. A common interface alone does not provide that guarantee.

This article proposes a reference design for evaluating integration and control behaviour. It is not a declaration that Bounty AI satisfies a jurisdiction’s legal requirements. Map the design to the operator’s licences, products and approved policies with the responsible compliance team.

1. Separate regulatory obligations from shared technical infrastructure

Keep jurisdiction and control purpose explicit

The UK Gambling Commission’s remote customer-interaction guidance describes identifying risk, acting and evaluating as an ongoing process. The MGA’s player-protection materials describe a separate Maltese framework, including responsible-gaming measures and relevant indicators. They should not be collapsed into a single universal “AI compliance” rule. UKGC guidance · MGA player protection.

Use shared identity resolution to connect relevant records, but preserve why a record exists and who may access it. An AML review is not interchangeable with an RG assessment; a completed KYC process is not a conclusion about either.

  • Record the jurisdiction and policy applicable to the workflow.
  • Distinguish source observations, risk assessments and binding restrictions.
  • Preserve the issuing system, effective time and review ownership.
  • Limit access to sensitive case information according to role and purpose.

Model the status lifecycle

Restrictions can be created, revised, reviewed or removed by authorised processes. Consumers need more than a boolean flag copied yesterday. Include effective dates and versions, and define what happens when a source cannot provide a current status. Status changes require an auditable transition, not an unexplained overwrite.

Customers only

The rest of this guide is for Bounty AI customers.

Full guides, product screens and walkthroughs are available to Bounty AI customers and pilot partners. Access is by invitation, and customer sign-in is not open yet.

  1. 2. Enforce the decision where the operation occurs
  2. 3. Test propagation, review and evidence under failure
  3. Operational outcome: accountable decisions across systems
Pilot on your data

Pilot partners get the full library when their pilot starts.

Free to read now

Account context should support responsible serviceRead the article

More in the Client library

All guides