How to Pass FundedNext Challenge with Trading Bots

Build the bot around a pass plan, not a profit fantasy

A bot passes an evaluation by avoiding disqualifying losses while accumulating enough valid profit, not by pursuing the fastest possible percentage return. Write a one-page pass plan before opening the account. It should identify the exact programme, platform, symbols, expected number of trades per week, maximum simultaneous positions, expected win rate, average win and loss, internal daily stop, internal account stop, news behaviour, and what causes a manual pause. If the plan cannot explain how the bot loses, it cannot explain how it survives. The useful question is not “can this robot make ten percent?” but “can this implementation tolerate a normal losing month without touching a firm boundary?”

Use conservative arithmetic. Suppose a strategy has a 45% win rate, an average winner of 1.4R, and an average loser of 1R. Its expectancy is 0.45 × 1.4 minus 0.55 × 1, or 0.08R per trade. That is positive but modest. At 0.25% risk per trade, the expected gain is roughly 0.02% per trade before execution costs. A challenge target may require time, a favourable sample, or more than one attempt. Raising risk to 1% makes the curve appear faster, but five routine losses cost about 5% before spread, commission, slippage, or correlated trades. A controlled plan accepts the slower path.

Separate a “target pace” from a “risk budget.” A target pace says what the system might reasonably earn in a week; it never authorises additional risk after a quiet week. A risk budget says exactly what can be lost today and over the account’s life. If results are below pace, leave the bot unchanged unless a pre-defined review condition occurs. Chasing a calendar deadline is how traders turn a sound mean-reversion or trend bot into an oversized gamble. For wider strategy selection, see algorithmic strategies for prop firm challenges.

• Write the account programme and platform version at the top of the plan.
• State risk per idea, not merely lot size.
• Define a daily stop and total stop below the official boundaries.
• List the only conditions that permit changing settings.

Verify FundedNext rules on the exact account before automation

Treat rule research as a technical requirement. Open the official FundedNext site and the agreement for the precise challenge, account size, platform, and date of purchase. Identify how daily loss and maximum loss are measured: balance, equity, closed profit and loss, floating profit and loss, starting balance, start-of-day balance, or a high-water reference can create very different exposure. Check reset time, permitted instruments, leverage, minimum activity, holding rules, news and weekend treatment, use of EAs, third-party access, copy trading, prohibited execution methods, account merging, scaling, refunds, and the funded-stage terms. Do not infer one programme’s treatment from another.

Translate every answer into a bot setting or a human procedure. If loss is equity based, the bot must include floating loss in its kill switch. If a daily reset occurs at server midnight, your journal must calculate the same window rather than your local midnight. If high-impact-event trading is restricted, the filter must close or block entries relative to the firm’s specified clock. If support says a method is permitted, retain the ticket and ask a precise question: name the programme, EA, symbols, order style, and whether the behaviour is allowed in both evaluation and funded stages. Vague questions invite vague reassurance.

Policies evolve, and a genuine bot user should welcome clarity rather than hunt for loopholes. FundedNext EA rules and settings provides a complementary compatibility framework, while automation rules and restrictions explains why legal software is not automatically permitted contractual conduct. If a current official source conflicts with this guide or an old screenshot, the official source controls.

Choose a strategy whose failure mode is acceptable

The best challenge bot is rarely the one with the highest historical return. It is the one whose worst plausible sequence fits comfortably inside the account’s internal loss budget. Trend systems can suffer clusters of small losses in ranges. Mean-reversion systems can endure a violent directional break. Breakout systems can be hurt by false moves and wide spreads. Grid, recovery, and martingale designs may show smooth history until a rare move creates concentrated exposure. Identify the failure mode in plain language, then decide whether the official rules and your own capital tolerance can carry it. A smooth equity curve with no hard stop is not safety; it may be unreported tail risk.

Ask for data that exposes adverse behaviour. Review a sufficiently long backtest with realistic commissions and variable spread, then a forward test across different market regimes. Count the largest consecutive losses, deepest equity drawdown, longest recovery, average holding time, and maximum open positions. Inspect individual trades around central-bank announcements, holiday liquidity, rollovers, and gaps. A strategy that trades only one liquid session may be easier to supervise than a multi-symbol robot opening positions throughout the day. A low-frequency bot can also help with consistency, provided the current programme permits its timing and meets any activity requirement.

