Disclaimer: I used to write banking software for a living, including implementing ACH management on both the customer-facing and backend processing systems.
The article is blatently misleading regarding realtime transfer of funds, but it takes some knowledge to understand why. Let's talk about ACH transactions.
ACH, or Atomated Clearing House, is the network that the majority of electronic funds in the US use. As the article points out, it's ancient and horrible, basically a 1:1 translation of the paper funds reconciliation to electronic format. In essence, a customer creates an ACH transaction, which is sent to two endpoints; the federal reserve a.k.a. The Fed, and an ACH operator. Just like a credit processor, the ACH operator is then responsible for delivering the funds to the destination financial institution (FI) and they make their money by charging the originating FI. The transfer only goes through once both The Fed and the operator finalize the transaction, which can take a day or more, and most of them are held for additional days to provide for reversals (effectively, cancellations).
Here's some important takeaways:
- To perform bank-to-bank transfers, you must either engage a third-party processor, or you must have an agreement (and process) with each individual bank you wish to transfer to.
- These transfers are subject to some very specific banking regulations, some of it relating to reporting to the Fed, who can block the transactions.
- Laws provide for effective reversal (issuing a reciprocal transaction, not necessarily a reversal) for 2 days for corp-to-corp transaction (CCD) and up to 60 days for transactions involving people (PPD).
- Just like most retailers, these are batch processed, not in real time, though the banks will reserve funds and adjust your balance accordingly. No one minds because legal protections result in at least a 2-day processing window anyway.
Okay, so what do we need to perform this transfer in realtime? Well, first, you'd have to get every bank in the US and the federal reserve to switch to a new system that actually supports real time transfers, instead of the ACH. Then we'd have to completely overhaul the 40+ years of recent laws that were written with a batch-based system in mind, including removing many of the funds reservations activities (and the legal protections that require them) in favor of a realtime system.
So how does this bank do it?
Based on the info from the article, it sounds like the bank is managing two accounts per individual account; the customer-facing one which serves the 'realtime' aspect, and the actual one that is used for the ACH transaction. The risk comes in when the bank accepts a credit or debit prior to it being authorized and completed, and thus the need for 'risk management' software, identical to the sort that ATMs use, especially when configured as a local authorizer (for branches too far from the main branch and others).
They just don't show the end user the reservation of funds like most FIs, and they assume the risk directly so there's no odd 'processing' credits or debits in their statement.
So, it's just smoke and mirrors. They have to use ACH if they want to talk to other banks, and they're not doing manual wire transfers. They just aren't telling their customers. Though if they hit the anti-terrorist check (I wrote the software that matches against the government list too, at one time), their customer is going to find out really quickly that it's really just an ACH after all, and they ~don't~ have those funds - it's illegal for the bank to provide them!