Darragh Buckley, CEO of Increase, on building the next generation of banking infrastructure

Today I’m talking with Darragh Buckley, the CEO and co-founder of Increase. If you’ve been following fintech for a while, you probably know Darragh as employee number one at Stripe, where he built the team responsible for moving money at a massive scale. At Stripe, he learned a crucial lesson about infrastructure: when you’re stuck solving business, technical, and risk problems all at once, you need to drop down a layer. That insight led to Increase, which does something quite novel, instead of connecting to banks one by one, they connect directly to the Federal Reserve itself, operating their own banking core that exposes all this functionality through APIs. With a team of less than 20 people, they’re now processing over $100 billion annually.

In this conversation, we dig into the lessons Darragh learned scaling Stripe, why he believes compliance and accounting should be built into engineering from day one rather than bolted on later, his vision for a future where community banks serve specific communities like dentists or families managing elderly parents’ finances, and why he’s personally investing in community banks across the Pacific Northwest. We also get into real-time payments infrastructure, including a great story about buying a car on a Saturday. Now let’s get on with the show.

In the podcast, you will learn:

• How Increase was born out of early challenges at Stripe.
• What he learned about scaling fintech companies at Stripe.
• The advantage of dropping down a layer when building fintech infrastructure.
• How Increase is able to connect directly to the Federal Reserve.
• The concept of a side core and how it integrates with banking cores.
• The different types of companies they work with.
• A fun story about paying a car dealer with a real time payment on a Saturday.
• The scale that Increase is at today.
• Why they decided that now is the time to spread with word about Increase.
• Why it matters to build compliance into your product very early.
• What lessons compliance can learn from software engineering.
• How they are managing real time risk.
• Why Darragh has personally invested in several community banks.
• What will have changed in financial services if Increase is successful.

Read a transcription of our conversation below.

FINTECH ONE-ON-ONE PODCAST NO. 565: Darragh Buckley

Darragh Buckley

I would like to see many more specialized financial institutions. And I think I would like to see specialized financial institutions within kind of industry niches. I would like to see a bank for dentists. I would like to see a bank for state farm agents. I would like to see a bank that helps folks manage their parents’ finances safely and soundly. We should see more products like that in our industry because we all have different needs. It might be the case that the community in community banking is no longer defined geographically, but based on other interests, like based on dentists, based on family finance.

Peter Renton

This is the Fintech One-on-One podcast, the show for Fintech enthusiasts looking to better understand the leaders shaping Fintech and banking today. My name is Peter Renton and since 2013, I’ve been conducting in-depth interviews with Fintech founders and banking executives. Today I’m talking with Darragh Buckley, the CEO and co-founder of Increase. If you’ve been following Fintech for a while, you probably know Darragh as employee number one at Stripe, where he built the team responsible for moving money. Now with Increase, he’s doing something quite novel in the infrastructure space. Rather than connecting to banks one by one, Increase connects directly to the Federal Reserve itself, operating their own banking core that exposes all this functionality through APIs.

In this conversation, we dig into the lessons Darrell learned scaling Stripe from nothing to a massive scale, why he believes compliance and accounting should be built into the engineering from day one rather than bolted on later, and his vision for a future with many more specialized financial institutions serving specific communities. We also get into the real-time payments infrastructure, including a great story about buying a car on a Saturday and why Darragh has been personally investing in community banks across the Pacific Northwest. Now let’s get on with the show.

Welcome to the podcast, Darragh.

DB: Cheers, thank you for having me, Peter.

PR: My pleasure. So let’s get started by giving a little background about yourself. I know you’re also not from this country. So tell us a little bit about where you grew up, how you came to be here and some of your professional highlights.

