BIC code structure explained: the 8 and 11 character format

A Business Identifier Code, or BIC, is an ISO 9362 identifier used to identify business parties and support the automated routing of business transactions. Swift acts as the ISO registration authority for BICs.[1]

The core BIC structure has eight characters. An optional three-character branch identifier extends it to eleven characters. Reading the format tells you how the code is organized. It does not by itself prove that the organization is connected to the Swift network, reachable for a service, safe to pay, or the correct beneficiary.

What is the BIC format?

Swift describes the eight-character BIC as a business party identifier built from three components:[1]

AAAA BB CC

The optional branch identifier adds three characters:

AAAA BB CC DDD

Swift says the branch identifier can identify a specific location, department, service, or unit of the same business party.[1]

The common informal labels institution code, country code, location code, and branch code are still widely used. For implementation, follow the terminology and validation rules in the applicable current ISO 9362 and Swift documentation.

Eight-character versus eleven-character BIC structure

An eight-character BIC identifies the business party. An eleven-character BIC supplements that identifier with a branch element.

That difference affects matching and data design:

• A system may store the eight-character party BIC separately from a branch identifier.
• Another system may store the combined eleven-character form.
• A user may enter eight characters where a process expects a specific branch.
• A legacy database may append a default branch representation during normalization.
• A payment rule may need to distinguish party identity from a service or branch context.

Do not drop the last three characters automatically. Do not append a value automatically merely to satisfy a field length. Preserve the received value and make any normalization explicit and reversible.

The site's BIC Directory guide covers the wider reference record, including the institution data attached to the code.

What a BIC tells you

A current BIC record can help a system identify a business party and attach governed reference information. Swift's public BIC page names attributes such as:[1]

• full legal name
• registered address
• financial or non-financial institution status
• publication date
• last update date
• expiry date where applicable
• whether the record is self-maintained

The code itself does not contain that full record. Those attributes come from the BIC reference source.

A BIC can therefore support:

• institution identification
• message addressing where applicable
• payment routing inputs
• counterparty data validation
• screening enrichment
• onboarding checks
• investigations and repair

The result should be logged with its source release and record status. A code match without a source date is weak evidence.

Connected and non-connected BICs

Swift distinguishes two types:[1]

• Connected BIC: has access to the Swift network.
• Non-connected BIC: has no access and is used for reference purposes.

Swift states that a non-connected BIC has no rights or authorization to connect and exchange messages over the Swift network.[1]

This is why a structurally valid BIC is not proof of connectivity. A code can be registered and useful for identification without being usable as a messaging endpoint.

Connectivity is also not the same as participation in a particular payment service. A routing decision may need separate current service, reachability, clearing, or correspondent data.

BIC validation has several layers

A production control should separate at least four questions.

1. Format validation

Does the input contain eight or eleven permitted characters? Is the country component alphabetic and structurally valid? Are spaces and punctuation handled according to the interface contract?

A regex can answer only part of this layer. It cannot prove registration or current status.

2. Registry validation

Does the BIC exist in the current official reference data? What is the record status? When was it last updated? Has it expired?

3. Relationship validation

Does the BIC relate to the expected branch, national identifier, legal entity, or counterparty context? The new SwiftRef Identifiers Directory guide explains why broader identifier relationships need a governed reference source.

For BIC and LEI specifically, the BIC-to-LEI guide explains that a relationship file supports cross-reference and review. It is not a guaranteed one-to-one conversion.

4. Transaction validation

Is this BIC suitable for the intended payment, service, currency, route, and beneficiary? Have sanctions, fraud, mandate, and account controls passed?

A directory can support the decision. It does not make the decision alone.

Is there a free complete BIC list?

Swift offers a free BIC Search service for occasional users.[2] Its terms say the service provides access to data published in the BIC Directory, including registered BICs and corresponding entity names and addresses.[2]

The same terms prohibit systematic queries intended to reproduce the entire directory or a substantial part of it, and prohibit redistribution outside the permitted use.[2] Swift also says rights in the directory and search content remain with Swift or its licensors.[2]

The honest answer is therefore:

• You can use the official free BIC search for occasional lookups under its terms.
• A production BIC database, bulk BIC file, or redistributed BIC list requires the appropriate licensed product, entitlement, and delivery arrangement.
• A third-party list is not automatically current, complete, licensed, or suitable for payment controls.

Do not scrape a BIC locator to build a production master file. Obtain the reference data through an authorized route and retain evidence of the release used.

BIC database, BIC file, and BIC reference data

Searchers often use BIC database, BIC file, and BIC reference as if they mean the same thing. The operational details matter.

A usable reference-data arrangement should define:

product and entitlement
file or API specification
release and effective date
full and delta behavior
record and relationship keys
status and expiry semantics
integrity and control totals
load, reconciliation, and rollback evidence

The site's BIC Plus versus BIC Directory guide explains why legacy product names may remain inside applications after the actual source changes.

When replacing a source, compare the exact schemas and definitions. Do not map fields because their labels look similar.

Common BIC data mistakes

Treating every eight-character value as a head-office payment endpoint

The official structure identifies the business party and allows an optional branch identifier. The correct operational endpoint still depends on the payment and service context.

Removing branch information

Truncating an eleven-character value may collapse a branch-specific input into a party-level value. Record the transformation and prove that it is permitted for the use case.

Assuming registration means connectivity

Non-connected BICs are registered for reference purposes but do not have Swift network access.[1]

Using a stale local table

A valid code can have changed entity data, status, or dates. Track the source release and reconcile updates through every consumer.

Treating BIC as payment authorization

A BIC identifies a party. It does not prove account ownership, a customer mandate, beneficiary validity, sanctions clearance, or permission to release value.

Reproducing a free search service in bulk

Swift's terms position free BIC Search for occasional use and restrict systematic extraction.[2] Use an entitled reference source for production data.

A safe BIC lookup flow

receive original value
-> normalize only under documented rules
-> validate 8 or 11 character structure
-> query current authorized BIC reference data
-> check record status and dates
-> preserve branch context
-> combine with service and transaction controls
-> record source release, match, rule, and decision

A useful result should distinguish:

• malformed input
• well-formed but unregistered code
• registered non-connected BIC
• registered connected BIC
• ambiguous or unexpected branch relationship
• valid reference match but unsuitable transaction context

Those outcomes support operations far better than one generic valid BIC flag.

Practitioner takeaway

BIC structure is simple enough to explain in a few lines: four alphanumeric characters, a two-letter country code, two more alphanumeric characters, and an optional three-character branch identifier.[1]

Using BIC data safely is harder. Payment teams need current official reference data, clear connectivity and relationship semantics, controlled normalization, release evidence, and transaction-specific checks. The code identifies a business party. It does not replace the rest of the payment decision.

Sources

1. Swift, Business Identifier Code, accessed 20 August 2026.
2. Swift, Free BIC Search terms and conditions, accessed 20 August 2026.
3. ISO, ISO 9362:2022, linked by Swift as the current standard page, accessed 20 August 2026.