Can You Use an EA on FTMO? Best Bot Strategies

The Direct Answer: When an EA Can Be Used on FTMO

FTMO has historically described automated and algorithmic trading as permissible, but permission for an EA is not a blanket approval of every implementation. The live FTMO agreement, FAQ material, platform conditions, and any written support clarification are the authoritative sources. Before buying an account, identify the exact product, account type, platform, and phase you intend to use. Then ask whether EAs are supported there and whether your planned style has a specific restriction. A sensible written question describes the mechanics, not a vague label such as “scalping bot.” For example, say that the EA opens one stop-loss-protected position from a closing-bar signal and does not use latency, arbitrage, copying, or third-party account control.

A compliant EA remains your responsibility. Turning it on does not transfer responsibility to the developer, marketplace, VPS company, or a person who installed it. You should be able to see the inputs, disable new entries, inspect the journal, and explain every order. That includes pending orders placed while you were asleep, trades reopened after a terminal restart, and a position closed by an emergency module. If you cannot access the account or do not know what a parameter does, you are not operating a controlled strategy. The distinction is explored further in EA permissions and restrictions across prop firms.

Do not confuse contractual permission with an assurance of profitability, future eligibility, or a payout. FTMO may review trading activity under its current terms, and a passing result does not make an otherwise restricted method acceptable. A robust decision is therefore two-part. First, establish that the method is allowed now. Second, establish that it can survive normal spread, slippage, correlation, and losing streaks without approaching the firm limits. Both questions need a documented answer before the first live evaluation order.

• Save the current official rules for the exact FTMO programme and stage.
• Describe the EA's entries, exits, sizing, symbols, and data source in plain language.
• Obtain written clarification from FTMO when a relevant rule is unclear.
• Keep sole control of credentials, settings, and the ability to stop trading.

Separate Allowed Automation from Restricted Trading Conduct

An EA can trade in a normal, rule-based way while a particular tactic can still be unsuitable. Firms commonly distinguish ordinary algorithmic analysis from conduct that seeks to exploit a technical weakness, delayed quote, price-feed discrepancy, execution fault, or infrastructure limitation. Names vary and terms evolve, so do not infer safety from the word “EA.” A robot can be a low-frequency trend follower, a news calendar tool, a grid engine, a copier, or a latency-sensitive scalper. Those are operationally different systems, and the facts matter more than marketing language.

Avoid any seller who frames a strategy as a way to defeat broker protections, exploit a gap between feeds, conceal account relationships, or guarantee that compliance systems cannot detect it. These claims are warning signs, not features. A legitimate EA needs no hidden VPS route, special execution loophole, or instruction to use another person's account. It should continue to make sense if fills are slower, spreads are wider, and an auditor reads its order history. This explanation of HFT and prop-firm restrictions helps distinguish ordinary automation from methods whose edge is inseparable from fragile execution conditions.

A useful test is reversibility. Could you turn the bot off, leave the platform alone for a day, and still reconstruct its logic from the settings and logs? Could you explain why two orders were opened at the same time? Can its edge survive a different server location without relying on a millisecond advantage? If the answer is no, pause. Complexity is not proof of sophistication. For FTMO use, auditable behaviour and a clear risk boundary are stronger assets than a dramatic equity curve.

Verify the Programme, Platform, Symbols, and Account Stage

Compatibility starts before installation. Confirm which trading platforms FTMO currently makes available for your chosen product, which account credentials you will receive, and whether the EA was written for that platform and build. MetaTrader versions, cTrader implementations, symbol names, contract specifications, fill policies, and trading sessions can differ. An EA compiled for one environment may load in another but calculate a pip, tick size, stop distance, or minimum volume incorrectly. Treat a successful installation as the beginning of testing, not proof of compatibility.