DB: Cheers. Yes, I’m originally from Limerick, Ireland, and though it’s been 20 years now since I’ve been in the US, I initially came for school and for work. I think one of the most kind of notable things in my professional background is I was early on at Stripe where I helped build out the team responsible for programmatic money movement. One of the assumptions that people make when they use Stripe is that money will arrive in their bank account and the team responsible for ensuring that happens was the team I led and grew. Like many folks at Stripe, it was always fascinating to understand what was happening a layer deeper. So Stripe was built on top of Wells Fargo in the early days. And you could always see that there were data or capabilities that existed a layer down. That was the prompt for my current company, Increase. So Increase exposes all of the US depository functionality by API allowing folks to do things like open bank accounts, send and receive transfers, issue cards, balances and transaction reporting. It’s the kind of thing that you’re able to do with paper and persistence in a branch, but being able to have your machines talk to my machines to make it happen instead. The kind of users and use cases that we end up seeing are, it’s folks who are sensitive to being able to do their banking at scale. So things like payroll companies, bill payment companies, any neo banks, that sort of thing.

PR: Yeah. So let’s go back to Stripe for a minute because you’re famously known as the first hire at Stripe. And that is obviously like now it’s a massive company, I think probably the most valuable private fintech company in the world. So tell us about, I’d love to get your learnings from scaling a fintech company from virtually from scratch all the way up to now trillions of dollars in transaction volume, what did you learn about scaling fintech companies?

DB: There’s multiple lessons and multiple stories. Let me start with, Stripe started as US only, but obviously had lots of non-US ambitions from pretty early on. One of the frictions that we ran into as we rolling from country to country was that you needed to establish a new bank partner relationship everywhere you went. So you’d end up needing to, you know, to, when you’re going into Australia, you were talking to National Australia Bank. And you are trying to align the business conversations, the risk conversations, and also the technical evaluation. And that’s just a lot of problems to try to solve at once, right? Like you’re trying to judge and assess what will make a successful partnership across a lot of axes there. And I remember sitting one Thursday night after multiple of these conversations with Dita. Dita is a good friend who led Stripes non-US ambitions and aspirations.

And both of us lamenting just like how hard this problem was to solve. That when you were trying to solve across three different things, you were just having to trade them off. And in that conversation sparked a kind of a reflex motion that occurred everywhere within Stripe, which is, are we doing this right? Do we really have to solve these problems at once? And between that conversation with myself and Dita was how can we decouple the business conversations from the engineering conversations?

How can we make this one problem instead of three problems? And the answer at Stripe there was drop down there. So rather than connect into a bank’s infrastructure, drop down and connect to Visa or MasterCard directly. And then rather than needing to evaluate whether or not this solution was technically workable, you get to solely have the business conversation and you get to have the technical conversations decoupled from that.

Now I’m not a very creative person. So when an answer like that comes up to one solution, I think how it could be applied elsewhere. so increase is just an expansion on that rather than connecting into banks across the US. Is there a way in which you can do one technical connection and not need to couple a technical conversation with a business conversation? So the way in which increase applies this is increase connects directly to the Federal Reserve rather than bank by bank.

And that makes it, first of all, it’s a lot easier to build on top of the Federal Reserve than it is to build on top of Wells Fargo’s interpretation of what the Federal Reserve is doing. And it also allows you to have separate technical conversations from business conversations. I think this insight should be used in more places.

PR: Hmm, interesting, interesting. Let’s just dive into that now. I’m going to leave that for later. But I’d love to kind of dive into, you’re connecting directly with the Federal Reserve, but you don’t have a Fed Master account is my understanding, right? So how are you doing that?

DB: Yeah, the Federal Reserve does contemplate technical service providers. Many of your listeners will be familiar that there’s across the nation, the banks and credit unions use technical service providers for their banking core, so their own maintenance of balances and transactions. Each of these can connect through to the underlying networks. So Increase’s role is as a peer to Jack Henry, FISA, FIS itself, the world. We run what’s known as our own core, sort of maintenance of those transactions and balances. But importantly, we expose all of that functionality by API.

PR: So you guys are a startup, and Jack Henry, Fiserv, FIS have been around for decades, public companies massively. How were you able to get a startup to do the connections that those established companies have done?

