by
Ruchin Kumar, VP South Asia, Futurex
Last updated: September 2, 2026
India’s Unified Payments Interface (UPI) has reached a scale at which payment security can no longer be treated as an application-level concern. In July 2026 alone, the platform processed 23.65 billion transactions worth INR 29.88 trillion, with 741 banks live on UPI.
That growth has changed the technology discussion for banks, payment system operators, and other organizations participating in India’s digital payment ecosystem. Infrastructure has to cope with enormous transaction volumes while preserving the confidentiality and integrity of customer information, enforcing access controls, maintaining reliable audit trails, and keeping critical payment services available.
The Digital Personal Data Protection (DPDP) Act, 2023, adds another dimension to that responsibility. India finalized the DPDP Rules in November 2025 and established a phased commencement schedule. Most of the substantive obligations affecting Data Fiduciaries, including the reasonable security safeguard requirements under Section 8 of the Act and Rule 6 of the Rules, are scheduled to take effect in May 2027.
For payment organizations, this should not be viewed as a new security regime arriving in isolation. Banks and payment system operators already operate under detailed RBI cybersecurity and digital payment security requirements. DPDP introduces an additional obligation around digital personal data, making it important to understand where existing payment-security controls align with the new framework and where additional work may be required.
Table of Contents
What the Final DPDP Rules Mean for Payment Organizations
Section 8 of the DPDP Act requires a Data Fiduciary to take reasonable security safeguards to prevent a personal data breach. Failure to observe that obligation can attract a penalty of up to INR 250 crore under the Act.
The final DPDP Rules provide considerably more detail on what constitutes reasonable security safeguards.
Rule 6 requires, at a minimum, appropriate measures for protecting personal data through mechanisms such as encryption, obfuscation, masking, or virtual tokens. It also covers access control, logs and monitoring, measures for continued processing after confidentiality, integrity, or availability has been compromised, retention of specified logs and personal data for security purposes unless another applicable law requires otherwise, appropriate security provisions in processor contracts, and technical and organizational measures to ensure that these safeguards are observed effectively.
For payment organizations, there is an important implication in that wording: DPDP does not prescribe a single security product or a single cryptographic architecture.
Instead, the regulatory expectation is broader. An organization needs an effective system of protection, access control, monitoring, resilience, and accountability around the personal data it processes.
That difference should shape technology decisions.
How RBI Requirements Fit Into the Picture
Indian payment organizations are not beginning from zero. The Reserve Bank of India (RBI)’s Digital Payment Security Controls Directions, 2021, applicable to scheduled commercial banks excluding small finance banks, payments banks, and credit card-issuing non-banking financial companies (NBFCs), already require regulated entities to establish governance and security controls for digital payment products and services.
The RBI specifically states that digital payment architecture should be robust and scalable to accommodate transaction volumes and customer growth. It also requires an appropriate level of encryption across the digital payment ecosystem and calls for strong, internationally accepted cryptographic algorithms, key lengths, cipher suites, and protocols that are not deprecated or demonstrated to be insecure.
For authorized non-banking payment system operators (PSOs), the RBI issued separate Master Directions on Cyber Resilience and Digital Payment Security Controls in July 2024. These directions introduced phased compliance dates for large, medium, and small non-bank PSOs and cover governance, cybersecurity preparedness, access management, application security, vendor risk, data security, incident response, business continuity, and digital payment controls. The data-security provisions specifically address protection of customer information, data traceability, encryption of data in transit and at rest, and controls around personally identifiable information.
The practical lesson is that DPDP should not be implemented as a parallel compliance island.
A bank or payment organization needs to determine which controls already exist due to RBI requirements, which of those controls support its DPDP obligations, and where gaps remain in personal data processing, data processors, access visibility, retention, and breach response. That exercise is far more useful than buying a second set of security controls labeled “DPDP.”
Common Misunderstandings About DPDP Act and UPI Security
Misunderstanding 1: Every UPI fraud is a DPDP breach
The two issues are related to security, but they are not synonymous.
A customer may be induced through social engineering to authorize a fraudulent payment without an organization suffering a personal data breach. Conversely, an attacker may gain unauthorized access to personal information without successfully initiating a fraudulent payment.
Security teams, therefore, need separate visibility into transaction fraud and unauthorized access to personal data, while maintaining the ability to correlate the two when an incident crosses both domains.
This becomes especially important under the final DPDP breach-notification framework. Rule 7 requires affected Data Principals and the Data Protection Board to receive specified information when a personal data breach occurs, with the detailed information required by the Board to follow within 72 hours unless additional time is granted.
Misunderstanding 2: UPI scale is primarily a throughput problem
Large transaction volumes make performance important, but raw throughput is only one part of payment infrastructure design.
A cryptographic environment also has to address key generation and storage, administrative access, application isolation, high availability, backup and recovery, monitoring, auditability, and the operational procedures surrounding those controls.
RBI’s 2021 Directions illustrate this broader view. In the card-payment context, the Directions specify controls around hardware security module (HSM) logging, high availability, access control lists, application-level isolation, privileged access management, and protected handling of keys and PIN-related cryptographic operations.
Misunderstanding 3: PCI P2PE is a general UPI security standard
This is an important distinction because card-security terminology sometimes carries over into broader digital payment discussions without sufficient context.
PCI point-to-point Encryption (P2PE) addresses payment card data protection from the point of interaction through decryption in an approved environment. RBI’s 2021 Digital Payment Security Controls Directions specifically address PCI P2PE, PCI PTS, PCI PIN, and PCI HSM within their card payment security provisions.
Those standards can be highly relevant to organizations whose payment environments include card acquiring, issuance, point-of-sale (POS) infrastructure, or associated payment workflows. They should not be presented as universal UPI encryption standards.
Misunderstanding 4: Encrypting payment data solves the key management problem
Encryption protects data by making it unusable without access to the corresponding cryptographic key. That makes protecting the key itself part of the security architecture.
Payment organizations should know where important keys are generated, where they reside, which systems can invoke them, who can administer them, how key lifecycle actions are authorized, and how those actions are recorded.
The more mature question is not simply whether payment data is encrypted. It is about whether the organization can demonstrate consistent control over the keys and cryptographic operations that protect that data.
Misunderstanding 5: Moving payment cryptography to the cloud transfers the responsibility
Cloud HSM services can change the deployment and operating model, but they do not eliminate the organization’s responsibility for its applications, identities, connectivity, policy choices, and other controls that remain within its scope.
The same principle applies to DPDP. Rule 6 explicitly addresses security provisions between Data Fiduciaries and Data Processors, meaning processor relationships must be reflected in the security model rather than treated purely as contractual arrangements.
A payment organization considering cloud HSM infrastructure should understand who administers the service, how applications connect to it, how key policy is configured, how access is monitored, what redundancy has been selected, and which responsibilities remain with the customer.
What a Stronger Payment Security Architecture Looks Like
For payment infrastructure leaders, the practical challenge is to align DPDP requirements with the payment-security controls already in place across the organization.
A useful review must begin with five areas.
1. Map personal data across the payment environment
Start with the data rather than the HSM.
Identify where digital personal data enters the payment process, where it is stored, which systems receive copies, which processors handle it, which logs contain it, and how long those records remain available.
2. Separate payment cryptography from general data protection
Not every personal data protection requirement is a payment HSM use case.
Some data may be better protected through application encryption, database transparent data encryption (TDE), masking, or tokenization. Payment HSMs become relevant where payment-specific cryptographic functions and keys require a hardware-backed cryptographic boundary and appropriate payment-security controls.
Making this distinction prevents organizations from forcing one technology onto every data-protection problem.
3. Govern keys as shared security infrastructure
When multiple payment systems depend on cryptography, fragmented key management processes become an operational issue.
Organizations should examine how keys are generated, distributed, rotated, backed up, retired, and audited across payment applications. They must also review the separation of duties and privileged access so that control over the cryptographic infrastructure does not depend excessively on a small number of administrators.
4. Connect cryptographic logs with incident response
DPDP Rule 6 requires appropriate logging, monitoring, and review to provide visibility into access to personal data and to support the detection, investigation, and remediation of unauthorized activity.
For cryptographic infrastructure, logs become more useful when security teams can correlate them with application, identity, database, and payment system events. This makes it easier to determine which identity performed an operation, which application requested it, and whether unusual activity coincided with a wider security incident.
The objective is not to create more logs. It is to make the existing security record usable when an investigation is needed.
How Futurex Supports Payment Cryptography at Scale
Futurex approaches payment cryptography as part of a broader enterprise cryptographic architecture.
Futurex’s Excrypt HSM platform provides a hardware-backed cryptographic foundation for supported payment and general-purpose workloads through a native HSM architecture. For the applicable Excrypt payment workload, the platform supports up to 100,000 payment operations per second, enabling payment teams to size cryptographic infrastructure for high-volume workloads without conflating a workload-specific performance figure with a blanket throughput claim.
Futurex’s CryptoHub unified security platform serves a different role. It unifies cryptographic management and orchestration, bringing policy, management, automation, and lifecycle control together across supported cryptographic services.
For organizations that prefer a managed cloud model, Futurex’s VirtuCrypt delivers cryptography through managed cloud services, including cloud payment HSM capabilities for supported transaction acquiring, issuing, and payment-key workflows.
Conclusion
UPI’s growth has made India one of the world’s most demanding environments for digital payment infrastructure.
The final DPDP Rules add another reason to examine that infrastructure carefully. When the substantive security obligations take effect in May 2027, organizations will need to demonstrate reasonable safeguards around digital personal data, including protection mechanisms, access controls, monitoring, resilience, and processor governance.
For data protection leaders, the pertinent question becomes “Does our current payment architecture give us enough control over the data, keys, cryptographic operations and access paths that we will need to defend?”
The answer to that question provides a much better starting point for both DPDP readiness and long-term payment security.
Frequently Asked Questions (FAQs)
When do the DPDP security safeguard requirements take effect?
The Government notified the phased commencement schedule on 13 November 2025. Sections 7 to 10 of the Act, which include the reasonable security safeguard obligations in Section 8, are scheduled to come into force 18 months after notification, on 13 May 2027. The corresponding Rules 5 to 16 follow the same 18-month commencement period.
Are UPI fraud incidents the same as personal data breaches?
No. A UPI fraud can occur without a personal data breach, and a personal data breach can occur without a fraudulent payment. One incident may involve both, depending on how the attacker obtained access and what information was compromised.
What should banks review before selecting payment HSM infrastructure?
Banks should examine the payment functions requiring cryptographic processing, key custody and lifecycle controls, peak cryptographic workload, availability requirements, administrative access, workload isolation, monitoring and integration with the wider security environment before determining the appropriate HSM architecture.
Can cloud payment HSMs support the same security strategy?
Cloud payment HSMs can form part of a payment-security architecture when the service, connectivity, application design, key model, redundancy and responsibility boundaries meet the organization’s requirements. Moving HSM infrastructure to a managed cloud service does not transfer responsibility for the applications, identities, policies and other customer-controlled parts of the architecture.