indiclabs.ai
←Back to case studies[Compliance Auditing]

Policy & Compliance Answers, From a Circular Hunt to a Cited Response

How a compliance and audit copilot gives staff cited answers instead of a manual hunt through circulars — and standardizes how risk and control assessments get written.

Large Enterprise Bank·India·10–14 Week Rollout Pattern
System Architecture
Architecture diagram: an employee question entering the bank's role-scoped internal knowledge base, handled by the Saarthi Policy & Compliance Copilot Agent, which re-queries the circulars, policies, and RCSA repository until it has a citable answer, then returns a cited answer to the employee.

The Challenge

Compliance and audit staff spend a meaningful share of their week just finding the right version of a circular or policy clause across repositories that were never designed to be searched — PDFs, Word documents, and internal wikis maintained by different teams with different update cadences. Getting the wrong or outdated version of a policy isn't a hypothetical risk; it's a recurring one.

Separately, risk-and-control self-assessment documentation — the process by which each business unit describes its own risks and the controls meant to address them — tends to drift in terminology and format from unit to unit. Two teams describing the same category of risk in different language makes it hard to roll anything up into a consistent, enterprise-wide picture.

“The retrieval isn't the hard part. The hard part is knowing whether the first answer is actually good enough to stop looking — that's the piece a plain search box can't do.”

The Solution

Powered bySaarthi →

The Saarthi Policy & Compliance Copilot Agent connects to the bank's internal policy and circular repositories and answers employee questions with a citation back to the source clause every time — never a confident-sounding answer with nothing behind it. It respects the bank's existing role-based access controls at query time, so an answer never surfaces a document the asking employee isn't cleared to see.

What makes it an agent rather than a search box is what happens when the first retrieval pass doesn't actually answer the question — which is common, since real policy questions are often composite ("does this exception apply given both circular X and the amendment in circular Y"). The agent re-queries, checks whether the new result actually resolves the question, and only stops when it has something citable. That decision loop — is this answer good enough, or do I need to look again — is the part a plain search box can't do. The same underlying retrieval and terminology-normalization capability is what standardizes RCSA write-ups: it flags when a unit's risk description uses inconsistent terminology against the bank's approved taxonomy, instead of leaving every unit's document freeform.

Multi-hop retrieval that re-queries instead of stopping at the first match
Access strictly scoped to the querying employee's existing role permissions
Verbatim source citation on every answer, no unsourced claims
Terminology-consistency flags across business-unit RCSA documentation

What This Pattern Typically Delivers

Staff get a cited answer in under 150ms of retrieval time instead of an email thread that may or may not get a reply before the question stops being relevant. Because every answer is scoped to the bank's own access model, nothing about this widens who can see what — it just makes what people are already allowed to see actually findable.

[READY_TO_DEPLOY]

[Secure and customize your model layers with sovereign compute architecture.]