Revolutionizing Open Banking with Unified APIs

Speaker A: Welcome to another episode of the Headless Banking podcast. Excited to be joined by Reuben, CEO of Quilt, doing some really cool stuff in the bank data aggregation space. So, Ruben, welcome to pod. Why don't you give a quick introduction before you dive in.

Speaker B: I'm, um, excited to chat. I am the CEO, founder and CEO of Quilt. We are a unified API for open banking. Essentially, we let folks access best in class done aggregation and enrichment platforms in one place through one integration, one contract. I got into this space originally. I've been in the financial data space pretty much my whole career. Uh, started at a company called S and P Capital iq. If I'm not mistaken, you and I worked in the same floor in different departments for a little bit.

Speaker A: Yeah. Many years ago, uh, we might have walked past each other in the hallway, probably.

Speaker B: So, yeah. This was in New York City right out of college. It's actually where I met my co founder. And so at Cap iq, I held a bunch of different roles. Started on the customer support desk, did some sales, then moved into sales management. And essentially. Right. So it was a financial data platform for investment bankers and hedge fund analysts and private equity analysts. I'd always been really interested in kind of personal finance. I'd use, like every budgeting app under the sun. Could never find something that really worked for me. And, uh, you know, at some point I decided that I was tired of making investment bankers better at their jobs with data. I wanted to make, like, normal people better with their money with data. And so that's kind of coincided with us leaving New York and moving to Texas. I'm based in Dallas today, and I got into the personal finance space, built, um, a budgeting app on top of Plaid at the time. And one of the things that quickly caught my attention was that it's pretty amazing that we can kind of like programmatically get access to our data, but that data needs a lot of work to become usable. So first of all, it was pretty messy then. I think it's still quite messy. Just a lot of it is the nature of where it comes from. There's so many layers of technology that touch a transaction from the moment you swipe a card or from somebody auto charges you until it's programmatically accessible to you. I got really interested in the data side of things, and that budgeting app kind of led us to start working on Quilt. We met a lot of folks that were struggling to make sense of aggregation data, and so we ended up building Quilt to help folks make it a lot more usable and a lot More easy to use right out of the box. I've been kind of, I taught myself to code before. That kind of gave me an interesting perspective because I kind of come from a business side but I also have a computer science background from high school as well. Today I kind of mostly run product for us in addition to some of the other things that I do as CEO. Um, we are, we've been growing really fast, well over 100 customers now. A lot of different use cases that we serve. And over the years we've kind of created a really interesting platform with a bunch of partnerships that give ah, us really broad coverage and really high success rates for folks connecting.

Speaker A: Just to recap, your story is interesting, I didn't realize but you've had multiple iterations of this thing over the last I guess five, six years. So you've been at this for a while, which is pretty interesting. I think you've got a strong founder journey. But basically to recap it though, you had created this budgeting app, this consumer app, right?

Speaker B: Yeah, yeah.

Speaker A: And along the way of doing that you realize that it's really hard to integrate the aggregators you're having to do. There's probably a bunch of data normalization across Plaid, Phoenicity, MX data, uh, the other ones. And while you were doing that people started asking you like hey, can you help me do my MX data integration or something. Right. And that's what led you to quilt and being like the end of end all, be all of I guess financial data aggregators.

