Hacking Payments

This is a follow-up to my earlier post on Hacking ACH. I was advising a company that specifically wanted to transfer funds in and out of user’s accounts in the US as rapidly as possible, and brainstormed a few ways to do that. Here is what I told them.

1) Fedwire. Regulate or negotiate against receiver fees on Fedwire. The speed is real time and the big banks which directly access the Federal Reserve system pay the Federal Reserve <$0.50 per transaction. Banks usually charge retail fees of $25 to send and $10 to receive wires of course, so if you use it to push small amounts of money, the receiving fees might be prohibitive for customers. Also, smaller banks frequently use a correspondent bank for access to FedWire, and pay much higher fees.
This works great if you can pull it off, but there is no pull capability in FedWire, its purely a push system. So this won’t work if you are looking at how to get funds out of users accounts quickly. For pushing it into their accounts, there is nothing more ubiquitous than FedWire. But it’s not 24/7 — it only works 9 am — 6 pm ET 5 on business days. And getting wholesale access to it from some banks can be very tough. Bank Wire desks are usually even more antiquated than their ACH processing.

2) Card/ATM networks. Almost all banks are already integrated with these and it’s all real time auth. 
This is how Square Cash works — it basically does a card pull, and then a push payment to a card using an Original Credit Transaction (OCT). Both Visa and Mastercard support OCT, and since Oct 2015, its been mandatory for all banks to accept incoming OCT transactions and give customers credit within 30 minutes. Visa brands this as Visa Direct, and Mastercard calls it MoneySend, although the best available API for using it is probably Stripe Connect (https://stripe.com/docs/connect/custom-account). Visa and Mastercard are building a gateway to each other, which means that you could just use one API to connect to both. When that happens, OCT will be pretty much universal. Nice thing about OCT is that it has a lot more data embedded into it about where the funds are coming from (https://developer.visa.com/vpp/). You will pay interchange on an OCT transactions however, so it will be expensive. If you end up using OCT do test how well it works with higher $ amounts — most usage in the p2p scenario probably has median amounts in the low hundreds of $s, and lots of banks block large debit transactions on cards. Push should be fine even for amounts up to $5k, but again, test it for amounts higher than that if your use case requires that.

3) Bank integrations. For this you’d have to persuade large banks to integrate you as a payment scheme. At the moment the only way would be going to Wells and saying — hey your xx thousand customers are sending/receiving $100m from us every month and you could get an advantage over your competitors by integrating us directly. Its a long shot, and really only viable if you are already a large late stage startup like Facebook/Paypal/Venmo/Stripe/TransferWise — somebody with real market power basically. You’d have to get at least the top 10 banks to sign-up, and they make too much money from fees to do that happily.

4) Check clearing system. Checks now clear electronically using check images after the Check21 act was passed. Since the network was built in the last 10 years, its actually fairly modern, and all the banks now support it. I’ve heard that for the large banks checks can (electronically) clear faster than ACH now, and sometimes intra-day between the large banks. You also have better protection on a check, since bouncing a check is actually illegal under the UCC. For example, this is how Zipmark processes its payments. But if you electronically create a check and it bounces , the customer will incur a Non-Sufficient Funds fee (NSF), and that can create long-lasting problems for them from the banks debit bureau system ChexSystems.

5) Good old ACH — same-day push ACH became mandatory for all accounts under NACHA rules in 2016. That is only one side of a transaction, but you can give customers faster payments by taking on the risk that a debit will fail, and funding customers instantaneously. Building a risk model for this is key of course, and its far from trivial. WithKash has done this, and it seems to be working for them so far, but they have a ways to go before they are at PayPal/Square/Digit scale.

The overall best way to do this might be to use ACH debit for pull transactions, but keep building a risk model and operational processes to get to T+0 (or strike a deal with WithKash to use theirs). You could also experiment with pull transactions on cards, but the cost is going to be substantially higher, fraud is still a big problem, and the transaction limits might not work for you. For push transactions OCT on card is probably the best way, if you can manage the interchange. You may have to store card numbers and become PCI certified for this, but its probably best to bite the bullet on that sooner rather than later anyway.