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, for sure. This isn’t one of those times. –Scott

Years ago, I was at a dinner during one of the annual Five Star Conferences in Dallas. And it was at a steakhouse because, well, Texas. (The “Five Star” is a major conference in the mortgage servicing industry.)

I was sitting across from a senior Black Knight executive. 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, because regulators were skeptical of change in mission-critical financial infrastructure. So the practical strategy wasn’t to rip and replace. Instead, it was to preserve the stability of the core system while scaffolding 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. Which isn’t all that surprising given the regulatory backdrop.

But I’ve had the same question 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

Technology leadership has turned velocity into a religion: Ship fast. Iterate. Fail fast.

It’s the Silicon Valley default, and it has made its way into boardrooms, 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 can mean 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, in healthcare, an EHR record gets corrupted and a patient is given medicine they’re allergic to.

Most risk decisioning drills down on the probability of a failure. In regulated industries, that focus overly minimizes the other half of the equation – the magnitude. When the downside can be consent orders, forced migrations, or 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 still matter. 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 kept as small as possible from the start. You cannot just assume you’ll clean it up later.

QA also has to be over-invested relative to most other industries. Engineers are just as capable in regulated industries as they are in non-regulated industries, but 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 miscalculation of risk.

I also would require “human in the loop”. 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, side note, your rollback plan has to actually be proven. “We think we can roll back” does not count.

The Data is the Real Liability

We also have to stop treating data like it’s just passive, dumb storage. It’s the operating record of the business and, when 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 objection is always: “Not at our volume.”

Scale, however, is really just an engineering challenge. Lowering the bar only makes you more vulnerable. Instead, move the testing upstream into a staging environment that mirrors production before the migration window even opens. This allows the post-release sanity checks to merely 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 less whether validation can be engineered and more where it occurs, how much the organization is willing to invest, and how much residual risk leadership is willing to accept.

Why am I so uncompromising on this? Because the law doesn’t care about 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.

Now you’re no longer arguing within the four corners of a contract – and you’ve waded 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, 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.

Places like healthcare, financial services, insurance, law.

Modernization is coming for all of them, accelerated now by boards and investors demanding AI integration as a baseline expectation. That pressure makes things worse.

In regulated environments, AI is not a magic tool that limits the blast radius of your technical debt – it actually expands it.

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

It is good engineering.

–Scott