Privacy governance built for finance teams handling sensitive customer data.
Fintechs, NBFCs, lending platforms and payment aggregators answer to both RBI/PMLA and the Data Protection Board. Avaril is the infrastructure layer that reconciles the two — consent, retention and grievance records built to satisfy both regulators from the same evidence.
DPDP Rules notified 13 Nov 2025. Full compliance mandatory 13 May 2027.
Two regulators, pulling in opposite directions
The DPDP Rules don't replace RBI's mandates — they layer on top of them. Every fintech, NBFC and payment operator now faces a dual compliance mandate on the same data.
| Compliance tension | RBI / PMLA requirement | DPDPA requirement |
|---|---|---|
| KYC data retention | Retain for 10 years post-account closure | Erase when purpose is fulfilled |
| Consent model | Implied / bundled consent acceptable | Purpose-specific, explicit, withdrawable |
| Breach reporting | Notify RBI within 24 hours | Notify the DPB within 72 hours |
| Vendor outsourcing | Breach notice from vendor in under 2 hours | DPDPA standard contractual clauses required |
| Data localisation | Payment data must stay in India | Adds separate cross-border transfer restrictions |
This is an engineering problem, not just a legal one. The gap can't be resolved with a policy document — it needs infrastructure that understands which legal basis governs which data at which moment.
Why fintech has to move now
A build that starts now has time to design, test and harden. One that starts after the May 2027 deadline does not.
Phase 1
13 Nov 2025
Data Protection Board operational. Penalties enforceable.
Phase 2
13 Nov 2026
Consent Manager registration opens (Rule 4 window).
Phase 3
13 May 2027
Full compliance mandatory — consent, security, breach reporting, data principal rights, grievance redressal.
Penalties reach ₹250 crore per breach category. A missed breach notification alone carries up to ₹200 crore, with no size exemption — a ten-person lending startup faces the same obligations as an established NBFC.
Governance built for the sector, pillar by pillar
Every capability below is accessible via API and SDK — integrated into the onboarding service, the loan pipeline, or the KYC step, not bolted on as a dashboard.
Consent management
A bundled terms-and-conditions checkbox covering every processing purpose is no longer compliant. Every processing activity needs its own legal basis, documented and withdrawable — and fintech has to separate statutory-basis processing (KYC, fraud checks) from consent-required processing (marketing, cross-sell, bureau sharing).
Electronic consent management
Every consent record is a self-contained, signed artifact — not a database row — so ConsentGrants trace back to the exact notice a user saw.
Legal-basis mapping
Avaril distinguishes consent-required purposes from statutory-basis purposes, so the consent UI only asks for what actually requires consent.
Verifiable child consent
Age-gated flows route minor-data processing (student loans, UPI for minors, junior savings accounts) through a separate consent pathway.
Accessible consent capture
Consent flows built to WCAG 2.1 AA, so consent from users with disabilities is verifiable to the same standard as everyone else's.
Signed consent artifacts
Every artifact produced through the SDK is cryptographically signed at the point of collection, independently verifiable by an auditor or the Board.
// Avaril SDK — consent collection in a lending app
import { AvarilConsent } from '@avaril/js';
const consent = await AvarilConsent.collect({
purposes: ['loan_processing', 'credit_bureau_sharing'],
excludeStatutory: ['kyc_verification', 'fraud_analytics'],
principal: { id: userId, age: userAge },
locale: 'hi-IN',
});
// Returns a signed ConsentArtifact — portable, self-verifyingData retention
Retention is where the DPDPA creates the most acute conflict for financial institutions. The erasure obligation clashes directly with KYC retention mandates, transaction-log requirements, and credit-history obligations — often within the same customer record.
Multi-regime policy definition
Different data assets in the same customer record are evaluated against their own governing regime, independently of the others.
Deletion-rule evaluation
An ISO/IEC 27555-aligned engine decides, per asset, what can be erased immediately, what is held under statutory override, and what needs anonymisation instead of deletion.
Enforcement, not documentation
Retention policies run on a schedule and produce an audit log of every deletion, retention justification and statutory override — the evidence file for a Board audit.
Vendor DPA alignment
For outsourced cloud infrastructure, retention clauses in every processor's DPA are tracked against the same policies configured in Avaril.
# Avaril Python SDK — retention evaluation in a lending NBFC backend
from avaril import RetentionEvaluator
evaluator = RetentionEvaluator(org_id=ORG_ID)
result = evaluator.evaluate(
principal_id=customer_id,
trigger='account_closure',
data_assets=['kyc_docs', 'txn_logs', 'marketing_prefs', 'device_data'],
)
# result.to_erase -> ['marketing_prefs']
# result.to_anonymise -> ['device_data']
# result.statutory_hold -> ['kyc_docs', 'txn_logs'] with justification loggedGrievance redressal
A data principal must exhaust a fiduciary's grievance process before approaching the Data Protection Board — which makes a fintech's grievance system a regulated surface, not an internal support queue.
SLA-driven ticketing
The Rule 14(3) 90-day SLA is enforced at the infrastructure level: every ticket is timestamped on receipt, given a deadline, and escalated automatically if that deadline is at risk.
Fintech-mapped grievance types
Consent withdrawal, access and portability requests, KYC correction, marketing objections, erasure with statutory-override documentation, and breach-notice disputes come pre-mapped.
Escalation on ageing tickets
Tickets approaching their SLA threshold route to a senior responsible person automatically, with a paper trail of every action taken.
Privacy documentation
A fintech's Privacy Notice has to accurately reflect what it actually shares with credit bureaus, insurance partners, collection agencies and analytics vendors — a document written once and left alone is a liability, not a defence.
Real-time documentation
Onboard a vendor and it's added to the registry with its DPA — the Privacy Notice, retention policy and RoPA update to reflect the new processing relationship automatically.
Structured editor
For bespoke contractual language or board-level policy, edits are reconciled against live processing activities and vendors, flagging inconsistencies rather than allowing silent divergence.
Deterministic generation
Policy documents are generated from templates, not an LLM — the same inputs always produce the same output, so you can show a regulator exactly what a notice said on a given date.
Built for engineering teams, not consultants
Every capability is accessible via API and SDK, designed to integrate where financial data actually flows.
@avaril/js
@avaril/react
avaril-python
CLI enforcement scoring
The avaril CLI audits your codebase's enforcement score — checking that the processing activities you've declared match what your code actually does. The score is the metric a CTO presents to the board: are we compliant today, and where are the gaps?
avaril audit --mode test # staging environment, no production data
avaril audit --mode prod # production environment, generates compliance reportAvaril never stores your end users' personal data. Consent artifacts are signed and returned to your infrastructure — compliance insight comes from the structure of your processing activities and policy configuration, not from seeing what data your users submit.
Avaril in practice
Built for how your business actually moves data
The right processing activities, retention rules and consent flows depend on which side of financial services you're on.
Lending platforms (NBFC)
Pain points
KYC data under PMLA retention, purpose-specific consent for bureau sharing, dual-regulator grievance SLAs, outsourced collection-agency DPAs.
Avaril maps the full lending lifecycle — application, underwriting, disbursal, servicing, collections — to the correct legal basis at each stage, with statutory retention overrides configured once and enforced automatically.
Payment aggregators & PPI issuers
Pain points
RBI data localisation, transaction-log retention, fraud-analytics DPIA, marketing consent redesign.
Payment processing (statutory basis) is separated from marketing (consent-required) at the data-asset level, with fraud-analytics activities documented against DPIA links and anonymisation requirements.
Insurtech
Pain points
Health data as sensitive personal information, claim-processing consent, actuarial data retention, TPA data-sharing agreements.
Consent flows support purpose-layering — base policy consent captured separately from health-disclosure consent, each maintained and withdrawable independently.
Account Aggregators (AA framework)
Pain points
Overlap between RBI AA directions and the DPDPA Consent Manager regime, the Rule 4 registration timeline, verifiable consent records.
Avaril's consent-artifact model is built to satisfy both frameworks at once, with a flow structure compatible with AA technical specifications.
Wealthtech / investment platforms
Pain points
Behavioural-scoring consent, credit-score exemption boundaries, data sharing with SEBI-regulated entities.
Processing-activity classification helps distinguish which analytics fall under the credit-scoring exemption and which require standalone consent.
Manual compliance, enterprise tools, or Avaril
Financial institutions have historically had two options. Avaril is built to be a third.
| Dimension | Manual / legal team | Enterprise tools | Avaril |
|---|---|---|---|
| Target buyer | Legal counsel | Enterprise compliance teams | Engineering teams & founders |
| Integration | Document-based | Dashboard-only | SDK + API + CLI |
| Real-time sync | No | Partial | Yes — live processing-activity registry |
| RBI / PMLA conflict handling | Bespoke legal advice | Generic | Pre-mapped legal-basis matrix |
| Consent artifact integrity | Self-attested | Proprietary | Ed25519 signed, portable |
| Developer experience | None | None | First-class |
| Time to implement | 3–6 months | 2–4 months | Days, via SDK integration |
What Avaril covers, and by when
Every DPDPA obligation on the compliance timeline, mapped to what's live in Avaril today.
| DPDPA obligation | Deadline | Avaril coverage |
|---|---|---|
| Data Protection Board operational | 13 Nov 2025 | Grievance system records defensible evidence from day one |
| Consent Manager registration window | 13 Nov 2026 | Avaril operates as a Data Processor; CM registration tracked against the Rule 4 window |
| Purpose-specific consent notices | 13 May 2027 | Signed consent artifacts, live |
| Security safeguards | 13 May 2027 | RBAC, MFA, tenant isolation and audit logs, live |
| Breach notification mechanism | 13 May 2027 | Multi-regulator breach notification workflowComing soon |
| Data principal rights (access, correction, erasure) | 13 May 2027 | Grievance redressal system with SLA enforcement |
| Data retention limits | 13 May 2027 | Deletion-rule evaluator with statutory-override logic |
| Grievance redressal | 13 May 2027 | SLA and ticketing with escalation, live |
| Vendor DPAs | 13 May 2027 | Vendor registry and DPA tracking, live |
| RoPA / processing-activity documentation | 13 May 2027 | Processing-activity registry with real-time policy generation |
Stripe built the financial infrastructure for the internet, so every startup could accept payments without becoming a payments company.
Avaril builds the privacy governance infrastructure for India's digital economy, so every fintech, NBFC and payment platform can handle personal data responsibly without becoming a compliance firm.
The financial sector's data complexity isn't a reason to wait. It's the reason Avaril exists.