February 2013

AML System Design and Implementation

Aligning Regulatory, Business, and Technological Requirements
A White Paper by Brookton N. Behm, Gregory W. LeMond, and Tapan P. Shah

Audit|Tax|Advisory|Risk|Performance

Successfully implementing an antimoney-laundering (AML) system depends on more than technology alone. An effective AML initiative is one that aligns a financial institutions regulatory compliance efforts with its technology strategy and ongoing business requirements.

AML System Design and Implementation: Aligning Regulatory, Business, and Technological Requirements

As regulatory scrutiny of anti-money-laundering systems intensifies, many banks and other financial institutions are struggling to deploy technological solutions that satisfy regulators requirements in an effective way while still enabling their various lines of business to operate efficiently. The success of this effort depends on the institutions ability to balance several distinct, yet interrelated, areas of concern: technology issues, business priorities, and risk and compliance requirements, including regulatory expectations related to the use of quantitative analysis models in their risk management decision-making. Bringing all of these areas together into a seamless package can help an organization to meet regulatory requirements and improve risk management while also providing operational improvements and adding genuine value to the organization.

Trends
As part of a comprehensive effort to combat money laundering and prevent the financing of drug trafficking, terrorism, and other crimes, AML compliance continues to be a top examination priority for regulators. In response to both legislative concerns and broader economic trends, regulators are applying renewed scrutiny to compliance with the AML regulations required by the Bank Secrecy Act (BSA) and the USA PATRIOT Act. In response, many financial institutions are turning to enterprisewide information technology systems to manage and meet their regulatory compliance needs.1 Common examples of these sophisticated solutions include the following: Transaction monitoring systems, which are used to monitor all transactions for unusual or potentially suspicious activity; Customer due diligence systems, which are intended to capture customer information, create customer risk profiles, and risk-score customers for AML risk; and Complex quantitative modeling systems that are intended to profile and capture certain specific sequences of transactions that are likely to be associated with fraudulent activities. These various components are supported by a variety of AML technology solutions, all of which must operate together in order for the overall AML program to be effective, as demonstrated in Exhibit 1. The Crowe Closed-Loop Anti-Money-Laundering Program (CLAMP model) is an AML operating model for regulated financial institutions. It can be used to illustrate the interlocking nature of the multiple components of a comprehensive AML compliance program.

www.crowehorwath.com

Crowe Horwath LLP

Exhibit 1: The Crowe Closed-Loop Anti-Money-Laundering Program (CLAMP) Operating Model

Corporate Governance/Enterprise Risk Management Enterprisewide/Compliance Risk Assessment AML Risk Assessment/AML Risk

Investigations and Reporting

Program Management Policies Written Procedures

Staffing/Training

Risk-Based Customer Due Diligence

Project Execution

Suspicious-Activity Monitoring

Project Planning

Single-Customer View Data and Document Management for Retention and Audit Trails
Effective Internal Controls Monitoring/Self-Testing Independent Audit

Source: Crowe analysis Increasingly complex systems are needed to detect money laundering and keep up with regulatory expectations. This increased regulatory pressure is driving financial institutions to evaluate the effectiveness of their overall AML programs, including specific components such as transaction monitoring, customer due diligence, and case management. At the same time, both organic growth and renewed acquisition activities are adding to the complexity of many institutions compliance tasks. New products and services such as person-to-person transfers and mobile banking technology, coupled with expansion into new geographic markets, mean that AML compliance is a moving target, requiring banks to deploy increasingly broad and sophisticated technology solutions. Moreover, even after implementing advanced AML solutions, many institutions are facing renewed scrutiny as regulators return to follow up on the effectiveness of the compliance initiatives.

AML System Design and Implementation: Aligning Regulatory, Business, and Technological Requirements

