Is your Transaction Monitoring system fit for purpose?

AML

5 Aug

Transaction monitoring (TM) is a critical control to support the identification and reporting of money laundering and terrorist financing. Smaller firms with limited volumes of customers and transactions may monitor transactions manually, but most organisations of scale use automated TM (typically using a vendor solution) to generate alerts for investigation when unusual and potentially suspicious behaviour is observed. In either case, monitoring needs to be appropriate for the scale, nature and complexity of the underlying business.

The FCA have issued several fines historically for compliance failures related fully or in part to TM, with the average fine of £127 million highlighting the importance of having an effective TM capability. Fines have included £64M for HSBC, £265M for NatWest, £163M for Deutsche Bank, £38M for Commerzbank and £108M for Santander.

Malverde have supported many clients to design, implement and optimise their TM systems. Through this experience we have developed the following list to support clients in reviewing the suitability of their system to manage their unique risks and avoid large inefficiencies and costs.

The architecture diagram below provides a simplified view of the key inputs, outputs and components of a TM system. The numbered items are explained in further detail in the table that follows.

*Simplified architecture diagram of a TM system (numbers reference the sections below)*

1 - Risk Identification

FCA observation	Question / consideration	Explanation
"Generally, the quality of the Business Wide Risk Assessments (BWRAs) we have reviewed is poor. In some instances, there is insufficient detail on the financial crime risks to which the business is exposed. In other instances, firms have considered and documented the inherent risks but have not adequately evidenced their assessment of the strength of the mitigating controls or recorded their rationale to support conclusions drawn on the level of residual risk to which the firm is exposed."	Have common typologies and methods of laundering money been researched and reviewed to assess the likelihood that they will occur within your business?	Use industry and regulatory guidance (such as Thematic Reviews) to understand how money can be laundered through the financial system.
	Has a list of 'red flags' and key risk indicators (i.e. evidence of a broader money laundering (ML) or terrorist financing (TF) typology) been compiled to inform what needs to be identified through transaction monitoring?	Each typology should be broken down into the observable red flags or KRIs that are associated with it to enable it to be detected.
	Have the ways in which your products could be used to facilitate money laundering or terrorist financing been evaluated? Are the risks clearly understood and documented?	The features of each product should be evaluated to understand how products can be exploited for the purposes of ML or TF, and which typologies could be enacted through each product - e.g. cash deposits, international wires, third party payments.
	Can your typologies and corresponding red flags/KRIs be clearly mapped to your TM rules and scenarios to provide a clear understanding of risk coverage?	Once scenarios have been defined, there should be a clear mapping between typologies and red flags and finally to the scenario(s) that provide risk mitigation.
	Are any ML & TF risks that are not mitigated through TM clearly understood, and are alternative controls in place to manage these risks?	Not all ML & TF risks will be best mitigated through automated TM - e.g. some indicators of modern slavery are hard to automatically identify. Alternative controls should be created for these risks where appropriate, with the risk and control mapping being documented in your Risk and Control Self-Assessment (RCSA).

2 - Data

    
            FCA observation
            Question / consideration
            Explanation 
        
            "Some firms fail to undertake regular appropriate assessments of the data feeds and data integrity of the systems. In some circumstances, this can lead to transactional activity from whole business lines, products or customers being excluded from the monitoring systems, in error."
            Is up to date information on expected customer behaviour available? For example, income/salary and occupation for individuals, revenue and nature of business for organisations.
            KYC/KYB information that captures expected behaviour is hugely important in enabling TM to determine unusual behaviour for specific customers, and can be a very beneficial input for the segmentation of customers.
        
            Are there automated reconciliation checks between the source system data feed records and the records loaded into the TM platform to ensure completeness of data loads?
            Dropped records can result in an incomplete view of a customers' activity and casts doubt on the integrity and effectiveness of the entire TM system.
        
            Is the scope of source systems feeding the TM platform fully understood and does this provide coverage for all of the customers and accounts that require monitoring?
            Obtaining a holistic view of customers' activity is critical for monitoring to be effective. Often disparate core banking systems are used for different products - it is key that transactions across all products are fed to the TM system.
        
            Are internal transactions (where both the originator and beneficiary accounts are both within your bank) monitored and can these types of transactions be differentiated from external transactions?
            Internal transactions between a customer's own accounts or between different customers that both exist within your bank can be required for building certain profiles. Often these types of transactions can be overlooked, providing an incomplete picture to the TM system.
        
