Checking data for a review: part 4 (data ranges)

This is the fourth article in a series on the checks we run before using data for a review.

Why this is relevant day to day (not just in a review)

Models use these fields as inputs. Most models and processes have rules for simple defaults, like a date of birth of 1 January 1900. But those rules may not carry through to derived fields (e.g. age band), or may not cover other types of default values.

What we check, and what it can find

For a review, we look at the range of values in each key field, and the list of categories.

Issues we look for include:

• default or placeholder values, such as 1 January 1900, 999, zero or similar
• impossible values, such as a date of birth in the future, or a claim paid before it was lodged
• values outside product rules, such as a loan term longer than the product allows
• categories that aren’t on the expected list, such as codes from closed products.

When a system requires a date of birth, and it’s not available, a default like 1 January 1900 might be captured instead. In a fairness review, those customers fall into the oldest age band, so this can skew the age-focused results. Age can also be derived in different ways across systems, which adds to the problem.

If the review is about accuracy, some of these values may be findings themselves. So we don’t generally remove them, but note them down and then agree how to treat them.

Disclaimer: The info in this article is not legal advice. It may not be relevant to your circumstances. It was written for specific contexts within banks and insurers, may not apply to other contexts, and may not be relevant to other types of organisations.