FTMO IP Detection Rules for EA Traders

What IP Detection Actually Means for an FTMO EA Account

An IP address identifies the network connection visible to an online service at a particular time. It does not prove a trader's identity, skill, residence, or intention by itself. Households often receive changing addresses from an internet provider, mobile networks rotate addresses, hotels place many guests behind one gateway, and a commercial VPS can be used by many unrelated customers. Consequently, a responsible review should consider IP information alongside login history, devices, identity verification, account terms, trading records, and explanations. Do not rely on internet commentary that claims a single unfamiliar address causes an automatic ban. Only current official communication can state how FTMO applies its processes.

For EA users, distinguish the person who owns and controls the account from the machine that executes instructions. You may inspect a terminal remotely while the EA operates on a server, and the terminal's network record may therefore differ from the browser record on your laptop. That difference is ordinary when it has a sensible explanation. It becomes difficult to defend if credentials are passed around, if a vendor operates the account, or if the trader cannot identify the VPS, terminal, EA version, and remote-access method. The useful question is not, "Can I hide my IP?" It is, "Could I accurately explain every access point and every person with access?" FTMO EA account-management guidance helps separate automation from delegated account control.

Think of detection as a review of consistency, not a technical puzzle to beat. A residential connection on Monday, a mobile connection on Tuesday, and a VPS terminal every day can be entirely consistent when the account holder can describe the routine. The same pattern becomes concerning when it is paired with contradictory personal information or unexplained control by others. This perspective helps an EA trader make better decisions: simplify the setup, avoid unnecessary services, and keep ordinary evidence. It also prevents overreaction. There is no need to interrupt a sound strategy simply because a dynamic ISP issued a different address.

• Record the account holder's legal identity and contact details.
• List each normal login location, device, and connection type.
• Separate client-area logins from trading-terminal connections.
• Identify the VPS provider, region, and operating-system account.
• Keep evidence that the trader, not a vendor, controls credentials.

Read the Current Official Terms Before Designing Around Access

Terms governing simulated evaluation accounts, FTMO Account activity, restricted practices, verification, geography, payment, and payout are time-sensitive. A search snippet, affiliate article, old social post, or a screenshot from another trader is not a safe compliance source. Before buying an evaluation and again before changing infrastructure, read the version of the FTMO Agreement and linked policies presented to you. Note the date, the account product, the platform, and the exact language relevant to your situation. If the wording does not plainly answer a proposed setup, ask Support a narrow question and retain the reply. A reply should describe facts, not seek permission to evade controls.

Phrase the question clearly: state that you are the verified account holder, name the country in which you reside, say whether your EA will run on a VPS, identify where that VPS is located, and explain whether you will connect by remote desktop while traveling. Ask whether any advance notice or documentation is required. Do not ask a support agent to bless an undefined future arrangement. If your plan later changes materially, ask again. This approach also protects you from configuring against a rule that applied to a different account type. EA compatibility on FTMO is useful planning material, but it is still secondary to the terms available when you trade.

Make rule review a recurring control rather than a purchase-day task. Revisit it when an account passes, when a payout becomes due, when FTMO announces a platform change, and when you add a new automation service. Record the source URL and access date in your journal. If terms appear to conflict with an older support reply, ask which guidance governs. Never treat silence as approval. This careful habit is especially valuable for automated systems because an unchanged terminal can continue sending orders long after a trader has forgotten that an assumption about access, timing, or restricted conduct needs updating.

• Save a dated copy or PDF of applicable official terms.
• Confirm the terms match your selected account and platform.
• Check restricted-practice and account-access clauses word for word.
• Ask Support before an unusual relocation or access arrangement.
• Store written replies with the question that produced them.

Map Every Access Path in an EA Workflow

A clean setup begins with an access map. Include the FTMO client area, email inbox, two-factor authentication method, trading-platform credentials, VPS provider portal, operating-system user, remote-desktop application, EA license portal, and any alerting service. Write who can access each component. The answer should ordinarily be one verified trader, with carefully limited technical support only where official terms and security practice allow it. A developer who receives an EA log file does not need your client-area password. A VPS host that supplies a server does not need trading credentials. Reducing permissions makes both security and later explanations much easier.

