Bank portability for startups
When to get it, why, & how to prep
While at Cash App we spent a lot of energy multi-sourcing vendors. For most core functions where we relied on a third party, we had 2 or more equivalent partners or vendors live at launch or shortly after. This practice was already common before I joined and I think it was a reaction to many near death experiences where a partner flexed either an economic/functional chokehold, or experienced an outage which degraded our SLAs to customers. This was the inspiration for writing about API Routing layers ; we built routing layers in house that contained the integrations between multiple vendors of the same type, and helped direct traffic according to whatever business rules applied (or the circumstance). Its fairly obvious how any business that shared our objectives or problems would benefit from having one. By having two or more parties at every level of our stack, we could play them off against each other economically, have redundancy if one was down, have additional coverage where applicable, or exploit their unique advantages to create superior benefits for customers. This approach is cognitively expensive, but it forces you to build your interfaces in more generic ways, which is more resilient in the long run.
This pattern played out over and over again during my time at Cash App. We had multiple instant deposit vendors, multiple card issuers, multiple identity verification providers, multiple issuing banks, multiple bank partners, multiple card manufacturers, etc. A lot of our scaling process involved building services to make routing & switching easier and smarter. If you're building consumer or SMB facing financial services, that involve issuing financial instruments (eg cards or bank accounts) or enabling those end users to initiate or receive payments using your service, these lessons will likely apply to you. There are also parts of the healthcare stack where (at Carbon Health) we've been able to route between multiple providers (the most obvious example is routing labs that get sent out to 3rd parties) but I have yet to see as broad applicability in our environment so far.
There were tons of advantages. For example, for identity verification we layered 3 vendors on top of each other. In normal times we’d run customer details through them in a waterfall until we got a successful hit. This configuration gave us:
negotiation leverage; re-routing traffic was the flip of a literal switch, so all of them were inclined to continuously improve their rates, coverage, SLAs etc in the rush to be first in the waterfall (because the first, naturally gets the most volume, and these providers price on volume)
higher coverage than pretty much anyone else in the industry, as we had the advantage of verifying customers across 3 partially overlapping datasources (you can now just buy Alloy[2] for this, instead of building it yourself). Pre-optimization we had pass rates north of 85%
redundancy: one day in 2019, two of these vendors had an outage, but we continued onboarding customers via the third (as opposed to having to shut down onboarding that day)
More recently I’ve thought that this approach might have been overkill. It requires a nontrivial amount of engineering, operations & product overhead to manage. Crucially, we had a lot of this at Cash App long before we had product market fit (probably part of being a large company). Other than for coverage reasons (which helped differentiate us both in the coverage of instant deposit and IDV) these items are unlikely to matter prior to you having figured out your business is working. Focusing on these areas negatively impacts your execution speed, and (my impression is) that the vendor stack in fintech has professionalized well enough over the last few years that these are issues you mostly don’t have to worry about these things.
A lot of the near death experiences & disruptions I experienced in the early days running the Cash Card were related to one or more ecosystem partners we relied on, not being able to keep a promise they made to us or degrading our customer SLAs for a contractual or regulatory reason. This includes episodes like a card printer literally running out of plastic (at which point we shifted our volume to another one) or our card issuer having an outage (at which point we surfaced an option to users to instantly access their funds by issuing a virtual card on the secondary card issuer).
Snags
In the last year, a lot of fintechs are feeling the effect of not having this now, as a few banks (Blue Ridge, Column & Radius) have come under regulatory scrutiny or had to otherwise shed programs. While working with a bank that was under a consent order, I learned how much we could be affected by the bank’s overall activities and regulatory posture, even when the regulatory issues had nothing to do with our program. You can literally do everything right, and still get impacted.
Regulators come down on banks in general, not surgical ways. Like a baby’s hand slapping a piece of butter; everyone is affected, regardless of whether you’re playing by the rules or not. The bank is obviously affected - because regulators will often instruct the bank to shed some categories of program (like Radius did for a ton of fintechs when it was acquired by Lending Club) regardless of whether the program was perfectly executing a CIP/KYC/AML program or whatever else the regulator was worried about. For us, here’s how it played out:
We’d issued a virtual card program on a partner bank, that was under some regulatory scrutiny prior to working with us
We were blocked from expanding the program in any direction (ach, physical cards, atms etc)
Our program specifically came under scrutiny a few months in, and after passing we were able to expand again.
If you’re a venture-backed fintech, getting caught in the blast radius of a bank regulatory action can be quite expensive (and in some cases has been existential), as the bank/program management operation ties up a lot of the cognitive bandwidth of much of your team, typically for months, and very often you can’t really service customers without fixing it. The net result of the last 18 months of regulatory action against a lot of banks that served fintech companies probably set fire to lots of venture capital, and stymied a lot of startups that had done one bank integration. Most thought they were done, focused on growth and the other parts of their value prop to hit milestones for their next fundraise, and once the regulatory action hit, had to pivot back to their bank integration and migrate to another bank, and then (in a lot of cases) 2022 happened and they ran out of time.
The trouble with banks
Banks play a special function in the fintech ecosystem. If you’re building a customer facing, money moving product in the US, you literally cannot provide services without partnering with a bank, and in many ways, as the entity with the regulatory interface, the bank is actually more senior than you in the relationship until you’ve hit real scale. In the pre-fintech, pre-2008 era, the FDIC approved 100+ new bank charters every year (one every 3 days), which is 2 orders of magnitude more than the average in the decade post crisis. I think this is one structural reason why you see most fintechs relying on bank partners to go to market initially, and to scale. In fact, I suspect that if regulators had clear paths laid out for new banks to be created and capitalized from scratch, you’d see more innovation and experimentation with different types of models, not less. This matters because the bank is such a complex piece of the ecosystem, and there are lots of ways the relationship can go wrong. Here are a few:
Regulatory issues: typically binary
From the outside looking in, regulatory actions are often the most binary or lacking in nuance (I say from the outside looking in because I’ve not worked at a bank in this capacity, and some of the lack of nuance might just be lost in translation between the regulator > bank > fintech). I’ve seen the regulatory interface go bad in a few ways; audits for KYC or AML failures, UDAAP violations and consent orders. Whenever any of these regulatory actions are taken, fintech startups are typically affected in one or both of two ways; they can’t onboard new customers, or they have to migrate off the bank entirely. As a startup trying to grow, both of these outcomes are functionally indistinct from death.
Network issues impact margins
Degradation in the banks relationships with card networks mostly impacts margins and customer experience, and is much less likely to be binary. Networks are incented for your program to grow as they make money on volume, but they also have incentives to protect the whole ecosystem, and are wary of bad actors as a result.
The most common issues I’ve seen in the network relationship is around how fees are calculated. We once had a program live for a year before our bank partner realized that certain network fees for settlement files, declines etc were being invoiced to the wrong place and had to be applied to our program, which meaningfully changed our operating margins. The bank <> network relationship (and the startup <> network relationship) is also set up to give the networks a kind of distributed leverage that multiple parts of the network organization can apply, in a way I haven’t really seen replicated in any other domain. Networks use this leverage liberally to force banks and startups into compliance. For instance, networks will sometimes provide financial incentives (you might know these as rebates) to a startup to encourage them to grow and route volume preferentially to one network instead of another. As a startup, you’re inclined to think about these as affecting your net interchange (basically you earn more interchange if you’re building an issuing program, and you pay less if you are building an acquiring program). The tactical way these are structured is not as a change to your pricing on every transaction, but as a rebate you earn (typically at quarter end or year end) in a bullet payment from the network. However, in your earnings as a company, these are just baked into margins. Networks will sometimes refuse to pay rebates as a lever to force you into compliance. This affects your working capital, burn etc. If you’re public, this affects earnings.
Incidentally, I think card networks are actually the most strategic big companies when it comes to managing their ecosystem. Companies like Apple and Google wield their influence like a bludgeon, so in every single interaction you’re aware who is more powerful and you tow the line. Visa is far more subtle; in each interaction you’re faced with two choices, one of which is obviously better for you in the short term, but makes you far more dependent on Visa going forward. You’re like the frog in the pot, by the time you realize you’re cooked, it’s too late and too expensive to extract yourself. I assume they’ve always been this way with banks. Of late, they’re no longer adversarial with fintech companies, and now try to figure out who the winners will be, and partner with them.
Operational issues impact execution speed and customer experience
Operational issues that arise are more often a rate limiter on execution speed and customer benefits. A few I’ve seen concern core money movement (ie what payment rails the bank has access to and how you use them), identity verification (what the bank enables you to use to verify a customers identity in terms of both what customers provide, what systems you use on the backend, and what policy gets applied), reconciliation (what you get access to to close your books) and exception management (what happens when something goes wrong with a customer or payment, who triages, who remediates, and what does the process cost. etc).
You don’t need it all on day one
Knowing what I know now, I probably wouldn’t recommend investing in getting a secondary banking partner while you’re building from scratch. It’s much more capital intensive than just one, and doesn’t yield you any offensive advantage (ie I’d rather have customers and a banking problem than two bank partners and no customers). With that said, having observed the collective experiences of lots of fintech startups in the 2020 to ‘22 era, it’s worth calling out that if you’re building a fintech product, in addition to taking typical startup risk, you’re taking some binary regulatory risk that’s difficult to mitigate in advance. I also don’t know if you can diligence your way out of this; its not clear what question you’d ask a bank that would elicit a revelation that another one of their card programs is problematic. In a lot of cases, that partner isn’t problematic yet, or the bank doesn’t know yet.
How to prepare
First, as you start to scale (once you’ve figured out customer acquisition and have a good handle on your value proposition), it’s worth capitalizing your company and structuring your team in a way where you can quickly adapt to one of these regulatory actions coming at you.
Second, stay lean enough long enough to be in a spot where you’re actually scaling and can capitalize in a way to fund this build.
Third, choose partners for payments, issuing etc [1] that have already done integrations with multiple banks (and ideally that have already successfully migrated programs like yours to a second bank). So if you face it, it won't be their first rodeo, and they've likely already had to abstract their interfaces away from being specific or too tailored to a single bank.
Fourth, make decisions upfront that reduce switching complexity if it ever comes to it. Moving customers to a new bank can be brutal. If you’ve issued cards and bank accounts, you’ll need them to accept new terms of service. If you’re not on a BIN that you control, you’ll need to issue brand new cards to them. If you’re not on your own routing number that you can migrate, you’ll need to issue new account and routing numbers (the notification of change process that enables ACH forwarding can help).
The things I think you can do upfront are 1) get your own BIN , 2) make sure your BAAS and bank agreement contemplates migrating the BIN and the customers to another bank, 3) make sure your ledger is decoupled from your bank partner (you can build one in house or use something like the Modern Treasury ledger service [2] , and 4) get a clean unused routing number, and ensure your commercial agreement contemplates/enables you transferring it to another bank. Getting your own BIN means you don’t have to re-issue cards if you get kicked off your bank partner, getting your own routing number means you don’t have to re-issue accounts (and break payroll, billpay payments etc) and having your own ledger means you don’t ALSO have to migrate the ledger across when you’re moving to another bank (it also means if the bank’s ledger goes down, your system doesnt have to go down with it).
All together, these don’t reduce the odds you need to switch banks, they just reduce the likelihood your business implodes if you do need to switch.
Thanks to Dimitri Dadiomov, Jim Esposito & Aaron Frank for reading this in draft.
Notes
[1] I suspect there's a similar set of recommendations/steps you can take for lending, equities, crypto, but I'm not as familiar with those categories.
[2] For disclosure, I'm invested in Alloy & Modern Treasury.