DEV Community: Okeke Jenny

How to quote a pass rate so a stranger can check it

Okeke Jenny — Tue, 03 Nov 2026 17:29:43 +0000

How to quote a pass rate so a stranger can check it

"87% success rate" is the most common number in the prop firm passing market and the least meaningful, because it does not say what it is a rate of. A percentage with an undefined denominator is not a statistic. It is a mood.

Here is what has to be true before a pass rate can be compared with another one.

1. Define the denominator, in purchases

The candidate denominators are very different things:

Evaluations attempted — every account that was worked on, including ones abandoned.
Purchases — every time a client paid. This is the honest one for a buyer, because it is the unit they are deciding on.
Clients — one person who bought four evaluations counts once, which can flatter or deflate depending on how they did.

A service quoting a rate per client while selling per evaluation has changed the meaning of the number without changing the number. The question to ask is literal: per purchase, or per client?

2. Include the resets, or the rate is survivorship bias

A retry policy creates an obvious accounting temptation: the first attempt fails, the retry passes, and the pass is counted while the failure quietly leaves the sample. The rate goes up and nothing about the service changed.

If retries are covered — and at a flat fee they usually are — then the honest figure counts resets as failures, because each reset is a purchase-equivalent the client did not have to make at another provider. Publishing "X of Y purchases reached funded status, including Z resets" is a weaker-sounding sentence that is worth more than a clean percentage.

3. Date the window and say what happened to open accounts

A rate over an undefined period is not reproducible. Rates drift with firm rule changes, market regime, and the mix of account sizes being sold.

Two minimum requirements: the window ("January–October 2026"), and a stated treatment of accounts still in progress. Excluding them inflates the rate. Counting them as failures deflates it. Either is defensible if it is written down; silence is not.

4. Make the claim checkable by someone who does not trust you

A number in a headline cannot be verified. What can be verified is an artefact a firm will confirm:

A certificate per pass, with the client name redacted and an account number the firm can look up.
A checked date, so a reader knows which version of the firm's rules applied.
The failures, listed with their cause, in the same place as the passes.

That last item is the one that separates a record from an advertisement, and it is also the one that is uncomfortable to publish, which is why it is informative.

5. Prefer the wording that cannot be read as a promise

"87% success rate" implies a probability about your evaluation. It is not one — the outcome depends on the account size, the firm, the rules in force that month, and the trader. What a service can actually claim is a historical count over a defined population.

The defensible sentence has four parts: count, denominator, window, treatment of resets. For example — "63 of 71 purchases reached funded status between January and October 2026, including nine resets." Every word there is a fact about the past, and a reader can ask to see the 71.

The disclosure

I run a passing service, ElitePropX, so the standard above is the one I am applying to myself. The passed challenges page lists the accounts that reached funded status with client names redacted, and the evaluations that were reset alongside them — roughly one in twenty. The methodology page states what a checked date means and how a correction is published when a firm changes a rule.

Whether the numbers on those pages are good is a separate question from whether they are legible. Legible first: a reader who can count the denominator can decide for themselves, and that is the only kind of claim worth making in a market where every competitor has a nicer percentage.

The one-line test

Before you compare two services, ask both: "your rate — per purchase or per client, what window, and are resets counted?"

The service that answers in one sentence is not necessarily better. It is the only one whose number you can actually use.

What happens to the account after the pass: handover, KYC, and the first payout

Okeke Jenny — Tue, 03 Nov 2026 17:28:55 +0000

What happens to the account after the pass: handover, KYC, and the first payout

The evaluation ends when the target is hit. The risk does not. Three separate things can still cost a trader a funded account that has already been earned, and all three happen after the part everyone optimises for.

The handover window is where passes die

A firm sees a login from one country for six weeks, then a new device in another country on the day the account is transferred. That is the exact shape its own anti-fraud checks are built to catch, and the trader who is legitimately taking over their account looks identical to the one who is not.

Practically:

Do not change region on handover day. If you are going to log in from a new country, do it before the pass, not after.
Do not route the first login through a VPN because the service's region looked cleaner. A residential IP that matches your KYC address is the boring, correct choice.
Log in once, from the device you will keep using. Device churn is a signal on its own.

None of this is about hiding. It is about not setting off a heuristic that a human then has to clear, usually by email, usually over a weekend, while the account sits idle.

KYC belongs to the account holder, and it is not a formality

This is the single most common reason a passed account never pays out: the identity on the funded account does not match the identity on the payout method.

A firm will verify the person it is paying. If the name, address and payment details diverge — a different surname on a bank account, a wallet under a trading alias, a company account where the KYC is personal — the payout is held when it is requested, not when the account is opened. That is the worst possible moment to discover it.

Confirm the payout details in the first 24 hours after handover, before any trading. It is a five-minute check at a moment when nothing is at stake.

The funded phase has rules the evaluation did not

Most firms apply at least one condition that only exists after funding:

Rule	Typical form	Why it surprises people
Consistency at payout	No single day above a share of total profit	It is evaluated when you request, not when you pass
News windows	A time band around scheduled events	The evaluation may have allowed holding through
Minimum trading days	Counted from the funded start date	A fast, correct pass can still be early
Profit split tiers	Split improves at a threshold	Affects what you withdraw, not whether you passed

The rules tab for the funded phase is a different document from the one you read during the evaluation. Read it after handover, not before, because that is when it applies.

