Except taxes aren’t certain. Not the amounts, not the timing, not the rules. And once you start pulling on that thread, the list of things we treat as certain, in our models and in our heads, gets uncomfortably long.

This is that list. It is not comprehensive, and it is not a claim that any of these things will change soon. The point is narrower and more useful: each item is something that felt impossible to imagine changing, right up until it changed. That feeling of impossibility is what this post is about, because the feeling is not evidence.

1. Taxes

South Africa introduced capital gains tax in 2001. Secondary tax on companies became dividends tax in 2012, at 15%, which became 20% in 2017. The corporate rate moved from 28% to 27% in 2023. VAT went from 14% to 15% in 2018, and in 2025 an announced further increase was scrapped after the political fallout, which is its own lesson: even the changes aren’t certain.

For life insurers the changes cut deeper. The four-fund tax basis arrived in 1993, and the risk policy fund was added from 2016, moving individual risk business from the I minus E basis to a corporate-style tax on profits. Anyone who had projected the tax cash flows of a risk book beyond 2016 on the old basis was simply wrong, through no fault of their modelling.

Yet most projection models take this year’s Income Tax Act and apply it to 2060. The amount of tax, the timing of tax, and the rules of tax all change, and they change more often than almost any other assumption we hold fixed.

2. Currency pegs

I worked in Lebanon in 2007. Insurers there held US dollar assets against Lebanese pound benefits, and pound assets against dollar benefits, and told me not to worry. There was no currency risk. The pound was pegged.

They had history on their side. The pound had been fixed at 1,507.5 to the dollar since 1997, a decade of perfect stability by the time I arrived, and it went on to hold for another twelve years. Then, from 2019, it lost more than 98% of its value, and the collapse took the banking system and those mismatched balance sheets with it. Dollar deposits became “lollars”, visible on the bank statement, inaccessible in practice.

Lebanon is not an isolated case. Sterling left the gold standard in 1931. The United States closed the gold window in 1971, ending Bretton Woods. Sterling was forced out of the ERM in 1992. Argentina’s one-to-one convertibility, in place for a decade and written into law, collapsed in 2002. And the Swiss franc’s floor against the euro, not even a peg, just a floor, was abandoned in January 2015 and the franc moved close to 20% in minutes, against the largest currency bloc in the world, in the middle of a trading day.

Against that record sits the Namibian dollar, pegged to the rand since 1993, along with the loti and lilangeni. Those pegs are fine. So far. Every peg on the broken list above was also fine, so far, right up until it wasn’t.

Judging pegs by the ones still standing is exactly the error. These are right truncated observations on data periods of hundreds of years. A peg that hasn’t broken is a censored data point, not a proof of safety. “Still pegged” only means the failure hasn’t been observed yet.

3. The biggest companies

None of the ten largest US companies of 50 years ago is in the top ten today. In 1975 the list was Exxon, General Motors, Ford, Texaco, Mobil, Chevron, Gulf Oil, General Electric, IBM and ITT. Oil and cars and machines, each one an institution nobody expected to be displaced.

Some fell further than merely out of the top ten. Kodak, a giant of that era, went bankrupt in 2012. Sears followed in 2018. General Electric, an original member of the Dow in 1896 and a continuous member from 1907, was removed from the index in 2018 after more than a century.

The investment crowd knows this statistic. It appears in every presentation on diversification and every argument for passive investing. But knowing it and believing it about today’s top ten are different exercises. Each of the 1975 giants looked as permanent then as the current ten look now, and the current ten look very permanent indeed.

4. Government debt

An A rating is meant to correspond to roughly a one in a thousand chance of default within three years. That figure comes from corporate rating transition studies, because the sovereign sample is too small to measure properly. Which is itself the point: there are so few rated sovereigns, and so few defaults among the well-rated ones, that a single Greece breaks the statistics.

And Greece happened. Rated A in 2009, restructured in 2012, with private creditors taking a haircut of more than half in the largest sovereign restructuring in history. Russia was investment grade weeks before its 2022 default. And for anyone who finds those examples comfortably foreign: South Africa defaulted in September 1985, freezing $13.6bn of foreign debt in the standstill that followed the Rubicon speech, with the financial rand resurrected to trap capital at home. The final payment on that 1985 debt was made in 2001, sixteen years later.

The usual response is that a government borrowing in its own currency cannot default, because it can print. Russia defaulted on its rouble-denominated GKOs in 1998. Printing was available. Default happened anyway, because default is a political decision as much as an arithmetic one.

We still discount liabilities on the government curve, hold government bonds at a zero capital charge for spread and default risk, and call the whole arrangement risk free. For most purposes that is a reasonable working convention. It is worth remembering that it is a convention.

5. Regulation

Not just the rules changing, which we half expect and occasionally even get consulted on. The interpretation and application of regulation can shift while the words stay identical.

Foreseeable dividends under SAM is a live example. The prudential standard has not changed. But the expected treatment has moved from deducting dividends from own funds once declared and near certain, to accruing an allowance for the coming year’s dividends through the quarterly QRTs. The SCR is unchanged, own funds are lower, and the reported cover ratio drops, on the same standard, for the same insurer, with the same balance sheet. Europe has seen the same dynamic: EIOPA has revised its guidance on matters like contract boundaries without any change to the underlying Directive.

This kind of shift is difficult to explain to a board. The regulation stayed the same but the answer moved. It sits in almost nobody’s risk register, precisely because the words on the page look so solid, and it arrives through industry letters, technical observations and supervisory feedback rather than through anything a legal review would catch.

6. Which power runs the world

Yes, this one is obvious. Persians, Greeks, Romans, Ottomans, British. Everyone knows empires end.

