Automated Trading Intelligence: From Market Evidence to Governed Decisions
How Barfinex turns market evidence into structured decision context while keeping strategy logic, deterministic admission, and risk authority separate.
“Automated trading intelligence” is useful only if the word intelligence means explainable evidence and decision context—not a black box that silently turns data into orders.
In Barfinex, automation is split into distinct responsibilities. Detector owns the strategy rationale, Advisor owns deterministic policy admission, and Inspector owns final execution, sizing, and risk authority while submitting through Provider. That separation is the central idea of this page.
Intelligence starts with an evidence chain
Before asking whether a signal is bullish or bearish, a system should be able to answer:
- Which market observation triggered the strategy?
- How fresh was the data?
- Which strategy version evaluated it?
- Which supporting indicators or context were attached?
- Which policy decision admitted or rejected the candidate?
- Which risk state applied after admission?
That chain is more valuable than an opaque confidence score because it can be inspected when the market behaves differently from the training or test period.
What is automated in Barfinex
Detector: causal strategy logic
Detector evaluates configured conditions and creates a scored candidate. The strategy should be able to explain why it fired in terms of its own inputs.
See Detector rule engine and signal context.
Advisor: deterministic admission
Advisor is intentionally not an AI decision engine. It does not reinterpret the trade thesis. It validates immutable candidate/evidence requirements and records ADMIT or REJECT.
That small boundary makes it possible to distinguish “the strategy generated a candidate” from “the candidate was structurally allowed to continue.”
Inspector: execution and risk authority
Inspector handles final sizing, execution authority, and risk rules. A candidate can be valid from the strategy's perspective and still be blocked because of exposure, drawdown, account state, or other configured limits. Approved execution still goes through Provider, the sole broker/exchange boundary.
Where machine intelligence can help
Machine-learning or language-model tools can still be useful in a research workflow, but their role should be explicit. Examples include:
- summarizing large sets of market context for a human reviewer;
- clustering similar market regimes for research;
- ranking evidence for investigation;
- helping researchers explore documentation or historical observations.
Those uses are different from assigning an LLM hidden authority to create or approve an exchange order.
A practical decision record
For a candidate to be explainable later, a useful record might contain:
| Field | Why it matters |
|---|---|
| Instrument and venue | Establishes market identity |
| Observation timestamps | Exposes stale or delayed inputs |
| Strategy/version | Identifies the exact logic |
| Signal direction and score | Records Detector output |
| Evidence references | Shows what the policy checked |
| Advisor result | Records deterministic admission |
| Inspector decision | Records final risk, sizing, and governed execution authority |
| Provider/venue result | Separates requested intent from venue-confirmed order and fill evidence |
This record lets a researcher compare decision quality separately from execution quality.
What not to optimize for
A system becomes less trustworthy when it optimizes primarily for:
- the highest possible number of signals;
- a confidence number with no calibration history;
- an AI explanation that is not tied to the inputs used;
- hiding rejected candidates because they make dashboards look worse;
- rewriting risk constraints to preserve a strategy's preferred action.
The research goal is not to make every candidate tradable. It is to make every important transition explicit.
Explore the workflow
- Markets — underlying instrument context.
- Signals — public signal surfaces.
- Advisor overview — deterministic admission.
- Inspector overview — final execution and risk authority.
- Architecture — service boundaries.
Automation and machine intelligence can fail. Data quality, liquidity, latency, costs, regime changes, and model error remain material. See the risk disclaimer.