Say 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. Electronic payments are great, yet your business is ready to move quicker.
Faster payments will allow your business to enhance the experience of your offering.
At Dwolla, we can propose various account-to-account payment solutions using the different payment types of the Dwolla Platform (e.g. Same Day ACH, Next Day ACH, Real-Time Payments, Push-to-Debit), but first we want to provide some guidance around how to responsibly manage the risk with faster payments.
Because yes, faster payments are secure, when managed diligently.
- What are ACH Payments?
- What are Real-Time Payments?
- Risk With Faster Payments
- ACH Returns vs Credit Card Chargebacks
- Payment Risk Management
- Having a Fraud Prevention Plan
- Documentation, Guides and Additional Resources
What Are ACH Payments?
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 user depositing funds into a digital wallet within an application.
While the rate of fraud is relatively low with ACH payments compared to other payment types, there’s always risk involved when working with payments. A 2018 Federal Reserve report found ACH payments had the lowest fraud rate, by value, among the top three non-cash payment types in the United States: cards, checks and ACH.
What Are Real-Time Payments?
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. With Dwolla, businesses can toggle between an ACH payment and a real-time payment with a simple channel request change in the Dwolla API.
One of the differences between ACH and RTP is that the financial institution that is sending and receiving the RTP transaction must choose to participate in the RTP® network through an agreement with The Clearing House. It’s important to note that not all banks currently participate in the RTP network. Other differences include the settlement times between ACH and RTP, along with the rails the transactions travel on.
Dwolla partners with innovative financial institutions to allow businesses to keep their existing banking relationships and still send instructions for transfers directly through our RTP API. This means you can send transfers over the RTP network without directly integrating with a participating bank.
Most payment systems–including ACH, cards and checks–offer a way to dispute, recall or stop a payment before or after it is processed. With the RTP network, all participants have agreed 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. This means participating banks are required to have funds available at the Federal Reserve at the time they initiate payouts. As a result, banks participating in the RTP network require the same level of confidence in their account holders who transact 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.
Risk with Faster Payments
Speeding up an ACH transaction doesn’t speed up the return code timeline. Some of the most common return codes still take up to two banking days to post.
So let’s say money has moved from a sender’s external funding source to a receiver’s external funding source using next day debit and same day credit. The receiver could collect their funds the next day or the day after the payment was initiated, congrats!
What happens when a return code comes back on the sender’s account within the return window?
Administrative returns, such as R02 – Account Closed or any returns due to administrative or account data errors, are received from the account holder’s bank and automatically processed within that two banking day timeframe. There are also 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, which can be received by the account holder’s bank and processed automatically within 60 calendar days.
Keep in mind that ACH is a consumer friendly payment option and allows for the account holder to work with their bank to claim unauthorized activity between one year for business accounts and two years for consumer accounts. Dwolla manually reviews these outliers to ensure user names match account holder information. No matter the return code or reason, clients receive the information via the API with the return processing information.
The automation of the return process and notifications to your business once a return code is issued continues to be a real value-add for scaling organizations.
Bottom line? Faster payments are great but they do create risk that your business needs to be aware of to responsibly manage payment risk for any losses.
ACH Returns vs. Credit Card Chargebacks
ACH returns are sometimes referred to as “ACH disputes” or “ACH chargebacks” but while those terms might seem like synonyms, they are crucially different. “Disputes” and “chargebacks” are terms heavily used in the credit card space and imply that there is a third-party arbiter looking at evidence from all parties to a transaction and determining a fair outcome.
Chargebacks and disputes do not happen during the ACH return process.
An ACH payment is not “disputed,” which hints that it may be resolved, nor is it “charged back,” the transaction is simply returned.
Payment Risk Management
Is it possible to manage the risk related to faster account-to-account payments? Absolutely.
Since Dwolla clients are responsible for the payment risk associated with their applications, Dwolla reviews the financial health of your company along with the transactional health of previous ACH payments that your business may have with other providers. If you don’t have that history or if your history doesn’t depict your platform as a low-risk business related to payments, then Dwolla may ask to review your financial health through a current year balance sheet or other financial documents.
In addition to having a solid fraud monitoring and know your customer (KYC) program, the first thing we suggest is starting with standard ACH transactions. We can also help by implementing specific send limits for your platform.
If your users only ever send $500 or less, then it doesn’t make sense to set a sending limit above that. You can also limit your users’ ability to utilize faster payments programmatically.
For example, you can build a rule into your software that the user must complete ten successful standard-speed transactions before they have access to faster payment speeds.
Additionally, you can utilize a third-party balance check feature to make sure you are avoiding the most common return code—insufficient funds (R01) and identity verification that allows you to verify the account holder’s name to compare to your user’s information through our partner Plaid.
Developing Your Risk Appetite
For both ACH and RTP payments, users should be extra vigilant about not sending payments in error or exposing their credentials to potential fraudsters. Remember, once a real-time payment is sent there is no opportunity to cancel, stop or initiate a return. The finality of an RTP transaction allows participants to consider a payment complete without having to wait days for the funds to actually become available.
Noting again, Dwolla does not handle fraud protection or fraud mitigation on behalf of our clients. Our clients have more contextual information about the end users interacting with their applications 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.
For those reasons, Dwolla expects our clients to responsibly implement the fraud prevention controls most appropriate for their situation. This includes the processes, procedures and monitoring programs necessary to protect your business and prevent potential losses.
Having a Fraud Prevention Plan
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 their 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 will need to take responsibility in managing their risk and that of end users by ensuring:
- Confidence in the identity of the recipient of any transaction initiated.
- Established controls to verify the amount of the transaction is correct before being initiated.
- Procedures are in place for handling potential disputes with receiving parties directly.
Implementing dual approvals and verification steps can assist in preventing errors in sending a real-time payment. For example, a business can create a two-step approval process where the user verifies the information submitted and agrees to continue with the process of the payment with an acknowledgement that all transactions are final.
Businesses that support payments between their users may want to consider developing a strategy to group users into tiers based on risk exposure. If a new business or consumer signs up for your platform, it might be wise to require them to establish a successful transaction history utilizing other payment methods before allowing an improved experience by granting access to faster payments.
It should be strongly considered to forgo the option of a faster payment if the receiver is not a known business or individual to the sender or otherwise creates an unacceptable level of risk.
Another option could be allowing users who undergo advanced due diligence, i.e. providing financial statements along with a personal ID for additional verification, real-time capabilities.
The processes and procedures laid out above can function most effectively if they are coupled with suitable system design principles and automated mechanisms.
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, otherwise they could end up being responsible for erroneous payments.
Consider the following types of preventative, detective or corrective controls:
- Ensure that all users (or applications) that are able to initiate faster payments are strongly authenticated. This means properly storing passwords and ensuring they require sufficient complexity, as well as making use of multi-factor authentication to mitigate any remaining password-related risk. In the case of automated processes, using a secure scheme, such as OAuth2, can prevent abuse.
- If the sources of RTP requests are known and static, such as a fixed endpoint in cloud infrastructure, further mitigate the risk of abuse by restricting access to any payment-initiating endpoints by IP address. If risk considerations warrant it, go further with Mutual TLS authentication.
- Be sure to limit authorization to send faster payments to only those users and applications that require that ability. Keeping this list as small as possible will keep multiple risk factors at bay.
- Ensure any public-facing portions of your application, such as login pages or API endpoints, are appropriately protected against abuse by automated tools or botnets. This can include the use of CAPTCHAS, where appropriate, using a third-party service to protect perimeters or ensuring password lockout or login rate-limiting controls in place on login forms.
- Monitor systems to flag any unusual activity, such as payment requests from unexpected users, IP addresses, user agents or other indicators such as large volumes of incorrect password attempts. The horse might be out of the barn at that point, but the sooner people are aware, the more effective your incident response procedures will work to mitigate the issue.
- Investigate the ability to identify anomalous transactions by other indicators, such as volume, timestamp, destination, etc. These considerations are very situation-dependent.
Make it Hard for Bad Actors (and Easy for Good Ones)
Be successful in deterring bad actors by implementing the right tools and procedures. We have found that businesses often find success by adding friction with additional steps in the onboarding process. This is not meant to create a poor user experience, but instead can give peace of mind.
Consider incorporating two-factor authentication, email verification or requesting additional documentation to support user identity verification. More information is often better when it comes to protecting a business. Depending on the industry, it’s also important to keep an eye on regulatory requirements related to Know Your Customer (KYC) and Customer Identification Program (CIP).
Additional Risk Resources
- How to Handle the Complexities of ACH Returns & Reversals
- CIP & KYC: Why Knowing Your Customers Matters to Your Bottom Line
- Protecting Your Business From a Salami Attack
- 5 Best Practices For Protecting Users From Cyber Attacks