Fraud Detection in Banking Payments Reviews and Ratings

Mandatory Features:

• Case investigation (CI): Transactions highlighted by the DE as high risk need to be assessed by human case investigators. Bank staff will use the CI module to make an informed judgment about whether a particular transaction is a true positive (fraud) or a false positive (not fraud). The CI module will give access to additional data sources such as know your customer (KYC) or watchlists to help make the judgment. There is always a capability for posting a report that states the judgment with an audit trail for how that decision was arrived at. To increase productivity and accuracy, case investigation modules may include additional capabilities such as automated workflow, AI assistants, smart allocation, triage for urgency/importance, data source prioritization and prepopulated reports.

• Orchestration: This applies to both data and processes. There must be a means of importing the right data, from the right systems and sources, at the right time, and then processing them in the right order. This is the “glue” that integrates the preceding three modules. Most vendors will have built their own orchestration capability, or else they will have adapted a standard business process management (BPM) tool for this specific purpose.

• Decision engine (DE): This module must include at least one (and usually both) of an ML model and a BRE. The DE will process data accessed via the TM module. It will also need a set of API connectors for ingesting additional data from security systems such as device ID, location intel and behavioral biometrics. Some of these APIs will be standard off-the-shelf connectors for common systems and others will be custom-made for a specific deployment. The combination of ML and BRE is used to highlight suspected fraudulent payments and money movements by calculating a risk score for each transaction. The ML may be imported from the bank (if it has a preexisting model) or it may be supplied off-the-shelf by the vendor and then tuned for the specific bank it is deployed at.

• Transaction monitoring (TM): This module is capable of ingesting data for financial events in the form of (a) incoming and outgoing payments and (b) money movements such as transfers between accounts held at the same bank or between products held by the same customer. It must have links to the payments hub (or payment systems) at the bank and also its core banking system.