Capital Mispricing and Structural Risk

Chapter 8: Operational and Regulatory Exposure

Architectural coupling produces regulatory exposure: a change requiring three days of code takes four months because it propagates across nine teams. Once reconciliation is available at negligible cost, the absence of reconciliation becomes a discoverable governance choice.

A European insurer receives notice of a regulatory change: all policies above € 25,000 annual premium must observe a mandatory 48-hour cooling-off period before activation. During this window, payment may be collected, the policy may be cancelled without penalty, claims are not valid, and risk exposure must not be recognised on the balance sheet.

This is a fundamental change to the policy lifecycle rather than a simple feature request.

Given that the insurer has five hundred services in its technology estate, “activation” is not managed by a single system but spans five: quoting, payments, the policy record, claims eligibility, and broker commissions. Each of these feeds data to dozens of other systems, with the policy record alone being consumed by fifty-seven.

Adding a cooling-off period fundamentally alters the definition of an “active” policy, meaning that every system that previously assumed a policy was either active or inactive must now account for a third state. The change requires updates across five systems and their dependants, including handling for policies already in progress, rigorous testing across financial reporting, and coordinated releases across nine teams.

While the actual code change takes only three days, the resulting dependency negotiation takes four months.

When the regulator asks how long the organisation needs to implement the change, the CTO says six months. The regulator asks why. The answer, that the organisation cannot change a single business rule without negotiating across nine teams because its systems do not reflect its business processes, is not something the CTO is willing to say. Instead: “integration testing and risk validation.” It is accurate enough to be unchallengeable, and vague enough to be unexamined. The CTO knew the real answer. The organisation cannot change a single business rule without negotiating across nine teams because its systems do not reflect its business processes. He chose not to say it. “Integration testing and risk validation” was accurate enough to be unchallengeable and vague enough to be unexamined.

...

See also: Full contents · Preview chapters · Illusions of Work