While the rules engine will be the brains of the Transaction Monitoring (TM) operation, the case management system should provide a practical, user-friendly solution. It is likely to be a high volume, high-pressure environment for the investigators with service level agreements and tight delivery schedules so having a case management system that is efficient and streamlined will be important. What follows now is a discussion of a few key areas related to the Case Management system which will need to be considered as part of vendor selection and as part of the wider project to implement the system.
Sometimes a little neglected when considering vendor offerings, being prepared with a good understanding of your workflow requirements is essential. How does your current business process work for managing Suspicious activity reports (SARs)/suspicious transaction reports (STRs) and alerts be it manual or automated? Is the process mapped? Has the process been reviewed recently to see how the process could be improved? Being armed with this level of detail at the vendor selection stage will help later on when you get to the actual build stage.
If you insist on following existing business processes rigorously by implementing lots of configuration changes to the workflow options on offer, you will open yourself up to challenges – more testing, increased project costs and time and added complications including more costs for future upgrades.
Sometimes it is the thought of the change which can be the most problematic rather than the actual new process.
With the high levels of sensitive customer data contained and accessible within the case management system, access levels and security will require some thought.
Passwords and access to the system should ideally meet your organisation’s security standards assuming there are developed protocols in place. Have you considered who in the organisation will approve access to the case management system? Who on behalf of the money laundering report office (MLRO) has that role?
IT access will also need to have the same standard of approvals in terms of access to the front end data and database side of the system. There will always be someone in IT who will have access to most or all of the data, this should be managed in line with your organisation’s security standards.
Vendor solutions should provide a neat solution which includes hierarchies within the access levels to allow for QA processes and necessary approvals and sign-offs of alerts and cases. This will need to be considered when you are looking at the case flow but ensuring the options are available at the outset will be critical. What levels of access do you need – investigator, QA manager, MLRO, etc? What levels of data should they be able to see and edit? Again, some thought will be required and ideally having the requirements mapped out even at a high level prior to vendor selection can prove invaluable.
How is your organisation structured? Are there separate business units that will need their data siloed on the system – who can have access to the data – do they have separate investigations teams and a different MLRO? No doubt there will be exceptions to the rules with the data which will cause some challenges – lack of a single customer view is a dominant issue for banks but also other anomalies can arise with customer categorisations and ownership within the organisation.
Some thought should be given to how access to employee-related alerts and cases will be managed and restricted. Does the data have the appropriate indicator denoting it as an employee record such that any alerts can be directed to a separate queue?
Two types of audit trails need to be maintained, one on the front end of the system where updates to the alerts, cases and STR/SARs are input by the investigators. With the second being in relation to IT access.
What level of activity recording do you expect to see for different processes – adding a comment or linking an alert to a case versus simply opening and reading a SAR/STR? The vendor should be able to provide full details of how the audit trail works and what actions taken will result in an audit line-entry being added. When you map the workflow as mentioned in the previous section, consider to the scenarios where you would actually need to refer to the audit trail – as part of the QA process, maybe where alerts/cases are not being processed in a timely manner, or if there is a concern about a particular case? The audit trail will confirm to you who has taken the action and what the specific action was, but do you also require a comment by the investigator to support the action. The rationale for the decision as to whether the alert/case is a true suspicion or not should be a mandatory input by the investigators.
In relation to the IT access and audit trails, this relates to access to the underlying database as there should be limited IT access to the front end of the application except possibly to support production issues. How is access to the database tracked, similarly if changes are made, how and where are these recorded? This is where the input from your internal information security and IT teams will be necessary.
Don’t forget to delete your data! Much easier said than done. The alerts, cases and disclosures, as well as the underlying transactional, account and customer information, need to be considered. In the first instance, the data retention policy needs to be agreed and timelines defined for the various types of data. For example, look at building up the set of rules for deletion – Closed alerts older than the agreed timeline can be deleted. Alerts which are linked to cases must be treated differently and the date of the case will take precedence, where the cases have then been reported in a SAR/STR different rules will apply again.
Also, consider legacy data which may have been migrated into your current system as this will likely mean there is a need to remove data off the system sooner than expected.
Work with your relevant Data or IT team to develop the plan for deleting data. What are the more complex scenarios that need to be catered for? The same applies to all AML and Screening systems in use for the organisation – define the retention timelines and agree on the plan. What are the expectations for business/AML testing and sign off throughout the process? Data retention requirements are not unique to AML so hopefully, there are developed practices within your organisation that can be straight forward to employ.
In a previous article, we did discuss how management information (MI) and reporting can help with managing day to day operational effectiveness which is important for the AML investigations areas, but also IT and management. For example, alert volumes processed per day, tracking system performance and outages, batch processing times, etc.
This level of MI will be dependent on the various workflow status’ and actions that are available for the alerts and cases and how accessible the data is for use in reports. What MI is offered as standard in the product, what is the breakdown of the data and what frequency it is available. Are there any challenges with running the reports in terms of database capacity – should the reports only be run outside of core operating hours so that there is no impact on the performance of the application for the investigators?
A further question is how will any configuration changes made to the workflow impact on the MI that is available?
How well the system responds and reacts to user input is a critical requirement. A system which is unresponsive and hangs on different pages will create an unworkable environment. There is no point investing in a state of the art AML solution if the users get frustrated and blocked from doing their job in a timely manner.
This requires IT engagement with the vendor at the outset. What are the minimum infrastructure requirements the vendor requires – how many users does that take account for. How will the system cater for a search by customer name or number or for all alerts with a certain status for example? Capacity and budget are closely linked so try to establish the requirements at the outset. It would be beneficial to speak to users and IT teams for existing clients of the vendors which sound most promising to you.
For this seemingly simple part of the TM proposition, there is still plenty to think about in relation to case management and usability of the system. This article is the tip of the iceberg but hopefully provides some useful insight as you embark on your TM solution journey.
For more information on this subject or further assistance please contact us at SQA Consulting.
