Bank Codes

What does a bank code identify?

A bank code points to an institution or routing unit within a particular payment system. It does not, by itself, identify the account to credit. To choose the right code, start with the destination and payment route.

Bank, branch, account, and payment route are different layers

An institution or branch identifier tells a payment system where to direct an instruction. The beneficiary's account identifier tells the receiving provider which account the payment is for. For example, an applicable UK domestic bank payment uses a sort code alongside an account number. If an invoice gives the sort code but omits the account number, the payer still lacks the account detail; copying the sort code into the account-number field cannot supply it.

These layers can appear as separate fields or inside a longer identifier. A BIC identifies a business party for financial messaging and may include a branch identifier, but it is not a customer account number. An IBAN is an account identifier built to a country's registered format: its country code and check digits precede a Basic Bank Account Number (BBAN), whose national structure can include a bank or branch field. The bank field inside an IBAN does not turn the complete IBAN into a bank-only code. Mexico's CLABE offers another pattern: its 18 digits include a bank code, a place code, an account field and a check digit. Supplying its three-digit bank component where a form asks for the full CLABE would leave out the account details. See Swift's IBAN standard and registry and Banco de México's CLABE explanation for those national structures.

The route matters even when the code looks right. A directory listing does not establish that the receiving provider accepts the chosen payment rail. Nor does a BIC's format or listing establish that the recipient's account exists; an IBAN's valid structure does not establish that the named payee owns it. Format, directory, rail and payee-name checks answer separate questions where available. Use the form's field labels and current receiving instructions to distinguish a BIC, a domestic code, an account number and a complete IBAN or CLABE.

Country and payment route decide which field to supply

The country determines which identifiers may exist. The payment route and provider's form determine which ones to enter. Check the destination, currency and named payment system against the recipient bank's current instructions. A national code, an account identifier and a BIC belong in different fields even when they refer to the same receiving institution.

For a US ACH payment, the sender needs the recipient's account number and bank-issued routing instructions for ACH. A US wire may call for its own routing instructions: the Federal Reserve maintains separate FedACH and Fedwire participant directories, so a nine-digit number's appearance or format alone cannot establish its use for both. For an applicable UK Faster Payment, the recipient supplies a sort code and account number. The sort code's listed support for Faster Payments, Bacs or CHAPS does not by itself confirm that a particular account can receive the selected payment; the provider confirms the available service.

A cross-border bank form may instead request a complete BIC and the beneficiary's account identifier, along with further details in the bank's instructions. A national routing code or a piece of an IBAN cannot fill its BIC field. Regional scheme rules can change the combination: for SEPA euro credit transfers and direct debits covered by the IBAN-only rule, the payer supplies the issued IBAN without being asked for the payee's BIC. Neither that regional rule nor a cross-border form's BIC field defines a universal set of fields for all international payments.

How do BIC and IBAN fit into a cross-border payment?

A BIC identifies a party involved in bank messaging; an IBAN, where a country issues one, identifies an account. The payment route and receiving bank's instructions determine which values a cross-border form requests.

A BIC identifies a business party for bank messaging

BIC stands for Business Identifier Code. Payment forms often label it a “SWIFT code,” but BIC is the identifier's formal name. Under Swift's BIC standard, it can identify a financial or non-financial business party for messaging and routing. In a bank transfer instruction, it points to a party the payment message must address; it does not name the beneficiary's customer account.

Read the entire value supplied in the receiving instructions. An eight-character BIC starts with a four-character business party prefix, followed by a two-letter country code and a two-character business party suffix. It may have a further three-character branch identifier, making eleven characters in that case. The prefix alone is neither a full BIC nor a domestic routing code. If the bank issues an eleven-character BIC, keep its branch component rather than shortening the value or replacing its suffix with XXX to make it look more familiar. The sending provider can confirm which value its route accepts.

A BIC can be registered as connected or non-connected to the Swift network. A value with the right shape, or a listing for that business party, therefore does not establish network access for the intended route. It also does not verify the beneficiary account or show that an assumed branch is the right one. Use the current BIC in the recipient's bank-issued instructions, and ask the sending bank about any unresolved route or branch question.

An IBAN identifies an account under a national format

