Reducing Invalid Alerts - 19 December 2011
Having agreed with the business what is a valid alert, it is possible to look at reducing the number of invalid ones.

The first thing to consider is the data. It may be a cliché, but "Garbage In, Garbage Out" is still a truism. If insufficient detail is provided in the customer, transaction or list data then the filtering will not be as efficient as it could be. For transactions, unfortunately, this is rarely possible to control as they must comply with the relevant wire service specifications. However, for the customer database the requirements for data sent to the filtering service can be specified internally. More importantly, in my opinion, however, is list management. Most people use lists directly from their creators, like OFAC, or from commercial list compilers like WorldCheck or Factiva with only minor internal additions. The problem is that some of these lists contain poor quality data that can cause significant problems for watch-list filtering software. Compliance departments are often reluctant to make alterations to commercially supplied lists but, in my opinion, there is scope to reduce the number of invalid alerts by applying some sensible editorial effort to them.

Once the input data is in order, we can turn to the output and how to modify that.

Speaking with alert handlers, I find the most common thing they do during Customer Database screening when looking to eliminate alerts against individuals with similar names is to compare the dates of birth. This can be automated in the software. The only criteria are that accurate dates of birth exist in both the list and the customer data and that their format is known so that a comparison can be made. This is particularly useful for PEP screening where the information is likely to be accurate so the difference in birth dates above which the alert can be discarded can be made quite small. For sanction screening, more care is needed because the dates of birth of criminals and terrorists are not necessarily known with the same degree of accuracy, where they are known at all. In this case, the difference should be larger. This leads to a quantifiable definition of an invalid alert. An alert against an individual will be considered invalid if: The exact values of course are decided by the Compliance team with due regard to the risk associated with the business. I have found a rule like this can remove a considerable number of alerts and is justified because it only automates what the alert handlers are doing anyway.

Again for customer screening, for companies and PEPs, a useful thing to do is to consider their location. In the modern world, individuals can be very mobile and criminals in particular will want to obscure their real location. For companies, however, it is much more difficult for them to relocate and, for PEPs, there is no incentive to give false information so John Smith, Mayor of London is unlikely to be John Smith of Boston, Massachusetts. This gives us another quantifiable general definition for an invalid alert. For transaction screening, Swift MT messages (are the ones of which I have most experience) are much less structured and it is therefore much more difficult to define general rules for what defines an invalid alert. With the advent of ISO20022 (SEPA and Swift MX) messages, this should improve but the watch-list software providers also need to mature in this area.

return to 1st page..