Algorithmic trading platform audit: pass or fail criteria

Then live execution introduces slippage, rejected orders, delayed stop-losses, frozen charts, or a spread wide enough to erase the strategy’s edge.

That is the real audit problem. An algorithmic trading platform is not just a terminal connected to a broker. It is a chain of software, APIs, market data, execution logic, risk controls, hosting, and operational procedures. A failure in any one layer can turn automated forex trading software into an expensive source of false confidence.

I audit these systems from the retail trader’s side. I am less interested in a platform’s feature list than in what happens when liquidity disappears, the VPS connection drops, a broker widens spreads, or an algorithm behaves differently from its backtest. The pass or fail decision should be based on those conditions, not on a polished demonstration during a quiet session.

Regulatory compliance is part of the platform, not paperwork around it

The first mistake is treating regulation as a broker-only issue. For automated trading, compliance is also an engineering question. The platform must control what the algorithm can send, record what it sent, and stop the system when market or infrastructure conditions move outside defined limits.

The regulatory framework differs by jurisdiction, but the direction is consistent: firms operating algorithmic systems need documented controls, traceability, resilience testing, and emergency intervention.

In the European Union, the Digital Operational Resilience Act, or DORA, took effect in January 2025. Algorithmic trading platforms are treated as critical ICT systems, which brings operational resilience into the same control framework as other regulated technology. DORA does not simply erase MiFID II obligations. The two regimes operate in parallel, with DORA covering broader ICT risk and MiFID II RTS 6 continuing to address algorithmic trading controls.

That distinction matters when reviewing a broker or technology provider. A platform can advertise compliance with one framework while leaving gaps in another. A serious audit should examine whether the provider can demonstrate:

• Pre-trade controls that restrict order size, frequency, leverage, and notional exposure.
• Post-trade records that preserve the order, amendment, cancellation, and execution history.
• A documented kill-switch with a defined activation time.
• Version control for Expert Advisors, Python services, APIs, and plug-ins.
• Business continuity procedures for data loss, connectivity failures, and system outages.
• Regular testing of disaster recovery rather than a policy document that has never been exercised.
• Clear responsibility between the broker, platform vendor, VPS provider, and strategy developer.

In April 2026, the Dutch Authority for the Financial Markets clarified that investment firms no longer need to include Articles 14 and 18 of RTS 6 in annual self-assessments because those IT risk and business continuity topics are covered under DORA. That does not mean those risks disappear. It means the documentation architecture changes. For a trader evaluating a regulated provider, the practical question remains the same: how is operational resilience tested, and what evidence exists when something fails?

India’s retail framework is also moving toward tighter controls. From April 1, 2026, the SEBI framework requires two-factor authentication, unique Algo-IDs, and audit trails for retail algorithmic trading. Brokers that do not comply are barred from onboarding new API clients. The NSE system audit guidelines require trading members to address 38 specific checks covering areas such as online risk management and version compliance.

For retail traders, these rules have an important side effect. They make it harder for a provider to treat API access as an informal add-on. If the platform cannot identify which strategy generated an order, preserve the relevant logs, or restrict the API session with proper authentication, it is not ready for serious automated execution.

A platform passes the compliance test only when its controls work under stress, not when its documentation looks complete.

Latency and throughput: use the right benchmark for the strategy

Latency is one of the most abused terms in automated trading. Vendors publish impressive figures that may describe only one part of the route from signal to fill. A server can process an instruction quickly while the overall order still waits on network travel, broker risk checks, liquidity-provider routing, and execution.

The relevant measurement is end-to-end latency:

1. The strategy receives or generates a signal.

2. The platform validates the order.

3. The API or terminal sends the order to the broker.

4. The broker accepts and routes the order.

5. The market returns an execution or rejection.

6. The platform records the result and updates the strategy state.

A low figure at step two does not guarantee a low figure at step six. This is where spreads and slippage enter the audit. A scalping Expert Advisor that earns a few points per trade can be profitable in a backtest and unworkable in live conditions if the round-trip delay adds even a small amount of adverse execution.

