Skip to content
Payment Methods

Standard ACH
Standard processing times.

Same Day ACH
Expedite your payments.

Instant Payments
Transfers in near real-time.


Real-time notifications.

Correlation IDs
Tracking transactions and reconciling bank records.

Addenda Records
Additional transaction information, like a note or memo.


Open Banking Services
Instant account verification, balance checks and fraud mitigation.

Digital interactions result in unique identifiers.

Bank Verification
Smoother, safer, more efficient transactions.

Secure Exchange Solution
Securely exchange data with trusted partners.


Sandbox Environment
Simulate use cases and try out features.

Dedicated Support
Supporting your payments journey.

11 min read

Mitigating ACH and RTP Fraud Risks in Faster Payments

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 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.

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 Send Flow: Originator to ODFI to ACH provider to RDFI. Then End of Day Settlement Federal Reserve to ODFI and RDFI to debit/credit accounts.

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.

ACH Receiving Flow: Originator to ODFI to ACH Provider to RDFI. Then End of Day Settlement Federal Reserve to both ODFI and RDFI to debit/credit accounts.

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

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.

Flow chart: Sender to verified bank to RTP Network or FedNow Service (this points down to Settled in Real-Time) to verified bank to receiver.

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.

Compare RTP to ACH

Back to Top

ACH Returns and RTP Irrevocability

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

Risk with Faster Payments

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.

Return Codes: Administrative Returns, example R02, 2 Banking Days; Unauthorized Returns, example R10; 60 Calendar Days; Business, Claim Unauthorized Activity, for up to 1 year, Consumer, claim unauthorized activity, for up to 2 years

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.

Back to Top

ACH and RTP Fraud Protection

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.

  • Identity verification to verify the account holder’s name matches the other information you’ve collected about that user.
  • Balance check to make sure you avoid the most common return code (insufficient funds (R01)).

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.

  1. The user verifies the information submitted.
  2. The user agrees to continue with the payment using a second channel, verifying that they initiated the payment and acknowledging that all transactions are final.

Have 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 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.

Establish Administrative Controls

Businesses take responsibility in managing their risk and that of their users by:

  • Ensuring confidence in the recipient’s identity for all transactions.
  • Establishing controls to verify the amount of the transaction before initiating it.
  • Developing procedures to handle potential disputes directly with receiving parties.

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.

Develop Technical Controls

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.

  • Authentication and Identity Verification: Ensure that all users (or applications) with access to faster payments are strongly authenticated. This means ensuring passwords are sufficiently complex and properly stored. Multi-factor authentication or biometric authentication can help mitigate any remaining password-related risk. In the case of automated processes, a secure scheme, such as OAuth2, can prevent abuse.
  • Restrict Access by IP Address: 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.
  • Limit Faster Payments Access: Be sure to limit faster payments authorization to only those users and applications that require it. Keeping this list as small as possible will keep multiple risk factors at bay.
  • Protect Against Automation and Bots: 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, third-party services to protect perimeters, or password lockout or login rate-limiting controls on login forms.
  • Watch for Unusual Activity: Monitor systems to flag any unusual activity such as payment requests from unexpected users, IP addresses, or user agents, or 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 effectively your incident response procedures will work to mitigate the issue.
  • Identify Other Transaction Red Flags: Investigate identifying anomalous transactions by other indicators, such as volume, timestamp, destination, etc. These considerations are very situation-dependent.

Back to Top

Invest in a Payments API

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.

Explore the Dwolla API

Additional Risk Resources

Guides and Documentation

Related Articles