Speaker B: Yeah. So we have built a consumer facing app. It's pretty hard to make money in personal finance. Right. You either have to monetize data or you have to charge. And to charge it really needs to be really good because it's very kind of competitive. We really hadn't raised any money then. It was basically just me and my co founder working on it. But one of the things we identified is the big problem to solve in the space is distribution. And so we found that uh, a bunch of the credit unions and community banks we're talking to really wanted to offer these types of engagement tools to customers. So we had a couple of pilots lined up that was actually go to market plan and then Covid hit. Uh, and during COVID I got a phone call from one of our points of contact and I'll never forget this, he said hey, so you know, I think the pilot's still on track, but we're taking a bit of a pause right now. Um, you know, remind me, do you guys do little Modification software and video chat support for bank branches. And I was like what? No, we don't do that at all. He was like, oh well that's the mandate right now. We have to shut down all the branches. But let me get back to you in a couple of weeks when this thing bowls over. Look man, I appreciate the optimism. I'm not an epidemiologist, but I just have a sense that this is not going to boil over in a couple of weeks. And as this conversation was happening I had kind of a couple of friends that were bugging me being like, hey, I'm building this kind of a Neo bank for this particular audience. And he kept bugging me being like hey, like I don't want to touch this stuff, like can you just license the tech for me? We realized somewhat presciently that the fintech and consumer fintech spaces is to be on the upswing because of COVID because so much of stuff is going to get digitized faster than it was already happening. That really is what led us to open up the API. Got some feedback from a few folks early on and we realized that this is actually a direction that makes more sense for us to go. You know Mark and I have sold into banks in our careers and so I think a lot of founders naive about how hard it is to sell into banks. Right? I mean this is just 12, 18 month sales cycles if you're lucky, right? You know people aren't buying the tech necessarily, they're buying trust, they're buying compliance, they're buying all this other stuff. So it's very different business than selling more to fintechs. And that's kind of how we started working on the current iteration of Quilt. Then that customer actually approached us one day and said hey, like we're selling our stuff to credit unions. You know the coverage you guys have, we were plot only at the time you applied. Like it's just not good for credit unions. Like we want to do Imax. Can you work with amex? And you know we got to introduce to the folks with mx we built a really strong relationship with them, um, integrated mx. And that's really what we became, this kind of unified API. We ended up rebuilding a lot of the product around this idea of a, um, many to one type of a uh, situation over time. We partnered with MasterCard. So now we have MPlat behaving in a very similar way in terms of one integration, one widget, one API. Normalize all the data. Ah, we serve the raw data as well. So there's full transparency, auditability. Yeah.

Speaker A: And do any of the banks still use this budget app or has it been deprecated? I'm just kidding.

Speaker B: Yeah, no, we ended up kind of killing, um, that off pretty quickly once we realized that that's just not really what we're really good at. And you know, it's hard enough to build one product, uh, and maintain that and maintain one, go to market. So, yeah, I've gotten better at this in general as a founder is just like killing stuff that I'm excited about because it's just not the right thing for the company. It's painful, but yeah, the budgeting app has been gone for a long time.

Speaker A: There's a saying. I think it's almost more important to decide what not to do, as is what you're going to do.

Speaker B: My team and I are having this discussion all the time right now around a lot of these gentic kind of coding tools.

Speaker A: Right.

Speaker B: Everybody's sort of talking about the death of software engineering, how uh, anybody can build anything now. Which isn't really true because, you know, we're seeing Amazon is having more outage than they ever had because they are letting the AI write all their code now and nobody knows how to debug it, nobody knows to review it. Yeah, I thought that was a, you know, somebody coined the term of slop debt. The outages that large companies are going to start having six to 12 months from now that are going to take a lot longer to resolve because not a human wrote this.

Speaker A: Nobody knows how the code works and there's as much code to review.

Speaker B: Yeah. But now going back to your point earlier, I think the knowing what not to build and knowing what not to ship, I think is going to increasingly become one of the main advantages that we humans, particularly, you know, experienced engineers. You know, just as an Uber used to take $10 to get from anywhere in Manhattan to anywhere in Manhattan and now it takes like 90, $99 if you're lucky. Right. I think we're gonna hit that at some point and hopefully people still remember how to write code.

Speaker A: So we kind of were chatting about AI. Like what is, how are you guys using AI? I'm assuming you're using cloud code to do stuff, but you're sounds like you're being a little bit Amazon.

