A domestic payment answers to one regime. A cross-border payment answers to the regime where the money starts, the regime where it lands, and often a third that governs the rail or the currency in between. None of these defer to the others. They stack, and they all apply at the same moment.
Most teams discover this the hard way: they build the happy path for one corridor, then bolt on compliance country by country as expansion demands it. That produces a system where the same transaction is handled three different ways depending on which engineer touched it last. The alternative is to treat the multi-rulebook problem as a design input from the start, the same way you would treat latency or idempotency.
Why one transaction triggers three regimes
Take a payout from a US business to a freelancer in Germany, settling in euros.
The originating leg falls under the US Bank Secrecy Act. FinCEN's Travel Rule requires that transmittal orders of $3,000 or more carry specified originator and beneficiary information, and the sender must screen against OFAC lists before releasing funds. The receiving leg falls under EU rules: the recipient's payment institution operates under PSD2 and the EU Funds Transfer Regulation, which mirrors the FATF standard and demands its own originator and beneficiary data set. The currency conversion and the rail in the middle add a third layer, because whoever performs the FX and moves the value across the corridor is itself a regulated party with its own licensing and reporting duties.
One payment, three sets of obligations, all live at the instant the money moves. The transaction does not get to pick which rulebook wins.
The thresholds do not even agree. The US Travel Rule floor is $3,000. The FATF standard, which the EU implements, sets the structured-data floor at EUR/USD 1,000. A $1,500 transaction can be below the US transmittal threshold for certain fields yet above the EU one. If your data model assumes a single global threshold, you will under-collect on one side of the corridor and not know it.
The two licensing shapes you are building against
The regime overlap is not only about transaction data. It is about who is allowed to touch the money at all, and the two major markets answer that question with opposite architectures.
The EU: one license, passported
Under PSD2, a Payment Institution authorized in one EEA member state can passport its services across all 30 EEA states without a fresh license in each. Initial capital sits in the EUR 20,000 to EUR 125,000 band depending on the services offered. Architecturally this means one authorization, one home-state supervisor, and a single set of conduct rules you can encode once.
The US: fifty doors, no passport
The US has no federal money transmitter license and no reciprocity between states. Money transmission is licensed state by state, and a transmitter generally needs a license in nearly every state it serves (Montana being the notable exemption). Each state sets its own surety bond, ranging from low five figures to over $1 million, and its own net worth minimum. There is no single switch that turns on US coverage.
The practical consequence: your launch sequencing, your capital plan, and your go-live calendar are downstream of which licensing shape each market uses. A product that assumes EU-style passporting will badly underestimate the time and capital to reach US scale.
Build the rulebook map before you build the flow
The architectural move is to make the regime stack explicit and queryable, not implicit in scattered if-statements. For every corridor you support, capture:
- Origin regime and its data, screening, and reporting duties on the send side.
- Destination regime and its duties on the receive side, including its own threshold.
- Rail and FX regime, meaning the licensing and reporting attached to whoever moves and converts value in the middle.
- The binding threshold, which is the lowest of the applicable floors across all three, because the strictest rule governs.
When a payment is initiated, resolve the corridor, look up the stacked obligations, and collect the union of required fields up front. Collecting the strictest set once is cheaper and safer than discovering mid-flight that the destination needs a beneficiary date of birth your intake never asked for.
ISO 20022 is the carrier, not the compliance
In June 2025 FATF adopted the most substantial revision of Recommendation 16 since 2001. It requires enhanced and verified originator information plus enhanced beneficiary information on cross-border transfers, expects that data to travel in structured form aligned to ISO 20022, and introduces the Legal Entity Identifier as the key identifier for legal persons. Jurisdictions have until the end of 2030 to implement it.
The lesson for builders: the migration to ISO 20022 gives you richer, structured fields, but it does not make you compliant. It is the envelope. You still have to populate verified data, screen it, and prove the beneficiary fields are present and accurate for the destination regime. Treat the structured message as the place your rulebook map writes its output, and validate that every field the binding regime requires is actually populated before the message leaves your system. An empty but well-formed field passes schema validation and fails the regulation.
A worked example: the $1,500 corridor
Return to a $1,500 send from a US originator to an EU beneficiary.
A naive system checks the US $3,000 Travel Rule floor, sees the amount is below it, and relaxes data collection. The payment then hits the EU receiving institution, where the EUR/USD 1,000 floor is exceeded and full structured originator and beneficiary data is mandatory. The message arrives incomplete, the receiving institution rejects or holds it, and your support queue inherits the problem.
A corridor-mapped system resolves origin (US BSA), destination (EU FTR), and binding threshold (the lower EUR/USD 1,000 floor) at initiation. It collects the union of fields, screens against OFAC and EU sanctions lists, populates the ISO 20022 message in full, and releases a payment that clears on the first attempt. Same money, same corridor, one design decision separating a clean settlement from a stuck one.
Takeaway
Cross-border is not domestic with extra steps. It is a problem where two or three independent regimes apply in full at the same instant, with thresholds that disagree and licensing shapes that pull your roadmap in different directions. Build the rulebook map as a first-class part of the system, resolve the binding obligations per corridor before money moves, and let the structured message carry verified data rather than hoping it does. The teams that architect for the overlap ship into new corridors in weeks. The teams that bolt it on spend those weeks unsticking payments one country at a time.