Chesnara plc

Actuarial Modelling & Data Solution

Howden Insurance Actuarial & Longevity (IAL) — Proposal (Option B)

27 July 2026

Private & Confidential

Executive Summary
Your Team
Technology Choice
Data Solution
Actuarial Modelling
Implementation Plan
Resource Plan
Scalability
Commercial Model
Case Study
Appendix A: About Howden
Appendix B: Technical architecture and process (illustrative)

1. Executive Summary

The Scottish Widows Europe SA (SWE) portfolio acquired as part of Project Sheen requires a documented, validated and audit-ready actuarial data and modelling solution that supports reporting requirements today and can evolve as Chesnara’s needs develop.

Following discussions with Jason Treadwell and the wider Project Team, and having considered the clarification responses to this Request for Proposal (RFP) provided on 14 July 2026, our proposal is designed to deliver those outcomes.

We propose Option B for the data workstream: Howden will build the data solution and provide resource to perform and transfer the data ingestion process through implementation, alongside a full Python actuarial modelling solution that Chesnara will host and own.

You will benefit from a documented, validated and audit-ready actuarial data and modelling framework built in Python, underpinned by actuarial modelling, data and reporting expertise, with a strong focus on documentation, validation and governance.

The result will be a scalable, transparent and flexible solution that supports the project timetable, preserves the strengths of the current Lloyds process (including working-day-one model-point production and Luxembourg Generally Accepted Accounting Principles (Lux-GAAP) / Solvency II outputs), and gives Chesnara full ownership of the solution on payment, with no ongoing licence costs and no vendor-specific lock-in.

Area	Description	What this means for you
Python-based solution	We will build your solution in Python, with no ongoing licence costs and no vendor lock-in. The solution will be scalable and easy to extend.	A fully customised solution that meets your needs, with complete ownership and flexibility to adapt as future acquisitions are integrated.
Option B data delivery	Howden builds the data pipelines and provides hands-on ingestion resource through implementation, with structured handover to Chesnara.	Faster path to working-day-one model points, stronger controls during the critical path, and internal capability built through co-delivery.
Large expert team	Howden Insurance Actuarial & Longevity (IAL) brings together 80+ insurance actuarial professionals from the Barnett Waddingham and Hymans Robertson insurance teams (see Appendix A).	Delivery by skilled experts with bench strength to protect the timetable when unforeseen issues arise.
Proven expertise	Extensive experience of audit support, model build and model transformation. We know what good model governance looks like.	Models and processes designed to meet internal governance standards, with documentation and testing aligned to what auditors look for — reducing audit queries.
Actuaries first	Led by actuaries, supported by a dedicated lead developer and software engineering resource.	More than a specification build: challenge on product features, materiality and methodology, with models aligned to Technical Actuarial Standards and outputs fit for downstream reporting.
Full intellectual property (IP) on payment	Engagement covers the build phase. On payment, Chesnara owns all code and IP. Hosted on Chesnara’s platform.	No multi-year platform licence; infrastructure under your control; freedom to evolve the estate.

We would be delighted to build a strong working relationship with you and look forward to discussing our proposal. Please get in touch with any clarification questions.

Amit Lad — Project Lead
Kim Durniat — Guardian Partner & peer review
Howden Insurance Actuarial & Longevity

2. Your Team

We have assembled a lean, actuarially led team drawing on the combined strength of the Barnett Waddingham and Hymans Robertson consulting practices within Howden IAL, supported by dedicated software development capability and the wider Howden IAL bench.

Role	Name	Focus
Guardian Partner & peer review	Kim Durniat FIA (Fellow of the Institute and Faculty of Actuaries)	Partner accountability, peer review, escalation
Project Lead & delivery management	Amit Lad MMath FIA Chartered Enterprise Risk Actuary (CERA)	Overall delivery, client management, plan / risks / milestones, workstream coordination
Data workstream lead	James Hadley	Data architecture, pipelines, data quality (DQ), Option B ingestion and handover
Model workstream lead	Sam Underhill FIA Fellow of the Institute of Actuaries of Australia (FIAA)	Model architecture, product builds, Solvency II (SII) / Lux-GAAP, cost of guarantees (COG) switch
Testing lead	Andrew Mason	Test strategy, independent testing, user acceptance testing (UAT) support, evidence packs
Lead developer	Allan Engelhardt	Engineering lead: Python architecture, run controller / graphical user interface (GUI), database integration, performance, deployment
Wider Howden IAL resource	As required	Surge capacity (parallel run, specialist review, additional developers)

There is no separate project manager — delivery management sits with the Project Lead to keep the team actuarially led and efficient.

Kim Durniat FIA — Guardian Partner & peer review

Partner and Head of Insurance & Longevity Consulting. Kim ensures clients receive high-quality advice and develops service offerings to the insurance sector. She holds the Life (including with-profits) certificate and acts as Actuarial Function Holder, Reviewing Actuary, Appropriate Actuary and Signing Actuary. She advises boards and senior managers across clients from friendly societies to Lloyd’s life syndicates and large international insurers.

Relevant expertise includes board advice on reserving and capital, peer review including audit support, mergers and acquisitions (M&A), Solvency II, governance reviews, with-profits, model validation, and Independent Expert / Skilled Person reviews.

Amit Lad MMath FIA CERA — Project Lead & delivery management

Principal, Insurance and Longevity Consulting. Amit plays a central role in regulatory, bulk annuity, transactional and technology offerings. He is Matching Adjustment subject matter expert (SME), leads technical engagements, and undertakes Senior Manager Function 20 (SMF20) roles with his Chief Actuary (Life) Practising Certificate. He is author of the annual with-profits investment performance survey.

Relevant experience includes Part VII (insurance business transfer under the Financial Services and Markets Act) / Independent Expert support, systems implementation and testing, process automation and model transformation, and outsourced actuarial valuations.

James Hadley — Data workstream lead

Senior Consultant, Howden IAL. James works on insurance and longevity analytical engagements, including published analysis of United Kingdom (UK) working-age mortality for insurers.

On this engagement he leads data architecture, Lifeware / State Street ingestion design, data quality and controls, and Option B operate-and-transfer through to Chesnara ownership.

Sam Underhill FIA FIAA — Model workstream lead

Partner and Senior Technical Actuary. Sam heads the Actuarial Calculations Team and has extensive experience developing and running bespoke actuarial modelling software, alongside UK and Australia actuarial consultancy (valuations, cashflow modelling, bulk annuity cashflows).

Andrew Mason — Testing lead

Associate and Senior Consulting Actuary, Howden IAL. Andrew supports life insurance clients with particular strength in automation, tooling and independent checking (including model-point conversion pipelines and automated checking).

He owns test strategy, independent testing, UAT support and audit-ready evidence through the June 2027 parallel run.

Allan Engelhardt — Lead developer

Principal and Head of Management Decision Analytics. Allan advises organisations on delivering commercial and operational value from data and analytics, with experience building accountable data science capabilities and client-side executive leadership (including organisations such as Vodafone, Eircom and Bupa Global).

On this engagement he leads software engineering — architecture, run controller / GUI, database integration, performance, packaging and deployment onto Chesnara’s platform — so Chesnara inherits maintainable, well-engineered code.

3. Technology Choice

3.1 Recommendation: Python for data and modelling

We recommend Python for both the data solution and the actuarial modelling solution. After assessing proprietary vendor platforms and open-source alternatives, Python best meets Chesnara’s priorities: governance and transparency, performance at Scottish Widows Europe SA (SWE) volumes, ease of implementation on Chesnara infrastructure, full IP ownership, and scalability for future M&A.