An International Bank Account Number (IBAN) identifies an account using a format registered for its country. It begins with a country code and check digits, followed by the Basic Bank Account Number (BBAN), whose fields follow that country's rules. A BIC identifies a business party; a standalone local bank code identifies one part of domestic routing; neither is the complete account identifier requested in an IBAN field. Swift's IBAN registry records the national formats rather than one universal arrangement of bank and account digits.

In a German IBAN, the BBAN includes an eight-digit bank identifier (BLZ) followed by a ten-digit account field. A GB IBAN contains a sort-code field. France's RIB account details separate a five-digit bank code, a five-digit branch code, an account number and a RIB key, alongside the issued IBAN. Each local code is one piece of the relevant national account details; it does not fill a form asking for the complete IBAN.

If a euro payment form requests an IBAN, copy the recipient's full bank-issued value, rather than entering a BLZ or assembling an IBAN from the parts you recognize. Nor should a payer invent a US or New Zealand IBAN from domestic account details: only countries with a registered IBAN format issue one. A format or check-digit result can test the number's structure, but it cannot establish that the account is active or belongs to the named recipient.

A route may require both identifiers or a different combination

The payment scheme and receiving bank's instructions determine whether an international form asks for a BIC, an IBAN, both or another combination. For a euro credit transfer covered by the SEPA IBAN-only rule, the payer enters the complete issued IBAN without supplying the payee's BIC. That rule is specific to the covered SEPA schemes; it cannot be copied into a different cross-border form.

An incoming US international wire offers a different, bank-specific example. Wells Fargo's receiving instructions tell its customer to give the international sender the bank's SWIFT/BIC, name and address, plus the customer's complete account number, account name and address. Its domestic-wire instructions specify a wire ABA routing number instead of the SWIFT/BIC. Chase likewise says it does not use an IBAN for incoming wires and asks international senders for its SWIFT/BIC and the customer's account number. These are instructions for those banks, not a required field list for every US recipient; a payer should use the actual recipient bank's current version.

Intermediary details are a separate route question. Wells Fargo says its SWIFT/BIC routing generally works without them. For some incoming foreign-currency wires, its currency-specific instructions supply intermediary-bank details when the sender's platform has an intermediary-routing field; otherwise the sending bank determines the route. The payer should follow the current receiving instructions and the sender's form, rather than inventing an intermediary from a BIC. An applicable UK domestic account-based payment illustrates another combination: sort code and account number, with receipt on the chosen UK payment system confirmed by the provider.

Compare the fields for the chosen route with the recipient bank's instructions. A complete BIC or well-formed IBAN answers an identification or format question; neither value alone establishes the full route or guarantees credit to the intended account. Ask the sending provider to resolve a mismatch between its form and the receiving instructions before submitting the payment. For the message path beyond field selection, see how Swift transfers work.

Which local codes are used for common domestic routes?

For domestic payments, the institution or branch code and the account detail often occupy separate fields. Their names and combinations change by country and payment system; use the recipient's details issued for the selected route.

United States — ABA routing number and account number

An ABA routing transit number (RTN) is a nine-digit identifier assigned to a US financial institution. It identifies the receiving institution for a payment system, while a separate account number identifies the beneficiary's account. The same nine-digit shape does not tell the sender whether a number is appropriate for an ACH payout, a Fedwire transfer or another bank instruction. The Federal Reserve's routing directory maintains FedACH and Fedwire participant information separately.

For a contractor payout by ACH, request the recipient's bank-issued ACH routing details and account number, then enter each in the matching field. For a wire, request the bank's wire instructions instead of copying a number from a check image or a generic search result. Those sources may show a real institution code without establishing that it is the one issued for the selected rail. Separate FedACH and Fedwire records also do not prove that every bank assigns different routing numbers to the two routes; the receiving bank's instructions settle the choice for that account and payment.

United Kingdom — sort code and account number

For an applicable UK domestic account payment, the recipient supplies a six-digit sort code and a separate account number. Pay.UK describes sort codes as routing identifiers allocated to payment service providers and registered for use in payment systems. The sort code directs the payment toward the provider's routing unit; the account number identifies the beneficiary account within the issued details. A valid-looking sort code alone therefore cannot complete the payment instruction.

