The checks we run before using data for a review

Getting hold of the right data is often one of the slower parts of a review. Once we have an initial sample, there's a set of checks to make sure we can use it effectively. We then repeat most of it when we have the full data set.

These checks highlight issues almost every time, so we have to do them. The result is usually a discussion to understand where any problems are coming from, then refining the data request.

Some checks form part of the initial reconciliation. Others go beyond the recon, because data can be accurate and complete and still not fit for purpose.

The issues we pick up through these checks affect the data our decisioning systems use. So the checks are just as useful day to day, outside of a review or audit.

In this series of articles, we’ll go through seven of these core checks and why they’re important.

Technical checks

1. Completeness (recon: do we have all the data)
2. Accuracy (recon: does the data line up, broadly)
3. Data ranges (dates of birth, timeframes, values, categories)

Functional checks

4. Field names (what they mean and how consistent they are across systems)
5. The effective date (current state, or state at the time of the decision)
6. Blanks/nulls (sounds technical, but is usually more functional)
7. Multiple master data entries for the same customer (should be covered by KYC checks, but often isn’t).

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.