The design of an LFI’s TM program should be informed by the LFI’s risk assessment, so that TM controls are applied across the full range of risks to which the institution is exposed and enhanced scrutiny is applied to the areas of highest risk. An LFI’s risk assessment should include, at a minimum, an assessment of the customers, products and services, delivery channels, and geographic exposure presenting the greatest money laundering (“ML”), terrorist financing (“TF”), and proliferation financing (“PF”) risks, as well as the strength of the controls currently in place to mitigate these risks. The risk assessment serves a range of critical purposes, including but not limited to enabling an LFI to:

With respect to transaction monitoring specifically, the risk assessment can be used to ensure that each mode of transacting with or through the institution—domestically or internationally—is subject to a form of TM that is commensurate with its risks and is operating effectively to mitigate those risks. The risk assessment should be updated at periodic intervals (at least annually or otherwise as appropriate and justified by the required circumstances) and also upon the occurrence of “trigger events,” such as material changes in the LFI’s business or risk profile or the legal and regulatory environment.

TM can include manual monitoring processes and the use of automated and intelligence-led monitoring systems. In all cases, the appropriate type and degree of monitoring should appropriately match the ML/TF/PF risks of the institution’s customers, products and services, delivery channels, and geographic exposure, and may therefore vary across an LFI’s business lines or units, where applicable. TM programs should also be calibrated to the size, nature, and complexity of each institution. LFIs with a larger scale of operations are expected to have in place automated systems capable of handling the risks from an increased volume and variance of transactions. LFIs utilizing automated systems should perform a typology assessment to design appropriate rule- or scenario-based automated monitoring capabilities and processes. While smaller LFIs may rely on TM systems that are less automated, they should still ensure that these are appropriately executed to address the risks from their day-to-day transactional activity.

Examples of automated tools include rule- or scenario-based automated suspicious activity monitoring systems (which typically perform post-execution batch screening of transactions on a daily, weekly, monthly, and/or ad hoc schedule), automated fraud detection systems, trade surveillance systems, and automated negative news screening tools. Examples of manual tools include unusual activity or unusual transaction reporting by business-line employees (including especially, but not limited to, customer relationship managers or those otherwise in customer-facing roles), reporting of potentially suspicious activity by LFI employees (including internal whistleblower reporting), manual reviews of document-based transactions (such as documentary trade finance transactions or loans), manual negative news screening, and periodic or event-based CDD reviews.

Particularly where purely manual processes are employed, LFIs should implement appropriate training on TM policies and procedures to ensure that personnel adhere to the internal processes for identification and referral of potentially suspicious activity. LFIs should be aware of all methods of identification and should ensure that their suspicious activity monitoring program includes processes to facilitate the transfer of internal referrals to appropriate personnel for further research. Regardless of whether automated or manual processes (or a combination of the two) are used to perform TM, it is the LFI’s responsibility to demonstrate that the monitoring program is effective and appropriately risk based.

Where practicable and on a risk basis, LFIs should monitor transactions at the customer or relationship level, including across financial groups, and not only on an individual account basis, so as to obtain a complete view of a customer’s transaction profile at the institution. Holistic monitoring of customers with multiple accounts is especially important for customers assessed to be politically exposed persons or as belonging to other high-risk categories.

LFIs should have in place adequate processes to ensure that customer and transactional data feeding into their TM program (whether using manual or automated processes, or both) meets established data quality standards, that data is subject to testing and validation at risk-based intervals, and that identified data quality and completeness issues are remediated in a timely manner.

As an initial matter, LFIs should identify and document all data sources that serve as inputs into their TM program. TM data sources may include both internal customer databases, core banking or other transaction processing systems, and applicable “flat-file” databases, as well as external sources such as Society for Worldwide Interbank Financial Telecommunication (“SWIFT”) message data. Source system documentation should include the identification of a system owner or primary party responsible for overseeing the quality of source data and addressing identified data issues. Where automated TM systems are used, LFIs should institute data extraction and loading processes to ensure a complete, accurate, and fully traceable transfer of data from its source to TM systems. LFIs should also ensure that staff’s access rights to both source systems and TM systems are commensurate with their roles and responsibilities, so as to ensure that relevant staff can perform their duties effectively and that access is not extended to unauthorized persons or those no longer requiring system access.

