Full Transcript for Why Stripe’s 1st Employee Bought a Bank | Darragh Buckley, Increase

Dara, welcome to the show. Cheers. Thank you very much for having me. Thanks for being here. So you were the first employee at Stripe and you just bought a bank. But what's going on? I did, yeah. The bank is now called Increase Bank. I run a company called Increase. Increase exposes US depository functionality by API. So having your machines talk to my machines to be able to orchestrate your finances.

And that's things like opening accounts, sending and receiving transfers, issuing cards, balance transaction reporting.

Our users and use cases are things like payroll, bill payment, loan servicing, neobanking. Some kind of no more public users are things like some of Gusto is built on top of us. Some of Gramp is built on top of us. We do their bill payment, for example. To give a sense of scale, we do about a little over half a trillion dollars in payment volume these days.

And those users choose to use us because

of reliability, transparency, and flexibility. They themselves are payments companies or folks familiar with payments who want all of the details and the capabilities, and Increase is designed to expose all of the data and capability of US depository functionality by API. So it's, I know, the joke is always like, Ramp does not need me in any way, shape, or form to explain ACH payments to them.

They got it. They just want all of the data and all of the capability in a way that's composable into their own product. So could you not do that five, 10 years ago? Well, I think if it's okay here, I'll speak to some kind of experience from Stripe. While I was building Stripe, we built on top of a cohort of US banks that grew out to global banks and integrating in with the card networks.

And the banking as it was exposed to us, you could always tell that we were always a little bit of an awkward duck, right? Like you're always wearing someone else's shoes, right? Like something always felt a little off,

be it the size or the scale. So like what felt off? Yeah. So... Stripe never did disbursements to merchants by wire, right? So Stripe would receive a chunk of change from the card network, from Visa, and need to push that out to Stripe users. A very natural way of, you know, moving those large,

those large amounts of money is by wire.

But Stripe was always hesitant to do that because when a wire would fail, we'd receive an email from the bank partner saying, we were unable to deliver this wire. Could you please go repair it? And it's just hard to build a product that you're proud of up on top of those kind of manual flows. And there are dozens of these examples. Oh, that data element.

Yeah, we don't pass it through to you. Why would you want it? So it was always... You knew you weren't in the right place. You knew you were building on top of someone else's product. There was a stone in your shoe, and you were trying to explain to someone why the stone in your shoe was super annoying. But they can't see the stone in your shoe.

So just like, why are you so worried about your shoe? Like, just keep walking. Very much a princess and the pea kind of problem, right? But you know you're not in the right place. You know that this is not built for you.

Main page at 3:29

No fault on it, right? Like it's built for someone else. Products are built for their users. You just don't happen to not be in the target users. And so increases the banking technology that I wanted while building Stripe, exposing all of the data and all of the capabilities by API. Of course, you want to be able to originate the ACH by API.

And of course, you want to be able to handle the return of it by API. And of course, you want to be able to handle the like,

secondary and tertiary processes in the case of ACH, this, you know, hold harmless requests, et cetera, by API. The dispute process that comes out at the end. Yeah, I get emails from my bank sometimes, like, someone just pulled an ACH. Like, do you approve the ACH pull that has already been pulled? Like,

maybe you could have told me before that. Yes, the train has left the station. Would you want it to have? You want it to come back. And no fault on that, but, like, all of those are... All of those should be exposed to companies that are looking to programmatically orchestrate their finances by API. The alternative is that you end up growing large manual operations teams or worse, just like not building that product, right? Did Stripe do that for a while? You'd like build around these weird capabilities? Oh, certainly.

Yeah. You end up And Nostripe ended up with a team at one stage with dozens of people on it for ACH return reconciliation. And the reason that that was necessary is because there was a particular data element in the ACH file, it's called a trace ID,

that didn't traverse correctly. And when you dug into the details, you could see why Wells Fargo was altering this data element. So what they were doing was not unreasonable. It wasn't like the engineers there built it badly.

but it wasn't built under anticipation that you'd want to

compose that within your own product. Yeah, and anytime you see a product that almost fits so close

and that we have such buildings built on top of it, one of us should surely go back and do a redo of the foundations. And that's what prompted increase. So there's been kind of the sort of, I don't know, infrastructure providers in the fintech space And it sounds like some of them would sort of solve some of these problems, right? Like, so were they not fully solving it by not owning a bank? Like, what was going on? Short answer, yes.

But let me give you a no. More interesting answer than the short one. Yeah, we need this to be an interesting podcast. We got like 80 minutes left to go. I just cannot just say yes.

This episode is brought to you by Monaco. Monaco is the first revenue engine built specifically for startups. Monaco's AI-needed platform replaces your legacy CRM and sales point solutions. It has everything startups need all in one place. Monaco helps build your TAM, generate demand, run outbound, capture every interaction, manage pipeline, and automate follow-ups all in one tool.

They pride themselves on an effortless onboarding, white glove activation, and get you to value in days, not months. And the product practically runs itself with built-in agents that are always working for you. Startups that switch to Monaco book three times more meetings. Start growing your revenue faster with Monaco. Try it now at monaco.com.

This episode is brought to you by Flex. It's the AI-native private bank for business owners. I use Flex personally and I love it because they use AI to underwrite the cash flow of your business, giving you a real credit line. The best part is 60 days afloat, double the industry standard. Flex has all the features you'd expect from a modern financial platform like unlimited cards, expense management, bill pay that syncs with your credit line, and their new consumer card, Flex Elite.

Flex Elite is a brand new, ramp-like experience for your personal life. A credit card with points, premium perks, concierge services, personal banking, cars and expense management for your family, net worth tracking across public and private assets, and a whole lot more fully integrated with your business spend. One card for your businesses, one card for your personal life, one card for everything.

To skip the waitlist, head to flex.one and use my code TURNER to get an additional 100,000 points worth $1,000 after spending your first $10,000 with FlexLeap. That's flex.one and code Turner for $1,000 on your first $10,000 to spend. Thank you, Flex. And now let's jump in.

Modern banking has like many comparisons to like 2010 payments, right? 2010 payments, so the like pre-stripe and ad yen and similar payments. Back in the day, you'd go get what's known as your merchant account and your merchant account is your like network level identifier. for you to be able to process transactions on the card networks. This is like the equivalent of if you had a card reader when you swipe your Visa or MasterCard.

Is that your equivalent of that? Your card reader would reference your merchant account. Exactly. Yeah. you'd get that from Wells Fargo merchant services or similar. Weren't there also like some local, really regional sellers of like these, these like, Oh, very much so. Um, there's a whole industry called independent sales organizations, ISOs, which, you know, are the, are the boots on the ground and the pavement pounders of the,

