Home / Case Studies / MSR Live
Architecture & modernisation
MSRLive is the platform a mortgage business uses to work out what its loan portfolios are worth. That calculation started life as a spreadsheet and has been in daily use since 2017. We have been rebuilding it as modern software, one piece at a time, under one rule that outranked everything else: the answers must stay identical.
Performance benchmark
150,000loans valued in under 10 minutes
Run time: 8h+ manual → <10m cloud batchThis is the clearest difference between the spreadsheet and the platform. A portfolio of this size could not be valued in one pass before — it had to be broken into chunks by hand, and it tied up both the machine and the person running it for the rest of the day.
The same job now finishes in the time it takes to make a coffee, and produces the same answers it always did.
§ 02 // Zero tolerance for variance
“A tiny rounding difference is not a small problem. It is a correction to published figures.”
01. Published figures integrity
These portfolios are assets on somebody’s balance sheet. The figure this platform produces is the figure that gets reported, so “close enough” has no meaning. A rebuild that shifts a result by a fraction of a percent does not give you a slightly different answer — it gives you an answer that no longer agrees with everything the business has already published.
Strict parity criterion
02. Project decision rule
That shaped the entire project. Most modernisation work is judged on speed, cost and maintainability. This was judged on those too — but only after it had passed one earlier test: do the numbers still match?
Non-negotiable precedence
The spreadsheet had won. Years of small decisions were built into it, every one of them mattered, and none of them was written down anywhere else.
Rebuild the calculation piece by piece — copying it exactly rather than reinterpreting it — then run it on infrastructure that can grow without changing the maths.
The web application stayed where it was, because that is where the business rules and the record of who did what already live, and rewriting it would have added risk without adding value. Only the number-crunching moved. Large jobs were taken off the main system and spread across cloud computing that scales up when there is more to do, then releases when it is finished. Completed results are copied to a separate reporting database on a schedule, so looking at history no longer slows anyone down.
There was never a cutover weekend, because there was never a moment when the whole engine changed at once.
The same five steps ran for every part of the model. Nothing reached real use on the strength of ‘looking’ correct.
Parity & precision protocol
Zero-tolerance replication · tested at decimal precision
Enforcing 1:1 mathematical parity across active mortgage ledgers
Matching the original was not a testing phase at the end; it was a rule that shaped every decision along the way. Where the new tools behaved differently from the spreadsheet, we changed the tools — never the expectation.
That sometimes meant choosing the harder option. Where a standard, convenient method produced a technically correct result that disagreed with the original in the decimal places the business reports on, we used the method that agreed instead.
Calculations match the original execution order precisely, because reordering operations changes the least significant decimal position — and that decimal position is what the business reports to auditors and balance sheets.
Evaluation stack verified
Three completely separate mathematical realities in the original spreadsheet and preserved as three distinct states in the rebuild. An empty cell or missing value is strictly isolated and never quietly coerced into a numeric zero.
Explicit state preservation
Handled exactly the way the original calculations evaluated them, preserving idiosyncratic boundary conditions and month-end conventions that contemporary timestamp parsers would otherwise silently ‘correct’.
Historical timeline matching
The models and API naming conventions reflect the precise terminology loan officers speak out loud, avoiding developer abstractions that introduce cognitive friction or conceptual drift between teams.
Direct domain parity
System capabilities & runtime
Screens below are from a test environment. All client and portfolio data has been blurred.
Loan data arrives from different clients in different layouts and formats. The platform maps each one through a reusable definition and turns it into a single consistent form. Anything that fails a check is flagged for attention rather than dropped — because a portfolio that quietly loses rows still produces a confident, wrong answer.
A valuation ties a portfolio to a saved set of assumptions, each assumption set belonging to a particular version of the product, so the thinking behind any figure can always be traced back — months later, if need be.
Results are presented in the language of the industry rather than the language of the software: balances, rates, terms, loan-to-value and credit quality, with arrears broken down by how far behind a loan is and by who owns it.
Once a valuation is signed off it becomes eligible to be copied into a separate reporting database, on a schedule. Because people make mistakes, the copy can be undone and the valuation reopened.
Rather than valuing a portfolio once, the platform can price it across a whole grid of scenarios — different regions, loan types, sizes and interest-rate movements. One definition turns into a large number of valuations, which is exactly the kind of work the rebuilt system was designed to absorb.
Long jobs can be watched while they run: how much is done, how much is left, what kind of work it is and when it started.
Nothing was adopted for novelty. The shape of the system follows the shape of the problem.
The existing application was kept and extended rather than rewritten, so years of business rules and history stayed intact.
Every calculation moved across was rewritten from scratch in Python as separate services, so each can be worked on without affecting others.
Large jobs are split into independent pieces and run in parallel on AWS, so a bigger portfolio means more machines rather than a longer wait.
A main database for day-to-day work, and a separate one for completed results, so reporting and daily use never compete.
Routine transfers and long-running jobs run to a schedule on their own, with notifications when something needs a human.
Changes step through an automated pipeline, one product version at a time, so releasing is routine rather than an event.
The headline difference against the old spreadsheet. A bigger portfolio now means more work running side by side rather than a longer wait, and ordinary day-to-day work no longer sits in line behind the largest ones.
Every calculation moved across was checked against known results from the original before it went into use. The rebuild changed where the work happens and how quickly it finishes — not what it produces.
Completed valuations build up in a separate place on a schedule, and can be undone if something is copied before it is ready. That gives a growing record to look back on without making daily work slower.
This was not delivered and handed over. It is a multi-year engagement on a system that is in use every working day while we change it.
One piece moves at a time and is checked against known results before it goes live. No big-bang switchover, and no weekend anybody has to hold their breath through.
We trace a problem to its actual cause first. In a system like this, fixing the visible symptom usually just moves the problem somewhere quieter.
Existing behaviour is preserved even when the code looks dated, because here "old-fashioned" and "wrong" are not the same finding. Improvements we spot get raised, not quietly merged.
Every change is scoped to the versions it actually affects. Two generations of the product are never assumed to behave the same way.
This is a mortgage platform, but very little of what made it difficult is specific to mortgages. If any of this sounds familiar, so is the problem.
It works, everyone depends on it, one or two people really understand it, and nobody can say exactly what it does. Replacing it is risky precisely because the spreadsheet, not any document, is the real specification.
Hidden production dependencyA single heavy task makes the system worse for every other user, cannot be stopped cleanly, and fails in a way that leaves nothing usable behind.
Monolithic execution queuesCustomers upgrade when it suits them, so more than one generation of the product is live at once and every change carries risk across all of them.
Backward-compatibility debtLooking at history slows down the people trying to get their work done, and the trade-off gets worse every month the system stays in use.
Shared transactional bottleneck