GLOBAL PAYMENTS KNOWLEDGEISO 20022 / SWIFT / SEPA / MT / MX

SWIFT / Learning brief

SWIFTRef: reference data services

Your notes

What this means in plain language

SWIFTRef is Swift's reference-data utility, publishing authoritative directories of institutions, codes, and settlement details so payment systems can validate and route correctly. Its accuracy reduces repairs and delays before a message is sent.

Before a payment is sent, systems need to confirm that the codes and account details on it are real and current. SWIFTRef is Swift's reference-data utility that supplies this trusted background information. Swift acts as the registration authority for the BIC (Business Identifier Code) and for the IBAN (International Bank Account Number) standard, so it is well placed to publish directories of institutions, national clearing codes, and settlement details. SWIFTRef collects and quality-checks that data, then delivers it three ways: downloadable files that feed a bank's own systems, a web application called Bankers World Online for staff to look up a single record, and real-time application programming interfaces (APIs) that other software can query directly. Accurate reference data means fewer payments stop for manual correction, so money reaches the beneficiary faster and at lower cost.

Understand the full idea, step by step

Type a friend's phone number with one digit wrong and, at best, nothing happens — at worst, a stranger gets your message. A cross-border payment is worse: the codes that say which bank and which account must be exactly right, or the money stops somewhere far away, days later, and someone has to fix it by hand. So banks keep a shared, trusted book of those codes. That book is what we look at here.

Why a wrong code is so expensive

A payment repair is any manual step needed to fix a message before it can move. Repairs are slow and costly because they pull a person into a flow that was meant to be automatic, and every hour of delay is an hour the beneficiary waits. A large share of repairs trace back to bad reference data: a code that was retired when two institutions merged, a branch that moved, a clearing code that no longer routes. The cheapest place to catch any of these is before the message leaves — while the customer is still there and correction costs a keystroke, not a week of investigation.

SWIFTRefSwift's reference-data utility

SWIFTRef is the shared library of payment reference data — directories of institution identifiers, account-numbering rules, national routing codes, and settlement details — published by Swift. Because Swift is the registration authority for the BIC (Business Identifier Code) standard and plays a central role in the IBAN (International Bank Account Number) standard, it sees the authoritative source data from institutions and national numbering bodies. SWIFTRef reconciles that data, applies quality controls, and publishes one trusted copy that many banks share, rather than each keeping its own partial version.

The same data, three ways to reach it

Files
Scheduled downloads a bank imports into its own systems — for bulk, automated validation of thousands of codes at a time
Web application
Bankers World Online — a browser lookup for staff confirming one institution, code, or settlement record by hand
APIs
Real-time queries (application programming interfaces) that confirm a code at the moment of capture — while a customer is still typing

You may be wondering: if SWIFTRef says the code is valid, does that mean the money will definitely arrive?

No — and the gap matters. Reference data describes institutions and codes: that a BIC is real and active, that an account number is well-formed for its country, that a route exists. It does not confirm that one specific customer account is open, funded, or in good standing, and it refreshes on a schedule rather than the instant a fact changes. A clean validation removes the most common errors; it does not replace account-level checks or sanctions screening, which are separate controls layered on top.

Where the check happens

  1. INSTRUCTION

    Asha Traders' instruction reaches Bank Alfa carrying the beneficiary's account details and the receiving institution's identifier.

  2. VALIDATION

    Bank Alfa validates each code against SWIFTRef — is the identifier real and active, does the account structure fit its country, does the route resolve?

  3. VALIDATION

    A code that fails to validate stops here. The payment is queued for correction while it is still cheap to fix, not returned days later.

  4. MESSAGE

    Only once every code checks clean does Bank Alfa build and release the outgoing payment message toward Nordbank.

COMMON CONFUSION

A code that is spelled correctly and has the right shape must be a good code.

Shape is not enough. A BIC can be perfectly well-formed and still be decommissioned, or belong to an institution that is not reachable for the route you need. Validating against a maintained directory answers the second question — is this code real and usable right now — which a format check alone never can.

STRICTLY SPEAKING

Strictly speaking, reference data is a foundation, not a guarantee. It underpins straight-through processing — a payment passing from initiation to settlement with no human touch — and the more fields that validate cleanly, the higher that rate and the lower the cost per payment. But directories refresh on a schedule, and they describe the structure connecting accounts to institutions, not the live status of any single account. Keep it current and it prevents most repairs; treat it as proof of delivery and it will occasionally surprise you.

