Can You Use EA on FTMO?

Can you use an EA on FTMO? Start with a qualified answer

An Expert Advisor, usually shortened to EA, can automate actions inside a compatible trading platform. That technical capability does not settle whether one particular strategy, account arrangement, or execution pattern complies with FTMO's current requirements. The careful answer to "can you use EA on FTMO?" is therefore conditional: review the current FTMO Terms and Conditions for the exact product and stage, classify everything the software and its operators do, and obtain an official clarification before trading if any material fact remains uncertain. This article explains how to conduct that review. It does not grant permission on FTMO's behalf.

The distinction matters because "using an EA" describes many different arrangements. One trader may write a simple program that applies a stop after a manual entry. Another may buy a strategy whose vendor controls the settings remotely. A third may connect several accounts through copying software. Those setups involve different questions about personal control, licensing, access, execution, and prohibited conduct. A broad statement about automation cannot responsibly answer all of them. The official FTMO terms listed below are the controlling public source used for FTMO-specific matters here, and readers should check the current version because program rules and contractual language can change after this page's verification date.

Begin by naming the account precisely. Record the product, challenge or account stage, platform, account owner, relevant jurisdiction, and date of review. Open the terms from FTMO directly rather than relying on a screenshot, forum summary, search snippet, affiliate article, or vendor sales page. Search the current document for language concerning trading behavior, third-party access, account operation, prohibited practices, copying, software, credentials, and termination. Read the surrounding clauses instead of treating an isolated sentence as a complete rule. If a dashboard notice or program-specific page adds a condition, include that material in the review and ask FTMO which provision controls if the documents appear inconsistent.

This approach is deliberately more cautious than asking whether a platform displays an automated-trading button. A platform feature shows what the software can execute, not what an agreement permits. Likewise, successful installation does not mean that FTMO reviewed the code, endorsed the method, accepted its license, or approved every resulting trade. Keep separate notes for technical compatibility and rule compatibility. Both need an affirmative, evidence-based answer before activation.

A useful decision rule is simple. Proceed only when the named participant remains in genuine control, the software source and license are legitimate, the execution behavior is understood, risk settings fit the applicable limits, access is secure, and no current FTMO provision or official answer makes the arrangement unacceptable. Pause when a vendor needs credentials, when another person can alter trades, when the strategy depends on an unclear execution advantage, when the code cannot be inspected sufficiently to describe its behavior, or when a rule question has no reliable answer. Pausing is an operational safeguard, not an accusation that a tool is improper.

Automation also does not remove ordinary trading risk. An EA follows its programming and environment, including mistakes in inputs, symbol names, time settings, volume calculations, data, connectivity, and update handling. It can act faster than a person can diagnose a bad assumption. Compliance review and operational review should therefore happen together. Neither proves profitability, guarantees a payout, prevents losses, or predicts FTMO's assessment of an individual case.

Read the current FTMO documents before interpreting software labels

A disciplined rule review begins with source hierarchy. FTMO's current Terms and Conditions are more authoritative for contractual questions than a social post or an EA seller's interpretation. Account-specific notices and official written support may clarify how a provision applies to stated facts. The MetaTrader 5 User Manual is useful for understanding platform functions, but MetaQuotes does not decide FTMO eligibility. Investor education from the CFTC and NFA can provide broader risk context, yet neither source interprets a private firm's agreement for a reader. Use each source only for the purpose it can actually support.

Download or preserve the terms that apply when practical, note the access date, and write down the exact program under review. Do not assume that wording remembered from an earlier challenge still applies. Do not transfer an answer from a different firm, account type, platform, or participant. FTMO can revise products and documents, so a historical answer is context rather than current authority. The sources on this page were checked on the date shown in the source list. Anyone reading later should verify the live official materials before making a decision.

