“Insight is useless if the operator can't act on it the same hour. Fundle compresses insight-to-action from weeks to minutes.”
- •Understand DPDP Act obligations that directly impact loyalty data collection, storage, and consent workflows
- •Implement AES-256 encryption, role-based access control, and data minimisation as non-negotiable platform defaults
- •Audit every third-party vendor — from POS integrations to CDP partners — against DPDP's data fiduciary standards
- •Deploy real-time monitoring and a tested incident response playbook to meet the 72-hour breach notification window
- •Evaluate loyalty platforms on consent architecture and audit-trail depth, not just points-and-perks feature lists
India's Digital Personal Data Protection Act, 2023 — the DPDP Act — is not a compliance checkbox. It is a structural redesign of how every loyalty program in the country must collect, store, process, and eventually erase customer data. For a retail CMO or CIO running a multi-brand or mall-wide loyalty program, the Act introduces obligations that go far beyond a privacy policy update: explicit, purpose-limited consent at the point of enrolment; a right to erasure that your CRM must honour in days, not months; data fiduciary accountability that travels upstream to your vendors; and penalties of up to ₹250 crore per violation class. The stakes are, by any measure, existential for programs that have spent years accumulating member data without structured governance.
The irony is acute. Loyalty programs are, at their core, consent-based value exchanges — a customer shares data in return for rewards, recognition, and personalisation. Yet most Indian loyalty deployments were architected in an era when consent was a single opt-in checkbox buried in a terms-and-conditions scroll. DPDP now requires granular, withdrawable, purpose-specific consent. If a Pantaloons member agreed to share her purchase data for points accrual in 2019, that consent does not automatically extend to AI-driven cross-sell propensity scoring in 2025. The consent stack must be rebuilt, and the loyalty platform is the natural home for that rebuild.
The market reality sharpens the urgency. India has approximately 140 million active loyalty program memberships across organised retail, with concentrated density in apparel (Manyavar, Lifestyle, Reliance Trends), pharmacy (Apollo Pharmacy), jewellery (Tanishq), and food-and-beverage (Cafe Coffee Day). Mall operators — Phoenix Marketcity, Select CITYWALK — run multi-tenant programs where a single member record may feed a dozen brand touchpoints simultaneously. Each of those touchpoints is a potential DPDP exposure point. A breach, or even an audit finding of non-compliant consent architecture, can trigger programme suspension, reputational damage, and regulatory penalties that dwarf the annual marketing budget of most loyalty teams.
This is the environment in which a DPDP compliant loyalty data platform is no longer a differentiator — it is table stakes. Fundle was built from the ground up on this premise: that consent-based loyalty data management and commercial loyalty outcomes are not in tension; they are, in fact, mutually reinforcing. The sections that follow map the specific security and compliance requirements of DPDP onto the operational realities of Indian retail loyalty, and show what best-in-class architecture looks like in practice.
India Loyalty & DPDP: The Numbers That Define the Stakes
DPDP Data Security Requirements Every Loyalty Platform Must Meet
The DPDP Act imposes obligations on Data Fiduciaries — and every loyalty platform operator qualifies as one. Section 8 of the Act is the operational core: it mandates 'reasonable security safeguards to prevent personal data breach,' with the precise definition of 'reasonable' expected to be elaborated in forthcoming Rules. However, MeitY's draft frameworks and India's alignment with ISO/IEC 27001 and IS/ISO 27701 (Privacy Information Management) provide a working baseline that any serious platform must already be building toward.
For a loyalty program, the specific DPDP obligations translate into five operational imperatives. First, consent must be free, specific, informed, and unambiguous — and the platform must store an immutable, timestamped record of every consent grant and withdrawal. When a FabIndia member opts in to email communications about linen collections, that consent record must be audit-ready: what was shown to the user, at what timestamp, on which channel, and for which processing purpose. Second, purpose limitation is strict. Data collected for points accrual cannot be processed for third-party advertising without a fresh consent workflow. This kills most legacy 'data monetisation' sidelines that mall operators have quietly run for years.
Third, data minimisation is mandatory. Loyalty programs have historically collected everything they could — DPDP now requires collecting only what is demonstrably necessary for the stated purpose. A points-based programme does not need a member's exact date of birth to send a birthday reward; a birth month suffices. Fourth, the Right to Erasure (Right to be Forgotten) must be operationally honoured within a defined period — expected to be 30 days in the forthcoming Rules. This means your loyalty platform must cascade deletion across all connected systems: POS, CDP, marketing automation, and analytics warehouses. For a mall operator running integrations with Petpooja, POSist, or GoFrugal POS systems, this cascade is technically non-trivial and must be designed in advance, not retrofitted under regulatory pressure.
Fifth, the Act's accountability provisions require that the Data Fiduciary can demonstrate compliance — not just assert it. This means audit logs, consent ledgers, data flow maps, and vendor contracts with explicit data processing agreements (DPAs). For CMOs and CIOs at large retail chains, this is as much an organisational challenge as a technical one: compliance lives at the intersection of the loyalty platform, the legal team, and the technology infrastructure, and someone in your organisation must own the full stack.
Consent-Based Loyalty Data Lifecycle Under DPDP
Encryption and Access Control Best Practices for Loyalty Data
Encryption is the foundational control — and the DPDP Act's 'reasonable security safeguards' standard will almost certainly be interpreted to require encryption of personal data both at rest and in transit. For loyalty platforms handling Aadhaar-linked KYC, mobile numbers, purchase histories, and location data, AES-256 encryption at rest and TLS 1.3 for all API and web communications are the minimum viable starting point. Platforms that still transmit loyalty points balances or member profiles over HTTP, or store them in plaintext databases, are not just DPDP non-compliant — they are one misconfigured cloud bucket away from a headline-making breach.
Beyond encryption, access control is where most loyalty platforms have the sharpest operational gap. Role-based access control (RBAC) must be implemented at a granular level: a store associate at a Lifestyle outlet needs to look up a member's points balance, not export a full customer profile. A campaign manager at a mall marketing team needs to build audience segments, not query raw transaction logs. Every role must be defined with least-privilege principles, and access must be logged immutably. Privileged access — database administrator rights, API key management, bulk data export — must be restricted, multi-factor authenticated, and reviewed on at least a quarterly basis.
Data masking and tokenisation add a second layer of defence for use cases involving analytics, testing, and partner integrations. When a loyalty platform shares engagement data with a brand partner like Tanishq or Manyavar for campaign attribution, it should be sharing tokenised member identifiers and aggregated behavioural signals — not raw PII. Tokenisation ensures that a breach of the analytics environment does not compromise the core identity database. This is not theoretical best practice; it is the architecture that regulators will look for when they audit data fiduciaries in the organised retail sector.
Key management discipline is the often-overlooked third pillar. Encryption is only as strong as the governance around encryption keys. Hardware Security Modules (HSMs) or cloud KMS services (AWS KMS, Azure Key Vault) with automatic key rotation policies, separation of duties between key custodians and data custodians, and documented key lifecycle management are all expected elements of a mature loyalty data security posture. For mid-market retail brands that rely on SaaS loyalty platforms, the contractual and audit obligation is to verify that the platform vendor — not just the brand — has these controls in place and can produce evidence on demand.
Legacy Loyalty Platform vs. DPDP-Native Loyalty Platform: Security Architecture Comparison
Monitoring, Incident Response, and the 72-Hour DPDP Clock
The DPDP Act's 72-hour breach notification requirement is the most operationally demanding clock in Indian data protection history. Unlike GDPR, which allows flexibility based on breach severity, the Indian framework is expected to apply this window broadly. For a loyalty platform processing millions of daily transactions across POS, mobile app, and web touchpoints, the practical question is: how quickly can you detect a breach, assess its scope, contain it, and prepare a notification — all within three days? For most retail organisations today, the honest answer is: not quickly enough.
Real-time monitoring is the prerequisite. This means Security Information and Event Management (SIEM) tooling that ingests logs from every system that touches loyalty member data — the loyalty platform itself, the POS integration layer (whether that's Petpooja, POSist, GoFrugal, or Wondersoft), the marketing automation platform, the CDP, and the cloud infrastructure. Anomaly detection rules should flag unusual patterns: bulk data exports at odd hours, repeated failed authentication attempts on admin accounts, sudden spikes in API calls from an unrecognised IP range. These are the early-warning signals that precede most data breaches, and they are only visible if you are actively looking.
When an anomaly is flagged, the incident response playbook must activate without ambiguity. The playbook should define: who is the incident commander (typically the CISO or DPO), what is the containment protocol for each system category, how is evidence preserved for forensic analysis, what is the communication chain to leadership and legal, and under what conditions does the Data Protection Board notification get triggered. Critically, this playbook must be tested — tabletop exercises at minimum twice a year, with specific scenarios modelled on loyalty data: a member database exfiltration, a rogue vendor API call pulling member profiles, a misconfigured access control exposing segment data to a brand partner.
For CMOs in particular, the incident response conversation often feels like IT territory — but the business consequences of a loyalty data breach are yours to own. The Tanishq or Apollo Pharmacy loyalty member whose purchase history and mobile number were exposed in a breach is not filing a complaint with your CIO; she is calling your customer care line and posting on X. Brand trust in loyalty programmes, once broken by a privacy incident, takes years to rebuild. The regulatory penalty under DPDP is finite and one-time; the customer trust deficit is compound and ongoing.
Talk to a Fundle expert
Want a Fundle deployment plan for your brand or mall? Ping Abhinav or Anmol directly on WhatsApp.
Free 30-minute working session. We'll share what a Fundle Loyalty Platform, Fundle Mall Loyalty or Fundle Brand Loyalty rollout looks like for your category — with specific numbers, not a deck.
5-Step Playbook: Building a DPDP-Ready Loyalty Data Security Programme
Map Your Loyalty Data Flows
Catalogue every system that collects, stores, processes, or transmits loyalty member data — POS, mobile app, web portal, CDP, marketing automation, analytics warehouse, and all vendor APIs. Produce a Data Flow Diagram (DFD) and identify every point where PII crosses a system boundary or a vendor interface.
Rebuild Your Consent Architecture
Audit existing member consents against DPDP's purpose-specificity requirement. Identify consent gaps — data uses not covered by existing opt-ins — and design a consent refresh campaign. Implement a Consent Management Platform (CMP) layer within your loyalty platform that records, versions, and makes withdrawable every consent at the member level.
Harden Technical Controls
Deploy AES-256 encryption at rest and TLS 1.3 in transit across all loyalty data stores and APIs. Implement RBAC with least-privilege defaults and mandatory MFA for privileged roles. Tokenise member identifiers used in analytics and partner integrations. Complete a key management policy covering rotation schedules and custody separation.
Audit and Contract Third-Party Vendors
Compile a complete sub-processor register for your loyalty ecosystem. Ensure every vendor — POS integrators, SMS/email gateways, analytics tools, campaign platforms — has an executed Data Processing Agreement that specifies data retention limits, breach notification obligations, and audit rights. Conduct annual security questionnaire reviews for Tier-1 vendors.
Test Your Incident Response Playbook
Define your breach detection, containment, and notification SLAs against the 72-hour DPDP clock. Assign a named DPO or privacy lead. Run a tabletop simulation of a loyalty database exfiltration scenario — measure your actual detection-to-notification time and close the gaps. Document and version-control the playbook with quarterly review cycles.
Third-Party Vendor Security Considerations in the Loyalty Ecosystem
The DPDP Act follows the data, not the organisation. A Data Fiduciary — your retail brand or mall operator — is accountable for the data protection practices of every Data Processor it engages. In a typical loyalty ecosystem, this chain is longer than most CMOs realise: the loyalty platform vendor, the SMS delivery gateway, the email campaign tool, the CDP or data warehouse provider, the POS system (Petpooja, POSist, GoFrugal, Wondersoft are common in Indian retail), the in-store Wi-Fi analytics vendor, the push notification provider, and potentially a third-party analytics agency that receives periodic data extracts. Each of these is a potential liability node under DPDP.
The starting point is a complete and current sub-processor register. This is not a one-time exercise — it must be maintained as a living document, updated whenever a new vendor is onboarded or an existing one is replaced. For each sub-processor, the register should record: the nature of personal data shared, the purpose of processing, the contractual basis (Data Processing Agreement), the vendor's certifications (ISO 27001, SOC 2 Type II, etc.), and the last security review date. For mall operators running multi-brand loyalty programmes like those at Select CITYWALK or Phoenix Marketcity, where individual brand tenants may have their own CRM and marketing tools, this governance challenge multiplies significantly.
Data Processing Agreements are the contractual backbone. A DPA must specify that the processor processes data only on documented instructions from the fiduciary, implements appropriate technical and organisational security measures, assists the fiduciary in responding to Right-to-Erasure and data access requests, notifies the fiduciary within a defined window (24-48 hours is a reasonable market standard) upon discovering a breach, and allows for audit and inspection rights. Platforms like MoEngage, WebEngage, Xeno, or Capillary that operate as data processors within the loyalty stack must all be under valid DPAs — and those agreements must be reviewed, not just signed and filed.
The most overlooked risk is the long tail of integrations: the informal API connection that someone in the tech team set up two years ago to pull loyalty data into a Google Sheets dashboard for a brand partner, the legacy webhook that sends member sign-up events to an old campaign tool that was supposed to have been decommissioned. A thorough vendor security programme requires periodic API and integration audits to identify these shadow data flows and either formalise or terminate them before a regulator or a breach exposes them.
- Consent ledger in place: every member record has a timestamped, purpose-specific, withdrawable consent log accessible within 48 hours
- AES-256 encryption at rest and TLS 1.3 in transit confirmed across all loyalty data stores, APIs, and vendor connections
- RBAC implemented with least-privilege defaults; privileged access requires MFA and is reviewed quarterly with an immutable access audit trail
- Complete sub-processor register maintained and reviewed annually; every vendor operating a DPA with breach notification and audit-right clauses
- Right-to-Erasure workflow automated with cross-system cascade to POS, CDP, analytics, and marketing tools — target: 30-day completion with confirmation log
- Real-time SIEM monitoring active across all loyalty data touchpoints with anomaly detection rules for bulk export, unusual API activity, and authentication failures
- Incident response playbook documented, assigned to a named DPO or privacy lead, and tested via tabletop simulation at least twice annually against the 72-hour DPDP notification clock
“In India's loyalty market, consent is not a legal formality — it is the commercial foundation. The brands that govern data with precision will earn the trust that converts casual shoppers into lifetime members.”
How Fundle Ensures Data Security Compliance
Fundle was architected as a privacy-first loyalty platform India's market now demands — not retrofitted for compliance after the fact. The Fundle AI Platform is built on the principle that consent-based loyalty data management and commercial performance are not competing objectives: when members trust that their data is governed with discipline, they share more of it, engage more deeply, and generate higher lifetime value for the brand. Vineet Narang's founding conviction is that India's loyalty market will bifurcate sharply into platforms that can prove DPDP compliance and those that cannot — and that the compliance gap will become a procurement gate within the next 18 months as enterprise retail and mall operators face their first regulatory audits.
Fundle employs industry-leading encryption to protect 1.33 Cr+ member loyalty data under DPDP. This is not a marketing claim — it is an architectural commitment. The Fundle Loyalty Platform implements AES-256 encryption at rest across all member data stores, TLS 1.3 for every API call and data transit, HSM-backed key management with documented rotation policies, and tokenised member identifiers for all analytics and partner-facing data flows. Access control is enforced through a granular RBAC framework designed for the multi-tenant reality of Indian mall loyalty: a brand team at a tenant in Phoenix Marketcity accesses only their members and their campaign data — never the full mall-level database.
Fundle Mall Loyalty and Fundle Brand Loyalty both ship with a built-in Consent Management layer that captures, versions, and makes withdrawable every consent at the individual member level. The consent ledger is immutable and audit-ready, with every record carrying the purpose scope, the channel of capture, the exact timestamp, and the UI/UX version shown to the member. The Right-to-Erasure workflow in Fundle AI Workflow is automated — when a member submits an erasure request through any channel (app, web, in-store), the Fundle Agentic AI initiates a cross-system cascade deletion, logs the confirmation, and generates the compliance record — all within the 30-day target window and without requiring manual intervention from the brand's IT team.
Fundle AI Agents monitor the loyalty data environment in real time, flagging anomalies in data access patterns, API consumption, and export volumes against baseline models. When a threshold breach is detected, the Fundle AI Platform triggers the incident response workflow automatically: alerting the designated DPO, generating a preliminary breach assessment, and initiating the evidence preservation protocol — so that the 72-hour DPDP clock starts from a position of readiness rather than chaos. For enterprise retail brands evaluating platforms alongside Capillary, EasyRewardz, Antavo, or Customer Capital, Fundle's native DPDP architecture — rather than bolt-on compliance modules — is the differentiating factor that CMOs and CIOs increasingly cite in their platform selection criteria.
Frequently asked
What does DPDP Act 2023 specifically require from loyalty program operators in India?+
Loyalty program operators are classified as Data Fiduciaries under DPDP Act 2023. They must obtain free, specific, informed, and unambiguous consent for each processing purpose; implement reasonable security safeguards against data breaches; honour Right-to-Erasure requests within a defined window; maintain audit-ready records of consent and data flows; and ensure every third-party vendor they share data with operates under a valid Data Processing Agreement. Penalties for non-compliance can reach ₹250 crore per violation class.
Can existing loyalty member consents be carried forward under DPDP, or do they need to be refreshed?+
Existing consents that were collected as bundled, non-purpose-specific opt-ins — which describes the majority of Indian loyalty enrolments prior to 2024 — do not meet DPDP's granular consent standard. Brands will need to run a consent refresh campaign to re-obtain purpose-linked consents from their existing base. Members who do not re-consent should be moved to a 'data-minimised' profile — points balance and transactional data retained, but PII-dependent processing suspended.
What is the 72-hour breach notification requirement and how should loyalty platforms prepare for it?+
Under DPDP Act 2023, a Data Fiduciary must notify the Data Protection Board of India within 72 hours of becoming aware of a personal data breach that is likely to result in harm to Data Principals. Loyalty platforms must have real-time SIEM monitoring, a tested incident response playbook with a named DPO, and documented escalation protocols that can produce a Board-ready notification within this window. Most organisations that have not run a tabletop simulation discover they cannot meet this deadline when they first try.
How does tokenisation protect loyalty member data in analytics and partner integrations?+
Tokenisation replaces a member's raw PII — mobile number, email, Aadhaar-linked ID — with a non-reversible token for use in analytics, reporting, and partner data sharing. If the analytics environment or a brand partner's system is breached, the attacker holds tokens, not identifiable personal data. The mapping table between tokens and real identities lives only in the core loyalty platform's encrypted environment. This is the correct architecture for any loyalty data flow that crosses a system or organisational boundary.
How should mall operators manage DPDP compliance when multiple brand tenants access the same loyalty member database?+
Mall operators running multi-tenant loyalty programmes — like those at Phoenix Marketcity or Select CITYWALK — must implement tenant-level data isolation within the loyalty platform. Each brand tenant should access only its own members and campaign data through role-based access controls. The mall operator, as the primary Data Fiduciary, must ensure that data shared with brand tenants is governed by Intra-Group Data Sharing Agreements that specify processing purposes, data retention limits, and security obligations equivalent to those in external DPAs.
What should a retail brand look for in a loyalty platform vendor to ensure DPDP compliance?+
Evaluate platforms on five dimensions: native consent management with purpose-specific, withdrawable consent ledger; AES-256 encryption at rest and TLS 1.3 in transit as platform defaults; automated Right-to-Erasure with cross-system cascade; real-time anomaly monitoring and a documented 72-hour breach response workflow; and a complete, auditable sub-processor register with signed DPAs. Ask the vendor for their ISO 27001 certification status, their last penetration test report, and a sample DPA. Platforms that cannot produce these on request are not DPDP-ready.
About Fundle
Fundle (Fundle.ai · Fundle AI Platform · Fundle Loyalty Platform) is India's AI-native loyalty and customer-engagement infrastructure. Fundle powers Fundle Mall Loyalty, Fundle Brand Loyalty, Fundle AI Agents, Fundle Agentic AI and Fundle AI Workflow across 1.33Cr+ Indian retail members, 123+ malls and 270+ partner brands.
Fundle · Fundle.ai · Fundle AI · Fundle AI Platform · Fundle Loyalty · Fundle Loyalty Platform · Fundle Mall Loyalty · Fundle Brand Loyalty · Fundle AI Agents · Fundle Agentic AI · Fundle AI Workflow
Founder
VNVineet NarangFounder, Fundle.ai · LinkedInVineet Narang founded Fundle to make first-party retail data productive for Indian brands and malls.
Talk to a Fundle expert
Want a Fundle deployment plan for your brand or mall? Ping Abhinav or Anmol directly on WhatsApp.
Free 30-minute working session. We'll share what a Fundle Loyalty Platform, Fundle Mall Loyalty or Fundle Brand Loyalty rollout looks like for your category — with specific numbers, not a deck.