Inspect every symbol the EA may trade. Match its expected names against the Market Watch list, and check whether it relies on a suffix, prefix, metal, index, crypto product, or cross that is unavailable. Also inspect contract size, minimum and maximum volume, volume increment, stop-level restrictions, swap treatment, and the platform's server clock. A multi-symbol robot may silently skip unavailable instruments or concentrate exposure in the few symbols it recognizes. That can transform a diversified research result into a concentrated evaluation risk.

Stage matters as much as platform. Rules that apply during an evaluation may not be identical to rules applicable after qualification, and payout-related conditions can have their own current requirements. Re-read the official material before changing stage, account type, or platform. Never assume a vendor's “FTMO preset” remains correct. The broader workflow in using an EA in an FTMO Challenge is useful, but the account dashboard and current agreement always outrank a guide.

Translate FTMO Loss Rules into Internal EA Guardrails

Published loss limits are hard boundaries, not risk targets. An EA should use an internal daily stop and an internal overall stop that sit comfortably inside the applicable official thresholds. The gap is a buffer for floating loss, commissions, swaps where relevant, spread changes, slippage, delayed updates, and the possibility that more than one order closes near the same moment. A bot programmed to use every permitted amount assumes perfect measurement and perfect execution. Neither assumption is appropriate for a live evaluation.

First determine exactly how the current programme measures daily loss: the reference point, reset time, whether equity and closed results are included, and how fees are treated. Then implement a conservative internal calculation using the same concepts. A practical internal formula is remaining daily room equals the chosen internal daily budget minus realized loss minus the worst reasonably expected loss on all open positions and pending exposure. If the remaining room is small, block new entries. Do not let a positive floating trade persuade the bot that protection is unnecessary.

The same logic applies to overall loss. Track realized drawdown and potential open loss across every symbol, not trade by trade in isolation. If the bot can reopen after a stop-out, include the maximum number of entries allowed by its own logic. A dedicated EA drawdown and lot-size guide can clarify the inputs, but it cannot know the wording of your account. Validate the EA's values against platform equity and the live dashboard before relying on them.

• Set internal daily and overall stops below the currently published account boundaries.
• Count open loss, fees, correlated positions, and pending-order risk.
• Make the stop block fresh entries and cancel pending orders where appropriate.
• Test the stop after a terminal restart and record the result.

Use UTC and Server Time Without Guesswork

Time errors create avoidable rule and strategy failures. Your laptop clock, local civil time, UTC, economic-calendar time, and trading-server time can all be different. Daylight-saving changes can alter the difference again. A session EA that was designed to trade a liquid London hour can enter during a quieter period if its input assumes the wrong clock. A news filter can miss an event if it expects UTC but receives server time. Write down which time basis every input uses rather than trusting labels such as “GMT offset.”

Build a simple time map. At a known moment, record UTC from a reliable source, the chart time displayed by the platform, the local time shown by your device, and the time used by the event calendar. Repeat around daylight-saving transitions or whenever FTMO changes the platform environment. Configure the EA from this map and use an on-chart display or log entry to prove when its session and news windows are active. A setting that says 08:00 means nothing until you identify 08:00 in which clock.

Daily-loss resets deserve the same discipline. Confirm the current reset definition in official FTMO material and observe it in the account environment. Do not schedule a late-session trade based on a presumed midnight reset. Floating positions, swap postings, and a bot that carries orders across the boundary can make an apparently harmless time decision consequential. The safe approach is to stop opening fresh risk well before any uncertain boundary and review the current official treatment before resuming.

Choose a Bot Strategy by Failure Mode, Not Marketing Return

The question is not which bot made the most profit in a selected screenshot. The question is how it loses. A strategy suited to FTMO has bounded, understandable losses and does not need a rare rescue event to remain solvent. Review the largest adverse excursion, losing streaks, time spent in drawdown, trade clustering, and sensitivity to spread. A lower-return approach that makes independent, stopped trades may be easier to operate than a high-return system whose risk arrives in one large tail event.