What to verify in the first 24 hours

The dashboard shows your name and email.
The payout method is set and matches your KYC identity.
The funded-phase rules tab has been read and screenshotted, with the date visible.
The account balance and starting floor match the certificate you were given.

Four items, one sitting. Each one is cheap to fix now and expensive to fix after a payout request has been refused.

Why the operator should hand over before the payout, not after

There is a structural conflict in a passing service that keeps control of a funded account until the client has been paid. It aligns incentives on paper — the operator only gets paid if the account pays — and it puts the operator in possession of an asset that belongs to someone else, under KYC documents that name the client.

The cleaner structure is the boring one: register the account in the client's name, hand over credentials the day the target is met, and take the fee for the evaluation rather than for the outcome. That is how the evaluation plan at ElitePropX is set up — the flat fee covers the evaluation, and the funded account is the client's from the moment it exists, which is also why the fee is not a share of the profit.

The short version

The pass is a milestone, not the finish. Match your KYC to your payout method before you trade, take the account over from a device and region you will keep, and read the funded-phase rules as a separate document from the evaluation's. Every one of those is a five-minute task that prevents a category of loss the trading itself did not cause.

Four contract terms to read before you pay a prop firm passing service

Okeke Jenny — Tue, 03 Nov 2026 17:28:51 +0000

Four contract terms to read before you pay a prop firm passing service

Every passing service sells the pass. The pass is the easy half to describe and the hard half to promise, so the marketing stops there.

What actually decides whether you lost money is the four terms underneath it. None of them are exotic, and all of them are usually missing from the pricing page.

1. Who holds the funded account

This is the one that matters and the one least often stated. When an evaluation is passed, the account exists somewhere — an email address, a login, a name on the KYC record, a payout method.

If the operator registered the account, you do not own an account. You own a promise that the account will be transferred, on terms that were not written down when you paid. If you registered it, you own it from the first login and the service is doing work on your account rather than selling you one.

Ask directly: whose email address is on the firm dashboard, and whose name is on the KYC record? A service that cannot answer in one sentence has not thought about it, which is worse than a bad answer.

2. What a breach costs, and who pays the retry

"Retries covered" is on every site in this market. It is a real benefit and it is nearly always undefined in three ways:

How many retries — one, or until it passes?
Within what window — same month, same quarter, indefinitely?
On which firm — the original one, or any firm, which matters when the original changes its rules mid-evaluation?

A retry promise with no count and no window is not a term, it is a sentiment. The clause to look for is the one that says what happens on the second breach, because that is where the arithmetic of a fixed fee stops being generous.

3. The refund trigger, and what it actually returns

"Pass or refund" sounds like a guarantee. Read what it refunds.

Your true cost is not the service fee alone — it is the service fee plus the challenge fee you already paid the firm, doubled if you are on a retry. A refund of the service fee leaves the challenge fee with the firm, which is often the larger number on a $200k account.

So the useful question is not "is there a refund" but "does the refund cover the firm's challenge fee as well, and what is the deadline for claiming it?"

4. What you receive, and whether a stranger could check it

The deliverable is one of three things: login credentials, a certificate, or a screenshot.

Credentials transfer an asset. Good.
A certificate with the client name redacted is checkable — a firm can confirm an account number exists.
A screenshot is a picture. It costs nothing to produce and proves nothing.

If the only artefact is an image, the pass has the same evidential status as a testimonial.

The awkward part: I run one of these

ElitePropX is a flat-fee passing service — $220 per evaluation, any account size, retries covered, no profit split on the funded account. So this is not a neutral buyer's guide. Treat it as the list of questions I expect to be asked, and hold me to the same four answers:

The account is registered in the client's name, with the client's email on the dashboard.
Retries are covered without a count, because the fee is per evaluation rather than per attempt.
A refund returns the service fee; the firm's challenge fee is not recoverable by us or by anyone.
The deliverable is credentials plus a certificate with the client name redacted.

The parts that make those answers checkable rather than asserted are published: the methodology explains what a checked date promises and how corrections are handled, and the passed challenges page includes the evaluations that were reset — roughly one in twenty — because a service that only lists wins has not published a record, it has published an advertisement.

The printable version

Four questions, in the order that saves the most money:

Whose email and name are on the account? · How many retries, in what window, on which firm? · What does the refund return, and by when? · Is the deliverable credentials, a certificate, or a screenshot?

If a service answers all four in writing, the price becomes comparable. If it answers two, the price is not the thing you should be comparing.

Four contract terms to read before you pay a prop firm passing service

Okeke Jenny — Tue, 03 Nov 2026 17:06:55 +0000

Four contract terms to read before you pay a prop firm passing service

Every passing service sells the pass. The pass is the easy half to describe and the hard half to promise, so the marketing stops there.

What actually decides whether you lost money is the four terms underneath it. None of them are exotic, and all of them are usually missing from the pricing page.

1. Who holds the funded account

This is the one that matters and the one least often stated. When an evaluation is passed, the account exists somewhere — an email address, a login, a name on the KYC record, a payout method.

2. What a breach costs, and who pays the retry

"Retries covered" is on every site in this market. It is a real benefit and it is nearly always undefined in three ways:

How many retries — one, or until it passes?
Within what window — same month, same quarter, indefinitely?
On which firm — the original one, or any firm, which matters when the original changes its rules mid-evaluation?