Is the breadth of data provided to the TM system sufficient to enable both alert generation and alert investigation?  Often a broader set of information is required to investigate an alert, inefficiencies arise when investigators are required to use other systems to obtain this data.
            Vendor data interface specifications often define a 'minimum viable product' or MVP, which is the minimum breath of data required for the out of the box scenarios to execute and generate alerts. In cases where an MVP or close to MVP data set is provided, there are significant knock on effects for both the creation of bespoke scenarios as well as alert investigation, with the data required to run a scenario or to investigate an alert respectively unavailable.
        
Are all transactions in the TM system mapped to an appropriate transaction type code (e.g. CASH, WIRE, CHEQUE, etc.)? Is an alert generated if a transaction cannot be mapped to a target transaction type code using the existing mapping table? Is the mapping table from source to target updated when a new business transaction code is introduced?
            Scenario logic selects subsets of transactions using the product transaction type codes (for example, cash based scenarios selecting only CASH transactions). It is extremely important that source transactions are mapped appropriately to the products transaction type codes during ETL, else scenarios will not work as intended. In the NatWest Fowler Oldfield case, a significant amount of cash went unidentified as a result if incorrect transaction type mapping.
        
Is an exception report generated for each data load? This report should highlight any warnings (e.g. formatting exceptions, key constraint exceptions) and any issues (e.g. unloaded transaction records) to enable further analysis.
            The content and structure of data feeds vary significantly over time. Often new products or categorisations are introduced upstream, without any consideration for how this may effect downstream processes such as TM. As such, it is very important to ensure that each data load completes successfully with no dropped records, and that the format for each data field is compatible with the TM system.
        
Are historical profiles up to date for all existing customers (typically 12 months of historical transaction data is required [where available] to build a profile for each focal entity)?
            Many TM scenarios compare activity to historical profiles that are unique to each customer. These profiles are automatically built and maintained in BAU as the TM system operates, however these profiles need to be 'back loaded' prior to initial go live of the system.

FCA observation	Question / consideration	Explanation
"Some firms fail to undertake regular appropriate assessments of the data feeds and data integrity of the systems. In some circumstances, this can lead to transactional activity from whole business lines, products or customers being excluded from the monitoring systems, in error."	Is up to date information on expected customer behaviour available? For example, income/salary and occupation for individuals, revenue and nature of business for organisations.	KYC/KYB information that captures expected behaviour is hugely important in enabling TM to determine unusual behaviour for specific customers, and can be a very beneficial input for the segmentation of customers.
Are there automated reconciliation checks between the source system data feed records and the records loaded into the TM platform to ensure completeness of data loads?	Dropped records can result in an incomplete view of a customers' activity and casts doubt on the integrity and effectiveness of the entire TM system.
Is the scope of source systems feeding the TM platform fully understood and does this provide coverage for all of the customers and accounts that require monitoring?	Obtaining a holistic view of customers' activity is critical for monitoring to be effective. Often disparate core banking systems are used for different products - it is key that transactions across all products are fed to the TM system.
Are internal transactions (where both the originator and beneficiary accounts are both within your bank) monitored and can these types of transactions be differentiated from external transactions?	Internal transactions between a customer's own accounts or between different customers that both exist within your bank can be required for building certain profiles. Often these types of transactions can be overlooked, providing an incomplete picture to the TM system.
Is the breadth of data provided to the TM system sufficient to enable both alert generation and alert investigation? Often a broader set of information is required to investigate an alert, inefficiencies arise when investigators are required to use other systems to obtain this data.	Vendor data interface specifications often define a 'minimum viable product' or MVP, which is the minimum breath of data required for the out of the box scenarios to execute and generate alerts. In cases where an MVP or close to MVP data set is provided, there are significant knock on effects for both the creation of bespoke scenarios as well as alert investigation, with the data required to run a scenario or to investigate an alert respectively unavailable.
Are all transactions in the TM system mapped to an appropriate transaction type code (e.g. CASH, WIRE, CHEQUE, etc.)? Is an alert generated if a transaction cannot be mapped to a target transaction type code using the existing mapping table? Is the mapping table from source to target updated when a new business transaction code is introduced?	Scenario logic selects subsets of transactions using the product transaction type codes (for example, cash based scenarios selecting only CASH transactions). It is extremely important that source transactions are mapped appropriately to the products transaction type codes during ETL, else scenarios will not work as intended. In the NatWest Fowler Oldfield case, a significant amount of cash went unidentified as a result if incorrect transaction type mapping.
Is an exception report generated for each data load? This report should highlight any warnings (e.g. formatting exceptions, key constraint exceptions) and any issues (e.g. unloaded transaction records) to enable further analysis.	The content and structure of data feeds vary significantly over time. Often new products or categorisations are introduced upstream, without any consideration for how this may effect downstream processes such as TM. As such, it is very important to ensure that each data load completes successfully with no dropped records, and that the format for each data field is compatible with the TM system.
Are historical profiles up to date for all existing customers (typically 12 months of historical transaction data is required [where available] to build a profile for each focal entity)?	Many TM scenarios compare activity to historical profiles that are unique to each customer. These profiles are automatically built and maintained in BAU as the TM system operates, however these profiles need to be 'back loaded' prior to initial go live of the system.

