At a manufacturer or an installation company, a large part of the value lies in people, machines and processes that you can see and touch. In financial services, the value lies mainly in licenses, documented procedures, client files and the way an organisation demonstrates that it is in control. That ratio — more regulation and files, fewer physical assets — determines what is at stake in a merger or acquisition. An integration that moves too fast here affects not only the operation but also the license on which that operation depends.
That is a different order than in most sectors. In an integration in construction or installation engineering, the question is often whether processes and equipment can logically be combined. At a bank, insurer, pension administrator or asset manager, the question that arises is whether the combination preserves the license, the supervision and the client trust. Anyone who treats that as a side issue gets stuck at the moment it really matters.
A second obstacle is the core systematics: the core banking system, the policy administration system, the investment platform. These systems contain not only data but also the logic with which products are calculated, premiums are set or interest is credited. Running two such systems side by side is manageable for a limited period, but over time becomes a risk in itself: every change then has to be implemented and tested twice.
The question is not only which system survives, but also when that choice must be made and what can go wrong in the meantime. That is precisely where a synergy baseline and a Day 100 plan make a difference: not as a prediction, but as a structure that records which dependencies exist between the system choice and everything that depends on it, from reporting to client communication.
Where companies in other sectors can freely adjust their reporting cycle to the merger, in financial services the reporting obligation to supervisors remains fully in force. Capital ratios, solvency, liquidity position — these must be reported regardless of what phase the integration is in. An integration plan that does not take this into account as a fixed boundary condition runs the risk that operational choices clash with reporting obligations that are not negotiable.
This is one of the places where the standard question of this approach sounds loudest: should this part actually be integrated, or is keeping it separate — at least for a period — the wiser path. For compliance and risk functions that question is more often relevant than for most other departments, because merging two risk models can result in a new, untested model.
A third obstacle is less visible but no less far-reaching: client files, powers of attorney and mandates are often personal and linked to a specific advisor or relationship manager. An integration that redistributes clients or migrates systems directly affects the relationship that underlies the business model. Where a manufacturer mainly sees a client as a buyer, in financial services the client is often the one who has entrusted their assets, their mortgage or their pension. Mistakes made at this stage are hard to undo.
This calls for a Day 1 plan that is not only technically drawn up, but also indicates which client contacts must remain unchanged in the first period and which depend on a system switch that has not yet taken place. The decision list — what is merged, what remains separate, and on the basis of which consideration — is not a formality here but an instrument to prevent unnecessary damage.
A final obstacle is less tangible than systems or licenses, but no less relevant: the risk appetite of the two organisations. An insurer with a conservative underwriting culture and a fintech with a growth-oriented approach can both be healthy, but clash as soon as they have to operate under one roof. This kind of difference is comparable to what can be read in what makes integration difficult in construction and in the bottlenecks in integration in the installation sector, where operational culture is also often underestimated. In financial services this plays out in risk models, acceptance policy and the way employees deal with grey areas in regulation.
This mix of license dependency, system coupling, reporting obligations, client relationships and risk culture means that a generic integration approach quickly falls short here. Similar, sector-specific considerations apply to the bottlenecks of integration in the energy sector and to the obstacles in integration in the real estate sector, and there too: the sector determines which dependencies are most critical, not the merger itself.
Anyone who has mapped these bottlenecks faces the next question: which part of the expected synergy is substantiated and which part is assumption. That question returns in substantiating synergy in a buy-and-build and in the question of who within the organisation owns a synergy figure. Without ownership, a synergy baseline remains a document without consequences.
Many of the bottlenecks described here — duplicate reporting, duplicate systems, duplicate control functions — consist of tasks that recur at a fixed frequency. For organisations that want to know which part of that work can be supported with AI, the work scan of FTE TO AI indicates per task which part is eligible for takeover, so that outcome can play a role in the choices recorded in the Day 100 plan.
Vraag maar wat er op Day 1 moet staan, of wat integreren juist kapotmaakt.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.