Python has become the industry standard across finance and related sectors because it combines powerful numerical capability with exceptional flexibility. Rather than relying on proprietary technologies that create ongoing licence cost and vendor lock-in, Python provides an open, well-supported platform that allows Chesnara to build, own and evolve solutions alongside the business.

For this engagement, “technology choice” covers four linked decisions:

Language / calculation platform — Python
Data processing libraries — NumPy, Pandas and Polars (used where each is strongest)
Hosting and runtime — Chesnara-hosted, Python + database
Operating model — Chesnara owns and runs the estate after build; Howden builds, transfers and supports

3.2 Why not a proprietary vendor modelling stack?

Factor	Proprietary vendor stack	Python (our recommendation)
Licence cost	Ongoing licence / concurrent-user / capacity fees	No ongoing model licence after build
Ownership	Vendor controls roadmap; limited IP	Chesnara owns all code and IP on payment
Lock-in	Contract term and migration cost to exit	Build-phase engagement only; portable code
Transparency	Logic often opaque or package-constrained	Open, reviewable actuarial code
Custom fit for SWE / Lux	May require workarounds for Lux-GAAP / Commissariat aux Assurances (CAA) and co-existence with contractual service margin (CSM)	Built to Chesnara’s product specs and output needs
Future books	New books may drive further licence / workspace cost	Same platform; incremental build cost only
Talent & maintainability	Specialist proprietary skills	Broad Python talent market; actuaries can own calculations

We are experienced with both vendor-based and open-source actuarial models. For Chesnara’s stated goals — operate models entirely within the Group, avoid lock-in, and scale with acquisitions — Python is the clearer fit.

3.3 Python ecosystem we will use

One of Python’s greatest advantages is its mature ecosystem of specialist libraries. We use best-in-class tools for different aspects of data processing and calculation, rather than forcing one library to do everything.

Library	Overview	Primary strength	Business benefit
NumPy	Foundational numerical computing library for highly optimised array and mathematical processing	High-performance numerical processing	Fast calculations; efficient analytics; support for advanced modelling workloads
Pandas	Industry-standard framework for structured business data from multiple sources	Data manipulation and business analysis	Rapid development; broad compatibility; powerful reporting; integration with existing extracts
Polars	Modern high-performance DataFrame library for large-scale processing	Large-scale data processing	Improved speed; lower memory use; headroom as volumes grow or further books are added

These technologies complement each other. Typical pattern for this programme:

Ingestion and transformation (Option B): Pandas / Polars for Lifeware and State Street extracts, mapping, DQ and model-point production
Core actuarial calculations: NumPy-backed routines for cashflows, discounting and capital building blocks
Reporting outputs: structured tables for SII, Lux-GAAP / CAA, Analysis of Change (AoC) / Analysis of Surplus (AoS) model outputs, and CSM landing files

3.4 Target architecture (Chesnara-hosted)

The solution will be hosted by Chesnara on Chesnara’s platform of choice. Howden does not propose a Howden-hosted SaaS platform.

Minimum environment (to be confirmed with Chesnara information technology (IT) at mobilisation):

Layer	Requirement
Runtime	Supported Python version (agreed at kick-off); package management (e.g. pip / poetry / conda as preferred by Chesnara)
Database	Access to a relational database for staging extracts, validated model points, run metadata, DQ results and audit logs
Storage	Secure file / object storage for source extracts, assumption sets and output packs
Access control	Role-based access for developers, production users and read-only reviewers; segregation of non-production and production where required
Deployment	Repeatable deployment via continuous integration / continuous delivery (CI/CD) pipelines (see Section 3.6) so changes are controlled, tested and reproducible
Connectivity	Controlled access to Lifeware / State Street extracts (file drop and/or application programming interface (API) as available); no requirement for Howden to host data

Logical components

Data ingestion & DQ services — extract → validate → transform → model-point / assumption stores
Calculation engine — hierarchical product models; deterministic non-profit (NP) / with-profit (WP); SII and Lux-GAAP frameworks; COG switch
Run controller (GUI) — configure runs, inputs, scenarios and output packs without editing code
Output & audit layer — results landing area for finance / CSM; run log; settings snapshot; reproducibility

This separation of orchestration (GUI / run control) from calculation means Chesnara actuaries can operate and, over time, amend calculations with clear testing and documentation disciplines.

3.5 Benefits for Chesnara

Benefit	Detail
No ongoing licence costs	No per-user or per-policy model licence after build
Full ownership	Chesnara owns code and IP on payment
Flexibility	Easy to extend for new products, COG methods and future books
Performance	Mature numerical and data stack suited to ~45,000–60,000 policies today, with headroom
Auditability	Transparent calculation logic; reproducible runs; clear audit trail
Database integration	Native fit to Chesnara’s chosen database and file estate
artificial intelligence (AI)-ready (optional later)	Natural path for future analytics / controls innovation, subject to Chesnara approval and regulatory expectations (RFP terms and conditions (T&Cs) on generative AI respected)
Ease of implementation	Greenfield post-separation build; no forced migration off a Chesnara-owned stack later

3.6 Continuous integration and continuous delivery (CI/CD)

We will use a CI/CD approach for development of both the actuarial models and the Option B data pipelines. This brings software-engineering discipline to actuarial change, so that every material update is versioned, tested, reviewed and releasable in a controlled way on Chesnara’s platform.

CI/CD is particularly valuable for this programme because Chesnara will own the code, host it internally, and need to operate and evolve it after handover — including under co-delivery and future M&A onboarding.

How CI/CD will work in practice

Stage	What we do	Why it matters for Chesnara
Source control	All model and data-pipeline code, configuration, tests and documentation live in a version-controlled repository (e.g. Git) on Chesnara-approved infrastructure	Full history of who changed what and when; supports audit and rollback
Branching & peer review	Changes developed on branches; merged only after review (actuarial and/or engineering, depending on the change)	Reduces key-person risk; embeds four-eyes discipline before code reaches shared environments
Continuous integration (CI)	Every proposed change triggers an automated pipeline: dependency install, style/quality checks, unit tests, and regression tests against agreed expected results (“golden” outputs) where defined	Breaks are found early — before UAT or parallel run — not at reporting deadlines
Test evidence	Pipeline stores pass/fail results, logs and (where relevant) output comparisons as artefacts	Supports model governance, internal review and external audit
Build & package	Successful builds produce a versioned, reproducible package of the model/data solution	Same artefact can be promoted across environments; avoids “it works on my machine”
Continuous delivery (CD)	Approved packages are deployed to Chesnara non-production environments automatically or via a one-click controlled promote; production release requires agreed sign-off	Faster, safer releases; clear separation of develop / test / production
Release traceability	Each run can record the model version / commit / package identity in the run log and audit trail	Reproducibility: Chesnara can show exactly which model produced a given valuation output

Actuarial controls inside the pipeline

CI/CD does not replace actuarial judgement — it enforces the control framework around it:

Specification-linked change — material methodology changes remain tied to agreed model specifications and Chesnara review.
Automated calculation tests — product cashflow building blocks, COG switch paths (deterministic / Black–Scholes / stochastic hook-up), and SCR / reporting output checks where automated assertions are practical.
Regression packs — representative model-point sets and expected results for NP UL, WP and key SII / Lux-GAAP outputs; failures block merge or release.
Data pipeline tests (Option B) — schema checks, DQ rule tests and reconciliation assertions run in the same CI framework as the models.
Segregation of duties — developers propose changes; reviewers approve; production promotion follows Chesnara release authority (including during co-delivery).

