Running old promises on systems that must change

Our oldest savings contracts were sold with minimum credited rates and annual revaluation linked to segregated funds, and many will remain in force into the 2040s. I plan their administration across that horizon rather than across a supplier contract or a budget cycle. That means keeping product rules documented outside the code, reconciled each year with the policy conditions and signed off by the actuarial function. It means tracking which variants still have live policies, so that effort follows obligations rather than the volume of code. And it means being able to answer a board's plain question: what would it take to move these books, and how long would we need? Closed books attract little attention, yet an error in a 1996 contract is as real to that policyholder as an error in one sold last month.

Solvency II expects us to notify our supervisor before outsourcing a critical or important function, and DORA now requires a register of every ICT third-party arrangement, specific contractual rights and exit strategies for services supporting critical functions. I treat those requirements as the minimum description of sound oversight. For each material supplier I want to know who in Corvelline owns the relationship, what evidence we receive, when we last tested our ability to leave and which sub-contractors sit behind the service. Concentration matters as much as any single contract: two of our critical services depend on the same hosting region, and the board knows it. I would rather show directors an honest dependency map that still has gaps than a complete-looking register that hides them.

Legacy skills are usually discussed as a staffing problem. I see them as a risk to the accuracy of policyholder benefits. Our COBOL specialists know why a batch step exists, not only how it runs. Since 2023 we have paired six graduates with experienced colleagues for two years, rotating them through product changes, year-end revaluation and incident support. Each pair produces documentation an actuary can read, written in terms of policy conditions rather than program names. I measure the programme by how much year-end work we complete without external contractors, and by how many product rules still live only in someone's memory. Both numbers have improved; neither is finished. Contractors remain useful for peaks, but they should never be the only people who understand a promise Corvelline made.

Nearly half of our new premiums arrive through broker firms, and our tied agencies use the same portal, so it is part of distribution rather than an IT convenience. At a broker group I learnt how intermediaries actually work: shared offices, several insurers' systems open at once and heavy pressure at year-end, when pension contributions peak. Security has to fit that reality without being weakened by it. Every portal user now authenticates with a second factor, using an app or a hardware key, and each broker firm has its own administrator who manages its staff's access. We monitor sessions for unusual behaviour and restrict bulk viewing of policyholder records. I review portal changes with the commercial director, because a control that brokers evade with shared accounts protects nobody.

Our risk committee receives a quarterly ICT-risk report that I prepare with the chief risk officer's team. It covers incidents and their classification against DORA's major-incident criteria, the results of recovery and resilience testing, open audit findings, supplier dependencies and progress on remediation. Where personal data is involved, the data-protection officer's GDPR assessment sits beside ours. I try to make each item answer three questions: what happened or could happen, what it would mean for policyholders and the company, and what decision the committee is being asked to take. I avoid colour-coded summaries that carry no explanation. A committee should be able to disagree with my judgement, and it can only do so when the evidence is in front of it.