A growing trend in financial institutions is performing rule-based auto elimination on secondary attributes. So for example when we have a match on a name; but a mismatch on a secondary attribute such as date of birth, nationality, or location; then the match will be eliminated before a person looks at it.
We at SQA Consulting only encourage this practice, but it should be done with care, computer-based rules have no lee-way for applying common sense, so your rules should be precise and cover all eventualities.
The date of birth seems such a simple thing to base elimination on if the dates of birth are the same – between your client and a watchlist entry with a similar name – then the likelihood of the match being true is significantly enhanced, more so than with any other attribute. If the dates of birth are different, then the likelihood of the match being true is severely degraded. A date of birth is a precise measure, it is a match, or it isn’t a match, but there are some cases that can cast doubt on a decision.
Date of Birth |
| Date of Birth |
| Reason for Doubt |
1965/11/10 | vs | 1965/10/11 | This could be an exact match with the day and month recorded in the wrong order. | |
1965/11/10 | vs | 1965/11/01 | This could be an exact match with only the year and month being originally recorded. | |
1965/11/10 | vs | 1965/01/01 | This could be an exact match with only the year being originally recorded. | |
1965/11/10 | vs | 1975/11/10 | This could be an exact match, but the data recorder accidentally typed a 7 instead of a 6. | |
1965/11/10 | vs | 1911/11/11 | This looks like a defaulted date of birth, more on that in the next article. | |
1965/11/10 | vs | 1927/02/29 | This is not a valid date and so cannot be trusted. | |
1965/11/10 | vs | 2030/02/13 | This date is in the future and so cannot be trusted. | |
1965/11/10 | vs | 2018/02/04 | This date is for someone very young, is it valid to have young people in our dataset? | |
1985/11/10 | vs | 1865/06/06 | This date if for someone unfeasibly old and so cannot be trusted. | |
1965/11/10 | vs | 1964/12/22 | These dates are unrelated, and there is no obvious reason to miss trust them. | |
1965/11/10 | vs | Circa 1975 | There is no indication of how close the 1975 figure is to reality, we cannot trust it. | |
1965/11/10 | vs | 1971/06/04 or | This person obviously goes by many dates of birth so do not assume that these are accurate. |
Many organisations go by a strategy of eliminating if the dates of birth differ by more than two years, yet clearly, as above there are reasonable scenarios where the date of birth could be different by much more than 2 years. Furthermore, there are dates closer than 2 years which have no similarity at all, and could reasonably be eliminated.
By following a careful strategy that considers all of the cases above you can safely eliminate screening alerts using auto elimination, not only will you achieve a lower false-positive rate, but you can also avoid manual mistakes where the above rules are not adhered to consistently.
To read more articles around how to auto eliminate safely. Click on the link here.
