Finacle Is Not Your Problem. Your Business Rules Are.
This post reached 4,000 impressions on LinkedIn — which tells me the observation resonates with everyone who has sat in a CBS escalation meeting. I have expanded it here with the full pattern, the mechanism behind it, and the structured approach that actually works.
In 18 years of banking technology delivery, every escalation labelled a platform issue landed on my desk eventually.
My experience across those escalations was consistent. Roughly 90% of what was reported as a Finacle problem, a Flexcube limitation, or a custom CBS defect was not a platform issue.
It was a business rule failure.
The platform was doing exactly what it was configured to do. The problem was that nobody had fully documented what it should do — and the gap between those two things had been invisible until the moment it became a crisis.
Why the platform gets blamed
The pattern is consistent across institutions and platforms. When something breaks in production, the first question is always: what changed? And the most visible recent change is almost always the platform — an upgrade, a patch, a configuration change, a migration.
So the platform gets the blame.
The institutional knowledge gap — the real cause — is invisible. It has no change log. It has no ticket number. It has no owner. It exists in the memory of a senior operations analyst who joined in 2008, or in a regulatory exception that was approved in a meeting nobody can now locate the minutes of, or in a workaround that was implemented during a crisis three product versions ago and never reviewed.
The platform is visible. The institutional knowledge gap is not. So the platform gets blamed.
I have seen this pattern across Finacle implementations, Flexcube deployments, and custom core banking builds at banks ranging from regional institutions to Tier 1 global banks. The platform is almost never the root cause. The documentation — or rather the absence of it — almost always is.
The three categories of undocumented rules
Across the CBS escalations I have managed, undocumented business rules fall consistently into three categories.
Rules that exist only in institutional memory
These are rules that were implemented correctly at the time, by people who understood them, but were never formally documented in a specification that survived beyond the people who wrote them. The configuration exists. The rationale does not.
When an upgrade changes how the platform handles the relevant scenario, the rule breaks. The escalation report says the platform behaviour changed. What actually happened is that the platform behaviour changed and nobody could explain why the old behaviour was correct — because the reason was in someone's memory, not in any document.
The most senior business analysts and longest-serving operations staff in your organisation are the custodians of this category. They know what the rules are. The risk is that they are the only ones who do.
Regulatory exceptions never entered into specifications
Regulatory accommodations are a particularly dangerous category of undocumented rule. A local regulator grants an exception to a standard requirement. The bank implements the accommodation. The implementation is correct. But the exception itself — the specific scope, the conditions, the expiry, the reporting obligation — is documented in a regulatory correspondence file that the technology team has never seen.
When the platform is upgraded or replaced, the technology team configures it to the standard requirement. The regulatory exception is lost. The bank is now processing transactions differently from the way the regulator was told it would process them.
This is not a platform failure. It is a governance failure — specifically, a failure to ensure that regulatory accommodations are reflected in the technology specifications that govern platform configuration.
Operational workarounds that became design
This is the most insidious category. A workaround is implemented to handle an edge case — perhaps during an urgent fix, perhaps as a temporary measure that became permanent. Over time, the workaround is used so consistently that it becomes indistinguishable from the intended design. New staff are trained on it. The operating procedures reference it. The exception reports monitor it.
Nobody remembers it was ever a workaround.
When the platform changes, the workaround no longer works. The escalation report says the platform broke something. What actually happened is that a workaround that had been elevated to the status of design was exposed as incompatible with the new configuration.
The most dangerous sentence in banking technology is this: "That is how we have always done it." It signals a rule for which no one has — or can find — a reason. And when the new platform asks why, nobody has an answer.
The standard directive — business rules harvest before technology assessment
Before any CBS upgrade or migration — Finacle version uplift, Flexcube reimplementation, custom platform replacement — I mandate the same first step.
Run a business rules harvest. Not a technology assessment.
The technology assessment comes later. It is important. But it cannot tell you what the platform should do — only what it currently does. The business rules harvest is what tells you what it should do. And that distinction is the difference between a migration that succeeds and one that generates an escalation list that runs for months.
The harvest methodology I have used across multiple engagements has five components:
Identify the knowledge carriers. In every bank I have worked with, there are five to ten people who carry a disproportionate share of institutional knowledge about how the core system actually operates. They are typically not the most senior people in the room. They are the longest-serving — the operations managers who have been there for 15 years, the business analysts who worked on the original implementation, the team leaders who have handled every edge case that has ever come through the queue.
These people are the first participants in the harvest. Their knowledge is the primary input. And their forthcoming retirement or departure is often the most urgent reason to run the harvest at all.
Structure the workshops by process domain, not by system module. The temptation is to organise the harvest around the platform's module structure — payments, accounts, treasury, reporting. Resist it. Organise it around the business processes — how does a payment instruction move from receipt to settlement, what happens when it fails, what are the exception paths, who has authority to override what.
Process-domain workshops surface the rules that matter. Module workshops surface the configuration that implements them — which is useful, but comes second.
Specifically probe for exceptions, overrides, and workarounds. The standard processing paths are usually documented, at least partially. The exceptions are not. Direct the workshops explicitly at the non-standard: what are the cases that do not follow the standard flow, who authorises them, how are they tracked, and — critically — why do they exist.
Cross-reference against regulatory correspondence. For every exception or non-standard treatment identified in the workshops, verify whether there is a regulatory accommodation behind it. If there is, obtain the original correspondence, confirm the current status of the accommodation, and ensure it is reflected in the migration specification.
Document to specification standard, not to meeting-notes standard. The output of the harvest is not a set of workshop summaries. It is a business rules specification — structured, version-controlled, owned by a named accountable party, and referenced explicitly in the migration design. The difference between a document that sits in a folder and a specification that governs a migration is ownership and process integration.
The cost of skipping the harvest
The business rules harvest adds time and cost to the front end of a migration programme. This is the objection I have heard most often, and it is a legitimate one — migration programmes are expensive, timelines are constrained, and the pressure to move quickly is real.
The counter-argument is also real: every undocumented rule that surfaces during migration costs more to resolve than it would have cost to document before the migration started. Significantly more — because the resolution happens under time pressure, with a partially migrated system, with unclear accountability for the fix, and with the risk that the resolution introduces a new inconsistency elsewhere.
I have sat in enough post-migration retrospectives to say with confidence: the programmes that invested in business rules documentation before migration spent less overall than the programmes that skipped it and paid the cost in escalations, timeline extensions, and parallel running periods that stretched long past their original scope.
The harvest is not a cost. It is a risk mitigation investment with a measurable return.
What this means for your next CBS programme
If you are planning a Finacle upgrade, a Flexcube migration, or any core banking platform change, the question to ask before you scope the technology work is this: do we have a documented inventory of every business rule, exception, override, and workaround in the current system?
If the answer is no — or if the answer is "mostly" or "I think so" — you have a knowledge gap that will surface during the migration. The question is not whether it will surface. It is when, and at what cost.
Run the harvest first. Document what the system should do before you migrate how it does it. Bring your knowledge carriers into structured workshops and get their understanding into a format that survives beyond their tenure.
The platform will do exactly what it is configured to do. Your job is to ensure the configuration reflects the full reality of your operating model — not just the parts that were formally documented when the system was first built.
Frequently asked questions
Why do core banking migrations fail?
Most commonly because of undocumented business rules — rules in senior analysts' memory, regulatory exceptions never entered into specifications, and operational workarounds that became indistinguishable from design. The platform gets blamed because it is visible. The institutional knowledge gap is not.
What is a business rules harvest in banking?
A structured documentation exercise before any CBS upgrade or migration. It brings the most senior business analysts and longest-serving operations staff into workshops to document every exception, override, and workaround. Not a bureaucratic exercise — a migration risk mitigation programme. Every undocumented rule is a potential failure point in the new platform.
How do you prepare for a Finacle or Flexcube upgrade?
Run a business rules harvest before the technology assessment. Identify your knowledge carriers — typically long-tenure operations staff, not the most senior people. Run process-domain workshops probing specifically for exceptions and workarounds. Cross-reference against regulatory correspondence. Document to specification standard with named ownership. Then scope the technology work.
What is the most dangerous phrase in core banking migrations?
"That is how we have always done it." It signals an undocumented rule for which no one has a reason. When the new platform asks why, nobody has an answer. That is when migrations stall, timelines break, and the platform gets blamed for what is actually an institutional knowledge failure.
Found this useful? I write weekly on core banking technology, CBS migrations, and the lessons 24 years across Citi, Standard Chartered, and 72 Indian banks taught me about what actually makes programmes succeed or fail. Subscribe to the newsletter — no spam, unsubscribe anytime.
Planning a CBS upgrade or migration? Explore my consulting services or get in touch directly.
Raj Thilak is Head of Technology for Data & Analytics with 24 years across Citi, Standard Chartered, Accenture, and Jio Financial Services. He has led Finacle implementations across 72 Indian banks and CBS migration programmes at Tier 1 global institutions. Based in Pune, India. rajthilak.dev
Found this useful? Subscribe for weekly insights.
Join the conversation
Loading comments...