When reading a provision, distinguish a permission from an absence of a named prohibition. A document may regulate outcomes or conduct without listing every software category that could produce them. Conversely, a broad reference to software does not necessarily answer questions about a third-party operator, copying arrangement, shared strategy, or hosted service. Translate the proposed workflow into facts: who selected the strategy, who owns or licenses the code, who can edit inputs, where signals originate, which device transmits orders, who can log in, and what happens without the participant's intervention. Then compare those facts with the whole relevant section.

Terminology deserves special care. Traders often use "EA" to cover indicators, scripts, panels, trade managers, copiers, signal bridges, remote services, and fully automated strategies. MetaTrader documentation explains technical distinctions, but a compliance review must also examine practical control. A product marketed as an assistant may still place orders. A product sold as an EA may only display an alert. A copier may run as an EA while receiving decisions from somewhere else. The product name should never substitute for a functional description.

If the terms leave an important point unclear, send a narrow question to official FTMO support. Include the account product and stage, platform, whether the code is personally developed or licensed, where it runs, whether any external signal enters it, who has credentials, who can change settings, and whether it communicates with a vendor server. Avoid asking only "Are EAs allowed?" because a broad answer can omit the exact fact that creates concern. Ask whether the described arrangement complies with the current rules and request the applicable source or clause.

Preserve the complete exchange, not just a cropped favorable sentence. A useful record contains the question, all disclosed facts, response, ticket identifier if available, date, and any linked rule. If the setup later changes, the answer may no longer address it. A new copier, data feed, account, remote administrator, binary update, or signal source can alter the compliance analysis. Reopen the review rather than stretching old guidance to new circumstances.

Conflicting information calls for restraint. If marketing copy appears broader than contractual language, or a community moderator's comment differs from current official terms, do not select whichever answer is more convenient. Ask FTMO to reconcile the discrepancy in writing. Until then, leave the software disabled. No article can guarantee how a private firm will investigate facts or apply its agreement, and this page does not offer a legal conclusion. It provides a method for getting a current, accountable answer before taking avoidable risk.

Separate personal automation from account management and copying

Automation and delegation are not the same thing. Personal automation means software carries out instructions under the participant's genuine control. Delegation occurs when another person or business exercises practical authority over trading, access, or configuration. A participant can own an EA file while still delegating control to its vendor. Conversely, personally written automation can remain under the participant's control if no outside operator can intervene. Current FTMO terms and an official clarification should decide whether the facts are acceptable, not the label attached to the product.

Create a control map before installation. List every human and service that can view credentials, start or stop the terminal, change settings, select signals, replace files, open orders, modify positions, or recover the account. Include vendors, developers, VPS administrators, technical support workers, signal providers, copier operators, and household members where relevant. For each entry, record the access level and remove anything unnecessary. If somebody other than the named participant can effectively operate the account, stop and verify the current FTMO rule before proceeding.

Passing services and managed-account offers deserve particular caution. A promise that another party will complete an evaluation, operate an account, or provide a preconfigured remote environment can raise account-control and credential issues regardless of whether an EA is involved. Do not give a service a password, recovery code, remote desktop session, or device approval merely because it describes the process as automation. This guide does not provide methods for concealing an operator, disguising access, or defeating monitoring. The compliant response to an uncertain arrangement is disclosure and official verification, not evasion.

Trade copying also requires a factual description. Identify the master account, the person making decisions there, every receiving account, the copier software, and who controls allocation. Copying one's own decisions and receiving another person's strategy are different arrangements, but neither should be assumed acceptable without checking the applicable terms. The presence of a local EA does not transform an external instruction into a personally originated decision. If multiple people, accounts, or services are involved, give FTMO the complete structure and ask about that structure specifically.

Signals create similar ambiguity. An alert that the participant evaluates before manually acting differs from a service that sends executable instructions directly into a terminal. Between those endpoints are webhooks, APIs, bridges, chat readers, and semi-automated panels. Document whether an external party chooses the instrument, direction, timing, size, stop, target, or exit. If the participant cannot explain where the trading decision originates, the workflow is not ready for a compliance assessment, much less live use.

