Mirror trading execution: API vs. Bridge vs. Plugin performance

A leader’s fill must be detected, normalized, queued, transmitted, validated against a follower account, routed to the broker, and then resolved into a final execution state. The interval between any two of those stages can dominate the result.

There is no defensible universal claim that an API, a liquidity bridge, or a terminal plugin is “fastest.” They occupy different points in the execution stack. A direct API can provide structured events and controlled order submission. A broker-side bridge is primarily an institutional routing and liquidity component. A terminal plugin is usually an automation layer constrained by the terminal, its event queue, and its connection to the trade server.

The correct comparison is not architecture label versus architecture label. It is the measured path from leader event to follower fill, under a specified broker, account type, hosting location, symbol, and load condition.

In mirror trading, the submission timestamp is not the execution timestamp. Treating them as equivalent produces misleading latency figures.

The mechanics of trade replication: API, bridge, and plugin

A basic mirror trading workflow has at least six distinct stages:

1. Leader-side event detection. The replication engine detects an order, deal, position change, or fill event on the source account.

2. State normalization. The engine converts source-side fields—symbol, direction, volume, stop loss, take profit, account currency, netting or hedging mode—into a follower-compatible instruction.

3. Risk and allocation calculation. Follower volume may be fixed, proportional to equity, capped by exposure, or reduced because of margin constraints.

4. Transmission and queueing. The instruction enters an API request queue, terminal event handler, vendor message bus, or bridge-connected routing layer.

5. Broker-side validation. The broker checks symbol availability, volume increments, market status, margin, permissions, price conditions, and execution rules.

6. Final execution handling. The follower receives an accepted, rejected, partially filled, or filled outcome. A robust system then reconciles the position state.

The architecture changes which of these stages are visible and controllable.

A bridge should not be described as a retail copy-trading plugin with lower latency by default. A broker-side liquidity bridge can aggregate liquidity, route orders, and connect a broker to liquidity providers through FIX or custom protocols. That is execution infrastructure. It can be part of the follower’s route, but it does not automatically solve leader-event detection, allocation logic, or follower-account state reconciliation.

Likewise, an API does not eliminate broker-side checks. It merely gives the replication service a documented interface for sending and monitoring instructions. The trade still enters the broker’s own validation and execution path.

Throughput constraints and rate limiting in cTrader Open API

The cTrader Open API is a useful example because its limits and execution events are explicitly documented. It supports real-time market data, trading operations, and access to current, pending, and historical orders, deals, and positions. Its payloads can use JSON or Google Protocol Buffers, with official SDK support for C# and Python.

That capability does not mean unlimited replication throughput.

A single cTrader Open API connection is limited to:

• 50 non-historical requests per second
• 5 historical requests per second
• 500 new-order operations per minute per authorized connection on cTrader Algo demo accounts
• A required heartbeat at least once every 10 seconds to avoid an inactivity disconnect

The first two limits matter directly to mirror trading software. A poorly designed copier can consume its quota before it places a single follower order. The common failure pattern is aggressive polling: repeatedly requesting positions, orders, history, and symbol data for every follower account while also issuing trade operations. The service remains “connected” but accumulates avoidable queue pressure.

A replication engine should be event-driven wherever the platform permits it. Polling still has a role in reconciliation, but it should not be the primary mechanism for detecting every state transition.

The distinction between order acceptance and final execution is equally important. On cTrader, execution processing produces a ProtoOAExecutionEvent, with documented states including accepted, filled, rejected, and partial fill. These are separate states, not synonyms.

A copier that marks a follower trade as complete after acceptance has only measured request progression into the broker workflow. It has not established the final volume, the fill price, or whether the trade was partially executed. That distinction becomes material during fast price movement, thin liquidity, or volume expansion across many follower accounts.

The available deal fields provide a limited but useful timing instrument. cTrader records include:

• createTimestamp: when the deal was sent for execution
• executionTimestamp: when it was executed

Both are Unix timestamps in milliseconds. Their difference can identify a documented portion of broker-side execution timing for that deal. It cannot, by itself, measure total trade replication latency.

The complete mirror-trading interval needs at least four timestamps:

The useful metrics are then explicit:

• Detection delay: T1 minus T0
• Broker processing interval: T3 minus T1, where timestamps are comparable
• Replication completion time: T3 minus T0
• Fill divergence: follower fill price minus leader reference price, normalized in ticks or points
• Volume divergence: requested follower volume versus final filled volume

Without this event chain, a platform’s claimed “sub-second copying” is not a performance result. It is a marketing interval with unspecified endpoints.

A low API response time can coexist with poor follower fills if the delay sits in risk checks, broker routing, liquidity availability, or partial-fill handling.

Asynchronous execution risks in MetaTrader 5 environments

MetaTrader 5 environments introduce a different measurement problem. OrderSendAsync() sends a trade request without waiting for a response from the trade server. This is appropriate where blocking on a server response is unacceptable. It is not a confirmation of execution.

A true return from OrderSendAsync() means the request was sent successfully by the terminal-side function. It does not prove that the request reached the trade server. It does not prove the server accepted it. It does not prove the follower position was opened.

This is where many plugin-based mirror trading systems overstate their execution evidence. A local function return is often logged as a completed action. In a proper audit trail, it is only the dispatch milestone.

MetaTrader 5 also does not guarantee that trade transaction events will arrive in the intuitive sequence assumed by simple copiers. One trade request can generate multiple transaction events. The arrival order of transaction groups is not guaranteed. The OnTradeTransaction queue contains 1,024 elements, and a handler that runs too long can allow older events to be replaced by newer ones.

