Nexora was built from the study of real execution.

Research · Intelligence · Risk · Execution

Quantitative trading infrastructure

NEXORA HFT is a technology platform built for quantitative research, market analysis, algorithmic validation, risk supervision and trading automation.

NEXORA was not conceived as a commercial dashboard built around conventional indicators. It was born from a far more demanding question:

What really happens between an apparently profitable signal and its actual execution in a real market?

Answering it properly means studying much more than a strategy.

• Latency
• Spread
• Slippage
• Commissions
• Market depth
• Data quality
• Liquidity
• Market regime
• Microstructure
• Execution probability
• Queue position
• Broker behaviour
• Statistical stability
• Out-of-sample robustness
• Operational risk
• Differences between backtest and live execution
• Human behaviour

NEXORA is built around that reality.

Who we are

Infrastructure, not intermediation

NEXORA HFT develops technology infrastructure for quantitative and algorithmic trading. The platform brings research, statistical analysis, artificial intelligence, quantitative models, risk management, market observation and automated execution together in a common architecture.

• NEXORA is not a broker
• It does not hold funds
• It does not accept client deposits
• It does not manage third-party capital
• It does not promise returns

Capital stays in the accounts each user opens with their own brokers, FCMs or compatible providers. NEXORA provides the technology infrastructure used to analyse, validate, supervise and — when the user and the relevant infrastructure authorise it — automate certain operational decisions.

Our philosophy starts from one fundamental principle:

A strategy should not be considered valid because it produces an attractive curve. It should be considered valid only when it can survive independent data, real costs, latency, adverse execution and regimes different from those it was developed on.

That is why validation is not a secondary function of NEXORA. It is part of its core architecture.

From hypothesis to evidence

A correct prediction can lose money

NEXORA’s development began by observing problems that often stay hidden behind a conventional backtest. A strategy can make a correct prediction and still lose money. That can happen because:

• the spread absorbs the statistical edge
• the commission wipes out the expected margin
• the order arrives too late
• liquidity disappears
• the position enters behind a sizeable queue
• the market changes regime
• the model is no longer calibrated
• the provider delivers an incomplete picture of the market
• the backtester assumes fills that would never have happened
• latency turns a positive signal into a negative execution
• the operator changes the system’s behaviour under emotional pressure

That is why NEXORA considers it insufficient to analyse only buying or selling. The goal is to study the complete cycle:

Every stage can be measured. Every stage can fail. Every stage must be auditable.

Quantitative architecture

A majority vote, every vote measured

NEXORA is being developed as a distributed decision ecosystem. The architecture currently comprises 16 quantitative decision engines, 14 strategy families and 7 neural models or architectures.

On top of these sit specialised systems for:

• Market Regime Detection
• Signal Fusion
• Order Flow
• Volume Profile
• Liquidity Analysis
• Execution Quality
• Risk Orchestration
• Probability Calibration
• Reliability Mapping
• Evidence Processing
• Latency Monitoring
• Broker Behaviour Analysis
• Market Data Validation

In HFT MODERNO, entry is decided by a simple majority of the components that vote. A component without data does not vote: it abstains and records why. And no vote counts just for existing: each component’s hit rate is measured separately.

An opportunity can carry expected direction, probability, confidence, time horizon, expected edge, forecast cost, spread, estimated slippage, regime, liquidity, data quality, the model’s historical reliability, risk, contraindications and operational context. The central architecture can then analyse the combined evidence before authorising a trade.

One Brain

A coordination layer, not a neural network

One Brain is not a single neural network. It is a higher coordination layer across multiple specialised systems. Quantitative engines, strategies, neural models, market analysis, microstructure, risk and execution each produce independent information.

One Brain is designed to:

• normalise evidence
• compare models
• measure reliability
• detect contradictions
• identify the regime
• weight signals
• reduce the influence of degraded engines
• detect anomalies
• estimate opportunity quality
• coordinate risk
• supervise execution
• learn from observed results
• recognise when not trading is the better decision

The aim is to replace the traditional paradigm — indicator, signal, order — with a more demanding architecture:

Artificial intelligence and quantitative models

Complexity is not evidence of quality

NEXORA researches several families of models: statistical, probabilistic classification, gradient boosting, LightGBM, XGBoost, sequential models, LSTM, CNN-LSTM, Transformers where there is a real quantitative justification, online learning, regime detection, microstructure models, probabilistic models, reinforcement learning, PPO, DQN, experimental Q-learning and continuous calibration systems.

NEXORA’s philosophy does not assume that a more complex model is necessarily better. A neural network earns operational authority only when it shows a measurable advantage over simpler alternatives.

A lightweight statistical model that runs with minimal latency can beat a deep architecture that raises computational cost without a demonstrable improvement.

Every model must justify its presence. Complexity is not evidence of quality.

Institutional reference

No affiliation, and said by name

NEXORA does not belong to, is not sponsored by and has no affiliation with Citadel, Citadel Securities, Renaissance Technologies or the Medallion fund. Nor does NEXORA claim to have their strategies, models, algorithms or proprietary systems.

