During-Payment Practices
Practice 11: Shared Fraud Utility
[Rules] [Tools] [Data]
The IIPS provides a shared fraud utility tool to support DFSPs’ transaction monitoring activities.
The IIPS should require DFSPs to monitor for suspicious transactions and be capable of preventing potentially fraudulent transactions while minimizing the impact on legitimate transactions.
The IIPS should provide a shared fraud utility tool, available for implementation by individual DFSPs, that provides these capabilities at a low cost. The shared tool could be a complement to DFSPs’ transaction screening methods or be the primary DFSP screening tool depending on the specific market context.
The exact functions may vary, but at a minimum it should have the capability to score transactions based on their likelihood of being fraudulent, to be able to learn from past fraudulent transactions, and to be capable of accurate and timely reporting.
Foundational fraud utility services implemented by the IIPS are ideally offered as a core service at no or very low cost to participants.
Aspects of the shared tool may be implemented by the IIPS platform, to mitigate fraud across DFSPs.
Example: Pix allows the receiver’s DFSP to put a precautionary block on funds credited to an end user account, for up to 72 hours to conduct analysis in case of suspected fraud.
—
What should be included in a transaction monitoring system operated by a DFSP?
Transaction monitoring systems vary in their sophistication and design; for example, they may be rules-based or utilize machine learning and/or AI. They must be capable of incorporating data on past confirmed frauds to continually update what constitutes a suspicious pattern.
Each DFSP will need to determine the right implementation for their organization, though an effective system will learn over time from confirmed fraudulent transactions and minimize the impact on legitimate transactions.
To be effective, transaction monitoring systems need to be supported by DFSPs’ operational processes that include timely investigation and resolution of transactions flagged as suspicious. Consideration should be given to appropriate value thresholds to determine transactions that require investigation.
—
Practice 12: Bad Actors List
[Tools] [Data]
The IIPS provides DFSPs with the capability to submit a list of bad actors, which allows the scheme to screen transactions against the list, to reject any that trigger the list, and to share the list with DFSPs to flag accounts owned by the bad actor.
A shared bad actors list (sometimes referred to as a negative list) maintained and implemented at the IIPS platform level provides a complementary functionality to the fraud utility. The application of a negative list allows DFSPs to conclude if the sender and/or receiver are considered a bad actor. Based on the conclusion, a transaction can be rejected.
The implementation details (i.e., how negative lists are submitted to the IIPS, how new bad actors are added and others removed, and how the lists are shared between different DFSPs) may vary. The FedNow Service will have a negative list screening function that will be optional (and free) for DFSPs to use.
Example: FedNow will enable screening of transactions against the Negative List (at each DFSP’s discretion).
Practice 13: Payments Addressing
[Tools]
The IIPS provides a safe payments- addressing approach.
The IIPS utilizes a directory that enables aliases for payments addressing in lieu of end user account numbers. Multiple types of aliases, such as a phone number, email, national ID number, other ID number, or a randomly generated alias may be supported.
A QR code is another example of an alias, typically used to initiate merchant payments. To send a payment, a payer needs only to know the payee’s alias. Masking the account information from potential fraudsters can make it more difficult for them to perpetrate fraud.
Further, providing multiple options for an alias, including options that do not include personally identifiable information, empowers end users to choose an alias most suitable for them. For example, restricting aliasing to phone numbers may make it challenging for some women to send or receive payments if they share a single phone with their husband. Women may also not feel comfortable sharing their phone number to receive a payment.
Approaches to alias and account naming (Practice 9) should be considered together. An alias needs to be easy to remember and easy to share. An account name needs to be relatable to the receiver, and therefore the alias. In doing so, the scheme support the sender in ease of initiation transactions to the right receiver.
Example: Brazil’s Pix system enables the use of a randomly generated number.
The decision to inclusively mitigate fraud must permeate all IIPS design decisions. Safe payments addressing, whereby the payer does not need to know the payees’ account number to initiate a payment, is one important example.
Next Topic in this Section: After-Payment Practices