Solvency II internal model approval is not primarily a test of model sophistication. The EIOPA supervisory guidelines and national competent authority examination practices converge on a consistent theme: regulators will accept a less complex model that is thoroughly understood and fully documented before they will accept an elegant model whose documentation is incomplete or whose audit trail is reconstructed rather than contemporaneous.
This is not an artifact of bureaucratic conservatism. It reflects a genuine supervisory concern: a model the carrier does not fully understand and cannot explain end-to-end is a model that will produce surprises, and surprises in a solvency context have systemic implications. The documentation standard is a proxy for model comprehension depth.
The following checklist is organized around the areas where pre-approval reviews and ongoing supervisory examinations most consistently find gaps. This is not a substitute for reading the Delegated Regulation (EU 2015/35) or EIOPA's guidelines on internal model submission, but it is a practical guide to where the preparation time is best spent.
Use Test Documentation
Article 120 of Solvency II requires that the internal model be widely used in and plays an important role in the governance and decision-making process. Supervisors interpret "use test" broadly, and documentation of model use is the most frequently cited gap in pre-approval reviews.
Required documentation includes: records of specific business decisions in which model output played an identified role, typically capital allocation, reinsurance structure decisions, and product pricing reviews; evidence that senior management and the board have received model outputs with appropriate explanation at regular intervals; and documentation that risk management decisions are traceable to model outputs rather than to separate judgment processes that happen to agree with the model.
A common gap: teams maintain excellent calculation documentation but have no systematic record of how model outputs influenced actual decisions. The calculation trail ends at the output, and the connection to governance is assumed rather than documented. Supervisors will ask for specific board minutes or management committee papers that reference internal model capital figures in the context of an actual decision. If those papers frame risk in terms of general experience rather than model output, the use test is likely to fail the documentation review.
Statistical Quality Standards: Assumption Documentation
Under Article 121, the model must use actuarial and statistical techniques that reflect the current state of practice. The examination of statistical quality focuses as much on assumption documentation as on model specification. For each key assumption, the documentation file should contain: the data source for the assumption, the date it was last reviewed, the review process used to validate it, a sensitivity analysis showing the impact of a material change in the assumption, and an explicit statement of the conditions under which the assumption would be revisited outside the normal review cycle.
The tail assumptions in reserve models and the correlation assumptions in aggregated risk modules attract the most examiner attention. These are the areas where the connection between data and assumption is most indirect, and where the examiner knows that small changes have large capital consequences. Assumptions that cannot be directly validated against internal data require particularly careful documentation of the external evidence or expert judgment basis.
Calibration Standards: Connecting to the 1-in-200 Standard
The Solvency Capital Requirement must correspond to the Value-at-Risk of basic own funds at a 99.5 percent confidence level over a one-year time horizon. The calibration documentation must trace the connection between model output and this standard explicitly. It is not sufficient to show that the model is calibrated to a 99.5 percent VaR in aggregate; the documentation must demonstrate this holds across the relevant risk modules and explain the aggregation approach.
Where historical data does not extend to the return period implied by the 99.5 percent standard, the documentation must explain the extrapolation methodology and justify its appropriateness. Supervisors are particularly focused on scenarios where the model implies implausibly low tail probabilities for risk types that have exhibited extreme events in the broader insurance market. The documentation should address these comparisons directly rather than leaving the examiner to draw their own conclusions.
Validation Documentation
Validation is a separate, ongoing process from model development. The validation documentation file should be maintained as a living record, updated each time a significant model component is validated, with entries timestamped and attributed to the responsible actuary or analyst.
The minimum validation documentation set includes: backtesting results comparing model predictions against actual outcomes over the longest available period; sensitivity tests demonstrating how the SCR changes with key assumption variations; a stress test log for the scenarios specified in the validation policy; results of profit and loss attribution exercises linking model predictions to actual P&L components; and documentation of any model limitations identified during validation with an assessment of the materiality of each limitation and the management actions taken in response.
We are not saying that a validation process without documented limitations is a sign of model quality. A validation document that finds no limitations is a sign of an incomplete validation process, and supervisors know this. Documenting known limitations with honest materiality assessments and described mitigants demonstrates model understanding far more convincingly than a clean validation report.
Documentation Governance: Change Management and Version Control
Post-approval, ongoing examination focuses heavily on change management. Article 115 requires notification of major model changes and pre-approval before implementation. The documentation system must be able to answer three questions for any point in time: what version of the model was running, what documentation applied to that version, and what was the approval status of the most recent changes.
The most common ongoing examination finding is not a model error but a version control gap. A change was made to the model, the change was considered minor, the classification as minor was not formally documented, and the updated documentation was not completed before the changed model began running in production. The change itself may be perfectly defensible, but the process trail does not demonstrate that the classification judgment was made with appropriate oversight.
A system that automatically logs model changes with timestamps, attributed changes, and a formal minor-versus-major classification step is not a luxury. For a team that has passed initial approval and is in the ongoing supervision phase, it is the mechanism that prevents a routine quarterly update from creating a documentation gap that requires explanation to the supervisor.
Operational Risk and Model Risk Controls
Article 230 requires a documented model risk policy. Examiners will request the policy document and then ask whether it is actually operating. Evidence of operating model risk controls includes: a model inventory with version and validation status for each model in scope; a documentation standard that is applied consistently and reviewed for completeness before each model is approved for use; a process for escalating model concerns identified during validation; and a documented owner for each model responsible for maintaining documentation currency.
The model risk policy is one of the areas where size matters in the supervisor's interpretation. A three-person actuarial team at a smaller carrier is not expected to have the same infrastructure as a large group. What the supervisor is looking for is that the controls are proportionate to the risk, consistently applied, and operated with genuine oversight rather than filed and forgotten. A simple, well-operated model risk process at a smaller carrier is viewed more favorably than an elaborate policy that the documentation record suggests is not actually used.
Pre-Submission Checklist: Where Teams Consistently Fall Short
Based on the patterns we observe in the documentation questions our early-access participants work through in preparation for regulatory interactions, four gaps appear most consistently. First, use test documentation that ends at model output rather than connecting to governance decisions. Second, assumption documentation that describes the current assumption but not the review process or the last review date. Third, validation documentation that is current for the last formal model review but has not been updated following subsequent quarterly model runs. Fourth, change management records that classify changes as minor without a documented rationale for that classification.
None of these require model rebuilding to fix. They require documentation discipline applied consistently over time, supported by a system that makes contemporaneous recording easier than deferred reconstruction. That is the distinction between documentation that satisfies an examiner and documentation that is assembled under pressure when the examination request arrives.