3 - Segmentation

    
            Question / consideration
            Explanation 
        
            Do you use segmentation to facilitate the use of different thresholds for groups of customers that are expected to behave differently? 
            Segmentation is critical where TM is used to monitor varying types of customers, or even similar types of customers with large wealth ranges or expected activity due to their circumstances.
        
            Do you have a documented methodology that was executed to create your customer segments?
            Regulators expect to see documented rationale as to how customer segments were chosen for TM to give confidence they are appropriate.
		
Are customers segmented into groups based on their expected behaviour? What key factor of expected behaviour has been used for segmentation (e.g. aggregate credit value per month)?
            Scenarios will focus on different facets of customers' behaviour, for example monthly volume of credit transactions, vs monthly value of credit transactions. These facets may not necessarily correlate. This poses a challenge for segmentation. Unless multiple segmentations are used (with scenarios then selecting the most appropriate segmentation to use according to the behaviour they are seeking to identify), a single facet of customer behaviour must be selected. This choice of variable should be driven by the most common variable used across all required scenarios.
        
Has 'bottom-up' segmentation been performed using historical transaction records to validate that segments are homogenous and mutually exclusive?
            Bottom-up segmentation uses historical transaction data to model the spread of customer behaviour within each segment. It helps to determine the homogeneity of each segment, as well as allow segments to be compared and contrasted to ensure they are sufficiently different from one another.
        
Can customers move between segments as their information and/or transactional behaviour changes? Is this automatic?
            A customer's segment is governed by KYC/KYB data (i.e. expectation of behaviour), rather than transactional data (i.e. actual behaviour). This data can change however, and it is important to ensure that processes are in place to update a customer's segment when needed. Any automated movement between segments must be governed appropriately to ensure that unusual activity is not inadvertently disguised.
        
Are all segments statistically significant in terms of the number of customers within them?
            Segments with low volumes of customers are not suitable for deriving threshold values.
        
Are high-risk customers monitored with additional scrutiny, either through segmentation or another mechanism?
            Regulatory guidance specifies that high-risk customers need to be subjected to additional scrutiny, without specifying what this means in the context of transaction monitoring. Occasionally high-risk segments are created, however care should be taken that this doesn't create statistically significant volumes or place high-risk customers in segments with other high-risk customers that are actually expected to behave very differently. A better solution, enabled by some TM systems, is to be able to set two thresholds for the same parameter for a single segment - a non-high risk (e.g. 95th percentile) threshold and a high-risk threshold (e.g. 85th percentile).

