Prop Firm Platform Requirements: Challenge-Account Infrastructure
A prop firm sells challenge accounts. Traders pay a fee to prove they can hit a profit target inside published risk rules. The ones who pass get simulated or real capital, and the firm takes a cut of the upside. It's a specific business — and most of what makes it work at the platform layer does not exist in a generalist multi-asset venue.
This playbook covers what that platform layer actually has to do. It's drawn from the team's ~30 years of combined experience shipping matching engines, hedging stacks and venue infrastructure. If you're weighing whether to license a platform, fork a generalist venue, or build in-house, this is the checklist your design has to pass.
The Challenge-Account Lifecycle Is a State Machine
Every funded trader moves through the same four states: evaluation, funded, breached, paid. Each transition fires on a specific event and gates a specific set of capabilities. The platform has to model this explicitly — not as feature flags sprinkled across the codebase, but as a first-class account-state field that the risk engine, the order router, the ops console and the ledger all read from the same place.
- Evaluation. Account funded with simulated capital, challenge fee collected. Trader can place orders inside published leverage and instrument limits. Every fill updates drawdown counters in real time. Hit the profit target and you transition to funded. Breach a rule and you transition to breached.
- Funded. Real capital now, or a mirrored allocation, with a profit-share agreement in place. The rule set often loosens a touch but drawdown limits stay. Payouts become eligible on a cadence.
- Breached. All open positions liquidated. All working orders cancelled. Account is read-only — the trader can view history and file a dispute but can't trade. Ledger frozen for audit.
- Paid. Payout window opens, profit-share calculates against the high-water mark, and USDT (or bank rail) settlement queues up for operator approval.
A generalist trading platform models accounts as "open" or "closed". A prop-firm platform needs the four-state model wired into every code path that touches an account. Retrofitting this into a venue built for direct-to-consumer trading is where most fork attempts stall out around month six.
Drawdown Tracking: Three Limits, Concurrent
Three drawdown limits run at the same time on every funded account. All three are load-bearing. All three need real-time evaluation. And all three need per-account tuning surfaces — different challenge products lean on different limits.
- Daily loss limit. Absolute or percentage loss from the day's starting equity. Resets at a published UTC cutoff. Breaches the instant cumulative daily P&L crosses the threshold — not at end-of-day settlement.
- Total drawdown. A static floor below the initial account size. A trader deposited (or allocated) $50k with a $2.5k total-drawdown limit can't let equity dip below $47.5k. Ever.
- Trailing drawdown. The floor moves up as new equity highs print, then locks (usually at the initial balance) once the account is in profit by more than the drawdown amount. This is the hard one — the trigger price is a function of the account's own P&L history, which is where most bespoke risk engines get it wrong.
All three have to evaluate on every fill and every mark-price update. Not close-of-bar. Not end-of-day. A trader who blows through the daily loss limit at 14:00 UTC and closes back to green by 15:00 has still breached — and a platform running an end-of-day check misses this and pays out on an account that should have been closed hours earlier. Real-time evaluation with atomic state transitions is the only design that holds up when the dispute email arrives.
Kill Switches and the Audit Trail
On breach detection, the platform has to do five things atomically:
- Cancel every working order on the account
- Liquidate every open position at market
- Transition the account state to breached
- Write a locked audit record — timestamp, triggering rule, equity at trigger, positions and orders at trigger, market prices at trigger
- Notify the trader with a specific reason
Atomicity matters. Liquidate first, then flip state, and you leave a window where new orders can still hit the book. Flip state first, then liquidate, and a failed liquidation call strands positions in a supposedly-closed account. The right pattern is a single ledger-committed transaction that flips state and enqueues the liquidation instructions together, with the matching engine reading account state as a hard gate on every incoming order.
The audit record is what defends the payout dispute six weeks later. A trader claiming "the platform closed me unfairly" gets answered with a timestamped record showing exactly which rule triggered, at what equity, with what positions open, and what the mark price was on each. Anything less and the firm eats the payout to dodge a chargeback fight.
Ops Console: Every Account, Every State, Drillable
The operator's risk team needs one console. Not one per rule-state. Not one per instrument. One console — every account, with the columns that actually matter for a prop-firm business:
| Column | Why it matters |
|---|---|
| Account state | Filter to funded-only, at-risk, breached-today |
| Equity vs. daily-loss floor | Who's close to breaching today |
| Equity vs. total-drawdown floor | Who's close to a permanent close |
| Open-position notional | Concentration and gambling-style sizing |
| Time in current state | Funded but idle 30+ days signals dropout risk |
| Pending payout | Who's queued for operator approval |
Every row drillable to the account's full position history, order history, and audit trail. Filters on rule-state, instrument, notional and time-window. Sortable on any column. This isn't a nice-to-have — without it, the ops team can't see which accounts are one bad fill from breaching, and can't investigate a dispute in under an hour.
See /platform/broker-ops for the shape of the ops surface the platform ships with.
Payout Automation: Fee In, Profit-Share Out
Three money flows run through a prop-firm platform:
- Challenge fee collection. Trader pays a fee to open an evaluation. Breach the challenge and the fee stays. Pass and it's often refunded on the first payout — a per-firm commercial choice the platform has to expose as config, not code.
- Profit-share calculation. Payout amount is the trader's share of profits above the high-water mark since the last payout. Common splits run 70/30 up to 90/10 in the trader's favour. The high-water mark persists across payouts and only resets on explicit operator action.
- Payout settlement. USDT to a trader-controlled address is the modern default. Bank rails still show up in some jurisdictions. Both need a 2FA gate on the trader side (confirming the destination), a 2FA gate on the operator side (approving the send), and a tx-hash record in the audit log.
At a hundred funded traders the ops assistant can run this manually. At a thousand it eats a headcount. The platform has to model the whole flow — fee collection, profit-share compute, 2FA gates, operator approval queue, tx-hash writeback — as first-class primitives. Not as a folder of admin scripts. See /pricing for how this is packaged.
Anti-Abuse Detection
Every successful prop-firm business attracts the same set of exploits. Traders are creative, and if there's a way to game the challenge without actually being profitable, someone will find it. The platform needs detection primitives for each:
- Cross-account hedging. Same trader running long on one account and short on another, guaranteeing at least one passes. Detect via IP, device fingerprint, funding-source and position-correlation clustering. Auto-flag for review — don't auto-close. False positives on legitimate multi-account traders get expensive fast.
- Martingale sizing. Position size doubling after every losing trade. Detect on a rolling per-account window. Flag at 2x consecutive. Auto-throttle at 4x.
- News-arb tactics. Coordinated positions right before high-impact news (NFP, CPI, FOMC), usually across many accounts under one operator. Needs an economic-calendar integration and a pre-news lockout window as per-firm config.
- Grid and gambling-style sizing. Full-account notional in one instrument, or a dozen tiny correlated positions that add up to the same thing. Both dodge the intent of drawdown limits without tripping them mechanically. Detection is heuristic and belongs in an ops-review queue, not on an auto-close.
None of these fire cleanly with zero false positives. The right design is a scoring surface that ranks accounts by suspicion, feeds an ops-review queue, and lets the risk team make the close-or-warn call with the audit record already attached.
Multi-Tenant Isolation for White-Label Operators
A platform hosting multiple prop-firm brands has to isolate more than just databases. Each tenant needs its own:
- Risk config (drawdown limits, leverage caps, per-instrument availability)
- Branded trader-facing surface (domain, colours, copy, support email)
- Support and payout ops queue — tenant A's ops team never sees tenant B's accounts
- Reporting and audit boundary (data export by tenant, never cross-cutting)
- Fee schedule and profit-share defaults
Shared underneath: the matching engine, the mark-price feed, the ledger primitives, the WebSocket infrastructure. This is a specific multi-tenant architecture — not one instance per tenant, not a shared schema across tenants, but a tenant-aware kernel with hard authorisation boundaries at every read and every write.
Reporting: The Founder's Numbers
Running a prop-firm business means knowing five numbers, at least daily:
- Challenge-pass rate by cohort (weekly signup cohorts)
- Average time-to-breach on failed challenges
- Funded-account P&L attribution — who's making money, who's dragging
- Payout-eligible balance and payout run rate
- Fee revenue by product tier
None of these are standard exchange-ops dashboards. The platform has to model challenge products, cohort membership and profit-share splits as first-class data — so the founder can answer "what's my true unit economic per funded trader" without spinning up a data-engineering project to find out.
Regulatory Considerations
Prop firms usually sit under a lighter regulatory posture than brokerages holding real client money to trade with. In most jurisdictions the challenge fee isn't a client deposit and the funded account isn't a segregated client trade. That doesn't get you out of the platform's KYC obligations — identity verification, sanctions screening, geo-restriction on prohibited jurisdictions all still apply. The platform ships these as configurable gates per tenant, because prop firms operating across regions accept very different risk profiles on who they onboard.
What Basis Points Ships
Every primitive above is a first-class feature of the Basis Points platform, not a bolt-on. The account state machine is baked into the ledger and read by the matching engine on every incoming order. Drawdown tracking runs continuously on every fill and every mark-price update, three concurrent limits per account. Kill-switch is atomic — state transition, order cancel, position liquidation and audit-record commit in a single ledger transaction. The ops console surfaces every account by rule-state with drillable history. Payout automation covers fee collection, profit-share calc, 2FA gates and USDT settlement. Anti-abuse detection runs as a scored ops-review queue. Multi-tenant isolation lives at the kernel, not the schema. Reporting exposes challenge-pass rate, time-to-breach and funded-account attribution as native queries.
Operators licensing the platform inherit these defaults and tune the commercial parameters — drawdown thresholds, profit-share splits, challenge fee, payout cadence — per their target market. See /pricing for how the platform is packaged for prop-firm operators, and /platform/broker-ops for the ops-console surface.
A prop-firm business isn't a generic trading venue with a fee schedule. It's a specific state-machine model with real-time risk enforcement, atomic kill switches, defensible audit trails and payout automation. Get the platform layer right once. Get it wrong and you lose the payout dispute in public.
Frequently Asked Questions
Can we run a prop-firm business on a generalist multi-asset trading platform?
Technically yes. Economically no, at any real scale. The primitives that matter — account state machine, three-limit drawdown tracking, atomic kill switches, an audit trail thick enough to defend payout disputes, anti-abuse scoring — are all missing from a venue built for direct-to-consumer trading. Retrofitting them into a codebase that models accounts as open/closed is exactly where most fork attempts stall out around month six.
How is trailing drawdown different from total drawdown, and why does it matter for platform design?
Total drawdown is a static floor below the initial account size. Trailing drawdown moves up with new high-water-mark equity, then locks once the account is in enough profit. The trigger price is a function of the account's own P&L history — so the platform has to persist per-account high-water-mark state and re-evaluate the floor on every mark update. That's materially harder to model than a static limit, and it's the drawdown type most bespoke risk engines get wrong.
What does atomic kill-switch mean in practice?
On breach detection, five actions commit in a single ledger transaction: state transition to breached, working orders cancelled, liquidation instructions enqueued, locked audit record written, trader notified. The matching engine reads account state as a hard gate on every incoming order — so once that transaction commits, no new order can land on that account. Not even in the microseconds between state flip and liquidation completion.
How do we detect cross-account hedging without false-flagging legitimate multi-account traders?
Cluster on IP, device fingerprint, funding-source and position correlation across a rolling window. Score the cluster, feed the top-N into an ops-review queue, and let the risk team make the close-or-warn call with the audit record attached. Auto-close on this signal is a losing design — false positives are expensive, and the true positives are usually obvious enough on human review that the queue isn't the bottleneck.
What multi-tenant isolation does a white-label prop-firm platform need?
Per-tenant risk config, branded trader-facing surface, isolated support and payout queues, hard reporting and audit boundaries, per-tenant fee schedule. Shared underneath: matching engine, mark-price feed, ledger primitives, WebSocket infrastructure. It's a tenant-aware kernel with authorisation boundaries at every read and every write — not one instance per tenant, and not a shared schema across tenants.
Do prop firms need the same regulatory posture as retail brokerages?
Usually lighter — the challenge fee isn't a client deposit and the funded account isn't a segregated client trade in most jurisdictions. That doesn't get you out of KYC, sanctions screening or geo-restriction — those still apply. The platform has to ship them as configurable per-tenant gates, because different operators accept very different risk profiles on which regions they'll onboard from.
Evaluating the platform?