Monthly Archives: December 2012

12.31.12
by

Set phasers (not) to stun!

A lot of this seems daunting, doesn’t it? So many possible lists, system settings to consider… and so much work to process Day 1. Seems a little nuts to me…

Well, even if you’re facing down the loaded end of a C&D (cease and desist), one doesn’t have to implement a whole raft of changes in the blink of an eye. You can phase in your changes.

What auditors and regulators want to see is, of course, an acceptable program – eventually. What matters more is the plan to get there. These folks aren’t ogres (at least, not the ones I’ve met).

Imagine the following paths to “full” compliance:

  1. In January, you screen all accounts with an average daily balance of $1MM US against your PEP list. In March, you lower that threshold to $750,000. In May, you lower the threshold to $500,000. In August, it goes down to $250,000 and finally, in January of the next year, you drop it to $100,000…
  2. In the beginning of January, you start screening your accounts against sanctions lists using exact matching. In mid-January, you start using fuzzy screening at 93%. In mid-February, the fuzzy threshold drops to 91% – in mid-March, to 90%, in mid-April, to 88%, in mid-May, to 87%…
  3. In January, you begin screening against OFAC, the HMT (Her Majesty’s Treasury) list, the UN list and the EU list, because they’re your highest-volume currencies. In February, you add the second tier – the Canadian lists (OSFI, plus the DFAIT economic sanctions countries and cities, which include some city names that are very common in the US), the Japanese Ministry of Finance, the Monetary Authority of Singapore list and the Hong Kong Monetary Authority list. In March…
  4. In January, you start screening account information against national and international-level foreign PEPs that are still in office. In February, you include officials who have left office within the last 3 years. In March, you include national and international-level domestic PEPs who are still in office. In April, you include domestic officials who have left office within the last 3 years. In April, you include provincial/state-level domestic PEPs. In May, you include local-level domestic PEPs.
  5. In January, you start out with what you consider the bare minimum list of sanctions lists, including OFAC. Over the next few months, you add transaction-specific lists, such as BIS (Bureau of Industry and Security), BISN (Bureau of International Security and Nonproliferation), DTC (Directorate of Defense Trade Controls) and the World Bank Debarred List. In the second half of the year, you add a screen to your client onboarding process against law enforcement lists, including US Marshal Service, FBI, and Interpol.

Making some of these changes may increase the overall number of matches over time (e.g. changing the fuzzy logic level), while others may just increase the number of matching entity listings (which increases the time to clear each item).

Why phase in changes, instead of a “big bang” that gets your program up to snuff immediately? First, there’s the cost – a large increase in matches will either mean overtime, a large increase in staff or temporary help and/or less time devoted to making a decision on each match. Second, there’s the likelihood that a massive set of changes will overwhelm your staff, making them less, rather than more, productive (which adds to costs and errors). Third, making significant changes requires that compliance processes still keep their focus on the proper set of priorities – like, economic sanctions items are most important, followed by PEP screening, followed by other due diligence efforts (that’s an example – your priorities might be different). Priorities can easily get lost amidst the rush to get the decks cleared on a daily basis.

So, plan getting from here (where you are today) to there (where you want to end up) in an orderly fashion, like they tell you to do in movie theaters for if there’s an emergency, like a fire – instead of in the mad rush that usually happens. There will be fewer bruises all around if you do.

12.31.12
by

Happy New Year!

May your 2013 be filled with greater subject matter expertise, more skilled, productive and knowledgable staff at all levels, and (especially) fewer regulatory inquiries.

All the best from Mr. Watchlist – thanks for reading!

12.28.12
by

ITSR, TRA, E-I-E-I-O!

OFAC yesterday published its final rule regarding the amendments to the ITSR (Iranian Transactions and Sanctions Regulations) which were mandated by the passage of the TRA (Iran Threat Reduction and Syria Human Rights Act of 2012) and elements of Executive Orders 13622 and 13628.

