Support ACH transfers from one bank account to another to prevent fraud

[justintoth]

The current infrastructure for transferring money from one bank account to another works like this:

1. Request a debit from the source bank account into the company's marketplace escrow account.
2. Check the status of the debit daily for when it has a status of succeeded, at which point the money is in the company's marketplace escrow account.
3. Request a credit to the destination bank account from the company's marketplace escrow account.
4. Check the status of the credit daily for when it has a status of paid, at which point the transfer is complete.

This process is wide open to fraud, in fact I was the victim of it a few days ago, hence this ticket. How the fraudsters do it is they send a debit from their source bank account and it posts as succeeded, then they receive the credit into their destination bank account and transfer the money into another account, then they reverse/cancel the debit, causing the company's marketplace escrow account to then have a negative balance equal to the amount of the payment.

This is a very easy way to steal as much money as you want from the company's marketplace escrow account and simply makes it not viable to ever use this method for ACH transfers. For myself, it only took fraudsters a month after I started supporting tenant -> landlord rent payments before they learned I was using Balanced and signed up for my service to exploit this loophole.

The only possible way to make this secure is to allow ACH transfers directly from the source bank account to the destination bank account, without having any "middle man" company escrow account. That way fraudsters would only be sending money from themselves to themselves, so there's no way for them to take money from the company.

Transfer fees can still be applied to the company's escrow account. If the company wants the source or destination party to cover the transfer fees, like in my case, they can still do a separate debit of that bank account for that amount. Fraudsters can still reverse/cancel the fee, causing the company to be responsible for it, however that is a much smaller amount so it dramatically decreases the risk of fraud. More importantly, the fraudster has nothing to gain by making the payment, so this shouldn't even be an issue.

For my service I'm completely blocked and can't support rent payment transfers until this is implemented, so I hope this will gain traction.

[dawsontoth]

:+1:

[matthewfl]

I think one of the issues with what you are proposing is that if the source of the funds decided to create a "charge back" on the ach debit, then there is not a guarantee that there are funds in the destination bank account. In this way, I feel that it pushes the problem of fraud onto your users instead of the marketplace which should be setup to handle this issue.

As for the case of registering that the debit has succeeded and then sending the funds to their destination, a marketplace can use the callback mechanism to track when a debit has cleared.

As for the issue of the marketplace taking on fraud, in the case that the ach debit is reversed, then they should also be reversing the ach credit. Ideally, using something like orders, this process could be automated.

tl;dr: who is responsible for the issue of fraud?

[justintoth]

"I feel that it pushes the problem of fraud onto your users" - This isn't accurate for multiple reasons. First of all, the tenant and landlord know each other, so it's not like the landlord is going to be accepting rent payments from some random fraudster on the internet. If the tenant sends a payment and then reverses it, the landlord is going to try to collect the rent payment by other means. Secondly, it doesn't push the problem of fraud onto the landlord because the landlord does not lose any money. If the tenant sends them money and then reverses it, the landlord is back to breaking even in the exchange. With the current approach, the marketplace is in the negative, losing the entire payment amount.

Granted, what you're saying would be true if you had an application like Amazon, where you are handling accepting payments from buyers and sending them to sellers. The buyer is unknown and could send the payment and then reverse it after the seller shipped the item to them. However for my business (rent payments), the landlord knows the tenant, and isn't at risk of losing any money or products in the exchange, so this functionality would add real value.

"the marketplace which should be setup to handle this issue" - There is no current way to handle this fraud strategy, hence me posting this issue.

"As for the case of registering that the debit has succeeded and then sending the funds to their destination, a marketplace can use the callback mechanism to track when a debit has cleared." - This is also not accurate, even if you do a read on the debit to check its status and it says "succeeded", the fraudster can still reverse/cancel the debit.

"As for the issue of the marketplace taking on fraud, in the case that the ach debit is reversed, then they should also be reversing the ach credit." - The fraudsters ensure that they have transferred the credited money into another account before cancelling the debit so there is no way to reverse the credit at that point.

[jkwade]

@justintoth very good points here. Let me see if I can add some clarity. I'd need to do a bit more research to be 100% confident in what I'm about to say, but think I'm mostly correct in stating that...

From a technical standpoint, what you're asking for is entirely possible, but would require the landlord (in your scenario, and the recipient more generally) to take on more responsibility and do more compliance work, so might not be entirely practical. The ACH network does support the direct transfer you describe above – that's how Balanced debits a payor's account and moves funds into the marketplace's escrow – but I'm not sure how Balanced (or the marketplace) would intermediate the funds transfer to do escrow or take a commission given our current set up. The funds would have to go from point A to point B without Balanced's involvement.

To do this, the recipient could set up a treasury management (TM) account with a bank (e.g. Wells Fargo) to get access to the ACH network, but this involves a long vetting process, compliance with Anti-money laundering (AML) and Know Your Customer (KYC) policies, and TM depts. don't usually work with very small merchants, which is why ACH providers like Forte exist. They can work with an aggregator of smaller merchants (i.e. a marketplace) to offer access to the ACH network, but they're essentially doing what Balanced is doing and asking the marketplace to take on the risk of reversals.

To do a transfer directly from a payor's bank account to a recipient's, the request to debit would have to be submitted by the recipient bank account owner or entity (usually their bank) that has ownership-access to the recipient bank account. To accomplish what you want with Balanced, we would have to have ownership or access to the recipient's bank account, such that we could initiate a "pull" of funds from the sender's bank account directly into the recipient's account.

So when @matthewfl says it's a matter of fraud responsibility, I think he's right given the current capabilities in the ACH network. Unless each landlord in your scenario goes direct to the ACH network through their bank, someone (the marketplace or the processor) is taking on the risk for them. These intermediaries could try to collect the reversed funds from the recipient, but in your scenario, the recipient is the fraudster. I've seen rent payment platforms successfully fight fraud by properly vetting the landlords, such that the chances of a recipient being a fraudster is low.

