Tim White
This post is the next installment in Tim White's discussion about managing the migration from one AML transaction monitoring system to another. The first installment focused on the process of selecting a system, and avoiding vendor "pinch".
Picture this: your financial services company (FI) has made the decision to change AML/Anti-Fraud/Sanctions Transaction Monitoring Systems (System)! As the project manager, you have been tasked with a time intensive job and have much to account for between now and going live on the new system. Great, so now what?
Successful migration projects all require; planning, communication, execution and documentation. Let’s look at some of the key elements that should be incorporated into your FI’s System migration roadmap. After you have established the project roadmap you can align it with the formal timeline of milestones for the project.[1]
Start from the beginning
Review all the; reasons, goals, objectives and limitations for the migration project. Be sure each goal and objective is continually being assessed and documented during all phases of the project. Regular communications and internal reporting on the project’s progress, resources needed, and most importantly challenges, is critical. Management does not like surprises! Be sure to schedule a weekly meeting with the new System vendor and stick to it religiously.
Know Your FI
Although this may seem obvious, it is very important for the project manager to be very familiar with all aspects of your FI’s; AML/Sanctions program, including risk assessments, risk appetite, and key risk factors. Two key concepts that are sometimes less obvious, but very important are
- Identifying all of the key internal stakeholders that you will need to collaborate with and report to throughout the project, and
- Familiarity of your FI’s IT systems environment (core, teller, wire, ACH, MI, LC, loans and SWIFT).
Comparative Analysis of Source DataSource data
Regardless of the reason(s) for migrating to new a System, it is imperative that you document all aspects of both the existing and new System environments, starting with all of the source data. Document the flow of data from each of your FI’s application sources; account opening, CDD, customer information and transaction originations to the existing System. List all account and transaction source data systems and the data feeds that are utilized (specific file names that are being; Extracted, Translated and Loaded (ETL)). Next, create a glossary or index of all the source data systems transaction codes and definitions. This will be very critical particularly if your bank is migrating to a new System because of system changes in the IT/operations area of the bank (core, teller, etc.). Also, document if there are manual data inputs (some data feeds may not be automated). Additionally, detail any known data gaps as well as any workarounds in place to address these deficiencies.
Performance of the current System
Document the status of the existing System, including how effective and efficient is it or is not. Details and specifics are very important when doing this phase of the analysis. Record the version or release and build of the current System being used. Note the volumes of AML/Sanctions/Fraud; alerts, false positives, cases, CTRs and SARs (CIP, CDD & EDD). These volumes will be important baselines and benchmarks for the new System. Describe any deficiencies, systemic limitations, implications of manual inputs, data gaps and data integrity issues. In short, document all the blind spots and exposures to false negatives. Record the existing alert, case and reporting backlogs. Finally, retain copies of the data integrity audits and model validation reports from the current System.
What is the current System monitoring?
List all of the current System’s typologies, scenarios, rules, situations and activity that it is monitoring for. For example:
- Structuring,
- NAICS group analysis (Cash, Wires, ACH, ATM, MI’s),
- Wire pass-thru,
- ACH credits for private ATMs,
- High Velocity (cash, wires, ACH, ATM, MI, debit card),
- Spikes in volume and amounts (cash, wires, ACH, ATM, MI, RDC, debit card), Etc.,
- What are the common SAR themes, thresholds, etc. being reported?
- Assignment of; NAICS, risk ratings, householding links, CTRs, Phase I & IIs exemptions, SARs, OFAC white lists, private ATM owners, MRBs, NRAs’, PEPs’, Reg GG, NGOs’, etc.
Include all of the specific settings (transaction types, quantities, amounts, date ranges, etc.) and the rational for these settings. This information will be essential for querying the new vendor on how these items will be implemented within the new System and should be documented in a Service Level Agreement with the new vendor.
How the new System will realize the project goals and objectives
Document in detail the:
- Performance expectations for the new System
- How the expectations will meet or exceed all applicable regulatory expectations and the reasons and goals for the migration.
Obtain this information in writing from the new vendor. Do not forget BSA record retention requirements.
Determine if the data sources will be the same in the new System environment. Assess the new System’s information parity and any benefits or deficiencies resulting from new or missing data being queried by the new System. Identify, what additional information does the new System utilize that the current System does not and vice versa; what are the implications of these data variances? Similarly, if the data sources are not the same, what are the new data sources (core, teller, wire, etc.), is any data missing (perform a gap analysis and identify the monitoring implications).
Document the specific monitoring technology in the new System and if it is important in achieving the project’s overall goals and why. Be specific; broad labels of: rules based vs behavioral vs scenario vs statistical vs AI is not sufficient. For the new System, obtain the specific rules, parameters, scenarios and algorithms. Question and verify the information and documentation on the technology, capabilities, and settings of the new System with the vendor(s). Evaluate the methodology being used in the automated risk rating system. Comprehensive documentation from the new vendor is essential for defending your FI’s decision to migrate to the new System from the current system. Additionally, this information will greatly assist in documenting that the project was a success and met its goals and objectives.
Testing and Validation of the New System
Your FI’s testing and validation of the new System should include:
- Metrics
- A model validation, and
- A system tuning schedule
- Performing a comparative analysis of the risk assessment tools and baseline detection capabilities (AML, fraud and sanctions).
You should also create reconciling reports for the risk ratings output and reports to document variance in the monitoring output. These reports will help answer the questions: are the same items alerting? What isn’t alerting? These reports will support a detailed gap analysis to identify the new alerts that were not generated by the old system. Once the gaps are identified, determine; if or how the settings or parameters can be adjusted to address the gaps. Assess if procedures and protocols need to be changed due to the identified gaps.
Validate the original project goals for switching systems were realized, e.g. fraud capabilities, false positive reduction, improved case management, inclusion of model validation, reporting, new analytics, improved auto-clear functionality, documentation, core system compatibility, etc.
Validate that the examiners expectations as discussed and documented before the project started were achieved. Be sure to assess this before starting the migration e.g. how much flexibility\deviation is the examiner going to be accepting of?[2]
Evaluating and Reporting the Results
The final step in the process is to evaluate and report on the project; were the goals and objectives for the project met (to what degree and why)? The report should start with an executive summary. Share the report with management, auditors and examiners. Build the report around the project plan and these questions:
- What areas of; monitoring, detecting, rating, reporting, and managing were improved?
- Were any weaknesses, limitations, or omissions, identified?
- If any were identified were they one off, systemic, tiny, or critical?
- Do they simply need to be documented or must they be addressed for the new System to be effective?
- What is the plan for addressing any omissions, limitations or weaknesses?
Document, Document, Document and then sunset the legacy system!
[1] Avoiding “Vendor Pinch” when migrating to a new AML/Anti-Fraud/Sanctions Automation System, March 27, 2020
[2] Avoiding “Vendor Pinch” when migrating to a new AML/Anti-Fraud/Sanctions Automation System, March 27, 2020
%MCEPASTEBIN%