Trend-following systems often take many small losses while seeking occasional extended moves. They can fit an evaluation when volume is low enough for the losing sequence and when their session choices are liquid. Their weakness is choppy markets and signal whipsaw. Mean-reversion systems can produce a high win rate, but investigate what happens when price does not revert. A stop-defined mean-reversion model is fundamentally different from a model that keeps adding size until a reversal. Do not let the win rate conceal the distribution of losses.

Breakout strategies need particular scrutiny at news and session opens because their apparent edge may be mostly an execution assumption. A swing system can reduce noise but introduces overnight, weekend, and event exposure if positions are held. No family is automatically best. The algorithmic strategy selection guide offers a comparison framework. Choose the system whose worst plausible week can be carried within your internal limits, not the one with the most persuasive sales headline.

Reject Recovery Logic That Hides Tail Risk

Grid, martingale, averaging, and recovery language require unusually careful analysis. A strategy may be described as “adaptive” because it adds positions after an adverse move, yet its true risk may be an expanding aggregate position with no dependable exit. It can show long strings of small wins in a backtest because the eventual large loss has not occurred in the sample. A prop evaluation can end before the historical recovery arrives, especially when a daily rule includes floating equity.

This is not a claim that every multi-entry model is forbidden or automatically unprofitable. It is a demand for a complete risk description. Ask the developer for the maximum number of entries, spacing logic, maximum total volume, hard account stop, behaviour through gaps, and treatment when an order is rejected. Run the worst case on the actual instruments, using adverse spread and slippage assumptions. If the answer depends on price eventually returning, then the risk is not bounded by a trade plan.

A safer design has a declared maximum loss for the entire idea, not merely for each ticket. It treats correlated entries as one position, exits when the thesis is invalidated, and will remain stopped after reconnecting. This is especially important when several pairs share a currency or when gold, indices, and currencies react to the same macro surprise. A calm-looking chart can conceal one large directional bet.

Model Correlation, Lots, and Concurrent Exposure

An EA can obey its per-trade lot cap while still create excessive portfolio risk. Long positions in several currency pairs can share exposure to one currency. Multiple index instruments can respond together to the same risk event. Two bots attached to separate charts may open nearly identical trades because they consume the same trend signal. The platform sees separate tickets; your internal risk model should see the combined scenario. Add a portfolio cap that blocks a new order when total defined risk reaches your chosen internal budget.

Calculate position size from a known stop distance and the current symbol specification, then check it again after a platform or symbol change. Do not use a fixed lot merely because it performed well on another account size. Confirm how the EA handles nonstandard tick value, fractional volume, and a stop that is too close for the broker environment. A quality bot should either calculate conservatively or refuse the order with a visible message. Silence after an invalid-size decision is an operational defect.

Use a scenario table before launch. For example, model all open positions reaching their stops simultaneously, a spread widening while stops trigger, and one correlated group moving together. Add commissions and expected adverse fill difference rather than assuming chart-price execution. The EA lot-sizing guide provides helpful principles for this calculation. The goal is not a mathematically perfect forecast; it is a volume choice that leaves room when reality is worse than the test.

Build News, Spread, and Liquidity Filters That Actually Work

Whether and how trading is restricted around economic news is time-sensitive and can differ by current FTMO account conditions or stage. Verify the official rule before enabling a news strategy or assuming that an open trade is treated like a new entry. If a restriction applies, make the EA's action explicit: stop new orders before the window, cancel relevant pending orders, decide whether existing positions are closed or merely managed, and delay re-entry afterward. A vague “news filter on” toggle is not enough.

The calendar source must be reliable and its event times must map correctly to the EA clock. Test the filter with a scheduled historical event and inspect the log. What happens if the calendar feed is unavailable, the event is revised, or a symbol has no direct currency tag? The safer failure mode is normally to stop opening new risk until the data is trustworthy. A filter that fails open, allowing entries because the feed broke, has the opposite of its intended purpose.

