Execution flow
The order lifecycle is what happens to an order. This page is which system does it, which matters when you are trying to work out where something went wrong.
The services in the path
| Step | Service | Responsibility | Hands on |
|---|---|---|---|
| 1 | Strategy service | Strategy definitions, lifecycle, deployments | A deployed strategy |
| 2 | Evaluation | Conditions against market data at candle close | A signal |
| 3 | Order execution | Risk pipeline, sizing, derivatives, reconciliation | A validated order |
| 4 | Broker gateway and BFF | Adapter selection, risk controls, client risk monitor | A venue-shaped order |
| 5 | Egress router | Controlled outbound path, static egress IP | An outbound request |
| 6 | Your broker or exchange | Execution | Fills |
Fills then travel back up the same chain: into the position ledger, then P&L, then risk metrics, then notifications.
Supporting services: market data ingestion (price data), ref-data (instruments, venues, calendars, adapter catalogue, entitlements), corporate actions, remote gateway (external signal ingress), stream (real-time updates to the interface).
Where each control lives
Knowing which layer owns a control tells you where to look when it behaves unexpectedly.
| Control | Owned by |
|---|---|
| Entry / exit conditions | The strategy definition, evaluated at candle close |
| Stop-loss, take-profit, trailing | The strategy definition, executed by the exit engine |
| Trading window | Order execution, pre-placement |
| The nine risk gates | Order execution, per order |
| Cooldown after a losing streak | Order execution, computed per evaluation |
| Margin validation | Order execution, for margined instruments |
| Derivatives kill switch | Order execution, fail-closed |
| Adapter selection and order shape | Broker gateway, from the ref-data adapter catalogue |
| Broker-side risk controls | Broker gateway / broker BFF |
| Egress identity | Egress router |
| Position ledger and reconciliation | Order execution |
| Capital allocation and accounting | Strategy service and the capital ledger |
| Entitlements | Ref-data, per tenant and plan |
Two isolated tracks
Paper and live are separate all the way down:
One strategy definition is shared by both tracks. Everything downstream of it is separate.
| Paper track | Live track | |
|---|---|---|
| Capital | Simulated | Real allocated capital |
| Fills | Internal simulator | Broker adapter, then the venue |
| Position ledger | Paper | Live |
| Performance summary | Paper | Live |
| The nine risk gates | Enforced | Enforced |
Nothing crosses between the two.
The gates run identically on both tracks. That is what makes a paper run a real test of your configuration rather than only of the strategy. See Paper trading
Nothing crosses: not capital, not positions, not history. A position opened in one mode runs to its exit conditions in that mode.
Adapter selection
The order's shape is not hard-coded. It is resolved from the adapter catalogue in reference data, which carries per-broker endpoints, field mappings and venue capabilities.
Two consequences worth knowing:
A broker is added by adding data, not code. Which is why the platform carries adapters for more than twenty venues.
Your connect screen is built from the same catalogue, filtered to what your tenant has enabled. A broker you cannot see is one that is not enabled for you, not one that does not exist. See Connect a broker.
The egress path
Orders leave through a controlled outbound path, and your account can be assigned a static egress IP.
That exists so a locked-down exchange API key is usable: restrict the key to one source IP, allowlist the platform's egress, and a compromised key is far less dangerous. See Connect a broker.
Where derivatives diverge
Derivative strategies route on their own spine rather than through the equity materialiser:
| Path | State |
|---|---|
| Entry, paper | Implemented |
| Entry, live | Refused, the safety gate, because live exit is unimplemented |
| Exit, paper | Implemented, with coordinated group close |
| Exit, live | Not implemented, the reason entry is refused |
| Expiry handling and worker | Implemented |
| Kill switch (global / tenant / strategy) | Implemented, fail-closed |
| Operator force-close | Implemented |
| Margin reservation and validation | Implemented |
| Reconciliation and projection | Implemented |
The kill switch's fail-closed behaviour is a genuine safety property: if the halt state cannot be read, new derivative entries are blocked rather than allowed. See Derivatives
Remote-strategy ingress
Externally-generated signals enter through the remote gateway, then take the same path from evaluation onward, the same risk gates, the same sizing, the same ledger.
Three ingress paths: push (HMAC-signed), pull (platform polls your URL), and a Telegram webhook. See Remote strategies.
A remote strategy is not exempt from anything. Its signals are gated identically.
Failure and recovery
| Failure | Behaviour |
|---|---|
| Market data gap | Conditions cannot be evaluated on the missing bar |
| Broker rejection | Recorded with the reason; the strategy continues |
| Venue outage | Orders do not place. Exits do not place either |
| Platform restart | Signals carry stable idempotency keys, so no duplicate orders |
| Cooldown across a restart | Computed, not persisted, a restart does not skip it |
| Malformed risk configuration | Fails open, no rules enforced, never a hard block on trading |
| Unreadable derivatives halt state | Fails closed, entries blocked |
| Position/order divergence | Reconciliation |
The risk-config parser fails open so a bad payload can never block a strategy trying to exit. The derivatives kill switch fails closed so an infrastructure problem cannot let a leveraged entry through.
Each is the safer direction for what it guards. The consequence for you is that a risk configuration you believe you set may not be in force, verify it on the risk panel. See Which limits are on by default.