Checking data for a review: part 5 (field names)

This is the fifth 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)

Management reports often combine data from more than one system, like an origination system and a core banking system, or a claims system and a policy system. If a field like “approved” or “closed” means something different in each, the combined numbers can be wrong even though the data in each system is correct.

What we check, and what it can find

For a review, we go through the key fields that we need to use: confirming what each one contains, how it’s filled in, and whether that has changed over time. Data dictionaries help, but can be out of date.

Mismatches include:

• the same field name with a different meaning in different systems
• different field names with the same meaning
• a meaning that changed over time, such as status codes redefined after a system upgrade
• derived values that look like captured data, such as gender inferred from title
• a category in one system that is a subcategory in another.

A “gender” field might be self-identified in one system, and derived from the title field in another. As we covered when looking at sex and gender in data, titles like “Dr” don’t tell us anything about sex. A fairness analysis by gender across the two systems would be based on two different definitions.

In insurance, one system might record “storm” as a loss type, while another treats storm as a subcategory of “weather”, along with hail and flood. When the two are combined, storm claims from the second system can end up counted as weather claims, so claim numbers or decline rates by loss type won’t line up.

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.