Why waiting until May 2027 will cost your fintech more than starting now

What starts on 13 May 2027?

The DPDP Act 2023 and the DPDP Rules 2025 start in three phases. The third phase is the one that reaches your website.

The Act does not mention cookies or banners. It asks for clear notice and consent where personal data is processed on the basis of consent. For a site running analytics and ad tags, a consent banner and tag controls are how that usually shows up in practice.

Our website guide to the DPDP Act covers the wider picture. This guide covers one thing: timing, for a fintech team that spends on paid acquisition.

Our argument is short. Turning on cookie consent the week before 13 May 2027 loses tracking data overnight, with no baseline and no fallback. Build and test early, then pick your switch-on date calmly.

What do Indian fintech websites load before a visitor chooses?

Almost everything they run. Of the 40 websites we tested, 37 loaded analytics tools and 29 loaded advertising tags before any choice, and 4 showed a cookie banner.

On 10 October 2026 we tested 40 Indian fintech, banking and insurance websites. Thirty were mid-size fintechs. Ten were large banks and insurers, included as a benchmark.

We opened each homepage once in a clean desktop Chrome profile with no stored cookies. We recorded which third-party hosts loaded and which cookies were set before any choice. We picked the sites by hand, so this is not a random sample.

What did the 40 websites do on first visit?

Four of the 40 sites showed any cookie banner. Two offered a refuse option next to Accept at similar weight. None held all tags until the visitor made a choice.

The largest single stack we saw was 7 advertising platforms on one homepage. Eleven sites loaded four or more.

Which tools do fintech websites load on first visit?

The list will look familiar to any growth team. Google Analytics loaded on 32 of the 40 sites. Google Ads, including DoubleClick and Floodlight, loaded on 28, and Meta on 25.

Adobe appeared on 8 sites. That was either Adobe Analytics or its tag loader, and we could not always tell them apart.

Three groups of tools deserve a closer look on a fintech site:

• Session recording. Microsoft Clarity loaded on 17 sites, Hotjar on 3 and FullStory on 1.
• Customer engagement platforms. Netcore loaded on 6 sites, MoEngage on 2, WebEngage on 2 and CleverTap on 1.
• App attribution. AppsFlyer loaded on 4 sites and Branch on 1. These tools credit app installs to ad campaigns.

Session recording matters more here than on most sites. It captures what a visitor does on a page. On a fintech site, that can include form fields.

What did the four banners actually do?

A banner on the page is not the same as a working choice. All four sites with a banner loaded tags before the visitor chose anything.

Here is what each one did:

• Two were notices with only an OK button. There was no way to refuse. One of them said that continuing to browse means consent.
• One had Reject All and Accept All at equal weight. Its text said continuing to browse counts as agreeing. Clicking Reject All was stored as "accepted", and the same tags loaded after a reload. We repeated it twice.
• One had Accept All, Allow Only Necessary and More Settings at equal weight. We chose Allow Only Necessary and reloaded. The advertising tags, Google Analytics and the session recording tool stopped, and the stored choice was correct. Two analytics tools still loaded.

The last banner was the closest to working, and it still missed two tools. That is a tag gating gap, not a design gap. The banner looked right and the wiring behind it was incomplete.

We saw one more thing worth checking on your own site. One site with no banner set Google's consent signals to "granted" for every visitor.

How do mid-size fintechs compare with large banks and insurers?

Size made little difference to the tag stack. It made some difference to whether a banner appeared.

Of the 30 mid-size fintechs, 1 showed a banner. Twenty-four loaded advertising tags before any choice, with an average of 2.2 ad platforms per site.

Of the 10 large banks and insurers, 3 showed a banner. Five loaded advertising tags before any choice, with 2 more unclear, and the average was 2.1 ad platforms per site. Neither group had a site that held all tags until a choice.

So a mid-size fintech is not behind its larger peers here. Almost everyone is starting from the same place, and the same work is ahead of all of them.

What about the sites that loaded nothing?

Three of the 30 mid-size fintechs showed no analytics or advertising hosts when the page loaded. Two of them loaded a tag manager that fired no tags on load. One had no tag manager on the page.

We would not read too much into that. Tags may fire only after a scroll or a click. Tracking may also run server-side, which this kind of check cannot see.

What does each fintech segment load?

Payments sites loaded the most ad platforms on first visit, and lending sites the fewest.

The segment figures cover the 30 mid-size fintechs only. The average is the number of ad platforms that loaded on first visit.

Payments

We tested 5 payments sites, and 4 loaded ad tags. They averaged 3.6 ad platforms, the heaviest stacks in the test, including the one with 7. LinkedIn loaded on 4 of the 5, alongside retargeting platforms such as Criteo and AdRoll. Look first at tag gating, because many platforms means the longest gating step.

Wealth and broking

