Blog article
See all stories »

Financial Crime - drowning in a sea of Alerts

Today, large financial institutions have dramatically grown the variety of their products and services.  At the same time they have similarly increased the type, number and sophistication of touch points by which customers can access such products and services.  The resulting greater complexity has coincided with the so-called ‘third wave’ of technology revolution change. 

And all this has taken place in an environment of rapidly growing regulatory supervision in risk, fraud and anti-money laundering compliance in response to terrorism and failures in corporate governance.

Today, it is not unusual to find 20 or more different detection systems across the enterprise, each generating their own Alerts and requiring significant specialist manual intervention to resolve these Alerts, based on varying risks and regulatory requirements.

 So, how can banks and other financial institutions meet these challenges to operational efficiency, scalability and spiralling costs? 

One way is to overlay existing applications with key elements of a rules-based BPM and robust case management solution.  Such an approach is ideally geared to deliver the simplicity and best practice resolution processes essential if the business is to be able to minimise the number of false Alerts, at the same time meeting the imperatives of reduced commercial risk and greater compliance.

A problem of complexity

Until now, there has been very little ability to correlate Alerts with the same or similar attributes between detection systems and across lines of business.  A situation for a given customer or account may cause multiple Alerts to be generated in multiple detection systems, leaving essentially departmental, or ‘siloed’, investigators unaware of the holistic view of risk.

It is generally recognised that the vast majority of Alerts are false positives.  As more detection systems are implemented and their sophistication increases, the ability for an organisation to proactively tune these systems becomes yet more challenging.

The regulatory risk of tuning out more Alerts is also increasing.  Central banks and regulatory agencies are imposing more oversight and large fines for failing to monitor, detect and manage certain types of risk behaviours.  This has in turn led to more Alerts being considered for investigation by the authorities.

Issues around hiring, resourcing, training and consistency abound.  As the number of Alerts generated continues to increase, more investigators are required, with each needing to either specialise or learn multiple investigation environments. 

And finally, the case management systems and investigative approach may vary significantly, causing inconsistent case results throughout the enterprise and, in turn, regulatory risk.  Similarly, results generated form previous Alerts and investigations are rarely shared across lines of business and types of fraud, AML and sanctions investigations.

The result is overwhelming

Internationally, the volume of Suspicious Transaction Reports (STRs) generated from these Alerts has also increased substantially.  Although the form of these STRs has been standardised, many countries still allow paper-based transmission and thus require manual input to digitise. 

As a result, the central banks have very similar types of correlation and case management requirements.  These include, for example: intelligent grouping of multiple STRs by relevant attributes to create an investigable case; access and augmentation of Case data from other government databases; using such information to drive a risk rating engine in order to prioritise risk and therefore investigation; and the scalability to handle growing volumes.   

A solution ‘vision’

This incorporates several key technologies:

  • The ability to interface with any type of system – current detection systems are leveraged, as they are critical to identifying suspicious activity and typically focus on increasingly specialised types of behavioural patterns.  Alerts governed by these current and future detection engines are ingested into one enterprise-wide financial crime case management platform.
  • The ability to specialise processing based on the Alert type and circumstance – as the structure of Alerts can vary substantially.  Not only are they produced by different detection engines created by different vendors, but also they require different types of supporting data
  • A configurable business rules engine that drives workflow based on situation – with manual or (preferably) automated triage functions triggered to apply business rules against the Alert circumstance, this detects and resolves or routes duplicate or multiple Alerts.  Intelligent routing also determines the investigator skill-set with best fit to work the case  
  • Robust case management driven by rules and circumstance – providing the human investigator with the proper tools to research and investigate the case
  • Managing and monitor investigator performance and compliance to regulatory requirements - including a range of relevant components, such as visual link analysis to link attributes to other cases identifying hidden networks of relationships.

A ‘real world’ example

How can this be achieved.  One way is to combine a business rules engine and Business Process Management (BPM) tool with automated triage functionality. 

The key is to treat everything as a rule.  Rules are stored in a repository and are created, modified and deleted using a form/model-based user interface.  This is the equivalent of programming, but is aimed at the application subject matter expert – that is, the business user rather than IT support.

These rules are used to generate the desired application and change can be immediate.  Most applications will typically focus on case management and workflow, with variability driven by business rules and situations. 

As part of this ‘solution vision’, a set of rules specifically addresses Financial Crimes Case Management (the FCM framework).  Use cases define FCM functionality, containing rules providing financial crime-specific templates for building a case management application best-suited to each client’s needs.

They contain rules for common industry process workflows, common actions, data schemes and working examples.  Assets of the framework can also be used as is, or copied to a higher level of specification (i.e. geography, product) for modification extension or replacement.  This has been described as a ‘situational layer cake’.

Rule sets allow organisations to add ‘specialised’ layers of instructions, by recoding just what will be different in specific situations, such as taking on board a specific type of Alert or investigating a specific type of case.

This layered approach ensures that rules at a higher level of specialisation take precedence and the rules engine determines which set of processes, rules and data sources apply for a given situation.  The result is a highly agile financial crime management tool, which is managed by the business to deliver rapid change in response to evolving regulatory, market and business imperatives.         


Comments: (0)

Now hiring