Environments

We will agree with Chesnara IT a simple environment topology, for example:

Development — day-to-day build and unit testing
Test / UAT — Chesnara validation, dry runs and parallel-run candidates
Production — BAU valuation runs only from approved packages

Deployment credentials and secrets remain under Chesnara control. Howden works within Chesnara’s CI/CD tooling where available (or helps stand up a lightweight pipeline compatible with Chesnara standards if required).

Benefits through the project lifecycle

Phase	CI/CD benefit
Build (Oct 2026 – mid 2027)	Rapid, safe iteration on products and frameworks; defects caught before parallel run
Parallel run (to Jun 2027)	Confidence that fixes do not silently break previously signed-off behaviour
Handover & BAU	Chesnara inherits not only code, but a repeatable release process
Future M&A / enhancements	New products or books added through the same tested pipeline, not uncontrolled copies

What CI/CD is not

CI/CD does not mean unsupervised automatic go-live of methodology changes. Production releases of material model updates will still require agreed actuarial and business sign-off. The pipeline makes that sign-off safer and more evidence-based.

3.7 Security, governance and AI

Chesnara information will be processed in line with agreed confidentiality, access control and Chesnara IT standards.
Model change will follow specification → build → test → peer review → release.
We will not input Chesnara confidential information into public generative AI tools unless explicitly approved in writing, consistent with the Request for Proposal (RFP) terms. Any future AI-assisted controls or DQ features would sit inside Chesnara-approved infrastructure.

4. Data Solution

4.1 Scope

An illustrative data architecture and process is set out in Appendix B. The data solution is an actuarial model data ingestion and validation capability — not a wider data lake or administration platform. It will:

Take extracts from source systems (Lifeware policy and reinsurance data; State Street asset / investment data; economic assumptions from public sources; non-economic assumptions from Chesnara).
Transform data into structured model-point files and assumption tables for the valuation models.
Apply automated data integrity and quality checks, reconciliations, and an auditable log of transformations and overrides.

Experience analysis, claims management information (MI) and other non-valuation uses are out of scope at this time. Volumes are modest (~45,000–60,000 policy records; closed book). Priority is timetable, controls and working-day-one readiness.

4.2 Option B (our proposal)

The RFP asked for two data options. This proposal is for Option B.

	Option A (not proposed)	Option B (proposed)
Howden delivers	Data solution build, documentation, testing framework, training	Everything in Option A plus Howden resource to operate and support ingestion through implementation, with structured handover
Chesnara role	Operates day-to-day ingestion using the solution	Co-delivery: Howden leads ingestion operations while transferring the process to Chesnara
Why Option B	—	Protects working-day-one model-point production through the critical path; builds Chesnara capability before Transitional Service Agreement (TSA) exit

Inputs required from Chesnara (format / content)

Source	Role	Inputs from Group
Lifeware	Policy and reinsurance extracts	Agreed extract format and schedule; data dictionary; mapping rules where known
State Street	Asset / investment information	Line-by-line feeds as currently provided; fund / asset-class mapping
Chesnara	Non-economic assumptions; governance	Assumption tables; product / feature documentation; sign-off on mapping and DQ tolerances
Public / market	Economic assumptions	Agreed sources and update process

Outputs: validated model points and assumptions; DQ exception reports; audit trail; landing area for model results for finance / third-party CSM consumers. No direct ledger or Workiva integrations in this scope.

4.3 Approach and controls

Actuary-led design of mappings, reconciliations and materiality
Repeatable Python pipelines with versioned configuration
Automated DQ (completeness, referential integrity, movements, thresholds)
Full audit trail of transformations and manual adjustments
Co-delivery: Chesnara validates dry-run and parallel outputs

Benefits: shorter working-day timetable; fewer manual interventions; stronger controls; a reusable pattern for future acquisitions.

4.4 Indicative effort — Option B (Howden hours)

Grades: GP = Guardian Partner; PL = Project Lead; DL = Data Lead; AC = Actuarial Consultant; AA = Actuarial Analyst; SD = Software Developer. Assumes ~8-hour days and moderate Chesnara co-delivery. Higher Chesnara contribution reduces Howden hours.

Milestone	GP	PL	DL	AC	AA	SD	Total
D1 Initiation, requirements, architecture	8	24	40	16	8	24	120
D2 Pipeline build & DQ framework	4	16	80	60	40	100	300
D3 Integration dry runs & documentation	4	16	48	40	32	40	180
D4 UAT support, training, handover	4	16	32	24	16	24	116
D5 Ingestion operate & transfer (to ~Jun 2027 parallel)	4	24	120	80	60	40	328
Option B total	24	96	320	220	156	228	1,044

4.5 Checking and testing the data solution

We will check and test data work continuously — not only at the end — so that model points released into valuation are complete, accurate and reconcilable. Testing combines automated controls, independent review and Chesnara co-delivery validation.

Testing approach

Layer	What we check	How
Pipeline unit tests	Individual transforms, joins, mapping functions and edge cases	Automated tests in CI/CD on every code/config change
Schema & contract tests	Extracts match agreed layouts, types, mandatory fields and freshness rules	Automated gates before staging load
Data quality (DQ) rules	Completeness, uniqueness, referential integrity, range/threshold breaches, unexpected movements	Rule engine run each ingestion; exceptions quarantined
Reconciliation	Control totals to Lifeware / State Street source aggregates and to prior approved runs (where comparable)	Automated reconciliations plus actuarial review of breaks
Lineage / audit checks	Approved model points trace to extract version, pipeline build and override log	Audit trail review; sample tracing
Independent testing	Critical mappings and DQ logic reviewed separately from the primary builders	Testing Lead (Andrew Mason) with supporting analysts
Dry runs	End-to-end land → approve inputs on mock then live-like extracts	Joint Howden / Chesnara review of outputs and exception packs
User acceptance testing (UAT)	Chesnara confirms inputs are fit for model use and operating process is usable	Chesnara sign-off on agreed test cases
Parallel-run period	Repeated production-like ingestions through to June 2027 parallel	Defect clearance; stability of WD1-style timetable

Roles in checking (data)

Role	Responsibility
Data Lead (James Hadley)	Owns test design for pipelines/DQ; resolves mapping defects
Software developers	Automate tests; maintain CI gates
Testing Lead (Andrew Mason)	Independent challenge of critical data logic and evidence packs
Project Lead (Amit Lad)	Ensures test scope covers timetable and audit needs
Chesnara actuaries	Validate dry-run / UAT / parallel outputs; agree tolerances and override policy

What will be in the data test plan

We will agree a written data test plan with Chesnara covering at least:

Plan element	Content
Objectives & scope	In-scope sources (Lifeware, State Street, assumptions); out-of-scope uses (e.g. experience analysis)
Roles & independence	Data Lead, developers, Testing Lead, Chesnara validators; maker/checker for overrides
Entry / exit criteria	When dry runs may start; when inputs are “approved” for model use
Test scenarios	First load, reload/idempotency, missing-file failure, schema drift, large exception volumes, prior-period movement
DQ rule catalogue	Each rule, threshold, severity (block vs warn), owner
Reconciliation inventory	Policy counts, premiums/benefits aggregates, fund values, asset totals (line and asset-class), to-source and to-prior
Defect management	Severity, fix/retest path, link to CI/CD where code/config changes
Evidence & sign-off	Pack contents; Chesnara acceptance points through parallel run