payment card industry. And it's fascinating. And, you know, where they grow up in different regions and jurisdictions and specialize in different things. So were they ultimately, do they evolve as like a go-to-market function of the card networks back like 50 years ago, whenever they started? Yeah. Yeah, indeed, indeed. Okay.

I very much appreciate this depth first approach to this question, by the way, just let me like tip to that. Well, it's like, it's like, I'm always like really fascinated just like how things came to exist the way that they did. Cause you're like, that's kind of messed up. Like, why do we have all these layers of like, you know, there shouldn't be an API to just be like, Hey, send a wire.

And it just does it versus, you know, why did that, why did that happen? Cause then, then you know how to fix it. If you understand how it works. Oh, certainly. But I will even like take a step back and go like, you know, why is it messed up is a fascinating trigger question for like, oh, I'm about to learn something instead, right? Like it's the, like, a solution has arrived at that I don't understand.

And the next question is like, great, I must not be seeing a constraint. Where are the constraints that I'm not seeing? And that's always a fun game to play, right? Like the, what am I currently blind to? Yeah. What am I not seeing? What am I like? The fun thing with the podcast is sometimes is like you have to kind of hit people with different angles of the same question to be like, what do most people get wrong? Or like, you know, what was the most surprising thing you learned about this? Like you kind of like poker.

I was like, all right, the third attempt. I got him. I got him to finally explain. Yeah, I got that. Yeah, different views reveal different things at times and fire different neurons. So basically, you get this merchant ID to get onto the card networks. Okay, but great, you now have this identifier. What are you going to do with it? You're building your software as a service company.

You needed a way to programmatically interact with that, right? You have your identifier. What are you going to do with it? So would this be RAMP and FREX and FLEX? Back in the day, we're talking about credit card acceptance. We had our merchant identifier, and then you had what was known as a gateway, right? Okay. And so these were the things like authorized.net.

And so back in 2010 payments, what you would do is you'd get your merchant identifier, bring it to authorized.net, and that would be how you'd be able to programmatically interact with the network. Okay. And among the insights from Stripe was like, these two things are not two separate things, right? Why are you talking to two companies here? This is one.

So you combine them. So Stripe combined them. That was kind of at least one of the initial insights of Stripe was

one of these things is not worthwhile without the other. So therefore, you should bundle these things. And that's what allowed, for example, you know, Sunday night signups on Stripe, right? That allowed for... You were just able to... Everything was within Stripe's control. It wasn't like Stripe told you to go off to talk to Wells Fargo Merchant Services and come back when you had your identifier.

Stripe would just take care of it all. And would you kind of almost be like a buffer layer between the

rougher, harder parts, and you'd kind of do that inside of the Stripe backend so it made it simple for people to do? At times, yeah. You've got to be careful with those abstractions becoming leaky. But yes, what you would attempt to do would be to kind of render the terms of the credit card networks into terms that were going to be more usable by...

by developers and engineers. Stripe creates these beautiful abstractions over all of these things. And this is actually in contrast to Increase, but we'll probably get to that in a bit. Okay, so 2010 payments, you're in this ecosystem of like gateways, merchant providers, Insight is verticalized that, yeah?

Current day banking ends up somewhat similar, right? You end up with these layers that are built on top of banks. And fundamentally, you've got like the bank, the Wells Fargo, running their own, what's known as bank core, their own maintenance of transactions and balances. That's what a bank core is. I've actually never known. I've seen the word.

There can be many, like there'll be dragons with respect to bank cores. But like, I think... You get a good first pass model if you just count it as maintenance of balances and transactions. Okay. So it's almost like a general ledger, like a live living ledger of the system, of the bank? Yes. Yeah. It's actually their client ledger, right? And so oftentimes you'll end up with a general ledger behind.

But... Boy, do I love my pedantic details. It's probably good. I'm happy to double-click on this any time. It's probably good that you know all the details.

Well, I think it's... I enjoy digging into these, right? So it's not like... these come to anyone at birth, right? If your interests take you this direction and you keep swimming, you end up with

Main page at 13:52

these fun hobbies. So current day banking, when you end up with a technology layer or an API layer that's talking to a bank's core,

looks very like 2010 payments. And my view is that's probably wrong, right? What we need is a bank with a technology muscle. We don't need to keep adding layers up on top of

bank technology. We need to redo from, we need to drop down there. Now, I'm always pretty skeptical when someone says, oh, we need to rebuild that technology, right? Because usually that's,

you know, a bit of an odyssey. But we've been building on top of banks technology for, you know,

successfully for 15 years, it's actually worthwhile that we just do a double click as to whether or not there's parts of it we should replace. So that prompted increase, right? Like increase verticalizes that. Increase replaces both the bank score and the API that you used to talk on top of it in much the same way that Stripe did this back in 2010.

And you have, you started in 2020, but you just bought the bank within the past year. So what was going on? Yeah. Um, my journey into banking started with kind of increasing in 2020 as building the technology and what the way in which we, we worked then, and we still do is

we have the technology with a series of bank partners. And so in particular, we built the core. but having that talk directly to the underlying networks. So talking directly to the Federal Reserve for Fed ACH, Fedwire, Check 21, FedNow, talking directly to Visa for our card issuing products. So we've had that for years and years and years and years.

And that was very necessary for me to build first

Increase built that first because that's the part that is very important for us as a company is growing to know and understand whether or not it's, you know, me and my friends who are interested in this or whether or not the appeal is broader, whether or not other people

felt the same problem and wanted it solved.

So yeah, technology has been up and running for years and years, but the bank purchase completed maybe about a year ago at this stage.

a small Washington State Chartered Bank called Twin City Bank. Fun fact, it's probably the closest bank to my house. I live in Central Oregon.

And we rebranded it about last month as Increase Bank. And so how do you buy a bank? What's the process of doing that? I actually saw there's an NBA player recently. I don't know, Harrison Barnes. I think he's retired, but he bought a bank. I came across that when I was looking this up. So I guess some people do buy banks. Bank investment is...

you know, uh, is actually relatively common. I recognize that bank investment, you know, to this age of, of controlling a bank might be less so, but, um, you know, fun fact about banks around the U S is there, there, you can publicly sell stock in them, right? You know, they're, they're, they're eligible for a Securities and Exchange Commission exemption that allows you to publicly sell stock.

So you could, in theory, just buy all the public stock of a publicly traded bank and then you would own the majority of the shares? Yes, in the same way that you could do so with any public company. But the fun parts are obviously when you run into various thresholds. And in particular, banking has restrictions on

