Newsletter Sign-up

In November 2005, the Financial Crimes Enforcement Network, or FinCEN, promulgated regulations for the insurance industry stemming from the Bank Secrecy Act and USA PATRIOT Act of 2001.

The purpose of these regulations is simply to plug all cash flows that might serve to cover money-laundering operations, and the requirements parallel those already in existence for the banking industry, jewelers, precious metal dealers and casinos. The regulations that require insurance institutions to implement customer-identification programs provide guidelines for what organizations must do to ensure they are adequately complying with the requirement to clearly identify their customers.

In particular, it is quite evident that there is no clear guidance on what it means to ensure that a proper name check has been done on an individual or corporate customer. The failure to be specific about this means that an institution might well be liable for unintentionally performing an unacceptable name check due to archaic technology or procedures.

Bank Secrecy Act regulations mandated by Section 326 of the USA PATRIOT Act require financial institutions to establish "reasonable" and "practicable" procedures to verify the identity of any new customer, including determining whether the customer appears on any government-issued lists of known or suspected terrorists or terrorist organizations. Among the lists against which a customer's name should be checked is certainly the Specially Designated Nationals list maintained by the Office of Foreign Assets Control.

Yet, there are no guidelines whatsoever as to what constitutes a "reasonable" effort to conduct such a name search, or how to evaluate the results of that search. In fact, even if an insurance company is acting in good faith and following its own internally developed, documented procedures for researching potential customers, the company may still be liable for penalties if an obscure variation of the way that a name is spelled on the OFAC lists causes it to be missed during that process.

This is ominous indeed. What is it that causes such a problem with checking names on government lists?

First, it should be pointed out that it would be unrealistic to consider having some expert in names manually vet transactions against the SDN list. The December 5, 2005, SDN list contains more than 3,000 entries of individuals, vessels and businesses. Even if all names were reported exactly the same and there were never errors in name data, sorting through it would be a formidable task.

Much more daunting, however, is the fact that the list contains variant transcriptions of the same name and even blatant errors in name formatting. For example, the following entries all represent the same Islamic name:

* Abdel-Rahman * Abdurrahmane * Abd Al-Rahman * Al Rahman (Shaykh Umar Abd)

The last of these actually misplaces the Arabic prefix "Abd" (meaning "servant of") in the "Given Name" field. A quick review by an expert in multicultural names would reveal that there are many such problems with the SDN list, across a variety of cultures. For instance, the common Chinese name "Hsueh"--also found in the SDN--would be very likely to appear in its more modern form as "Xue."

Note that these are not different names; they represent the same name but written in different ways depending on which standard for transcribing the language is used. (Those not familiar with American names, for example, might have the same problem knowing that "Mary Ann" and "Marianne" could both be used to spell the same name.)

The question naturally arises: who in your organization is trained to know that these are variant forms of the same name? More to the point, should you even be required to have such people on staff?

Unfortunately, if you use an automated system to filter transactions, you could run even greater risks. The reason for this is because most name-searching systems in use today are based on something called "key-based" technology.

Key-based systems (also called "name grouping," "compressed name," "name rooting," etc.) all depend on some initial processing of names. They then retrieve names with the same "key." It's very fast, but very dangerous too.

The problem is that no one can predict with full confidence what a "likely match" will be. This is certainly true for the multitude of variations in the way names are transcribed from other writing systems, or when considering random errors, such as typos.

For example, Mir Aimal Kansi, who killed two CIA employees in 1993, was able to obtain a business visa and cross the border merely by dropping the "n" from his surname because this form of his Pakistani name (Kasi) baffled the key-based name-search systems in use at that time.

MITIGATING THE RISK

The government and regulators need to be more explicit about what constitutes due diligence in checking names against its lists. The Border Enhancement and Visa Reform Act of 2001 did just that. In Section 202 of that law, the government specifies that any name-search systems used for terrorist tracking by law enforcement and intelligence agencies must be the most advanced technology available.

The old one-size-fits-all, key-based systems must be upgraded to new technology that actually processes names differently depending on what kind of name it is. In other words, this multicultural name-recognition software should actually determine automatically what kind of name is being investigated (i.e., is it Chinese, Indonesian, Nigerian, Russian, Arabic, etc.?), and then modify its processing to produce the most useful matches for the person conducting the search.

Name-recognition technology has been so successful within the government that now major financial institutions use it to support their customer-identification programs processing. And, they are getting remarkable results in productivity and risk reduction from all over the world.

Requirements for filing suspicious activity reports in the United States are somewhat different than those mandated in the European Union. There, researching the actual likelihood that a potential match does in fact refer to the individual in question is the responsibility of the insurance company. EU financial institutions have to search the equivalent of 13 SDN lists, where the input from all member countries is considered. The need for sophisticated processing is thus even greater because names coming from other writing systems have French transcriptions, German transcriptions, Dutch transcriptions and so forth.

This obligation has caused considerable backlogs at those institutions still using key-based technology because those older systems are notorious for their incidence of false positives. In other words, many database returns from the key-based systems are clearly irrelevant, but they must be nonetheless manually vetted to be in compliance with EU law.

Those institutions that have implemented advanced multicultural name-search systems have reported profound reductions in such false positives and a substantial gain in their efficiency in processing potential SARs.

Until the government specifies for the financial community exactly what it deems necessary for adequate name checking, it would perhaps be worthwhile to check with and take cues from the U.S. Department of Homeland Security and other government agencies to find out what technology they use and recommend for this critical task.

JACK HERMANSEN is CEO of Language Analysis Systems Inc., a Virginia-based company that specializes in multicultural name-recognition software.

April 15, 2006

Copyright 2006© LRP Publications