What does a broker export actually contain?
The sourceA trade-history CSV is a row per trade: entry time, exit time, size, and a result, in the order they happened. That order is not decoration — it is the one thing a single win-rate number cannot carry. Two traders can share an identical win rate and average result and still have lived through completely different sequences: one spread evenly across the sample, the other arriving in clusters of five and six losses in a row.
Reducing that file to a win rate and an average win / average loss in R is how trading calculators typically consume it — free ones and paid ones alike.
| p̂ | measured win rate across the file |
| R̄w | average winning trade, in R |
| R̄l | average losing trade, in R |
| n | trade count — the sample size behind all three |
What CSV import does today
Current statePropSurvival's CSV import performs exactly the reduction above: it reads your file, computes p̂, R̄w and R̄l, and then simulates by drawing trades independently from that pair — the identical mechanism a manually typed win rate and reward-to-risk would drive. This is a parametric summary, not a replay of your literal trades. Measuring the summary instead of guessing it is real, useful work; it is not the same operation as resampling the file's own rows.
Nothing about that is hidden or a downgrade — it is the same free, full-accuracy engine either way, and measuring your statistics from a file is strictly better than typing a remembered average. What matters is being precise about which of the two operations is actually happening.
How much a small sample can actually tell you about p̂ and R̄ is derived in Trading journal intelligence; the i.i.d. assumption underneath every resample is stated in full in Clause 03 of the Risk Disclaimer.
What the summary keeps, and what it discards
The gap, derivedA win rate and an average R keep the sample's long-run mean exactly — by construction, resampling from them converges on the same average the file itself has. What they cannot keep is order. Draw trades independently and the order of outcomes carries no information; a real trader's actual sequence — a bad week that produced six losses in a row, or a hot streak that front-loaded most of a month's gain — is exactly as probable under that model as any other arrangement of the same wins and losses. The model has thrown away the one fact that decides whether a drawdown floor is breached by six independent coin flips landing badly, or by six trades that were never independent in the first place.
A drawdown floor is breached by the worst run in a sequence, not by the average trade. Anything that changes how runs cluster changes the floor's breach probability even when the win rate and average R do not move at all.
Try it: the summary method against reading the trades themselves
Live instrumentThis generates 100 synthetic trades at a fixed 45% base win rate and 1.5 reward-to-risk, with a streakiness control that sets how likely a trade is to repeat the previous one's outcome. At zero, outcomes are independent draws at exactly that base rate; any single 100-trade draw still wanders around it, and the measured rate of the current draw is printed under the charts. From the same 100 trades it then runs two resampling methods, 3,000 paths each: the parametric method above (draw independently from the measured win rate and R), and a block method that resamples contiguous 10-trade chunks of the actual sequence, which keeps any local clustering intact. Move the slider and watch where the two agree, and where they stop.
The 100 generated trades, in order — graphite is a win, ruby is a loss:
Parametric — draws independently from p̂ and R̄
Block bootstrap — resamples 10-trade chunks of the real sequence
—
Illustrative comparison — 3,000 paths per method, 100 trades per path. Both methods run on the identical 100-trade sequence shown above, so the only difference between the two charts is the resampling method itself.
A standard resampling technique: instead of drawing one trade at a time, it draws whole contiguous chunks of the real sequence, so a real streak stays a streak in the resample instead of being broken apart. It is one way to preserve order; it is not what CSV import does today.
What comes next, honestly
Scope, stated plainlyReading a trader's own sequence directly — instead of the summary computed from it — is a natural direction for this engine, for exactly the reason Clause 03 demonstrates: it is the only way to let a real streak affect a drawdown estimate the way it affected the real account. It is not built today, and nothing on this page promises when it will be.
What is real and available today is the full parametric engine: free, full accuracy, running on statistics you type or import, against a firm's published rules or against a rule set you write yourself. That is not a smaller product waiting to become the real one — it is the real one, doing the job it is built to do, honestly described.
The same i.i.d. boundary applies whether the rules being tested are a firm's or your own — see Write your own rulebook.
Common questions
QuestionsDoes PropSurvival replay my exact trade sequence?
Not today. CSV import computes a
summary from your file — win rate, average win, average loss — and resamples from that summary,
exactly as a manually typed win rate and reward-to-risk would be modeled.
Will a version that reads my trades directly exist?
Reading a trader's own sequence
directly, instead of its summary, is a natural direction for this engine. Nothing on this page promises a
date or a feature that is not yet built.
Does this change what a personal rule set can measure today?
No. Your own rules —
a maximum drawdown, and optionally a daily stop, a goal, a horizon, a ruin threshold — run today, free,
at full accuracy, against whatever statistics you provide, typed or imported.
Turning your own statistics into a rule you can test is covered in Write your own rulebook.