who can control a bank. And there are control thresholds. The first is kind of a 10%. The second is a 25%.

And to progress past those thresholds, there are various regulatory approvals that are

required. But yeah, how to buy a bank is a fun part about... understanding different industry norms right how you might go about like buying a technology company or how you might go about buying you know the the local printer might be different than how you go about buying a bank in particular like banks can't tell you they're for sale right um Why not? Because you end up with a drain of the loan officers from the bank itself.

The folks producing loans within the bank would then be

known to be on the market and that would be problematic for the banks generate money is you make, I mean, generally like a spread on the interest in lending out the capital to people like generating loans. Very much so. It's an asset for the bank. If you're looking for a good first pass model of the bank, it's a lender, right? Like don't, Don't worry about

the deposit side from the first pass if you're looking for like... Super simple. Yeah. So you can imagine now if you're in this situation where you can't tell anyone that your bank is trying to be sold, what do you do? And so the industry has this humorously named conference called Acquire or Be Acquired. Right.

So like, let's allow ambiguity. Oh, you might be here to acquire, right? We're definitely here to acquire. We are not on the market. So it's like everyone shows up. It's kind of like one of those things, Like every VC says their top decile or whatever. Like every founder says, oh, I'm not raising right now. Like every bank that goes to this conference, oh, we're definitely trying to acquire other people.

We're not trying to get clients. So some of these are, and you can imagine entering a new culture, you're always going to like, which social faux pas am I going to make, right? Like how am I going to, Look at that, like the neophyte novice here accidentally. Did you have to wear a suit to this thing? Like it was the first time you'd ever worn a suit? I had actually worked in investment banking before.

So like... In theory, I had owned a suit. Yeah, but... So understanding these kind of norms around... Around...

Industry acquisition, like it takes a bit. Typically you end up working through investment bankers and the investment bankers are the ones who kind of, you know, knows who's looking at which direction. Originally back in 2023, I had pursued buying another Washington state chartered bank called Washington Business Bank. We had gotten pretty far in the regulatory approval process and the message back was like, listen, you're new to this industry.

You seem nice and all. Everything's together. We'd like to encourage you. You should sit in a bank board for a while

as a means of us getting to know each other. And so at that stage, I started sitting on bank boards. The kind of learning that you can get from being on like the governance layer and seeing what happens is fantastic. What all did you learn from that?

like you're learning things as, as, as, as broad and wide as

Main page at 21:23

like, this is what you need to be looking with within your like lending portfolio within your lending pipeline. And this is how long these deals are going to take. This is what we're specializing in. And explicitly we are not specializing in these other things and we'll walk away from all of these. So like we lend to farmers or we do not lend to farmers.

You will have a specialization. Yeah. Yeah. And it's dangerous to wander too far outside your specialization. Why is that? Don't you want to grow, diversify? It sounds riskier, technically, to be really focused. Oh, concentration can be a thing and you need to watch out for that. I suppose what I'm saying is don't accidentally wander as opposed to don't wander.

Choose your directions carefully and see where you have a differential advantage based on what you're currently good at, et cetera. And so purposefully wander, but don't just chase the next fad. You will, yeah. Does that happen too often, you think?

Yes, would be the short answer. We ended up with a bunch of banks in like the 2010 timeframe, for example, chasing

financial technology partnerships. And so a lot of community banks around the nation saw it as a growth mechanism and didn't have the appropriate

capability or capacity to be able to do so safely and soundly. And so we ended up with a regulatory pushback against that. And I think quite a lot of that regulatory pushback was appropriate.

I think there was skepticism that many of, especially the smaller community banks, knew what they were getting into.

And it was also one of the reasons we kind of, it took us so long to build out

increased bank, right? The acquisition closed north of a year ago, and it takes quite a while to put in place the

correct capability and capacity. You can't just slap an API on it kind of thing and, like, we're good to go. Like, what's so hard about it? This episode is brought to you by Clerk. When I had Clerk co-founder Colin Sidoti on the show, we talked about why authentication keeps changing. For a software company, that work goes beyond just getting someone signed in.

Business customers need their own organizations with their own users and access requirements. Clerk handles authentication and user management with pre-built components that developers can customize to match your product. With multi-tenancy built-in, you can manage organizations and set roles and permissions for each customer. And Enterprise Single Sign-On lets customers use their existing company login so your team can spend more time building the product your customers actually came for.

Start building for free at clerk.com. That's C-L-E-R-K dot com.

This episode is brought to you by Numeral. Numeral is the fastest, easiest way to stay compliant with US sales tax and global VAT. It's easy to set up and they automatically handle all registrations, ongoing filings, and their API provides sales tax rates wherever you need them with all the integrations you need. Their solution combines AI-driven automation with human expertise to manage global sales tax compliance end-to-end.

Numeral supports over 3,000 customers, including companies like Brex and Character AI, and they pride themselves on white-glove, high-touch customer service. Plus, they guarantee their work, and they'll cover the difference if they mess anything up. If you want to get compliant, check out Numeral at their new domain, numeral.com. That's N-U-M-E-R-A-L dot com for the end-to-end platform for sales tax and VAT compliance.

is the question whether or not practically you can or whether or not safely you can, because practically you can certainly strap a jet engine to a go-kart. You will promptly find a wall. So what's the first wall that you'd run into? If you strapped a jet engine to a go-kart or if you exposed a bank by API. Maybe they're the same thing.

So I'm assuming you like build this API and you were probably like within pretty quickly like, all right, we're good.

Was there anything you had to like, oh, shoot, we had to adjust for this thing? Yeah. I think this is where you get into

the money movement side is very, very important, right? Like it's important to get all of the details and the reliability and the transparency correct there. But how that interacts with compliance regimes is interesting. fantastically important. And it's very useful if that's not a post hoc tag on, right? Like it's very useful if you're able to embed the compliance regimes as code early on.

And that requires engineers being comfortable, you know, reading the source docs for the compliance regimes. It

also requires compliance professionals and experienced practitioners

being comfortable jumping into the engineering details.

Main page at 26:26

If, for example, you are, there's a compliance regime that has to do with the data elements that need to traverse when you're sending a wire, and they apply at a threshold, dollar amount threshold of $3,000, and it's called a travel rule. And it's very useful if you build that in from the start into your wire processing system, as opposed to

when you're going through your first audit, realizing that you need it and then tagging it on. So it's almost like you need to make sure

when someone goes to enter in that wire, there's just almost like an extra box. It's like, oh, by the way, we just need you to fill this in also. And then anything else is going to get triggered. It's like just part of the product in a way. Indeed. If you're able to build it into the product, early, you can make life nice for yourself. There's this time during an examination, and you may have had this experience yourself with respect to kind of any audits or tests.