DB: Yeah, a lot of that is showing the experience and capability of the company. I was in the fortunate place where folks had heard of my prior work and therefore there was kind of an establishment of credibility that existed there. A lot of increased folks have also come from Stripe and so we’re used to operating reliable infrastructure like we do now. So a lot of the appeal is that we are used to building reliable, transparent, flexible systems. And that appealed both to banks, the Federal Reserve, and to our users.

PR: So then let’s talk about this side core piece that like you’re not a full banking core. You’re not really competing against directly against that. Like you are working with organizations that have existing relationships, those big three core providers that you mentioned. So what maybe you could firstly define what you mean by a side core and then you’re also you’re partnering with banks, fintechs, neo banks. mean, tell us a little bit about the types of partnerships you have. But first, let’s start with the side core.

DB: I I’ll answer the question, but let me jump to a story. When building Stripe on top of Wells Fargo, Stripe was always hesitant to do disbursements to merchants by wire. So to use the Fedwire system to pay people what they were owed from their credit card transactions. And the reason for that hesitancy wasn’t because wires are expensive or slow or anything else. It was because when a wire was unable to be delivered, so when you sent it and, for example, the account number was off or anything else, the way Stripe would be notified would be receiving an email from Wells Fargo. And it’s hard to build good, reliable product on top of an email flow. And I don’t fault Wells Fargo for this in any way, shape or form. They designed themselves for a different kind of client. Operating at Stripe’s scale on wires wasn’t something that Wells Fargo had built in early on. And this points to one of the things about a core. Like Wells Fargo’s core wasn’t contemplated that Stripe would want to programmatically interact with the core as much. If your FIS, Fiserv, Jack Henry, or any of the other cores across the nation, you’re building your core with an expected bank account holder in mind. And this will be the core for small businesses. This will be the core for large scale ACHs. This will be the core for long tail retail deposits. So many of the assumptions about how your core will be used that impact what you build come from who the expected account holder is.

This is the motivation for increase building an API first core, right? That we needed to build our own maintenance of transactions and balances because how our core is used is different to how an FIS or a Fiserv or a Jack Henry core is used. To get specific, we have many users who do payroll on top of us. Now you can always send and receive, you know, 10 transfers a day on top of any core across the country. But if you’re sending 10,000 transfers a day, or if you’re sending 100,000 or a million transfers a day, you’re going to need to interact with that core differently. And so it’s very important that increase contemplates that your machines are going to need to talk to my machines, both for the happy path, everything works out just fine, but also for the exception cases. This got returned because the account number was off, or…we need to be able to monitor the kinds of returns, know, administrative versus unauthorized returns. And if you’re able to build that in early on in the technology, you’re able to make both the product better, but also things like monitoring and supervision and compliance with rules and regulations easier.

PR: Then what about like the types of companies you’re working with? Like I read you’re working with banks, traditional banks. You’re also working with lot of fintechs, payroll companies. Maybe tell us a little bit about the use case for each of the different types of companies you work with.

DB: It’s probably useful to talk about a specific one, just so everything is tangible. so a user that has given us permission to talk about them and their use case is Ramp’s bill pay product is built on top of this. So you go along to Ramp and you upload your invoice ramp pulls out the pertinent details. you know, the amount and the invoice number and who you’re trying to pay Ramp then needs to affect that money movement. Right. And so Ramp needs to pull money from your account and push money to the payee’s account.

And the way in which they do that is through increase. They have their machines talk to our machines that say, debit this account on FedACH for this amount, and then credit this account by FedACH for this amount. And so the affecting the real world money movement is what increase helps Ramp with.

PR: What about other types of companies?

DB: At the level at which we operate, the distinction between, for example, payroll or bill payment or loan servicing, they all very quickly look and feel like the same thing. They all very quickly look and feel like expose the data and capability of the underlying US networks at high fidelity. So be able to interact with the Federal Reserve’s network, FedACH or Fedwire or CHECK21 or more recently FedNow by API.

