What Is a SWIFT Code (BIC)? Bank Details for International Payouts

A contractor sends an IBAN and a SWIFT code. Your payout provider also asks for a currency, beneficiary name and sometimes an intermediary bank. Those fields serve different purposes. Copying a plausible bank code into every routing field can turn correct account details into an instruction the receiving bank cannot use.

What the BIC identifies#

BIC means Business Identifier Code. SWIFT administers the registration of these identifiers under ISO 9362. Banks commonly call a BIC a SWIFT code, but the identifier is also used for other business parties. It is not a customer account number.

The base identifier has eight characters: a four-character business-party prefix, a two-letter country code and a two-character business-party suffix. An optional three-character branch identifier makes the complete code eleven characters. A nine- or ten-character value is not a valid alternative length.

Use the code given in the beneficiary bank’s receiving instructions. Do not invent a branch suffix or assume that the first code found in a search result is the one needed for this account. A bank can have more than one identifier or different instructions for different currencies.

BIC and IBAN checks solve different problems#

An IBAN contains a country prefix, check digits and the national account structure. Its length and structure depend on the country. Use the current SWIFT IBAN Registry to validate the relevant national format instead of imposing one country’s length on every recipient.

A checksum catches some transcription errors. It does not prove that an account exists, belongs to the named beneficiary or accepts the currency you plan to send. Likewise, a BIC format check cannot establish the directory status or actual payment connectivity of a bank.

Keep three separate checks: syntax, receiving instructions and beneficiary verification. Record which source supplied the instructions and when the beneficiary last approved them. Where your provider offers an account-name check, retain the result and its stated limitations rather than treating it as an unlimited ownership guarantee.

When you need a BIC and when you do not#

The route determines the customer-facing fields. The European Payments Council explains that eligible euro SEPA credit transfers and direct debits use the IBAN-only rule: customers do not need to supply the BIC. Payment service providers can still use bank identifiers internally. Do not add a mandatory customer BIC field to an otherwise eligible SEPA instruction just because international wires use one.

A non-SEPA international transfer may require a BIC, account number or IBAN, beneficiary address and further bank instructions. A domestic route may instead require a national routing code. Follow the provider’s requirements for the particular country, currency and product; a field named “bank code” in one integration may mean something different in another.

The second example does not become a SEPA transfer merely because the account has an IBAN. Nor should a provider silently convert the payout to EUR if the contract promises USD. Confirm the recipient currency and any conversion before approving the instruction.

Collect and approve receiving instructions#

• Ask the beneficiary for bank-issued receiving instructions for the intended currency.
• Match the beneficiary record to the account-holder details using the verification process appropriate to your payment program.
• Validate the account format and BIC against suitable reference data; investigate a mismatch rather than guessing a replacement.
• Confirm provider support for the bank, currency, legal payer and recipient type.
• Have an authorised person approve changed bank instructions through an established contact channel.

An email asking you to replace a bank account is a change request, not sufficient evidence of approval. Use a known contact method and retain the approval with a version of the bank details. The release process should bind the payout to that approved version so a later edit cannot silently change an already approved payment.

Do not require the BIC country to match every other country field as a universal rule. A beneficiary’s residence, bank-account country and permitted intermediary location may differ. Review the actual route and receiving instructions. Equally, a difference is not a reason to ignore restrictions applicable to your payer, provider or transaction.

Submit, trace and reconcile the payment#

SWIFT is a financial messaging network. Banks and other financial institutions perform the funds transfer and account credit. A message sent successfully is not the same event as money becoming available to the beneficiary.

Store a permanent payout obligation ID, the approved bank-details version, the provider payment ID and any trace reference the provider supplies. These records let operations ask about the exact transfer rather than initiate a replacement when a recipient reports a delay.

If submission times out, keep the obligation reserved while you query the provider or bank. A provider’s idempotency mechanism applies only within its documented scope and retention period. Reusing the same text as a key at another provider or on another rail does not prevent both transfers from completing.

Correcting a rejected BIC can justify a new attempt once the original attempt is known not to be able to complete. A cancellation request or an unanswered trace is not that confirmation. Record the terminal outcome, approve corrected details and then create the next attempt under the same business obligation.

Reconcile the bank debit, provider outcome, fees and beneficiary-credit evidence available for your route. Keep returned funds and unresolved transfers as explicit exceptions. Closing a support ticket or receiving an HTTP success response does not settle the recipient’s claim.

Keep the operator handoff useful#

For a failed payout, the handoff should contain the country and currency, approved account-details version, exact submitted routing fields, provider reference, raw rejection reason and the action already taken. Limit access to bank details and show support only the information needed to resolve the case.

Separate a data correction from a compliance decision. A valid BIC does not clear a sanctions restriction, and a tax-document issue does not become acceptable by switching rails. Apply only the release obligations relevant to the payer, provider and payment; do not turn unrelated tax or VAT checks into universal bank-code requirements.