Banks receive a steady stream of RBI circulars, and every one of them has to be interpreted, implemented, tested and proven. No single step there is exotic. The difficulty is that the steps land in different places: the interpretation in a document or an email thread, the implementation in a ticket, the test in a QA tool, the proof in whatever can be reassembled months later when someone asks. The link between a regulatory paragraph and the system change that satisfies it usually lives in emails, spreadsheets and tickets, which is another way of saying it does not reliably live anywhere.

That produces a familiar set of failures. Interpretations of circulars sit in documents and email threads, with no clear owner or approval record. It is hard to see which products, controls, procedures and systems a single rule actually touches. Engineering tickets lose the connection to the source paragraph, so a wrong implementation can ship unnoticed. When an implementation was wrong, past customers may have been affected, and assessing them is slow and manual. Procedure updates and staff acknowledgements are tracked by hand. When an inspector asks why a release was approved, evidence has to be assembled from many systems.

Kavach is the platform SoluLab built to hold that chain together: one connected, auditable record running from circular text through applicability, requirements, controls, delivery work, verification, customer remediation and board reporting, with a named human decision at every gate.

The joins where regulatory change fails

Regulatory change does not usually fail in the middle of a step. It fails at the joins: between a paragraph and its interpretation, between a requirement and its code, between a test and the build it proves. Each technology in the platform was chosen to hold one of those joins together, which is a narrower design brief than "manage compliance" and a more useful one.

The first consequence of that framing is that nothing is reasoned over until it has been pinned down. Regulations, internal policy, and the systems and teams that implement them are each parsed, linked and versioned before reasoning starts. Versioning is doing real work here. An approval only means something if you can say which version of a requirement was approved, and a verification run only proves something if you know which requirement version it ran against.

Kavach end to end

Regulatory Intelligence triages incoming circulars by domain, impact and owner, so a circular arrives with a route rather than with a reading list. Circular Workspace then anchors each case to the exact source paragraph and to the bank records it affects, which is the join that normally breaks first.

The reasoning engine drafts applicability decisions and testable requirements from the circular text, states the scope boundary, and identifies candidate system changes. Each draft is reviewed and approved by a named person. Work Orchestrator turns approved requirements into owned delivery work and procedure updates. Updated procedures are versioned and distributed through it, and each recipient's acknowledgement is tracked until the distribution is complete, which replaces the spreadsheet usually kept for exactly this.

Why AI drafts and a named person decides

Reading circulars and mapping them to bank systems takes expert time that does not scale. That is the case for putting a model in the loop, and it is the whole case. AI drafts and recommends. Requirements, applicability decisions, QA evidence and release decisions are approved by named reviewers, and each approval is recorded against the version it applies to.

That division is not a disclaimer bolted on at the end. It is why drafts are versioned, why the scope boundary is written out rather than implied, and why candidate system changes are presented as candidates. A reviewer who has to approve something needs to see what was assumed, not only what was concluded.

Why a knowledge graph

Compliance evidence is only useful if every link in the chain can be followed. The graph connects each regulatory paragraph to the requirements, controls, procedures, systems and code it affects, so a team can see the full impact of a change and walk any link in either direction: from a paragraph down to the code, or from a code change back to the paragraph that required it.

The living chain of trust

The Living Chain of Trust runs the approved checks against a specific build and source snapshot, and ties the results, the QA decisions and the release gate to the requirement version they prove. Build identity is part of the record, so "this was tested" stays a statement about a particular artefact.

Two things follow from holding that record. Kavach runs a retrospective customer assessment, comparing observed and expected outcomes per account, flagging discrepancies and keeping customer remediation open as its own outcome until it is resolved. And each case shows its outcomes independently, such as release approval, deployment, customer remediation and case status, so approval of one part never hides open work elsewhere.

An inspector or auditor can ask case-specific questions, such as why a release was approved, and get an answer drawn from the case records, with the supporting requirement, run, QA decision and procedure linked. The platform is designed to run in the bank's own cloud or on-premises environment, with role-based access, maker-checker approvals, encryption and a complete activity log.

Read the full Kavach case study: https://www.solulab.com/case-study/ai-powered-regulatory-change-management-platform-for-banking-compliance/

Watch the product walkthrough (demo data): youtube.com/watch?v=Mu5zDajV0Qc