If your business is moving money electronically through the ACH Network and the standard transfer time of three to four business days is not fast enough for you or your customers, you may want to consider faster pay by bank payment options. Faster payments allow your business to move more quickly and enhance the experience of your offering.
However, they also introduce new risks. To protect your business and your customers, you need to develop new business processes and security measures that manage and mitigate those risks. This blog post provides some guidance around how to do so responsibly and effectively.
It’s important to understand there are two types of ACH transactions.
ACH credits push funds into an account, such as a direct deposit from an employer to an employee’s bank account.
ACH debits pull funds from an account, such as a utility company automatically deducting the amount of a monthly bill from a customer’s account.
With a Standard ACH transaction, after a transfer is initiated, funds can take up to 3-5 business days before they are available to the recipient. For those who need faster speeds, Same Day ACH allows a credit to or debit from a bank account to settle within the same business day.
While the rate of ACH payment fraud is relatively low compared to other payment types, working with payments always involves risk. In fact, the fraud rate of alternative payment types continues to rise according to the Federal Reserve. From 2018 to 2021, the value of possible check fraud grew 4 percent per year.
Back to Top
Real-time payments are transactions that are sent in near real-time to the receiver. Currently, RTP transactions are for disbursements (credits) only. The Clearing House created the RTP® network in 2017 to provide nearly-instantaneous payments between eligible bank accounts. Real-time payments are similar to ACH payments in that funds are sent between bank accounts.
Financial institutions sending and receiving the RTP transaction must both choose to participate in the RTP® network through an agreement with The Clearing House. (Unlike the ACH network, which is nearly ubiquitous, not all banks currently participate in the RTP network.) RTP transactions are also irrevocable – meaning that while there are options to request the return of an erroneous payment, there is no guaranteed or automated way to recover it.
An ACH return is a credit or debit entry that is typically initiated by a Receiving Depository Financial Institution (RDFI). It returns a previously originated credit or debit entry to the Originating Depository Financial Institution (ODFI) and can happen for a variety of reasons. For more information about common ACH return codes and reasons, check out our ACH Return Code Glossary.
With the RTP network, all participants agree that once an RTP transaction is initiated, that transaction is final and irrevocable. The RTP network is based on a good funds model and is strictly a credit (push) payment system. Participating banks are required to have funds available at the Federal Reserve at the time they initiate payouts, and they need to be confident in the funds being sent by their account holders transacting on the network. Sending financial institutions can ask a receiving bank to send back a payment sent in error, but the receiving bank is not obligated to honor the request.
Back to Top
The ACH return process is one of the elements that can introduce risk into faster payments. Speeding up an ACH transaction (for example, sending a Same Day ACH transaction) doesn’t speed up the return code timeline. Most common return codes still take up to two banking days to post.
Taking the example of an ACH debit from earlier, a utility company might choose to use Same Day to improve cash flow and pull funds from its customers with Same Day availability. Once the utility company has successfully debited its customer, the funds will become available the same business day. The utility company can move the funds from its operating account to investment accounts immediately – a win for its cash flow and for predictable timing for the customer. However, the customer may have mistyped their banking information or may not have sufficient funds in the account. In that case, the utility company’s account will be drawn negative when the customer’s bank sends a return code two banking days later and the funds are sent back to the debited bank.
Administrative returns - such as R01 - Insufficient Funds, R02 - Account Closed or any returns due to administrative or account data errors - must be received from the account holder’s bank and automatically processed within that two banking day timeframe.
An account holder’s bank can receive and automatically process unauthorized returns, including R10 - Customer Advises Originator is Not Known to Receiver and/or Originator is Not Authorized by Receiver to Debit Receiver’s Account, up to 60 calendar days after a transaction is initiated. For more information about common return codes and their timing, check out our ACH Return Code Glossary.
Since authorization is a key aspect of the ACH Network, it offers extended timeframes for claiming unauthorized activity. In certain cases, it allows for the account holder to work with their bank to claim unauthorized activity for up to one year for business accounts and two years for consumer accounts.
Bottom line? Faster payments offer many benefits to both businesses and consumers, but they do create risk that your business needs to be aware of to responsibly manage payment risk for any losses.
Is it possible to manage the risk related to faster account-to-account payments? Absolutely. The right mitigations will depend on your business’s specific funds flows, user types and risk tolerance. Many businesses use a variety of the strategies we’ll describe here in different combinations depending on the risks they are most concerned about.
In addition to solid fraud monitoring and know your customer (KYC) programs, if you’re a new business or a business new to account-to-account payments, you should generally start with standard ACH transaction timing and implement specific, practical send limits for your platform. If your users only ever send $500 or less, then setting a sending limit above that likely exposes you to unnecessary risk if your platform becomes a target of fraud or abuse.
Build smart payment flows. For example, you could build a rule into your application that the user must complete a certain number of successful standard-speed transactions before you offer them access to faster payment speeds.
Take advantage of data services. Additionally, if you are experiencing fraud or have high risk clients, you may find the following tools useful.
Use the contextual information you have about your users interacting with your application to understand whether a payment pattern makes sense for that user. The best people to understand normal payment patterns on your application–and thus detect fraud–are your own team members.
Users must be extra vigilant about not sending payments in error or exposing their credentials to potential fraudsters. This is especially important with real-time payments, because there is no opportunity to cancel, stop or initiate a return. Implementing dual approvals and multi-factor authentication are best practices when you offer RTP and can help prevent real-time payment errors. For example, a business offering RTP should create a two-step approval process for any payment initiation.
Businesses that offer payments should prioritize implementing appropriate processes and procedures to help prevent and mitigate returns. A high-level understanding of end users and how they’re transacting can help detect unusual activity. Some businesses are able to manually review all account activity for each of their users, but others either build monitoring software and reporting or use a third-party provider.
Monitoring software and reporting can be tailored based on criteria such as frequency of transactions, dollar amounts and IP addresses, but these are only some of the options to consider.
Again, knowing your end users will help you flag inconsistencies and risky behavior that can be stopped before they encounter a financial loss due to an ACH return.
Businesses take responsibility in managing their risk and that of their users by:
Businesses that support payments between their users may want to develop a strategy to group users into tiers based on risk exposure. If a new business or consumer signs up for your platform, you could require them to establish transaction history using other payment methods before giving them access to an improved faster payments experience.
Trust is an essential component of any online payment. When it comes to faster payments, you will want to apply that same principle. For businesses and individuals with strong trust (i.e. established relationships and significant vetting), faster payments can revolutionize information and payment flows and massively improve end user experience. If relationships aren’t quite as established, strongly consider removing faster payment options for receivers who aren’t known to the sender or are otherwise considered high risk.
Even with 24/7/365 customer service availability, when a transfer is initiated and completed in seconds, relying on trying to correct an error after the fact is risky. Businesses must take reasonable steps to ensure that transactions are authorized in advance, or they could end up being responsible for erroneous payments.
Consider the following types of preventative, detective or corrective controls.
Payments APIs have additional features and connectivity that can help you mitigate risk and prevent and identify fraud.
These APIs can integrate with third party providers and data aggregators that provide identity verification and balance check features. This can give you more confidence that the account owner is the one initiating the transactions and that the account they’re using has sufficient funds before the payment is processed. If you don’t integrate with one of these third party providers, many payments APIs have a micro-deposit feature for validating bank accounts.
Payments APIs can also provide up-to-date payment statuses and real-time webhooks. Up-to-date payment statuses give you visibility into each individual payment as it processes, while real-time webhooks proactively notify you about changes in payment status (including returns). Both these features allow you to identify problems and react to fraud quickly.
Finally, payments APIs can make payments more secure through tokenization. After a customer and account are set up in the API, there is no need to pass Personally Identifiable Information (PII) back and forth. To process transactions, the API tokenizes the customer identities, the bank account information and the transactions to prevent that information from being intercepted by bad actors. This also means that you don’t have to store that sensitive data in your application. Instead, you can simply gather the data and pass it through to the API provider.