But obvious is not the same as internalised. A Roman in CE 50 could not have imagined Rome falling, and Rome had another four centuries in the west, and fourteen in Constantinople, of not falling to prove them right. In 1913 Britain ruled the largest empire the world had seen, close to a quarter of the map and of its people, and did not expect it to be dismantled within 50 years. India was gone by 1947 and most of the African colonies by the mid-1960s. The Soviet Union was a superpower until 1991, and then, within months, not a country.

Reserve currency status has already changed hands within the span of a long life: sterling held the position the dollar holds now, and lost it over the middle decades of the twentieth century.

Today, with the dollar in every reserve, US capital markets in every portfolio and Silicon Valley in every pocket, it is hard to feel that any of it could end. That difficulty is the whole point. It is exactly what certainty felt like in Rome, in London, in Moscow. I have no prediction to offer about when or how American primacy ends, and I would distrust anyone who does. The exercise is not prediction. The exercise is noticing that “I cannot imagine it” describes the limits of my imagination, not the limits of the world.

7. Whether to give your kids peanut butter

A palate cleanser, and a serious one. For years the official advice was to avoid peanuts in infancy, especially for high-risk children. The American Academy of Pediatrics recommended avoidance until age three in 2000. That guidance was withdrawn in 2008, and then the LEAP study in 2015 showed the opposite of the original advice: early exposure cut peanut allergy in high-risk infants by just over 80%, and by 2017 the formal guidance recommended deliberate early introduction.

Settled science on feeding children, followed conscientiously by a generation of parents, turned out to be not just wrong but inverted. If that can flip, the confident consensus in your own field deserves at least an occasional raised eyebrow.

The pattern

The pattern is not that things change. Everyone knows things change, and a list of changes is just trivia. The pattern is that each change was unimaginable the day before, to serious people with good information, and “unimaginable” turned out to be a statement about their imagination rather than about the world.

For those of us who build and rely on models, this has a practical edge. “Certain” in a model usually means “we chose not to model it”. Tax rules, the peg, the government curve, the supervisory interpretation: each is a variable somebody decided to hold constant. Sometimes that is a sensible choice. Modelling everything is neither possible nor useful, and a model that treats everything as uncertain tells you nothing.

But it is a choice, and it should be a conscious one. A worthwhile exercise, for an ORSA or simply for an afternoon: write down the certainties your model assumes, pick the one that feels most absurd to question, and ask what would happen if it moved. The one that feels most absurd is the interesting one. That feeling is the tell.

Even death only makes the certain list on outcome, not timing. Modelling the gap between the two is most of what actuaries do.

What belongs at number 8?

For both funeral policies and life microinsurance policies, the original sum assured benefit cap was set at R100,000. The rules say each escalates with inflation, but there is no consistent official source of the currently applicable amount. Is the CPI escalation really in force, enough that you can rely on it? How do you calculate it, exactly? And where do you find the figure for each year?

I have answers!

The short answer is that the escalation is real and automatic. It is written into the prudential standards, and the regulators have confirmed in writing that the limits rise “annually and automatically” with CPI (Joint Communication 4 of 2020, clause 3.4.1).

What is missing is a published number. Neither the Prudential Authority (PA) nor the Financial Sector Conduct Authority (FSCA) puts out the escalated figure for any given year, which is exactly why some insurers have been unsure whether to use it.

The post includes the caps, the primary source wording that specifies them, and the year-by-year values on official Statistics South Africa data. As always, the amount that applies to your specific product or licence is a question for your PA or FSCA frontline analyst before you rely on it.

The two caps – funeral and microinsurance

These two caps sit in different standards, for different insurers, but they are deliberately the same number.

The funeral cap. Prudential Standard GOI 7 prescribes, for the Funeral class of life insurance business, a

“maximum amount of R 100 000 (hundred thousand Rand) per life insured, escalating annually, from the commencement date of this Prudential Standard, by the Consumer Price Index (CPI) annual inflation rate published by Statistics South Africa, as defined in section 1 of the Statistics Act, 1999”

(GOI 7 clause 5.2, quoted verbatim by the Authorities in Joint Communication 7 of 2024, footnote 3). GOI 7 applies to insurers “other than microinsurers”, so this is the traditional-insurer funeral number. It commenced on 1 July 2018.

The microinsurance caps. The Governance and Operational Standard for Microinsurers (GOM), clause 11.1, prescribes:

“a) Life insurance: R 100 000 per life insured, escalating annually, from the commencement date of this Prudential Standard, by the Consumer Price Index (CPI) annual inflation rate published by Statistics South Africa…

2. Non-life insurance: R 300 000, per policy, escalating annually, from the commencement date of this Prudential Standard, by the Consumer Price Index (CPI) annual inflation rate published by Statistics South Africa…”

GOM commenced on the same day, 1 July 2018 (clause 3.1). Most life microinsurance is funeral business, so in practice the micro life cap is also mostly a funeral number.

The match is not a coincidence. It is deliberate consistency, so that what is, in many customers’ eyes, the same product faces the same limit whichever licence writes it.

The escalation is in force, and automatic

This is the part people are unsure about, so it is worth quoting the regulators directly. In Joint Communication 4 of 2020, the FSCA and the PA state, at clause 3.4.1:

“The PA confirms that the maximum prescribed limits will be increased annually and automatically by the CPI rate published by Statistics South Africa. Contractual increases automatic or otherwise must result in policy benefits that remain within the prescribed thresholds at any given point in time.”

Two things follow. First, you do not need an annual re-publication for the cap to increase. It moves by operation of the standard. Four years later the Authorities said the same, describing the GOI 7 cap as the maximum that “currently” applies (Joint Communication 7 of 2024, footnote 3).

