Analytics for BFSI Under DPDP: What You Can and Cannot Track

Most DPDP guidance written for BFSI is about governance, appointing a Data Protection Officer, running impact assessments, drafting policies.

Useful, and not the thing that breaks first.

What breaks first is the marketing and analytics stack: the pixels on your loan application pages, the session recordings running on your KYC screens, the customer identifiers being passed into analytics platforms, and the third-party tags nobody has audited since they were installed.

This covers what you can track, what needs consent, and what has to stop — specifically for banks, NBFCs, insurers and fintech lenders.

One note: this is technical configuration guidance, not legal advice. Which obligations apply to your entity is a conversation for your counsel and compliance team.

Two Deadlines, and the Earlier One Matters More

The common mistake is planning to May 2027. The penalty framework activates six months earlier, and consent infrastructure is the longest lead-time item in the programme.

Practitioner estimates put a bank with modern core systems at 9–12 months to reach compliant infrastructure. Legacy platforms with paper-based consent are closer to 14–18 months. Against a May 2027 deadline, both of those mean starting now.

Penalties reach ₹250 crore. For BFSI this sits alongside RBI's own monetary penalty powers, and for serious digital lending violations, potential restrictions on the ability to operate.

Most of You Will Be Significant Data Fiduciaries

The DPDP Rules establish criteria for Significant Data Fiduciary classification based on volume and sensitivity of data processed. Most BFSI organisations will meet them.

A mid-sized NBFC with a few lakh customers processing loan applications, repayment data and credit bureau information will almost certainly be designated. That triggers additional obligations — a Data Protection Officer, Data Protection Impact Assessments, and independent audits.

For analytics specifically, SDF status means your tracking configuration becomes an auditable artefact. "We were not sure what that tag did" stops being an acceptable answer.

The Tension Nobody Resolves Cleanly

BFSI is the one sector where DPDP and existing regulation genuinely pull in opposite directions.

RBI and PMLA require retention. Minimum seven years for customer account information, transaction records and KYC documentation.

DPDP requires deletion. Purpose limitation means data should be erased once the processing purpose is fulfilled, unless a legal obligation requires keeping it.

Both are correct. The resolution is documentation — a retention schedule that states, per data category, which legal obligation justifies keeping it and for how long.

Why this matters for analytics: your GA4 data retention setting is not covered by the RBI carve-out. Behavioural analytics data is not KYC documentation. If your GA4 retention is on a long default because someone assumed the seven-year rule applied across the board, that assumption is wrong and it works against you.

Set analytics retention deliberately and separately, with its own documented justification.

What You Can Track

Behavioural data that does not identify an individual, with appropriate consent for analytics cookies.

• Page views and screen views through the application journey

• Funnel step progression — eligibility check started, application started, document step reached, submitted

• Time spent per step

• Device, browser, connection type

• Traffic source and campaign attribution

• Aggregate drop-off rates by stage

• Error events, including failure reasons at document upload

• A/B test variant assignment

This is the important part: none of the analytics work that actually improves your funnel requires personal data.

Diagnosing why applicants abandon at document upload needs to know that an upload failed and why — file too large, format rejected, camera permission denied. It does not need to know whose upload it was. Our post on why loan application funnels lose users at document upload covers that instrumentation, and every event in it is compliant by design.

What You Can Track With Explicit Consent

Consent under DPDP must be free, specific, informed, unconditional and unambiguous. Pre-checked boxes, bundled consent and implied consent from continued browsing all fail.

Specific means purpose-specific. A single "accept cookies" toggle covering analytics, advertising and personalisation does not meet the standard. Each purpose needs its own consent state.

With properly obtained, purpose-separated consent:

• Cross-device journey stitching using a customer identifier

• Retargeting and advertising audiences

• Personalisation based on browsing behaviour

• Marketing attribution tied to an identified user

Two things that follow:

Withdrawal must be as easy as consent. If granting is one tap, withdrawing cannot be an email to support — and withdrawal must propagate to the systems actually processing the data, not just update a flag in your banner tool.

Consent must be auditable. The burden of demonstrating consent sits with you. Not a current-state flag, but a record of what was consented to, when, and under which notice version. For a credit bureau pull, the consent record needs a timestamp and must predate the pull.

What You Cannot Track

Personal identifiers in analytics platforms. Never send name, phone number, email, PAN, Aadhaar, account number or customer ID into GA4 or any general analytics tool. This is prohibited by Google's own terms independently of DPDP, and under DPDP it becomes a statutory issue.

