Back to blog
Backtests, paper bets and published records: what each can prove

Backtests, paper bets and published records: what each can prove

A betting backtest and a live tipster record can display the same profit curve while describing completely different events. One may reconstruct decisions after the results were known. Another may record recommendations sent before kick-off. A third may document bets someone actually placed. Before comparing returns, establish which of those claims the evidence supports. The useful question is not whether a chart looks convincing, but what was decided, when it was decided and whether anyone could have acted on it under the stated conditions.

Start by identifying what each row represents

A retrospective backtest

A backtest applies a set of rules to historical data and calculates hypothetical selections and outcomes. It can help investigate an idea, catch accounting errors or explore where a method breaks down. It does not establish that those selections were published at the time, that anyone risked money or that followers could obtain the recorded odds. Ten years of historical rows remain retrospective evidence if the recommendations were generated after the events. A larger archive does not change their origin.

Paper betting on future events

With prospective paper betting, a method starts recording new selections as events approach, without placing actual bets. If its rules were fixed beforehand and the timestamps are preserved, this tests something that a retrospective reconstruction cannot: what the method would select without knowing the outcome. It still leaves execution untested. A quoted price may disappear, an intended stake may exceed the accepted amount, or the relevant market may not be accessible. Keep the paper label even after a successful run.

Published tips and accepted bets

A published record documents advice made available before an event, subject to the service's editing and retention rules. An accepted betting receipt documents a transaction, including its price and accepted stake. Those records answer different questions. Someone can place a winning bet without having recommended it publicly. Someone can publish a recommendation without staking personal money. A convincing assessment keeps the two forms of evidence separate and connects them only where the timing and details genuinely match.

Rebuild the information available at the decision time

A historical dataset often combines information collected at different moments. The result is known after the match; a confirmed line-up may arrive shortly before kick-off; an opening price exists much earlier than the closing price. A strategy claiming to make morning selections cannot silently use afternoon team news. Its calculations might be perfectly accurate while answering an impossible question: how well could someone have performed with information they did not yet possess?

This is one form of information leakage. Scikit-learn's documentation explains why letting evaluation data influence model development can make measured performance too optimistic. Applying that principle to betting means asking for an explicit timeline: data availability, selection time, publication time and possible execution time. This is a methodological check, not an accusation of dishonesty. Missing documentation limits the conclusion even when there is no evidence that the author deliberately changed anything.

For example, suppose a system selects matches at 09:00 but its historical archive contains only closing odds. Replaying the strategy with those prices does not show what a subscriber could have achieved at 09:00. Changing to a genuine morning snapshot could alter both the qualifying selections and their returns. Ask which timestamp accompanies the price, which market it describes and whether the same decision rule was used. The label “historical odds” alone does not settle any of those points.

The winning strategy may have been selected after the test

Leakage is not the only way a retrospective result becomes flattering. An author might try dozens of leagues, price ranges, weekdays and exclusions, then publish only the strongest combination. Each individual run can use correctly dated inputs while the final choice still benefits from hindsight. Bailey and colleagues examine backtest overfitting in financial simulations. Their research does not establish a universal failure rate for sports tipsters. It supports asking how many alternatives were explored before the displayed strategy was chosen.

Keeping a later period out of development can make the next assessment more informative. However, repeatedly consulting that period, changing the filters and calling the resulting score independent defeats its purpose. A revised method is a new version. Record what changed and start assessing subsequent decisions under the revised rules. Improving a method is legitimate; presenting the improved explanation as though it had been fixed before all the displayed results is what undermines the comparison.

Ask for the rule version and the date it was frozen, rather than just the number of historical bets. Our guide to the minimum sample size for evaluating a tipster covers uncertainty from limited records. Provenance is a separate issue. A large, poorly designed dataset cannot repair an impossible decision timeline. Conversely, a short prospective record can be honestly documented while remaining far too limited to establish skill. Integrity and statistical strength should be assessed together without treating them as interchangeable.

