The sentiment is understandable. The existing model is slow, poorly documented, and full of code that nobody fully understands. There is an opaque subroutine that handles a tranche of conventional with-profits business written in the 1980s, and the only documentation is a comment that reads: “Whatever you do, do not remove this.” The codebase is not so much software as it is sedimentary rock, and each layer contains its own fossils.

So you start fresh. Clean architecture. Modern platform. This time, you tell yourself, we will do it properly.

Joel Spolsky wrote about this pattern over two decades ago, calling it the single worst strategic mistake a software company can make. Netscape rewrote their browser from scratch and nearly died. More recently, Sonos rewrote their mobile app from the ground up in 2024, promising “an unprecedented streaming experience.” The result was a catastrophe: core features were missing, existing systems broke, the company’s share price dropped by 25%, and the CEO lost his job. The rewrite had taken two years. The team had done extensive user testing. The prototypes looked good. The problem was not the vision. It was the thousand things the old app had quietly been handling that nobody had thought to write down.

The complexity is in the problem, not the code

When a developer looks at a legacy actuarial model, they see spaghetti and hacks and massively nested if statements and think “bad code.” Sometimes they are right. But more often, the cludge is an accurate representation of complicated business logic. That weird branch that treats one closed book differently from every other? That is a tranche of policies migrated in from another licence in some distant corporate past, policies that stubbornly crawl off the books at their own pace rather than running off as the assumptions suggest. The hardcoded matrix of flags in the decrement logic? That is handling multiple causal surrender and lapse events, where the interaction effects were agreed through industry negotiation rather than derived from first principles.

Consider the products themselves. Conventional with-profits policies from the 1970s and 1980s, now-defunct retail discretionary smoothed bonus products, universal life variants with guarantee structures that differ by tranche because of policy wording glitches that affected business written during a narrow window. These are not edge cases. In a mature life insurer’s book, they are the book. Every product variant that was ever sold, however briefly, however accidentally, lives in the model forever.

You can refactor the syntax. You can rename the variables. You can restructure the control flow. You can attempt to enforce coding standards. The essential complexity survives every rewrite, because it was never a function of the code to begin with. It was in the contracts, the policy wordings, the historical decisions, and the accumulated institutional memory of the actuarial team.

This is why model rewrites so often converge back towards the same complexity as the original. The optimistic timeline assumes the new model will be simpler. It will not be simpler. It will be the same complexity with less battle-testing.

The rabbit hole goes deep

I recently fell down a rabbit hole reading about why COBOL systems persist in banking. The reason turned out to be more interesting than I expected, and it illustrates something important about legacy systems in general.

COBOL performs arithmetic in decimal. Not binary floating-point, which is what R, Python, C, and virtually every modern language use by default, but actual base-10 arithmetic. This matters because in binary floating-point, 0.1 cannot be represented exactly. It is not a rounding issue or an implementation bug. One-tenth in base 2 is a repeating fraction, the same way one-third is repeating in base 10. The practical consequence is that 0.1 + 0.2 does not equal 0.3 in any language that uses IEEE 754 doubles. Try it in R. It returns FALSE. Excel, incidentally, will tell you it returns TRUE, because Microsoft decided decades ago to silently paper over the issue with heuristic rounding at the display level. It is a load-bearing lie: technically dishonest, pragmatically essential, and the foundation upon which the entire global financial system’s spreadsheets rest.

For actuarial modelling this rarely matters in practice. You are working with estimates and probabilities, and 15 significant digits of precision is more than enough. But the point is not about COBOL or Excel specifically. It is about how deep the assumptions in any system go. The banking world discovered, when they tried to move off COBOL, that the decimal arithmetic was not just a feature of the language but a load-bearing property of the entire ecosystem. Rounding behaviour, reconciliation logic, audit trails: all of it assumed exact decimal representation.

Actuarial models have their own version of this. Assumptions about evaluation order, about when intermediate rounding occurs, about how decrements interact, about the precise sequence of operations in a monthly projection step. These assumptions are rarely documented because the people who wrote the model did not think of them as assumptions. They were just “how it works.” Until someone tries to replicate “how it works” in a new environment and discovers that a hundred small implicit choices produce a hundred small differences, each individually immaterial, collectively significant, and individually painful to diagnose.

The documentation mirage

The standard diagnosis at this point is: “Well, we should have documented it properly.” And yes, in an ideal world, every modelling decision would be recorded, every assumption justified, every edge case explained. But documentation has a half-life. The moment you write it, it starts decaying. And the effort to keep it current competes with the effort to actually do the work it documents.

Models most in need of documentation are the complex ones that change frequently, which are precisely the ones where documentation goes stale fastest. The simple stable model that has not changed in five years has beautiful documentation. The critical model that three people are iterating on weekly has a README from 2019 and some optimistic comments about “come back to this” in the code.

Good documentation requires a different skill from good modelling. Explaining why you made a choice is harder than making the choice. Most documentation ends up describing what the model does, which anyone with the code can see, rather than why it does it that way, which is the thing that is actually lost when someone leaves.

So when someone says “we will document the old model thoroughly before we migrate,” treat that with the scepticism it deserves. It is not that documentation is worthless. It is that comprehensive documentation of a complex actuarial model is closer to a research project than a task on a Gantt chart, and it will never be truly complete. The knowledge that matters most, the kind that explains why line 437 exists, often lives only in the model itself and in the memories of the people who built it. Sometimes the most valuable documentation in the entire codebase is a comment that says “do not remove this.” It tells you nothing about what the code does. It tells you the one thing that matters: someone before you tried removing it, and something terrible happened.

