Sportsbook & trading
A book that prices correlation and caps its own liability.
Odds from multiple providers under a pluggable pricing strategy, same-game multis re-priced off a real correlation model instead of a naive product, settlement from a live results feed, and a trading sweep that suspends a selection at its liability cap without a trader watching it.
Pricing
Same-game multis, priced properly
Legs inside one fixture are not independent. "Team A to win" and "Team A over 2.5 goals" move together, so multiplying their prices — which is what a naive accumulator does — overstates the odds and hands the customer a positive-expectation bet. Ledgerfield re-prices those legs off a pairwise correlation matrix, takes the correlation-adjusted joint probability as fair odds, and applies the book margin to that.
// naive product of the two leg prices naive_odds 6.40 // pairwise correlation lifts the joint probability… correlation_factor 1.18 implied_prob 0.1844 // …so the fair price is materially shorter, before margin correlated_odds 5.15
- Correlation is per market-type pair, not a flat fudge factor, with a documented default for pairs that have no specific entry.
- Joint probability is capped at 0.95 so a heavily correlated slip cannot round its way to a certainty.
- The naive price is returned alongside the offered one — your trading team can see exactly what the correlation model took out, on every slip.
Worth asking every vendor"Show me the correlation factor you applied to this slip." A book that cannot answer is multiplying prices, and a customer who has worked that out is the most expensive customer they have.
Trading protection
The book caps itself
Liability is not a nightly report. A sweep runs every 5 minutes, suspends any selection that has reached its liability cap, and re-opens the ones that fall back under it — so exposure is bounded whether or not anyone is at a desk.
Liability sweep · 5 minutes
Selections suspend at their cap and re-open when exposure drops. The sweep is idempotent and non-overlapping, so a slow run never doubles up on the next tick.
Markets close at kick-off
A fixture that has started stops accepting pre-match bets, and the sweep is explicitly prevented from re-opening it — a case that is easy to get wrong once the two mechanisms exist side by side.
In-play drift is clock-driven
Live price movement is advanced by the scheduler, never by an incoming request. Anything a public endpoint can advance, a poller can advance on purpose and cash out against.
A real defect we found and fixed, stated because it is instructiveThe in-play price walk originally ran inside two public unauthenticated GET requests. An anonymous poller could advance the market at will and cash out against its own movement — measured at +52.45% risk-free before it was moved onto the clock. We are telling you about it because "we have never had a bug" is not a claim any honest platform makes, and how a vendor handles the ones they find is the thing actually worth evaluating.
Odds & settlement
Providers are pluggable. So is pricing.
Two providers, one interface
The Odds API and SportMonks both implement the same provider contract. Adding a third is a class, not a migration — and pricing is a separate, swappable strategy on top of whatever the providers return.
Best price or prioritised book
Ship the best available price across bookmakers, or follow a prioritised bookmaker order. Both are strategy implementations; re-pricing stored odds under a different strategy costs zero provider credits.
Settlement from a results feed
Fixtures settle from the live results provider. Past a defined grace window a synthetic fallback resolves the fixture rather than leaving customer money in limbo indefinitely — the grace window is the point, not the fallback.
Leg grading is explicit
Void legs drop out of an accumulator and the return they carried drops with them; a dead leg kills the slip. Both rules apply identically to settlement and to cash out, which is where books typically diverge by accident.
System bets
Trixie through Lucky 63 — and where the maths actually lives
Eight permutation types on top of singles and accumulators: Trixie and Patent at three legs, Yankee and Lucky 15 at four, Canadian and Lucky 31 at five, Heinz and Lucky 63 at six. The slip shows the line count and the total stake before it is placed.
| Type | Legs | Folds included | Lines |
|---|---|---|---|
| Trixie | 3 | doubles, treble | 4 |
| Patent | 3 | singles, doubles, treble | 7 |
| Yankee | 4 | doubles → 4-fold | 11 |
| Lucky 15 | 4 | singles → 4-fold | 15 |
| Canadian | 5 | doubles → 5-fold | 26 |
| Lucky 31 | 5 | singles → 5-fold | 31 |
| Heinz | 6 | doubles → 6-fold | 57 |
| Lucky 63 | 6 | singles → 6-fold | 63 |
The nuance a CTO will care about, and most vendors would leave you to findThe
permutation expansion runs in the widget layer, not the backend. The
client works out the k-combinations and places the resulting lines through the ordinary
bet endpoint — there is no bet_type: "lucky63" the API accepts on its own.
That is a defensible design and it keeps the settlement path simple, but it means
an operator writing a bespoke front end either reuses our widget or
re-implements the combination maths. If you had assumed otherwise you would have
found out in integration week, so we are telling you in evaluation week.
What the sportsbook does not doThere is no live-dealer product, no in-house trading-desk tooling beyond the automated sweep, and no bet-broker or exchange model. Odds come from third-party providers under our pricing strategies — Ledgerfield is not an odds compiler and does not claim to be one.
See the correlation model price a real slip.
We will build a same-game multi live against the production API and show you the naive price, the correlation factor and the offered price side by side.