Financial institutions rely heavily on the use of automated technology to detect unusual or suspicious activity. Notwithstanding the sizeable investments that many companies have made to implement and upgrade transaction monitoring systems, the need to validate transaction monitoring systems to ensure they are effective, comprehensive, and commensurate with organizations' AML risks remains a common theme in anti-money laundering (AML) enforcement actions.

From a software implementation perspective, installing an AML transaction monitoring system may seem no different from implementing any other system; however, there are specific AML risk factors that an institution should consider during the implementation. These include, among other standard considerations, issues such as identification of risk-based suspicious activity monitoring scenarios determination of initial thresholds for the identified scenarios, and a systematic threshold tuning methodology. Inadequate consideration of these factors could lead to, increased operational costs, missed reporting deadlines, a high number of false positive alerts and, most importantly, undetected suspicious activity and regulatory criticism.

At a high level, a disciplined system implementation approach for AML monitoring technology has the following advantages:

• Risk Focused Scenarios: By executing a systematic scenario selection process, the financial institution is able to select targeted scenarios tailored to the institution's AML risk profile. Implementing appropriate risk-based scenarios can improve the quality of alerts and, therefore, the efficiency of monitoring and investigation personnel.
• Deeper Understanding of Source Data and Coverage: Often AML implementation projects uncover data architecture issues with source systems or transaction codes that need to be addressed as part of the project to ensure adequate and accurate data is flowing into the AML transaction monitoring system. As a by-product of following a disciplined system implementation approach, implementers will gain an in-depth knowledge of data coverage (i.e., products, transactions, accounts) associated with the selected scenarios and, therefore, will be better prepared to answer system "metadata" related questions posed by auditors and regulators in a more confident and precise manner.
• Systematic Threshold Setting and Tuning Process: By considering the threshold setting as a part of the implementation process, a financial institution can develop a systematic tuning process which is repeatable and enables the financial institution to adjust the threshold values periodically for the selected scenarios at a risk responsive level (i.e., changes to customer base, changes to products and services, changes to transactional behaviors).
• Efficient Deployment Process: Existence of a Project Management Office (PMO) promotes a clear co-ordination amongst various teams responsible for a problem-free deployment of the monitoring system. This co-ordination enables the project's key stakeholders to gain a clear understanding of the project state and react in timely manner to make the required changes.

Implementation Considerations:

Significant effort is needed to achieve an effective AML transaction monitoring system implementation. The following are key tasks that should be executed to implement a technology driven suspicious transaction monitoring system successfully.

1. Scenario Planning

In this phase of transaction monitoring system implementation, the scenarios eligible for deployment and the data sources supplying information to the chosen scenarios are identified. This phase involves the following considerations:

Scenario Identification: This task involves effectively mapping the risks identified in the institution's AML risk assessment and common money laundering red flags (i.e., Money Laundering and Terrorist Financing Red Flags included in the FFIEC BSA/AML Examination Manual) for the respective lines of business with current transaction monitoring controls. Mapping aids in identifying gaps in the current monitoring controls and the scenarios which are necessary to ensure adequate coverage of products/services, and mitigation of money laundering risks.

Data Source Identification: This task involves identification of various source systems which host the required data. It also involves determining processes which will be used for extracting and loading the data into the chosen monitoring system. The implementers can then create a dictionary (metadata) of data sources, and determine which products/transactions should be in scope for monitoring. The following items are key points to note for data sourcing:

• Data Availability: Is the in-scope data readily available?
• Data Quality: Has the data quality been verified? This is a critical step as inaccurate information (e.g., miscoded transactions) can lead to skewed data analyses and undesired/inaccurate results. For example, when designing scenarios to capture wires flowing to high-risk jurisdictions, it is imperative country identifiers are present and that country codes/values are accurate.
• Data Refresh Rate: How often is the data refreshed?
• Data Volume: Has the current volume of data and potential scalability needs been determined? Data volume must be supportable by existing hardware infrastructure "as-is" or additional hardware resources must be identified.