Second, a CPI-linked benefit escalation is catered for. Set the starting Sum Assured at or below the cap, and it stays within the cap as both rise together.

The current values, year by year

Take the R100,000 base at the July 2018 index and scale it by the Stats SA headline CPI index (Table B1, December 2024 = 100). The standard names “CPI” without naming a reference month. I use the July index, because the escalation runs from 1 July, and the June index or the compounded annual rate give the same answer to within a tenth of a percent.

The 2018 to 2025 rows use the published July index. The 2026 row is provisional: the July 2026 index only publishes on 19 August 2026, so it uses the latest available index (May 2026) and will firm up then. The non-life column is the same calculation from a R300,000 base.

One independent check. The only escalated figure any official body has stated is a FAIS Ombud comment, quoted in the trade press in January 2024, giving the 1 July 2023 funeral maximum as R126,773.46. That is not a PA or FSCA publication, and the Ombud is a dispute-resolution body rather than the prudential regulator, so treat it as a cross-check rather than a source. It is a useful one: this method returns R126,693 for 2023, which is 0.06% away.

The escalation is mandatory, but neither the PA nor the FSCA publishes the resulting amount, which is why the only figure in circulation had to reach the market through an Ombud comment. So the number is yours to compute. I don’t know why there isn’t a single authoritative source. As always, if in doubt, check with your front line PA and FSCA analysts and get an answer to your particular case, for your particular product, and your particular licence conditions.

Important heads-up: What counts towards the cap?

The cap is per life insured, per insurer. Joint Communication 4 of 2020, clause 2.5 (footnote 1), explains that

“the amount that may be insured per life insured cannot exceed R100 000 in respect of a particular insurer, the number of policies under which such life is insured is therefore irrelevant”

So stacking several policies on one life with the same insurer does not raise the ceiling: four R30,000 policies do not pay R120,000, and that insurer may pay at most R100,000 on that life. Different insurers do not aggregate, though, so a life covered by several insurers can be paid up to R100,000 by each. That cross-insurer gap is the over-insurance issue the Authorities are now reviewing.

Riders count too, in aggregate. Clause 3.3.1 confirms the maximum “includes rider benefits” and that “the prescribed maximum limit applies to both primary and ancillary benefits on the aggregate”. Primary benefit plus every rider is summed against the one indexed cap.

A cashback rider, a grocery or education benefit, or a waiver of premium all draw on the same R100,000.

Double accidental death (where double the stated Sum Assured is paid on accidental death) is a particular case to watch out for. The PA lists “the double accidental death benefit that will lead to the R100 000 threshold being exceeded” and confirms it is subject to the cap like any rider.

In practice, offering a double accident death benefit effectively limits the base sum assured to half the cap, so that twice it lands on the cap rather than over it.

Cashback and loyalty benefits carry an extra restriction for microinsurers. GOM clause 11.2 provides that a microinsurer

“may not, without the approval of the Prudential Authority, issue a life insurance policy or a non-life insurance policy that provides for a loyalty benefit, no-claim bonus or rebate in premiums”

So a cashback framed as loyalty is both counted against the cap and, for a microinsurer, subject to approval.

Above the cap, you leave the Funeral class. Clause 3.2.1 confirms that funeral benefits above the maximum “may be provided under the Risk Class (Class 1) individual and group death”, provided the policy meets the Risk class description, and its footnote records that such a policy

“would not, for example, be able to provide benefits in the form of a funeral service (in-kind benefit) as the Risk Class description only makes provision for lump sum / monetary benefits”

So above the cap you must pay cash, under a Risk-class licence. That route is not open to a microinsurer, whose Risk business is capped the same way.

The bottom line

The escalation is real, automatic and written into the standards, so you can work out the current cap yourself: take the R100,000 base and apply the Stats SA index. Just keep in mind what sits inside that cap. Riders, cashback and the accidental death multiple all count against it, and it applies per life insured per insurer, not per policy. For confirmation though – ask your PA or FSCA analyst.

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?

Maybe. But maybe not. Let me take the scenic route to explaining why.

Driving my daughter to school, I occasionally spot someone tailgating or cutting across a solid line. What’s striking is how often within seconds I’ll see them make a second and third thoughtless move. Weaving without indicating, pushing into the off-ramp queue at the last moment – all the sorts of things nobody does in the queue at Woolies when there is accountability. Ring of Gyges stuff – and frankly unfair that both types of people populate this universe.

Yes, there’s confirmation bias here. I’m sure I make mistakes that annoy others. Attribution bias too – we forgive our own lapses as innocent mistakes while judging others harshly. I don’t think that’s all of it though.

What we’re observing is that observations are usually not independent. Errors cluster. They share root causes, be it time pressure, risk tolerance, cell phone use, attitudes towards others, personality, upbringing and more. Whatever produces one lapse doesn’t reset between intersections. One observation carries information about an underlying factor you can’t directly see.

When you see a pattern, update your priors on what comes next.

Back to that not-at-fault claim. A claim happened. And empirically, one claim predicts the next. The insurer often doesn’t know why, but the signal is there in the data. Maybe your car is parked on a busy road. Maybe it’s closer to a corner than ideal, or near a distracting intersection. Maybe street lighting is poor. Maybe it’s just a high-traffic area where the probability of someone having a bad day near your vehicle is elevated. As more complex analysis tools (yes including AI…) are applied, with more data and more context, we may get closer to understanding the hidden risk factors underneath the high level outcomes. Either way, the correlation is there.

The customer likely did nothing wrong. The premium increase can still reflect rational Bayesian updating.