3. The refund trigger, and what it actually returns

"Pass or refund" sounds like a guarantee. Read what it refunds.

So the useful question is not "is there a refund" but "does the refund cover the firm's challenge fee as well, and what is the deadline for claiming it?"

4. What you receive, and whether a stranger could check it

The deliverable is one of three things: login credentials, a certificate, or a screenshot.

Credentials transfer an asset. Good.
A certificate with the client name redacted is checkable — a firm can confirm an account number exists.
A screenshot is a picture. It costs nothing to produce and proves nothing.

If the only artefact is an image, the pass has the same evidential status as a testimonial.

The awkward part: I run one of these

The account is registered in the client's name, with the client's email on the dashboard.
Retries are covered without a count, because the fee is per evaluation rather than per attempt.
A refund returns the service fee; the firm's challenge fee is not recoverable by us or by anyone.
The deliverable is credentials plus a certificate with the client name redacted.

The printable version

Four questions, in the order that saves the most money:

Whose email and name are on the account? · How many retries, in what window, on which firm? · What does the refund return, and by when? · Is the deliverable credentials, a certificate, or a screenshot?

If a service answers all four in writing, the price becomes comparable. If it answers two, the price is not the thing you should be comparing.

A verification page that survives a skeptic: redaction, dates, and publishing the resets

Okeke Jenny — Fri, 30 Oct 2026 06:36:37 +0000

A verification page that survives a skeptic

Every service in a market like this one has a results page. Almost none of them is worth reading, because the format is the same: logos, a big number, no dates, no method, and a selection rule you cannot see. The page is written to be skimmed by someone already convinced.

The question worth designing for is different: what would this page have to contain for a skeptical reader to be able to check it?

1. Redaction that keeps the evidence

The instinct is to remove names, then remove account numbers, then remove the date because it feels identifying, and end up with a logo wall that proves nothing.

Redaction should remove identity, not evidence. Keep:

the firm and the plan,
the account size,
the pass or reset date,
the phase and the result,
the certificate or statement, with the account number masked.

What is left is a claim a reader can compare against the firm's own timeline and payout mechanics. "Alpha Capital Group, $100k, passed 12 September" is checkable in a way "500+ challenges passed" is not. The dates also make the page expensive to fake at scale, which is why they are the first thing a bad results page drops.

The version of this that a buyer can actually read is passed prop firm challenges — certificates in, names out, dates intact.

2. Publish the resets

This is the part almost nobody does, and it is the only part that converts the page from marketing into data.

Any process with a failure rate has failures. If a results page shows none, one of three things is true: the sample is curated, the failures are renamed as something else, or the volume is too small to have any. A reader cannot tell which, so the rational move is to discount all of it.

Publishing resets alongside passes does something a testimonial cannot: it sets a denominator. If you show twenty passes and one reset, the reader has a rate instead of a claim, and a rate can be argued with. It also forces the operator to write down why each reset happened, which is usually more informative than the passes: a breach on the news window, a trailing floor touched on an overnight gap, a consistency check at review.

3. Dates on the rules, not just the results

Results age. So do rules. A comparison page dated 2024 is not wrong, it is stale, and the reader has no way to tell which sentences have expired.

So each figure carries a checked date, and the page says what that date promises: which source was read, what happens when a firm does not publish a figure, and what the page does when a firm changes a rule after publication. That policy is the thing that makes a date mean something — without it, "updated" is a timestamp on a build, not a fact about the content. The one I work to is written up at how we check firm rules, including the corrections log.

A corrections log is uncomfortable and worth it. A page that has visibly corrected a figure is more credible than one that has never needed to, because the second one either got lucky or is not checking.

4. Separate the checkable claims from the persuasive ones

There is a version of this page that puts a success rate at the top, and it is the version that gets discounted. Success rates depend on the sample, the definition of success, and who was allowed to buy — none of which the reader can audit.

The claims that survive scrutiny are the ones with a paper trail:

a fee, and what it covers,
what happens on a retry,
a payout split,
a dated price comparison across providers.

The full breakdown, including what is and is not refundable, is on the cost page. Note the shape of it: prices and terms, no percentages. That is deliberate. The numbers a reader can verify against their own invoice are the numbers that belong on a page like this.

5. Make the page boring to maintain

A verification page decays the moment it becomes a project. Two fields per record, appended to a text file, rendered at build time:

{ "firm": "Example", "size": 100000, "outcome": "pass", "date": "2026-09-12", "evidence": "certificate" }
{ "firm": "Example", "size": 100000, "outcome": "reset", "date": "2026-09-19", "reason": "daily loss" }

If adding a row takes more than a minute, the resets stop being added first, and then the page is a logo wall again. The format should be dull enough that nobody needs to be in the right mood to update it.

None of this is exotic. It is the ordinary discipline of publishing a denominator, dating your claims, and letting a stranger check the arithmetic. It is rare in this market because it is only worth doing if the results survive being checked — which is exactly the filter a skeptical reader is applying.

A printable prop firm rule checklist in vanilla JS, with no build step

Okeke Jenny — Fri, 30 Oct 2026 06:34:08 +0000

A printable rule checklist in vanilla JS, with no build step

A prop firm rulebook is written in percentages. A trading platform shows dollars. The gap between those two units is where most evaluation failures happen, and it is a UI problem, not a discipline problem.