Then map the direction of each connection. Your laptop might reach the VPS from home; the VPS terminal might reach a broker server; a phone may receive alerts without holding the password. A cloud backup or signal copier can add another endpoint that deserves scrutiny. This map prevents accidental sharing, such as leaving a saved trading password in a support ticket or allowing a former contractor to retain remote desktop access. It also exposes whether a proposed convenience feature effectively gives a third party operational control. Read how firms review shared signals and IP addresses before using shared infrastructure or a copied signal.

Use the map during maintenance as well. When an EA stops, the temptation is to grant broad access quickly because an open position or a scheduled session feels urgent. A prewritten map tells you which connection can be checked without exposing another credential. It also makes offboarding concrete: when a VPS is replaced, remove the old terminal, revoke its remote credentials, and confirm that alerts no longer route through it. Good access design is not merely a compliance record; it reduces the chance that a forgotten machine keeps running an obsolete configuration.

• Draw the route from your device to the VPS and terminal.
• Assign one named owner to every password and recovery method.
• Remove obsolete remote-desktop users and saved sessions.
• Use distinct strong passwords and multi-factor authentication where offered.
• Document which services receive trade data or alerts.

Use a VPS for Reliability, Not Concealment

A VPS is a reasonable technical choice when an EA needs stable power, connectivity, and platform uptime. It can also reduce disruption caused by a home router restart or laptop sleep. Choose a reputable provider, secure the server, and select a region based on legitimate execution and support considerations rather than an attempt to create a misleading identity. The VPS IP will often remain stable while your personal broadband address changes. That is a helpful operational record, not a workaround for ownership rules. The account holder should be able to log in, review logs, update the EA, and stop trading without relying on an undisclosed operator.

A server location is not automatically evidence of residence. Traders commonly use data centers in other countries. Still, a mismatch between residency, verified identity, payment details, and a server should be explainable if reviewed. Keep your VPS invoice, provider name, server region, provisioning date, and remote-access account. If the provider migrates your machine or changes its address, capture the notification. For configuration and resilience rather than compliance assumptions, see VPS considerations for forex EAs. Never present a VPS address as your personal location, and never rent a server controlled by a passing service.

Reliability choices should also be measured. Monitor terminal connection status, disk capacity, clock synchronization, restart behavior, and whether the platform actually relaunches after maintenance. A server that silently disconnects can force hurried remote intervention from an unfamiliar network, while a server that restarts with duplicate charts can create unwanted orders. Test every recovery procedure on a safe environment. Keep the hosting account and billing under your control so you can retrieve logs or shut the system down without asking an unrelated operator. Reliability and accountable control reinforce each other.

• Open the VPS account in the trader's own name and email.
• Enable operating-system updates, firewall rules, and secure remote access.
• Keep the provider invoice and server-region confirmation.
• Configure restart behavior, EA health checks, and a manual kill switch.
• Change passwords immediately if a technician was granted temporary access.

Travel, Mobile Networks, and Changing Home Internet

Travel produces a normal change in browser IP, mobile carrier, time zone, and perhaps device. It should not be treated as a reason to use someone else's network identity or to hand the account to a friend at home. Before a longer trip, check current country eligibility and sanctions-related restrictions in official materials. A country can be acceptable as a place to travel without being acceptable for onboarding or payment, and rules may depend on residency rather than nationality. If an account will remain active on a VPS while you travel, decide whether you will merely monitor it or modify settings, and make sure any planned access is consistent with current policy.

A home connection can also change without travel. Dynamic IP allocation, an ISP replacement, a power outage, and switching from Wi-Fi to cellular data are commonplace. Do not panic and create elaborate technical detours. Log the date, approximate reason, and new provider if known. What matters is a coherent timeline. If you expect access from an unusual country, especially one that could affect eligibility, contact Support first with the facts. The same principle applies when a hotel, airport, or coworking network makes a login appear far from your usual address. Honest notice is safer than an explanation invented after a review.

Plan travel around operational risk, too. A weak hotel connection is a poor place to update an EA, modify stops, or install a terminal. If the system is already stable on a VPS, monitoring through a secure personal device may be enough until you return. If a change cannot wait, use a known secure connection and record the reason. Do not ask a friend to make the change from your normal home location. That might preserve a familiar address while destroying the much more important fact that you personally controlled the decision.

• Check destination-country eligibility before international travel.
• Keep your regular VPS running only if your configuration permits it.
• Log significant travel dates and any material network change.
• Avoid public computers and unsecured Wi-Fi for sensitive account changes.
• Contact Support before access from a potentially restricted jurisdiction.

