Stress-testing insurance illustration software — synthetic policies, synthetic insureds, real validation

Insurance illustration software is the engine that produces the projected policy values customers see at point of sale. It runs across product types (term, whole life, universal life, variable universal life, indexed UL, RILA, annuities), product variants per type, and carrier-specific contract terms. Every illustration is a regulated document — under NAIC Model Regulation 580, AG 49-A for IUL, AG 53 for non-guaranteed elements, plus state-specific overlays — and every wrong number is a potential market-conduct finding.

This article is the working note for engineering teams building or validating illustration software. The synthetic-policy-and-insured shape needed to stress-test across product types, the validation gates that catch regulatory non-compliance, and the failure modes that ship when the test corpus is too narrow.

What illustrations actually have to do

A compliant illustration produces a year-by-year projection of policy values — death benefit, cash value, premium pattern, dividends, indexed credits, charges — for both the guaranteed and non-guaranteed scenarios. The customer sees this projection. The state insurance department audits this projection. The carrier defends it.

The output has structural requirements:

Each row is a code path. Each carrier has its own implementation. Each state has overlays. The matrix is large and the room for error is correspondingly large.

Product-type-specific stress points

The AG 49-A tier (IUL specifically)

IUL illustrations are subject to the most explicit constraints. A compliant IUL illustration:

1. Constraint 1
   Illustrated rate ≤ BIA
   BIA = 25-year geometric mean of the underlying index with the contract's actual cap, floor, and participation rate applied. Engine has to compute this from history, not from a constant.
2. Constraint 2
   Multiplier self-funding
   Any illustrated multiplier (e.g., 110% of indexed return) must be funded by an explicit policy charge. The illustrated benefit minus the illustrated charge must net to zero on average.
3. Constraint 3
   Persistency bonus self-funding
   Same logic for bonuses that vest over time — must be funded by charges in the projection.
4. Constraint 4
   Indexed loan illustrated rate cap
   Illustrated rate on indexed loans cannot exceed BIA + 50 bps.
5. Constraint 5
   Disclosure presence
   Required statements about non-guaranteed values, BIA being a benchmark not a forecast, etc.
6. Constraint 6
   Side-by-side guaranteed presentation
   AG 49-A explicitly requires the guaranteed column to be visible, not just disclosed.

Engines that fail any of these gates are producing non-compliant illustrations. Carriers shipping non-compliant illustrations face market-conduct exam findings.

What the synthetic test corpus has to look like

A working illustration-software test corpus:

The non-compliant illustrations are the most important and most often missing. A test corpus consisting only of compliant illustrations doesn't exercise the violation-detection code path that's the actual job of a validation engine.

The validation gates

Three gates we run on illustration-software stress tests:

1. Gate 1
   Math reconciliation
   The illustration's year-by-year values reconcile across columns. Premium + interest credit − charges = next-year cash value, exactly. Engine bugs at this level are the most embarrassing.
2. Gate 2
   Regulatory compliance
   AG 49-A constraints, AG 53 dividend-scale rules, Model Reg 580 disclosure requirements. State overlays applied where applicable.
3. Gate 3
   Edge-case behavior
   Lapse-prone projections produce realistic warnings, not silent failures. MEC reclassification triggers visible disclosure. Section 1035 origin policies preserve basis correctly.

Engines passing all three gates on a comprehensive test corpus are in defensible position for the next NAIC exam. Engines that pass only Gate 1 — and don't have a structured test corpus — are operating at the regulatory risk that the regulator finds the issues before the engineering team does.