We’ve talked about real-time payments for years and years and years. And I think one of the most interesting things about the last year has been that we now have it, that we are now living in the world of having real-time payments, though, of course, it’s not evenly distributed in the country just yet.

A friend of mine was going to trade in their car. Their car was out of warranty. They’ve got young kids. So they were just going to the auto dealer to take their current car and ask for the more modern version of it so that it’s back under warranty. They show up on Saturday at the auto dealer and they say, I’d just like to take that car. I’ll give you the keys for my one and I’ll pay you and I’ll drive off. And whatever the amount was run into a bit of difficulty, the difference between the traded in car and the new car was more than the auto dealer would allow them to swipe on their card. And they’re like, okay, can I give you a check? And the auto dealer was, I’m sorry, we’re over our risk limit of what I’m allowed to accept in a check.

How am going to pay you? Like, I need to take this car off the lot. Surely there is some way for me to pay you. And so the salesperson at the auto dealer goes into their finance function, chats for five minutes, comes back out and they’re like, I’ve got a solution for you. We’ll give you a loan until Monday. And you know, my friend is like, you know, surely there is a better way here. My friend happens to use Increase.

And so he jumps into his increase account and he sends out a real time payment from his increase account to the auto dealer’s account. And he says to the salesperson, would you mind going back into your finance function and just click the refresh button on your bank account and see whether or not the money has arrived? And you can imagine the salesperson on the forecourt is sweet summer child. That isn’t how US finance works. Like, do you not know that it’s a Saturday? Per our traditions, we…we don’t do things like that. It’s like, just humor me. Go back inside and click the refresh button. Salesperson goes back in, clicks the refresh button. Like, how did you hack my bank account? Right? Like, I can see the money that’s subscribed. And it’s fun. It’s like when the existing networks are good. The FedACH, Fedwire, Check21, FedNow, real-time payments cards are great. They’re not evenly distributed. We’re missing some of the last mile delivery of their functionality but they are ubiquitous, cheap, fast, great networks. We should do a better job of using the things that we already have.

PR: Right. No, I totally agree. the expectation, like as you say, that auto dealer expectation is that it’s a Saturday. I won’t get anything till Monday. That, I mean, we’re in FinTech. We know that there are better and faster ways, but that hasn’t reached the broader population yet. It’s like, we still need, we have work to do there I think. Anyway, let’s talk about scales. think I read that you’re processing over $100 billion annually and your team still has less than 20 people. Are those numbers, are they roughly correct? Tell us about your scale.

DB: Fortunately, those are a bit stale at the moment. think we’re in… We’re still about the same headcount, but yeah, numbers have kept growing. Yes, so I’m fortunate enough to have seen Stripe’s growth curves and to have seen increases growth curves and increases, especially volume growth curve is maybe 10x what Stripe’s growth curve was at the equivalent time in. Now, the volume is very different, it monetizes differently, but it’s fun to see what you can do with a smaller team these days.

The reason that you can do it with a smaller team is partly where we sit within the ecosystem, referred to this earlier, but it’s a lot easier to build directly on top of the Federal Reserve for scale and reliability than it is to build on top of a bank’s interpretation of the Federal Reserve. Federal Reserve is just a very good, reliable organization. But it is a lot of trust that users give us for dealing with that scale and taking that very, very seriously with respect to things like…transparency, reliability, and the flexibility of it, but also things like cash reconciliation and making sure that everyone understands where every penny is at every second.

PR: You’ve kept a low profile, it seems. I mean, you’ve been around for many years. Was it 2020 you started Increase? Was that the year? And you’ve kept a pretty low profile. I haven’t seen a whole lot of articles about you guys, but it sounds like that’s changing, I mean, you know, we’re having this interview. know you’re talking with others in the space as well. Why have you decided now’s the time to get your name out there more?

