From Single-Rail Systems to a Forever Payments Platform
Payments infrastructure shouldn’t need constant rewrites. Explore how modern teams are building multi-rail systems designed to adapt as new rails and requirements emerge.

Over the last several months, I’ve been hearing a familiar tension from teams building payment-heavy products: payment volumes are up, customer expectations are up even higher, and the rails they started with are no longer enough.
ACH isn’t going anywhere. Wires remain essential. RTP and FedNow are accelerating. Push-to-card has become table stakes for certain payout experiences. And stablecoins have introduced a settlement model that simply didn’t exist a decade ago.
For a long time, it was reasonable to design around a single primary rail. You could integrate deeply, build your product, and plan to revisit the architecture later. But the world has changed. Customers now expect money to move instantly, globally, and reliably, regardless of the hour or the rail. What many teams are experiencing isn’t failure; it’s simply that their architecture was built for a different time.
When Single-Rail Architectures Hit Their Limit
Most products still begin the way they always have: integrate a single rail deeply, ship quickly, get traction. That approach works, right up until the moment it doesn’t.
Suddenly the architecture begins to feel tight. Each new rail introduces its own settlement rules, failure modes, exception logic, and compliance workflows. Operational dashboards drift out of sync. The same logic shows up in multiple places because every new rail needs its own set of accommodations. Product velocity slows, not because the team is moving slower, but because the infrastructure wasn’t designed to stretch this far.
When you zoom out, the pattern becomes clear: you thought you were adding a new rail. In reality, you were revealing the limits of an old architecture.
Stablecoins Don’t Replace Rails—They Expand Them
Stablecoins are often presented as replacements for traditional rails. In practice, they expand the surface area. They offer global, 24/7 settlement with deterministic finality, which unlocks real opportunities for cross-border platforms, marketplaces, and treasury operations.
Stablecoins don’t remove complexity. They introduce their own compliance requirements, operational patterns, and risk considerations. When a system wasn’t designed to handle that variation, the friction becomes obvious very quickly. The question is whether your payments architecture was built to absorb change.
Designing for a Multi-Rail Future
The teams that navigate this transition share a common trait: they treat payments as intent, not as rail-specific instructions. “Move this amount from here to there under these constraints” becomes the abstraction. The system chooses the appropriate rail; the product doesn’t hardcode it.
When you lean into this approach, the architecture begins to change.
- A unified ledger models money movement consistently across rails.
- Compliance sits alongside payments rather than being reinvented per integration.
- Operational visibility comes from one source of truth rather than from stitching together partial views across banking portals, blockchain explorers, and internal logs.
This approach isn’t theoretical. It’s how teams preserve product velocity while the ecosystem around them evolves. It’s how companies adopt new rails without rewriting core systems. And it’s how PMs and founders maintain flexibility as their businesses enter new markets, add new payout types, or respond to competitive pressure.
The Case for a Forever Payments Platform
A “forever payments platform” isn’t about permanence; it’s about resilience. It is infrastructure designed to outlive the rail choices you make today. As rails accumulate, the question becomes less “Which rail should we adopt next?” and more “Can our architecture absorb this change without destabilizing the product?”
For founders, this means removing a source of existential risk: the midlife architectural rewrite that arrives right when the business is scaling fastest. For PMs, it means the ability to ship new payment capabilities—new rails, new geographies, new flows—without rethinking the foundation every time.
At Modern Treasury, this philosophy shapes the work we’re doing: one system to operate across fiat and stablecoin rails, a unified ledger, integrated compliance, and the flexibility to work with your banks or with managed accounts. But even beyond our product, the principle holds: build for change, not for a single moment in time.
If you’re evaluating how your product will evolve in a multi-rail world, check out what we’re building. We’re always glad to compare notes. It’s a challenging shift—but also one of the most exciting opportunities payments teams have had in decades.

Sam is co-founder and CTO of Modern Treasury. Before that, was an engineer at Kiavi (fka Lending Home), was co-founder and CTO at Agustus & Ahab, and worked for Everlane and Rearden Commerce. He earned his BS from Columbia University, where he also worked on hacking projects. Sam is known to celebrate company milestones with Krispy Kreme deliveries.