You get your list of data requirements. Can you pull these data elements? We're going to sample from them, et cetera.

but can you pull them all for the time being so that we're going to tell? And even though you know that you've been doing everything correctly, even though you know that your processes are correct, you've good organizational hygiene with respect to these things,

when you see the data correct, there's this sigh of relief.

Great, all worked. And I think you should try to make that sigh of relief like asymptote to zero. I think that sigh of relief should be like as small as possible. And the way in which you can get there is by like running the examination on yourself more frequently, right? In much the same way when we were building like engineering products, we build like a test battery around it, right? And so there's never any question when you're rolling out the next version of the API, whether or not you're correctly, you know, capturing that parameter because you know that it wouldn't have deployed but for, you know, that test having passed.

And if you can do the same with respect to compliance regimes, you can help yourself a lot.

And the way you get good at doing hard things is by doing them more often, right? Yeah. you know, this was kind of a lesson from engineering of like, how do you get good at doing the hard thing of, you know, rolling out a new version is you do it dozens of times a day, right? Like, what if you do don't like have any manual step in there? And if you're able to apply, I don't know, the same concept to compliance regimes, how do you get good at doing examinations? You do it on yourself multiple times a day, right? Like you run all of that same logic yourself multiple times a day.

Yeah. That seemed kind of like way too obvious that that was not a normal kind of thing. Because it just seems like, oh, looks like one of our processes that we've built doesn't really match what we should be doing. We should probably change it.

Like any solution, when you look at it from the correct angle, you're like, ah, that's it. And you're like, cool, cool. Yeah. And, you know, that is the benefit of having, being able to look at things from multiple angles. Yeah. So one thing that you mentioned was you talk directly to the Fed, to the Federal Reserve. You work with them. I don't even know how that works.

I thought that was... Doesn't every bank kind of do that? What's the importance of that? Yeah, in ways. So Stripe built on top of Wells Fargo. And the way that Stripe would interact with Wells Fargo is Stripe would... Send Wells Fargo the messages that Wells Fargo was to send to the Federal Reserve, right? And if it gets passed through in high fidelity, all's good, right? If some things change in between, it's very useful to know what changed.

Then you can adjust it as your stripe to measure. Correct, yeah. Or it helps you understand how things are going to fail, right? So, you know, Stripe was not talking directly to the Federal Reserve there. And that meant it was difficult for Stripe to expose that to others, right? Like if Stripe really wanted to expose...

some data from wires, if Stripe did not receive that from Wells Fargo, it fundamentally couldn't expose. It wasn't Stripe's gift to give unless it had been given that gift, right?

Someone else's abstraction places a limit on what you can do.

And that can be frustrating from product, right?

So Increase's role there was to step down and talk to the Federal Reserve directly.

The Federal Reserve is also a fantastically reliable and good service provider. I think this was one of the

unknowns for me when starting Increase was, like, how good is the fundamental layer, right? Yeah. You think, man, that thing was started in, like, two centuries ago. Well, Federal Reserve is later than that. Federal Reserve is, like, 100 years, right? What year was it? 1907?

And the actual group, the Federal Reserve, is many things. And I don't just mean in its regional banks level. I also mean in its... It's got this division called Federal Reserve Services, which is its technology layer. And so, you know, central bank, bank regulator, and technology provider are not fundamentally like components that need to be placed together, but

we have chosen to do so as a nation, calling them the Federal Reserve.

So it's Federal Reserve Services is the technology layer that we end up chatting with a bunch. And they have good technology. And they've got fantastic technology. And also they're very good operators. Like I know the fun fact here is about a year and a half ago, the Federal Reserve ran an update to its messaging specification to do with wires.

Main page at 32:28

Fedwire system bumped over to an international standard called ISO

20022. No one knows about this outside of, you know, a kind of niched group of interested people, right? But it required coordination across the financial institutions of the nation. So it's basically like at one moment in time, everything needs to be adopted for the new methodology. Yep. Okay. You've seen enough technology companies, right? And so if anyone described a technology transition like that to you, you likely would do the same thing I do, which is like, head in hands, like, oh, please don't try to do that.

That will go horribly. Yeah, I mean, it's like Y2K. You're like, the world is going to end on midnight when the calendar rolls over.

And with, you know, the Federal Reserve was under constraints, and this is the one that made most sense that it was going to be a hard cutover, but successfully operated that hard cutover through just good planning, good

good testing, good operations for months and months prior. And

success here is defined as you didn't know about this thing, right? Like you didn't read about it on the front page of the paper

that wires across the nation stopped. So the fundamental underlying of the U.S. deposit area networks is in fact great, right? Like we have like real-time payments there. we're missing the last mile delivery of that, right? Like, we're missing the productization part of, or the ability to productize that. So what was, like, missing in that last mile? Yeah, high-fidelity pass-through of the data and the capability, right? So it would, like, there'd be someone who's sitting with all the technology and they have access to it all, but they don't, like, expose it correctly? Exactly.

On the button. Why didn't they just expose it correctly? Oh, exposing it correctly isn't, like, trivial, right? Like, so...

This is the case where I'll differentiate between product at Stripe and product at Increase. Product at Stripe is creating these beautiful abstractions. You're a developer, you care about payments. You do not care about ACH. You do not care about bedwire. You want this abstraction. Product at increase is... Oh, this is the FedACH API. You want to know what that parameter is called? It's called the exact same value as the network calls it.

We do not try to be creative and to create an abstraction there because you want... high fidelity pass through of that data and information.

And that's what I wanted while building Stripe. So you're almost like building, the increased product is like built for the Stripes of the world and Stripe is built for developers. Very much so. Our users and use cases are like, are those technology companies building financial products for others? So I'm curious then, like, how did this go when, like, Stripe's a customer, wouldn't maybe have like an inside track with Stripe where it's like, but with some customers, they may have already been using a product and you're like, or they built it all internally.

Main page at 35:48

And then you go to them and say, hey, you have this whole team, like switch increase. Like, how does that go getting people, like convincing a lot of these companies to switch over? Yeah. Yeah. Oftentimes there's a moment in a sales conversation. It's usually someone from product or engineering is the person interested in picking up increase.

And often there's a moment in that conversation where they're like, sure, I get that you have these APIs, but do you pass through the input message accountability data? And when do I get that? And you're like, yep, you get that here and in this way. And after three or four of these skeptical questions, there's this sigh of relief and dropping of shoulders, which is just like, Oh, I'm with my people.