Pay.UK's sort-code checker shows separate indications for receiving Faster Payments, Bacs Direct Credits and CHAPS. Those indications reflect directory-level support, not a guarantee that a particular account can receive the payment. Only the provider can confirm the service available for that account and payment. If the payment must use a particular scheme or meet a deadline, check the current scheme information and confirm uncertain account-level availability with the provider before sending.

A GB IBAN contains a sort-code field, but the complete IBAN also includes its country code, check digits and other nationally specified account fields. Enter the issued full IBAN when a form requests an IBAN; enter the bank-issued sort code and account number when the applicable domestic form asks for those fields. Extracting one field from the IBAN does not make it interchangeable with the whole account identifier.

Germany and France — local bank fields inside issued IBANs

In Germany, the national part of a DE IBAN contains an eight-digit bank identifier, the Bankleitzahl (BLZ), followed by a ten-digit account field. The BLZ identifies the bank within those account details; it is only one component of the complete IBAN. For a payment form requesting an IBAN, use the recipient's full bank-issued number rather than entering the BLZ or assembling a number from the visible parts. Swift's IBAN registry records this country-specific structure.

The Deutsche Bundesbank's bank-sort-code files distinguish the current and next validity periods and include deletion and successor information. A code shown for a future period is not automatically today's instruction. A saved BLZ from old instructions may need checking against the recipient bank's current IBAN; a deleted directory record does not always mean that the BLZ itself was deleted. If old and new details differ, ask the recipient or bank for the current issued instructions rather than substituting a successor code into an IBAN yourself.

France separates its local account details differently. A French RIB lists a five-digit code banque, a five-digit code guichet for the branch, an eleven-character account number and a two-digit RIB key, as well as the complete IBAN and BIC. The two local codes can help a payer distinguish bank and branch fields when comparing issued details; neither can fill an IBAN field. For an eligible SEPA euro payment, enter the complete issued IBAN, and treat a mismatch between listed components and current instructions as a reason to confirm the details before sending.

Other national patterns — which code belongs to which field?

“Bank code” may mean a separate institution or branch field, one component of a longer account identifier, or a detail the chosen route does not ask the payer to enter. These examples show where each code belongs in the issued details.

Canada, Australia, and New Zealand

For a Canadian wire, Payments Canada's guidance separates a three-digit financial-institution number, a five-digit branch transit number and the beneficiary account number. A sender should obtain all applicable fields from the recipient's bank and ask the sending institution which format its wire form expects. The institution and transit numbers identify routing information; neither can take the place of the beneficiary account number. This is wire guidance, not a field list for every Canadian payment.

Australia uses a six-digit BSB code, commonly displayed as XXX-XXX, for institution and branch routing. If an Australian payout form asks for a BSB, enter the recipient's bank-issued BSB and separate account details. AusPayNet's BSB lookup is updated monthly and shows payment-stream indicators, but it does not verify the individual account. Its real-time-payment indicator has a further limit: an unflagged BSB does not by itself show that the destination is unreachable on the New Payments Platform. The provider's current receiving instructions govern the payout.

In New Zealand, the first two digits of a domestic account number identify the bank and the next four identify the branch. Payments NZ also publishes a bank-branch register with a separate National Clearing Code field. A payer needs the recipient's full issued account details and should follow the sending form's labels; the local bank/branch segments alone are incomplete. Do not convert them into an invented IBAN or assume a generic field called “NZ BSB” is the official instruction.

Mexico and Brazil

Mexico's CLABE is a complete 18-digit account identifier, not just its institution code. Banco de México breaks it into a three-digit bank code, three-digit place code, eleven-digit account field and one check digit. For a SPEI payment, the beneficiary's full CLABE is one account identifier a payer may use. If the chosen form asks for CLABE, enter the recipient's complete issued value; a three-digit bank number cannot fill that field. Other beneficiary identifiers may be available for SPEI, so CLABE is not required for every such payment. Its check digit tests structure, not whether the number belongs to the intended payee.

For a Brazilian account-detail transfer, the payer may need the recipient's agency, account and other identifying details; a Pix key can instead identify the receiving account without manual entry of agency and account fields. Banco Central do Brasil's Pix guidance describes this distinction. Pix can also be initiated by QR code or account details, so the presence or absence of a separate bank-code box depends on the provider's chosen flow. A key is not proof that the named recipient is legitimate; use the current route-specific instructions rather than a generic bank-number list.

