Increasing Speed Without Sacrificing Security
As the speed of payments processing and posting increases, what should banks and clearing houses do to guarantee the same level of security that they do in a same-day or next-day environment – or even improve it?

The best way to prevent fraud in systems of any speed is by making payment initiation more secure. Multi-factor authentication – the use of two separate devices and channels – is the most effective way to do this. Many countries outside of the United States have instituted two-factor authentication to send a credit transfer through online banking. In addition to the user name and password required to log on to online banking (first factor), customers must also input a one-time security code in order to send a transaction (second factor). This code can be sent via a mobile phone, generated via a token such as a key fob, issued via a hardened browser stored on a secured USB stick, or it can come from a paper-based slip with multiple one-time use codes. The central issue is that authentication takes place with a different device than for initiation.

Tokenization and Analytics
Real-time processing can transform the value proposition for mobile payments. Two of the most promising real-time use cases for mobile are point-of-sale applications and peer-to-peer products. Many consumers are uneasy about giving out their bank account details, but this concern can be alleviated by replacing the exchange of bank account information with a non-sensitive data element (token) that links to a customer’s bank account details, which remain concealed.

The token can either be a one-time use element that is generated at the moment of payment initiation or it can be a persistent proxy number such as a phone number or email address linked to a person’s bank account details via a secure database. In addition to the added security of not having to share one’s bank account details with another person or business, the use of proxy numbers also promotes ease of use since most people have not memorized their bank account details. Instituting a proxy number database does create an attractive honey pot for fraudsters, but securing it does not present more of a security challenge than current bank back-office infrastructure. More important, assuaging customer concerns helps drive adoption of real-time system technology and the products and services built on top of it.

There are a number of potential operating models the U.S. could pursue when developing a proxy number database for mobile payments. The U.K. has created a national universal database for all banks called Paym that is operated by its national clearing house, Vocalink, and stores proxy numbers for registered bank accounts in the country. Sweden has developed a service that individual banks can join, Swish, that enables customers of participating banks to send and receive mobile payments in real-time. Denmark has opted for a competitive model with multiple proxy databases that bank customers have to sign up for individually. Given the diversity of the U.S. banking market, the Danish model seems like the best fit for this country, where the key issue will be ensuring the interoperability of multiple mobile platforms.

The use of data analytics is also essential for preventing fraud in a real-time environment. The onus for fraud detection is mostly on originating banks, but payment system operators can use analytics to run pattern and velocity checks. Operators performing fraud checks with analytics may even be able to see fraud that individual banks cannot, such as cases where a suspicious number of transactions are destined for the same receiver account, which indicates it may be a mule account.

Rule Changes and Bank Policies
When a payment system moves to real-time, changes to the operating rules can help control fraud. Prime examples are omitting direct debits from the real-time system and checking for a valid authorization before funds are transferred. Direct-debit rules are more complex than those for credit transfers, and direct debit refund rights are also more generous. Preventing the ability of customers to initiate a pull transaction in real-time (where the payee initiates an ACH payment) is a best practice that has been adopted by every real-time system in existence today.

Banks that want to take extra steps to prevent fraud on credit transactions can also institute limits on payment values or volumes, or set thresholds to trigger a transaction review. These measures allows them to ignore smaller value payments that pose little risk of fraud and focus on higher value transactions or on transaction volumes to or from a specific bank account. When the Faster Payments system went live in the U.K., some large- and medium-sized banks lowered the daily maximum transaction value limits due to fraud concerns. One bank set a transaction limit as low as £6.00 at one point. These banks then bolstered their internal analytics and pattern recognition practices to further mitigate the fraud risk.

Best Practices for Industry Participants
Anti-fraud mechanisms – multi-factor authentication, tokenization, analytics, rule changes, and individual bank policies – ensure the overall security and stability of a real-time payments system, but their use differs by a bank’s role and by the status of a payment in the transaction chain. Depository financial institutions have the bulk of the responsibility when originating a transaction; payment system operators can contribute to fraud detection and security; and though depository financial institutions on the receiving end have very few mechanisms to detect or prevent fraud in credit transactions, they can play an important role in direct debits.

Originating Depository Financial Institutions
The easiest way to prevent fraud in a real-time environment is to stop fraudulent transactions at the point of initiation, and in a credit push payment environment, the ODFI is most likely to bear the loss in the event of fraud. ODFIs therefore have the greatest incentive to stop fraud and the highest probability of success. Measures start with account-opening procedures, secure practices for payments initiation follow, and analytics can then help, but to a lesser extent.

