Cross-Border Payments Are Currency Transactions Between Whom?
Cross-border payments connect payers and recipients in different countries, but currency conversion is not always involved. Understanding that distinction helps finance teams assign costs, collect the right data, and avoid incorrect payment assumptions.
Cross-border payments are currency transactions between parties in different countries. Those parties can be businesses, individuals, governments, or financial institutions. More precisely, they are international payments: they may involve currency conversion, but do not have to.
The short answer to “between whom?” is therefore payers and recipients in different countries—not necessarily parties using different currencies. The Association for Financial Professionals’ cross-border payments definition uses the location of the sender and recipient as the central distinction.
For finance teams paying hundreds of international recipients, this is more than terminology. Treating “cross-border,” “foreign currency,” and “international wire” as interchangeable can lead to unnecessary conversions, incomplete onboarding, and inaccurate cost reporting.
Who are the parties in a cross-border payment?
The underlying payment connects the party that owes money with the party entitled to receive it. Banks and payment providers help execute that obligation, but they are not necessarily the commercial counterparties.
- Business to business: A company pays an overseas supplier, agency, or incorporated contractor.
- Business to individual: A platform pays an overseas seller or creator, or a company pays an individual contractor.
- Individual to individual: A person sends a remittance to someone in another country.
- Individual to business: A customer pays a merchant abroad.
- Institutional payments: Banks, governments, and other institutions transfer funds internationally.
Do not confuse the recipient with the recipient’s bank. A supplier’s incorporation country, operating location, and bank-account country may differ. Likewise, a payment provider may receive funding in one jurisdiction and deliver the payout through a domestic account elsewhere.
For ordinary explanation, payer and recipient countries establish the concept. For regulatory reporting, card-network classification, or provider eligibility, use the applicable definition: residence, legal establishment, account location, and payment-instrument issuance can matter differently.
Cross-border payment and currency exchange are separate concepts
A cross-border payment answers where the parties are. Foreign exchange answers whether one currency is exchanged for another. The delivery rail answers how the payment reaches the receiving account.
The following hypothetical cases show why these should be separate fields in a payment record.
| Scenario | Cross-border obligation? | FX required for this payment? | Operational implication |
|---|---|---|---|
| A French business pays a German supplier in euros | Yes | No, if funded in euros | Different countries, same currency |
| A US company pays a UK supplier’s USD account in dollars | Yes | No, if dollars remain dollars | Confirm the account accepts USD |
| A US company converts dollars to pay a UK supplier in pounds | Yes | Yes | Record conversion and delivery separately |
| A business converts its own USD balance into EUR | Not established by conversion alone | Yes | An FX trade is not necessarily a supplier payment |
| A provider pays an overseas recipient from prefunded local funds | Yes, for the underlying obligation | Possibly upstream | A domestic final leg does not redefine the obligation |
Same currency does not mean domestic, and a domestic delivery rail does not mean the underlying obligation is domestic. Conversely, a foreign-currency transaction does not prove that the parties are in different countries.
What actually happens to the money?
In an electronic bank payment, physical currency is not shipped across a border. Institutions debit and credit accounts, exchange payment instructions, and settle obligations through the relevant arrangements.
Correspondent banking connects institutions
Where the sending and receiving banks lack a suitable direct relationship, intermediary banks can help complete the payment through correspondent accounts. SWIFT can carry the payment messages; it is not itself the account holding the supplier’s money.
Intermediaries can introduce additional processing, deductions, or investigations. However, counting intermediaries alone does not establish the final price or arrival time. Currency, account arrangements, compliance checks, and service terms also matter.
Local delivery changes the final leg
A provider may collect funds from the payer and use liquidity already held in the destination market to make a domestic transfer to the recipient. Funding, conversion, and recipient credit can occur at different times.
That structure can simplify delivery, but it does not remove the provider’s need to manage liquidity and applicable compliance obligations. Finance should still identify the legal payer, beneficiary, funding currency, and amount due.
Currency conversion may happen before, during, or after payment
A company can buy destination currency before a payment run, request conversion when releasing a payment, or send a currency that the receiving bank later converts. These choices place control over the exchange rate in different hands.
Holding funds through multi-currency global accounts can separate conversion timing from payout timing. It does not eliminate currency exposure: holding a currency ahead of a future obligation creates its own treasury decisions.
Separate the payment obligation from the FX trade
Consider a hypothetical US business that owes a UK contractor an amount denominated in pounds. It holds dollars but can choose when to buy the pounds.
There are distinct records to preserve:
- Commercial obligation: The contractor must receive the agreed sterling amount under the contract’s fee and payment terms.
- FX transaction: The business exchanges dollars for pounds at an agreed rate, subject to the quote’s conditions.
- Payment execution: The provider delivers pounds to the contractor’s eligible account.
If the business already holds enough pounds, it can make the payment without a new conversion. If it buys pounds but the payout fails, the conversion may remain completed. A payment failure does not automatically reverse the FX trade.
This distinction also separates different risks. Exchange-rate risk concerns changing currency values. Payment-delivery risk concerns whether the beneficiary receives the funds. FX settlement risk concerns delivering the currency sold without receiving the currency bought.
The BIS Committee on Payments and Market Infrastructures discusses this last risk in its report on FX settlement risk mitigation. Payment-versus-payment arrangements address that currency-exchange settlement risk; they do not by themselves guarantee that a supplier’s account has been credited.
Build a classification record before selecting the rail
For a scaled payout operation, a single “international payment” flag is too coarse. Keep the following dimensions separate so that routing, compliance, and reconciliation use the same underlying facts.
- Identify the obligation’s parties. Record the paying legal entity and the beneficiary’s legal name, entity type, and relevant country information.
- Identify the accounts. Capture the sending and receiving account countries separately from the parties’ countries.
- Record the currencies. Distinguish invoice currency, funding currency, instructed payout currency, and expected credit currency.
- Assign conversion responsibility. Specify whether treasury, the sending provider, or the receiving institution controls any conversion.
- Define the amount owed. Establish whether the agreement requires a fixed recipient amount and who bears permitted charges.
- Validate corridor-specific requirements. Confirm account identifiers, bank details, beneficiary information, payment purpose, and supporting documents where required.
- Define completion evidence. Distinguish an accepted instruction from account debit, settlement, and confirmed beneficiary credit.
Country requirements are not interchangeable. An IBAN is not a universal account identifier, and a BIC alone does not identify the beneficiary’s account. Use the country-by-country international contractor payment guide as a starting point, then confirm current requirements with the executing provider.
Keep payment classification distinct from tax classification, too. A recipient’s bank-account country alone does not establish tax residence or withholding treatment. Tax documentation and identity checks support the broader process but should not be reduced to a bank-location lookup.
What the definition cannot tell you
Calling a payment cross-border does not establish its speed, price, or regulatory treatment. An instant domestic final leg may still depend on prior funding, conversion, screening, or operating windows elsewhere in the chain.
The BIS report on extending and aligning payment-system operating hours identifies operating-hour differences as a cross-border payment friction. Ask providers which stage their delivery estimate measures and what conditions must be met before the clock starts.
Similarly, “no conversion” does not mean “no fees.” Same-currency international payments may still incur transfer, intermediary, or receiving-bank charges.
Start with the parties, then design the payment
The answer is straightforward: cross-border payments connect parties in different countries. Currency exchange is a possible component, not the defining requirement.
Before your next payment run, classify obligations, account locations, currencies, and conversion responsibilities separately. Review exceptions where those fields disagree rather than forcing them into a single domestic-or-international label.
Then evaluate payout automation against that record: can the workflow preserve the intended recipient amount, apply the appropriate controls, and reconcile conversion separately from delivery? Those are more useful acceptance criteria than an “international payments supported” checkbox.
Created with AI assistance. Sources are linked in the article; this content is general information, not legal, tax, or financial advice.
Discussion
32 commentsRelated resources
How to Pay International Contractors: A Country-by-Country Bank Payment Guide
A successful contractor payment delivers the agreed amount—not just a completed transfer instruction. Build a country-specific payment plan around bank details, currency, fees, and the date funds become available.
Payout Support: Build a Clear Escalation and Resolution Model
Reliable payout support connects recipient questions to payment evidence, accountable owners, and controlled actions. Here is how finance and operations teams can build that operating model across borders.
Google Affiliate Account: Choose the Program, Verify the Payout
There is no single Google affiliate account for every product. Identify the right program, payment operator, and country rules before treating reported earnings as available cash.
Run your entire money cycle on one ledger
Global payouts, AP/AR automation, and AI agents with their own wallets and spend limits.
Get started
The 'local delivery changes the final leg' section is critical for anyone building payment status dashboards. We initially showed 'payment complete' when our provider debited our account, but the actual recipient credit happened 1-3 days later depending on their local clearing times. Had to rebuild the entire status flow to track funding, conversion, and final settlement as separate events.
We ended up adding a separate 'recipient_credited_at' timestamp field in addition to 'provider_debited_at' for exactly this reason. The gap is especially unpredictable when the local leg hits a weekend or holiday in the recipient country that we weren't tracking.
The point about not confusing the recipient with the recipient's bank is something we learned the hard way. We had a Singapore-incorporated vendor operating out of Thailand with a Hong Kong bank account, and our compliance team initially flagged it as three separate jurisdictions for sanctions screening. Turns out we needed all three data points but for different reasons: incorporation for tax reporting, operating location for service delivery verification, and bank location for the actual payment rail.
We ran into the same thing with a Malaysia-based vendor using a EUR account in Germany. Our solution was to add separate fields for beneficial owner jurisdiction, bank country, and payment currency in the vendor master record, then map those to the appropriate screening workflow. Still manual, but at least it's documented now.
We ran into the same thing with a Malaysia-based vendor using a EUR account in Germany. Our solution was requiring a jurisdiction attestation form during onboarding that captures incorporation, operations, beneficial ownership, and each bank account country separately. Still manual, but at least we have the data structured before the first invoice hits.
The scenario table really highlights why we stopped letting our ERP auto-classify transactions based on currency alone. We had a situation where a Polish entity paid a Romanian supplier in PLN and the system flagged it domestic because no FX occurred, which broke our intercompany reporting completely.
We had the exact same problem. The fix was splitting our payment table into obligation_currency, funding_currency, and payout_currency fields, plus a cross_border boolean that's set at the entity level regardless of FX activity. Took about two sprints to migrate historical data but intercompany reconciliation finally works.
We had the exact same problem. The fix was splitting our payment table into obligation_currency, funding_currency, and delivery_currency as separate columns. Once we added a geographic flag independent of FX activity, intercompany reconciliation actually started working.
The distinction between "currency conversion may happen before, during, or after payment" is something our AP team learned the hard way. We were treating the FX timestamp as the payment timestamp in our cost allocation system, which completely distorted our quarterly supplier spend reports when we started using forward contracts.
We had the exact same problem. The fix was splitting our payment table into obligation_currency, funding_currency, and settlement_currency with separate timestamps for each event. Reconciliation got more complex but at least our variance reports now reflect actual supplier costs instead of FX timing artifacts.
We had the exact same problem. The fix was splitting our payment table into obligation_currency, funding_currency, and delivery_currency with separate timestamp fields for each event. Reconciliation got easier once we stopped conflating the FX trade with the actual disbursement.
The section on separating the payment obligation from the FX trade is the clearest explanation I've seen of why booking a single journal entry for 'international payment' creates accounting chaos. We finally started treating the FX leg and the payment leg as distinct events with separate timestamps and counterparties, which means our variance analysis actually makes sense now.
Same here. We also added a reconciliation rule that alerts if the FX timestamp and payment timestamp are more than 48 hours apart, because that usually means someone bypassed the workflow and we need to manually verify the rate lock actually covered the right obligation.
Same here. We also added a reconciliation rule that alerts if the FX timestamp and payment timestamp are more than 48 hours apart, which catches cases where treasury bought currency but AP never released the actual payout.
The article correctly separates cross-border from FX, but in practice the hardest part is when your treasury team thinks in terms of FX exposure and your AP team thinks in terms of payment delivery rails. We've had situations where treasury hedged GBP exposure for a contractor who actually invoiced in USD to their US bank account, creating a completely unnecessary conversion round-trip. The data model fix is easy once you see it, but getting both teams to use the same fields consistently took months.
We solved this by requiring AP to flag the obligation currency at invoice entry, which treasury then uses to aggregate exposure by currency and maturity. The payment rail decision happens downstream. It's extra work up front but it finally got both teams looking at the same source of truth.
We solved this by requiring AP to flag the obligation currency at invoice entry, which treasury then uses to plan conversion windows. The payment team doesn't care about the hedge, they just need the right currency available when the run executes. Took about two quarters to get everyone aligned on the handoff.
The point about recipient's incorporation country vs. operating location vs. bank-account country is something we learned the hard way. We had a vendor incorporated in Singapore, operating from Thailand, with a EUR account in Estonia. Our AP system flagged it as APAC, our compliance team treated it as EU for sanctions screening, and our FX desk priced it as SGD. Took three months to align the data model across teams.
We ran into exactly this with a contractor set up similarly. The real problem came when we needed to issue a 1099 equivalent and had to reconcile which jurisdiction's rules applied. Now we collect all three data points during onboarding and map them separately in our vendor master file.
Same. And then tax reporting season arrived and we realized we'd been classifying the withholding obligation incorrectly for six months because we keyed off the bank country instead of tax residency. Now we collect all three locations at onboarding and let the system route based on context.
The correspondent banking section glosses over one of the biggest operational pain points: when an intermediary deducts fees without clear documentation, reconciling the payment to the original invoice becomes a nightmare. We've started requiring our provider to give us full routing chain visibility upfront, but even then the deduction amounts are unpredictable. Would be helpful to see a follow-up on how treasury teams are actually handling intermediary fee variance in their reconciliation workflows.
We've been asking for the same thing. The challenge is that many intermediaries aren't in the original routing instruction—they get added dynamically based on correspondent relationships at settlement time. Unless your provider has real-time MT103 field 71F visibility or pre-negotiated routing, you're often reconciling after the fact.
We've had better luck negotiating fixed intermediary fee caps directly into the provider contract, but that only works if you have enough volume. The routing visibility helps but doesn't solve the underlying issue that correspondent fees aren't standardized and can change without notice.
I'd push back slightly on the local delivery section. Yes, the provider's liquidity management is their problem, but from a treasury perspective you absolutely need visibility into whether they're doing real-time conversion or drawing down prefunded balances. The former gives you spot exposure, the latter means you're exposed to however they hedge their pool. Not the same risk profile at all.
Agreed, and this is why we flag the conversion method in our payment metadata now. When a provider pulls from prefunded balances you're effectively locking in rates upstream, which changes how we think about hedge timing. Our treasury team wants that visibility at the transaction level, not buried in the provider's black box.
Agreed, and this is why we flag the conversion method in our payment metadata now. When a provider uses pooled funds they're effectively taking the timing decision away from you, which can be fine for small payouts but becomes a hedge accounting headache at scale.
The scenario table is exactly what we needed when building our invoice tagging schema last quarter. We were treating every cross-border payment as an FX event in our data model and it created a mess during reconciliation when our European entities paid each other in euros. Ended up with phantom conversion records that accounting had to manually reverse.
We had the exact same problem. The fix was splitting our payment table into obligation_currency, funding_currency, and conversion_occurred as separate columns. Reconciliation time dropped by about 60% once we stopped assuming cross-border always meant FX.
We hit the same issue with euro zone payments. Our workaround was to add a boolean field for FX_occurred and a separate one for cross_border_flag so reconciliation could distinguish them. Still required schema migration and back-filling historical transactions though.
Quick question on the compliance angle: when you say "account location" can matter differently for regulatory reporting versus provider eligibility, are you referring to OFAC screening based on account domicile vs beneficial owner residence? We've had vendors reject payments to USD accounts held by non-US entities and the explanation was always vague.
Yes, exactly. OFAC screening looks at beneficial ownership and residence, but some providers also have internal rules based on where the account itself is held—especially if it's in a jurisdiction they don't have clearing arrangements with or where sanctions risk is elevated. We've seen the same thing: contractor clears OFAC, USD account exists, but the account domicile triggers a separate eligibility rule in the provider's system.
Yes, that's part of it. OFAC cares about beneficial ownership and where the person or entity is actually located, not just the account's physical domicile. But card networks sometimes classify cross-border based on issuing bank country versus merchant acquiring bank country, which can be totally different from where the actual parties are incorporated or resident. We ended up maintaining separate flags in our system because one vendor's eligibility check would pass but another's compliance screen would kick it out.