Data Migration Where Reconciliation Matters
Mergers, acquisitions, portfolio transfers, and core-system replacements in banks and insurers move customers, accounts, policies, products, balances, and years of transactions between systems that define a product differently, inside a short business window, under auditors who expect every amount to be accounted for.
Why Financial-Services Migrations Are Difficult
What distinguishes core banking and insurance migrations from other industries. Each one is a business question before it is a technical one.
Products are defined by the data, not by the catalogue
On a core banking file a product is a combination of values: account type, class code, rate plan, fee waiver, statement cycle. On a policy file it is a combination of line, coverages, riders, tariff, and payment plan. The combinations that actually exist, each with its number of accounts or policies and its balance or premium, are the real product list, and it is always longer than the catalogue. Each one needs a target product or an explicit decision.
Every amount has to balance
Balances, accrued interest and charges, floats and holds in a bank; premiums, reserves, outstanding claims, and commissions in an insurer. Totals by account or policy, by product, by branch or agent, and against the general ledger are taken at extract, after transformation, and after load, and every difference is explained before business resumes.
Many systems, one customer
Deposits, loans, cards, securities, and collateral; or policy administration, claims, billing, reinsurance, and agent commissions. Twenty or more core applications is typical, each with its own master file, and one customer appears in most of them. The relationships between them have to survive the move, not only the records.
Mergers, acquisitions, and portfolio transfers
When one company’s data goes into another’s production systems, the receiving systems will not be redesigned for the newcomer. Products, numbering, customers, and history all have to fit what is already there, the date is set by the deal and the regulator, and on the first business day the acquired customers expect their accounts, policies, cards, and payments to simply work.
Two companies, one numbering
Branch, account, policy, and claim numbers collide, and the same customer exists in both companies under slightly different names and addresses. Numbers are reassigned with a cross-reference that cheques, direct debits, standing orders, cards, and open claims still have to find; customers are matched before they are merged.
Interest, premiums, and dates in flight
Accounts are converted mid-cycle: interest accrued to the day, statement cycles half complete, rate changes and maturities scheduled. Policies are converted mid-term: premiums partly paid, renewals due, claims open with reserves set. The target has to continue accruing, billing, and settling as if it had always held them, to the cent.
A business window measured in hours
In a bank the conversion runs between close of business and the next opening, usually over a weekend, with the whole organisation waiting. Insurers have more room, but claims, payments, and renewals still cannot wait long. Throughput is designed from the mapping, not tuned at the end, and the window is proven in a dress rehearsal on the full file.
History the customer and the regulator can see
Years of transactions, statements, policy versions, and claim files are kept for the regulator and shown to the customer online. They sit in formats different from the master files and are often larger than everything else combined. Whether each year is migrated, archived, or kept read-only is a decision with a cost on both sides.
Secrecy, solvency, and the regulator
Personal and financial data under banking or insurance secrecy and data-protection law, consents before an extract leaves a system, KYC and anti-money-laundering records that must continue without a gap, reserves that feed solvency reporting, and a regulator and auditors who will ask how each figure got where it is.
Start With the Products, Not the Fields
The value profile of each source file shows which field values occur and how often. The fields that define a product are selected, and every combination found in the data is listed with its number of accounts or policies and its total balance or premium. That list, not the product catalogue, is matched to the target’s products in a product matrix. Combinations the target cannot hold are product gaps, and they are decided by the business before field mapping starts, because the field mapping depends on the answer.
- Profile
- Combinations
- Product matrix
- Gaps
- Set-up
The same comparison runs at value level for every mapped field: transaction codes, hold codes, claim and policy status codes with no target equivalent, values the code book does not list, and documented values that never occur in the file.
Principle: expose gaps earlyWhat This Means for the Project
Products are mapped before fields
The product matrix, source product to target product with accounts or policies and amounts per line, is agreed first. Product gaps go to the business for a decision and to the target team for set-up, which must exist before system test.
Day one is designed from the customer’s side
Old-to-new account and policy cross-references, cards and cheques that still clear, direct debits and premium collections that execute on the first business day, statements and claim files that show the history: each is a migration requirement that is mapped, tested in the rehearsal, and proven, not assumed.
Balancing is part of the mapping
For each amount, count, and key field the mapping records how it is balanced and against what. The balancing reports are generated from the same mapping as the conversion program, so the proof cannot drift from the rules.
Balanced, Then Proven
Balancing answers whether the totals agree: record counts and hash totals per field, balances, premiums, and reserves by product, branch or agent, and ledger account, at extract, after transformation, and after load. Proof answers whether each account and policy is right: the data is extracted back from the target and compared with the source at record and field level under the approved rules, and the result, with every explained difference, is the audit trail of the conversion.
Principle: prove it, do not assume itPlanning a Financial-Services Data Migration?
Let's examine the source environment, target objectives, and migration challenge.