India, Hong Kong, and Japan

For India's RTGS system, the Reserve Bank of India's instructions ask for the receiving branch's IFSC and the beneficiary account number. Both sending and receiving branches must be enabled for RTGS. The IFSC supplies a branch and route detail, while the account number identifies the beneficiary account.

MICR serves a different function. The RBI describes India's nine-digit MICR code on a cheque's MICR band, and NPCI explains that MICR-line data accompanies the electronic cheque image in the Cheque Truncation System. The MICR number neither replaces the beneficiary account nor belongs in an RTGS field asking for IFSC. This RTGS distinction should not be generalized into a rule for every Indian payment system.

In Hong Kong, HKICL publishes dated clearing-code and branch-code lists. The list helps identify a current candidate code, but a bank-name match does not establish the code issued for the particular recipient or whether a chosen payment route uses both fields. Confirm the receiving details with the recipient's bank instead of selecting a code from a name search alone.

For an applicable Japanese domestic transfer through the Zengin system, the destination details include a four-digit financial-institution code, a three-digit branch or store code and a separate account number. Zengin-Net's field diagram and Japan Post Bank's transfer specification distinguish those fields. An institution code without branch and account details cannot identify the beneficiary; obtain the bank-issued account type and name fields as the chosen form requires. This domestic pattern is not a universal checklist for an international wire to Japan.

How can you find and verify the right bank code?

Start with the recipient's issued details for this payment. A format test, directory entry, payment-system listing and any available payee-name result each answer a narrower question. Passing one check does not establish that the intended account will receive the payment.

Start with the recipient bank's current issued instructions

For a payment into your own account, use receiving details your bank currently provides through an authenticated channel or statement, and ask the bank if they do not specify the route you need. For someone else's account, ask the intended recipient for the bank-issued receiving instructions. Compare them with the destination, currency, payment system and field labels in the sender's form before copying a code. A domestic payout and a cross-border wire may call for different details even when they go to the same bank.

A public directory can identify an institution or payment-system listing. It cannot identify the beneficiary's account, establish who owns it, or supply the bank's instructions for the selected currency and any conditional intermediary route. Use the recipient's issued account details and ask the sending provider to confirm the route; a bank-name match in a code list cannot answer either question.

Suppose a contractor sends a BIC but no account identifier. The BIC identifies a party for bank messaging, so the payer still needs the complete account details and any other fields required by the chosen payment form. Ask the contractor for the bank's current instructions through a trusted contact method before creating the payment. Do not fill an account-number or IBAN field with a BIC or a plausible value from a lookup.

Check format, current directory entry, and rail availability separately

A format check may catch a mistyped BIC or an IBAN that fails its country format or check digits. Passing says nothing about whether a BIC is connected to the relevant messaging network, whether an IBAN account is active, or whether the named recipient owns it. A directory check establishes whether the code appears in a current authoritative record; it still does not establish whether the selected payment system can receive this particular payment.

Check the rail separately. The Federal Reserve keeps FedACH and Fedwire participant information in separate searches; a US routing number's nine-digit shape cannot confirm participation in both. In the UK, Pay.UK's sort-code checker indicates receipt through Faster Payments, Bacs Direct Credits and CHAPS separately. Its listing does not confirm service for an individual account, which only the provider can confirm. Ask the sending or receiving provider about the actual route rather than treating a generic code lookup as approval to send.

The date of a directory record matters. The Bundesbank distinguishes currently valid and future-period BLZ files, including deletion and successor information. Australia's BSB lookup and New Zealand's bank-branch register are updated monthly, while Hong Kong's clearing and branch-code lists are dated. These records can help identify a current code, but their update dates and listings do not establish the beneficiary account or replace the receiving bank's issued details.

If a saved supplier code has the right format but comes from an old record, compare it with the recipient's current instructions before the next payout. Ask the sending provider to confirm the selected rail if a directory lists several possibilities or the receiving details do not match the form. Do not change a code or reconstruct an account identifier merely to make a validator accept it.

Treat a payee-name check as a different signal

