Solutions / PAM

Who the player is, to the whole platform.

One authority for identity, account lifecycle, standing, segments and consents. Every money-adjacent service asks it before acting, and none of them keeps its own copy.

Authority over Account standing
Personal data Vault references only
Staleness bound Explicit
What it owns

PAM, precisely

01

Account lifecycle

Registration through closure, with reason codes and named authority evidence at every transition.

02

Pseudonymous reference

Services see a player reference, never a name. Personal data lives in a purpose-scoped vault behind its own access control.

03

Standing artifact

One versioned document — status, gates, limits, segments — consumed by wallet, cash desk, bonus and KYC through a single read.

04

Segments

Behavioural and commercial tags that promotions and cashback consume. Computed here, and nowhere else.

05

Consents

Marketing, privacy and terms recorded against the document version accepted, so you can prove what was agreed and when.

06

Data-subject rights

Access and erasure orchestrated across every context, honouring legal hold and financial retention rather than fighting them.

Contracts it exposes
ReadGetAccountStanding
CommandsRegisterPlayer · SetLimit · ApplySelfExclusion · CloseAccount
EventsPlayerRegistered · AccountStatusChanged · SegmentAssigned · ConsentRecorded
What it never does
Hold money or compute a balance
Decide a KYC outcome
Let a downstream service cache its own copy of standing

Every module on this platform is defined as much by what it is forbidden to do as by what it owns. That is what makes a boundary auditable instead of aspirational.

A gate applied here applies everywhere, because nothing downstream keeps its own version of who the player is.

See it running

Every module here surfaces as screens an operator uses on a Monday. Ask for a walkthrough of the ones that decide your week.