Now, is it always this principled? No. Sometimes it’s crude loss-ratio management. The insurer just wants to recover what they paid out over time. Sometimes the pricing model can’t even distinguish at-fault from not-at-fault, so everything gets the same treatment. These practices exist, and they’re harder to defend.

The legitimate version, where claims predict future claims for reasons the policyholder can’t fully observe or control, that’s real too. And if the signal is real, not adjusting the premium means other policyholders cross-subsidise the risk. The question isn’t whether someone pays, but who.

If you feel this is still unfair, well I think you’re correct on some level, albeit not yet a practical one:

All risk rating involves a choice about what “fair” means. Is it fair that you pay a price tailored to your risk, even if that risk stems from factors you didn’t choose? Or is it fairer that we all pay the same, pooling our luck and misfortune together? The young driver pays more not because they decided to be nineteen, but because nineteen-year-olds crash more often. Risk-based fairness says differentiate. Solidarity-based fairness says pool.

These aren’t the same definition, and better maths won’t reconcile them. We try to draw lines, some factors “feel” acceptable, others don’t, but those lines are social and political choices, not mathematical ones. Therefore they will differ between people, between firms, and over time.

So next time your premium moves in a way that feels unjust, ask whether the insurer is being lazy or seeing something real. But also ask who else would pay if you didn’t. Insurance is a group exercise, and the maths doesn’t care about fault. Only we do.

I once read that meteorologists are better calibrated forecasters than stock pickers. By calibrated, I do not mean they are better or worse at forecasting, but that their level of confidence matches their accuracy. When they believe they are 80 % likely to be right, they are right about 80 % of the time. When they are uncertain, their forecasts are indeed less accurate. Stock pickers, and I suspect some economists, tend to be less well calibrated. They are not necessarily poor forecasters, but they are often overconfident, and that is a different problem altogether.

The point came from Superforecasting by Philip Tetlock and Dan Gardner, which explored how some individuals become remarkably well-calibrated forecasters through constant feedback and disciplined self-assessment. One reason meteorologists perform better is feedback. Stock pickers and economists can always point to exceptional events that explain why forecasts went wrong. Who knew there would be a drought, or that Russia would invade Ukraine, or that COVID-19 would shut down economies? There is always a convenient exogenous shock. Weather forecasters do not have that luxury. They live by feedback. They issue forecasts every day and are judged immediately by outcomes they cannot explain away. Their models evolve constantly because their results are tested constantly.

That contrast came to mind when I first encountered Computable General Equilibrium (CGE) models about a decade ago. They were intriguing. A little too clever, perhaps, and impressive in their scale. Thousands of equations, countless parameters, and from all of that emerges the predicted effect of an intervention on GDP, employment, or wages—sometimes quoted to two decimal places. At the time, it seemed remarkable, but I could not see the transparency I wanted. There was little evidence of how these models were calibrated, how reliable they were, or how confident one should be in their results.

I came across them again recently. I am not saying CGE models are unhelpful or that their results are wrong. They can be useful for exploring direction and mechanism – how substitution between sectors or between labour and capital might unfold. They are elegant frameworks for thinking through equilibrium interactions. What concerns me is the way they are sometimes used. There is often little effort to quantify uncertainty, measure accuracy, or report diagnostics that would tell us how well the model is performing. That makes me uneasy.

I would like to see genuinely robust studies that take a CGE model, generate predictions, and check them against what actually happens. Yes, there will always be surprises, but if the models barely outperform a simple trend line, the enormous complexity and opacity seem hard to justify.

Even before that, I would want to see what the model predicts with no intervention at all. CGE models are built to find a general equilibrium, but there is no guarantee the economy we feed in is itself in equilibrium. The first step should surely be to see what the model does on its own. If its natural equilibrium is very different from the starting point, that tells us something. Either the real economy is far from equilibrium, or the model’s structure is not reflecting it well.

I am not suggesting this problem occurs frequently, but the diagnostic results are rarely reported, and that makes me wonder whether it sometimes does. If the model is not allowed to reach its internal equilibrium before the intervention is applied, the change in GDP or other results could be partly driven by the model’s own adjustment toward equilibrium. It would be useful to know.

I would also like to see how stable the results are when the model is run with successive years’ data. If we input the economy as it stood each year, do the parameters and balances remain consistent? If not, that raises questions about the model’s stability. For example, can it predict the next year’s social accounting matrix (the SAM) with any meaningful accuracy? If it cannot, then I am not sure how much confidence we can place in the counterfactual results.

As I understand it, CGE models are calibrated rather than statistically estimated. They rely on factual data inputs, some parameters solved to achieve equilibrium, and elasticities imported from previous studies. Those elasticities differ across the literature, and the uncertainty around them is often considerable. How confident are we in those numbers? What happens if we vary them within plausible ranges? If small changes produce very different equilibria even before any intervention, then those elasticities are critical. If the results remain fairly stable, that is reassuring.

We could also test how much the estimated impact of a policy or intervention depends on these elasticity choices. If the results swing widely, confidence in the model’s precision should be low. And if the model’s internal uncertainty interval for GDP, wages, or productivity is wider than the intervention effect, that should be stated clearly.

In actuarial work, we routinely perform analysis of surplus to understand why results differ from expectations. We ask whether deviations stem from data, assumptions, or the model itself. That discipline drives improvement and professional scepticism.

Actuaries are not perfect. There are areas of our own work where experience analysis or model validation is weak. Some solvency projections (ORSA AvE notably, but there are others) , for example, are never properly reconciled to outcomes. That is disappointing, but at least the mindset of testing and validation is embedded in the profession. The actuarial control cycle is still taught.