So the tool is small: pick a plan, enter an account size, get every limit in cash, printable. Everything below is the reasoning behind it — no framework, no build step, one file that still works when the network does not.

The conversion is one function, with a rule about rounding

const cash = (accountSize, pct) => Math.floor(accountSize * pct / 100);

Math.floor, not Math.round. If the true daily limit is $4,999.50 and you display $5,000, a trader can be stopped out and believe they were inside the rule. Rounding in the stricter direction is the only choice that cannot mislead, and it costs nothing.

The same logic applies to the profit target, except there the strict direction is upward — round the target up, so "you need $10,000" is never understated as $9,999.

Trailing floors are a state machine, not a number

This is the part a static table cannot express. On a trailing plan the floor moves with the peak, so the figure the trader needs is the distance from the floor right now:

function trailingFloor({ startBalance, peak, trail, locksAtBalance }) {
  const moved = peak - trail;
  // Many plans stop raising the floor once it reaches the starting balance.
  return locksAtBalance ? Math.min(moved, startBalance) : moved;
}

locksAtBalance is one line of code and it is the difference between a plan that lets you build a cushion and one that follows you until payout. Two plans with identical headline percentages differ only here.

Missing data gets a state, not a default

Every checklist row is one of three things:

a confirmed figure from a rulebook read on a stated date,
an unconfirmed row, printed as an open question, or
a derived figure computed from confirmed inputs.

const row = (label, confirmed, value, note) => ({
  label,
  state: confirmed ? 'confirmed' : 'unconfirmed',
  value: confirmed ? value : null,
  note,
});

The temptation is to delete an unconfirmed row so the checklist looks complete. That is how a checklist stops being a checklist. An open question — "does this plan trail intraday or only at settlement?" — is the most useful line on the page, because it is the one the trader has to answer before paying.

The working version, with plans read from firm documentation and figures left blank where the firm publishes none, is the rule checklist generator. It prints, it needs no account, and the row states are visible rather than hidden behind a tooltip.

Print CSS is the actual feature

The page exists to be carried into a session, so @media print is not decoration:

@media print {
  .site-header, .cta-band, form button { display: none; }
  .checklist li { break-inside: avoid; }
  .checklist { font-size: 11pt; }
}

break-inside: avoid on each row matters more than it sounds: a limit split across two printed pages is a limit nobody checks. Hiding the call to action on paper is the difference between a worksheet and a flyer.

Why vanilla, and where it costs you

Three reasons, in order of how much they mattered:

It has to work offline. A rules checklist opened on a laptop during a news event should not depend on a CDN.
It is one screen of state. A framework would be more code than the feature, and harder for the next person to audit — which matters when the correctness of the arithmetic is the product.
No build step means no supply chain. Nothing to update, nothing to install, nothing that breaks at 03:00.

The cost is real: no reactivity, so every input handler re-renders the list by hand, and the state lives in a plain object that you have to keep coherent. At this size that is cheaper than the alternative. It stops being cheaper around the point you need URL-shareable state, which the embedded calculator does and this one does not.

The one thing to copy

If you take nothing else: convert the unit before the trader is in the position. A 5% daily limit on a $100,000 account is $5,000. Someone down $3,900 with an open position is not thinking in percentages, and "I still had 1.1% left" is not a thought anybody has while watching a losing trade. The rule was known; it was just in the wrong units.

Which rule breaks first, once the units line up, is covered one at a time at prop firm rules explained — daily loss and maximum loss are the two that end most evaluations, and they are the two that are easiest to misread as the same rule when one trails and the other does not.

Twenty prop firm rulebooks, one schema: normalising rules that only look comparable

Okeke Jenny — Fri, 30 Oct 2026 06:34:06 +0000

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.

The clause that voids a funded account, and where you should have read it

Okeke Jenny — Mon, 26 Oct 2026 15:46:38 +0000

Almost every buyer of a prop firm passing service checks the price. Very few check whether the service is permitted where they intend to use it. Those two checks take about the same amount of time, and only one of them can cost you the account. The same asymmetry — paying for the attempt, not the outcome — is why the retry policy is the real price of a passing service is worth reading before the terms page.

Where the clause lives

Firms do not put the relevant term in one place. It shows up in three documents, and they are enforced at different moments:

Document	What it governs	When it bites
Evaluation terms	Who may trade the evaluation account	During the evaluation
Funded account agreement	Account ownership, delegation, sharing	Before the funded login is issued
Payout conditions	What must be true at withdrawal	At payout review

The third one is the one people miss. Passing the evaluation is not the same permission as being paid from the funded account, and the two are governed by separate text.

The clause that actually matters

Search the firm's terms for these terms, in this order:

third-party trading — the direct one
account sharing or shared access
delegation / discretionary management
automated or algorithmic trading, if a bot is involved
ownership of the account and whether it can be operated by someone other than the named holder

Most firms prohibit at least one of these outright on the funded account. Several permit it on the evaluation and forbid it afterwards, which is the worst combination for a buyer, because the service succeeds and the payout still fails.

Why enforcement lands late

A prohibited arrangement is usually not detected at account issue. It is detected after the account is traded and a payout is requested, when the firm reviews the trading record against the person who requested the logins. That review is where the term is applied.

The practical consequence: the risk is not spread evenly. It is concentrated at the single moment when the money is supposed to move. A service that does not tell you this is not protecting you from it.

What the check should look like before you pay

