SwiftRef Identifiers Directory explained: scope, files, and legacy migration

SwiftRef Identifiers Directory is a global reference-data product for validating and cross-referencing payment identifiers. Swift describes it as a single source of data collected from central banks, code issuers, clearing and settlement mechanisms, banking associations, regional financial communities, and financial institutions.[1]

Its public product page names BICs, LEIs, Distinguished Names, national identifiers, national clearing codes, and IBAN data among the identifiers it cross-references.[1] That makes it broader than a simple BIC list.

The directory can help a payment team answer questions such as: Is this identifier structurally and operationally valid? Which institution is associated with it? Which other identifiers relate to the same institution or payment context? The result is still reference evidence, not permission to route or release a payment.

What is the SwiftRef Identifiers Directory?

The SwiftRef Identifiers Directory sits in the reference-data layer of a payment architecture. Its job is to provide current relationships and attributes that systems can use before, during, and after payment processing.

Swift's current public page lists these cross-referenced identifier families:[1]

• Business Identifier Codes, or BICs
• Legal Entity Identifiers, or LEIs
• Distinguished Names, or DNs
• national identifiers
• national clearing codes, including sort codes
• IBAN data

Swift also describes three public use cases:[1]

1. A corporate validates a BIC, clearing code, account-number format, and currency amount details before sending a payment.
2. A treasury operator derives an account-holding bank name and address from an IBAN to validate bank details captured in an ERP system.
3. A payment operator resolves a beneficiary bank's head-office name and address from a bank or branch code and country code.

Those examples show the product's role: identifier validation, enrichment, and relationship resolution before downstream controls make their decisions.

Identifiers Directory versus a BIC-only source

A BIC-focused directory and the Identifiers Directory answer different questions.

The site's BIC Directory guide explains the BIC registry context and how teams use BIC data for institution identification. The Identifiers Directory adds a wider relationship layer across identifier families.

A directory match does not prove sanctions clearance, account ownership, a valid customer mandate, available liquidity, or current service reachability unless those questions are explicitly covered by separate current data and controls.

Is it a Swift identifiers directory or a participants directory?

Searchers often use broad phrases such as swift identifiers directory or swiftref participants directory. These phrases can hide different needs.

A user may be looking for:

• an identifier and its institution record
• a list of participants in a specific payment or messaging service
• BIC connectivity status
• national clearing-system participation
• an IBAN-related bank lookup
• an LEI relationship
• a service-specific routing endpoint

Identifiers Directory is the product name covered here. A service participant list or reachability directory may be a separate source with its own update cycle and entitlement. Do not treat a broad identifier match as proof that an institution participates in a particular service.

The first architecture question should therefore be: Which operational decision must this data support? Product selection follows that decision, not the other way around.

What files does the Identifiers Directory provide?

Swift's public product page describes coverage, benefits, and use cases. It does not publish the complete customer file contract on that page.[1] Exact file names, schemas, delivery channels, update schedules, delta behavior, and commercial entitlements should be taken from the current contracted specification and Swift document centre.

That boundary matters. A public marketing description can support a scope overview. It cannot safely define a production parser.

For every contracted file, capture this implementation record:

product and entitlement
file or API name
release and specification version
delivery channel and schedule
full, delta, or both
record key and relationship keys
field definitions and code lists
null, status, deletion, and expiry semantics
control totals and integrity checks
effective date and replay behavior

Never derive a production schema from a legacy sample, an archived product page, or a vendor screen. Obtain the current specification and test against actual entitled data.

How Identifiers Directory relates to legacy directories

Existing systems may still contain names such as Bank Directory Plus, BIC Plus, BIC Directory 2018, or internal labels that predate the current source.

The BIC Plus versus BIC Directory guide explains one naming transition in the BIC product lineage. The Bank Directory Plus explained guide records a separate legacy product context. Archived Swift training material reviewed for that article said Identifiers Directory was replacing Bank Directory Plus and that the legacy product was being phased out.[2]

The safe conclusion is not that every old field has a direct new equivalent. The safe conclusion is that a migration must compare the current contracted source with the exact legacy source used by the institution.

A local database table may still say BANK_DIRECTORY_PLUS after its feed changes. An application label is not proof of the live product, file version, or field meaning.

Migration is a data-contract change

Treating the move as a file-name swap is the quickest way to create silent reference-data defects.