I found my place. Great. I'm glad that one of us went ahead and did this, right? Like, I'm glad that one of us went ahead and did the...

Dropped down to the base level and just surfaced it all with no abstractions.

When we're in the... Those are actually pretty fun conversations, right? Like, oftentimes there's a...

high degree of shared experience. Yeah, actually, the founder I was mentioning earlier that

uses Increase that I know, he was telling me, I was like, oh, Increase, I don't know if I've heard of them before. Why'd you go with those guys? Like, because there's like other, there's other solutions on the market. And he was like, I don't know, they just like, I felt like they were engineers and everyone else I talked to was like a salesperson and like the Increase

I have no idea. I guess he talked to you, which is what you mentioned, but it just felt like he understood the problem and understood the technology behind it. So that's why I went with them. I was like, oh, interesting.

Increase is about half engineers, and it's very, very important to have not just engineering with an increase, but I think everyone takes the same approach. And that's what we strive for is friendly competence, right?

that we are willing and capable to talk about the details with everyone. Great. You want to talk about the, I know, ISO 8583 standard for the card network. And like, and you care about this parameter that's in there. Yep. I know why you care about that. That's similar to the life that I've lived of wanting to build that into my own product.

Like you probably want it in this way. Like, great. Yes.

The intention of increase is that you're composing it into your own product. And I had recently, I think it will have come up before this episode goes live, but I guess like a peak preview in the future. If not, I had Ron Gabrisco, who's the CRO of Databricks. Okay. Their sales team joined before they had a million in revenue. And I think they just announced they're doing 7 billion in run rate or something.

Maybe it's bigger than that. I can't even remember the number. But he built the sales team there. And I think their thing is they just like, their sales team is like very technical. Like they're not traditional quote unquote sales people. They're people who like understand the problems that you're facing. They understand the technology behind it and then how do they solve the problems that you have.

And I know that's always been my favorite way to think about sales because I like, you know, you grow up thinking like, oh, sales guy, like snake oil salesman, whatever. Yeah. you know, shoving something that they don't need in front of them. But it's really like, somebody has a problem, and if you can solve it, they'll pay you money for it.

So, how can I solve your problems? And then, that's really how you should be doing it at the end of the day. And there are different modes of sales. Sales folks.

I very much enjoy the, like, the salesperson who can be in a challenger sales model. So what's a challenger sales model? My understanding, like, here is where I'm... It's important to understand that this is...

Not my own skill set, but it's listening, exploring, sitting with the problem, but then being comfortable saying, I think you're doing it wrong, right? Like, I think that you should be doing this instead. I hear what you're saying. I'm trying to understand the constraints that I'm like, you know, are not obvious from the start, but I've asked enough questions around it.

And like, no, you should do it this way. You should hold the product this way instead.

And it can be very trust building, right? Like it requires a lot of like empathy on behalf of the salesperson. It requires a lot of technical competence on behalf of the salesperson, a lot of understanding.

But then having a trusted third party who's familiar with the bank side being able to say like, no, you should probably do it this way is valuable, right? Like you're not trying to be infinitely flexible. it's okay that there's a correct way to do things. So what does a good kind of increased customer look like or like the average customer? Because, you know, guy we were just talking about, he's just like starting his company.

I mean, he's like super small. You also have

I mean, I could say Stripe is basically almost the scale of a public company. So what does a customer look like of increase? Yeah, ours very much tends towards the larger use cases as opposed to the earlier use cases. I certainly do hold many of the early use cases near and dear to my heart and want to continue supporting those. But it's more for the at-scale users.

use cases like payroll, bill payment, when you are moving kind of billions of dollars. And it is very important to you that you're able to do it with a high degree of reliability, with a high degree of transparency. That's where we do best.

So you got to like, a lot of the customers you get, they're probably already doing some of this stuff or using something else. You got to like get them to switch over. Either switch over or if they're launching a new feature that's adjacent to

to something they already have. I don't know if I was to give a recent example. Yeah, built pay

is a great example. I think we actually have a case study up about this, ramp uses us to like pull in money from the from the payer and push out money to the the payee and you know we are their means of interacting with the federal reserve for that so um in particular you originate ach debits so the u.s mechanism for pulling money from someone's accounts and then uh how you do the funding to the the payee be it by ach credit or fedwire or even uh even checks, more modern mechanisms or things like real-time payments or FedNow

or push to card and being able to combine all of those nicely within one API.

That can be valuable. One thing I think is super interesting about Increase, you mentioned you're doing over half a trillion in volume and you have, according to LinkedIn, there's 33 employees. I have no idea how accurate LinkedIn is, but that's like a pretty high, you know, employee to volume moved ratio. Yeah, I think the point to emphasize beforehand is I would not do so with that amount of people unless it was safe to do so with that amount of people.

But the preamble aside, I'd go to, it's fascinating how much you can scale when you're just like building on top of the Federal Reserve when you don't have those abstractions. Like a lot of the other operational team stuff in the general financial services space is adjusting for the abstractions. Yes. Figuring out how to get around them. Or figuring out what happens when things leak through.

An example from Stripe. ACH reconciliation or ACH turn allocation. You send a transfer. The transfer is not able to arrive to the person's account. It gets bumped back to you from the receiving bank. And now you need to know which transfer got bumped back to you. Sounds like a trivial problem, right? Sounds like, but of course, how could money just arrive back to you without you knowing why? It would, of course, be labeled.

Correct. Yeah, right. Of course. Yeah. But it's not labeled. The identifier, the primary identifier, the one that you're meant to use is called a trace ID. And the trace ID is a numeric string of 15 characters.

You don't get all of those 15 characters because some of that embeds the routing number. So you've got less entropy than you might expect.

And so, you know, you'll end up repeating these at like pretty high frequency, right? Like they're not actually a unique identifier for you.

And so you'll end up also building heuristics. Okay. It was this transfer with this ID and to this account and routing number. Great. That allows me uniquely identify. And so you'll build your heuristic mapping of this. It's just fine.

Stripe didn't have that trace ID because of some systems issues with

with how Stripe interacted with Wells Fargo. No fundamental fault on either group or anything, but it meant we ended up using the heuristics very early on And of course, then there's things that manually fall out of that heuristic queue. And so you build a team that is responsible for those allocations. You're kind of like automating and making software to make up for the lack of capabilities in the original software.

Indeed, yeah. And that's a reasonable thing to do to a point. And at that point, the correct thing to do is go back and fix the fundamental problem.