Spread and liquidity controls should be independent of the event filter. Set a maximum spread condition based on observed live data, not the most favorable tick in a backtest. Include a check for stale ticks, rollover conditions, market closure, and abrupt slippage. News trading with an EA and this discussion of gaps, slippage, and spread explain why a profitable chart rule can fail when execution quality changes. Skipping a trade is often cheaper than forcing an entry in an abnormal market.

Test the Exact Configuration Before an Evaluation

Backtesting is research, not certification. A report is only as useful as its data quality, spread modelling, commission inputs, slippage assumption, and parameter discipline. Check whether the test used bid-only or realistic bid-ask pricing, whether it includes variable spread, and whether it covers different volatility regimes. Inspect the raw trades, not only the final balance line. A curve driven by a few large gains, one instrument, or one exceptional year may not be robust enough for an evaluation.

Forward test the same files, inputs, symbols, and VPS configuration you plan to use. Watch for missing trades, duplicated trades, altered lot sizes, incorrect session windows, and differences between expected and actual stops. A demo test does not duplicate every live condition, but it can reveal logic and deployment errors without an evaluation fee at risk. Keep a changelog. If you change a parameter after a disappointing week, record what changed and why, rather than blending several systems into one untraceable result.

Test failure states deliberately. Disconnect the terminal, restart it with a position open, remove the calendar feed if relevant, force an order rejection where safely possible, and inspect how the EA responds to a widened spread. Verify that one chart cannot create duplicate instances and that magic numbers or identifiers keep strategies separate. Backtesting versus live EA trading is a useful reminder that a difference is evidence to investigate, not a reason to disable protection.

• Forward test the exact platform, symbol list, inputs, and VPS image.
• Compare EA logs, journal entries, and platform history for every trade.
• Test restart, disconnection, rejected-order, and calendar-feed failure behaviour.
• Freeze the evaluation configuration and document any later change.

Operate a VPS and Access Plan You Can Defend

A VPS can help an EA remain online, but it is not a compliance workaround. Choose it for stability, security, and sensible proximity to the trading environment, then check FTMO's current account-access policy before using it. Keep the operating system patched, use a unique strong password and available multi-factor protections, and restrict remote access to yourself. A cheap, unattended server with unknown users is not a professional trading setup. The EA should also handle a VPS restart safely rather than resuming blind.

Maintain an access record containing the VPS provider, broad location, IP information where relevant, device used to access it, dates of material changes, and the reason for each change. This is useful when travelling, replacing a computer, or answering a legitimate question about account access. Do not share credentials with a developer who offers to “manage” the robot. They can provide instructions or a file without taking control of your account. FTMO IP and EA access guidance gives a fuller operational framework.

Remote monitoring should not become remote interference. Use alerts for disconnections, unusually large spread, new order, daily internal-stop activation, and error messages. Then define who acts on an alert: ideally you, using documented steps. Avoid logging in from a shared computer or letting a friend close trades while you are away. Security, ownership, and a coherent explanation of your activity are more important than chasing uninterrupted screen time.

Monitor Without Overriding Every Normal Loss

Automation reduces repetitive decision-making; it does not remove the need for an operator. Create a short daily routine: confirm the terminal and VPS are connected, review current equity and internal budgets, check upcoming event conditions, read error logs, and compare expected open positions with actual positions. The routine should take little time because it is structured. Constantly staring at candles and changing settings after each loss defeats the testable logic that justified using an EA in the first place.

Define amber and red conditions in advance. Amber might mean the EA can manage existing orders but cannot create new ones because spread is elevated, an event window is close, the daily buffer is thin, or the calendar feed is uncertain. Red means all strategy activity stops after an unexplained order, a platform mismatch, a configuration change, repeated execution anomaly, or an internal hard stop. Restart only after you identify the cause and record the corrective action. A bot should fail safely, not trade aggressively while its information is unreliable.

