Buyer’s Guide for Fraud Detection in Banking

Published 11 January 2022 - ID G00756888 - 17 min read

By Analyst(s): Akif Khan

Initiatives: Identity and Access Management and Fraud Detection

Detecting fraudulent transactions and events is a constant

challenge for banks. Security and risk management leaders must
focus on consolidating fraud detection across products and
channels, aligning with organizational infrastructure strategy, and
seeking compelling differentiation from vendors.

Additional Perspectives

■ Summary Translation: Buyer’s Guide for Fraud Detection in Banking

(10 February 2022)

More on This Topic

This is part of an in-depth collection of research. See the collection:

■ Security and Risk Management Leaders’ Guide to Online Fraud Detection and
Identity Proofing

Gartner, Inc. | G00756888 Page 1 of 14

This research note is restricted to the personal use of cavieira1@topazevolution.com.

 Overview
Key Findings
■ Projects to investigate new fraud detection platforms often fade away as they fail to
communicate clear business drivers to justify the change in the face of complex
vendor migration activities.

■ Most banks have multiple fraud detection platforms, typically deployed at the
banking product level (e.g., debit cards, wire transfers, digital banking channels),
resulting in gaps between silos open to exploitation by fraudsters.

■ Many banks regard on-premises deployments as the only option for fraud-detection-
focused transaction monitoring, discounting the possibility of cloud or vendor-
hosted deployment models without adequate consideration.

■ RFPs for fraud detection solutions often fail to reveal sufficient differentiation
between vendors because they focus on too narrow a set of capabilities and
features. Proof of concept (POC) projects are relatively common when assessing
new fraud detection vendors. However, each of the different approaches to a POC
comes with significant challenges.

Recommendations
Security and risk management (SRM) leaders responsible for fraud detection must:

■ Gain the buy-in of stakeholders by clearly identifying and communicating the drivers
behind utilizing a new fraud detection solution and the business benefits of doing
so.

■ Shift to customer-level fraud screening by using a single fraud detection platform to

screen transactions and events across as many banking products and channels as
possible.

■ Evaluate all deployment models with an open mind by assessing which aligns most
strongly with organizational infrastructure strategy and which is best-placed to
deliver cost-effective business benefits.

■ Create an effective RFP by focusing on the fullest range of transaction and event
monitoring capabilities to differentiate among vendors. Decide whether doing a POC
project is worthwhile or feasible by understanding the scope, limitations and
constraints of the various POC approaches.

Gartner, Inc. | G00756888 Page 2 of 14

This research note is restricted to the personal use of cavieira1@topazevolution.com.

 Strategic Planning Assumptions
By 2025, 50% of new fraud detection solutions for banking will be customer-centric
platforms deployed across products and channels, replacing multiple siloed solutions, for
better customer experience and fraud detection.

By 2025, the number of new deployments of transaction and event fraud detection
monitoring platforms for banking that are vendor-hosted and managed will double to
more than 70%, reducing operational costs and complexity.

Introduction
Monitoring financial transactions and events for fraud in real time across a variety of
products and channels is a critical requirement that all banks must fulfill. This task is
challenging for many banks as they have multiple solutions from multiple vendors
deployed at the banking product or channel level. For example, they offer one solution for
screening card authorizations, another solution for wire transfers, yet another for digital
banking and so on. The majority of these solutions were deployed on-premises many
years ago and may now be behind in the upgrade cycle, and difficult to migrate away
from.

This use of multiple fraud detection platforms hampers the ability of banks to detect
cross-channel fraud activity that targets accounts by exploiting a customer’s many
different contact points with the bank. As fraud attack vectors have evolved in parallel
with increasing expectations of minimal friction for customers, alongside industry
changes such as faster payments, banks are finding that their long-standing deployed
solutions often no longer meet their requirements. At a time when many banks work to
execute on digital transformation programs and migration to cloud environments, the
future of these multiple legacy on-premises deployments must be addressed.

So how can SRM leaders in banking choose a modern solution for transaction- and event-
based fraud detection that supports a more cost-effective and efficient customer-centric
approach that is product- and channel-agnostic? They should follow the steps outlined in
this research, in conjunction with using Tool: RFP Questionnaire Template for Fraud
Detection in Banking, to (see Figure 1):

■ Develop a business case for moving to a new solution.

■ Consolidate fraud screening across banking products and channels.

■ Select a deployment model that aligns with organizational strategy.

Gartner, Inc. | G00756888 Page 3 of 14

