The Case for In-House Trading Infrastructure

The default way to stand up a pricing and trading operation is to assemble it. License a data feed from one vendor, a pricing engine from another, a risk system from a third, and write the glue code that holds them together. It is faster to launch and the costs are predictable.

It also caps what the resulting business can ever be. Rimble built all five layers itself, and the reasoning is worth setting out, including the cases where it is the wrong decision.

What an Assembled Stack Actually Costs

The problems with a vendor-assembled stack are not primarily about quality. Individual components are often perfectly good. The problems are structural.

The first is that a licensed pricing engine gives you the same prices as everyone else licensing it. You can apply a different margin, but the underlying view of the world is shared with your competitors. In a business where the accuracy of the probability estimate determines profitability, buying that estimate from a vendor means buying the thing you are supposed to compete on.

The second is that attribution becomes impossible. When a book loses money over a month, the question is whether the data arrived late, the model was miscalibrated, or the risk limits were wrong. With three vendors and a glue layer, nobody can answer this. Each party has visibility into its own component and an incentive to point at the others. Meanwhile the loss keeps happening.

The third is latency, which compounds across hops nobody controls. Every boundary between systems adds delay. For pre-match pricing this is tolerable. For in-play, where prices need to reprice continuously against a live event, it is disqualifying.

The fourth is licensing. Data agreements frequently restrict what may be derived from a feed and redistributed. A firm may find that the derivative markets it most wants to offer are contractually unavailable, not technically infeasible. This limit is invisible until you hit it, and then it is immovable.

Layer One: Ingestion

Rimble takes data from official league and federation sources rather than scraping or reselling.

The reason is that scraped data is not merely delayed, it is delayed in a biased way. Latency is worst during periods of dense activity, which is precisely when prices need to move most and when the cost of a stale price is highest. A feed that is reliable when nothing is happening and unreliable when everything is happening is close to worthless for in-play pricing.

Official feeds also carry defined semantics for edge cases: how a substitution is recorded, what happens on a technical pause, how a disputed result is amended. Downstream summaries flatten these distinctions, which forces a model to infer what actually happened from an ambiguous description. Rimble currently ingests across esports, Formula 1, cricket, and kabaddi at a volume of more than 50,000 events priced annually.

Layer Two: Simulation

Each sport gets a purpose-built model rather than a shared engine with different parameters loaded in.

This is not stubbornness. The structures genuinely have nothing in common. A Counter-Strike round economy, where the outcome of one round determines what both teams can afford to buy in the next, does not resemble a cricket innings, where pitch deterioration over five days changes how the surface plays. A Formula 1 race, with tyre degradation and pit strategy interacting across a fixed lap count, resembles neither. A generic model with sport-specific coefficients would have to abstract away exactly the dynamics that make each sport predictable.

The output is not a line. It is a joint distribution over outcomes, produced by simulating the event a large number of times and retaining the full result set. Everything downstream is a query against that distribution, which is the point developed in our piece on price origination.

Layer Three: Pricing and Quoting

This layer converts the distribution into prices, and it does more work than it appears to.

Any individual market is an expectation computed over the simulation output, which is why market depth comes close to free once the model is right. Rimble publishes 50 or more markets per esports match, 40 or more per Formula 1 race, 30 or more per cricket match, and 20 or more per kabaddi match. Those are not separately built products.

The correlation engine lives here too. Combos have to be priced from the joint distribution rather than by multiplying independent legs together, which is what makes unrestricted same game parlay pricing possible on the feed side and correlated basket quoting possible on the trading desk. Inventory skew is applied at this layer as well, so that quotes lean toward reducing exposure the book already carries.

Layer Four: Risk and Inventory

Once a firm commits its own capital, position management stops being a reporting function and becomes part of the pricing loop.

The critical requirement is that exposure be aggregated with correlation accounted for. Positions across several contracts on the same match are not independent, because they resolve together. A book showing twenty separate positions may in fact hold one concentrated bet on a single outcome. Summing notional across positions will not reveal this. Only measuring exposure against the joint distribution does.

Because the risk layer reads from the same simulation output that produced the prices, this happens natively rather than through a reconciliation process between systems that model the world differently.

Layer Five: Distribution and Execution

The final layer delivers prices two ways: the customer-facing API that operators integrate, documented in the API reference, and the quoting interface the trading desk uses to respond to requests.

Both read from the same pricing engine. A sportsbook taking the feed and a counterparty asking the desk for a price on the same event are seeing the same underlying view. There is no separate trading model that disagrees with the published feed, which matters both for consistency and for the firm's ability to reason about its own positions.

What Ownership Buys

Attribution is the largest practical gain. When results diverge from expectations, the entire path from source event to quoted price is inspectable by one team. Diagnosis takes hours rather than a support ticket cycle across three vendors.

Iteration speed follows. A model improvement ships when it is ready, not when it reaches the top of a vendor's roadmap. Over several years this difference compounds more than any single modeling decision.

There is no external ceiling on derived markets. If the simulation can answer a question, the question can be quoted. This is the direct reason the desk can price long-tail contracts with no reference price anywhere.

And the edge is genuinely proprietary. Six years of pricing 50,000-plus events a year against settled outcomes produces a well-tested view of where the models are reliable and where they are not. That calibration record is only meaningful because the models are Rimble's own.

When Not to Build This

Building five layers is expensive, slow, and only justified under a specific condition: pricing has to be the product.

A firm competing on distribution, brand, user experience, or customer acquisition should license its pricing and put engineering effort where it actually differentiates. Building a simulation stack to support a business that wins on other dimensions is a costly detour, and the resulting models will lose to specialists.

The calculation changes when the accuracy of the price is the thing being sold, or the thing capital is being committed against. At that point every layer you do not own is a constraint on the business, and the fact that it is someone else's constraint does not make it any less binding.

Frequently Asked Questions

1. What does Rimble's in-house infrastructure include?

Five layers, all built and operated by Rimble: data ingestion from official league and federation sources, per-sport simulation models that produce a joint distribution over outcomes, a pricing and quoting layer including the correlation engine, position and risk management with correlation-aware limits, and the distribution layer covering both the customer API and the trading desk's quoting interface.

2. Why does owning the data ingestion layer matter for pricing?

Scraped or resold data is delayed, and the delay is biased. It is worst during periods of dense activity, which is exactly when prices need to move most. Official source data from leagues and federations arrives with known timing and defined semantics for edge cases, so the model is not inferring what happened from an ambiguous downstream summary.

3. When is building trading infrastructure in-house the wrong choice?

When pricing is not the product. A firm that competes on distribution, user experience, or customer acquisition should license pricing and put its engineering effort where it differentiates. Building all five layers is only justified when the accuracy of the price is the thing being sold, or the thing capital is being committed against.