The first one is definitely something that will happen once a bank partner of ours launches the white labeled service. Electronic checks (ACH) are usually a flat, several cents, fee.
Unfortunately, debits are likely going to require some sort of verification.
My guess is that when he speaks of 'verification' it's more in the context of underwriting the originator of the transaction for fraud/creditworthiness vs. ensuring the account being debited is valid.
> b) allows you to debit a bank account w/o any verification or micro-deposits
That's an extraordinarily bad idea. If you gave a fraudster access to something like that, they could just pull money out of accounts where they had the routing and account #. You'd also be at risk if the customer fat fingered entry of those numbers and you debited the wrong account.
The US ACH rails lack a lot of necessary features to enable debits without verification of ownership of the account. Unless you want to be on the hook for the above scenarios of course.
'a' is fairly common, I believe. It's ubiquitous in Europe (typically no fee), and in the U.S., Bank of America will let you do an ACH transfer to any account in the U.S. for $3/transfer. Not sure what other banks' policies are.
Wire transfers are directly from one bank to another, and will go through same-day. ACH is like writing a check, but saves you having to handle the physical paper. It still goes through all the same automated batch processing as a check, so it takes a few days to clear.
$3 is a lot. Most banks will do it for 50 cents or less. If you have huge volume (someone like Square or Stripe) you can often get it down to one or two cents.
I use ING Direct (recently bought by Capital One and recoined "Capital One 360"). You can either wire directly from one checking account to another using an ACH transfer. Or you can do a Person2Person payment which is similar to a paypal transfer. Enter your recipient's email address, ING sends them an email, they follow the directions and "pick up" the money, transfer occurs.
Both are free to the best of my knowledge.
Edit: ING is a Dutch company, so maybe that's why.
I think he may mean between 2 parties, perhaps in his application. Not specifically between himself and another party, which is possible today with a few services.
I have the a) problem and have yet to find a solution that doesn't involve (manually) sending a fixed-format file with transfer orders to the bank we work with...transfers within the EU are free, though, but this is the bank's policy (due to competition, of course). A simple RESTful API that can be used for ACH transfers across countries or even continents would be killer, given the current options...
I talked to a payments guy a while back and asked why america doesn't have the same kind of easy P2P wire transferability that europe has. He basically said it's because the banks think paypal is good enough. Paypal is the USA's P2P wire transfer system. 2 personal accounts can transfer money to each other for free. I pay my rent to my 1-property landlord by paypal with no fees too.
it's not an accident that they make it so difficult. they are protecting massive revenue streams. bitcoin solves a lot of these problems by giving people real control over how to move money around. eventually bitcoin wallets will be easy and secure enough that while you might not pay your bills with it, you'll keep a running balance on it just like amazon or itunes credit.
> it's not an accident that they make it so difficult.
The easy direct funds transfers in other countries shows that it is an accident.
In Australia, opening a bank account requires applicants to show sufficient ID (the 100-points check[1]). It was intended to cut down on money laundering and tax evasion, but as a happy side effect banks have very high assurance about who money is moving from and to.
That means that direct deposits don't require the heavy validation that a cheque does. So such transfers are free and usually settle in 24 hours. Often the same day.
I wrote a post a while back about how I would like to be able to set up triggers to take action on deposits -- a sort of IFTTT for your bank. It sounds like Standard Treasury ultimately could make this possible, which would be awesome.
Thanks for the link! We have this exact use case in mind, actually. Trigger based web hooks for transactions is definitely something a few people have mentioned to us and that we're talking to our bank partners about.
tbrooks, unfortunately it will be a couple of months until the products are ready for developers. Sorry! We're in contract negotiations and then we have to do the integrations. We might build sandboxes in a few weeks, but that only helps so much.
Connectivity between businesses and bank payment platforms is a huge point of pain for both banks and their customers. Large banks have been focused on resolving this with their largest clients (enabling connectivity to SAP, Oracle, etc.), but there hasn't been a big push elsewhere. Hopefully this will benefit smaller banks and smaller businesses as well.
I had a similar problem once, where my local bank couldn't provide enough functionality through their existing web banking system, so I ended up writing my own REST API for the bank based on screen scraping / HTML scraping. Terrible approach for something that involves money, but luckily this was read-only and only for proof of concept.
Screen and HTML scraping is pretty standard for getting information out of bank systems. That's even primarily what Yodlee does! It's a lot harder to work directly with the banks, but in the long-term it will allow us to offer REST APIs and web hooks that make a lot more sense.
Sounds like what we need... a way to enable a payment from one of our customers to another. Not a wire, not a credit card transaction, can't require anything more than a regular bank account on both sides of the transaction.
Zac and Dan know this space inside and out. I've dealt pretty extensively with Wells Fargo and I can tell you it is extraordinarily painful. These banks need all the help they can get.
Sounds like a great idea! I wish you strength for the integration part, I do the same thing in the travel industry, the hidden complexity of these systems is absolutely incredible. People complain about win32, but this stuff is one step further. Most of it is still compatible with systems from the early 70s.. Welcome to the wonderful world of TTY, EDIFACT, TPF and all the rest :-)
This question is one we're still answering with banks. The exact security model will likely differ slightly by bank, depending on their idiosyncratic wishes and standards. Also, the security model could be broken down in to (a) How do we talk to the banks (b) How is our system secured and (c) How do end-developers talk to our systems.
For the last one, which is what I think you're asking, it seems like our bank partners will settle on (1) a long, random, high-entropy API secret key (like Stripe) or SID/auth token combo (like Twilio) or (2) Both the secret key AND something like OAuth because banks really want multi-factor authorization. But again, nothing is set yet.
Direct banking customer to customer with an API...oh yes many marketplaces would enjoy that (essentially acting like a phone operator that connects both parties).
I can see some value in providing a way for some third party (i.e. the marketplace) to escrow down the line.
a) transfer money between 2 bank accounts for a flat fee
b) allows you to debit a bank account w/o any verification or micro-deposits