BIC Plus vs BIC Directory: What Changed Under SWIFTRef?

BIC Plus is a legacy SWIFTRef product name, while BIC Directory is the current BIC-focused directory. Learn what the replacement means, which migration controls matter, and why a name change is not enough.

BIC Plus and BIC Directory are not two current SWIFTRef products that a payment team needs to choose between. SWIFT's current BIC Plus training page says BIC Directory is replacing legacy BIC Plus and that the older module is no longer being updated.[1]

The practical point is simple. If an old interface specification, file name, data contract, procedure, or vendor screen still says BIC Plus, the team should identify the actual feed, release, delivery channel, fields, and update process before changing any payment control.

For a current product overview, see the site's BIC Directory guide. This independent article concentrates on the replacement history and migration controls. It is not SWIFT product documentation, advice, or endorsement.

What was BIC Plus?

BIC Plus was a SWIFTRef reference-data product used to support institution identification and payment preparation. The legacy name may still appear in:

• file-transfer jobs
• database table names
• vendor product labels
• field-mapping documents
• sanctions-screening enrichment flows
• payment-repair procedures
• regression-test data
• internal service names

The label alone does not prove which dataset, version, or service is actually in use.

What is BIC Directory?

SWIFT's current product page says BIC Directory provides BIC8 and BIC11 records together with registered names and addresses, SWIFT connectivity status, and Distinguished Names.[2] It also describes connectivity details for services including FIN, FINplus, InterAct, and FileAct.

That makes the directory more useful than a flat list of codes. A payment team can use it to investigate which institution is associated with a BIC, whether the record appears in the release being used, and which connectivity details the source provides.

A BIC record is reference data. It can support identification, validation, routing preparation, onboarding, screening enrichment, and repair. It does not prove that a payment is authorized, that an account exists, or that a counterparty passed every compliance check.

BIC Plus vs BIC Directory at a glance

What actually changes in a migration?

A naming change can look harmless. Reference-data migrations fail when teams change the label but do not test the contract behind it.

File and schema contract

Compare the exact source and target specifications. Record the delivery format, field names, data types, key structure, null handling, code lists, record status, release date, and version identifier. Do not map fields only because their names look similar.

Record identity

Decide which field is the stable key in each downstream system. A BIC can be eight or eleven characters, and branch handling can change how a system joins, displays, or deduplicates records. Preserve the original source value alongside any normalized form.

Connectivity and service assumptions

A BIC identifies an institution or business party under the standard. Connectivity data answers a different question. A code can exist without proving that the party is reachable for every service or message flow.

Keep code validity, connectivity status, service participation, routing choice, and bilateral authorization as separate controls.

Delta and full-file behavior

Establish whether each delivery is a complete replacement, a delta, or both. Test additions, changes, deletions, late files, duplicate files, missing files, and replay. A successful transfer is not proof that every consumer loaded the current reference state.

Downstream joins

List every system that consumes the directory directly or through a golden source. Typical consumers include payment engines, screening tools, client onboarding, investigations, repair workstations, routing services, data warehouses, and reporting.

Operational ownership

Assign ownership for acquisition, validation, loading, exception handling, rollback, consumer communication, and release evidence.

A safe BIC reference-data migration pattern

current contracted source
-> immutable landing file
-> checksum and release validation
-> schema and code-list validation
-> staged transformation
-> comparison with previous release
-> exception review
-> controlled promotion
-> consumer reconciliation
-> retained evidence and rollback point

This pattern keeps three questions separate:

1. Did the right source file arrive?
2. Did the institution transform it correctly?
3. Did every critical consumer load and use the intended version?

Common migration mistakes

Treating the old product name as the data contract

A job called bic_plus_load may already consume a newer directory. Rename work should follow contract verification, not replace it.

Assuming a valid BIC means a reachable endpoint

BIC existence, SWIFT connectivity, service availability, payment routing, and bilateral permissions are different facts. Do not collapse them into one boolean.

Ignoring deleted or changed records

A load that only inserts new rows can leave stale BIC data active. Deletion and change behavior must be tested explicitly.

Repairing values without provenance

If an operator or enrichment service changes a BIC, retain the submitted value, corrected value, source release, decision rule or user, and timestamp.

Letting every application interpret the feed differently

Centralizing the raw source is not enough. Shared field definitions, update semantics, and reason codes reduce inconsistent downstream behavior.

How BIC Directory differs from Bank Directory Plus

BIC Directory focuses on BIC records and associated BIC information. Bank Directory Plus historically supported broader domestic and international payment reference-data needs, including relationships between national identifiers and BICs. Read Bank Directory Plus explained for the legacy product and current Identifiers Directory context.

The distinction matters because a project looking for domestic clearing identifiers, institution hierarchy, and a candidate or linked BIC is solving a broader problem than BIC validation alone. The selected BIC still depends on the scheme, service, branch, source release, and local decision rules.

Questions to ask before changing a BIC feed

• What is the exact contracted product and delivery channel today?
• Which specification and release version are authoritative?
• Is the delivery a full file, delta, API, or hosted lookup?
• How are additions, modifications, and deletions represented?
• How are BIC8 and BIC11 values handled?
• Which consumers depend on connectivity or Distinguished Name data?
• Which controls prove completeness, freshness, and promotion?
• Can the previous release be restored quickly?

A reference implementation can help test these controls without pretending to provide live directory answers. BankValidate uses synthetic CSV data and a bundled synthetic fixture. It does not query SWIFTRef, BIC Directory, Bank Directory Plus, Identifiers Directory, or any external provider.

Frequently asked questions

Is BIC Plus the same as BIC Directory?

BIC Plus is a legacy SWIFTRef product name. SWIFT says BIC Directory is replacing BIC Plus.[1] Teams should verify their current contract and technical specification rather than treating the names as two live alternatives.

What does BIC Directory contain?

SWIFT says the current directory includes BIC8 and BIC11 records, associated registered names and addresses, SWIFT connectivity status, and Distinguished Name data.[2]

Is BIC Directory the same as Bank Directory Plus?

No. BIC Directory is centered on BIC data. Bank Directory Plus historically supported broader payment reference data, including national-identifier relationships and operational hierarchy.

Does a BIC prove that a bank can receive a payment?

No. Payment reachability also depends on connectivity, service participation, routing arrangements, message rules, and bilateral permissions.

Should an old BIC Plus job be renamed immediately?

Not before the source and downstream contract are verified. First confirm what it consumes, compare schemas and release behavior, test every critical consumer, and retain rollback evidence.

Practitioner takeaway

The important difference between BIC Plus and BIC Directory is not a marketing label. It is the reference-data contract that payment controls depend on. Establish the current source, prove the fields and release semantics, keep BIC validity separate from reachability, and reconcile every downstream consumer before retiring the legacy path.

For help assessing a SWIFTRef feed or migration, see SWIFTRef consulting and the Reference Data topic.

Sources

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

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

Topics: SWIFTRef, BIC Directory, BIC Plus, Reference Data, Payments, Data Migration