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 the 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.

It is a fundamental change to the policy lifecycle, not a feature request. With five hundred services in the estate, “activation” is not one system but five, quoting, payments, the policy record, claims eligibility, and broker commissions, each feeding dozens of others; the policy record alone is consumed by fifty-seven. Adding the cooling-off state means every system that assumed a policy was either active or inactive must now account for a third, with updates across five systems and their dependants, handling for in-flight policies, testing across financial reporting, and coordinated releases across nine teams.

The actual code change takes three days; the dependency negotiation takes four months. When the regulator asks how long the change will take, the CTO says six months, and is asked why. The honest 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 he will say, so he offers “integration testing and risk validation” instead: accurate enough to be unchallengeable, vague enough to be unexamined. The CTO knew the real answer and chose not to say it. The critical moment is not the coupling itself but the point at which coupling forces dishonesty into a regulator's question. Organisations absorb internal costs for years; external exposure begins when the absorption requires a lie of omission. The board's exposure here is not only institutional: a director who governs through untested representations, when verification is cheap and has been presented to the board, occupies a different position from the director who lacked the tools.

In a system decomposed around business processes, a regulatory change is contained within the unit that owns the affected state: it modifies its logic, updates its contracts, and deploys. In a system decomposed around technical convenience, the same change propagates across every system that touches the state, and the coordination makes the timeline unpredictable. For a board, the implication is direct: the time to respond to a regulatory change is determined not by the complexity of the regulation but by the degree of coupling in the system, and the symptom is a change that should take weeks taking months, with no one able to explain why without describing the architecture. A board can measure this directly. Take a recent regulatory change and compare the time spent on code to the time spent on coordination. Call it the coordination overhead ratio. In the vignette it is roughly 1:40: three days of code, four months of coordination.

Coupling also creates incidents whose costs are distributed across the organisation and never aggregated, the € 2.1 million dispersed across departments in Chapter 6 at internal scale. At external scale, the same distribution prevents the board from seeing operational exposure accumulate: each deferred investment and unresolved dependency is a source of future incidents whose costs are attributed to quality and never connected to the structural decision that caused them.

Six months after the change, the regulator asks the organisation to demonstrate how it was made: which services were modified, in what order, with what testing. In the autonomous unit model, the answer is the deployment record and the contract changelog; in the current model, it is reconstructed from memory, incident tickets, and a Confluence page last updated during the implementation. Operational resilience frameworks now mandated in financial services, DORA in the EU and the FCA framework in the UK, ask not whether the firm has documentation but whether it can demonstrate end-to-end understanding of its important business services: how a process operates, who owns it, what it depends on, and where those dependencies are specified. An organisation with explicit process definitions and versioned contracts answers from its operating artefacts; one without them commissions a compliance programme that produces documentation degrading the day it is signed off, and repeats the cycle every period.

...

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