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.

• Single names, both as known aliases and sometimes main names: Patricia, Carlos, Guiseppe and Ashok all being examples that can cause problems. Ashok, in particular has no other useful information than that single, relatively common Indian name.
• If you have to screen against the Hong Kong Securities and Futures Commission (HKSFC) list you will come up against entries for major financial institutions like Standard Chartered Bank and Wells Fargo. The latter does not even refer to the real Wells Fargo but someone trying to pass themselves off as Wells Fargo for phishing purposes.
• It may be paranoia, but the Iranian Shipping Company seems to have renamed all their vessels to deliberately confuse watch-list filters: Laura I, Brothers, etc. All names of ships that will match with common European business names.

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:

• Both list entry and customer record contain a valid date of birth. Beware of dummy dates, (I have one client whose system puts 01/01/1850 into the date of birth field if it is unknown) and cover multiple formats and separators.
• For sanction screening the date of birth of the list entry and that of the customer differ by more than 5 years.
• For PEP screening the date of birth of the list entry and that of the customer differ by more than 2 years.

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.

• Both the list entry and the customer record contain location information (City and/or Country)
• For companies or PEPs, the location information does not match.

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..