Example reconciliation tolerances (illustrative — to be agreed)

Final tolerances will be set with Chesnara (and refined once real extracts arrive). Illustrative starting points for a closed book of this size:

Control	Example tolerance (illustrative)	Notes
Policy / record counts	Exact match to source extract (after agreed in-force definition)	Any break is investigated
Unit fund values (aggregate)	Within 0.01% or £1,000, whichever is larger	Absolute floor avoids noise on small funds
Asset inventory (aggregate market value)	Within 0.01% or £5,000, whichever is larger	Line-level breaks sampled if aggregate OK
Mapping “unmapped product / fund” rate	0% unmapped for in-force valuation set	Warn earlier in dry runs if mock data incomplete
DQ blocking rules	Zero open blocking exceptions at approval	Warnings may remain with documented waiver
To-prior movement (aggregate)	Explain movements above 0.5% or agreed £ de minimis	Not a hard fail — analytical control

Evidence we will retain

DQ and reconciliation reports by valuation date
Exception and override registers (with disposition)
Data test plan, results and sign-off records
Pipeline version / package identity linked to each approved input set

5. Actuarial Modelling

5.1 Design principles

An illustrative model architecture and process is set out in Appendix B.

Models run entirely within the Group on Chesnara infrastructure
Python — transparent, maintainable, no proprietary licence lock-in
Governance: specification → build → independent testing → documentation → training
Actuaries first, supported by Allan Engelhardt and software engineers
Chesnara provides product feature specifications; Howden reviews, challenges, converts to detailed model specifications, and builds

Howden Prophet expertise

Howden IAL has extensive practical experience with Prophet (including Prophet Actuarial Library Suite / ALS-style estates): operating and reviewing Prophet workspaces, supporting audit and validation, and migrating valuation functionality from Prophet to open Python platforms. That experience is directly relevant here because SWE currently uses Prophet, and from October 2026 Lloyds Banking Group (LBG) may be able to provide selected Prophet model outputs to support testing and migration (see Section 5.5).

Our team understands Prophet structures (including typical UL / WP workspace splits), model-point disciplines, and how to design independent reconciliations that are meaningful when comparing a greenfield Python model to an incumbent Prophet estate — including where products are “same as”, where ALS libraries drive behaviour, and where differences are expected for documented methodology choices.

Management actions and bonus setting

During specification and build we will discuss and agree with Chesnara the level and extent of modelling of management actions (for example which actions are dynamic versus static, which are material for TPs / COG / SCR, and how they are parameterised).

We acknowledge an important limitation: bonus setting is retained by Scottish Widows Limited (SWL). The Chesnara Python model will therefore not replace SWL’s bonus declaration process. Bonus-related inputs and constraints will be taken as provided through the agreed data / assumption interface (and, where relevant, aligned to information available during the LBG TSA period), rather than assumed to be freely reset inside the Chesnara model. We will document this boundary clearly in the model specifications and testing approach so that reconciliations to Prophet outputs are interpreted correctly.

5.2 In-scope coverage

Capability	Day-1	Notes
Deterministic Non-Profit (unit-linked)	Yes
Deterministic With-Profit	Yes
Cost of guarantees (COG)	Yes	Switch: (a) deterministic, (b) Black–Scholes proxy, (c) full stochastic
Solvency II	Yes	technical provisions (TPs) and related balance sheet items; full Solvency Capital Requirement (SCR) under the Standard Formula (SF); AoS / AoC model outputs
Lux-GAAP and additional CAA requirements	Yes
Asset treatment	Yes	Line-by-line for SCR; by asset class for value of in-force (VIF) / guarantee calculations
Stochastic architecture	Yes	Via COG switch; economic scenario generator (ESG) build out of scope
asset-liability management (ALM) style asset modelling	Future-ready	Not day-1
CSM engine	Interface only	Outputs landed for third-party CSM

Out of scope: International Financial Reporting Standards (IFRS) 17 CSM engine; ESG build; experience analysis / claims MI / dashboards; downstream AoC report packs; Solvency and Financial Condition Report (SFCR) / Own Risk and Solvency Assessment (ORSA) / stress and scenario testing (SST) packs; financial planning and analysis (FP&A) / planning / monthly MI; liquidity reporting; direct ledger / Workiva / FP&A integrations.

5.3 Solution features

Run controller (GUI): configure and execute runs without editing code
Hierarchical product models: shared core; product-specific overlays
Outputs & audit: run log, settings snapshot, reproducible results
COG switch: deterministic / Black–Scholes / full stochastic
Performance: NumPy / Pandas / Polars appropriate to book size

5.4 Indicative effort (Howden hours)

Product count still to be confirmed (TBC); estimates assume a manageable closed-book unit-linked (UL) + WP set.

Milestone	GP	PL	ML	AC	AA	SD	TL	Total
M1 Setup, specs, architecture	16	40	60	40	16	40	16	228
M2 Deterministic NP (UL) build	8	24	100	120	60	80	24	416
M3 Deterministic WP build	8	24	120	140	80	80	24	476
M4 SII framework (TPs, full Standard Formula (SF) SCR, AoS/AoC outputs)	12	32	100	120	60	60	32	416
M5 Lux-GAAP / CAA outputs	8	16	60	80	40	40	16	260
M6 COG switch (det / Black–Scholes (BS) proxy / stochastic)	8	16	80	80	40	60	24	308
M7 Aggregation, reporting outputs, CSM landing	4	16	40	60	40	60	16	236
M8 Testing, UAT, parallel-run support	16	40	80	100	80	40	120	476
M9 Training, documentation, handover	8	24	40	40	24	24	16	176
Modelling total	88	232	680	780	440	484	288	2,992

ML = Model Lead (Sam Underhill); TL = Testing Lead (Andrew Mason). Other grade codes as defined under the data solution effort table.

5.5 Checking and testing the actuarial models

Model testing is designed so that Chesnara — and ultimately auditors — can see that calculations match agreed specifications, that changes do not silently break prior behaviour, and that outputs are fit for SII, Lux-GAAP / CAA and downstream CSM landing. The Testing Lead operates independently of day-to-day model build, supported by CI/CD automation and Chesnara co-delivery validation.

Testing approach

Layer	What we check	How
Specification walkthrough	Detailed model specs correctly interpret Chesnara product feature documents	Joint review/challenge before and during build
Unit tests	Individual calculation building blocks (e.g. charges, decrements, unit-fund roll-forward, discounting, guarantee mechanics)	Automated tests in CI on every relevant change
Component / product tests	NP UL and WP product overlays against worked examples from specifications	Builder tests + independent re-performance on samples
COG path tests	Deterministic, Black–Scholes proxy and stochastic hook-up each produce expected behaviour for controlled cases	Dedicated test cases per switch position
Reporting framework tests	TPs and related balance sheet items; full SF SCR plumbing; AoS / AoC model outputs; Lux-GAAP / CAA extracts; CSM landing shapes	Assertion tests + spreadsheet/tool-assisted checking where useful
Asset-view tests	Line-by-line SCR asset path and asset-class VIF / guarantee path both consume mapped data correctly and reconcile at control totals	Dual-view reconciliations
Regression (“golden”) packs	Representative model-point sets and expected results; failures block merge/release	CI/CD gate (Section 3.6)
Independent model testing	Critical methodology and outputs re-checked away from the primary developers	Testing Lead-led programme; evidence pack
Peer review	Partner-level review of approach, material judgements and readiness for governance	Guardian Partner (Kim Durniat)
UAT	Chesnara actuaries confirm models are operable and outputs understandable/usable	Agreed UAT scripts and sign-off
Parallel run (to Jun 2027)	Full test parallel against the reporting calendar	Defect triage; stability; documentation freeze for go-live candidate