Institutional performance standards provide useful reference points, but they must not be copied blindly into a retail forex evaluation. Technical audits for institutional trading systems may define passing order-submission latency as below 1 millisecond, with a mean below 500 microseconds. Throughput may need to exceed 100,000 orders per second. Those figures are relevant to high-frequency systems, but they are not a sensible requirement for a swing-trading EA that opens two positions per week.

The audit should match the benchmark to the trading logic.

I do not accept a platform’s average latency figure without the distribution behind it. The mean can look attractive while the worst 1% of orders arrive too late. Request at least median, 95th percentile, and maximum observed latency across normal and volatile sessions.

The same applies to slippage. A realistic test should separate:

• Positive slippage and negative slippage.
• Market orders and pending orders.
• Major currency pairs and less liquid pairs.
• Normal spreads and spread widening.
• European, US, and rollover trading hours.
• High-impact news windows.
• Stop-loss execution and ordinary entries.

If the vendor presents only the best execution examples, the report is incomplete. A retail algorithmic trading platform should be judged by the bad trades it controls, not the easy trades it fills.

What to record during a live execution test

A useful test does not require institutional infrastructure. It requires consistent logging. For every order, record the signal timestamp, order submission timestamp, broker acknowledgment, fill timestamp, requested price, executed price, spread, volume, and rejection reason if applicable.

The platform should also record whether an order was modified, partially filled, or cancelled. If those events are missing from the log, the system cannot be properly investigated after a loss.

For MT4 and MT5 environments, the terminal journal is only one source of evidence. The EA should write its own structured log, including strategy version and trade identifier. API-based systems should preserve request and response data. Python services need explicit handling for timeouts, duplicate requests, stale quotes, and broker-side rejection messages.

That level of detail may look excessive when a strategy is winning. It becomes essential after a platform freeze or a disputed fill.

Risk controls decide whether automation is survivable

A strategy can have a positive expectancy and still be unsafe to run unattended. The audit needs to test the controls around the strategy, not just the entry and exit rules.

The basic risk layer should be independent enough to stop the algorithm when the strategy itself malfunctions. If the same code that creates an order is also the only code allowed to stop trading, a software error can disable both functions.

At minimum, I look for controls covering:

• Maximum position size by symbol and account.
• Maximum total exposure across correlated currency pairs.
• Maximum daily loss and rolling drawdown.
• Maximum number of orders within a defined interval.
• Maximum spread permitted for a new trade.
• Maximum slippage accepted before cancellation.
• Trading-hour restrictions and news-event rules.
• Margin-level protection.
• Duplicate-order prevention.
• A hard stop for abnormal price, quote, or connectivity conditions.

These controls should be tested with simulated failures. Set the account close to its daily loss limit and verify that the next signal is rejected. Send a deliberately oversized order and confirm that the system blocks it before transmission. Disconnect the market-data feed and check whether the EA continues using stale prices. Restart the terminal and verify that it reconstructs open positions correctly instead of opening replacements.

The kill-switch is the most important control because it must work when normal logic is no longer trustworthy. A proper kill-switch should cancel pending orders, prevent new submissions, and, where the mandate requires it, close open positions. The process needs a clear authority: a human operator, a risk service, a broker-side control, or an automated rule.

Some technical specifications require activation within 100 milliseconds and immediate cancellation of pending orders. That is a reasonable institutional target for systems designed for rapid execution. A retail trader may not need a 100-millisecond response, but the principle still applies: the kill-switch must have a measured response time and must not depend on a frozen graphical terminal.

I test the control through several paths:

1. Trigger it from the platform interface.

2. Trigger it through the API or command line if supported.

3. Disconnect the strategy service.

4. Block the data feed.

5. Restart the trading terminal.

6. Confirm that pending orders are cancelled.

7. Confirm whether open positions are closed or left under a documented policy.

8. Verify the event in the audit log.

If only the first test works, the control is not robust. A button that appears on the screen is not the same as an emergency mechanism.

Correlation is where many retail risk models fail

A bot may trade EUR/USD, GBP/USD, and AUD/USD as if they were three independent opportunities. In a sharp dollar move, they can become one concentrated position. The platform therefore needs portfolio-level limits, not only symbol-level limits.

The same problem appears with grid and martingale systems. Each individual order may comply with a size limit while the combined exposure becomes dangerous. A platform audit should calculate the worst-case exposure after a sequence of entries, not merely inspect the first trade.

