Cross-border payment compliance management: the operating model for banks and credit unions

Cross-border payment compliance management is an operating model, not a control list. Most credit unions and tier-2 banks already own every individual control. Screening runs. Onboarding files exist. Reports get filed on time. What breaks is the seam between those controls, and the question of who owns what once a payment leaves the country. This article sets out how to structure that work. It covers which obligations bind, which team should hold each control, where the handoffs fail in practice, and how to evidence the whole chain when an examiner asks. It is written for institutions sending business payments abroad, whether through a correspondent bank, a licensed money service business, or a settlement platform.

What does cross-border payment compliance management actually cover?

Start with scope. A domestic payment answers to one regulator and one rulebook. A cross-border payment answers to at least two, plus the rules of any correspondent in the middle. Cross-border payment compliance management is the discipline of holding all of them at once, on every transfer, with evidence.

Five obligations do most of the work. Customer due diligence at onboarding, including beneficial ownership. Sanctions and politically exposed person screening on both parties. Travel Rule data that must accompany the transfer. Transaction monitoring tuned to corridor risk. Recordkeeping and reporting that lets a supervisor reconstruct any payment years later.

Each of these is well documented on its own. The failure is almost never a missing control. It is a control that runs on data another system already discarded, or a control that two teams each assumed the other owned. Cost pressure makes this worse. The World Bank Remittance Prices Worldwide database has kept the global average cost of sending 200 dollars above 6 percent for years, and compliance overhead is a large part of that number.

Who owns each cross-border payment compliance control?

Write the ownership down before you write the policy. In most mid-size institutions the map is stable, even when nobody has drawn it.

Onboarding sits with the business line, with compliance approving the risk rating. Screening sits with an operations team that runs the engine, while compliance owns the tuning and the alert disposition. Travel Rule data sits with whoever builds the payment message, which is usually payment operations rather than compliance. Monitoring sits with the financial crime team. Reporting sits with the named anti money laundering officer, who is personally accountable in most jurisdictions.

The seam that fails most often is between the message builder and the screener. If party data is assembled in one system and screened in another, the two drift apart. A beneficiary name normalised for display is not the string the screening engine should see. Fix that seam by naming a single record of truth for party data, then screening from it directly. Everything else in the model depends on that one decision.

How should sanctions screening work on an outbound payment?

Screen at three points, not one. Screen the counterparty at onboarding. Screen every payment before release. Rescreen the whole book whenever a list changes.

The reason for the third point is legal rather than operational. United States sanctions rules impose strict liability, so a payment released to a newly designated party is a violation regardless of intent. The Office of Foreign Assets Control updates its lists continuously. A control that screens only at onboarding will miss those updates, and the gap is invisible until it is expensive.

Two practical tests will tell you how strong the control really is. For any historical payment, can you show the list version used and the match score at the time. Can you rerun last month of traffic against the current list in under an hour. If either answer is no, the control is weaker than the policy claims it to be.

What does the Travel Rule require, and at what thresholds?

The Travel Rule is the obligation most often left half built, because it lives inside the message rather than on a screen. FATF Recommendation 16 requires originator and beneficiary information to travel with a transfer, and the FATF interpretive note applies a 1,000 USD or EUR threshold to virtual asset transfers. The FATF 2024 Targeted Update reported that most assessed jurisdictions were still only partially compliant with the virtual asset standard.

Thresholds differ by jurisdiction, so build to the strictest one you touch. In the United States, the Bank Secrecy Act recordkeeping and travel rules apply to funds transfers of 3,000 dollars or more, under 31 CFR 1010.410. In Canada, FINTRAC requires travel rule information on virtual currency transfers of 1,000 Canadian dollars or more, and a large virtual currency transaction report at 10,000 Canadian dollars within 24 hours. In the European Union, Regulation (EU) 2023/1113 extended transfer of funds obligations to crypto-asset transfers from 30 December 2024, with no de minimis threshold at all.

The data itself is already standardised. IVMS101 is the interoperable format for originator and beneficiary details. ISO 20022 messages such as pacs.008 carry the same parties as discrete structured fields. When both are populated from one record, the Travel Rule stops being a separate project and becomes a property of the payment.

Which records must you keep, and what will an examiner ask for?

Assume reconstruction. The test a supervisor applies is whether you can rebuild a payment end to end from your own records, without asking a counterparty for help. Bank Secrecy Act rules require covered records to be retained for five years, and comparable retention periods apply in Canada and the European Union.

In practice an examiner picks a sample of payments and then asks for the evidence behind each one. The customer file and the beneficial ownership record. The screening result, with its timestamp and list version. The Travel Rule data exactly as sent. The monitoring alerts raised, and how each was dispositioned. Any report filed, and the documented reason it was or was not filed.

Counterparty evidence matters just as much. FinCEN requires a money service business to register within 180 days of formation and to renew every two years, under 31 CFR 1022.380. A bank serving MSB customers should hold current registration evidence for each one, refreshed on a schedule rather than at account opening.

How do you build a cross-border payment compliance model that scales?

Sequence the build so that each stage is useful on its own, and so no stage depends on a system you have not replaced yet.

• Map every corridor you actually serve, with volumes, counterparties and the regulators at both ends. Scope follows the corridor map, not the organisation chart.
• Name one owner and one deputy for each control, in writing. Ambiguous ownership is among the most common root causes in examination findings.
• Designate a single record of truth for party data, and make screening, messaging and reporting all read from it.
• Set thresholds to the strictest jurisdiction you touch, then document why. Running one standard costs less than running five.
• Instrument every handoff. Log the time, the actor and the outcome of each step so the chain can be replayed rather than remembered.
• Run a reconstruction drill. Pick ten past payments at random and rebuild each from records alone, on the clock, once a quarter.
• Review corridor risk on a fixed cadence, and again after any list change, licence change or new counterparty. Static risk ratings age badly.

Notice what is absent from that list. There is no new screening vendor and no new policy document. The work is structural. It is about where data lives, who is answerable, and whether the chain can be replayed on demand.

The institutions that pass examinations comfortably are not the ones with the most controls. They are the ones that can name the owner of every control, show the data each control read, and replay any payment from their own records without making a phone call.

Where StableNet fits

StableNet, built by SpendTheBits, is a cross-border B2B payment and settlement platform for banks, credit unions, licensed money service businesses, exchange houses and remittance fintechs, and it is built so that compliance and messaging read the same data. KYB and KYC onboarding, KYT, sanctions and PEP screening, FATF Travel Rule data in IVMS101 form, a compliance workbench and a tamper-evident audit trail sit inside the same platform that generates the payment messages: pacs.008 customer credit transfers, pacs.009 interbank legs, pacs.002 status reports and pacs.004 returns, all tracked end to end by UETR. Settlement is in regulated stablecoins on public blockchains and completes in minutes with on-chain auditability, so the record an examiner asks for and the record the rail produces are the same record. SpendTheBits is a Bank of Canada registered payment service provider and a named finalist in the Swift Hackathon 2026 Technical Challenge.