A worked example: identical selections, opposite balances

Consider four hypothetical single bets, each with a stake of 1 unit. Two win and two lose. The backtest assigns decimal odds of 2.10 to all four. Each winner produces +1.10 units net; each loser produces −1 unit. The final result is +0.20 units from 4 units staked. The winners return 4.20 units in total, but that is not the profit: those returns include the winning stakes. Confusing return with net profit would badly overstate the evidence.

Now imagine someone executes the same four selections at 1.95. The outcomes and stakes remain unchanged. Each winner produces +0.95 units, leaving a total of −0.10 units after the two losses. The strike rate is identical, yet the balance changes sign. The difference of 0.30 units comes entirely from the price. Neither calculation includes a subscription or commission. This example is an accounting illustration, not a forecast or a claim about the prices normally available to followers.

If one recommended bet was never accepted, the executed record contains a different set of transactions. Do not insert a fictional bet into the personal account to make it resemble the tipster's chart. Keep recommended selections and accepted transactions separately, and record why they differ when that is known. Equally, do not use only the recommendations you happened to execute as an unexplained substitute for the service's complete record. Each balance needs its own clearly defined population.

What to inspect beyond the headline figure

A useful record identifies the event, exact market, relevant period, selection, odds, stake and publication time. It also needs consistent treatment of pending bets, voids and corrections. These fields let readers ask precise questions; they do not by themselves establish that the archive is complete or that money changed hands. Our article on signs of manipulated tipster statistics explains how to inspect discontinuities without assuming that every documented correction is evidence of fraud.

Distinguish synthetic examples from observed records. A polished interface can display generated data, and an ordinary spreadsheet can hold genuine contemporaneous observations. Presentation quality says little about provenance. Similarly, identity verification answers a question about the person or account; it does not automatically verify the prices, settlement, completeness or execution of every bet. When a service uses “verified”, ask exactly which object has been checked, by whom and within what limitations.

Automation and independence are also different. Software can consistently apply the wrong settlement rule. A manual check can be accurate yet cover only a selected batch. Ask what happens after an error is discovered, who can amend the record and whether previous figures change. You do not need access to the source code to recognise that an explanation is incomplete. You can defer a purchase because evidence is insufficient without claiming that the service has committed fraud.

A practical evidence request

Rather than asking for another promotional screenshot, request the period covered, the origin of the selections, the relevant rule version and the status of each row. Ask whether losing periods are retained, whether accounts can restart and how hypothetical prices are distinguished from accepted ones. A provider may have reasonable limits on sharing personal or proprietary information. Those limits do not automatically make its claims false, but they can prevent you from reaching the stronger conclusion that the marketing suggests.

How to interpret records on Tippium

Tippium publishes and tracks tips; it is not a bookmaker and does not execute the reader's bets. Picks are recorded before the event, but authors can edit or cancel them while the conditions before the first event's start are met. Afterwards, they are locked. A confirmed paid account restart deletes bets and statistics, without displaying a restart counter. The currently available history therefore cannot establish permanent retention of every recommendation ever associated with an identity.

There are automated profiles and demonstration data, including simulated or modified histories. Identity verification does not certify profitability or amount to an external audit. Public net units and yield describe the retained record, not the personal earnings of every follower. Check the origin of the profile before treating a figure as evidence of real execution. The explanation of how Tippium works places publication and access in context without turning a tracking service into independent proof of accepted bets.

You can create a Tippium account to consult profiles and organise access while keeping those distinctions in mind. Before paying for any service, write down the conclusion the material actually supports: historical simulation, prospective tracking without proven execution, or documented transactions for a defined set. If the origin or timing remains unclear, ask for the missing information and postpone the decision. A modest, accurate description is more useful than a confident claim built on an ambiguous chart.

Neither a positive backtest nor a published record guarantees future results. Betting can cause financial losses and other harm. Do not use money needed for essential expenses or increase stakes to recover losses. Stop and seek appropriate support if control becomes difficult.