Question / consideration	Explanation
Do you use segmentation to facilitate the use of different thresholds for groups of customers that are expected to behave differently?	Segmentation is critical where TM is used to monitor varying types of customers, or even similar types of customers with large wealth ranges or expected activity due to their circumstances.
Do you have a documented methodology that was executed to create your customer segments?	Regulators expect to see documented rationale as to how customer segments were chosen for TM to give confidence they are appropriate.
Are customers segmented into groups based on their expected behaviour? What key factor of expected behaviour has been used for segmentation (e.g. aggregate credit value per month)?	Scenarios will focus on different facets of customers' behaviour, for example monthly volume of credit transactions, vs monthly value of credit transactions. These facets may not necessarily correlate. This poses a challenge for segmentation. Unless multiple segmentations are used (with scenarios then selecting the most appropriate segmentation to use according to the behaviour they are seeking to identify), a single facet of customer behaviour must be selected. This choice of variable should be driven by the most common variable used across all required scenarios.
Has 'bottom-up' segmentation been performed using historical transaction records to validate that segments are homogenous and mutually exclusive?	Bottom-up segmentation uses historical transaction data to model the spread of customer behaviour within each segment. It helps to determine the homogeneity of each segment, as well as allow segments to be compared and contrasted to ensure they are sufficiently different from one another.
Can customers move between segments as their information and/or transactional behaviour changes? Is this automatic?	A customer's segment is governed by KYC/KYB data (i.e. expectation of behaviour), rather than transactional data (i.e. actual behaviour). This data can change however, and it is important to ensure that processes are in place to update a customer's segment when needed. Any automated movement between segments must be governed appropriately to ensure that unusual activity is not inadvertently disguised.
Are all segments statistically significant in terms of the number of customers within them?	Segments with low volumes of customers are not suitable for deriving threshold values.
Are high-risk customers monitored with additional scrutiny, either through segmentation or another mechanism?	Regulatory guidance specifies that high-risk customers need to be subjected to additional scrutiny, without specifying what this means in the context of transaction monitoring. Occasionally high-risk segments are created, however care should be taken that this doesn't create statistically significant volumes or place high-risk customers in segments with other high-risk customers that are actually expected to behave very differently. A better solution, enabled by some TM systems, is to be able to set two thresholds for the same parameter for a single segment - a non-high risk (e.g. 95th percentile) threshold and a high-risk threshold (e.g. 85th percentile).

4 - Scenarios

    
            FCA observation
            Question / consideration
            Explanation 
        

    
            “The firm tailors the monitoring system rules to its business, risk and relevant typologies. The system and rules are tested and reviewed for right outcomes” 
(Proposed new text for revised Financial Crime Guide .)
            Are there scenarios in place to identify the proceeds of crime from fraud and scams - for example mule accounts?
            It is important to recognise that profits from fraud are the proceeds of crime and should result in the filing of a SAR. With the proliferation of scams and Authorised Push Payment (APP) Fraud, it is typical to expect the existence of mule accounts within your organisation that receive money as a result of scams. TM can act as a useful tool to detect the existence of mule accounts.
        

            Can specific products be identified within scenarios and the scope of a scenario applied to certain products only?
            Given product features define how money can be laundered through a specific product, it is important that the data, system and configuration allow scenarios to be applied appropriately to different products. As an example, typologies for credit products are quite different to those for current accounts.
		
Is the system able to consolidate and monitor all of a customer's activity across all of their products (i.e. holistic monitoring)?
            It is key that all of a customer's behaviour is considered when attempting to identify unusual behaviour. Activity that may seem legitimate for a single account may actually be highly suspicious when considered in the context of the broader activity across all of a customer's accounts.
        
Are you able to identify cash deposits that are made at the Post Office (if allowed by any products)?
            The FCA identified cash deposits through the Post Office as a common method of laundering money and as something that was poorly monitored by the firms that allow it. The FCA now expects firms to have TM capabilities which allow them to identify suspicious activity in non-branch cash deposits and to detect deviations between expected and actual activity. See  https://www.fca.org.uk/firms/financial-crime/cash-based-money-laundering for further details.
        
Are new/updated scenarios piloted or subject to evaluation periods before being put into production?
            It is good practice to test changes or new scenarios to assess their efficacy, prior to putting them into production to ensure they are identifying the relevant behaviour effectively.
        