Gaps
Banks efforts to address these AML regulatory concerns are complicated by a variety of factors, the most obvious being the inadequacy of many legacy technology platforms not sophisticated or flexible enough to address the changing regulatory requirements. In addition, data today is required to be both more granular and to have greater breadth than in the past, with data typically spread across the enterprise. Many of the most widely used core banking systems were not originally designed to address these requirements. While a growing number of software vendors are offering technology solutions to assist banks with AML compliance, the need to configure these sophisticated new systems to work with existing core banking systems can have a substantial impact on the total cost, speed of implementation, and overall effectiveness of such solutions. Even under the best circumstances, installing and implementing a new AML solution is a large and complex technology project. Evolving regulatory requirements can further complicate the effort, as can the competing needs and concerns of many stakeholders. Among these concerns are questions about the timing of implementation of critical functionalities, the potential impact on the institutions customer experience, and the development of the workflow and management of the new AML workload. While working to balance these competing priorities, financial institutions must also continue to manage their business-as-usual operations in a seamless manner. This means that, inevitably, there are practical limits to the resources they can devote to implementing or upgrading new AML compliance systems. These pressures all reinforce the importance of pursuing a balanced approach to addressing AML technology issues an approach that addresses the direct compliance requirements, reflects the institutions business and strategic priorities, and operates within the institutions technological strategy and environment.

The competing needs and concerns of stakeholders can complicate the installation and implementation of a new AML solution concerns such as the timing, the potential impact on customer experience, and the flow and management of the new workload.

www.crowehorwath.com

Crowe Horwath LLP

Challenges
As they work to improve their compliance with AML regulations, financial institutions must also work to meet a series of foreseeable challenges. Following are some of the specific issues that commonly arise during the implementation of AML systems in order to meet regulatory needs and gain operational efficiencies: Business requirements and risk coverage. The business requirements for the AML system must include the functional, informational, performance, and technical requirements for a typical IT system. In addition, they must include requirements arising from regulatory compliance needs. Regulatory requirements related to AML compliance are determined by performing a coverage assessment that ties the requirements to the risks the system is intended to mitigate. For example, in the case of a transaction monitoring system, the bank might determine through its coverage assessment that there is a previously unidentified need for coverage of specific risk factors or transaction types.

Data acquisition and testing. Because an AML system processes large amounts of data, data acquisition and testing for completeness, accuracy, and quality are critical. The ability to deliver quality data to the AML system is most often the limiting factor in system implementations. In fact, in our experience with working with clients, data acquisition and testing typically represent about two-thirds of the total effort and resources required to deploy an AML system. Selecting, purchasing, and deploying the technology account for a relatively small fraction of the total cost of ownership. Data and model validation. In addition to the ability to access data from a variety of sources, another critical requirement for a successful AML system implementation is spending the necessary time to validate both the data itself and the quantitative analysis models that are used. For transaction monitoring systems, the validation would be for models used to identify potentially suspicious activity. It is important to

AML System Design and Implementation: Aligning Regulatory, Business, and Technological Requirements

confirm the validity of such models before the system goes live rather than waiting to see if problems arise afterward. Failure to validate in advance is one of the most common causes of too many false positive events or coverage gaps. Coordination. In more general terms, the business units, AML compliance team, vendor, and technology teams often struggle to coordinate their requirements and work together effectively at implementing the AML system. Clear communication is important in order for the common goals of regulatory, business, and technology needs to be understood by all involved. These projects are unlike typical IT projects because there is an additional dimension to be considered regulatory compliance which often overrides other competing priorities. Evolving regulatory requirements. When banks move into new markets and lines of business, regulatory compliance challenges can multiply dramatically as new customer interfaces and relationships increase the complexity of monitoring transactions and customers. Even institutions with relatively stable growth strategies must remain vigilant as regulators priorities evolve to reflect changing

risks in the industry. The AML system must be flexible enough to address new compliance requirements that result from new markets, products, and services without the need for a complete overhaul of the system. Project management challenges. In addition to the AML-specific challenges just noted, the design, configuration, and implementation of such a system are vulnerable to all of the challenges that are inherent in any large and complex IT initiative. These include miscommunication, imprecise requirements, unclear lines of authority, cost overruns, and missed deadlines. It is important for the project management leadership of the initiative to understand the regulatory dimension of the project. A specialized AML system implementation team can reduce the risk of project failure while also freeing a banks internal resources to focus on business-as-usual matters.

www.crowehorwath.com

Crowe Horwath LLP

Exhibit 2: AML Technology Implementation Framework

Systems Inventory and Specifications

Phase 1: Analysis and Conceptual Design

Risk Assessment

System Capability Analysis Report

Coverage Assessment

Coverage Assessment (optional)