These changes are, in really concise form:

  1. Transactions with the Iranian government or their agents, by entities owned or controlled by US persons, but established or maintained outside the US, are prohibited if such transactions would be prohibited for entities established or maintained in the US
  2. “Winding-down” transactions, if they don’t occur in the US or involve a US person, are now permitted. Such transactions involving Iranian financial institutions are only authorized if the assets involved are blocked only due to these specific transactions.
  3. Transactions involving entities owned or controlled by a US person and established or maintained outside the US are authorized if such transactions would be authorized (due to general licenses) for an entity established or maintained in the US
  4. A number of general licenses are being amended so that, if a transaction would normally be authorized under one of them, but would be blocked under other parts of the sanctions regulations, the transaction is not authorized
  5. There are new civil penalties for entities owned or controlled by US persons, but established or maintained outside the US, which engage in transactions intended to evade sanctions regulations, unless the US person terminates its relationship with the entity by February 6, 2013

OFAC also notes it is making a pair of “technical corrections” to ITSR subpart E, section 560.505.

Now, these changes refer to specific sections of the ITSR – rather than delve into these in detail, it’s better to consider the impact of these changes. The bottom line is that:

  1. Sanctions, licenses and civil penalties extend beyond the US shores as long as the entities involved are controlled or owned by US persons.
  2. You can’t pick and choose the parts of the regulations that are the most lenient – if there are more than one reason an item is blocked, each has to be lifted for an item to be authorized
  3. Not all of this is with immediate effect. Certain winding-down transactions are being permitted and offshore entities can evade OFAC’s reach if their US ties are cut

Fun reading for the New Year…

Links:

OFAC Press release
Final Rule for ITSR Amendments in Federal Register

12.28.12
by

What makes PEP different

Identifying Politically Exposed Persons, or PEPs, are a mandatory part of typical anti-money laundering (AML) regulations issued by governments. PEPs pose a greater than normal risk of being involved in financial crimes, such as fraud and money laundering, because of their access to, and influence over, large amounts of capital.

When one identifies who is a PEP, there is a business decision to be made: will the business relationship be maintained and, if so, will any additional ongoing monitoring of the customer’s transactions take place so as to identify possible malfeasance?

A whole ‘nother kettle of fish

This makes PEP screening fundamentally different than in a number of ways than economic sanctions screening. Firstly, one generally only screens static data like account information to identify PEPs; identifying patterns of conduct involving someone not on the firm’s books is very difficult, at best.

Secondly, since a PEP is not inherently a “bad guy” who you have to report to the authorities, the standard of care in identifying them can be different. For example, one could exclude defined contribution accounts (e.g. pensions, 401K, 403B, and 529 accounts) from a PEP screening under the reasonable assumption that those accounts cannot credibly be involved in a fraud or other financial crime due to the restrictions on those accounts, while you would have to screen those against sanctions lists. Or, you could use a more stringent matching methodology to find PEPs (also driven by how much larger PEP lists are – one commercial provider has over 1.1 million named individuals on its list), since the implications of “missing” a PEP are only an issue if that client actually launders money or commits a fraud through the account.

Who am I looking for?

Now, here’s the real problem: what’s a PEP, and how does one gets lists of them? On the first point, there are no globally-accepted definitions. Countries typically set the standards for their regulated entities, or piggyback on definitions from international groups like FATF (Financial Action Task Force) or the Wolfsberg Group.

The definitions, at a very basic level, define classes of persons connected with governments, their family members and close associates, when one becomes a PEP, and when one ceases to be considered a PEP. Unfortunately, these vary wildly: in some countries, “family members’ are parents, children, siblings and spouses, while in others, extended family members are included as well. In some countries, people become PEPs when they decide to run for political office, win or lose. And the “expiration” of a PEP designation ranges from 1 year out of office to no standards whatsoever. The one common thread appears to be, however, is that the officials who are designated as PEPs are federal-level officials, not provincial or local-level functionaries (although in practice, not so much).

A new wrinkle has arisen recently from the offices of FATF. Until now, PEPs generally were understood to be foreign officials, not domestic ones – in fact, a number of regulators referred to them as PEFPs (Politically Exposed Foreign Persons). While this still can result in high match rates, it is generally lower in countries that are not particularly ethnically diverse; scanning names in Portugal may hit Brazilian officials and those of Portuguese extraction around the world, but will not match a lot of names from Russia or Japan or..

FATF recently updated their AML/CFT Recommendations to include screening against domestic PEPs. As one can imagine, that will significantly, if not exponentially, increase the number of PEP matches – and the ratio of false positives to true matches.

PEP Lists

