Before-Payment Practices

Practice 6: Sender Authentication

[Rules]

The IIPS requires DFSPs to utilize multiple tools and controls to authenticate end users.

Sender authentication tools verify that the sender is who they claim to be. Different tools may support authentication.

Multifactor authentication is a common approach that requires the end user to verify their identity with a combination of something they have (e.g., a mobile phone), something they are (e.g., their fingerprint or iris scan), or something they know (e.g., a PIN or password). Use of multiple methods to authenticate senders will more effectively prevent fraud.

Not all tools will be applicable to each end user, context, or use case. For example, an end user that
relies on a feature phone cannot biometrically authenticate but will be able to verify their identity with their phone number and PIN. A DFSP may additionally apply device identification methods, such as matching the user’s identity to physical device identifiers.

Example: India’s UPI system provides a set of prescriptive end user authentication requirements.

Practice 7: Confirmation of Payee

[Rules] [Tools]

The IIPS enables a confirmation of payee (CoP) service that allows end users to verify the name of the receiver prior to initiating a payment.

A confirmation of payee service may prevent authorized push payment fraud where a sender is scammed to sending a payment to
a fraudster’s account. (It can also prevent funds being sent to an unintended party due to errors in keying their alias or account number.) The application of CoP allows the end user to see the name (e.g., first and last name of consumer or name of business) associated with a receiver’s account number or alias prior to sending a payment. An unexpected name may signal to the end user that the receiver is not the intended party, leading them to cancel the payment.

CoP introduces an additional end user touchpoint  into the payment initiation flow. When well designed and implemented, CoP can contribute to preventing fraudulent payments, making the additional step a worthwhile trade-off.

Example: UK’s Faster Payments has enabled confirmation of payee. Pix also mandates that payee identification be displayed in the payer’s screen at payment initiation.

Practice 8: Internal Fraud

[Rules]

The IIPS requires DFSPs to implement controls designed to prevent a DFSP employee from perpetrating fraudulent payments.

Fraud may be perpetrated by DFSP employees. The application of internal operational controls contributes to preventing this type of fraud. At a minimum, these include controls that strictly restrict access rights to critical transaction systems, dual controls that require more than one individual to initiate or review transactions, and separation of duties that prevent a single individual from playing too many important roles in a process.

Practice 9: Account Naming

[Rules]

The IIPS requires DFSPs to utilize clear and descriptive account-naming conventions.

For tools such as confirmation of payee to work effectively, DFSPs’ customer onboarding processes need to ensure that internal names assigned to consumer and business accounts provide a clear indication of who the customer is. For example, a company account could be identified by the company name and a consumer account by the first and last name of the account holder or other preferred identifier (e.g., a nickname or initial for first name). As part of the confirmation of payee, the name of the payee should be displayed to the payer once they enter the alias for the receiver’s account.

Clear account naming is relevant across use cases. For example, in a QR-enabled merchant payment, fraud may be prevented by displaying the merchant name to the payer before they confirm the transaction.

Practice 10: Education

[Rules] [Tools]

The IIPS requires DFSPs to educate end users, employees, and partners on fraudster tactics and mitigation practices on an ongoing basis and at payment initiation using proven approaches.

End users contribute to mitigating fraud by staying alert to fraudster tactics and when possible, stopping a fraud attempt by not initiating a suspicious payment. An end user educated about fraud can be a powerful tool of fraud prevention, but it is just one tool and alone will not prevent all fraud events.

For fraud education to be effective, it needs to be multilayered, part of multiple stages of the end user payments journey, and appropriate to the local context. Use case specific education, such as educating customers to be alert to fake merchant QR codes, should also be considered. Ongoing education may be provided through a variety of channels. Education must be designed for low-income and women end users and be delivered in a relevant format and language.

The moment of payment initiation may provide a particularly good opportunity for just-in-time education. For example, when a payer initiates a payment to a merchant by scanning a QR code, they could be shown a message that reminds them to always validate that the QR code is indeed for the merchant they want to pay. An effective approach will consider the benefits of education against the trade-off of introducing too much friction.

The IIPS may play a role in supporting DFSPs in these efforts. For example, campaigns aimed at spotting fraud may be incorporated in broader IIPS advocacy or branding campaigns. The IIPS may consider developing and sharing guidelines or resources on user experience (UX) methods that have proved to be effective in capturing end users’ attention.

There is no “one size fits all” approach to impactful education and achieving impactful education is challenging.¹ IIPSs and DFSPs should measure the effectiveness of their approaches and evolve them over time.

1. Callsign, White Paper on Online Fraud.

Next Topic in this Section: During-Payment Practices