Business and Regulatory Alignment / Coordinated Technology Strategy / Program and Project Management

Source: Crowe analysis

Solutions
When analyzing the many complex tasks associated with an AML technology system launch, it can be helpful to consider the effort as two separate, yet intricately related, phases. These phases can be visualized as depicted in Exhibit 2. The first phase, analysis and conceptual design, encompasses much of the upfront planning and scoping and also serves to build organizationwide buy-in while assessing and documenting the magnitude and complexity of the effort. The second phase, implementation and configuration, involves completing all of the various activities required to implement the system. The project team for a typical AML system implementation consists of personnel from the institutions AML compliance group and lines of business as well as people from the selected software vendor. In addition, the team may include external consultants such as subject-matter experts on BSA/AML compliance.
8

Phase 2: Implementation and Configuration

AML System Design and Implementation: Aligning Regulatory, Business, and Technological Requirements

Phase One: Analysis and Conceptual Design

During this phase a top priority is to identify, capture, and document all relevant business requirements not just from a technology and business perspective, but also from a regulatory standpoint. Most of the implementation elements in this phase merit special attention, as follows:

Business Requirements Definition

The business requirements definition process addresses risk mitigation requirements contained in the organizations formal risk assessment, operational processes of the work group, regulatory requirements, and specific functionality of any systems that will be replaced. Documenting these requirements clearly helps to define what, specifically, the institution expects to derive from the system from both regulatory and operational perspectives. It is important that these requirements are carried forward and remain a viable reference throughout the project, especially when making future decisions about systems and how they will be implemented. A coverage assessment is a key input to defining the business requirements and helping to identify and prioritize current gaps. This assessment uses the initial risk assessment, along with regulatory feedback, guidelines from the Federal Financial Institutions Examination Council, and knowledge of common money-laundering trends to map both current and future risk mitigation requirements. The assessment will help to identify and prioritize current gaps in order to put a plan in place to address them.

Map/Gap Analysis
A direct follow-up to the business requirements definition and coverage assessment is a structured analysis of what features and functions are supported by either the legacy system or alternative means. The purpose of this analysis is to identify areas where coverage requirements are not supported, or where data is unavailable to support that coverage, in order to prioritize the functional requirements of the new AML system.

Selection Study
In some implementations, the buy or build decision is made at the selection study stage. In most instances, however, the decision to acquire technology from outside sources is already understood, and the critical issue at this stage is to identify, qualify, and select the appropriate vendors. At this point, it is critical to use the original business requirements definition document and the gap analysis to prioritize the requirements and drive the selection process.

Implementation Strategy and Planning

Thorough planning and vendor management, as well as active executive sponsorship at the implementation strategy and planning stage, are essential to begin the implementation on a strong foundation and achieve on-time and on-budget results. In addition, this step is used to document the process that will be used to assure continued coverage of risk during the cutover from the legacy system to the new system and to communicate the overall implementation plan to regulators.

www.crowehorwath.com

Crowe Horwath LLP

Model Development and Selection

An AML model provides a framework for defining the rules, measurements, and scoring that can alert risk managers to situations requiring additional review or investigation. The Office of the Comptroller of the Currency and the Federal Reserve Board have issued written guidance on the appropriate use of financial model risk management as an AML tool.2 In general terms, this regulatory guidance defines modeling as a quantitative method or system consisting of three components: 1. Information input, which delivers assumptions and data to the model; 2. Processing, which transforms inputs into estimates; and 3. Reporting, which translates the estimates into useful business information. Because of the complex and highly technical nature of an AML model, much of the effort is necessarily focused on design, development, testing, and implementation methodology. Inevitably, however, the effectiveness of the system is directly dependent on the accessibility, integration, and quality of the underlying data being fed to the models. In the case of most vendor transaction monitoring solutions, several potential monitoring rules or scenarios are provided to mitigate the same or similar risks. Each of these rules or scenarios typically has slightly differing data requirements. Institutions should select the rules or scenarios they plan to use based on their coverage assessment, the results of their map/gap analysis, and which results are most closely aligned with the information the banks systems are capable of providing initially. These can be enhanced or modified over time as the bank gathers any additional required data elements.

Data Integration Discovery

