A few times a month, a founder will ask me a question like:
“hey between i2c, Synapse, and Cambr - who should I use to issue cards to my customers?”
As of this writing (Feb 2020), a startup that wants to issue cards or bank accounts has several options but no default. Today if you’re starting an online store, Shopify is the default online store. If you’re launching a startup and need to collect payments, Stripe is the default payments service. Today, if you’re building an application that is reliant on SMS, Twilio is the default. Defaults are the no brainer choice – they’ll solve 99% of your use case on day 1, and for what they don’t solve, you either a) won’t need it till you’re scaling or b) can probably extend them yourself. Today if you’re issuing a card or a bank account, there’s no such option. You’ll need to go through a sales form on some website, sign up and have a chat before you can actually get API keys.
I think the “default” position is one of the most valuable positions to chase in financial technology today, and for the companies with the technology it’s easy to chase, and for everyone else it’s hard. It’s valuable because fintech is shifting to a phase where financial services are more and more being built into software products directly. Shopify building in merchant payments via Stripe is the poster-child for this, but you’ll see it everywhere you look; Uber (with the Uber Card), Lyft (with instant push to debit) and others. To be the default; to be the company that the mythical two people in a garage choose to use, or that someone building a side project on the weekend chooses to use, onboarding must be developer-first; a developer must be able to issue, fund and transact on a card or bank account without talking to a human at your company. A whole slew of use cases and demand are trapped behind the high hurdle it takes to interact with the major issuer-processor platforms and card issuing services today. For this essay I’ll use issuer-processor and Banking-as-a-service provider (or BAAS provider) interchangeably; it’s the technology platform that issues cards, assigns card numbers, processes card payments, maintains cardholder name/dob etc, and often (but not always) manages balances.
Today, banking-as-a-service and issuer-processor platforms compete on who has the best sales team. This looks very much like credit card payment processing before Stripe and Square came along - sales teams went out and won deals. In a post Stripe world, any developer can be up and running taking credit card payments in a few hours. This doesn’t yet exist in card issuing/banking-as-a-service, and when it does, it will have the same transformative effect, enabling software companies to embed payments into their offering, and adding incremental operating leverage to those who do.
The issuer-processing and banking-as-service companies out there today have the technology to do the job, and have reasonable sales teams, and have reasonable wins, but that’s not sufficient to be the default, and it’s not sufficient to break away from the competition. To be the default, they have to be developer-first, meaning that a software developer can issue a card from scratch and start transacting, without first having to talk to someone at your company. Here’s how I think it should work;
Given that, what happens a lot of the time when an issuer needs to switch issuer processing/ach processing platforms, and by extension needs to switch the account and routing number issued to a customer, is that they lose a lot of cusotmers. A recent example was Simple, switching from the Bancorp to BBVA. [QUANTIFY THIS]. There are a few paths an issuer can take to make this slightly less painful such as silently switching in the background but ensuring that the old credentials work for a long time, providing financial incentives to get people to switch, etc. Overall, however the stickiness of cardholders to an issued instrument means issuers are sticky to the issuer-processor and bank they are on, modulo some gargantuan financial incentive to switch.
This means that as a new issuer-processor, you have a couple of GTM strategies available to you. Sell better: have a salesforce that is better at identifying when banks and issuer fintechs want to switch or add a new banking-as-a-service platform, and better at selling to them. The majority of banking-as-a-service platforms adhere to this strategy, including Cambr, Marqeta, i2c, Synapse, Galileo and others. This approach is very friendly to the chief revenue officer/sales org of a company. Be less expensive: cost less (financially) for issuers fintechs and banks to onboard onto and use. The majority of old line issuer-processor platforms such as FIS, Fiserv, Jack Henry and TSYS follow this strategy. Most of sauce is in having a basic set of services that is extremely inexpensive and configurable, and additional services that are charged on a fee per account per month basis. This enables the bank/issuer fintech to optimize their costs by choosing which fees they are willing to pay by choosing which services they are interested in using, and what costs they’d like to pass on to consumers. This approach is very CFO friendly Be easier: enable a developer to issue cards within a weekend. Zero banking-as-a-service platforms are doing this today. It could work for a few reasons: A lot of banking-as-a-service platforms have holes and edges in places that are not obvious at the outset; by the time you realize they’re not right for you, or they do something in a weird way that forces you to make a product tradeoff, you’ve signed a contract and are 6 months into implementation, with deliverables baked into your organizations goals and your entire organization aligned to make it work. This forces the banking-as-a-service platform to simplify their API interface sufficiently to make it possible for a developer to execute end-to-end without talking to salesperson. Which means, 2 people in a home office anywhere in the country could spin up a program. This means that a bank or issuer fintech could evaluate your product before talking to you, and could get a product in the hands of internal stakeholders before signing an agreement, negotiating, etc. It also means, that, for many banks and issuer fintechs, who today would absolutely love to have an alternate banking-as-a-service platform for myriad reasons (Economic leverage vs. their existing vendor, featureset, scaling), they get to try a new one, without the biggest cost that currently stands in the way; getting the organization aligned and getting operating and engineering headcount required to stand up a new bank stack.
I call this strategy whale hunting, but with kelp :).
The analogue here is that, there’s unbounded upside to becoming the card issuer or banking-as-a-service provider that becomes the default. Being the default (and being inexpensive and developer-first) enables others to experiment with card issuing, and that experimentation is the only thing that will give you the chance to embed power law dynamics into your business model. To embed power law dynamics, your edge can’t be sales, because then you’re relying on your sales team as a filter for which startup is going to have massive transaction volume 10 years out. Today, pretty much every banking as a service provider in-market is sales driven, rather than developer driven.
The problem here is not technical - I’m pretty certain the infrastructure can be built to make BINs portable. This is a business (and probably partially a regulatory) problem. BINs today can only be owned by banks, who are principal members in Visa and Mastercard. Admittedly, I’m not sure why this is.
One solution is to create the concept of a meta-bin. This would be a BIN range not owned by the bank, or the processor, but owned by the specific issuer and managed by the processor/BAAS provider. Having a meta-bin would mean that the issuer can seamlessly switch banks without shipping new cards (and all the risk that comes with portfolio migrations). It would also mean that the network (Visa or Mastercard) could direct incoming authorization traffic and settlement messages to any issuer-processor/BAAS provider chosen by it’s owners. An issuer that owned a meta bin could switch banks and processors with minimal negative impact to cardholders.
To make this work really well, you’d also need a meta-routing number. Similar to a meta-bin, this routing number would be owned by the issuer (company thats acquiring cardholders) and would enable the issuer to switch the underlying bank, without forcing cardholders to enter a new account / routing number combination into their payroll system.
Thanks to Temi, Femi, Jim Esposito, Justin Overdorff, Bo Jiang, Dhanji Prasanna, and Chris Skeels for reading this in draft form.