Stage 3 · Free
Funded futures accounts have two categories of negative outcomes. A recoverable breach — daily loss limit trigger, consistency hold, or session halt — closes a session or delays a payout but leaves the funded account active. A terminal deactivation permanently closes the funded account. Four conditions produce terminal deactivation: trailing drawdown floor breach, inactivity dormancy clause, fee-lapse, and account integrity violation. Each condition has a distinct cause, a distinct consequence, and a distinct prevention requirement. The full taxonomy is specified in the funded account agreement's deactivation conditions section — the section most traders do not read until after a deactivation event.
Part 1 of 4 — The outcome taxonomy
The taxonomy matters because the appropriate response to each outcome type is different. A recoverable breach requires a behavioral correction and a return to the pre-session routine. A terminal deactivation requires a decision about whether to purchase a new evaluation or switch firms — not a reset, because there is nothing to reset. See how the funded futures account agreement differs from the evaluation agreement for where the deactivation conditions section appears in the funded account agreement and why the evaluation agreement's funded-phase preview often does not enumerate the terminal conditions in equivalent detail.
Three events produce recoverable breaches. A daily loss limit trigger closes the current trading session: the platform auto-liquidates open positions when the DLL amount is reached, the session ends, and the funded account's balance reflects the session's net loss. The funded account remains active. The next session begins with the account intact and a fresh DLL calculated from the current balance. A consistency hold blocks a pending payout request: when the best-day percentage in the current payout period exceeds the consistency cap, the payout is delayed until the denominator grows enough to bring the ratio within the cap — or until the consistency window resets after an approved payout. The funded account continues operating during a consistency hold. A session halt is a platform-level event, not a rule event: the platform stops an open position due to a technical issue, margin breach, or news-window restriction. The session ends, the funded account continues, and no rule breach is recorded unless the session's loss triggered the DLL first.
The common structure across all three recoverable breach types: the funded account remains active and continues generating payout eligibility. The trading session or the payout request is what is affected — not the funded account itself. See how to recover from a drawdown on a funded futures account for the protocol that applies after a DLL trigger pushes the balance into the drawdown recovery range — the recovery phase is a funded account status, not a separate breach category.
Four conditions produce terminal deactivation. A trailing drawdown floor breach closes the funded account when the balance falls below the floor. Inactivity dormancy closes the funded account when no qualifying session is completed within the dormancy window specified in the funded account agreement. A fee-lapse deactivation closes the funded account when the required monthly platform or data fee is not in active status on the deactivation date. An account integrity violation closes the funded account when the firm classifies a behavioral or structural breach as non-remediable — typically account-sharing, a third-party trading service, or a pattern of prohibited instrument use the firm determines was intentional.
The common structure across all four terminal deactivation types: the funded account is closed, and no restart option exists for that account. The path forward after a terminal deactivation is a new evaluation — at the same firm or a different firm — not a reset of the existing funded account. The only funded account with a recovery path is one in the drawdown recovery phase after a DLL trigger: the floor has not been breached, the account is active, and the recovery protocol is a below-ceiling sizing discipline until the balance rebuilds. Once the floor is breached, the recovery path from the drawdown recovery article does not apply — the account is gone. See what happens when a funded futures firm closes for the scenario where the firm's deactivation of accounts is involuntary — a firm closure is distinct from account-level terminal deactivation but shares the same structural outcome: no active funded account and a pending payout that is no longer guaranteed.
Part 2 of 4 — The three recoverable breach types
Understanding the DLL trigger's mechanics — specifically what it does not do — prevents the confusion that leads to over-trading in recovery. The DLL trigger does not breach the trailing drawdown floor. It closes the session. The floor may have advanced closer to the current balance if prior sessions were profitable, which means a DLL trigger in a drawdown session can leave the account with a smaller gap between the balance and the floor than before — but the floor breach is a separate event that requires the balance to fall below the floor, not just approach it.
When the intraday DLL is reached, the platform auto-liquidates all open positions. This is not a discretionary action — the platform executes the liquidation when the session's net loss hits the DLL amount. After liquidation, the session is over. The trader cannot place additional trades for the remainder of the trading session. The funded account's balance reflects the session's net loss, and the DLL resets at the next session's open — the DLL is not a running total across sessions but a per-session limit that recalculates from the current balance each day.
Three outcomes are possible at the next session depending on the firm's funded account structure. First, the account continues at full sizing with no record of the DLL trigger beyond the balance reduction — the trader returns at the same contract ceiling as before the DLL trigger. Second, the account continues but is flagged for additional review: the firm's automated monitoring detects the DLL trigger and places the account in a review queue; if the trigger is consistent with normal trading activity the review clears and no further action is taken; if the trigger pattern suggests a rule problem the firm may initiate a manual audit. Third, the account is paused for a 24-hour period: some firms use a mandatory cool-down after a DLL trigger before the account can resume trading. The funded account agreement specifies which of these three structures applies — the agreement's deactivation conditions section often contains the cumulative breach limit, which is distinct from the per-trigger consequence. A cumulative DLL breach limit specifies that if DLL triggers accumulate to a defined threshold within a single payout period — for example, three DLL triggers in one period — the funded account is deactivated rather than continued. The cumulative limit converts a recoverable breach into a terminal deactivation when the threshold is crossed. See how to handle a losing streak on a funded futures account for the four-threshold decision tree that applies when DLL triggers cluster — the decision tree is the preventive protocol against hitting a cumulative breach limit.
A consistency hold is not a funded account status — it is a payout request status. When the best-day percentage in the current payout period exceeds the consistency cap, the payout request is ineligible. The funded account continues operating. Trades can still be placed. The balance continues to grow or decline. The consistency hold resolves in one of two ways: the denominator grows large enough through additional profitable sessions to bring the best-day percentage within the cap, or the payout period resets after an approved payout and the window starts fresh for the next period.
The key distinction: a consistency hold does not threaten the funded account. It delays payout eligibility. The risk associated with a consistency hold is behavioral — not rule-based. A trader in a consistency hold who increases position size to accelerate the denominator growth, or who takes on higher-risk sessions to generate more qualifying profit days, introduces DLL risk that did not exist before the hold. The consistency hold requires patience and continued adherence to the same pre-session sizing routine. It does not require a change in position size. See how the consistency rule works on a funded futures account for the denominator mechanics and how the window resets after an approved payout — the same mechanics govern how long a consistency hold lasts.
A session halt is a platform-level event. The most common causes are a technical disconnect during an open position (the platform closes the position at the prevailing price when the connection is restored or after a timeout), a margin breach that triggers forced liquidation below the DLL threshold (the position is liquidated before the DLL is reached because margin requirements are not met at the current position size), or a news-window trading restriction on platforms that enforce firm-specific hour restrictions automatically. In each case, the session ends — open positions are closed — but no funded account rule breach occurs unless the position's loss exceeded the DLL at the time of liquidation.
Session halts are distinguished from DLL triggers by the cause and the consequence. A DLL trigger is a rule event: the platform reaches the DLL amount and liquidates. A session halt is a platform event: the platform stops the position for a non-rule reason. From a funded account perspective, what matters is the session's net P&L: if the halt produced a loss that brought the balance below a level that requires a drawdown recovery protocol, that protocol applies regardless of whether the session ended via DLL trigger or platform halt. The funded account's deactivation conditions section does not typically classify session halts as rule events. A platform halt is not listed as a breach type in most funded account agreements.
Part 3 of 4 — The four terminal deactivation conditions
Three of the four terminal conditions are preventable with routine tracking that takes under two minutes per session: checking the gap between the balance and the trailing drawdown floor, logging the most recent trading date, and confirming the monthly fee is in active status. The fourth — account integrity violation — is preventable through instrument and account compliance only. The funded account agreement specifies each condition's threshold. The evaluation agreement's funded-phase preview section typically does not preview the inactivity window, the fee-lapse consequence, or the cumulative breach limit with the same precision as the funded account agreement — which is why the funded account agreement's deactivation conditions section must be read before the first funded session.
A trailing drawdown floor breach occurs when the funded account's balance falls below the trailing drawdown floor. The floor advances as the balance rises above the starting value and locks when the balance exceeds the starting value by the full DTF distance. Once locked, the floor is permanent at the lock level — it does not recede if the balance falls back. If the balance subsequently falls below the locked floor through trading losses, the funded account is permanently closed.
The floor breach is terminal and immediate. There is no warning notification before the breach closes the account — the breach occurs when the balance falls below the floor, and the platform or firm closes the account at that point. Unlike a DLL trigger, which stops losses at the DLL amount before the floor can be breached in most sessions, a floor breach occurs when losses accumulate across sessions without the DLL triggering first — or when a single session's loss is large enough to push the balance below the floor even after the DLL triggers. The most common sequence: the floor has locked at a high level after a strong profit run, the account enters a drawdown phase, and losses across multiple sessions reduce the gap between the balance and the locked floor to zero. The prevention protocol — below-ceiling sizing during drawdown recovery, mandatory session halt at the DLL÷6 recovery ceiling — is designed specifically to prevent this sequence. See funded futures trailing drawdown floor mechanics for the complete floor lifecycle including how the lock mechanism works and why the locked floor is the permanent reference level that determines when a breach occurs.
If a payout request is pending when the floor breach occurs, the outcome depends on the funded account agreement's terms. Most agreements specify that payout requests are voided by a floor breach, converting an approved payout into an unsecured claim. The practical prevention: submit payout requests as soon as eligibility criteria are met, not at the end of a payout period. The gap between approval and fund transfer is the window during which a floor breach can void an otherwise approved payout.
The inactivity dormancy clause specifies that the funded account is deactivated if no qualifying session is completed within a defined calendar window. Most funded account agreements use a 30-calendar-day dormancy window. The window begins from the date of the last qualifying session. A qualifying session is typically defined as a session with at least one closed trade — a position that was opened and closed on the same trading day. Some firms add a threshold: a qualifying session must produce a closed P&L above a minimum amount, or must include a minimum number of completed round-trip trades. The funded account agreement specifies the definition. A session where a position was opened but not closed does not typically count as a qualifying session for dormancy purposes.
The inactivity dormancy clause is the most often triggered terminal condition during planned trading breaks. A trader who plans a two-week vacation without checking the dormancy window in the funded account agreement may return to find the funded account deactivated if the 30-day window expired during the break. The prevention: before any break longer than two weeks, check the dormancy window in the funded account agreement, calculate when the window expires from the date of the last qualifying session, and either complete a qualifying session before the break if the window expires during the planned break period, or contact the firm's support team in writing before the window expires to request a dormancy extension. Many firms offer a one-time extension for planned breaks — the extension request must be submitted before the window expires, not after deactivation. The response should be in writing and should specify the new window length. See what to do while waiting for your funded futures account to activate for the activation window documentation requirements that mirror the dormancy window tracking requirement — both require a written record of the timeline and the firm's confirmation.
Most funded futures firms charge a monthly platform fee, a data fee, or both. The funded account agreement specifies the fee amount, the billing date, and the consequence of a missed payment. In most structures, a missed fee triggers a notice period — the firm sends a notice that the fee is overdue and that the funded account will be deactivated if the fee is not resolved within a specified number of business days. If the fee is not resolved within the notice period, the funded account is deactivated. Some firms deactivate without a notice period if the funded account agreement specifies that fees are due in advance and a lapse voids the account.
Fee-lapse deactivation is distinct from the evaluation fee: the evaluation fee is paid once to enter the evaluation, and the funded account's ongoing fee is a separate recurring charge for platform access and data feed while the funded account is active. A common mistake: assuming that a firm's monthly evaluation subscription fee covers the funded account. In many cases the fee structures differ. The funded account agreement specifies the funded account's fee separately from the evaluation fee. Confirm the funded account fee amount and billing date from the funded account agreement before the funded account goes live. Set a calendar reminder for the billing date each month and verify that the payment method on file is valid before the billing date. If the payment fails for any reason, resolve it before the notice period expires — the funded account agreement specifies the grace period. See how funded futures firm rules actually differ for the fee structure variation across firms — the fee amount, billing date, and notice period are all firm-specific and must be confirmed from the funded account agreement, not assumed from the evaluation agreement's funded-phase preview.
An account integrity violation is a breach the firm classifies as non-remediable — meaning the breach cannot be corrected and the funded account cannot continue under any recovery protocol. Three types of behavior produce account integrity violations in most funded account agreements. First, trading prohibited instruments in a pattern the firm's audit determines was intentional: a single accidental trade of a prohibited instrument may produce a post-hoc rule breach or a net profit discrepancy review, but a repeated pattern or a pattern on instruments explicitly banned in the funded account agreement's prohibited instruments clause may be classified as an intentional account integrity violation. Second, account-sharing: evidence that a third party other than the registered account holder has placed trades in the funded account. This is typically detected through device fingerprinting, IP address variation outside the account holder's expected geography, or trading patterns that deviate significantly from the account's prior history. Third, a third-party trading service: evidence that the funded account is being operated by an automated system or a third-party provider rather than the registered account holder. The funded account agreement prohibits third-party trading services, and firms audit for this through pattern recognition and session metadata.
Account integrity violations are permanent closures. They may also result in forfeiture of any balance above the trailing drawdown floor, voiding of all pending payout requests, and in some cases a ban from the firm's evaluation program. The funded account agreement's account integrity section specifies the full consequence set. Prevention is compliance-only: trade the permitted instruments, trade only from the account holder's own devices, and do not use third-party automated systems on the funded account. There is no recovery protocol for an account integrity violation because the breach is behavioral, not performance-based — the firm's position is that the account was not operated according to the agreement's terms from the point of the violation, and the funded account agreement is void as of that point.
Part 4 of 4 — What to track to prevent each terminal condition
Prevention begins with the funded account agreement. The deactivation conditions section specifies the trailing drawdown floor parameters, the dormancy window, the fee billing date and notice period, and the account integrity classification criteria. Each threshold that produces a terminal deactivation has a corresponding metric to track in the pre-session routine. If the metric is not in the pre-session routine, the terminal condition can be reached without notice. See how to read your funded futures account agreement after passing for the four-section reading framework that extracts all eight inputs — including the dormancy window and fee-lapse notice period — before the first funded session.
The trailing drawdown floor breach is the most common terminal deactivation and the one with the least external warning. The prevention metric is the floor gap: the difference between the current account balance and the trailing drawdown floor. This metric should be in the pre-session routine as one of the five dashboard checks before any position is placed. A floor gap above the DLL amount is normal operating range — a DLL trigger in the next session cannot push the balance below the floor unless the loss exceeds the floor gap, not just the DLL. A floor gap below the DLL amount requires immediate attention: a DLL trigger in the next session will not prevent a floor breach if the gap is smaller than the DLL amount, because the DLL trigger stops at the DLL amount while the floor breach occurs at the floor level. If the floor gap is below the DLL amount, sizing must be reduced to a level where a full-DLL session cannot breach the floor.
For EOD trailing drawdown model accounts, the floor gap is stable between sessions and updates at settlement. For intraday trailing drawdown model accounts, the floor gap changes during the session as the floor advances in real time with unrealized gains — which means the floor gap must be recalculated after any session where the balance reached a new high, even if the session closed flat. The pre-session floor gap check uses the current dashboard balance and the current floor level, both of which should be read from the firm's dashboard rather than calculated from the prior day's values. See funded futures trailing drawdown floor mechanics for the floor advancement formula and when the floor locks — the lock level is the permanent minimum floor gap that determines when a breach occurs.
The inactivity dormancy clause is prevented by tracking one metric: the number of calendar days since the last qualifying session. This metric should appear in the trading journal as a date field — the date of the most recent session with at least one closed trade. Before any break from trading, calculate the number of calendar days from the planned last session to the planned return date, and compare it to the dormancy window in the funded account agreement. If the gap exceeds the dormancy window, the funded account is at risk of deactivation during the break.
The action threshold: if the planned break will produce a gap greater than the dormancy window minus seven days, take one of three actions before the break begins. First, complete a qualifying session on the last day before the break to reset the dormancy clock. Second, contact the firm in writing before the break to request a dormancy extension, with the break dates specified. Third, if neither option is viable, consider whether the break length should be shortened to stay within the dormancy window. The seven-day buffer before the window expires allows for the firm's response time on an extension request. Do not wait until the window is about to expire to contact the firm — some firms require extension requests to be submitted at least 48 hours before the window expires. The funded account agreement specifies the extension request process if one exists.
The fee-lapse deactivation is prevented by a monthly calendar reminder. Before the billing date each month — which is specified in the funded account agreement and typically confirmed in the funded account activation email — verify that the payment method on file with the firm is valid and that no outstanding fee balance exists. If the payment method changed since the funded account was activated (a new card number, an expired card, or a changed bank account), update the payment method before the billing date. If the billing date falls during a period when the trading account is not being actively monitored — a travel period, a break from trading, or a holiday — set the calendar reminder to trigger at least five business days before the billing date so there is time to resolve a payment issue before the notice period expires.
The funded account agreement's fee-lapse section specifies the notice period between a missed payment and deactivation. If the notice period is 7 business days, a missed payment on the 1st of the month produces deactivation on or after the 10th. If the notice period is 3 business days, the window is much tighter. Knowing the specific notice period from the funded account agreement determines the urgency with which a missed payment must be resolved. A firm that sends a notice by email should have that email address active and monitored — a missed fee notice that goes to a spam folder during a trading break can expire without the trader knowing the notice was sent.
Account integrity violations are not preventable through metric tracking — they are preventable through compliance only. The three prevention requirements correspond to the three types of account integrity violations: trade only the instruments permitted by the funded account agreement's instrument list, trade only from the account holder's own devices, and do not use third-party trading services or automated systems on the funded account. Each requirement is binary — either the account is in compliance or it is not. There is no threshold to approach and a corresponding adjustment to make.
The instrument compliance requirement is the one most often breached accidentally. Instrument permissions vary by firm and by account tier — some firms permit crypto futures at the funded level, some prohibit them; some permit micro-versus-standard contract substitutions, some do not; some have news-window hour restrictions enforced at the instrument level. Before the first funded session, confirm the instrument permissions from the funded account agreement's prohibited instruments section, not from memory of what was permitted during the evaluation. The funded account agreement may permit fewer instruments or more instruments than the evaluation agreement's funded-phase preview described. See funded futures evaluation prohibited instruments for the two-category compliance structure — the same structure applies to the funded account's instrument compliance requirement, with the funded account agreement's instrument list as the operative reference.
No. A daily loss limit trigger closes the current trading session — the platform auto-liquidates open positions when the DLL amount is reached — but the funded account remains active. The next session begins with the account intact and a fresh DLL calculated from the current balance. The funded account closes permanently only when the trailing drawdown floor is breached, which is a separate event from a DLL trigger. However, most funded account agreements contain a cumulative breach limit: if DLL triggers accumulate to a defined threshold within a single payout period, that threshold can trigger a terminal deactivation rather than a recoverable breach. The funded account agreement's deactivation conditions section specifies whether a cumulative limit applies and what the threshold is.
A daily loss limit trigger closes the session when the session's net loss reaches the DLL amount. The funded account continues. A trailing drawdown floor breach occurs when the funded account's balance falls below the trailing drawdown floor — a different threshold set by the highest balance reached, not by the DLL amount. The floor breach permanently closes the funded account. In most sessions, a DLL trigger stops the session's loss before the balance falls below the floor. But if the floor has locked at a high level during a prior profit run and the account enters a drawdown phase, the gap between the current balance and the locked floor can narrow to a point where a DLL trigger's loss brings the balance close to or below the floor. The floor gap — the difference between the current balance and the floor — is the metric to track to prevent a floor breach.
The dormancy window is specified in the funded account agreement's deactivation conditions section. Most firms use a 30-calendar-day window from the date of the last qualifying session. A qualifying session typically requires at least one closed trade. Before any break longer than two weeks, calculate the gap between the last qualifying session and the planned return date, compare it to the dormancy window, and either complete a qualifying session before leaving or contact the firm in writing to request a dormancy extension. The extension request must typically be submitted before the window expires, not after deactivation. Check the funded account agreement for the specific window length, qualifying session definition, and extension request process — these vary by firm.
Most funded account agreements specify that payout requests are voided by a trailing drawdown floor breach, converting an approved payout into an unsecured claim. For deactivations triggered by inactivity, fee-lapse, or account integrity violations, the funded account agreement's deactivation conditions section specifies the payout outcome — some firms honor pending payouts that were approved before the deactivation event, others void all pending requests on deactivation. To reduce the risk of losing a pending payout, submit requests as soon as eligibility criteria are met rather than waiting for the end of a payout period. The gap between submission and fund transfer is the window during which a deactivation can void an otherwise approved payout.
Funded account agreements classify three types of behavior as account integrity violations that produce permanent closure: trading prohibited instruments in a pattern the firm determines was intentional, account-sharing where a third party places trades on the account, and use of a third-party trading service or automated system. These are classified as non-remediable because they represent a fundamental breach of the account agreement rather than a performance rule failure. Prevention is compliance-only: trade only permitted instruments, trade from the account holder's own devices, and do not use third-party trading services. There is no recovery protocol for an account integrity violation.
Founding 100
The Founding 100 closes when 100 members are in. After that, pricing moves to the standard rate. If you're reading the library and working through evaluations, the founding tier is the time to join.
See the Founding 100 offer