BIC to LEI Mapping and the Relationship File
BIC to LEI mapping links the code that identifies a bank operationally to the code that identifies it as a legal entity. Here is how the mapping works, where the free relationship file comes from, and how to apply it to your data without inheriting its gaps.
What is BIC to LEI mapping?
A BIC (Business Identifier Code) identifies a financial institution for operational purposes such as routing and messaging. An LEI (Legal Entity Identifier) identifies the legal entity itself for transparency and regulatory reporting.
BIC to LEI mapping connects the two: given a BIC, find the legal entity's LEI, and vice versa. It is the bridge between how a bank is addressed in payments and how it is identified in counterparty, KYC, and reporting systems.
The GLEIF and SWIFT BIC-to-LEI relationship file
SWIFT and GLEIF (the Global Legal Entity Identifier Foundation) jointly publish a BIC-to-LEI relationship file. It is open, free to download, and refreshed on a regular schedule, which makes it the practical starting point for most mapping work.
The file expresses relationships between BICs and LEIs. It is not a guarantee of one-to-one coverage, which is why the next step matters.
Why BIC to LEI mapping matters
The mapping is a prerequisite for several controls that auditors and regulators increasingly expect.
- Regulatory reporting: many reporting regimes require the LEI of the counterparty, not just its BIC.
- KYC and onboarding: resolve a payment counterparty to a verified legal entity.
- Counterparty identification: link operational payment records to entity-level risk and exposure data.
- Screening and risk: reduce ambiguity when the same institution appears under multiple codes.
Data-quality gotchas
The relationship file is a strong foundation, but it is not complete. Treat it as input to be validated, not a finished answer.
- Coverage gaps: not every BIC has a published LEI relationship.
- Lapsed LEIs: an LEI can fall out of an active registration status and still appear in older internal data.
- One-to-many: a single legal entity often holds multiple BICs across branches and networks.
- Stale internal joins: mappings copied into internal systems years ago drift from the current file.
Applying the mapping cleanly to your data
The value is not the file itself, it is a trustworthy join between the file and your own records. The approach is to validate your messy internal BIC and LEI data against the relationship file using deterministic, explainable checks, so integration is seamless and migration runs smooth.
Every proposed correction is a suggestion your team approves. BankValidate is the reference build that demonstrates this remediation core on synthetic data; the same approach applies against the live relationship file in a real engagement.
Frequently Asked Questions
- Where can I download the BIC-to-LEI relationship file?
- GLEIF and SWIFT jointly publish the BIC-to-LEI relationship file. It is available to download for free from GLEIF and is refreshed on a regular schedule.
- Is BIC to LEI mapping one-to-one?
- No. A single legal entity (one LEI) frequently holds multiple BICs across branches and networks, and not every BIC has a published LEI relationship, so coverage must be validated.
- What is the difference between a BIC and an LEI?
- A BIC identifies a financial institution for operational purposes such as routing and messaging. An LEI identifies the legal entity itself for transparency and regulatory reporting. Mapping links the two.
- Can I just load the relationship file and be done?
- Loading it is straightforward, but coverage gaps, lapsed LEIs, and stale internal joins mean the file should be validated against your own records before it is trusted in reporting or screening.