Demerger and Post-Merger Reconciliation Separation

Iain Colquhoun
Apr 21
5 min read

Separation is a reconciliation event before it is a legal one. A bank demerger separates two balance sheets. That is the easy part. What it actually separates is every data feed, every reconciliation account, every match rule, every user profile, every scheduler job that was built under one parent and now has to run as two.

This document describes the reconciliation separation framework applied to a Tier 1 UK bank demerger, covering the As Is to To Be RACI rebuild, the import format library rebuild across five data feed types, the SIT and UAT test coverage across six domains, and the cutover to go-live sequence.

At a glance

2 Entities. Parent estate and new entity running from day one.
5 Feed Types. Swift, Ledger, Faster Payments, SEPA, FX rates.
6 Test Domains. Static, user access, recon workflow, import, data feed, audit.
Day 1 Go-Live Continuity. No reconciliation day lost across the separation event.

The separation problem

Demergers are sold as legal events. They are actually data events. The legal separation has a published date and a public narrative. The reconciliation separation has neither, and has to be delivered to the same date.

A reconciliation estate under a parent bank is rarely architected as two independent environments that can be pulled apart cleanly. It has been built up over years: shared match rules, shared user populations, shared static configuration, shared scheduler jobs, shared service provider contracts. A demerger forces that shared environment to become two independent ones on a fixed date, with no disruption to daily reconciliation continuity and no loss of audit trail.

What actually has to be separated

Static configuration. Every balance pool, account, match rule, lookup table, common view, department, class.
Data feeds. Every inbound file type: Swift, core ledger, payment schemes, SEPA, FX rates.
User populations. Profiles rebuilt for the new entity, transition access defined.
Scheduler and batch. Every automated job, independent on the new side.
Reporting. Ownership, distribution, sign-off routes.
Service provider contracts. Independent ticketing, change process, service levels.

As Is to To Be: the RACI rebuild

A proper RACI for a Tier 1 reconciliation estate runs to several hundred activity lines. It is not an artefact. It is the governance contract between the business, the new IT function and the service provider.

The starting point is a full activity-level RACI, not the diagram that sits in a programme deck, but the working document used daily to manage the transition. For each activity, two states sit side by side: the As Is state describing who did what before separation, the To Be state describing who does what after. The split is rarely one-for-one.

Activity groups covered

Platform static configuration. Every static change type the platform supports.
User access. Creation, profiles, privileges, SSO, leavers.
Data feeds and import pipeline. Format creation, amendment, reject batch handling.
Reconciliation workflows. Match, unmatch, write-off, proof, sign-off.
Break management. Investigation, allocation, ageing, classification.
Reporting and audit trail. Creation, distribution, retention, evidence production.

Import format rebuild

Every data feed into the reconciliation engine has to be rebuilt for the new entity. File naming changes. Delivery paths change. Reformatter rules change. Account mapping changes. None of it is individually difficult. The volume is what creates the risk.

Five feed types. Two libraries. No reconciliation day lost. A Tier 1 UK bank reconciliation estate typically carries five data feed types: Swift MT950, core ledger extracts, Faster Payments, SEPA, exchange rate files, each with multiple variants by geography, currency or account type.

The operational control that matters most during cutover is the reject batch. Every file that fails validation lands in the reject batch. During parallel running, reject volumes on the new side are the single clearest signal of which format changes have not been correctly specified. The reject batch is not a backlog to clear; it is an operational control, and it has to be treated as such from day one.

SIT and UAT test coverage

SIT validates the technical stack. UAT validates the business workflow. Both are required. Collapsing them into a single testing phase is a recurring cause of go-live failure.

Six test domains across two phases. Static configuration, user access, import and reject management, reconciliation workflow, data feed end-to-end, audit trail. SIT validates the technical stack, the service provider can execute the configuration on the new platform. UAT validates the business workflow, operations teams can run their day-to-day activities under the new operating model.

Test coverage in a separation is not just about finding bugs. It is about producing the documented evidence that the new entity can demonstrate to its regulator, its auditor, and its own board that the reconciliation estate on day one is doing exactly what it was doing on the last day under the parent.

Cutover, parallel running and go-live

Every workstream converges on the cutover date. The reconciliation separation has two specific deliverables at that date: the new environment running live, and the transition evidence the auditor will ask to see.

Parallel running is the single most effective control against go-live failure. Old and new environments process the same reconciliation population from the same source data. Outputs are compared at end of day. Differences are investigated and resolved before cutover. Length is defined by how long it takes to see every data pattern the environment produces; month-end and quarter-end are the hardest to catch.

The cutover sequence

Pre-cutover. Final parallel run. Differences signed off. Freeze applied.
Cutover window. New feeds activated, legacy deactivated, user access switched, scheduler jobs live on new side.
First live day. End-to-end reconciliation on new environment. Outputs compared to last parallel run.
Rollback window. Defined period (typically 1-2 weeks) where legacy can be reactivated.
Stabilisation. First month-end and quarter-end completed. Legacy decommissioned or carved down.

Separation failures are architectural, not engine problems

Reconciliation separation failures are almost never caused by the reconciliation engine.

They are caused by what happens upstream of it. Every problem traces back to one of a small number of architectural errors:

RACI built as a diagram, not a working document. Handoffs between business, new IT and service provider undefined in practice.
Import formats ported without retest under new entity account naming. Records silently reject or route to wrong accounts during cutover.
SIT and UAT collapsed into one phase. Technical and workflow issues block each other in the same queue.
Parallel running cut short to meet legal completion. Month-end and quarter-end data patterns not seen.
First audit evidence produced retrospectively. Programme team reconstructs sign-off chain and continuity proof weeks after the event.

Adding more test cycles to a separation that has not been scoped properly does not reduce the risk. The correct approach is to go back to the activity-level RACI, define the separation data architecture around it, and build the test coverage against that foundation.

This framework is platform-agnostic. The architectural principles transfer directly across any automated reconciliation environment, regardless of the underlying platform.

Running a demerger, acquisition or post-merger reconciliation workstream?

ReconIQ is a specialist reconciliation advisory and consulting firm, bringing hands-on delivery capability, not advisory oversight, to Tier 1 banks, broker-dealers and asset managers across demerger, acquisition and post-merger integration events.

Get in touch. info@reconiq.co - reconiq.co
Author. Iain Colquhoun