Configuration dependent
Jurisdiction
Policies set per brand and market: reality checks, affordability thresholds, risk scoring and trading limits, changed in configuration, not code.
The problem
Every market has its own rules. Hard-code them and every new market is a release; leave them loose and every audit is a scramble.
What the platform does
Policies are configuration. Each brand carries its own reality-check, affordability, risk-scoring, loyalty and trading policy, and the platform enforces them at the point each decision is made.
How it works
Follow it through.
- Brand policy
- Platform API
- Controls
- Every decision
- 01
Agree the operator’s licence position and the markets it will serve.
- 02
Set the brand’s policies in platform administration.
- 03
The API applies those policies to every decision for that brand.
- 04
Policy changes are recorded like any other staff action.
Controls
- Reality-check interval and whether players can switch it off
- Affordability threshold and rolling window
- Risk-scoring model and bands
- Trading limits
Operator experience
Brand configuration screens set each policy per brand, so two brands on one platform can run different rules.
Integration points
- Geolocation provider, where the market requires it
- Identity and exclusion schemes per market
Audit & reporting
Configuration changes are staff actions, written to the audit record.
Software is evidence
The real interface.
Not a mock-up. This is the implemented screen, populated by a test environment.
Related capabilities
Let’s talk about what you’re building.
Tell us what you’re building. We’ll tell you plainly what the platform does today and what it would take.