Independence and four-eyes

Build side	Check side
Model Lead & actuarial builders implement to specification	Testing Lead designs/owns independent test plan
Developers implement engines, GUI and automation	Automated CI plus independent re-performance on material items
Data team supplies approved inputs	Model tests include input-sensitivity and garbage-in detection where practical

Material methodology changes require specification update, tests updated in the same change set where feasible, and review before production promotion.

Use of LBG Prophet outputs (from October 2026)

From October 2026, LBG may be able to provide selected outputs from the incumbent Prophet model currently used for SWE. Where available, these outputs will be a major accelerator for testing and migration — not as a substitute for specification-based build, but as an independent benchmark.

How Prophet outputs will support testing

Use	Benefit
Aggregate reconciliation	Compare Python vs Prophet totals for reserves / TPs, fund values, key cashflows, and selected SCR building blocks where like-for-like
Product / cohort analytics	Identify which products or segments drive differences quickly
Sample policy deep-dives	Re-perform on a targeted sample where aggregates break or where features are complex (WP guarantees, charges, etc.)
Regression baseline	Freeze agreed Prophet-derived expected results (with documented adjustments) into “golden” packs for CI
Migration confidence	Demonstrate readiness for parallel run with evidence familiar to Chesnara governance and auditors
Interpretation of differences	Separate (i) defects, (ii) intentional methodology changes, and (iii) known boundary items such as SWL-retained bonus setting / management-action scope

Howden’s Prophet experience means we can interrogate LBG-provided outputs efficiently (workspace/product context, expected ALS behaviours, and typical reconciliation pitfalls) and design comparison packs that remain usable even when file layouts are imperfect.

Where Prophet outputs are delayed or incomplete, testing continues against specification worked examples, mock model points and analytical reasonableness checks — the plan does not depend solely on LBG data, but will exploit it fully when provided.

What will be in the model test plan

Plan element	Content
Objectives & scope	Products, regimes (deterministic NP/WP, COG modes, SII including full SF SCR, Lux-GAAP / CAA, AoC/AoS outputs, CSM landing); explicit out-of-scope items
Roles & independence	Model Lead / builders vs Testing Lead; Partner peer review; Chesnara validators
Entry / exit criteria	Spec baseline agreed; unit tests green; independent testing complete to agreed coverage; UAT and parallel-run gates
Test inventory	Unit, product, COG-path, reporting, asset-view, regression, Prophet-comparison, and UAT cases
Prophet comparison strategy	Which outputs, valuation dates, aggregate vs sample, treatment of known differences (incl. management actions / SWL bonus boundary)
Tolerances	Numeric thresholds (see below) and qualitative acceptance rules
Defect management	Severity, retest, linkage to CI/CD and specification updates
Environments	Dev / test-UAT / production package rules
Evidence & sign-off	Pack list; Steering / governance inputs as Chesnara requires

Example model reconciliation tolerances (illustrative — to be agreed)

These are starting proposals for discussion with Chesnara once Prophet outputs and product specs are visible. Absolute and relative tests would both be used; WP and guarantee items may need wider analytical bands initially.

Comparison	Example tolerance (illustrative)	Notes
In-force policy count	Exact match (same extract definition)	Gate for any Prophet vs Python run
Aggregate unit reserves / unit liabilities	Within 0.1% or £25,000, whichever larger	Tighter once stable
Aggregate non-unit / WP liability components	Within 0.25% or £50,000, whichever larger	Allow for bonus / management-action boundary effects; unexplained breaks still investigated
Selected cashflow totals (e.g. claims, charges) annual	Within 0.2% or £10,000, whichever larger	Product-level drill-down if breached
Best estimate liabilities / TPs (aggregate)	Within 0.25% or agreed £ de minimis	Document methodology differences explicitly
SF SCR (aggregate)	Within 0.5% or agreed £ de minimis	Module-level explain if breached; line-by-line asset mapping checked first
Sample policies (material features)	Difference within agreed £ / bp band per case, or exact match on specified intermediates	Sample size and selection rules in test plan
COG (deterministic vs proxy vs stochastic hook)	Directional / ranking checks plus agreed numeric band vs Prophet where comparable	Full stochastic vs Prophet only where ESG basis aligned

Material unexplained breaks outside tolerance remain defects until cleared or formally accepted as known differences with governance sign-off.

Chesnara involvement

Consistent with co-delivery, Chesnara will be involved in validating all material test and dry-run outputs, agreeing tolerances, participating in UAT, and signing off parallel-run readiness. Howden provides the evidence packs; Chesnara provides acceptance decisions. Where LBG Prophet outputs are supplied, Chesnara will help confirm extract definitions and interpretation of SWL bonus / management-action boundaries.

Evidence we will retain

Model specifications and change history (including management-action scope and SWL bonus boundary)
Unit/regression test catalogues and CI results
Prophet comparison packs and reconciliation worksheets (where LBG outputs available)
Independent testing reports and issue logs
Model test plan, UAT scripts, results and sign-offs
Parallel-run comparison packs and defect closure records
Run logs linking outputs to model version / package identity

6. Implementation Plan

6.1 Delivery principles

Co-delivery: Chesnara actuaries embedded in requirements, challenge of specs, validation of results and UAT
time and materials (T&M) milestones with estimated effort and transparent burn vs estimate
Audit-ready by design
Preserve Lloyds strengths: working-day-one model points and reliable Lux-GAAP + SII production

6.2 Indicative timetable

Aligned to appointment from 1 October 2026 and full test parallel run at June 2027, with half-year (HY) / full-year (FY) 2026 validation as data allows.

Phase	Timing	Outcomes
Appointment & mobilisation	Oct 2026	Governance, environment, access, milestone plan
Design & specification	Oct–Nov 2026	Data and model architecture; COG switch; SCR vs VIF asset treatment; management-action scope; agree Prophet comparison approach with LBG outputs if available
Data solution build (Option B)	Nov 2026 – Jan 2027	Pipelines, DQ, dry runs
Core deterministic models	Dec 2026 – Mar 2027	NP UL + WP deterministic builds
Regulatory frameworks	Feb – Apr 2027	SII (incl. full SF SCR), Lux-GAAP / CAA, AoC / AoS outputs
COG options & hardening	Mar – May 2027	Deterministic / BS / stochastic switch; performance; controls
Ingestion operate & transfer	Through Jun 2027	Option B operate-transfer; working day one (WD1) discipline
Parallel run	To Jun 2027	Full test parallel (incl. Prophet reconciliations where LBG outputs available); defect clearance; runbooks
Training & handover	May – Jul 2027	User training; Python knowledge transfer (KT); final documentation
Post go-live support	12 months from go-live	Discounted support & training queries

6.3 Training

Model architecture and data flows; run controller and business-as-usual (BAU) calendar; assumption management; DQ and audit outputs; Python knowledge-transfer workshops; user guides and reference documentation.

6.4 Post go-live support