We are also learning from “new” data science, which takes validation seriously. Models are trained and tested on different data, evaluated out of sample and out of time, and using techniques such as Monte Carlo Cross Validation (a new discovery for me) or k-fold cross-validation. These approaches help ensure that models perform reliably, not just on the data that built them but on data they have never seen.

I would like to see economists apply similar rigour to CGE modelling. Calibration is not validation. Without testing, backtesting, and clear communication of uncertainty, the apparent precision of these models can be misleading.

CGE models can be valuable tools, but their uncertainties and dependencies are often poorly understood, poorly expressed, and underappreciated.

Perhaps I am missing something. Perhaps these diagnostic checks are done quietly somewhere. I would be glad to be corrected by economists who understand these models better than I do. I am genuinely open to learning more.

Because if these models can withstand that kind of scrutiny, they deserve confidence. If they cannot, they still have value, but we should be honest about what they are: structured thought experiments with useful stories to understand. Not forecasts – and those second decimals places should never be shown.

This happens more often than it should in our profession. We read reports, proposals, and especially requests for proposals where the language is superficially sophisticated, but the actual message remains unclear. The natural response is to label this a “communication problem” – someone who knows their stuff but just can’t explain it clearly.

I think that misses the real issue.

The Real Problem Runs Deeper

If your thoughts actually aren’t that clear, you aren’t going to get them down clearly on paper. What appears as a communication issue is often actually a structured thought process problem.

I’ve seen this pattern repeatedly, especially with students and younger professionals. They’ll struggle to answer a question clearly, whether in writing or in person. When you dig deeper, it’s not that they can’t find the right words – they haven’t really figured out what they think about the problem in the first place.

The communications exam can be a bugbear for some people, and for different reasons. But some of the time when I see communication being a struggle, it’s students not being able to read the question, not being able to answer the question, or in our case with clients (or their procurement teams), not understanding what they’re really actually asking for. Because communication is at least half listening and receiving as it is writing down.

If you can’t understand the question and think about it, you can’t put your answer down, or your proposal down, or your scope down clearly. If your scope isn’t clear, good luck ever delivering on it.

Lead Astray To The Jargon Trap

There’s another layer to this problem that’s particularly acute in technical fields. Students get led astray by their peers, by teachers, and then by a lack of self-confidence about the right way to sound professional. They convince themselves that the way to appear competent is to use the fanciest, most convoluted language possible.

This becomes a malignant habit that gets reinforced over time – the more impressive you sound, the more professional you must be.

The opposite is true.

No one knows what you’re actually saying. I’m not sure you entirely know what you’re saying either.

The Writing Test

Here’s something I’ve learned from two decades of consulting: I can have seemingly amazing, brilliant ideas in my head that make complete sense. But when I have to write them down and explain them to somebody else, I sometimes realise it was complete nonsense. There were fatal flaws in my thinking, but it’s hard to keep all those complex ideas organised in your mind.

When you put it down on paper, you realise that doesn’t really work.

The discipline of writing – even if nobody else is ever going to read it – forces you to organise your thoughts. It reveals the gaps in your logic, the assumptions you haven’t examined, the connections that seemed obvious but actually don’t hold up.

This is why I find putting down notes incredibly useful, regardless of whether anyone else will see them. Writing isn’t just about communicating your ideas to others; it’s about clarifying them for yourself.

What Actually Works

The solution isn’t complicated, but it requires discipline:

First, figure out what you actually think. Before you worry about how to say something, make sure you know what you’re trying to say. If you can’t explain it simply to yourself, you don’t understand it well enough yet.

Second, choose clarity over impressiveness. Every time. The goal is understanding, not demonstrating your vocabulary.

Simpler words, simpler sentences, shorter sentences (but also a mix), active voice, more paragraphs and consciously ordered lists and tables – are all far more important than demonstrating familiarity with a thesaurus.

Third, take the reader on a clear journey. They haven’t been thinking about this for months like you have. Start where they are, not where you are.

Fourth, test your writing. Read it back. Better yet, have someone else read it. If they can’t follow your logic, that’s not their problem – it’s yours.

Beyond the Mechanics

I had the benefit of UCT’s Professional Communication Unit way back in 2001, which taught style and tone and formatting and structure. Everything they covered is still absolutely valid and relevant today – which says something about how timeless good communication principles are. But the technical aspects of writing – grammar, formatting, structure – are just the delivery mechanism.

The real work happens before you start typing: the work of thinking clearly about what you’re trying to accomplish, what your reader needs to know, and how to get them from where they are to where you want them to be.

This matters more than we sometimes acknowledge. Clear writing isn’t a nice-to-have skill that you add on top of technical competence. It’s fundamental to how you think through problems, how you test your ideas, and how you turn insights into action.

If you can’t write clearly about what you do, there’s a good chance you don’t understand it as well as you think you do.

This raises an important question: Should developing markets, including South Africa, adopt SFCR-style public disclosures? How do weigh the costs and benefits, and is this calculus different than in Europe?

The Case for Public SFCR Reporting

Enhancing Industry-Wide Risk Management

• Public disclosures let insurers benchmark themselves against their peers, highlighting best practices and exposing weaknesses.
• Insurers gain valuable insights into what “good” looks like, thus driving overall improvements in industry risk management standards.
• To my own interests, having more detailed information to understand the insurance sector and perform benchmarking would be invaluable. Hopefully my work has some value for individual insurers and maybe even the industry as a whole, but I recognise this point may have less weight for others.

Transparency and Trust