U.S. payment industry stakeholders should work together to determine whether the prevailing account-opening procedures are adequate to prevent fraudulent accounts. Some best practices from other countries would be impractical here, such as accessing a national fingerprint database to verify identity, as South African banks do. Denmark offers a more practical model to follow, banks there have built-in delays that prevent users from making payments for several days after opening an account. As this country transitions to a real-time system, banks should review what information a customer needs to provide in order to open a bank account and how long they need to wait before using it.

The most important thing an ODFI can do to prevent fraud is to institute multi-factor authentication for payment initiation. Having at least two layers of security means that even if a person’s login information is compromised or their computer is stolen, a fraudster would also have to have access to the device (mobile phone, fob, USB stick, paper) that contains a one-time code to initiate a payment.

ODFIs can use analytics, such as velocity checks and pattern recognition checks, to detect fraud that they otherwise would not notice. Analytics can also flag a suspicious number of new beneficiaries registered to an account, in which case an ODFI can then place a hold on payments from the account, review transactions, inform other banks and regulators, or reject the transactions outright. The use of analytics provides an extra barrier when fraudulent transactions are initiated.

Payment System Operators
In a real-time environment, the primary anti-fraud best practice for a payment system operator is to calculate the probability of a transaction being fraudulent (also known as scoring transactions), but then refer suspect ones to banks for decision-making instead of blocking the transaction outright. This allows operators to capitalize on the fact that they can sometimes detect patterns that banks miss, such as a suspicious set of transactions originating from multiple ODFIs and headed for the same RDFI or receiver. However, very few payment system operators around the world actually employ such techniques, and the reasons are varied. Many do not have the financial strength to accept liability for fraud cases that may slip through, and many operators have expressed concerns that establishing fraud checks could reduce the incentive of banks to establish effective prevention mechanisms. Nevertheless, such checks are common among large card processors and should be included in any set of best practices.

Receiving Depository Financial Institutions
For credit transactions, there is little an RDFI can do to prevent fraud outside of the normal know-your-customer and anti-money laundering/counter-terrorist financing procedures. By the time a fraudulent transaction has reached the RDFI, it is unlikely that the receiving bank can employ techniques that have not already been used by the originating bank or system operator. For direct-debit transactions RDFIs can verify that an authorization is in place, maintain and check white- and black-lists, and help reverse unauthorized transactions. However, there is no large system in the world that processes direct debits in real-time, as the complexity of direct-debit processing and refund rights make real-time direct debits impractical and more vulnerable to fraud. Some countries have sped up direct-debit processing so that they clear and settle multiple times a day, but real-time direct debits do not yet exist in any significant volumes.

Start With Credits, Avoid Debits
When developing a real-time system, the best practice is to institute real-time for credit transfers only. A few countries (such as Switzerland) claim to offer real-time debits, but these transactions are actually requests for real-time credit transfers, they are not true pull transactions. A payer can pre-authorize a push credit transaction to a payee, and the payee’s bank then has the authority to initiate this pre-authorized transaction. This method for real-time “debits” has proven to be secure in the countries that offer it, but they are not direct debits in the traditional sense.

There are good reasons why no real-time system in the world currently offers genuine pull direct debits. Many scheme rules require an RDFI to notify the ODFI (or the originator to notify the receiver) of a direct-debit authorization days before the transaction is settled. Direct debits can often require a notification period where a bank must inform its customer before money is drawn from their account, which can defeat the purpose of real-time. And almost all payment systems have lengthy return periods for disputed direct-debit transactions, which can discourage one-off direct debits and would likely produce skepticism from industry stakeholders were real-time direct debits under consideration.

It’s possible that real-time direct debits could be developed for a particular use case, but given the necessity of refund rights and the complexity of the fraud prevention they require, a system should only add real-time debits when the need justifies the marked increase in risk. The first country to do this will be blazing a new trail.

Striking a Balance 
When the United States moves to real-time, banks should strongly consider allowing consumers to initiate real-time ACH transactions to any valid bank account. This would be a marked improvement from the current way most U.S. ODFIs treat bill payment, allowing ACH payments only to pre-registered beneficiaries. Most countries with real-time systems today automatically allow all bank customers to use the real-time system without any special registration requirements for either payer or payee. The ability should apply to all ACH payments, whether real-time or same-day/next-day. There is no need to create institutional barriers to consumer and business use of the system.

Real-Time Security Demands Industry Participation 
Many view real-time processing as essential to enabling the development of new products and services in demand by corporates and consumers. Banks and system operators can mitigate the related fraud risks by instituting multi-factor authentication for payments initiation, using tokenization to keep bank account information private, applying analytics to detect broad patterns of fraud, and limiting real-time processing to credits (push payments) only. Ensuring usability can be achieved by allowing customers to initiate real-time payments directly and by avoiding any kind of special registration process. By working together to institute these measures, industry stakeholders can ensure a fast, secure, and ubiquitous system for real-time payments that paves the way for future innovation and flexibility.