Reference Data in a Bank Migration
How banks move reference data to a new platform: list the domains, pick one golden source, load it before positions, check identifiers, confirm settlement instructions and keep owners.
Alexander Kiel
Business Analyst · Banking & Wealth Management
16.05.2026 · 8 MIN READ · DATA MIGRATION
ON THIS PAGE
1. List Every Reference Data Domain
2. Pick One Golden Source per Domain
3. Load Reference Data Before the Positions
4. Check Identifiers Against Their Source
5. Confirm Every Settlement Instruction
6. Keep Reference Data Owned After Go-Live
Sample case: HSBC
In short
FAQ
Reference data describes what a bank holds and deals with: instruments, issuers, counterparties, settlement instructions, calendars and code lists. Good reference data management decides whether trades settle. Data cited in an ESMA report shows that settlement fail rates in terms of value fell from 6.6% to 3.8% between January 2022 and January 2024. Among the causes, ESMA lists changes in SSIs not being communicated or updated in good time.
The margin for error is shrinking. EU and EEA markets move to T+1 on the agreed date of 11 October 2027. The industry roadmap names missing or late static data such as SSIs and ISIN set-up as a reason trades are not instructed on trade date.
In a migration, reference data is loaded first and often checked least. Every position and every payment depends on it. Does your bank know which system will be the golden source for each instrument after cutover?