Avoid buying a black box because it displays a high monthly percentage. A seller should be able to explain entry logic at an appropriate level, the intended market, stop-loss design, position-sizing method, data assumptions, settings, licence controls, and known weaknesses. The assessment approach in reviewing FundedNext bots is more useful than a ranking. No bot should be accepted simply because it passed once: one pass can be luck, unusually favourable spreads, or a risk level you would not repeat.

Calculate a protective risk budget

Start from the official loss limit, then deliberately leave unused room. If the published daily loss allowance were D percent, an internal stop might be only 40% to 60% of D, depending on the bot’s execution sensitivity. If the total allowance were M percent, an internal account stop could be 50% to 70% of M. These are planning examples, not claims about FundedNext limits or universal settings. The unused difference pays for slippage, spread expansion, commissions, swap, delayed closure, a platform disconnect, calculation mismatch, and human error. A firm limit is a disqualification line, never a sensible operating target.

Calculate exposure at portfolio level. If EURUSD and GBPUSD each risk 0.30% with stops, they may behave like more than 0.60% when a single dollar event drives both. Two bots on gold and a dollar index-related product can also be highly connected. Set a maximum combined risk by currency, asset class, and direction. Include pending orders because several stop entries can activate in a rapid move. Define risk as the loss at the actual stop plus estimated costs, not the margin required to open the trade. Margin is borrowing capacity; it is not a loss-control number.

For a worked framework, imagine a 100,000 nominal account and an internal daily stop of 1,000 account-currency units. Four uncorrelated setups each risking 200 leave 200 for costs and imperfect fills. Two correlated setups might instead receive 150 each, leaving 700 unused. If the EA cannot calculate monetary risk because a symbol’s tick value, contract size, or account currency differs, do not enable it. Use the EA drawdown and lot-size calculator as a cross-check, then compare its result with the terminal’s own contract specifications.

Convert lots into real stop-loss exposure

A fixed lot is not fixed risk. On forex, pip value depends on pair, contract size, account currency, and conversion rate. On indices, metals, energy, and CFDs, the tick value and point definition can differ by symbol and platform. A bot configured with 0.10 lots may risk a modest amount on one instrument and far more on another. Measure risk with the platform’s contract specification: monetary risk equals stop distance in ticks multiplied by tick value multiplied by volume, plus a cost allowance. Test this calculation in a demo terminal using the same broker feed and account currency where possible.

Build a small “risk unit test” into launch preparation. Set a hypothetical entry, stop, and volume for every permitted symbol. Record the terminal’s displayed profit or loss at the stop. Compare it with the bot log and spreadsheet result. Then repeat with a different account currency and with a spread widened beyond normal conditions. An EA that uses a generic pip multiplier may misread gold, JPY pairs, indices, or suffix symbols. The test is dull, but it catches the kind of configuration error that can consume a daily limit in seconds.

Use dynamic sizing only if its inputs are understood. A percentage-of-equity rule may increase volume after a winning streak and reduce it after losses. That can be appropriate, but it interacts with any equity-based firm measurement and with open floating profit. A fixed-risk rule is often easier to audit during a challenge. Whichever model you use, cap volume independently. The detailed principles in the EA lot-sizing guide help distinguish a valid stop-based calculation from a comforting but meaningless lot number.

Map UTC, server time, and trading sessions correctly

Time is an operational risk, not a cosmetic chart label. The economic calendar may display local time or UTC, while FundedNext’s platform can use broker server time that changes with daylight-saving conventions. Your VPS may use a third time zone. The bot may interpret news files in UTC but session filters in server time. Create a table with four columns: event time in UTC, server time, your local time, and the bot’s configured time. Recheck it when daylight saving begins or ends in relevant regions, when the broker changes server time, and after a terminal update. Never assume “New York open” has the same server hour year-round.

For a news rule, define the protection window in the format required by current official terms. For example, if an event is at 13:30 UTC and the required avoidance period is known, the bot must stop new entries at the corresponding server time, decide what to do with pending orders, and manage existing trades according to the policy. Do not invent a calendar flag from an unverified website. Confirm source reliability, currency mapping, impact classification, update cadence, and what happens if the feed fails. A fail-safe configuration blocks entries when the calendar is unavailable rather than silently trading.

Session filters need similar care. A London-breakout bot should prove that its server-hour window still maps to the intended liquid session. A rollover filter should use actual broker conditions, not a generic midnight. Record each change in the journal with UTC timestamp. The practical issues of event execution, spread, and gaps are covered in this guide to gaps, slippage, and spreads.

Treat news filters as a layered control