Even when the code and account identifier have the expected format, they do not establish that the account details match the person or business you intend to pay. For covered EU euro credit transfers, Verification of Payee separately compares the payment-account identifier with the intended payee's name before initiation. The ECB describes this for standard and instant credit transfers, with results of match, close match, no match or other. Its availability follows the applicable EU provider and timetable; it is not a name check for every European or international payment.

For covered UK domestic payments, Confirmation of Payee can compare the name entered for a new or amended payee with account details such as sort code and account number. A participating provider may offer it with Faster Payments, Bacs or CHAPS. Its responses include yes, close match, wrong name and unavailable. An unavailable result means the service could not give a match answer; it is not the same as a wrong-name result. Existing payees and standing orders may not receive a new check.

Use the result to decide what to verify next. A match or yes means the submitted name and account data were consistent in that check, but it does not establish that the payment request itself is legitimate or guarantee credit or reimbursement. For a close match, review the exact recipient name and details with the intended payee; for no match or wrong name, pause before authorizing and confirm the instruction through a trusted contact method. An other or unavailable result gives no affirmative match; ask the provider or recipient what could be checked. If a contractor has sent changed bank details, a passing IBAN check digit should not override a name mismatch.

The checks form a sequence: obtain current issued details, match the route and form fields, test the format, check current code and rail information where available, and review any applicable name-check result. Resolve discrepancies before authorizing. None of these checks alone proves rightful ownership or final credit.

Caption: A route-aware review sequence, not a universal payment form. Directory and name-check services vary by payment; EU VoP and UK CoP apply only within their stated scope. A passing check does not establish rightful ownership or final credit. Swift, International Bank Account Number · Federal Reserve Banks, E-Payments Routing Directory · Pay.UK, sort code checker · ECB, Instant Payments Regulation and verification of payee · Pay.UK, Confirmation of Payee FAQs

What should you do if a code or payment detail appears wrong?

If the payment has not been authorized, identify which detail conflicts with the recipient's issued instructions and resolve it before sending. If it has already been submitted, ask the sending provider for its status before attempting a correction or second transfer.

Before sending, resolve a mismatch with the bank and intended recipient

Treat the error message or mismatch as a clue to the layer that needs checking. A format rejection calls for comparing every character with the bank-issued value; re-enter a confirmed copying error, but do not invent a BIC suffix or alter IBAN digits to satisfy the form. A code absent from a current directory calls for fresh recipient-bank instructions. If the code is listed but the chosen payment rail is in doubt, ask the sending provider and recipient bank which route the issued details support. A BIC entered into an account or IBAN field is a field-selection problem: request the missing account identifier rather than trying another bank code.

A name-check discrepancy raises a different question. If an applicable EU Verification of Payee or UK Confirmation of Payee result is close or negative, compare the account details and exact payee name with the intended recipient through a trusted contact method before authorizing. The Pay.UK guidance directs users to check close or wrong-name results; a format-valid sort code or IBAN does not resolve the mismatch. A matching result also does not make a suspicious change in bank details safe without confirmation.

Suppose a vendor provides a new German IBAN but an old supplier record shows a different BLZ. The Bundesbank files distinguish current and future validity periods and may show deletion or successor information; deletion of a record does not always mean deletion of the BLZ. Pause, obtain the vendor bank's current issued IBAN and clarify the difference with the intended recipient or bank. Replacing digits inside the IBAN with a plausible successor would create an unverified instruction rather than verify the original one.

After sending, use the payment reference and ask the sending bank for status

If the instruction has already been submitted, keep its transaction reference and contact the sending bank or payment provider promptly. Explain which code or account detail may be wrong and ask for the actual status. An accepted instruction, debit or well-formed code does not establish that the intended recipient's account was credited. Ask whether the payment was rejected, is still being processed or held, or has been credited; the next action depends on that answer and the route used.

Ask the sending provider what correction, trace or recall options are available at the payment's current stage. No general rule here guarantees that a transfer can be recalled, when an answer will arrive, or whether money can be recovered. In parallel, ask the intended recipient to confirm whether their account received the payment and the amount. Resolve the first transfer's status before sending a replacement, so a missing confirmation is not mistaken for a failed payment.

The detailed steps differ by route. For the message path and tracing concepts in a cross-border bank transfer, see how Swift transfers work; your sending provider can explain the options for this particular transaction.