This happens more often than teams realise — usually through a URL parameter carrying an application reference, or a form field value passed into an event parameter by a well-meaning tag.

Financial attributes as event parameters. Loan amount requested, credit score, declared income, approval status. These are the most sensitive categories you hold. They do not belong in a marketing analytics platform.

If you need funnel analysis by loan size, use bands — loan_band: 1L-5L — not exact values, and be deliberate about whether even that is necessary.

Unmasked session recording on KYC and document screens. A session recording tool capturing an applicant photographing their Aadhaar card is processing sensitive personal data through a third-party vendor, usually one that is not in your data processing agreements.

If you run session recordings, KYC and document upload screens need full masking or exclusion. This is the single most common serious exposure we see in BFSI analytics stacks.

Third-party advertising pixels on post-authentication pages. A Meta or Google Ads pixel on a logged-in account page or an application form is transmitting behavioural data about an identified financial services customer to an advertising platform.

Audit where your advertising tags fire. In most BFSI stacks they were installed for the marketing site and have quietly spread to application flows.

Data collection RBI already restricted. RBI's Digital Lending Guidelines already limit collection of contacts, gallery and location data. DPDP makes over-collection a statutory consent violation in addition to an RBI circular breach — so the same practice now carries exposure under two frameworks.

The Three Highest-Risk Practices

In order of how often we find them and how serious they are:

1. Session recording running unmasked across the full application journey. Installed by growth, never reviewed by compliance, capturing document uploads and form fields containing financial data.

2. Advertising pixels on authenticated pages. Marketing tags that spread beyond the marketing site into the application funnel, transmitting identified-customer behaviour to third parties.

3. Identifiers leaking into analytics through URL parameters. An application ID or reference number in the query string, captured automatically as page path, and now sitting in your analytics as a customer identifier.

None of these are deliberate. All three are what happens when a tracking stack accumulates over years without an audit.

What to Configure Before November

• Consent Mode v2 in GTM, with all four parameters and defaults set to denied before any tag fires

• Purpose-separated consent categories in your banner — analytics, advertising and personalisation as distinct choices

• A withdrawal mechanism that is persistent, accessible, and verified to actually propagate

• A complete tag inventory — every tag, what it does, what it transmits, and which vendor receives it

• Session recording masking rules for KYC, document upload and any screen displaying financial data

• Advertising tag scoping restricted to pre-authentication pages only

• URL parameter audit to confirm no identifiers are entering analytics through page paths

• Analytics retention configured separately from RBI-mandated retention, with its own documented justification

• Server-side tagging with consent enforcement, giving you a single enforcement point rather than relying on each browser-side tag independently

Our guide to DPDP compliance for analytics covers the Consent Mode configuration in detail, and our guide to server-side GTM covers the enforcement architecture.

What This Does to Your Numbers

Expect reported traffic and conversions to fall once consent is properly enforced. That is the mechanism working — you were previously measuring people who had not agreed to be measured.

Three consequences to plan for:

Your baseline resets. Conversion rates before and after are not comparable. Set a new baseline post-implementation.

Modelling becomes load-bearing. With Consent Mode and modelling enabled, GA4 estimates non-consented behaviour from consented patterns. Without modelling configured, you get the drop with nothing filling it.

Reconciliation matters more. The gap between analytics-reported applications and your loan origination system will widen structurally. Knowing what that gap should be, and monitoring whether it stays stable, becomes your main signal that the setup is working. Our guide to reconciling CRM and analytics numbers covers the method.

Where FunnelFreaks Fits

DPDP gets scoped as a legal and governance project, and the policy work belongs there. The configuration does not.

Whether your GA4 tags respect the consent signal, whether withdrawal actually propagates to your server container, whether an application reference is leaking into analytics through a URL parameter, whether your session recording tool is masking the document upload screen — these are implementation questions. They are also where compliance succeeds or fails in practice.

We work on the analytics layer specifically: auditing what your stack currently collects and transmits, implementing consent enforcement, scoping tags correctly, and rebuilding funnel measurement so it produces the insight you need without the data you should not be holding.

The useful finding in most BFSI audits is that the compliant configuration is also the more useful one. Funnel diagnosis does not need personal data. It needs events instrumented properly — and most stacks are collecting a great deal they cannot use while missing the granular event data that would actually explain their drop-offs.

A well-drafted privacy notice sitting above a GTM container that fires regardless of consent is not compliance.

Need your analytics stack audited against DPDP before November? Talk to FunnelFreaks — we inventory what you collect, implement consent enforcement, and rebuild the measurement so it works without the data you should not be holding.