Avoiding Duplicate Signals in Automated Trading

An automated trading strategy can identify the correct market condition and still behave incorrectly if the same signal is processed more than once. A single valid breakout, for example, may be detected repeatedly while a candle remains open or after a system reconnects.

Duplicate signal handling is therefore an important part of trading software design. The goal is not simply to detect a signal, but to ensure that one intended trading event does not accidentally create multiple actions.

This requires clear event identification, state management, idempotent processing and reconciliation with the actual order and position state.

What Is a Duplicate Trading Signal?

A duplicate signal occurs when the same strategy event is processed multiple times even though it is intended to produce only one action.

For example, suppose a strategy generates a Buy signal when a 15-minute candle closes above a resistance level.

If the software evaluates the same completed candle several times and sends a Buy order each time, the strategy may create multiple entries from one intended signal.

Duplicate signals can happen for several reasons:

• The same market event is received more than once.
• A strategy is evaluated repeatedly during the same candle.
• The application restarts and forgets its previous state.
• A network timeout occurs after an order is submitted.
• A broker response is delayed.
• Multiple application processes evaluate the same strategy.
• Signal records are not uniquely identified.

The exact failure depends on the architecture, but the underlying problem is the same: the system cannot reliably distinguish a new event from an event it has already processed.

Why Duplicate Signals Matter

Repeated entries can change the strategy's intended behaviour.

A strategy designed for one position may unexpectedly create several positions. This can affect:

• Position size
• Capital usage
• Risk exposure
• Stop-loss and exit management
• Margin requirements
• Strategy state
• Daily trade limits

The software may be following its instructions literally while still behaving incorrectly because the same instruction was triggered multiple times.

That is why duplicate prevention should be part of the strategy design, not something added only after a production incident.

Understanding Idempotency

Idempotency means that processing the same operation more than once does not create additional unintended effects.

In automated trading, this is especially useful when the system cannot immediately know whether an earlier order request succeeded.

For example, a strategy may generate a signal with a unique identifier:

Strategy A + Symbol X + Candle 12345 + Buy

If the same signal reaches the execution component again, the system can recognise that the signal has already been processed.

Instead of creating another order, it can return the existing result or safely ignore the duplicate.

Why Idempotency Is Important

Network communication is not always perfectly predictable.

Consider this sequence:

1. Strategy generates a Buy signal.
2. Application sends the order request.
3. Broker receives the request.
4. Application does not receive the response because of a connection problem.
5. Application assumes the request may have failed.
6. Application sends another request.

If the first order actually reached the broker, the second request could create an unintended duplicate.

An idempotent design helps the application avoid treating uncertainty as permission to submit another order.

Use Unique Candle or Event Identifiers

For candle-based strategies, the candle itself can provide an important reference point.

A signal identifier can include information such as:

• Strategy ID
• Symbol
• Timeframe
• Candle open time
• Signal direction
• Strategy version

For example:

STRATEGY01-XAUUSD-M15-2026-08-20T10:15-BUY

The exact identifier format depends on the system, but it should uniquely represent the intended event.

Why Candle Time Matters

If a strategy is designed to evaluate one completed candle once, the candle's timestamp can be used as part of the processing key.

The system can record:

Last processed candle = 10:15

When the same 10:15 candle is evaluated again, the system knows that it has already processed that event.

This is much safer than simply assuming that every strategy evaluation is a new signal.

State Flags for Signal Control

A state flag records what the strategy has already done.

For example:

• `signal_detected`
• `entry_submitted`
• `entry_confirmed`
• `position_open`
• `exit_pending`
• `daily_limit_reached`

The exact state model should match the strategy.

A simple workflow might be:

1. Candle closes.
2. Entry conditions become true.
3. Signal state changes to `SIGNAL_CREATED`.
4. Order request is submitted.
5. State changes to `ORDER_PENDING`.
6. Broker response is received.
7. State changes to `POSITION_OPEN`.

If the same candle is processed again while the state is already `ORDER_PENDING` or `POSITION_OPEN`, the system should not create another entry unless the strategy explicitly allows it.

Avoid Overly Simple Flags

A single Boolean such as `trade_taken = true` may work for a simple strategy but can become insufficient in a more complex system.

A robust state model may need to distinguish between:

• Signal generated
• Order requested
• Order accepted
• Order rejected
• Order partially filled
• Position confirmed
• Position closed

This makes recovery and debugging more reliable.

Database Records and Unique Constraints

Persistent storage can strengthen duplicate prevention.

A signal-processing record might contain:

• Strategy ID
• Symbol
• Timeframe
• Event identifier
• Signal type
• Processing status
• Order identifier
• Timestamp
• Error information

A database can enforce uniqueness for an appropriate combination of fields.

For example, the system may define a unique processing key based on:

Strategy + Symbol + Timeframe + Candle Time + Signal Type

If the application attempts to insert the same event again, the database can prevent another identical record.

The exact uniqueness rule must match the strategy. Two different valid signals can sometimes occur during the same candle, so blindly using candle time alone may be insufficient.