Developers may need access while creating or troubleshooting software, but convenience does not automatically justify account access. Use a separate development environment and non-account-specific materials when possible. Do not provide FTMO credentials or continuing remote control. If troubleshooting genuinely requires an arrangement that could expose the account, ask FTMO first and limit access according to its answer. Also make sure the software license permits the planned installation and does not require a vendor to retain operational control.

Account recovery belongs in the same control map. The participant should control the registered email, multifactor authentication, platform passwords, customer portal, and approved recovery methods. Shared mailboxes and vendor-controlled hosting can undermine that boundary even when nobody admits to trading manually. Remove old authorizations after support work, rotate credentials through supported processes if exposure occurs, and report a suspected compromise honestly. Do not continue automated trading while an unknown party may have access.

The safest summary is not "all third-party software is forbidden" or "an EA makes everything personal." Both statements are too broad. Assess the actual chain of decisions and access against FTMO's current official materials. Keep authority with the named participant, avoid outsourced operation, and request a written ruling whenever someone else can influence execution. This compliance-centered position protects the integrity of the review without pretending to know facts that only the participant, vendor, and firm can confirm.

Review EA ownership, licensing, updates, and external dependencies

An EA's legal acquisition and technical installation are separate from FTMO compliance. A marketplace receipt may show a right to use software, but it does not show that every strategy behavior is compatible with the firm's current terms. Likewise, an official support answer about a described strategy does not resolve copyright, license, or vendor-contract questions. Review both dimensions and seek qualified advice for a genuine legal dispute. This article does not determine ownership or provide a legal opinion.

Start a software inventory containing the product name, developer, version, acquisition source, license holder, activation method, installed files, libraries, configuration files, and network dependencies. Keep authentic receipts and license text where available. Do not use pirated binaries, cracked activation tools, copied account credentials, or files of uncertain origin. Besides obvious security and rights concerns, unknown code makes it difficult to explain behavior truthfully during a compliance inquiry.

Determine whether the EA communicates outside the platform. Some tools contact a license server, obtain data, receive strategy instructions, synchronize accounts, or download updates. External communication is not automatically improper, but its purpose changes the factual analysis. A server that validates a purchase is different from one that selects trades. Ask the vendor to describe endpoints and operational control clearly. If the vendor cannot or will not explain what the remote component does, do not connect it to an FTMO account.

Source code access can aid review, yet source ownership is not a universal requirement and does not itself prove compliance. When only a compiled file is available, obtain reliable documentation of inputs, order logic, communications, and failure behavior. Observe permissions requested by the platform and operating system. Do not enable broad web access, dynamic libraries, or remote controls casually. Follow MetaQuotes documentation for platform functions, and remember that platform instructions explain operation rather than FTMO policy.

Version control should be practical and honest. Record the checksum or another dependable identifier where appropriate, version number, installation date, settings, and person who authorized the change. Preserve the prior approved configuration long enough to investigate a problem, subject to legitimate license terms and security needs. Never modify records to make an unreviewed version appear older. The objective is to know exactly what ran, not to manufacture evidence after an event.

Treat every update as a new review point. A vendor can add instruments, alter sizing, change timing, introduce external signals, revise licensing, or replace order-management logic. Release notes are helpful but may not describe every internal change. Test technical behavior away from the FTMO account, compare all settings, and ask the developer about material differences. Recheck official rules if the workflow or execution behavior changes. Prior acceptance of one version should not be treated as indefinite approval of unrelated later behavior.

Presets are code-adjacent instructions, not harmless decoration. A settings file can determine position size, trading sessions, symbol filters, maximum orders, stops, and external identifiers. Know who created each preset and whether it was designed for the exact symbol specifications and environment. A vendor's high-risk preset, unexplained optimization file, or remotely changing configuration should remain off until its behavior and compliance implications are understood. Never represent somebody else's ongoing strategy control as merely a settings choice.