• Detailed reports provide analysts and policyholders with greater clarity into insurers’ operations, solvency, and risk strategies.
• It becomes significantly more challenging for insurers to differently represent (a range from gentle positioning to heavy spin to outright misrepresentation) their financial or risk positions to different stakeholders such as management, control functions, boards, analysts, and regulators when comprehensive information is publicly available.

Better Stakeholder Discipline

• Enhanced transparency makes it more difficult for insurers to conceal emerging solvency or risk issues, thus prompting earlier and more effective regulatory or market intervention.
• Analysts and rating agencies benefit from having direct access to consistent, detailed data, promoting market discipline and investor confidence.

The Downsides and Challenges

Cost and Complexity

• Producing detailed SFCR-style reports is resource-intensive, requiring substantial actuarial expertise, time, and money—resources that are often scarce in developing markets. This is not generally true in South Africa, but is absolutely true across the rest of the continent. Anyway, just because there are resources in South Africa doesn’t automatically mean this is the best use of their time, or that additional demands on these resources won’t impact the supply-demand equating level of salaries and therefore costs for insurers.
• Many insurers in developing markets face significant skills shortages, making it challenging to produce consistently high-quality reports. The level of current internal reporting could benefit from additional resources and time as it is.

Competitive Sensitivities

• Public disclosures risk exposing sensitive strategic insights to competitors, potentially placing companies at a disadvantage in competitive markets. This is often mentioned by insurers – it came out with the original IFRS4 disclosure requirements and again with the IFRS17 disclosure requirements.
• The thing is – I don’t know how many people trawl through competitor financial disclosures to uncover secret strategic source. I’m not dismissing the point, but I am questioning how much of an issue this is. With staff turnover and rotation through industry, there are plenty of mechanisms for more crucial practices to disperse across insurers.

Quality and Utility Concerns

• My experience across large numbers of South African insurers suggests that many insurers already go through the motions, incurring costs without value, in producing ORSA (Own Risk and Solvency Assessment) reports that are not used internally for anything other than compliance.
• Without careful oversight, SFCR-style reports risk becoming tick-box exercises—costly documents that serve regulatory compliance rather than genuine risk management.

Finding the Right Balance

Considering these points, adopting SFCR-style public reporting in South Africa and other developing markets should be approached cautiously:

• Incremental Implementation: Gradually introduce public disclosures, starting with key sections but with a clear roadmap so that insurers know now what they are building towards. There is merit in starting and producing something rather than having endless projects to produce some grand opus in 5 years’ time.
• Proportionality Principle: Ensure reporting requirements align with the insurer’s size and complexity – but this can’t mean that small insurers do nothing. The relevance of risks to each insurers must be considered.
• Standardisation with Flexibility: Provide clear reporting templates to minimise redundancy, enabling insurers to leverage internal reports such as ORSAs, thereby enhancing ongoing risk management practices. There is value in allowing insurers to customise their approach, especially for an ORSA, so that it is most useful for their internal purposes. However, the SFCR is an external document. There is arguably greater merit in standardisation for the reader (ease of navigation, ease of comparability) and for the producer (less time spent changing structure and content and wondering what is expected). Sometimes paint by numbers can great bang for buck.

Final Thoughts

Public SFCR reporting undeniably offers valuable transparency, improves risk management practices, and strengthens market discipline. However, the real challenge is striking a balance—achieving meaningful disclosures without imposing excessive burdens. If implemented thoughtfully, tailored to market realities, and aligned with insurers’ practical capacities, SFCR-style reports could become an essential part of strengthening insurance markets in South Africa and beyond.

In a world where even detailed internal reports like the ORSA are often unread compliance artefacts, is it naïve to think public SFCRs will be any better? Maybe. But transparency has a strange way of forcing people to care. It may be that the SFCR, being publicly available to analysts, regulators, academic researchers, students, and consultants (!) will find more traction and more use than most ORSAs.

The act of writing for an external audience can clean up fuzzy thinking and force clearer articulation of risk positions—something that internal-only reports often fail to achieve. It’s one thing to desire diverse views on a Board, but group-think and anchoring are all too common. I’ve lost track of the number of times the discipline of writing things down has made me realise the ideas in my head weren’t quite as brilliant or even consistent as I’d thought.

Perhaps SFCRs can do that at scale.

This article outlines a collection of common and problematic pitfalls I’ve seen in ORSA stress and scenario testing, capital modelling, and governance. Some are technical, some cultural, and all are worth addressing if we want the ORSA to do what it should: support better decision-making under uncertainty.

These insights reflect my experience across a wide range (and varying quality) of ORSAs, including independent reviews, informal and formal regulatory feedback (including from the Prudential Authority), informal discussions with regulators, and public statements from supervisors across multiple jurisdictions.

1. Toothless Scenarios and Soft Stresses

• Many ORSA scenarios are too mild to test anything meaningful.
• Often there’s no indication of severity. Is this a 1-in-5 or 1-in-50 event? Without context, interpretation is impossible.
• Firms are sometimes surprised they survive a 1-in-200 scenario, forgetting that survival at that level is by design.

2. Recycled, Stale, or Misaligned Scenarios (and Ignored Emerging Risks)

• Same tired stresses reused each year without meaningful refresh.
• Narrative scenarios assigned numerical calibrations that don’t match the story.
• Horizon scanning is often absent or perfunctory; emerging risks must be systematically identified and tested.
• Scenario testing should anticipate what could plausibly happen next, not merely repeat past events.

3. Implausible or Alienating Scenario Design

• Unrealistic or inconsistent scenarios alienate management and the board.
• Severe scenarios are valuable, but they must be framed with historical precedent or research to be credible.
• Overconfidence in models is dangerous; even the best models can fail catastrophically, as history shows.

