Swift Code


Contents
A SWIFT code is the common name for a Business Identifier Code (BIC), which identifies a financial or other business party in payment messages. It has eight characters plus an optional three-character branch identifier. It does not identify the recipient's account or guarantee payment delivery.
What does a SWIFT code identify?
A SWIFT code identifies a business party in a financial instruction. To understand its role, separate the identifier from Swift's messaging network and from the recipient's account details.
SWIFT, BIC and the messaging network
“SWIFT code” is the familiar payment-form name for a Business Identifier Code, or BIC. The ISO 9362 identifier registered by Swift identifies a business party. That party is often a bank in a wire instruction, but a BIC can also identify a non-financial institution. The two labels refer to the same code in this context; neither says that a payment has been made.
Swift also operates a network that carries standardized financial messages between institutions. A BIC can identify a party in such a message, but holding a BIC and having access to the network are separate: Swift distinguishes connected BICs from non-connected BICs used for reference. The network carries payment instructions; the relevant banks and other institutions carry out the transfer and settlement. The message itself does not move or credit the funds.
For example, when paying a contractor by bank wire, the sender can enter the receiving bank's confirmed BIC in the bank-identifier field and enter the contractor's account identifier separately in the beneficiary-account field. The BIC identifies the business party named in the instruction; the account detail identifies where that contractor's payment is intended to be credited. The sender should use the receiving bank's instructions for that account and payment route, rather than treating a plausible BIC as a complete payment instruction.
The eight-character identifier and optional branch
A BIC has eight characters identifying the business party and may add three characters for a branch. In Swift's current structure, the first four characters are the business-party prefix, the next two are the country code, and the final two of the eight are the business-party suffix. The country code refers to the business party's country or geographical territory, not the payee's account. The suffix is not a guaranteed city or physical-location code.
Take the fictional ABCDGB2A123 as a reading example, not as payment details. ABCD is the business-party prefix, GB the country code, and 2A the business-party suffix. Those first eight characters form the BIC8 portion; 123 illustrates the optional three-character branch identifier. A branch identifier can distinguish a location, department, service or unit of the same business party, so an eleven-character BIC need not point to a separate physical branch.
An eight-character BIC may also appear with XXX appended as an eleven-character form. XXX alone does not establish that the destination is a head office. If a payment form asks for eleven characters, follow the receiving bank's current instructions for the account and route. Do not replace a distinct three-character suffix supplied by the bank with XXX, or invent one to make the field fit.
What the code cannot tell you
A string with the right length and character pattern could be a BIC; its shape alone does not confirm that it is registered. Even a registered BIC for the receiving bank does not identify the contractor's account or verify who owns it. An IBAN identifies an individual account, while a BIC identifies a business party. Depending on the route, a payment instruction may need both or may use a different account identifier.
A format check, or a directory listing that does not state network status, cannot establish Swift connectivity. Swift distinguishes connected BICs from non-connected BICs, and neither status establishes that a particular route will accept and credit the instruction. If a supplier invoice lists a bank BIC but no account identifier, ask for the missing receiving-account instructions before sending. Selecting a plausible bank code cannot fill that gap.
When is a SWIFT code needed?
The payment route and provider's form determine whether the sender must supply a BIC. A transfer crossing a border does not, by itself, settle which bank and account identifiers the form will require.
Cross-border wires and domestic bank codes
An international bank-wire form may ask for the receiving institution's SWIFT/BIC alongside the beneficiary's account details. The recipient obtains the code from its bank's current incoming-payment instructions; the sender enters it where the chosen wire provider asks for the bank identifier. In Bank of America's U.S. wire forms, for example, the domestic-wire fields include an ABA wire routing number and account number, while its international-wire instructions ask for bank information including a SWIFT code and account number. Those are that bank's form requirements, not a rule for every payment provider or destination.
The identifiers belong to different payment systems. An ABA wire routing number identifies a bank for a U.S. domestic wire; a UK sort code is used in routing payments through UK payment systems. Neither should be copied into a BIC field or assumed to replace a BIC on every international route. A U.S. company paying a contractor's U.S. account by domestic wire would follow the domestic form and use the receiving bank's wire routing number. If it instead selects an international wire to a contractor's UK bank, the sender checks that provider's required fields and the UK bank's incoming-wire instructions, which may include a BIC. The first decision is the payment route; the code follows from it.
IBAN, SWIFT/BIC and SEPA payments
An IBAN identifies an individual account in countries that use that standard; a BIC identifies a business party such as the receiving bank. One cannot be substituted for the other when a payment form asks for both. Some international-wire routes request a BIC and an IBAN or other account number, so possession of an IBAN alone does not answer whether the selected route needs a BIC.
For eligible euro credit transfers and direct debits in the Single Euro Payments Area (SEPA), the customer-facing rule is more specific. The European Payments Council's IBAN-only rule says consumers and corporates making those payments are no longer asked to supply the payer's or payee's BIC; the IBAN is sufficient for that customer input. Payment service providers may derive a BIC for processing. The rule does not determine what a non-SEPA wire, a non-euro payment or an interbank route requires.
For example, a company paying a contractor in euros can enter the contractor's IBAN without obtaining a BIC when its provider offers an eligible SEPA credit-transfer route. If the company instead selects an international-wire route, that provider may ask for both the receiving-bank BIC and the account details. Check the route offered and its fields before requesting another code from the contractor.

