Around a third of prop firms are gone within two years. It’s a stat that gets passed around a lot, and it rarely points at what you’d guess. The killer is almost never a bad month in the markets. It’s a platform licence that gets pulled, a data feed that goes dark, or a payment processor that freezes an account while a payout queue sits there with nothing moving through it.
That’s a software story dressed up as a finance story. And the software is the part I find genuinely interesting, especially if you came to this from a technology angle rather than a trading one.
Here’s the plain version: a prop firm is a trading platform business that happens to sell evaluations. Traders pay a fee to prove they can trade, the firm takes a slice of the proceeds, and everything in between runs on software that has to stay up. If you’re reading up on how to launch a prop firm, the honest place to start is the machinery under the brand, not the logo on top of it.
From spreadsheets to a real trading stack
The first wave of prop firms ran on surprisingly thin tools. A form on a website, a spreadsheet of traders, and manual reviews when someone asked for a payout. That worked while the numbers were small. Once evaluations started selling by the thousand, the cracks showed fast.
What replaced spreadsheets is a stack you’d recognize from any modern trading desktop, layered in order:
- A broker or liquidity connection for order routing
- A platform licence for the trading terminal traders actually use
- A risk engine that tracks exposure in real time
- A CRM that ties a trader’s identity to their account and their payout history
- Payment rails for collecting fees and sending payouts
Each layer is a piece of technology you can point at. But the interesting part is the glue. The firm’s real asset is the sync between the terminal and the back office, because that’s where accounts get verified, rules get enforced, and money gets released.
Why platform dependency keeps sinking firms
I’ll be blunt here: betting your entire business on one platform licence is the single riskiest technical decision a prop firm can make. It isn’t a hypothetical. Firms have watched a licence get revoked and been left frozen for months, with trader accounts sitting idle and nobody able to log in.
What makes it feel safe up front is cost. Getting live on a platform vendor is usually the cheapest way to launch with real terminals and real prices. So the vendor becomes the whole business by default. Then the vendor loses a regulatory approval somewhere, or renegotiates terms, and your firm is a website with no product.
The smarter firms treat the platform as a component. They keep a second connection ready, own their own risk engine, and hold their back-office data so migrating a license is an engineering task, not an existential one. Here’s the thing most people miss: the technical stack has to survive the platform, not sit inside it.
That mental shift is also the one that changes how you read the regulations around leveraged retail products, since those rules shape which platforms and jurisdictions are even available to connect with.
The Three Ledger Rule
When I help people think through a launch, I use a framework I call the Three Ledger Rule. Every prop firm needs three separate books, and they need to be reconciled on a schedule:
- The fee ledger. Money collected for evaluations, by timestamp.
- The payout ledger. Obligations promised to traders once they pass.
- The reserve ledger. The cash buffer held against payouts at all times.
That sounds obvious, and yet the most common failure pattern is simple: money from evaluations gets spent as revenue while payout obligations keep growing underneath it. A firm looks profitable in month three and is underwater by month six from nothing more than accounting logic. A serious risk engine reports the three ledgers in one view.
Worth noting that the securities rulebook in the US touches on record-keeping and online protection obligations, and if you build around those principles early, your software tends to be cleaner later. The SEC publishes plenty of guidance on the topic.
A concrete build order that holds up
Here’s the sequence I’d recommend, in the order the technical work actually needs to happen. If you try to skip ahead, you’ll rebuild something later and pay twice.
- Lock the data model first. Decide how a trader, an account, a payout, and a rule violation relate. Every later decision depends on this.
- Choose the platform and a backup. Two viable connections, not one. Test the failover.
- Build the risk engine before the marketing site. No, seriously. A tracker that flags a trader breaking a rule, or an account with exposure beyond tolerance, is what keeps liabilities from becoming surprises.
- Set up the CRM around identity and payouts. KYC fields, payout history, and support tickets all live in one place.
- Add the payment path and test the failure cases. Processor freezes happen. Know what your next step is before you need it.
- Write the rulebook, then encode it. If enforcing the rule requires a person to remember it, it won’t be enforced consistently across thousands of accounts.
One detail worth pointing out. If you plan to publish anything that looks like a performance claim in your marketing, the standards around misleading financial promotions are stricter than they look. The International Organization of Securities Commissions publishes guidance that’s a useful reference.
And if the connection passes through a US derivatives platform, the Commodity Futures Trading Commission is the regulator to read about. Getting clear on that early saves you an expensive rebuild later, because changing jurisdiction mid-flight is much harder than choosing deliberately at the start.
What the history actually shows
The prop firm model didn’t get complicated because the trading got harder. It got complicated because the operations scaled faster than the technology around them. Manual review queues, payment backlogs, retroactive rule changes, and single-platform exposure all trace back to that gap between how fast traders arrived and how fast the back office could keep up.
Every firm that’s still around after five years built its stack deliberately, and every firm that vanished left the same trace in the code. If you were to start building one today, what would your first engineering decision be, the platform, or the data model underneath it?
About the Author