On the second point (knowing what PEPs there are out there), regulators say you must identify PEPs, but give no real assistance as to identifying who these people are. The lists which drive PEP screening are all provided by commercial vendors. And, since “bigger is better”, since it reduces the risk of missing someone, commercial PEP lists are enormous – there is a real “arms race” to have the biggest, most “complete” database.

Part of that reason is that the driving force behind PEP identification is to prevent financial crime; officials in control of only part of a country are just as capable, albeit on a smaller scale, of committing fraud as national figures. And regulated firms, especially the largest, want to identify those persons, too – from a purely financial and reputational risk perspective (no one wants to be mentioned in a story about fraud or money laundering). Therefore, commercial PEP lists have come to include provincial/state and local officials as well as national ones. As you can imagine, there are many more of those than federal-level officials, in general.

In general, if a government employee with a title can be identified, they have a decent chance of ending up on a commercial PEP list. Years ago, I searched for my last name on the PEP lists we used. I found a Jeff Sohn (no relation), who was a project manager with the NY State Library Department. A very wide net, indeed.

The bottom line

So, it lands on the compliance professional to manage the onslaught of data. This can be done by setting corporate standards for how frequently to screen, which relationships to screen, and which PEP listings to screen against, among other potential parameters. Those decisions are part of a firm’s “risk-based” AML program, where the risk of financial or regulatory liability is matched off against the cost of reviewing the potential matches.

12.27.12
by

It takes two to tango

So, companies match their static and transactional data… to what? What specific pieces of the watchlist listing should be matched?

Well, what is there to match on? Well, there’s the name… what else?

Listings often have addresses but you don’t really want to match on those alone. After all, street addresses are not unique and, in fact, may generate false positive matches (there is a street named after Robert Mugabe in Harare, Zimbabwe, for example). And listed individuals may be located in non-sanctioned countries. I know of one OFAC-listed firm (Travel Services, Inc.) located in Florida in the US, for example.

For similar reasons, date of birth is not a good single element to match on. And don’t get me started about OFAC, who lists some dates of birth as “approximate”, in which case they want you to pick up the phone and call them regardless of how far off the dates are.

But, on a frequent basis, there are other ways to identify the listed entity besides their name. For example, national IDs like the Cedula in Colombia or the SSN in the US are included in sanctions listings. Same thing goes for passports for people, DUNS or VAT IDs for companies, IMO (International Maritime Organization) numbers and call signs for cargo vessels, and SWIFT ids and other routing codes for banks (and some corporates).

Now, I have mentioned matching on a single element. Why not multiple pieces of information?

Certainly, you can rely on multiple pieces of information in static data screening – if you have it, if the data quality is good, and if you consider keying errors and use of default values. Raise your hand if you’ve ever seen a system that defaulted date fields to 1/1/1970 (Windows) or November 11, 1858 (DEC VAX – remember those?). Of course, the chances of you getting multiple criteria if you’re screening transactional data are slim to none.

Don’t forget that dates come in multiple formats – US format (month/day/year), European format (day/month/year) and the format used in Asia (year/month/day). It’s important to know how the dates are formatted by the data provider before trying to use date of birth as a matching criteria – at least past using the year.

Now, I should preface the rest of this by noting that how data actually gets matched – whether the matching criteria are in software or in the watchlist databases – varies. So, both the software and data providers need to be able to explain how the data elements that generate matches are being derived.

As you can see, I’ve avoided the elephant in the room – the entity name. What should we match on? Let’s assume that things other than people and groups (i.e. countries, cities, cargo vessels) are pretty simple – match the whole thing. But, what about those pesky people, companies, and other organizations?

At one end of the spectrum, you could match on the entire name as listed – but you’d miss a lot of potential matches. People often don’t use their full names when opening accounts, much less doing business, and the little niceties of corporate names (e.g. The, A, Of, Inc, Corp, etc.) often get omitted in the name of brevity and speed.

On the other hand, you could cast a very wide net. Imagine matching on a person’s last name only, or matching on any individual token in a corporate name – oh, the horror! Clearly there is a middle ground.

Let’s deal with corporate names first. It seems a reasonable middle ground to eliminate articles, prepositions and corporate suffixes (Co, Corp, Inc, Ltd) and match on what’s left. Additionally, if the group or company is identified by an acronym, it would be reasonable to match that, too (although I have a beef about that which I’ll get into in a future post).