DB: Yeah, known bug, as they say, but the, it’s important to spend the first while, especially in financial services, ensuring that reliability is high. We have a different level of responsibility with respect to people’s money and making sure that we feel good from a sleep at night perspective, but also from a security perspective, a compliance perspective, that everything works as it should. And that takes time. This isn’t a short or quick journey for us. This journey is measured in decades for us and making sure that we’re doing it correct is important to me.

PR: I read somewhere that you were talking about that this now in today’s world, really can’t have people that are making decisions that live in silos anymore, that you feel like you’ve got to have, you need to be able to speak both the language of finance and the language of engineering. mean, that’s something that I think in traditional banks, this is a fairly new idea, right? Where you’ve had your engineering team, have your finance team, your marketing team. Like how and why do we need to change that?

DB: This is a part I’m very excited about. I think if I was to speak to an example of the kind of thing that’s important to me here, I think if you build compliance and accounting and regulation and safety in earlier on within the technology and in the product, you can improve all of those. You can improve the product, can improve the regulatory compliance, you can improve the safety of them.

To give an example, there’s a rule in US money movement called the travel rule. It strictly applies to any wires, for example, that are greater than $3,000 and it requires certain data elements be present. And ordinarily, in kind of a traditional setup, you’d enforce it perhaps based on policy. You’d write down that any wire greater than these $3,000, you must collect these details. And as you come up to your exam, you’d pull all your wires that are greater than $3,000, you’d sample them. You’d check in that you have all of those details and you’d sigh with relief. And don’t get me wrong, I love me a good sigh, but like it’s a lot easier to build that in earlier such that you know all of those data elements must be collected because your engineering systems wouldn’t allow someone transmit a wire to you, but for having those details. Like literally if someone tries to give you an instruction in your dashboard, your site or your API, you would decline it except for those details being present. And that’s a far easier system to reach a high degree of confidence that complies with all the rules and regulations. There’s no sigh of relief that all of those data elements are there if it wasn’t possible for any wire instruction to be sent there but for having those details.

And you can do this in a myriad of places across building financial technology. If you build in compliance early, if compliance is just as part of good practice as building software tests and running your continuous integration suite against your code, it makes compliance easier. I came to engineering from a investment banking background. And one of the things that struck me as I was first arriving in software engineering was the reliance on tooling, right? Like how software engineering itself improves by building better tooling.

And one of the lessons from early on was that hard things become easier if you do them more often. How do you plan for whether or not the server fails? You blow up the server regularly. Now, the hard thing within a lot of regulatory compliance is your examination every 12 to 18 months. And how do you get better at doing your regulatory exam every 12 to 18 months? You do it yourself every day.

Yeah, you set up the system such that you’re running the examination on yourself each and every single day and not on a sampled basis, not at a watered down basis, but as close to the real thing as you can. And obviously you have to automate that if you’re doing it every single day. But one lesson that software engineering can bring to compliance, and of course, there are many lessons that compliance can bring to software engineering, but is that doing hard things more often makes you better at doing the hard things.

PR: Let’s talk about real time risk management because you gave the example of that real time payment moving on a Saturday, you’re moving money at scale, you’ve got direct Fed connections. How are you managing the real time risk here and what does that infrastructure look like?

DB: From a practical point of view, means making sure that you’re having the metrics, making sure that you’re having the reasonable primitives that you’re going to need, recognizing when an account or routing number is associated with prior negative behavior, watching out for which data elements are associated with prior maladventure. And those are kind of the table stakes of everything that we do. I think…if I was to point towards one area where we as an industry could do better with risk management, especially with respect to real-time payment risk management, it’s that we currently have a mismatch between our fraud system times and our payment rail times. We can now move money very quickly, but we’re slower to follow up with our fraud systems.

I can wire you all of the money now but for me to follow up with your bank and report that, that transfer was actually associated with some fraudulent behavior might take days. So we have money movement in seconds, but fraud in days. And that’s incorrect, right? Like we need to reduce the time difference there. Sometimes folks within banking will point towards slower systems as a benefit for fraud reduction. And I would gently push back…that the thing that’s incorrect is not the speed of the money movement. The thing that’s incorrect is the differential between the speed of the money movement and the speed of the fraud system. That we need to get the fraud systems back to comparable time horizons than the money movement systems. Make me double-click on any of that if it’s too abstract.