Scenario Development: This task comprises translating the functional specifications of each monitoring scenario into a deployable module customized for the chosen transaction monitoring system. Typically, this task is executed by the vendor of the monitoring system but the institution may choose to design code and test the scenarios itself. In addition, the institution may desire customized scenarios to cover adequately money laundering risks specific to the institution.

2. Threshold Setting

In this phase, the limits for executing the identified scenarios are identified. Listed below are key subtasks that should be undertaken to determine initial thresholds as well as an approach for ongoing tuning of scenarios.

Customer Segmentation: This task involves applying various data analysis techniques to the in-scope data to determine the number and type of the customer segments that can be deployed in the system. Successful execution of this step enables the implementation team to determine appropriate thresholds which are customized to the behavior exhibited by the respective customer segment rather than using a single threshold for the entire customer base.

Initial Threshold Setting: In this step, advanced statistical analysis is used to determine effective threshold values for a given scenario.. The threshold setting exercise should be performed for each customer segment and risk level, which means there may be multiple thresholds for a given scenario.

Threshold Tuning: Prior to going live with the thresholds determined in the initial threshold setting exercise, a dry run should be performed to generate alerts that can be investigated in the test environment. The investigation of these alerts can provide insight into the quality of alerts that can be expected in the production environment. This provides an opportunity to perform further threshold tuning, if warranted, before deploying the selected thresholds in production.

Significant effort is needed to achieve an effective AML transaction monitoring system implementation

Documenting Tuning Methodology and Rationale: Developing and maintaining proper documentation of any and all changes made to thresholds, including final tuning adjustments, are imperative to evidence the rationale and execution of the defined methodology and to provide a foundation for future tuning.

3. Deployment

Deployment activities are executed throughout the life cycle of the project and include various types of tasks. The following highlights two: Testing and Production Deployment.

Testing, Testing, and More Testing: Testing is integral to a traditional software development cycle, which includes dedicated testing phases, such as System Integration Testing (SIT) and User Acceptance Testing (UAT). Before the monitoring system is deployed in production, the in-scope monitoring functionality should be subjected to a rigorous SIT and UAT testing cycles. Resulting defects, depending on their severity, are either fixed or added to the defect log which can be referenced as part of future system deployments.

Production Deployment: After a successful testing cycle, the software components are targeted for deployment in the production environment. Typically, in this phase, the software change request is raised and approvals are received from key stakeholders before the software is deployed in production. Simultaneously, software should be deployed in a contingency environment also in order to meet the system disaster recovery requirements.

4. Project Management Office (PMO)

Project Management is an overarching phase which spans from the project inception to the project closeout. The PMO comprises of Project Planning, Resource Management and Change Management aspects of system implementation.

Project Planning: This task requires creation of project plans by taking into consideration the people, resource constraints and level of effort required to implement the chosen scenarios. If the project gets too complex due to software codebase, numerous dependencies etc. a multiphase deployment plan may be required.

Resource/Financial Management: This task involves understanding and effectively managing the constraints arising due to people and process resources, by developing and closely tracking a project budget and escalating any issues to the key stakeholders in a timely manner

Change Management: During the course of the implementation cycle, there are multiple instances where there may be a need to modify the functional, technical or business requirements. In order to manage this change effectively and ensure that the appropriate functionality is deployed in production, there must be a disciplined change management process which focuses on managing change requests, procuring required approval from key stakeholders, maintaining an open communication channel among all responsible parties and working with the technology deployment team to transition the system effectively into the production environment.

The exhibit above depicts a typical Transaction Monitoring Implementation Process.

Summary

The creation and execution of a systematic transaction monitoring system implementation plan which focuses on scenario identification, data sourcing, customer segmentation, threshold setting, and functionality testing enables the financial institution to deploy a transaction monitoring system which is effective, extensible and meets the needs of key business and technology stakeholders.

Luis Canelon, senior manager, Protiviti, Regulatory Risk Consulting, London, UK, luis.canelon@protiviti.co.uk

Carl Hatfield, director, Protiviti, Information Technology Consulting, Boston, MA, USA, carl.hatfield@protiviti.com

Chetan Shah, associate director, Protiviti, Anti-money Laundering Consulting, Charlotte, NC, USA, chetan.shah@protiviti.com