4. Over-Engineering vs Usefulness

• Attempting to build the “most accurate” pandemic scenario misunderstands the point: scenarios are for learning and planning, not for prediction.
• Prioritise strategic insight over technical perfection.

5. Investment Returns Detached from Reality

• While not common, flat investment income across stress scenarios is a serious modelling failure.
• Investment returns must reflect changes in asset levels and market conditions under stress.

6. LACDT: Tax Calcs Behaving Badly

• Deferred tax recoverability often lacks robust testing.
• Future stressed profits must first create a DTA before any LACDT benefit can be recognised. Tiering here can hit you – more than you considered for the base SCR calc and your QRT.
• Income vs capital gains treatment and tax fund nuances are often overlooked.
• Just because LACDT can’t be negative (per the FSIs), doesn’t mean you can’t have existing DTAs fail recoverability testing in a stress and have loss amplification from deferred taxes!

7. Tiering and Fungibility Constraints Not Considered

• Capital tiering restrictions often ignored under stress.
• Assumed fungibility between entities or tiers can be unrealistic, especially under stress scenarios.
• See the point about DTA and tiering above too.

8. Over-Reliance on Standard Formula Extrapolation

• Normal distribution assumptions are often inappropriate; t-distributions, Lognormal, Pareto tails, or piecewise fittings are better suited.
• Ideally your own experience should be able to inform 1 in 10 stresses and act as a sanity check on scaled 1-in-200 stresses.
• Thin historical experience leads to poor calibration of rare-event risks, especially for equity markets.
• And really, there are several standard formula stresses that are probably not appropriate as a starting point. Some non-life cat stresses may be too conservative – and mass lapse has its critics, but life cat risk, expense risk, and retrenchment risk stresses are likely too low.

9. Unrealistic Business Volume and Expense Assumptions

• Base cases often adopt stretch targets as certain outcomes.
• Expenses are incorrectly assumed to scale perfectly down with policy volumes, ignoring the reality of fixed costs.

10. Incurred vs Paid Confusion

• Claims incurred and claims paid are routinely confused. The impact on profit vs balance sheet and cash can be counter-intuitve.
• Timing differences, especially under IFRS 17 (LCI/CIP dynamics), matter for liquidity and solvency modelling.

11. Short Projections for Long Risks

• Three-year horizons are insufficient for long-burn risks including the obvious candidate – climate change.
• Five years should be the baseline internally, with qualitative insights over longer horizons. Yes, the reliability decreases as the term increases, but it can still be informative. You may chose to disclose only 3 years more broadly, but the longer view is important to at least understand trends.
• Long-term (10–30 year) qualitative assessments should supplement the ORSA, accounting for amplifying systemic interactions.

12. Disconnect Between ORSA and Management Forecasts

• Management runs the business based on one view; the ORSA is prepared using another.
• Without alignment, the ORSA cannot pass the use test or add value to strategic decision-making.

13. Ignoring Dynamic Risk Interactions

• Risks are often modelled in isolation.
• In reality, correlations and feedback loops matter: lapse impacts guarantees, claims experience shifts reinsurance pricing, and market volatility affects lapse and claims simultaneously.

14. Either No Management Actions, or Superhero Versions

• Some ORSAs model no management actions (overly conservative but unrealistic).
• Others assume immediate, flawless actions without delay or cost (equally unrealistic).

15. Unexplained Profit and NAV Changes

• ORSA profit projections must reconcile to balance sheet movements.
• Adjustments between IFRS and SAM/Solvency II frameworks should be clearly documented.

16. ORSA Process Too Slow to Be Relevant

• A nine-month ORSA development cycle leads to stale outputs.
• ORSA timing must be aligned with the business planning cycle and responsive to external shocks.

17. Weak QA and Model Review

• Detailed, independent model review is often absent.
• Common failures include claims timing mismatches, unrealistic ROEs, omitted asset growth dynamics, and unstated assumption interactions.

18. Boilerplate Overload, Insight Underload

• ORSAs are often bloated with standard wording, burying the important insights.
• Focus must remain on what is changing and what genuinely informs management decisions.

19. No Trigger or Process for Out-of-Cycle ORSA

• Firms sometimes only trigger an out-of-cycle (OOC) ORSAs for an SCR breach — far too late. If the risk or solvency situation (internal or external) has changed, it’s time for an OOC.
• Proportional, trigger-based OOC ORSAs must be defined and actioned when material changes occur.
• An OOC doesn’t need to cover the entire process or the full 80 page report. Just the key parts that have changed.

20. Reverse Stress Testing as an Afterthought

• Reverse stress testing needs to explore genuinely different failure modes, not just ramp up severity.
• Defining what constitutes “failure” (capital breach, strategic collapse, or profitability death spiral) needs careful thought.

21. Weak or Missing Rationale for Scenario Selection

• Documenting why scenarios are chosen reveals how the firm prioritises risk.
• Disconnects between identified risks and tested scenarios highlight critical weaknesses.

22. Board Engagement and Use Test Failures

• Board sign-off without meaningful engagement misses the point.
• Effective risk functions bring ORSA components to the Board repeatedly during the year to drive strategic debate.

In Closing

None of these issues is inevitable. Most stem from habits — some from lack of scrutiny, others from good intentions that weren’t tested hard enough. But if the ORSA is to support real-world resilience, it has to reflect how capital and risk actually behave. That means grounding assumptions, engaging the business, and constantly asking: “Would I act on this?†

If the answer is no, the ORSA needs work. If the answer is yes, you’re on the right track.

Hyperinflation, Currency Crises & Insurance Industry Collapse

