The Quiet Craft of Picking Payment Rails
The Quiet Craft of Picking Payment Rails
In every payments roadmap I have worked on, there is a moment where someone — usually a stakeholder who has just been to a fintech conference — asks, "why don't we use rail X?" And the team has to explain, again, that rails are not interchangeable. They are choices with consequences that last for years.
This is a short field note on how I think about that choice.
Rails are not just APIs
A payment rail is a bundle of an API, a settlement model, a regulator, a counterparty network, an FX policy, and a dispute process. The API is the smallest part. When you sign up to a rail, you are signing up to all of it.
That is why "let's just integrate rail X" is rarely the right way to frame a discussion. The right framing is closer to: what does this rail let us promise our customers, and what does it force us to do operationally for the next decade?
The four questions I ask before adding a rail
Whenever a new rail goes on the table, I run it through the same checklist:
Why FX makes this even harder
In domestic payments, you can sometimes brute-force your way through a bad rail with operational effort. In FX, you cannot. The exposure is too dynamic. A bad FX rail leaks money in places that don't show up cleanly on a P&L until quarter end — and then they show up loudly.
I learned this the hard way scoping cross-border platforms. The most expensive lesson: a rail with a bad pricing feed will quietly destroy your margin while every dashboard tells you everything is fine. The fix isn't a better dashboard. The fix is to not pick that rail.
A short note to product peers
If you are a PO or PM owning a payments roadmap, my unsolicited advice:
Previous
Scrum, the Way a Banker Still Loves It
Next
Open Banking Is Mostly Plumbing — and That's the Point

Paul skipped presentations and built real AI products.
Paul K Paul was part of the March 2026 cohort at Curious PM, alongside 17 other talented participants.
