Implementing DPDP Compliance Across Core Banking and Channel Systems: A Program Blueprint for Finacle, BaNCS and Beyond

Every serious conversation about the Digital Personal Data Protection Act, 2023 (DPDP) inside an Indian bank eventually arrives at the same wall. Someone from the legal or compliance team has read the Act, understood the obligations, and drafted a policy. Then they take it to the technology and operations teams — and the room goes quiet. Because the honest question on the table is not "what does the Act require?" It is "how do we make the core banking system do it?"

That is the question this paper is about. Not DPDP in the abstract, but DPDP inside Finacle, TCS BaNCS, Oracle FLEXCUBE, and the dozen channel systems bolted onto them — internet banking, the mobile app, the UPI stack, the loan origination system, the call centre CRM, the branch teller application, the business correspondent (BC) tablet in a village in Bundelkhand. A bank is not one system. It is a constellation of systems that all touch the same customer's personal data, and DPDP applies to every one of them at once.

We will treat this as a program, not a project. A project has an end date; a compliance program is a standing capability. And we will keep returning to one organising idea — the Data Principal 360 view — because without it, everything else in DPDP becomes a set of disconnected point-fixes that fall apart under the first Data Protection Board inquiry.

---

Why core banking is the hardest place to implement DPDP

Most DPDP tooling in the market was built for the marketing website and the CRM. Those are the easy surfaces. The core banking system is hard for structural reasons that every banker will recognise:

• The CBS is the system of record, but not the only one. A single customer's personal data lives in the CBS, the loan origination system, the credit card platform, the treasury system, the AML/CFT engine, the data warehouse, three or four analytics marts, the cheque-truncation archive, and the document management system that holds their scanned Aadhaar and PAN. DPDP's rights — access, correction, erasure — apply to all of it, not just the copy in Finacle.

• Regulatory retention fights data minimisation. The RBI's KYC Master Direction requires records to be retained for years after the account closes. The Prevention of Money-Laundering Act adds its own retention. DPDP requires erasure when the purpose is served. These are not contradictions if you model them correctly, but they are a contradiction if your erasure workflow is a blunt DELETE.

• Consent was never a first-class concept in the CBS. Finacle and BaNCS were architected around account and product, not around purpose of processing. There is no native field that says "this customer consented to cross-sell on 12 March 2026 under notice version v4." You have to build that layer and bind it to the CBS, not inside it.

• The channel sprawl is enormous. Every channel — net banking, mobile, ATM, IVR, the BC network, the DSA/agent network selling loans — collects personal data under some purpose. If your consent and preference state does not propagate to every channel in near real time, a customer who withdraws marketing consent on the app will still get a cross-sell SMS triggered by the loan origination system that never got the memo.

This is why a bank cannot buy DPDP compliance as a bolt-on. It has to implement a data protection control plane that sits alongside the CBS and channels and governs how personal data is collected, used, shared, and retired across all of them. The rest of this paper is the blueprint for that control plane.

---

The organising principle: Data Principal 360

Before we go domain by domain, fix the centre of gravity. Under DPDP the unit of obligation is the Data Principal — the individual. Not the account. Not the customer ID. The person.

This matters because banks think in accounts and products, but DPDP thinks in people and purposes. A single individual might be:

• A savings account holder (CIF 1)
• A joint holder on a spouse's account (CIF 2)
• A guarantor on a business loan (a third relationship)
• A nominee on a fixed deposit
• A former credit-card customer whose closed account still sits in the archive

The Data Protection Board does not care that your CBS has three CIF records for this person. When they exercise their right of access, they are entitled to a summary of all personal data you process about them, across all of those relationships and all of those systems. When they withdraw consent for marketing, it must stop across all of them.

Data Principal 360 is the capability that resolves every identifier a bank holds — CIF, UCIC, customer ID, account numbers, card tokens, loan account numbers, the mobile number, the PAN, the masked Aadhaar reference — to a single canonical person, and then hangs off that person their consent state, their preferences, their active purposes, their open grievances, and their DSR history. It is the spine of the entire program.