The testing problem is nearly intractable

The textbook software development answer to safe migration/refactoring is: write comprehensive tests against the old system, then verify the new system produces the same results. This sounds clean. It falls apart quickly in practice.

An actuarial model is not best thought of as a simple function that takes an input and returns an output. It is a function of data, assumptions, methodology, regulatory basis, reporting date, and a constellation of configuration choices. To truly test it, you would need to verify results across combinations of all of these dimensions: base and stressed assumptions, multiple products, different data vintages, BEL, SCR, RM, RA, EV, ORSA projections and more. The required test suite is, for practical purposes, infinite.

But even if you could write enough tests, testing locks in current behaviour, not correct behaviour. If the existing model has a subtle bug that slightly misstates the impact of a particular stress scenario, your tests will faithfully preserve that bug. You now have a comprehensive test suite that gives you high confidence in reproducing the wrong answer. Which is arguably worse than no tests, because it creates false certainty.

Conversely, tests that are too simple create their own risks. A test that says “the total reserve is within 1% of the old model” might pass while masking a situation where two large errors in opposite directions cancel out. Over time, as the portfolio changes and one of those errors stops being offset, the discrepancy surfaces, and by then nobody remembers that the migration was the cause.

The practical approach is something looser than formal test suites: attribution analyses, movement analyses, and sense checks that tell you why results changed, not just whether they changed. An unexplained difference is not a rounding tolerance to be waved through. It is an unknown.

The replication question

Here is a question that derails more migration projects than any technical challenge: during the rebuild, the team discovers that the old model has a bug. Maybe the lapse rates for a particular cohort are being applied incorrectly. Maybe a decrement interaction is not handling concurrent events properly. The old model has been producing results with this error for years, and those results have been reported, audited, and relied upon.

Do you replicate the bug in the new system to maintain consistency? Or do you fix it?

There is no clean answer. Replicating the bug feels deeply unsatisfying. Every professional instinct says to fix it now that you have found it. But fixing it means your “like-for-like” migration is no longer like-for-like, and every future reconciliation has to account for the correction. The reconciliation work, which is already the hardest part of any migration, becomes significantly harder when you are trying to separate platform differences from methodology changes.

My view is that, in general, replication first, correction later, is the lesser evil. Get the new system producing the same numbers as the old one, including the known (or newly identified) bugs, and then fix the bugs as a subsequent, documented change with its own impact assessment. It is slower. It is unsatisfying. But it is the approach that keeps the audit trail clean and the actuarial team’s confidence intact.

This only works if errors are logged rigorously at the point of discovery. Each one needs a description of the issue, the products and tranches affected, an estimate of the financial impact, and enough technical detail that a reader coming to the register months later can find commonality across findings and know where to start when the correction work begins. A vague note that says “lapse rates may be slightly off for product X” is not useful. A note that says “the lapse decrement for product X, tranches written between 2003 and 2007, is applied before the surrender decrement rather than simultaneously, resulting in an estimated overstatement of reserves of approximately R2m” gives the next person something to work with.

One big model or many small ones?

A migration forces a structural question that is easy to defer and hard to answer well: should the new platform use a single large model with flags and indicators to handle product variation, or multiple smaller models that are individually simpler but collectively harder to manage?

The single-model approach is appealing because it eliminates duplication. Core logic like decrements, lapse rules, and economic scenario generation lives in one place. Change it once, and every product picks up the change. But the model becomes increasingly complex, the flag-and-indicator logic becomes its own source of bugs, and a change intended for one product can have unintended consequences for others. Testing a single change requires running everything, which in a large model can mean hours of runtime.

The multi-model approach is appealing because each model is smaller, easier to understand, and faster to run. But it introduces duplication, and duplicated logic mutates over time the way DNA does: small transcription errors accumulate with each copy, and eventually two models that should be applying the same lapse basis are not. One gets updated, the other does not. A fix is applied in three of the five copies but missed in the other two. Maintaining consistency across a library of models requires discipline and tooling that is easy to underestimate.

There is no universally right answer. But the choice should be made deliberately at the start of a migration, not allowed to emerge organically, because reversing it later is extremely expensive.

Living with two systems

A related pragmatic question: does every product need to migrate?

For a mature life insurer, the long tail of the book often includes products that are tiny, declining, and odd. They might represent a few hundred policies with unique features that would take weeks to replicate in the new platform. The cost of migration far exceeds the operational benefit, especially if the product will run off within a few years anyway.

The temptation is to leave these in the old system and migrate everything else. This can work, but it introduces its own pain. Running two modelling environments means maintaining two sets of assumptions, two data feeds, two run processes. If the old system is not integrated into the new orchestration and workflow environment, the residual products become a manual process that someone has to remember to kick off, reconcile, and consolidate. Automated kick-off of external models outside the main controller environment is possible in principle, but brittle in practice: it adds integration points, error handling, and monitoring requirements that erode the simplicity gains of leaving the products behind.

Over time, the old system becomes an unloved orphan: patched reluctantly, understood by fewer and fewer people, and increasingly fragile.

