Articles / Learning brief
Payment hub reference and standing data
Your notes
In simple terms / 01
What this means in plain language
Reference and standing data are the lookup tables a payment hub relies on to validate, enrich, and route payments. This article explains what they contain, how they are kept current, and why stale data causes repairs and delays.
Reference and standing data are the background tables a payment hub reads constantly but that individual payments do not carry. They include directories of bank identifiers and account numbers, routing tables that say how to reach each network, currency and calendar data that record which days a currency settles and by what cut-off time, and code lists for purposes and charges. When a payment arrives short of detail, the hub fills the gap from this data, and when it must decide where to send a payment, it consults these tables. Because the data changes in the outside world, a bank must keep its copy current, loading updates from official sources on a regular schedule. When the data is wrong or out of date, the effects are immediate and visible: payments cannot be validated, they need manual repair, they route to the wrong place, or they miss a cut-off and settle a day late. Good reference data is quiet, and poor reference data is expensive.
Complete lesson / 02
Understand the full idea, step by step
A payment message is surprisingly light on detail. It does not carry the phone book of every bank in the world, or a calendar of which days a currency settles. It refers to those things — and the hub looks them up. That background of lookup tables is reference and standing data, and when it is right nobody notices it at all.
Reference and standing data — the lookup tables a hub reads to validate, enrich, and route
Reference and standing data are the background tables a payment hub reads constantly but that individual payments do not carry: directories of bank and account identifiers, routing tables, currency and calendar data with cut-off times, code lists for purposes and charges, and customer static data. When a payment arrives short of detail, the hub fills the gap from this data; when it must decide where to send a payment, it consults these tables. The payment carries a reference; the data supplies the meaning.
What the tables hold
- Bank identifiers
- BIC (Business Identifier Code) directories and account-number references used to recognise and address banks
- Routing
- Which network or correspondent reaches a given bank or scheme
- SSIs
- Standing settlement instructions — where and how a party wants to receive settlement
- Calendars & cut-offs
- Which days a currency settles, and the latest time a payment can be accepted for same-day value
- Code lists
- Purpose codes, charge codes, and other controlled values a rail requires
- Customer static data
- Standing details about the bank's own customers used to enrich and validate their payments
The data does the enrichment
This is why a payment need not carry every detail itself. A hub reads reference data to complete routing, resolve an identifier, and confirm a value against a code list — the enrichment step from the engine lesson runs on these tables. Because the outside world changes — banks merge, codes retire, cut-offs move — the bank must keep its copy current, loading updates from authoritative directories on a regular schedule. Good reference data is quiet; poor reference data is expensive.
WHAT IF — A BIC directory or a currency calendar is left out of date
What happens: The effects are immediate and visible: payments fail validation and need manual repair, or they route to the wrong place, or they miss a cut-off and settle a day late — a real cost to the customer and to operations.
How it is handled: The fix is a schedule, not a scramble: load updates from authoritative sources on a defined cycle, and treat a spike in repairs — as Maya saw — as a signal to check whether a table has gone stale. A missed cut-off does not automatically mean "next day"; the outcome may be queuing, re-dating, rerouting, repair, or rejection depending on the rail and the timing.
STRICTLY SPEAKING
Strictly speaking, a standing settlement instruction is routing and settlement data — it records where and how a party wants to be paid. It is not by itself proof of an account relationship or a legal agreement between the parties. Treat an SSI as a reliable address to validate against, not as evidence that two banks have agreed anything.
FOR NOW, REMEMBER
- Reference and standing data are the lookup tables a hub reads to validate, enrich, and route — identifiers, routing, SSIs, calendars and cut-offs, code lists, customer static data.
- Payments carry references, not the full detail; the data supplies the meaning behind them.
- Stale or wrong data causes repairs, misrouting, and missed cut-offs, so it must be refreshed from authoritative sources on a schedule.
- An SSI is routing and settlement data, not a proof of agreement; a missed cut-off can mean queuing, re-dating, rerouting, repair, or rejection — not automatically next day.
TRY IT YOURSELF
Overnight, Bank Alfa's cross-border repair queue jumps sharply, and every stuck payment carries a bank code that will not resolve. What is the most likely cause and fix?
You have now met the engine, the hub, its capabilities, templates, and the data underneath. The topic behind these articles assembles them into one architecture — how the pieces fit and fail together.
KEEP GOINGKey takeaways / 03
Three things to remember
- 01
Reference and standing data include identifier directories, routing tables, currency and calendar data, and purpose and charge codes.
- 02
The hub reads this data to validate, enrich, and route payments, so a payment need not carry every detail itself.
- 03
Stale or wrong reference data causes repairs, misrouting, and missed cut-offs, so it must be updated on a schedule.
Practical use cases / 04
Where you would use this
A payments team loads updated bank identifier and routing directories each cycle so beneficiary details validate correctly.
An operations desk traces a spike in manual repairs to an outdated purpose-code list and refreshes it.
A treasury function uses currency calendar and cut-off data to warn when a payment will miss same-day settlement.
Worked example / 05
Put the idea into a real situation
Illustrative example: a fictional bank, Northwind Bank, processes 20,000 cross-border payments in a week. Its BIC (Business Identifier Code) directory is three months out of date, so 600 payments carry a bank code that no longer resolves. Each needs a manual repair that takes an analyst 4 minutes, adding 2,400 minutes, or 40 hours, of work in one week. Refreshing the directory on schedule would have let those 600 payments validate and route without a person.
Evidence & review / 07
Evidence & review
Describes reference and standing data in a payment hub generally; identifier and SSI points reflect common cross-border practice, not one operator's rules.
What this brief simplifies: Repair-spike figures and update cadence are illustrative; real data-governance splits ownership across many feeds and schedules. Cut-off outcomes are described, not quantified.
Sources for this brief3
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
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.
- Market practice
SwiftRef reference data services ↗ — Swift · BIC directories and reference data used for validation, enrichment and routing
Used for public summaries of the SwiftRef directories and their delivery through files, a web application, and application programming interfaces.
- Market practice
Correspondent banking (final report) ↗ — CPMI, Bank for International Settlements · Standing settlement instructions
Published in July 2016; its statistics cover 2011-2015 and are dated, but the definitions and arrangement types remain widely used.