FRM for Central Infrastructures - Key Considerations

White Paper

FRM for Central Infrastructures - Key Considerations

As real-time payment systems expand globally, preventing fraud across multiple payment rails becomes increasingly challenging. In this white paper, we explore key considerations for building a centralized FRM system that is adaptive, intelligent, and secure. Discover how leveraging AI and real-time data can enhance fraud detection, reduce false positives, and support flexible, multi-rail systems. With insights from RS Software’s proven solutions, this paper offers a roadmap for creating resilient fraud management infrastructures at the national level. If you are ready to protect your payments infrastructure and learn how to safeguard your systems in a rapidly evolving digital landscape, read on.

Introduction

At RS Software, we have been developing central infrastructures across card and account-to-account (A2A) payments for the past two decades. In India, we built the UPI, the country's faster payment rail, along with a multi-rail real-time fraud and risk management (FRM) system, as an implementation of RS IntelliEdge™. According to Volt, 80 countries are currently in some stage of rolling out real-time payment (RTP), also known as faster or instant payment. Unlike earlier forms of payments, RTP does not have a settlement phase. Thus, fraud on real time rails needs to be identified and, the fraudulent money flow stopped immediately.

It is important to note that countries rolling out RTP or similar systems have often delayed building the fraud and risk management (FRM) system for RTP. Additionally, banks/financial institutions (FIs) have not considered deploying FRM for RTP on their end either. For instance, Pay.UK launched RTP in 2008, but an FRM system is yet to be launched. Only recently has the Confirmation of Payee (CoP) or Verification of Payee (VoP) been mandated in the UK and many other countries. In contrast, UPI was launched with CoP in 2016, while the full-fledged FRM was launched in 2018. 

Building the FRM system as a central infrastructure is a relatively new paradigm. In this article, we share our experience and outline the key considerations for an FRM system for a central infrastructure.

Key Considerations 

Federation

An FRM system as a central infrastructure must support federation by design, allowing individual banks and institutions to manage their own processes while collaborating within a unified, cohesive framework. Banks/FIs focus on specific demographics for their business, and their FRM systems are tailored to their client's payment behaviours. However, the central FRM system needs to cater to common causes and still be flexible to support the unique requirements of member banks. 

FRM systems must deploy fraudulent transaction filters from both deterministic and probabilistic perspectives, realized as rules and AI/ML models, respectively. The central FRM should allow rules at the consortium level, with banks providing overrides or creating their own rules. Common models across banks leverage larger datasets for more effective fraud detection. In this federated model, banks draft rules and set parameters suitable for their clients without sharing proprietary client profile information.

Operating the national FRM system in India for over five years, we've seen that most of the rules for detecting fraud are drafted by the member banks themselves, thus, harnessing collective intelligence to protect customers. 

The FRM system classifies transactions into three categories:

  1. Good Transactions: Legitimate and safe transactions.
  2. Confirmed Bad Transactions: Fraudulent activities identified with certainty.
  3. Alerts (Grey Transactions): Suspicious transactions that need further investigation.

When alerts are flagged, risk analysts at member banks review and act on them. This process helps improve the volume and accuracy of labelled data, which in turn enhances the training of AI/ML models used in the system. As volumes grow, so do alerts, necessitating productivity tools for risk analysts. 

At RS Payments Innovation Lab, we have innovated a solution to enhance efficiency of risk analysts leveraging AI and Gen AI-based co-pilot. This co-pilot will assist fraud analysts by providing real-time insights and offering intelligent recommendations for alert investigation. The co-pilot will streamline the case management process, enabling faster detection, investigation, and resolution of fraudulent activities while reducing manual effort and improving overall efficiency.

Accuracy

