Skip to content
Why Stripe’s 1st Employee Bought a Bank | Darragh Buckley, Increase artwork

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

The Peel with Turner Novak

October 15, 2026

Darragh Buckley was the first employee at Stripe. He’s since started Increase, the banking infrastructure that moves over $500 billion a year. And he just bought a bank.

Speakers Turner Novak, Darragh Buckley

TopicsTechnology

Turner Novak (0:02)

Darragh, welcome to the show.

Darragh Buckley (0:04)

Cheers. Thank you very much for having me.

Turner Novak (0:06)

Thanks for being here. So you were the first employee at Stripe, and you just bought a bank. What's going on?

Darragh Buckley (0:13)

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.

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. 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 like 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.

Turner Novak (1:38)

So can you not do that five, 10 years ago?

Darragh Buckley (1:42)

Well, I think if it's okay here, I'll speak to some kind of experience from Stripe.

Turner Novak (1:47)

Yeah.

Darragh Buckley (1:48)

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. Like you're always wearing someone else's shoes. Like something always felt a little off, be it the size or the scale.

Turner Novak (2:17)

So like what felt off?

Darragh Buckley (2:19)

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 moving those large amounts of money is by wire.

But Stripe was always hesitant to do that because when a wire would fail, we would receive an e-mail 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.

Turner Novak (3:11)

But they can't see the stone in your shoe. So just like, just why are you so worried about your shoe?

Darragh Buckley (3:15)

Like just walking in or like just... Very much a princess in the pea kind of problem, right? Like, but you know you're not in the right place. You know that this is not built for you.

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, etc.

Turner Novak (3:58)

by API.

Darragh Buckley (4:00)

The dispute process that comes out at the end.

Turner Novak (4:03)

Yeah, I get emails from my bank sometimes is like someone just polled an ACH. Like, do you approve the ACH? That has already been polled.

Darragh Buckley (4:11)

Maybe you could have told me before that.

Yes, the train has left to 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? Like...

62 more minutes of transcript below

Thousands of transcripts fetched by people building searchable podcast archives

Fetch the whole transcript

The demo key returns a sample episode in full, no card needed:

request
curl -H "x-api-key: pt_demo" \
  https://spoken.md/transcripts/1000651996090

Markdown with the speakers named, for your notes, your knowledge base, or anything that makes HTTP calls.

From $0.10 per transcript. No subscription. Credits never expire. Prices exclude VAT, added at checkout for EU customers. Not what you expected? Email us within 14 days with 20 or fewer credits used and we refund the pack in full.

Using your own key:

request
curl -H "x-api-key: YOUR_KEY" \
  https://spoken.md/transcripts/1000796495615