Yeah, and hence increase. So then how do you think about hiring and adding to the team? There's not very many people. Like, how have you been doing that? Yeah, it's... I enjoy working in high empowerment cultures. And I enjoy working with people who enjoy working in high empowerment cultures. And for me, high empowerment means the kind of ability to wander the world and affect the change that you need to build a product.

There are prerequisites for that. You got to hire well. And you also have to trust the people who you hire and trust that they trust you to

go off and affect that change. It does mean that it's very useful not to silo too strictly, right?

You have to allow a compliance person to wander into engineering and an engineering person to wander into compliance. And I suppose more than just allow, but like, you know, promote and expect them to do so too.

Stripe was very good at this for very many years. Stripe maintained it to a higher headcount than Facebook maintained it to. Facebook maintained it to a higher headcount than Google maintained it to. Google maintained it to a higher headcount than Microsoft maintained it to.

So I would aspire and hope that increase will maintain it to an even larger headcount. But I think it's what builds good product. It's what builds effective organizations. One thing we talk about now, going back to Stripe. So you met the Collisons back in Ireland. Yeah, we grew up in the same hometown. This is like Limerick? In Limerick, yes.

Is that a big city? Limerick's not all that big.

At the time, it was maybe 35,000 people, depending on where you draw the city lines. So it's like not a big city. It's for the US. Correct. Yeah, yeah, yeah. But it has a very forward-looking university, which I think was very influential on kind of all of us. And it has a whole bunch of like multinational companies.

And that creates a different kind of, I don't know, window of what's possible.

Yeah, so we grew up in the same hometown, spent more time together while at college and university in the U.S.

And then I ended up joining up with them in about 2010 as Stripe's first employee. You were kind of the banking guy? You did, yeah. Prior, I worked for Lehman Brothers prior.

Oh, shit. You had firsthand experience with the banking system. Well, I expected that this is where I will show the, you know, the kind of how early Stripe was in its journey with respect to what is a bank, right? Like counting, you know, oh, you worked for an investment bank. Surely that is a bank. And, you know, kind of, oh, sweet summer child, no.

Yeah. It reminds me of the story, like, I had Will Gabrick on the podcast, and he told me a story about how, I think, one day Patrick texted him. It was like,

I forget exactly the conversation, but it was like, you know, you know finance. Like, why don't you be our CFO or something? Like,

here's this broad regime. Like, John and Patrick, they have many superpowers. One in particular is learning, right? And kind of their own ability to learn, who they learn from, how they learn. Yeah. It's fantastic. And so you're like, oh, this sounds like a good idea. I'll go be the banking guy of this Stripe company and be the Irish superheroes coming over to fix payments in the US.

Wouldn't go that far. But yes, I joined up and it was quickly evident that what was necessary was like,

It was less banking and more kind of engineering related to banking. And so that was kind of the first thing that I jumped into. I think, I know, some fun

Main page at 49:56

vignettes here might be you have likely had this experience, right? Like where you're at a group project and there'd be like, you know, four people on the group project and you're all going to be working on this thing together and you're going to kind of get to know each other. And so I arrived into Stripe and like the early group project is like, well, it's John Collison, it's Patrick Collison, that's Greg Brockman.

Like this is a very high powered group to be able to learn and build with.

Yeah, and I'm very grateful for that experience. So you were like the fourth, the other guy. The other guy on the team. Yeah, the guy. So what did you learn working with the early Stripe team? Yeah. I think one of the most impactful and kind of meaningful for me was the amount that a small empowered team can get done. If you'll forgive a story.

There was one night where... I suppose it was an afternoon, we jump on the call with a partner and this was how Stripe was finally going to be able to talk to the credit card network more directly, right?

And on the call, the person in charge of certification was like, okay, great. The next certification date is six weeks. You've got a lot of things to do before six weeks, but you know, six weeks, you should be able to get it done. And you can imagine in startup world, six weeks, when someone who says this to you, you're like, wait, what? Like you might as well have just said 10 years from now, right? Like this is not, this is beyond our like time horizon to contemplate.

So someone pipes up in the call of like, oh, we've, you know, is there any time sooner? Like, oh, there is tomorrow at 10 a.m. But like, you're not going to be ready for that. I just assumed. There's no way. And so, you know, there's a meaningful look around the table of like, oh, no, sign us up for that. Great. We'll chat to you then. Sure.

Okay. How am I going to like... I'm just assuming you're coming back in six weeks. Well, yeah, yeah. But sure, I'll humor you.

Hang up the phone, kind of look around. It's like, okay, we've got 18 hours to get this, like, you know, 150 test cases done.

I guess I know what I'm doing. One of us is starting at the top. One of us is starting at the bottom. Go for it. And you just work through the night. What do you do after test case 36? You do test case 37.

and just keep going throughout the night with this group. And it's a fantastic, I know, shared stress, strife, and struggle is great for, you know, building camaraderie. And that's always fun. Maybe at about eight in the morning, In order to talk to the certification service, we needed to do a, back in the day, plain old telephone connection, right? So I had to run down to Fry's electronic store in South Bay.

As it's opening, knock, knock, knock, please, I need this part for this thing. Great, I'm now jumping back to Palo Alto. Yeah.

getting the call at 10, by maybe 11.30. Okay.

Everything's passed. Never in my years have I seen anyone go through this certification this quickly, but you're good to go. You can run your first live transactions. So just turning on the first live revenue for the company. Yeah.

Yes. The sigh of relief of a group that has like achieved something that required just like a sprint of effort and endurance and is great, right? Like that, that experience of, of

overcoming adversity is great, right? That's kind of what drives much of the enjoyment of startups. It's almost like no one's ever done this before, but we just did it. And we didn't even know this was a thing. We didn't even know this was a hard problem. We just were like, all right, we'll just get it done. Yeah, ignorance can be helpful, right? In certain circumstances.

But it's more to do with the group, right? Doing these things alone is fun and whatnot, but it's more when you're sharing this experience with

with a group that's kind of dedicated to empowering each other, to dedicate to helping each other learn and grow. Yeah, I value that. And so carrying that forward and to increase was very important for me. Is there anything about Stripe maybe that someone from the outside wouldn't have seen or wouldn't have understood about the reason that Stripe was so successful and the reason that it worked? Like, I don't know, myths about the company that are...

incorrect or or they should be myths and no one actually knows about yet um i think this changes over time right like and um it's okay that um a company's story changes over time i think probably in a

you know what's what's now common of a group of smart nice hard-working people who are relatively disciplined around thought and how to give support to each other in the correct ways.

Those are useful. Back in the day, differential characteristics were probably things like long-form written, like culture of communication, like writing it down. That wasn't as common. I don't think it was as common in 2010 as it currently is. I don't think I would call it a differential characteristic these days. I mean, now you can just throw some prompt in Claude and get some AI slop and share it in the chat.

