What to make of the DB settlement

This morning, OFAC posted an enforcement action against Deutsche Bank Trust Company for a small amount of money, less than twenty grand. Nonetheless, the settlement is now of public record and its a foregone conclusion that legal fees, regulators demands and other items will most likely dwarf the cost of the penalty. Plus nowadays bad press is the last thing a large bank needs. Sadly, the staff at DB work very hard and have a monumental task and tend to be very dedicated, but certain items slip through the cracks. So the best thing to do in a situation such as this is to learn from the lessons and apply them to your own programs. The two best lessons I can bring from just looking at the settlement are both of a technical and human capital nature: 1. Let’s take a look at what happened with the first violation: On October 24, 2008, DBTCA processed a $3,177 funds transfer originated by Hansabanka’s customer, Air Baltic Corporation, destined for the account of “I.A.C.” at Commerzbank AG, Frankfurt, Germany. The originator to beneficiary information field of the payment instructions contained the reference “MELIGB2L,” the Business Identifier Code (“BIC”)for the London branch of Bank Melli. Only DB bank and the compliance officer working the case at OFAC know the full facts, however the failure to stop the Bank Melli payment for its SWIFT code produces a couple of questions you may want to test on your own filter. When OFAC designates an entity, sometimes certain items like a bank’s SWIFT code are left out of the designation and your institution will need to be able to fill in the gaps. Either you can purchase lists from private vendors or generate your own. Given this occured in 2008, it is unknown if DB had taken either of those courses of actions or simply placed what came in from the OFAC XML file into their filtering system. Yet in any event, assuming they had purchased a list it brings up a second and often overlooked issue: data quality. You know, that thing that plagues every database manager’s nightmares and gets compliance officers all loopy over their 8:00am coffee whenever they talk about it. But when you are testing your filters you need to make sure your data is consistent, full and if the datapoint is indeed unknown, at least it is marked as unknown. The worst case scenario is when a client, wire or filter data is marked with something incorrect that serves as a placeholder for an unknown data point. So don’t go putting your anniversary date in place of a new customers unknown DOB (seriously, this has happened). From a first glance at the settlement, and barring a quirk in the filter, my thoughts are that the Bank Melli payment slipped through from either incomplete entries on a prime sanctions target (I mean, Bank Melli and Saderat are basically the OFAC boogeymen) or there was an inconsistency within the data that caused the filter to overlook it. 2. The second transaction involved a wire that was ultimately intercepted by DB was rejected and not blocked, most likely from human error after a peer review: A total of seven DBTCA employees, including a senior member of the review team who was the final reviewer for escalated OFAC matters, reviewed this transaction and failed to notice the reference to EDBI in the payment. Based on their review, DBTCA rejected the transaction based on the beneficiary’s location in Iran, rather than blocking the transaction due to the involvement of EDBI. In this case, the filter...

read more