That limit changes the design requirement. A plugin that performs network calls, database writes, follower-volume calculations, or synchronous retries inside OnTradeTransaction is exposing itself to event loss under burst conditions. The handler should capture the minimum immutable event data, assign a sequence or correlation key, and offload noncritical processing to a separate queue.

A terminal plugin should also reconcile state rather than infer state solely from callbacks. The minimum reconciliation set is:

• Source deal or order identifier
• Follower request identifier
• Follower order identifier, if created
• Follower deal identifier or position change
• Requested volume and final filled volume
• Requested price conditions and final fill price
• Terminal timestamp and broker-reported transaction timestamp where available
• Rejection, cancellation, or partial-fill reason

This is not administrative logging. It is the only way to distinguish a delayed event, a rejected request, a missed callback, and a partial execution from one another.

For small account groups and low trade frequency, a terminal-resident copier can be operationally adequate. Its disadvantage appears as concurrency rises. Every terminal instance adds process-level overhead, broker-session dependence, local queue behavior, and a separate failure domain. Scaling from 10 followers to 500 is not a linear multiplication of the same operational model.

Infrastructure bottlenecks: beyond VPS ping and network latency

A VPS is frequently treated as a generic cure for trade replication latency. It is not. It improves one segment: connectivity between the virtual server and the broker’s trade server.

MetaTrader’s virtual-hosting documentation defines ping as network delay between the virtual server and the broker’s trade server. Lower ping can reduce execution friction, including slippage and requote probability. That is a valid reason to measure server proximity. It is not evidence that lower VPS ping guarantees identical fills or lower end-to-end copy delay.

The copied trade may still wait at several points before it reaches the broker:

• Leader-event detection may occur after the leader has already received a fill.
• The copier may batch follower instructions or wait for risk calculations.
• API quotas may delay outbound requests.
• A terminal event queue may be congested.
• The follower account may fail margin or symbol validation.
• The broker may route the follower order to a different liquidity path.
• The market may move between leader fill and follower execution.

A useful infrastructure audit separates these components rather than compressing them into one “latency” number.

What should be measured

For each broker and hosting region, record at least:

1. VPS-to-broker ping, measured in milliseconds and sampled repeatedly rather than once.

2. Leader event receipt time, using the copier’s own monotonic clock.

3. Follower request dispatch time, after volume transformation and risk checks.

4. Broker acceptance and execution events, preserving the platform-provided state.

5. Final fill deviation in ticks, split into favorable and adverse outcomes rather than averaged into a single number.

6. Tail latency, especially p95 and p99 replication completion time. Median values hide queue bursts.

7. Failure rates, including API throttling, rejected orders, partial fills, dropped connections, and reconciliation mismatches.

The test must also hold the configuration constant. A comparison between a direct API in the broker’s preferred region and a plugin running on a distant retail VPS is not an architecture comparison. It is a hosting comparison.

The same problem applies to follower accounts. Different account currencies, leverage, margin levels, symbol suffixes, minimum lot sizes, hedging or netting modes, and permissions can alter the replication path. A system can detect a leader fill in milliseconds and still produce a follower rejection because the requested volume rounds below the broker’s increment or exceeds available margin.

The practical conclusion is narrow: move compute close to the broker only after measuring where delay actually occurs. If 80% of the interval is inside a serialized risk engine or an overloaded terminal callback, reducing network ping by 3 ms will not materially change trade replication latency.

Protocol reliability: FIX sessions and event handling logic

At higher scale, the central question is not only speed. It is recoverability.

FIX is designed for reliable electronic-trading messaging through a bidirectional ordered stream with sequence numbers. FIXP extends that objective toward efficient, reliable operation in high-message-rate and low-latency environments. Neither protocol removes market risk or creates matching fills across accounts. Their operational value is message integrity, session recovery, ordered processing, and explicit sequence control.

For server-side mirror trading, those properties matter when a connection drops during a burst of source events. The system needs to answer four precise questions:

• Which leader events were observed before the disconnect?
• Which follower instructions were sent?
• Which requests were acknowledged by the downstream system?
• Which final executions remain unresolved?

A replication engine that cannot answer those questions is not fault tolerant. It is merely fast while connected.

The core implementation pattern is an idempotent event ledger. Each leader-side execution should produce a durable replication record before follower routing begins. That record requires a stable source identifier, follower target, transformed volume, intended action, and downstream correlation IDs. Replays after reconnect must not generate duplicate follower positions.

This is particularly relevant when the source platform emits multiple events for one trade lifecycle. A system that reacts indiscriminately to order creation, order update, deal execution, and position update can copy the same economic action twice. The replication trigger must be defined precisely: for example, only a new executed deal, not every order-state change.

The performance target should therefore be framed as a controlled trade-off:

The verdict: architecture is secondary to the measured execution path

For mirror trading software, a direct API is usually the cleanest basis for a measurable, centrally managed replication engine. It exposes structured states, supports service-side deployment, and avoids the process sprawl of many terminal instances. But API rate limits, event design, and broker-side execution still define the actual ceiling.

A broker-side bridge belongs in a different category. It can be critical to routing and liquidity execution, particularly in broker infrastructure, but it is not a standalone answer to copy logic or leader-to-follower timing. Calling it inherently faster than an API or plugin confuses execution routing with replication orchestration.

A terminal plugin remains viable for contained deployments, especially where the source and follower accounts exist inside the same platform environment. Its weaknesses are measurable: terminal lifecycle dependence, event-queue pressure, ambiguous local completion signals, and limited scaling discipline.

The relevant benchmark is not “API versus bridge versus plugin.” It is a timestamped execution ledger showing T0 through T3, request-rate pressure, p95 and p99 completion times, rejection and partial-fill rates, and tick-level fill divergence for one defined route.

Anything less is not a mirror trading performance comparison. It is an unverified claim about a machine whose critical stages were never measured.