Actuary

I start by translating the output into a business question the stakeholder already cares about, rather than the mechanics of the model itself. For example, when I worked on a pricing update for a term life product, instead of explaining the mortality table adjustments and the discount rate assumptions, I framed it as: this change moves our loss ratio from 78% to 71%, and here is what happens to premium for a typical policyholder. I use a single chart wherever possible, usually a simple bar or waterfall showing the movement from old assumption to new, and I avoid jargon like tail risk or credibility weighting unless someone asks. I also build in a short buffer for questions before moving to the next slide, because the first question usually tells me whether I pitched the explanation at the right level. With a board, I lead with the recommendation and the number, then offer detail only if they want it.

I have completed the exams through the associate level, covering probability, financial mathematics and valuation, in a pathway similar to the IFoA or SOA route, and I am now working through the fellowship modules with a target of one sitting every six months. I sat my most recent exam in April, on reserving and capital modelling, and I am now studying the one covering professionalism and communication, alongside a full time role, which means blocking out about eight hours a week on a fixed schedule rather than trying to find time around other commitments. I keep a study log and revisit weak topics using past papers rather than rereading the core reading, because past papers are what actually show whether you understand the material or just recognise it. My employer sponsors exam fees and gives me study days before each sitting, which I plan around quarter end so the two don't collide.

Quarter end and especially year end are when this tension is sharpest, because the reporting deadline doesn't move but the data you need sometimes arrives late or looks wrong. My rule is that I will flag a concern before I will quietly adjust a number to fit a deadline. Last year end, a claims feed came through with what looked like a duplication issue two days before the reserving deadline. I raised it immediately with my manager and the data team rather than assuming it was small enough to absorb, and we ended up pushing sign off by a day rather than booking a reserve estimate I wasn't confident in. Where I can, I build in checkpoints earlier in the cycle, a preliminary run two weeks out and a near final run one week out, so anything strange surfaces with enough runway to investigate properly instead of on the last day.

Most of my day to day work sits in a mix of Excel, R and SQL, plus a dedicated actuarial platform for the heavier reserving and capital work. I use Excel for quick checks and anything that needs to go straight into a stakeholder pack, but I move to R once a model needs to run against a full policy level dataset rather than a summarised one, or once I'm doing anything with simulation, like bootstrapping a reserve range. SQL is how I pull and shape the underlying data before it goes anywhere near a model, and I've written a fair number of queries that other people on the team now reuse. The actuarial platform we use handles the regulatory capital calculations, since building that from scratch in a spreadsheet is slow and risky from a version control point of view. I'm comfortable in Python too, mainly for anything that needs to talk to other systems or where I want to automate a report that used to be manual.

On a critical illness product I worked on, we priced using an incidence assumption based on industry experience data, since we didn't have enough of our own claims history yet. About eighteen months after launch, our own experience started coming through worse than the industry benchmark, particularly for one condition category. I flagged the divergence as soon as it showed up in the quarterly experience analysis, rather than waiting for a fully credible dataset, and worked with the pricing team to model a range of scenarios for how much of the gap was genuine versus noise given the small volumes. We ended up repricing that product line within two renewal cycles instead of waiting for the next full review, and I built a monitoring dashboard so the same divergence would surface automatically next time rather than depending on someone spotting it in a spreadsheet. The lesson I took was to be more explicit up front about how much weight we were putting on industry data and for how long.

I was doing a peer review on a colleague's reserve calculation for a motor book and noticed the paid to incurred ratio looked off for one accident year compared to the pattern in every other year. It turned out he'd applied a development factor from an earlier version of the triangle, one that hadn't been updated after a data refresh. I raised it directly with him first rather than escalating straight to our manager, since it was clearly an oversight rather than anything more serious, and we worked through the correction together so he understood exactly where it had gone wrong. We also agreed to add a simple sense check, comparing the new reserve estimate against the prior quarter's roll forward, so a jump like that would get caught earlier next time. I did let our manager know once it was fixed, mainly because the reserve number had already gone into a draft board pack and needed correcting before it went further.

During a year end close, I was asked to finalise a reserve estimate for a new product line two days earlier than planned, to fit an earlier board meeting. The underlying claims data for that line was still being cleaned by the data team, and two fewer days of validation felt like too much risk for a number heading to the board. I explained specifically what was unresolved, not just that I had concerns, and offered a provisional range with wider margins as an alternative, along with a date by which I could give a firm number instead. My manager took that provisional figure to the board with a clear follow up date, rather than pushing me to firm it up early. It meant an awkward conversation in the moment, but a wrong number in a board pack would have been a worse conversation a few weeks later.

I start with the standard actuarial methods, chain ladder and Bornhuetter Ferguson for claims reserving, cross checked against each other rather than relying on one in isolation, especially for the more recent, less developed accident years where chain ladder is least reliable. From there I build in a margin for uncertainty on top of the best estimate, informed by how volatile that line has been historically. On the capital side, under a Solvency II style framework, I'd look at how the reserve estimate feeds into the technical provisions and then flows through to the solvency capital requirement, checking that the assumptions used for reserving and for the capital model stay consistent with each other, since inconsistency between the two is a common source of regulatory queries. I also make sure there's a clear paper trail justifying any expert judgement applied on top of the mechanical result, because that's usually the first thing an external reviewer or regulator asks about.

I'd start by pulling actual experience data at the same level of granularity as the original pricing assumptions, so the comparison is genuinely like for like rather than aggregated actuals against granular pricing cells. For a mortality study, that usually means splitting by age band, gender and policy duration, then calculating an actual to expected ratio for each cell against the pricing basis. I look for whether any divergence is concentrated in a specific segment or spread evenly across the book, since a concentrated pattern points to a genuine trend while a spread pattern is more often noise or a data issue. I'd also test credibility explicitly, using something like a limited fluctuation approach, before recommending any change to assumptions, particularly for smaller segments where a handful of claims can swing the ratio significantly. Once I'm confident the divergence is real, I'd model a few scenarios for how quickly to phase in a revised assumption rather than moving to the new number in one step.

Most of my models start with policy level data pulled via SQL from our data warehouse, which I then clean and validate in R before it goes anywhere near a model, checking things like duplicate policy numbers, implausible dates, and gaps against the prior period's extract. I keep the data pull, the cleaning and the modelling as separate, version controlled scripts rather than one long spreadsheet, so if something looks wrong I can isolate which stage introduced the issue rather than starting from scratch. For anything that needs to run repeatedly, like a quarterly reserving process, I automate as much of the pipeline as I can so the actuarial judgement goes into reviewing the output rather than rebuilding the mechanics every quarter. Documentation is something I'm strict about, every script has a header explaining what it does and what it expects as input, because I've inherited enough undocumented spreadsheets from previous roles to know how much time that saves the next person.