Understanding NiveshBuddy Data & Assumptions
Every figure on a results page is a model output, not a measurement. What the model assumes about data, execution and costs — and how those assumptions change the way you should read a result.
What You’ll Learn
By the end of this article, you’ll understand:
- Why every result is a model output rather than a measurement
- The three families of assumption behind any NiveshBuddy figure
- Which simplifications flatter a result, and why they lean one way
- Three habits that change how you read a modelled figure
- How a historical backtest differs from a forward simulation
What a result actually is
A backtest result looks like a measurement. It has decimal places, it is drawn from real historical prices, and it describes trades in named companies on dated days. All of that is true, and it is still not a measurement.
It is the output of a model — and a model is a set of decisions about what to include and what to ignore. Which prices count. When a decision is allowed to act. What costs money and what is free. Every one of those decisions is a simplification, made so the calculation is possible at all.
The useful thing about NiveshBuddy's simplifications is that they are knowable. This article puts them in one place, so that when you read a result you know roughly how far it sits from what would actually have happened.
Why the gap accumulates
Taken one at a time, each assumption is small and defensible. Prices are read at the close rather than continuously. A trade is modelled as filling at the official closing price. Costs are whatever figure you entered.
The trouble is that they stack, and — for the execution and cost assumptions — they mostly lean the same way.
A backtest that charges nothing for trading, fills every order exactly at the closing price, and deducts no tax will report a better outcome than the same rules would have produced in a real account. Not because anything is wrong with it, but because each simplification removes a friction rather than adding one.
That is worth internalising as a habit rather than a calculation. There is no correction factor to apply, and inventing one would be worse than useless. The point is directional: treat a modelled result as an optimistic reading of the rules, not a neutral one.
Three families of assumption
What every NiveshBuddy figure assumes
Data
Strategies are evaluated on end-of-day prices from 2021 onwards, so nothing intraday exists to the model — no gaps, no spikes, no circuit limits. The history is adjusted for corporate actions: dividends, bonuses and splits, and mergers and demergers too. A simulation, moving forward through live data, restates holdings for bonuses and splits, and sells a holding before a merger or demerger rather than reconstructing it.
Execution
Rules are evaluated on one day's close and the resulting trades execute at the next scheduled rebalance close, which is what keeps a backtest from acting on information it could not have had. Stop losses are rules checked on a closing price, not orders resting in the market.
Costs
Transaction Cost is a percentage you enter yourself — between 0 and 1%, charged on every buy and every sell — and it defaults to zero. It is the only cost in the model. Taxes, liquidity constraints, market impact and how your broker actually fills an order are not represented at all.
Each of those is taught properly elsewhere: execution timing and how to read a result in Running & Understanding Backtests, corporate actions in Understanding Corporate Actions & Historical Data, and stop handling in How Stop Loss & Trailing Stop Loss Work. This article is about what they add up to.
One trade, all the way through
Here is a hypothetical trade — illustrative, not from any particular backtest — followed from the moment a rule fires to the moment money would really have moved. The strategy rebalances on Mondays.
| Stage | What the model does | What an account does |
|---|---|---|
| Friday's close | Reads the closing price, ranks the eligible stocks, decides what to buy | The same data, but you only see it once the market has shut |
| The weekend | Nothing happens | Results, news and global markets move on regardless |
| Monday's close | Buys at the official closing price, for exactly the quantity implied | You place an order and receive whatever fill you receive |
| Cost of trading | Deducts the percentage you entered, commonly zero | Brokerage, statutory charges, and the spread you crossed |
| While holding | Follows an adjusted price series | Circuit limits, halts and thin days constrain what you could have done |
| On exit | Sells at a closing price, instantly and completely | Settlement takes time, and tax is assessed on the gain |
No single row is unreasonable. Read the right-hand column top to bottom, though, and you can see why two people running the same rules — one in a backtest, one in an account — should not expect the same number at the end.
What to do about it
Knowing where a model simplifies is only useful if it changes how you read the output. Three habits do most of the work.
Enter a transaction cost you would actually pay. It is the one friction the model will apply for you, and it sits at zero until you change it. The field is labelled Transaction Cost (each buy & sell) because it is charged on both sides, so a round trip pays it twice. A Quick Strategy always runs at zero; to test a cost, Customize the strategy and set one in Backtest Settings (a Custom backtest, so it spends a Strategy credit). A strategy that trades often is affected far more by this than one that trades rarely, so the same figure can matter enormously or barely at all. The trade log's optional Return (Net% /Abs) and Transaction Cost columns show it applied, trade by trade.
Read returns as pre-tax. Tax is assessed on gains in an account and is not part of the model at any point, so it sits outside every figure on the page rather than being netted off somewhere you have not looked.
Compare like with like. The assumptions are applied consistently across strategies, which makes a result far more reliable as a comparison than as a forecast. Two strategies tested the same way can be weighed against each other even though neither number will be reproduced exactly in an account.
Backtest and simulation are different models
These two get confused, and the difference is not a matter of degree.
A backtest replays a strategy against history. Every date has already happened, every price is known, and the whole run happens in one go — you wait for it to compute, not for the market to move.
A Simulation is a paper portfolio run with virtual money: it follows a linked strategy forward through current market conditions. It moves at the speed of the market, and it can absorb your own execution decisions along the way — rejecting a scheduled trade, or recording what you actually did at your broker. It places no real orders and is not a broker account.
One detail captures the distinction neatly: a simulation receives no Strategy Score. A score summarises a pure historical evaluation of a set of rules, and a simulation is not that — it reflects forward execution and whatever adjustments you made. Scoring it would be scoring you as much as the strategy.
So the two answer different questions. A backtest asks whether the rules would have worked. A simulation asks whether you can actually follow them.
Common misconceptions
Four things a result does not mean
"It used real prices, so it is real"
The prices are real; the trading is not. Every fill is modelled at a closing price for the exact quantity implied, which is the one thing about a backtest that never happens in an account.
"Zero transaction cost means it is free"
The zero is a default in a field you can edit, not a statement about what trading costs. NiveshBuddy does not charge it and does not claim it is realistic.
"A simulation tests my trading calls"
It runs with virtual money, but the trades come from the strategy's own rules, on its schedule. Your part is limited to rejecting a scheduled trade or recording a different real fill — so it tests the rules, and how closely you follow them, rather than your discretionary calls.
"A longer backtest is a safer one"
More history is more evidence, and also a wider mixture of conditions the rules may have handled very differently. Length improves the sample; it does not make the assumptions above any less true.
None of this makes a backtest less useful. It makes it a piece of evidence produced under stated conditions, which is exactly what it should be. Historical and virtual results do not guarantee future performance, and what you do with a strategy remains your decision.
Key takeaways
- Every figure on a results page is a model output, not a measurement — a set of decisions about what to include and what to ignore.
- The assumptions divide into three families: data, execution and costs.
- Data is end-of-day from 2021, so nothing intraday exists to the model; history is adjusted for corporate actions, and a simulation sells ahead of a merger or demerger rather than reconstructing it.
- Execution reads one close and trades at the next scheduled one, which is what stops a backtest acting on information it could not have had.
- Transaction Cost is a percentage you enter, charged on each buy and each sell, and defaults to zero; taxes, liquidity, market impact and broker fills are not modelled at all.
- The execution and cost simplifications mostly lean one way, so read a modelled result as an optimistic reading of the rules rather than a neutral one.
- Enter a transaction cost you would actually pay — it is the one friction the model applies for you, and it starts at zero.
- Returns are pre-tax: tax is assessed on gains in an account and sits outside every figure on the page.
- The assumptions apply consistently across strategies, which makes a result more reliable as a comparison than as a forecast.
- A backtest asks whether the rules would have worked; a simulation asks whether you can follow them.
- A simulation receives no Strategy Score, because it reflects your execution as much as the strategy's rules.