These tips are intended for AML practitioners and are given from a non-technical high level. Contact THE DATA INITIATIVE to learn more about the technical aspects of an AML data ecosystem.
When thinking through requirements always begin with utility – what the data is used for and how it can be further exploited down the road. If you are just thinking about data to satisfy a mandate (e.g.; transaction monitoring), you are not constructing a strategy or receiving any additional value from the requirements exercise. Strategic requirements concerning data is often the most overlooked aspect of an AML program, causing an ongoing reactionary state.
The following is a list of data sets that should not just be considered but required: laws and regulations; regulatory guidance; regulatory actions; authoritative publications; watch lists; negative news; enterprise; policies and procedures; customer; transactional; event/operational; and issues.
When it comes to sourcing data, think macro first. By macro we mean divide sourcing strategy into internal and external data source collection. Next, think acquisition or means – how you collect or acquire the data from the sources. This may involve internal methods such as tagging and reporting data or external methods such as third-party licenses, subscriptions, or manual research. Having an efficient well documented methodology is a best practice for a sourcing strategy. For most aspects of your AML program where data is applied (e.g.; transaction monitoring), this methodology is likely a requirement for testing and examination!
Organizing data can be done effectively in a number of different ways. Since we discussed sourcing in the context of internal and external, this could be a logical place to start. Next, think about the link to the functional aspect of the AML program (e.g.; programmatic or operational) would help organizationally. Another component of this organizational tree would be to link to the sub-functional aspect of the AML program (e.g.; program/policy, know your customer, watch list management, suspicious activity reporting, etc.). Data organization in this hierarchical structure can be extremely beneficial down the road as it relates to further exploitation, integration, and maintenance.
Applying the data to functional and sub-functional areas of the AML program involves support from either your analytics or technology teams in instances. This application should have a general cadence (strategic / known) where all key aspects of the AML program (program management, operations management, and technical teams) are coordinated on data deployments. Application also means where does it go and how it is used primarily.
If you reference back to the list of required data sets you should generally see those used as follows: program and policy development; training; board and oversight reporting; list screening; due diligence; suspicious activity monitoring and reporting; currency transaction reporting; risk assessments; testing; and business intelligence. There may be additional applications (e.g.; big data, machine learning, and other advancements in enabling technologies) that become apparent as you have actually applied the data strategically.
Toughest aspect of managing the data ecosystem – goal – having data that resides in a singular platform. The best practice here is to have data that is unified into a single platform to do the following: apply to programmatic and operational areas; exploit for intelligence and analysis purposes; and to leverage day-to-day as a referenceable library of knowledge. Additionally, this is where and how big data analytics can actually come to fruition.
There is one simple tip for data maintenance – schedule / calendar refresh and deployment activities and stick to it! Frequency of the schedule should be driven by the risk of not having the data in the production (use) environment. Allow for uncontrollable events to fall within the scheduling cycle instead of chasing down data reactively. Again, methodology is the key here!
The AML data ecosystem is fairly complex and often overlooked both internally and by the solutions provider landscape. This is why THE DATA INITIATIVE has undertaken the task of shedding light on the data problem and bringing to bear real solutions to solve it!