Prop Firm Payout Rules: From Eligibility to Money Received

This guide follows that process through selected CFD/FX and futures examples and one hypothetical calendar. It focuses on when a payout becomes available and how it reaches you. The amount you can request is a separate calculation.

For the stages before a payout, see how prop firm challenges work from purchase through funded-stage trading.

What happens between trading profit and a payout?

A profitable account has reached only one part of the process. Firms may call the payment a payout, a reward (FTMO), a Performance Reward (FundedNext), or a withdrawal (The5ers). Those labels do not identify whether a request, an account debit, or a cash receipt has occurred. Use the following stages to understand what has happened and what remains outstanding. A firm's dashboard may combine stages or use different labels; check what each label actually confirms.

Define the destination. Money received by a payment provider can still require a separate withdrawal before it reaches your bank. Likewise, a trading-account debit confirms that its balance changed; it does not prove that money arrived elsewhere. Under a profit split or payment deduction, the account debit and cash received can also differ in amount.

The advertised account balance also need not be withdrawable capital. For example, FTMO describes real-money rewards earned on its simulated CFD accounts, subject to its objectives and agreement. The payout concerns eligible performance under those terms.

The account-size and loss-allowance guide explains what the displayed account size means and how it differs from the room available for losses.

What must you satisfy before requesting a payout?

Check the whole set of conditions, not just the waiting period. A request can depend on several requirements being satisfied together:

• Account stage and status: the correct funded-stage account, required agreement or activation, and compliance with the applicable trading rules.
• Time and activity: a minimum interval, a number of traded sessions, or a number of sessions meeting a defined profit threshold.
• Performance and amount: positive or eligible profit, a consistency condition, minimum account value, and an amount that fits the applicable request limits.
• Trading state: closed positions or canceled pending orders if required, and any restriction on trading while the request is reviewed.
• Identity and payment setup: required verification, documents, supported destination, and correctly completed payment details. Some checks happen earlier; others can occur after approval.

The three eligibility checkpoints separate purchase access, funded onboarding, and the provider checks needed for a usable payout destination.

Read the definition behind a day count. A calendar day, a day with a trade, and a session with at least a specified net profit are different units. Ask which timezone defines the session, whether charges are included, and whether the days must be consecutive.

For a calendar showing which sessions qualify, how costs change the count, and when the waiting period finishes, see minimum trading days and profitable days.

Also separate the threshold needed to qualify from the amount allowed in a request. Satisfying one does not satisfy the other. Record the amount rules even when your immediate question is timing. Keep cash reimbursements and purchase credits separate from trading rewards when recording what a payout returns to you.

A short consistency calculation

Consider a separate hypothetical rule: the largest profitable session must be no more than 40% of total net profit, measured from the first funded session through the request. At least three traded sessions are required. All results below are realized after trading costs, losses reduce the denominator, no payout has occurred, and all other eligibility conditions are satisfied.

Four completed sessions produce +$600, +$500, −$200, and +$300:

Total net profit = $600 + $500 − $200 + $300 = $1,200

Largest-session share = $600 ÷ $1,200 = 50%

The session count is sufficient, but the 40% condition is not. If a fifth session adds $300 net, total profit becomes $1,500 and the largest session remains $600: 600 ÷ 1,500 = 40%. Equality is allowed under this hypothetical rule, so that condition is now met. It does not determine the permitted payout amount.

Use the actual program's denominator and measurement window. A rule based on the sum of profitable days needs a different calculation from one based on net profit after losing days.

For a daily ledger showing how losing days, different denominators, and a new best day change the result, see the consistency-rule calculation guide.

The hypothetical profit history in our first-payout study makes account age, qualifying days and consistency explicit before calculating the request and trader allocation.

Which event starts the first-payout clock?

It depends on the exact account and payout path. Account activation, the first trade, and completion of qualifying sessions can lead to different request dates.

These selected official descriptions were checked on 26 September 2026. They illustrate timing and activity requirements, not every condition for payment.

For how both Topstep paths apply to one account, see Topstep Trading Combine Standard's first funded payout requirements.

Do not transfer a rule between a firm's markets, evaluation and funded stages, or payout options. Even within one firm, a different path can change the answer.

Worked example: when does the money arrive?

Consider a hypothetical account, with its first funded-stage trading session on Monday, 7 September 2026. Its rules require:

1. Seven elapsed calendar days from that first session date.
2. Five sessions with at least $100 net profit each; they need not be consecutive.
3. Completed identity and payment setup, which finishes on Thursday the 10th.

Assume all other requirements are satisfied when the request is submitted. The dollar values below determine qualifying sessions only; they do not calculate a withdrawable amount. Sessions use one hypothetical program timezone, and net P&L already includes charges.

First, complete the overlapping eligibility conditions

The seven-day calendar wait finishes on Monday the 14th, but only four sessions have qualified. The fifth qualifies on Tuesday the 15th. Because this example does not require consecutive qualifying sessions, the losing session does not erase earlier qualifying sessions.

Because these requirements run in parallel:

Ready date = latest of calendar-wait completion, fifth qualifying session, and setup completion

Ready date = latest of 14 September, 15 September, and 10 September = 15 September

You do not add seven calendar days to five qualifying days. You wait until every requirement is satisfied. A different program could specify that one condition begins only after another, so the overlap must come from its actual rules.

Then follow the processing clocks

The complete request is submitted after the session on Tuesday the 15th. For this illustration, review takes two business days; the trader confirms the invoice and payment details the following day; dispatch then takes two business days; delivery takes another two business days.