Both prior to the initial deployment of a TM system or process and at risk-based intervals thereafter, LFIs should test and validate the integrity, accuracy, and quality of data to ensure that accurate and complete data is flowing into their TM program. Data testing and validation should typically occur at minimum every 12 to 18 months, as appropriate based on the LFI’s risk profile, and the frequency of such activities should be clearly mandated and documented in the LFI’s policies and procedures. Such testing can include data integrity checks to ensure that data is being completely and accurately captured in source systems and transmitted to TM systems, as well as the reconciliation of transaction codes across core banking and TM systems. Testing may also utilize quantitative data quality standards or benchmarks to track data quality over time and specify a threshold or range beyond which data irregularities or other data quality issues shall require corrective action.

In addition, LFIs should put in place appropriate detection controls, such as the analysis of trends observable through management information system (“MIS”) data and the generation of exception reports, to identify abnormally functioning TM rules or scenarios and ensure that any such irregularities caused by data integrity or other data quality issues are appropriately diagnosed and remediated. Where appropriate, a root cause analysis should be performed, and any findings and recommended remedial actions should be escalated to senior management to address the underlying issue in a timely manner.

LFIs should employ TM detection scenarios (or “rules”) that are designed to identify potentially suspicious or illegal transactions and elevate them for further review and investigation, as warranted. LFIs utilizing automated systems should perform a typology assessment to design appropriate rule- or scenario-based automated monitoring capabilities and processes. Transactions may be suspicious simply in virtue of their individual characteristics (such as their value, source, destination, or use of intermediaries) or because, together with other transactions, they form a pattern that diverges from expected or historical transactional activity or may otherwise be indicative of illicit activity, including the evasion of reporting or recordkeeping requirements.

TM rules may be automated or manual and should employ value and other thresholds and parameters that take into account the specific risks and contexts of the institution, as identified in the financial crimes risk assessment, and the specific product or service and customer type involved in the transaction. To this end, LFIs should perform risk-based customer and product segmentation, so that rule parameters and thresholds are appropriately calibrated to the type of activity subject to TM. LFIs with larger transaction volumes should consider employing the use of statistical tools or methods such as above-the-line and below-the-line testing, which involves increasing and decreasing the predetermined thresholds of TM rules in a testing environment and measuring the resulting output, to better fine-tune their calibrations and reduce the volume of false-positive alerts.

In order to identify patterns of potentially suspicious or illegal activity spanning multiple transactions, LFIs should group individual TM parameters and thresholds into multi-factor risk scenarios in order to more precisely target transaction patterns and behaviors consistent with known illicit financing typologies. Key typologies and associated indicators of relevance in the context of the UAE published by the FIU are included in the CBUAE’s Guidance for LFIs on Suspicious Transaction Reporting.⁴ The use of scenarios should not be limited to LFIs with automated transaction monitoring systems, as smaller institutions with less-automated systems can and should apply the same logic in training and guiding their staff to detect these more complex risks. However, LFIs with a larger scale of operations are expected to have in place automated systems capable of handling the risks from an increased volume and variance of transactions. In all cases, LFIs should maintain documentation that articulates the institution’s current detection scenarios and their underlying assumptions, parameters, and thresholds.

Where automated systems are employed, LFIs should perform pre-implementation testing of TM rules and systems, using historical transaction data as appropriate. Such testing should include system integration testing to ensure compatibility of the TM system with source systems and other AML/CFT compliance infrastructure and user acceptance testing to ensure that the system performs as anticipated in the operating environment. Material data mapping, transaction coding, and other data quality issues, as well as irregularities in TM model performance and outputs, identified through pre-implementation testing should be prioritized for remediation and subject to re-testing prior to the deployment of a TM system.