Speaker B: Yeah, I think we're in the fintech space. Right. And the mentality of move fast and break things doesn't really work here. I think that's something we're really sensitive about. A lot of these models are non deterministic so if you're dealing with money and you're dealing with calculations, that's not something that I think a lot of folks are very comfortable with. I think we're still adapting, but mostly trying to figure out what are the things AI uh is good at for us and what it is not. One of the things that it's good at. We're finding, and this is a recent phenomenon, like last two, three months is a lot of these modern models are getting much better at reasoning through our code base, which means that we have an engineer that might not have touched a particular area of the platform before and it's assigned a particular bug or a ticket or wants to take initiative on something. They can actually now instead of trying to find time with our CTO or somebody who built that six, uh, months ago, they can spend five, ten minutes talking to the AI about this product, helping it kind of trace almost like describe how we operate with abstraction layers. Right. Abstraction layers are all over our product. So being able to understand how this thing works and how it was designed and what sort of the point of it is, it's gotten pretty good at that. Right. I think like it's still not foolproof, so folks usually will still go and check. Kind of like uh, compressing that context into something that another human being that didn't work on understands. I think the AI is getting really good at that. It's helping us a lot. I think small isolated bug fixes which are kind of tedious but are unlikely to break a lot of other stuff and very isolated in scope. We're increasingly using AI to kind of take the first stab at fixing that. There's still very intensive human reviews. You know, we're so active compliant. Right. So we actually have certain regulatory kind of compliance related requirements around. You know, like, like code has to be reviewed by a human. We have very specific sort of thresholds for like who needs to review what. And I think it's going to take a very long time for us to loosen that just because we want to. You know, if we have an outage, I want somebody that understands that code to be able to fix that. I'm not counting on cloud code to fix that. Which means folks need to really understand what's going into production.

Speaker A: Yeah, and that totally makes sense for your space where you're providing the backend financial data infrastructure to some sort of fintech. If you guys go down, then all of a sudden my bank account information is not right in this app. That's the core of the entire app. So I think another real quick. There was like an article from Chris, uh, Catalini. I think it was like two weeks ago, maybe. I thought it was really interesting because he was saying how, yeah, uh, A.I. can do all this stuff, right? It can do all these tasks now, but being able to audit the outputs and verify that they're great is a moat. You know, there's AI can output 100 times more code documents analysis than humans can, but most of it's slop. So how do you actually build the AI that for your software, for your tool, so that it's easy for the humans to understand and verify that it's accurate, especially in the financial world?

Speaker B: I think it's going to be big. A big part of our process with AI is we maintain sort of like pretty specific kind of documents that describe different systems and kind of have instructions, right? To say, if you're fixing a bug or if you're implementing this thing, make sure you find similar patterns and follow those patterns. Right. We do not want, like, you know, we have a really good engineering team. I don't need AI to improve on our architecture, our design. Like, we're not at the stage of that company where, you know, we're waiting for AI to make an engineering breakthrough for us. I think, though, it's actually more important to mitigate the opposite risk of that, which is that we have established certain abstractions and certain patterns and certain ways of doing things that are backed by a very robust test suite, which means that if we add new capabilities using frameworks we already have in place, uh, we in some cases automatically get the test coverage. In other cases, people expand the test. But we're not trying to create new patterns with AI when we use. Or one of our engineers uses AI to generate some kind of code change. Right? The thing that we look at in reviews is not just is it going to work, but, like, does it align with how we write code for similar things? I think that's really the difference between turning these AI tools into really meaningful extensions of your engineering team and making fewer people get a lot more output other than trying to replace your engineers. Right? I have zero interest in doing that. I like my engineers. I would actually like more engineers. And so this tooling should enable people to do their best work, not to create more work for humans to clean up later.

Speaker A: Well, we went down this inevitable AI tooling rabbit hole, but I'd like to bring it back to Quilt and what you guys are doing. So I know we talked a little bit last time about how you're focused on B2B connectivity, but I'd like to maybe for folks that are listening and don't know quilt, how do you guys, why use you and not use plaid? Like, what's the difference? Or how do you guys stack up in that arena?

Speaker B: I think there's a couple of ways of thinking about this. The most important purpose of um, account aggregation is allowing an end user to connect their bank account so that your application can access that data in a permission and secure manner and build tooling, build insights, build payment experiences off of that data. At the end of the day, having the user successfully connect is probably the top, um, goal, the top thing that this thing does. And one of the things that matters quite a bit is of course, the coverage, right? Who has the most coverage in the industry? And one of the things that you'll find if you look at it is none of the aggregators are particularly transparent about their coverage, some more so than others, of who they actually support. But even who they support, right, is a more complicated question than, um, do I support bank X? It's also, do I support Bank X for product Y? Right. So if you think about aggregation, the core two use cases that have really powered this space over the years has been transactions and balances. So being able to get snapshots of at least hopefully daily balances and transaction feeds. So that's what every budgeting app uses, that's what bookkeeping platforms use. And then the second part is going to be instant account verification for payments. So Venmo PayPal, you connect your bank account, they access your account so that you don't have to provide those, uh, they verify that basically it's you kind of like giving them those credentials and then they're able to then process payments using those accounts. Those are two of the main products. But there are actually a lot more products in open banking over the years that have expanded. So we have account ownership data. We recently launched a PDF statements product. We actually have several thousand institutions working at PDF statements out of the bank. The original raw PDF statements from, from the bank that they issued to their customers.