Contract developers should work under clear boundaries. Define ownership and permitted use in an authentic agreement, but do not infer that a contract with the developer binds FTMO. Keep production credentials out of code repositories and support messages. Use sanitized logs when possible. End remote permissions after work concludes, remove unused API keys, and inspect scheduled tasks or startup items. If a developer must remain involved in live operation, disclose that fact when asking FTMO whether the arrangement is allowed.

Finally, establish an abandonment rule. Retire the EA if its provenance cannot be verified, its license is invalid, its remote behavior is opaque, the developer demands account control, an update cannot be assessed, or the current FTMO materials create unresolved concern. Money already spent on software is not a reason to accept a compliance or security risk. A documented decision not to deploy is often the most responsible result of a thorough software review.

Translate FTMO limits into conservative automated risk controls

An EA can place and modify orders quickly, but speed does not transfer responsibility away from the participant. Before activation, identify every current limit and objective applicable to the exact FTMO account. Use the official terms, dashboard, and program materials available to that participant, then verify ambiguous calculations with FTMO. Do not copy numerical thresholds from this article because products and rules may change, and a number that applies to one stage may not apply to another.

Translate each applicable rule into a written operational requirement. Define what equity or balance measure matters, when a period begins and ends, how open profit or loss is treated, whether commissions or swaps affect the calculation, and what happens around server-time boundaries. Ask FTMO if the official explanation does not settle a point. The EA's internal label, such as "daily stop," is not proof that its formula matches the firm's calculation.

Position sizing needs independent verification. Review contract size, tick value, quote currency, account currency, volume step, minimum and maximum volume, stop distance, and conversion logic for every intended symbol. Test how the program responds to missing or abnormal values. Hard-coded assumptions copied from another broker or symbol can produce a materially different exposure. A conservative design should reject an order when required data is unavailable rather than guess.

Aggregate exposure is more important than a single-order setting. Count open positions, pending orders, correlated instruments, multiple strategy modules, and manual trades. Determine whether each component sees the others before calculating size. Two individually cautious EAs can create excessive combined risk if neither knows the other exists. If more than one tool runs, assign a portfolio-level limit and a single authority that can prevent additional orders. Verify that this design remains consistent with current FTMO requirements.

Define behavior for slippage, partial fills, rejected modifications, widened spreads, market closure, disconnection, delayed data, platform restart, and duplicate events. An EA should not repeatedly increase volume or remove protection merely because an order failed. The safe response may be to stop and alert the participant. Technical testing cannot remove market risk, and a stop order cannot guarantee a particular execution price. Avoid performance promises from vendors who describe controls as infallible.

Time logic requires special attention. The computer's local clock, VPS time, platform display, and trading server can differ. Daylight-saving changes and holiday schedules can shift sessions. Record which clock drives each condition and test boundary behavior. Do not assume that a midnight reset in the EA corresponds to an account rule. Obtain the current official definition and configure a safety margin rather than operating exactly at a limit.

News and event handling should follow the account's current rules and the strategy's documented risk plan. Do not rely on an old calendar screenshot or another firm's policy. Identify the data source, timezone, update process, and response to missing events. If a relevant FTMO restriction or condition is unclear, keep the EA off during the uncertain period and ask support. This page does not claim that a particular news-trading method is permitted.

Use layered stop conditions. A strategy-level stop can halt new entries after defined behavior. A platform-level monitor can detect connection or order anomalies. A human-controlled shutdown procedure can close or disable systems where doing so is operationally appropriate. Layers should fail conservatively and avoid fighting one another. Document who receives alerts and how quickly that person can respond, but never assume monitoring guarantees prevention of a breach or loss.

Set buffers below applicable constraints according to a cautious plan rather than targeting the boundary. Buffers accommodate calculation differences, costs, slippage, and concurrent events, although they cannot guarantee compliance. The appropriate size depends on the strategy and current account terms, so this guide does not invent a universal percentage. If the system only appears viable when it operates extremely close to a contractual limit, reconsider the design instead of searching for a less visible implementation.