The reference lies in the publicly known engineering principles of institutional quantitative trading. Our goal is to come closer — in technological and methodological discipline, not in size, assets, infrastructure or results — to standards used in professional systematic-research environments.

The philosophy can be summed up in a few principles:

• Measure before assuming
• Validate before deploying
• Separate research from production
• Control risk independently of the strategy
• Optimise the critical path
• Make every experiment reproducible
• Record every important decision
• Constantly compare simulation and reality
• Drop models that stop working

Technology

Different problems, different tools

C++20 is used mainly in components where latency, determinism, performance and memory control are critical: market-data processing, signal computation, microstructure, Order Flow, execution engines, order management and quantitative computation.

Rust is a second strategic layer, focused on performance, memory safety, concurrency, event-driven processing, market-data adapters, replay, normalisation and high-availability services. The technology direction of FUTURES HFT PURE is a hybrid C++20 plus Rust architecture.

Python remains a research tool: data science, machine learning, training, backtesting, feature engineering, calibration, optimisation, statistical analysis, Monte Carlo and walk-forward. NEXORA’s philosophy avoids putting Python into the critical execution path unnecessarily where latency requirements are strict.

The visual interface is not the trading engine. The interface observes, controls and governs the engine.

The four operating systems

Kept separate on purpose

HFT MODERNO — an architecture for very short-term analysis and execution. It prioritises latency, liquidity, microstructure, signal quality, timing, anomaly detection, regime detection and execution quality.

AUTO LEGACY — a multi-timeframe system that keeps traditional and quantitative components developed during the ecosystem’s early evolution. It works on structure, multi-timeframe, trend, momentum, volatility and context.

HFT GUARDED — a system where capital preservation, filtering and risk control take precedence over trading frequency. Its priority is not to maximise the number of trades: it is to stop low-quality trades from getting through the architecture.

AUTO FUNDED — a configuration designed to operate under strict limits on loss, exposure and operational discipline, similar to certain evaluation environments and accounts with defined limits.

The four systems stay separate because mixing different operational goals within a single architecture makes it hard to measure their behaviour correctly.

NEXORA Futures HFT Pure

Microstructure, not derived candles

FUTURES HFT PURE is an independent architecture. It is not simply HFT MODERNO applied to futures contracts. It is designed around the microstructure information available in centralised markets.

• DOM
• Level 2
• Market By Price
• Market By Order where the provider allows it
• Time & Sales
• Trade Prints
• Queue Dynamics
• Order Book Imbalance
• Delta
• Cumulative Delta
• Footprint
• Volume Profile
• POC · VAH · VAL
• HVN · LVN
• Absorption
• Stacked Imbalance
• Liquidity Voids
• Sweep Detection
• Microprice
• Book Pressure
• Fill Probability
• Adverse Selection
• Queue Persistence
• Order Flow Velocity

All of this lets Futures HFT Pure analyse market microstructure directly instead of relying only on candles or derived indicators.

Features that depend on Market By Order can only be enabled when the provider actually supplies that information. NEXORA does not simulate MBO and present it as real MBO.

Rithmic

Development kit and test environment

NEXORA is building its Futures infrastructure around professional market-data and execution providers. Rithmic is one of them.

The integration process evaluates R|API+ C++, R|API+ .NET for auxiliary tools, R|Protocol API, secure WebSocket, Protocol Buffers, market data, order management, execution reports, historical data, account information, orders, cancellations, replacements, ACKs and fills.

«NEXORA Futures is being validated using Rithmic’s official development kit and its Rithmic Test environment, through professional market-data and execution interfaces. Access to production environments is subject to the corresponding authorisations and processes.»

NEXORA does not claim official certification, partnership or production integration until those processes have been completed and documented.

Market data as infrastructure

Raw material, not chart decoration

A quantitative infrastructure needs to know what happened, when it happened, what information was available, what the algorithm actually received, how long it took to receive it, how long it took to process it, when the decision was made, when the order went out, when it was acknowledged, when it was filled, at what price, what depth existed, what liquidity was available, what slippage occurred and what the decision really cost.

That is why FUTURES is designed around a normalised event bus able to record several clocks:

• Exchange Timestamp
• Provider Timestamp
• Receive Timestamp
• Processing Timestamp
• Decision Timestamp
• Send Timestamp
• ACK Timestamp
• Fill Timestamp
• Cancel Timestamp
• Replace Timestamp

Without that information, the word HFT loses much of its technical meaning.

Replay and backtesting

The right question is not what would have happened

A traditional backtest usually answers: “What would have happened if I had bought here?” For NEXORA that question is not enough.

Could that order really have been executed at that moment, with that latency, that depth, that queue, that liquidity and those costs?

That is why the Futures architecture is moving towards event-driven replay, order-book reconstruction, queue modelling, latency modelling, partial fills, execution models, spread and commission modelling, slippage, realistic costs, fill probability, adverse selection and market-impact hypotheses.

