Easing the Pain of Lookbacks in Financial Crimes Compliance
Conducting a lookback of your financial institution’s transactions can be a painful and costly experience, particularly in the high-pressure context of global financial crimes, where data challenges, monitoring system effectiveness, and ever-shrinking budgets challenge every compliance officer’s daily existence. And, that’s not even getting to those bad actors who keep finding new ways to game your systems and regulators who keep urging you to do more to stop them. This industry insight addresses best practices to ease the pain of these extensive transaction reviews, which are often required by regulators when anti-money laundering (AML) monitoring and Office of Foreign Assets Control (OFAC), and other global sanctions alerting tools have been viewed as deficient.
The concept of a lookback is not unique to any risk area. Lookbacks can be valuable in determining risk and confirming compliance, whether in terms of business losses or regulatory enforcements and penalties. The concept of a lookback is not complicated. But in order to do it right you need the right people in the right places with robust data analytics tools. Depending on the size of the lookback it can take a great deal of time at substantial cost, including an army with specialists in a number of different disciplines.
‘Looking Back’ at the Past
The first lookback one of us experienced was in the insurance industry around 1991, as a new compliance officer in a large insurance company. In the 1980s, someone came up with a seriously misguided concept called vanishing premiums. The concept was rooted in a strong economy where returns on investments were at an all-time high. For a version of whole life policies, where a traditional life policy was married to an investment portfolio, investment returns were projected at current rates for the term of the policy so that premiums would “vanish” at a point in time while the life coverage would continue for the full term.
Now the problem. The economy crashed and returns went south. Insurers sent letters to policyholders telling them, guess what, you need to continue to pay your premiums. Company amortization schedules projecting covered life payments based on investment returns were declared misleading. So, we had to conduct a lookback of everything from sales and marketing materials to amortization schedules for thousands of customers. And back then, automated lookbacks were not in vogue, or rather, not possible.
Data Analytics Rule the Day
Since then, over the course of the past 20-plus years, we have worked for a number of multifaceted financial institutions (e.g., wholesale, consumer, corporate, wealth management, and broker-dealer) that required a lookback. In each case we found that data was key, no matter the type of lookback. So let’s start with data. Data is like money. If you don’t have it, there’s not much you can do.
How much complete and accurate data you have will drive how robust your lookback will be. It’s not just about the volume of data. It is about data integrity and lineage. No different than any other process rooted in data, if you have garbage feeding into your alerting system you cannot expect productive alerts or might entirely preclude the generation of some critical alerts.
All source systems that feed alerting systems have to be identified, with their data validated. It is imperative that whoever is managing this work stream not only understands the alerting system’s model logic, but also understands the type of data required for the rules to effectively generate alerts. To their detriment, financial institutions often leverage information technology specialists who have little or no AML or sanctions experience, or any background in alerting systems (e.g., model and rule logic).
Validation of the rules takes some time and requires the right people and tools to execute. This is not only important when setting the initial thresholds but also critical to ensuring a lookback is effective. Generate the new alerts in a test environment before you go into a production environment as only production environment alerts will need to be fully reviewed and dispositioned.
Be sure you take into consideration the different types of client segments and transaction risks associated with your portfolio (e.g., individual, small/large commercial, private banking). Similarly, customer risk rating attributes should also be considered in the overall process.
Management Tools Ensure Quality
Unless you’re looking at a small number of alerts, a case management tool is required. A robust end-to-end investigation process needs to be established, to detail alert clearing triage and escalation processes. This includes a quality assurance process.
Staff needs to be well-versed in investigations and suspicious activity report (SAR) requirements. This is where the rubber meets the road. Due to the size of the staff required for this part of the lookback and the limited number of experienced people available for large lookbacks, financial institutions often leverage analysts or hire companies that staff these rolls with people who have little or no experience in dispositioning AML and sanction alerts. Be careful with your staffing and who is managing it.
As you work through the test environment try to project the number of alerts you may be getting once in production. This will help in staffing the lookback team, since the last thing you want is to put yourself into a huge backlog situation that further complicates the lookback.
There should also be analysts reviewing the alerts generated in the test environment in order to provide an assessment of the effectiveness of the alerting system and its rules. This step can be used to eliminate false positives and further enhance threshold settings prior to generating alerts in production. In one lookback we experienced a high number of false positives because the firm did not fully utilize analysts to assess alerts in the test environment.
Document, Document, Document
Documentation is critical. Optimization or validation support and procedures for data mapping, rules, and fuzzy logic need to be documented and maintained. As a regulator might say, “If it is not documented, it doesn’t exist.” The staff needs to be trained so there is a consistent approach to everything it does. This is no different than your business-as-usual mode.
Tuning Day-to-Day Processes
Finally, conducting a lookback without ensuring your business-as-usual process isn’t robust is a waste of time and money; you may find yourself right back where you were. Update procedures and processes as necessary to ensure they dictate your new processes. Make sure you plan for staff needs consistent with your enhanced alerting systems. Have them shadow the lookback teams as part of their training.
Conclusion: Prevention Is the Ideal
Avoiding a lookback is a lot easier and less costly than conducting one. Failures resulting in lookbacks often occur due to budgetary constraints, poor data integrity/lineage, and inadequate alerting tools management (e.g., insufficient or incorrect rules and a lack of optimization or validation). Senior management and boards need to be educated on AML/Bank Secrecy Act (BSA) and OFAC requirements so they understand the magnitude of the risk, as well as the appropriate level of resources needed to minimize it. They may be surprised at the size of both. And hold firm on what is needed. Too many times senior management has stepped in to damage a program. We once had a senior executive tell us we had too many analysts so we should “turn down the dials” to reduce the number of alerts. Our response was “it’s not a television set.”
