There is a category of risk in BFSI that does not appear on most risk dashboards. It is not market risk, credit risk, or operational risk in the conventional sense. It is something more specific and more insidious: the risk that what your institution says it does and what it actually does are not the same thing.

Not because of fraud or negligence. Because a policy document and a rule engine are two different objects, maintained by two different teams, updated on two different timelines, with no systematic mechanism to verify that they agree with each other.

This is the policy-rule mismatch problem. It is present, in some form, at almost every BFSI institution operating at scale. It is responsible for a significant proportion of regulatory findings that institutions receive - not findings about conduct or intent, but findings about the gap between stated policy and operational reality. And it is almost entirely invisible until something surfaces it.

How the mismatch forms

The policy-rule mismatch does not emerge from a single point of failure. It accumulates through a series of individually reasonable decisions made by people who are each doing their job correctly within their own domain.

A lending policy is updated to reflect a new RBI circular on income verification. The compliance team updates the policy document. The updated document goes to the product team, who produce a change specification. The spec goes to engineering. Engineering implements it. The change passes QA. It goes live.

Three months later, a product manager notices that a specific edge case - applicants with variable income components above a threshold - is being handled differently from what the policy specifies. The policy says they should be subject to additional verification. The rule engine is approving them automatically. The engineering team investigates. The specification was ambiguous on this edge case. The developer made a judgment call. The call was logged in a code comment. It was never reviewed against the policy.

For three months, the institution has been making credit decisions that do not match its stated policy. The number of affected applicants depends on how common the edge case is. The financial and regulatory exposure depends on what the policy was trying to protect against. The institution finds this through its own quality review. That is the best possible outcome. The alternative is discovering it through a customer complaint, an audit finding, or a pattern of unexpected defaults.

The four most common sources of mismatch

Ambiguity in the policy document. Policies are written in natural language. Natural language is inherently ambiguous in ways that rule engine logic is not. A policy that says "borrowers in high-risk occupations are subject to enhanced due diligence" requires someone to define "high-risk occupations" operationally. 

If that definition is not explicit in the policy, different people will draw different boundaries. The rule engine will implement one boundary. The policy will imply another. The mismatch is structural from the moment the policy is written. This is the same underlying condition behind why policy documents nobody fully understands remain the default operating model at so many BFSI institutions.

Boundary conditions at implementation. 

Rule logic operates on precise conditions - greater than, greater than or equal to, inclusive, exclusive. Policy language rarely specifies these boundaries explicitly. A policy that says "applicants with income above ₹5 lakh are eligible" does not specify whether an applicant with exactly ₹5 lakh qualifies. 

The developer implementing the rule makes a call. It may match the policy intent. It may not. Nobody verifies it systematically because there is no mechanism that compares rule logic to policy text and flags potential discrepancies.

Update lag between policy and rule engine. 

Policy updates and rule engine updates happen on different timelines. A regulatory change may require a policy update immediately but a rule engine update may take weeks to clear the engineering queue, pass QA, and go live. 

During that window, the policy and the rule engine disagree. This is a known, managed risk in most institutions - but the window is rarely measured or monitored explicitly. Over a year, across multiple policy updates, the cumulative time during which policy and rule engine are out of sync is often significantly larger than anyone has calculated.

Undocumented exceptions and workarounds. 

Over time, rule engines accumulate configurations that were added to handle specific edge cases - an exception for a particular distribution channel, a carve-out for a specific product variant, a temporary adjustment that was never removed. 

These configurations are technically correct when they are added. They may not remain correct as the surrounding policy evolves. And because they are not linked to the policy clauses they were added to address, they are invisible to anyone reviewing the policy document - including the compliance team and the regulator.

Why this is harder to detect than it should be

The policy-rule mismatch is difficult to detect systematically because the two objects it involves - the policy document and the rule engine - exist in completely different systems with no native connection between them.

The policy document lives in a document management system, a shared drive, or a compliance platform. It is maintained by the legal and compliance team. It is updated through a document revision process that involves track changes, version history, and approval workflows.

The rule engine lives in the product's technical infrastructure. It is maintained by the engineering team. It is updated through software development processes - tickets, code reviews, deployments, QA testing.

These two systems do not talk to each other. There is no automated check that compares the current state of the policy document against the current state of the rule engine and flags discrepancies. The comparison only happens when a human - a compliance reviewer, a QA engineer, an internal auditor - manually checks one against the other. 

