NAIC ORSA Filings Require Lineage Across Risk and Reserves

Every insurer above NAIC's premium thresholds has to file an annual Own Risk and Solvency Assessment, a self-produced internal report proving to regulators that the company understands its own risk exposure and holds enough capital against it. The report sounds like a writing exercise. It is actually a data aggregation problem. A defensible ORSA pulls underwriting risk, reserve adequacy, investment risk, and reinsurance exposure into one coherent narrative, and those four categories almost always live in separate systems: policy administration, actuarial reserving models, the investment accounting platform, and a reinsurance tracking spreadsheet that someone updates by hand every quarter.

When those systems do not agree, or when nobody can explain how a number in Section 2 was derived from the underlying policy and claims data, the ORSA stops being a self-assessment and becomes an examiner's opening question. This post covers what NAIC's ORSA Guidance Manual actually asks for, why the data behind it is structurally hard to assemble, and what it takes to produce an ORSA that holds up when a regulator asks where a number came from.

What the NAIC ORSA Guidance Manual Actually Requires

The NAIC ORSA Guidance Manual lays out three sections every filing has to cover, and each one draws on a different part of the business.

Section 2 is where most of the data governance burden sits, because it requires the insurer to show its risk number is actually derived from the business, not asserted from a prior year's filing with updated totals.

Why Underwriting, Reserving, and Investment Data Stay Siloed

None of this is siloed by accident. Underwriting and claims data sit in a policy administration system built for transaction processing, not risk aggregation. Reserve estimates come out of actuarial models that take policy and claims data as an input but store their own assumptions and adjustments separately. Investment risk lives in a third platform entirely, usually managed by a different team on a different schedule. Reinsurance exposure, which determines how much of the underwriting risk the insurer is actually retaining, frequently lives in whatever spreadsheet someone built when the reinsurance program first launched.

Building the ORSA means tracing a number in the final filing back through all four of those systems to the source transaction that produced it, across code and schemas that were never designed to be read together. That tracing work, done manually, is what consumes weeks of actuarial and risk team time every filing cycle.

What Good Looks Like: Lineage an Examiner Can Follow

Foundational is the only data and AI governance platform that analyzes source code directly, including application code, actuarial model code, ETL and transformation scripts, and the established policy administration systems most insurers still run. That source code analysis produces deterministic lineage: a complete, cross platform map of exactly how a risk figure in the ORSA traces back to the underwriting, claims, reserve, and investment data that produced it.

Lemonade used this approach to significantly accelerate regulatory approval for its AI driven underwriting, because the lineage behind each automated decision was already documented rather than reconstructed under deadline. The same principle applies to an ORSA filing. When lineage exists as a byproduct of how the risk systems were built, the insurer is not reassembling evidence every March. It already has the evidence on file, and what regulators actually require from data lineage is exactly that kind of traceable, source derived record, not a narrative description of controls.

This is the same evidentiary bar insurers are already seeing on the AI side of their business. As Foundational covered when Colorado's AI insurance disclosure rules changed, regulators consistently want a decision trail back to source, not a compliance artifact assembled after the fact. ORSA risk aggregation and AI underwriting disclosure are different filings asking the same underlying question.

Own Risk and Solvency Assessment (ORSA)

An Own Risk and Solvency Assessment is an internal, insurer-produced report that evaluates the company's material risks and the capital it holds against them, filed annually with state regulators under the NAIC Model Act. Insurers above the premium threshold must complete one covering risk management framework, quantified risk assessment, and prospective solvency, and must be able to show the underlying data that supports each number. The assessment is self-produced, but the evidence behind it is what an examiner actually tests.

Frequently Asked Questions

Which insurers have to file an ORSA?

Insurers and insurance groups that write $500 million or more in annual direct and assumed premium, or that belong to a group writing $1 billion or more combined, must file an ORSA Summary Report under the NAIC Model Act, which the large majority of states have adopted. Smaller insurers can be required to file at a regulator's discretion, typically when risk profile or examination findings warrant it.

What does an examiner actually check in an ORSA filing?

An examiner checks whether the quantified risk figures in Section 2 and the capital conclusions in Section 3 can be traced back to the underwriting, reserving, investment, and reinsurance data that produced them. A narrative that describes a risk management framework without data to support the numbers is the most common source of follow up questions and supplemental information requests, and often the reason a filing draws a repeat exam the following cycle.

How does source code analysis help with ORSA data governance?

Source code analysis traces how a risk figure moved through the actual code and systems that produced it, including policy administration, actuarial reserving models, and investment platforms, rather than relying on documentation written after the fact. Foundational analyzes that source code directly and produces deterministic lineage, so the evidence behind an ORSA number already exists before an examiner asks for it.

Why is reinsurance data the hardest part of an ORSA to govern?

Reinsurance exposure determines how much underwriting risk an insurer actually retains, but it is frequently tracked outside the core policy and claims systems, often in spreadsheets maintained manually since the program began. Without lineage connecting those treaty terms back to the underlying policies, the retained risk figure in an ORSA filing is difficult to verify independently, and even harder to defend when treaty terms change mid year.

Conclusion

NAIC's ORSA Guidance Manual asks insurers to prove they understand their own risk, and that proof has to trace back to real underwriting, reserving, investment, and reinsurance data, not a restated summary of last year's filing. Foundational's source code analysis gives risk and actuarial teams that traceable evidence before the filing deadline arrives, not after an examiner asks. See how Foundational maps ORSA risk data back to its source on a demo call.