Risk documentation should end with a clear kill criterion. Disable the EA after an unexplained order, settings mismatch, update, access change, data failure, calculation discrepancy, or official rule revision until the issue is resolved. Preserve accurate records and communicate truthfully if asked. Automation is valuable only when the participant can understand, supervise, and stop it; unattended operation is not a substitute for accountable control.

Test technical behavior without claiming performance or approval

Testing has two limited purposes in this context: discover how the software behaves and determine whether its configuration matches the documented plan. It cannot prove future returns, guarantee compliance, or bind FTMO to an outcome. Historical simulations depend on data and modeling assumptions. Forward observation covers only conditions that occurred. Treat all results as diagnostic evidence rather than a pass rate, profit promise, or official certification.

Begin outside the FTMO account in an environment suited to safe technical review. Confirm installation, dependencies, symbols, permissions, input ranges, and logging. Use the MetaTrader manual to understand tester and terminal functions where relevant. Do not assume that a platform test environment reproduces FTMO's execution, contractual calculations, or account review. The goal is to find obvious defects before they can affect the account, not to imitate or probe firm controls.

Write expected behavior before each scenario. State the market condition or simulated event, expected order action, maximum intended exposure, protective action, alert, and shutdown response. Include ordinary failures such as unavailable data, invalid price, rejected order, lost connection, restarted terminal, corrupt settings, and expired license. Compare observed behavior with the expectation and investigate discrepancies. A vague statement that the robot "looked fine" is not an adequate readiness record.

Test inputs at their boundaries, including zero, maximum allowed by the design, missing values, incompatible combinations, and accidental duplicates. The program should validate settings and refuse unsafe configurations with an explicit message. A default value should not silently replace an invalid risk input. If the code's behavior cannot be determined, ask the developer or abandon deployment. Never use a live FTMO account as an experimental environment for unknown execution logic.

Symbol mapping deserves its own matrix. Record the platform symbol, contract details, price digits, volume increment, trading schedule, order types, and any suffix or prefix. Verify each intended market separately. A configuration that works for one instrument should not be cloned mechanically across others. When account specifications change, repeat the review. Technical availability of a symbol does not establish that a strategy involving it meets all current FTMO conditions.

Check restart and recovery behavior carefully. Determine whether the EA reconstructs existing positions, duplicates pending orders, forgets a daily counter, or re-enters after a crash. Confirm what happens when charts are changed, templates are loaded, the account is switched, or automated trading is toggled. Require an unmistakable indication of active version and settings. The participant should be able to reconcile every open order with a known strategy instance.

Logs should be proportionate, secure, and truthful. Capture timestamps, version identifiers, settings references, strategy decisions, order requests, platform responses, and errors necessary for diagnosis. Avoid recording passwords, recovery secrets, or unnecessary personal information. Protect files from unauthorized access and follow applicable retention obligations. Do not edit logs to influence a later review, and do not use logging as a way to collect or reverse engineer FTMO security signals.

A pre-production review should compare the tested configuration byte for byte or setting for setting with what will be installed. Confirm the account number or environment safely, chart assignments, allowed symbols, schedules, risk limits, and external addresses. Have the participant perform the installation or supervise it without surrendering credentials. If a vendor insists on a secret configuration or remote session that prevents meaningful oversight, pause and seek clarification.

Finish with a signed or dated readiness note. It should identify unresolved issues, not conceal them. Approval is inappropriate if the official rule review is stale, a vendor retains control, behavior differs from documentation, risk calculations are uncertain, or account access is insecure. The note demonstrates a careful process only; it does not force FTMO to accept conduct and should never be presented as an official authorization.

Operate a VPS securely without disguising identity or access

A virtual private server can keep a trading terminal running when a home computer is offline, but it introduces another computer, network, administrator, and credential boundary. Whether a specific VPS arrangement is acceptable must be checked against current FTMO materials and, when needed, official support. Do not infer permission merely because a hosting company advertises to traders or because the platform connects successfully.

