Twenty prop firm rulebooks, one schema
Two evaluations can advertise the same number for the profit target, the same number for maximum loss, and behave nothing alike.
That is not an accident of marketing. It is because "10% maximum loss" is three different rules depending on things the headline does not say: whether the floor moves, whether it moves against the equity peak or the balance peak, and whether it moves intraday or once at settlement. One trader passes a $100k account on 10% loss and an identical trade sequence fails another. Nothing in the number told them apart.
I spent a while putting twenty of these side by side. The interesting part was not the figures. It was how many fields have to exist before a comparison is honest.
The fields that actually decide the outcome
Roughly in order of how often they change the answer:
| Field | Why it changes the outcome |
|---|---|
| Drawdown model |
static, trailing_eod, trailing_intraday. A trailing floor turns locked-in profit into a liability. |
| Drawdown basis | Equity peak or balance peak. Closing a winner and re-entering changes one and not the other. |
| Daily limit basis | Equity or balance, measured on server-day close or continuously. |
| Lock point | Many trailing plans stop moving once the floor reaches the starting balance; some never stop. |
| Server-day boundary | If the reset is 00:00 server time and you trade the 23:00 candle, you are in two days at once. |
| Consistency cap | Usually "no single day above X% of total profit" — computed on closed P&L, at review, not at pass. |
| News window | A time band around an event, or a flat ban on holding through it. Vague in most rulebooks. |
| Minimum days | Turns a fast, correct pass into a breach with no trading error involved. |
What "comparable" means, and what it does not
Once those fields exist, the commercial numbers become readable. A plan with a 6% target, a static 6% floor and no minimum days is a different product from one with a 10% target, a trailing intraday 10% floor and five minimum days, even if both are sold as "easy".
The version of this on ElitePropX's rules matrix is firm by firm, with the unconfirmed cells left visible rather than filled in. That last part is the design decision that took the most discipline, and it is worth explaining.
Do not fill a gap from memory
Every rulebook has a field that is not published, or published only per account size, or moved last quarter. The tempting thing is to infer it — "most trailing plans lock at breakeven, so assume this one does" — and that inference is exactly how a comparison table becomes fiction that reads as data.
So each record carries its own uncertainty:
{
"firm": "example",
"plan": "2-step",
"account_size": 100000,
"drawdown": {
"model": "trailing_eod",
"basis": "equity",
"value": { "type": "percent", "value": 10 },
"locks_at_balance": true
},
"consistency": { "cap_percent_of_profit": 30, "evaluated": "review" },
"checked": "2026-10-23",
"unconfirmed": ["drawdown.locks_at_balance"]
}
The unconfirmed array is not documentation, it is data: the renderer prints those rows as an open question instead of a number. A field that is null is honest. A field guessed from a sibling plan is a liability in a document someone uses to size a position.
That convention is written down at how we check firm rules — which source counts, what a checked date promises, and what happens when a firm changes a figure after publication. If you are building a reference table of anything regulated, the checked-date and corrections policy is the part worth copying first; the table is the easy half.
The derived fields do the work
The normalised record is only useful once it produces numbers a trader can act on without arithmetic in a live position:
- Distance to floor in cash — and on a trailing plan, the distance from the current floor, not from the starting balance.
- Contracts or lots from a stop distance, so the size is chosen from the floor rather than from the target.
- Trades at 1R to clear the target, which is usually the moment a plan's "achievability" becomes obvious.
- Cost per attempt including resets, because the fee is paid before the outcome is known.
Those four are the entire reason to keep a schema rather than a spreadsheet. Each one is a different loss of fidelity when you convert a percentage into currency at the wrong moment, and each is cheap once the fields are typed.
The eight rules themselves, one at a time — daily loss, maximum loss, trailing drawdown, consistency, news, weekend holding, EAs, minimum days — are covered at prop firm rules explained. Read that first if the field names above are new; come back to the schema when you need to compare two plans rather than understand one.
The takeaway, if you never build the table
Normalising rules is not a data-cleaning exercise. It is the step that reveals the rule the firm did not put in the headline. If you only ever do one thing, record for each plan you buy: the drawdown model, the basis, and the server-day boundary. Those three explain most of the resets that look like bad trading and are not.
Top comments (1)
Two plans can share the same 10% loss number and still be Different products once trailing, equity versus balance, and server day show up.
From my experience i'd lock each rule as a named object with grain Outside the comparison sheet, then open the definition and the source fields before calling them comparable. An unconfirmed cell beats a confident guess every time.