Prop-firm traders — FTMO, FundedNext, MyFunds, The5ers, and the long tail of smaller firms — almost always run more than one challenge in parallel. The typical funded-trader cohort runs three to seven accounts simultaneously, sometimes across multiple firms. They are not running different strategies on each account. They are running one strategy across all of them, with the explicit goal of parallelising pass-fee economics and accelerating the path to meaningful payouts. The math is straightforward: if a strategy passes a $200k FTMO challenge with a 40% probability, running four concurrent challenges raises the probability that at least one passes to roughly 87%. The pass-fee cost scales linearly; the expected payout from a funded account is unchanged per challenge but the time-to-first-payout compresses dramatically.
Generic copy-trading tools — the kind that have existed since 2016 — were not built for this use case. They were built for the assumption that a signal source has one downstream destination, and the rare 'multi-account' modes they offer are bolt-ons that struggle with the operational realities of prop accounts. This article walks through what the routing layer actually has to handle for prop-firm trading, where the generic-router assumptions break, and the architecture of what we built to solve the problem properly.
What makes prop-firm routing structurally different
Per-account drawdown caps with firm-specific definitions
Every prop firm has a daily-loss cap and a maximum-drawdown cap. The numbers vary (3-5% daily, 6-12% max). The harder problem is that the definition of 'daily' and the calculation of 'drawdown' differ subtly between firms. FTMO uses a trailing drawdown definition — your max drawdown follows your equity high. Topstep uses a static drawdown that resets only after a trading day. The5ers uses an account-balance-based drawdown that ignores unrealized P/L until close. A generic router that treats them all as 'daily-loss = 5%' will overshoot the actual breach point on some firms and leave money on the table on others.
The right architecture: per-account drawdown rules that mirror the specific firm's definition, evaluated server-side at every order entry. The PipSync prop-firm module includes pre-configured rule templates for the 14 most common firms, plus a custom-rule builder for the firms not yet templated.
Per-account symbol allow-lists and news-event restrictions
Most firms restrict trading certain instruments at certain times. The restrictions vary: some firms ban news trading entirely (defined as holding positions through a high-impact event); others ban initiating new positions in a window around scheduled events; others restrict certain instruments (crypto, exotic FX, single-name equities) during specific market hours. A signal that's perfectly valid for one account might violate the rules of another.
The generic-router failure mode: the signal fires, the strategy thinks it sent a trade to all accounts, but actually three of four accounts silently rejected the order because of a per-account restriction. The trader's equity curve diverges between accounts in ways that are confusing to debug because the audit log doesn't surface the per-account rejection reasons.
PipSync's prop-firm mode: every order entry generates a per-account decision tree (allowed / blocked-for-symbol / blocked-for-news / blocked-for-drawdown / blocked-for-position-limit) and writes the result to the audit log per account. The trader can see exactly which accounts took the trade and why each rejection happened.
Position size that differs by account balance even within the same firm
A $25k FTMO account and a $200k FTMO account have different per-trade lot-size limits. A strategy that says 'risk 0.5% per trade' produces different absolute lot sizes on each. The routing layer has to compute the per-account size correctly without forcing the user to maintain four separate copies of the same strategy with different sizing parameters.
The architecture: strategy rules are expressed as risk percentages, not absolute lot sizes. The router computes per-account lot sizes at order entry based on each account's current equity and the broker's lot increment for the instrument. The strategy is one logical entity; the per-account sizing is mechanical translation.
Independent stop-out behaviour without source disconnection
When one of the four accounts breaches its drawdown cap, that account must stop trading. But the source must continue feeding signals to the other three. The naive implementation — disabling the source when the first account breaches — destroys the parallelisation logic that made prop-firm mode worth using in the first place.
PipSync's behaviour: per-account circuit breakers that pause individual accounts on breach while keeping the source live for the rest. The audit log records the breach and the operator gets a notification, but the rest of the routing continues uninterrupted.
The audit-log problem
Pre-prop-firm-mode, a single signal generated a single conceptual trade with multiple per-account fates. The audit log was structured around 'one trade, multiple outcomes' — which is how every copy-trading platform's database model has been built since the model existed. The problem: computing a clean per-account equity curve from a 'one trade, multiple outcomes' audit log requires reconstructing the per-account event sequence from the outcomes, which is error-prone and computationally expensive.
The fix: prop-firm mode treats each account as a distinct routing destination from the start. One signal generates N independent orders (where N = number of subscribing accounts), each with its own audit-log row including its own filled price, slippage, broker fees, and outcome. The source's analytics roll up by-account, not by-source-with-fate-fields. The trader can ask 'what was my P/L on account 3 from signals from source A in March?' and the database returns the answer with a simple aggregate query.
The downside: the audit-log volume increases by a factor of N. A user running four accounts now has four times the audit-log rows. We accepted the cost because the analytical clarity is worth the storage; the daily 12-month retention math at typical signal volumes works out to single-digit-GB per workspace per year, which is operationally trivial.
The per-account analytics view
Once the audit log is properly account-keyed, the dashboard can show per-account analytics that prop traders actually want: equity curve per account, max drawdown per account, win rate per account, average loss per account, days-to-next-payout per account, time-since-last-trade per account. These metrics don't make sense at the source level because the constraints are per-account, but they're essential for prop-trader operational decision-making.
Practical insights that come from the per-account view: identifying that one of your funded accounts is being disproportionately hit by news-time slippage relative to the others (the broker's slippage profile differs); spotting that one account is approaching its drawdown cap before the others (lets you pause that account preemptively before a breach); seeing that one account has been on a trade-frequency floor that's threatening its minimum-trading-day requirement.
Operational rules for prop-firm traders using the multi-account architecture
- Run identical strategies across all accounts. Strategy drift between accounts compromises the parallelisation logic and makes debugging impossible.
- Set per-account drawdown caps tighter than the firm's actual cap. A 3% personal cap with a firm cap of 4% leaves you with a 1% margin to absorb slippage and partial-fill weirdness without breaching.
- Use per-account news-event blockers even on firms that don't strictly require them. The unhedged news-event move on a typical major-pair can blow the daily cap on its own.
- Audit weekly. The per-account analytics view shows you patterns that are invisible at source level — broker-specific slippage, intraday timing variance, instrument-specific edge differences.
- Don't increase position size on funded accounts beyond what passed the evaluation. The temptation is real; the empirical outcome is meaningfully worse risk-adjusted performance.
What's still hard
Cross-firm correlation tracking. If you're running an FTMO account and a FundedNext account on the same strategy, the two accounts have correlated drawdowns by construction — and a bad week for the strategy hits both at once. The current PipSync architecture treats each account as independent for routing purposes but doesn't model the cross-account correlation for portfolio-level risk. That's on the roadmap for the prop-firm v2 architecture, planned for Q3 2026.
Reset-attempt economics. Some traders buy reset attempts on failed challenges. The economics are sometimes — rarely — positive, depending on the firm's reset pricing and the trader's edge distribution. PipSync doesn't currently surface a 'should I reset' analytics view; the operational guidance is to treat resets as a meaningful expense and only buy them if your edge has demonstrated durability over a meaningful sample.