Four questions, and the answers should arrive in writing:

Has the specific firm and account size been checked, or is the answer about firms in general?
Which clause was read, and on the evaluation or on the funded account — or both?
What happens if the answer is no? The correct answer is a refusal before payment, not a refund after a breach.
What access is requested, and when does it end? Scope limited to the evaluation account, returned on the pass, password changed afterwards.

If the service cannot answer the second question, the "terms check" is a slogan. Reading the terms is a specific action with a specific output, and the output is a sentence naming the clause.

The uncomfortable part

Some firms forbid this entirely, on both accounts. There is no version of the service that is permitted there, and any provider willing to accept that job has decided your account is worth more to them than the restriction is.

That is why the refusal matters more than the acceptance. A provider that says yes to every firm has not read anything — and the place you find that out is the payout stage, after you have paid twice and waited six weeks.

The terms-check step in the process I run happens before payment and has one of two outcomes: we name the clause and proceed, or we decline and the process stops at no cost. The funded stage is deliberately not covered — once the account is in your hands, sizing and drawdown management are yours, and no passing service can trade it for you.

Disclosure: I run ElitePropX, a prop firm challenge passing service. This post describes the check we are supposed to perform; if a firm's current terms prohibit third-party trading, we decline the job. Verify the terms yourself for the firm and account size you are considering — terms change, and this post is general rather than specific to any firm's current rules.

The retry policy is the real price of a prop firm passing service

Okeke Jenny — Mon, 26 Oct 2026 15:45:08 +0000

If you compare prop firm passing services by headline fee, you will pick wrong about half the time. The number that decides what you actually spend is the retry policy — and most providers do not publish it. If you want to price your own situation rather than take a table on trust, the expected value of a prop firm challenge, in Python lets you plug your own pass rate and fee into the same arithmetic.

Here is the arithmetic that makes the difference visible.

The model

Let f be the fee, p the probability of passing a given attempt, and m the multiple of the fee charged on a retry (1.0 = full price again, 0.0 = free).

The expected spend per funded account is not f. It is:

import random

def cost_per_funded_account(fee, pass_prob, retry_multiplier, trials=20000, max_attempts=12):
    """Expected total spend to end up with one funded account.

    retry_multiplier: 1.0 -> a failed attempt costs the full fee again
                      0.5 -> retries are discounted
                      0.0 -> retries are free
    """
    total = 0.0
    for _ in range(trials):
        for attempt in range(1, max_attempts + 1):
            total += fee if attempt == 1 else fee * retry_multiplier
            if random.random() < pass_prob:
                break
    return total / trials

if __name__ == "__main__":
    for fee, mult in [(220, 0.0), (400, 0.0), (400, 1.0), (588, 1.0)]:
        print(f"${fee} fee, retry x{mult}: ${cost_per_funded_account(fee, 0.40, mult):,.0f}")

At a 40% pass rate:

$220 fee, retry x0.0:   $220
$400 fee, retry x0.0:   $400
$400 fee, retry x1.0:   $1,000
$588 fee, retry x1.0:   $1,470

The provider advertising $400 can cost you more than twice the one advertising $588. Nothing on either sales page tells you which column you are in, because the retry term is buried in checkout or not stated at all.

This is the whole problem with fee comparison tables. They compare the price of attempt one and call it the price of the service.

What the published prices actually are

I keep a dated table of what these services charge at two account sizes. Checked October 2026:

Provider	At $100k	At $200k	Model
ElitePropX	$220	$220	Flat, any size, retries covered
ThePropFirmPass	£449 (~$565)	Not published	Rises with size, from £349
PassYourProp	$588	$1,158	Size tiers
Pass Prop Challenges	$400	$700	Size tiers
Funded Traders Passing	Not published	Not published	Quote only

Two things stand out.

The spread is wider than the headline fees suggest. At $200k, the gap between the cheapest flat price and the highest published price is more than 5x. If you are comparing providers for a $200k account, the fee you read at $100k is not the fee you pay.

One of five does not publish a price at all. Quote-only pricing is not automatically bad, but it means you cannot compare it to anything without asking, and you cannot tell later whether the number moved.

Three questions that decide the real cost

What happens to a failed attempt? Free re-run, discounted, or full price again. This single answer moves the expected cost more than the fee does.
Does the fee change with account size? A flat fee removes size from the calculation. A tiered fee means the $100k price is marketing and the $200k price is the product.
Is there a profit split on the funded account? A profit share is not a lower fee, it is a fee paid later and contingent on the account surviving. It also gives the provider a position in your funded account.

Why the retry term is usually unstated

Because stating it makes the headline number look worse, and the headline number is what gets compared. A provider charging $400 with free retries and a provider charging $400 with full-price retries present identically until you are at checkout.

There is a structural version of this: a per-attempt fee is billable every time you fail, so the provider is paid more when you need more tries. That is not an accusation of bad faith, it is a description of the incentive. Fee models reward different behaviours, and you should know which behaviour your provider is being paid for.

The one thing to ask before you pay

"If the evaluation fails while you are running it, what do I owe you for the next attempt?"

Anything other than a clear answer is an answer. If the provider cannot state it in writing before you pay, the term that governs your loss is the one you did not read.

Worth adding: the firm's own reset charge is separate from the service fee and is usually not refundable either. Model both. The flat-fee model I run covers resets while the evaluation is running, which is the reason it is priced the way it is rather than per attempt.

