Selected Work

Bloomberg2015 – 2026

Redesigning Bloomberg's fixed-income benchmark calculation system

A from-scratch redesign of the engine that calculates the fixed-income benchmarks used across entire Bloomberg's ecosystem, the project I'm proudest of, and one I designed end to end.

The problem

Bloomberg's fixed-income benchmark calculations feed a large number of downstream applications, anywhere a client needs to know how a bond or a portfolio of bonds is behaving relative to a benchmark. These applications are highly sensitive to benchmark calculations, which became a real constraint on how the platform could evolve. Every fix had to be made without breaking correctness.

Constraints

  • Correctness comes before speed. A faster benchmark calculation that's occasionally wrong is worse than a slow one that isn't — the output is used directly in financial analysis, so silent errors are the failure mode that matters most.
  • Consistency across consumers. The same benchmark numbers had to stay consistent across every Bloomberg application that reads them, which ruled out a rewrite that only worked for one use case.
  • No clean-slate luxury. The redesign had to happen underneath a live system, not beside it.

What I designed

The design of this system — the calculation architecture and the validation approach around it — was mine end to end. Two pieces mattered most:

  1. A redesigned calculation engine, restructured to remove the bottlenecks that were driving latency, while keeping the same guarantees the rest of the platform depended on.
  2. A validation and reconciliation framework that runs alongside the calculations themselves, catching discrepancies before they reach production rather than after a client notices them.

The reconciliation layer isn't a bolt-on — it sits in the critical path and is part of why the redesign is trustworthy enough to ship.

The trade-off

Building a verification layer alongside the calculation engine is, on paper, extra work that doesn't move the latency number. In practice it's what made the latency work shippable at all: it's much easier to redesign a calculation engine aggressively when you also have an independent system checking its output against expectations. The reconciliation framework effectively bought the confidence needed to be more ambitious with the performance redesign, rather than being a cautious afterthought.

85% reduction in processing latency
15% fewer post-deployment defects, from the reconciliation framework

Impact

The redesign cut processing latency by 85% while improving both scalability and reliability, and the accompanying validation and reconciliation framework reduced post-deployment defects by 15% — protecting the correctness of the analytics consistently across every Bloomberg application consuming that data. It's the project on my record where the architecture, the trade-offs, and the outcome are most fully my own.