Real-Time Payments: 4 Requirements for Scam Protection Systems

How to design a multi-CSM (clearing and settlement mechanism) RTP solution for maximum fraud and scam protection

This is a post co-authored by Alexandre Graff with Krishanu De, senior director, head of Payments, Risk & Compliance at Cognizant, and Manan Gauba, head of Strategy and Partnerships, BFS at Cognizant.

The growth in real-time payments has been well-documented globally, but rising in parallel are scams and fraud. To stop this “scamdemic”, financial institutions must evolve their systems to enable the huge growth potential of RTP while increasing consumer protection from scammers. In this post, we’ll discuss some essential considerations for designing such an RTP system, especially one that works with multiple Clearing and Settlement Mechanisms (CSMs).

First, it’s worth summarizing the huge growth in the RTP space. RTP systems are expected to grow at a CAGR of 21.3% between 2022 and 2027. More than 70 countries have already adopted RTP in some fashion. A recent FICO survey shows that consumer adoption is keeping pace:

  • 90% of more than 14,000 consumers from 14 different countries polled have used RTP
  • 38% use RTP more than five times per month
  • 88% plan to maintain or increase use of RTP in the coming year

A global wave of scams has shadowed RTP’s rapid adoption, resulting in more consumers suffering significant losses.

  • Financial crime and fraud are projected to cost banks and financial institutions $40.6B globally by 2027.
  • In 2022, 20% of all consumers worldwide were victims of payment fraud, of which ~27% was Authorized Push Payment (APP) fraud, the most common form of fraud related to RTPs
  • APP fraud losses are expected to climb to $6.8B by 2026 at a CAGR of 11% (2022-27) across six major RTP markets (US, UK, India, Brazil, Australia, and Saudi Arabia).

Changes in Clearing and Settlement Mechanisms

We have also seen the introduction of new RTP CSMs, such as FedNow, which the US Federal Reserve launched last year to replace The Clearing House. Indeed, some markets now have multiple CSMs.

RTP fraud system diagram

 

Banks operating in RTP ecosystems with multiple CSMs typically have the option to integrate with more than one. While this means additional complexity and cost it also gives banks the ability to transact with more counterparties, which invariably attracts a larger customer base.

Many financial institutions have begun enabling instant cross-border payments. For example, BIS Nexus is connecting Europe’s TIPS with ASEAN-5. Elsewhere, Singapore and Indonesia have a cross-border QR code-based payment already in place. These regional networks bring additional opportunities for banks and PSPs to capture an international client base.

Fraud Risk Grows with Multiple CSMs

A fraud-resilient integrated solution approach is required for creating instant payment hubs or enabling RTP rails that process domestic RTGS, ACH, or SWIFT transactions. The nature of real-time payments poses additional challenges for fraud systems, demanding more powerful fraud prevention safeguards that stop scams before they take place.

How can fraud be detected even before the payment hits the payment hub? Network and counter-party collaboration is the key — sharing the data characteristics of fraudulent transactions through the Payment Market Infrastructure service is essential for combating counter-party fraud and will provide better protection for consumers. Additional AI/ML-based suppression layers of protection against sophisticated threats would help detect and block RTP fraud with granular precision, reducing losses and improving approval rates. Detection of network decoding traffic and deploying firewalls to block suspicious transactions are some techniques for managing fraud early in the lifecycle.

How to Design a Multi-CSM RTP Solution for Maximum Fraud and Scam Protection

1.    Build in advanced scam detection techniques

Standard fraud prevention models and techniques are failing to detect RTP scams, for multiple reasons. The small size of most RTP transactions means its easier for fraudulent transactions to slip under the radar. Criminals often launder the stolen money through multiple account “hops,” making tracking and recovery harder. There are also fewer “red flags” with RTP fraud, as it’s generally the legitimate customer making the transaction.