Disclosure: I run ElitePropX, one of the providers in the table above — so treat the $220 line as our own price rather than an independent figure. The other four figures are from their public pricing pages, checked October 2026, and I can send the raw rows to anyone who wants to rebuild the table.

VPS latency is a trading rule, not an infrastructure detail

Okeke Jenny — Tue, 13 Oct 2026 18:34:31 +0000

The connection between your trading terminal and the broker's server is usually filed under "infrastructure". On a prop firm evaluation it is a rule, because several of the rules that end accounts are enforced on time rather than on price. A stop that triggers on your chart and a stop that triggers on the firm's server are two different events, and latency is the distance between them. Latency is only half the story: the same fill difference that costs a few ticks can decide whether a trailing floor is touched, which is what trailing vs static drawdown shows with real intraday paths.

This is worth taking seriously because the failure it produces is invisible in a backtest and looks like bad luck in a journal: the price never touched your stop, yet you were stopped out; or the daily loss limit fired and the loss you see is larger than the loss you sized.

The three rules that are actually clocks

Almost every drawdown rule that causes a surprise has a time component:

The daily loss limit reset. It resets at a fixed server time — often the firm's midnight, sometimes the market's daily close in a specific timezone. The exact instant your "day" starts and ends is a server-defined boundary, not the one on your wall clock.
The news window. Restrictions on opening or holding positions are defined as intervals around an event (e.g. "two minutes either side of a high-impact release"). The window is measured on the server's clock.
The maximum trade duration / overnight cutoff. Some programmes require positions to be closed within a session or before a cutoff time. The cutoff is a server timestamp.

If your terminal's clock, your VPS's clock and the broker's clock disagree, a trade you believe is inside the window can be outside it — and there is no "close enough". The rule evaluates a timestamp.

Why a home connection is the wrong reference

Two distinct problems, and it is worth separating them:

Latency. The round-trip time between your terminal and the server. On a routed home connection in a different region this can be tens of milliseconds with high variance. That variance is the issue, not the absolute number: a variable delay means a stop order that arrives late by exactly the amount the price moved in that window, which on a fast instrument during a release can be the difference between a $200 loss and a $600 one.

Timing. Most prop-firm rule enforcement happens server-side, so latency does not change whether the rule fired — it changes the price at which your order filled relative to the trigger. But a home connection with an unstable clock can also change what your terminal thinks the time is, which matters for a manual decision near a cutoff.

A VPS fixes both by placing the client in the same datacentre region as the broker, cutting round-trip time to single-digit milliseconds and removing the domestic-connection jitter.

The arithmetic of a late fill

The reason this matters to the account rather than to comfort is that the loss from a late fill is proportional to size:

extra loss = slippage_per_unit × size (in units)

Take a scenario: during a news release, price moves 8 pips in the 40 ms between your stop triggering and your order reaching the server under a home connection, versus 1 pip on a co-located VPS. On a position where one pip is worth $10: Execution only explains so much if the exposure is the real problem, which is the argument in multiple funded accounts are one position.

Home connection: 8 pips × $10 = $80 of slippage on that single exit.
Co-located VPS: 1 pip × $10 = $10.

Neither fills at the stop price, so both are worse than the chart suggests. The difference is $70 on one trade. Repeat it across a strategy that exits several times a day and the VPS is not a luxury — it is a direct reduction in the slippage that eats into a drawdown budget already measured in dollars.

The second-order effect is worse. A stop that fills 8 pips late is 8 pips closer to the floor than planned, and the trader's sizing assumed the planned stop. The trade was correctly sized for one loss and delivered a larger one. Over a series, that drift is exactly what "my account died earlier than my backtest" looks like.

What the firms require

Many firms make a VPS mandatory for automated trading (EAs and bots), for two reasons: to keep the strategy's latency predictable, and to satisfy the firm's own requirement that the client runs continuously. The requirement is usually stated in the automated-trading or technical section of the rules rather than on the pricing page, which is why it surprises traders who read only the marketing.

The practical checklist before running anything automated on an evaluation:

Location. The VPS region should match the broker's server region. Latency is a function of geography, not of how much RAM you bought.
Always-on. The client must not sleep. A dropped connection during an open position is a rule risk (some firms treat a dropped EA as a violation).
Clock sync. NTP synchronisation, so the terminal's timestamps agree with the server's for window-based rules.
Standby power and redundancy. A VPS that reboots on the daily boundary can miss the cutoff. The failure mode is a position held through a window that should have been closed.

What to do this week

Measure your actual round-trip latency to the broker's server, not to a generic internet host, and note the variance over a session.
Find the firm's reset time and news windows in server time, and convert them into the timezone your terminal displays. Put the conversions on the chart.
Price the slippage you are currently paying. If it is a meaningful fraction of your daily drawdown allowance, co-location pays for itself faster than any strategy tweak.
Size from the realistic stop, not the ideal one. If you know your exits slip, the budget should include the slip.

None of this is alpha. It is the difference between a rule that fires on the server at the moment it is written to fire and a rule that fires on your side of the connection at a moment you did not choose. On an account whose entire margin is a few thousand dollars of drawdown, that difference is not infrastructure — it is risk.

The practical setup — which programmes require a VPS, what region to pick for each broker, and how the timing rules are written — is in the VPS requirements breakdown. If you would rather model the cost of slippage on your own sizing before choosing, the prop firm profit calculator works in the same account currency.