FCA observation	Question / consideration	Explanation
“The firm tailors the monitoring system rules to its business, risk and relevant typologies. The system and rules are tested and reviewed for right outcomes” (Proposed new text for revised Financial Crime Guide .)	Are there scenarios in place to identify the proceeds of crime from fraud and scams - for example mule accounts?	It is important to recognise that profits from fraud are the proceeds of crime and should result in the filing of a SAR. With the proliferation of scams and Authorised Push Payment (APP) Fraud, it is typical to expect the existence of mule accounts within your organisation that receive money as a result of scams. TM can act as a useful tool to detect the existence of mule accounts.
Can specific products be identified within scenarios and the scope of a scenario applied to certain products only?	Given product features define how money can be laundered through a specific product, it is important that the data, system and configuration allow scenarios to be applied appropriately to different products. As an example, typologies for credit products are quite different to those for current accounts.
Is the system able to consolidate and monitor all of a customer's activity across all of their products (i.e. holistic monitoring)?	It is key that all of a customer's behaviour is considered when attempting to identify unusual behaviour. Activity that may seem legitimate for a single account may actually be highly suspicious when considered in the context of the broader activity across all of a customer's accounts.
Are you able to identify cash deposits that are made at the Post Office (if allowed by any products)?	The FCA identified cash deposits through the Post Office as a common method of laundering money and as something that was poorly monitored by the firms that allow it. The FCA now expects firms to have TM capabilities which allow them to identify suspicious activity in non-branch cash deposits and to detect deviations between expected and actual activity. See https://www.fca.org.uk/firms/financial-crime/cash-based-money-laundering for further details.
Are new/updated scenarios piloted or subject to evaluation periods before being put into production?	It is good practice to test changes or new scenarios to assess their efficacy, prior to putting them into production to ensure they are identifying the relevant behaviour effectively.

5 - Thresholds

    
            FCA observation
            Question / consideration
            Explanation 
        
            "More broadly, we also find some firms’ transaction monitoring systems are based on arbitrary thresholds, often using ‘off-the-shelf’ calibration provided by the vendor without due consideration of its applicability to the business activities, products or customers of the firm. We often find that firms have difficulty in demonstrating how the thresholds would relate to the levels of expected activity of specific customers or customer cohorts."
            Is there a matrix of scenarios versus segments, identifying where segment specific thresholds are applicable?
            On occasion a scenario may use a single threshold that remains constant across all segments. Maintaining a matrix of scenarios against segments, highlighting where segment-specific thresholds are required helps to ensure the rationale is maintained and evidenced, and supports subsequent thresholds setting and tuning exercises.
        
            Is there a documented methodology for how scenario thresholds are chosen, tested, and refined?
            Thresholds need to be tailored to your business, customers and products. Regulators take a dim view of organisations that use thresholds based simply on 'expert judgment' with no supporting data analysis, or worse still using 'out of the box' thresholds with no subsequent tuning.
		
Are threshold choices and associated rationale documented?
            It is important to capture how and why thresholds were selected for each scenario.
        
Are periodic threshold reviews conducted to assess the efficacy of existing thresholds and improve if required?
            MI from investigated alerts should be used to further improve thresholds and improve efficiency. In addition, changes such as inflation and other macro economic effects result in thresholds needing to be periodically reviewed and updated to remain effective.

FCA observation	Question / consideration	Explanation
"More broadly, we also find some firms’ transaction monitoring systems are based on arbitrary thresholds, often using ‘off-the-shelf’ calibration provided by the vendor without due consideration of its applicability to the business activities, products or customers of the firm. We often find that firms have difficulty in demonstrating how the thresholds would relate to the levels of expected activity of specific customers or customer cohorts."	Is there a matrix of scenarios versus segments, identifying where segment specific thresholds are applicable?	On occasion a scenario may use a single threshold that remains constant across all segments. Maintaining a matrix of scenarios against segments, highlighting where segment-specific thresholds are required helps to ensure the rationale is maintained and evidenced, and supports subsequent thresholds setting and tuning exercises.
Is there a documented methodology for how scenario thresholds are chosen, tested, and refined?	Thresholds need to be tailored to your business, customers and products. Regulators take a dim view of organisations that use thresholds based simply on 'expert judgment' with no supporting data analysis, or worse still using 'out of the box' thresholds with no subsequent tuning.
Are threshold choices and associated rationale documented?	It is important to capture how and why thresholds were selected for each scenario.
Are periodic threshold reviews conducted to assess the efficacy of existing thresholds and improve if required?	MI from investigated alerts should be used to further improve thresholds and improve efficiency. In addition, changes such as inflation and other macro economic effects result in thresholds needing to be periodically reviewed and updated to remain effective.

6 - Alerts & investigations

    
            FCA observation
            Question / consideration
            Explanation 
        

    
             "We frequently find that the rationales supporting the discounting of transaction monitoring alerts require strengthening. Discounting rationales often fail to demonstrate the level of investigation undertaken or record a sufficient explanation as to why activity is no longer considered unusual when scrutinised against the customer’s expected activity. 