The decision should be explicit and time-bound. If the plan is to leave products in the old system, there should be a clear runoff date after which those products will either be migrated or, if they are small enough, approximated in the new system. An open-ended commitment to maintain two platforms in parallel is a commitment that tends to last much longer than anyone intended.

The case for migrating anyway

Given all of this, why would anyone migrate? Because the reasons to move are real, even if the process is painful.

The strongest argument is rarely about the actuarial code itself. The core projection logic, the bit that actually calculates reserves and capital, is broadly the same complexity regardless of the platform. The arithmetic is not all that special. The case for migration is about everything around that core: better long-term vendor support, modern workflow and automation capabilities, improved system architecture that enables genuine runtime improvements, proper change control and audit trails, user management, cloud processing, and the ability to integrate with modern data pipelines.

A legacy model might produce perfectly good numbers, but if the assumption update process involves manually editing text files, if change control is a folder of dated ZIP archives, if running a stress scenario means waiting overnight for a batch job, then the platform is constraining the business even if the arithmetic is fine.

Migration also presents an opportunity, if managed carefully, to clean up decades of accumulated inconsistencies. Not the load-bearing hacks, which exist for good reason, but the other kind: the copy-pasted subroutine that was modified slightly for each product and now exists in seven inconsistent versions. The assumption tables that use three different date conventions because they were built by three different people over fifteen years. The configuration settings that nobody is sure are still active. A migration done with eyes open can rationalise these, as long as the team resists the temptation to rationalise everything at once.

What not to do

One recurring temptation is to skip the vendor platforms entirely and build a bespoke system from the ground up in Python, or Julia, or whatever the language of the moment happens to be. The argument is appealing: we know our business better than any vendor, modern languages are fast enough, and we will have complete control.

I am sympathetic to this, because I have done it. In the early 2000s, I built a proof-of-concept actuarial system on an open-source stack: PHP and C++ on the back end, HTML and JavaScript on the front end, with memoized calculation so that values were computed on demand and cached for reuse. It was designed from the ground up to be standards-compliant so the server could run on a laptop, on premises, or in the nascent cloud. It worked – I’m still impressed with young me there. The core system logic was not the hard part.

The hard part was everything else. The assumptions manager. The data input validation and transformation. Change control and version history. User management and access permissions. Audit logging. Batch processing and job scheduling. Error handling and recovery. Reporting and output formatting. The ability to offload computation to remote infrastructure. That was where I bailed on the project.

Building a basic actuarial projection engine is a manageable problem. A competent developer can get a working prototype running in weeks (it took me a little longer…). But a projection engine is perhaps 20% of what an actuarial modelling platform needs to be. The other 80% is the engineering infrastructure that makes it usable, auditable, and safe in a production environment with multiple users, regulatory oversight, and real money at stake. That 80% is what the established vendor platforms have spent decades building, and it is what a bespoke system will spend years rediscovering.

The comparison is often made to a spreadsheet. Excel’s calculation engine is straightforward. What makes Excel a product is everything around it: the interface, the formatting, the collaboration features, the ecosystem. Building “Excel but for our specific needs” sounds efficient until you realise how much of the value is in the parts you thought were trivial.

A pragmatic framework

If you are considering a migration, here is what I would suggest.

1. Be honest about the motivation. If the primary driver is “the code is complex,” that is not a good enough reason. The new code will be complex too, eventually, because the problem domain is complex. If the driver is “the vendor’s support is no longer working” ,” or “our current architecture cannot support the automation and workflow improvements the business needs,” those are real reasons that justify real investment.
2. Plan for the migration to take longer than you expect. (Hofstadter’s Law applies with full force here: it always takes longer than you expect, even when you take into account Hofstadter’s Law). Every model migration I’ve seen that stayed on its original timeline did so by cutting scope, not by being faster than expected. Budget for the edge cases, the discovered bugs, the reconciliation work, and the institutional knowledge that only surfaces when someone tries to replicate it. If your initial estimate is eighteen months, plan for three years and you might finish in two and a half.
3. Decide your replication and error-handling policy upfront. I have argued for replicating first and correcting later, with a rigorous error log that gives subsequent teams enough detail to act on. Either way, what matters is that the policy is deliberate and that discoveries are recorded with care. Not having a policy is not an option.
4. Invest in attribution analysis rather than pass/fail testing. You need to understand why results differ, not just detect that they differ. A 0.1% difference with a clear explanation traced to a specific implementation choice is better than a 0.0% difference that you achieved by accident.
5. Make deliberate structural choices early. One model or many? Which products migrate and which stay behind, and for how long? These decisions shape the entire project and are expensive to reverse.
6. Resist the temptation to improve the model and migrate it simultaneously. The migration alone is a large enough project. Bundle it with methodology changes and you lose the ability to diagnose whether a difference in output comes from the new platform or the new approach. Migrate first. Improve second. The discipline to separate these is the single biggest predictor of success. (One exception here might be preparing for GPU acceleration or improved vectorisation etc.)

Joel Spolsky was right that rewrites are dangerous. Sonos learned it the hard way. Netscape learned it before them. But Spolsky was writing about software companies, where the old product is still shipping and generating revenue while the new one is being built. Actuarial model migrations are a different beast: you cannot run two production models indefinitely, the regulatory environment is evolving whether you migrate or not, and eventually the cost of not migrating exceeds the cost of migrating.