Speaker A: Let's pause on that. So wait, people want the PDF statements from the bank?

Speaker B: They really want the PDF statements.

Speaker A: What's that about?

Speaker B: I would say like two major use cases. So one is bookkeeping platforms and bookkeeping automation. As much as everybody wants to have the robots do your books, the robots aren't going to go to jail if the books are done incorrectly. And so most of these bookkeeping platforms, both legacy, so to speak, and Modern ones, at the end of the day need to reconcile the bank feeds they see with the actual data that is. And so every, uh, accountant we've ever had, no matter what technology they use, at some point they bug us, go like, hey, like, can you log into your account and give us the PDF statements? Or we're like, why is this happening? But this is. So that's kind of use case one. Right. So it's kind of like to audit and confirm that anything automated was done correctly. The second use case that's kind of an interesting one is somewhat related to this is we're actually working with, you know, we can share this like Carta on um, their fund accounting team. So the fund accounting team kind of has a similar process where they have to access kind of PDF statements for the funds that they work with and kind of reconcile inflows and outflows of investments that folks made, which was a super manual process for everybody for a long time. And so now they're kind of using our PDF statement integration to, to like mostly automate that work away. I, I think PDF statements for bank accounts is like a, a cousin of Excel where it's not really ever going to go away. Right. Like because it's an authoritative document that is provided by somebody that is kind of like in a certain final format.

Speaker A: I think that's true, especially since you can't always trust the data coming through the feed. So it makes sense that you'd want to reconcile that. And I think in the age of AI as well, you could just have an AI tool read the bank statement. Maybe that's even better if you don't need the frequency of the data. If monthly's okay, like maybe that's actually a better option. Yeah.

Speaker B: And I think for one area we haven't explored this too much, but if you think about investment management and a lot of these RIAs. Right. I think everybody kind of dreams of real time wealth tracking. But if you're dealing with, let's say high net worth pool for high net worth individuals, I don't think these people care what yesterday was like. Right. They want to know what it looks like over a month or over a quarter as they're kind of compounding stuff, I think that's an area where there's a huge opportunity to improve the technology in those spaces. It's a big thing to bite off. But I think that's an area where PDFs starting to come in more handy. But I realized I never kind of fully answered your question like earlier. Right. Like I think what I was getting at with the coverage question is there's a lot of coverage to be had. Nobody has anywhere close to full coverage. None of the aggregators are that close. We don't have open banking in the United States in a real sense. Right. We've had rumblings towards it. We've had the stop start regulation with the Consumer Financial Protection Bureau that's been electro joke. And so if you look at the very best companies in fintech across pretty much every category, they all eventually give up on using one aggregator and start layering in multiple ones.

Speaker A: Right.

Speaker B: Like Monarch Money on the PFM side is a good example of this Rex ramp. Sorry.

Speaker A: I love Monarch, it's a great app.

Speaker B: Uh, and at the end of the day I think most folks that spend enough time in aggregation find that you just really need multiple providers because also not all connections are created the same. You might have one bank that's on OAuth here and not on OAuth over there. You always want the OAuth connection for a variety of reasons. And we provide all of that to folks in one place.

Speaker A: So instead of having to go out and do your own integration, you just work with quilt 1 integration. How many backend providers do you guys have? And going back to the coverage question, what's your coverage then? Can you break it down across the providers? I'm just curious.