Device Changes, Remote Desktop, and Browser Hygiene

Replacing a laptop, reinstalling an operating system, or using a phone during an emergency is generally a security event to manage, not a reason to avoid the account. Update your password, sign out of older sessions where possible, and add the new device gradually through normal authentication. Preserve proof of ownership for significant equipment if it is relevant to a later explanation, but do not send unnecessary personal data unless FTMO requests it through an official channel. Be wary of browser extensions, remote-support tools, and shared password managers. They can expose credentials or make it impossible to say who initiated a login.

Remote desktop deserves special care because it can make an EA workflow efficient while also allowing direct trade control. Use an account you alone administer, protect it with unique credentials and multi-factor authentication where available, and restrict network access. If a developer needs to diagnose an EA, prefer logs, screenshots, a demo environment, or a supervised screen session without credentials. Giving a developer an unattended remote desktop session to a live evaluation can turn a technical fix into third-party access. The underlying distinction is explained further in automation versus account management.

Browser hygiene matters because the client area is often the path to profile, payment, and account changes. Do not sign in through links from unsolicited messages, even if they mention a compliance check. Navigate to the official site independently and verify notices through established channels. Use a separate browser profile for financial services if that helps you avoid risky extensions and casual shared sessions. Clear unused saved credentials when selling a device or returning a work computer. Security records are most persuasive when they show that you made unauthorized access difficult in the first place.

• Use a named operating-system account rather than a shared administrator.
• Revoke remote-support access after each troubleshooting session.
• Review saved browser passwords and active account sessions.
• Maintain an emergency device procedure that does not share credentials.
• Test remote access on a demo terminal before an urgent live need.

Account Ownership Is More Important Than a Familiar IP

The most defensible arrangement is uncomplicated: the person who completed registration and verification owns the account, chooses the strategy, controls the credentials, and bears responsibility for the decisions. An EA does not change that responsibility. Buying software, subscribing to a signal, or commissioning code may be compatible with personal operation, but another person logging in to execute, change risk, pass a challenge, or receive account credentials raises a different issue. A familiar IP cannot make third-party control acceptable. Conversely, an unfamiliar hotel IP does not itself make a personally controlled account unacceptable.

Avoid informal arrangements that blur this boundary. A relative should not monitor and intervene while you sleep. A seller should not "optimize" a live account after a drawdown. A community administrator should not collect login details to install the same system for members. If you need help understanding an EA, obtain documentation and test on a demo, then operate it yourself. The comparison in EA bot versus passing service explains why control, transparency, and contractual responsibility matter more than promised results. Never assume a third party is safe because it uses a VPS or claims many clients do the same.

Ownership also means understanding enough of the system to supervise it. You do not need to be the programmer, but you should know the symbols it can trade, how it sizes positions, when it is meant to run, how to disable it, and where its logs live. If a provider refuses to explain those basics and instead asks for blind trust plus credentials, that is a warning. A sustainable arrangement lets the trader make an informed decision, verify parameters, and stop the system independently. It does not outsource responsibility while retaining the appearance of personal trading.

• Keep email, client-area, platform, and VPS recovery details private.
• Do not give a vendor live-account passwords for installation or tuning.
• Reject offers to trade, pass, or manage your account remotely.
• Make strategy and risk changes yourself after documented testing.
• Check that no family member or colleague has retained access.

Shared EA Signals and Similar Orders Require Care

A firm can review more than addresses. Identical entries, exits, lot changes, instruments, timestamps, stop-loss patterns, and coordinated behavior across accounts may create questions about copied execution or prohibited coordination. Similarity is not automatically wrongdoing. Popular indicators, common market events, and commercially sold EAs can naturally produce overlap. Yet an EA that sends exactly the same orders to a large group at the same moments may be more difficult to distinguish from centrally directed trading, particularly where terms restrict copying, signal sharing, or group conduct. Read the current language rather than relying on labels such as "private" or "licensed."

The practical response is not to add random delay or alter trades merely to defeat detection. That would undermine your strategy and suggest the wrong objective. Instead, operate within terms, understand whether your EA source and signal architecture are permitted, and ask Support a factual question if you plan to use commercially distributed software. Keep purchase records, licensing terms, version notes, and your own configuration history. If the EA has settings that legitimately reflect your risk budget, symbol set, trading session, or news filter, document why you chose them. EA settings optimization should be treated as a risk-control exercise, not a method of disguising a shared signal.