A calendar toggle alone is not a news plan. Decide separately whether the bot may open trades before an event, leave existing positions open, modify stops, trigger pending orders, re-enter after an exit, or resume immediately afterward. Each decision should reflect the current FundedNext rules and the strategy’s tested behaviour. A trend bot might tolerate a managed position through an event but prohibit new entries; a short-term mean-reversion system may need a wider exclusion period. Do not use a rule-compliant setting as an excuse to trade a method whose live slippage has never been tested.

Test the filter by replaying or observing several historical high-impact releases. Verify that the calendar event is correctly classified, the bot converts time correctly, pending orders cancel, and the log reports a clear reason for blocked entry. Also test missing internet, stale calendar data, and a VPS reboot. A system that resumes one hour early after a time-zone error is not protected. Keep manual control available, but do not manually override the filter because a headline “looks predictable.” That turns a systematic account into an unrecorded discretionary experiment.

News windows can differ by programme or stage, so re-verify after passing. Keep screenshots of settings and the relevant official wording. For a broader explanation of how events alter algorithmic execution, read news trading with a forex EA. The right outcome during an uncertain announcement is often no trade. Missing an opportunity costs nothing against a daily breach.

Build execution safeguards beyond the strategy logic

A profitable entry model can fail because of execution. Add hard limits for maximum spread, maximum slippage where the platform supports it, maximum number of entries per symbol, maximum total positions, maximum order attempts, and a minimum delay between new orders. Prevent duplicate trading when a terminal restarts or two charts load the same EA. Assign unique magic numbers and ensure one installation owns each symbol-timeframe combination. Check whether the bot uses market orders, stop orders, limit orders, partial fills, or modifications, then verify that each behaviour is acceptable under current terms.

Use a circuit breaker based on account state. It should block new trades once daily realised plus floating loss reaches the internal daily stop, and it should remain locked until the correct reset condition. A second breaker should stop the account at the internal maximum drawdown. Add an unusual-condition brake: if spread exceeds the tested ceiling, price gaps beyond a threshold, trade context errors repeat, or the bot’s calculated risk disagrees with the platform, it stops and alerts you. A safe bot fails closed. It does not keep retrying because an order was rejected.

Run a stress checklist before launch. Simulate a rejected order, an internet interruption, a widened spread, a partially filled order, and a terminal restart with a position open. Inspect the log and account history afterward. The safeguards should be visible in both, not merely promised by a vendor. Understanding drawdown rules is useful context, but the bot’s internal calculation remains your responsibility.

Forward-test the exact configuration before purchase

Backtests find ideas; they do not validate a challenge deployment. Forward-test the same compiled EA, settings file, symbols, chart periods, broker feed, VPS location, and account currency intended for the evaluation. A demo from another broker may have different symbol names, spread patterns, commission, leverage, stop levels, swaps, trading hours, and execution. At minimum, gather enough live observations to verify that orders, stops, risk sizing, session windows, and filters act as designed. The purpose is not to prove future profit with a tiny sample. It is to discover implementation errors before they become paid errors.

Keep the test small and immutable. Version the EA file, hash or label the settings file, and record every parameter. Capture account statement exports, journal notes, terminal logs, screenshots of contract specifications, and VPS clock settings. When a trade differs from expectation, classify it: market movement, spread, slippage, calculation, timing, platform, or operator error. Fix one cause, retest, and do not quietly change five settings until the history is flattering. That practice makes the eventual challenge performance interpretable.

Compare live and test outcomes honestly. If the backtest assumed a two-pip spread but live spread repeatedly exceeds it at entries, update the model or avoid the session. If the live bot takes fewer trades because a valid spread filter blocks them, do not disable the filter simply to reproduce a sales curve. backtesting versus live EA trading explains why these differences are normal and why they must be priced into the pass plan.

Deploy a VPS as production infrastructure

A VPS improves availability; it does not excuse neglect. Choose a location with stable connectivity and reasonable latency to the platform infrastructure, but do not build a prohibited latency-dependent method. Confirm operating system updates, terminal compatibility, memory, disk space, restart policy, two-factor authentication, and backup access before a market session. Use a unique strong password, restrict remote-desktop access, and never share FundedNext credentials or a VPS login with a seller, signal group, or passing service. Account ownership and access rules should be verified directly with current official terms.