Speaker B: Yeah, so we have twice the number of unique institutions that any individual aggregator has. And a unique institution isn't just a specific bank or a credit union. It might also be like a sub brand of a bank or a credit union. And then we have, you know, at least 3x the number of ways to connect to something. So if one particular provider does not work, which happens quite frequently, particularly the smaller you get with the fi, a lot of these older screen script institutions you might have, every aggregator might have an integration to it, but none of them are doing that much volume on that. The integration may have atrophied. You know, nobody maybe has like actually checked it in a while. And so we can kind of waterfall down until we can get you the best connection depending on what providers you have enabled. In general. Yeah, we're seeing kind of 3x 2x the number of institutions, the 3x the number of paths to get there. And that's been, you know, a big, I think, a big driver of our success. And the other part I would add to this is the integration part is one thing and I think that particular part is probably going to get easier. I don't think you can vibe code your way into like a production grade integration with any of these aggregators. There's too much nuance, a lot of undocumented behavior, really, that doesn't make any sense until you actually experience it. But the barriers to that are going down. The part that is still hard and I think is going to continue to be hard and arguably could become even harder is actually licensing the data. We don't talk about this a lot in the age of AI. I think everybody thinks that the barriers to building anything is in the code and the technology. Uh, you remember probably back at S and P, right? I think there was a big existential debate inside that whole organization. Are we a tech company or are we a data company? The data is really what created enterprise value for S and P. Right. They had these unique data sets that nobody had. They were very good at licensing those data sets. And I think you're going to start to see the aggregators continue to defend that as they should. Which also means that buying data from them, I think, in some ways could become even harder. So most of the aggregators have pretty fat minimums, sometimes up to $10,000 a month just to work with them.

Speaker A: Oh, wow. Which ones? I'm just curious because, like, Plaid is not Plaid. Anybody can integrate the Plaid, right?

Speaker B: Yeah, I think Plaid has, you know, Plaid has done a really good job of. Of sort of. You know, when you think about this whole space just starting out, right, like, if you wanted to get yodle access, like you needed to like sign an NDA, like give up your firstborn, like jillion dollars before they'll give you sandbox access. And I think Plaid came and said, hey, like, the future belongs to developers. We're going to make this so every idiot like Ruben can quit his job and start building this. I think they did a really good job of kind of lowering those barriers. I think in many ways, at least what we've seen is they're, uh, kind of shifting a little bit m quite a bit more upmarket now. I think a lot of the pay as you go, kind of really small plans, I don't think that they're as excited about supporting that anymore from a lot of the folks that come to us that we hear. Whereas, you know, if you look at like MX or MasterCard, these are inherently much more enterprise type of organizations. Right. I think they're all improving their posture with developers, but at the end of the day, they make a lot of their money by working with large institutions and large banks and supporting a hacker who has $100 a month budget is just not really in the model for those companies today and I don't really see that changing anytime soon.

Speaker A: Yeah, that makes sense.

Speaker B: This is actually a good way to

Speaker A: pivot I think because to talk about like our use case for Treasury Path and why we partnered with Quilt is that also I think you mentioned is that these large aggregators are primarily focused on consumers and there's a very long tail of commercial banks that are just not served for this. And that's how we stumbled across you guys is we were like we have a client who has 10 bank accounts at ah, these small region, not even regional sub regional banks and we trying to connect that data. We were lucky to find Quilt because you guys could help us do it. And so I think there's that gap on the B2B connectivity side which no one's really covering.

Speaker B: I think it comes down to the history of account aggregation in the U.S. it started with kind of like Yodle, that was the first generation and uh, that was really focused on investment management, kind of wealth management type use cases, portfolio holistic views. They still kind of, I think that's probably their strength to this day. We started to see people build like budgeting app and like mint.com and then some of those first generation of budgeting apps that were starting to leverage that some of them were building their own feeds.

Speaker A: Yeah. When you think about fintech in general it's been very consumer focused. So really 2020 maybe things started moving towards businesses.

