Does Plaid provide information about the location the checking account was initially opened or the general location of the account owner's residence? The biggest problem with Stripe is they provide ZERO checks on IP location + billing/shipping zip code, checking the email against known fraudulent email addresses, or shipping location against known drop locations.
Right off the bat one thing you should really try to change is the lack of MFA by Wells Fargo. You should beg and plead to have them do something. They're by far the most available and cheapest accounts sold online.
I'll hear a lot more about beating your system in the future. I'll pass along whatever I hear.
I'm hoping "validating available balance" for a dev means "sufficient funds to cover this transaction" (which might not factor in any overdraft facility), and certainly not:
"developer can see account balances".
How does validating the balance and checking the owner's identity help? When someone's identity and bank credentials are sold (~$15-$300) it's usually very inclusive. MMN, DOB, SSN, previous residences, balances, cards attached to the account, security questions... It's not like people are just selling numbers from a check they found on the sidewalk.
For credit card processing, automated fraud prevention does in fact come standard on all Stripe accounts and takes into account a great number of signals including some that you brought up below, like whether the location of the IP address used matches the location of the billing address.
For ACH, we've built even more stringent verification--as well as any other signals we might take into account, purchasers have to demonstrate, through microdeposits or Plaid, that they have direct access to the bank account in question.
It's impossible to prevent all fraud, but we take it very seriously and are investing heavily in continually improving and expanding what we do there. It sounds like you may have had some specific bad experiences, and we'd love to hear your feedback and suggestions for improvement. Please do reach out--I'm [email protected].
The problem I see with Stripe's fraud prevention is that it appears to be "all or none", with no visibility or control on our end.
The only control knob appears to be whether to allow Stripe to automatically decline things it thinks are fraud. It doesn't appear to provide any detail on why it thought something was fraud.
So it seems to leave two choices:
- Allow stripe to decline things, and try to address false positives manually. There is no "go ahead and charge this button", by the way...you would have to contact the customer.
- Set stripe not to decline things, but lose even the limited visibility to "stripe would have declined this".
The real problem, in my mind, is that fraud risk for both the banks and providers like Stripe is really small. You risk very little.
The vast majority of the cost goes back the individual merchants/sellers, who have the least visibility into what the risk of an individual transaction is.
Thus, there's very little incentive for the banks, or stripe, to provide decent tools. A shame, because your ability to see the bigger pictures means your tools would always be better than anything we can use.
That would allow the flexibility for merchants to make their own decisions without the hassle of manually dealing with false positives. The trouble with the false positives is that you have to talk the customer into entering all their data again, without having anything specific to tell them, like "Er, you were declined, but I have no idea why...can you try again?".
I am curious how good it is if it is standard.. Some how major vendors lost quite a lot of money on hoverboards with Stripe.
I consider this a long time, so long, that I'm actually considering on working directly with a bank myself and plugging into ACH network directly (The way we operate, its faster for some clients to just be paid through PayPal and cashout through PayPal).
As far as fraud goes, ACH charges can be reversed with no questions asked for 60 days if it turns out the charge was unauthorized (with no recourse, except asking the customer). On the other side, if a fraudster has your bank credentials, and can confirm with micro deposits, this is no different than them going to PayPal or Venmo with that same information.
Even with zip code verification you have minimal protection. There are no geo-location checks for IP + billing/shipping zip code or other protections. Stripe should bundle with a service like MaxMind IMO.
And with about 2 lines of code you can add more advanced things like device fingerprinting and geolocation through Kount.
*Disclaimer: while I don't work for Braintree yet, I start there in June (though my experience with Stripe is very strong).
Being able to turn that on & off would be incredibly useful. As far as I know most non-US banks don't support zip code verification, so enabling it effectively blocks international transactions. It's frustrating trying to explain to a small non-technical business the difference between "zip code check not supported" and "zip code check failed".
In short, we provide an in-house risk framework that has features ranging from device fingerprinting, network-based transacation linking, Dynamic 3D Secure, velocity/consistency/referral checking, behavioral analytics, and more. We feature both standard velocity-based rules and a lot of unique whitebox ML-based logic that is very open to tweaking and customization.
We are in a fortunate position (being payment platform). This enables us to have access to a lot of the data necessary to identify fraud (raw issuer responses, full visibility on the auth flow, etc.), so we've been able to build a considerable tool-set.
You can see our risk documentation here: https://docs.adyen.com/manuals/risk-manual
And our general overview page here: https://www.adyen.com/home/payment-services/revenueprotect
Feel free to get in touch! [email protected]
It is quite easy to get access to high value checking accounts for less than 50 USD. They could be personal or business. For between 25-75 USD you could get access to all the login information you need to access Wells Fargo/SunTrust/BoA accounts. You could see both Plaid micro-deposits. Even PayPal has faced this issue and they're solution was to be a huge pain in the fucking ass to users.
Balancing convenience with security for ACH is not an easy task. That's why ACH is so damn hard to do online.
I'd love to know how long you should expect for an ACH payment to clear and into your bank account. The two day period for credit cards is so small. Who checks their statements every single day? This is obviously the benefit of using Stripe if you're the merchant, but it leaves you vulnerable.
We can only pray that Stripe accepts some responsibility for verifying these ACH transfers.
Fraud on Stripe is a two-fold problem. They've got fraudsters signing up for Stripe accounts and running cards through them. They've also got fraudsters making purchases on Stripe-based sites. Obviously, Stripe prefers that the charges are made to legitimate users. That way they're not out all the money.
Edit: It appears it could take "up to 5 days" for the payments to be processed. This is entirely on the bank's side of the equation. I guess from there you'll only need to wait your 2 days (7 days for some users) to receive the ACH into your bank account. I see massive fraud coming in here.