Watch the platform work

LaunchBrandingGamesBonusesPlayersFinancialsAuditOnboarding

Launch: Provision a casino. The recording follows a new brand from an empty environment to a working player lobby.

1. LaunchLength 0:30

   Provision a casino. The recording follows a new brand from an empty environment to a working player lobby.

   What to watch for

   • The environment is created by the platform rather than assembled by an engineer.
   • The game catalogue is already connected when the lobby first renders.
   • The brand's colours and logo are in place before anybody writes any front end code.

   This is the provisioning path end to end. It starts from an approved application and finishes on the player facing front page of a working casino brand: the lobby, the game tiles, the welcome offer and the payment routes all live in one environment that did not exist at the start of the recording.

   Nothing in the sequence is assembled by hand. The platform creates the environment, wires the wallet, connects the aggregated game catalogue, applies the brand and hands over the back office. The operator's part is the application and the decision to launch, not the build.

   The still frame

   The poster shows the front page of a demonstration casino brand: a dark lobby with slot tiles behind a large headline, a welcome offer, a call to action into the games hall, a row of game studio logos, and a strip of demonstration figures along the bottom.

   Two clocks, not one

   Provisioning takes hours. Getting to a live, trading casino also depends on licence approval, payment onboarding and content agreements, which we sequence with you.

   Demo data

   Every figure on screen belongs to a demonstration environment. Player counts, balances and jackpot totals are test values, not results from a trading casino.

2. BrandingLength 0:30

   Customise without code. Brand Studio builds the look from the brand's own colours and publishes it without a release.

   What to watch for

   • The logo and favicon are replaced from the same panel, with the size limits stated on screen.
   • The player lobby beside the editor updates as the brand changes, so nothing is published blind.
   • A readiness indicator tracks what is still missing before the brand is complete.

   Brand Studio sits in the settings area of the back office, with the live player lobby beside it. On the left, the operator uploads a logo for the site header, a favicon for the browser tab and a background for the sign in screen. On the right, the lobby renders exactly what a player would see: the promotional banners, the search bar, the provider filter, the category chips and the game collections underneath.

   The work that normally needs a front end team is a form here. Colours, assets and layout are set in the panel, checked in draft, and published when they look right. A setup checklist tracks what is still outstanding, so an operator can see how close the brand is to finished rather than guessing.

   The still frame

   The poster shows the Brand Studio panel on the left, with logo and favicon slots and a sign in background upload, next to a live preview of the player lobby with promotional banners across the top, category filters and a row of game tiles.

   Demo data

   Every figure on screen belongs to a demonstration environment. Player counts, balances and jackpot totals are test values, not results from a trading casino.

3. GamesLength 0:30

   Manage the catalogue. Studio visibility, lobby coverage and player facing collections, controlled from one screen.

   What to watch for

   • Studio visibility is a switch, and turning a studio off removes it from the player lobby immediately.
   • The counters separate the full aggregated catalogue from what is actually visible in the lobby.
   • Collections are built on top of automatic curation rather than instead of it.

   The Games screen is where an operator decides what its players can actually see. A counter strip across the top separates the titles in the lobby from the titles available in the aggregated catalogue, and the studios connected from the studios currently visible. Those are different numbers on purpose: the catalogue is what we can reach, and the lobby is what this brand has chosen.

   Below it, the studio list carries a game count and a visibility switch for each supplier. Switching one off pulls its titles out of the player lobby without touching the integration underneath. At the bottom, collections group titles into the named rows a player scrolls through. New games arrive categorised and placed automatically, so the collection tools are there to express an opinion rather than to do the filing.

   The still frame

   The poster shows the Games screen: a row of catalogue counters across the top, a searchable studio list with per studio game counts and visibility switches, and a panel underneath for building the collections shown in the player lobby.

   Demo data

   Every figure on screen belongs to a demonstration environment. Player counts, balances and jackpot totals are test values, not results from a trading casino.

4. BonusesLength 0:30

   Configure incentives. Reward type, wagering terms, expiry and per player limits are set as rules the engine enforces.

   What to watch for

   • Wagering terms and stake caps are fields on the campaign, not a paragraph in the terms and conditions.
   • Game eligibility defaults to every game at full contribution, and narrowing it is a deliberate act.
   • Grants per player and a maximum bet while a bonus is active are set before the campaign can go live.

   A campaign is built in one form, in two halves. On the left, the identity and the reward: an internal code, the operator facing name, whether the reward is a deposit match, a fixed amount or free spins, and the ceiling on what it can pay out. On the right, the terms that decide whether the campaign is safe to run: the wagering multiplier, the expiry in days, how many grants one player can hold, and the maximum bet allowed while the bonus is active.

   That right hand column is the abuse control, and it is not optional paperwork. Because the engine enforces the terms as play happens, a bonus cannot be farmed by a player raising stakes the moment the balance is credited. Game eligibility starts at every game contributing in full, and an operator narrows it only where it has a reason to.

   The still frame

   The poster shows the Bonuses screen with a campaign in progress: campaign identity and reward fields on the left, including bonus type and maximum bonus amount, and wagering terms on the right covering multiplier, expiry, grants per player and maximum bet while active.

   Demo data

   Every figure on screen belongs to a demonstration environment. Player counts, balances and jackpot totals are test values, not results from a trading casino.