STEP 1
List Every Reference Data Domain
Start with an inventory. Typical domains are instruments, issuers, counterparties, settlement instructions, holiday calendars, code tables, products and fee schedules. For each domain, record the systems that hold it, the vendor feeds that fill it, the number of records and the teams that change it. Some of these tables sit outside the core platform and are easy to miss.
Market bodies see the same gap. The EU T+1 roadmap calls for improving the quality of static reference data to facilitate STP. A migration is the natural moment to do that work. My article on source to target mapping shows how to translate the code lists once the domains are known.
✓
List each domain with its systems, feeds and record counts
✓
Include tables held outside the core platform
✓
Name the team that changes each domain today
Which reference data tables in your bank are maintained in spreadsheets rather than systems?
Keep in mind: Market data such as prices is often fed from the same vendor but is not reference data. Scope it separately.
STEP 2
Pick One Golden Source per Domain
After a merger or platform change, two systems often hold the same instrument or counterparty with different values. Decide for each domain which source wins: the vendor feed, the new platform or one of the old systems. Set rules for records that exist on one side only, such as locally created structured products or private assets.
The ECB expects uniform data definitions and glossaries with clear ownership of data. It also calls for periodical reconciliation with institutions' sources and reports. A golden source makes that reconciliation possible. My article on the data quality framework shows how to name an owner and a golden source for critical data.
✓
Choose one golden source for each reference data domain
✓
Set rules for records that exist on one side only
✓
Record every decision with its owner and date
If both systems hold the same bond with different coupons, which one does your bank trust?
Keep in mind: Vendor data is not automatically right. Compare vendors with the old system before you declare one the golden source.
STEP 3
Load Reference Data Before the Positions
Load in dependency order: calendars and code tables first, then issuers and counterparties, then instruments, then settlement instructions, then accounts. Positions and transactions come last. A position that points to a missing instrument is either rejected or loaded against a default. Both create breaks.
Settlement shows why order matters. ESMA lists delays related to instrument reference data (e.g. new ISIN not being available) as a cause of fails. Respondents also noted that certain ISINs are not eligible to settle in every EU CSD. My article on data migration strategy shows how rehearsals test the full load sequence.
✓
Define the load order for every reference data domain
✓
Stop the position load if an instrument is missing
✓
Time the reference data load in each rehearsal
What happens in your migration to a position whose instrument is not yet set up?
Keep in mind: Reference data keeps changing until cutover. Plan a final delta load for new instruments and corporate actions.
STEP 4
Check Identifiers Against Their Source
Validate every identifier before it moves. Check ISIN format and check digits, look up LEIs in the global index, confirm BICs and remove duplicates that point to the same instrument or entity. Map internal instrument numbers to public identifiers wherever one exists, so the new platform does not depend on keys from a system that will be switched off.
ISO 6166 gives each instrument a unique identification code and associated minimum descriptive data. Entity identifiers age faster. GLEIF reported for the third quarter of 2025 that the overall renewal rate increased to 57.1%. A counterparty master built years ago is likely to hold LEIs that were never renewed.
✓
Validate ISIN, LEI and BIC formats before the load
✓
Check each LEI status against the global index
✓
Replace internal keys with public identifiers where possible
How many counterparties in your bank's master still carry an LEI that has lapsed?
Keep in mind: A lapsed LEI is still a valid code. It only shows that the entity data behind it may be outdated.
STEP 5
Confirm Every Settlement Instruction
Settlement instructions decide where cash and securities go. Extract them per counterparty, market and currency, remove old and duplicate entries and confirm the rest with the counterparties. Freeze changes in the weeks before cutover and route any urgent change through a call-back on a known number. A wrong instruction moves money to the wrong account.
The EU T+1 roadmap states that SSIs are an inherent weak point in post-trade processing, leading matching and settlement exceptions. An industry task force was set up to devise EU market standards for populating, sharing and storing SSIs. A migration that cleans settlement instructions now is ahead of that work.
✓
Confirm each settlement instruction with its counterparty
✓
Freeze instruction changes in the weeks before cutover
✓
Verify urgent changes by call-back on a known number
When did your bank last confirm its settlement instructions with each active counterparty?
Keep in mind: Never accept a changed instruction by email alone. Treat every change request as a possible fraud attempt.
STEP 6
Keep Reference Data Owned After Go-Live
Reference data needs care after cutover. New instruments arrive daily, bonds mature, issuers merge and counterparties change their details. Name a data owner for each domain, define who may change what and check vendor feeds every day. Close the old maintenance screens so that changes happen only in the new platform.
Regulators notice when reference data decays. The FCA wrote that inaccurate or incomplete instrument reference data limits our ability to conduct effective market oversight. It found venues failing to populate the termination date even after the instrument has matured or expired. The same gaps appear in a bank's own instrument master if nobody owns it.
✓
Name one data owner for each reference data domain
✓
Check vendor feeds and exceptions every day
✓
Close maintenance screens in the old systems at cutover
Who in your bank corrects an instrument record when the vendor feed is wrong?
Keep in mind: Two teams that can both change the same table will create two versions of the truth within weeks.
The Silo Effect | Gillian Tett (US Managing Editor @ Financial Times)
SAMPLE CASE
HSBC
UK deposit-takers must mark certain accounts so that protected deposits can be identified for the Financial Services Compensation Scheme (FSCS). Accounts held for beneficiaries must be marked in a way that allows for their immediate identification. These markings are classification data on every account.
The PRA found that the root cause of these issues stemmed from the 2018 ring-fencing. The ring-fencing project did not adequately address FSCS requirements within HBEU. It also found that the code used to extract data from source systems was not subject to regular review. HSBC Bank plc incorrectly classified 99% of eligible deposits by value as ineligible for FSCS protection.
The PRA noted that had the PRA not made enquiries, it is unclear when HBEU would have discovered the errors. On 30 January 2024, it fined HSBC Bank plc and HSBC UK Bank plc £57,417,500.
Key takeaway: Classification flags are reference data too. When a migration or restructuring moves accounts, test every flag that feeds a regulatory report, not only the balances and positions that everyone checks.
"The serious failings in this case go to the heart of the PRA's safety and soundness objective."
Sam Woods (Deputy Governor for Prudential Regulation @ Bank of England)
In Short
Reference data in a bank migration needs its own plan: an inventory of every domain, one golden source per domain, a load order that puts reference data before positions, checked identifiers, confirmed settlement instructions and named owners after go-live.
The result is a platform where positions find their instruments, trades settle on time and regulatory reports draw on flags that someone has tested. Clients and supervisors see the same data before and after cutover.
Frequently Asked Questions
What is reference data in banking?
Reference data in banking describes the things a bank deals with rather than its transactions. It covers instruments and their identifiers, issuers, counterparties, settlement instructions, holiday calendars, currencies, country codes and internal code lists such as product types. Many systems use the same reference data, so one wrong value can affect trading, settlement, risk and regulatory reporting at once.
What is the difference between reference data and master data?
Reference data is a set of permitted values or descriptions that classify other data, such as currency codes, instrument types or holiday calendars. Master data describes the core entities a bank works with, such as clients, accounts and counterparties. Master data records often use reference data as attributes. Both change less often than transactions and both need clear owners.
What are standard settlement instructions?
Standard settlement instructions, or SSIs, tell a bank where to deliver or receive cash and securities for a counterparty. They hold details such as the custodian, the account, the place of settlement and the currency. Banks exchange and store them so trades can settle without manual input. A wrong or outdated SSI leads to failed settlement or misdirected payments.
TAGS
ABOUT THE AUTHOR
Alexander Kiel
Business Analyst for process optimisation, data migration, business integration and project support in banking and wealth management. Lean Six Sigma Green Belt and Certified Scrum Master. Former private banking front office, with front-to-back experience from client advisory to data and systems.
KEEP READING
Related Articles

DATA MIGRATION
5 SEP 2026 · 8 MIN READ
Delta Migration After the Initial Load
How banks move the changes made after the initial load: fix the start point, capture every change including deletes, apply them in order, reconcile each delta and drain the last one.

DATA MIGRATION
13 JUN 2026 · 8 MIN READ
Migrate, Archive or Delete Legacy Data
How banks decide what happens to legacy data in a platform change: sort it by status, set the history depth, archive what must be kept, delete the rest and record each decision.

DATA MIGRATION
18 APR 2026 · 8 MIN READ
Source to Target Mapping for Bank Data
How banks map old data to a new platform: start from the target fields, profile the source, build the mapping sheet, translate code lists, get sign-off and test every rule.