AI Can Build the Engine. The Actuary Must Design the Control Room.

The most interesting part of applying AI to actuarial work is not whether AI can write code.

It can.

The more important question is whether the actuary knows what should be built, where the risks are, which parts can be delegated safely, and which parts must remain under professional control.

That distinction matters. Without it, AI does not create a better actuarial process. It may simply help us build a larger and more complicated black box, faster than before.

I recently worked on an asset key rate duration tool for regulatory reporting. The tool projects bond cashflows, calibrates Z-spreads, revalues assets under key rate shocks, and produces portfolio-level KRD outputs. The coding work was accelerated significantly with AI assistance. But the real value of the exercise was not the macro itself.

The real value was in designing the workflow.

The Reporting Problem

For many insurers, asset cashflow projection and Z-spread analysis already exist in some form. They may be used for different reporting purposes, such as local capital reporting, matching adjustment analysis, asset model point generation, or internal asset-liability management.

The difficulty is that these processes are often separated.

One workbook prepares asset cashflows. Another calculates Z-spreads. A third file creates model points. A separate process may be used for stress testing or sensitivity analysis. Each step may work, but the overall process can become fragmented.

That fragmentation becomes a problem when a new reporting requirement asks for an integrated view.

In this case, the BMA reporting process required asset and liability KRD information to be included in the LLSBA process for both SBA and SA firms. For the asset side, this created a practical need:

• read bond-level asset data;
• project future cashflows;
• calibrate Z-spreads using the relevant discount curve;
• revalue assets under selected key rate shocks;
• produce KRD outputs; and
• validate whether the results are broadly reasonable.

This is not only a calculation problem. It is a workflow design problem.

From Separate Steps To One Controlled Process

The objective was to bring the key steps into one process.

At a high level, the tool follows this sequence:

The inputs are deliberately familiar: bond identifier, currency, market value, notional, coupon information, maturity date, call information where relevant, and the discount curves used for valuation. The outputs are also familiar: projected cashflows, calibrated Z-spreads, shocked market values, and KRDs by selected tenors.

What changes is the way the process is controlled.

Instead of treating cashflow projection, spread calibration and sensitivity calculation as separate exercises, the tool links them. The same asset data feeds the projection. The projected cashflows feed the Z-spread calibration. The calibrated spread is then used consistently when revaluing under shocked curves. The outputs are collected in one place so that the results can be reviewed, challenged and explained.

This is particularly useful when the same framework can also be adapted for other purposes. For example, by replacing the BMA discount curves with HKRBC curves, the same structure can be used to replicate RBC-style Z-spread calculations.

That does not mean the tool becomes a universal valuation engine. It means the process is transparent enough to be reused with care.

What AI Was Good At

AI was useful in the build.

Once the actuarial workflow was defined clearly, an AI coding agent could help generate the VBA structure needed to automate the process. It could create loops, read asset records, populate cashflow schedules, run repeated calculations, organise output tables, and help debug the mechanics.

This is exactly the kind of work where AI can be powerful.

The task is technical, repetitive, and detail-heavy. It benefits from speed. It also benefits from an agent that can hold a structure in mind and turn a sequence of instructions into working code.

In a traditional spreadsheet environment, a significant amount of time can be lost not because the actuarial concept is difficult, but because the implementation is tedious: copying formula blocks, maintaining consistent ranges, adding columns, handling multiple tenors, and checking whether outputs are written to the correct place.

AI can reduce that friction.

Some tasks are also safer to delegate because they are tightly testable. For example, reading bond data, reading the discount curve, solving for a Z-spread, and revaluing cashflows under stressed curves are all mechanical tasks with clear input-output relationships. The Z-spread calibration, in particular, has a natural closed-loop check: when the solved spread is applied back to the projected cashflows and discount curve, the repriced value should reconcile to the observed market value within an acceptable tolerance.

That does not make the task trivial. It means the task can be tested. AI can help implement the calculation and repair errors exposed by reconciliation, but the control expectation has to be specified by the actuary.

But this is only safe when the actuary has already defined the destination.

What AI Was Not Allowed To Decide

AI did not decide what the regulatory requirement meant.

AI did not decide which curve basis should be used.

AI did not decide whether a Z-spread was reasonable.

AI did not decide whether the KRD profile made sense for the portfolio.

Those are actuarial responsibilities.

This is the central lesson from the exercise. AI can build the engine, but the actuary must design the control room.

For this tool, the actuarial control layer included questions such as:

• Does the repriced dirty market value reconcile back to the input market value?
• Do shocked market values move in the expected direction?
• Does the KRD profile broadly reflect the maturity and cashflow profile of the assets?
• Are long-tenor sensitivities plausible, especially where cashflows extend to 20 or 30 years?
• Are callable features, maturity dates and coupon assumptions treated consistently enough for the intended purpose?
• Does the sum of KRDs broadly reconcile to an effective-duration-style measure?
• If a result looks unusual, is the cause data, methodology, curve construction, optionality, or code?

These are not cosmetic checks. They are the difference between a useful tool and a dangerous one.

Delegation Map

The practical question is not whether to use AI. The practical question is where to use it.

In this case, the delegation boundary looked something like this:

This boundary is important.

If too little is delegated, AI becomes a novelty. If too much is delegated, the process becomes unsafe. The value comes from controlled delegation: using AI where it is efficient, while keeping actuarial judgement where it belongs.

Validation Is Part Of The Design

One of the most important parts of the tool is not the calculation of KRDs itself, but the validation around it.

A KRD table can look neat and still be wrong. A macro can run without error messages and still be based on an incorrect maturity date, a misapplied curve, an incomplete cashflow projection, or a shock that is not being applied as intended.

For that reason, the tool includes checks such as market value reconciliation after Z-spread calibration and comparison of KRD outputs against a broader duration measure.

The duration comparison is not expected to be perfect. A small set of regulatory tenors, such as 2, 5, 10, 20 and 30 years, cannot capture every shape of the yield curve. Interpolation is needed to estimate sensitivities between key points. Callable features, curve extrapolation, shock size and non-linear effects can all create differences.

But the comparison is still valuable.

It gives the reviewer a sense of scale. If the sum of KRDs is broadly consistent with effective duration, the result has passed one important reasonableness check. If it is not, the difference may still be explainable, but it must be explained.

That is actuarial control in practice. The purpose of the check is not to prove that the tool is perfect. The purpose is to force the result to make sense.

The same principle applies to the interpretation of asset and liability KRDs. Suppose the asset KRDs diverge significantly from the liability KRDs beyond 30 years. That may be a modelling error, but it may also be economically reasonable. Asset cashflows after 30 years may be thin, while the liability profile may remain more long-tailed. In that situation, the actuarial task is not only to ask the AI to recalculate. It is to understand whether the mismatch is real, decide whether the validation evidence is sufficient, and explain the implication clearly to management.

This is the part of the process that should not be outsourced. AI can generate numbers, charts and diagnostics. The actuary must decide whether the result is credible, what it means for ALM risk, and how to communicate it to a CFO or reviewer.

Future Refinements

The current version is a working analytical tool, not a finished product.

There are obvious areas for refinement.

First, the key tenor design could be made more flexible. The current regulatory tenors can remain as the default, but the tool could allow users to specify additional tenors for internal ALM, validation or management reporting. A simple configuration table could make the macro less hard-coded and more adaptable.

Second, the validation section could be expanded. A useful enhancement would be to calculate portfolio effective duration under a parallel curve shock and compare it with an expanded KRD set, for example annual tenors from 1 to 50 years. This would create a stronger validation bridge between key rate sensitivities and total duration.

Third, the user interface could be cleaned further so that inputs, assumptions, outputs and checks are clearly separated. This matters if the tool is to be used repeatedly, reviewed by others, or adapted for future reporting cycles.

These refinements are worth doing, but they should not distract from the main lesson.

A tool does not need to be perfect to be useful. It needs to be controlled, understandable, and honest about its limitations.

The Broader Lesson

This case study is about asset KRDs, but the lesson is broader.

Many actuarial processes have the same shape. A new requirement arrives. Existing processes partly cover the need, but not cleanly. Data is available, but not in the right structure. Calculations exist, but are scattered. Validation is possible, but not embedded. Documentation is incomplete because the process evolved under time pressure.

AI can help in these situations.

But only if the actuary first understands the full process:

• the purpose of the requirement;
• the data needed;
• the methodology choices;
• the output users;
• the validation checks; and
• the points where judgement is required.

Without that understanding, AI may simply make it easier to produce a black box.

With that understanding, AI can become a practical accelerator. It can help convert actuarial design into a repeatable workflow, reduce implementation time, and make intermediate outputs easier to review.

The actuarial value is not in typing code faster. The value is in knowing what the code should do, what it should not do, and how to challenge the result when it looks too easy to accept.

AI accelerated the build.

Actuarial judgement defined the problem, challenged the output, and made the tool usable.

That is the relationship I want to keep exploring.

Note: This article is based on a mock asset dataset and a generalised workflow. Company-specific assets, curves, assumptions, reporting figures and confidential implementation details have been intentionally omitted or generalised.