Bank Directory Plus Explained: Identifiers, BIC Links, and the Replacement Path

Bank Directory Plus is a legacy SWIFTRef product that connected national identifiers, institutions, and BICs. Learn what it did, why Identifiers Directory matters now, and how to migrate safely.

Bank Directory Plus was a SWIFTRef reference-data product designed to support domestic and international payment preparation, validation, and processing. It addressed broader identifier and institution relationships than a BIC-only directory.

It is now a legacy product. SWIFT's current BIC Plus training page describes BIC Directory as replacing legacy BIC Plus, while Identifiers Directory is the current broader global reference-data offering.[1][2] New projects should start with the current product, contract, specification, and delivery options. Existing users still need to understand Bank Directory Plus because its files, field names, and control assumptions may remain embedded in payment systems.

This is independent explanatory content, not SWIFT product advice or endorsement. Current SWIFT documentation and the organization's contracted specification remain authoritative.

What problem did Bank Directory Plus solve?

Payment instructions do not always begin with a BIC. A domestic clearing file, client master, ERP, or local payment instruction may identify an institution using a national identifier. A payment platform then needs to establish which institution that identifier belongs to and which candidate or linked BIC may support the intended flow.

Archived SWIFT training material described Bank Directory Plus around three practical capabilities:[3]

• understanding its data content and structure
• identifying the main national identifier and a linked BIC
• understanding operational-entity hierarchy

That is a relationship-data problem, not only a format-validation problem.

What did Bank Directory Plus contain?

The exact licensed specification is authoritative for any implementation. At a practical level, Bank Directory Plus was used to connect payment identifiers and institution context so teams could prepare and validate payment instructions.

Important concepts included:

• national identifiers used by domestic payment systems
• BICs associated with those identifiers
• institution and operational-entity relationships
• hierarchy for interpreting a branch, office, or related operating entity
• country and payment context used by downstream validation

Do not infer an implementation schema from this summary. For new work, use the current product documentation and contracted data dictionary.

Bank Directory Plus vs BIC Directory

Read the BIC Directory guide for the current BIC-focused pillar and BIC Plus vs BIC Directory for the naming transition.

Why Identifiers Directory matters now

SWIFT describes Identifiers Directory as a current global reference-data source collected from central banks, code issuers, clearing and settlement mechanisms, banking associations, regional communities, and financial institutions.[2]

That changes the starting point for new work:

1. Do not build a greenfield integration from an archived Bank Directory Plus description.
2. Confirm the current Identifiers Directory specification, delivery channel, update schedule, and entitlement with SWIFT.
3. Treat a migration as a data-contract change, not a file-name swap.
4. Revalidate every downstream control that depends on identifier relationships or hierarchy.

An old application may continue to display Bank Directory Plus after its source changes. Internal product labels are not reliable evidence of the live feed.

How national identifier to BIC resolution works conceptually

payment instruction
-> national clearing identifier
-> identifier relationship lookup
-> candidate institution or operational entity
-> candidate or linked BIC
-> context and reachability checks
-> validated routing decision or controlled exception

The lookup does not prove the final route. The payment service, currency, market infrastructure, account arrangement, message type, connectivity, and bilateral permissions can all affect the operational decision.

The safest output is not just a BIC. It is a result with provenance:

submitted identifier
+ country or scheme
+ matched record key
+ candidate or linked BIC
+ relationship or hierarchy context
+ source product and release
+ rule version
+ decision and reason code

Control boundaries to keep separate

Identifier validity

Does the submitted national identifier follow the expected scheme and structure?

Directory relationship

Does the cited reference source connect the identifier to an institution, operational entity, or BIC in that release?

BIC status

Is the BIC present and current in the BIC source being used?

Reachability

Can the institution receive the intended payment through the relevant service, clearing system, or correspondent route?

Authorization

Is the transaction allowed under account, sanctions, fraud, compliance, and bilateral controls?

One directory match cannot answer all five questions.

Migration controls for existing users

Inventory every dependency

Search interface specifications, batch jobs, data tables, APIs, stored procedures, vendor configurations, repair tools, screening enrichment, onboarding, and reports.