5. PlayersLength 0:30

   Manage the player lifecycle. Account state, compliance tier, verification status and the audit history of every check.

   What to watch for

   • Account state, tier, verification and screening status sit together at the top of the record.
   • The verification attempt has its own timeline, so a stalled check is visible rather than inferred.
   • Every view of a player's document is itself an audited event with a named actor.

   The player record opens on the facts a reviewer needs before doing anything else: whether the account is active, which compliance tier the player sits in, whether identity checks have cleared, what the screening result was, whether two factor login is on, and whether the email is confirmed. Those are separate states, and the platform shows them separately rather than collapsing them into one word.

   Underneath, the record splits into identity, documents, the current review, the decisions taken and the raw data behind them. The verification attempt carries its own timeline from queued to pending to reviewed, with the time spent at each stage. The audit list at the bottom records who looked at what, so opening a player's identity document is an event with a name attached rather than an invisible action.

   The still frame

   The poster shows a player record: the player name with status chips for account, tier, KYC, AML, two factor and email across the top, a tabbed view underneath, a verification attempt timeline running from queued to reviewed, and an audit list of recent identity events.

   Demo data

   Every figure on screen belongs to a demonstration environment. Player counts, balances and jackpot totals are test values, not results from a trading casino.

6. FinancialsLength 0:30

   Control wallets and transactions. Deposit activity, the currency everything settles in, and how a payment becomes a balance.

   What to watch for

   • Deposited, failed, paid and net are four separate figures, and the screen keeps them apart.
   • Whatever a player pays with, the brand's books are kept in one settlement currency.
   • The rules for price movement between payment and confirmation are stated on the screen, not buried.

   The Deposits screen answers the question a finance lead asks first: what did players pay, what actually landed, and what is left after costs. Deposited, failed, paid and net are shown as four figures rather than one, because the difference between them is where reconciliation problems usually hide. Below it, a breakdown of what players paid with, by asset and network.

   The lower half is an explainer the platform prints for the operator: the player pays in any supported coin, the crypto processor converts it, the balance lands in the brand's settlement currency, and there is only ever one currency to reconcile. It also states plainly how price movement between payment and confirmation is handled, and whether this casino adds anything on top. Both are platform defaults, and the screen says so instead of leaving an operator to find out later.

   The still frame

   The poster shows the Deposits screen: a row of totals for deposited, failed, paid and net, a breakdown of what players paid with by asset and network, and a numbered explanation of how a crypto payment becomes a player balance.

   Demo data

   Every figure on screen belongs to a demonstration environment. Player counts, balances and jackpot totals are test values, not results from a trading casino.

7. AuditLength 0:30

   Trace every platform event. Administrative actions, security events and system configuration changes in one stream.

   What to watch for

   • Player actions, staff actions and system actions share one stream and one clock.
   • Every entry carries who did it, in what role, from where and on what device.
   • A withdrawal appears as a sequence of separate events rather than a single outcome.

   The audit trail is one list, in time order, covering administrative actions, security events and system configuration changes together. A withdrawal does not appear as a result. It appears as the sequence that produced it: requested, approved, processing, payout verified, sent. Each of those is its own row, with its own timestamp, so the gap between any two of them is measurable.

   Every row names the actor and the role behind it, and separates a staff member from the player from a system process such as the payments integration. Alongside that sits the country and city, the network address and the browser and operating system. Filters narrow the stream by type or by actor. This is the record that regulator evidence packs are built from, which is why it is append only and why nothing on the platform writes to it selectively.

   The still frame

   The poster shows the Audit Trail screen: a time ordered list of withdrawal, deposit, login and authentication events, each row carrying a timestamp, an event type, the actor and role, the country and city, the network address and the browser and operating system.

   Demo data

   Every figure on screen belongs to a demonstration environment. Player counts, balances and jackpot totals are test values, not results from a trading casino.

8. OnboardingLength 0:30

   Verify identity at signup. The operator application runs through identity checks before a casino can be created.

   What to watch for

   • The application is a staged flow, and the current stage is always named on screen.
   • Verification splits into an individual route and a business route, each with its own checks.
   • The casino cannot be created until the identity step clears, so the gate sits before the build.

   Onboarding is the operator's own path onto the platform, not a player journey. The application runs as a staged flow: apply, confirm the email address, verify identity, complete the owner profile, pass platform review, then launch. Progress is shown as a bar with the current stage named, so an applicant always knows what is outstanding and who is waiting on whom.

   The verification stage is the gate. An applicant chooses the individual route, which runs know your customer checks, or the business route, which runs know your business checks, with an indication of how long each usually takes. Identity has to clear before casino creation unlocks. Doing it in this order is the point: the platform never provisions an environment for someone it has not yet verified, and the verification result is what later steps are checked against.

   The still frame

   The poster shows the operator application: a five stage progress bar with the verification stage current, and an identity verification panel offering an individual route with know your customer checks and a business route with know your business checks.

   Demo data

   Every figure on screen belongs to a demonstration environment. Player counts, balances and jackpot totals are test values, not results from a trading casino.