The metrics a broker could not buy
A brokerage could only see what its trading platform chose to report about its traders, which was not much and not the right things. Their own analysts had worked out what they actually needed to watch. This is the system that measures it, sitting between the broker and its clients without either side having to change how they work.
What was wrong
Brokers largely see their traders through whatever their trading platform surfaces, and MetaTrader surfaces a fixed and fairly shallow set of figures. That is enough to know what happened and rarely enough to know what is happening — which trader is drifting from their stated strategy, which account is behaving unlike itself this week, where a position warrants a conversation before rather than after. The firm's senior analyst had defined measures that would answer those questions. Nothing they could buy implemented them.
What made it awkward
- The measures themselves are the client's intellectual property and the reason the system is worth having. They are not described here, and that constraint shaped the build as much as any technical one.
- It had to be invisible from both sides. Traders carry on in the platform they already use, and nothing about the broker's existing arrangements could be disturbed to accommodate it.
- Financial data, so a figure that is merely probably right is worthless. Anything the system reports has to be reproducible and explainable after the fact, because decisions get taken on the strength of it.
- The definitions were expected to change. Analysts refine what they measure, and a system where refining a measure means a developer and a release is a system that stops being refined.
What I built
- An ingestion layer that reads trading activity continuously, without traders changing anything about how they work or noticing that it exists.
- A calculation engine implementing the analysts' measures, built so a definition is configuration rather than code — the people who own the measures can change them without waiting for me.
- An API the firm's own tools read from, which is where the numbers stop being mine and become theirs to present however they like.
- Thresholds that raise something for a human to look at, so the system prompts a conversation rather than taking an action on its own.
- A full history of every calculation, so any figure can be reproduced months later against the inputs it was derived from.
Decisions worth explaining
Measures as configuration, not as code
The analysts own the definitions and will keep refining them. Hard-coding the first version would have made every refinement a development task, and the honest outcome of that is that refinement stops.
The trade-off: A configuration layer is more to build and more to get wrong than a hard-coded formula, and it needed validation of its own so a bad definition fails loudly instead of quietly producing a plausible number.
Flag for a person rather than act automatically
These measures inform decisions about people's accounts and livelihoods. A system that acts on its own would need to be right in a way no system is, and would put the firm behind an automated decision it could not explain.
The trade-off: It needs somebody to read what it raises. The value depends on that habit forming, which is not something software can guarantee.
Every calculation kept, not just the current answer
A number that cannot be reproduced is not evidence. If a decision gets questioned in six months, the firm has to be able to show what was measured, when, and from what.
The trade-off: Considerably more storage and a slower path for historical queries than storing only the latest value.
An API rather than screens
The firm had people and tools for presentation and none for this. Building an interface would have duplicated what they already had and put me in the way of their own analysts.
The trade-off: Nothing is usable until something consumes it, so there was a stretch with real output and nothing to look at.
How it ran
First weeks
Working through the measures with the analyst until they were specified precisely enough to implement, which took longer than expected and was the most valuable part.
Months two to five
Ingestion and the calculation engine, checked against periods the analysts already knew the right answers for.
Months six to nine
The API, the configuration layer, and the history that makes every figure reproducible.
Final months
Thresholds, hardening, and handover to the team who run it.
What I would do differently
I started building before the measures were pinned down as tightly as they needed to be, on the assumption that the details would settle as we went. They did settle, but some of them settled differently to how I had built for, and I rewrote work that a longer conversation at the start would have got right the first time. On a system whose entire value is the precision of its definitions, the specification was the wrong place to move quickly.