The trick is to go in with realistic expectations about how hard it will be, a clear-eyed understanding of what you are actually gaining (hint: it is not cleaner code), and enough humility to respect the load-bearing hacks you will encounter along the way. That comment that says “whatever you do, do not remove this”? Read it as a colleague speaking to you across time. They learned something the hard way. Your job is to learn it without repeating the pain.

But for many, this promise is being hindered by a foundational legal concept: The Principle of Indemnity.

By insisting that property insurance must always be a contract of indemnity (meaning you cannot recover more than your actual, audited loss) regulators have forced the industry into a structural kludge known as the “Dual Trigger.” It’s a legal “fix” that satisfies the status quo but creates a cascade of inefficiencies for insurers and consumers alike.

The Mechanism of the “Dual Trigger”

In a rational parametric model, the data event is the payout. In the regulated world, however, two hurdles must be cleared:

1. The Data Trigger: The physical event occurs (e.g., wind speed, rainfall).
2. The Indemnity Proof: The policyholder must provide evidence that their actual loss equals or exceeds the payout.

This second trigger creates what we might call the Indemnity Trap. It caps the payout at the lower of the two values, fundamentally changing the nature of the risk.

Where the Principle of Indemnity comes from – and why it is a good idea in traditional insurance

Traditional insurance needs indemnity. It ensures the contract restores you rather than enriching you. In the non-life market, we insure the uncertainty of a loss. We don’t just insure the occurrence of an event.

If you could collect a payout that far exceeded your actual loss, you’ve moved from a safety net to a lottery ticket. This “Lotto Effect” turns insurance into a legally sanctioned wager. That windfall potential creates a toxic moral hazard. It invites fraud like arson or staged theft. It also rewards negligence. Why protect an asset when you are worth more if it burns?

By capping payouts at the Ultimate Net Loss, we align the policyholder’s interests with the asset’s survival. Insurance remains a stabilizing force. It protects wealth. It doesn’t generate profit from destruction.

The Problem: Asymmetric Basis Risk

This structure creates a profound misalignment. When we layer an indemnity cap onto a parametric trigger, we create a one-way street of risk:

• When the data misses: If the storm causes massive damage but the sensor doesn’t hit the trigger, the policyholder gets nothing. This is the “Negative Basis Risk” everyone acknowledges.
• When the data hits: If the sensor hits the trigger but the physical damage is light (perhaps because the owner invested in resilience), the indemnity rule steps in and caps the payout.

The result is a structure where the payout can be lower than the data suggests, but never higher. This isn’t a malicious choice by insurers; it is a structural constraint that leaves the risk transfer incomplete. It also reintroduces the very thing parametrics were meant to kill: payout delays. The moment you require a loss audit, the “instant cash” benefit of the parametric model is lost to the administrative friction of the indemnity process.

The Pricing and Underwriting Friction

This isn’t just a headache for policyholders; it complicates pricing.

To price a “clean” parametric policy, an actuary only needs weather data. But to price a policy with an indemnity cap, they must also predict the probability of the cap being hit. This requires traditional, granular underwriting of the asset. We’ve replaced a low-cost, scalable model with a high-cost, bespoke one, simply to satisfy a legal definition.

Assessing the Regulatory Responses

Why do regulators cling to the indemnity requirement? While the intentions are often centered on market stability, the logic behind these defenses deserves a closer look.

Argument 1: The Mitigation Incentive The traditional logic is that indemnity prevents moral hazard. The fear is that if people “profit” from a disaster, they will want the disaster to happen. However, this overlooks a critical reality of resilience. Traditional indemnity insurance actually discourages mitigation. If you spend your own capital to save your factory with sandbags, your indemnity payout simply drops to match your lower loss. In a parametric model without an indemnity cap, you are rewarded for that foresight. You keep the surplus as a “resilience dividend.” The current rules are, in effect, a structural barrier to climate adaptation.

Argument 2: Speculation vs. Insurable Interest There is a concern that without a proof of loss, insurance becomes a “Lotto” or a wager on the weather. But the gatekeeper against speculation should be Insurable Interest, not Indemnity. If a buyer demonstrates a legitimate economic exposure to the event at the point of sale, the speculative element is already addressed. We do not need a cumbersome audit at the back-end to solve a licensing and gatekeeping question at the front-end.

Argument 3: The Life Insurance Precedent It is often argued that property must be treated differently from life insurance because assets have a market value that must not be exceeded. Yet, the Life, Disability, and Critical Illness sectors function perfectly well as “valued contracts.” These are multi-trillion dollar industries that rely on Insurable Interest and a Reasonable Sum Assured. There is no fundamental logical reason why a crop, a solar farm, or a retail business could not be treated with the same “valued contract” logic we already apply to human life.

The Path Forward: The “Ought”

We shouldn’t be trying to “fix” parametric insurance by adding indemnity caps. We should be updating the regulatory framework to recognize Index-Based Insurance as a distinct legal category.

A modern, rational framework would require three things:

1. Provable Insurable Interest (Ensuring the buyer has skin in the game).
2. Reasonable Sum Assured (A cap based on total economic exposure, not just physical damage).
3. Objective, Independent Data Triggers that are demonstrably correlated with the risk exposure

The current “Dual Trigger” system isn’t a design choice; it’s a symptom of a regulatory system that hasn’t changed fast enough. I’d argue the regulations are focused too much on the potential cost and risk of change, while glossing over the downsides of not changing.

Is it time to stop forcing 21st-century risk tools into a 19th-century legal box?