How about individuals? Again, you’re not going to get all the names, fully spelled. So, it boils down to a question of what subsets of the possible names you should match on. In general, Mr. Watchlist believes that any matching system must match multiple name components, one of which is the last name.

Now, let’s now enumerate all the little details that one (or, at least, one’s software) needs to take into account:

  1. One must consider what abbreviations or contractions, alternate spellings or transliterations and foreign translations, of the selected tokens might also occur – and account for them. “Bank” should match “Bk” and “Banca,” while “Mohammed” must also match “Muhd” and “Muhamad” (among many others).
  2. One must consider what is considered a person’s last name.
    • For Hispanic names, the first last name is the father’s, which will always be used. For Portuguese names, it’s the second last name. If you wish to also search for the “optional” names, realize that, at best, you will generate multiple matches when you could have generated one (e.g. “Maria Elda Rodriguez Pulido” will match “Rodriguez Pulido” as well as “Maria Rodriguez”) and may also generate matches to obvious false positives (“Rodriguez Pulido” will also match “Jose Rodriguez Pulido”, for example).
    • For Arabic names, there are multiple name components that are neither considered “last” or “midde”. The one that, according to an acquaintance of Mr. Watchlist’s from a bank in the UAE, is the closest to a “last” name is the nisbah, which is a tribal or geographic name (e.g. “Al-Tikriti” or “of Tikirit”, was Saddam Hussein’s nisbah). And the kicker is that the only “required” name component is the first name – so you may not even get a nisbah.
  3. One must consider how to handle name components that consist of multiple tokens. For “Juan M. de la Cruz”, does the software drop “de” and “la” (meaning “of” and “the”) and match only on “Cruz”, or does it require all three? Similarly, “Abdul” in non-Americanized Arabic names, is always followed by one of the 99 adjectives for Allah. Does the software treat the pair of tokens as a single name component? As an aside, the “Abdul Rahman” on the SDN list is really the equivalent of listing someone purely as “Barney.”

Of course, the elephant in the room remains to be named: unless you are willing to endure great expense, you will not catch everything. Normally a listing for “The Ford Motor Company” would match on something like “Ford Motor”, and possibly abbreviations like “FoMoCo” and “FMC”. But you could get a reference like “Ford” – do you really want to stop all references to that? In a more tangible sense, there were Burmese companies called “New York” and “Hong Kong” – someone, somewhere (either you or your data provider) had to make an assumption or shortcut to prevent the deluge of matches.

So, that really is the last issue to be considered: how does a data provider deal with terms that are too generic to be a sole matching criteria? There are entity names, aliases or acronyms of “So”, “Maria”, “SRA”, “BOTH”, “Am”, and “55”, not to mention the examples above. Does the data provider drop these, combine these with another criteria (e.g. “Hong Kong Yangon” because the company is located in Yangon) or leave them as-is? And how can you modify the handling of these should you wish to?

Ultimately, you may not get a perfectly-tuned set of data. However, if you at least understand the reasoning behind what it provides, you can better strategize your matching and operational strategies going forward.

Reference:

Arabic nomenclature: A summary guide for beginners

12.26.12
by

Bad puppy!

Well, I mentioned in my previous post that I would deal with the problems I see with the “refer back to lower-level staff” workflow step separately. Well, this here is where I’m going to deal with it.

The problem, to my mind, is the “puppy peeing on the carpet” problem. So, if you’ve ever had a puppy, you know they have accidents. And there are various ways of dealing with that problem, and none of them are particularly pleasant. One of the ways people handle doggie pee is to whack the dog on the nose with a newspaper – bad dog!

The dog may make the error once again, maybe even twice. But eventually they learn – and, except for when it’s sick, or left at home way too long between walks, the dog never soils again. There is no more need for a rolled-up newspaper as a training device.

The same happens with referrals back to the lower-level staff. They may not give you enough information once or twice, but that referral will clearly be seen as punitive (and something that can probably be dragged out of the system logs for their annual review). After it happens a number of times, they will go out of their way to document, if not over-document, everything about each item that they send up the chain of command. So, not only is that part of the workflow not used again (unless you have a new litter of puppies), staff is probably wasting time getting too much information just so it doesn’t get another referral from management.

Mr. Watchlist’s mantra is to keep it simple unless you really have to do otherwise. Referrals down the chain of command are an unnecessary frill that will probably produce unexpected and unwelcome consequences.