Caption: The provider's route controls the fields. IBAN-only applies to eligible customer-facing euro credit transfers or direct debits in SEPA; it does not rule out BIC in processing or other wires. US wire routing numbers and UK sort codes are local examples. European Payments Council, IBAN and BIC in SEPA · Bank of America, Wire Transfers · Pay.UK, Sort Code Information
Other payment routes and bank-specific requirements
If a provider's form does not ask for a BIC, first confirm the route it is offering rather than adding a code from a directory. The absence of a separate branch code is a different question: a BIC's three-character branch element is optional, so an instruction need not use a distinct suffix for every branch. That does not establish which identifier a particular account should use. Follow the receiving bank's current account instructions and the sending provider's fields.
A BIC field may also be only part of the required information. For its own international-wire service, Bank of America lists destination-dependent identifiers, including Canada's Transit Code or India's IFSC for bank details and an IBAN or Mexico's CLABE for account details. A bank code cannot stand in for every local or account identifier, and these examples are not a checklist for all destinations. When a form is unfamiliar, ask the sending bank which payment route and fields it will use, then obtain the receiving bank's instructions for that account. Enter the BIC only when the route calls for it, using the exact code the bank confirms.
How do you find and verify the right code?
Start with current instructions for the recipient's actual account, then check that the code fits the currency and payment route the sender will use. A bank-name match alone does not choose a payment-ready BIC.
Start with the receiving account's current instructions
Ask the recipient for the BIC in their bank's authenticated account details or official incoming-payment instructions. If those details are unclear, the account holder can ask the receiving bank to confirm the code for that account and intended payment. For example, Bank of America directs customers to select their actual receiving account in online or mobile banking to view incoming-wire details. Its published instructions also vary by currency, showing why a bank name alone cannot settle the choice.
An invoice, an old statement or a public code finder may provide a candidate, but none necessarily states the bank's current instructions for that account and route. A directory can help check the institution behind a BIC; it cannot by itself confirm that the chosen code is the one to enter in this payment form. If the invoice, directory and bank app disagree, pause and have the recipient confirm current incoming instructions with the bank. Then compare those instructions with the sender's provider form rather than selecting the most familiar-looking listing.
Match the bank, branch, currency and route
When several BICs appear under one bank's name, match the receiving institution and country first, then the instructions for the actual account, branch or service, payment currency and chosen wire route. A shared bank prefix, a directory's city label or an XXX suffix cannot resolve those conditions. The receiving bank may specify a code and address for one type of incoming payment and different details for another; the sender should transfer the complete matching instruction into the provider's form.
A current, bank-specific example makes the choice concrete. Bank of America's U.S. incoming-wire instructions, checked 7 October 2026, give BOFAUS3N for U.S.-dollar wires or wires whose currency is unknown, and BOFAUS6S for foreign-currency wires. The page lists different receiving-bank addresses for those two cases. Both codes can look like plausible matches for the same bank, yet its published currency instructions distinguish them. They are Bank of America instructions, not templates for another recipient bank. Obtain the recipient bank's current instructions for the account and currency; for a Bank of America account, confirm the current code and address before sending.

