Leadership1 publisher3 min readPublished
Discovery scope decides a core banking migration months before go-live
Roman Eloshvili of XData Group writes that banks map their standard customer journeys and skip the exceptions, and that the exception cases are what settle where the new core's ownership ends and CRM, AML and reporting begin.
The Board Room · Leadership desk
What happened
- Roman Eloshvili, founder and CEO of XData Group, writes in Forbes that a lot, if not most, failed core banking migrations fail in the months before go-live and not at the cutover itself.
- His central claim is that treating a core system replacement as primarily an IT task is the biggest misconception, because the migration changes products, business processes, data ownership and integrations.
- KYC, AML and sanctions platforms are treated as tools separate from the core, yet their checks govern account opening, product eligibility, transaction approval and account freezes.
Compiled by The Board RoomSomething wrong?How this is made
Why it matters
- decision Deciding what the new core owns and what stays in CRM, AML or reporting is a business call that gets settled during discovery. A bank that runs discovery as a technical inventory has made that call without the business in the room.
- constraint The scarce input is the time of the few people who hold the undocumented product logic. Someone else has to cover their day jobs, and that staffing cost belongs in the plan and the budget before the vendor contract is signed.
- exposure One customer-status field maintained two different ways reaches account opening, product eligibility and transaction approval. The failure surfaces in compliance decisions, and the availability dashboard will not show it.
What the new core owns is not a technical question, and it gets answered during discovery. "Without understanding complete end-to-end business processes and the full scope of a bank's operations," Eloshvili wrote, "it becomes almost impossible to define what the new core should actually own and what should remain in surrounding systems such as CRM, AML or reporting platforms" [8]. Once that line is drawn, it fixes which system holds a customer's status and which team has to go and ask for it.
The tradeoff he names is between discovery time and exception coverage. Banks build their inventories of applications, APIs and interfaces around standard journeys such as opening an account, making a payment or calculating interest [6]. Reversals, overdue loans, account freezes, manual adjustments and operational exceptions get less attention, and he wrote that these are often the hardest parts of the migration [7]. Banks also assume the legacy systems are documented. But "the knowledge behind certain products, calculations or exceptions often exists only in the minds of a handful of specialists who directly worked on them" [9]. Ask those specialists to run the migration and the day job at once and bottlenecks appear. The space to do the migration work has to be in the plan from the start, he argues [10].
Integration counts are the other place where the board deck makes the project look simpler than it is. Executives reviewing architecture diagrams see dozens or hundreds of integrations, and Eloshvili wrote that "the number is much less important than what each of those integrations represents" [11]. One payment interface sits on authorization, reservation of funds, clearing, settlement, reversals, reconciliations and their exceptions [12]. KYC, AML and sanctions platforms are treated as separate tools. Yet their checks decide whether an account can be opened, who can use which product, whether a transaction is approved and whether an account is frozen [13]. If two systems hold different versions of a customer's status, the inconsistency spreads through the bank [14].
This is also a vendor's case for a longer paid discovery phase. Eloshvili runs a B2B software development company selling into the European banking sector [1]. The Forbes column does not include failure rates, named engagements or a dated project. The rest of it is checkable inside any bank without buying anything: ask who can explain how an overdue loan reversal is booked, and whether the answer exists in a document or only in a person's head. He also concedes that some of the dependencies never appear in technical documentation at all, because manual reconciliations and informal workarounds persist on the strength of what experienced employees know [15].
The sequencing is what makes this a decision for this quarter. A core replacement sets a bank's data-ownership map for years, and Eloshvili wrote that "by the time the technical migration begins, many of the decisions that determine its success or failure have already been made" [3]. Scope is cheapest to change during discovery. A bank that staffs discovery as an IT inventory, with the same specialists still carrying daily operations, will find out at cutover which processes nobody owned [5].
What to watch
- A named case study with failure rates or dated projects would turn this practitioner argument into evidence.
- Migration plans that budget backfill for the specialists holding undocumented product logic, showing up as staffing lines in the plan.
- Any bank that publishes its post-migration ownership map for customer status across core, CRM and AML systems.