The default banking-as-a-service platform will be developer-first

February 2020

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;

Problem

There’s a few reasons there’s no developer-first card issuing platform;

1. To issue a debit/credit card, you need a bank
2. For most banks, the prospect of a stranger on the internet issuing a financial instrument, and funding and transacting on that instrument without the bank knowing the issuing entity poses a tremendous amount of regulatory & financial risk. One such risk is that a card is issued to a specially designated national, which would put the bank’s entire business at risk. This risk is high enough that the issuer-processors (Marqeta, Synapse and others) would rather not deal with the headache of a bad actor at all.
3. The presence of a sales and account management team imposes large ongoing fixed costs, and in order to fund those costs, most issuer-processor (or banking as a service) platforms impose large fixed fees on customers (even startups) and impose hurdles such as
4. These fixed costs are too high for most developers to bear in any kind of experimental/speculative project

Why being developer-first matters

Issuing financial instruments to customers is incredibly sticky for lots of reasons. For instance, if you’ve issued a checking account to a consumer, and that consumer is engaged, it means that the consumer’s paycheck is being deposited into the account, and they are paying their bills from it (electric, cellphone, mortgage etc) and likely using that card. It would take an insane amount of energy to get that consumer to link a brand new account + routing number + payment card to their mortgage/energy/gas/cellphone bill, and as a consequence, your product is incredibly sticky to that consumer.

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.

Proposal

I believe a developer-first platform should have the following attributes:

1. A developer should be able to sign up, verify their identity, get API access, issue, and transact on a limited number (eg 10) of cards/bank accounts before having to talk to anyone at your firm
2. The API should encode everything the developer needs to set, in order for the bank to be happy; their identity, their acceptance of the necessary agreements, the cardholder's identity and acceptance of the relevant agreements, etc
3. The API should also be able to request any additional specifics required (eg collecting a drivers license + selfie in addition to collecting other information) and verify them without having to independently integrate into a KYC provider.
4. The developer should be able to transact within some sane financial limit , and should be able to provide additional information programmatically to lift the limit. An example limit could be
   • Issue 10 cards
   • Each card can do a max of 5 transactions a week, with a limit of $100/transaction and $300 in total transaction volume
5. Cards should be customizable using something like a DoD/Inkjet printing technology, which would enable developers to create a pretty custom card (where the face of every card is different).
   • That said, there should be a default card, bank, and usage configuration that forms the low cost starting point.
   • At scale, an account management team can work with the issuer to create truly custom cards.

   Use Cases

   • Weekend developer / side project: Enabling any developer to issue a card during a weekend or a hackweek. Perfect for engineers at large software companies to try things out with minimal risk and minimal need for a BD person
   • Startup: The easiest way for any YC/Techstars company to issue a card. These first 2 use cases have the most potential to embed power laws.
   • Neobank redundancy: The easiest way for Chime and others at scale to spin up the second stack in their system; to help them load balance, add redundancy and business continuity, ensure that their primary bank/processor stack is competing on economics and quality.
   • Legacy Bank redundancy: Large legacy banks have invested significantly in their core processor (the technology which manages balances, account numbers etc) and their card/issuer-processor. Most legacy systems cost large banks around $3 per account per month for every cardholder (regardless of whether the cardholder is active). This is $3 for what is functionally a row in a databse table! This cost is the reason banks like Chase and Wells checking accounts have monthly fees; they’re passing the ongoing fixed cost of their technology providers on to cardholders. A developer-first issuer-processor would reduce the cost of experimentation sufficiently that even big banks can try things out with low risk.

   I call this strategy whale hunting, but with kelp :).

   Stripe as an analogue: embedding power laws

   One of the things I’ve always liked about Stripe as a business is that it’s one of the few businesses that embeds power laws. What makes Stripe work is that once a year, a startup launches that, 10 years out, will do $10b in processing volume (Shopify, Lyft, Styleseat etc). This doesn’t preclude large companies moving their processing over to Stripe, but it’s an approach that is functionally only available to the player in the category that is the default, and for every startup starting out today, Stripe is the default payment processor. If you ask any startup founder today how they plan to process payments, 9 times out of 10, they'll respond with "Stripe".

   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.

   Meta-bin + Meta-routing number

   Today, banks and issuer-processors have a lot of leverage over the companies that issue cards. The bank owns the BIN and routing number and directly interfaces with Visa/MC. The processor (or BAAS provider) manages the BIN on the banks behalf, and assigns sub-BIN ranges to companies/startups that want to issue cards. This means that if you rely on a specific issuer-processor, and you’ve issued millions of cards, and you’re not a bank, switching out the issuer-processor or the bank (also known as a “portfolio migration) means you have to resend millions of cards to your customers. There are several problems with this; 1. the customers all have to accept a new cardholder agreement, 2. you have to pay to ship them all new cards and incur the costs of the plastic, 3. once received, the customer still has to activate the card, 4. once activated, they have to wander around the internet and relink the card to Amazon, Netflix, Spotify etc. and 5. this effort requires time, money, people, and generates zero additional revenue.

   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.

   Getting there

   This essay really mixes 2 concepts: 1. creating a developer-first issuing platform to make it easyto start issuing cards/bank accounts, and 2. Creating a meta bin/routing platform to make it easy for issuers to switch banks/issuer processors. I think it would be pretty hard to execute both in parallel. Building a high quality issuer processor platform that is developer focused is a mostly an organizational design problem; many banking-as-a-service platforms that exist today have the technical foundation to do this, but haven't yet convinced their bank partners that this is worth doing, and they've built sales heavy organizations. Building an issuing platform with a meta-bin/meta-routing concept is primarily a business innovation challenge; the technical hurdle is material because there's no prior art, but the hardest thing to do will be convincing Visa and Mastercard that this should exist. You'll probably need the tailwind from the developer first approach to fund the meta-bin concept, so that's where you start, and then the meta-bin/meta-routing concept comes when you attain scale.

   Thanks to Temi, Femi, Jim Esposito, Justin Overdorff, Bo Jiang, Dhanji Prasanna, and Chris Skeels for reading this in draft form.