Hope this helps.

[jkwade]

@dawsontoth would be interested to hear your thoughts on my comment above.

[dawsontoth]

@jkwade That's really helpful information.

The lowest risk solution for us would be the direct from tenant to landlord payment, but as you've highlighted, that doesn't seem possible. Either the landlord wouldn't want to go through the hassle of setting up a TM account, or they wouldn't be allowed to do so (too small).

The next appropriate solution would be to make sure the landlord is who they say they are. Fraudsters have already demonstrated that the verify bank account functionality doesn't deter them, so we would need something more. But that's where this all falls short for us. We don't have something more. If we did, even if only 1 fraudster gets through and takes $1000 dollars from us, that negates 1000 successful transactions. And that's just to break even monetarily, and doesn't account for any of our other costs.

Basically, it isn't worth taking on the risk.

[jkwade]

@dawsontoth Really sorry to hear this. I'm not sure what else Balanced can do since some of these issues are inherent to the ACH network.

My team and I have written a few times on fraud in marketplace settings. Maybe these resources will help:

• How to Fight Fraud with High-Pass Filters
• Death, Taxes, and Chargebacks
• Online Payments Risk Management & Fraud w/ Ohad Samet

[justintoth]

I think we need guidance on how we could properly vet users to confirm they aren't fraudsters. We won't get anyone signing up if we're asking for social security numbers, and even if we did ask for it, there is nothing we could do with it to really know whether the user might be a fraudster or not.

Landlord/tenant relationship aside, Balanced is open to fraud by anyone who wants to consume the API. Let's say I'm a fraudster, here are the steps I will take to steal all of Ashton Kutcher's money.

1. Sign up for a Balanced production marketplace account, which only requires email address and password.
2. Use the API to add a customer and bank account, verify it.
3. Use the API to send a debit for some amount of money to the Balanced account.
4. After it posts, use the API to send a credit from the Balanced account back to their account for the same amount of money.
5. Reverse the debit, causing Balanced to lose that amount of money.
6. Repeat the process above with 100 new Balanced marketplace accounts, causing Balanced to get PUNK'D.

The point I'm trying to make is that if Balanced is wide open to fraud then anyone who uses it will be too. It should be Balanced's responsibility to provide a secure payment service, otherwise it shouldn't be offered. As it sounds like it's not possible to do so, then really this service shouldn't be offered.

[jkwade]

@justintoth Happy to discuss how to better vet merchants and thanks for telling the world how to steal our money ;-)

But I don't buy your logic that payment systems which are susceptible to fraud should not be offered? If that logic were followed to its full extent, the ACH and credit card networks shouldn't be offered. Your logic also implies that the security of the payments service we provide isn't our responsibility since we use technology from a bank/processor, which uses technology from a payments network (ACH or credit card), which should be secure.

Instead, the way fraud risk is mitigated in these systems is by asking the merchant side of the equation to take on risk. Visa/MC pass risk to banks, banks pass risk to processors, processors pass risk to merchants. If the merchant can't pay, the liability flows down the stack, and as a result the entities in the merchant stack tend to underwrite anyone above them in the stack they work with to take on part of that risk. This is why Balanced asks the marketplace/platform to take on the risk of transactions that occur on their platform.

Thanks for bringing up this topic. It's been on my mind for weeks and it's nice to finally articulate what I think. Happy to answer any other related questions.

[justintoth]

My point isn't really that it shouldn't be offered just because it's possible it could be exploited, it's more that it shouldn't be offered because it's so darn easy to exploit. I understand that you're pushing the validation onto the marketplace, I bring up how to exploit Balanced directly to point out that even if real marketplaces are taken out of the picture, Balanced can still fall victim to fraud. Therefore regardless of what validation marketplaces have, Balanced still needs to figure out how to prevent the exploit I mentioned above. If Balanced solves it, then marketplaces can as well using the same method.

Perhaps most of Balanced's customers are using credit cards, or ACH only for single transactions (debit payments for instance) rather than the middle-man scenario illustrated above, so maybe it's not that big of a deal to lose a few marketplaces like us. However maybe in the future some more thought can go into how Balanced can assist middle-man marketplaces better in protecting against fraud.

It sounds like you don't think there is anything more that can be done from Balanced's perspective, so I guess it is what it is. I just wanted to raise the issues in hopes of finding a solution so we could keep using Balanced.

[dawsontoth]

Were there any hallmarks to our particular scenario (with the $2,500) that pointed to fraud? In hindsight, we do see that the account names were suspect (same name with different numbers appended). I'm wondering if there's anything indicative in the account numbers of the fraudsters, or something like that. Or, if there is a way to hunt them down?

What if we only accepted 1) deposit verified bank accounts from 2) known banks (as differentiated by their routing number) where we could 3) go to the known bank to contest chargebacks?

Sorry, I know this particular GitHub issue is getting a bit off topic, and very precise to our scenario. It'd be lovely to come up with a solution.

[jkwade]

@justintoth Sorry for the hiatus here. I think I'm misunderstanding you, so let me explain my case and then ask you a question:

The ability for a buyer to reverse a payment is a fundamental part of the credit card and ACH networks. You call it an exploit, but I doubt it can be patched. Our solution to mitigate risk from this exploit is to vet the marketplaces that sign up for a Balanced account. I'm suggesting the marketplace do the same thing for their merchants. How would you suggest we eliminate or mitigate this risk?

@dawsontoth I'd prefer to discuss specifics of fighting fraud in a private communication channel. Feel free to contact me: jkwade@balancedpayments.com