ACH Disputes.

ACH transaction disputes, why you are unlikely to win as a business and what are some of the security measures to prevent this.

TL;DR:

• This post is for anyone who has to deal with ACHs.

• There are 85 R codes.

• Most R codes are bad for you but a very limited number of them have dispute windows of 60 days.

• R10 code is the way for a customer to claim that you/your business is fraudulent and weren’t authorized to debit their account.

• SEC Codes are the descriptors of any ACH transaction that specify the transaction details like originating account type, recurring vs not etc.

• There are 6 main steps in the ACH dispute process that you should stick to.

• Sometimes a civil lawsuit is the only viable option since ACH regulations are limited.

R codes can be the death of you and if you have no idea what an R codes are, it will be a surprise death. Specifically we’ll talk about R10 code.
If you google how to handle an R10 code, you will find a bunch of garbage written by merchant-centered organizations where the bottom-line of the article is “buy our service and the problem is gone”.

B.S. R10s are complicated, time-consuming and costly. Winning a dispute with a client in this situation is almost impossible even if you have all the data in the world and I’ll cover - why and how to prevent them from happening in the first place.

Problem we are reviewing today:

You are the owner of Dreamers Properties (aka XYZ co). XYZ co helps real estate owners list their properties, collect rent and pay out their vendors and disburse the earnings to their external accounts.
You have a customer named Tom. Tom sends a $10,000 ACH to top-up their wallet on your platform. Then Tom makes a payment of $10,000 to one of their contractors’ external bank accounts from your platform.
Then Tom, the bad actor, proceeds to reach out to his bank (from where he pulled the original $10,000) and claims that he had never authorized that transaction and he has no idea who XYZ co is that show up on his banking statement.
Bank reverses the ACH and pulls the funds from XYZ co’s bank account.

Now the fun begins.

Quick overview before we dig further.

There are 85 R codes and almost all of them are bad in one way or another but today we’ll just focus on R10 because they tend to carry the biggest losses on top of being extremely time-consuming.

In this post I’ll cover the process of returns and transaction disputes for ACH. How they are started, how they are handled and what you can realistically expect when it comes to going through transaction disputes. All that is done so that when you face Tom the bad actor, you know what you can realistically expect from this process.

R10 code.

R10 code is defined by NACHA as follows: “Customer Advises Originator is Not Known to Receiver and/or Originator is Not Authorized by Receiver to Debit Receiver’s Account”. Translating into normal English, this means that the customer claims that the funds were pulled from their account by an entity that wasn’t authorized to do so. As in - they claim the pulling party is fraudulent.

A transaction coming out of a personal bank account has a dispute window of 60 days and coming out of businesses’ bank account has a window of only 2 days. HOWEVER, systems sometimes tend to struggle in identifying personal VS business accounts and if YOUR system mislabels it and sends a request to the originator’s bank that includes the wrong identification of the transaction - you’re cooked.

An important thing to note here is that depending on the payment processor you select, it might be on the individuals to properly identify their account as business or personal. If that is the case, keep a close eye on your users to make sure this isn’t abused.
If your processor doesn’t offer any automated solutions, I would recommend going directly to Plaid (or a similar company) to help you.

Now back to our example of Tom the bad actor. Tom is onboarding his business to your XYZ platform but purposefully mislabels his company’s bank account as “personal” during the onboarding process. Now in your system Tom’s company happens to have a personal bank account. This is completely plausible and doesn’t raise any red flags necessarily.
Now Tom is onboarded and he follows the scenario which I have outlined earlier. The transaction is out and now comes time to dig further into the ACH communication protocol. Specifically the SEC — standard entry class codes.

SEC Codes.

According to NACHA, the SEC Code generally indicates:

• The nature of the transaction as consumer or corporate in nature (i.e., whether the funds transfer affects a consumer account or a corporate account at the RDFI).

• Whether the transaction is single-entry or recurring.

• The specific computer record format that will be used to carry the payment and payment-related information relevant to the application.

If you want to see the specific SEC codes you can find them here.

In other words, the first point says that the SEC code specifies whether the transaction is related to a consumer or a non-consumer (personal VS business) account.
And guess what? SEC code doesn’t care that your client (Tom) has purposefully mislabeled his account as “personal” rather than “business” and if his transaction is cleared as “consumer” in SEC code rather than “non-consumer” - Tom the Rat will have 60 days to dispute it.

Dispute.

Tom the bad actor did his thing. You are now in the hole for $10,000. Could be worse but still a sizeable amount of money. Now what?

Now it’s time to dispute. Depending on who runs the system, the approach might vary but there are standard paths that are available and expected.

Immediate steps:

1. Reach out to the customer (Tom) and start the dialogue. There might have been a legitimate issue that needs to be addressed.

2. Connect with your payment processor. They need to be notified as they will be helpful in this process (unless the problem is resolved by speaking to the customer).

Following steps:

3. Work with the processing bank to attempt to dishonor the debit return. This means that your payment processing partner is reaching out to the bank and trying to find the way to fully and immediately cancel the dispute (this depends on what R code you got). This solution rarely succeeds because banks don’t like their customers to be in the wrong as it may result in such a customer to go to a different bank.