Given how infrequently this happens and how complex rule engines become over time, significant mismatches can persist for months or years without detection. This manual dependency is precisely the cost of manual policy management that compounds quietly until an audit or a regulator forces the reconciliation.

The regulatory implications of this are significant and growing. RBI, IRDAI, and SEBI are all increasing their scrutiny of the gap between stated policy and operational practice. 

The DPDP Act adds a data governance dimension - institutions must be able to demonstrate that their data processing rules match their stated privacy policies, with penalties up to ₹250 crore per violation. The era in which a well-written policy document provided meaningful protection from regulatory scrutiny is ending. Regulators are increasingly asking to see the rule, not just the policy.

The downstream consequences that make this urgent

The policy-rule mismatch is not a theoretical problem. It produces specific, recurring consequences that most BFSI institutions have experienced in some form, even if they have not attributed them to this root cause.

• Incorrect credit decisions. 

  • Underwriting rules that do not match the credit policy produce loan approvals that the policy would have declined, and declines that the policy would have approved. 

  • The first category creates portfolio risk. The second creates customer experience failures and potential mis-selling exposure. Both categories are invisible until the outcomes surface - in default patterns, in customer complaints, or in an internal audit that compares decision logs against policy criteria.

• Incorrect claims outcomes. 

  • For insurers, a claims processing rule that does not match the product policy produces settlements that should have been declined and declines that should have been settled. Both have financial consequences. 

  • The declined-but-valid settlement becomes a complaint and potentially a regulatory escalation. The approved-but-invalid settlement is a financial loss that compounds across every similar case until the mismatch is caught. Getting this right depends on how the underlying verification systems for claims lifecycles are designed in the first place, since endorsement and claims decisions inherit whatever gaps exist upstream.

• Regulatory findings that cannot be explained. 

  • When a regulator asks an institution to explain why a particular class of decisions was made the way it was, the answer has to come from somewhere. If the rule engine configuration cannot be traced to a specific policy clause - because the link was never documented - the institution has to reconstruct the rationale from memory, email threads, and meeting notes. The reconstruction is often incomplete. 

  • The regulator notes the gap. The gap becomes a finding. The finding requires a remediation plan. The remediation plan costs more than the original implementation would have if it had been done with traceability from the start.

What detection and prevention actually requires

Solving the policy-rule mismatch requires addressing the absence of connection between the two systems - the policy document and the rule engine - rather than adding more manual review steps to a process that is already laborious enough to generate compliance fatigue.

The structural requirement is a layer that sits between the policy document and the rule engine - one that can read the policy, extract the rule logic embedded in it, compare it against the current rule engine configuration, and surface discrepancies explicitly rather than relying on periodic manual review to find them. This is the same problem addressed in our practical guide on policy documents to enforceable rules: taking existing policy text and making it operational without standing up an entirely new system around it.

When the policy changes, the layer identifies what in the rule engine needs to change and flags any gaps between the updated policy and the current implementation. When the rule engine is updated, the change is linked to the policy clause it reflects - creating the traceability that makes regulatory explanations possible.

Conflict detection is the second requirement. A well-governed policy environment does not just compare policy to rule engine - it checks rules against each other for internal consistency. When a new rule interacts with an existing rule in a way that produces a conflict, that conflict should be surfaced before deployment, not discovered when the two rules produce contradictory outputs on the same applicant or claimant.

This is the specific gap that PolicyOS by TartanHQ addresses. 

PolicyOS converts policy documents into structured, executable rule logic - making the translation from text to rule explicit and auditable. It detects conflicts between new rules and existing ones before deployment. It maintains a version-controlled record of every policy state and every rule configuration, linked together, so that the relationship between a policy clause and the rule it produced is traceable at any point in time.

The institutions that will navigate the next wave of regulatory scrutiny with the least friction are the ones that can demonstrate - not claim, demonstrate - that their rule engines match their policies, that their changes are traceable, and that their conflicts are caught before they produce decisions rather than after. That capability is not available from a document management system or a rule engine alone. It requires the layer between them.

The mismatch between what your policy says and what your rule engine does is, right now, either a known gap you are managing or an unknown one you are not. Finding out which before the regulator does is the less expensive option by a significant margin.