Your SEPA-shaped API can't send a US payment — and where the rails seam really lives
We recently read a European digital bank’s public and partner APIs from source — the SDKs, the OpenAPI spec, the partner API — to find where a US-domestic payment would enter its system. The answer was nowhere. Not because the engineering was poor; the security model was better than most. It was because the API had been built, correctly, for the world it lived in.
This is not one bank’s quirk. It is the default shape of every European payments API, and it is the first thing to understand before planning a US rails integration.
What a SEPA-shaped API looks like
Open the payment object in almost any European bank’s API and you find the same fields: an amount with a currency, a description, and a counterparty alias — a pointer whose type is IBAN, EMAIL, PHONE_NUMBER, or, for the occasional international leg, SWIFT. That is the whole counterparty model. It has served SEPA well for years.
Now try to express a US payment in it. There is no field for an ABA routing number. No concept of an ACH Standard Entry Class code, or of the batch file that ACH transactions travel in. No FedWire message type. No pacs.008 bound for The Clearing House. No place to put the beneficiary’s account type. The rails are not “unsupported”; they are not representable.
The same holds one level down. The bank’s internal model — which its public API is usually a thin window onto — was designed around IBANs and SEPA settlement. It is not a matter of adding an enum value.
Why this matters more than the rails themselves
Most US-entry programs start with the rails: get RTP access, get FedWire access, map to NACHA. That ordering is backwards. Before any of those adapters can be built, there has to be a place in the bank’s own system where a US-dollar payment exists — with the identifiers the US networks need, the state machine US rails require (pending, sent, accepted, settled, returned), and an audit trail that a US examiner can follow.
We call that place the seam. It is the boundary between the bank’s core and the US rails, and it is the single design decision every US entry path shares:
- If the bank charters a US subsidiary, the seam is between the group core and the new bank’s ledger.
- If it acquires a US bank, the seam is between the group core and the acquired bank’s rails access.
- If it operates through a sponsor bank while the charter question plays out, the seam is between the core and the sponsor’s platform.
Only the counterparty at the seam changes. The seam itself — and the ISO 20022 canonical layer that runs across it — is the same in all three cases. That is why we tell foreign banks that a well-designed US rails integration should not depend on a regulatory outcome they don’t control.
What to put at the seam
Three things, in this order.
An ISO 20022 canonical message. Not a US-specific model bolted onto the SEPA one, and not the sponsor bank’s proprietary format. The bank emits and accepts pacs.008-shaped intents at the seam; everything rail-specific lives in adapters on the far side. This keeps the bank’s SEPA model untouched and makes each US rail a mapping problem rather than a core change.
Idempotency and reconciliation the bank owns. Public and partner APIs in this space rarely offer an idempotency key on payment submission. A retry after a timeout can double-send. The seam is where the bank persists an outbound intent before anything is submitted, and where it reconciles what was sent against what the network confirmed — because the network’s callback is a hint, not the truth.
A US-shaped audit trail. Deterministic transaction identifiers, originator and beneficiary data captured in the form BSA/AML and OFAC processes need, and an immutable record a US examiner can read without an engineer in the room. Retrofitting this after the fact is the most expensive mistake in the program.
The practical test
If you are a European institution planning US entry, ask your engineering lead one question: where, in our system today, would a payment to a US routing number live? If the answer is a pause, you have found the first work item — and it is not a rails adapter.
Cross Border Wires designs and builds US payment rails integration — RTP, FedNow, FedWire, ACH, ISO 20022 — for foreign banks, fintechs, and sponsor banks. If you’re working out where your seam is, the Rail Integration Assessment answers it in one to two weeks.