This is a sports & gaming problem we approach through our Platform to Platform service line.
The problem
You sell tote bets and you sell fixed odds, and internally they are two platforms. The tote side sends bets to host pools and settles on the dividends those hosts declare. The fixed-odds side prices your own book and carries your own risk. They were built at different times, probably by different suppliers, and they each hold a version of the customer.
The customer does not see two systems. They see one account, one balance and one bet history, and they expect a scratching in the last race to behave consistently whichever product they backed it in.
Between the two sits a reconciliation. Someone runs it, usually overnight, usually in a spreadsheet, and it is the reason your finance team knows yesterday’s position rather than today’s.
Why it’s hard
Two ledgers, one customer. A balance is only a balance if one system owns it. When two do, the answer to “what can this customer stake right now” depends on which system you ask and how recently they spoke. The same split shows up on your side of the ledger as a liability position that has to be assembled from two sources before anyone can act on it, which means it is always slightly historical.
The routing decision sits in the bet path, not in a nightly job. Whether a given bet should go out to a tote host, go out to a fixed-odds operator, be retained and settled in-house, or be split, depends on the tenant, the bet type, the market and the liability already on the book. That is a decision taken while the customer is waiting, against state that is moving. Two separate systems cannot take it at all — each one only knows its own half of the position.
A scratching lands in one system and not the other. A late scratching has to propagate to displayed markets, to bets already accepted, to the fixed-odds prices derived from the same field, and to the treatment applied by whichever host a bet was bypassed to. Handling it correctly in one product and approximately in the other is how a customer ends up with two different answers to the same question, and how a trading desk ends up with two different views of its exposure.
Host-declared dividends are data you do not control. Bypassing to a host means accepting that host’s pool close, its deductions, its dividend declaration and its scratching treatment, then mapping all of it back onto your bet types, your bets and your customers. Amendments after declaration are part of the normal case, not the exception. None of that arithmetic is yours, which makes the integration harder rather than easier — you have to be able to reproduce a settlement you did not compute.
One wallet, two settlement clocks. Fixed odds settles on result. A bet routed to a tote host settles when the dividend is declared, which may be minutes later and may be amended after a protest. A unified wallet has to hold both without letting a customer spend a balance that a dividend amendment is about to change.
Exotics and multi-leg bets compound every one of the above. One leg changing touches every combination that includes it, so the combination count is the multiplier on all of the work above rather than a separate feature.
Same-race multis, on the same engine
A same-race multi combines outcomes within a single race, so the legs are correlated by construction. If a favourite wins, the probability distribution over the remaining placings shifts. Pricing the combination by multiplying independent win and place probabilities ignores that, which produces prices that are systematically generous on some combinations and unsellable on others.
The requirement this creates is that same-race multi prices derive from the same probability set as the win market, with the correlation between legs modelled rather than assumed away. Pricing each leg as an independent event is the failure mode, and it is a pricing problem before it is an engineering one. The engineering requirement that follows is single-source probabilities: if the multi price and the win market it derives from come from different places, they will drift into disagreement, and the arbitrage is on your side of the book.
How we approach it
The routing decision is the product. A rules engine evaluates every bet and chooses one of four paths: bypass to an external tote host, bypass to an external fixed-odds operator, retain the risk and settle in-house, or share the risk dynamically. Routing is configuration, evaluated per bet against the tenant, the bet type, the market and the current position. This is the component that makes one platform viable for both products, and it is the component that cannot be added later without touching every path that moves money.
Bet types modelled properly, not as variations on one record. Win, place, quinella, trifecta and first four have their own combination generation, their own leg semantics and their own settlement path. Modelling a tote bet as a fixed-odds bet with a variable price is the shortcut that looks economical for a quarter and then makes exotic settlement impossible.
Settlement against declared dividends, reproducible on demand. For bypassed bets we consume the host’s declaration and amendments and settle against them, writing settlement to the ledger as a transaction set per bet and per leg. When someone queries a payout months later, the answer is reconstructed from the declaration we received and the rules in force at the time, not recalculated from today’s data.
One wallet and one bet history. Multi-currency wallets with settlement hooks for both models, so the customer’s balance, transaction ledger and history come from one place. This is the part that removes the overnight reconciliation, and it is the least visible piece of work on the project.
One set of scratching and amendment rules. Scratchings, gear changes, protests and amended results enter once and fan out to pricing, to bets already accepted, to settlement and to reporting. The alternative — each subsystem consuming the feed independently — guarantees eventual disagreement.
Per-tenant policy on shared machinery. Two brands on the platform can run different price margins, different market availability and different routing policy against the same engine and the same probability set.
What we do not do. We do not operate a tote pool. We do not compute dividends, commingle pools across hosts or apply breakage — those belong to the host, and any vendor telling you otherwise is describing a different product. We also would not migrate the fixed-odds book and the tote product in the same cutover: bypassed tote settlement is auditable against a declared dividend, which makes it the safer half to move first and verify against the incumbent in parallel.
What it takes
Host access, and the commercial agreements behind it. Bypassing bets to a tote host is a commercial arrangement before it is an integration. If those agreements are not in place, the platform can route the same bets into in-house risk instead, but that is a different business decision and it should be made deliberately rather than discovered at go-live.
A feed carrying declarations and amendments, not just prices. Declared dividends, deductions applied by the host, and post-declaration amendments. Without amendments you have a settlement path that is correct until the first protest.
A written routing policy per bet type and per tenant. Which bets bypass, which are retained, where the split sits, and what happens when the host is unavailable. This needs your trading and compliance functions, not your engineering team, and it needs to happen early because settlement is built against it.
Parallel running. Expect a period where both systems settle the same bets and the outputs are compared. That is not wasted effort, it is the evidence you will want when a regulator or a customer asks.
Bet type mapping. Every bet type you offer today has to be mapped to a host pool type, a fixed-odds market, or both, with the settlement path stated for each. This inventory is usually the first thing that reveals which products nobody has actually specified.
Where this has been done
This is a shipped reference. We built and continue to operate a multi-tenant tote and fixed-odds betting platform in production, covering per-bet routing to external tote hosts and fixed-odds operators, in-house risk retention and settlement, exotic and multi-leg bet types, and fixed-odds pricing on the same engine and the same wallet.
Where the same platform runs across several brands, the consolidation economics are covered separately in our multi-tenant use case.