How we built Dcomply: regulatory change detection and DPDP compliance for Indian BFSI

The problem: compliance teams are drowning in PDFs

Walk into the compliance function of a mid-sized NBFC in Mumbai and you will find, at minimum, two spreadsheets, one shared inbox, and a WhatsApp group. Somewhere in that mix lives the "list of RBI circulars we need to action this quarter." The list is almost always out of date. Someone on the team, usually the most senior person, spends an hour every morning refreshing rbi.org.in, downloading PDFs, forwarding them to the treasury desk, the KYC desk, the IT desk, and the grievance officer. On a good week they miss two circulars. On a bad week they miss five.

Now add SEBI for the AMC subsidiary, IRDAI for the insurance tie-up, and MeitY for anything touching data. The circular volume across just these four regulators runs to roughly 1,200 new notifications a year, not counting FAQs, clarifications, master directions, and the re-issued versions that supersede earlier ones. Every one of these documents can carry a hard deadline, and every missed deadline is a supervisory letter waiting to happen.

Then the DPDP Act 2023 arrived. Overnight, the compliance surface got roughly three times wider. Consent artifacts, data principal request handling, breach reporting timelines of 72 hours, DPO appointments, cross-border transfer restrictions, notice requirements in eight languages. All of it needed workflows, all of it needed evidence, and all of it needed to be defensible in front of the Data Protection Board of India once the rules were notified.

When we started scoping Dcomply as Decipher's own SaaS product, this was the working hypothesis: a compliance officer at a BFSI firm should never have to check a regulator's website manually again, and every piece of evidence they will ever need for an audit should already be in one place, hash-verified, before the auditor asks.

The starting point: what Dcomply had to become

Before writing a line of code, we sat with compliance heads at four firms across the BFSI spectrum: a mid-sized NBFC, a small private bank, a general insurer, and a payments fintech. The requirements list that came out of those conversations was concrete:

• Ingest every RBI, SEBI, IRDAI, MeitY, and e-Gazette notification within hours, not days, of publication
• Classify by entity applicability, so an insurance-only circular does not clog the NBFC's dashboard
• Extract hard deadlines automatically from the text and turn them into calendar-anchored tickets
• Route tickets by function area, treasury, KYC, grievance, IT, DPO, so each team sees only what applies to them
• Hold evidence artifacts (DPO reports, DPIAs, consent records, board minutes, control test results) in one audit-ready store
• Answer natural-language compliance questions like "what is our current RBI stance on green deposits?" with cited sources
• Be deployable inside a bank's own VPC for firms with strict data residency policies

None of the items on that list are individually novel. Putting them together in a way that works for a compliance officer whose main tool is Excel is where the engineering lives.

The architecture

Dcomply is five layers stacked on top of each other. Ingest, classify, extract deadlines, route to tickets, and store evidence. A retrieval layer sits alongside the whole stack for question-answering. Every layer is independently observable and, importantly, every layer can be turned off in favour of a manual override without breaking the ones above or below it.

The LLM stack, and why we run three

We evaluated a single-model setup early and rejected it. Different steps in the pipeline have very different cost, latency, and reasoning requirements, and forcing them all through one model was either overpaying for tagging or under-serving the harder reasoning work.

• Claude Sonnet for the reasoning-heavy work: deadline extraction verification, classification when the embedding match is weak, and the user-facing Q&A layer. This is where accuracy matters most and where the extra cost per call is justified.
• GPT-4.1-mini for cheap, high-volume tagging: function-area classification when the embedding similarity is already high, sub-topic labelling, and short-form summarisation for the dashboard.
• Llama 3.3 (self-hosted) as a drop-in for both above, offered to tier-1 banks whose data policies do not permit any content leaving their VPC. Runs on H100 nodes inside the client environment with the same prompt templates as the API-based models.

The DPDP Act module

The DPDP Act 2023 module was scoped separately from the general regulatory-change module because the workflows are fundamentally different. Regulatory change is broadcast (a circular applies to a class of entities), while DPDP is transactional (a specific data principal exercises a specific right on a specific date).

