Foreline Line Intelligence

Foreline/Products/Player Radar

Product 2 · Player Radar

Judge accounts by price, not by outcomes

Every bet an account places is compared with our fair closing price of exactly the line it took. An account that systematically beats that close is sharp — whether or not it happens to be up on you yet. That is why a first call takes 10–20 bets instead of thousands.

CLV vs our close Any line the customer took Two-component flag No PII
Request trial See pricing → Or start with a retro-audit: the same scoring, run walk-forward on your own history.
How it scores

CLV against a close you can audit

Closing-line value is the standard measure of sharpness. What it usually lacks is a close worth measuring against: one that exists for the exact line the customer took, is de-vigged, and cannot be revised after the fact.

You post the bets An anonymised account ID and the bet parameters — event, market, line, side, price, stake, timestamp. No names, no KYC, no payments, no IPs, no devices.
We reprice each bet against our close The fair closing price of that exact line, from the surface. Lines the reference market never quoted are repriced from the ladder tables rather than dropped — which is where most CLV tooling loses the sharpest part of the flow.
Two components have to agree A CLV component (how far the account beats fair) and a signed component (how consistently it is on the right side). A single lucky streak moves one component; a professional moves both.
You get a continuous score and your own threshold Returned live from POST /v1/score: a score with an anytime-valid confidence (0–1) — a fair account has at most a 1−c chance of ever reaching confidence c, however often you poll. So you read it after every bet and act on your own level instead of waiting for a fixed bet count. The components stay exposed, so your risk team sees why.
The number that matters

False positives, measured on a real null

A detector that flags aggressively is easy to build and expensive to run — every false positive is an ordinary customer you limited for nothing. So we set a budget first and measured against it on flow where there was nothing to find.

1.32%
family-wise false-positive rate, measured on a real null — against a 2% budget set in advance
10–20
bets to a first call, because the judgement is on price rather than on settled P&L
No PII
an anonymised account ID and bet parameters are the entire input
  • Family-wise, not per-test. Scoring a book means running the same test across thousands of accounts, so a per-test error rate flatters itself. The 1.32% is controlled across the whole family of tests — the rate at which the system raises any false flag, not the rate per account examined.
  • On a real null, not a simulation. The rate was measured on real flow where no professional was present, so it reflects the messiness of actual customer behaviour rather than a well-behaved generator.
  • A budget set before the measurement. 2% was the design constraint; 1.32% is what came out. Publishing both is the point — a rate with no stated budget is a number chosen after seeing the answer.
Coverage of your flow

Scored on the lines your customers actually took

Your book does not only offer the lines the reference market quotes — and neither do sharp customers only bet them.

  • Arbitrary customer lines. A bet on a rung the reference never quoted is repriced from the ladder tables and scored like any other, instead of being skipped for lack of a benchmark.
  • The close cannot be revised. Our closing prices are committed in the ledger as they are produced, so a score cannot be improved after the outcome is known — the same guarantee applies to us as to you.
  • Same engine, offline: the retro-audit runs this scoring walk-forward over 6–12 months of your history and returns two figures in your money.
Integration

One call, live

Post an account with its bets, get a score back. The endpoint is in the point rate class of its own, score — 120 calls a minute and 60 000 a day on the default contract, sized for a book that posts each bet as it accepts it.

curl -s "https://api.foreline.io/v1/score" \
  -H "X-Foreline-Key: $FORELINE_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "account_id": "acct_7d41c9",
    "bets": [
      { "event_id": 1633801638, "market": "handicap", "line": -0.75,
        "side": "home", "odds": 1.94, "stake": 120,
        "placed_at": "2026-07-24T15:02:11Z" }
    ]
  }'

Request and response fields are documented in the API reference. The values here are illustrative — the field names are not: event_id is our numeric id and never a string of yours, the price is odds (decimal) and the timestamp is placed_at. handicap is one accepted spelling of the market; the full dictionary, shared with Parlay Protection, is in Naming a leg.

POST /v1/score reference →

Built on the same surface

The other three products

Fair-Price Surface

The whole ladder, de-vigged and banded — the close every score is measured against.

See the product →

Line Radar

Main-line changes as a fact-stream, plus warnings when your price drifts from fair.

See the product →

Parlay Protection

A coherent score matrix, so joint outcomes are priced consistently with the marginals.

See the product →
Get started

Request a trial of Player Radar

Tell us roughly how much flow you take and in which markets. We reply with a trial key, or with the retro-audit route if you would rather see it on your own history first.

Email us

We usually reply within one business day. Pricing is quoted per scope — ask and we will send terms.

Request trial