A DP360 model is not a "nice to have" reporting dashboard. It is the precondition for every other DPDP right working correctly. Without it, "erase my data" is unanswerable, because you cannot even enumerate what you hold.

Practically, DP360 is built as an identity-resolution and consent-ledger layer that reads from the CBS and channel systems (often via the bank's existing data lake or a CDC/streaming feed), maintains a salted, tokenised identity map so the person can be found without spreading raw PII further, and exposes one authoritative answer to the question "what do we process about this person, why, and with what consent?" Every domain below plugs into it.

---

Domain 1 — Consent management

The obligation

Under Sections 5 and 6, before or at the point of collection the bank must give a clear notice and obtain consent that is free, specific, informed, unconditional and unambiguous, tied to a specified purpose, with withdrawal as easy as granting. And consent is not one thing — a bank processes personal data for many purposes: account servicing, statutory KYC/AML, credit assessment, cross-sell and marketing, analytics, and sharing with credit bureaus and co-lending partners. Each is a separate purpose, and marketing consent must be unbundled from account-servicing consent.

What this means inside the CBS and channels

The CBS cannot be the consent system of record — it has no purpose model. Instead you build a consent management layer that:

1. Renders a versioned notice at every collection point — account opening in the branch on the teller application, digital onboarding in the mobile app, the loan application in the LOS, the card application, the BC's tablet — in English and the applicable Eighth Schedule language.
2. Captures consent as an immutable artifact: the individual, the notice version, the purpose code, the grant/deny, the timestamp, the channel, IP or device, and the officer or system that captured it. This is the evidence pack you will produce for the Board.
3. Binds consent to purpose, not to product, so a single grant can govern processing that spans the CBS, the analytics mart, and the co-lending partner feed.
4. Propagates the consent state in near real time to every channel that acts on it, through a consent API the LOS, the campaign engine, and the CRM all check before processing.

Real-world use case — urban private-sector bank

A metro-tier private bank runs a cross-sell engine that fires pre-approved personal loan offers over SMS, email, WhatsApp and in-app. Pre-DPDP, the engine read straight from the data warehouse. Post-DPDP, every campaign run first calls the consent API keyed on the canonical Data Principal; anyone without a live marketing_comms consent is filtered out before the message is composed. When a customer taps "stop these messages" in the app, the withdrawal is written to the consent ledger and the very next campaign run excludes them — no 30-day lag, no "we'll update it in the next cycle."

Real-world use case — rural / financial-inclusion context

A regional rural bank (RRB) onboards a farmer for a Kisan Credit Card through a business correspondent with a tablet, in Bhojpuri, at a haat (village market). The farmer cannot read English and may have limited literacy. Here the notice must be rendered in the local language, and consent for the mandatory purposes (KYC, credit assessment for the KCC) is distinct from any optional purpose (cross-selling a micro-insurance product). The BC tablet captures the consent artifact offline and syncs it when connectivity returns; the artifact records that consent was given in-language, assisted, at a specific location. If the farmer later says "I never agreed to insurance calls," the bank has a defensible, timestamped, in-language record of exactly what was and was not consented to. This is where consent management stops being a compliance checkbox and becomes customer-trust infrastructure for Bharat, not just India.

---

Domain 2 — Cookie and digital-channel tracking governance

The obligation

The bank's public website, net-banking portal and mobile app set cookies and use SDKs — analytics, session, marketing, fraud-detection. Non-essential cookies and trackers (marketing, behavioural analytics) require consent before they fire; essential ones (session, security, fraud) do not. The consent must be granular and withdrawable, and no non-essential tracker may fire before the customer chooses.

What this means for banking channels

This is broader than a cookie banner. A modern banking app embeds SDKs for crash reporting, product analytics, marketing attribution, and sometimes device-fingerprinting for fraud. Each must be categorised:

• Strictly necessary (login session, CSRF, fraud/velocity checks) — no consent needed, but still disclosed.
• Analytics / performance — consent-gated.
• Marketing / attribution — consent-gated, and unbundled from analytics.

The governance layer must (a) present a granular consent choice on first visit and in the app's privacy settings, (b) suppress non-essential SDKs from initialising until consent is granted — not just hide the banner while the tracker fires anyway, which is the most common failure — and (c) log the cookie/tracker consent as its own artifact tied to the same Data Principal, so the preference centre and the DSR access report can show it.

Real-world use case

A bank's marketing team adds a new attribution SDK to the app to measure a festival campaign. Under a governed model, the SDK is registered in the tracker inventory as marketing, ships disabled by default, and only initialises for users who have granted marketing-tracking consent. The DPO's dashboard shows the new tracker, its category, and the consent rate — so a tracker can never be silently added to a regulated banking app without appearing in the governance inventory. In a sector where a single "bank app is spying on users" headline is a reputational event, this is as much brand protection as it is compliance.

---

Domain 3 — Data Subject Rights (DSR) / Data Principal rights management

The obligation

Sections 11–14 give the Data Principal the right to a summary of the personal data processed and the processing activities, the right to correction, completion, updating and erasure, the right to grievance redressal, and the right to nominate someone to exercise these rights on death or incapacity. The bank must provide readily accessible means to exercise them and respond within the prescribed timelines.

Why this is the hardest domain in a bank

Because of the constellation problem. An access request means enumerating personal data across the CBS, cards, loans, the warehouse, the archive, and every partner the data was shared with. An erasure request collides head-on with statutory retention. This is where Data Principal 360 earns its keep: the DSR workflow does not go hunting through systems by hand — it asks DP360 "everything we hold about this canonical person" and gets a structured answer.

How to implement it as a program, not a helpdesk ticket

1. Intake — a single DSR portal (web + app + a branch/BC-assisted path for customers who are not digital), with identity verification proportionate to the request (an OTP to the registered mobile for access; stronger verification for erasure), so the bank does not hand one person's data to another.

2. Fulfilment orchestration — the request fans out to every system holding the person's data. Access produces a consolidated report; correction writes back to the source of truth and propagates; erasure runs the retention-aware logic below.

3. Retention-aware erasure — this is the subtle part. When a customer asks to be erased, the engine classifies each data element:

   • Data whose purpose is served and carries no legal retention → erased.
   • Data under statutory retention (KYC records under the RBI Master Direction, transaction records under PMLA) → not erased, but the customer is told why it is retained and for how long, and it is locked from all non-statutory processing (no marketing, no analytics).
   • Data needed for an open dispute or legal claim → retained under that documented basis until resolved.

   The output is not a binary "deleted / not deleted" — it is a defensible, itemised disposition the bank can show the Board and the customer.

4. SLA and audit — every DSR is tracked against its statutory clock, and every action is written to an append-only ledger.

Real-world use case — urban

A customer closes their salary account after switching employers and files an erasure request through the app. The engine erases marketing preferences, closes analytics profiling, and purges the closed account from the cross-sell mart — while retaining the KYC record and last-ten-years transaction history under the RBI/PMLA basis, locked from any marketing or analytics use, with an auto-generated explanation sent to the customer stating the legal basis and the retention end-date. The customer gets a genuine, honest answer, and the bank stays compliant with both laws at once.

Real-world use case — rural

A migrant worker who opened a Jan Dhan account in his home district now lives 1,500 km away and wants a copy of everything the bank holds on him, but has no smartphone. The DSR program must include an assisted channel: he walks into any branch or to a BC, is identity-verified via Aadhaar-based OTP to his registered number, and the branch initiates the DSR on his behalf. The consolidated access report is made available in a form he can actually use — printed at the branch, in his language. Rights that only work for the app-literate urban customer are not DPDP-compliant rights; they are a partial implementation that fails the inclusion test the Act implicitly sets.

---

Domain 4 — Preference Centre access

The obligation and the idea

The preference centre is the customer-facing face of consent. It is where a Data Principal sees, in one place, what they have consented to, what channels they have opted into (SMS, email, WhatsApp, call, in-app), and can change any of it — as easily as they granted it. Withdrawal must be comparable in ease to consent.

Implementation in a banking estate

The preference centre is a read/write view onto the consent ledger and DP360, exposed in net banking, the mobile app, and via an assisted branch/BC path. It must show:

• Each purpose and its current consent status, with the notice version it was granted under.
• Each communication channel and its opt-in state.
• Cookie/tracker preferences for the digital channels.
• A one-tap withdraw / change, which writes to the ledger and propagates to every downstream system through the consent API.

The critical engineering property is propagation latency. If a customer switches off "promotional calls" in the preference centre but the outbound dialler campaign list was built yesterday, they will still get called — and that is a withdrawal that was not honoured. The preference centre, the consent ledger, and every consuming system (dialler, SMS gateway, email platform, WhatsApp BSP, in-app messaging) must share one source of truth checked at send time, not a nightly export.

Real-world use case

A customer, irritated by promotional calls during work hours, opens the preference centre and turns off marketing calls while keeping transaction alerts on. Because the dialler checks consent at dial time against the shared ledger, the next campaign simply skips him — but his UPI-credit and cheque-return SMS alerts (a legitimate account-servicing purpose, not marketing) keep flowing. The distinction between servicing and marketing communications, correctly modelled, is what lets the bank honour the withdrawal without breaking the alerts customers actually want.

---

Domain 5 — Records of Processing Activities (RoPA)

The obligation and why banks especially need it

RoPA is the bank's authoritative inventory of what personal data it processes, for what purpose, on what lawful basis, sourced from where, shared with whom, and retained for how long. The DPDP Rules push Significant Data Fiduciaries (which the large banks will be) toward maintaining and auditing exactly this. But even beyond the letter of the law, RoPA is the map without which none of the other domains can be operated — you cannot honour an access request across systems you have not inventoried, and you cannot run a DPIA on a data flow you have not documented.

Building RoPA for a core banking estate

A bank's RoPA is large — hundreds of processing activities across retail, corporate, treasury, cards, and wealth. The practical approach:

1. Discover, don't just interview. Interviews miss the shadow flows — the analyst's spreadsheet extract, the partner SFTP feed, the marketing mart nobody documented. Pair business-process interviews with data discovery across the estate (the CBS, warehouses, file shares, endpoints) so the RoPA reflects reality, not the org chart.
2. Structure each entry around: processing activity, purpose, categories of personal data (and any sensitive categories — financial data, and where present, biometric or health data), lawful basis (consent vs. a legitimate use), source systems, recipients (bureaus, co-lenders, insurers, IT vendors), cross-border transfers if any, and retention.
3. Version it. RoPA is a living record. When a new co-lending partnership launches or a new analytics use-case goes live, the RoPA entry is created before processing begins, and prior versions are retained so you can show the Board what was true at any point in time.
4. Link RoPA to the other domains. Each RoPA entry references the consent purposes that authorise it, the DPIA that assessed it (if high-risk), and the vendors involved. This turns RoPA from a static register into the join table of the whole program.

Real-world use case

Before launching a co-lending arrangement with an NBFC for rural gold loans, the bank creates the RoPA entry first: purpose (co-lending credit assessment and servicing), data shared (identity, KYC, loan and repayment data), lawful basis, recipient (the NBFC and its LSP), retention, and the DPIA reference. When the Board later asks "who do you share rural gold-loan customer data with, and under what basis?", the answer is one query, not a three-week scramble across departments.

---

Domain 6 — Vendor and third-party risk management

The obligation

Under Section 8, a Data Fiduciary may engage a Data Processor only under a valid contract, and — critically — the Fiduciary remains accountable for processing done on its behalf. A breach at a vendor is the bank's breach. Banks have unusually deep third-party estates: the core banking vendor itself, the LSPs and DSAs originating loans, the co-lending partners, the card network and processors, the analytics and martech vendors, the cloud provider, the BPO running the call centre, the print vendor mailing statements, the KYC/CKYC utilities.

Implementing third-party risk as a program

1. Inventory every processor and the data it touches, linked to the RoPA entries that use it. If a vendor does not appear in this inventory, it should not be receiving personal data — that is the control.
2. Contract for it. Data processing addenda that bind the processor to the bank's DPDP obligations: purpose limitation, security safeguards, breach notification to the bank within a tight window, sub-processor disclosure, cooperation with DSRs and audits, and deletion/return on exit.
3. Assess and tier by risk. A martech SaaS handling marketing preferences is a different risk tier from an LSP handling full KYC in a village. Higher-risk processors get deeper due diligence and periodic re-assessment.
4. Monitor continuously, not once at onboarding. Track which vendors hold which data, whether their assessments are current, and whether any have had incidents — so the picture is live when the Board or the bank's own board asks.

Real-world use case — the rural lending edge

Rural loan origination often runs through DSAs, LSPs and BCs — thousands of field agents on tablets, frequently the weakest link in the data-protection chain. A farmer's Aadhaar, PAN, land records and bank details pass through an agent's device. The vendor-risk program has to reach all the way to that tablet: the LSP contract must mandate device security, prohibit local retention of KYC images beyond the sync, and require the agent app to route all personal data through the bank's governed pipeline rather than storing it in a personal cloud folder. The bank's accountability does not stop at the LSP's head office — it extends to the last agent in the last village. Modelling and monitoring that is one of the defining challenges of DPDP in Indian banking's inclusion mandate.

---

Domain 7 — Data Protection Impact Assessment (DPIA)

The obligation

Significant Data Fiduciaries must undertake periodic DPIAs. Beyond the mandate, a DPIA is simply the discipline of assessing, before you launch a high-risk processing activity, what could go wrong for the individual and how you will mitigate it. In banking, high-risk means: new analytics and AI/ML models scoring customers, any processing of sensitive financial (or biometric) data, large-scale profiling, new data-sharing arrangements, and anything involving vulnerable populations.

Making DPIA a gate, not a formality

The program embeds the DPIA as a launch gate in the bank's change process. Before a new processing activity goes live:

1. Trigger — a screening question set decides whether a full DPIA is needed (new purpose, sensitive data, AI-driven decisioning, new sharing, vulnerable subjects → yes).
2. Assess — necessity and proportionality, the specific risks to the Data Principal, and the safeguards (minimisation, security, human review of automated decisions, opt-outs).
3. Decide and record — the DPIA outcome is documented, linked to the RoPA entry, and either clears the launch, clears it with conditions, or blocks it pending mitigation.

Real-world use case

A bank plans an AI-driven credit model that scores thin-file rural customers using alternative data (mobile usage, transaction patterns, even agri-cash-flow signals). This is textbook high-risk: automated decisioning, a vulnerable population, and novel data. The DPIA forces the questions before launch — Is the alternative data necessary and proportionate? What happens to a farmer wrongly denied credit by the model? Is there human review of adverse decisions? Is the training data lawfully sourced? — and records the mitigations (an appeal path with human review, exclusion of prohibited data, bias testing). The model launches having been assessed, not after a regulator or a headline forces the assessment retroactively.

---

Domain 8 — Grievance redressal

The obligation

Section 13 gives the Data Principal a right to a readily available means of grievance redressal from the Data Fiduciary (or its Consent Manager), with a response within the prescribed period, before the individual escalates to the Data Protection Board. For a bank, this sits alongside the existing RBI-mandated grievance machinery (the Banking Ombudsman scheme, the internal grievance cells), and the two must be coherent, not contradictory.

Implementing it

1. A clear, accessible intake for privacy grievances specifically — in the app, on the website, and through the branch/BC/call-centre — distinct from a generic "contact us" so privacy complaints are recognised and routed correctly.
2. Tracking against the statutory clock, with the grievance linked to the Data Principal (via DP360) so the officer handling it can see the customer's consent state, DSR history, and any related complaints in one place.
3. A documented resolution and escalation path — resolved by the DPO's function within the timeline, with a clear route to the Board if the customer remains dissatisfied, and a full audit trail of every grievance for the Board's inevitable question: "show me your grievance log."

Real-world use case

A customer complains that despite withdrawing marketing consent, she is still getting promotional WhatsApp messages. Because the grievance is linked to her DP360 record, the officer immediately sees that her consent was withdrawn on a certain date, but a specific co-lending partner's campaign feed had not honoured the propagation. The grievance does two things: it resolves her individual case (stop the messages, confirm to her), and it surfaces a systemic defect — a downstream consumer not checking consent at send time — which feeds back into the vendor-risk and consent-propagation controls. A well-run grievance function is not just customer service; it is the early-warning system for where the compliance program is leaking.

---

Tying it together: the program-driven operating model

Read the eight domains again and one thing becomes obvious — they are not eight separate projects. They are eight views of one control plane, joined by two shared assets:

• Data Principal 360 — the canonical person, resolving every identifier and carrying consent, preferences, purposes, DSR history and grievances.
• The consent/records ledger — the immutable, versioned system of truth that consent, preferences, RoPA, DPIA and vendor links all read from and write to.

A bank that builds these two assets first, and then implements each domain as a capability plugged into them, ends up with a program that compounds. Consent feeds the preference centre. RoPA maps the DSR fan-out. DPIA gates new RoPA entries. Vendor risk is linked to the RoPA entries that use each vendor. Grievances surface defects in all of the above. Everything reconciles to the same person.

A bank that instead buys a cookie banner from one vendor, a DSR portal from another, and a spreadsheet-based RoPA from a consultant ends up with eight islands that cannot answer a single Board inquiry between them, because none of them agree on who the customer even is.

A pragmatic phasing for a core banking program

1. Foundation (Quarter 1–2): Stand up DP360 identity resolution and the consent ledger. Discover the estate and build the first RoPA from reality. Instrument the CBS and channels with the consent API.
2. Customer-facing rights (Quarter 2–3): Consent capture at every collection point, the preference centre, cookie/tracker governance, and the DSR intake + fulfilment with retention-aware erasure.
3. Governance depth (Quarter 3–4): Vendor-risk inventory and DPAs, the DPIA launch gate, and the grievance function wired to DP360.
4. Assurance (ongoing): DPO oversight, periodic audits, breach-response readiness, and the evidence packs that let you answer the Board in hours, not weeks.

The techno-business reframe

For the board and the CEO, the case is not "we must comply or be fined up to ₹250 crore" — though that is true. The stronger case is that a DP360-anchored data-protection program is a customer-trust and operational-efficiency asset. It gives the bank a single, accurate view of every customer's consent and preferences — which reduces mis-selling complaints, cuts wasted marketing spend on customers who opted out, shortens grievance resolution, and turns a regulatory obligation into a differentiator in a market where trust is the scarcest resource in financial services. In urban India it protects the brand; in rural India, where the bank may be the customer's first-ever formal financial relationship, it is the brand.

---

Closing

DPDP compliance inside Finacle, BaNCS, FLEXCUBE and the channels around them is not a matter of switching on a feature. It is the discipline of building a data-protection control plane that governs personal data across a sprawling, retention-bound, channel-heavy estate — and doing it around the individual, not the account.

Start with Data Principal 360. Build the consent ledger. Then implement consent, cookies, DSR, the preference centre, RoPA, vendor risk, DPIA and grievance as capabilities that all reconcile to the same person and the same truth. Do that, and when the Data Protection Board calls, the bank does not scramble. It answers.

The AutoCops Privacy Monitor implements this control plane — Data Principal 360, a consent and records ledger, and every domain above — designed for the Indian banking estate and its urban-and-rural reality. If you're mapping DPDP onto your core banking and channel systems, that is the problem we built for.