2.1 Requirements Gathering & Assessing Data Relevance

Why Task A-1 Exists

The first task in the PCPA Content Outline's Dealing with Data domain is to "gather and assess the relevance of information from stakeholders in actuarial analysis." It is listed before importing, transforming or cleaning anything, and that order is deliberate. A technically flawless GLM built on the wrong target variable, the wrong population, or fields that will not exist when the model is used is worthless.

On the project, you do not interview anyone — CAS hands you a statement of the business problem, scope parameters, and one or two data sets. The skill being assessed is the same one: read what you were given, work out what question is actually being asked, and decide which supplied fields belong in the model.

From Business Request to Modelling Question

Stakeholders rarely arrive with a modelling question. They arrive with a symptom. Your job is to convert it.

Four decisions come out of this conversation, and all four must be settled before you write any code:

1. The target variable. Pure premium, frequency, severity, loss ratio, or a binary outcome such as renewal or large-loss indicator.
2. The unit of analysis. Policy term, policy-year, claim, vehicle, or location. This determines the grain of every join you will do later.
3. The population. Which line of business, which states, which policy effective dates, and what is deliberately excluded (for example, reinsurance assumed business or run-off programmes).
4. The decision the model supports. Rate relativities, underwriting referral, claims triage, or marketing. This determines what "good" means, which diagnostics matter, and who the eventual audience is.

Who Holds Which Piece of the Story

Different functions know different things, and each reveals a different class of defect.

• Underwriting — knows which fields are actually collected at quote, which are optional, and which underwriters routinely default or leave blank. This is where you learn that a "years in business" field is 60% missing for one distribution channel.
• Claims — knows how case reserves are set and re-set, whether the extract is on a report-year or accident-year basis, and which claim types are handled outside the main system.
• IT and data engineering — knows the extract's refresh cadence, its keys, when a system conversion changed field definitions, and which fields are overwritten rather than versioned.
• Product management — knows about rate changes, form changes, and underwriting-guideline changes that make old policy years behave differently from new ones.
• Compliance and legal — knows which characteristics may not be used in the jurisdiction being priced, and which require filing support.

Four Tests for Relevance

A field supplied by a stakeholder earns a place in the candidate predictor set only if it passes all four of these.

1. Does it exist at decision time? If the model prices a policy at quote, then any field populated after the policy is written — endorsement counts, audited payroll, claim adjuster notes — is unavailable when the model must run. A field whose value is only known after the outcome is a leakage field, and it will produce spectacular training performance and a useless deployed model.

2. Does it describe the risk period being priced? A vehicle's odometer reading today does not describe the policy year that produced the 2023 losses in your training data. Predictors must be as of the start of the exposure period for the record they sit on, which is why point-in-time snapshots matter more than current-state tables.

3. Is it populated for every record to be scored? A field available on 40% of renewals and 5% of new business cannot carry a rating relativity for new business. Coverage rates must be checked per segment, not just in aggregate.

4. Is its use permitted and defensible? Some characteristics are prohibited or restricted in the jurisdiction being priced, and some are permitted but require filing support. This screen belongs at the front of the process, not after you have tuned a model around the variable.

[!WARNING] The most common P&C leakage traps: claim counts or paid losses used as predictors of loss cost; "policy cancelled" flags predicting retention; audited exposure predicting a premium that was itself derived from the audit; and a reserve-adequacy field built from the same triangles that produced the target. Each one is a field that stakeholders will genuinely offer you, and each one is disqualified by test 1.

What to Ask For, Explicitly

When requesting an extract, specify all of the following. Vague requests generate the data problems you will spend the rest of the project fixing:

• Grain and key — one row per what, and which columns uniquely identify a row.
• Date basis — accident year, policy year, report year, or calendar year, and evaluated as of which date.
• Loss basis — paid, case-incurred, or ultimate; gross or net of reinsurance; with or without ALAE; capped or uncapped.
• Exposure definition — earned or written, and in what units.
• Scope filters — states, lines, sub-lines, programme codes, and anything deliberately excluded.
• Field dictionary — definitions, permitted values, units, and the date each field was introduced.

Carrying This Into the Project Report

The project rubric does not have a line item called "requirements gathering," but two criteria depend on it directly: the model must work and be appropriate to address the business question (C-3), and the candidate must describe why a variable was or was not included (C-2). A single sentence early in the report — naming the target, the unit of analysis, and any field you excluded because it would not exist at decision time — earns credit against both.