As noted earlier, much of the cost associated with an AML system is a function of the large amount of data involved. For this reason, it is important to spend significant time planning the data acquisition process carefully. In order to develop a high-level estimate and timeline, the project team should carry out a data discovery exercise to get an understanding of what data the AML system requires and to identify where that data is stored throughout the organization, how it is available to other systems, and what issues and challenges could be encountered when trying to bring this data together for use in the AML system. At a high level, this means the project team must be able to answer the following questions: 1. What is the source of customer information? Is it the product of demographic profiles, customer due diligence programs, or some other system? 2. What is the source of account information? How and where does the bank maintain granular detail on specific accounts? 3. What are the sources of transactional information? To find out, the base transaction information must be identified and reviewed for cash, automated clearinghouse, wire transfers, checks, credit cards, and all other types of transactions. Then the parties tied to each transaction must be identified.

10

AML System Design and Implementation: Aligning Regulatory, Business, and Technological Requirements

Phase Two: Implementation and Configuration

A number of activities must occur during this phase, including many that typically run in parallel. Some activities, such as system testing and user acceptance testing, are similar to the implementation life cycle in many IT system implementations. This section focuses on the key activities that are different for an AML system implementation.

Data Acquisition
Just as it did during the analysis and design phase, data management plays an important role in all of the activities that occur during the implementation and configuration phase. Unfortunately, management can easily underestimate the time and resources these essential data integration activities require.

Many kinds of data from multiple systems must be located, accessed, and aggregated in order to arrive at a single risk profile and comprehensive customer risk rating.
The broad categories of data required for AML systems include customer, account, and transaction data. Customer due diligence systems require reference data and data related to know your customer (KYC) and know your account (KYA) data. Information about a customers demographic profile and expected activities is often housed in multiple accountopening systems. This data from systems, as well as other sources, must be aggregated in order to arrive at a single risk profile and comprehensive customer risk rating. Transaction monitoring systems also require granular data about customers, accounts, and transaction data along with information about the counterparties. The transaction data is typically stored in the banks channel systems, with the core banking systems providing summary information. For transaction monitoring systems, the specific fields required will vary, depending on the rules or detection methodologies the bank selects. It is necessary to understand where and how all of this information is stored in the banks various information systems and how it can be brought together to provide adequate monitoring of suspicious activities. Data acquisition is typically the largest, most time-consuming, and most costly aspect of the entire implementation process. The challenges involved in this effort might seem to bear a resemblance to the challenges of implementing a banks core technology platform. Beneath this surface similarity, however, are significant differences. In addition to accessing data across a variety of systems, the AML data acquisition effort also must capture more granular data and at the same time be capable of integrating a broader data set than might exist in just a single bank system. The data discovery activity mentioned earlier provides information on the source systems that have the required information and the issues that must be addressed to bring all of the data together. Data acquisition consists of completing the field-level mapping and development of the integrations required to send the data from the different source systems to the AML system.

www.crowehorwath.com

11

Crowe Horwath LLP

Data mapping involves documenting the mapping of the source data fields to the AML system with the appropriate business or transformation rule required to convert the source data. The compliance team must be an integral part of this activity and be involved in decisions made during the data mapping that affect the output of the AML system. Developing the data integrations for a transaction monitoring system is typically done using extract, transform, and load (ETL) methodology due to the large volume of data that must be processed from the source systems to the target AML system. While custom approaches may be considered, banks ideally should use an ETL tool that inherently provides a number of functions required for a data integration of this magnitude and complexity.

Data Validation
The objective of data validation is to develop a reasonable belief that the systems being relied on for BSA/AML compliance are receiving an accurate and complete data set. Data validation is discussed in this section in the context of a transaction monitoring system. Similar steps can be considered for a customer due diligence system as well. Data validation of the AML system typically consists of five basic steps: 1. Assessing data touch points and administration. Evaluate existing documentation supporting the methodology, logic, and theory of the AML model, and compare it with the organizations AML risk assessment. In addition, evaluate the key dataintegration and data-mapping processes and documentation and take an inventory of data feeds, customer and transaction data systems, and system documentation and deployment controls. 2. Testing a selection of source transactions. Apply risk-based testing procedures to confirm that the data recorded within source systems or ledgers is appropriately captured. 3. Testing the IT interfaces between the banks core operating system and the AML system. Evaluate and test a selection of source records to verify that the transformation logic and recording in the AML application were successful. 4. Testing the interfaces among the various AML system components. Confirm that data tied to the exception reports or alerts is properly presented in the case management system. 5. Validating the detection models reporting parameters. Complete back testing procedures to confirm that the selected alerts are properly generated and reported based on the stated rules and parameters of the alerts. Transaction monitoring systems require data that is complete, accurate, and timely. Missing or inaccurate dates, codes, amounts, or account numbers must be addressed in the source systems. Regulators today often conduct their own data testing to verify the accuracy and effectiveness of monitoring systems. As regulators focus on evaluating the completeness of the underlying data that drives an institutions risk assessment and mitigation efforts, banks must be prepared to provide confirmation of the accuracy of information, including how it was validated.