Yes, and you would get all of the value for doing that and none of what actually matters. Yeah, yeah, exactly, yeah. Yeah. if you're using it as the thought partner to grow and develop yourself, yes. But like, you know, the reason you had long form written was because it was like helping you learn, right? Like it was forcing you to put your ideas down in like a legible way for falsifiable statements and you were going to have to expose all of your logic to someone else and someone else was going to be able to point out the parts that were more or less shaky.

And it's not like you're on thesis defense territory, right? Like you're not being like attacked for this thing. This is a group project of us all trying to come to the correct answer. Yeah. But, you know, that's a lot easier when there's a, like, artifact to look at, right? Like, yeah. Well, yeah, sure. And then it's like a culture of everyone looking at the artifact together and using the artifact to get to a point of learning or truth at the end.

Yeah. And you're all there in support of the person who's going to have to, like, own the decision

and you're going to get behind this decision this person makes. So it's like working together to get to the right decision. Yeah. Very much so, yeah. But I don't

like the particulars of all of this matter, right? Like, I feel like there's nothing objectionable about that statement that we've made, and it's probably not all that interesting until you get to the details. Yeah.

Main page at 57:11

Anything specifically that you learned from Patrick and John? Yeah, I... There's this fun story. Forgive me for storytelling again. That's more interesting to people, I think. So... As is the tradition of all startups who first get their office, right? You arrive into the office and the place is empty. Like, great, what are we going to do? Ikea trip.

Jump in the car to Ikea, get, you know, six of the cheapest desks and cheapest chairs that you can get. Put them back in the car, drive back to the office.

You're unloading the car, right? Pick up a box.

put it down, you walk back to the car. That's not what John and Patrick do. They pick up the box, walk into the office, put it down, sprint. And you're like, you know, me as observer, like, do we park illegally? Did, like, did I miss something? Right? Like, why are you running?

they just always have this sense of urgency, right? There's just always a, oh, we can just do it faster. Why would we not just do it faster? Just run. We'll run. And if you're in an environment where someone else is running, are you going to be the one person who's not running? Like, of course not.

You're going to run too. And not in an obnoxious way. Not in a like, I'll grace you and if, you know,

and if you're slower than me, I'll rub it in your face, right? Like it very much is in a like, no, this is, you know, just all of us here together. You just got to get there faster. Yeah. You can save, probably create an extra, if you're doing a lot of traveling and movement, the faster you move, the more time you save. Yes. But I think that, that cultural prevalence of the importance of urgency is

John and Patrick are fantastic at creating. And

it's not an obnoxious, like, why haven't you done it yet? It's just like, oh, why wouldn't we just do it now?

Giving it a very friendly, pleasant, but boy, you're going to want to keep moving way.

Yeah, and... They're very, very good at doing this nicely. Yeah, I think Patrick has a blog post about, I think it's just called Fast or something. It's like his name.com slash fast or something. And it's just like a list of like, it's like literally just like bullet points. Yeah, how the Empire State Building got built really quickly. Yeah.

Yeah, that at times... Like our expectations around speed are just missed set. And we can, in fact, when you have the right group of people with the right resources and the right things out of their way,

you can do things at unreasonably fast speeds. One thing going back to the podcast I had with Will when he came on, he said an early thing that you guys learned at Stripe was it was like a really high up executive slash CEO or something in financial services. He didn't actually tell me who it was. I can't. Maybe he did. I can't remember. But something that they told you was, you know, you guys look all gung ho, like we're building a payments company.

And he's like, oh, you're not building a payments company. You're actually in the fraud business or something to that effect. Yeah.

And I feel like Will actually told me, but I forget. And I'm interested in hearing it again. So why is it ultimately you're not actually in the payments business, like the money movement business? You're actually in the fraud business. How does that work? Yeah, I think,

as you can imagine, cards in particular, but payments generally, are

magnets for bad actors and in particular fraud.

You know, there's a lot of money to be extracted.

I get emails every day with like a fake invoice from some random company, right? And I'm like, I guess some people get caught by this. Yeah, and in very unfortunate ways, right? And there's many things that we can do as an industry to

reduce that. Why has it been so hard to solve the fraud problem? if you're able to tell me how to properly solve the identity problem, I'll be able to tell you how to solve the fraud problem.

And I'm not meaning to unfairly throw it back at you. I'm just saying that like,

we haven't correctly solved like online identity. We

have various versions of it to like, reasonable levels of of confidence but like you know that's the a fundamental problem of of fraud payments is um is identity because you're like pretending to be someone else really at the end of the day at times now there are other versions uh which i know i wouldn't actually like chuck in the

or you may or may not count as fraud, like first party fraud, you received a good and you pretended like you hadn't received the good, right? Like that's not solved by identity, but from a, you know, something that rounds to correct definition,

Main page at 1:02:46

saying, if you solve identity for me, you will vastly, you will solve fraud for me is correct. And I know one of the things you did really early on was you would literally just like manually look at transactions and just kind of watch them come in. Yeah. Like what did you get from that? I think this is kind of advice to any payment company who's starting, right? Like that you can try to design all of your fraud systems from,

you know, in the absence of data and like try to think deeply around it, but know that you'll miss it.

the far more important thing is just watching the initial activity. And by initial activity, I mean like, it's not unreasonable to expect a person at an early stage payments company to look at every transaction up until there are like, you know, 5,000 transactions a day. You kind of have to do that. Oh, and I don't know of how to build

good risk systems without that, right? You do all of the thinking beforehand, of course. Make sure you're collecting all of the data, of course. But you're not even going to know what the patterns look like until you start seeing the patterns.

you have a pretty effective neural net between your ears, you should go use it. Does AI and all that kind of help with this nowadays? It would be very... And I can imagine that there's quite a lot that can help. I'd be surprised if you still didn't want to do, like, a person sitting in front saying, this trucking company should not, in fact, be receiving this mortgage escrow payment.

Something's up. I think Will actually told me that Stripe has built their own kind of like model internally where when certain entities make a transaction, you can kind of tell based on learnings over time of where they might be grouped and more chances of these happening. I'll link a spot to click on to check out that part of the episode because I'll probably butcher the way exactly it's done.

But it was pretty interesting. Just like, oh yeah, I guess that does actually make sense. Like you can just essentially the models will know, like, you know, it's probably not perfect, but they'll, they'll start to pick up on these things and these behaviors and those clusters are fun. I like anything within early company. It can be tempting to overbuild in that particular area and