For 12 months from agreed go-live, Howden provides support at discounted T&M rates for support and training queries. Material change requests remain standard T&M unless otherwise agreed.

7. Resource Plan

7.1 Howden resource

See Section 2 for named roles. Software Developer hours are led by Allan Engelhardt, with supporting developers as required. Wider Howden IAL bench provides surge capacity.

7.2 Chesnara resource (co-delivery)

Chesnara provides experienced actuarial resource for requirements workshops, review of detailed specs, validation of test / dry-run outputs, UAT sign-off, and progressive ownership of BAU ingestion under Option B handover.

Illustrative Chesnara effort: ~0.5–1.0 full-time equivalent (FTE) across the programme, peaking around UAT and parallel run. Higher Chesnara contribution reduces Howden T&M burn (see Commercial Model).

7.3 Programme effort summary — Option B + modelling

Workstream	Howden hours	Approx. days (@ 8 hrs)
Data solution (Option B)	1,044	~131
Actuarial modelling	2,992	~374
Programme total	4,036	~505

Grade totals (Option B + modelling)

Grade	Hours
Guardian Partner (Kim)	112
Project Lead (Amit)	328
Data Lead (James)	320
Model Lead (Sam)	680
Actuarial Consultant	1,000
Actuarial Analyst	596
Software Developer (Allan + support)	712
Testing Lead (Andrew)	288
Total	4,036

Apply agreed day rates by grade to produce pounds sterling (GBP) milestone fee estimates.

8. Scalability

8.1 Why scalability matters for Chesnara

Chesnara is an acquisitive group. SWE brings Luxembourg into scope; further purchases over the next three years are reasonably foreseeable. Any data and modelling solution must therefore work for SWE day-1, and remain a repeatable pattern for additional closed (and potentially open) books without rebuilding from scratch or re-entering a proprietary licence trap.

Scalability for this proposal means five things:

Volume — more policies, funds and model points
Product / feature complexity — new product types and guarantee structures
Regulatory / reporting scope — additional regimes or disclosure cuts as Group needs evolve
Operating model — Chesnara teams in a federated structure can run and extend the estate
M&A onboarding speed — faster path from acquisition data room to controlled valuation production

8.2 Volume and performance scalability

Initial volumes (~45,000–60,000 policies) are modest for a modern Python stack. Design choices that protect future growth:

Design choice	Scalability effect
Polars / efficient DataFrame processing for heavy transforms	Lower memory and faster runtimes as extracts grow
Hierarchical calculation design	Shared logic scales across products without copy-paste explosion
Database-backed staging and results	Avoids brittle “spreadsheet as system of record” patterns as history accumulates
Configurable output packs	Users request only the outputs needed, reducing unnecessary processing
Run controller separation	Operational scaling (more users / more runs) without rewriting calculation code

If a future book is materially larger or more computationally intensive (e.g. deep stochastic sets once an ESG is available), we can add targeted performance work (vectorisation, batching, selective parallelisation) as a discrete T&M package — without changing platform.

8.3 Product and methodology scalability

Mechanism	How it helps future books
Hierarchical product models	New products inherit shared cores (mortality, unit-linking, discounting, etc.); only differentials are coded
Configuration-led assumptions	Tables and parameters, not hard-coded constants, drive many behaviours
COG switch (det / Black–Scholes / stochastic)	Methodology can deepen as data and ESG availability mature, without a second model estate
Asset treatment already dual-mode	Line-by-line for SCR and asset-class for VIF / guarantees — pattern reusable where future books need both views
Future-ready hooks	ALM-style asset modelling and richer stochastic dynamics can be added later without discarding day-1 foundations

8.4 Data scalability and multi-source readiness

The Option B data solution is built as a pattern, not a one-off script:

Connector-style ingestion for Lifeware and State Street, with mapping and DQ rules held as controlled configuration
Clear extension points for additional admin systems or extract formats from future acquisitions
Automated DQ and reconciliation that can be retargeted to new source schemas
Audit trail that remains meaningful as the number of sources and adjustments grows

Greenfield post-separation for SWE avoids carrying forward legacy SWE platform constraints, while still aiming to preserve Lloyds’ operational strengths (speed to model points; Lux-GAAP + SII production).

8.5 Group / federated operating model

Chesnara operates a federated model. There is no SWE actuarial function yet; recruitment is in progress. Scalability therefore includes people and process, not only code:

Co-delivery and training so Chesnara can run BAU without vendor dependence
Documentation, runbooks and test evidence that new joiners can follow
IP ownership on payment — no contractual barrier to Group reuse across entities (subject to Chesnara internal governance)
Hosting on Chesnara’s platform of choice, aligned to Group IT standards rather than a parallel vendor cloud

8.6 M&A onboarding playbook

For a future acquisition, we would expect to reuse:

Data ingestion / DQ framework and control standards
Model architecture and run controller
Reporting output patterns (SII / local GAAP / AoC outputs / CSM landing as relevant)
Testing and documentation templates
Mobilisation and co-delivery approach

Typical incremental work (scoped as T&M once diligence data exists): source-system mapping; product feature specifications → model specs; product build / “same-as” reuse analysis; parallel-run support; local regulatory overlays.

Commercial implication: Chesnara pays for incremental build, not a fresh platform licence per book.

8.7 What we are not claiming

Scalability does not mean every future Group need is in this fixed scope. Day-1 excludes ESG build, full ALM asset modelling, experience analysis platforms, and downstream MI packs. Those can be added later on the same Python estate if Chesnara chooses — which is precisely the point of the technology and ownership model.

9. Commercial Model

9.1 Structure

Time & materials for the build phase, organised into milestones with estimated hours (Sections 4–5)
Engagement covers build and agreed implementation support — not a multi-year platform licence
On payment for delivered work, Chesnara owns all code and IP
Invoicing in GBP, billed in the UK
No ongoing software licence; infrastructure costs sit with Chesnara as host

9.2 Incentive for Chesnara resource

Where Chesnara takes a larger share of delivery, Howden hours reduce. We will agree a baseline estimate per milestone, report actuals vs estimate, and reflect higher Chesnara contribution as lower Howden burn (with an effort credit on remaining milestones where agreed tasks are consistently delivered by Chesnara).

9.3 Combined services

This proposal covers data (Option B) + modelling together. We propose a 5% reduction on Howden hours (or equivalent fee credit) relative to the sum of standalone estimates, reflecting shared governance and overlapping testing.

9.4 Post go-live support (12 months)

Suggest 20% discount to standard grade rates (confirm commercially) for support and training queries for 12 months from go-live. Change requests: standard rates unless bundled.

9.5 Value-add

Within reasonable T&M materiality during build: actuarial challenge of product specs and materiality; audit-oriented controls and documentation; knowledge transfer; design hooks for future stochastic depth, asset modelling and further books.

9.6 Fees

Fee tables will be completed by applying agreed day rates to the hour schedules in Sections 4.4, 5.4 and 7.3. A rate card and discounted support rate card will accompany the commercial schedule.

10. Case Study

Python model development (anonymised)

Requirements: A global insurer needed to migrate life valuation systems to an open-source platform to improve maintainability and avoid sizeable licence fees. The system modelled cashflows across multiple reporting regimes and 29 products (including term, whole of life, critical illness and short-term credit).

Services provided: In three months, the team delivered a fully reconciled, tested and documented Python valuation system with a user-friendly no-code interface; inputs/outputs compatible with existing database and Excel processes; additional flexible output options; Audit Committee approval for year-end use; external audit with no model amendments required.

