The architecture, described in plain terms
This is a distributed system whose job is to be boring under pressure. Below is how it is structured, what each layer is responsible for, and how it behaves when something goes wrong.
Six stages between the market and your broker
The same pipeline runs for every account. What differs per account is scope, risk parameters and the broker at the end of it.
- Researcher
- Strategy
- Signal
- Client Routing
- Execution Infrastructure
- Broker
Illustrative architecture. Layer names describe the platform's processing stages, not live market activity.
Seven layers, each with one job
The platform is deliberately split so that a change in one layer cannot quietly alter another. Select a layer to see what it is responsible for.
Market Data Layer
A normalised ingestion layer turns multiple upstream feeds into one consistent internal representation, with health checks and fallbacks.
- Multi-source ingestion
- Normalised instrument model
- Feed health monitoring
- Automatic fallback path
Strategy Engine
Strategies are declarative definitions — instruments, conditions and lifecycle state — evaluated by a single engine rather than scattered scripts.
- Declarative strategy definitions
- Instrument scoping
- Lifecycle states
- Session & trading-hour awareness
Signal Distribution
A published signal is an auditable object with a validity window, routed only to accounts eligible for that strategy and instrument.
- Eligibility resolution
- Validity windows
- Per-account routing
- Full distribution audit trail
Risk Management
Risk is a gate, not a report. Rules are evaluated before an order exists, so a rejected signal never reaches the market.
- Pre-trade validation
- Position & exposure rules
- Per-account limits
- Documented rejection reasons
Execution Infrastructure
Execution runs on isolated infrastructure per account, so one account's activity never interferes with another's.
- Isolated execution per account
- Deterministic order construction
- Controlled retry policy
- Order state tracking
Monitoring
Signals, jobs, orders and positions are observable end to end — every state change is recorded and queryable.
- Signal-to-order traceability
- Job state history
- Live position view
- Operational alerting
Security
Access is role-based and consent-driven. Broker credentials are held only to maintain your authorised session.
- Role-based access control
- Explicit broker consent
- Scoped session handling
- Immutable audit log
Four constraints we hold ourselves to
These are engineering commitments, and they occasionally make the platform slower to change. That trade is deliberate.
Separation over convenience
Data, strategy, signal, risk and execution are distinct layers with defined interfaces. A change in one cannot quietly alter the behaviour of another, which is what makes the system reviewable.
Deterministic by default
Given the same signal and the same account state, the platform constructs the same order. Anything non-deterministic in an execution path is a defect, not a feature.
Fail closed, not open
When a dependency is unavailable or a check cannot be completed, the platform declines to act rather than guessing. Not trading is a safe outcome; trading on stale state is not.
Recorded before it is convenient
Every signal, validation result, dispatch and broker response is persisted. If we cannot explain why an order exists, the system is not doing its job.
What happens when something breaks
Any honest description of trading infrastructure has to cover this. Feeds drop, sessions expire and brokers reject orders — the question is what the system does next.
Session handling
Broker sessions are established and refreshed automatically within the authorisation you granted. A failed session stops execution rather than retrying blindly.
Feed degradation
If market data becomes unreliable, dependent strategies stop producing signals instead of acting on suspect input.
Retry policy
Order submission retries are bounded and idempotent, so a transient network failure cannot become a duplicate position.
Observability
Job state, signal lifecycle and order state are queryable end to end, which is what makes support answers specific rather than speculative.
No latency figures, no uptime percentage
Published millisecond figures and uptime percentages are meaningless without an audited measurement methodology, and most of the round-trip time in retail algorithmic trading sits with the broker and the exchange rather than with us. We would rather describe the architecture accurately than quote a number you cannot verify.
Technology risk is real: connectivity, feed, broker API and platform failures can all affect execution. No system can eliminate this, and our liability is limited as set out in the Terms of Service.
Ask us something specific
If you want to know how a particular failure mode is handled or how your broker's API is integrated, we will answer at whatever depth you want.
Trading involves substantial risk of loss and is not suitable for everyone. Past performance does not guarantee future results.