Cross-Border Payment Reconciliation — What Nobody Tells You

The Core Problem

In domestic payments, reconciliation is a matching exercise. You sent $100, the bank received $100, the merchant got $97 after fees. Three numbers, one currency, same-day settlement. Done.

Cross-border payments break every one of those assumptions. You send SGD 1,000 to a supplier in Indonesia. By the time it arrives as IDR, the amount has been touched by your bank, a correspondent bank (maybe two), the beneficiary's bank, and an FX conversion somewhere in the chain. Each one takes a cut, and the FX rate used might differ from what you quoted the customer.

Reconciling this means answering: did the right amount arrive, in the right currency, to the right account, within the expected timeframe? And if not, where did the money go?

The Five Reconciliation Headaches

1. FX Rate Mismatches

This is the most common source of reconciliation breaks. You quote a customer an FX rate at 10:00 AM. The payment doesn't settle until 3:00 PM — or the next day. The rate your bank actually uses might differ from what you quoted.

The fix is to separate your customer-facing rate from the execution rate. Lock the customer rate at quote time, execute at market rate, and track the spread as revenue or cost. Your reconciliation then checks three things: the quoted rate, the executed rate, and the resulting P&L on the spread.

2. Correspondent Bank Fees

SWIFT payments can be sent with three fee instructions: OUR (sender pays all fees), BEN (beneficiary pays), or SHA (shared). In practice, even with OUR, correspondent banks sometimes deduct fees anyway. Your beneficiary receives less than expected, and the deduction shows up as a cryptic line in the MT940 statement days later.

Build your reconciliation to expect fee deductions even when they shouldn't happen. Store the expected amount, the actual received amount, and the difference. Flag anything beyond your tolerance threshold (I use 0.5% for SWIFT payments) for manual review.

3. Settlement Timing Gaps

Domestic bank transfers settle same-day or next-day. Cross-border payments can take 1-5 business days depending on the corridor, the banks involved, and whether compliance checks flag the transaction. Your system shows "sent" but the beneficiary's bank hasn't credited yet. Is it delayed, stuck in compliance, or lost?

The answer is usually "delayed," but you won't know for sure without tracking expected settlement windows per corridor. SGD to USD via SWIFT? Expect T+1. SGD to IDR via a local payment rail? Could be T+0 same day. SGD to NGN? Budget for T+3 minimum and don't panic until T+5.

4. Reference Number Fragmentation

Every participant in the payment chain generates their own reference number. Your system has a transaction ID. Your bank assigns a SWIFT UETR. The correspondent bank has an internal reference. The beneficiary bank has yet another. Matching these across systems is the grunt work of reconciliation.

5. Multi-Currency Ledger Complexity

If you're operating a payment platform, you likely hold balances in multiple currencies. Each cross-border payment touches at least two currency ledgers. Your reconciliation needs to verify both sides: the debit in the source currency and the credit in the destination currency, at the correct FX rate, with fees accounted for.

Building a Reconciliation Pipeline

After getting burned enough times, I settled on a three-stage pipeline that handles most cross-border reconciliation scenarios.

Stage 1: Ingest and Normalize

Banks send you data in different formats. Some give you MT940 SWIFT statements, some give CSVs, some have APIs. Your first job is to normalize everything into a common schema: transaction ID, date, amount, currency, counterparty, reference, and status.

// Normalized transaction record
{
  "internal_ref": "TXN-2026-04-001234",
  "bank_ref": "SWIFT-UETR-abc123",
  "date_initiated": "2026-04-01T10:00:00Z",
  "date_settled": null,
  "source_amount": 1000.00,
  "source_currency": "SGD",
  "dest_amount": 11450000,
  "dest_currency": "IDR",
  "quoted_rate": 11500.00,
  "executed_rate": 11450.00,
  "fees": 25.00,
  "fee_currency": "SGD",
  "status": "pending_settlement"
}

Stage 2: Match and Classify

Run matching in layers. First, try exact match on your internal reference — this catches 70-80% of transactions. Then fuzzy match on amount + date + counterparty for the rest. Anything left unmatched goes into an exception queue.

For cross-border specifically, your matching needs tolerance bands. A payment of SGD 1,000 might arrive as IDR 11,425,000 instead of the expected IDR 11,450,000 because a correspondent bank took a $2 fee. Your matcher needs to know that's a fee deduction, not a missing payment.

Stage 3: Resolve and Report

Auto-resolve breaks within your tolerance threshold. Generate a daily report showing: total transactions, matched count, exception count, total value of exceptions, and aging of unresolved items. The aging report is critical — a 1-day-old unmatched payment is normal, a 5-day-old one needs investigation.

Practical Tips from Production

1. Reconcile daily, not monthly. Monthly reconciliation in cross-border payments is a recipe for disaster. By the time you find a problem, the trail is cold and the correspondent bank's support team has moved on.
2. Build corridor-specific rules. SGD→USD behaves differently from SGD→PHP. Settlement times, fee structures, and common failure modes vary by corridor. Your recon engine should know this.
3. Track the SWIFT gpi UETR. If your bank supports SWIFT gpi, use the Universal End-to-End Transaction Reference to track payments through the correspondent chain. It's the closest thing to a tracking number for international wires.
4. Automate MT940 parsing early. Manual statement reconciliation doesn't scale past 50 transactions per day. Invest in automated parsing and matching before you need it.
5. Keep a fee database. Track actual fees charged per corridor, per bank, over time. This data is gold for pricing decisions and for setting accurate tolerance thresholds in your matcher.

When to Build vs. Buy

If you're processing fewer than 1,000 cross-border transactions per month, a spreadsheet-based reconciliation with some scripting might be enough. Between 1,000 and 10,000, you need a proper pipeline but can build it in-house with PostgreSQL and a few cron jobs. Above 10,000, seriously evaluate dedicated reconciliation platforms like ReconArt, Duco, or Xero's multi-currency features.

I've built reconciliation systems at two different scales, and the lesson is always the same: start simple, automate the matching, and invest in exception handling. The matching logic is the easy part. The hard part is what happens when things don't match — and in cross-border payments, things frequently don't match.

References

• SWIFT — ISO 20022 Migration and Standards
• SWIFT gpi — Global Payments Innovation
• BIS — Correspondent Banking
• FATF Recommendations — International Standards on AML/CFT
• Open Banking Standards — UK Open Banking Implementation Entity

Disclaimer: This article reflects the author's personal experience and opinions. Settlement times, fee structures, and banking processes vary by institution and jurisdiction. Always verify with your banking partners for corridor-specific details.