#NPCI Just Forced Data Minimisation on 23 Billion UPI Payments a Month — Nine Months Before the DPDP Act Required It

Every UPI app and bank in India has until September 4, 2026 to stop displaying customers' full mobile numbers during payments. The instruction did not come from the Data Protection Board of India, and it does not cite a single section of the DPDP Act — but it is the largest act of enforced data minimisation the Indian internet has seen, and it lands roughly nine months before the DPDP Act's substantive obligations bite on May 13, 2027.

The National Payments Corporation of India (NPCI) issued the circular in late July. Its practical effect: on a system that processed 23.66 billion transactions worth ₹29.88 lakh crore in July 2026 alone, a piece of personal data that has been visible by default since 2016 stops being visible by default. That is the story worth paying attention to — not because phone numbers are especially sensitive, but because of who made the call, and what it tells Indian businesses about how the DPDP Act is actually going to be enforced.

#What the NPCI circular actually requires

The directive is narrow, specific, and has a hard date. Per reporting from Business Standard, Business Today and StartupTalky, banks and UPI apps must:

• Mask the registered mobile number on customer-facing screens. Only the last four digits stay visible to the counterparty in a transaction. Payment screens, confirmation pages and transaction history are all in scope.
• Suppress the number entirely on QR-code payments. Scan-and-pay at a shop counter or a roadside stall should not hand the merchant — or the customer — a working phone number, before or after the payment completes.
• Mask other identifiers alongside it: UPI IDs and bank account numbers on customer-facing interfaces.
• Make username-based Virtual Payment Addresses the default. UPI has always allowed a handle that is not derived from your phone number; almost nobody used it, because apps auto-provisioned <mobile>@bank at signup. NPCI now wants the non-phone handle offered as the default identity for new users, not buried in settings.

One outlier report puts the compliance date at September 9; the weight of coverage, including Business Standard and Business Today, says September 4. Either way, apps could begin rolling changes out from August 1, and the window is now under a month.

#Why a payments body is doing the Data Protection Board's job

Here is the part Indian compliance teams should sit with. India's data protection regulator exists — the Data Protection Board of India was constituted on November 13, 2025, and its chairperson and members were appointed on June 6, 2026. Its grievance portal is live. But the Board is an adjudicatory body, not a rule-maker. It hears complaints and imposes penalties; it does not issue design mandates telling an industry what its default settings should be. And the obligations it will eventually adjudicate — notice, consent, data principal rights, security safeguards — are not enforceable until May 13, 2027.

So the substantive privacy engineering in India between now and then is being done by sectoral regulators and infrastructure operators who already have levers. NPCI is not a regulator at all in the statutory sense; it is a not-for-profit company that operates the rails. But it controls scheme rules, and scheme rules bind every participant bank and every third-party app on the network. When NPCI says "mask it by September 4," Google Pay, PhonePe, Paytm and every sponsor bank do it, or they are out of compliance with the scheme.

This is a pattern, not a one-off. RBI has folded data-governance expectations into its cybersecurity and outsourcing norms for banks and NBFCs; SEBI has done the same through its Cybersecurity and Cyber Resilience Framework for market intermediaries; IRDAI runs its own information and cybersecurity guidelines for insurers. As practitioners at K&K have noted, the DPDP Act does not displace any of these — it layers on top, and where two regimes touch the same control, the stricter one governs in practice.

The lesson for anyone waiting for May 2027: your DPDP compliance deadline is probably not May 2027. It is whenever your sector's regulator or your ecosystem's infrastructure operator decides to move, and they are moving now.

#The DPDP principle NPCI is enforcing without naming it

The circular reportedly aligns itself with the DPDP Act in general terms rather than pinning itself to a section. But the principle at work is unmistakable, and it sits in Section 6(1) of the Act: consent is limited to "such personal data as is necessary for the specified purpose." Necessity is the test. Anything beyond it is processing without a lawful basis, no matter what the user clicked at signup.

Apply that to a UPI transfer. The specified purpose is moving money from A to B. Settling that payment requires a routing identifier and an account. It does not require exposing A's working mobile number to B — and it certainly does not require exposing it to a merchant who scanned a static QR at a tea stall. The phone number is visible because UPI's identity layer was built on phone numbers in 2016 for onboarding convenience, and the display followed the plumbing. That is architecture leaking into disclosure, which is exactly what a necessity test is meant to catch.

The same reasoning reaches purpose limitation more broadly. A number collected to authenticate you into a payments app is being repurposed, silently, as a contact channel handed to strangers. Under the DPDP framework, collecting for one purpose and disclosing for another needs its own justification. There is none here.

Malcolm Gomes, COO at Privy by IDfy, framed the shift precisely in comments to StartupTalky: NPCI's mandate "marks an important shift from reactive safeguards to privacy by design," signalling that personal data should not stay visible simply because a platform has historically relied on it. That last clause is the whole audit prompt for the next nine months. We've always shown it is not a lawful basis.

#The harassment problem that forced the issue