Preventing Duplicate Evaluation

Duplicate orders can originate before the order stage.

A strategy may be evaluated multiple times because the application receives several market-data updates.

If the intended strategy uses candle-close confirmation, the application should explicitly track whether the current candle has already been evaluated.

For example:

1. Receive market update.
2. Identify the current candle.
3. Check whether the candle is complete.
4. Check whether this candle has already been processed.
5. Evaluate the strategy once.
6. Record the processing result.

This prevents repeated evaluation of the same event.

Tick-Based Strategies Are Different

Tick-driven strategies may intentionally evaluate many times.

In that case, candle identifiers alone are not enough. The system needs an event model appropriate to the strategy, such as a unique market-data event, timestamp sequence, order state or other defined condition.

The key principle is:

The duplicate-prevention mechanism must match the unit of the strategy's intended decision.

Order Reconciliation

Signal tracking alone is not enough.

The software must also compare its internal state with the actual order and position state available from the execution venue or broker integration.

This process is called reconciliation.

Suppose the application records:

Order request sent = Yes

but the application then restarts.

After restart, it should not assume that no order exists simply because its local memory was lost.

Instead, it should retrieve available order and position information and compare it with its stored strategy state.

Reconciliation Can Handle Uncertain Outcomes

A useful reconciliation workflow can be:

1. Load pending signals.
2. Retrieve relevant orders and positions.
3. Match them using appropriate identifiers.
4. Determine the actual execution state.
5. Update the internal strategy state.
6. Only then decide whether another action is required.

This is especially important after connection failures or application restarts.

Handling Partial Fills and Rejections

Order execution is not always a simple success-or-failure event.

Depending on the trading venue and order type, an order may be:

• Accepted
• Rejected
• Partially filled
• Filled
• Cancelled
• Pending

The strategy's state machine should define what happens for each relevant status.

For example, a partially filled entry should not automatically be treated as if no position exists.

Similarly, a rejected order should not automatically trigger repeated retries unless retry behaviour is explicitly defined.

Multiple Strategy Instances

Duplicate signals can also happen when more than one process runs the same strategy.

For example, two application instances may both detect the same breakout and attempt to place the same order.

Possible controls include:

• Strategy instance identifiers
• Distributed locks
• Database constraints
• Centralised signal processing
• Broker-side identifiers where supported

The correct approach depends on the system architecture and execution requirements.

Common Mistakes

Relying Only on In-Memory Variables

A variable stored only in application memory disappears when the process restarts.

Important trading state should have an appropriate persistence and recovery design.

Assuming Network Timeout Means Order Failure

A timeout means the application did not receive a response within the expected period. It does not necessarily prove that the order was not processed.

Using Candle Time Without Strategy Context

The same candle can generate different valid events for different strategies or symbols. Event identifiers should include enough context.

Retrying Automatically Without Reconciliation

Blind retries can turn an uncertain execution result into a duplicate order.

Treating Signal State as Order State

A signal being generated does not mean that an order was accepted or a position was created. These states should be distinguished.

A Practical Duplicate-Signal Prevention Workflow

A robust workflow can be structured as follows:

1. Receive market data or a scheduled evaluation event.
2. Identify the relevant strategy event.
3. Generate a deterministic signal identifier.
4. Check whether the event has already been processed.
5. Evaluate the strategy conditions.
6. Apply risk and position checks.
7. Create a persistent signal record.
8. Submit the order using appropriate identifiers.
9. Record the order response.
10. Reconcile uncertain or pending states.
11. Update the final strategy and position state.
12. Prevent the same event from creating another unintended action.

This design creates a clear trail from market event to trading action.

Testing Duplicate-Signal Protection

Duplicate prevention should be tested deliberately rather than assumed to work.

Useful test scenarios include:

• Same candle received multiple times
• Application restart after signal generation
• Restart after order submission
• Network timeout after order request
• Delayed broker response
• Duplicate market-data event
• Partial fill
• Order rejection
• Two strategy processes running together
• Reconnection after network failure

The goal is to verify not only normal execution but also uncertain execution states.

How Suyotech Supports Trading Software Development

Suyotech Solutions provides software engineering services for custom trading automation, including MT5 EA development, TradingView solutions, broker API integrations, trading dashboards and custom trading applications.

For automated trading systems, duplicate prevention can be incorporated into the strategy workflow through clear event identifiers, persistent state, order tracking and reconciliation logic.

Conclusion

Duplicate signals are not simply a strategy problem. They are often an application-state and execution-management problem.

Reliable automated trading software should know which event it is processing, whether that event has already been handled, what order state exists and whether the actual trading account matches the system's internal state.

Idempotency, unique event identifiers, state management, persistent records and order reconciliation provide practical tools for reducing unintended repeated actions.

Good duplicate prevention does not make a trading strategy profitable, and automation cannot guarantee future trading results. It simply helps the software behave consistently with the strategy rules under normal and failure conditions.

If you are developing an automated trading system and need reliable signal and order-state handling, contact Suyotech Solutions to discuss your software requirements and architecture.