Be particularly cautious with trade copiers, master terminals, managed groups, and invitations to join a supposedly private execution pool. Their architecture can centralize decisions even when each participant owns a separate account. Before connecting any such tool, identify who creates the order, who can change it, where credentials reside, and whether current terms allow the arrangement. A vendor's assurance is not authoritative. If you cannot explain the chain of instruction from market condition to your terminal, choose a simpler system or seek official clarification before risking an account.

• Verify current copying and coordinated-trading restrictions before deployment.
• Keep the EA license, source, vendor invoice, and version changelog.
• Record your own risk, session, symbol, and filter settings.
• Do not use randomization intended to evade a compliance review.
• Ask Support about a commercial signal architecture before connecting it.

Build an Evidence File Before You Need It

A short evidence file makes a genuine review less stressful. It need not contain every click or private document. Maintain a dated access log with device changes, VPS provisioning, significant travel, ISP changes, terminal migrations, and contacts with Support. Save provider invoices and migration notices. Keep EA release notes, parameter exports, broker-server details, and a brief trading journal that identifies planned sessions and risk limits. Store these records securely and do not alter them retrospectively. The aim is an accurate operational history, not a story tailored to a perceived detection system.

Make entries promptly and use plain language. For example: "Moved terminal from personal desktop to my VPS; server remains in Frankfurt; I alone administer remote desktop; EA version updated after demo test." That sentence is more useful than a spreadsheet full of unexplained IP strings. If an address is known, record it as supporting technical detail, but recognize that a public IP can change or be shared. The journal also improves trading discipline: it tells you whether a loss followed an approved parameter change, a connection failure, or a discretionary override. an EA trading journal can help structure that review without turning it into surveillance theater.

Set a modest retention routine. Once a month, export the essential terminal and VPS information, review active users, and confirm that the live parameters match the approved configuration. After a material event, make a short entry while details are fresh. This is less burdensome than trying to reconstruct months of connections from memory after a question arises. Avoid collecting passwords, full identity documents, or other sensitive information in the journal unless there is a separate secure need. The goal is useful provenance, not an insecure archive of everything you own.

• Create a dated access and infrastructure change log.
• Save VPS invoices, migration emails, and support conversations.
• Export EA settings before and after each meaningful change.
• Record platform server time and the terminal account identifier.
• Keep records encrypted or otherwise protected from unauthorized access.

UTC, Broker Server Time, and EA Scheduling

IP review and trading-rule compliance meet when an EA follows a schedule. Your local clock, UTC, VPS clock, and broker-server clock may all differ. Daylight-saving changes can shift offsets even when the VPS itself does not move. An EA scheduled by server time can enter during a restricted window if the developer assumed a fixed UTC offset. That is a trading-control problem, not an IP problem, but a confusing timeline makes any later explanation harder. Record the platform server time, determine its current relationship to UTC, and test around the relevant session boundaries.

Use UTC as the reference language in your documentation, then state the server-time conversion currently in force. Recheck after daylight-saving transitions, a platform migration, or broker-server maintenance. For example, write that a news filter pauses new entries from a specified UTC interval and verify the terminal shows the intended corresponding times. Do not invent a universal offset or assume that a city label on a VPS establishes the broker clock. Current official rules determine any restricted event or reset timing. news trading for forex EAs provides a useful framework for filters, but the official FTMO rule must control your live settings.

Include pending orders and open-position behavior in the test. A filter that blocks new market orders may not cancel a pending entry placed earlier, and a pause may not manage an existing trade as intended. Similarly, a daily reset can occur while an EA is holding exposure. Review terminal logs around the boundary and calculate risk using the definitions in current official materials. Precise clocks do not excuse a strategy that ignores floating loss, spread expansion, commissions, or the actual account rule. Time control is one layer in a wider risk-control system.

• Set your operational log timestamps in UTC.
• Note the current broker-server offset and daylight-saving behavior.
• Test EA session and news filters after every time change.
• Confirm platform clock synchronization on the VPS.
• Never infer trading-rule time from the VPS location alone.

Eligibility, Verification, Payment, and Payout Context

Access patterns cannot be considered in isolation from eligibility. Before payment, confirm that FTMO currently accepts traders resident in your jurisdiction and that you can complete the required identity and payment steps using accurate information. Do not use another person's card, address, document, or payment account to work around a restriction. A payment name that conflicts with the verified trader can create avoidable questions, even where a particular payment method technically processes. If a legitimate reason requires a different payer, obtain a current written answer from official Support rather than relying on a forum.

