In part one of this article, Implementation of AML Software: “The Keys to Success” Part 1 of 2, we discussed evaluating your needs, vendors, budget and having a good well thought-out plan, including a Business Requirement Document (BRD) and Functional Design Document (FDD). We covered some, not all, iterations that can change your needs or focus, but overall, how important each step is imperative to your efficiency in both expense and workflow. Now we’ll discuss the technical and business implementation of anti-money laundering (AML) software, testing, production cutover, and post-implementation.
Technical Implementation:
When choosing the right hardware for the job everyone asks the vendor for those specifications early on, quite often long before the Business Requirement Document (BRD) and Functional Design Document (FDD). The only way to know this is to create the BRD and FDD. You can ask the vendor to send you sample environments and this may help, but it is best to wait until after the BRD and FDD are done properly to evaluate the hardware and some of the software requirements.
When determining the infrastructure around the interfaces several things need to be considered; such as: Who creates them? Do they already exist, and do they need to be customized for me? How much is this going to cost me now, and moving forward? These questions are important considerations for any IT manager. Unfortunately, this is a little bit of a catch 22.
The only way to know what the interfaces need to do specifically is after the creation of the BRD and FDD. Should you build your own interface or buy one and customize it? Generally it is best to buy them. The biggest questions here that will dictate how much customization is required is: how newly created the interfaces and how differently you may use the source system.
More often than not, I find that most institutions prefer to buy from their core system vendor and not the AML software vendor. There are advantages and disadvantages to this, see figure one. The advantages to using your core software vendor is that if they need to alter the banking system interfaces in some way they will often do it automatically. They also tend to be large companies that have been and will be around for some time. The disadvantages to using your core system vendor is that they tend to do only what you ask and don’t really have a commitment to anti-money laundering (AML) compliance. Further, they can be more costly and changes take much longer. On the flip side, if you use your AML software vendor for the interfaces, the advantages are that the interface costs tend to be cheaper, the duration of development tends to be much shorter and they have of a commitment toward AML compliance, which has residual benefits. However, some disadvantages might be that they may be a small company like many AML Software vendors, so they might not have the stability as a larger, more established core banking software vendor.
Figure 1, the Advantages and Disadvantages of using your Core system Vendor Vs. Anti-Money Laundering Software Vendor.
Next: controls, controls and more controls. You hear from managers, especially IT “we need controls”; in this case it is absolutely true. You can set up the best anti-money laundering (AML) system in the world, but in time, with poor controls you will find yourself in a pickle real fast. This is a common problem within the industry. Everyone sets up controls, but there tend to be plenty of gaps too. When implementing AML software be sure to write a procedure to ensure these controls are understood, evaluate all the control points, and be sure to monitor them regularly.
Training for technical users is different than for business users because they will need to train on tasks such as adding users, interface data reconciliation, server logs and so on. However, training for the technical users or end users should be thorough and repetitive. The bulk of the training should be done up front when implementing the software; however, repetition is highly effective. The entire implementation is essentially training, see figure two. Place your training sessions throughout the project and base the topic on a need to know basis so that you are not overwhelming your users. When scheduling training during annual upgrades, you must decide whether or not to do the full training or just incremental training. A good rule of thumb is to alternate with incremental and full training every other year. The full training is a good refresher and can allow for your users to learn more about the system, break bad habits and create new ones.
Figure 2, an example training schedule.
Business Implementation:
As with the IT procedures, compliance procedures are very important. This is typically the first thing the auditors ask for so be sure your procedures are detailed and they should give you a sense of how to make each decision. This is especially important when dealing with less experienced or lower level positions. Also, be sure to update procedures each year when you upgrade the system.
Data correction is an arduous process. It needs to be done in nearly all institutions to better your compliance position. Data issues appear in several ways. The first consideration in data is what meets the mandatory/required in order for profiling and rules/scenarios to trigger cases as expected. The second is to create a more comprehensive compliance program. This data needs to be accurate, complete and meaningful. The third is the nice to have data that saves you in operational efficiency, which is data that saves time by preventing the need to go to another system for additional information. The first data requirement needs to be done in Stage 1 and the later two generally end up in Stage 2 of the AML implementation or part of the ongoing risk mitigation strategy.
As previously said, business user training has a different focus from technical users. Business users will be trained on case review, rule parameters, profiling, reporting and so on. Training for the business staff also needs to be repetitive. Similarly, it’s important to only give the users the need to know information as to not overwhelm them with too much at once. A good idea is to strategically place the training sessions throughout the project. Basically, you should have a concept level training in the beginning so they can make educated decisions during the feature design stages; a full training in the middle of implementation; and a refresher training just before you go live. See figure two, above, for an example training schedule. The training just before going live is sometimes coincides with writing the procedures of that institution. A parting thought in regards to training is ensuring the trainer goes beyond on what button to push, but explain why and when to hit that button. Many systems are robust and are not intended to use all features, but more of a combination of features that work properly together to accomplish the task. We find that often a trainer does not explain how to use or when to use a feature, and this can be very important.
Testing:
Testing proves all of your hard work. There are many types of testing. Unit Testing (UT) is used for testing the interfaces one unit at a time – each interface at a code level. Systems Integration Testing (SIT) is an end-to-end test that proves that the entire IT infrastructure functions as designed. User Acceptance Testing (UAT) is the most well known and is also the most important for a number of reasons. Like the other phases of testing it proves that the system functions as designed, but it has the added benefit of allowing you to optimize the system before you move to production. This tuning can be critical to ongoing compliance operations. It is very common that when an institution goes from a manual anti-money laundering monitoring solution to an automated, the case volume increases. I find testing is often undervalued either by limiting the scope or the documentation. Also, it is often missing key components such as negative testing, which is generally due to a lack of understanding of formalized testing.
Figure 3, Types of Testing.
Production Cutover:
There are many steps in cutting over to production depending on your server architecture. More than likely what was the original configuration based on the FDD will change slightly after testing. This change is a healthy change to the project because it allows for corrections and optimization. You will need to make all of the configuration changes before cutting over. As opposed to the more limited data you may have loaded for UAT, you may now need to load all of the historical data as defined by your requirement documents and this may take some time. A cutover plan can assist greatly, especially if you have a large institution where there are many areas of IT involved. Part of this plan should be a roll back procedure and there should be break points for a go/no-go decision. Effectively, when you flip the switch, all logs and the database should start tracking the usage of the system for audit reasons for the first time. This means you may need to back up and clean out the system if the production machine was used for UAT. You will also need to turn on interface feeds and such from other systems. It is best to demonstrate in writing that the cutover plan was followed and was successful so that management can give it their blessing (sign-off). Finally, all items pertaining to the project should be archived for later auditing. This should include BRD, FDD, status reports, testing documents and each update to the project plan.
Post Implementation:
The institution should perform an anti-money laundering Independent Verification and Validation (IVV) or Model Validation three to six months after production cutover; however, it should be independent of the vendor who implemented your system. Based on this report, the institution should be able to determine what they have done and what is left to be done with confidence, by comparing the plan to the IVV or model validation report. Keep in mind; you should be budgeting for upgrades to keep up with the industry and regulations. It might also be a good idea to seek help from the vendor and AML professionals to continue to improve, and bring an outside/objective influence to your AML program. Remember, incremental improvements are much more cost effective in the long run.
Conclusion:
The intention of this article was to provide high level guidance to the process of implementing anti-money laundering software to compliance officers and non technical compliance professionals. In part one, we covered evaluating your needs, vendors, budget and having a good well thought-out plan, including a Business Requirement Document (BRD) and Functional Design Document (FDD). In part two, we covered the technical and business implementation of anti-money laundering (AML) software, testing, production cutover, and post-implementation. Hopefully this has given you a better understanding of what is necessary to consider when implementing your anti-money laundering software.
If you would like to know more about ARC Risk and Compliance, and our approach to the RFP/RFI process; assistance in creating a BRD or FDD; or the implementation, upgrade or conversion of your AML software, please contact us.