Hyperinflation destroyed Zimbabwe’s insurance sector, and decades later, it still hasn’t recovered. Currency crises in Lebanon, Argentina, and Venezuela have crippled financial institutions, showing how fragile financial systems can be when trust in money itself disappears.

A recent discussion started as a tongue-in-cheek debate: Is inflation a more efficient way to raise revenue than taxation? But it evolved into a broader debate on monetary risk, Bitcoin, inflation, and long-term economic trends—and why so many common arguments deserve scrutiny.

How Inflation Impacts Insurance

Premiums & Inflation Risk
High inflation makes level premiums unworkable, erodes the real value of cover. Optional benefit increases create adverse selection problems in life insurance. Even constant percentage increases fail under volatile inflation, and real wage stagnation worsens affordability pressures.

Monetary Instability & Insurer Solvency
Currency collapses create huge challenges for insurers trying to meet liability obligations in real terms. When inflation spikes, reserves built on past assumptions become grossly inadequate, leading to solvency concerns and even industry-wide failure.

Crypto & Smart Contracts in Insurance
Blockchain has potential for parametric insurance, automated claims processing, and fraud reduction. But much of the excitement outpaces practical application—or solves problems that were already solved while not addressing key remaining challenges.
(And let’s be real—just because a smart contract auto-executes doesn’t mean lawyers won’t find ways to argue intent and “meeting of minds.†)

My (Cautious) View on Blockchain

I spoke at the 2016 ASSA Convention on Seductions of the Blockchain, and my position remains:

• Cautiously optimistic
• Interested in opportunities
• Frustrated by the lack of rigorous debate from both fanatics and skeptics

The fanboys see blockchain as a cure-all, while the status-quo-invested skeptics dismiss it entirely. Reality, as always, is more nuanced.

Key Arguments & Concerns

1 Inflation as an ‘Efficient’ Tax?

Some argue that taxes are administratively complex, difficult to collect, and inflation acts as an “invisible tax† that transfers wealth to the state with less friction.

The Problem? Inflation isn’t a neutral mechanism:

• Distorts price signals and makes long-term contracts unreliable.
• Increases uncertainty and raises borrowing costs.
• Disproportionately harms those without inflation-protected assets—often the poorest.
• Erodes trust in government’s ability to manage financial stability.

Hyperinflation isn’t just caused by overspending—it requires excessive money printing to cover deficits. Many governments (e.g., Japan, the US, and EU countries) have run huge deficits for years without hyperinflation because they borrow responsibly instead of monetising debt.

Friedman’s famous quote:
“Inflation is always and everywhere a monetary phenomenon in the sense that it cannot occur without a more rapid increase in the quantity of money than in output.”

2 Bitcoin as a Predictable Alternative to Fiat?

Bitcoin proponents argue that a fixed supply prevents inflation and provides monetary certainty. But there’s a flip side:

The Problem? A rigid money supply is deflationary, which discourages spending and investment:

• BTC expansion (~0.9% today, falling below 0.5%) is well below global population and economic growth.
• Fixed-supply currencies have historically failed because economies need monetary flexibility to adjust to shocks.
• A deflationary currency discourages productive investment. If BTC’s price is expected to rise, why spend it? Why take out a loan?

This is why almost all mainstream economists—from Keynesians to monetarists—support some level of controlled monetary expansion.

Academic reference: Friedman advocated rules-based money supply growth, not a hard cap. Even Hayek, a proponent of free-market money, acknowledged the need for adaptable monetary systems.

A bigger issue: Some crypto coins have fixed supply, but the total universe of crypto coins is unlimited. New projects, forks, and tokens emerge constantly, meaning there is no true scarcity at a system-wide level.

3 Credit Risk & Smart Contracts – Who Pays When the Funds Aren’t There?

Smart contracts don’t solve credit risk. Traditional insurers must hold capital reserves and meet solvency requirements to ensure claims can be paid. Smart contract-based insurance lacks an equivalent safety net—yet.

Key Risks:

• No Guarantee of Payouts: If a smart contract is underfunded, it can’t issue emergency capital or negotiate claims—it just fails.
• Over-Collateralization Isn’t a Perfect Fix: Many DeFi protocols require excessive collateral to mitigate risk, but this limits scalability and locks up capital inefficiently. Actuarial approaches to capital adequacy could provide a smarter balance.
• Cascading Failures in Market Shocks: A major market downturn can cause mass liquidations, leading to systemic failures—just like traditional financial crises, but with fewer stabilizers.

Future Opportunity:

• As DeFi regulation increases, some form of capital adequacy requirements (like Solvency II for insurers) may emerge.
• Actuaries and insurance risk experts could play a role in designing smarter DeFi risk models.

Final Thought: Smart Contracts Are an Exciting Tool—but They Need More Work

Smart contracts introduce new efficiencies, but they also introduce new risks:
They remove intermediaries—but also eliminate safety nets.
They change fraud risk—but introduce oracle manipulation risk.
They enable fast, automated transactions—but don’t guarantee funds will always be there when needed.

For insurance, finance, and risk management, blind reliance on smart contracts is dangerous. But recent advancements show promise:

• Regulators are starting to provide legal clarity.
• Hybrid smart contracts (automated + human oversight) are emerging.
• Decentralized oracles & improved collateral models are evolving.

The real opportunity? Combining smart contract automation with actuarial risk management principles to build more resilient decentralized insurance solutions.

Would love to discuss with those working in insurance, risk management, DeFi, and blockchain regulation.

#Inflation #Blockchain #BTC #ETH #DeFi #DistributedLedger #MonetaryPolicy #FinancialRisk #Insurance #RiskManagement #Actuary #Economics #LegalRisk #ParametricInsurance