What information is needed for an international wire transfer?

Most of the details come from the recipient. You need their full name and address, their account number or IBAN, and the SWIFT/BIC code, name and address of their bank. Add intermediary bank details only when the recipient's bank gives them. Add a payment reference, a purpose of payment when your bank asks for one, and choose who pays the charges: OUR, SHA or BEN. Copy each detail from the recipient's own bank details, not from memory. A wrong or missing detail can get the payment rejected, held while a bank checks it, or credited to the wrong account.

Give the sender your full name as your bank holds it, your address, your account number or IBAN, and your bank's SWIFT/BIC code, name and address. If your bank publishes its own instructions for incoming international payments, send those exactly as written, including any intermediary bank it lists for the currency. Your bank can confirm each detail.

No. An IBAN contains the domestic account details and adds two things in front: a two-letter country code and two check digits. In the example SWIFT's IBAN Registry gives for the United Kingdom, GB29 NWBK 6016 1331 9268 19, GB is the country code, 29 are the check digits, and the rest is the domestic part, called the BBAN: the bank code NWBK, the branch code 601613 and the account number 31926819. When the recipient's country uses IBANs, give the IBAN.

Only when the recipient's country uses IBANs. SWIFT, which ISO designated as the registration authority for national IBAN formats, lists every registered format in its ISO 13616 IBAN Registry. The United States is not in it, so a payment to a US account uses the account number and the bank's SWIFT/BIC code, plus a routing number when the recipient's bank gives one.

It is the Business Identifier Code defined by ISO 9362, and it identifies the recipient's bank in the payment. SWIFT issues BICs as the ISO registration authority. A BIC has 8 or 11 characters: a 4-character business party prefix, a 2-letter ISO country code, a 2-character business party suffix, and an optional 3-character branch identifier.

Give it when your bank's form asks for it. It also lets you check that the SWIFT/BIC code belongs to the bank you mean. For the ISO 20022 messages banks exchange under CBPR+, SWIFT says a beneficiary bank identified by its BIC needs no postal address. The recipient's own address, as a party to the payment, is still needed.

Only when the recipient's bank asks for them. An intermediary bank is a bank the payment must pass through between your bank and the recipient's bank. Some banks publish intermediary bank details for incoming payments in particular currencies. If the recipient sends them, copy them exactly. If not, leave the intermediary fields empty.

A short text that tells the recipient what the payment is for, such as an invoice number, so they can match it. ISO 20022 calls it remittance information. On an MT103-format record it is field 70, at most four lines of 35 characters, and it is meant for the recipient.

The reason for the payment, such as a salary or a purchase of goods. In a pacs.008 it has its own element, Purp, separate from the reference, and the message has another element for the information that regulatory and statutory requirements call for. Give a purpose when your bank asks for one. A bank can reject a payment whose purpose is missing or invalid, with reason code FF07, or whose regulatory reporting details are missing or invalid, with RR05.

It depends on the detail. A bank on the route can refuse the instruction, which a tracker reports as RJCT, usually with a reason code such as AC01 for an account number that is invalid or missing. A bank can report PDNG, pending, while it runs further checks, which can include a question to the sending bank. And if a wrong account number belongs to another valid account, the receiving bank may credit that account. RJCT is a report about the instruction, not a movement of money: any return of the funds travels as its own separate payment. Ask your sending bank for the reason code and what happens to the funds.

Give the name exactly as the recipient's bank holds it. When the name and the account do not match, the bank that holds the account can reject the payment with reason code BE01. Check the account number or IBAN just as carefully. In the EU, the Payment Services Directive treats a payment made to the unique identifier you gave, such as the IBAN, as correctly executed for the payee that identifier names (Directive (EU) 2015/2366, Article 88).

Not by the sender alone. Ask your sending bank at once to recall the payment, and quote its UETR. A recall asks the bank that holds the money to send it back. It is a request, not a reversal, and any money that comes back travels as its own separate payment. In the EU, when the unique identifier you gave, such as the IBAN, was wrong, your bank must make reasonable efforts to recover the funds and may charge for it if your contract says so (Article 88 of Directive (EU) 2015/2366).

Not on the date first planned. SWIFT had planned to remove unstructured addresses from CBPR+ payment messages in November 2026. On 27 August 2026 it deferred that change and said it will give an update on revised timing and approach by December 2026 at the latest. Keep the recipient's town and country in separate fields: they are the minimum of the CBPR+ structured and hybrid address formats, which banks can already use.

No. uetr.ai does not collect or check bank details. After the payment is sent, paste its UETR into uetr.ai to see what the banks have reported. The free check shows the plain-language status and how many banks have reported. Paid plans add the named banks that reported and the exact status code each one returned. If a bank rejected the payment, your sending bank can read the reason code that came with it.