This did not start as a compliance exercise. It started as a safety problem that women in India kept documenting publicly.

Because a UPI handle is usually <mobile>@bank, and because apps display the counterparty's name and number, a single small transaction is an identity disclosure. Pay a stranger for a marketplace item, split a bill, or accept a payment as a small merchant, and you have handed over a phone number attached to a verified real name. Complaints about unwanted contact, harassment and identity exposure following routine payments accumulated to the point where NPCI cited user safety alongside regulatory alignment as the trigger for the circular.

That origin matters for how businesses should read the DPDP Act. The Act's harms framing is not abstract. "Risk to the rights of Data Principals" — one of the Section 10 criteria for designating a Significant Data Fiduciary — includes precisely this kind of downstream harm: not a breach, not a leak, just a default that exposes people to each other in ways they never chose. Nobody hacked UPI. The disclosure was working exactly as designed, and the design was the problem.

If your product surfaces one user's contact details to another user as a side effect of a transaction — marketplaces, delivery, ride-hailing, classifieds, ticketing, recruitment portals — you are running the same exposure with none of NPCI's cover. Number masking and proxy calling exist in some of these sectors already; where they don't, the gap is now visible.

#What has to change by September 4, and who does the work

The engineering is not glamorous, but it is not trivial either, and it is spread across three parties.

Banks and PSPs hold the mapping between mobile number, VPA and account. They must ensure that masked forms are what flows to the app layer in the first place, rather than sending the full value and asking the front-end to hide it. Masking at the presentation layer only is the wrong architecture: the unmasked value still crosses the wire and still lands in client-side logs, crash reports and analytics payloads.

UPI apps must rework payment, confirmation and history screens, and — the harder part — change onboarding so a username-based VPA is what a new user gets by default. That touches conflict resolution for handle collisions, migration paths for the hundreds of millions of existing phone-derived handles, and every support flow that currently asks a user to read their number back.

Merchants and aggregators downstream of the QR flow lose a data field they may quietly depend on. Anyone who has been reconciling settlements, running loyalty programmes or building customer profiles keyed on the payer's phone number needs a different key before September 4 — and if that phone number was being retained beyond the transaction, that retention needed a lawful basis under Section 6(1) anyway.

For everyone in that chain, the practical first step is not a code change. It is a data-flow map: where does the mobile number enter, which systems see it, which of them actually need it, and which are holding it because a schema field existed. That mapping is the same artefact the DPDP Act's notice, retention and erasure obligations will demand in 2027. Doing it once, now, under a payments deadline, is cheaper than doing it twice. Our resources section walks through building that inventory, and the consent manager tooling covers how purpose-scoped collection should look once the Phase 2 consent-manager framework goes live on November 13, 2026.

#The precedent this sets for the next nine months

Three things about this episode generalise.

First, defaults are the enforcement surface. NPCI did not ban showing phone numbers; it changed what happens when nobody makes a choice. The DPDP Act's consent architecture works the same way. A consent notice that is technically complete but bundled into a default-on flow will not survive scrutiny in 2027, and the regulators most likely to say so first are the sectoral ones.

Second, the timeline everyone is planning against is soft in one direction only. MeitY has already consulted industry on compressing the compliance window for Significant Data Fiduciaries from 18 months to 12 — which would pull SDF obligations forward to November 13, 2026 — and on notifying the SDF list and cross-border transfer restrictions sooner than May 2027. Nothing in this framework has moved later. Plans built on "we have until May 2027" are betting against the observed direction of travel.

Third, the cheapest compliance work available right now is deletion and suppression. Every field you stop collecting, stop displaying and stop retaining is a field that needs no consent notice, no retention schedule, no erasure workflow, no breach exposure and no line in a Data Protection Impact Assessment. NPCI's circular is a reminder that the fastest route through a data protection regime is usually to have less data in scope.

#What to do this month

If you operate anywhere in the UPI stack, the September 4 date is a hard one and the work is scoped above. If you don't, the exercise still transfers directly:

1. List every screen where one user sees another user's personal data. Phone numbers, full names, email addresses, addresses, order history. For each, write down the specified purpose that disclosure serves.
2. Kill the ones with no answer. Not "reduce" — remove the field. If a workflow genuinely needs contact, use a masked proxy.
3. Check your identifiers. Anywhere a phone number, PAN, Aadhaar number or email is doing double duty as a primary key and a displayed value, split the two. Internal keys should never be human-meaningful identifiers.
4. Check your logs and analytics. Masking on the UI while shipping the raw value to a third-party analytics SDK is not data minimisation; it is data minimisation theatre with an added cross-border transfer problem.

The Data Protection Board has not fined anyone yet. That is not the same as nothing being enforced. India's privacy regime is arriving through scheme circulars, sectoral cyber frameworks and default settings, well ahead of the statutory calendar — and UPI just became the largest worked example of it.

Mapping where personal data leaks between your users is the first step to DPDP readiness. Start with our resources library for data-inventory templates, and see how purpose-scoped consent should be structured with our consent manager before the November 13, 2026 registration window opens.