Complexity has a price

Fourth in the series. Last time we showed how we hold a vast universe of factors in view at once — more than a quarter of a million risk drivers — and capture how they move together without the mathematics collapsing. Across the first three pieces we have kept making the same quiet admission: none of this comes free. Pricing each product as written, replaying real market history, carrying the whole universe rather than a convenient slice of it — each choice has a cost. This piece is about that cost: what the accuracy actually takes to produce, and why the bill never reaches your desk.

Quantifying risk properly is expensive. It is tempting to think the expense is mostly the model — that once you have built a good one, the rest is just pressing "run." For a handful of liquid shares, that is close enough to true. For a real wealth portfolio it is wrong, and the cost it overlooks falls in two places a client never sees: the data we have to gather and the computation we have to perform. Both are large. The only question worth asking is who pays them.

We answered that at the start. We do.

The price in data

The first cost is paid before a single calculation runs.

We explained in an earlier piece that full repricing is expensive less in money than in data — and this is what we meant. To value an instrument correctly, you have to describe it completely, and a complete description is a demanding thing to assemble.

For a structured product, that means the entire payoff: every barrier, every conditional coupon, every call date, every reference to an underlying asset, exactly as the term sheet sets them out. Leave one clause out and you are no longer pricing the product the client owns — you are pricing a simpler thing that happens to share its name.

Bonds make the same demand with less drama. A bond looks plain until you meet its variants — variable coupons, step-ups, contingent conversions, amortising schedules, embedded options, day-count conventions that differ from one market to the next. Each flavour has its own complete schedule of what is paid, and when, and under what conditions; to carry a bond's value across thousands of possible futures, we need the whole of that schedule, not the gist of it.

Here is the part that matters to you and it is the whole point of doing it this way. You assemble none of it. You give us an identifier — the same code your custodian already uses — and we go and find the complete specification, in all its awkward and tedious detail, and we keep it current as the world revises it. The instrument's complexity stays on our side of the line.

The price in computation

The second cost is paid in full every night.

We described the overnight run earlier in the series — roughly 1.5 billion calculations, finished before sunrise, the answer waiting in about half a second when you ask. This is the article in which to say what it takes to make that true.

Once we hold a faithful description of every instrument, each one must be put through its paces — not once, but against the whole range of market conditions we test it under. The cost of a single pricing varies enormously: a plain share is revalued in about a tenth of a second, while a complex multi-underlying structured product can take minutes on its own. Multiply that across every instrument in every portfolio, against every scenario, and you arrive at the figure we keep returning to — the roughly 1.5 billion repricings we run each night, spread across 600 workers computing in parallel.

The clock is the unforgiving part. The run has to finish before the trading day opens in Singapore, so that an advisor in Asia finds current numbers already waiting — and yet it must start as late as it can, to capture the fullest possible picture of the day that has just closed. Every night, the whole operation is threaded between those two fixed points.

The reason for all this night effort is speed in daylight. Whatever can be worked out in advance, we work out in advance, and store. We precompute as much as the night allows precisely so the complexity never lands on you: when the question comes — what could this portfolio lose, where is the risk concentrated, what happens if rates move — the heavy work is already done, and the finished answer is all you ever see. It returns in about half a second rather than half an hour. And because the live questions cannot all wait for the next night's run, some of those pricing instances are kept awake through the day, ready to compute on demand.

Built from many specialised services, on the cloud

None of this runs as one enormous program. The engine is built from a couple of dozen specialised services, each responsible for a single job — one gathers market data, another constructs the interest-rate curves, others price the instruments, generate the scenarios, and check the results before any of it is released. It is, in effect, the chain we described in the first piece, with each link a service in its own right.

They can do that because the engine runs on cloud infrastructure rather than a fixed bank of machines. The amount of computing power is not settled in advance. When demand climbs — more portfolios, more questions, a market in turmoil that has everyone asking at once — we bring more power to bear, and release it when the surge passes. High demand is met with more computation rather than longer waits, so a busy day does not have to become a slow one.

Everything described here is built for a single purpose: faithfulness — to the term sheet, to the market, to the question you asked. But give it the wrong input and it will hand back a flawless calculation of the wrong answer. Keeping those inputs sound — sourcing them, cleaning them, catching the errors before they spread — is a discipline of its own, and it is where the next piece in this series begins.