Phase 1 to Phase 2 to Funded: How a Prop Firm Account Lifecycle Works

Why the lifecycle needs a four-column mental model

A prop firm's candidate journey looks simple from the outside — buy a challenge, pass it, get funded, get paid. Underneath, each stage is really four things happening in coordination: a CRM state change, a trading platform action, a risk/rule check, and — at several points — a human decision. Firms that only model the CRM side end up with accounts that are "funded" in the database but not actually provisioned on the platform, or payouts that are "approved" without a corresponding risk check ever running. Walking through the lifecycle stage by stage, across all four columns, is the only way to catch those gaps before they become support tickets.

Purchase
   |
   v
Account Provisioned  -----> [Platform: account created]
   |                        [CRM: candidate record + phase 1 state]
   v
Phase 1  (rules evaluated continuously) --- Failed/Breached --> Reset / Retry offered?
   |                                                                |
   | target + conditions met                                       v
   v                                                          [back to Purchase/
Phase 1 Passed                                                 Account Provisioned]
   |
   v
Phase 2  (rules evaluated continuously) --- Failed/Breached --> Reset / Retry offered?
   |
   | target + conditions met
   v
Evaluation Passed
   |
   v
KYC / Review  ---- Manual Review / Suspended (docs, checks) ---> resolved -> continue
   |                                                            \-> rejected -> closed
   v
Funded Account  -----> [Platform: funded account provisioned]
   |                   [Risk: live monitoring begins]
   v
Trading  (ongoing) <---------------------------+
   |                                            |
   v                                            |
Payout Request                                  |
   |                                            |
   v                                            |
Review  (risk + ops check) --- flagged --> Manual Review / Suspended
   |
   v
Payout  -----> [Payments: funds sent]
   |
   v
Scale / Repeat  --------------------------------+

Purchase

A candidate selects a programme and pays. The prop firm CRM records the order against the product catalogue configuration (account size, phase structure, price) and hands off to payments processing. The trading platform is not involved yet. Human operations are typically only involved if the payment itself fails or needs manual reconciliation — otherwise this stage is fully automated in a mature setup.

Account provisioned

Once payment clears, an account has to actually exist on the trading platform — this is a distinct technical event, not a status label. In MT4/MT5 environments this is commonly done through the MT5 Manager API, which creates the account, assigns it to the correct group with the programme's starting balance and permissions, and returns credentials back to the CRM to deliver to the candidate. The CRM marks the candidate's phase-one state as active and starts the rule engine's tracking window. Operations involvement here should be near zero in a well-automated build; manual account creation is a sign of an integration gap, not a normal operating mode.

Phase 1 and Phase 2

Trading happens on the platform; the rule/risk logic evaluates it against the phase's conditions continuously, as described in detail in our challenge engine article. The CRM's job during this stage is to reflect current status back to the candidate — equity, progress toward target, days remaining — without itself deciding pass or fail; that decision belongs to the rule engine. Operations is generally passive here unless a flagged case needs review. When a phase is passed, the CRM records the transition and either provisions a new account for the next phase or updates the existing one's state, depending on how the firm's programme is built; when a phase fails or is breached, the CRM updates status to failed/breached and, if the firm supports it, offers a reset or retry — which loops back to a new purchase or provisioning event rather than reviving the old account.

Evaluation passed

This is a CRM state, not a platform state — the platform has no notion of "evaluation," only account activity. The CRM logs that all required phases and conditions were met and moves the candidate into the next workflow stage. This is also where firms differ most in process: some move a candidate straight to funded provisioning, others insert a distinct verification phase first, and that difference is a business decision, not a technical constraint.

KYC / review

Before capital or a funded account is issued, most firms require identity verification and a review of the account's trading history for anything the rule engine may not have caught automatically — this is inherently a human-and-process step, sitting with prop firm operations, even where document checks are assisted by automated tooling. Outcomes here are resolved-and-continue, or rejected. A candidate can also land in a suspended or manual-review state at this point if documentation is incomplete or a flag was raised during evaluation — this is an exception state, not part of the standard path, and it should be visible to operations as a queue, not buried in a generic "pending" status.

Funded account

A funded account is a new (or reconfigured) provisioning event on the trading platform, usually with different permissions, balance and risk parameters than the evaluation account — funded capital is not simply the evaluation account relabelled. Automated risk technology such as RiskMan typically begins live monitoring at this point, because the firm's own capital is now at stake rather than a challenge fee. The CRM records the funded status and the terms that apply going forward, which may differ from the evaluation phase's rules.