Multiple funded accounts are one position, not several

Okeke Jenny — Tue, 13 Oct 2026 18:33:55 +0000

A trader runs three funded accounts at the same firm, same instrument, same strategy, and treats them as three independent shots at a payout. Then a single bad session takes all three at once. The accounts were not three positions. They were one position, tripled, with three drawdown floors reporting the same loss.

The diversification a trader thinks they own from multiple accounts is a function of correlation between the account strategies, not the number of accounts. Getting this wrong is one of the most expensive modelling errors available, because it converts what looks like risk reduction into concentrated risk with three times the fee surface.

Why the independence assumption is so tempting

Three accounts feels safer than one for an obvious reason: three floors means three separate opportunities for at least one to survive. That intuition is correct if the strategies are independent. The arithmetic is the same as any portfolio:

One account, probability of breach on a given day: p.
Three accounts, probability that all breach on a given day: p³ (if independent).

At p = 0.2, that is 0.8% — reassuring. But the same three accounts trading the same strategy on the same instrument in the same session have correlated daily returns. In the limit of perfect correlation, all three breach together: Running several accounts at one firm is not diversification, it is one position at several times the size — and when the correlated loss lands, the breaches stack; see a soft breach and a hard breach are different failures.

Three perfectly correlated accounts, probability all breach: p = 20%.

The two scenarios have identical account counts and identical per-account risk. They differ only in correlation, and the difference in joint-breach probability is a factor of twenty-five.

That is the whole point: accounts are not the unit of diversification; strategies are.

Where the correlation actually comes from

It is worth naming the sources, because they are all avoidable and none of them is visible on a dashboard:

Same instrument, same direction. Two accounts long the same index in the same session is one bet, expressed twice.
Same strategy, same signals. A mean-reversion system run on three accounts generates the same entries. The trades are duplicates.
Same session. Two different edges traded in the same overlapping hours share the market regime, and regimes are the dominant risk factor.
Same firm's shared constraint. If the firm applies a portfolio-level or per-trader rule, three accounts at one firm are not even independent at the rule level.

Only the first is obvious. The second and third are the ones that actually bite, because a trader running a breakout strategy on three accounts in the same 90-minute window is, mechanically, running one breakout strategy at triple size.

The measurable version

If you keep trade logs per account, the correlation is computable and it is not hard:

// Pearson correlation of daily returns between two accounts.
function corr(a, b) {
  const n = Math.min(a.length, b.length);
  const ma = mean(a.slice(0, n));
  const mb = mean(b.slice(0, n));
  let num = 0, da = 0, db = 0;
  for (let i = 0; i < n; i++) {
    const xa = a[i] - ma;
    const xb = b[i] - mb;
    num += xa * xb;
    da += xa * xa;
    db += xb * xb;
  }
  return num / Math.sqrt(da * db);
}

function mean(xs) {
  return xs.reduce((s, x) => s + x, 0) / xs.length;
}

Run it on the daily P&L of account A against account B. A value near 1.0 means the two accounts are one position. A value near 0 means the second account is genuinely diversifying. Most "multiple accounts" setups measure above 0.8, which is why the downside arrives correlated even when the accounts look independent on paper.

For more than two accounts, the object you want is the correlation matrix, and the useful summary is its largest eigenvalue: if one factor explains most of the variance, you have one strategy wearing several hats.

The consequences for drawdown

Correlation does not just change the probability of a joint breach. It changes the shape of the loss you have to survive:

Independent accounts: losses arrive at different times. One account can be funded and paying while another is recovering. The equity curve of the portfolio of accounts is smooth.
Correlated accounts: losses arrive together. Every account is down on the same day, against floors that are all measured from peaks that all rose together. The worst day in one account is the worst day in all of them.

Because drawdown is a function of the worst path, not the average, correlated accounts concentrate exactly the event that ends them. The trailing-floor mechanic makes this worse: a good run raises all three floors simultaneously, so all three accounts are at maximum vulnerability at the same moment.

What to do about it

None of this means multiple accounts are a mistake. It means the diversification has to be engineered rather than assumed:

Measure the correlation before adding the third account. Two accounts at 0.9 are one account with double fees.
Diversify the strategy family, not the instrument. Two correlated instruments (an index and its futures) are not diversifying; an intraday momentum system and an overnight mean-reversion system may be.
Stagger the session, not just the signal. If both accounts trade the same hours, they share the regime.
Check the firm's portfolio-level rules. Some firms cap aggregate risk across a trader's accounts, which makes the accounts correlated by policy regardless of strategy.
Reserve the uncorrelated account for the worst day. The value of the second account is highest when it is the one not in the drawdown. That only happens if it holds a different bet.

A funded account is a small business with a hard floor. Running three of them is running three businesses — and three businesses selling the same thing in the same market on the same day are one business with three sets of overheads. Correlation is the number that tells you which you have.

The practical firm-level detail — per-trader account caps, whether one firm's accounts share a risk limit, and how the rules treat multiple accounts at the same or different firms — is in the multiple accounts at one firm breakdown.

Weekend holding: what an overnight gap does to a funded account

Okeke Jenny — Tue, 13 Oct 2026 18:33:20 +0000

