BIC to LEI mapping: what the relationship file proves and what it does not

What is the difference between a BIC and an LEI?

BIC

A Business Identifier Code is defined under ISO 9362. SWIFT is the registration authority appointed by ISO and assigns and publishes BIC records.[1]

In operations, a BIC is commonly used for institution identification, financial messaging, routing preparation, screening enrichment, and payment investigation. For more detail, see the BIC Directory guide.

LEI

A Legal Entity Identifier is a global identifier for a legal entity. It links an entity to reference data in the Global LEI System.

An LEI answers a legal-entity identity question. It does not, by itself, prove that a named person is authorized to act for that entity. That is one of the problems addressed by the vLEI model.

Why both identifiers matter

The mapping file connects these identifier domains without making them interchangeable.

What is the BIC-to-LEI relationship file?

GLEIF and SWIFT introduced the BIC-to-LEI relationship file in February 2018. GLEIF says the mapping process was established by SWIFT and certified by GLEIF. The official download page currently makes monthly CSV files available free of charge and describes the relationship file as open source.[1]

The file can help teams:

• enrich a BIC-bearing payment or counterparty record with an LEI
• reconcile payment data with a legal-entity master
• connect operational institution identifiers to regulatory-reporting identifiers
• reduce manual lookup during investigations
• compare internal mappings with an external certified relationship source
• identify gaps, conflicts, or stale internal relationships

Use the file as a cross-reference source. Keep the source release and mapping provenance with every derived result.

Where to download it

Use the official GLEIF BIC-to-LEI relationship files page. It provides current and historical monthly files, supporting material, the license agreement, and a CSV import guide.[1]

Do not rely on a copied spreadsheet or an undated vendor extract when the decision needs current evidence.

Important CSV and Excel warning

GLEIF warns that opening the CSV file directly in Microsoft Excel can produce errors in LEI codes and points users to its CSV Import Guide.[1]

A minimum intake process should:

1. preserve the downloaded ZIP or CSV unchanged
2. record the source URL, publication month, file name, byte size, retrieval time, and checksum
3. parse the file with an explicit schema
4. keep identifiers as strings
5. validate expected headers and record structure
6. reject malformed BIC or LEI values to an exception table
7. compare record counts and relationship changes with the previous release
8. load into staging before promotion

A practical data model

Do not force the relationship into a single BIC column on an LEI master. Use a relationship table so multiple records and lifecycle changes remain visible.

bic_lei_relationship
- bic
- lei
- source_name
- source_release
- source_file
- source_retrieved_at
- source_checksum
- observed_at
- relationship_status
- ingestion_run_id

Keep raw and normalized identifiers separately if normalization is required.

submitted_bic
-> format normalization
-> BIC reference lookup
-> BIC-to-LEI relationship lookup
-> LEI reference and status lookup
-> decision with source release and reason code

Do not assume a one-to-one relationship

A safe implementation treats BIC-to-LEI as a relationship dataset, not a guaranteed one-row lookup. Institution structures, branch codes, identifier assignment, and lifecycle changes can create more than one relevant record or no current match.

Your application should support at least these states:

• one BIC maps to one LEI
• several BIC records relate to one LEI
• one submitted BIC produces multiple candidate relationships
• no relationship is present in the current file
• an internal mapping conflicts with the published relationship
• the LEI record exists but its current status needs review
• the BIC or LEI changed between releases

Do not convert every exception into an automatic correction. Some need data-owner review.

What a BIC-to-LEI match proves

A match proves that the cited relationship source connects the BIC and LEI in the cited release.

It can support:

• entity reconciliation
• reference-data enrichment
• counterparty aggregation
• investigation triage
• mapping quality checks
• regulatory and risk-data joins

What a BIC-to-LEI match does not prove

It does not, by itself, prove:

• that the LEI is currently active
• that the BIC is reachable for a specific payment service
• that a bank account exists or belongs to the legal entity
• that a person is authorized to act for the entity
• that the entity has passed sanctions, KYC, KYB, fraud, or credit checks
• that two internal customer records should be merged automatically
• that the relationship is valid for every historical date
• that the selected payment route is correct

Each of those requires its own source and control.

Monthly update controls

Because GLEIF describes the relationship file as monthly, freshness should be measurable.[1]

download
-> immutable landing
-> checksum and metadata receipt
-> schema validation
-> relationship diff
-> exception classification
-> staged load
-> sample and aggregate reconciliation
-> approved promotion
-> downstream consumer confirmation

Track the current and previous source month, total relationship count, additions, removals, changed pairs, malformed records, unresolved conflicts, consumer adoption, and decisions still using an older release.

Alert on missing releases, unexpected count changes, schema changes, repeated files, and stale consumer caches.

Mapping quality controls

Validate both identifier formats

Do not attempt a relationship lookup until BIC and LEI values pass basic format controls. Format validity is not proof of assignment, but it removes obvious noise.

Check the source release

Return the mapping source and publication month with the result. Matched without a source date is weak evidence.

Check the LEI record separately

After obtaining the LEI, query the authoritative LEI source for the current record and status required by the use case.

Separate no-match from invalid

A valid BIC with no relationship in the current file is different from an invalid BIC. Use separate reason codes.

Preserve conflicting mappings

If the internal mapping differs from the published relationship, do not overwrite silently. Keep both values, sources, effective dates, and the review decision.

Reconcile downstream use

A successful central load does not prove that reporting, screening, payments, or KYC systems use the current mapping. Measure consumer adoption.

Example reason codes

Common implementation mistakes

Opening and resaving the CSV in Excel can corrupt identifiers. A mapping without a source release is weak evidence. A no-match does not prove no relationship exists outside that release. A shared LEI or BIC relationship is not a universal customer-record merge instruction, and the file is not a replacement for KYC or KYB.

The BankValidate reference build demonstrates deterministic suggestions and review controls with synthetic CSV and a bundled synthetic fixture. It does not query GLEIF, SWIFTRef, BIC Directory, Bank Directory Plus, Identifiers Directory, or any external provider.

Practitioner takeaway

The BIC-to-LEI relationship file is a valuable bridge between payment identifiers and legal-entity data. Its value depends on disciplined ingestion, monthly freshness, explicit relationship modeling, source provenance, LEI lifecycle checks, and honest handling of no-match or conflict states.

For help designing or remediating these controls, see SWIFTRef consulting, BIC Plus vs BIC Directory, and the Reference Data topic.

Sources

[1] GLEIF BIC-to-LEI relationship files, accessed August 20, 2026.

[2] GLEIF: The verifiable LEI, accessed August 20, 2026.