This research note is restricted to the personal use of cavieira1@topazevolution.com.

 ■ Develop an RFP that focuses on differentiating capabilities across vendors.

■ Understand the merits of carrying out a POC project.

Figure 1: Buying Considerations for Fraud Detection in Banking

Note: This research is about transaction and event monitoring with a fraud detection
focus. It is not about transaction monitoring in the context of anti-money-laundering
(AML), often also referred to as “financial crime.” While many vendors in this market offer
capabilities to address both use cases, the sole focus here is fraud detection.

Analysis
Identify Drivers to Make a Solid Business Case
All banks will have one or more fraud detection solutions of sorts in place for monitoring
transactions and events across their credit and debit card portfolios, wire transfers, digital
banking channels, and other product lines for fraud. The decision to move to a new
solution is not a trivial one. Implementing a new fraud detection solution for transaction
and event monitoring is a project that can typically cost more than $250,000 in
implementation costs and take significant time and resources to execute. Gartner
observes that many such exploratory projects to seek replacement products never come to
fruition due to weak business cases that fail to identify the key benefits and drivers for
upgrading transaction and event monitoring capabilities. As a result, investment is not
forthcoming to replace the status quo that banks often convince themselves is “good
enough.”

Gartner, Inc. | G00756888 Page 4 of 14

This research note is restricted to the personal use of cavieira1@topazevolution.com.

 Action: SRM leaders must gather stakeholders and identify the key business drivers for
modernizing the bank’s approach to fraud detection. The strategic imperative is to
implement a customer-centric approach to fraud detection — monitoring transactions and
events across products and channels on a single platform. Such stakeholders should
include technical architects and those responsible for fraud detection, compliance, user
experience and customer support. These business drivers can then be used to shape the
case for making the investment in a new solution. Table 1 shows the three most likely
high-level business drivers and the more granular drivers within each.

Table 1: Drivers to Build a Strong Business Case

Fraud KPIs Governance IT Operations

■ Reduce silos between ■ Improve explainability ■ Reduce number of

multiple fraud into machine learning platforms across the
platforms (ML) decisions business

■ Reduce case ■ Improve ML ■ Reduce burden of on-

management performance premises
workload predictions management

■ Reduce investigation ■ Improve ML ■ Improve efficiency of

costs promotion controls ML model
maintenance
■ Reduce false ■ Address bias in ML
positives models

■ Reduce fraud

Source: Gartner (January 2022)

Consolidate Across Products and Channels by Moving to Customer-Level

Fraud Detection
The majority of banks that Gartner advises have more than one transaction monitoring
solution deployed, each delivering fraud detection across a different product line,
transaction or event type, or interaction channel. In addition, they will have additional
classes of fraud detection tools focused on preventing fraud in the contact center, new
account-opening fraud or account takeover. This situation has arisen due to different
product lines within the bank having their own budgets, systems and leaders responsible
for fraud detection. Growth through acquisition is another culprit for such fragmented
fraud detection processes.

Gartner, Inc. | G00756888 Page 5 of 14

This research note is restricted to the personal use of cavieira1@topazevolution.com.

 The result is a siloed fraud detection environment in which the dots cannot be joined
between potentially fraudulent activity across products or channels that may be
impacting any single customer. For example, an online card transaction judged in
isolation may just about fall within risk tolerance. However, if a fraud detection solution
could detect high-risk activity on a customer’s account in the digital banking channel (for
example, updating a mobile phone number to receive one-time passwords by SMS), then
that card transaction may be seen in a different light. This consolidation is becoming
even more necessary as the number of use cases and products is increasing with
initiatives related to faster payments and open banking.

Action: SRM leaders must seek to evolve their bank’s approach to detecting fraudulent
transactions and events by moving from a channel-level and product-level approach to a
customer-level approach. By using a single platform to monitor for fraud across a
customer’s account activity with the bank, fraudsters cannot take advantage of a siloed
detection strategy.

In the same way that banks seek to have a single view of the customer from a
relationship perspective, SRM leaders should implement a transaction and event
monitoring solution that enables a single view of the fraudster.

SRM leaders must define requirements for any transaction and event monitoring solution
to be able to support or orchestrate fraud detection across the breadth of the bank’s
products and channels, including the contact center. These different types of transactions
(for example, a wire transfer versus a credit card transaction) will have markedly different
attributes and characteristics. As such, a fraud detection solution may require the use of
different ML models to screen these various transaction types. Vendors should be asked
to demonstrate how their solutions can assess the risk of any given transaction or event
by taking into account the previous activity seen for that customer across transaction
types and, hence, across different ML models within the solution.