Speaker B: I feel, you know when kind of plaid first showed up, right. Like they had a couple of customers that really took off and I think in some ways took plot with them. Right. You think about Chime, you think about Venmo, you think about Robinhood, these are all hyper consumer and exclusively consumer type use cases. Over time I think you saw that become like the driver of growth for the whole industry. And so a lot of the integrations, a lot of feeds were really focused on consumer. And even to this day if you think about commercial models for pretty much all the aggregators, they're usually volume driven, right? So you pay X amount of X dollars or cents per month per connection or per user for aggregation. And in some cases it's based on the number of accounts, some cases based on number of connections per user. Right. But like at the end of the day it's all about the volume. And when you think about the B2B connectivity, what's the percentage of where is Brex or SVB in the list of top most used banks at Any of these aggregators it's going to be, I would bet, well, uh, outside the top 100 type, 200 of the banks. Right. But for the people that need those connections that are often B2B products, B2B use cases, the value of that connection working is much, much higher than somebody who, you know, is using a, uh, free budgeting app, can't connect that bank account and they start freaking out. And I think there's this interesting misalignment in the industry because the business model has always been around this like volume based pricing. The business connections I think have unintentionally gotten kind of the short end of the stick and they're not getting us prioritized. I think we're seeing some rumblings of folks at least acknowledging that and realizing that actually there's a lot of value in this. But ultimately the business models need to change a little bit. I mean, I would expect that, you know, if somebody could promise you significantly higher success rates for connecting your bank accounts, you're going to pay a lot more for that than somebody who's building a budgeting app who has a very, very tight margin to hit on a per user basis. Our B2B customers are often the ones that have, um, doing a lot less volume but they have much, much higher value like connections with us. And that's been the challenge for us as well.

Speaker A: And when you say B2B, you're selling it to apps like Treasury Path, other kind of business account aggregation tools primarily, or do you sell directly to a corporate even?

Speaker B: We have a couple of corporates that are using us, uh, in our CFO office trying uh, to create connectivity. And one of the things that's interesting is those folks are often doing the weirdest things and just to get the data working. Like we have one customer that every day they hit the uh, balance refresh, the real time balance refresh endpoint, which is really for payment use cases primarily. It's like validate the account, has enough money like you know, for them. They have a handful of accounts, they're not going to grow that much past that. They're not going to just suddenly open a million more bank accounts. And so they're actually able to use that product. Uh, and the way our contract is set up with them, it's totally advantageous for them to do that. But we were very surprised when we started seeing them hit that endpoint because they're not using payments capabilities. You start to see people kind of get a little creative because a lot of their accounts, right, like are at some smaller institutions to our point, where the cadency of data refreshes on a regular basis is, you know, once a day if they're lucky, but sometimes it's every two or three days. And so they just hit the balance refresh endpoint and actually get a fresh balance sooner. So you start to see these creative things that people will do to make things work.

Speaker A: Yeah, I mean, it is crazy. That's like a lot of what we hear from our clients too is I just, I have to log into five different bank accounts and check my balance

Speaker B: like two to three times a week

Speaker A: just to figure my balances. And you'd think that would be solved, uh, these days. But it's not like they're literally a commercial real estate company. They have 20 bank accounts because each one of their shopping malls has to have its own account and it's got accounts payable and accounts receivable. So they have to make sure they have money in the account every day. So they're employing maybe, I think, three to five employees that are just basically managing bank accounts and manually.

Speaker B: Yeah, I mean, we hear this quite often. I think it's a little crazy in a way, like to think that this is the year 2026 and this is happening. But I think, uh, you know, at the end of the day, right, like there's this misalignment between what people expect and what people want. And at the end of the day, like, a bank is ultimately a risk management company. Like, that's really all they're doing. It's all about mitigating risk. And I think the idea of seeing completely frictionless data flows back and forth. I think we're a little bit of a ways off. Right. I think the enterprises really need to see the value of this before they in turn start to open up their APIs. And, you know, the reality, I think a lot of folks might not realize is how much screen scraping still goes on. Right. I think a lot of folks expect that because if you bank with Chase or Bank of America or Wells Fargo or some of the big banks, right, you are not sharing your credentials with the aggregator or the app, uh, that you're using. There are secure kind of oauth flows for you. Just saying when you log into Google, you can log into bank of America and give access to your app. And while that is responsible for a lot of volume, it is a small percentage of the actual overall institutions. And when you go down to the B2B space or the business banking space, it's, I would say, Almost exclusively screen scraping based. All the problems of screen scraping that we've sold on the consumer side now apply to the business side. So hopefully we start to see some of these banks start to kind of open up APIs. But I'm skeptical.