Here is a rule that costs more accounts than almost any other and gets discussed the least: what happens to an open position between Friday's close and Monday's open. Many prop firms restrict or forbid holding across the weekend. The restriction is easy to read and easy to ignore, because a backtest rarely tells you it exists — and because the strategy that violates it often looks better than one that respects it.

This is about the gap: why overnight and weekend exposure is a different instrument from intraday exposure, and how to decide whether your edge can live inside the rule.

The gap is not a bigger candle

An overnight gap is a discontinuity, and discontinuity behaves differently from volatility in one specific way: it cannot be stopped out at a price.

Consider a long on an instrument that closes at $1.0000 on Friday. Over a weekend, news moves the open to $0.9800 on Sunday night. A stop at $0.9950 did not get you out at $0.9950. It got you out at the first available price, which is $0.9800 — 150 pips below your intended exit, on a single bar, with no chance to react. Gap arithmetic is easy to get wrong in a backtest for the same reason as look-ahead bias hides in the bars you did not load: the bar you never loaded is the one that moved the floor.

That difference matters most in exactly the situation a funded account is most vulnerable: right after a good run. A trader who is up $6,000 on a $50,000 account with a $2,500 trailing floor has a floor that has climbed to $53,500. A weekend gap of 180 pips on a size that translates to 3% of the account is not a loss on the weekend. It is a hard breach at the open, before the first trade of the new week. A gap is easiest to size for if you convert the rule into currency first — the maximum loss calculator turns the percentage floor into the distance your position can travel overnight.

The gap did not exceed the drawdown. It exceeded the stops.

Why the rule exists at the firm

Two reasons, and it is worth understanding both because they shape how tightly firms enforce it:

Risk control across the book. A firm holding hundreds of accounts cannot hedge a shared directional exposure that every account carries into a weekend. Forbidding the hold removes a correlated tail risk from the entire portfolio at once.
Accountability for the gap. A gap is un-hedgeable and uncontrollable, which makes it the worst possible event for a firm that has to defend a maximum drawdown. It is the one loss that cannot be managed by skill, so the rule removes it by construction.

That is why the rule is usually a hard restriction with no fee-based workaround, unlike a daily-loss soft breach. Firms are not selling you a product you can pay to keep; they are removing an unmanageable risk from their book.

The two shapes of the rule

"Don't hold over the weekend" is written in at least three different ways, and they are not equivalent:

No positions held through Friday's close. You must be flat before the close. The strictest form.
No positions opened within a window before the close. You may hold a position opened earlier, but cannot add near the close. This is a hedging of the same risk, and it interacts with your entry timing rather than your holding policy.
Instrument-specific. Some firms ban weekend holds on indices and FX but allow them on others, or vice versa. The restriction is in the instrument list, not the general rulebook.

Assume the strictest interpretation until you have read the firm's specific account-type rules. A general marketing page saying "swing trading allowed" frequently refers to the funded account, not the evaluation, or to a specific programme. Whether that gap is fatal depends on which drawdown model the firm runs: on a static floor you can absorb it, on a trailing floor the same gap closes an account that looked safe — trailing vs static drawdown simulates the identical trade sequence under both.

Is your edge actually a gap edge?

The question that decides everything: strip the overnight moves out of your backtest and look at what is left.

A quick way to do it — recompute the strategy using only the intraday path:

// Does the edge survive without the gap?
// Take the same signals, but close the position before the session ends
// and re-enter at the next open instead of holding through it.
function withoutGaps(trades) {
  return trades.map((t) => ({
    ...t,
    // Replace the overnight return with zero: the position is flat across the gap.
    pnl: t.pnlIntraday,
  }));
}

function withGaps(trades) {
  return trades.map((t) => ({ ...t, pnl: t.pnlIntraday + t.overnight }));
}

If the difference between withGaps and withoutGaps is most of the strategy's total return, the edge lives in the gap. That is not a flaw in the strategy — it is information. It means the strategy is incompatible with any firm that forbids the hold, and the correct response is to filter the firm list by that constraint before comparing anything else, not to try to trade it anyway.

If the difference is small, the strategy has an intraday core and the overnight component is noise. In that case the rule costs you little and you can ignore it.

The failure mode to guard against

The dangerous version of this is a trader who knows the rule, believes the overnight component is small, and is wrong — because the backtest understated it. Backtests frequently misprice overnight exposure in three ways:

They fill at the close rather than the open, silently avoiding the gap.
They assume the stop was honoured at its price on the gap bar.
They use continuous synthetic bars that do not have gaps at all.

Each of those turns a real weekend risk into a modelled non-event. The fix is to reconstruct the strategy on actual session-boundary data, with the open price as the only fill available after a gap.

What to write down

Before buying any evaluation, three numbers:

The rule, in the firm's exact wording. Which instruments, which programme, which account type.
The overnight share of your edge. The withGaps minus withoutGaps difference, as a fraction of total P&L.
The gap risk in account currency. The worst historical weekend gap in your instrument, times your typical size — expressed in the drawdown's units, not pips.

If (2) is large, the rule is disqualifying for that firm and no sizing fixes it. If (3) is large relative to your remaining room, the same is true even for a small gap edge. The rule is not a formality you sign past; it is a constraint that eliminates some strategies and some firms, and the arithmetic that decides which is short and knowable in advance.

The firm-by-firm version of the rule — which programmes permit weekend holds, which ban them outright, and where the instruments differ — is in the weekend holding rules breakdown.