Evaluate Deployment Models With an Open Mind

Traditionally, transaction monitoring solutions focused on fraud detection have been
deployed on-premises within the banks’ tight control. The reasons for this are manifold:

■ Many solutions were deployed 10+ years ago when on-premises was the only
available option to meet data security and response time requirements.

Gartner, Inc. | G00756888 Page 6 of 14

This research note is restricted to the personal use of cavieira1@topazevolution.com.

 ■ To minimize latency, particularly when screening credit and debit card
authorizations, the fraud detection platform was deployed as close as possible to
the core banking and card authorization platform, which was also typically on-
premises.

■ Banks have historically been averse to sending their transaction data outside of their
networks.

The benefits of moving applications to the cloud that are relevant in any industry, such as
lower total cost of ownership (TCO), ease of scalability, more efficient maintenance and
upgrades, and speed of deployment, are equally relevant to banking. 1 The majority of
banks now have cloud migration projects underway, although migration of core banking
and payment applications to the cloud are unlikely to be at the top of the list until
confidence is built up (see Top Trends in the Cloud Heat Map for Banking and Investment
Services for 2021). 2

Gartner surveyed 14 representative vendors in the fraud-detection-focused transaction

monitoring market for banking. 3 Four typical deployment models for their solutions were
identified:

■ On-premises — bank managing solution and infrastructure

■ Private cloud — bank managing solution and infrastructure

■ Public cloud — bank managing solution on third-party infrastructure

■ Vendor-hosted — vendor managing solution and infrastructure (Note: The vendor

may be leveraging public cloud services for hosting.)

Vendors were asked to rank these deployment options across different criteria, with the
results below consistent across the majority of vendors:

■ Fees for implementation: On-premises was most expensive, with private cloud and
public cloud in next place with equivalent fees, and the vendor-hosted model being
the least expensive to deploy.

Gartner, Inc. | G00756888 Page 7 of 14

This research note is restricted to the personal use of cavieira1@topazevolution.com.

 ■ Fees for ongoing services: The vendor-hosted model consistently had the highest
ongoing annual fees, with on-premises, private cloud and public cloud all somewhat
less expensive and with equivalent annual licensing fees. All vendors were keen to
point out that the vendor-hosted model carried the highest fees, as it delivered the
most value and offered the lowest TCO to the banks when taking into account the
reduction in their operational burden.

■ Duration of implementation: On-premises deployments take the longest, with private

cloud and public cloud in next place with equivalent duration, and vendor-hosted
deployments taking the shortest time. Several vendors noted, however, that the time
taken for due diligence by the bank’s infosec teams was shortest for on-premises
deployments and by far longest for vendor-hosted deployments, which offsets some
of the implementation project efficiency gains for the latter.

Vendors were also asked to give figures reflecting the percentage of their client
deployments that fall within each category — first across all their deployments ever, and
second just for deployments made in the last two years. The results are summarized in
Figure 2. Note that none of the vendors revealed the absolute number of client
deployments for reasons of confidentiality.

Gartner, Inc. | G00756888 Page 8 of 14

This research note is restricted to the personal use of cavieira1@topazevolution.com.

 Figure 2: Trends in Deployment Models

The results indicate a marked drop in the number of on-premises deployments in the last
two years versus historical deployments. This is offset by a significant increase in the
number of public cloud deployments in the last two years, and a moderate increase in the
number of vendor-hosted deployments. While on-premises just about remains the
dominant deployment model, over one-third of deployments in the last two years are
vendor-hosted and managed.

Action: SRM leaders should have an open mind and explore the breadth of deployment
options available rather than simply assuming that on-premises is the only viable option.
Most vendors now offer a range of deployment modes that can align with a bank’s
infrastructure and application deployment strategy. Assess each of these deployment
models on the basis of performance, scalability, implementation costs, ongoing vendor
fees, operational burden and TCO. Seek references from other clients that have deployed
as you wish to, understanding any challenges faced and the benefits that were realized.

Gartner, Inc. | G00756888 Page 9 of 14

This research note is restricted to the personal use of cavieira1@topazevolution.com.

 Seek Clear Differentiation Between Vendors With an Effective RFP