Install only what is needed. One clean terminal profile per account reduces accidental cross-account trading. Disable automatic chart templates that attach the wrong EA. Ensure the platform starts after reboot, the correct account is logged in, auto-trading status is visibly checked, and the EA’s licence survives restart. Configure alerts for VPS offline status, terminal disconnection, order errors, and internal stop activation. Test a planned reboot during closed or low-risk periods, then verify that no duplicate order or unprotected trade appears.

Maintain an access record: VPS provider, region, IP where relevant, device used for remote access, change date, and reason. When travelling, do not improvise with shared café computers or let another person “watch” the account using your login. The account-access considerations in FundedNext IP and VPS guidance are especially relevant. Ask support in writing before a material access change if current policy leaves doubt.

Use a daily operating routine instead of constant interference

Automation still needs a human operator. Before the active session, inspect account equity, open and pending orders, internal daily loss remaining, economic calendar status, VPS connection, terminal journal, spread conditions, and whether the bot is on the intended account. Confirm the server date against UTC. During the session, monitor alerts rather than every tick. Intervene only for pre-defined conditions such as a rule conflict, malfunction, duplicate order, abnormal spread, news-feed failure, loss breaker, or account-access issue. Watching each fluctuation encourages discretionary meddling without improving safety.

After the session, export trades and reconcile them with the bot log. Record realised and floating profit or loss, maximum open risk, spread at entry if available, blocked signals, errors, manual actions, and remaining internal budget. Note whether performance was within the strategy’s expected distribution rather than labelling every red day as failure. A routine journal reveals if a bot has changed behaviour after a platform update or if costs are drifting. It also gives you evidence for a factual support query.

Create a stop-work rule. For example, pause new trading after a configuration change, unexplained trade, broker-symbol change, calendar failure, two consecutive execution anomalies, or internal daily stop. Restart only after documenting the cause and completing a check. This is more professional than “letting it recover.” an EA trading journal for funded performance gives a useful structure for this record.

Handle drawdown and losing streaks without revenge optimisation

Every legitimate strategy has a losing sequence. Before trading, use simulation or historical sequences to estimate a plausible run of losses at the chosen risk. If six losses in a row are possible and each trade risks 0.35%, the direct loss is 2.1%, before costs or correlation. Decide in advance whether the bot continues, reduces risk after a threshold, or pauses for diagnosis. The answer should arise from testing, not panic. A system that has never been tested through drawdown cannot be trusted merely because its first week is green.

Do not double lot size to recover, remove stops, add a second untested robot, widen a recovery grid, or override a session filter because the challenge is behind schedule. Those actions change the distribution at the worst possible moment. A temporary reduction from 0.30% to 0.15% risk can be reasonable if it was planned and does not distort strategy operation; equally, a pause may be correct after unusual execution. What is not reasonable is silently changing parameters until the account either recovers or breaches without leaving an audit trail.

Use a three-question review after an adverse day: did the bot follow the documented rules, did market and execution conditions remain within tested assumptions, and did an external rule or platform condition change? If all are yes, the loss may simply be normal variance. If one is no, stop and correct it. The wider account-protection framework in using EA stop losses to protect a funded account remains valuable after the evaluation too.

Avoid copied signals, prohibited conduct, and account ambiguity

Permitted automation is not a licence to outsource responsibility. Do not give credentials to someone who claims they will pass the account, run a hidden copier without written confirmation, or subscribe to a mass signal whose identical timing could raise compliance concerns. Do not attempt to exploit pricing delays, demo-feed errors, platform vulnerabilities, or infrastructure latency. A challenge account is governed by its agreement, and conduct that appears clever in a marketing video can lead to review, denial, or closure. Read the live definition of prohibited practices rather than relying on labels such as “EA safe.”

If you use your own algorithm across accounts, keep control of code, settings, access, and audit logs. Similar trades can arise naturally from the same owner running the same method, but the firm’s current policy may have conditions around copying, group trading, IPs, or account ownership. Be transparent when asked. A clean explanation consists of dated settings, account ownership, VPS records, and logs, not an invented story after the fact. The discussion in shared EA signals and IP addresses explains why operational patterns matter.

Avoid a seller that asks for a login, promises a guaranteed pass, conceals its method, or tells you to evade rules. Those are commercial and compliance warnings. You remain responsible for every order in the account. A bot provider can be a software vendor, but it should not become an undisclosed account manager.

Plan payment, eligibility, and payout operations globally

Before paying for a FundedNext Challenge, confirm directly that residents of your country are eligible, that your identification documents can be verified, and that the payment route is available to you. Terms can exclude or limit jurisdictions and payment processors can impose their own checks. Use payment details in your own name where required, retain invoices and receipts, and understand currency conversion, card fees, transfer fees, and refund conditions before purchase. A low advertised fee can cost more after conversion or a rejected payment, particularly when your local currency differs from the account denomination.