Trading (ongoing)

The funded trader trades on the platform indefinitely, subject to whatever ongoing rules the firm applies to funded accounts — these are a distinct configuration from evaluation-phase rules and should never silently inherit them. Risk monitoring runs continuously in the background; the CRM's role is largely dashboard and status reporting to the trader unless a violation or scaling milestone is reached.

Payout request, review and payout

A trader requests a payout through the CRM. This triggers a review combining risk checks (has trading activity been consistent with the account's rules and with the firm's anti-abuse policies) and operational checks (is the request within programme terms, is KYC still current). Only after that review clears does the request move to prop firm payments & payouts, where funds are actually transferred — a step the CRM and risk system do not perform themselves, since moving money is the payment provider's function. A flagged request routes to manual review rather than proceeding automatically; this is one of the more consequential exception paths in the whole lifecycle, since it directly affects trader trust. Our dedicated piece on payout infrastructure covers this stage in more depth.

Scale / repeat

Where a firm operates a scaling plan — increasing a funded trader's capital allocation based on sustained performance — that is a CRM-tracked milestone informed by the risk system's performance data, resulting in another account reconfiguration on the platform. Not every firm offers scaling, and the mechanics differ enough between firms that no single model should be assumed; check any specific firm's published terms rather than generalising.

Exception states across the lifecycle

Operator checklist: verifying the lifecycle end to end

• Walk one candidate through every stage in a staging environment and confirm each handoff — CRM to platform, platform to rule engine, rule engine back to CRM — fires correctly and within an acceptable time window.
• Confirm funded-account provisioning is a distinct event from evaluation-account provisioning, with its own permission and risk configuration.
• Check that manual review queues surface enough context (account history, the specific rule or check that triggered review) for operations to act without re-requesting data.
• Confirm payout review is a separate, logged step before funds move — not a status flag that payments processing trusts blindly.
• Verify reset/retry provisions a genuinely new account rather than reactivating a breached one.

Operator checklist: ownership by system, not by assumption

• CRM: candidate record, phase/status display, KYC workflow, payout request intake, communications.
• Trading platform: account creation, order execution, equity/balance/trade history recording.
• Rule/risk logic: phase evaluation, breach detection, ongoing funded-account risk monitoring.
• Operations: manual review decisions, KYC adjudication, dispute handling, exception resolution.
• Payments/PSPs: moving funds for payouts, once review has cleared — never before.

Frequently Asked Questions

Is "Evaluation Passed" the same event as a phase being passed?

No. A phase pass (Phase 1 Passed, Phase 2 Passed) is a rule-engine determination about a single phase. "Evaluation Passed" is the CRM-level milestone that all required phases and conditions for the whole programme have been satisfied, which can involve more than one phase-pass event.

Does KYC always happen before funding, or can it happen earlier?

Firms differ on timing — some run identity checks at purchase, others only before funding is released. Architecturally, the review step before a funded account is provisioned should not be skipped regardless of when initial KYC was collected, since account details or risk profile can change between purchase and passing an evaluation.

What actually changes on the trading platform when an account becomes funded?

Typically the account is reconfigured or reprovisioned with different permissions, balance and risk group settings than the evaluation account carried — the specifics depend on how a firm's platform environment and MT5 Manager API integration are set up, and are not standardised across platforms.

Who decides whether a suspended account gets reinstated?

This is a human operations decision, informed by whatever data the rule engine and platform can supply about the account's history. It is not something the rule engine or the platform resolves on its own.

Can a trader be in "Trading" and "Manual Review" at the same time?

Operationally yes — a flagged concern can be under review while trading continues, or a firm may choose to pause trading pending review, depending on the severity of the flag and the firm's own policy. The lifecycle model should support both without forcing a single rigid path.

Related Prop Firm Research

• How Prop Firm Challenge Engines Work: Rules, Phases, Breaches & Automation
• Prop Firm CRM Architecture: From Challenge Purchase to Funded Account
• Prop Firm Payout Infrastructure: Requests, Review, Risk Checks & Payment Operations
• Prop Firm Technology Stack: CRM, Trading Platform, Risk, Payments & Operations
• All prop firm research