Wells Fargo, Part II: The Data Stuff
Today we continue our look at the latest enforcement action against Wells Fargo, this time examining all the operational-level improvements that the bank needs to make in its financial crimes compliance program, per a settlement with banking regulators reached last week.
As you might recall, Wells reached a settlement with the Office of the Comptroller of the Currency to overhaul its compliance program — everything from suspicious activity identification, to customer due diligence, to risk assessments, to sanctions compliance, to data integrity and testing. While the bank makes those improvements, it can’t expand into any new products or geographic markets with medium or high money-laundering risks without first seeking OCC’s blessing.
In our previous post about all this, we explored the reforms that Wells Fargo’s board needs to make, as well as the roles and responsibilities that management needs to make in both the First and Second lines of defense. That still leaves a lot of operational specifics, so let’s get to it.
First, Wells needs to improve its customer due diligence program. That means the compliance team needs to define levels of customer risk clearly, and then develop a methodology for assigning those defined risk levels to the customer based on that customer’s entire relationship with the bank: who the customer is, where he or she lives, the typical transactions he or she makes, the dollar size of the transactions, and so forth.
Wells needs to adopt a lot of procedures along those lines, too. Procedures to collect and verify beneficial ownership information for new accounts; procedures to verify customer identity data; procedures, procedures, and more procedures.
Interestingly, Wells Fargo must also adopt procedures that “contain a clear statement of management’s and staff’s responsibilities,” such as reviewing customer risk profiles and approving changes to those profiles as necessary. Those procedures must also assure that staff responsible for customer due diligence have sufficient authority, training, and skills to perform their assigned responsibilities.
That all sounds great to me, but what OCC is really saying here is that Wells must adopt forcing mechanisms to make managers take their customer due diligence and other anti-money laundering compliance duties seriously. That’s good; we’ve seen many examples over the years of banks turning a blind eye to those duties. I just don’t recall a regulator calling out this specific fix so explicitly.
Identifying Suspicious Activity
Yes, Wells must improve its procedures and controls for identifying suspicious activity; but I was particularly intrigued to see that it has lots of work to do on transaction monitoring — which is a technology-intensive challenge, and a real headache to do well and expediently.
For example, Wells Fargo must have procedures and controls to assure that its transaction monitoring systems apply appropriate rules, thresholds, and filters for monitoring transactions, accounts, customers, products, services, and geographic areas; and all of that activity must be “commensurate with the Bank’s BSA/AML risk profile.” So if Wells Fargo wants to expand into high-risk jurisdictions or products (lookin’ at you, cryptocurrency), it will need to improve its transaction monitoring capabilities dramatically.
Moreover, Wells’ methodology for establishing and adjusting rules, thresholds and filters must be properly appropriately documented; and its automated transaction monitoring systems must undergo periodic independent validation. Any time those tests identify something that comes up short, the findings must be documented and promptly addressed.
That’s a lot of promises to make about effective transaction monitoring systems. The obvious question, then, is who does all this at a practical level? I assume the compliance team will sketch out all those procedures at a logical, flow-chart level, but the technology team will need to implement those procedures in the real world, on real systems. Then an audit team will need to test the procedures on a regular basis.
I’m fascinated by all this because this is a challenge that one of Wells’ top competitors, Citibank, has so far failed to manage. Citi has struggled for four years to improve its regulatory compliance program. Just last week it pushed aside its chief operating officer for the slow pace of progress, and assigned chief technology officer Tim Ryan (yes, that Tim Ryan, former head of PwC) to take over.
Wells apparently is not as far gone as Citi, since OCC fined Citi earlier this summer for its inability to improve its compliance technology, whereas it only put Wells on an improvement plan. Still, the challenges for Wells are likely to be formidable.
Better Data Integrity
Along similar lines, Wells must also strengthen its program for data integrity, since without quality data its sanctions and AML compliance efforts can’t be trusted. To that end, the bank must…
- Define clear roles and responsibilities for the management of compliance data.
- Maintain inventories of the bank IT systems that contain relevant compliance data.
- Document its “data dictionaries” and “data sourcing process maps,” which, respectively explain the nature of the data in Wells Fargo’s possession and where that data comes from.
- Create “data lineage documentation,” which provides a record of how data moves across your various enterprise IT systems; and build alerting mechanisms so the compliance teams know when a change to IT systems might affect data integrity. (Those whoops you hear in the background are vendors like Workiva jumping for joy at the prospect of bidding on a project like this.)
We could go on from there, but you get the basic idea: Wells needs to develop and implement strong data integrity controls, so that the AML and sanctions compliance folks can (1) trust the enterprise data they see; and (2) trust that when enterprise IT systems change in some way, the compliance team will know about that change and still be able to get updated data flows as necessary.
If any single theme emerges from these promises, it’s that a successful compliance program — foremost for banks, but for all companies, really — now relies so much on a mastery of technology and data systems.
It’s about validating data, applying rules to automated systems, assuring that technology changes in the First Line don’t blow up compliance operations in the Second Line, understanding how data originates in your enterprise and then how it flows around after that, and so forth.
So when I argued a few weeks ago that chief compliance officers don’t need law degrees — well, this is why. Because compliance at the corporate scale depends on technology and data management, more than it depends on knowledge of the law. You can always call outside counsel to help you with the law.
But if you don’t know how your systems move information around your enterprise, lord help you.