12

AML System Design and Implementation: Aligning Regulatory, Business, and Technological Requirements

Business Process Design and Implementation

The output of an AML system, specifically customer due-diligence or transactionmonitoring alerts, must be reviewed by BSA/AML compliance personnel at the bank. Typically the financial intelligence unit (FIU) handles this review. It is important that the business processes appropriate for accomplishing this task are in place, with the new AML system being the enabler of these business processes. The BSA/AML compliance personnel must lead this portion of the project and work closely with other members of the project team. The typical activities include: Designing the FIU workflow processes to review the output of the AML system (potentially high-risk customers or transaction alerts). The review process might be a multistep process with deadlines associated with each of the steps. Defining the appropriate roles that will be set up to support this workflow process and the types of access that will be available to the different roles in order to perform specific functions. For example, the function of filing a suspicious activity report will not be available to all personnel in the FIU. Developing appropriate procedures to support the revised business processes and the new AML system.

Model Implementation and Tuning

AML system implementation ultimately involves implementing AML models for customer risk rating and transaction monitoring. The AML models must be verified and tuned to confirm that results are consistent with the model requirements and that controls are adequate. Model implementation includes confirming that the models being implemented generate output based on the data being passed to them. The models must then be tuned so that the model output is consistent with the risk profile of the bank. In the case of transaction monitoring systems, this activity helps the bank determine from a broader selection of models the particular models to implement. The tuning steps are necessary to reduce the noise and false positives that might otherwise be generated by the chosen models. Taking shortcuts at this stage can ultimately lead to greater system inefficiency, because the institutions limited AML resources might be focused on reviews of transactions or customer relationships that did not warrant the attention. For additional information on model implementation and tuning, please refer to the Crowe white paper and series of articles on effective AML model risk management for financial institutions.3

www.crowehorwath.com

13

Crowe Horwath LLP

Production
In order to facilitate an orderly transition from the prior system to the new system, it often is necessary that an AML systems go-live process be different from that of a traditional IT system implementation. An AML system may have a technical go-live followed by a business go-live. A technical go-live involves making all aspects of the AML system and related components ready and available from a technology perspective, including any data feeds that are enabled to provide information to the AML system. At this point, however, the AML models are not turned on as the system of record. A business go-live refers to turning on the first AML model, so that the output of the model is then reviewed by analysts in the FIU as the system of record. Additional models are then gradually turned on, in accordance with a coverage plan approved by the BSA officer. Depending on the readiness of the new AML system and current risk coverage, a technical go-live and business go-live may occur at the same time, or they may be separated by a period of time. The phased approach allows a bank to make sure that the technology environment is ready, the data feeds are exercised, and any supporting batch processes are being executed correctly prior to turning on the AML models.

Ongoing evaluation of models is necessary to confirm that results continue to provide meaningful output and that controls are adequate.

Model Validation
After the production environment has been stabilized and the AML models have been running consistently for some time, the models that were activated during the course of the implementation should be validated by a third party. Ongoing evaluation of models is necessary to confirm that results continue to provide meaningful output and that controls are adequate. The supervisory guidance on model risk management defines model validation as the set of processes and activities intended to verify that models are performing as expected, in line with their design objectives and business uses. It also identifies potential limitations and assumptions and assesses their possible impact. While the concept of validation is not new, the guidance expands the expectations for an effective validation review. The guidance from the Federal Reserve Board states, All model components inputs, processing, outputs, and reports should be subject to validation; this applies equally to models developed in-house and to those purchased from or developed by vendors or consultants. Model validation confirms that an institutions AML models are aligned with business and regulatory expectations and are properly addressing the underlying risks. For additional information on model validation, please refer to the Crowe white paper and series of articles on effective AML model risk management for financial institutions, particularly the article on model validation.4

