Algorithmic Trading Infrastructure: Data, Signals, Risk, and Execution Boundaries
A practical map of algorithmic trading infrastructure: market-data ingestion, signal generation, decision gates, risk controls, execution boundaries, and observability.
Algorithmic trading infrastructure is the set of systems that turns raw market events into evidence a trading team can inspect, test, and govern. The important part is not the number of services: it is whether every transition has an owner, a data contract, and a way to explain what happened later.
Barfinex uses a five-service model to make those boundaries explicit. This page focuses on the infrastructure itself rather than on any particular strategy.
The infrastructure chain
A useful way to reason about the stack is as a sequence of responsibilities:
| Layer | Question it must answer | Barfinex surface |
|---|---|---|
| Market access | What happened at the venue, and when? | Provider, exchange catalog |
| Normalization | Can different venues be compared through one contract? | Provider |
| Signal generation | What observable condition did the strategy detect? | Detector, signals |
| Policy admission | Does the immutable candidate satisfy deterministic admission rules? | Advisor |
| Execution, risk, and sizing | Is the candidate allowed under current truth, and how should the governed order lifecycle proceed? | Inspector |
| Broker/venue evidence | What did the broker or venue actually accept and fill? | Provider boundary and venue-confirmed facts |
| Observation | Can an operator reconstruct the decision path? | Studio and audit-oriented records |
Keeping these responsibilities separate reduces a common failure mode in automated systems: a single component silently changing the meaning of data, strategy intent, and risk at the same time.
Data quality is part of infrastructure
A strategy cannot be more reliable than the data contract beneath it. For each source, infrastructure should make at least five facts inspectable:
- Venue and instrument identity — which market produced the observation.
- Event time and receive time — whether latency or clock drift could matter.
- Normalization rule — how symbols, units, book levels, or candles were transformed.
- Freshness — whether the value is current enough for the decision horizon.
- Provenance — which source produced the evidence used by the strategy.
The data-feed catalog, markets, and Provider API boundary describe the public side of this data layer.
Signals are evidence, not orders
Detector owns strategy logic. A signal should identify the condition that fired, the inputs used, and the strategy configuration that produced the candidate.
That distinction matters because a signal can be statistically interesting while still being unsuitable to trade. Spread, liquidity, account state, portfolio exposure, and operational health may all invalidate the action without invalidating the signal itself.
See signal context and the Detector API reference for the public contracts around this stage.
Admission and risk are different jobs
Barfinex deliberately keeps Advisor small. Advisor does not invent a new trade thesis or resize the position. It records deterministic ADMIT or REJECT policy decisions over immutable candidate and evidence inputs.
Inspector owns the later execution/risk boundary: it resolves current truth, computes final size, applies exposure and account constraints, and owns the governed order lifecycle. Approved order mutations still pass through Provider, the sole broker/exchange boundary.
Separating admission from risk gives an audit trail a useful answer to two different questions:
- Was this candidate structurally eligible?
- Was it acceptable under the current execution and risk state?
What good infrastructure should make observable
A production trading stack should let an operator reconstruct:
- the market evidence available at decision time;
- the exact strategy version that produced the candidate;
- the policy result and its reason;
- risk constraints in force at the time;
- the requested execution intent versus venue-confirmed order/fill truth;
- failures, retries, stale data, and degraded dependencies.
Without that chain, a backtest, dashboard, or PnL number may be impossible to explain after the fact.
Build-versus-buy questions
When evaluating infrastructure, ask more specific questions than “does it support trading?”:
- Can the same instrument be identified consistently across venues?
- Are timestamps and units normalized deterministically?
- Can strategy code be versioned independently from risk policy?
- Is a rejected candidate still observable for later analysis?
- Can a risk rule block execution without rewriting strategy logic?
- Are private credentials and account data isolated from public surfaces?
- Can every order and fill be traced back to the evidence that caused it?
Those questions are useful whether you build your own stack or use Barfinex components.
Related reading
- Architecture — service boundaries and flow.
- Provider API — public gateway contract.
- Advisor overview — deterministic admission.
- Inspector risk policies — final execution and risk governance.
- Trading research platform — how researchers use the infrastructure before operational deployment.
Infrastructure can improve consistency and auditability, but it cannot make a strategy profitable or eliminate execution risk. Review the risk disclaimer before operational use.