We tested 8 sites, and 7 loaded ad tags. They averaged 2.4 ad platforms, with up to 5 on one site. LinkedIn, X, Bing and Quora appear alongside Google and Meta, and app attribution tools loaded on 2 sites. Look first at how you credit web-to-app journeys, since those depend on a recorded web click.

Insurtech

We tested 5 sites, and 4 loaded ad tags, with an average of 2.2 ad platforms. This segment had the most session recording and engagement tooling: Hotjar, FullStory, WebEngage and MoEngage. The only mid-size site with a banner was here. Look first at what your session recording tool captures on quote and proposal forms.

Small finance banks

We tested 4 sites, and 3 loaded ad tags, with an average of 2.25 ad platforms. Meta loaded on 3, LinkedIn on 2 and the Netcore engagement platform on 2. Look first at the engagement platform, and which consent category it belongs in.

Lending

We tested 8 sites, and 6 loaded ad tags. The average was 1.25 ad platforms, the lightest in the test. The usual set was Google Analytics, Clarity, Google Ads and Meta. Lead and loan forms sit on the homepage of several, so look first at the form and the recording tool running on that page.

Why does waiting feel sensible for a fintech?

Waiting is a reasonable instinct, and there are three reasons for it.

1. Paid acquisition depends on conversion data. Every week of full tracking helps bidding and reporting. Giving that up early feels like a cost with no return.
2. Fintechs are already regulated and used to audits. A date seven months away looks like one more legal item for later.
3. The Act does not name cookies. So website work ranks low on a long list.

All three are fair. None of them is an argument against building early.

The problem is not the switch-on date. The problem is doing the build, the testing and the switch in the same week.

When that happens, the data drops and nobody can say why. Some of the drop is visitors refusing. Some of it may be a broken tag. Without a tested build and a baseline, you cannot separate the two.

You can keep full tracking until May and still be ready. Those are two separate decisions: when to build, and when to switch on.

Which fintech numbers move after consent goes live?

Reported users, sessions, conversions and audiences all fall for visitors who refuse. The applications, accounts and policies in your own backend do not.

We will not tell you how far each number moves. We have no data that would support a figure, and it depends on your visitors and your banner. We can tell you which numbers move.

For visitors who refuse, expect these changes:

• GA4 records fewer users, sessions and key events. The visits still happen. They are not recorded.
• Ad platforms receive fewer conversions. Reported cost per lead or per funded account looks higher, even when real cost has not changed.
• Remarketing and lookalike audiences grow more slowly. Fewer visitors are added to them.
• More traffic shows as direct or unassigned. The visit that carried the campaign is not recorded, so the later visit has no source.
• Web-to-app journeys are harder to credit. This applies where app attribution relies on a web click.
• Session recordings and A/B tests cover fewer visitors. They cover only those who accepted, so the sample is smaller and less mixed.

One set of numbers does not move: the real applications, accounts and policies in your own backend. A visitor who refuses cookies can still complete a loan application.

That gap is the main thing to explain inside the business. Reported numbers change because measurement changed. The business itself may be exactly where it was.

How long does cookie consent take to set up on a fintech website?

For a site with one tag manager and paid ads, the total is usually two to three months. The steps overlap, so the ranges below do not simply add up.

On one recent project the technical setup took two weeks and legal review added another. The technical work is rarely what sets the end date.

Fintech legal and compliance teams tend to review carefully. Start the notice step early, and run it alongside the build instead of after it. Our page on privacy and cookie notices explains what goes into them.

Three parts of the work need extra attention on a fintech site:

• The banner. Accept and Reject sit at equal weight, and the categories match your real tags. See our cookie consent banner page for how we build it.
• Tag gating. This is the step that failed on the banners we tested. Scripts placed outside the tag manager are a common cause.
• Forms. Lead and loan application forms need their own consent notice and an unticked checkbox. We cover that under consent on forms.

Who does what?

Four groups share the work. Name one person in each group, so every handover has an owner.

Marketing and analytics lead, because they know which tags exist and why. Engineering time is small but hard to book at short notice. Ask for it now. If you would like the build done for you, see DPDP website implementation.

How do you check what your website loads before consent?

Load your homepage in a clean browser and watch what it requests in four states: no choice, Accept, Reject, and Accept then Reject. It takes about ten minutes.

This is the check we used on the 40 sites, extended to cover all four consent states. Anyone can repeat it on their own homepage in about ten minutes. You need Chrome and nothing else.

Set up the browser

1. Open a new Chrome profile, or an Incognito window with extensions off. This way no old cookies hide the banner.
2. Open Developer Tools. Right-click the page and choose Inspect.
3. Go to the Network tab and tick "Preserve log".
4. Open the Application tab and find Cookies for your site.

Run the four states