The Basics: Why Hold More Than 1x SCR?

Before diving into comparison challenges, it’s worth briefly considering why insurers typically maintain SCR cover ratios well above 1.0. The obvious reason is to maintain a buffer above regulatory minimums, but there are several other important considerations:

• Supporting future business growth and associated strain
• Providing capacity for opportunistic investments or acquisitions
• Covering risks not captured by the standard formula, such as reputational risk and strategic risk
• Accounting for cases where the standard formula may not perfectly reflect an insurer’s specific risk profile. (This is a pet area of mine. There are multiple problematic areas, from treatment of concentration risk, to no scale adjustment for non-life underwriting risk, the lack of a flood catastrophe scenario, too light mortality catastrophe, possibly too-high equity stresses, too-low retrenchment stresses and more!)
• The old idea of holding a buffer to allow a riskier investment strategy is less relevant with whole balance sheet risk capital measures, where the higher risk investment strategies themselves result in higher SCR.

There are clear reasons to want to hold as little capital as possible, related to capital rationing and aiming to increase Return on Equity. Perhaps I’ll cover that in a different post – there are some quirks related to the discussion, as more capital inevitably feels like it drives a conversation towards taking greater risk, rather than tax-optimised, liquidity-optimised market consistent value optimisation.

Life Insurers: Different Business Models, Different Dynamics

The comparison of SCR cover ratios becomes particularly interesting when examining life insurers with different business models. Consider these key differences:

Risk Protection vs Investment Products

Insurers focused on risk protection business demonstrate fundamentally different SCR cover behavior under stress compared to those primarily writing annuities or investment products. This stems from the different nature of their key risks and how these respond to adverse scenarios.

One of these impacts is how mass lapse risk affects SCR cover ratios. When a mass lapse event occurs, both own funds and SCR can decrease simultaneously due to the loss of negative reserves. This means that insurers with significant exposure to mass lapse risk might show surprisingly resilient SCR cover ratios during stress scenarios for those with significant mass lapse risk – quite the opposite of an annuity writer’s exposure to longevity, interest rate, or spread risks which will drive a good portion of their capital.

One aside, SCR cover resilience doesn’t necessarily indicate lower real-world risk to shareholders, who can still lose significant shareholder value (whether measured by Own Funds or Embedded Value) in a mass lapse event. The probability of actually defaulting on promises to policyholders remains remote.

Market Risk Considerations

Equity risk exposure creates another layer of complexity. Insurers with significant shareholder equity portfolios benefit from a natural risk reduction mechanism during market stress – as equity values fall, the exposure and thus the required capital for equity risk also decreases. This creates very different SCR cover behaviour compared to insurers whose primary risks (like mortality) don’t have this characteristic.

Bancassurers or newer insurers typically have less equity risk in their portfolios relative to older, more diversified business (especially those with mutual/with profit ancestry).

Non-Life Insurers: The Reinsurance Effect

For non-life insurers, reinsurance strategies play a crucial role in understanding SCR cover ratios:

Beyond the 1-in-200

Most non-life insurers purchase reinsurance protection beyond the 1-in-200 year event level that drives SCR calculations. Some might secure coverage for 1-in-400 or 1-in-500 year events, while others might optimise their reinsurance purely for SCR efficiency, stopping at the 1-in-200 level. Two insurers with identical SCR cover ratios might therefore have vastly different protection against extreme events.

Purchasing reinsurance cover just up to 1-in-200 also runs the risk of business volumes and exposure growing more than expected, overflowing those reinsurance limits.

This creates an interesting paradox: The probability of severe losses (where Assets < Liabilities) can vary dramatically between insurers with the same SCR cover ratio, depending on their reinsurance limits. However, their chances of breaching the SCR cover ratio in moderate stress scenarios (1-in-20 to 1-in-50) might be similar, as these events typically fall within reinsurance coverage limits.

In practice, many Boards and management teams really worry about the more realistic risks of beaching regulatory solvency. This is because the likelihoods involved feel more plausible, because this event will happen before outright insolvency, and because in general the 1 in 500 or larger events are likely industry-wide. There is an element of better to be in trouble along with everyone else…

A Common Challenge: Government Bond Treatment

Both life and non-life insurers face challenges around the treatment of government bonds as risk-free assets. Two insurers with identical SCR cover ratios might have vastly different exposures to sovereign default risk, despite this being treated as zero in standard formula calculations.

Conclusion

While a higher SCR cover ratio (say 1.8x versus 1.5x) might seem to clearly indicate stronger financial resilience, the reality is far more nuanced. Before drawing conclusions from peer comparisons, we need to consider:

• The underlying business mix and its risk characteristics
• Reinsurance structures and their effectiveness beyond regulatory capital requirements
• The appropriateness of standard formula assumptions for each entity
• The rigour applied in implementing regulatory standards

Only by understanding these factors can we begin to make meaningful comparisons of insurers’ true financial strength and risk resilience.

For example:

📊 Having fewer children has a temporary impact to boost productivity as resources aren’t spent on child rearing and more time is available for labour force participation. (This will have contributed to China’s decades-long GDP growth.)

👥 Longer term, fewer children results in a reduction in the working age population. This can result in higher unit labour costs. (Mismatch of education and skills to available jobs can still cause unemployment, as it does in China.)