Counting convention: business days are Monday–Friday, with no holidays. Each two-business-day clock starts counting on the next working date after its triggering event. There are no cutoff complications, additional document requests, or account-status changes. The example uses each stated duration in full. These chosen durations are neither industry averages nor promises about the fastest possible payment. We model dates, not exact times of day.

The Friday confirmation illustrates two sources of delay: a step controlled by the trader and a subsequent weekend. If confirmation happens later, the dispatch clock starts later. If verification remains incomplete, the request date itself may move. A real forecast also needs the relevant holiday calendar and submission cutoff.

What do “24-hour,” “instant,” and “on-demand” payouts mean?

Read the stated start and end events before comparing the numbers. A schedule can describe when requests are allowed; a speed claim can describe review, payment dispatch, provider credit, or final receipt.

“On demand” describes request availability only within its stated conditions. It does not mean unconditional access to all displayed profit or immediate bank receipt. Similarly, “every two weeks” is incomplete until you identify what starts each interval.

Current official examples show why the wording matters:

• FTMO's CFD reward process: account review and notification take 1–2 business days after requesting. Following approval and withdrawal-information submission, the reward is typically sent 1–2 business days after invoice approval. Those statements end at review and sending, respectively; neither gives a bank-arrival deadline. Reward FAQ
• FundedNext's published Brand Promise: its 24-hour clock starts with a submitted reward request, and its explanation distinguishes sending from method-dependent arrival. Bank-transfer requests are excluded from the promise; incorrect payment details also qualify responsibility for delays. This is a published commitment, not a measured payout-speed result. Clock definition · Terms and exclusions
• Topstep's Aeropay route for supported US bank accounts: the instant label applies after approval. Internal approval can take 1–3 business days; a bank without real-time support can add 1–3 business days. Payout policy
• Tradeify through Rise: the detailed instructions describe funds appearing in the Rise wallet within 24–48 hours after approval. The trader then requests a withdrawal; bank receipt is described as taking 1–3 business days. Provider credit and bank receipt are separate milestones. Rise instructions

Keep the source's units intact. Hours, business hours, business days, and trading sessions are not interchangeable. Do not assume two estimates use the same timezone, holiday calendar, or counting convention.

For comparisons, write a complete statement: “This interval runs from [event] to [event], for [account and method], subject to [conditions].” If the source does not identify those elements, the end-to-end timing remains unresolved.

When a speed claim comes from a review or screenshot, use the payout-record checks to identify the event actually documented, its source, and the limits of treating one observed payment as typical.

What can change while a request is pending?

Submitting a request does not prove that all checks have passed. A pending status may concern account review, a required document, payment-provider setup, or a transfer already in progress. Identify the stage before interpreting the delay.

Continued trading can also matter. Tradeify's Growth Funded policy permits trading after submission but says a request will be denied if the account fails or falls below the applicable payout thresholds before processing. It also allows only one pending request per account. Treat this as that program's rule, not permission to trade during every firm's review.

Payment setup is another dependency. Tradeify's Rise instructions include identity approval and acceptance of the firm's team invitation; manual verification can take 1–3 business days. Completing the prop firm's account setup does not mean that a separate provider has finished its checks.

If a request appears delayed, gather its ID, submission time, exact account, current status, requested documents, selected method, and any transfer reference. Ask which stage is incomplete, what action is required, and which published timing applies to that stage. A review deadline and a bank-transfer estimate answer different questions.

What should you check for the next payout?

Recheck the next cycle's starting event and requirements. Do not assume the first waiting period repeats from the date money reached your bank.

For example, The5ers' withdrawal FAQ describes later requests every two weeks from the last approved withdrawal. Scaling restarts its 14-day timer. Approval, receipt, and scaling are therefore different events to record.

For your account, check whether activity counts and consistency calculations restart, whether the next request requires new profit, and whether a pending request blocks another.

Eligibility does not tell you how much you can receive or what remains in the account afterward. First check the request minimum, any percentage or cash cap, the trader's profit share, and deductions. Then distinguish the amount debited from the trading account from the cash received. For the next trading cycle, recalculate the remaining balance and loss buffer using the rule's actual post-withdrawal treatment, including whether a threshold stays in place, resets, or applies to a new account. This timeline alone cannot determine a suitable withdrawal amount.

To calculate the amount, use the profit-split, payout-cap, and retained-buffer guide, which reconciles the gross request, firm share, fees, cash received, and account debit. Before trading again, use the post-payout account checklist to confirm the actual debit, new threshold, remaining buffer, and whether the same account continues. For background on how thresholds move, see static, EOD, and intraday overall max loss.

Before you pay: complete this payout worksheet

Use the exact program and funded-stage terms. Leave an unanswered field marked unknown and seek clarification before relying on it.

Next step: fill in the worksheet for one account you are considering, then trace its first payout using actual dates. Keep unverified processing stages open instead of turning the first available request date into a promised receipt date. Bring those findings into the before-you-pay program comparison alongside eligibility, trading permissions, loss rules, and costs.

Sources and method

Official pages checked on 26 September 2026:

• FTMO: How do I withdraw my reward?
• The5ers: Withdrawal requirements and High Stakes payout policy
• Topstep: Payout Policy and Express Funded Account Parameters
• FundedNext: 24-hour countdown and processing timeframe
• Tradeify: Rise payout instructions and Growth Funded payout policy

This guide combines desk research with an original hypothetical calendar. The dates and qualifying-day count were calculated from declared assumptions; they are not an observed trader payout. Published policies and service targets are not measurements of average processing times, approval rates, or comparative reliability. The checked date records the research date, not a contractual effective date.

Payment terminology and the Tradeify Growth Funded policy title and pending-request conditions were rechecked on 1 October 2026. Other source checks retain the date above.