” We get around together, we down forever,
And we won’t get mad when caught in bad weather “

Run D.M.C loved their stripes very much. They professed their loyalty to the German brand in 1986 and in turn it supported their further development as a huge international success.

Similarly, Fintech loves its own Stripe, and for very good reasons. No doubt, Stripe is one of the most internationally successful fintechs of all, supporting over 1 million businesses around the world. Every venture investor wants one in their portfolio. Every fintech wants to acquire sticky customers like it. The playbook is simple and easy to measure. Onboard plenty of online merchants, eliminate overheads by making the platform fully self-serviceable, relentless pursuit of flawless back-end processes to ensure the highest possible payment success rates and, finally, charge a commission on each transaction. Marc Rubinstein penned a great post on his excellent newsletter Net Interest about this.

At its heart, Stripe believes payments are a problem rooted in code, not finance. Consequently, Stripe is designed for developers, to the extent that when it launched in September 2011 the service was initially known as /dev/payments. Although the Collison brothers had to change that name for various reasons, the focus on building for devs did not budge an inch ever since. Stripe invests a great deal in making it as simple as possible for online businesses to integrate its software products. Software is eating the world, isn’t it?

Back in 2014, JPMorgan’s Jamie Dimon famously warned that Silicon Valley startups are coming to eat the bank’s lunch. Mr Dimon probably didn’t imagine back then a wave of founders looking at banking more widely as a code problem, rather than a finance one. What if banking could be distributed and consumed, like software, as a service, with only a few lines of code? It turned out it certainly can be done. The growing ubiquity of APIs, a few regulatory developments like full e-KYC and the e-money regime, and small US sponsor banks operating under the Durbin amendment for interchange fees created the conditions for the rapid rise of Stripe-like API-first banking as a service platforms. Easy integration, simple pricing with low upfront costs and speed to market were the bedrock of the BaaS value proposition. Looking across multiple BaaS offerings, one finds the same message appearing again and again – build in minutes, launch in weeks. These platform providers, mostly non-bank orchestration layer platforms, take huge pride in their developer-first APIs. All the while, investors were cheering for SaaS metrics, even in recent bad weather.

For a certain type of BaaS customer segment, this model resonates very well. Globally, hundreds of consumer and SME fintech applications were built on top of that middle layer; some are very successful indeed. These fintech customers have a few things in common. They usually sign up with the platform when they are at their early stages. Speed and a simple cost structure are critical in order to get to market quickly and cheaply. Their founding teams often share a mix of finance and tech backgrounds and (sometimes only think) they know the required components for their product. The API building blocks providing the fundamental banking products – accounts, payments, debit cards – are all they really need to start shipping their product. Start ups usually appreciate the self-service model too. What these early stage start ups lack is a user base. They have to go and get it.

So how does a BaaS platform sustainably make money from this customer segment? One option everyone is crossing fingers for is to land the next Revolut. That could work very well indeed. However, there has been no Revolut since, well, Revolut. The other option is to operate, effectively, like an angel investor to a big number of early stage businesses, price to capture their business and hope that enough of them will grow to a reasonable scale and, with them, your top line.

There are many problems with this strategy. Simon Taylor wrote in a recent Brain Food newsletter (subscribe here) ‘fintech founders don’t start with the end game in mind’. They inevitably iterate until they they find product market fit or close shop. They then have to acquire a customer base, all the while the BaaS platform is carrying all kinds of risks with that fintech client. Platforms, pressurised by their investors to continue to show growth in signed contracts and contracted ARR, are forced to expand their search and onboard more fintechs, sometimes fintech embryos, and in some cases do a little less due diligence and a little more reliance. At some point the regulators and the partner banks started to take notice and we are currently seeing the impact of these revelations.

Banking as a Service is now a whole fintech sub sector in itself. The early ‘angel investor’ model has been useful to prove the viability of the concept and drive investment $ but it is limited in terms of a road to profitability. It is important for our sector that platforms continue to serve fintech firms. However, the road to profitability, I believe, means BaaS providers have to adapt in two ways:

1. Focus a little less on the ‘as-a-Service’ part and a little more more on the Banking bit. Whichever way you look at it, there is ultimately one proven way to make profit in banking – credit. Payments, accounts, and debit cards are all on an inevitable race to the bottom when it comes to profit margins.
2. Build the value proposition for non-finance enterprises, and the appropriate internal processes to support that, from sales through risk, compliance and customer support.

Following years of market education we are finally seeing significant interest from all kinds of companies – the retailer Axel Johnson in Sweden (with SEBx), Indonesian e-commerce Bukalapak (with SC’s Nexus) and Netsuite (HSBC). These are very different types of customers compared with BaaS tech led early adopters. It is, perhaps, time to wave the strictly Stripe-ish business model goodbye. Here’s why.

Non finance enterprises naturally do not possess the deep FS knowledge fintech does, and most probably don’t want to fill that gap either. The business challenges they face are inherently different because they are not solving for customer acquisition. Increased engagement or user stickiness is the name of the game, with new revenue streams from banking a close second. A logistics giant has different needs to an e-commerce platform or a large retailer. BaaS providers require a higher degree of sector knowledge and co-creation if they are to deliver the best solution for the enterprise. Deals (these are not partnerships, by the way…) will not be won by pointing at the APIs and sandboxes saying ‘look how simple they are, just go ahead and build on them’.

Co-creation also helps build trust and expertise. Trust is paramount when the enterprise effectively takes a brand value risk  upon adding a financial service to their user experience. There is nothing more important to these companies than the brand they spent years cultivating. They obsess about every customer interaction. Any failure (a delayed payment is not a failure when it has to go through checks, but the user does not care) on the banking side reflects immediately on their own brand (a good example of the possible outcome is Walmart lawsuit against Capital One).

Enterprises need to know they have a banking provider that understands that and has the appropriate level of support to mitigate any such risks. One doesn’t learn about one’s customers’ unique challenges by referring them to API docs.

Make no mistake, the BaaS tech stack must be enterprise grade, immaculately documented and yet simple to integrate. The enterprise’s tech team still hold a big sway on the decision to go with one provider or another. Having said that, the engineers are not in most cases the main customer at non-FS enterprises. Your real customer is probably less attracted to your developer-first image and more to your understanding of their industry and being in it with them for the long haul.

Large enterprises, with their existing user base, are more likely to require credit products more quickly than sub scale fintech clients. They don’t have to lure in consumers (or SMEs) with cheap/ free accounts or debit cards. Credit often provides stickiness and interaction with the end consumer. Credit is hard, and credit needs scale, but credit is how financial services make money and BaaS need to do more in credit. Beyond credit are the great profit pools of savings, investments and insurance. You know, finance.

Finally, BaaS providers may have to review their pricing strategy and ask themselves whether they are leaving anything on the table. Pricing for value, not volume, may be required. In any case, introducing credit to the product mix increases the complexity of any pricing model so it is a good opportunity to iterate on it all.

The market for BaaS is immense. We’ve only started to scratch the surface of possibilities. There are great sets of tool kits out there available to build upon from a growing number of providers globally, either from banks or platforms. These API ‘lego’ building blocks may be confusing for some large clients. Turning those blocks into beautiful embedded finance ‘models’ will force business and operating models to evolve. Embedded finance is not a tech revolution, it is a business model revolution. I used to mean that in the sense that traditional banks must evolve to maintain relevance in an embedded world. It turns out BaaS providers also need to evolve.