2004 Nov 01
Lessons from the USA PATRIOT Act
David M. Raab
DM Review
November, 2004

Maybe I need to get out more, but I found the customer identification regulations of the USA PATRIOT Act to be fascinating reading. These regulations define how financial institutions are required to capture and verify customer information, to help prevent money laundering in support of terrorism, drug traffic and other criminal activities. The document is online at http://www.ustreas.gov/press/releases/reports/326finalrulebanks.pdf.

The regulations were actually issued in April 2003, effective October of that year. But regulatory compliance guidelines and examination procedures only started appearing during 2004, so it’s just now that many institutions are likely to be asked to show how they have met the rules. (And I would have gotten to the regulations sooner, but there was this delightful new Minneapolis phone book that I didn’t want to rush through. So many T’s!)

What makes the regulation document interesting is that, in addition to the rules themselves, it describes comments received on the original draft regulations and adjustments made in response. Whether the changes represent minor accommodations to practical reality or craven sacrifice of national security to corporate greed, you can decide for yourself.

But the regulations can also be viewed as a real-world example of a complex information management project. Since we can assume the initial proposals, comments and final resolutions were all carefully thought through, the document let us legally eavesdrop on an earnest and intelligent discussion. Indeed, the document reinforces lessons that are often taught but too frequently ignored.

– definitions matter. The first portion of the regulations defines basic terms including “account”, “bank” and “customer”. These generated considerable controversy, as commenters strove in most cases to limit the scope, and thus compliance cost, of the regulations. As often happens, the rules ended up with some pretty non-intuitive definitions. “Customers”, for example, includes only people opening new accounts who don’t have a preexisting banking relationship–thereby excluding signatories, beneficiaries, and people who apply but are rejected, all of which were covered in the original proposal. “Account” itself is also narrowly defined as a “formal banking relationship”, thereby excluding more casual transactions such as check cashing as well as non-banking relationships such as providing business services. Again, the original regulations were broader.

– processes, not systems, truly drive an organization. Just about the only specific requirements within the regulations are those describing how to set up a “customer identification program”. These include Board-level approval; documented policies, procedures and controls; a designated compliance officer; ongoing employee training; and an independent audit function. Record retention rules are also quite precise. By very sharp contrast, the only specific substantive requirement is that banks gather customer name, address, birth date, and government identification number–and there is considerable leeway even for these. Otherwise, a bank is pretty much free to set up any program it likes, so long as it can establish a “reasonable belief that it knows the true identity of each customer.” Even this standard is relative to the risks inherent in the bank’s particular business. Given the stress on flexibility, it is telling that the regulators understood that they had to require a formal process, and define the components of that process in detail, to have any hope of being effective.

– good data is hard to find. Of the four required data elements, address and government identification number generated considerable comment. It turns out that not everyone has a street address (for example, members of the military), and others do not wish to provide it for privacy reasons. The regulators allowed a few exceptions but generally retained the demand for a proper physical address instead of a mailing address like a post office box. Government identification number is even more problematic: again, not everyone has a Social Security Number or business tax ID, particularly non-citizens and new businesses. The final rules give considerable flexibility in this area, again ultimately relying on each bank to decide what to gather for a “reasonable belief” it knows the customer’s true identity.

– data errors are like weeds: they spread quickly and put down deep roots. This is one lesson the regulators seem to have rejected, presumably because they felt the cost was too high. Existing customers need not be re-verified, even if they were inherited through an acquisition, open a new account, or are simply existing customers of an affiliated institution. Thus, if anybody slips through the cracks once, they will never be checked again. Even more worrisome, exemptions for credit card issuers allow them to rely on third party data sources, such as credit rating bureaus, for information that would otherwise be provided by the customer itself. These sources are far from infallible, and even if a mistake is uncovered, any decisions based on the old data will not be revisited.

– identification and authentication are different things. The regulations correctly distinguish between gathering identity information from a customer, and verifying that customer is who he says he is. As anyone who has ever worried about computer system security realizes, these are indeed distinct challenges. The regulations provide no substantive standards for the verification process, other than helpfully noting that although “there is currently no method that would permit a bank to verify, for example, a taxpayer identification, passport or alien identification number through an official source”, the bank still “generally may rely on government-issued identification as verification of a customer’s identity” so long as it has not been visibly altered. Again, the details are left up to the bank’s own risk-based policy decisions.

– anti-terrorism efforts have a long way to go. Okay, this one has nothing to do with systems projects. But it was still jarring to read that although banks must check customers against federal terrorist lists, “because Treasury and Federal functional regulators have not yet designated any such lists, the final rule cannot be more specific with respect to the lists banks must check in order to comply with this provision.” It seems the Treasury Department’s own Office of Foreign Assets Control (OFAC) list, the main list for terrorists, money launderers, drug kingpins and such, is somehow not yet designated. You may sleep a little better knowing that banks (and pretty much everybody else) are required to check against the OFAC list by other regulations.

– everything costs more than you think it will. After noting that the “vast majority” of commenters concluded the regulators had underestimated the cost of compliance, the authors earnestly state they “reconsidered the burden estimates” and adjusted them–to eleven hours per year per institution. And you thought bureaucrats had no sense of humor.

* * *

David M. Raab is a Principal at Raab Associates Inc., a consultancy specializing in marketing technology and analytics. He can be reached at draab@raabassociates.com.

Leave a Reply

You must be logged in to post a comment.