Oxelbarrow replaces manual entry timing with a rules-based model that scales position size against measured volatility, rather than against sentiment or headline reaction.
Day trading rewards consistency, but consistency is difficult to sustain across hundreds of discretionary decisions. Fatigue, recency bias, and reaction to short-term price movement accumulate quietly, and the deviation from a stated strategy widens with each session.
Oxelbarrow was built to remove that drift by encoding entry criteria into a fixed, auditable rule set — one that executes identically on session one hundred as it did on session one.
The model does not attempt to predict direction. It attempts to size and time entries so that capital is deployed in proportion to measured risk, following a defined conditional structure: if realised volatility exceeds a rolling threshold, the model reduces tranche size; if it contracts below that threshold, the model increases it within a capped range.
The platform is structured around three operational concerns: how quickly data is processed, how risk is contained when conditions change, and how the system behaves as instrument count grows.
Market feeds are ingested on a streaming basis with sub-second internal processing latency, so sizing decisions reflect current conditions rather than a stale snapshot from the previous interval.
Hard caps on tranche size, instrument exposure, and daily deployment sit beneath the predictive layer, so a model misread cannot translate into unbounded position size.
The ingestion and decision layers are separated, which allows additional instruments or data sources to be added without reworking the core entry logic.
Price, volume, and order book data are pulled from connected sources and normalised into a consistent schema before any calculation runs against them.
Volatility and depth inputs are passed through the entry model to produce a tranche recommendation, timestamped and stored for later audit regardless of outcome.
The recommendation is checked against account-level constraints, then submitted as an order if, and only if, every constraint clears.
Connections use read/trade-scoped API keys that you generate and revoke from your own brokerage account. Oxelbarrow never stores raw login credentials, and keys are encrypted at rest.
Internal processing from data receipt to tranche recommendation runs in the sub-second range under normal feed conditions. Order submission time then depends on the connected broker's own execution speed, which sits outside our control.
Yes. The rolling volatility window, maximum tranche percentage, and daily deployment cap are configurable per instrument, within the platform's published safety bounds.
No. The model manages the size and timing of capital deployment relative to measured volatility; it does not forecast price direction and carries no guarantee of profit.
If the ingestion layer loses a feed beyond a configured timeout, pending tranche instructions for that instrument are held rather than executed on incomplete data.
Security note: all account data is encrypted in transit using TLS 1.2 or higher. Access logs are retained for audit purposes and can be reviewed on request through your account dashboard.
Account setup and API key linking typically take under fifteen minutes once documentation has been reviewed.