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.
Alexander Kiel
Business Analyst · Banking & Wealth Management
18.04.2026 · 8 MIN READ · DATA MIGRATION
ON THIS PAGE
1. Start From the Target Fields
2. Profile the Source Before You Map
3. Write the Source to Target Mapping
4. Translate Code Lists and Identifiers
5. Get Sign-Off From the Data Owners
6. Test the Mapping With Real Records
Sample case: Commonwealth Bank of Australia
In short
FAQ
Source to target mapping links every field of a new platform to its origin in the old systems, with the rule that turns one into the other. Errors are expensive: MIT Sloan Management Review estimates the cost of bad data to be 15% to 25% of revenue for most companies. In banking, the ECB wrote in May 2024 that adequate RDARR capabilities are still the exception.
Payments show what is at stake. On 22 November 2025, cross-border payments ended the coexistence with the old MT format. The day before, Swift observed 97% of payment instructions sent using ISO 20022. The next step follows soon: after November 2026, payments containing unstructured addresses will no longer be supported.
A mapping is only as good as its weakest rule. One field mapped wrongly can pass every total and still send wrong data to clients or regulators. Does your bank know who wrote each mapping rule and who approved it?
STEP 1
Start From the Target Fields
Begin with the new platform, not the old one. Export every target field with its format, length, mandatory flag and allowed values. Each target field then needs one answer: where its value comes from. Working from the source side moves fields nobody needs and misses fields the new platform requires.
The Basel Committee expects a bank to have a dictionary of the concepts used, so that data is defined consistently. A structured address under ISO 20022 requires a minimum of the TownName and Country to be included in a structured format. A legacy field with three free-text lines cannot fill that without a rule.
✓
Export every target field with format, length and allowed values
✓
Mark each field as mandatory, optional or derived
✓
Write a one-line business definition for each target field
Which mandatory fields on your new platform have no obvious source in today's systems?
Keep in mind: Default values fill gaps quickly but also hide them. Record every default and the reason for it in the mapping sheet.
STEP 2
Profile the Source Before You Map
Profile each source field before you write a rule. Count empty values, distinct values, formats and outliers. A field called country may hold ISO codes, country names in three languages and free text. Profiling turns these surprises into known cases before the first trial load.
The Basel Committee wants data aggregated on a largely automated basis so as to minimise the probability of errors. Banks must also explain the appropriateness of any manual workarounds. Every value a mapping rule cannot handle becomes such a workaround. My article on the data quality framework shows how to measure data against clear rules.
✓
Count empty, distinct and invalid values for every source field
✓
List each format variant a field contains today
✓
Share the profiling results with the business owner
How many different spellings of the same country does your client master hold today?
Keep in mind: Profile production data, not a test copy. A test copy may be older or cleaner than the records it was taken from.
STEP 3
Write the Source to Target Mapping
Keep one row per target field. Each row names the target field, the source system and field, the transformation rule, the default, the owner and the status. Add a version number and a change log. The sheet becomes the single reference for developers, testers and auditors, so nobody has to read code to understand a value.
Supervisors expect the same trail. The ECB asks for complete and up-to-date data lineages on data attribute level, from data capture through extraction, transformation and loading. The sheet is the lineage of the migration itself. My article on data migration strategy shows where the mapping fits into the wider plan.
✓
Use one row per target field with a named owner
✓
Write each rule so a business user can read it
✓
Version the sheet and log every change with its reason
Could an auditor trace one client's risk profile on your new platform back to its source?
Keep in mind: A rule written only in code is invisible to the business. Keep the sheet and the code in step at every release.
STEP 4
Translate Code Lists and Identifiers
Code lists need their own mapping. Country, currency, client type, risk profile, product and transaction codes often differ between systems. Build a translation table for each list and decide what happens to a value without a match: stop the load, use a default or send it to a review queue. Identifiers need the same care: one client keeps one key.
Use international standards wherever the target allows. ISO 4217 represents currencies with a three-letter alphabetic code and a three-digit numeric code. For legal entities, the LEI is a unique 20-character alphanumeric code that shows who is who and who owns whom. The Basel Committee also asks for single identifiers and/or unified naming conventions for data.
✓
Build a translation table for every code list
✓
Decide the action for each value without a match
✓
Keep one identifier per client, account and counterparty
What does your migration do today with a currency or country code it does not recognise?
Keep in mind: A code added to the old system after sign-off has no rule. Freeze the code lists or monitor them until cutover.
STEP 5
Get Sign-Off From the Data Owners
IT can write the rules, but only the business can confirm what a field means. Ask each data owner to review the rows for their domain, such as clients, accounts, positions, cash or static data. They confirm the definition, the rule and the default, then sign off a numbered version of the sheet. Changes after sign-off go back to the same owner. A lesson I took from a decommissioning project is that responsibility for each migration step must be clear before the work starts.
The ECB expects data owners responsible for key risk indicators and critical data elements. It also asks for uniform data definitions and glossaries with clear ownership of data. Owners should be managing metadata relating to the data lineage and data dictionary. The mapping sheet is that metadata.
✓
Name one business owner per data domain
✓
Sign off a numbered version of the mapping sheet
✓
Route every later change back to the same owner
Who in your bank can confirm what risk profile 3 means in each of your systems?
Keep in mind: A sign-off on a sheet nobody read is worthless. Walk owners through real records, not only through the rules.
STEP 6
Test the Mapping With Real Records
Test every rule with real records before the first full trial. Pick sample clients for each rule and edge case, run them through the mapping and compare the result with what the owner expects. Then reconcile counts and key fields after each trial load. When a test fails, fix the rule in the sheet first and the code second.
The FCA fined Goldman Sachs International £34.3 million after 220.2m errors in its transaction reporting. The failings related to its maintenance of the counterparty reference data used in its reporting and to its change management. My article on reconciliation automation shows how to match records at scale.
✓
Test each rule with sample records and edge cases
✓
Reconcile counts and key fields after every trial load
✓
Fix the mapping sheet first, then the code
Which rule in your mapping has never been tested with a real client record?
Keep in mind: Matching totals do not prove a correct mapping. A swapped code can pass every count and still be wrong.
The Next Web of Open, Linked Data | Tim Berners-Lee (Founder @ W3C)
SAMPLE CASE
Commonwealth Bank of Australia
When Commonwealth Bank of Australia (CBA) introduced intelligent deposit machines, it set up an automated process for threshold transaction reports to AUSTRAC. These reports cover cash transactions of $10,000 or more. The process identified cash deposits by searching for certain transaction codes.
In November 2012, to correct an error message, a new transaction code was applied in respect of some cash deposits through IDMs. The reporting process was not updated to search for that new transaction code. Until it was corrected in September 2015, it did not generate TTRs for 53,506 deposits of $10,000 or more.
CBA admitted the late filing of 53,506 Threshold Transaction Reports along with other breaches. In June 2018, CBA and AUSTRAC agreed a $700 million penalty to resolve the proceedings. CBA said the late reports were all caused by the same single systems-related error.
Key takeaway: A mapping is never finished while the source system still changes. Treat every new code in an old system as a change to the mapping, with an owner, a rule and a test.
"While not deliberate, we fully appreciate the seriousness of the mistakes we made."
Matt Comyn (Chief Executive Officer @ Commonwealth Bank of Australia)
In Short
Source to target mapping for bank data works when it starts from the target fields, profiles the source and keeps one sheet with one row per field. Every code list gets a translation table and every rule gets an owner's sign-off and a test with real records.
The result is a migration where every value can be explained, every change has an owner and a new code in an old system does not go unnoticed.
Frequently Asked Questions
What is source to target mapping?
Source to target mapping is the documented link between each field of a target system and its origin in one or more source systems. For every target field it records the source field, the transformation rule, any default value and the owner. Developers use it to build the migration, testers use it to check results and auditors use it to trace values.
What should a source to target mapping document include?
A source to target mapping document needs one row per target field. Each row shows the target field and its definition, format and mandatory flag, the source system and field, the transformation rule, the default value, the data owner and the status. A version number, a change log and the translation tables for code lists complete the document.
What is the difference between data mapping and data lineage?
Data mapping defines how a field in one system becomes a field in another, usually for one migration or interface. Data lineage traces the full path of a data element from capture to report, across every system and transformation. A mapping document supplies part of the lineage, but lineage is kept up to date for as long as the data is used.
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
16 MAY 2026 · 8 MIN READ
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.