FRM systems must achieve high accuracy with low false positives. AI/ML models for detecting fraudulent transactions are probabilistic, with accuracy typically around 70%-80% and false positives around 20%-30%. While effective for unknown fraud patterns, increasing model complexity (more parameters and epoch numbers lead to overfitting and increased false positives. 

Deep Learning Models like RNN and LSTM can model temporal factors but require substantial data and energy. They become stale with drift detection and need frequent refreshing, adding latency. Simpler Artificial Neural Network (ANN) models respond faster to drift and require less computational resources. Decision tree-based models, like Random Forest, can be trained much faster than the deep learning models and are adept at handling structured data.

Rules, based on risk analysts' expertise, can take the shape of complex conditions with high efficacy. These complex rules usually need long-term aggregated data (e.g customer behaviour profiles), short-term high-fidelity information of the transactions from the recent past, profiles of the point of purchase, and many more. 

For optimal fraud detection, FRM systems must allow dynamic creation of sophisticated rules, which many existing platforms fail to support, limiting their overall efficacy in managing and mitigating fraud risks effectively.

FRM systems for central infrastructure cannot use the customer profile information that reside with banks. These profiles must rather be built, gleaning intelligence from transactions. Using such profiles has been found to provide accurate results as well. Combining AI/ML models with high-precision rules improves system accuracy.

Change

FRM systems must be flexible, responsive, and accurate enough to adapt to new payment rails and fraud types. In non-RTP systems, the FRM typically is applied comprehensively before the settlement cycle. However, with RTP, the authorization and settlement happen in one sweep. As new rails, such as real-time payment rails, are rolled out, the scenario changes for both fraudsters and the preventive technologies associated with the same. This necessitates new FRM solutions to be flexible, highly responsive, and accurate enough to address this change.

An FRM at the central infrastructure provides a holistic view of multiple payment rails, enabling cross-channel fraud detection. We have witnessed such patterns emerge once an RTP rail gets rolled out in an ecosystem that already has existing A2A payment rails. Thus, the FRM system at the central infrastructure not only needs to support the new payment types but should also cater to multiple rails from a single platform and have the capability to detect channel-hopping fraud. 

Multi-rail FRM systems reduce operating expenses and total cost of ownership (TCO) while providing multi-channel business monitoring from a single point. At RS Payments Labs, we are developing dashboards for detailed telemetry across channels to detect systemic stress and prevent impacts proactively.

Technology

Existing FRM solutions use legacy and/or proprietary components, limiting integration and future extensions. Modern solutions must support API-based interaction with microservices architecture, aligning with customers' enterprise technology strategies. 

Open banking adoption requires modern technology for detecting fraud from payments that are invoked from third-party constructs. The design must consider scalability, ensuring rule execution time is independent of rule complexity. To address exceptions the system needs to have a “safety valve” construct so that the platform is not impacted adversely by inadvertent inefficient rules. 

While AML systems are usually removed from transaction FRM systems, global best practices recommend that FRM and AML (also known as  FRAML) be brought closer both in technology and operation as RTP adoption increases. Banks share their Suspicious Activity Reports (SAR) with the Financial Intelligence Unit (FIU) typically once a month to detect money laundering. However, with RTP, a delay of a month is not suitable and there could be an interim need for investigating suspicious money movements. The FRM platform for multi-rail deployed as a Central Infrastructure provides the opportunity to investigate money movements across bank accounts. A key consideration of the technology design is to enable such an AML Assist functionality.

Sustenance 

Central Infrastructure has a significant societal impact, necessitating greater control over solutions and scope for custom builds. This involves using one or more of the following:

  • Composable Components: To build the solution, the customer may want to use some existing components they might already have in production and buy and integrate the other components. This provides a lower-risk path for the customer. However, the products themselves need to be aligned with the composable component paradigm, otherwise, the components would not integrate easily to create the whole.
  • Layered Feature Enablement: If the customer chooses to “build” or “extend” the component they have procured, they will typically need the source code, especially for the middleware and surface features. Unless the products are built in said paradigm, which in certain parlance is referred to as “Core, Mantle, Surface” layers, this flexibility cannot be provided. If it is built using the Core, Mantle, and Surface layers, the custom build is typically done in the Surface and/or Mantle layers while keeping the Core intact. 
  • Flexible Deployment Models: While some customers would want the system to be deployed on-premises in their data centers, others may be flexible to use a cloud-based deployment or SaaS deployment and there could be many options between these two extremes. The solution as such should be able to support multiple deployment formats but may be constrained by the operational parameters of latency, availability, reliability, etc.

This enables Central Infrastructure authorities to have larger control over the solutions deployed.

In Summary

The key considerations for an FRM system as a Central Infrastructure need to include the following – F.A.C.T.S.,

  • Federated: Offering member institutions to have their own rules and parameter values enables leveraging consortium intelligence without sharing client profiles which is the proprietary knowledge of banks; this consortium power also improves the efficiency for reviewing the alert cases to build better labelled data.
  • Accuracy: Utilize the power of probabilistic data filtering (using AI/ML) as well as the power of deterministic rules that look at long-term profiles and short-term datasets of the payment instrument to provide very high accuracy of fraud detection with low false positives. The AI/ML model selection should be lightweight so that it can be refreshed often and changed in-flight so as to not delay when “drift” is detected in the models.
  • Change: New rails would bring new fraud types and hence the existing fraud detection strategies would have to change, and the platform needs to support that; moreover, an FRM as a Central Infrastructure provides an opportunity to look at channel-hopping fraud and plug the same.
  • Technology: The technology stack of the new FRM should not have technology debt. It needs to support new ways of data interchange such as APIs, with the capability to handle differential loads via microservices. The technology should be flexible to support enterprise stack and deployment preferences (on-premises, cloud, SaaS). There should not be limitations in defining the rules as the rule complexities should not be constrained by the same. The solution should consider deploying technology to enable FRAML aspects since faster money laundering remains a risk with RTP.
  • Sustenance: The FRM at the central infrastructure needs to support custom build options. Hence the products need to cater to providing implementation of features realized via mix-and-match capabilities. This is possible only when the FRM product is built with a composable component paradigm.

RS IntelliEdge™

RS IntelliEdge™ from RS Software is an FRM product deployed as a central infrastructure, operating for over five years and protecting multiple payment rails, including UPI. It supports all key considerations mentioned, with high accuracy and low false positives. RS IntelliEdge™ supports a federated structure, with more than 90% of rules framed by consortium members and deploys fast-acting AI/ML models like Random Forest. It offers multi-channel fraud detection, a modern technology stack, and API-based data interchange. RS IntelliEdge™ supports composable components, work with pre-built models, and AML Assist for money laundering investigation.

Over five years of operation, RS IntelliEdge™ has handled diverse fraud scenarios, enriching the product for global deployment. With a proven track record and robust technology, it is ready to protect payment systems worldwide. 

Shared Intelligence

RS IntelliEdge™ approaches shared intelligence from dual perspectives: bottom-up – is what banks want to share within the consortium, and top-down – which consortium shares and banks would want to customise. 

While banks may be open to sharing “black-listed” actor details with all members of the consortium, they will not want to share bank account level details of their customers (age, ZIP code). 

Moreover, supporting a federated structure, our solution offers the banks the flexibility to customize rule thresholds for their own customers for a rule authored by the central.

As an example, we show two graphs which protects P2P payments on velocity (amount / time). 
Graph 1 is at consortium level, where we see multiple peaks indicating multiple attempts across several banks, yet the occurrences are maintained below 3% using consortium level rule thresholds, but in Graph 2, a particular bank applied specific threshold for the transactions belonging to their customers and managed to almost eliminate (<1%) the P2P velocity frauds. 

Note: Graphs show indicative value for illustration purpose only

There are thousands of such variations which can prevent fraud very effectively without increasing the false positives leveraging shared intelligence and federated overrides.

Leave a Reply

Your email address will not be published. Required fields are marked *

Comment moderation is enabled. Your comment may take some time to appear.