Skip to content
Protocolzone Protocolzone

Platform modules

Inside a multi-tenant
tote and wagering platform.

Ashva is a wagering platform we built and operate for a tier-one wagering operator. This is the module inventory: what each part prices, settles, ingests or distributes, and where the hard problems sit.

It is written for a head of trading or a head of engineering assessing whether we understand the domain. It is not a product brochure — the commercial page is /products/ashva/.

Talk to the platform team How we build platforms

Trading modules

Pricing, market state and the bet lifecycle from open to settled.

Odds and probs

Price from a probability you can inspect, not from a number with no parent.

Probability-first pricing: rated prices, margin application, overround control and price movement rules across thoroughbred, harness, greyhound and sports.

Read the detail →

Betting automation

The routine bet lifecycle runs itself; people handle the exceptions.

Automating the bet lifecycle: market opening and suspension, rules-based acceptance, resulting, settlement, refunds, dead heats and protest adjustments.

Read the detail →

Risk modules

Exposure limits, acceptance rules and the current position per tenant.

Risk management

Liability tracked where it accumulates, not where it was written.

Exposure limits, bet acceptance rules and referral queues applied per tenant, per market and per customer, with correlated liability tracked across legs.

Read the detail →

Reporting and exposure

The current position, per tenant, without waiting for an overnight run.

A real-time position board per tenant: money in, current exposure and risk position, drillable from consolidated view down to a single market or customer.

Read the detail →

Data modules

Every feed in and out, and the form record both traders and punters read.

Ingress and egress

Every feed in and out, versioned, validated and replayable.

Every feed in and every feed out, contract-checked and replayable: racing data, tote pools and results inbound; partner, reporting and settlement extracts outbound.

Read the detail →

Race and runner stats

One form record, read by the punter and by the pricing model.

Form, ratings and sectional history assembled per runner, jockey, driver and trainer, served to punters in the front end and to traders as pricing inputs.

Read the detail →

Operations modules

The one calendar the whole platform trades, prices and settles against.

Schedule management

One calendar the whole platform trades, prices and settles against.

Meetings, races, fields and market timing as one calendar: scratchings, rider and driver changes, track conditions, delays and abandonments applied as they land.

Read the detail →

Distribution modules

Onboarding operators and putting a branded front end in front of punters.

Content modules

Vision, editorial content and promotional offers, configured per tenant.

Content management

Content for operators and customers within the platform.

Operator-facing and customer-facing content management within the shared wagering platform, scoped to the needs of each brand.

Read the detail →

Broadcast and streaming

Racing and sports broadcast within the platform.

An in-platform racing and sports broadcast module. Review content sources, playback surfaces and rights requirements for each operator rollout.

Read the detail →

Promotions and bonusing

Promotions and bonusing within the platform.

Promotions and bonusing within the wagering platform. Define campaign requirements, accounting boundaries and operator controls before rollout.

Read the detail →

Why it is built this way

Tenant isolation across the platform.

Retrofitting tenancy into a live betting engine is not a refactor, it is a rewrite. Building it in from the start is what produced the outcomes below.

  • One estate instead of one per tenant

    Multi-tenancy cut infrastructure cost substantially against running each tenant on its own infrastructure. Consolidation economics, not a feature list.

  • One console instead of per-tenant admin

    A single management portal reduced operational cost, because tenant administration stopped being a task repeated once per brand.

  • The live position, in one place

    One reporting surface shows money in, exposure and risk position across tenants as it happens, rather than reconciled overnight. The same surface makes fraud, VIP and bonus-hunter cohorts identifiable instead of discovered after the fact.

The pattern transfers. Multi-tenant consolidation, a single operational console and cohort or anomaly identification are domain-independent — which is the honest bridge from wagering into trading, insurance, government and retail work.

Assessing a platform build?

We will go through how this engine handles the part you are worried about, including where we would not repeat the decision.

Start a conversation Platform to Platform