BIC Code Validation: Why Some Banks Require 11 Characters (Not 8)

A BIC can be valid under ISO 9362 and still be rejected by a bank profile. The important distinction is between the identifier's standard structure and the stricter rule a receiving bank applies to a particular agent field. If an Excel export contains an eight-character BIC, do not blindly append XXX: some profiles accept the short form, while others require a bank-supplied 11-character value.

The 8- and 11-character BIC structure

ISO 9362 defines an eight-character BIC as bank code (4), country code (2), and location code (2). A three-character branch code is optional, producing an 11-character BIC. XXX is commonly used to identify a primary office, but whether an 8-character value can stand in for that form is a bank-profile decision, not a safe spreadsheet transformation.

8 characters:  AAAA BB CC
               bank country location

11 characters: AAAA BB CC DDD
               bank country location branch

What the implemented bank profiles do

The shared input validator recognizes the BIC pattern ^[A-Z]{6}[A-Z0-9]{2}([A-Z0-9]{3})?$: eight characters or eleven characters, uppercase, with letters in the first six positions and alphanumeric location/branch positions. In a credit-transfer workflow, the shared validator treats BICs as optional for the generic input shape; for a SWIFT workflow it requires the creditor BIC in that same 8-or-11-character shape. Bank-specific rules can add constraints after that shared check.

There is no one common bank rule beyond the shared syntactic pattern. The profiles above differ on whether a BIC is required and whether a valid eight-character BIC is sufficient.

Why a bank can require all 11 characters

Straight2Bank is the implemented example. Its profile checks the supplied recipient and intermediary agent BICs before XML generation and fails with a row-specific error unless each is exactly 11 characters. This protects the bank-facing agent identity from an assumption about branch routing.

Shared syntax accepts:
CHASUS33
CHASUS33XXX

Straight2Bank agent validation accepts:
CHASUS33XXX

The difference is layered validation: the shared format check can pass an eight-character value, and the Straight2Bank generator then applies the narrower rule to the affected fields. Passing a generic regex is not proof that a target-bank profile will accept the file.

The converter validates; it does not invent a branch code

No implemented profile pads an eight-character BIC, appends XXX, or otherwise converts it to 11 characters. The generator writes the supplied BIC into the appropriate agent element. For Straight2Bank, it fails loudly instead of completing the value. That is the safe behavior: a guessed branch code may describe a different routing destination.

• Keep BICs as text in Excel so leading letters and the optional final three characters are preserved.
• Use uppercase values matching the shared 8-or-11-character pattern.
• Keep debtor, creditor, and intermediary agent BICs in separate columns; a mandatory debtor-agent BIC is not interchangeable with a recipient agent BIC.
• For Straight2Bank recipient and intermediary agents, source the full 11-character value from the beneficiary or bank rather than guessing XXX.
• Map the BIC fields and select the target profile before generating, so bank-specific validation runs before download.

BIC versus BICFI in newer ISO 20022 messages

Length and element name are separate concerns. The generator uses BIC for older message namespaces and BICFI when the selected namespace is pain.001.001.09. For the wider CBPR+ migration context, see MT101 to pain.001: what the November 2026 SWIFT deadline means. Do not change a value's length just because the XML element name changed.