Plan the full lifecycle before the first trade. Check available payment methods, refund conditions if applicable, payout options, conversion costs, receiving-bank requirements, and whether a payment intermediary asks for extra verification. Payout eligibility and timing are governed by current official terms, not by a trader's anecdote. Keep invoices, receipts, confirmation emails, and payout statements. Your local tax, reporting, consumer, business-registration, and foreign-exchange obligations depend on where you live and your circumstances; a qualified local professional is the appropriate source for that advice. local-currency payout considerations can help you prepare questions, not replace legal or tax guidance.

Avoid treating a payout as a reason to improvise an identity change. If your bank closes, your legal name changes, you relocate, or a payment method fails, gather the relevant official evidence and ask what process applies. Do not substitute a relative's bank details or create inconsistent profile information as a shortcut. A legitimate administrative change is easier to resolve when it is reported promptly and supported by documents requested through official channels. Financial records should match the truthful account narrative that also explains your access and residency.

• Confirm residence eligibility using current official sources.
• Use truthful personal, billing, and verification information.
• Retain payment receipts and official payout confirmations.
• Check receiving-bank and currency-conversion requirements in advance.
• Consult a qualified local adviser about reporting and tax obligations.

Respond Calmly if FTMO Requests Information

A compliance question is not an invitation to speculate, accuse a system, or delete evidence. Read the request carefully, verify that the message comes through an official channel, and respond by the stated deadline. Answer only what is asked, but answer completely and truthfully. A useful response might identify your usual residence, confirm that you personally control the account, explain that the EA runs on your named VPS, list a travel date, and attach requested records. If you do not understand a question, ask for clarification. Preserve the original message and your response.

Do not create new network tricks while a review is pending. Do not reset logs, alter timestamps, use a relative's connection, or let a vendor enter the account to "fix" the appearance of activity. Those actions can turn a straightforward explanation into a genuine integrity issue. Temporarily pause the EA if instructed or if you cannot ensure it remains within the rules, but do not assume a pause resolves a contractual question. Explain system facts, including any accidental security incident. If unauthorized access occurred, change credentials immediately, document the incident, and follow official support instructions.

A good response is chronological and restrained. State what changed, when it changed, why it changed, and what you did to maintain personal control. Attach only relevant invoices, screenshots, or logs through the requested secure route. Avoid sending passwords, full recovery codes, or unrelated personal records. If a previous statement was mistaken, correct it plainly rather than compounding it. Compliance staff need usable facts, while the trader needs a durable record of what was disclosed. Professional communication often resolves uncertainty better than a lengthy argument about a supposedly suspicious IP.

• Verify the sender through official FTMO contact channels.
• Preserve the request, attachments, and your complete response.
• Provide accurate facts with dated supporting records when requested.
• Pause or change trading only in line with official instruction.
• Do not delete logs, fabricate explanations, or recruit third parties.

Security Failures Can Look Like Compliance Problems

Many suspicious-looking events begin as ordinary security failures. A leaked password can create an unfamiliar login. A compromised email can change recovery details. A copied remote-desktop credential can allow a stranger to inspect the terminal. A pirated EA can contain malicious code or send data to an unknown server. Prevention is therefore part of compliance. Use unique credentials, multi-factor authentication where available, reputable software sources, current operating-system patches, and restricted remote access. Do not store account passwords in plain-text parameter files, screenshots, chat messages, or a shared team workspace.

Create an incident plan before one is needed. Know how to disconnect the terminal, change client-area and email passwords, revoke VPS access, collect logs, and contact official Support. Test a kill switch on a non-live environment so that an outage does not tempt you to grant hurried access to a third party. Separate the EA's trading parameters from credentials, and back up configuration securely. The risk framework in EA stop-loss protection complements access security because an unauthorized or malfunctioning system can cause financial-rule breaches as well as identity concerns.

After an incident, distinguish containment from investigation. First stop unauthorized access and protect the account. Then preserve the available evidence: relevant login alerts, provider notices, system logs, and the time you changed credentials. Do not reinstall or wipe the server before saving what is needed to understand the event, unless immediate security advice requires it. Review whether an EA license key, API connection, alerting bot, or old remote user contributed to the problem. A measured response supports both account security and a credible explanation.