The market for transaction and event monitoring solutions focused on fraud detection is
increasingly crowded. Gartner actively tracks dozens of vendors in this space. Twenty-
seven percent of end-user client inquiry calls in 2021 were explicitly on the topic of
understanding this vendor landscape, reflecting both the high demand and the support
needed by clients to differentiate between vendors. 4 Differentiating among vendors that
all claim to have the best ML and to detect the most fraud is a challenge.

The foundation of assessing any vendors is, of course, focused on core aspects such as:

■ Vendor viability — age, financials, locations, team

■ Client base — size, geographic spread, profile of clients, win rate, attrition rate

■ Support — on-site versus remote, language skills, professional versus managed

services, partnerships with consulting firms

Differentiating at the product level itself is a more challenging task for many banks that
may lack the domain expertise to understand what is available in the market. Table 2 lists
the broad set of product features and capabilities that should be considered when
assessing any vendor.

Gartner, Inc. | G00756888 Page 10 of 14

This research note is restricted to the personal use of cavieira1@topazevolution.com.

 Table 2: Fraud Detection Capabilities
(Enlarged table in Appendix)

Action: SRM leaders must differentiate between vendors for fraud detection in the RFP
process by asking questions that align with the fullest set of capabilities as described in
Table 1. SRM leaders should leverage Tool: RFP Questionnaire Template for Fraud
Detection in Banking to view detailed questions to ask vendors in each of the areas listed
in Table 1. The tool also provides context as to the reason for and value of asking each
question. Questions that are deemed appropriate for your focus and requirements can be
leveraged in your relevant organizational RFP templates.

Gartner, Inc. | G00756888 Page 11 of 14

This research note is restricted to the personal use of cavieira1@topazevolution.com.

 When documenting the broad set of features selected above, SRM leaders should seek to
craft open questions to uncover creative, superior or unexpected methods that vendors
would suggest to address a specific requirement. Further guidance can be found in Best
Practices for Better Online Payment Fraud Detection RFPs.

The business drivers discussed earlier should be clearly explained right at the beginning
of the RFP so that vendors have a clear understanding of what they need to deliver.
Finally, as much detail as possible about the events, products and channels that will be
within the purview of the fraud detection solution should be included.

Understand the Benefits and Constraints of a POC Project

Many banks will want to test a new vendor in some kind of POC project before committing
to working with it. Our survey of vendors revealed some large differences in approaches
here, with some vendors stating that they rarely, if ever, agree to do POC projects, and
others stating that they engaged in them on nearly all new deals. On average, vendors
reported that about 32% of new deals involve a POC project.

The manner in which these POC projects were conducted also varied greatly. The most
common approach was for a bank to provide a batch file of historical data for the vendor
to analyze — in a bid to seek evidence that the vendor could identify fraudulent
transactions within the dataset. While this approach is relatively low effort for the bank,
many vendors were keen to point out that such an approach offers negligible value in
practice. In production deployments, most vendors would be building custom ML models
for the bank. In these batch file POCs, off-the-shelf, existing ML models typically need to
be used which lack specificity to the data in question. Vendors also pointed out that none
of their solutions would perform at optimal levels from the outset, but would typically
improve over time as models matured — another aspect lost in the batch file POC
approach. Additionally, capabilities of some vendors, such as device intelligence,
behavioral biometrics and behavior risk assessment for digital channels, cannot be
assessed with historical batch data. Such POC projects were cited as taking two to four
weeks.

Gartner, Inc. | G00756888 Page 12 of 14

This research note is restricted to the personal use of cavieira1@topazevolution.com.

 A smaller number of POC projects were reported as consisting of the vendor sending live
production data to its hosted environments. In these cases, the POC could more
accurately reflect the capabilities of the solution, but these projects were cited as taking
two to four months as custom models were developed and allowed to mature. It should be
noted that such POC projects effectively involve taking the vendor through the
procurement process of infosec evaluation and contractual agreements. As such, these
kinds of POCs are often positioned as an initial phase of a longer-term contract, with the
ability to terminate should the POC results not be satisfactory.

Action: SRM leaders must consider whether they are willing to invest the time and effort in
a POC project, or whether relying on RFP responses and appropriate client references is
sufficient. Where a batch file POC project is undertaken, SRM leaders must seek clarity
from vendors beforehand about the inevitable caveats that will be made around the
results. SRM leaders must ensure that internal stakeholders are aware of such limitations.
Upon understanding these, a pragmatic decision can be made as to whether the POC
genuinely offers value or is actually a tickbox exercise that can be skipped. Where a POC
project is being carried out that involves a live production integration, SRM leaders should
set expectations with business stakeholders about the length of time involved to gain
meaningful insights.

