Direct answer
Technical Target can seem to “change” during volatile markets even when the intended rule is fixed. The main reasons are (1) price gaps between when the platform shows a level and when the order is actually executed, (2) latency and order routing delays, and (3) liquidity withdrawal, which can widen spreads and reduce available fills. On top of that, the order-handling logic of the trading venue/provider can determine whether a target is filled as expected, partially filled, adjusted, or rejected.
Mechanics: what “Technical Target” is and what can change
A Technical Target (in trading systems that place take-profit style levels) is a predefined price condition tied to an open position. In a simple model, you set a target at a specific price, and the system attempts to close or reduce the position when the market reaches that condition.
Even if the target value you entered does not change, the resulting fill can change because the market and the execution pipeline do change:
1) Price gaps
In volatile markets, price may jump from one level to another without trading at intermediate prices. If your take-profit condition is crossed between updates, the platform may end up executing at the next available executable price rather than at the exact displayed target. This creates a mismatch between “the target level” and “the effective execution price.”
2) Latency and timing
There is typically a delay between order submission, order acceptance, and execution. If the price moves during that delay, the system may place or trigger the order against a newer market state. The target condition is still the same rule, but the market state at execution is different from the state at submission.
3) Liquidity withdrawal
Liquidity can thin out when volatility increases. Fewer participants willing to buy or sell means the order book becomes less stable. A larger gap between bid and ask (wider spread) and reduced depth can change the price at which an order is executed once it triggers.
Evidence or example (non-real-time): how an apparent target change happens
Assume a position with a take-profit target at a particular price level. Now suppose the market is unstable:
- At time A, the system displays the market around the target level.
- Before the order is executed at time B, price jumps due to fast trading activity, and the market passes through the target without sufficient liquidity at that exact level.
- At time B, the system can only execute using the next available executable prices.
From the user’s perspective, this can look like the “Technical Target changed,” because the realized close price differs from the target you associated with the rule. In reality, the target rule remained the same, but the fill outcome changed due to gaps, timing, and liquidity.
Limitations and risks: what can fail or vary
At least one material failure mode is partial fills or non-ideal fills. If the system cannot fully close the position at the moment the condition triggers (common when liquidity is thin), it may execute only part of the intended quantity and leave the rest to be filled later—possibly at different prices.
Other variability sources include:
- Order acceptance and rejection behavior: some systems may accept the order but not guarantee execution at the exact target price.
- Different handling rules for triggers and execution logic: depending on how orders are implemented, a trigger may cause immediate execution, queueing, adjustment to available prices, or cancellation.
- Cost effects: trading costs (such as spread and commissions) can make the effective result differ from a simple “target price minus entry price” mental model.
Because these behaviors depend on the execution environment and market microstructure, you cannot assume a stable, one-to-one mapping between the entered target price and the realized fill price.
Verification: how to independently check what “changed”
A practical way to verify what happened—without relying on predictions—is to compare three timestamps/records from your own execution history:
- When the order/target was submitted
- When the order was accepted/triggered
- What execution price(s) were actually filled
Then compute the difference between:
- the intended target level and
- the realized execution price(s) (including any partial fills).