💹 Relatively large retiring populations and retired populations can skew capital markets and interest rates as they sell assets to consume. With fewer new savers and investors available, these asset prices will likely decrease. Production constraints through lower working age populations will increase the cost of goods and services, requiring further sales of assets. The impact on bonds and interest rates is more complex given the move from equities to bonds before selling even bonds. At some periods, interest rates may decline as consumption slows while there is still plenty of capital. In time, interest rates will likely rise as surplus capital decreases.

🏘️ Population declines may decrease housing demand overall. However, not all housing is created equal, and pockets of demand outstripping supply will continue for much longer than the total measures suggest.

🏗️ Large property supply overhangs (not only China, but yes China) can decimate confidence and savings if prices collapse.

📉 Decreasing populations make it much more difficult to grow nominal GDP, putting upwards pressure on Debt/GDP ratios. Inflation can do wonders here, so expect more inflation. Or defaults. Or both. And knock on impacts on interest rates and spreads.

🌍 Xenophobia, meet necessary global population migration. And this before we’ve introduced climate-forced migrations to the analysis. Countries with ageing populations (most countries) need young immigrants, but with that comes cultural clashes.

🌱 Reduction in resource and energy utilisation may have some offsetting impact on our planet and climate change

There’s much more to this story. But sometimes insurance execs want to know what the clear product demand change will be.

One answer could be pet insurance.

China is set to have more pets than children soon. Goldman Sachs says by 2030 there might be double the number of pets as children. Pet Insurance and Pet Food might be two big growth areas to pay attention to amongst the fundamental revision of society as we know it.

#demographics #demographicshifts #populationtrends #longterm #petinsurance #insurance #trends #petfood

Suggestion – Introduce the equivalent of the UK’s Skilled Person Review

We must find ways to intervene with struggling insurers well before it’s time for a statutory manager or curator. Curators and statutory managers are expensive, invasive, and disruptive – and because of this, implemented as a last resort, meaning the prognosis is usually poor.

The UK’s FCA and PRA have the power to ask for a “Skilled Person Review† often termed a Section 166 review after the section of the Financial Services and Markets Act it falls under.

A skilled person review can entail a variety of roles, including assessing a firm’s governance, risk management, systems, controls, and compliance with regulatory requirements. The skilled person may also recommend remedial actions and provide oversight during their implementation.

These reviews might be triggered by a low or declining solvency level, a question around governance, risk and compliance practices, concerns over product designs and the treatment of customers, or questions related to regulatory compliance in any area.

Early intervention through a skilled person review can help identify and address potential issues in a struggling insurer. This proactive approach can prevent larger problems from arising and potentially avoid the need for more invasive and expensive measures such as placing the insurer into curatorship.

A Skilled Person Review will involve an independent third party with the appropriate skills to perform the review. The review itself could take several weeks or months, with the scope defined by the specific need.

However, insurers might request similar reviews for their internal purposes if the management team or Board have concerns in a particular area.

Benefits for the insurer include:

• Identifying and addressing weaknesses in risk management, governance, and controls.
• Reducing the likelihood of regulatory action due to non-compliance.
• Improving the insurer’s reputation and relationship with regulators.
• Gaining independent insights and recommendations for business improvements.

In South Africa, our regulator doesn’t have the same specific tool in current legislation. There is arguably enough general “investigations† scope in the Financial Sector Regulation Act or the Insurance Act to implement this. The clarity provided by the Section 166 review scope and format, and history of application in the UK provides regulatory certainty for everyone. It also means this regulatory action is less likely to be opposed by insurers.

Earlier investigations that get to the bottom of issues quickly, or allay concerns, may have a role in improving outcomes for policyholders and shareholders alike

With a hefty additional dose of approximations, I get about the same figure all the way back to 1998.

This amounts to an insurer failing every other year.

The primary causes? In every case it’s more than one thing. Here are some of the recent common causes – I’ll expand on each of these in a series of posts.

1 Underwriting risk and pricing

Mispricing, particularly when moving into new markets or new lines of business is a common starting point.

Funeral insurers feeling competitive pressures are looking for new markets – typically semi-underwritten life products, misguided savings products, niche legal expense cover products, or further afield into non-life proper. Here be dragons.

For all the benefit of diversification from a statistical perspective, the research says that focussed insurers fail less often.

Climate change is going to break underwriting and pricing models, meaning that even previously well understood risks increase the chance of failure.

Non-life insurers need to get claims inflation under control – or at least continue the unpopular premium and excess increases to restore sustainability to premium rates.

2 Cost of customer acquisition outstripping funding and VNB

Rapid growth may be many insurers’ dreams.

However, too rapid growth can strain capital adequacy. Rapid growth can also be a telltale sign of under-pricing, leading to large volumes of unprofitable business. Selling many policies that don’t cover their acquisition expenses is a short cut to real trouble.

A worrying sign here is the reduction in VNB margins across broad sectors of the underwritten life insurance space. This ramps up pressures to dilute new business metrics, which is a terrible idea.

3 Misuse, and misrepresentation of (financial) reinsurance

Reinsurance is a fundamentally important tool to manage risk, manage capital requirements, gain expertise in a new market, and to provide liquidity.

Reinsurance, especially financial reinsurance when misused, can obscure the deteriorating solvency position of an insurer and lead to a false sense of security for risk managers, NEDs, and regulators.

The principles on how to treat financial reinsurance and contingent commissions are about right – but the detailed rules and the rigour and honesty with which those principles are implemented sometimes are not.