What is in the module today:

• Data Fiduciary registration workflow, tracking the client's registration status, categorisation as Significant Data Fiduciary or otherwise, and the associated reporting cadence
• Data Principal request handling for access, correction, and erasure requests, with a 30-day SLA counter, identity verification workflow, and audit trail of every action taken on the request
• Consent artifact management, storing the exact consent notice version, timestamp, language, and the specific purposes consented to, per data principal
• Breach reporting playbooks with 72-hour timers, pre-built templates for the Data Protection Board notification, and separate templates for affected data principal communications
• DPO delegation, so the appointed Data Protection Officer can assign sub-tasks to function owners while retaining accountability for the response
• Cross-border transfer register, tracking which categories of personal data flow to which countries, updated as MeitY notifies restricted or permitted jurisdictions

The DPDP module ships with a starter library of policies, notices, and DPIA templates drafted by our compliance consulting team. Clients customise these, but the starter set is what gets a mid-sized NBFC to a defensible baseline in weeks instead of quarters.

Retrieval and reasoning for compliance Q&A

The Q&A layer runs on the same principles we described in the VakeelSaathi RAG case study, adapted for regulatory text. The corpus is smaller and more structured than case law, which helps, but the accuracy bar is arguably higher: a compliance officer citing an answer from Dcomply in an internal note is doing so on the record.

The setup:

• Hybrid retrieval across a pgvector semantic index and a BM25 keyword index, both partitioned by regulator so a SEBI-only query does not retrieve RBI results by accident
• Cohere Rerank v3 on the merged top 30 candidates, with a similarity floor below which the system explicitly refuses to answer
• Claude Sonnet generation with a strict-grounding prompt that mandates a citation for every factual claim and forbids invented circular numbers or dates
• Every answer renders with inline references to the exact circular ID, paragraph, and issue date, each clickable through to the source document in the evidence vault

Retrieval latency on the full 15,000-document index runs sub-second. End-to-end user-facing latency for a cited answer is 2 to 4 seconds, streamed so the user sees the answer forming as it is generated.

What we got wrong first, and fixed

Three misses are worth documenting because they are the sort of thing anyone building a compliance system in India will hit.

Miss 1: over-triggering false positive tickets

The first classification pass did not scope tickets by entity type carefully enough. An RBI circular addressed to "Scheduled Commercial Banks" was still generating tickets on the NBFC dashboard because the embedding-based classifier saw enough banking vocabulary to match. Compliance officers at pilot clients started ignoring the dashboard within a week because most of what appeared there was not theirs to action.

The fix took two changes. First, we added a hard rule layer on top of the ML classifier: if a circular's opening addressee line explicitly names a category, that category is dispositive, and the embedding classifier only supplements it, never overrides. Second, we introduced a per-client entity profile (this client is an NBFC-ICC, not an NBFC-MFI, and does not hold an AMC licence) so the ticket engine can filter final output against what the client is actually licensed to do.

Miss 2: hallucinated deadline text

The first deadline extractor was pure LLM. It hallucinated dates roughly 4% of the time, usually by rounding "within 30 days from the date of this circular" into a specific calendar date that was one day off, or by picking up a date from a footnote that was actually the issue date of a superseded earlier circular. In compliance work, a wrong deadline is worse than no deadline.

The fix was the regex-plus-LLM consensus check described earlier. Every candidate deadline gets extracted twice, once by regex patterns tuned on 2,000 hand-labelled Indian regulatory circulars and once by the LLM with a targeted prompt. If both agree, the deadline is used. If they disagree, the item goes to a human review queue where the compliance-consulting team resolves it and the disagreement gets logged as training data for the next classifier iteration. Post-fix, our extractor error rate on a held-out eval set sits below 0.5%.

Miss 3: evidence vault was not tamper-evident

The first version of the evidence vault was straightforward S3 with versioning. Technically defensible but not cryptographically provable. An early client's internal audit team pushed back: "how do we prove to a regulator that this DPIA document was not edited after the audit period closed?" Versioning alone does not answer that. Someone with write access to the bucket could have replaced the file and rolled the version.

