This is a financial & insurance problem we approach through our Platform to Platform service line.
The problem
Your bottleneck is not ideas. Analysts produce candidate factors and strategy variants continuously — a new rolling comparison, a residual against a fitted curve, a composite of three things that each almost work. The bottleneck is that every one of them becomes an engineering ticket, waits for a sprint, gets implemented by someone who did not have the idea, and comes back for a round of “that is not quite what I meant”.
The visible cost is cycle time. The larger cost is invisible: when testing an idea costs a week of someone else’s calendar, most ideas are never tested. Research throughput is set by the engineering queue, and the queue does not know which ticket contained the edge.
Why it’s hard
General-purpose code is the wrong authoring surface. Let analysts write production Java or Python and you have two bad options: a review gate that reintroduces the queue you were removing, or ungoverned code running against live capital. Most shops oscillate between the two.
The notebook-to-production gap reintroduces the queue. The common compromise — research in notebooks, reimplementation by engineers for production — means two implementations of every strategy, drifting apart silently. When live behaviour diverges from research behaviour, you cannot tell whether the strategy or the translation is wrong.
Speed without guardrails just produces flawed factors faster. An authoring layer that lets analysts compute over the full history will let them build leaking factors — features that read information from after the decision point — at research speed. The leakage guard has to live in the engine, or the authoring layer is a liability multiplier.
Models and humans have to coexist with an audit trail. Sometimes the human is right, and a production system needs the override. But an override applied as a configuration edit is untraceable: six months later nobody can say which outputs were model and which were judgement. That reconstruction is exactly what governance reviews ask for — RTS 6 requires a documented development and testing methodology, the PRA’s SS5/18 expects algorithm approval and inventories, and the FCA’s August 2025 multi-firm review found firms still falling short on controls and governance. An inventory is made of versions and attributions; if the platform does not produce them, compliance reconstructs them by hand.
Factor definitions change meaning under models built on them. When a factor definition is edited, every model that consumes it silently means something different. Unless factors are versioned as first-class objects, working out which version of a factor produced a given backtest is archaeology.
How we approach it
A purpose-built expression language for strategy authoring. Instead of exposing a code library, we build a domain-specific expression language over a unified data model: the averages, regressions, population comparisons and composites that factors and strategies are made of. An analyst writes the expression, the engine compiles and evaluates it, and no engineer is involved. This is the mechanism that moves testing an idea from a sprint to an afternoon — and it changes which ideas get tested at all.
Guardrails in the engine, not in review. The engine enforces the information boundary: a factor is computed excluding future values relative to the point being modelled, whatever the expression says. Authoring speed and backtest integrity stop being a trade-off.
Everything versioned, every output attributable. Model versions are recorded against every output. Human overrides are recorded events carrying who and when. Hybrid modes — machine output, human-curated output, or a blend — are explicit states, not conventions. In BetrBets, every tip published to a user carried the model version that produced it or the named override that replaced it; the same discipline is what a trading inventory needs.
The authoring layer feeds the validation gate. A strategy authored in the language goes into the same walk-forward replay and A/B machinery described in our backtesting and simulation use case, so faster authoring does not mean weaker validation. The two are one pipeline.
What we do not do. We do not write your strategies. The alpha, the overrides and the risk appetite are yours; the engagement builds the layer that lets your analysts ship them safely. We would also not build the language before the unified data model exists — an expression language over inconsistent data is a faster way to compute nonsense.
What it takes
A unified data model first. The language is only as expressive as the structure it computes over. If your instrument, event and derived data live in per-source shapes, unification is the first phase and the language is the second.
Factors as versioned, first-class objects from day one. We learned this the expensive way: in the racing engine, models were versioned and factors initially were not, and reconstructing which factor version produced a given backtest became archaeology. It is cheap to do from the start and miserable to retrofit.
A promotion policy. Who moves a strategy from authored to validated to live, against what criteria, recorded where. This is a decision for your trading and compliance functions, not for engineering, and the platform is built against it — so it needs to exist early.
Analyst adoption, which means respecting their tools. Model development stays in Python, R or whatever your team is fluent in. The language is for factor and strategy definition, not a replacement modelling framework; asking researchers to abandon their stack is how authoring platforms die unused.
Where this has been done
Delivered — in racing and in a consumer betting product, not on a financial desk. The expression-language factor engine ran in production for several years inside a racing analytics platform we built and operate, and removing engineering from the modelling loop is the documented outcome of that work — see the racing probability modelling case study. The versioned-models-with-recorded-overrides pattern, including hybrid machine/expert output, shipped in BetrBets, a tipping product we built and later sold, which executed authorised bets against Betfair Exchange.
The transfer argument is that a trading factor and a racing factor are the same object: arithmetic over a point-in-time data model, authored by a domain expert who is not an engineer, needing leakage guards, versioning and an audit trail. We have not shipped this platform for a financial trading desk, and the page says so rather than implying it.