A journal is the bridge between code and accountability. Record UTC time, server time, settings version, platform result, reason for manual intervention, expected risk, actual fill, and whether a filter acted. Review weekly for recurring slippage, missed signals, correlated entries, and differences from the test. An EA trading journal for funded performance can structure the review. The aim is to improve operational reliability, not to force the system to look successful.

Plan the Move from Evaluation to FTMO Account

Passing an evaluation is a change of operating context, not a reason to raise risk. Before trading any subsequent account, re-read the current terms for that stage. Confirm whether news handling, permitted instruments, drawdown calculations, minimum activity, consistency expectations, scaling, or payout procedures differ. The phrase “my EA passed” describes a historical result. It does not establish that every old setting remains suitable for the new environment. Make a new dated rules snapshot and compare it line by line with the evaluation plan.

Reduce complexity during the transition. Start with the same documented configuration only if it still fits the terms and if the strategy's recent forward evidence remains sound. Do not immediately add symbols, copy across accounts, double lots, or remove filters to meet a personal income expectation. A funded account is valuable precisely because it can be preserved. The best first objective is clean, explainable execution through a complete reporting and payout cycle, not a spectacular first week.

Payout conditions are administrative as well as trading matters. Check the official current process, available payment methods, required verification, supported payout currencies, minimums or timing where stated, and any fees or conversion charges. Keep invoices, evaluation receipts, platform reports, payout records, and tax documentation. Local tax, reporting, consumer, banking, and business obligations vary by residence and personal circumstances; obtain qualified local advice rather than relying on a trading forum. This local-currency payout guide is a useful starting checklist, not legal or tax advice.

Avoid Account Management, Signal Copying, and Ownership Confusion

Operating your own EA is different from handing an account to someone else. If a seller asks for login details, promises to pass the account for you, or controls the strategy remotely without your understanding, stop and review the current FTMO terms. Account ownership, identity verification, access, copied trades, and third-party services can raise contractual issues even when the orders themselves are automated. You must not use automation as a label that disguises outsourced account operation.

Similarly, identical activity across accounts may invite questions when it results from a commercial signal, unauthorized copier, shared setup, or coordinated group. That does not mean ordinary traders cannot use common indicators or independently reach similar conclusions. It means you should know the origin of your EA's signals and be able to document your control of the installation. Read how shared EA signals and IP patterns may be reviewed before adopting any multi-account or copied-signal arrangement.

The clean operating model is straightforward: your account, your verified identity, your credentials, your EA licence where required, your VPS access, and your documented settings. Ask official support in writing before making an arrangement that changes any of those facts. A clear answer before purchase is more useful than an argument after a review. Convenience is never a sufficient reason to give up account control.

A Practical EA Decision Framework and Conclusion

Use a four-question gate before launching. Is the method currently permitted for this exact FTMO account and stage? Can you describe every entry, exit, maximum exposure, and shutdown condition? Has the exact configuration survived realistic forward testing and failure tests? Can the plan withstand ordinary adverse execution while staying inside internal buffers? A “no” or “not sure” at any gate means delay the evaluation and resolve the missing evidence. That is not lost opportunity. It is a cheaper decision than learning the answer through a breached account.

The strongest FTMO bot strategy is therefore usually boring in the best sense. It trades liquid conditions it was tested in, uses finite risk, recognizes correlated exposure, respects verified timing, and stops when inputs or infrastructure are unreliable. It does not need to recover indefinitely, exploit a price-feed quirk, borrow someone else's account, or consume the final margin of a loss rule. Strategy quality appears in the loss plan as much as in the entry signal.

In conclusion, an EA can be used on FTMO when it is operated within FTMO's current terms and configured for the actual account environment. Verify current official rules before every material decision, preserve buffers rather than targeting limits, use UTC and confirmed server time, secure your access, and keep clear records from payment through payout. The right bot is not a promise of funded income. It is a controlled process that remains understandable when the market, platform, or rulebook is less convenient than expected.

