Fraud Management: Where Should Fraud Be Managed?

There are many aspects of risk management in the operation of any payment system. In this section, we look specifically at fraud management. In most traditional payments systems, the service providers (normally banks) assume responsibility for detecting fraud in payments to/from their end-customers. This includes correctly managing the “know your customer” (KYC) requirements of their regulators, as well as identifying, controlling, and resolving issues of transactional fraud. In some cases, the payment scheme provides various fraud management services, and/or requires participants to contribute data which is used for these services. Requirements for fraud management derive from regulation, from scheme operating rules, and from the business practices of providers. Some operating rules transfer fraud liability under certain circumstances: this is addressed in another section (see Issue: Safety).

With payments services being built, in some cases as a brand-new service, there is an opportunity to consider changes to the traditional model (Note that this excludes authentication fraud, or correctly identifying the consumer using the device: that remains the responsibility of the DFS provider). In this section, we examine the merits of a more centralized approach to fraud management. A centralized fraud management service would work at the hub or switch level to help participants manage fraud, money laundering, and other risks. The centralized service would collect data on applications and transactions and identify potential risks. The management of services against these identified risks would be up to the participants.

Option “A”: Fraud management should be done primarily at the participant level

This is the traditional payments system approach. This approach supports the primary responsibility of the participant to detect and control fraud, and makes those participants liable (to regulators and their investors) for failures to control fraud. The approach enables participants to compete on the quality and cost of their fraud management activities.
Arguments against this approach, include: Each provider has to independently invest in similar fraud detection and monitoring capabilities, which is economically inefficient. Each participant does this using primarily their own data: their analysis is limited to insights derived from this data. Fraud management is arguably a poor sphere for competition amongst providers.

Option “B”: Fraud management should be done primarily at the hub, on behalf of participants

The analysis and detection of fraud is a data-driven exercise. With all participants pooling transaction data, the hub can make better analyses and detect patterns not discernible from individual provider data. A shared approach to the data analysis will reduce participant costs and improve the quality of fraud detection.
However, without control over the fraud detection analyses, participants will believe they cannot control their exposures; participants may see their fraud management as a competitive asset; participants may worry about excess costs from a centralized approach. Making this approach work would require “on-us” transactions (where the sending and receiving participants are the same entity) to be put through the hub, something some participants would resist on cost and business privacy grounds.

The Financial Inclusion Perspective: Option “B” is preferred

The Level One Project Guide prefers fraud management at the switch or hub level, both for cost reduction and fraud management quality reasons. Often, providers will stop providing service, or sharply reduce service levels, when fraud starts to spike: we want to be able to proactively prevent fraud and react quickly to it when it starts to occur. Note that this is related to the participation issue, in that participants vested in the rule-making process will be able to have a say in how the centralized fraud management is handled. (See Issue: Participation.)