Data Enrichment, Normalisation and Reference Data

Enrichment adds information the customer did not supply, using data the bank already holds. When a customer sends EUR 12,400 to a supplier in France and gives only an IBAN, the bank looks up the BIC from the IBAN, confirms the bank name is BNP Paribas, and adds the country code FR. When a corporate customer sends a salary file with employee numbers only, the bank looks up each employee account and name from its customer master file. When a payment is marked urgent, enrichment adds the correct cutoff time and the fee for that service. Each enriched value is marked as derived, so an investigator can later tell which values came from the customer and which values the bank added. Normalisation makes the same value look the same every time, whichever channel supplied it. Names are stored in upper case or in title case according to one agreed rule, extra spaces are removed, and punctuation is handled consistently. Addresses are split into the same lines in the same order, with the town, postcode, and country code in fixed positions. A phone number supplied as plus 44 20 7946 0958 is stored in the same format as one supplied as 02079460958, and a date supplied as 6 Nov 2026 is stored as 2026-11-06. Without normalisation, the same customer can appear as three different people in screening, reporting, and reconciliation, and that creates false alerts and missed matches. Reference data is the shared lookup information that every payment depends on, and it must be maintained with care. The currency table states that EUR has two decimal places, JPY has none, and BHD has three, and it states which currencies the bank can send. The country table maps DE to Germany and SG to Singapore, and it records which countries are subject to extra checks. The bank calendar states that 25 December is a holiday in London but a working day in some other centres, and the cutoff table states that a payment to the euro area must be released by 2 in the afternoon London time for same day value. If reference data is wrong, even a perfect payment can be rejected or delayed. Standing data about charges, limits, and customer agreements is also applied during enrichment. A corporate customer may have an agreement that all payments to suppliers in the euro area carry a fixed fee of EUR 15.00, while a retail customer may pay GBP 25.00 for an urgent international transfer. A customer may have a daily limit of GBP 50,000 for online payments, and a payment of GBP 60,000 must be split, approved by a second person, or sent through the branch. The canonical model records the fee that was applied, the limit that was checked, and the agreement that governed the decision, so the customer statement and the bank ledger agree with each other. Consider a payment that shows why enrichment matters in practice. A customer in Manchester sends GBP 9,850 to a new supplier in the Netherlands and types the IBAN NL91 ABNA 0417 1643 00 with a space in the wrong place. Normalisation removes the spaces and validates the check digits, enrichment derives the BIC ABNANL2A and the bank name ABN AMRO, and reference data confirms that NL is the Netherlands and EUR is the expected currency for that account. The payment is then converted at the agreed rate, the fee of GBP 15.00 is added, and the payment is released with a complete record. Without those steps, the same payment could have been rejected for an invalid IBAN or sent without the bank identifier the next bank needed.