Evidence
1
Challenges and Opportunities in Banks’ Cloud Migration, Accenture blog.

2
On the Road to Cloud, Banks Still Have Far to Go, Forbes.

3
Fourteen representative vendors within the banking fraud detection market were
surveyed regarding deployment models and POC projects. The surveyed vendors were ACI,
AI Corporation, BAE Systems, Bottomline, DataVisor, Featurespace, Feedzai, FICO,
Fraud.net, IBM, NICE, SAS, Tencent and XTN Cognitive Security. The vendors included in
this survey do not constitute an exhaustive list of all vendors within this market. Inclusion
in this survey of representative vendors is not an endorsement, nor is omission an implied
criticism. Gartner thanks the listed vendors for supporting this research.

4
Based on analysis of over 1,150 client inquiries taken by Gartner analysts Akif Khan and
Jonathan Care during 2021.

Recommended by the Author

Some documents may not be available as part of your current Gartner subscription.

Gartner, Inc. | G00756888 Page 13 of 14

This research note is restricted to the personal use of cavieira1@topazevolution.com.

 Market Guide for Online Fraud Detection
How to Create a Payment Fraud Detection Strategy at the Organizational Level
Best Practices for Better Online Payment Fraud Detection RFPs
Quick Answer: How Do You Reduce Fraud in the Contact Center (Phone) Channel?

© 2022 Gartner, Inc. and/or its affiliates. All rights reserved. Gartner is a registered trademark of
Gartner, Inc. and its affiliates. This publication may not be reproduced or distributed in any form
without Gartner's prior written permission. It consists of the opinions of Gartner's research
organization, which should not be construed as statements of fact. While the information contained in
this publication has been obtained from sources believed to be reliable, Gartner disclaims all warranties
as to the accuracy, completeness or adequacy of such information. Although Gartner research may
address legal and financial issues, Gartner does not provide legal or investment advice and its research
should not be construed or used as such. Your access and use of this publication are governed by
Gartner’s Usage Policy. Gartner prides itself on its reputation for independence and objectivity. Its
research is produced independently by its research organization without input or influence from any
third party. For further information, see "Guiding Principles on Independence and Objectivity."

Gartner, Inc. | G00756888 Page 14 of 14

This research note is restricted to the personal use of cavieira1@topazevolution.com.

Table 1: Drivers to Build a Strong Business Case

Fraud KPIs Governance IT Operations

■ Reduce silos between multiple fraud platforms ■ Improve explainability into machine learning ■ Reduce number of platforms across the
(ML) decisions business
■ Reduce case management workload
■ Improve ML performance predictions ■ Reduce burden of on-premises management
■ Reduce investigation costs
■ Improve ML promotion controls ■ Improve efficiency of ML model maintenance
■ Reduce false positives
■ Address bias in ML models
■ Reduce fraud

Source: Gartner (January 2022)

Gartner, Inc. | G00756888 Page 1A of 3A

This research note is restricted to the personal use of cavieira1@topazevolution.com.

Table 2: Fraud Detection Capabilities

Capability Description

Data Ingestion and Responses Supported methods for sending transaction, event and interaction data for
monitoring and receiving responses

Products, Channels and Events Supported Breadth of support for banking products (e.g., cards, wire transfers),
channels (e.g., online, contact center) and events (e.g., payment, login,
account update, password reset)

Fraud Detection Key metrics relating to fraud detection efficacy

Rules or Policy Engine Approach to enabling creation and management of rules and policies for
fraud detection

ML How ML is deployed and managed to deliver fraud detection

Governance, Bias and Explainability Approach to ensuring that ML capabilities are subject to oversight and
control

Consortium Data Sharing of data between a vendor’s banking clients for mutual benefit

Authentication Support Whether native authentication tools are offered on the platform or can be
orchestrated via risk-based assessment

Digital Risk/Trust Signals Support Whether native tools to detect risk in digital channels are offered on the
platform

Third-Party Connectivity Breadth of prebuilt integrations to other vendor solutions

Gartner, Inc. | G00756888 Page 2A of 3A

This research note is restricted to the personal use of cavieira1@topazevolution.com.

Capability Description

Case Management Approach to enable users to manually investigate transactions

Graph/Network Visualization Details of any visual network analysis tools on offer

Reporting Scope of reporting insight on offer to users

Source: Gartner (January 2022)

Gartner, Inc. | G00756888 Page 3A of 3A

This research note is restricted to the personal use of cavieira1@topazevolution.com.