We identified instances where firms failed to assess alerted transactional activity against the established customer profile to validate the source of funds for high-value transactions. In one example we saw, a firm failed to do this despite adverse media allegations that funds had been obtained through illicit means, and that failure placed the firm at significant risk of facilitating money laundering."

            Can alerts related to the same customer be rolled up or consolidated into a single case?
            It is highly inefficient to investigate alerts relating to the same underlying customer separately. Worse still, separate investigations may be carried out in isolation, with no knowledge of the other alert. This can result in behaviour that would be judged as suspicious when reviewed holistically being dismissed.
        

            Do investigators have all the information required to conduct an investigation at their fingertips within the TM case management interface, or do they need to source and record data from other sources?
            It is very time consuming for operations teams to interrogate other systems in the course of investigating an alert. This wastes time on low value activity, creates investigator fatigue and reduces the time spent making decisions on the suspicion associated with an alert. Furthermore, the additional information manually gathered to assess the alert may be valuable for improving the scenario - such improvements will be far more difficult if the data is not already available to the TM system.
		
Do investigators create any spreadsheets or use any ancillary software in the course of an investigation (for example, pasting transactions into a spreadsheet and applying formulas or creating charts)?
            Ad-hoc external analysis to support an investigator's decision is common and in some cases cannot be avoided. However, investigators frequently performing similar analyses outside of the TM system is very inefficient, and efforts should be made to integrate these analyses into the case management tool itself.
        
Are investigation narratives pre-populated using available information, for review and editing by the investigator, rather than being created from scratch by the investigator?
            Advances in natural language generation (NLG) and generative AI allow for detailed investigation narratives to be pre-populated for alerts. These automated narratives can then be reviewed and edited by investigators, saving significant amounts of time as well as ensuring auditability standards are met.
        
Does your investigation focus on the unusual behaviour highlighted by the underlying scenario, rather than performing a generic account/customer review?
            TM scenarios are designed to identify KRIs that are indicative of a money laundering or terrorist financing typology. As such it makes little sense to perform a generic account review following the generation of an alert. A generic account review will not only take a long time, it may also lack focus on the key risk(s) originally identified by the scenario.
        
For closed alerts, are sufficiently detailed rationales provided that explain why an alert was discounted?
            It is a regulatory expectation for closed alerts to have an accompanying rationale as to why they were deemed to be non-suspicious.
        
If your firm uses models for triaging TM alerts (e.g. scorecards overlaid on existing systems, ‘hibernation’ of alerts until additional risk indicators are identified), is the model clearly understood and its behaviour justifiable? 
            A clear evaluation of any alert triage methods used must have been completed to ensure that suspicious behaviour is not being hibernated, closed or otherwise not presented for human review. Techniques to evaluate alert triage mechanisms can include using historical transactions to regenerate alerts and ensure that any previous alerts that resulted in SARs continue to be presented for human review, as well as performing sample based checks on hibernated alerts to ensure suspicious activity is not being erroneously dismissed.
        

