OFAC Enforcement Action: Another Grand Slam Penalty

Today OFAC released an enforcement action against Alma Investment LLC, a quasi-investment and trading company in the UAE that decided it wanted to violate the ITSR. This case and the penalties seem very similar to another grand slam almost exactly a month ago. While N=2 does not make a pattern, this is the second time OFAC has leveled the full amount of the base penalty under IEEPA against a trading company facilitating transactions with Iran in less than a 30 day period. Both cases were most likely concluded 30 days after the PPN was issued. If OFAC is getting tough against these trading companies, I would suspect that we will start to see an uptick on these enforcement actions. Likewise, OFAC not so subtly couched their rationale for this focus as that “assessing a civil monetary penalty against Alma will have a compliance/deterrence effect by encouraging greater due diligence by foreign financial institutions that maintain accounts for third-country trading companies and/or money transmitters.” Enough said.    ...

read more

When the assessed penalty = the base penalty

There is a bit of mystery surrounding yesterday’s penalty against a Turkish trading company. First, there isn’t much information on the company to start with, which honestly could answer one of the bigger questions. But to be assessed the penalty, they must have a U.S. presence or tenuous connection to our jurisdiction. That is perhaps the most unclear part, but given its a trading company they could very well have a small office in New Jersey that handles a bunch of import/export. This is pure conjecture however. What is striking about the penalty is that the entity was “assessed” the statutory maximum. I say assessed because it appears from the enforcement notice that the company did not settle nor did they cooperate with OFAC, a mistake on their part. OFAC assesses penalties based on enforcement guidelines. If a violation has occured that OFAC wishes to pursue, they may issue a pre-penalty notice (“PPN”) to the alleged party, which most likely happened in this case. The party then has 30 days to respond in writing, state their case and attempt to settle with OFAC. Of course, OFAC can and will extend the time allotted for a settlement if you reach out to them in good faith. Generally, it is during the settlement process that companies are able to negotiate down the penalty amount. Likewise, if an institution settles with OFAC then OFAC will generally only issue a settlement and not a finding of violation that explicitly declares that the institution has violated sanctions. It’s always been my opinion that because OFAC posts settlement agreements, whether there was a direct FOV or simply a settlement then the cat is already out of the bag. But I think the objective of a settlement is a reduced fine and to show the public that you cooperated with OFAC, not squabbling over legal syntax. The entire process can be seen in 31 CFR part 501 Appendix A(iv)(c). If you haven’t gone over this part of the CFR, you are doing your compliance program a disservice. In this case, it seems that the violator either made no attempt to settle, respond to the PPN or their attempt to settle was in such bad faith that a settlement was not possible. This is why the penalty was an assessment and not a settlement. Another point found here is that the penalty was for the statutory maximum allowed under IEEPA. Yikes. I haven’t seen a case like that in a while. Penalties are done on a sliding scale matrix. I pulled the figure below straight from part 501’s appendix. Essentially, on the horizontal, OFAC is looking to see if the penalty was egregious or resulted from reckless actions. In the most basic context, was this a simple mistake that yielded no harm to sanctions or was the transaction conducted by a sophisticated institution that was either acting recklessly, had knowledge of the action and resulted in harm to the sanctions program?     Some of the factors are the expected ones, and OFAC will take into consideration whether the compliance program was sophisticated at the level of the entity(i.e. a large bank needs to have a very good program), whether there was knowledge of the violation by senior management, what corrective actions were taken, how cooperative the institution was, etc. Winding up in the egregious category will result in the full penalty applicable for the program while the non-egregious side will result in a base penalty set forth in part (i)(b) of the appendix. The other side of the scale is for voluntary-self disclosures. While the entire...

read more

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

OFAC Reporting Requirements (Part I): Inside the Visa RPPR finding and the importance of reporting

Today, OFAC issued a Finding of Violation (FOV) against Visa. But it wasn’t your typical notice that we have been accustomed to, of payments slipping through the cracks, wire stripping or general failure to stop bad money going into bad hands. Today’s FOV was focused on the failure to report that an entity had blocked funds. Essentially, the crux of the FOV is that after blocking funds in which Iranian proliferation-bank Melli had an interest in, they placed the money into a blocked account but never reported it to OFAC. Of all the things that have happened in the past couple of years, this is comparatively benign. However, given the size of the institution (your wallet probably has one of their products in quick reach), a failure to report both left OFAC in the dark and raises some concerns about their program’s ability to keep records. Hence why this was an FOV and not a cautionary letter. To be clear, there are varying degrees of actions OFAC can take to penalize an institution. An FOV exists to straddle the dimension where a party committed an error that is of sufficient concern to OFAC that warrants more than a private cautionary letter but not of sufficient concern to warrant a civil penalty. Oddly, FOVs alone are a very rare occurrence, more rare than settling and much more rare than a simple cautionary letter. FOVs do tend to proceed a civil penalty, but this was not the case here. If anything, this case does bring up a very important point. The ten day reporting requirement is not arbitrary. It exists to ensure that critical information gets to the right people in a timely fashion.Blocked and rejected assets reports serve two key purposes. To provide information for the Terrorist Assets Report through the use of the Annual Report of Blocked Property. The second and more immediate purpose is these reports of blocked and rejected assets help paint a picture and inform OFAC of activities. These are critical for allowing OFAC to identify trends in sanctions, understand the landscape and identify possible violations. In this case, Visa left critical information out of both their annual report as well as two blocking reports. The consequences of these actions could be anywhere from something as simple as partial accounting of all blocked assets all the way to not having the right information about a critical incident involving sanctions. For instance, if a bank was to block funds but not report it and a party was to come to OFAC with a license to release those funds, OFAC, the client and the bank would all be caught flat footed in adjudicating the request. An even more serious example would be failing to report blocked funds from a bank with known ties to nuclear proliferation, resulting in OFAC not knowing about a particular transaction and being able to execute steps to prevent further transfers. It essentially gives the bad guys a head start on their ability to adjust.   This is part one in a series of OFAC reporting requirements that will cover the importance of good reporting, what OFAC does with Blocking and Reject reports and a look at the Annual Report of Blocked...

read more