I also check whether the risk engine uses account equity or balance. Balance-based limits can conceal floating losses. An account may appear to be within its daily loss allowance while open positions have already consumed most of the available risk budget.

This is not a theoretical distinction. Automated systems often fail during the transition between a floating loss and a closed loss. The platform must define exactly when the limit is measured and what happens to existing positions when the threshold is breached.

Backtesting integrity: a passing curve is not evidence of live readiness

Backtesting software criteria are often reduced to a profitable equity curve. That is not an audit. A backtest is useful only when its assumptions are close enough to live execution to make the result informative.

The first issue is data quality. Check whether the test used bid prices only, midpoint data, or a modeled spread. For forex strategies, entries and exits can be materially different depending on whether the tester applies real tick data, fixed spreads, variable spreads, and realistic commissions.

A credible test should state:

• The data period and currency pairs.
• The time zone and daylight-saving treatment.
• The spread model.
• Commission and swap assumptions.
• Slippage assumptions.
• The treatment of rejected or delayed orders.
• Whether price gaps are modeled.
• Whether the strategy can see information that would not have been available at the time.
• How missing candles and bad ticks were handled.
• Whether the parameters were selected using the same data later used to evaluate performance.

Look closely at optimization. An EA with dozens of adjustable inputs can fit almost any historical series. The more degrees of freedom the strategy has, the greater the risk that the reported performance reflects noise rather than a repeatable market effect.

Walk-forward analysis is a better test because it separates the period used for optimization from the period used for evaluation. The Walk-Forward Efficiency ratio is commonly calculated as annualized out-of-sample return divided by annualized in-sample return.

A WFE above 0.5 is generally treated as a passing signal in this type of review. A result below 0.3 indicates a likely overfit strategy. Neither threshold proves that the system will make money live. It only gives a structured way to identify strategies whose behavior collapses outside the optimization sample.

The test should also be repeated across different market regimes:

• Low-volatility range conditions.
• Strong directional trends.
• Rapid reversals.
• High-spread news periods.
• Interest-rate or central-bank repricing.
• Extended periods of weak liquidity.
• Different brokers or pricing feeds where possible.

If the strategy works only on one broker’s historical feed, that is a platform dependency, not proof of robustness.

Backtesting answers whether the rules could have worked under the chosen assumptions. It does not answer whether the broker will fill them at those prices tomorrow.

The live-versus-backtest gap needs a formal measurement

After deployment, compare live execution with the backtest at the trade level. Do not wait for a large drawdown. A small forward test is enough to expose the main differences.

Track the following:

• Entry price deviation from the modeled price.
• Exit price deviation.
• Average and worst slippage.
• Spread at signal time and execution time.
• Time between signal and order acceptance.
• Difference in trade frequency.
• Difference in stop-loss and take-profit hit rates.
• Swap and commission variance.
• Requotes, rejections, and partial fills.

The objective is not to force live results to match the backtest exactly. That is unrealistic. The objective is to understand which assumption is responsible for the gap. If the backtest assumes a 0.6-pip spread and the live median is 1.4 pips, the strategy may need a different entry filter. If the system generates fewer trades because quotes are stale, the issue is infrastructure or data handling.

A platform that cannot produce this comparison is difficult to audit and harder to trust.

VPS hosting and infrastructure resilience

A good strategy can still fail because it is hosted badly. Automated forex trading software depends on uninterrupted connectivity between the trading terminal, broker, market data, and any external signal or risk service.

The VPS location should be close to the broker’s execution servers when low latency matters. But physical distance is not the only issue. Packet loss, routing instability, CPU contention, disk errors, clock drift, and forced reboots can all affect execution.

For ordinary swing trading, a small amount of network latency may be irrelevant. For scalping, the same delay can change the fill. The platform audit should therefore measure the actual connection from the chosen VPS to the broker, rather than rely on the provider’s advertised location.

The infrastructure review should cover:

