How Do Cross Border Payments Work? From Approval to Credit
A cross-border payment is a sequence of funding, checks, currency conversion, and settlement—not a single transfer event. Understand what happens after payment approval and what finance teams should verify at each stage.
Cross-border payments work by coordinating financial institutions or payment providers in different countries to debit the sender and credit the recipient. The process typically includes validating payment details, checking compliance, securing funds, converting currency when needed, and settling through banking networks or other payment infrastructure.
Not every international payment requires currency conversion, and not every payment travels through a chain of correspondent banks. Some providers collect funds in the sender’s country and pay recipients from balances already held in the destination country.
For finance teams paying hundreds of vendors, contractors, or sellers, the essential distinction is this: payment approval, provider acceptance, settlement, and recipient credit are different events. Understanding those events helps explain where money can wait—and what evidence is needed before calling an obligation paid.
What happens after you approve an international payment?
The stages below describe a typical bank-account payout. Their order can vary: a provider may validate details before quoting FX, while another may require funding before accepting an instruction. Compliance checks can occur at several points.
| Stage | What happens | What finance should verify |
|---|---|---|
| Instruction | Recipient, amount, currency, and purpose are submitted | Approved obligation and verified beneficiary |
| Validation and screening | Details and transaction are checked | Accepted instruction or actionable exception |
| Funding | Available funds are reserved or debited | Usable balance, not merely incoming funds |
| FX conversion | Currencies are exchanged if required | Rate, quote validity, and recipient amount |
| Routing and settlement | Institutions exchange instructions and settle obligations | Route reference and settlement status |
| Recipient credit | Receiving institution credits the beneficiary | Credit confirmation where available |
| Reconciliation | Payment, fees, and FX are matched to records | Matched obligation and explained differences |
Instruction: defining exactly who receives what
The sender supplies the recipient’s legal name, account details, destination currency, amount, and payment reference. Depending on the route and jurisdiction, the provider may also require an address, payment-purpose code, tax identifier, or supporting invoice.
Distinguish between a fixed sending amount and a fixed receiving amount. If a contractor must receive an agreed local-currency amount, instructing a fixed amount in the sender’s currency may not satisfy that obligation after conversion and deductions.
Validation and compliance: different checks with different purposes
Validation asks whether the instruction is usable: are required fields present, and do account identifiers follow the expected format? Compliance checks address matters such as identity, sanctions exposure, and transaction risk. Requirements depend on the provider, parties, jurisdiction, and transaction.
A correctly formatted account number does not prove account ownership. Likewise, passing the originating provider’s checks does not prevent an intermediary or receiving bank from requesting more information. Independently verify changed beneficiary details before release.
Funding and FX: making the payment executable
An approved batch cannot move without available funds or an agreed credit arrangement. A pending deposit may appear in a dashboard without being usable for payouts.
Where currencies differ, conversion may happen at the sending bank, the payout provider, or the receiving bank. Establish who controls that conversion and when the rate becomes binding. Holding destination currency through multi-currency accounts can separate conversion from payment execution, but holding foreign currency still creates exchange-rate exposure and ties up liquidity.
How does the money actually reach another country?
Correspondent banking: banks settle through accounts
When the sending and receiving banks lack a direct settlement relationship, they can use correspondent banks. A bank holds an account with another bank, often in the currency needed for settlement. Debits and credits across these accounts discharge the payment obligations along the route.
SWIFT provides secure financial messaging; it does not itself hold or transfer the payment funds. The message communicates the instruction, while participating institutions perform the account movements. Some routes involve intermediaries; others are more direct.
This explains why a transmitted message is not proof that the recipient has spendable funds. Processing at a correspondent or the beneficiary bank may still be outstanding.
Local payout networks: paying from destination liquidity
A provider may receive the sender’s funds in one country and instruct a local partner to pay the beneficiary from an existing destination-country balance. The provider then manages replenishment and settlement across its network, potentially aggregating obligations rather than making a separate international bank transfer for every recipient.
The recipient-facing leg can therefore be a domestic transfer even though the underlying transaction is cross-border. This model does not remove the need for funding, FX, regulatory compliance, or banking partners. It changes where those functions happen.
The BIS monitoring survey published in May 2026 identifies payment-system access, operating hours, and interoperability as foundations for better cross-border services. A fast domestic rail helps, but it cannot compensate for unavailable destination liquidity.
Linked instant systems and stablecoin routes
Some fast payment systems connect across borders, but availability depends on the specific linkage, participating institutions, transaction type, and limits. A domestic instant-payment capability is not automatically a global payout capability.
Stablecoins offer another settlement mechanism: value moves between blockchain addresses rather than solely through bank-account entries. However, a recipient expecting bank money may still need conversion and withdrawal through a regulated service. Network confirmation does not prove local bank credit. Custody, issuer risk, compliance, and cash-out availability remain material considerations.
What determines payment cost and delivery time?
There is no universal cross-border fee or delivery window. Both depend on the sending and receiving countries, currencies, institutions, route, funding method, and transaction characteristics.
Assess cost across the entire payment:
- Transfer charges: fees for originating or processing the payment.
- FX spread and conversion fees: the difference between the offered rate and a relevant market benchmark, plus any separately charged conversion fee.
- Intermediary or receiving charges: deductions that may reduce what the beneficiary receives.
- Exception costs: investigation, return, repair, or reconversion charges when applicable.
Ask whether the quote guarantees the recipient amount and which charges it excludes. A low transfer fee alone does not establish a low total cost.
Delivery time includes more than settlement on the final rail. Funding availability, screening, operating hours, holidays, currency conversion, and beneficiary-bank posting can all affect when funds become usable.
The FSB’s October 2025 progress report found that policy milestones had not yet translated into tangible global improvements for end users. Treat infrastructure improvements as enabling conditions—not guarantees for an individual payment. For operational forecasting, use route-specific payment ETA assumptions rather than one worldwide delivery promise.
Which recipient details are needed?
Collect information for the actual payout route, not simply the recipient’s country. For example, a domestic GBP payout in the UK commonly uses a sort code and account number; a euro bank transfer to Germany typically uses an IBAN; an Indian bank-account payout commonly requires an account number and IFSC.
These are examples, not complete country specifications. An international wire may require a BIC and bank address, while a local method may use different identifiers. Purpose codes and supporting documents can also vary by transaction.
Maintain current provider requirements by destination, currency, rail, and recipient type. The country-by-country contractor payment guide provides a useful starting point for bank-detail collection.
A hypothetical payment: accepted does not mean paid
Consider a US business paying a UK contractor in GBP through a provider’s local payout network. The invoice is approved, beneficiary details are validated, USD funding becomes available, and the provider converts the agreed amount into GBP.
The provider accepts the instruction, but its destination balance needs replenishment before the local payment can be released. Nothing is wrong with the contractor’s account, and repeating the instruction would not solve the funding constraint. It could create a duplicate.
The useful diagnostic question is not simply “Where is the payment?” It is: “What is the last confirmed event, what event should happen next, and who owns that transition?”
A release checklist for finance and operations
- Define the obligation: confirm recipient, invoice, receiving currency, and required net amount.
- Validate the route: confirm eligibility, required fields, limits, and supporting documents.
- Confirm funding and FX: check usable funds, quote expiry, and conversion responsibility.
- Set the completion standard: distinguish submitted, accepted, settled, and beneficiary-credited statuses.
- Assign exception ownership: identify who handles funding holds, compliance requests, returns, and bank investigations.
- Prevent duplicate release: use unique payment identifiers and investigate ambiguous statuses before retrying.
- Close the records: reconcile principal, fees, FX, and any returned funds to the original obligation.
Start by mapping one recurring payment route against these checkpoints. Payouts.com’s payout automation can form part of a unified money operation, but the operating principle remains the same: automate around verified events, not an ambiguous “sent” label.
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 Settlement Times by Country: Build Reliable Payment ETAs
An instant domestic rail does not make an international payout instant. Use this country reference and operating framework to set payment ETAs that account for funding, calendars, and recipient-bank availability.
ACH Wire Transfer Time: A Cutoff and Escalation Playbook
ACH and wires run on different clocks. Learn how to set release deadlines, identify where a payment is waiting, and decide whether an urgent replacement is safe.
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 explanation of how local payout networks work—receiving funds in one country and paying from destination balances—clears up why we sometimes see a domestic reference number on the recipient's end even though we initiated an international wire. That used to confuse our reconciliation process until we realized the provider was essentially breaking the transaction into two legs.
Same here. It took us a while to realize that when the recipient sees a local ACH or SEPA reference, the provider is just paying from a pre-funded account in that country. Now we match on our internal instruction ID instead of trying to chase down the downstream reference.
Same experience. Once we understood that the provider was paying from a pooled local account rather than routing our specific wire all the way through, it also explained why reconciling by transaction ID alone didn't work. We had to match on recipient details and amounts instead of tracking a single reference end-to-end.
The separation of compliance checks from validation is something our team didn't understand until a payment cleared initial screening but then got frozen at the intermediary bank for additional documentation. Now we track both separately in our payment log and flag high-risk corridors that tend to trigger secondary reviews even after our provider accepts the instruction.
We saw the same thing on payments to UAE. The article's point that passing the originating provider's checks doesn't prevent downstream holds is exactly what happened to us. Now we require purpose codes and invoice attachments upfront even when technically optional, just to reduce the chance of a freeze three days later.
The reminder that validation doesn't prove account ownership is critical. We've had two incidents where beneficiary details passed all format checks but the account name didn't match our vendor record—one turned out to be a compromised email requesting a change. Now we call the vendor directly on a known number before releasing anything over 10k if banking details have changed in the last 90 days.
We added a similar step after a near miss. The challenge is that some providers now offer account-name matching as a validation layer, but coverage is inconsistent across corridors. When it's available it catches most mismatches before funding, but you're right that a phone call is still the only reliable control for beneficiary changes.
We do the same callback verification now. The article's point about distinguishing validation from compliance checks is spot on—format checks happen at the provider level, but they can't confirm the relationship between beneficiary name and account ownership. That requires out-of-band verification on our side.
The staging table is helpful, but I wish more providers actually surfaced these discrete events in their APIs instead of lumping everything into a single opaque 'processing' status. Right now we're doing status polling every six hours and still can't tell if a payment is stuck at compliance review or waiting for recipient-bank credit.
We pushed our provider to add intermediate status codes last quarter and got 'kyc_review', 'funds_reserved', and 'awaiting_settlement' exposed as distinct states. Made a huge difference for our monthly close process when we can actually see where high-value payments sit.
We had the same frustration until we started requesting webhook events tied to specific reconciliation stages rather than relying on status polling. Not all providers support it, but the ones that do expose at least funding confirmation, FX execution, and settlement separately, which maps pretty well to the table in the article.
The BIS survey reference is interesting but the takeaway feels incomplete. Yes, payment-system access and operating hours matter, but the bigger friction we see is still compliance hold-ups and unpredictable intermediary fees that don't show up in the quoted rate. Fast rails don't fix opaque deductions.
Exactly. The article does mention that compliance checks can happen at multiple points and that intermediaries can request more info even after the originating provider approves, but it doesn't solve the opacity problem you're describing. We've started requiring full fee disclosure upfront in the contract, but enforcement is still hard when a correspondent two hops away takes a cut.
Agreed. The article does touch on this when it says 'passing the originating provider's checks does not prevent an intermediary or receiving bank from requesting more information,' but you're right that it doesn't quantify the problem. We've had payments delayed four days because an intermediary flagged a purpose code mismatch that didn't even exist in the original instruction.
The table breaking down instruction, validation, funding, FX, routing, and recipient credit is the clearest summary I've seen of why 'we sent the payment' and 'they received the money' aren't the same statement. We now require our AP team to log which stage a payment is in when a vendor calls asking where their funds are, and it's cut down the number of escalations to treasury by half.
We took a similar approach but also added the corridor to the log, since a UK payment might credit same day while something routed through two correspondents to South Africa can take three. Helps set expectations when the vendor follows up.
We did something similar but added expected settlement windows by corridor. Vendors in the UK usually clear same-day or next, but Mexico can take three business days even when the provider accepts the instruction immediately. Helps manage the 'where's my money' calls.
The section on local payout networks finally explains why some of our 'international' payments to contractors in Mexico settle same-day while others to the UK can take three days even though both are supposedly instant rails. It's not the destination speed, it's whether the provider already has liquidity sitting there.
Exactly. We see the same pattern with Brazil payments. When the provider has pre-funded BRL accounts there, settlement is faster than some of our domestic ACH runs. But if they're routing through correspondent banks it can still take two or three days plus we get hit with lift fees we didn't expect.
Right, and the article mentions that providers manage replenishment across their network separately from your individual payment. So you're basically benefiting from their treasury allocation strategy without seeing it. We've started asking providers explicitly whether they prefund in specific corridors before choosing a route.
The point about correspondent banks performing the actual account movements while SWIFT only handles messaging is critical, but I still see teams treating a SWIFT transmission timestamp as proof of payment completion when reconciling month-end accruals. We now require beneficiary bank credit confirmation for any material cross-border obligation before we close the books.
We implemented the same rule after our auditors flagged it twice. Now we only release accruals when we have either a credit confirmation from the beneficiary bank or documented acknowledgment from the vendor, whichever comes first. The SWIFT MT103 just proves we initiated, not that the obligation is settled.
Same. We switched to waiting for nostro confirmation or MT910 before releasing the accrual, which added 1-2 days to our close process but at least the auditors stopped questioning our cutoff treatment.
The distinction between fixed sending amount versus fixed receiving amount is something our AP team still gets wrong regularly. We've had three contractor disputes this quarter alone because someone keyed in the USD equivalent instead of locking the GBP amount the contract specified. Simple enough concept but surprisingly easy to miss when you're clearing 200+ invoices a week.
We built a sanity check into our payment workflow that flags any instruction where the send and receive amounts differ by more than 5% from the contract currency. Doesn't prevent everything, but it's caught enough mistakes that AP actually thanked us for it.
We added a mandatory dropdown in our ERP that forces users to choose 'sender currency' or 'beneficiary currency' before they can even enter the amount field. Doesn't prevent every error but at least makes people stop and think which number they're actually committing to.
"A pending deposit may appear in a dashboard without being usable for payouts" — learned this the hard way when we tried to fund a batch from an inbound wire that showed as received but wasn't yet cleared. Would be useful to know which providers actually distinguish between ledger balance and available balance in their API responses.
Same issue here. Our treasury system now shows 'credited' vs 'available' separately, but we had to request that feature after missing a same-day payout window twice. The provider-side distinction matters most when you're scheduling batches tight to collection timing.
We had the exact same problem. Now we just wait 24 hours after any inbound wire posts before using those funds for international batches, which obviously isn't ideal but at least we stopped getting failed funding errors midway through processing.
I appreciate the clarity on SWIFT's actual role. Too many people in finance still think SWIFT moves the money when it's just messaging infrastructure. That said, the article glosses over how opaque correspondent chains can be in practice—we've had payments stuck for days with zero visibility into which intermediary was holding things up, and our provider couldn't tell us either.
We started asking for MT103s as standard proof of transmission and routing, which at least gives us the correspondent chain on paper. Doesn't solve the delay problem but it helps when you need to chase a stuck payment with actual reference numbers instead of just a ticket ID from your provider.
We started asking for MT103s as standard proof of transmission and routing, which at least gives you the correspondent chain in writing. Still doesn't solve the visibility problem while the payment is in flight, but it helps with reconciliation when banks claim they never received it.