PR: Do you build that yourself or do you go out to other, to vendors specializing in that sort of thing?

DB: We can build the parts that impact just us on our own, our own ability to review transfers, our own ability to watch out for bad behavior. Financial networks are necessarily networks, however, they involve multiple banks and multiple financial institutions. So some of that needs to be industry standards of speed to reaction. If, for example, there was this fraud pattern from, I don’t know, maybe a year, a year and a half ago of mortgage escrow fraud. You’d end up with in particular, was folks using trucking services details to open an account. And so you expect this to be a trucking service. You expect this to be involved in fuel payments and receiving payments themselves from whoever the manufacturer is who’s paying them to move their goods and services. But what you’d actually see is the first transfer that would arrive in would be a mortgage escrow wire. And we all know where this comes from. It comes from…you’re making a home purchase and someone sends you the PDF that says, instead of using those details that I gave you, use these ones instead and trying to steal someone’s life savings. And those are very, very sad cases. But when you receive that fraudulent wire, you need to go back to the original bank and tell them we have received this fraudulent wire. I need to give this money back to you. Someone has been misled here. And if you can send me the wire in seconds, but it takes me days to get it back to you, that’s a mismatch, right? And we as an industry need to get better at reducing that mismatch in time.

PR: Also, one of the few articles that I’ve read about you in recent years, in the last year, is that you’ve personally invested in some community banks. What’s going on there?

DB: Yeah, I live in Oregon and Pacific Northwest generally. There’s a number of small community banks that I’ve invested in. Community banking being the local economic driver of the towns we live in, the counties we live in, the states we live in. I would like more of these to thrive. There are skills that I think, I don’t know, perhaps some of my background could help those institutions develop. And I would like to be able to help build the next generation of community banks. So bringing in some technology into banks such that they can still safely and soundly serve their communities, but are able to do so with less of a deficit in technology to kind of the large national brands. You may love your local community bank, but at some stage you need the app that JP Morgan Chase gives you. It’s disappointing that you have to leave your community bank relationship, you know, because Chase has Apple Pay and your local bank does not. That would be a sad reason for us to lose that community bank.

PR: So last question then, if or let me say when increase is very successful over the next decade, what will have changed for those of us in financial services that are doing the building?

DB: There’s part of this which is boring, which is reliable, transparent, flexible product building kind of appeals to the engineer who is at the payroll company. And so that’s, you know, may you never have the excitement of not receiving a paycheck because of an engineering system upstream. But let me point to things that are perhaps more tangible and impactful, or at least resonant.

I would like to see many more specialized financial institutions. And I think I would like to see specialized financial institutions within kind of industry niches. I would like to see a bank for dentists. I would like to see a bank for state farm agents. I would like to see a bank that helps folks manage their parents’ finances safely and soundly. We should see more products like that in our industry because we all have different needs. It might be the case that the community in community banking is no longer defined geographically, but based on other interests, Like based on dentists, based on family finance.

PR: I think could well be a sustainable future for community banks. But anyway, we’re out of time, Darragh. I’ll have to leave it there. Great to have you on the show. Really enjoyed learning more about you and your company. Thanks and best of luck.

DB: Cheers, thank you for having me, Peter.

PR: During conference season, I was at a small event with Michael Su, the former acting head of the OCC. He talked about the need for community banks to build communities beyond the geographic ones they currently serve. This was exactly the same point that Darragh was just making. But what is different is that Increase has the technology to help make this happen. Now, it is just a case of how many community bank CEOs and boards are forward thinking enough to make this transition. But that is a conversation for another time.

Anyway, that’s it for today’s show. If you enjoy these episodes, please go ahead and subscribe, tell a friend or leave a review. And thanks so much for listening.