The validation chain should come close to:

The goal is to reduce the gap between expected and observed performance as far as possible.

Quantitative validation

The goal is to try to destroy the hypothesis

An internal result should never be considered sufficient on its own. Strategies must be assessed through an appropriate combination of in-sample research, out-of-sample tests, walk-forward validation, purged validation where appropriate, Monte Carlo, stress tests, parameter sensitivity, regime analysis, ablation tests, cost, latency and fill analysis, probability calibration, forward testing, shadow execution and comparison of real against expected.

• Profit Factor alone is not sufficient evidence
• Win Rate alone is not sufficient evidence
• Sharpe Ratio alone is not sufficient evidence
• A visually attractive curve is not sufficient evidence

The goal of validation is not to confirm a hypothesis. It is to try to destroy it. If it survives, our confidence grows. If it does not, it must be discarded or redesigned.

Risk Orchestrator

A risk layer able to overrule the strategy

Risk Orchestrator can assess exposure, drawdown, volatility, correlation, liquidity, spread, slippage, execution quality, concentration, regime, data quality, model reliability, consecutive losses, anomalies, provider status, infrastructure status, session risk, account risk and operating limits.

A strategy can request a trade. Risk can reject it. The survival of the system takes priority over any single signal.

Execution Layer

A discipline of its own

The execution layer turns a theoretical decision into a real order as efficiently and as controllably as possible. It can take into account order type, market, limit, stop, liquidity, spread, expected slippage, queue position, timing, cancellations, replacements, timeouts, retries, duplicate-order protection, reconnection, partial fills, broker confirmation, exchange confirmation and the real state of the position.

A good signal executed badly can become a bad trade.

Observability

From black box to auditable infrastructure

The infrastructure must be able to explain its own behaviour. The goal is that a trade can be reconstructed afterwards. Not just “the system bought”, but:

• This data arrived
• These engines produced this evidence
• These models produced these probabilities
• This was the regime
• This was the data quality
• Risk authorised this exposure
• Execution chose this order type
• This was the latency
• This was the fill
• This was the result

That turns a black box into an auditable infrastructure.

The story behind the system

Born from the opposite side

NEXORA was not born inside a large financial institution. It was born from the opposite side: from direct experience of running retail infrastructure and hitting, again and again, the limits that separate a theoretical strategy from a trade that can really be executed.

Before NEXORA there were:

• discarded strategies
• failed models
• lost accounts
• overtrading
• latency
• slippage
• calibration errors
• execution problems
• results that did not survive out of sample
• differences between simulation and production
• wrong assumptions
• human decisions that are hard to control under pressure

Instead of being hidden, those mistakes ended up becoming engineering requirements. Every failure produced a question. Every question produced a measurement. Every measurement produced a new layer of the system.

That process continues, because a serious quantitative system is never finished. It is constantly measuring, verifying, learning and recalibrating.

What NEXORA is not

Limits on the same level as capabilities

• It is not a broker
• It is not a bank
• It is not an asset manager
• It is not a custodian
• It is not a funding firm
• It does not accept deposits
• It does not manage third-party capital
• It does not guarantee profits
• It does not guarantee returns
• It does not guarantee that an algorithm will keep working
• It does not turn artificial intelligence into automatic profit
• It does not remove market risk
• It does not replace the operator’s financial responsibility

NEXORA does not promise to remove risk. It does not promise profits. It does not promise income. It does not promise future consistency. It does not promise that a historically profitable strategy will stay profitable. It does not promise that artificial intelligence implies automatic superiority. It does not promise that a backtest necessarily represents the future.

Our obligation is different: to make the process more observable, more measurable, more verifiable, more reproducible and more controllable.

Transparency by design

An engineering property, not a marketing statement

A metric should be able to state its origin, its dataset, its period, its instrument, its version, its configuration, its costs, its model, its strategy, its broker, its methodology and its environment.

• A result without provenance has little value
• A Profit Factor without a dataset has little value
• A Win Rate without a trade count has little value
• A Sharpe without context has little value
• A backtest without costs has little value
• An impossible fill invalidates results
• A prediction without calibration has little value

A strategy that only works on the period it was built on is not sufficient evidence.

Responsibility and risk

What NEXORA cannot control

Trading and leveraged instruments carry a substantial risk of loss and may not be suitable for every trader. NEXORA provides software infrastructure for research, analysis, automation, supervision and operational control. NEXORA does not hold the user’s funds: accounts remain with the relevant broker, FCM or provider.

Execution also depends on external factors NEXORA cannot fully control: liquidity, market, exchange, broker, FCM, data provider, network, infrastructure, latency, slippage, gaps, rejections, partial fills, outages and extraordinary market conditions.

Historical, hypothetical, simulated, backtested, forward-tested or any other prior performance is no guarantee of future performance.

The user remains responsible for account selection, capital, leverage, configuration, risk, use of the software, authorisation of automation and their financial decisions.