← Back to Blog
Prop Firm Rules Are Really a Spec Your Strategy Code Has to Meet

Prop Firm Rules Are Really a Spec Your Strategy Code Has to Meet

Consistency caps, hold times, request limits, VPS bans and third-party EA restrictions. What prop firm rules mean for automated strategies, and how to check your code against them before you pay for a challenge.

A prop firm's rulebook reads like trading terms, but a fair chunk of it is really a spec your code has to meet. Where the strategy runs, who wrote it, how many requests it sends to the server and how long it holds a trade can all be rules. A rules review published this week found two firms that ban hosted servers, and one that reserves the right to ask for your EA's source code.

Note that the review was produced by Velotrade, a prop firm that is also in its own dataset (the disclosure is at the end of the syndicated version). So treat its tallies with some care. The rules themselves are the useful part, and you can check a strategy against them before you pay for a challenge.


The rules that are really code specs

The review looked at 15 firms. Stripped of the marketing, the rules that matter to an automated trader fall into five groups.

  1. Consistency rules. A cap on how much of your profit can come from one day. The review counted them at 11 of 14 firms, which makes them the most common rule by a distance.
  2. Hold-time and activity limits. One firm prohibits holding more than half of trades for under a minute. Another forbids automated activity above 2,000 server requests a day.
  3. Hosted server (VPS) bans. Two firms prohibit hosted servers, and one requires all activity to come from the trader's own device.
  4. Third-party EA restrictions. Two firms restrict expert advisors the trader didn't write. One prohibits third-party software outright and reserves the right to request the source code as proof.
  5. HFT and latency arbitrage bans. The review treats these as legitimate risk controls, since that kind of strategy takes money from a firm's pricing model rather than from the market. Fair enough.

Only the first of those is about P&L. The other four describe how your software behaves: where it runs, what it sends and who owns it. Discretionary traders rarely bump into them. Automated traders can breach them without placing a single bad trade.


Consistency rules vs trend-following

This is the rule most likely to catch a perfectly well-behaved strategy.

The review gives three of the stricter versions. One requires your best day to be no more than 50% of your winning-day profits. Another caps a single day at 40% of net results. A third limits any day to 30% of the payout you request.

Now take a trend-following system. A lot of them lose small and often, then make most of the month in one or two big moves. That's the design, not a flaw.

Here's an illustrative example with round numbers (not real results). Say a strategy has ten winning days in a month, totalling $4,000 in profit. One of those days, a strong trend day, made $2,500. Under the 50% version of the rule, the best day is 62.5% of winning-day profits. That's over the cap, even though the strategy did exactly what it was built to do.

The review says exceeding a consistency rule doesn't fail the account. In practice it usually affects when you can take a payout, and you may need to keep trading until that one big day is diluted. But note that "keep trading to dilute it" means more trades, more exposure and more chances to hit the drawdown limit. That's a real cost, and it's worth knowing before you start.


VPS, bought EAs and source-code requests

The VPS ban deserves a close read, because a lot of automated traders run on a VPS by default. It's the standard answer to "what happens if my home internet drops?"

A rule that all activity must come from the trader's own device changes that setup. If you run NinjaTrader or MT5 on a VPS for a prop account, check the firm's terms for the words "own device", "hosted server" or "VPS" before you buy the challenge, not after the first payout request.

Third-party EA restrictions raise a different question: who wrote the code? If you bought an EA off a marketplace, you may not have the source at all. You'll have a compiled file (an .ex5 for MT5, or a protected DLL/assembly for NinjaTrader). If a firm asks for source code as proof and you can't produce it, that's a problem you can't fix on the day.

If a coder built the strategy for you, you're in a better position, but read the terms closely. "Written by the trader" and "commissioned by the trader" aren't obviously the same thing, and the review doesn't say how firms treat that difference. Ask the firm directly, and get the answer in writing.


Measuring yourself against the rules

Most of these rules can be checked before you risk a challenge fee. You just need to measure the right things.

Best-day share. Export daily P&L from your sim or backtest and work out each month's best-day share the way your firm defines it (best day ÷ winning-day profits, ÷ net results, or ÷ payout requested). If you regularly land above the cap, you know what's coming.

Hold-time distribution. Export individual trades and look at the spread of durations, not the average. If the rule is "no more than half of trades held under a minute", count them. An average of three minutes can easily hide 55% of trades closing inside 60 seconds.

Request count. This is the sneaky one. Every order submission, modification and cancellation is a request. A trail stop that moves on every tick sends a lot of them. In MT5, each stop move made with a call like PositionModify is a separate request to the trade server. In NinjaTrader, a trail that updates on each tick (Calculate set to OnEachTick) can change the stop order far more often than one that updates on bar close.

So a strategy with a handful of trades a day can still produce hundreds or thousands of requests, purely from stop management. Log every order action in sim for a normal week and count them. If you're anywhere near a cap like 2,000 a day, change the trail logic. Move it in steps of so many ticks, or only on bar close, rather than on every tick.


Gotchas

Rules change. Firms revise their terms, sometimes with little notice. Whatever you checked when you bought the challenge may not be the rulebook you're paid under. Keep a dated copy of the terms you signed up to.

Wording is often vague. "Automated activity", "server requests" and "hosted server" aren't always defined. Does a cancel count as a request? Does a platform-simulated stop count if it never reaches the server? The review doesn't say, and firms may not either. Ask, and get the answer in writing.

The firm's server is the only test that settles it. Your own logs are a good estimate. The firm's records are what they'll use.

Backtests don't measure request counts well. A Strategy Tester run models fills, not the chatter of order modifications a live broker connection produces. Sim or market replay on the actual platform is a better measure.


A pre-challenge checklist

  1. Read the automation section of the terms: VPS, third-party code, source-code requests, request or activity limits, minimum hold times.
  2. Run the strategy in sim for a normal week and log every order action: submits, modifications and cancels.
  3. From that log, work out daily request count, hold-time distribution and best-day share.
  4. Compare each against the firm's numbers. Anything that runs close to a limit on a normal week will go over it on a busy one.
  5. If the trail stop is the problem, change the trail logic before the rules change it for you.

Treat the rulebook as part of the spec, and check it before you start the challenge.


If you need expert help with an automated trading strategy, reach out to TradingCoders and tell us what you're building.