Speaker A: Yeah, I got a couple more questions before we wrap this up. Uh, just kind of going down that thread and the scraping. Do you see that the cloud flare released a tool last night? I believe that basically allows anyone to build a screen scraper now, which is kind of counterintuitive to their entire business

Speaker B: model, but it's available. I think maybe the AI stuff is breaking their brains as well. So at the end of the day it's kind of exciting to see a lot of big companies launch things like this where if you need to scrape websites, most companies will build that in house or we'll hire some small companies to do that for you. I think if you have a need for that, going to like a cloudflare is probably pretty good because you, you're buying a certain level of trust. But uh, yeah, I doubt that you can scrape bank websites with that. And I think that's one of the things we're starting to see is I think as particularly in business account connectivity, I think if it doesn't start to improve fast enough through like the normal channels, so to speak, I think there's a real risk of people starting to deploy AI and kind of go it alone and try to do it themselves. Which was the whole point in some ways of this open banking framework is to prevent that because I think that might be really good for that individual company if they can pull it off. But overall it's bad for the ecosystem, it's bad for that bank, it's probably bad for the customer that's being scraped this way. Right. So it's hard to say what will happen, but I'm no longer making predictions about what the world will look like a week from now. But that is something I'm somewhat concerned by.

Speaker A: Yeah. And in our space particularly like the B2B connectivity is one thing just for US banks, but then you go outside of the US like we have the US Israeli companies and there's no open banking in Israel either. So like to get any data out of an Israeli bank is a nightmare. And so you could think of like how scrapers could even just start off on that kind of cross border bank solution. Right. The final question though is who is there any competitor, like who's on your landscape? Because I don't know anybody else who's doing this kind of financial data aggregator of aggregators.

Speaker B: Yeah. I think there have been a couple of companies over the last few years that have tried to do similar ish things. I think we seem to have outlasted them in some ways in part because I think this is not a business where you just pour a lot of capital at it and try to blitz scale your way to growth. I think in general that does not work well in infrastructure and certainly in fintech infrastructure. Right.

Speaker A: You know, uh, we fintech like it's hard in business. B2B fintech like throwing a bunch of money at. It's not gonna scale. Yeah.

Speaker B: I mean so much of this space, Right. Is around building trust and building relationships. And these are a little bit like old world, old school type of habits that I think a lot of newer companies maybe don't appreciate as much. Like one of the things we learned at S and P is that like, yeah, you can close a deal over the phone, but like it's way better for you to just show up in person and close the deal in person and go and have lunch with somebody and build a human relationship. I think for us, like we've really embraced that way of doing business and you know, I think that's helped us certainly on the supply side of what we do. Right. So if you're trying to create a platform like ours where you need, you know, you want to create kind of a superior set of coverage. Right. You have two paths. One is you go and you try to do what Plaid Felicity NMX did and try to do that faster yourself. Which means go and build thousands, tens of thousands of integrations yourself, which is extremely capital intensive and maybe uh, a little less so now, but it's still capital intensive and. But nobody's going to trust you in the beginning because who are you to do this? That's approach one, approach two, I think is to partner with these companies as much as you can. And so, you know, we have really strong partnerships with amex and mastercard in particular. And so we are able to effectively kind of accumulate that coverage by partnerships. And as part of that, I think those partnerships have taken time to build. Those partnerships are built on real human relationships are built on trust. And I think that's one of the things that makes it hard for somebody to come in and try to replicate. That certainly can be done. But I think you're starting. It's an uphill climb. It's a good.

Speaker A: Getting those partnerships is a lot of

Speaker B: work and it just takes time again just to build that trust. With all the stakeholders. I think the number one competitor we have really is people trying to hand roll the stuff in house and trying to assemble the individual providers directly. I think when it comes to the really early stage startups, I think it's often folks are choosing between just going straight to Plaid versus going through us. We don't resell Plaid, but we support it. If you have your own sort of relationship, that's generally the way we think about the world.

Speaker A: Awesome, man. This has been fantastic. I learned a ton. Appreciate the time. Thank you, Reuben.

Speaker B: Thanks, Chef. It's a pleasure.