Consider a concrete operator scenario. A trader has a simple EUR/USD closing-bar trend EA that takes at most one defined-risk position and normally trades only during a documented liquid session. Before an evaluation, the trader checks the current FTMO platform symbol, maps the chart clock to UTC, sets an internal daily stop below the published limit, and forward tests the actual input file on a secured VPS. On a day with a major scheduled event, the calendar module switches the system to amber, cancels fresh pending entries, and sends an alert. The trader sees that the event time is correctly converted, leaves the protection in place, and reviews the log afterward. That is automation serving a written plan rather than replacing judgement.

Contrast that with a fragile scenario. A purchased robot promises a high win rate but does not disclose its averaging cap, uses a generic “FTMO” preset, and is installed by a seller who requests remote credentials. It opens trades on several related symbols, has no visible portfolio stop, and its calendar times were copied from a different server. A quiet week of gains says almost nothing about the exposure. One persistent move, liquidity interruption, or platform restart can expose the hidden assumptions. Declining that setup is not being overly cautious. It is recognizing that the operational design, not only the entry signal, determines whether a bot is suitable for an account with defined loss boundaries.

Use a decision record to keep the process honest. Write the version of the EA, its licence source, checksum or file date where practical, parameters, allowed symbols, server-time offset, event source, internal risk limits, VPS details, and the official terms version reviewed. Add the date of each test and the result of every deliberately induced failure. When a setting changes, state the hypothesis and the approval date. This record is valuable for your own discipline, for debugging a difference between expected and actual trading, and for responding coherently if FTMO asks a reasonable question. It also prevents a common mistake: attributing a later result to an EA when the operator has quietly changed several settings.

Finally, plan for the mundane parts of trading before they become urgent. Verify eligibility and payment availability in your country before buying, keep proof of payment, and understand how you will receive a payout if you qualify. Check exchange rates, intermediary charges, identity verification, and banking limits with the relevant providers rather than estimating from a headline. Set aside records for local accounting and tax review. A technically excellent EA cannot solve an unavailable payment method, an incomplete verification step, or an ignored local obligation. An FTMO automation plan is complete only when its trading controls and its administrative path are equally clear.

A sensible first-week protocol is deliberately restrained. Confirm that the platform account, symbol permissions, and chart clock still match the test environment. Check the EA log before the preferred trading session, not just after a trade. Let it take only the opportunities defined by its plan and resist the temptation to add a second system because the first day was quiet. Reconcile each order against its intended entry, protective stop, volume, and filter state. If a result differs, stop new entries until you understand whether the source was market execution, configuration, or code. This rhythm produces useful evidence while the account risk is still small.

Treat a losing sequence as a scheduled operating event rather than a personal emergency. Every valid strategy has a distribution of outcomes, and a sequence of stopped trades may be normal if it remains inside the pre-modelled range. Review whether the system followed its rules, whether fills were within the assumed range, and whether the market regime resembles the research sample. Do not widen a stop, increase volume, disable a spread filter, or add a recovery robot merely to make the curve feel better. Stop work only when a defined threshold is reached or an assumption is contradicted. This is how a trader preserves the distinction between controlled variance and a genuine defect.

Vendor due diligence should be as concrete as strategy due diligence. Ask what data the developer used, which settings are essential, how updates are delivered, whether the licence is tied to an account or machine, and what support means in practice. Request documentation that explains all inputs, including magic numbers, maximum order count, trade direction controls, session hours, event behaviour, and emergency stop logic. Be cautious when a seller will show only selected screenshots, cannot provide a raw trade history, or dismisses questions about drawdown as proprietary. You do not need the developer to disclose every intellectual detail, but you do need enough information to operate the system responsibly.

Review costs as a complete process rather than only an evaluation price. There may be a software licence, renewal or update cost, VPS charge, payment-provider conversion, and cost of failed attempts. There may also be opportunity cost if a delicate robot requires constant supervision or cannot trade through ordinary conditions. Compare those costs with the evidence quality and the amount of risk you are willing to assign. Never use a higher lot size simply because you want to recover a fee more quickly. Fees are sunk once paid; the remaining decision should be based on the current account, the verified rules, and the strategy's defined risk.