1. Inventory every consumer

List direct and indirect consumers, including:

• payment engines
• routing services
• ERP and treasury integrations
• client and counterparty onboarding
• sanctions and screening platforms
• repair and investigations tools
• data warehouses
• regulatory and management reporting

Include spreadsheets, manual lookup procedures, cached extracts, and vendor applications. Hidden copies often outlive the official feed.

2. Map meaning, not labels

Build a field-level crosswalk from the actual legacy specification to the current Identifiers Directory specification. Compare:

• business definition
• key and cardinality
• code list
• format and length
• null behavior
• status and effective dates
• hierarchy and relationship semantics
• source and maintenance responsibility

Two fields with similar names may not support the same decision. One legacy record may map to several current relationships, or no safe equivalent at all.

3. Test relationship ambiguity

Reference data often contains one-to-many and many-to-one relationships. A national identifier, institution, BIC, branch, LEI, clearing code, and account pattern do not automatically form one permanent row.

The site's BIC-to-LEI guide makes the same point for BIC and LEI data: a relationship file supports cross-reference and review, not guaranteed one-to-one conversion.

Test cases should include:

• several identifiers linked to one institution
• one identifier with historical or status changes
• branch and head-office relationships
• mergers and reorganizations
• missing or expired records
• conflicting internal and external data
• identifiers valid in format but unsuitable for the intended service

4. Validate full and delta behavior

If the delivery uses full files, deltas, or both, prove how additions, changes, deletions, late deliveries, duplicates, replay, and rollback work. A successfully transferred file is not evidence that every consumer reached the same reference state.

Record the release, hash, control totals, load result, exception count, and consumer reconciliation for each run.

5. Separate validation from authorization

A valid identifier is an input. It is not a payment decision.

The release flow may still need:

• customer and account mandates
• sanctions and fraud controls
• amount and currency rules
• service reachability
• routing policy
• beneficiary checks
• segregation of duties
• current authority evidence

Keep the directory result and the transaction decision as separate auditable steps.

How to integrate the directory safely

A simple reference-data pattern is usually enough:

acquire entitled release
-> verify source, integrity, and version
-> stage without overwriting the current release
-> validate schema and control totals
-> build normalized records and explicit relationships
-> run regression and ambiguity tests
-> reconcile every downstream consumer
-> approve promotion
-> retain rollback and evidence

Production controls should answer:

• Which release produced this result?
• Which record and relationship keys matched?
• Was the record current at the decision time?
• Which normalization was applied?
• Was the match unique?
• Which downstream rule used it?
• Can the result be reproduced after the next update?

Do not silently correct customer or counterparty master data because a directory value differs. Surface the mismatch, explain the source and rule, and apply an approved remediation.

Common mistakes

Calling every Swift list a participants directory

Product, registry, reachability, and service-participant data are not interchangeable. Confirm the source that governs the exact decision.

Assuming a BIC proves network access

Swift distinguishes connected and non-connected BICs. A non-connected BIC can identify an organization for reference purposes but has no rights or authorization to exchange messages over the Swift network.[3]

Building from public page text

Public product pages help explain scope. Contracted specifications govern production files and APIs.

Losing source evidence after enrichment

When data is normalized or cross-referenced, preserve the original value, source product, release, record key, rule version, and resulting relationship. Otherwise a later reviewer cannot explain the match.

Migrating only the central loader

A new golden-source load can pass while caches, extracts, vendor tools, and manual procedures remain on old data. Reconcile every consumer.

Practitioner takeaway

SwiftRef Identifiers Directory provides a broad current reference-data context across BICs, LEIs, DNs, national identifiers, clearing codes, and IBAN data.[1] Its value is not merely the number of identifiers. It is the ability to validate and cross-reference them using a governed source.

For a new integration, start with the current product page, contracted specification, entitlement, and actual delivery. For a legacy migration, identify the exact old source and test the data contract field by field. In both cases, preserve the boundary between reference evidence and payment authorization.

Sources

1. Swift, SwiftRef Identifiers Directory, accessed 20 August 2026.
2. Swift archived training material cited in Raafet Choukri, Bank Directory Plus explained, source archive captured 14 April 2026.
3. Swift, Business Identifier Code, accessed 20 August 2026.
4. Swift, Free BIC Search terms, accessed 20 August 2026.