Cross-Cutting Practices

Practice 1: Fraud Definitions

(Liability) (Tools) (Data)

The IIPS provides a framework for defining fraud types.

A common global framework for talking about the push payments fraud does not yet exist. Clarity and consistency in defining fraud is needed for effective collection of fraud data, analysis of fraud patterns and trends, assigning of liabilities, and as a result, stronger risk mitigation.

Definitions and classification frameworks are often developed through collaboration. Regulators often serve as the ecosystem conveners. IIPSs may also lead these or support these efforts.

IIPSs’ scheme rules can mirror or reference existing definitions and fraud type frameworks; in cases where they do not exist, scheme rules should provide them.

Example: The FraudClassifier model (see below), which was developed by the payments industry under the leadership of the US Federal Reserve to provide a basic fraud classification. At the highest level, it categorizes fraud based on who initiated the payment (an authorized or unauthorized party) and how it was executed.

Practice 2: Typologies Catalog

(Tools) (Data)

The IIPS leads or participates in collaborative efforts to define and evolve a fraud typologies catalog. The catalog is made available to DFSPs for use in transaction screening.

A common language for talking about fraud is essential, but alone not sufficient. Fraudsters perpetrate fraud in a myriad of ways, which include sophisticated tactics and multistep approaches along a payment journey. A close understanding of the details of fraud typologies will allow ecosystem stakeholders to identify and put in place appropriate controls. Specifically, typologies can be reflected in transaction monitoring systems as a set of rules used to screen for potential fraudulent payments.

Creating an accurate and comprehensive fraud typologies catalog will require collaboration. Fortunately, in many markets DFSPs, IIPSs, regulators, and other experts within the ecosystem commonly meet to align on best practices.

The most useful typology will provide a framework for cataloguing and reflect true fraud vectors, as they evolve.

Practice 3: APP Is Fraud

(Liability)

The IIPS considers payments that have been authorized as a result of social engineering, in which the legitimate end user is not complicit, to be fraudulent.

Financial liability rules should scope fraud to include the most common and concerning fraud types. Specifically, payments that are confirmed to have been authorized as a result of social engineering, in which the authorizing end user is not complicit, should be considered fraudulent.

The fraud definitions framework provides an important base for successful alignment with this practice.

Example: This is a topic of active current debate by regulators and IIPS. UK regulators are pushing for regulations to require payment service providers to reimburse funds lost to end users due to APP fraud. The European Commission is evaluating adding APP fraud to its liability and refund rules. In the US, IIPSs (most notably, Zelle) are increasingly under pressure to incorporate more clarity in their rules on fraud liability.

Practice 4: KYC Controls

(Rules) (Tools) (Data)

The IIPS requires DFSPs to apply controls appropriate for each KYC tier and customer risk profile.

DFSPs are naturally incentivized to appropriately align controls to each customer risk profile and KYC tier to manage their risk exposure.

Controls may pause services. For example, DFSPs may require that a new customer cannot withdraw funds deposited into their account for a certain (short) time period. This type of control can help DFSPs to identify if the new account was opened in order to perpetrate fraud.

Controls may limit services. Limits on the value or volume of transactions that a customer is permitted to conduct can also be beneficial. While the application of limits is not strictly a fraud prevention tool, applying these limits may minimize the financial impact of fraud events. IIPSs commonly elect to have high or no transaction value limits at the scheme level in order to enable a variety of use cases. However, they should not prohibit (and may encourage) DFSPs from setting lower limits for individual end user accounts.

Practice 5: Data Protection

(Rules) (Data)

The IIPS provides guidelines for confirmed fraud reporting and safe use of data to protect end user privacy and DFSP data confidentiality.

While data is a key enabler of fraud mitigation, data sharing, storage, and use may introduce other risks if it is not properly safeguarded. Consumer protection considerations should be incorporated into the design of all risk mitigation controls to ensure that end user data is protected.

Payment messages often capture and transmit rich data elements including sometimes personally identifiable information on end users. Sharing of that data, even for fraud mitigation, requires controls to protect end user privacy and DFSP data confidentiality. IIPSs can play an enabling role by establishing clear guidelines for participants on safe use of data, incorporating and building on available regulatory guidelines.

Guidelines may include requiring end user consent on use of certain data elements, limiting access to the data, and use of the data for fraud mitigation purposes only.

Next Topic in this Section: Before-Payment Practices