it can be useful if instead of coming up with a intricate data pipeline analysis tool, then you just look at them at the start. And one thing I think you like to do is you like to give cards to your agents. Like, how does that go? Because a lot of people are kind of like, oh, we're going to... It's like agentic payments. Right? Yeah. How do you do this? Yeah, the thing that I'm...

I don't know. I feel like I'm particularly grateful that I'm able to do that perhaps not everyone is able to do yet is... You know,

similar to others, have agents wandering the world doing things for me.

Main page at 1:05:33

But I want them to be able to economically interact. I want them to be able to pay. What are they paying for right now? I am currently traveling to San Francisco. I likely need to

send a set of flowers home, thanking for being with the kids today. and being able to set the agent upon that task is great. Yeah, so what are the limitations of that, right? Like if an agent goes to the local flower shop, jumps on their site, is able to stack up the checkout, et cetera, et cetera, it would be useful if they're able to complete that.

But in order to be able to complete that, they've got to have, you know, credit card, right? They don't need to be able to interact with crypto, right? Like

the flower shop already has a checkout. They need to be able to enter the 16 digits of the card on the site.

Now I'm able to give my agents payment cards, right? Like my agents have their own bank account.

And if they need more money, they ask me for more money. Like I went through the $100 you gave me. Can I have more, please? And so you give them $100 more. And a difference here that I'm pointing towards is I'm not sitting within the synchronous approval process for a transaction, right? Like the point is that I'm not thinking about it. It selected, you know, what it was buying.

It selected the instant coffee from the local roastery that it's going to send me, right?

It would be broken for me if I need to go in and enter the card details.

likely what would happen there would be some sort of timeout because I didn't get to it quickly enough and we'd end up in various loops to try to synchronize our schedules. But having the agent have an account, having the agent have a payment card is great. And the control plane on that for me, the thing that stops it...

just burning a bunch of money, is it can only spend what's in its account and it asks for more money when it needs more money. It sounds like it's almost, it's like when you have an employee that has a charge card, like you can only spend this, these are the rules of what you can spend it on. It's almost like applying the same principles in a way to an agent.

Indeed. And this is what you can and can't do, there's rules. Yeah, and in particular, I suppose what I'm pointing towards there is we don't perhaps need to rebuild all of the checkouts across the internet. We don't need to

plug a bunch of crypto or stablecoin connections into these. It's okay that we use the existing ones. societally i hope we run both of these experiments it'd be great to know which one like you know plays out but for the immediate use case it's very very useful that we use like you know the card with its known dispute process um yeah do you have a favorite um founder or kind of historical figure that you've gotten a lot of inspiration from Oh, fascinating.

I think this is going to vary based on different characteristics in different places. There can be a hundred of these. Sure, yeah. And I think in particular, what you're trying to do there is not

overly romanticize the person, but that particular characteristic that you really liked

I mean, I've gotten some off-the-record answers to this question, like a dictator. And it's because of not what you would think. But it's kind of interesting. I won't say any of the names. It would be unfair for me to probe deeper on that particular question. Yeah, but it's kind of interesting. What did you kind of like? Oh, that's like with being fast and urgency.

Like, oh, I can apply that principle to myself. Yeah. Yeah, I'm wondering if there's like any, you know, maybe like non-intuitive or maybe it's like super obvious answers to this question. Yeah, you know the way when you end up running like

a small mental model of someone in your head, you're like, what would this person do in this situation? I feel like that's always like a kind of, you know, a sign of admiration, right? Like you've carried around this person as a heuristic for you. One related to engineering for me, if I'm allowed to go that way, and you can tell me my hobbies are too boring.

Tom Brown, who's one of the Anthropic founders previously at OpenAI, has this like remarkably impactful experience

like a technical essay from early on of just

use boring technology widely, right? Don't try to over-optimize for the correct tool for the correct job.

Very much benefit from like, use a broad tool that can do many things. And what you're pointing towards there is just like the price of complexity. When you're using the correct tool in the correct place, now you have many correct tools and your ability to understand the correct tools is hard. So just be very careful about your complexity cost of what it is that you're doing.

I reach for that one maybe daily. It's okay to do something in the wholly uneventful way. It doesn't need to seem bright or clever. It just needs to seem maintainable.

Yeah, and it's almost like There's sometimes some like the glamorous of building and trying some new hard thing. There's like more social status internally. Like you get more joy from like, I figured out this really complicated thing versus like sometimes it's the beauty of the simplicity of like not actually complicating it. Don't get me wrong, I can admire arduous intellectual pursuits, right? It's okay that those, you know, but we can do that by answering the hard crossword on a Sunday, not by obligating our team to maintain a thing for years, right?

Main page at 1:11:46

choosing the uneventful thing. And I especially think this is true in banking, right? Imagine if your friend is an air traffic controller and they show up to meet for you to coffee and they're saying like, I've had the most exciting day at work. You'd be like, no. I don't want excitement from my air traffic controllers. It was so boring. Nothing happened.

I will make the statement. I think you want the same from your banker. I think you want your banker to have an uneventful day. I think you want your banker to, in fact, enjoy uneventful days. There to be a quiet satisfaction of that

you know, reliably, regularly getting the things done as expected. Yeah, I think that personality works well in banking. Yeah, because when I think about what are the biggest events in banking, they're generally not something that you want to see happening on a daily basis. Indeed. Yeah. Yeah. In much the same way that the underlying utilities of society, electricity or water, et cetera,

it's okay that these things are uneventful. it's in fact good that they're uneventful yeah I feel like any type of like infrastructure you want no events like it's just it works as is always all the time yeah and um operators and builders and maintainers who who kind of value that um it like I know can be well suited yeah well it's been a lot of fun thanks for coming on the show I've very much enjoyed it thank you very much for having me And thank you very much for listening.

Thanks again to this episode's sponsors, Monaco, Flex, Clerk, and Numeral. And if you like this, please share it with a founder who's building on top of the banking system or anyone who still thinks the way to fix broken infrastructure is to stack one more layer on top of it. Make sure to check out the back catalog of over 150 episodes with founders and investors like Tomer London from Gusto, Sam Blond at Monaco, and Gary Tan at YC.

Tune in over the next few weeks for conversations with Matt Murphy at Menlo, where we unpack their pre-revenue investment in Anthropic, with Oren Ziv, who manages over $2.5 billion as a solo GP all by himself, and with Aydin Senkut at Felicious Ventures. If you don't want to miss any of these, subscribe to my newsletter, The Split. Links in the description to get each episode plus a transcript emailed to your inbox every week.

Thanks again for listening. See you next time.