FOR NOW, REMEMBER

  • SWIFTRef is a shared, quality-controlled library of payment reference data, so validation is consistent from one bank to the next.
  • It is delivered three ways — files for bulk checks, a web tool for manual lookups, APIs for point-of-capture verification — and most banks combine them.
  • Catching a bad code before the message leaves turns a slow, costly repair into a keystroke.
  • Reference data describes institutions and codes, not whether a specific account exists; account checks and screening remain separate.

TRY IT YOURSELF

Bank Alfa's system validates every code on Asha Traders' payment against SWIFTRef and all pass. What has this actually confirmed?

The receiving institution's code is real and active and the account structure is well-formed — but not that the supplier's specific account is open and funded.

Correct — Exactly. Reference data confirms the codes and structure, which removes the most common repair causes. Whether that one account is open, in good standing, or clear of sanctions concerns is checked by separate controls.

The EUR 12,400.00 has been delivered to the supplier's account.

Not this one — Validation happens before the message is even sent. No value has moved; the check only confirms the codes are usable so the payment can proceed.

The payment has been screened for sanctions.

Not this one — Reference-data validation and sanctions screening are different controls. A clean SWIFTRef check says the codes are valid, not that the parties are cleared.

We kept saying "the receiving institution's code." The next lesson opens the two directories that decide whether that code is real, and translate it to and from the domestic identifiers a bank meets every day.

KEEP GOING

Three things to remember

  1. 01

    SWIFTRef is Swift's central source of validated payment reference data.

  2. 02

    It is delivered as files, a web lookup tool, and real-time APIs.

  3. 03

    Good reference data prevents repairs, returns, and settlement delays.

Where you would use this

USE CASE 01

A bank loads SWIFTRef files into its payment engine to validate BICs and clearing codes automatically.

USE CASE 02

An operations analyst uses Bankers World Online to check a single institution before releasing a held payment.

USE CASE 03

A fintech calls a SWIFTRef API in real time to confirm a code while a customer is still entering payment details.

Put the idea into a real situation

Illustrative example: a fictional bank, Meridian Trust, processes 50,000 outbound payments a day. Before adopting SWIFTRef feeds, 6% stopped for manual repair, costing an average of USD 5.00 each in staff time, or USD 15,000.00 a day. After loading the directories to validate codes at capture, the repair rate fell to 1.5%, reducing that daily cost to USD 3,750.00 and saving USD 11,250.00 each day.

Evidence & review

REVIEWED 2026-07-13

Swift's SWIFTRef reference-data utility and its delivery channels (files, Bankers World Online, APIs), as used in cross-border payment validation.

What this brief simplifies: Presents reference-data validation as a single early checkpoint; a production engine runs many field checks and combines files, web, and API channels. Directory refresh cadence and exact product packaging are described, not quoted with version-dependent numbers.

Sources for this brief2
  1. Market practice

    SwiftRef reference data servicesSwift

    Describes the directories Swift publishes as a reference-data utility, including the BIC Directory, Bank Directory Plus, IBAN Plus, the Standing Settlement Instructions Directory, and the SEPA Routing Directory. · Checked 2026-07-13

    Used for public summaries of the SwiftRef directories and their delivery through files, a web application, and application programming interfaces.

  2. Simplified educational illustration

    Payments Signal editorial teaching modelsPayments Signal

    This site's own simplified teaching models. · Checked 2026-07-12

    Used wherever diagrams, scenarios, figures, or example values are didactic constructions rather than sourced facts; every such use carries a simplifications disclosure. All people, companies, banks, and list entries in examples are fictional.

Learn this properly

Related briefs

View SWIFT archive

SWIFT Universal Confirmation and gpi Services

Universal Confirmation asks every bank to confirm the fate of a payment — credited, returned, or rejected — feeding the gpi tracker. This piece walks through the gpi service variants and the Daily Validation Report as a detective control.

READ BRIEF

What a payment declares about itself — and who carries it

Every ISO 20022 payment carries two kinds of metadata: coded fields that declare what the payment is — service level, local instrument, category purpose, purpose — and an agent chain that names who moves it, bank by bank. This article reads a fictional pacs.008 field by field: what each code means, why there are four purpose-ish fields and not one, and how the instructing, previous-instructing, intermediary and reimbursement agents thread a payment across borders.

READ BRIEF