The honest answer to which futures prop firms allow automated trading is that it depends on the firm, the account type, and the week you are asking. There is no stable list, and any article that hands you one as settled fact is doing you a disservice. What is useful is knowing why the answer moves, where your own setup sits on the spectrum firms actually rule on, and exactly what to verify before you point any automation at a prop account.
Automated is not one thing: the spectrum firms rule on
Firms rarely publish a single yes or no verdict on automation. They rule on a spectrum, and where your setup sits on that spectrum decides which of their rules even apply to you. Before you read any firm’s policy, locate your own setup in the taxonomy below, because the same three-word question (“do you allow automation?”) means something different for each style.
Fully hands-off bots (EAs and algos)
Unattended strategy logic that submits orders with no human in the loop: an expert advisor, a compiled strategy, or a script that watches the market and fires entries and exits on its own. This is the category firms most often restrict or prohibit, and it is the one to verify most explicitly. Do not assume a firm that tolerates assisted tools also tolerates a fully unattended bot.
Semi-automated and assisted (signal plus manual confirm)
Software proposes, a human approves each order. The tooling does the watching and the math, but a person clicks to send. Some firms carve this out as acceptable where a fully automated system would not be, but the carve-out language is specific. Read exactly what manual means to them: some require you to be present and actively adjusting, not just approving a queue.
AI agent workflows
An LLM agent that proposes orders through a tool interface, reading live state and suggesting an action that a human or a rule then gates. This is novel enough that most rulebooks predate it and do not name it at all. Do not read that silence as permission. Ask support, in writing, how they classify an agent that proposes but does not auto-execute, and whether it lands in their automated bucket or their assisted one.
Copy, mirror, and trade-copiers across accounts
Replicating one account’s fills onto others. Copying your own accounts and copying someone else’s are treated very differently, and this is where multi-account caps and rules about holding a full-size and a micro contract on the same instrument start to interact. If you run several accounts off one signal, the copier itself may be fine while the account-count cap or the position-aggregation rule is what trips you.
| Automation style | What it means | Rule dimension firms attach | What to get in writing |
|---|---|---|---|
| Fully hands-off bot | Unattended logic submits orders, no human per order | Whether unattended execution is allowed at all, per account type | A written yes or no for fully automated execution on your account |
| Semi-automated / assisted | Software proposes, you approve each order | How the firm defines manual, and whether active monitoring is required | The exact definition of assisted, and whether a confirm click counts |
| AI agent workflow | An agent proposes orders through tools, gated before sending | Which bucket an agent falls in, since most policies predate it | A support reply classifying a propose-only agent |
| Copy / mirror / copier | One account’s fills replicate to other accounts | Multi-account caps and mini plus micro aggregation | Whether copying your own accounts is allowed, and any account-count cap |
No firm names, no allow or forbid verdicts. The last column is always something to confirm in the firm’s own words.
Why there is no single answer
Three things keep the answer from being fixed. First, each firm writes its own rules, and they disagree with each other. What one firm treats as ordinary assisted trading, another may class as prohibited automation. Second, the rules often differ between an evaluation account and a funded account at the same firm, so a policy that applies while you are being evaluated may change once you pass. Third, firms revise their terms. Platforms change, account products change, and the automation language changes with them. A screenshot of a rule from last quarter is not evidence of the rule today.
The rule dimensions that decide whether your automation survives
Firms rarely rule on automation in isolation. Automation collides with the other rules already in the book, and the same bot can pass at one firm and fail at another purely because a neighbouring rule is shaped differently. These are the dimensions to map before you assume that automation allowed settles anything. Each is described in general terms on purpose: read your own firm’s numbers off your own firm’s rulebook.
Trailing drawdown: end-of-day versus intraday
Many firms enforce a trailing drawdown threshold that moves up as your balance grows. The detail that matters is when it updates. An intraday or per-tick trailing threshold that ratchets on unrealized profit punishes give-back very differently from one that only recalculates at end of day. The identical bot, run against the two models, hits the wall at different points in the session. Verify which model applies and whether it locks once it reaches your starting balance.
Consistency rules and bot pacing
A consistency rule caps how much of your total profit any single day may represent, with commonly cited ranges around 20 to 50 percent. A bot that has one outsized day can fail this even while net profitable, because the rule is about distribution, not the total. Verify the current consistency percentage and whether it applies at payout, during evaluation, or both.
Daily loss limit and halt behaviour
Some firms set a hard daily loss limit that ends the trading day when hit; others let the drawdown act as the only natural limit. This matters for automation because a bot does not feel a stop the way a person does. Verify whether hitting the limit ends the day, ends the account, or neither, and whether it is measured on realized loss alone or realized plus unrealized.
News-window and minimum-hold rules
Firms commonly restrict opening positions around high-impact news releases, and some require a minimum hold time on a position. Both are easy for an automated entry to trip without a human noticing the clock. Verify the exact window around named releases and any minimum-hold requirement in seconds.
Scaling, position caps, and the mini plus micro interaction
Beyond a per-order size cap, there is usually a maximum net position, and a rule about whether holding a full-size and a micro contract on the same underlying (ES and MES, for example) counts as one aggregated position or two. An automation that scales in can breach the aggregate cap while every individual order looks fine on its own. Verify the position cap per account and how the firm aggregates related contracts.
Infrastructure: VPS, latency, and the platform allowlist
Some firms restrict running your automation on a VPS, and some ban latency-arbitrage or high-frequency patterns outright. Separately, only certain platforms are usually in scope (NinjaTrader, Tradovate, Rithmic, or a Project X style stack), and the automation policy may only speak to those. Verify which platforms the policy actually names, and whether VPS or high-frequency use is called out. If your automation drives NinjaTrader, the NinjaTrader 8 MCP bridge is the surface those rules apply to on our side.
How firms detect automation, and why it matters even where it is allowed
Firms review trade logs, and machine-driven trading leaves a signature. Identical timestamps across orders, zero-variance sizing or stop distances, and entries placed faster than a person could click all read as automation to a reviewer. This matters even when automation is permitted, because detection feeds into other rules: anti-manipulation clauses, risk-behaviour or gambling language, and the consistency checks above. A firm that allows bots still expects the bot to respect the same limits a human would.
A per-firm verification workflow, before you fund anything
Treat verification as a ritual you run per firm, not a box you tick once. The checklist below is the core of it, but the habits around it matter as much as the questions.
Read the rulebook section, not the marketing page
Automation language lives in the rules and the FAQ, not the sales page. The homepage may say trade your way; the actual policy is in a clause three levels down. Read that clause in full, including the definitions section, because the definition of automated is where the real scope sits.
Get the ambiguous parts confirmed in writing
Where the rulebook is silent or vague (an agent that proposes, a copier across your own accounts, a VPS), email support and ask a specific question. Keep the reply. A dated written answer from the firm is your record, and it is worth more than any third-party summary or forum post.
Re-verify on every change
A rule you verified can move under you. A platform migration, a new account product, or a switch from evaluation to funded can all change which automation clause applies. Re-run the checklist after any such change rather than assuming last month’s answer still holds.
- How does the firm define automated or algorithmic trading, in its own words?
- Does that definition treat an AI agent that proposes orders differently from a fully hands-off system?
- Do the automation rules differ between evaluation and funded accounts?
- Are third-party tools and bridges permitted, and are any specific ones named or excluded?
- Are there rules about copying or mirroring orders across multiple accounts, and any account-count cap?
- Is VPS use or high-frequency trading restricted for automated strategies?
- Which trading platforms are in scope, and does the automation policy vary by platform?
Firms traders ask about
The names that come up most are Topstep, Apex Trader Funding, Tradeify, Take Profit Trader, Earn2Trade and Lucid, among others. Each publishes its own automation policy, and each can revise it. We are deliberately not reproducing any firm’s specific rules here, because doing so would age badly and could mislead you into acting on a stale term. Go to the firm’s own rules page, read the automation section in full, and if anything is ambiguous, ask their support to confirm in writing. Treat that written confirmation as your record.
How PitBridge fits, and how it does not
Software has a real but bounded role here. PitBridge does not know your firm’s rules and cannot make you follow them. What it can do is enforce the limits you configure and keep a local record of what happened. If you have verified that your firm caps position size, sets a daily loss limit, and forbids trading through a news window, you map those into guardrails, and the engine refuses any order that would break them.
# limits you set from rules you verified, enforced locally
place_order account=sim instrument="MES 09-26" side=BUY qty=20
BLOCKED reason_code=MAX_CONTRACTS_PER_ORDER
order not sent. this is your rule, not the firm's word.Example decision. Values are yours to configure. Not a firm policy.
Turning verified rules into enforced limits
Once you have verified a rule, you map it to a guardrail and the engine refuses any order that would break it. The table below makes the mechanism concrete: each left-column item is a rule you verified with your firm, and each right-column value is the typed reason code you would see when the engine blocks. These are starting points you adjust to the rules you checked, never a statement of any firm’s policy.
| Rule you verified with the firm | Guardrail that enforces it | Reason code when it blocks |
|---|---|---|
| Max contracts on one order | max_contracts_per_order | MAX_CONTRACTS_PER_ORDER |
| Net position cap | max_position | MAX_POSITION |
| Daily loss stop | daily_loss_halt | DAILY_LOSS_HALT |
| Bank the day at a profit | profit_lock | PROFIT_LOCK |
| Only trade allowed contracts | instruments allowlist | INSTRUMENT_NOT_ALLOWED |
| Session or news window, holiday closes | trading_window / holiday calendar | OUTSIDE_TRADING_WINDOW / NO_TRADE_DAY |
| Spacing after a loss or an order | cooldown_after_loss_s / cooldown_after_order_s | COOLDOWN_AFTER_LOSS / COOLDOWN_AFTER_ORDER |
| Order-rate ceilings | max_orders_per_minute / _hour / _day | MAX_ORDERS_PER_MINUTE / _HOUR / _DAY |
| Duplicate-order guard | duplicate_window_s | DUPLICATE_ORDER |
| Human in the loop on first, live, or larger orders | human_confirm | HUMAN_CONFIRM_FIRST_ORDER / _EVERY_LIVE_ORDER / _SIZE_INCREASE |
Config keys and reason codes taken verbatim from the daemon. The left column is always a rule you verified, never a rule attributed to a firm.
The order of enforcement is fixed and not up for negotiation by the thing placing the order. The kill_switch is always evaluated first, so nothing new passes once you engage it, and human_confirm is always last, so a person only ever sees orders that every other guardrail already allowed. The nine tools an agent can call (get_accounts, get_positions, get_orders, get_account_state, get_guardrail_status, place_order, cancel_order, close_position, flatten_account) can read state and place, cancel, close, or flatten. None of them can release the kill switch, arm live trading, or change a guardrail value. Those controls live on the CLI, operator-only. That is a deliberate difference from a copier or a webhook relay, where the thing sending the order and the thing that could disable the check are often the same surface.
The guardrails page lists what the engine refuses, and the pillar on prop firm rules in software covers how to turn verified rules into enforced limits. A local audit log gives you a record of every decision, which is useful if a firm ever asks what your automation did.
Automating on a prop account is a good use of hard local limits, precisely because an out-of-bounds order is expensive. But those limits are only as correct as the rules you fed them, and the rules are the firm’s to set and change. Tell us your firm and platform on the waitlist. PitBridge is trading infrastructure, not financial advice.