Trade Desk

Desk infrastructure for trading operations and treasuries: position and profit-and-loss truth, market-data ingestion, order and execution records, risk limits with real-time checks, and end-of-day reconciliation against broker and custodian statements. Status: preview — components proven in engagements, packaged desk deployments scoped per client.

The gap between the exchange and the desk

Exchanges run microsecond infrastructure. The desks trading on them frequently run on spreadsheets refreshed by hand, positions reconciled at day-end by whoever is most junior, and fat-finger limits that exist in culture rather than in code.

That mismatch is not about sophistication — the people running these desks are usually excellent at the trading. It is that position truth, risk visibility and reconciliation are infrastructure problems rather than trading problems, and nobody on the desk has infrastructure as their job.

The symptoms are consistent: profit-and-loss as a morning surprise, exposure known approximately, and the question “who changed this position?” having no answer at all.

What the platform provides

• A position engine built as a ledger. Every trade, corporate action, fee and adjustment an immutable event; positions and profit-and-loss computed as projections you can rebuild and prove. It is the fintech architecture wearing a trading jacket, and it means any number can be replayed to its source.
• Market data with staleness alarms. Feed ingestion, snapshot history, and loud alerts when a price stops updating — because a stale price presented confidently is more dangerous than a missing one.
• Order and execution records. The full trail per broker, so the reconstruction of any day is a query.
• A risk layer. Exposure and concentration continuously, pre-trade limit checks where broker integration allows and alerts always, plus value-at-risk and scenario simulation where mandates require them.
• End-of-day reconciliation. Broker and custodian statements against internal truth, breaks queued with reasons rather than dumped as a list.

Why positions belong in a ledger

Because the hard questions on a desk are all historical. What was our exposure at the moment that trade went through? Why does the broker’s position differ from ours by 200 shares? What did this strategy actually earn, net of costs, since inception?

Snapshot systems answer with today and a shrug about the past. Event-sourced positions answer with arithmetic, because the past is the data model rather than a memory of it. The same argument that governs ledger design applies here with more urgency, because the numbers move faster and the counterparty keeps their own set.

The honest scope

This is infrastructure, not advice. I do not build strategies, generate signals, or offer anything resembling investment recommendations. Nothing the system outputs is advice, and I am not licensed to make it so. Your decisions are yours; the system’s job is to make sure they are made against accurate positions.

Not latency-critical execution. High-frequency infrastructure is a different specialism with different engineering, and pursuing it here would be selling you something I should not. Most desks asking about latency actually have a truth problem — they cannot say what they hold — and solving that changes more than a faster route ever would.

Preview status is real. The components run in engagements: the portfolio system built the event-sourced position core, risk modelling built the simulation layer. What is still maturing is packaging that into something deployable without me in the room, and the tag stays until that is true.

Where it fits

Proprietary desks, treasury operations inside larger businesses, and family offices running active books — the tier where real money moves daily and the institutional platforms are priced for institutions.

The signal that it fits: your end-of-day position agreement currently depends on a person and a spreadsheet, and the person has never taken two consecutive weeks off.

What gets built first

Position truth before anything else. Trades and corporate actions flowing into the event store, positions computed and compared against the broker daily. Until those two agree without human intervention, every risk number computed on top is decorated guesswork.

Then reconciliation discipline. Breaks categorised by reason — timing, corporate action not applied, fee treated differently, quantity mismatch — and aged so nothing sits unresolved for a fortnight because it was nobody’s specific job.

Then the risk layer. Exposure and concentration first because they are computable from positions alone, then value-at-risk, then simulation where the mandate justifies the complexity.

That order is deliberate and I will hold to it even when the risk dashboard is the thing that was wanted first. Risk metrics computed on positions that do not reconcile are worse than none, because they carry false authority into decisions.

What it will not do

It will not tell you what to trade, it will not optimise execution, and it will not replace your risk officer’s judgment. It also will not rescue a desk whose real problem is that two people believe they own the same book.

What it does is make the desk’s position an established fact, continuously, so that every conversation above it — risk, allocation, performance, audit — starts from agreement rather than from reconciliation.

Related reading

/work/portfolio-system — the position engine in production · /work/risk-modelling — the simulation layer · /products/portfolio-manager — the advisory-side sibling · /industries/wealth — the trade context

The end-of-day question

Can you state your positions right now, from the system, and would the broker agree? If either half needs a person to check, that is the conversation. /contact — profit and loss should be a fact rather than a feeling.