Skip to content
Protocolzone Protocolzone

Case study · Sports & Gaming

Consolidating many wagering tenants onto one platform

One multi-tenant platform, one management console, one real-time reporting surface across all tenants — with player-risk cohorts identifiable as they happen rather than after the fact.

Delivered for a tier-one wagering operator, through Platform to Platform and 24×7 Operations Desk.

The challenge. Every tenant ran on its own infrastructure, with its own administration and its own reporting. Cost scaled linearly with tenant count and nobody could see consolidated risk.

A wagering operator running multiple brands had a structural cost problem. Each tenant sat on its own infrastructure, was administered separately, and reported separately. Adding a brand meant adding a stack.

We built and now operate the multi-tenant platform that replaced that arrangement.

The problem with one stack per tenant

Per-tenant infrastructure looks reasonable at two tenants and stops being reasonable somewhere around five. The costs compound in three directions at once:

Infrastructure scales linearly with brands. Every tenant carries its own compute, its own datastores, its own redundancy. Peak capacity has to be provisioned per tenant even though tenants peak at the same moment — race day is race day for all of them.

Administration scales linearly too. A configuration change, a market suspension, a compliance update, a release: each has to be applied per tenant, by someone, correctly, every time. That is a per-tenant cost that shows up as headcount rather than infrastructure spend, which makes it easier to miss.

Risk becomes invisible. This is the expensive one. If each tenant reports separately, nobody sees consolidated exposure. A player active across several brands is several unrelated players. Position is reconciled overnight, which means the information arrives after the window in which you could have acted on it.

Why it is hard to fix

Retrofitting tenancy into a live betting platform is not a refactor. Tenant identity has to reach every layer — pricing, risk, settlement, wallet, reporting, content — and it has to be enforced rather than conventional. Get it wrong in one query and one tenant sees another tenant’s liabilities.

It also has to be done without downtime, against a platform that is settling real money, under jurisdictions that do not accept “we were mid-migration” as an explanation.

For platforms expected to serve multiple organisations, that experience makes tenant isolation an early design decision across request paths, background jobs and storage. The isolation model still depends on the operating requirements.

What we built

A single multi-tenant platform. Tenant isolation enforced at the data layer, per-tenant configuration and white-labelling from one deployment. Brands differ in presentation, market offering and jurisdictional rules; they share the engine.

One management console. Operators administer every tenant from a single surface — configuration, markets, suspensions, releases — instead of repeating the same operation per brand.

One real-time reporting surface. Live money in, exposure and risk position across all tenants, visible as it happens. Not an overnight batch. This is the part that changed how the operations team works: position became something you watch rather than something you receive.

Player-risk cohort identification. The same reporting layer flags fraud signals, VIP behaviour and bonus-hunting patterns as cohorts. Those players were always in the data; they were not previously identifiable while it still mattered.

Results

Infrastructure cost fell substantially against the per-tenant baseline. Consolidation onto shared infrastructure removed the linear relationship between brand count and infrastructure spend.

Operational cost fell with the single management console. One operation instead of N, and correspondingly fewer opportunities for one tenant to drift out of configuration with the others.

Operational efficiency improved across the tenant estate. Consolidated real-time reporting replaced per-tenant reconciliation, and the risk team acts on position during the event rather than reviewing it afterwards.

Player-risk cohorts became identifiable in-flight — fraud, VIP and bonus hunters surfaced as they behave, not in a retrospective audit.

We continue to develop, deploy and operate the platform.

Where this transfers

None of the above is specific to wagering. The shape of the problem — many tenants, per-tenant infrastructure, no consolidated view, anomalous behaviour that is only visible in aggregate — recurs across every domain we work in.

Mining telemetry across sites. Insurance claims across brands or underwriters. Government service delivery across agencies. Trading and exchange across venues. Retail across store estates. The engineering is the same: enforce tenant isolation, consolidate the operational surface, and make cohort and anomaly identification real-time rather than retrospective.

Engagement facts

Client
Tier-one wagering operator
Industry
Sports & Gaming
Service lines
Platform to Platform, 24×7 Operations Desk
Evidence
Anonymised delivery
Jurisdictions
NSW, Victoria, Northern Territory

Read next

The practice behind this.

Service lines

Use cases

Platforms involved

Facing something like this?

We can go considerably deeper on the architecture in a conversation than an NDA lets us go on a public page.