Freeze the current contract

Retain the current specification, sample file, data dictionary, release identifier, transformation rules, test cases, and exception behavior as the comparison baseline.

Map meaning, not labels

Create a field-level crosswalk. Record definition changes, key changes, cardinality, null handling, status semantics, hierarchy behavior, code lists, and fields with no safe equivalent.

Test ambiguous relationships

Include one-to-many relationships, missing mappings, changed hierarchy, invalid national identifiers, obsolete records, branch and head-office scenarios, and cases needing human review.

Reconcile consumers

Prove which source release each critical application used. Compare counts, unmatched keys, changed mappings, repair rates, and routing outcomes.

Retain rollback and evidence

Keep the previous release, promotion record, checksums, validation output, approved exceptions, and consumer acknowledgements.

Common implementation mistakes

Using the first BIC returned

A relationship lookup can produce multiple candidates or a context-dependent result. The decision rule must explain why one BIC is selected.

Ignoring the identifier scheme and country

A national identifier is meaningful inside a scheme. Treating it as globally unique free text creates false matches.

Treating hierarchy as legal ownership

Operational hierarchy supports routing and reference-data interpretation. It is not legal-entity proof without an authoritative legal-entity source. For governed cross-referencing, see BIC to LEI mapping.

Treating a match as reachability

An identifier-to-BIC relationship is not proof that a payment can use a particular service or route.

Hiding uncertainty

No match, multiple candidates, stale source, and conflicting sources are valid operational states. Each needs a reason code and review path.

Practical implementation checklist

• Confirm the current SWIFTRef product and entitlement.
• Obtain the current specification and sample delivery.
• Define identifiers by scheme and country.
• Keep submitted and normalized values.
• Model identifier-to-entity and entity-to-BIC relationships explicitly.
• Separate BIC existence from payment reachability.
• Preserve source release and rule version in every decision.
• Test one-to-many, no-match, changed, and deleted cases.
• Reconcile every downstream consumer after promotion.
• Keep rollback data and evidence.

BankValidate demonstrates reviewable validation flows using synthetic CSV and a bundled synthetic fixture. It does not query SWIFTRef, BIC Directory, Bank Directory Plus, Identifiers Directory, a live directory, or any external provider.

Frequently asked questions

What is Bank Directory Plus?

Bank Directory Plus was a SWIFTRef reference-data product used to support domestic and international payment preparation, validation, and processing. Its legacy scope included national identifiers, linked BICs, and operational-entity hierarchy.[3]

Is Bank Directory Plus still the current product?

Treat it as legacy. For new work, verify the current Identifiers Directory product, specification, and commercial entitlement directly with SWIFT.[2]

What is the difference between Bank Directory Plus and BIC Directory?

BIC Directory focuses on BIC records and associated BIC information. Bank Directory Plus addressed broader payment identifier relationships, including national identifiers linked to BICs and operational hierarchy.

Does a national identifier always map to one BIC?

Do not assume that. The relationship can depend on the scheme, service, institution structure, branch context, and source release.

Does a directory match prove payment reachability?

No. Reachability also depends on the payment scheme, service participation, connectivity, currency, routing arrangement, and bilateral permissions.

What should an existing user do before migrating?

Freeze the legacy contract, map fields and semantics to the replacement source, test ambiguous and changed relationships, reconcile every consumer, and retain rollback evidence.

Practitioner takeaway

Bank Directory Plus should be understood as a legacy payment reference-data product, not a current default recommendation. Its lasting value is the problem model it exposed: controlled relationships between national identifiers, institutions, operational hierarchy, and BICs. For new work, verify the current Identifiers Directory contract. For migrations, prove every field, relationship, decision rule, and downstream consumer.

For help with an assessment, see SWIFTRef consulting and the Reference Data topic.

Sources

[1] SWIFTRef BIC Plus training page, accessed August 20, 2026.

[2] SWIFTRef Identifiers Directory product page, accessed August 20, 2026.

[3] Archived SWIFTRef Bank Directory Plus training page, archived April 14, 2026.

Topics: SWIFTRef, Bank Directory Plus, Identifiers Directory, Reference Data, BIC, Payments