• Use unique passwords for email, FTMO, VPS, and platform accounts.
• Enable multi-factor authentication wherever the service supports it.
• Install EAs only from sources you have independently vetted.
• Keep a tested procedure to stop trading during an incident.
• Change all relevant credentials after suspected compromise.

Common Myths That Produce Bad Decisions

Myth one is that a trader must use one IP forever. Real life includes dynamic addresses, travel, device replacement, and mobile data. The safer standard is consistent ownership and an honest explanation. Myth two is that a VPS is prohibited because it has a different address from a home computer. A VPS can be a normal way to host an EA, subject to current terms and appropriate use. Myth three is that a VPN or proxy solves an access problem. It may instead obscure facts, increase security risk, conflict with local access restrictions, or make a legitimate pattern harder to explain. Do not use network tools to manufacture a preferred appearance.

Another myth is that changing trade timing or adding arbitrary variation makes a copied strategy acceptable. Whether conduct is permitted depends on the current agreement and actual control, not on cosmetic changes. Finally, no blog can guarantee a particular outcome or describe an undisclosed detection threshold. The correct process is to read official rules, preserve evidence, and obtain written clarification for your exact setup. A strong EA operation is boring: one accountable trader, secure systems, documented changes, conservative risk, and no need to conceal who did what.

Be cautious of anyone selling a "safe VPS country," a "clean IP," or an alleged whitelist. Those products encourage traders to optimize for an imagined detector rather than for eligibility and honest operation. They may also create new problems when many unrelated users share the same promoted service. Select hosting based on reliability, security, and lawful practical use. Select an EA based on evidence, risk behavior, and permitted strategy characteristics. If an offer's main value is hiding the trader or masking coordination, it is incompatible with the operating standard described in this guide.

• Reject claims of a secret safe IP count or guaranteed workaround.
• Do not use VPNs, proxies, or randomization to misrepresent control.
• Treat a VPS as reliability infrastructure, not identity infrastructure.
• Base decisions on current official terms rather than social-media anecdotes.
• Choose transparency over technical theatrics when a change is necessary.

A Decision Framework for Any Access Change

Before changing a device, network, country, VPS, or EA operator, run a four-part decision test. First, is the change necessary for security, reliability, travel, or normal personal use? Second, will the verified trader remain the sole person controlling credentials and trade decisions? Third, is the change consistent with current eligibility and written terms? Fourth, could you explain it with contemporaneous records in two clear sentences? If any answer is no or uncertain, pause and ask official Support before continuing. This test is more durable than memorizing rumors about locations or IP addresses.

Apply the same test to vendors. A service that sells code and gives installation instructions may be distinct from a service that requires credentials, logs into a terminal, selects trades, or promises to pass an account. The latter arrangement deserves far more caution and may conflict with applicable rules. Also test the operational effect of a change on risk: a new VPS may alter latency, terminal behavior, server time, spreads, or execution. Use a demo or permitted testing method before a live migration. backtesting versus live EA trading explains why historical results alone cannot validate infrastructure changes.

• State the business reason for the proposed change in writing.
• Confirm sole control remains with the verified account holder.
• Check current terms and country eligibility before proceeding.
• Create a dated record and retain supplier notifications.
• Test technical consequences without putting the account at risk.

Conclusion: Make Your EA Setup Easy to Explain

FTMO IP detection rules for EA traders should lead to disciplined operations, not fear of ordinary technology. A different address can result from a legitimate VPS, travel, a new ISP, a phone connection, or remote monitoring. None of those facts replaces the central requirements of truthful eligibility, personal account control, security, and compliance with the current agreement. The more your workflow depends on undisclosed helpers, borrowed identities, opaque signal distribution, or tools intended to hide a pattern, the less defensible it becomes.

Run an EA from infrastructure you own or administer, retain a concise record of changes, use UTC and broker-server time carefully, secure every credential, and ask official Support before unusual circumstances become urgent. Verify payment and payout logistics honestly and handle local obligations with suitable professional advice. Most importantly, never design an automated workflow around evading review. Design it so that, if asked, you can show who controlled the account, where the terminal ran, why an address changed, and how the strategy stayed within the rules. That is the sustainable standard for an evaluation and for any later funded stage.

• Operate only accounts you personally own and control.
• Use transparent, secure VPS and remote-access procedures.
• Maintain dated access, configuration, and support records.
• Verify time-sensitive rules directly with official FTMO materials.
• Escalate uncertainty to Support before making an unusual change.