FCA observation	Question / consideration	Explanation
"We frequently find that the rationales supporting the discounting of transaction monitoring alerts require strengthening. Discounting rationales often fail to demonstrate the level of investigation undertaken or record a sufficient explanation as to why activity is no longer considered unusual when scrutinised against the customer’s expected activity. We identified instances where firms failed to assess alerted transactional activity against the established customer profile to validate the source of funds for high-value transactions. In one example we saw, a firm failed to do this despite adverse media allegations that funds had been obtained through illicit means, and that failure placed the firm at significant risk of facilitating money laundering."	Can alerts related to the same customer be rolled up or consolidated into a single case?	It is highly inefficient to investigate alerts relating to the same underlying customer separately. Worse still, separate investigations may be carried out in isolation, with no knowledge of the other alert. This can result in behaviour that would be judged as suspicious when reviewed holistically being dismissed.
Do investigators have all the information required to conduct an investigation at their fingertips within the TM case management interface, or do they need to source and record data from other sources?	It is very time consuming for operations teams to interrogate other systems in the course of investigating an alert. This wastes time on low value activity, creates investigator fatigue and reduces the time spent making decisions on the suspicion associated with an alert. Furthermore, the additional information manually gathered to assess the alert may be valuable for improving the scenario - such improvements will be far more difficult if the data is not already available to the TM system.
Do investigators create any spreadsheets or use any ancillary software in the course of an investigation (for example, pasting transactions into a spreadsheet and applying formulas or creating charts)?	Ad-hoc external analysis to support an investigator's decision is common and in some cases cannot be avoided. However, investigators frequently performing similar analyses outside of the TM system is very inefficient, and efforts should be made to integrate these analyses into the case management tool itself.
Are investigation narratives pre-populated using available information, for review and editing by the investigator, rather than being created from scratch by the investigator?	Advances in natural language generation (NLG) and generative AI allow for detailed investigation narratives to be pre-populated for alerts. These automated narratives can then be reviewed and edited by investigators, saving significant amounts of time as well as ensuring auditability standards are met.
Does your investigation focus on the unusual behaviour highlighted by the underlying scenario, rather than performing a generic account/customer review?	TM scenarios are designed to identify KRIs that are indicative of a money laundering or terrorist financing typology. As such it makes little sense to perform a generic account review following the generation of an alert. A generic account review will not only take a long time, it may also lack focus on the key risk(s) originally identified by the scenario.
For closed alerts, are sufficiently detailed rationales provided that explain why an alert was discounted?	It is a regulatory expectation for closed alerts to have an accompanying rationale as to why they were deemed to be non-suspicious.
If your firm uses models for triaging TM alerts (e.g. scorecards overlaid on existing systems, ‘hibernation’ of alerts until additional risk indicators are identified), is the model clearly understood and its behaviour justifiable?	A clear evaluation of any alert triage methods used must have been completed to ensure that suspicious behaviour is not being hibernated, closed or otherwise not presented for human review. Techniques to evaluate alert triage mechanisms can include using historical transactions to regenerate alerts and ensure that any previous alerts that resulted in SARs continue to be presented for human review, as well as performing sample based checks on hibernated alerts to ensure suspicious activity is not being erroneously dismissed.

7 - Monitoring & improvement

    
          FCA observation  
          Question / consideration
            Explanation 
        

    
			“Do you frequently review the monitoring system rules and typologies for effectiveness? Do you understand the threshold and rule rationales?” 
(Proposed new text for revised Financial Crime Guide .)
            Is reporting and MI granular enough to understand the performance of specific scenarios as well as individual investigators? Are true positive rates for each scenario recorded and understood?
            It is very important to understand the efficacy and efficiency of individual scenarios. It is common for completely unproductive scenarios to remain active for many years, creating large amounts of waste, cost and investigator fatigue. Conversely, scenarios that result in high SAR conversion rates should be closely evaluated using 'below the line (BTL)' analysis to ensure that potentially suspicious behaviour is not being missed by the choice of current thresholds. MI should also enable investigator specific information to be evaluated in order to assess the performance of individuals and teams.
        

            Is there the capability to differentiate between unproductive alerts (i.e. alerts highlighting normal/expected behaviour for a given customer) and alerts which correctly highlight unusual behaviour, yet do not result in a SAR?
            TM systems famously have low true positive rates, where a true positive is defined as an alert that has resulted in a SAR being submitted. As TM systems are fairly blunt instruments, they typically only identify unusual behaviour, which may or may not be suspicious. The behaviour may be perfectly explainable given the wider, often qualitative context available to a human investigator. But it is still important they present this behaviour for review in case it is suspicious. It is therefore important to have additional granularity when recording investigation outcomes to facilitate better tuning of scenarios. For example, alert outcomes could be 'Normal - Not suspicious', 'Unusual - Not suspicious' and 'Suspicious'. Use of an 'Unusual - Not suspicious' outcomes enables far better understanding of scenario performance to inform tuning.
		
Is there a Quality Control (QC) process that ensures a percentage of a given investigators completed cases are reviewed to ensure they are in line with established processes? 
            Quality control processes are a key element of governance to achieve confidence that alert reviews are being conducted to the expected standard. Without QC investigators may take short-cuts in order to meet their targets, resulting in suspicious behaviour being missed. 
        
Is there a method of applying different rates of QC  checking per investigator (for example, checking 100% of cases for a new investigator vs 5% for an established investigator)? 
            It is sensible to have a method that allows for new or more junior investigators work to be checked more thoroughly than experienced investigators.
        
