By Prasad Patil, CTO & Chief – Business Operations, Mobicule Technologies
For most of the last decade, collections technology in India’s BFSI sector has been built around a fairly simple assumption: that the rules governing how a bank, an NBFC or an HFC can pursue a defaulting borrower are stable enough to be written directly into the platform’s code. Interest computation methods, penal charge structures, communication windows, escalation timelines and recovery workflows were designed for the specific lender category the institution belonged to and then embedded deep within the application logic. It worked, largely because regulatory change in this space was infrequent and incremental.
That assumption is now being tested. The Reserve Bank of India’s draft circular from August 12, 2026 which proposes to harmonise interest rate frameworks across banks, NBFCs and HFCs ahead of an April 2027 effective date, is the latest in a string of regulatory moves that are converging previously distinct rulebooks into a more unified, and more fluid, compliance environment. For collections platforms built on the old assumption of stability, this convergence is proving difficult to absorb.
Where regulatory logic has traditionally lived
In most legacy collections systems, regulatory requirements are not treated as a separate, governable layer. They are woven into the core application, often across multiple modules simultaneously. A penal interest rule might sit inside the payment engine, a borrower communication restriction might be coded into the field agent app, and a category-specific escalation timeline might be buried in the workflow engine. Each of these was originally built to reflect the specific obligations of a bank, an NBFC or a housing finance company, on the reasonable premise that those obligations would not need to move often.
This approach is not the result of poor engineering. It reflects how regulation itself used to function as a set of category-specific rules that lenders complied with on their own terms and timelines. The architecture mirrored the regulatory structure of its time.
Why is this becoming a constraint?
The difficulty is that regulatory logic embedded this way is expensive to change. When a rule is hardcoded across several modules, updating it is rarely a single edit. It typically requires locating every instance where that logic appears, testing each dependent workflow, and validating that changes made for one lender category have not inadvertently affected another. For institutions operating across multiple lending lines, or for platform providers serving both banks and NBFCs, this multiplies quickly.
The current wave of RBI guidance is exposing exactly this weakness. Beyond the August 12 draft on interest rate harmonisation, the central bank’s August 6 proposal to restrict NBFCs to term loan products, and its pending Model Risk Management guidance, all point toward a compliance environment that will keep evolving rather than settle into a new steady state. A collections platform architectured around fixed, category-specific logic is not well positioned for that reality. Every subsequent circular becomes another rebuild rather than a routine update.
The shift toward configurable architecture
What is emerging in response is a move away from hardcoding regulatory rules into application logic and toward treating compliance parameters as configurable, governable data that sits above the core platform. In this model, interest computation methods, penalty charge caps, communication windows, and escalation rules are defined as parameters that can be updated through configuration rather than code changes. The underlying collections workflow, whether it involves early-warning triggers, borrower segmentation or phygital engagement across digital and field channels, stays intact. At the same time, the regulatory layer above it can be adjusted independently.
This is a meaningful architectural shift, not a cosmetic one. It requires collections platforms to be designed from the outset with a clear separation between business logic and regulatory logic, with the latter exposed through rule engines and governance layers that compliance teams, rather than engineering teams, can manage. Done well, it means a change like the RBI’s proposed interest rate harmonisation can be implemented as a configuration update tested against the new framework, rather than a months-long re-engineering exercise across every affected module.
Where AI and governance fit in
Configurability alone is not sufficient. As collections platforms increasingly rely on AI for tasks like borrower risk scoring, propensity-to-pay modelling and channel selection, the same discipline needs to extend to how these models are governed. AI-driven decisions in a regulated recovery process need to be explainable, auditable and adjustable in step with the regulatory framework they operate under, not treated as static once deployed. A platform that decouples regulatory logic from business logic is naturally better placed to extend this discipline to its AI components as well, since both are governed through the same configurable, auditable layer rather than buried inside fixed code.
This is the direction the industry is heading in, whether the trigger is interest rate harmonisation, the NBFC lending restrictions under discussion, or the risk management guidance still to be finalised. As regulatory expectations around debt collection continue to evolve, the platforms best equipped to keep pace will be the ones that were designed for change from the start, not the ones that are fastest to patch around it after the fact.