When the RBI issued its circular RBI/2025-26/47 updating the liquidity coverage ratio requirements for small finance banks, the compliance teams reading it faced two distinct problems. The first was understanding what changed in the provision itself. The second was answering a different question entirely: which of our internal controls actually needs to be updated as a result?
Most compliance monitoring tools, including the better general-purpose document management platforms, address the first problem reasonably well. Some version-comparison tooling exists. PDF annotation is available. Alert systems can flag that a new circular has been published. But the second problem, the mapping from regulatory change to internal control, is the step most tools skip entirely. That gap is where a significant portion of compliance officer time disappears.
Why the Mapping Step Is the Hard One
A policy register in a regulated Indian financial institution is a structured document (or more often, a set of documents) that links each internal policy to the regulatory provision it implements. A liquidity management policy references the RBI's liquidity coverage ratio directions. A KYC policy references PMLA obligations and the RBI's Master Direction on KYC. A fair practices code references the Reserve Bank of India's fair practices code circular for NBFCs.
When a regulatory provision changes, the policy register entry that maps to it also needs to change. That sounds mechanical. In practice it is not, for several reasons.
First, the mapping in most policy registers is maintained at a level of granularity that does not correspond cleanly to how circulars are structured. A bank's liquidity management policy might span 15 pages covering multiple related RBI provisions. When one paragraph within one of those provisions changes, identifying exactly which lines of the policy are affected requires reading both documents with that specific question in mind.
Second, a single circular change can propagate into controls that are not obviously related to the topic of the circular. A change to reporting frequency requirements in a capital adequacy circular can affect how the compliance calendar is structured, which is not typically documented as a capital adequacy control. Finding these second-order effects requires knowing the institution's control architecture well enough to notice when something non-obvious is touched.
Third, many policy registers in Indian banks and NBFCs were built over time by different teams and are not internally consistent. Some entries are highly specific; others are broad. The mapping from "what changed in this circular" to "which specific policy register entries are affected" requires someone who understands both the regulatory text and the existing documentation structure.
The Manual Process and Its Failure Modes
In practice, the mapping step is done by the compliance officer who received the circular alert. They read the circular, form a view on what changed, and then search their policy register for relevant entries. The search is usually keyword-based, either using a PDF search or a manual scan of a spreadsheet.
This process has a known failure mode: it finds what you search for. If the compliance officer searches for "liquidity coverage ratio" and the relevant control entry in the policy register is labeled "short-term asset-liability mismatch management," the search returns nothing. The connection between the regulatory change and the control exists in the mind of the person who originally wrote the policy register. If that person is no longer on the team, the connection is invisible to keyword search.
A second failure mode is scope under-estimation. When a circular changes a provision that the team considers minor, the mapping review is correspondingly shallow. This is rational under time pressure. But some "minor" changes have meaningful downstream control implications that only become apparent when an auditor asks why a specific control was not updated after a specific circular was published.
A third failure mode is incomplete propagation. The compliance officer identifies the primary affected control and updates it. They do not identify the two secondary controls that also reference the same regulatory provision through a different chain. Six months later, an internal audit review finds the inconsistency and classifies it as a compliance gap, even though the team genuinely tried to implement the change.
What Automated Mapping Addresses
The approach we take with OnFinance AI starts with the premise that a policy register is a structured knowledge artifact, not just a document. When a policy register has been indexed against the regulatory provisions it implements, the system knows which controls map to which regulatory sections. When a circular changes a provision in those sections, the system can identify the affected control entries without requiring the compliance officer to remember or search.
This is not a simple text match. The regulatory reference language in a policy register entry often does not match the title or section number of the relevant Master Direction exactly. A control that says "per RBI guidelines on credit card operations" needs to be understood as referencing RBI's Master Direction on Credit Card, Debit Card and Rupay Prepaid Card Operations, even when those exact words are not present. Building that understanding requires domain-specific regulatory language modeling, not generic document similarity.
The output of an automated mapping pass is a list of potentially affected controls with the specific regulatory change that triggers the review. The compliance officer's job then becomes reviewing that list and making judgments: does this change actually require an update to this control, or is it technically within scope but not operationally significant for our institution? That judgment is theirs to make. The retrieval is automated.
The Control Register Is Not Static
One thing we learned building this is that the policy register itself evolves in ways that the mapping system needs to track. When a compliance officer updates a control in response to a circular change, that update should be recorded with the circular reference that triggered it. When the next amendment to the same provision arrives, the system should know what the control looked like before the last update and what the circular that prompted the update actually said.
This version history is what makes an evidence pack complete. The audit trail for a control update should show: the circular reference, the date it was processed, the provision that changed, which control was reviewed, whether an update was made, and who signed off. Without that chain, an RBI inspection team asking "how did you respond to circular X?" receives an answer that is partially reconstructed from memory rather than documented from fact.
We are not saying that manually maintained policy registers cannot work. Many well-run compliance teams maintain them effectively. What we are saying is that the mapping step between circular change and control update is where the manual process is most prone to failure under the realistic conditions of a compliance team managing multiple regulators simultaneously. The tools that stop at "here is what the circular says" and do not address "and here are the controls that need review" are leaving the harder half of the work undone.
When the Gap Matters Most
The mapping gap matters most during periods of high circular volume. In the months following a major regulatory framework revision (the NBFC scale-based regulation rollout from 2021 to 2023 is a recent example), the circular flow from the regulator is dense with clarifications, phase-in notices, and operational guidance. Each of those circulars potentially touches different controls in the same broad framework. Managing them sequentially with a manual mapping process means that by the time you have processed the fifth amendment, you may have lost track of which controls you updated in response to which earlier amendments.
A second context where it matters is staff turnover. The institutional knowledge required to do the mapping well, knowing that a particular internal control was written in response to a 2019 circular that was later superseded, lives in individuals. When those individuals leave, the knowledge gap shows up as compliance failures: controls that reference outdated provisions, updates that were never made because the new team member did not know the prior state.
Building the mapping into the system rather than relying on individual memory is the structural fix. The compliance officer's expertise is still required. What changes is whether that expertise is applied to judgment calls or consumed by document retrieval.