The overall lesson is – the improvement in your solvency should reflect the actual risk transferred and economics of the transaction.

The most egregious error is claiming that a FinRe deal has resulted in an increase in assets without an increase in liabilities. Tricks of claiming that repayment of the commission (a loan) is contingent on future profits and therefore isn’t a liability are invalid. Games with contract boundaries include recognising the upfront commission (which is to be repaid over many years of renewing contracts), but not recognising years of future reinsurance premiums because the in-force policies have annual contract boundaries.

On contingent commissions, the key question to ask is “has my SCR gone down by more than the risk transferred?”. If one reinsures 70% of the portfolio using QS, but 90% of that risk comes back through contingent commission, then applying the FSIs blindly can result in a 10x overstatement of the benefit of reinsurance. You have shared 7% of the risk, not 70%.

My rule of thumb is not to take advice on the regulatory, solvency, or accounting treatment of the reinsurance from the one selling you the reinsurance.

4 Complex, incestuous asset transactions, and poorly controlled ALM

Aggressive asset valuations, typically of unlisted, illiquid investment that have some related party in the mix, are one of the clearest red flags for an insurer about to fail.  There is always the next Warren Buffet wanting to “invest the float† and make money in some undeveloped property, associated business, or beautiful basket of tulips.

Careful ALM is critical for long-tailed policies. There it needs to be managed carefully and regularly. Monitoring isn’t enough – there needs to be a mechanism to change the portfolio when mismatch parameters breach thresholds.

For other portfolios, sometimes a simpler portfolio that introduces less complexity, fewer tax risks, less operational and liquidity risks, is better than a supposedly more ALM-tuned portfolio that actually increases risks of catastrophic failure.

Asset concentration has been a primary cause of at least one major South African insurance failure before too. Although, as always, this wasn’t the single cause.

5 Taking large (binary) risks when already in trouble

As solvency positions decline, some CEOs, seeing the writing on the wall, choose to take significant risks that will either solve their solvency problem, or increase the impact of insolvency to policyholders.

Something as simple as continuing to write business, especially long-term business, when the solvency capital isn’t available to support this business places existing and new policyholders under additional risk.

Pinning hopes (and management bandwidth) on big-bang investment deals without addressing underlying operational concerns usually don’t pay off.

6 Failed corporate governance

Corporate governance failures are usually the second or third thing to go wrong. Poor internal controls, ineffective or insufficiently independent risk and compliance teams, and outright financial statement fraud mean that serious problems are overlooked, sometimes for years.

Fraud is more often a response to problems (especially where management believes they are in the right and it’s just a matter of time before markets/the cycle/business turns). In select cases, insurers are used as vehicles to instigate fraud as first step

Some boards and shareholders deprioritise good governance. When times are good it’s easy to emphasise good governance. What about when governance gets in the way of decisions executives want to make? Or when it raises awkward questions about pet projects? Or where the business is struggling but management is confident they can trade out of the difficulty as long as they are given the space and time?

It’s easy to do the right thing when it doesn’t come with costs.

7 Slow regulatory intervention

Too often, regulatory intervention is too slow and not targeted at the underlying causes. It’s hard to blame the regulator entirely, given the massive opposition to statutory managers and curatorships.

There are many amazing, skilled, and experienced individuals at our regulator. Are there enough? Is the quality and approach consistent? Are they hamstrung by insurers under resourcing their own control functions and lines of defence?

Can anything be done to decrease failure rates?

Having a strong, experienced, and independent actuary who pays close attention to the regulations and guidance is crucial. Your head of actuarial function should provide good advice on business issues. They should also occasionally constrain your options and make you rethink your positions.

A solid, experienced, and independent Head of Actuarial Function goes a long way.

Appropriate risk management and governance practices are defined in multiple different places, and they can all work well enough if followed diligently. Making sure the teams are experienced and skilled and empowered to tell truth to power is rather more difficult.

The original discussion was about the value of a second opinion, when you get bad news. I have an opinion on this – informed by years of product reviews, IFRS, EV and regulatory audits, peer reviews of other actuaries, cleaning up the mess of failed insurers, being reviewed myself, attending actuarial, risk and audit committees for over 40 insurers in South Africa.

It is useful to get a second opinion when you don’t like the first answer. Opinion-shopping doesn’t end well though. If you keep asking for additional opinions until you get the one you like, don’t be surprised if it comes back to bite you. I’ve seen legal opinions waved around as if it proves a point beyond doubt – including when the opposite side is exactly as confident.

Whether it’s a legal or actuarial opinion, it is critical to:

• look at what the team was asked to opine on, the exact wording of the request and answer;
• ask the team to present their views and engage in an informed Q&A session;
• explicitly ask how confident they are in the answer and then interrogate why; and
• ask the team what information or facts would have led to a different answer (and then check how sure you are on those underlying “facts”).

My ultimate weapon is to, where possible, ask for the opinion without the team knowing which answer you want. We can’t quite do double-blind testing but the closer you get the more you can trust the output.

It it useful to get that second opinion when the news is good too!

We are too ready to believe the things we want to believe. Terrible decisions can result from not testing good news.

Independent reviews can provide additional insights, a new perspective, and challenge existing thinking:

1. If it uncovers a fundamentally different perspective, you’ll be glad to have that additional information sooner than later. It is not a coincidence that it is when I am reviewing insurers in financial difficulty that I more often found problems in existing actuarial, financial, risk and governance matters. A series of bad advice has consequences and sometimes it takes a while for the results to be obvious. An earlier independent review can highlight these much sooner.
2. If independent review confirms everything is as expected, you have still gained the benefit of confidence to continue basing decisions on that information.
3. Best of all, the very practice of having occasional independent peer reviews helps to keep a sharp, objective focus from the original actuary. Knowing that someone will inspect your work is an excellent way to ensure quality of work, apply good practice and following actuarial guidance, not give in to pressure, steer clear of fraud, and ultimately think a little deeper.

Independent reviews aren’t only for spotting problems. In the past my reviews have identified new opportunities and insights to drive growth and innovation – identifying untapped complementary lines of business to drive growth, putting in place premium reviews to restore profitability, adjusting commission structures to skew sales towards profitable business, highlighting changes to renewal pricing practices to be more competitive, accessing Iterative Risk Margin and Loss Absorbing Capacity of Deferred Tax benefits to improve capital management.

As you read your next Board pack or actuarial report, consider how an independent review could help identify untapped opportunities, mitigate risks, and drive growth.

That’s the ballpark figure I usually work with as the minimum number of micro insurance policies required for scale. The expenses of running even a micro insurer are not that trivial.

For underwritten products within a full life licence? Larger premiums per policy but definitely more complexity. Competition is tougher too. Hyper local brands don’t translate into trust at this level. Viable niches may exist, but at what volumes?

You might wonder if there is scope to sell greater value products at higher premiums that can bring that number down in some contexts?

The rise of embedded insurance

Turns out this has been given plenty of thought already – “micro” insurance is the less popular name these days from a product and provider perspective. Inclusive Insurance certainly sounds better and more inclusive (!)

I think part of that push though was recognising the challenges and limits of truly “micro” insurance, at least at an individual level in providing commercially viable options that meet needs at the scale necessary.

Inclusive Insurance has been eclipsed in some words for “embedded insurance”, a term that talks less to the needs and objectives for society, and more to one that is practical and viable commercially. Embedding insurance in other products are services can drive down some of the costs, but then by virtue of being embedded, the absolute amount of premium is even further limited. Volumes may go up – and there have been some success stories here – but margins typically remain fine so I’m going to guess that my 40,000 may be too low in these instances. The success stories are in the 6- and 7-digit volume space.

Microinsurance licence restrictions

Back to “microinsurance” and the regulatory restrictions that apply in South Africa:

• Savings elements might seem attractive to increase premium size and provide “value” rather than a set price point. But savings elements are not permitted in microinsurance policies in South Africa.
• Loyalty schemes or cash back may be a way to attach greater value to a product, but again are not permitted in the microinsurance framework.
• Fairly large sums assured are possible within microinsurance – often attracting increased adverse selection or outright fraud.

Can product tailoring increase average premium?

Product tailoring can be expensive and can counter plans for
economies of scale while simultaneously targeting a smaller market. I’d still like to see more of this rather than pure commodity products. I’d be happy to be wrong if this approach meant a viable micro insurer could provide genuine value, see strong demand, and require fewer than 40,000 policyholders or comfortably sell more than that.

Microinsurance pros and cons – an important choice

A key point here is whether a standalone microinsurer is the right vehicle for a truly niche insurer? The increased governance and compliance policies effected by the major cell providers have frustrated cell owners and entrepreneurs, slowed down innovation and led them to look elsewhere. A microinsurance licence is a great option for some, but not a panacea for everyone.

I’ve helped insurers apply for licences, buy licences, consider alternative arrangements, and I’m sure at some point I’ll be working with micro insurers to transfers portfolios to other insurers and close down licences.

There is also opportunity to apply to the Prudential Authority for scope to do more with the licence, with careful consideration of the risks and capital.

Does digital fix everything?

Digital sales is a complex area. Some insurers have had some success with purely digital sales. But when these distribution channels are owned by someone else, the costs are not as low as “digital† might make you think. If NTUs are high, and premium collections are low, it can quickly become expensive. There’s a fine line between removing friction from a sales and underwriting process (which definitely improves sales) and making it so easy to “sell† that the customers haven’t really decided that they want what they’ve bought.

Parametric insurance – watch this space!

We should be doing far more with parametric insurance in South Africa. Thinking around climate risk and the positive role insurers can provide in this space (rather than only worrying about the risks it poses to them) may present some new opportunities. Insurers can apply their expertise in understanding and pricing risk, while providing a socially and economically beneficial product at a price that shows value and profit.

I have been pondering whether IFRS17 makes life interesting for microinsurers given the wording of FSM2 “Valuation of Assets, Liabilities and Eligible Own Funds” for microinsurers (issued by the PA). The interpretation and application challenges actually predate IFRS17. FSM2 makes some silent and unlikely assumptions around treatment of premium debtors for typical microinsurance business. More on that in a future article.

IFRS17 does make life interesting (in the worst meaning of the word) for microinsurers, in that they must all apply IFRS17 to their insurance contracts. There’s no reason not to apply the Premium Allocation Approach given restrictions on policy term – and this simplifies many of the calculations significantly. Whether the audit firms looking at microinsurers understand IFRS17 or the required disclosures is an important quite separate topic, but one which must be resolved independent of the prudential reporting basis itself.

So here’s a wild idea. Why not drop FSM2 altogether and align the prudential balance sheet with the IFRS one?