4. Try to claw back the funds that were sent to the end recipient. This one is also unlikely since the recipient’s external bank account most likely isn’t connected to your platform. If it is - go for it but you might get hit with another R10 from the new person and this time it would even be kind of justified.

5. Collect the data. The more the better: users’ onboarding process, what identification materials you have to prove that your customer is who they claim to be, if you have 2 Factor Authentication, PIN protection or any other precautions that you took to protect your users from an account takeover, video capture of users’ interactions from within the app/website etc., share those. Look at the section called “Preventative Measures” below to find more information on how to combat bad actors.
   Work with your payment processor on collecting information on the specific payment in question. What IP was used to initiate the transaction, location of the payment, who the payment was sent to, what is the past history of the clients payments etc. Again, the more the merrier - anything that you think can be useful most likely will be useful.

6. Start the conversation with your clients’ bank in the formal dispute. Most of those take place over long email threads with an unreasonable amount of people included in the said threads. Make sure to work with your payment processor to identify the right people at the bank. This is where you will share all the data you have collected in the past step.

Final steps and summary.

This is the extent of the ACH rules and regulations. If nothing happens after these steps are completed, it’s the wild wild West out there. On a more serious note, you will have three primary options:

• Continue trying to establish contact with the client and hope for the best.

• Civil lawsuit. I will not be covering this section since it’s far beyond my knowledge set nor does it interest me. But it’s a viable option.

• Write off the loss, learn from the mistakes and ensure that it doesn’t happen again.

Based on the amounts of money involved in any given transaction, make your choice wisely.
Most likely if the attack was accomplished by an actual scammer the chances of getting the funds back are almost 0. However, if a real client got you into this mess, you might find success by sticking to the steps above.

To summarize, it’s very tough to win these disputes because banks are inclined to believe their customer and because any evidence that you present might be countered with “we were hacked”, the banks don’t care enough to dig further. So the lawsuit might be a viable option since you’ll be able to present the evidence that will be actually reviewed.

Preventative Measures.

Now that we’ve covered what to do when a bad actor gets into your system, let’s cover some of the ways you can protect yourself (XYZ co) from further attacks.

KYC Data Points - Below are some important points to consider when onboarding users. These serve as important data points and, depending on your universe and marketplace characteristics, you may consider other data points not covered here:

• Phone Number

• Email

• DOB and SSN (last 4 at a minimum)

• Business Specific Attributes:

  • Tax Identification Number

  • Principal Name

  • Website

• Physical Address

• IP Address

• Copy of Government-Issued ID, preferably with the user taking a clear selfie holding the said ID.

• Bank statement for the most recent month - if the past transactions are aligned withe the stated purpose of a business being onboarded it’s a good green flag and vice versa.

Deeper dive into the data points listed above:

1. Phone number.
   - Verify the ownership of the number by sending an SMS code to the given phone number through Twilio phone verification.
   - Run additional data checks to verify if the business is using VOIP/Simulator phone services. Persona’s Phone and Email verifications can be integral to this process.

2. Email.
   - Manual screening would be helpful but obviously not scalable, everyone knows how to handle manual screening so not going further here.
   - You can use Zero Bounce for an API-based email validation.
   - I would also recommend looking at Persona for this service since Persona can cover a good chunk of onboarding verifications.

3. DOB and SSN. Run this through Persona or Plaid - both are great options.

4. Compare the IP address location with the physical location stated by the user. Persona has some services around address verifications here but I’m not familiar with them.

5. Government IDs can be manually verified or, once again - Persona:)

Important things to note:

1. During the process of writing this article I found out about a company called riskified (shoutout to my boss for sharing it with me) that can help you insure the risks of such bad actors. They also help reduce non-fraud chargebacks and have a bunch of other useful products.

2. The scenario that I have described earlier with XYZ co is one of the many possible options in which you can get defrauded by a bad actor. There is a situation in which your payment processor will be pulling funds from the external bank account of Tom just to send a standard ACH to the end recipient, once that transaction is completed and funds settle in the end users’ account, the dispute is still possible.
   Even though the transaction is going from the external bank account to another external bank account, bypassing your XYZ co, there is a period of 3 days when funds technically speaking are sitting in your processor’s bank account waiting for all clear from Tom’s bank. If this flow is a bit confusing, feel free to drop a comment with clarifying questions.

You can read up on more useful information here:

• The reasoning that clients can use to dispute any transaction: https://www.nacha.org/rules/differentiating-unauthorized-return-reasons

• SEC-codes, what they are, what do they mean etc.: https://achdevguide.nacha.org/ach-file-details

• An amazing article by yours truly about RFP and how you can bypass ACH debits and horrible disputes by going through RTP/FedNow: https://www.aft.finance/blog/rfp/

Tis’ it, hope you enjoyed this deep dive into the fun subject [sarcastic, but seriously, it’s very useful to know] of ACH disputes!
In the last post, 100% of responders said that the posts should be longer so I did just that. What do you think about this one?