“Model development is not a straightforward or routine technical process.”

Collaboration between functions is vital in designing appropriate model structures. Effective design and output is dependent on the selection of appropriate inputs, rules, thresholds, and controls, by model developers, users, IT and, AML risk and compliance personnel.

Due to the unique AML risk profiles and business requirements of every organisation, each model should be tailored to the specific requirements of each individual company.

Both regulatory and business requirements must be factored into model development. For example, for suspicious-activity monitoring, an organisation may outline the transaction types and the parameters that could trigger a rule for further investigation.

Your company should remain aware of its AML models’ limitations. Limitations might be found in the inputs, processing, or output, and should be documented and evaluated.

Action plans should be developed, and executed using a risk-based approach to enhance the AML models and ensure they are fit for purpose. It is good practice to test new or replacement models on subsets of customers, accounts, and transactions before they are rolled out across the business. This will allow you to remove inefficiencies in design, limit operational impact, or reduce implementation risk.

The 5 Components
We have found that the organisations that have adopted the five important components displayed in the exhibit below have AML models that are fit for their intended purpose, tailored to specific business needs and risks, and monitored on an ongoing basis.

Source: Crowe Horwath LLP analysis

1. Model definition and requirements. Organisations must define the purpose, requirements, and areas of intended use of each AML model.

2. Model design. Model design establishes a model structure expected to mitigate known customer, account, and transaction risks. Organisations should clearly define business rules, thresholds, and processes that align the model with regulatory and business requirements. This will allow management to document and evaluate the design of the model against those requirements.
Model inputs must be relevant, complete, and accurate, and timing requirements for the data feed must be clearly defined. For example, sophisticated anti-money laundering transaction monitoring systems use algorithms to review and flag transactions are potentially unusual or suspicious. These systems may expect data feeds on a daily basis due to the importance of timely identification of such activity.

3. Data management. Data is the primary input to an AML model and must be managed appropriately. Management must validate that input data is suitable, accurate, complete, and accessible.
Signs of poor data management include:
– Logic errors that produce inaccurate output
– Absence of data attributes from legacy systems designed for specific business functions without regard for the purpose of the model
– File loading errors and timing issues
– Application of logic or methodology that is not aligned to the organisation’s business model or risk profile
– Inability to isolate or source all necessary data

4. Analysis of results. Regulators require that systemic testing plans, results, and detailed analyses be documented. Organisations should test and monitor an AML model’s effectiveness and use, as conditions and applications change. This process will for example, determine whether or not resources are being used appropriately.

5. Continuous feedback and improvement. Management need to know whether or not the AML models are working, and continually enhance the model risk management programme. Model users are in a unique position to provide feedback about results, and the rules and parameters used for monitoring risks and making decisions on an ongoing basis.

Model users have first-hand knowledge of the trends that result in false-positive or otherwise inaccurate alerts, and can inform management of the following:
– Customer attributes that contribute to elevated AML risk;
– Rules and thresholds used to set upper and lower boundaries for tracking and monitoring alerts; and
– Model elements that are hitting the mark and those that are not generating the output model users need.

Practical Application Leads to Better Results

Companies that fail to plan and execute a systematic approach to model development, implementation, and use could find themselves:
– Implementing AML models that don’t meet business and regulatory requirements
– Leaving a gap in coverage that increases exposure to regulatory risk
– Operating on assumptions that are not documented and justifiable to senior management, boards, and regulators
– Providing incorrect or incomplete data to an AML model that leads to incorrect results and decisions that have business, legal, regulatory, and reputational consequences

How confident are you that your organisation effectively develops and reviews its AML models to ensure business and regulatory requirements are met?