14

AML System Design and Implementation: Aligning Regulatory, Business, and Technological Requirements

Conclusion
Deploying an AML system is a large and complex endeavor involving the alignment of regulatory, business, and technology requirements. This implementation differs from other technology projects in that there is an additional dimension to be considered: the issue of regulatory compliance, which overrides other competing priorities on a typical system implementation. For example, the project may already have a solid deadline prior to kicking off due to regulatory commitments made by the bank. Not only does the effort require the coordination of numerous internal resources, but in most instances the institution also will find it necessary to involve a variety of outside specialists, including consultants and software vendors. Each one of these groups approaches the project from a slightly different perspective, and each will bring its own preferred methodology and processes. It is essential that these diverse approaches and priorities are aligned with the institutions needs. In order to achieve this common vision and understanding in a way that supports the organizations long-term strategic plans, it is also important that the financial institutions compliance requirements and business processes drive the system implementation and integration. Financial institutions that follow a structured approach for an AML system implementation such as the one outlined in this white paper significantly increase the odds of a successful implementation that meets regulatory expectations.

www.crowehorwath.com

15

For more about ITs role in compliance, see Gregory B. Hahn and Tapan P. Shah, Using IT to Respond to Regulatory Challenges, CroweHorwathLLP white paper, September 2012, http://www.crowehorwath.com/ ContentDetails.aspx?id=5048 For the guidance, see Office of the Comptroller of the Currency, OCC 2011-12: Supervisory Guidance on Model Risk Management, April 4, 2011, www.occ.treas.gov/news-issuances/bulletins/2011/bulletin-2011-12a.pdf; and Federal Reserve System, Guidance on Model Risk Management, SR 11-7, April 4, 2011, www.federalreserve. gov/bankinforeg/srletters/sr1107.pdf John A. Epperson, Arjun Kalra, and Brookton N. Behm, Effective AML Model Risk Management for Financial Institutions: The Six Critical Components, CroweHorwathLLP white paper, August 2012, http://www.crowehorwath.com/ContentDetails.aspx?id=4889&terms=AML%20Risk%20Management Ibid; and John A. Epperson, Gary W. Lindsey, and Paul R. Osborne, Planning and Executing an Effective AML Model Risk Management Program: Model Validation, CroweHorwathLLP, December 2012, http://www.crowehorwath.com/ContentDetails.aspx?id=5584

Contact Information
Brookton Behm, CAMS, is a principal with Crowe Horwath LLP in the Grand Rapids, Mich., office. He can be reached at 616.233.5566 or brookton.behm@crowehorwath.com. Greg LeMond, CAMS, is a director with Crowe in the Chicago office. Hecan be reached at 312.899.1519 orgreg.lemond@crowehorwath.com. Tapan Shah, PMP, is with Crowe in the Chicago office. He can be reached at 630.586.5113 or tapan.shah@crowehorwath.com.

www.crowehorwath.com
When printed by Crowe Horwath LLP, this piece is printed on Mohawk Color Copy Premium, which is manufactured entirely with Green-e certified wind-generated electricity.

The Mohawk Windpower logo is a registered trademark of Mohawk Fine Papers Inc. Green-e is a registered trademark of Center for Resource Solutions. Crowe Horwath LLP is an independent member of Crowe Horwath International, a Swiss verein. Each member firm of Crowe Horwath International is a separate and independent legal entity. Crowe Horwath LLP and its affiliates are not responsible or liable for any acts or omissions of Crowe Horwath International or any other member of Crowe Horwath International and specifically disclaim any and all responsibility or liability for acts or omissions of Crowe Horwath International or any other Crowe Horwath International member. Accountancy services in Kansas and North Carolina are rendered by Crowe Chizek LLP, which is not a member of Crowe Horwath International. This material is for informational purposes only and should not be construed as financial or legal advice. Please seek guidance specific to your organization from qualified advisers in your jurisdiction. 2013 Crowe Horwath LLP RISK13902