Part of the Ashva module inventory — a multi-tenant tote and fixed-odds betting platform we built and operate. The engineering practice behind it is our platform build and integration service line.
The question that decides whether a multi-tenant wagering platform is actually multi-tenant: how long does it take to bring the next operator live, and does doing so require a release?
If onboarding needs a code change, the platform has one tenant and a set of special cases.
The tenant record is the unit of configuration
An operator is a tenant record holding jurisdiction, product entitlements, limits, branding, commercial terms and credentials. Every service scopes data access by tenant at its own boundary. Isolation enforced at the presentation layer is not isolation, it is a filter waiting to be forgotten in one query.
Entitlements enforce the licence
Codes, markets, bet types and modules available to an operator are held centrally and enforced by the platform. An operator cannot be accidentally configured into a product its licence does not permit, because the constraint lives with the tenant record rather than in an operations runbook.
Connectors absorb partner variation
Aggregators and downstream operators each have their own idea of what a bet message looks like. Those differences are handled in per-tenant connectors that translate to a stable internal contract. The alternative, conditional logic in the core wagering path keyed on partner identity, is how a platform becomes unreleasable.
Reporting cuts both ways
Each operator sees its own turnover, settlement, exposure and activity. The platform holder sees the consolidated position across operators, which is the only place correlated exposure across brands is visible. Both views come from the same reconciled data, described in the reporting and exposure module.
What this module does not do
It does not price, accept or settle bets. It decides who is on the platform, what they are allowed to offer, how their interface is shaped and how their activity is reported.