Passing a challenge does not remove operational checks. Before relying on a payout, read the current official payout schedule, profit split, minimum conditions, identity process, payment-provider availability, and tax documentation requirements. Do not promise clients or family that a payout will arrive on a particular date or in a precise local-currency amount. Exchange rates, intermediary fees, holidays, compliance reviews, and local banking rules can alter receipt. Maintain a ledger in both account currency and local currency with UTC dates, invoices, payouts, conversions, and fees.

Tax treatment varies enormously. Income from trading-related arrangements may be treated differently depending on residence, business status, payment type, and local law. Seek advice from a qualified local accountant or adviser rather than using an online trading forum as authority. the local-currency payout guide can help frame the practical questions, but it is not personal tax or legal advice.

Move to the funded stage with less risk, not more

A passed challenge is evidence of one controlled sample, not permission to increase risk. Re-read the funded agreement because news rules, consistency expectations, payout conditions, drawdown calculations, leverage, scaling, and prohibited methods can differ from evaluation. Update the rule matrix and obtain written clarity before continuing an uncertain strategy. Preserve the challenge configuration for several weeks unless there is a documented technical need to change it. The urge to “make the fee back quickly” can destroy the account that took discipline to earn.

Set a funded-stage objective based on longevity: protect the account, establish a clean statement, and seek a first valid payout under current terms. Many traders benefit from reducing per-trade risk below the challenge level until actual funded execution is observed. Keep withdrawals, buffer requirements, and any scaling thresholds separate in the plan. A withdrawal that leaves too little equity cushion can make normal variance dangerous; conversely, hoarding profit without a reason may not suit personal cash-flow needs. Use written scenarios rather than emotion.

Review performance monthly by distribution, not only return. Compare trade count, expectancy, costs, maximum adverse excursion, drawdown, time-of-day, and rule-filter activity to forward-test expectations. If the edge deteriorates, reduce or stop exposure and investigate. Long-term success is operational reliability plus controlled risk, not a screenshot of a passed dashboard. scaling multiple funded accounts with an EA is relevant only after one account is stable and current terms permit the arrangement.

Diagnose bot performance with a decision framework

A challenge creates pressure to make a change after every disappointing result. Replace that impulse with a decision framework. First classify the observation as an implementation fault, a rule-compliance risk, a market-condition change, or ordinary statistical variation. An implementation fault includes an incorrect lot calculation, duplicate order, clock mismatch, or filter failure and requires an immediate pause. A compliance risk includes a newly published restriction or an unclear support answer and also requires a pause until resolved. A market-condition change may warrant research, but it is not automatically proof that the strategy has failed. Ordinary variation means the bot acted as tested and the outcome falls within its expected losing distribution.

Set numerical review triggers before launch. For instance, investigate, rather than instantly edit, if live average spread is materially above test assumptions, if average slippage breaches the tested range over a meaningful sample, if trade frequency changes sharply without a known session reason, or if losses exceed a pre-modelled percentile. Choose thresholds from the strategy’s data; do not manufacture them after a drawdown. Compare like with like. A week containing holidays, a major rate decision, and thin liquidity should not be compared mechanically with a normal week of liquid trading.

When a trigger fires, freeze the current evidence. Export the statement, terminal journal, EA log, settings, news-calendar records, and server-time record. Reproduce the issue on a non-challenge environment if possible. Change one variable only, document the rationale, and forward-test again. This process protects both the account and your ability to learn. It also avoids the common error of optimising parameters to a handful of losing challenge trades, which produces a bot tailored to noise rather than an edge.

• Pause immediately for an implementation fault or a possible rules conflict.
• Use pre-defined thresholds for investigation, not feelings about a red day.
• Export evidence before changing a parameter or restarting the terminal.
• Modify one variable, then verify it outside the active challenge.

Design an emergency response that works under stress

An emergency plan is a written sequence for the moment when normal controls fail. Put the sequence where you can access it without logging into a compromised computer. It should include how to disable auto-trading, remove pending orders, close positions when appropriate, confirm closure in account history, disconnect the VPS, change credentials, and contact official support. Include account number references safely, the official support route, VPS provider support, and a local record of current exposure. Do not wait to write this plan until a surprise central-bank move, an unauthorised login alert, or a platform outage has made calm thinking difficult.