1. State 1, no choice. Load the homepage and do not touch any banner. In Network, filter for names such as google-analytics, doubleclick, facebook, clarity and linkedin. In Cookies, look for names such as _ga, _gcl_au, _fbp and _clck.
2. State 2, Accept. Click Accept and reload. Tags and cookies are expected now.
3. State 3, Reject. Clear the site's data under Application, Storage, Clear site data. Reload, click Reject, then reload again. No analytics or advertising requests should appear, and those cookies should not be set.
4. State 4, Accept then Reject. Clear the site's data and click Accept. Reopen the cookie choices, click Reject and reload. The tags should stop, and the cookies they set should be gone.

What does a good result look like?

A good result is simple to describe. Nothing non-essential appears in states 1, 3 and 4. Everything you expect appears in state 2.

If you have no banner yet, you can still run state 1. It gives you a first list of what loads, which is the start of your inventory.

What can this check not see?

This is one page on one browser. It cannot see server-side tracking, tags that fire deeper in a journey, or what happens inside your app.

Treat it as a first look, not a full review. A fuller DPDP website audit covers more pages, forms and journeys.

How do you lose less GA4 and ad data after consent goes live?

You cannot keep data from visitors who refuse, and you should not try. You can make sure the data you are allowed to collect is complete, and that you understand the gap. Five things help: modelling, the right Consent Mode setup, server-side tagging, a baseline month and one note to finance.

Can Google Analytics model the visitors who refuse?

Yes, but only after the property qualifies. Google Analytics can model the behaviour of visitors who refuse, using the visitors who accepted.

Google's stated minimums are:

• At least 1,000 events a day from visitors who refused analytics, for at least 7 days.
• At least 1,000 daily users who accepted, on at least 7 of the previous 28 days.
• Google tags must load before the consent banner appears, so refusals are counted without cookies.

Timing matters here. A site that switches on at the deadline starts that clock at the deadline. A smaller site may never reach the minimums, so check your own volumes before you count on modelling.

The third condition can sound like what we saw in testing. It is different. In our test, tags ran in full and set cookies with no choice offered. Here, Google tags load in a restricted state, set no cookies and wait for the answer.

Which Consent Mode setup allows GA4 modelling?

Consent Mode has two setups. They differ in what happens before the visitor chooses, and in what you get back.

Which one to use is not a marketing decision alone. It is a choice your legal contact should approve.

If they choose Basic, plan for the smaller dataset. Say so in your forecasts early, so it does not arrive as a surprise in May. Our page on Consent Mode v2 and tag gating explains both setups in more detail.

Consent Mode covers Google tags only. Each other ad platform has its own consent setting, and each needs to be set and tested.

Does server-side tagging help?

It helps with one thing. Server-side tagging makes data from consenting visitors more complete.

It is not a way around a refusal. A visitor who refuses has refused, wherever the tag runs. Build it for data quality, and keep it behind the same consent choice.

Why run a baseline month?

A baseline month is a few weeks of consent running live before the date. It tells you three things you cannot learn any other way:

• Your acceptance rate.
• Which channels lose most.
• How far reported conversions sit below real ones in your backend.

For a fintech, the backend numbers are completed applications, funded accounts and issued policies. Reconciling ad platform conversions against those numbers is good measurement practice in any case. Consent just makes the habit more useful.

What should you tell finance and your agencies before the switch?

Send one short note before the switch. It should cover:

• The switch-on date.
• That reported conversions will fall, while backend numbers should not.
• Which reports to trust during the first weeks. Backend comes first.
• That year-on-year comparisons across the switch need a note.
• That agencies should not react to the first week's numbers by cutting campaigns.
• When the first baseline readout will be shared.

The note has one job: to stop people reading a measurement change as a performance change.

What should a fintech do each month before 13 May 2027?

Audit before the end of December, build in January and February, test in March, and be ready by April.

The plan below fits the two to three month build into seven months, with room for legal review. Nothing in it reduces your tracking before April.

By April the build is finished and tested, but not yet live. Then you choose between two options.

Option 1: switch on a few days before 13 May

You keep full tracking for the longest time. The switch is a single tested publish, not a project. You have no baseline, so the first weeks of data arrive without a reference point.

Option 2: switch on in mid-April

You give up about four weeks of full tracking. In return you get a baseline before the date. You learn your acceptance rate and your channel gaps while there is still time to explain them.

Which option fits your team?

Option 2 suits teams that report paid media numbers to finance. A baseline makes those conversations much easier.

Option 1 suits teams where every week of full data matters more. That is a fair choice when it is made on purpose.

Use the planner to pick a switch-on date and see what it means for your build start, your baseline and GA4 modelling.

Both options depend on the same thing: the build being finished early. If the build slips into May, neither option is open to you. The week you are left with is the one this guide argues against.

Sources

• AZB & Partners: India's Digital Personal Data Protection framework comes into effect, for the three dates
• Google Analytics Help: Behavioral modeling for consent mode, for the modelling minimums
• DPDPWeb testing of 40 fintech, banking and insurance websites, 10 October 2026

This guide is about website work and is not legal advice. Your legal contact decides how the Act applies to you.