The central compliance principle is transparency. Use hosting for legitimate continuity, not to misstate location, conceal another operator, create misleading access records, or evade review. This page will not explain IP masking, device spoofing, identity concealment, or monitoring bypass. If ordinary travel, an internet-provider change, or hosting creates a question, describe the genuine facts to FTMO and request guidance. A truthful pause is safer than a technical workaround.

Keep the server under the participant's personal administrative control. Use a reputable provider, unique credentials, multifactor authentication where supported, current security updates, firewall restrictions, encrypted connections, and limited user accounts. Change default passwords and remove unused services. Store recovery information securely outside the server. These are general defensive measures, not guarantees against compromise or statements about a particular FTMO security requirement.

Inventory every administrator. Hosting support may have infrastructure privileges even when it does not know platform credentials. An EA installer or freelance technician may receive remote desktop access. Record why access is needed, limit its scope and duration, supervise appropriate work, and revoke it promptly. Never let a vendor continue operating the terminal merely because installation is inconvenient. If outside access to the account cannot be avoided, ask FTMO whether the precise arrangement is permissible before granting it.

Separate credentials by purpose. The hosting portal, operating system, remote desktop service, trading platform, email, and FTMO customer area should not share passwords. Do not place secrets in scripts, chat messages, screenshots, cloud notes, or vendor tickets. Restrict clipboard and drive sharing when they are unnecessary. If credentials are exposed, disable automation, secure the accounts through supported procedures, and report relevant facts honestly rather than trying to hide the incident.

Server location should reflect a legitimate operational choice, not a plan to manipulate how the participant appears. Network addresses can change for normal technical reasons and do not tell the whole story of account control. FTMO's internal review methods are not established by the sources listed here, and readers should not speculate about them. Maintain normal provider invoices, access notices, and change records so genuine events can be explained accurately if asked.

Configure uptime monitoring without handing trade authority to a third party. A notification service can alert the participant that a terminal stopped, but an outside operator who logs in and makes trading decisions changes the control analysis. Define who may restart the server, who may restart the application, and who may alter the EA. Automated recovery should not duplicate orders or reset safety counters, and its behavior should be tested before account deployment.

Patch management requires balance. Unpatched systems create security risk, while automatic restarts or changed libraries can disrupt execution. Establish a maintenance window, review vendor notices, preserve the active configuration, and retest material updates. Do not postpone critical security work indefinitely to keep a strategy running. If safe maintenance cannot be completed without unacceptable account exposure, stop trading until the environment is secured.

Have an incident plan for compromise, unexplained login alerts, malware, missing files, altered settings, and provider outages. The first action should protect the account and halt uncertain automation. Preserve authentic evidence, contact appropriate providers, rotate exposed credentials through approved channels, and tell FTMO relevant facts if required or prudent. Do not delete records, fabricate an explanation, blame an IP address without evidence, or continue trading from an environment that is no longer trusted.

A VPS checklist is complete only when it covers account policy, personal control, security, maintenance, recovery, and exit. Before changing provider or location, revisit the current rule review and update the access inventory. Securely remove platform data and credentials from retired servers. The server is an operational tool, not an exemption from the participant's obligations or a shield behind which another person may manage the account.

Use a documented pre-trade verification checklist

A checklist turns broad caution into a repeatable decision. It should be short enough to use and detailed enough to expose material changes. Complete it before the first activation, after any update or access change, and whenever FTMO changes relevant terms or the selected product. A checked box must correspond to real evidence. The form does not cure prohibited conduct and should never become paperwork used to rationalize an unclear setup.

1. Identify the governing account and sources

Write the exact account product, stage, platform, named participant, and review date. Link the current FTMO Terms and Conditions and any program-specific official material actually consulted. Record the version or retrieval date. Note unresolved conflicts and include complete official support exchanges. If the source cannot be identified, the review is not complete.