The rebuild added two things. Every artifact upload now computes a SHA-256 hash, and that hash is chained into a rolling per-tenant hash log that is itself periodically anchored to a WORM-locked object. WORM (Write Once Read Many) S3 buckets with retention lock are used for the primary storage on all new deployments. An auditor can now be handed a single verification tool that walks the hash chain and confirms no artifact in scope was altered post-submission.

Deployment options

Dcomply ships in two shapes because BFSI firms sit in two very different data-policy worlds.

SaaS multi-tenant

Hosted by us on AWS ap-south-1 (Mumbai). Row-level tenant isolation in Postgres, per-tenant encryption keys managed via AWS KMS, and per-tenant S3 prefixes with separate IAM policies. Smaller NBFCs, HFCs, and payments fintechs typically start here because the setup time is a week or two rather than months. LLM calls in this mode go to Anthropic and OpenAI over their standard business APIs with zero data retention flags set.

Single-tenant inside client VPC

For tier-1 banks and larger insurers, the entire Dcomply stack deploys inside the client's own AWS or Azure environment. Postgres and pgvector run on managed RDS or Azure Database, object storage is the client's own S3 or Blob with the client's KMS keys, and the LLM layer routes to zero-data-retention Azure OpenAI, or to self-hosted Llama 3.3 on GPU nodes inside the client environment. The application code, the ingestion pipeline, and the workflows are identical across both deployment modes. What changes is where the data lives and who holds the keys.

Results after six months

These numbers are drawn from the pilot cohort of four clients (one mid-sized NBFC, one private bank, one general insurer, one payments fintech), measured over the six months from January to June 2026. Averages across the cohort, with the qualifier that pilot conditions include heavier hand-holding from our consulting team than a normal roll-out would.

The audit-prep story is the one clients talk about the most. The insurer in the pilot cohort ran their annual internal audit in April 2026. Their pre-Dcomply cycle for pulling evidence, reconciling ticket status, and producing the auditor's file was three weeks of dedicated work from a two-person team. With Dcomply, the same cycle took four days. The evidence was already in the vault, the hash chain was already verified, and the ticket-to-artifact mapping was one report away.

On the DPDP side, all four pilot clients hit 100% SLA compliance on data principal requests received during the pilot window. This is partly volume (the numbers are still small because public awareness of DPDP rights is still building) but the workflow held up cleanly on the requests that did come in, and the 30-day counter is what the compliance heads pointed to as the piece they most appreciate.

What is next

The roadmap through the end of 2026 focuses on three areas.

Automated impact simulation. When a new circular arrives, the system should not just create a ticket. It should surface, on the same view, which of the client's current controls are affected, which policies need re-drafting, and which contracts need addendum reviews. This requires deeper integration between the regulatory-change layer and the client's own control library, which we are building now with the first three clients as design partners.

Native connectors to MetricStream and ServiceNow GRC. The API layer already supports pushing tickets and evidence out, but the deep, native, two-way connectors are being built as full first-class integrations rather than webhook wiring. This is the piece the tier-1 banks need before they will use Dcomply alongside an existing enterprise GRC.

Regional-language circular support. State-level RBI notifications, cooperative bank circulars from state cooperative departments, and certain IRDAI communications appear in Hindi, Marathi, and Kannada, among others. Our current pipeline is English-only. The multilingual work extends the ingestion and classification layers to handle Hindi and Marathi in the next release, with Kannada, Tamil, and Bengali in the following one.

Can we build something like this for your team?

Dcomply is a productised version of a pattern we have deployed across other regulated domains. The layers (ingest, classify, extract, route, store, retrieve) hold whether the source is RBI circulars, MCA notifications, environment ministry gazettes, or industry-specific regulator feeds. If your compliance function is spending its mornings refreshing a regulator's website, there is a version of this that would work for you.

Book a call. We will walk through your current sources, the ticket volumes you are dealing with, and what a Dcomply deployment (SaaS or in-VPC) would look like for your environment.