Benefits: Client ownership with no ongoing licence fees; actuaries able to understand and change calculation methodology safely; faster set-up and run times via the GUI and process refinements.

11. Appendix A: About Howden

Howden Group

Howden is a global insurance group with expertise across insurance, reinsurance, risk consulting and employee benefits. With over 25,000 employees in more than 115 countries, we combine global reach with deep local insight.

Howden Insurance Actuarial & Longevity

Howden Insurance Actuarial & Longevity (IAL) was created through bringing together the Barnett Waddingham and Hymans Robertson insurance actuarial teams. The team brings together 80+ specialists across general insurance, life insurance and longevity.

Services include:

Provision of a Chief Actuary (UK SMF-20)
Full outsourced actuarial function (pricing and reserving)
Capital modelling, management and validation
Risk and assurance services
Regulatory and investment advice
Process transformation

Howden IAL operates separately of any Howden broking or placement relationships. We maintain independence to provide expert and impartial advice. Strong data governance and information security protections are in place, as demonstrated by our Quality Assurance Scheme (QAS) and International Organization for Standardization (ISO) certifications.

Howden Insurance Actuarial & Longevity
One Creechurch Place, London, EC3A 5AF
T +44 (0)20 7623 3806
E info@howdengroup.com
www.howdengroup.com

12. Appendix B: Technical architecture and process (illustrative)

This appendix sets out an illustrative view of how the data and model architectures and processes could look. Final designs will be confirmed with Chesnara during mobilisation against actual Lifeware / State Street extracts, product specifications and information technology (IT) standards. The patterns below are consistent with Sections 3–5 (Python, Chesnara hosting, Option B, CI/CD).

B.1 End-to-end landscape