2. Describe the EA in plain language

State whether it generates entries, manages orders, sizes positions, receives external instructions, copies trades, contacts remote servers, or merely displays information. Name the version and configuration. A reviewer should understand the chain of decisions without relying on marketing terminology. When behavior is unknown, leave automation disabled.

3. Confirm personal account control

List everyone with portal, platform, email, server, code-update, or remote desktop access. Confirm that the participant controls credentials and can stop the strategy. Remove obsolete permissions. Escalate any vendor, signal seller, copier operator, passing service, developer, or administrator who can influence live execution. Ask FTMO about the complete arrangement rather than minimizing that person's role.

4. Validate legitimate software rights

Keep the authentic license, acquisition record, developer information, and permitted installation details. Verify that required activations do not transfer practical account control. Scan and secure files through an appropriate process. Reject cracked software, unknown binaries, and unexplained external dependencies. For an ownership dispute or license interpretation, consult a qualified professional rather than treating this educational page as legal advice.

5. Reconcile current risk requirements

Transcribe applicable limits from official account materials without relying on remembered numbers. Verify time definitions, equity treatment, costs, open exposure, and reset conditions with FTMO where unclear. Map those requirements to conservative controls and buffers. Check combined automated and manual exposure, not only the settings of one chart.

6. Verify technical specifications

Review symbols, contract values, price precision, volume increments, sessions, server time, order permissions, stop rules, and conversion logic. Confirm behavior for rejection, slippage, disconnection, restart, partial fill, and missing data. Match the deployed version with the tested version. Do not activate if a mismatch or unexplained order remains.

7. Secure the workstation or VPS

Apply unique authentication, least privilege, updates, network restrictions, backups of appropriate configuration, and an access inventory. Ensure that hosting is used transparently and not for concealment. Revoke temporary technicians. Document genuine provider and location changes, then seek official guidance if current materials make their relevance uncertain.

8. Establish supervision and shutdown

Name the person receiving alerts, conditions that stop new orders, procedure for disabling the terminal, and response to an account or security incident. Make the stop process accessible without a vendor. Test recovery safely. Do not promise that supervision prevents every loss, rule breach, or technical failure.

9. Ask focused official questions

Prepare a factual description that includes external signals, copying, shared code, remote access, hosting, and operational roles. Send it to FTMO when public documents do not answer a material issue. Preserve the response and do not broaden it beyond the disclosed facts. Re-ask after meaningful changes.

10. Make a genuine go or no-go decision

A "go" means the current evidence supports the exact configuration and responsible people are prepared to supervise it. A "no-go" applies when a rule is unresolved, access is shared, software behavior is opaque, rights are doubtful, risk mapping fails, or security is compromised. Record reasons honestly. Sunk cost, vendor pressure, or fear of missing a trading session should not reverse a no-go.

Review the completed checklist after deployment as well. Compare actual orders, logs, access, and settings with the approved description. Stop when reality diverges. A checklist is useful because it creates a moment for judgment before code acts, but its value depends entirely on accurate inputs and a willingness to decline activation.

Respond honestly to updates, errors, and compliance questions

Even a carefully reviewed EA can encounter an unexpected event. The appropriate response is containment, preservation, assessment, and truthful communication. Do not let the program continue placing orders while nobody understands what happened. Disable the affected automation through the established procedure, secure the account if access may be involved, and record the observable facts before theories replace evidence.

Preserve relevant platform logs, EA logs, version information, settings, order identifiers, timestamps, access notifications, and vendor messages. Protect sensitive information and do not publish credentials or personal data. Do not edit, backdate, selectively recreate, or destroy records to make the event appear compliant. Honest records may not prevent an adverse outcome, but fabricated records create additional integrity and security problems.

Classify the event without rushing to assign blame. Possible categories include configuration error, code defect, vendor update, platform behavior, connection failure, data issue, credential exposure, unauthorized access, misunderstood rule, or ordinary market execution. Several causes may interact. State what is known, what remains unknown, and what evidence supports each conclusion. Avoid claiming that FTMO or a provider caused an event without adequate evidence.