Caption: Bank of America US incoming wires, checked 7 October 2026: BOFAUS3N for US dollars or unknown currency; BOFAUS6S for foreign currency. Confirm the receiving account's current code and address; do not use these codes for another bank. Bank of America, Receiving Wire Transfers
Check directory status without assuming reachability
A code that passes an eight- or eleven-character format check has only passed a syntax check. A registered BIC is a further fact; Swift network access and acceptance of a payment on a particular route are further questions still. Swift distinguishes connected from non-connected BICs, including non-connected codes valid for reference. Even a connected listing cannot establish that the recipient account exists, that the chosen route will accept the instruction or that the funds will be credited. Use a directory to inspect the identifier and any status it provides, then confirm payment instructions with the banks involved.
One directory needs especially careful handling. The European Payments Council's Register of Participants lists reference BICs that identify participants in its schemes; the EPC says these must not be relied on as valid routing BICs. Participants provide routing BICs to their chosen clearing and settlement mechanisms separately. A finance operator who finds an institution in that register should obtain the receiving bank's and sending provider's routing instructions before filling a payment field. This warning concerns the EPC participant register and its schemes, not every public BIC directory or every customer-facing form.
A previously used BIC may still be correct, but past success does not confirm the current account and route. Swift's BIC records include a last-update date and an expiry date where applicable; bank instructions can also change. Before reusing a saved beneficiary template, compare its code with the receiving bank's current instructions, especially after a change in bank or account details, and confirm that the sending provider still accepts the route. An expiry field does not mean every BIC expires.
What if the code is missing or wrong?
The next step depends on whether the payment has been sent. Before release, resolve the provider's required fields against the receiving account's instructions; after release, ask the sending bank or provider to investigate the payment's status.
Before sending: resolve missing or inconsistent details
If the form asks for a BIC that the recipient has not supplied, first check which payment route the provider is offering. For an eligible euro credit transfer in SEPA, the EPC's customer-facing IBAN-only rule means the payer need not supply a BIC when the provider offers that route and accepts the beneficiary's IBAN. A separate international-wire form may still require the receiving-bank BIC. Switching forms without checking route eligibility and fields does not resolve the missing instruction.
For a wire that requires a BIC, ask the recipient to obtain current incoming-payment instructions from the bank for that account, currency and any relevant branch or service. If an invoice, bank app and directory disagree, pause the instruction and have the account holder confirm the correct details with the receiving bank; the sending bank can clarify the fields for its selected route. Do not choose a nearby branch code, append XXX merely to fill eleven characters or use the first directory match. A plausible-looking BIC cannot replace the receiving bank's actual payment instructions.
After sending: ask the sending bank to investigate
If you notice a wrong BIC after releasing the payment, contact the sending bank or provider immediately. The result depends on the route and institutions: HSBC's international-transfer guidance describes possible delay, rejection or return when beneficiary bank information is incorrect, while Swift's IBAN Plus guidance notes that an incorrect BIC in that SEPA data context may cause misrouting or return. None of those outcomes is inevitable for a particular payment.
Give the sending bank the payment reference and the receiving bank's corrected instructions. Ask what status it can confirm and whether an amendment, cancellation or recall request is available for this transfer. Those options and any recovery depend on the payment's status and the institutions involved; do not assume the bank can reverse or recover it. Check the first payment's status before issuing a replacement so you do not create a duplicate. For the broader route, tracking and recall process, see how SWIFT transfers work.
What information accompanies a SWIFT code?
A BIC is only the business-party identifier in a payment instruction. Depending on the bank, destination and route, the sender may also need the beneficiary's name, account number or IBAN, the receiving bank's name or address, and a local bank or account identifier requested by the provider. These fields answer different questions: the BIC names the business party, while the account detail identifies the account intended to receive the funds. Bank of America's international-wire guidance, for example, asks separately for recipient details, bank information including a SWIFT code and an account number; it notes that some destinations need further identifiers. That is one bank's form, not a complete checklist for every payment.
If a contractor invoice supplies a BIC but omits the account identifier, ask the recipient for the receiving bank's current incoming instructions for that account and currency before submitting the payment. Compare those instructions with the sending provider's fields, including any bank address or local code it requests. A matching BIC cannot fill a missing beneficiary-account field or determine which route the provider will use.
The BIC is an identifier, not a payment service or fee. Any transfer charge, intermediary charge or foreign-exchange cost comes from the chosen service and its terms, which can depend on the route and currency. Check the provider's current quote separately from the bank-code details; do not assume that using or looking up a code is universally free. For the broader payment route, charges and tracking, see how SWIFT transfers work.