An engineer sits across the table from a bank examiner. How does that conversation go?
Better than you might think, Darragh Buckley would argue. The engineer wants to know what the system is doing at every step. The examiner wants to know it’ll do the right thing every time. Those aren’t competing demands. They’re the blueprint for a better bank.
That idea runs against one of FinTech’s founding stories: Banking’s future depends on replacing legacy infrastructure. But after helping build Stripe’s earliest banking integrations, Buckley reached a different conclusion. The rails weren’t broken. The trouble was the distance between those rails and the software companies trying to build on top of them.
That conviction eventually carried Buckley beyond banking-as-a-service partnerships and all the way into bank ownership.
Increase’s launch of Increase Bank is where that journey landed. Founder and CEO Buckley told PYMNTS CEO Karen Webster that his time as the first employee of Stripe revealed capabilities banks possessed but rarely exposed in ways modern software companies could actually use.
“The systems are good and reliable,” Buckley said. “And they serve very much the use cases that they were built for.” But, he added, “many of our current use cases, especially around ambitious technology companies, run into edge cases that perhaps weren’t contemplated. If you’re rebuilding the technology stack anyway, contemplating those compliance regimes from the start makes it easier to build a safe and sound system.”
Plenty of FinTech executives would happily send ACH and Fedwire to the museum. Buckley won’t. He credited the Federal Reserve with operating dependable systems.
“The Federal Reserve is fantastically reliable,” Buckley said. “They changed the messaging format for Fedwire… across 3,500 institutions… and everything succeeded. Everyone got paid. Lights stayed on. Traffic still moved.”
His analogy isn’t a blockchain or a rocket ship. It’s public transportation.
The tunnels don’t change often. What riders feel are better schedules, easier payments and clearer explanations when something goes wrong. The infrastructure can stay put while the experience gets better.
That mindset helps explain why Increase didn’t start by pursuing a banking charter. It first built its own technology stack, connected directly to payment networks, and developed the operations developers need to build financial products. Only after years of working with partner banks, serving on a community bank board, and learning how regulated banking really works did Buckley conclude that the final piece required owning a bank.
The strategy grew out of the kind of operational frustration Buckley knew firsthand from Stripe.
Take wire transfers. Sending the money usually wasn’t the hard part. Handling the exceptions was. A failed wire might arrive as an email demanding manual intervention, workable at dozens of transactions, painful at thousands. Buckley doesn’t blame partner banks.
“They were built for a different kind of client,” he said.
Software companies can’t treat payments as black boxes. They need to see when an instruction is received, transmitted and acknowledged. That status data can be as valuable as settlement itself because it’s what lets developers build dependable products around the payment. Buckley said.
Webster put her finger on what buying a bank actually changed.
“It seems like the bottlenecks come in many different ways, including the access part,” she said, referring to direct connectivity to Federal Reserve services and card networks.
Buckley agreed, but direct access isn’t the whole story. Bank ownership also removes the final operational layer between payment networks and the businesses that depend on them.
“Increase’s role is improving that last mile delivery as opposed to burning the house down and trying to build something new,” Buckley said.
Data Turns Banking Into Software
Fixing the last mile doesn’t stop at processing a payment. It means turning a bank’s operations into something software can see, test and trust.
Consider Increase’s continuous test transactions that monitor connections to the Federal Reserve, Visa and other networks. Instead of waiting for customers to report a problem, the system keeps checking whether the infrastructure upstream is behaving as expected.
Then there’s payroll, the invisible machinery of household finance. Buckley called payroll engineers “one of the great unsung heroes of the U.S. economy” because millions of consumers don’t think about payroll until it fails. Mortgages, rent payments and countless household obligations depend on those files arriving on schedule every pay period.
“For most banks, that’s not the way it works,” Buckley said. “If you’re the payroll engineer, you send the instructions to your bank. Your bank may or may not turn around and say, ‘We got it,’ and that is the terminal point in that interaction. The next point you will know whether everything succeeded will be user support questions telling you, ‘I didn’t get my money.’”
Increase answers the silence. As processing advances, it confirms receipt, submission to the Federal Reserve, and the Fed’s acceptance and action on the file. The goal isn’t simply faster payments. It’s knowing where the money is before support tickets start telling you where it isn’t.
Buckley brings the same software lens to community banking. Community doesn’t have to mean geography, he said. Technology can group businesses by the financial problems they share.
“The dentist in Bend [Oregon] looks more similar to the dentist in Boston than they do to the restaurant next door from a banking services perspective,” Buckley said. “We should end up with the bank for dentists, not the bank for Bend, Oregon.”
That’s the engineer-and-examiner conversation in practice. Regulation supplies the guardrails; software makes the system visible. Buckley isn’t trying to tear banking down. He’s trying to make it legible to the companies building on top of it.
Watch the full interview with Darragh Buckley to learn more about:
- Why Buckley said he believes owning a bank changes the economics and operational flexibility of API-first financial infrastructure.
- How technologists and bank regulators approach the same operational problems from different perspectives, and why both disciplines benefit from closer collaboration.
- Where stablecoins fit alongside the FedNow® Service, Fedwire and ACH, and why Buckley said domestic payment rails and blockchain networks solve different problems.
