Jan-Erik Asplund
Background
Justin Howell is the co-founder and CEO of banking-as-a-service platform Rize. We talked to Justin to learn more about the complex back-end infrastructure of fintech and how banking-as-a-service platforms look to stitch together functionalities like ledger, checking, and card issuing.
Questions
- Let’s start with how Rize came about.
- You mentioned that finance on the back end is separated into these silos that customers don’t see and that don't really talk to one another or interoperate, which manifests in these building blocks of fintech that companies find difficult to put together into a unified view. Is that an accurate summary? What are some of the common building blocks and why is it so had to make them talk to one another?
- It sounds like partnering with point solutions that can do individual tasks is important for you in providing that connective tissue.
- Could you dive into a little more detail on what it looks like for these tools not to play nice? What does it look like when you're stitching together a bunch of point solutions, and it just sucks, and what is Rize doing to correct that?
- You mentioned earlier the idea of building backwards from the customer point of view, focusing on customer needs versus building an abstraction layer over the banking core. Is that the main way you view your positioning as different from the new generation of banking-as-a-service companies -- like Bond, Unit, Treasury Prime -- and is there other stuff as well?
- Your vision hinges on the idea that companies today might want to add just banking or a credit card to their app, but that in the future an increasing number will want to add brokerage and other products. What other kinds of products are you envisioning, and what's the narrative you see driving this trend of ever more horizontal products being bolted on?
- What’s your take on the different dynamics between serving embedded finance companies versus a company focused on fintech, like a neobank comparable to Chime?
- I feel like that helps explain a little bit why, for example, Square uses Marqeta with Cash App. They’ve gotten the economics to work out to where it makes sense to use Marqeta versus spending a ton of time building their own version.
- You’ve mentioned this comparison between the cloud and banking and finance. Is the way that banking and brokerage work on the back end so disconnected and so siloed that it’s an even bigger mistake to build your own, versus in the cloud where maybe you can build everything except you outsource one aspect easily to AWS?
Interview
Let’s start with how Rize came about.
My co-founder, Kirk Voltz, and I originally got together because we shared a vision for a much more customer-centric and intuitive approach to financial services. The problem that we really wanted to solve was: How do you take this complicated financial services world that is regulated into different silos -- like banking, brokerage, lending, crypto, and insurance-- and map them to how people think about and use money out in the real world? End customers really don't see the distinctions amongst those silos, despite the fact that, within the industry, not only do those silos never talk to each other, they literally may not know how each other operates. That's the gap that we wanted to bridge there.
In many ways, what is now known as embedded finance -- being able to take existing capabilities and combine them into existing user experiences -- is how we thought things should work, but when we started five years ago, that wasn't a concept yet. What we really understood were the consumer pain points, which is why Rize actually started as a consumer fintech. We built automated saving technology and then we brought investing and banking into that. Again, we were interested in starting to knock down some of the silo distinctions, because for an end customer at the end of the day, it’s all just money. You really don't care how the engine works: you just want the car to go from point A to point B.
What we discovered in the process of building all that for ourselves is what we had originally thought was merely a complicated UI/UX matching problem, was actually an infrastructure problem. You can’t build the right user-centric, financial user experiences if you don’t build out the missing horizontal connective tissue. As we talked to other fintech builders, we discovered that pretty much everybody was running into the same infrastructure problems and having to recreate the wheel -- and usually doing it badly.
It turned out that what we had originally built for ourselves was a much more flexible and elegant solution to those infrastructure problems than anybody else had done to date. Thinking from the customer's perspective led us to build a very different set of architecture; our flexible, synthetic account core.
So we ultimately pivoted the business from being a B2C builder ourselves to becoming an API-based B2B platform that serves other fintech builders around these core infrastructure elements. We're the only player in this space that's been on both sides of the table, which gives us a very unique perspective and allows us to very legitimately say, "We've been in your shoes.”
You mentioned that finance on the back end is separated into these silos that customers don’t see and that don't really talk to one another or interoperate, which manifests in these building blocks of fintech that companies find difficult to put together into a unified view. Is that an accurate summary? What are some of the common building blocks and why is it so had to make them talk to one another?
I think you interpreted that correctly. We really start with the UX side of things, while the industry usually operates with this complicated many-to-many matching problem. It's all just money to an end customer. But that money sits in a variety of different underlying accounts, gets manipulated by a variety of institutions and moves in a bunch of different ways. The pieces were never designed to talk to each other.
One of the trends that you saw in the first wave of fintech was that data itself wasn't good enough. You had this whole wave of Personal Financial Management tools that were all the rage for a period of time and that would give you visibility into what's happening with your money across a variety of different pieces of that ecosystem, but the reality was visibility didn't do much. What end customers really wanted was, "All right, you just convinced me that I should do something. Can I just hit a button and it happens? Can you put it on automatic for me?" That's where you go to the next layer of needing a set of shared infrastructure that folks can build against that can actually give you the ability to put things on automatic.
It’s pretty similar to the early days of the internet and cloud pre-AWS. In that world, you were just trying to bring a new website out in the universe, but you had to go buy and manage all your own servers in order to do it, which was really not most people's area of expertise. Then AWS came along and said, "Well, we're good at that stuff. We'll just give you guys a set of APIs. Now you can focus on actually just doing customer acquisition correctly and building the right product. You can't run Netflix without AWS, but Netflix is a content company, and that's where they want to spend their time and effort, not on the underlying pipes that allow them to run 35% of the internet on a given evening.
In our space, the equivalent to that was trying to bring a new banking product into the world: I have to go find a bank, convince them to work with me, figure out how to integrate to them, then I’ve got to go find a processor and integrate with them.
What's missing in many cases is that horizontal connective tissue that can take all those different point solutions and weave them into one API or one contract so that I do this stuff once and it all works, as opposed to having to do it all those different times to the point where they were literally thinking, "Well, we might have to go build that ourselves." Until they found us and realized, "Oh, that's exactly what Rize does."
It sounds like partnering with point solutions that can do individual tasks is important for you in providing that connective tissue.
That's right. I think the difference between our world and the world of, say, AWS is that AWS owns the entire stack down to the studs. In the financial world, that actually doesn't make a lot of sense, because it's so regulated. Being best in class at something like KYC/AML, like Alloy, is a massive multi-billion dollar business in and of itself. Being best in class at being a custodial bank partner is a job in and of itself. Being best in class at being a brokerage custodian, like a DriveWealth or an Alpaca, is another job in and of itself. I think it'd be foolish in this space to try to do all of those things extraordinarily well, when you've got folks who are just focused on that particular area. They're always going to be better at that.
But you end up with an ecosystem of different point solutions who are good at certain different things but haven't really thought about themselves as an ecosystem before.
Could you dive into a little more detail on what it looks like for these tools not to play nice? What does it look like when you're stitching together a bunch of point solutions, and it just sucks, and what is Rize doing to correct that?
Bad infrastructure can kill a lot of businesses. Even the ones who manage to break through and have a huge amount of success are finding themselves hugely limited. When everybody sees the opportunity to start moving horizontally and adding more capabilities, they think “now that I've built a customer base, how do I surround them with a much wider, more seamlessly integrated set of products and services?” There's a reason why that's really hard to do. All of these Fintechs were built with very rigid tech stacks and adding additional pieces to an old stack is really, really hard. So you see the consequences of outdated technology all the way up and down from infrastructure problems that can prevent you from ever really getting a chance to get to market, to the folks who have had a lot of success, but now are stuck with their ability to only do one thing. They need to add new capabilities to grow their business.
At Rize, we focus on a world where, again, our job is to be the horizontal connective tissue so that your process of getting to market as a neobank is not a 18 to 36 month process, but something that you can do in as little as 6 to 10 weeks. If all you ever want to do is have a bank account and a card, there's a bunch of businesses that can solve that problem for you these days. But if you have a vision where you ever want to do more than that, the way that we've developed our technology makes it a whole lot easier for you to add more capabilities and flexibility over time.
You mentioned earlier the idea of building backwards from the customer point of view, focusing on customer needs versus building an abstraction layer over the banking core. Is that the main way you view your positioning as different from the new generation of banking-as-a-service companies -- like Bond, Unit, Treasury Prime -- and is there other stuff as well?
When we think about differentiation, we start with what we call the synthetic core. The problem that we wanted to solve with the synthetic core was originally for ourselves, back when we were on the B2C side of things: how do you build a product when you need to be able to, say, combine capabilities across banking and brokerage?
The fundamental building block of financial services has always been the underlying regulated account. Traditionally you’ve had two different sources of truth, because you’ve had accounts on both sides. Again, you look at some of these guys with 15 million plus accounts who are trying to add some of those additional capabilities, and they have an immense amount of difficulty doing so because the source of truth has always been these underlying accounts. You have to build a whole bank stack, you have to build the whole brokerage stack -- those two things were never designed to be able to talk to each other. Because we approached this problem from the other direction, we always said, "this needs to ultimately roll up to an individual customer." We need to create a world where, regardless of where money sits or where things are operating across a variety of different financial verticals, it's always got to be able to roll up to a single customer.
It feels like a normal account and it has the same kind of characteristics as a normal account that you as the builder think about, but instead of having the underlying source of truth be the bank account or the brokerage account, you can do it at what we call a synthetic core layer that can reach down, handle and utilize all the different capabilities of the different verticals that you plug into it, allowing you to build the experience around an end customer’s wants
What that means for our customers is you can start with a very simple use case, just an account and a card, but as you want to add more capabilities nothing has to change about your build in order to access that. We effectively just gave you a new set of switches that you can turn. You get a lot more future proofing by building against Rize, because as we add more capabilities, you don’t have to find ways to connect a banking-as-a-service platform to a brokerage-as-a-service platform and then have to create the connective tissue over those kinds of pieces. We've created a world where that abstract layer is already there.
A variety of other differentiators flow from that. We're not only the cheapest out in the market by quite a bit, but we have much more flexibility to really price appropriately to each client’s end use case as opposed to "here's one size that fits all."
Compliance is also at the absolute core of what we do. We're really able to provide compliance as a service to our customers, saying, "Look, here's everything that you need to get yourself off the ground, templated out for you already. And then all the different pieces that you're going to need to be able to maintain compliance and have visibility up and down the stack are already built into the platform for you." We've taken away that trade off -- it used to be in the early days that either you're going fast or you're going compliant, but you can't really do both. You can go fast, you can get to market fast, you can start to scale quickly, and you've got the tools that you need around that to have compliance as well.
Our synthetic core, pricing, and compliance management system are a bunch of the big areas where we really differentiate ourselves from our competitors.
Your vision hinges on the idea that companies today might want to add just banking or a credit card to their app, but that in the future an increasing number will want to add brokerage and other products. What other kinds of products are you envisioning, and what's the narrative you see driving this trend of ever more horizontal products being bolted on?
We see the world being driven by a combination of embeddable and multi-product use cases. I don't know if you saw Matt Harris's piece on fintech 3.0 -- where fintech 2.0 is embedded and fintech 3.0 is this world of seamless interoperability of money, assets and identity operating freely and instantaneously across multiple verticals.
That really is the way that we've always envisioned this future. You're going to need different areas where assets can exist on the credit side of the world or on the investment side of the world. But it’ll be kind of the seamless interoperability of, say, Cash App -- which I think has probably done a better job than anybody else out there -- where within a single application, you can have cash, you can operate in crypto, you can operate within investments. That's hugely complicated on the back end, but it is woven into a seamless experience that makes a lot of sense for an end customer, so we don't think it's particularly interesting.
It’s been fun for us just looking at the first wave of clients going live right now. They're focusing on a specific niche of customers that might be college students, military, or what have you, but they’re already thinking about–within a year or two of launch–being able to provide the right kind of investment and the right kind of credit products. All of those different pieces that are really going to be tailored to the needs of a specific niche audience. That’s one area that has provided some nice validation.
What’s your take on the different dynamics between serving embedded finance companies versus a company focused on fintech, like a neobank comparable to Chime?
I think there certainly are differences between serving a fintech versus more of a non-financial company looking for embedded capabilities. But what I think is interesting is, to some extent, we're starting to see some conversions between those two worlds.
Where we're starting to see some convergence between those two is that both sides don't want to have to spend as much time on the true fintech aspect of this. The brands are clear on this from the beginning: “I don't want to have to become a fintech in order to offer fintech capabilities. The easier that you can make that for me, the better.” What we’re starting to see over on the fintech side of things, too, is that also hits us as well: “Just because the financial part of the business is the business doesn't mean we want to have to get deeply down into all the infrastructure side of the stuff, either. We really want to be able to focus more on the right UX and all the other things, too.” There's just more of a financial element to it. I think those are the guys who are more quickly moving towards: “And I'd love to be multi-product around some of that stuff, because not only does that give me more ability to more deeply tie into my customers’ lives, it starts to open up additional revenue channels as well, so it's not just interchange-oriented.”
So I'd say we see less of a difference between serving those two different communities. Part of the challenge of the business is, how do you build things in such a way that you can effectively serve both? Then it becomes a little bit more of a marketing and customer acquisition challenge for us as a B2B platform. How do you talk a little bit differently to a fintech versus a brand? That's some of the learning that you have to do over time, too.
I feel like that helps explain a little bit why, for example, Square uses Marqeta with Cash App. They’ve gotten the economics to work out to where it makes sense to use Marqeta versus spending a ton of time building their own version.
Yeah, you look at all these infrastructure businesses -- internet and cloud with AWS, ecommerce with Shopify, and our space -- the infrastructure is critical to all of those businesses. You literally cannot run the business without the infrastructure. But the infrastructure is not the business, either. There's a reason why companies like SynapseFi were able to prove there's a huge market here. If you give somebody the choice of, “Do I build it all myself, versus do I have a set of APIs to build against?” -- pretty much all day, every day, I'm going the easier route. But the service had to be good enough that it actually solves the problems. I think you're seeing more and more situations across financial services where, if it does its job, and you don't have to build that whole thing yourself, that works. As long as you've got it compliant and as long as you've got a set of economics that allow everything to be healthy up and down that stack, that's where things are going to move towards. As you pointed out, that’s true even for a company as accomplished as Square.
You’ve mentioned this comparison between the cloud and banking and finance. Is the way that banking and brokerage work on the back end so disconnected and so siloed that it’s an even bigger mistake to build your own, versus in the cloud where maybe you can build everything except you outsource one aspect easily to AWS?
I think you're exactly right. It actually is more fraught with danger, because there are more pieces involved, there are more things to do, and there are more things that you can screw up. It's been an interesting evolution. Even over the course of the last 18 months as we were doing the pivot, I remember having a bunch of conversations before we were live with the platform -- where everybody was saying, “I'm not going to get burned again, I'm just going to go direct.” That always felt like the wrong way to think about things in this space. The infrastructure really is closer to an AWS. You need it, but it's not your business.
I think in the financial world, you will continue to see more opportunities for differentiation and specialization. It's a massive market that I think we're in the very early innings of. You're going to continue to see more new entrants come into the space. As long as you've got more and more people who want to build in this world on the client side of things, and you've got more and more financial institutions who want to have a role to play somewhere in there, you've got demand coming in from both sides. That's going to drive more and more stuff happening in this space.
This is definitely not a winner-takes-all space. This is going to be a space where I expect a bunch of big winners. But at the same time, not everybody's going to make it. It's going to be a rising tide that floats a bunch of boats, but not all the boats. If I had to predict, there are going to be some more spectacular crashes and burns in and around this space within the next five years, particularly around things like compliance.
Compliance is probably the hardest piece, especially if you really haven't been down in the trenches doing it yourself to understand just how badly that can go; where the weak spots are -- not just within what you're building, but across partners; how regulators really think about this kind of stuff; and how you give regulators comfort that there is visibility and transparency and control throughout these systems. Particularly when you start to think about how you do that seamlessly and correctly across a variety of different verticals that are regulated slightly differently by different regulators.
Disclaimers
This transcript is for information purposes only and does not constitute advice of any type or trade recommendation and should not form the basis of any investment decision. Sacra accepts no liability for the transcript or for any errors, omissions or inaccuracies in respect of it. The views of the experts expressed in the transcript are those of the experts and they are not endorsed by, nor do they represent the opinion of Sacra. Sacra reserves all copyright, intellectual property rights in the transcript. Any modification, copying, displaying, distributing, transmitting, publishing, licensing, creating derivative works from, or selling any transcript is strictly prohibited.