┌──────────────┐   ┌──────────────┐   ┌────────────────┐
│   Lifeware   │   │ State Street │   │ Assumptions    │
│ policy / RI  │   │ asset feeds  │   │ (econ / non-   │
│   extracts   │   │ (line-by-   │   │  econ tables)  │
└──────┬───────┘   └──────┬───────┘   └────────┬───────┘
       │                  │                    │
       └────────────┬─────┴────────────────────┘
                    ▼
       ┌────────────────────────────┐
       │  Data platform (Option B)  │
       │  land → validate → map →   │
       │  DQ → model points /       │
       │  assumptions (database)    │
       └─────────────┬──────────────┘
                     ▼
       ┌────────────────────────────┐
       │  Actuarial model engine    │
       │  (Python; run controller)  │
       │  NP UL / WP / COG switch / │
       │  SII / Lux-GAAP / outputs  │
       └─────────────┬──────────────┘
                     ▼
       ┌────────────────────────────┐
       │  Results & audit store     │
       │  → finance / CSM landing   │
       │  → run log / version stamp │
       └────────────────────────────┘

All components run on Chesnara-hosted infrastructure (Python runtime + database + secure file storage), with changes released through the CI/CD pipeline described in Section 3.6.

B.2 Data architecture

B.2.1 Logical layers

Layer	Purpose	Typical contents
Landing	Immutable (or append-only) copy of source extracts as received	Lifeware files / API payloads; State Street line-by-line asset files; raw assumption files; receipt metadata (source, timestamp, checksum)
Staging	Parsed, typed, lightly standardised data	Normalised tables (policy, cover, fund link, reinsurance attributes, asset lines); rejected-row quarantine
Conformed actuarial data	Business-meaningful entities after mapping	Policy master; product / feature flags; benefit structures; fund holdings; asset-class rolls for VIF / guarantees; line-level assets for SCR
Model input store	Valuation-ready inputs	Model-point files; assumption sets; run configuration references; DQ exception register
Control & audit	Evidence of process integrity	DQ results; reconciliation balances; transformation log; user overrides (with maker/checker where agreed); pipeline run identifiers

B.2.2 Data process (Option B operating rhythm)

Illustrative working-day flow (timings to be agreed; target spirit = Lloyds working-day-one model points):

Step	Activity	Owner (Option B)	Output
1	Receive / pull extracts from Lifeware and State Street	Howden (transferring to Chesnara)	Landed files + checksums
2	Schema & freshness checks	Automated pipeline	Pass / fail gate
3	Parse and load to staging	Automated pipeline	Staging tables
4	Apply mapping rules (product, status, funds, features)	Automated + config tables	Conformed data
5	Run DQ rules (completeness, referential integrity, movements, thresholds)	Automated pipeline	DQ report; exceptions
6	Investigate / clear material exceptions	Howden with Chesnara validation	Cleared or documented overrides
7	Build model-point and assumption extracts	Automated pipeline	Model input store
8	Reconcile key control totals to source / prior	Automated + actuarial review	Sign-off pack for the valuation date
9	Release “approved inputs” flag for model runs	Agreed authority	Inputs available to run controller

B.2.3 Illustrative data objects

Domain	Example entities / fields (indicative)
Policy	Policy id; status; product code; commencement / maturity; premium status; benefit bases; rider flags; with-profit indicators
Unit-linked	Fund identifiers; units / values; charge bases; switch / premium allocation rules as required for valuation
With-profit	Asset-share / bonus-related attributes as specified; guarantee indicators; discretionary benefit flags
Reinsurance	Treaty identifiers / attributes needed for reporting (noting current external treaties may not be modelled as gross/net if confirmed out of model scope)
Assets	Line-by-line holdings from State Street for SCR; mapped asset-class aggregates for VIF / guarantee calculations
Assumptions	Mortality / lapse / expense tables; economic inputs; management action parameters as applicable

B.2.4 Controls embedded in the data architecture

Idempotent pipelines — re-running for the same valuation date produces the same approved inputs (absent intentional override).
Config over code — mappings and DQ thresholds held as versioned configuration, released via CI/CD.
Segregation — landing (as-received) kept distinct from approved model inputs.
Exception workflow — failures do not silently drop; they quarantine and require disposition.
Lineage — each model-point row can be traced to source extract version and transformation build.

B.3 Model architecture

B.3.1 Logical components

                    ┌─────────────────────────┐
                    │     Run controller      │
                    │  (GUI / orchestration)  │
                    │  run id, inputs, COG    │
                    │  switch, output packs   │
                    └───────────┬─────────────┘
                                │
        ┌───────────────────────┼───────────────────────┐
        ▼                       ▼                       ▼
┌───────────────┐     ┌─────────────────┐     ┌─────────────────┐
│ Input adapter │     │ Calculation     │     │ Output adapter  │
│ model points  │────▶│ core (shared)   │────▶│ SII / Lux-GAAP  │
│ assumptions   │     │ + product layer │     │ AoC/AoS outputs │
│ asset views   │     │ + reporting     │     │ CSM landing     │
└───────────────┘     │   frameworks    │     │ audit artefacts │
                      └─────────────────┘     └─────────────────┘

Component	Role
Run controller (GUI)	User selects valuation date, input versions, COG mode, scenarios/options and output packs; starts/monitors run; no requirement to edit Python for BAU
Input adapter	Loads approved model points, assumptions and asset views; validates readiness gates from the data platform
Calculation core	Shared engines: projection loop, discounting, unit-fund mechanics, demographic decrements, charge logic, capital building blocks
Product layer	Hierarchical product models — common parent behaviour with product-specific overlays for NP UL and WP features
Reporting frameworks	SII balance sheet items (including full SF SCR), Lux-GAAP / CAA outputs, AoC / AoS model outputs
COG module	Switchable path: (a) deterministic, (b) Black–Scholes proxy, (c) full stochastic (when ESG inputs available)
Output adapter	Writes results tables, disclosure extracts, CSM landing files, run log, settings snapshot, model version stamp
Test harness	Used in CI and by Testing Lead — unit tests, regression packs, comparison utilities

B.3.2 Hierarchical product design

                ┌──────────────────────┐
                │   Base policy model  │
                │ (timing, status,     │
                │  common cashflows)   │
                └──────────┬───────────┘
           ┌───────────────┼───────────────┐
           ▼               ▼               ▼
   ┌─────────────┐ ┌─────────────┐ ┌──────────────┐
   │ NP UL core  │ │ WP core     │ │ Shared add-  │
   │ (units,     │ │ (guarantees │ │ ons (e.g.    │
   │  charges)   │ │  / bonuses  │ │  riders as   │
   │             │ │  as specs)  │ │  specified)  │
   └──────┬──────┘ └──────┬──────┘ └──────────────┘
          │               │
          ▼               ▼
   Product overlays   Product overlays
   (“same as” reuse   (“same as” reuse
    where justified)   where justified)

Benefit: regulatory or methodology changes to shared cores propagate consistently; new products are added as overlays rather than forked codebases — supporting M&A scalability (Section 8).

B.3.3 Model process (valuation run)

Step	Activity	Notes
1	Confirm approved inputs for the valuation date	Gate from data platform
2	Configure run in GUI (COG mode, output packs, SCR asset view vs VIF asset-class view)	Settings snapshotted
3	Execute calculation engine	Progress visible in run controller
4	Generate outputs + audit pack	Results store + run log + model version
5	Automated post-run checks	Control totals, movement reasonableness, comparison to prior where configured
6	Actuarial review / UAT sign-off	Chesnara co-delivery validation
7	Release outputs to landing area for finance / CSM consumers	No direct ledger integration in this scope

B.3.4 Asset treatment inside the model

Use case	Asset representation	Rationale
SCR (market and related Standard Formula stresses)	Line-by-line State Street–sourced holdings (as mapped)	Granularity for full SF SCR
VIF / guarantee / COG calculations	Modelled by asset class	Proportionate liability / guarantee modelling

Both views are fed from the same data platform mappings so that SCR and VIF remain reconcilable at control-total level.

B.3.5 COG switch (process view)

                 ┌────────────────────┐
                 │  Select COG mode   │
                 │  in run controller │
                 └─────────┬──────────┘
           ┌───────────────┼───────────────┐
           ▼               ▼               ▼
    Deterministic    Black–Scholes    Full stochastic
    guarantee path   proxy path       path (ESG-fed)
           │               │               │
           └───────────────┴───────────────┘
                           ▼
                 Guarantee / option
                 cost outputs into
                 reporting frameworks

Day-1 builds all three hooks; practical use of full stochastic depends on ESG availability (ESG build remains out of scope).

B.4 How data and model processes join under CI/CD

Artefact	Versioned in source control	Released via CI/CD	Consumed by
Mapping & DQ configuration	Yes	Yes	Data pipeline
Model-point builder logic	Yes	Yes	Data pipeline
Product / core model code	Yes	Yes	Calculation engine
Regression test packs	Yes	Run on every change	CI gate
Assumption table templates	Yes (structure); values may be valuation-date inputs	Structure via CI/CD	Model runs
Approved valuation inputs / results	Stored in database / file store with lineage	Not “code release” — process release with audit	Reporting consumers

This keeps code and config under engineering release control, while valuation-date inputs and results remain under the actuarial operating calendar — with both joined by version stamps in the run audit trail.

B.5 Design principles (summary)

Greenfield, Chesnara-owned — no dependency on SWE’s pre-separation platform beyond agreed extracts.
Actuary-led, engineer-enabled — calculation transparency for actuaries; packaging, GUI and CI/CD led with Allan Engelhardt’s development stream.
Controls before speed — WD1 ambition without silent failure paths.
Extend, don’t fork — hierarchy + configuration for products and future books.
Outputs, not downstream systems — model and data platforms produce landing outputs; CSM engine and finance tools remain separate.

Out of scope (checklist)

Item	Status
IFRS 17 CSM engine	Out of scope (outputs integration only)
ESG build / provision	Out of scope
Experience analysis, claims MI, wider dashboards	Out of scope
Downstream AoC report packs / MI	Out of scope (AoC model outputs in scope)
SFCR, ORSA, SST management frameworks	Out of scope
FP&A / planning / monthly MI / solvency monitoring packs	Out of scope
Liquidity reporting	Out of scope
Direct ledger / Workiva / FP&A integrations	Out of scope
Day-1 full ALM-style asset model	Out of scope (future-ready)
Multi-year managed service / licence term	Not proposed — build phase; IP to Chesnara on payment

Chesnara plc

Actuarial Modelling & Data Solution

Howden Insurance Actuarial & Longevity (IAL) — Proposal (Option B)

Contents

1. Executive Summary

2. Your Team

Kim Durniat FIA — Guardian Partner & peer review

Amit Lad MMath FIA CERA — Project Lead & delivery management

James Hadley — Data workstream lead

Sam Underhill FIA FIAA — Model workstream lead

Andrew Mason — Testing lead

Allan Engelhardt — Lead developer

3. Technology Choice

3.1 Recommendation: Python for data and modelling

3.2 Why not a proprietary vendor modelling stack?

3.3 Python ecosystem we will use

3.4 Target architecture (Chesnara-hosted)

3.5 Benefits for Chesnara

3.6 Continuous integration and continuous delivery (CI/CD)

How CI/CD will work in practice

Actuarial controls inside the pipeline

Environments

Benefits through the project lifecycle

What CI/CD is not

3.7 Security, governance and AI

4. Data Solution

4.1 Scope

4.2 Option B (our proposal)

4.3 Approach and controls

4.4 Indicative effort — Option B (Howden hours)

4.5 Checking and testing the data solution

Testing approach

Roles in checking (data)

What will be in the data test plan

Example reconciliation tolerances (illustrative — to be agreed)

Evidence we will retain

5. Actuarial Modelling

5.1 Design principles

Howden Prophet expertise

Management actions and bonus setting

5.2 In-scope coverage

5.3 Solution features

5.4 Indicative effort (Howden hours)

5.5 Checking and testing the actuarial models

Testing approach

Independence and four-eyes

Use of LBG Prophet outputs (from October 2026)

What will be in the model test plan

Example model reconciliation tolerances (illustrative — to be agreed)

Chesnara involvement

Evidence we will retain

6. Implementation Plan

6.1 Delivery principles

6.2 Indicative timetable

6.3 Training

6.4 Post go-live support

7. Resource Plan

7.1 Howden resource

7.2 Chesnara resource (co-delivery)

7.3 Programme effort summary — Option B + modelling

Grade totals (Option B + modelling)

8. Scalability

8.1 Why scalability matters for Chesnara

8.2 Volume and performance scalability

8.3 Product and methodology scalability

8.4 Data scalability and multi-source readiness

8.5 Group / federated operating model

8.6 M&A onboarding playbook

8.7 What we are not claiming

9. Commercial Model

9.1 Structure

9.2 Incentive for Chesnara resource

9.3 Combined services

9.4 Post go-live support (12 months)

9.5 Value-add

9.6 Fees

10. Case Study

Python model development (anonymised)

11. Appendix A: About Howden

Howden Group