Fintech ?? Food - 5th August 2021
Hey everyone???, thanks for coming back to Brainfood, where I take the week's biggest events and try to get under the skin of what's happening in Fintech. If you're reading this and haven't signed up, join the 7,644 others by clicking below, and to the regular readers, thank you.???
Hello ??
This past week Y-Combinator held its demo day for the Summer 21 batch of companies. Usually, I like to give a quick summary of those for you Brainfood readers. This batch, however, had 69 (yes, sixty-nine) Fintech Companies at demo day. So it’s going to take a little while to get through. So watch this space ??
PS. Can’t stop thinking about loot, hbu?
Weekly Rant ??
Fintech Providers - Making sense of the noise.
In the past half-decade, new providers have taken parts of the Banking-as-a-Service stack and brought it up to modern software standards, but how they've done that differs. We can picture the stack as below, at an abstract level?(there's tons of nuance missing here, of course, but it's a helpful frame for a conversation).
Then when you map providers against this map, you'll see things get messy.??
(To every provider I missed here please don’t @ me. Also for the sake of fitting logos on a diagram, I know some providers here do more than the categories they’re in, some arguably less. I guess that’s kind of the point. It’s very hard to do apples to apples in Fintech provider land.)
There’s so much nuance in what each of these companies actually offers. Amount is much more vertically integrated, as is Solaris. A company like Alloy is much more horizontal, and may often partner with many of the other names you see in the diagram. There’s almost no true apples-to-apples comparison in Fintech provider land.
Two providers might look like they do "compliance," but what they actually do under the hood can differ dramatically, as can?how they do it.
Some of these folks have full banking licenses, some have payment licenses and existing partnerships, some just provide software. They all work for someone, some of the time.
But the trend is, the broader the offering, the less configurable (or more opinionated) the offering is. If it does more for you, it’s harder for you to change it to work the way you want it to.
None of these approaches are wrong, but they present their customers with a trade-off.
Opinionated vs. Build and assemble yourself.??
Last week, I spoke to the CTO of a consumer Fintech who lamented the provider landscape (especially as they are building a remittance app, which involved a lot of cross-border activity). This CTO had worked as an engineer in countless consumer Fintech companies and encountered the same problem repeatedly.?
The choice Fintech builders face is between a highly?opinionated ?provider who gets you to market quickly or building yourself to solve your specific problem.
An opinionated provider makes choices on your behalf to help you get to market quickly. The canonical example is Stripe, which hides mountains of payments complexity behind a single API. Stripe is making choices about how to handle errors or how analytics work. Customers have almost zero internal build to do to be able to accept payments. The same is true for providers in compliance-as-a-service, fraud-as-a-service, and more who own either a horizontal or vertical layer in the BaaS stack.
To borrow from?Packy M's "APIs all the way down," ?when something needs to get done,?but it's not worth our time doing it, hiring a 3rd party API provider like Stripe makes sense.
An opinionated provider not only improves time to market, but they're also 100% dedicated to that thing you don't want to waste your time on. They help companies reduce their R&D spend and prevent them from maintaining code every time the payments world changes. Oh, and payments and finance are regulated; not having to deal with all of that complexity is a massive accelerator.
If you're at an early stage or simply want a capability that "just works," opinionated APIs and providers are the dream.
There are a few challenges with opinionated provides, though.??
Opinionated providers often cost more than if you built a capability yourself. The more opinionated the provider, the more margin they can justify because they displaced more of your own R&D?Capex and Opex ?spend.
Opinionated providers also, by their nature, work in a certain way. That might be fine if you're part of their core user base, but going back to the example of our CTO building a remittance app. If your fraud-as-a-service provider assumes anything moving into Kenya has a higher probability of fraud, that might break your product.
Interestingly, we're now seeing a middle ground emerge. If we go back to Stripe as an example. The emergence of "Payfac-as-a-Service" is designed to be halfway between building a payments division yourself or outsourcing wholly to a PayFac like Stripe. Companies like Infincepft, Finix, or Payrix play in an interesting "we'll make you a PayFac with our more configurable platform" space.
The reality is opinionated vs. build isn't a binary choice; it's a spectrum.
The choice is a trade-off. How important is time to market? How much can you risk vendor lock-in for?this capability??And how much do you want to own the economics of that capability?
As every company becomes a fintech company, owning the economics can be appealing. But in the earlier stages for a Fintech company, getting live and showing traction to investors is vital.
The new primitives of finance help.
One way out of the spectrum of opinionated vs. build yourself is to have open-source codebases that contain the individual software primitives your developers need.
As covered previously, projects like Moov and fragment have taken the non-differentiated code built in-house by developers and built projects and communities around those open-source codebases. This code is often "close to the metal," handling deep payment infrastructure or lookups against sanctions lists.
These primitives of finance can be combined as developers see fit and often do one thing exceptionally well. The codebases are battle-tested as some of the biggest companies around the world adopt them at scale and make improvements over time. The primitives don't carry the same level of opinion as the API providers but help avoid some of the self-build issues we saw previously.
The primitives often suit larger companies operating at scale and improving their unit economics or developers looking to something more bespoke than the API providers would allow.
These primitives present their own challenges, though.
If you're a relatively smaller organization, you have to add them to your platform or around other providers you have. This requires custom work and build. This potentially increased Capex, the effort involved, and time to market.
领英推荐
We're also in the early stages of developing fintech primitives. They cover a small % of the Banking-as-a-Service stack and are very US-Centric (so back to our remittance app for Africa, not helpful in the short term).
The Orchestration Challenge
There’s something missing from our picture.
How do all of these providers fit together?
It feels like there’s a box missing from the diagram, that runs alongside the whole stack, orchestrating it, and allowing you to make propositions out of it.
We have a few approaches emerging.
When companies are small, they often make design choices that enable speed to market, but that create technical debt or vendor lock-in. So they’re likely to choose an “all-in-one” solution that gives them as much of the stack as possible.
Companies that scale eventually get to replace their technical debt, but they do so by building their own orchestration software.??Every fintech company or non-bank that does Fintech is now wrestling with an orchestration challenge. Imagine you're a global e-commerce platform, and you're live with Neobank like features. Maybe you have partners for the US and, to some extent, Europe. What about other markets where those providers don't exist??
Maybe loosely coupled BaaS is the way there, or maybe we need an alternative. If everyone is building the same orchestration code, maybe we need that, and just that.
Just as we have seen e-payment orchestration become a category, I think we'll see Fintech provider orchestration become a category. Maybe that comes from the existing BaaS players, but I actually think it in itself is a specialism. For companies who don't want to use a BaaS provider but do have an orchestration problem. Who want to avoid vendor lock-in, potentially go multi-geo, but don't want to build all the primitives themselves. What do?they?use? ??
ST.
------------------
4 Fintech Companies ??
1. SaaStrify ?- Self-driving SaaS procurement
2.?Prive ?- Amazon subscriptions feature for any merchant
3. India Gold ?- Gold storage and collateralized lending
4.?Bloom Money ?- Community-Driven Fintech savings?
Things to know ??
Good Reads ??
Tweets of the week ??
Only for substack subscribers :)
That's all, folks. ??
Remember, if you're enjoying this content, please do tell all your fintech friends to check it out and hit the subscribe button :)
Payfac-as-a-Service empowers software companies to create an embedded payments experience that is delightful, transparent, profitable, and stupid simple ??
3 年Love the shoutout and analysis on PayFac-as-a-Service! Keep up the great work Simon Taylor!
Growth-Focused Sales & Business Development Leader | Expert in Payments, Fintech, & Strategic Partnerships | Proven Track Record of Driving Market Expansion, Revenue Growth, & Client Retention
3 年Always great content!
Chief Market Officer at Casca
3 年Orchestration… ??
Builder, Orchestrator, Salesman. Passionate about how #technology impacts humanity. Advisor in #BehaviouralSciences & #ArtificialIntelligence. On path of decoding human character.
3 年really good reads and analysis, Simon! I am keen to see how BNPLs would play out in Asia and what Amazon will do about these, as there seems to be a bigger appetite for BNPL in Asia than even in Europe
?????? Co-founder & COO @ upcover | ex-Goldman Sachs
3 年Great read as always, thanks for sharing Simon. Would love to see your take on the massive announcement by the Indian regulator RBI on account aggregator framework.