If current terms, an official request, or the seriousness of the issue calls for contacting FTMO, provide a concise factual timeline and answer questions accurately. Include the software's role and outside access rather than describing an automated event as spontaneous. Ask what additional information is needed and preserve the complete exchange. This page cannot predict the firm's decision or promise restoration, payout, eligibility, or any legal remedy.

Vendor support should not become uncontrolled account management during an incident. Share sanitized diagnostics where feasible. Do not give passwords, recovery codes, or unsupervised remote access because the situation feels urgent. If live access is genuinely proposed, verify the arrangement with FTMO first and restrict it appropriately. A developer can explain code without taking over the participant's trading identity.

After containment, reproduce the defect only in a safe environment. Compare the production version and settings with the approved record. Review updates, file integrity, dependencies, operating-system events, and connection history. Do not experiment on the FTMO account or place trades designed to discover monitoring behavior. The purpose is ordinary diagnosis and prevention, never evasion or reverse engineering of firm controls.

Corrective action may include retiring the EA, reverting a legitimate version, changing settings, fixing code, strengthening access controls, replacing the server, improving alerts, clarifying rules, or ending a vendor relationship. Retest the complete affected workflow. A narrow fix is insufficient when the incident reveals that nobody understood the software or that an outside party actually controlled it.

Reactivation requires a fresh no-go review. Confirm that the cause is sufficiently understood, correction is verified, current FTMO requirements have been checked, official questions are resolved, and access is trustworthy. Document residual uncertainty. If those conditions cannot be met, keep the software off. There is no entitlement to reactivate merely because downtime is inconvenient.

Use lessons from the incident to improve the general process without rewriting history. Update the checklist, clarify ownership, reduce permissions, strengthen tests, and add a meaningful alert where appropriate. Preserve the original timeline alongside later findings. A mature operating process admits mistakes and changes controls; it does not pretend that an incident never occurred.

Rule updates deserve the same pause discipline as technical failures. Subscribe to appropriate official communications, revisit live terms periodically, and compare revised language with the factual workflow. Do not rely on a vendor to monitor FTMO policy for you. If a revision affects copying, account access, prohibited conduct, software, or risk calculations, seek a current answer and keep the relevant function disabled until the review is complete.

Conclusion: Can You Use EA on FTMO?

The responsible conclusion is qualified rather than promotional. An EA is a technical tool, and its acceptability depends on the exact FTMO account, current official rules, strategy behavior, software rights, access model, and execution arrangement. Check the live FTMO Terms and Conditions before activation and ask official support about material facts the public documents do not clearly resolve. A platform's ability to run an EA is not blanket approval from the firm.

Keep the named participant in genuine control. Do not outsource account operation to a passing service, signal provider, vendor, developer, or VPS administrator. Do not assume that copying becomes personal trading because a local EA transmits the orders. Describe who makes every decision and who can change every setting. If another party can operate the account, pause and obtain a direct current answer.

Use legitimately acquired software whose behavior can be explained. Inventory versions, licenses, presets, external communications, and updates. Validate symbol details, time logic, aggregate exposure, failure handling, and shutdown controls away from the FTMO account. None of that testing proves profitability or compels FTMO to approve an arrangement. It simply reduces avoidable uncertainty.

Run hosting transparently and securely. A VPS should support continuity, not disguise identity, location, access, or third-party management. Protect credentials, limit administrators, maintain updates, and remove old permissions. This guide intentionally provides no bypass tactics. Genuine access changes and security incidents should be documented and addressed honestly.

Finally, preserve a dated evidence trail and recheck it after every material change. Rules, products, software, and infrastructure can evolve. The source verification date below describes this page's review, not a promise that wording remains unchanged. When current guidance is missing, conflicting, or stale, the correct operational decision is to leave the EA off until FTMO clarifies the setup.