Are there Service Level Agreements (SLAs) in place to ensure that alerts are investigated within an acceptable period?
            There should be processes in place to ensure that no alerts 'fall through the cracks' and remain un-investigated for long periods of time. Despite transaction monitoring and SAR filing being a post-event control is a legal obligation to report suspicious activity - i.e. file a SAR - 'as soon as practicable' after the associated transactions have occured.
        
If you learn that criminals have abused your facilities, do you perform a review to learn how monitoring methods could be improved to lessen the risk of recurrence?
            When made aware of breaches that were not identified through your existing controls, reviews should be performed to evaluate if any controls could be introduced or improved to identify the associated activity. This includes transaction monitoring.
        
Are you made aware of new product releases and do you assess if any modifications / additions are needed to manage any additional risk?
            A new product approval process should include 1st line risk teams, with the individuals / teams responsible for maintaining TM consulted. This gives an opportunity for any required changes to manage risk to be identified and implemented prior to the new product being launched.
        

FCA observation	Question / consideration	Explanation
“Do you frequently review the monitoring system rules and typologies for effectiveness? Do you understand the threshold and rule rationales?” (Proposed new text for revised Financial Crime Guide .)	Is reporting and MI granular enough to understand the performance of specific scenarios as well as individual investigators? Are true positive rates for each scenario recorded and understood?	It is very important to understand the efficacy and efficiency of individual scenarios. It is common for completely unproductive scenarios to remain active for many years, creating large amounts of waste, cost and investigator fatigue. Conversely, scenarios that result in high SAR conversion rates should be closely evaluated using 'below the line (BTL)' analysis to ensure that potentially suspicious behaviour is not being missed by the choice of current thresholds. MI should also enable investigator specific information to be evaluated in order to assess the performance of individuals and teams.
Is there the capability to differentiate between unproductive alerts (i.e. alerts highlighting normal/expected behaviour for a given customer) and alerts which correctly highlight unusual behaviour, yet do not result in a SAR?	TM systems famously have low true positive rates, where a true positive is defined as an alert that has resulted in a SAR being submitted. As TM systems are fairly blunt instruments, they typically only identify unusual behaviour, which may or may not be suspicious. The behaviour may be perfectly explainable given the wider, often qualitative context available to a human investigator. But it is still important they present this behaviour for review in case it is suspicious. It is therefore important to have additional granularity when recording investigation outcomes to facilitate better tuning of scenarios. For example, alert outcomes could be 'Normal - Not suspicious', 'Unusual - Not suspicious' and 'Suspicious'. Use of an 'Unusual - Not suspicious' outcomes enables far better understanding of scenario performance to inform tuning.
Is there a Quality Control (QC) process that ensures a percentage of a given investigators completed cases are reviewed to ensure they are in line with established processes?	Quality control processes are a key element of governance to achieve confidence that alert reviews are being conducted to the expected standard. Without QC investigators may take short-cuts in order to meet their targets, resulting in suspicious behaviour being missed.
Is there a method of applying different rates of QC checking per investigator (for example, checking 100% of cases for a new investigator vs 5% for an established investigator)?	It is sensible to have a method that allows for new or more junior investigators work to be checked more thoroughly than experienced investigators.
Are there Service Level Agreements (SLAs) in place to ensure that alerts are investigated within an acceptable period?	There should be processes in place to ensure that no alerts 'fall through the cracks' and remain un-investigated for long periods of time. Despite transaction monitoring and SAR filing being a post-event control is a legal obligation to report suspicious activity - i.e. file a SAR - 'as soon as practicable' after the associated transactions have occured.
If you learn that criminals have abused your facilities, do you perform a review to learn how monitoring methods could be improved to lessen the risk of recurrence?	When made aware of breaches that were not identified through your existing controls, reviews should be performed to evaluate if any controls could be introduced or improved to identify the associated activity. This includes transaction monitoring.
Are you made aware of new product releases and do you assess if any modifications / additions are needed to manage any additional risk?	A new product approval process should include 1st line risk teams, with the individuals / teams responsible for maintaining TM consulted. This gives an opportunity for any required changes to manage risk to be identified and implemented prior to the new product being launched.

ChecklistTransaction MonitoringAMLCFTFCAAML Transaction MonitoringCheck listSegmentationScenariosThresholdsAlertsFalse positivesAlert triage

Simon McMahon