Fintech startups need to move money quickly and safely in order to make consumer-friendly features like rent-splitting or shared savings work.
But to do that, they need help navigating the world of ACH bank transfers, which can be slow and complex.
Startup Astra provides companies with automated transfers from one bank account to another and says it does them faster. That's important for startups with features such as automatic savings when you work out or buy a latte or splitting rent payments or sharing savings — or even if neobanks want to make it easy for new customers to transfer money into new accounts.
Astra specializes in faster ACH transfers, which can be sent in one day from one institution to another. This is made possible by technology that does risk assessment to make sure that a settlement will not fail. It also has a system that can set up triggers to automatically make transfers.
NACHA, the organization that operates the ACH network, has been developing same-day ACH transfers, which it says grew quickly in the second quarter of this year. But those faster transfers only accounted for 1.3% of total ACH payment volume in the quarter.
We caught up with Gil Akos, co-founder and CEO of Astra, to find out more about Astra's work and the future of payments.
Let's clarify this first, how long does it take to do a bank transfer?
If you're doing an ACH debit pull, the bank can choose "next day" or "standard" settlement. Next day is T plus 1 day [one day transfer] and standard is T plus 3 to 4 days.
Why can't fintechs do this in one day?
A neobank could do next-day settlement for an ACH debit pull, but they don't because there's a huge amount of ACH risk. You don't want to have the transfer reversed. Return codes for "insufficient funds" or "frozen accounts" come through on the morning of the second day. That's why standard settlement is three days. You don't want a $1,000 transfer to a destination account available the next day, and the customer withdraws or spends it, but then on T plus 2 those funds get pulled back to the source account because of a return code.
How do you address that?
Our system optimizes for throughput and speed. We have a higher fidelity. When you create an ACH file [to transfer funds] as a developer, you can ask Astra's API to route funds to Tomio in T + 1 and we're most likely able to do that. For Jane, who has one or more risk factors, developers can ask for longer time. We couple settlement speed parameters with risk mitigation.
With Astra, what's being automated?
So a common use for our platform is our customers would present a user experience to their end user that says, "When my balance for my debit card goes below a certain threshold, say $200, automatically refill it from an outside source." So you specify these parameters in our system and then we track the inputs, and whenever it's been triggered, we execute the payment on their behalf. So a company like Daylight or Fold, which are our customers, can leverage that automation to make sure that there's an ongoing capture of deposits, based on conditions on the ground. So when my Fold balance goes below $100 it can be automatically refilled from an outside source.
How is what you're doing different from others?
There's three key facets to our product. One is that you can easily fund from an outside source and execute the transactions such that they're faster. Second is that because of our payment architecture, we're optimizing against risk, so your origination risk goes down to zero. So you're not on the hook for a bunch of failed transactions. And last, you get to embed this advanced capability into your product, which means you capture more deposits over time.
How do you handle the speed versus risk?
Historically, that's done through the fintech's partner bank, if a challenger bank is originating those transactions by way of the ACH system. But there's a ton of limitations there and you have to build out and operationalize a lot of capabilities around what should happen when. Do you set a blanket policy so that all transfers are slow, so you're insulated from risk, or do you take the other binary option which is, you let transfers be faster for settlement, but you have to own the losses, because you'd have to make your bank partner whole?
Astra says, you get to specify a desired settlement speed that we then optimize against, and get funds in faster, and reduce risk. And by the way, funds are continually flowing inbound by way of rules, as opposed to expecting the user to actually take action in your app.
Do you have to do any of those security checks that those institutions would do on their own?
We do that by default, because that's part of how we optimize for settlement speed.
Is some of this business rules? If for example, you were connecting my Chase to Schwab, because of a rule at Chase it's just not possible to do T + 1?
I think that's accurate. But because I think what we're teasing here is, when you're either pulling or pushing you only have a limited set of capabilities, because it's like a one-way action from either the source or destination. If you think about it like the Internet Protocol suite, the layers. So instead of staying at that same layer and doing a push or a pull, with Astra you're talking to the next layer above, and then we're routing through from BofA to Robinhood.
I thought you were going to say, well, if we partner with both sides then it can be much faster, but you're saying that's not necessary?
No, because we can create the NACHA files for ACH debits or credits, independently of either one of them. And we have the full range of parameters that we can specify. And as we build out other payment rail options into our system, like real-time payments, and push to card, it means that the developer has more and more capabilities around speed and settlement and costs that they can weigh against each other. It can be any one of those source destinations or third party entities that are sending an API request to us, to route those funds.
Is ACH the best way to send funds?
In the U.S., the three primary payment rails are ACH by a landslide; card transactions, so debit rails with Visa and MasterCard; and then new real-time payments. Cards are maybe more expensive but you have a high confidence that it's going to settle. ACH is more ubiquitous to work with and it's cheap. But it's fragile, and specifically it's around these return codes and having to understand these different nuances around push and pull. Along with that, the reason it's inexpensive is because when you as a bank are sending this list of files of what should be transferred that day, they get processed in batches.
With ACH they only batch send once a day, but now they're talking about doing it two to three times a day?
So what NACHA as a governing body is doing is making more of these batch windows available so that you can pair that with the parameters around settlement speed. Because the tailwinds of everything is, the more time goes on, the more expectation for all individuals or businesses is that the settlement is going to happen faster — as in instant.
In theory, we can get same-day ACH?
Definitely. There's a not-too-distant future where you can pair the appropriate, same-day ACH debits and ACH credits together, if you get them into the right batch windows so that they clear by the end of the business day. So it's T + zero — it's not instant.
Does that affect what you're doing at all?
We're actually doing some beta testing right now with some additional clearing windows or parameters for settlement speed. And so as that comes through and it's available through our bank partners, we can then extend that to our customers.
And your customers are mostly fintechs who are accessing the funds?
We have two types of customers. One is fintechs, such as neobanks: We typically help them get funds into customer accounts faster and more reliably.
But we also have customers who don't want to be in the flow of funds. They want to allow their customer to route funds from user A to B where our customer is not in the flow of funds [though the end user has logged in and approved this]. DoorDash could do this themselves, since they have the payment-ops chops to debit from here into our corporate treasury and credit out to drivers. But in a lot of use cases, marketplaces don't want to touch the funds. This could be a personal finance app, such as sharing or saving for couples, or an app for sharing subscriptions costs for Netflix. Funds bounce back and forth but the app doesn't want to stand up a treasury system to facilitate that, so we help them do that.
