by Simon Darchis, SVP, Head of Fintech Products & Strategic Initiatives, FinWise Bank
I’ve had a version of the same conversation dozens of times over the past few years. A fintech payments lead leans in and tells me their biggest problem. And almost every time, I expect them to say something about speed or costs. Real-time and cheap rails, faster clearing, instant settlement—that’s the narrative that’s dominated payments for as long as I can remember.
But more often than not these days, that’s not what they say.
What they describe is messier, and honestly, more interesting:
“We have five different payment integrations and none of them talk to each other.”
“We can’t tell our compliance team what our actual fund balances are in real time.”
“We built a payments feature. We didn’t mean to build a payments operations team.”
That shift in the conversation tells me something important is happening. Speed is no longer the hard part. Managing the complexity we built in pursuit of speed—that’s where the real challenge lives now.
Too Many Rails, Not Enough Clarity
It wasn’t supposed to be this complicated.
ACH, wires, RTP, FedNow, push-to-debit, bill pay networks—each of these rails exists for good reasons. They serve real use cases with real tradeoffs between cost, speed, reach, and certainty. But as fintechs layered them on one by one over the years, what looked like optionality on the roadmap started to feel like technical debt in production.
The result isn’t a payments stack. It’s a patchwork.
Multiple integrations that don’t share a data model. Disconnected workflows that require manual handoffs. Reconciliation processes that would feel more at home in 2008 than in 2025. And somewhere in the middle of all of it, a compliance team trying to answer questions about fund positions that the system simply wasn’t designed to answer.
I see this pattern constantly—both in conversations with our fintech partners and in the work we’ve done internally building out our own payments infrastructure. The operational surface area expands faster than the team’s ability to manage it. And in today’s environment, where regulatory scrutiny is real and customer expectations are high, that gap has consequences.
From Moving Money to Orchestrating It
The concept of a payments hub isn’t new. But I think we’re finally starting to understand what it actually needs to be.
Moving money—the actual mechanics of getting funds from A to B—is largely a solved problem. The rails exist, the networks are mature, and execution is table stakes. What isn’t solved is the layer above that: the intelligence, the control, and the accountability that should sit on top of those rails.
A real payments hub does more than aggregate. It orchestrates. It makes decisions in real time—should this transaction go over RTP or fall back to ACH? Is the recipient reachable on push-to-debit? Does this use case require wire certainty?—and it does so without requiring a fintech to think about the underlying plumbing.
But here’s what I’ve come to believe after spending years working on this: orchestration is only half of the equation. The other half is trust. And trust in payments infrastructure comes down to one thing: the ledger.
Why the Ledger Became the Center of Everything
If there’s one lesson I take from everything that’s happened in the BaaS space over the past few years, it’s that ledgering is no longer a back-office function. It never really was—we just got away with treating it like one for a long time.
The model that most of the industry grew up on was what I’d call indirect subledgering: funds sit in a pooled FBO account at the bank, the fintech maintains their own internal ledger, and the two systems stay in sync—most of the time. When they drift apart, someone notices. Sometimes quickly, sometimes not. And in the worst cases, nobody notices until a regulator asks a question that neither side can confidently answer.
I’ve seen this firsthand. And I think anyone who’s worked closely with BaaS infrastructure over the past few years has too.
The shift that’s happening now—what I’d call direct subledgering—addresses this at the structural level. Instead of splitting the source of truth between the bank and the fintech, the subaccounts live at the bank. Transactions post directly to them. Balances are real-time, always. The ledger of record is unified and auditable—and critically, the FBO itself isn’t directly reachable; all access flows through the defined subaccount structure.
For fintechs, this changes the operating model in ways that go beyond compliance. Real-time visibility into fund positions. Built-in reconciliation. Reduced dependency on third-party ledger systems that introduce their own failure modes. And maybe most importantly—confidence. The kind of confidence that lets a fintech tell a customer exactly where their money is, at any moment.
That’s not a back-office function. That’s a product differentiator.
Intelligent Routing: Designing Around Outcomes, Not Constraints
Once you have ledger integrity as your foundation, the rail orchestration layer can do what it was always supposed to do: get out of the way.
The fintechs I find most interesting aren’t the ones asking “which rails should I support?” They’re asking “how do I build a product that just works?” And the difference between those two questions is the difference between building around constraints and designing around outcomes.
A well-architected payments hub handles this automatically. RTP or FedNow when the recipient is reachable and speed is the priority. ACH when cost efficiency matters more than immediacy. Push-to-debit when reach is the variable. Wire when certainty is non-negotiable. The fintech expresses the intent; the infrastructure figures out the execution.
This isn’t just more elegant engineering—it’s operationally significant. Every time a fintech team has to manually manage a payment rail decision, they’re spending cognitive bandwidth on infrastructure instead of product. Multiply that across thousands of transactions and dozens of edge cases, and you start to understand why payments operations teams end up as large as product teams.
The goal is to make that overhead invisible.
Security Has to Move Upstream
One thing I want to be direct about: as payments accelerate, the old model of catching problems after the fact breaks down.
Real-time payment systems don’t give you much runway for manual intervention. By the time a fraud flag comes through, the transaction may already be settled. That means the control environment has to shift—not just in tooling, but in philosophy.
Authentication tied directly to subaccounts. Granular access controls that prevent direct reach into pooled funds. Real-time fraud monitoring baked into the transaction flow, not bolted on afterward. Zero-trust architectures that treat every request as potentially untrusted until proven otherwise.
I think of this as the difference between reactive security and structural security. Reactive security tries to catch bad things as they happen. Structural security makes bad things harder to do by design. In a real-time payments world, structural is the only model that actually scales.
The Bigger Picture: Payments as Infrastructure
Zoom out for a moment and the pattern is familiar.
We’ve seen this kind of transition before—in cloud, in data infrastructure, in APIs. Fragmented tools give way to unified platforms. Batch processing gives way to real-time systems. Visibility that used to require a report gives way to a live dashboard. And slowly, what used to be a feature becomes core infrastructure.
That’s what’s happening in payments. It’s not a feature fintech companies bolt onto their products anymore. It’s the foundation their products run on. And that distinction matters enormously when you’re thinking about reliability, regulatory readiness, and the ability to scale without breaking something.
I’ve thought a lot about this framing in the context of what we’ve been building at FinWise. The question was never just “how do we move money?” It was: “what does it mean to own the infrastructure layer that fintech products depend on?” Those are very different questions, and they lead to very different answers.
What This Means for Builders
If you’re building a fintech product today—or partnering with a bank to power one—I think the strategic question has genuinely shifted.
Speed is assumed. Connectivity is expected. The new differentiation is in control, clarity, and accountability.
The fintech products that will define the next few years aren’t going to win because they support every payment rail. They’re going to win because those rails work together seamlessly, because the underlying financial truth is always accurate, and because the whole system can hold up under scrutiny—regulatory, operational, or otherwise.
In my experience, the fintechs that get this right early actually move faster, not slower. They spend less time on operational fire drills and more time on product. They have better conversations with regulators. And they’re better positioned to scale when the moment comes.
Closing Thoughts
I started this piece talking about a conversation I’ve had dozens of times. What I’ve noticed is that the fintechs that are most advanced aren’t the ones still chasing speed—they’re the ones who figured out that speed without control isn’t actually an advantage.
At FinWise, the work we’ve been doing around payments infrastructure reflects this belief directly. Unified rails, direct subledgering, real-time ledgering, structural security—these aren’t separate initiatives. They’re components of a single thesis about what payments infrastructure should look like for the next era of embedded finance.
The future of payments isn’t faster. It’s more trustworthy. More accountable. Built to hold up to whatever the market—and the regulators—throw at it.
That’s the standard we’re building toward. I think it’s the one that matters.