the case for open payment rails

Payments data is the most standardizable data in finance, and the least standardized. What we learned building Open Rails.

A payment is about as simple as financial events get: someone, someone else, an amount, a time. Yet ask two banks to compare notes on a single wire and you’ll watch a week disappear into exports, format arguments, and phone calls. The data isn’t complicated. It’s just trapped — in per-institution schemas that were each reasonable once and are collectively absurd now.

We spent two years building Open Rails, a shared schema for payments data across a consortium of institutions. This is the argument for doing it in the open, and the honest account of what that costs.

Format friction never shows up as a line item, which is why it survives. It shows up as reconciliation teams, as fraud patterns that stop at institutional boundaries, as “we’ll have that analysis next month.” One member institution estimated that a third of its payments-operations effort was translation in some form — moving the same facts between representations that disagree about nothing important.

The perversity is that everyone pays this tax to preserve schemas nobody loves. The formats aren’t competitive advantages. They’re just old.

A closed consortium standard would have solved the immediate problem, so it’s fair to ask why publish. Three reasons held up. First, adoption: institutions that would never license a competitor’s format will adopt a public one, because a public schema is infrastructure rather than a vendor relationship. Second, scrutiny: the schema got materially better after outside teams filed issues against it — edge cases in refunds and partial settlements that no single member had clean data on. Third, longevity: a format survives its authors only if nobody owns it.

What open doesn’t mean is open data. The schema is public; every institution’s transactions stay its own. Conflating the two is the fastest way to lose a room of bank executives, and the distinction deserves to be made early and often.

The schema took months; the mappings took the rest. Every institution’s feed carries decades of local decisions — fields repurposed in 2009, codes that mean different things before and after a migration. The useful move was treating each mapping as a living artifact: an agent maps the feed onto the schema field by field, keeps the original value alongside the mapped one, and flags what it can’t classify instead of guessing.

Keeping the original beside the translation turned out to be the trust mechanism. When a mapped value looks wrong, anyone can check it against the source in seconds. No one has to believe the pipeline — they can audit it.

Start with two institutions and one payment type, not eleven and everything. Publish the schema before it’s finished — the corrections are the point. Budget for translation, not design; the elegant part is the cheap part. And write down, on day one, that the schema is public and the data is private. Every hard conversation we had traced back to someone assuming otherwise.

The rails are boring. That’s the achievement. The interesting work — the shared fraud signals, the same-day cross-bank reconciliation — only became possible once the boring layer stopped being anyone’s problem.