I’ve written elsewhere about how I frame velocity analysis in technology strategy. Regulated environments – such as mortgage servicing – helped me form the backbone of my approach. There are times to move fast and break things; this isn’t one of those times. –Scott

Years ago, I was at a dinner during one of the annual Five Star Conferences – good steak, better wine, right people in the room. (The “Five Star” is a major conference in the mortgage servicing industry.)

I was sitting across from a senior Black Knight executive, and at the time Black Knight owned a platform called MSP (“Mortgage Servicing Platform”, obviously named by an engineer), a system that touches a massive chunk of the mortgages in this country.

I asked the executive directly how they thought about modernizing MSP toward a more web-based architecture. I had spent years building that kind of platform inside a law firm to manage operational workflows in a compliance-heavy environment, so the architectural gaps were top of mind for me.

The answer was candid: The regulatory environment made modernization genuinely dangerous. Regulators were fundamentally skeptical of change in mission-critical financial infrastructure. The practical strategy wasn’t to rip and replace; it was to preserve the stability of the core system while building modern interfaces around it.

It was the right call at the time. Fast forward to early 2024, and ICE leadership was still describing the broader mortgage technology market as being in the “early days of an analog-to-digital conversion” (ICE acquired Black Knight in 2023). Roughly a decade later, and we’re still in the early innings.

That’s not a criticism of the industry. It’s confirmation that the constraints are real.

But it leaves us with a massive question I’ve had since that dinner: If you can’t just move fast and break things, how do you actually modernize a system that isn’t allowed to fail?

The Wrong Religion

The dominant culture in technology leadership has turned velocity into a religion. Ship fast. Iterate. Fail fast. It’s the Silicon Valley default, and it has colonized boardroom thinking, where speed is often the first dial people reach for – including in industries where it is genuinely inappropriate.

In a consumer app, a bad deployment is a bad day. You roll back, fix it, and move on. Nobody loses their home, and nobody dies.

In a regulated environment, a bad deployment means you miscalculate an escrow balance, trigger an incorrect insurance disbursement, and suddenly you’re sending a borrower a foreclosure notice based on a math error. Or, if you’re in healthcare, an EHR record gets corrupted and a patient is given medicine they’re allergic to.

The risk calculus in regulated industries can’t just focus on the probability of a failure – it must also involve real appreciation for the magnitude at stake. When the magnitude of a mistake is existential – consent orders, forced migrations, a $25 billion national settlement – speed of execution cannot be your primary KPI. Accuracy must be.

This isn’t an argument against modern CI/CD. Automated pipelines and regression testing do not become irrelevant. But safety needs a real seat at the table when those pipelines are designed.

In this world, “we moved fast and fixed it later” is not a badge of honor – it’s an exhibit.

Modernization Without Silent Failure

You can still use an agile approach here, but the rules are different. Sprint slices cannot carry unresolved dependencies forward, across functional boundaries or compliance boundaries.

In a normal product environment, technical debt accumulated across sprints gets cleaned up as the work iterates (allegedly). In a regulated system, that debt is an active audit exposure that compounds with interest. The blast radius of technical debt has to be engineered to be as tight as possible from the start – not left to be managed later.

QA has to be over-invested relative to most other industry contexts. Not because the engineers aren’t capable, but because the cost of a miss isn’t a bug report – it very well could be a regulatory finding. Treating QA as overhead rather than insurance protecting your EBITDA and margin is a massive miscalibration of risk.

That also means no automated deployment hits production without senior-level human sign-off. The pipeline handles the validation gates and reconciliation checks, but a human looks at the results and makes the final go/no-go call. And your rollback plan has to actually be proven. “We think we can roll back” is a liability, not a plan.

The Data is the Real Liability

We also have to stop treating data like it’s just passive storage. It’s the operating record of the business – and, mismanaged, it becomes a direct source of liability.

Before and after every migration, you need to reconcile record sets using standard confidence interval analysis, segmented by risk category. Higher risk record types get larger sample sizes. The highest risk record types get full population validation. The standard is 100% clearance across every record sampled – not “within tolerance” or “acceptable error rate”. If a single record fails, the migration doesn’t ship.

Whenever I bring this up, the immediate objection is always: “Not at our volume.”

Scale is a processing challenge, not a standards challenge. The answer to the scale issue isn’t lowering the bar, it’s moving the testing upstream into a staging environment that mirrors production before the migration window even opens. The post-release sanity checks then confirm what you already know.

If a vendor tells you 100% clearance isn’t feasible at volume, they are describing a testing architecture problem, not a mathematical impossibility. Ask them where the testing happens, not whether it can be done. At modern scale, the question is rarely whether validation can be engineered – it is where the validation occurs, how much investment the organization is willing to make, and what level of residual risk leadership is prepared to own.

Why am I so uncompromising on this? Because the law doesn’t adopt your engineering conventions. It asks whether your conduct was reasonable.

“Within tolerance” is an engineering concept, not a legal standard.

A plaintiff’s attorney representing borrowers in the long tail of your tolerance band doesn’t care about your technical constraints. They will argue that data reconciliation is binary, and that knowingly accepting incorrect records was an intentional choice that resulted in real harm to a real person. That moves the dispute out of a clean contract frame and into negligence-style questions about reasonableness, foreseeability, and harm. That is a terrible place to defend your choices.

Bending to Reality

Mortgage servicing is where I first ran into this reality, but the framework applies anywhere the regulatory surface area is large, and the cost of being wrong is measured in consent orders and courtrooms rather than churn rates and app store reviews. Healthcare, financial services, insurance, law.

Modernization is coming for all of these sectors, accelerated now by boards and investors who are demanding AI integration as a baseline expectation. That pressure lands hard, because in regulated environments AI doesn’t suspend the blast radius of your technical debt – it expands it.

That creates a specific need for technology leaders, boards, and investors to understand that accuracy (and the investment required to foster it) isn’t a constraint on good engineering in these environments.

It’s the very definition of good engineering, because technology must bend to the realities of the business – not the other way around.

–Scott