⁴ Available at https://www.centralbank.ae/en/cbuae-amlcft.

Consistent with a risk-based approach, LFIs may consider assigning risk-weighted scores to TM alerts in order to prioritize higher-risk alerts for expedited review. LFIs may opt to assign a higher risk score, and thus to prioritize for review and investigations, transactions that violate individual TM rules corresponding with especially heightened risks (based on the risk profile and risk appetite of the institution) as well as transactions identified as violating multiple TM rules. LFIs with larger TM alert review and investigation teams may likewise opt to allocate higher-scoring alerts to more senior investigators or those with specialized expertise in certain risk areas. In such a scenario, non-high scoring alerts could then be allocated to the staff using a “round robin” or any other technique in order to ensure a balanced and efficient distribution of alerts among staff. Although alert scoring may be used to achieve a risk-based prioritization and allocation of manually generated TM alerts, such processes may be especially useful for LFIs faced with a high volume of alerts produced by automated TM systems.

LFIs should document and track TM outputs in order to identify and address any technical or operational issues and understand key risks or trends over time. Irregularities in TM system performance, including significant changes in the productivity of TM rules over time, may be indicative of underlying data quality or data integrity issues or of the need to recalibrate rule thresholds or parameters. Identified data quality or integrity issues should be reported back to designated data or owners, and apparent rule calibration issues (such as unproductive rules or those producing excessive volumes of false positive alerts) should be reported back to model owners for tuning and optimization. Where TM outcomes analysis reveals that certain transaction types or patterns are repeatedly flagged by the TM system and then consistently cleared as false positives by TM investigators, the LFI may consider employing a risk-based suppression logic or other “whitelisting” process to prevent the generation of alerts on activity repeatedly deemed not to be suspicious. Such methods, however, should not be applied to higher-risk customer or transaction types and should be carefully monitored and subject to periodic and event-driven testing, tuning, and validation, as described below.

In addition, LFIs should ensure that senior management is regularly updated on the performance and output of their TM program, including through the provision of metrics, trends, and other MIS reporting generated by TM systems or produced by TM alert review and investigation teams. Such reporting may include an analysis of the number of alerts produced by each TM rule and the proportion of such alerts that are cleared as false positives, that require further investigation, and that ultimately result in the filing of an STR/SAR. TM-related reporting and analysis should feed back into an LFI’s financial crimes risk assessment, and LFI management should use this information to ensure that the institution’s customers and transaction remain within the LFI’s risk appetite and that activity exceeding its risk appetite is addressed through appropriate risk mitigation measures, including but not limited to the use of account- or customer-based risk markers and/or activity, product, or service restrictions.

On a periodic basis and in the event of material system output or operational irregularities, LFIs should reassess the functionality of TM systems and processes, including the continued relevancy of detection scenarios and assumptions and the calibration of rule threshold values and parameters. As with pre-implementation testing, post-implementation testing should include checks for system integration, data quality, and operational functionality, and should additionally include back-testing of TM rules to ensure that they remain current and effective in targeting riskier transactions and activity. Any proposed tuning or adjustment to TM rules, particularly material adjustments, should be subject to pre-implementation testing using sample or historical data to ensure the proper functioning of the new or revised rules, and should be reflected in updated TM documentation.

TM model testing and validation should be performed by individuals with sufficient expertise and appropriate level of independence from the model’s development and implementation. Generally, validation should be done by people who are not responsible for the development or use of the TM model and do not have a stake in whether a model is determined to be valid. Independence may be supported by the separation of reporting lines (as where model validation is performed by an internal audit department as part of independent testing of the AML/CFT program) or by the engagement of an external party not responsible for model development or use. As a practical matter, some validation work may be most effectively done by model developers and users; it is essential, however, that such validation work be subject to critical review by an independent party, who should conduct additional activities to ensure proper validation. All model validation activities and identified issues should be clearly documented, and management should take prompt action to address model issues.