If FTMO changes a rule, platform integration, symbol schedule, dashboard calculation, or account process, treat that as a configuration event. Pause fresh trading, read the new official wording, identify affected inputs, and retest before enabling the bot again. This is particularly important for settings that refer to time, risk limits, news, symbols, or order handling. The same discipline applies to an EA update. Save the previous version, compare release notes, run it in a safe test environment, and do not assume a new file behaves like the old one. Change control is not glamorous, but it is one of the clearest signs of a sustainable automated operation.

Keep the human override narrow and documented. There are valid reasons to intervene: a verified platform outage, an order placed contrary to the configured logic, an official rule change, an incorrect symbol mapping, or an internal protection failure. In each case, capture the relevant log and account history before changing anything. There are weaker reasons to intervene: disappointment with a normal loss, fear of a position that remains within its planned risk, or an urge to chase a target. Mixing the two produces a hybrid system whose performance cannot be evaluated. Decide in advance which circumstances permit manual closure, cancellation, or a temporary trading pause, and review those choices after the fact.

Periodic review should include positive periods as well as difficult ones. A profitable month can hide a concentration problem if most gains came from one event, one instrument, one session, or one unusually favorable spread condition. Break the results down by symbol, direction, hour, holding time, filter state, and market regime. Compare realized risk with the intended budget and note whether the strategy traded less often because safeguards blocked marginal setups. A protection that prevents a questionable order is working even though it reduces the number of trades. This perspective helps an operator resist optimizing solely for short-term return while overlooking the controls that keep the account viable.

For traders considering several accounts, add complexity only after one deployment is stable and currently permitted. Separate accounts do not make correlated risk disappear, and copying the same robot without a central exposure view can multiply a single market error. Check FTMO's current rules before any arrangement involving multiple accounts, automation, or shared infrastructure. Maintain separate credentials and records, use a clear risk allocation, and do not assume that success on one account validates instant scaling. The durable sequence is evidence first, controlled repetition second, and expansion only after both the trading and administrative process remain manageable.

Make the daily checklist observable rather than aspirational. “Watch risk” is vague; “compare platform equity, open worst-case loss, pending orders, and the internal daily budget before the trading window” can be completed and recorded. “Check the news” is vague; “confirm that the calendar loaded, its time is mapped to server time, and the filter state is shown in the journal” is testable. Specific procedures are especially valuable when you are tired, travelling, or surprised by volatility. They remove the need to reinvent a response under pressure and make it easier to see where an error entered the process.

It is also wise to retain independent copies of critical information. Export account history periodically, save the relevant EA logs, and capture configuration screens after each approved change. Store documents securely, including the current terms snapshot, purchase confirmation, identity-verification correspondence where appropriate, VPS invoices, and payout statements. Do not publish credentials, account numbers, or personal documents in a support chat or social group. Good records protect you from your own memory first, but they also make legitimate support conversations much more efficient. A precise timestamp and a saved log are better evidence than a reconstructed story.

The core decision remains simple even though the preparation is detailed. Use an EA on FTMO only when you understand it, control it, and have checked that its current use fits the official conditions. Select a strategy whose loss is finite and whose execution assumptions are conservative. Protect the account with independent risk, time, and access controls. Verify every important fact that can change, from programme eligibility to payout handling. If that preparation sounds more demanding than buying a robot and pressing start, that is exactly the point: responsible automation is a disciplined operating practice, not a shortcut around one.

Patience is therefore an operational control. Waiting for a written clarification, a completed test, or a clean trading condition can preserve both the account and the integrity of the strategy.

• Confirm current eligibility, payment options, and account terms before paying.
• Use written rules and official support, not vendor claims, for permission decisions.
• Keep risk, time, access, and payout records in one reviewable folder.
• Pause the EA whenever a material rule, platform, or configuration assumption changes.