A cross-border payment fails for one of two reasons: the sender skipped a mandatory field, or a bank along the route could not match that field to its database. Both errors cost time, recall fees and sometimes reputation with suppliers. The cure is a disciplined information checklist used before you press Send or sign off an API batch.
The universal core
Every corridor and provider will ask for the following, so start here:
- Beneficiary’s full name exactly as it appears on the bank account.
- Beneficiary’s address, usually down to street level (helps client-screening engines).
- Beneficiary account identifier — IBAN inside most of Europe, CLABE in Mexico, ACH routing plus account number in the United States, or a simple account number elsewhere.
- Bank name and branch address to satisfy “Know Your Correspondent” rules.
- SWIFT/BIC code for the beneficiary bank; think of it as the postcode that guides a payment through SWIFT’s network.
- Transfer currency and amount stated in ISO 4217 format (EUR, USD, JPY).
- Purpose of payment or “reason code” when required by the destination country’s central bank.
Country-level extras that often trip people up
- Routing transit number for Canada, IFSC for India, BSB for Australia, Sort Code for the UK, CNAPS for China, PIX key in Brazil’s real-time rail.
- National ID numbers for the beneficiary when sending to South Korea, Vietnam or Argentina.
- CNPJ/CPF tax IDs in Brazil or RFC in Mexico when goods cross borders.
- Local language beneficiary name (in Hangul or Kana, for example) if the receiving bank rejects Latin script.
Compliance and sender validation
Regulated institutions must know who is paying and why:
- Sender’s legal name, address and date of birth for personal accounts; company name and registration number for businesses.
- Originating account details if the payout does not come directly from the customer’s own bank.
- Invoice reference, contract number or shipment ID for trade-related transfers.
- Supporting documents—purchase orders, invoices, customs declarations—if the payment exceeds local reporting thresholds.
Keeping these items in a secure, searchable vault cuts audit stress and speeds up any future recall request.
Intermediary-bank data for tricky corridors
When your chosen provider does not have a direct clearing relationship, you may need:
- Correspondent bank’s SWIFT/BIC, name and address.
- Field 56 or 57 instructions in an MT103—often auto-filled by the platform but worth double-checking.
- Fees-sharing choice—SHA (shared), OUR (sender pays all) or BEN (beneficiary pays all)—plus an explicit debit account for OUR charges.
Operational details that keep finance sane
- Preferred value date or “execution date” to avoid landing funds on a weekend.
- Cut-off-time awareness; many banks close their FX books at 16:00 on the server’s local clock.
- Client memo or end-to-end ID that your ERP will use to reconcile incoming confirmations.
- Beneficiary notification email so suppliers know funds are on the way and can ship earlier.
One-page checklist to print or embed in your ERP
- Beneficiary name
- Beneficiary address
- Account identifier (IBAN / account number / local format)
- Beneficiary bank name and address
- SWIFT/BIC
- Local routing code (IFSC, CLABE, BSB, CNAPS, etc.)
- Transfer amount and ISO currency code
- Purpose of payment / reason code
- Sender identity details (name, address, tax ID)
- Invoice or contract reference
- Intermediary bank details (if any)
- Fees-sharing instruction (SHA / OUR / BEN)
- Preferred value date and cut-off confirmation
- Notification contacts
Populate this list once, store it in your vendor master file and surface it automatically each time someone raises a purchase order. Errors will plummet, and finance will spend fewer hours tracing missing wires.