• CPU and memory headroom during peak strategy activity.
• Disk space for terminal and audit logs.
• Automatic restart after a terminal crash.
• Time synchronization.
• Backup and restoration procedures.
• Monitoring for process failure.
• Alerting through an independent channel.
• Network packet loss and reconnection behavior.
• Protection against duplicate orders after a restart.
• Separation between trading services and unrelated workloads.

The last point is frequently missed. A cheap VPS running several terminals, a browser, a database, and unrelated scripts may pass a casual test and degrade during market volatility. Resource usage should be observed while the platform processes real-time ticks, not while it sits idle overnight.

The 30-second disconnection rule

Infrastructure-level safety specifications often require an automated kill-switch to trigger if the VPS loses connection to the trading platform for more than 30 seconds. The exact threshold may vary by system, but the control concept is valuable.

The key question is what “connection lost” means. A terminal can remain open while its quotes are stale. The operating system can show an active network connection while the broker session is dead. A Python process can be running while its API token has expired.

The monitoring layer should distinguish among:

• No network connection.
• No broker heartbeat.
• No fresh market data.
• API authentication failure.
• Terminal process failure.
• Broker rejection of a valid heartbeat or order request.

When the threshold is exceeded, the system needs a defined response. That could mean cancelling pending orders, closing positions, disabling new trades, or escalating to a human operator. The response must be appropriate to the strategy. A swing system may tolerate a delayed alert; an event-driven scalper may not.

Recovery is equally important. When the connection returns, the system should not immediately replay every missed signal. It should reconcile current broker positions and orders, check whether prices are still valid, and establish a new strategy state. Otherwise a restart can create duplicate positions or enter a trade based on an obsolete signal.

A practical pass-or-fail framework

I use a staged review rather than one overall score. A platform that fails a critical safety control should not be rescued by good latency or an attractive backtest.

The pass criteria should be risk-weighted. A platform with 99.99% availability is not acceptable if its kill-switch fails. A platform with sub-millisecond internal processing is not useful if the live spread is consistently larger than the strategy’s expected edge.

The same caution applies to marketing claims about extreme performance. Some high-frequency platforms report end-to-end latency around 350 nanoseconds using FPGA acceleration. That is a specialized institutional environment. It should not be used to set expectations for a retail MT5 VPS connected to a conventional forex broker. The relevant comparison is the complete execution path available to the trader.

What retail traders should test before going live

A full institutional audit may be expensive, but the retail version can still be disciplined. I would run the review in this order:

1. Inspect the strategy’s permissions. Confirm whether it can open, modify, and close positions, and whether those permissions can be restricted by symbol, size, or trading session.

2. Run a controlled demo test. Use the same broker server, account type, platform build, VPS region, and EA version planned for live trading. A generic backtest is not a substitute.

3. Force operational failures. Disconnect the VPS, stop the terminal, block the API, and interrupt the data feed. Record exactly what the strategy does.

4. Measure real execution. Log spread, latency, slippage, rejected orders, and stop execution. Use several sessions, including a volatile period.

5. Reconcile after restart. Close and relaunch the terminal. Check whether the system recognizes existing positions and avoids duplicate orders.

6. Test the kill-switch separately. Do not assume it works because the button is visible. Confirm its effect at the broker and in the audit log.

7. Compare forward results with the model. Start with small exposure and review every deviation from the backtest assumptions.

8. Set a retirement rule. Define in advance when the algorithm will be disabled: a drawdown limit, execution deterioration, abnormal spread, data failure, or a change in market behavior.

This process will not make an unprofitable strategy profitable. It will identify whether the platform is behaving as designed and whether the strategy’s assumptions survive contact with the market.

Final verdict

An algorithmic trading platform passes when it can control risk, produce a complete execution record, recover from operational failure, and deliver live fills that remain broadly consistent with its tested assumptions. Compliance documents, low-latency claims, and attractive backtests are supporting evidence. They are not the decision.

For most retail traders, the decisive metrics are practical: actual spread, negative slippage, rejected orders, restart behavior, API security, VPS stability, and the speed of emergency intervention. Those costs determine whether automation has an edge or merely automates losses.

My verdict is straightforward. Do not approve a platform because the strategy runs without errors on a quiet demo account. Approve it only after the system has been forced to fail and has demonstrated that the failure will not become an uncontrolled position. That is the standard separating automated trading from unattended risk.