Define specific emergency triggers. Examples include an order not generated by your approved bot, a position size above the cap, a loss breaker that fails to lock, a discrepancy between dashboard and terminal, repeated trade-context errors, a compromised credential, or a current rule change affecting an open strategy. The first priority is risk containment, not discovering whose software is at fault. Disable new entries, preserve logs and screenshots with UTC timestamps, and avoid repeatedly reconnecting or sending fresh orders. Once exposure is controlled, compare terminal history with the official dashboard and make a concise, factual support request if needed.

Plan for ordinary human absence too. If you will travel, lose internet, face a local power outage, or be unavailable during a session, the bot must remain safe without improvisation. A VPS alert to a secure phone can help, but alerts are not a substitute for limits. Tell no unauthorised person to operate the account on your behalf. If your situation changes in a way that affects location, device, payment, identity verification, or account access, consult current official terms or support before it becomes an emergency.

• Keep a tested procedure to disable automation and verify all orders are closed or controlled.
• Store logs, settings, and screenshots after an anomaly before troubleshooting.
• Use official support channels only; do not share credentials in a chat group.
• Re-enable the bot only after the cause and the account state are documented.

Complete FundedNext bot launch checklist

The final checklist exists to turn research into evidence. Complete it before the first live order, after every major platform or EA update, and when daylight saving or account terms change. If one item cannot be confirmed, keep automated trading disabled. This is not excessive caution: a bot can place many orders faster than a human can correct one assumption. A checklist separates a repeatable operating process from confidence based on a previous pass.

Keep the completed checklist with dated screenshots, exports, and support replies. Include the EA version and parameter file, because a harmless-looking change to risk percentage, symbol suffix, time filter, or magic number can alter the strategy completely. The person responsible for the account should be able to reconstruct why any order was allowed. That accountability is as important as the entry algorithm.

The most damaging mistake is selecting settings from an advertisement instead of from your own risk budget. A vendor may have used a large account, a different broker feed, an older rule set, an unusually favourable period, or a risk level that gives a high chance of failure. The second mistake is treating a maximum loss figure as available trading capital. The third is assuming that an EA label means the same thing as permitted automated conduct. These errors share a cause: a trader imports confidence from someone else while retaining all contractual and financial responsibility personally.

Other fragile practices are subtler. Traders run two robots whose open risk overlaps, forget a pending order after a news filter, let a VPS restart attach an EA twice, use local time for a server reset, or continue after the bot reports an order error. They may also confuse balance with equity, omit commission from a risk calculation, or mistake a profitable floating trade for locked-in room. Each issue is manageable if discovered in testing. Combined, they can create a breach that looks inexplicable only because no one maintained a complete exposure picture.

Finally, do not make the challenge a test laboratory for a newly purchased system. The fee does not turn untested automation into a strategy. Build evidence first, begin at conservative size, and accept that stopping is sometimes the successful decision. Risk-management lessons from forex robots reinforces the central point: durable automation is defined by what it refuses to do when conditions are uncertain, not by how aggressively it trades when conditions look easy. The direct answer remains simple. You can pursue a FundedNext Challenge with a trading bot when current official terms allow your use, the bot is independently tested, its worst plausible loss is far below official limits, and you actively operate it. If any of those conditions is missing, delay the challenge rather than gambling the fee. Patience is an active risk control, especially when live conditions are inconsistent with the tested environment.

• Read and save current official terms for the exact programme and funded stage.
• Confirm country eligibility, identity requirements, payment route, and payout practicalities.
• Record broker server time, UTC offset, reset time, and daylight-saving procedure.
• Verify EA permission, strategy restrictions, third-party access, copying, news, and holding rules.
• Forward-test the identical EA build, settings, symbols, VPS, and account currency.
• Calculate each symbol’s monetary stop loss and set independent volume caps.
• Set internal daily and total stops safely inside official boundaries.
• Cap correlated exposure, pending-order exposure, positions, spread, and retry attempts.
• Test calendar failure, terminal restart, disconnection, partial fill, and duplicate-order handling.
• Enable VPS, terminal, error, and loss-breaker alerts; secure credentials and access.
• Create the daily pre-flight, reconciliation, pause, and restart journal procedures.
• Do not start until every unresolved rule question has a current official answer.
• Never copy advertised lots without recalculating monetary risk on your own account.
• Count floating, pending, and correlated exposure before approving new entries.
• Investigate every execution error before allowing the next signal.
• Treat a challenge as a controlled deployment, not a software beta test.