Automation-AML

To Automate or Not to Automate … That is NOT the Question: An AML Perspective

Introduction

RPA-Research-Are-You-Bot-3-Ready-Adviser

Since the 1970s, the U.S. Congress has passed plentiful legislation requiring financial institutions to safeguard against individuals and/or businesses that may commit the act of money laundering. These institutions must adhere to regulations by diligently creating auditable paper trails and reporting client activity and potentially suspicious transactions. Increased regulatory fines require them to maintain costly anti-money laundering (AML) programs that have – until now – required a great deal of manual work.

These AML programs fall into two groups: know your customer (KYC) programs, which require banks to collect client information on a periodic basis, and transaction monitoring, which requires banks to analyze applicable transactions and corresponding activity within an account. Regardless of whether a financial institution employee operates within KYC and/or transaction monitoring, all business processes involved can be broken down into two steps: 1) an analyst will complete the business process, and 2) a senior and/or more experienced employee will perform a follow-up quality assurance check to ensure it is correct and compliant. This follows the central “Maker-Checker” methodology used by financial institutions to authorize information systems.

Much of the work that helps financial institutions comply with these new AML regulations has – until recently – been performed manually. Challenges include:

  • Increasing cost of compliance due to changing requirements, including steep fines for not meeting compliance.
  • Increasing headcount that is not an effective long-term strategy as individuals hired for the job do not have the necessary skillset.

The RPA Methodology

Today, many organizations are enjoying the advantages of implementing RPA to support manual functions. Presuming a financial institution’s AML processes are mature, stable and have established business rules to determine money laundering risk, implementing RPA can benefit the organization by potentially reducing headcount and/or overall cost associated with satisfying compliance requirements. However, financial institutions have been slow to adopt RPA solutions in their AML programs because of a fundamental disconnect between the desire for data-driven insights and the ability to make decisions based on those insights, which creates a constraint on satisfying compliance concerns.

Let’s explore two examples that illustrate how implementing RPA can do just that, given the right conditions.

1. Cursory Reviews to Approve a Loan

When a client applies for a loan, a financial institution typically uses an analyst to document the client’s AML risk and provide a synopsis of the findings to support the approval or denial of the loan. In these types of reviews, an analyst populates a form with corresponding AML data performing the same, repeatable processes – a perfect candidate for RPA implementation. When the financial institution deploys RPA in this context, it can use these outcomes as insights to derive tailored business rules that allow an automation to perform the low-risk reviews while routing the medium to high-risk reviews to a corresponding analyst to determine loan approval. Thus, the institution achieves the dual benefits of greater efficiency and improved insight.

However, before automating the analyst process, the institution must consider the existing business rules involved with the process. Most RPA insights will indicate this use case: “…screening systems [which can] generate thousands of duplicate alerts that are then closed by investigators using previous case closure evidence.” What this use case does not consider is that many financial institutions have business rules already “baked into” their AML processes that create an abundance of “enhanced due diligence” alerts within an account. These rules automatically deem the account to be medium to high-risk instead of providing the correct indication of low-risk. This scenario inflates a customer’s risk rating and generates false positives instead of legitimate suspicious activity and creates unnecessary work for the human workforce.

To formulate a successful, long-term automatable solution, financial institutions must consider the tuning thresholds that mitigate alerted activity based on prior history. If the thresholds established generate a greater number of false positives, these thresholds should be revised. Conversely, if the tuning thresholds generate the appropriate number of alerts that deem activity to be considered for further review, the bank should collect these data points to understand AML risk associated with approving or denying the loan. RPA can capture these data points to expedite the process by directing those medium to high-risk approvals to the human workforce while automatically approving the low-risk loans.

2. Account Reviews

All financial institutions conduct account reviews – whether proactively or in reaction to compliance requirements – by sampling a specific time period to determine if the transactions occurring within an account are legitimate. An analyst would choose a sample of these transactions and research the transactions and counterparties accordingly to determine AML risk.

The data can determine risk based on transaction trends such as customer type, product type, markets served and transaction amount. Tracing and reviewing trends to help determine AML risk allows for future RPA solutions to be implemented. The automation can leverage the trends found in the analyst reviews as business rules, perform cursory reviews on the associated transactions and counterparties and reserve the medium to high-risk cases for the human workforce.

To showcase the power of RPA, for example, let’s assume grocery store A administers 1,000 checks totaling $500,000 and grocery store B administers 10,000 checks totaling $5,000,000. After an account review, an analyst deemed these grocery stores to be low-risk. RPA can perform these reviews as well by comparing them to similar customer profiles and indicate to the analyst that certain account activity should be deemed low-risk. The analyst simply needs to perform a cursory review on counterparties to ensure the transactions between the customer and the counterparty are suitable based on industry, and the account review can be finished more efficiently as a result.

Conclusion

There is no “one size fits all” approach to implementing RPA in the AML landscape, and RPA is certainly not the sole answer to the current suite of challenges. Leveraging technology to combat money laundering in financial institutions is relatively new, and much goes into AML reviews that RPA cannot easily support, such as preparing suspicious activity reports and searching counterparties to determine the connection between an international company and a U.S.-based individual. Enterprises must consider how they use AML-specific data to make compliance decisions and allow RPA to support that journey as opposed to using RPA to make these compliance decisions. A data-driven AML program that leverages RPA creates the foundation for a successful risk-based approach toward determining AML risk that satisfies regulatory compliance concerns and adds maximum value to the process.

About the author

Kyle “KJ” Fenton leverages his prior consulting experiences and insights to help enterprises get the most out of their robotic process automation (RPA) investments. He provides documentation of all of the necessary business requirements obtained during stakeholder meetings and plays a key part in developing automations and training employees to manage them. Since joining ISG, KJ has developed demonstrations for both Automation Anywhere and Blue Prism products that showcase ISG’s point of view and capabilities. His most recent client experience involves building out two automations that handle life policy claim payment processing for a global life insurance