Account-to-Account Transfers – The MVP of Fintech
Banks, as we know them today, are founded and built on a series of complex infrastructural elements that work in tandem to get a bank to customer-ready levels. There are two infrastructure requirements for building a modern banking experience – spinning up accounts and cards, and then funding those accounts. And while there are a host of companies that can make the card and account offering aspect straightforward, there is far less attention paid to the critical responsibility of funding these new accounts – that needs to change.
We live in the golden age of starting a “bank.” Although the actual number of bank charters is at a historic low (4,337 in 2020), the ability to build a new “bank” on someone else’s bank charter has never been easier or less expensive. BaaS providers, like Unit, Marqeta, Treasury Prime, etc., will give new neobank users an FDIC-insured bank account with an accompanying debit card through a sponsor bank who handles the regulatory overhead. All it takes to officially issue branded accounts and debit cards is a few phone calls, an extensive application, and several months of onboarding and contracting. But then what?
A major challenge faced by neobanks is that most Americans don’t change their primary bank – ever. As a neobank, the ultimate victory would be getting a user to switch their direct deposit from an existing bank account to a new one. However, it is far more likely that a new user will keep their existing checking account and add a new debit card to their growing wallet of cards. So the question is: how do the funds that are continuously flowing to a user’s existing checking account get to their shiny new neobank account?
The answer: account-to-account (A2A) transfers. Although simple in their fundamental concept, these transfers are tricky to master in a way that can obtain new customers and retain loyal ones. The challenge is complex, including technical, operational, and compliance overhead as you interface with archaic payment rails and pervasive fraud. There are common strategies outlined here, defining the difference between success and failure in the shark-infested waters of this unfamiliar “NeoBankLand.”
But developers in the ever-growing fintech industry do have a few options for how they can transfer funds from a traditional bank account over to a their neobank:
Junior Varsity (Safe, but with Bad UX)
Although not very common, and full of friction from a UX perspective, one option is to direct new users to go to their old bank with their updated account info and push funds from one to the other.
The Upside:This option is extremely low cost on the developers’ end as they are not paying for the transfer and thus, any associated fraud.
The Downside: Asking a user to jump out of the new application is never an optimal choice and will likely result in a one-off transaction. So, when the balance at their new account falls, developers will end up having to ping the user to go back and send more funds, which is far less than ideal and an extremely clunky process.
Varsity (Risky, but with Better UX)
Another option is working with a BaaS provider to access the ACH network, and then leveraging a data provider to pull in a user’s account and routing numbers. With this, developers have the ability to spin up an ACH debit transfer from the source account over to the user’s new one.
The Upside: This provides a much cleaner, user-friendly experience, as transfers can now be completed without users leaving the application. It also creates flexibility with recurring transfers, as long as they are built on top of the access to existing ACH rails.
The Downside: There is heightened risk of return codes and transfer failures. Regardless if a neobank is leveraging their existing banking partner for transfers, or using another service for ACH origination, any transfer failures will be their responsibility.
The Big League (Safest, and with the Best UX)
Perhaps the most preeminent option is to leverage a new breed of API transfer products that offer risk mitigation as well as financial automation.
The Upside: The APIs can be integrated in weeks and instead of burning critical development hours managing and orchestrating transfers, developers can focus on building their core product. As an added benefit, neobanks will likely only need one or two services for an integration like this, compared to, maybe, five if they were to build out the orchestration technology themselves. Some of these transfer APIs will also allow developers to set up recurring or percentage-based transfers which will keep the balances in users’ new accounts high – which in turn helps with charge volumes and revenue.
The Downside: This reduction in development time and complexity comes at a cost, most commonly tied to users and transfer volumes, which will be higher than the raw ACH or debit charges that may have been considered. That said, time is expensive – save it by utilizing a more full-stack transfer API.
It’s an exciting time to be a developer in almost any context, especially within fintech as it has exploded at a profound rate. The barriers have never been lower for a small, dedicated team to leverage scalable infrastructure to build new, dynamic financial products aimed at all kinds of new use cases. Developers need to focus on a core product, evaluate payment needs, and see what offerings currently exist to help make funding new accounts as easy as possible. With the right infrastructure provider, the Big Leagues are now more accessible than ever!
Companies In This Post
- Finastra Showcases Strategies for Lending Growth and Compliance at Its User Connect Series Read more
- January Closes a $12 Million Series B to Help Americans Get Out of Debt Read more
- Chubb and NetSPI Launch Cyber Protection Partnership Read more
- The ever evolving world of payments with Fiserv | FF Salon at Sibos 2023 Read more
- Empeon Partners with Tapcheck to Empower Employees with On-Demand Pay Read more