Imagine running a trading strategy against a month of historical market data.
The first run produces 42 trading decisions.
You run it again with exactly the same data and configuration.
This time, it produces 43.
Nothing changed. At least, nothing you intentionally changed.
Which result is correct?
More importantly, how can you trust a trading engine that cannot reproduce its own decisions?
This is one of the fundamental questions we had to address while developing NERV Trade, my Java-based trading engine.
In the NERV Trade engineering series , we've already explored why a trading bot is fundamentally different from a trading engine.
A trading bot can generate BUY and SELL signals. A trading engine must also manage their consequences.
But before building a reliable execution lifecycle, we needed to answer a more fundamental question:
Given the same market observations, initial state, and configuration, can the engine produce exactly the same decisions?
That question led us to one of the earliest architectural foundations of NERV Trade: determinism.
1. The Problem With a Strategy That Changes Its Mind
Most trading strategies are built around indicators.
Moving averages, RSI, MACD, volatility, and other measurements help determine whether a particular market condition is favorable.
For example, a simple strategy might generate a BUY signal when a fast moving average crosses above a slower one.
if (fastMovingAverage.compareTo(slowMovingAverage) > 0) {
return Signal.BUY;
}
return Signal.HOLD;The logic appears deterministic.
Given the same two values, the result will always be the same.
But real trading strategies rarely operate on two isolated numbers.
They depend on a sequence of market observations, calculations, time boundaries, configuration, and sometimes previously accumulated state.
Consider the following inputs:
Market: BTCUSDT
Timeframe: M5
Candles:
10:00
10:05
10:10
10:15
10:20The strategy evaluates these candles and produces a BUY signal.
Now imagine replaying the same data, but the application evaluates the strategy while the final candle is still being constructed.
The calculated indicator values may differ.
The resulting decision may change.
The problem isn't necessarily the indicator formula.
The problem is that the strategy did not evaluate the same information state.
2. Determinism Is More Than Using the Same Market Data
A common definition of deterministic software is that identical inputs produce identical outputs.
That definition is useful, but it raises an important question:
What exactly counts as an input?
For a trading strategy, the answer extends beyond historical prices.
A reproducible trading decision may depend on:
- The exact market-data snapshot.
- The timeframe and candle boundaries.
- The decision timestamp or logical evaluation time.
- The strategy configuration.
- The initial strategy state.
- The ordering of observations.
- The numerical calculation rules.
- The version of the strategy implementation.
If any of these change, two evaluations may legitimately produce different results.
Therefore, a stronger definition is:
A deterministic trading decision is reproducible when the same complete input snapshot, initial state, and evaluation rules produce the same output.
This distinction matters because two applications can process the same historical price series and still reach different decisions if they disagree about which observations were available at a particular point in time.
3. Time Is an Input, Not a Hidden Dependency
One of the easiest ways to introduce nondeterminism is to allow trading logic to depend directly on the system clock.
Consider this simplified Java example:
public Signal evaluate(MarketSnapshot snapshot) {
Instant now = Instant.now();
if (isTradingWindowOpen(now)) {
return analyze(snapshot);
}
return Signal.HOLD;
}The result now depends on when the method executes.
Run it at 10:00 and it may return BUY.
Run it at 18:00 and it may return HOLD.
The market data hasn't changed.
But a hidden input has.
For deterministic evaluation, the relevant time should be explicit.
public Signal evaluate(
MarketSnapshot snapshot,
Instant evaluationTime) {
if (isTradingWindowOpen(evaluationTime)) {
return analyze(snapshot);
}
return Signal.HOLD;
}Now the caller controls the evaluation time.
A historical replay can evaluate the strategy using the time associated with the historical decision rather than the current wall clock.
Tests can use a fixed timestamp.
Production processing can use an explicitly established decision boundary.
This doesn't mean the entire application must avoid
Instant.now().
Operational timestamps, logging, and monitoring still need the current time.
The important rule is that wall-clock time should not silently influence a decision that is supposed to be reproducible.
4. A Candle Is Not Complete Until It Is Complete
Trading systems often organize market data into candles.
A five-minute candle might represent the interval from 10:00 to 10:05.
During that interval, its high, low, close, and volume can continue changing as new trades arrive.
Consider a candle currently forming:
Timeframe: M5
Interval: 10:00 - 10:05
At 10:02:
Open: 100
High: 103
Low: 99
Close: 102
At 10:04:
Open: 100
High: 105
Low: 99
Close: 104
At close:
Open: 100
High: 105
Low: 98
Close: 99The final candle looks very different from its intermediate state.
If the strategy evaluates the candle at 10:02, it sees one market condition.
If it evaluates the completed candle, it sees another.
Both observations can be valid for different strategy designs.
But they cannot be treated as interchangeable.
For strategies designed around closed candles, the rule must be explicit:
Only candles confirmed as closed may participate in the decision snapshot.
A strategy intentionally using intrabar information requires a different contract: it must preserve the actual observations available during the candle's formation.
Replaying only the final candle cannot reconstruct every intrabar decision.
This is an important distinction.
Determinism does not require every trading strategy to wait for candle closure.
It requires the strategy's observation rules to be explicit and reproducible.
5. Market-Data Ordering Must Be Predictable
Another subtle source of inconsistent decisions is observation ordering.
Imagine receiving the following candles:
10:00
10:05
10:10
10:15The sequence is straightforward.
But live market-data feeds may reconnect, deliver updates late, or provide overlapping data during recovery.
An application might encounter:
10:00
10:05
10:15
10:10
10:15If calculations blindly depend on arrival order, the result may differ from an evaluation performed over correctly ordered historical data.
A reliable market-data boundary needs to establish:
- How candles are identified.
- How observations are ordered.
- How duplicate observations are handled.
- How corrections or revisions are represented.
- What happens when expected intervals are missing.
A simplified normalization step might look like this:
List<Candle> ordered = candles.stream()
.sorted(Comparator.comparing(Candle::openTime))
.toList();Sorting is useful, but it is not a complete solution.
If two records represent the same candle interval but contain different values, the engine still needs an explicit rule for determining which version is authoritative.
Likewise, sorting cannot recover an observation that was never received.
These are data-quality and consistency concerns, not merely collection-processing details.
6. Mutable State Can Make Identical Data Behave Differently
A trading strategy may also maintain state between evaluations.
For example, it might track whether a signal has already been emitted for a particular candle.
Or it might remember a previous indicator value to detect a crossover.
Stateful strategies aren't inherently nondeterministic.
But their initial state and transition rules must be part of the reproducibility contract.
Consider this simplified example:
public final class CrossoverStrategy {
private BigDecimal previousDifference;
public Signal evaluate(
BigDecimal fast,
BigDecimal slow) {
BigDecimal difference = fast.subtract(slow);
Signal result = Signal.HOLD;
if (previousDifference != null
&& previousDifference.signum() <= 0
&& difference.signum() > 0) {
result = Signal.BUY;
}
previousDifference = difference;
return result;
}
}The strategy's output depends on its previous evaluation.
If we reuse the same instance without resetting its state, a second run may produce different results.
The solution isn't necessarily to remove state.
Instead, we should make state transitions explicit.
public record StrategyState(
BigDecimal previousDifference) {
}
public record EvaluationResult(
Signal signal,
StrategyState nextState) {
}
public EvaluationResult evaluate(
MarketSnapshot snapshot,
StrategyState currentState) {
// Calculate the decision from the snapshot
// and the supplied state.
return new EvaluationResult(
Signal.HOLD,
currentState);
}The implementation above illustrates the interface shape rather than a complete trading strategy.
The architectural idea is that the next state becomes an explicit output of the evaluation.
Given the same snapshot and the same initial state, the transition can be reproduced.
This also makes testing easier because the test does not depend on whatever happened to a shared strategy instance beforehand.
7. Deterministic Calculations Need Numerical Rules
Java provides several ways to represent numerical values.
For financial calculations, BigDecimal is frequently
useful because it provides explicit decimal arithmetic and rounding rules.
But simply using BigDecimal does not automatically make
a calculation correct or reproducible.
Precision and rounding must also be controlled.
BigDecimal average = total
.divide(
BigDecimal.valueOf(count),
8,
RoundingMode.HALF_UP);The appropriate scale and rounding mode depend on the calculation.
Indicator precision, order quantities, exchange tick sizes, and financial accounting may require different policies.
We should not assume that one rounding policy is appropriate everywhere.
Deterministic numerical behavior also requires controlling calculation order and avoiding unintended differences between implementations.
Two mathematically equivalent formulas may produce slightly different numerical results depending on their representation and rounding steps.
Near a strategy threshold, even a small difference can change a decision.
Therefore, numerical conventions are part of the strategy contract.
8. Testing Determinism Means Testing Repetition
Traditional unit tests often check one input and one expected output.
That's necessary, but deterministic systems benefit from another kind of verification.
Run the same scenario more than once.
Then compare the results.
Conceptually:
@Test
void sameInputsProduceSameDecisions() {
MarketHistory history = fixtureHistory();
StrategyConfig config = fixtureConfig();
List<Decision> firstRun =
replay(history, config);
List<Decision> secondRun =
replay(history, config);
assertEquals(firstRun, secondRun);
}The example assumes that each replay starts from the same initial strategy state and uses the same evaluation rules.
Otherwise, comparing the two runs would not be meaningful.
A more comprehensive deterministic test suite should examine:
- Repeated evaluations using identical input snapshots.
- Replay from a known initial state.
- Consistent candle ordering.
- Duplicate market-data delivery.
- Missing candle intervals.
- Boundary timestamps.
- Partial versus closed candles.
- Indicator threshold behavior.
- Different JVM default timezones.
One important distinction: deterministic analysis does not guarantee identical live executions.
A broker may fill the same order differently at different times.
Network conditions, liquidity, fees, and exchange state can change.
The goal is to reproduce the decision-making process under controlled inputs—not to pretend that the external market is deterministic.
9. Why Determinism Matters for Debugging
Imagine a strategy unexpectedly generates a BUY signal.
Without reproducibility, debugging becomes guesswork.
You inspect the current market data, but the values have changed.
You rerun the strategy, but the result is different.
You examine the logs, but they don't contain the exact input snapshot used during the decision.
Now you are trying to reconstruct a historical event from incomplete evidence.
Determinism makes a different workflow possible.
Capture Decision Context
|
v
Restore Input Snapshot
|
v
Restore Initial State
|
v
Run Strategy
|
v
Compare DecisionIf the output differs, we have evidence of an inconsistency in the replay environment, implementation, or captured inputs.
If the output matches, we can investigate the actual decision rather than debating whether the software behaved differently.
This is particularly valuable when strategy behavior depends on multiple timeframes and several indicators.
Instead of asking why the system produced a decision that we cannot reproduce, we can ask why a reproducible decision was made.
That's a much better engineering problem.
10. Determinism Also Makes Backtesting More Honest
Backtesting is one of the most attractive parts of building a trading system.
We can evaluate a strategy against historical data and examine how it would have behaved.
But a backtest is only meaningful if it respects the information available at each historical decision point.
Consider a strategy evaluating the market at 10:05.
It must not use information that only became available at 10:30.
Otherwise, the strategy is benefiting from future knowledge.
This is commonly known as look-ahead bias.
It can make historical performance appear much better than what could have been achieved in live trading.
Determinism and look-ahead prevention are closely related, but they are not the same thing.
A backtest can be perfectly deterministic and still contain look-ahead bias.
It may consistently reproduce the same incorrect decisions.
Therefore, reproducibility is necessary for trustworthy testing, but it is not sufficient.
We must also verify that the strategy's information boundary matches what would actually have been available at the time.
We'll explore that problem in a dedicated article later in the series.
11. The Architectural Lesson: Make Decisions Reproducible
The deeper lesson from deterministic trading is not limited to financial markets.
It applies to any system where decisions must be explainable, testable, and recoverable.
Fraud detection.
Pricing engines.
Risk evaluation.
Recommendation systems.
Automated workflows.
In each case, a decision becomes easier to trust when its inputs and evaluation rules can be reconstructed.
For NERV Trade, determinism became an important architectural foundation because the engine would eventually need to support more than simple strategy evaluation.
It would need historical replay, simulation, testing, execution accounting, and recovery.
Those capabilities benefit from a decision-making process whose behavior is predictable under controlled conditions.
Before trusting a trading engine to execute a decision, we should be able to explain and reproduce how that decision was produced.
12. The Next Problem: One Candle Is Never the Whole Story
At this point, we have established an important requirement.
Given the same complete input snapshot, initial state, and evaluation rules, the strategy should produce the same result.
But there is another complication.
Trading decisions rarely depend on a single timeframe.
A five-minute chart might suggest a BUY.
A fifteen-minute chart might indicate consolidation.
The hourly trend might still be bearish.
And the four-hour chart might tell an entirely different story.
How do we combine those observations without accidentally mixing information from different points in time?
How do we ensure that higher-timeframe candles were actually available when the lower-timeframe decision was made?
And how do we preserve deterministic behavior when several timelines must agree?
Those questions led to the next major component of NERV Trade: multi-timeframe analysis.
That's where we'll continue the story.
Continue the NERV Trade Engineering Series
This is Article #3 in the NERV Trade engineering series, documenting the architectural decisions and engineering challenges involved in building a Java-based trading engine.
Previous: A Trading Bot Is Easy. A Trading Engine Is Not.
Next: One Candle Is Never the Whole Story: Building Multi-Timeframe Analysis.
Explore the NERV Trade article series
About NERV Trade
NERV Trade is part of NERV — Next-Generation Engineering for Runtime Velocity, an open-source engineering initiative focused on Java and Spring-based systems.
The project explores deterministic market analysis, multi-timeframe strategies, trade lifecycle management, execution accounting, durable persistence, broker integration, and operational safety.
Follow the project and other NERV libraries on GitHub .
This article discusses software engineering and trading infrastructure. It is not financial advice.
Post a Comment