This is why customized machine learning models are needed, which can identify multiple features required to confirm the identity and intentions of the sender. These models use new techniques, such as specialized behavior sorted lists (B-lists), which can determine the probability that the debit party is the authentic originator of the payment. B-lists also monitor key attributes of the originator’s payment history and learn what constitutes normal behavior for an originator, which means these models can detect anomalies that may be signs of a scam.

2.    Create Payment Command Centers guided by customized rule sets

The major challenge for banks and PSPs is to act instantly after detecting a scam, given that intervention must take place in real time. First, the right interdiction support must be baked into the payment flow for all RTP CSMs. Classifying detected fraudulent transactions against a predefined and agreed upon taxonomy for each participating RTP network is difficult for any risk scoring engine. Thus, it’s crucial for PMIs to separate authorized transactions from push-payments in order to apply the appropriate rule set. In fact, not only does the entire process of interdiction and regulatory reporting and compliance depend upon the classification rules defined by the PMIs for the CSMs and participating banks and PSPs, but those rules usually evolve over time. Therefore, any fraud detection and command action software needs to be easily customizable in order to support rule updates.

Setting up a separate RTP command center that can employ automated responses based on the appropriate (and easily updatable) scenario-driven rule sets should be a critical consideration for banks and PSPs that process a large volume of RTP transactions.

3.    Stakeholder collaboration strengthens data modeling

Stakeholders should share their enhanced data and intelligence, as well as collaborate in order to reduce fraud more effectively. Solution design can also foster collaboration by allowing easy API access to third-party providers, making data source modification easier. Integration with credit bureaus is crucial for sourcing individual and corporate credit history, eligibility scores, credit types, interest rates, and more. Access to PMI data—including fraudulent transaction history, watch lists, compliance metadata, and settlement reports for both domestic and cross-border transactions—is also of utmost importance. Finally, several third-party firms and organizations can source know-your-customer (KYC) information, aggregated transaction data, channel data, financial information data, and ratings. Banks and PSPs should always seek out ways to make their intelligence more comprehensive, and they should be supported by a solution that facilitates connectivity to these data sources.

4.    Leverage both internal and RTP network data and controls

Instant PMIs such as FedNow provide certain capabilities for preventing fraud through various transaction limits (network- and participant-level) and through participant-defined negative lists. Typically, network-level limits are defined by the PMI, whereas participant-level limits are set by banks and PSPs. Participating banks and PSPs need to fully leverage these capabilities to fight RTP fraud. In terms of internal tooling, transactional fraud models have been very effective in fighting account takeovers, CNP fraud, etc.

However, RTP transaction fraud requires more sophisticated tools to detect scams that fall in a more ambiguous area that will often look like authentic transactions. The best approach to tackling this problem is a consortium-based model that detects anomalies in the consumer’s behavior and fed by the data sources we’ve discussed.

Additional Design Considerations

  • Manage all RTP transactions through an RTP hub.
  • Adopt ISO 20022 as the internal message formatting of the RTP hub — this will be the most common format.
  • Ensure you have configurable and scalable translation and orchestration. This allows legacy systems to coexist with the new messaging standard and aids in gradual transition from a fragmented ecosystem to a standardized target architecture.
  • Employ a sound framework for selecting your solution. Prioritize considerations such as the supporting RTP CSMs, geographical coverage and NFR requirements.
  • Develop a detailed data transition plan and prepare for contingencies. The process of data mapping from existing channels to a new RTP CSM transaction processing hub can lead to data truncation and other snags. Test rigorously during the transition and be ready to troubleshoot.
  • Take an iterative approach to your RTP transformation. You will want to roll out your RTP hub in phases, especially if you’re participating in multiple CSMs. This is primarily to ensure you maintain interoperability with your back-end systems and third-party services.

Learn More About RTP and Fraud Prevention

chevron_left Blog home
RELATED POSTS

Take the next step

Connect with FICO for answers to all your product and solution questions. Interested in becoming a business partner? Contact us to learn more. We look forward to hearing from you.