The Practical Steps Banks and Financial Institutions Must Take, Starting with Observability
What Is the DPDP Act?
The Digital Personal Data Protection (DPDP) Act, 2023, along with the DPDP Rules, 2025, is India’s comprehensive framework governing how organisations collect, process, store, secure, and delete personal data.
In simple terms, the Act lays down:
- What personal data can be collected?
- Why it can be collected?
- How long it can it be retained?
- Who can access it?
- When it must be deleted?
- How breaches must be detected, reported, and proven?
The Rules convert the Act into an operational playbook spelling out logging, retention, access control, monitoring, breach reporting, and audit obligations in clear terms.
For banks and financial institutions, DPDP is more than a mere privacy law. The Act asks for a relook at its underlying systems, data, and operations.
What DPDP Means for Banks, NBFCs, and Financial Institutions
For BFSI organisations, DPDP fundamentally changes how compliance is demonstrated.
Earlier, compliance relied heavily on policies, internal controls, and periodic audits.
Under DPDP, organisations must now prove compliance continuously, using:
- Verifiable logs
- Access trails
- Processing records
- Breach detection evidence
- Retention and deletion records
This means:
- Every UPI transaction
- Every digital onboarding journey
- Every loan application
- Every internal access to customer data
must be observable, traceable, auditable, and defensible even months after the event.
DPDP therefore makes observability and log management foundational infrastructure critical.
Step 1: Enforce Role-Based Access and Prove It with Logs
DPDP expectation:
Only authorised individuals and systems should access personal data, and every access must be provable.
Bank-specific examples
- UPI operations:
A customer support executive views failed UPI transactions to resolve disputes — but should not access full account details or PAN data. - Digital onboarding:
A risk analyst reviews KYC verification logs but cannot access raw Aadhaar or document images.
- Lending:
Credit operations teams can view loan status and score outputs, but not raw bureau response files unless authorised.
What must banks do now?
- Go beyond applications and map roles to each touchpoints.
- Capture access logs across:
- UPI switches
- Mobile banking APIs
- Onboarding services
- Loan processing systems
- Log the 'Why' alongside the 'Who.' Your logs must capture not just the user ID, but the Purpose Code (e.g., 'Dispute Resolution') that authorized the data fetch. If an agent accesses a record without a valid Purpose Code, the log itself becomes the alert trigger.
DPDP-Ready Log Schema for a Lending Platform
Why observability matters
Observability platforms stitch together:
- IAM events, Application access logs, API calls, Backend data access
In the above mentioned customer support example, the platform must change how it logs information.
Instead of User: Agent_007 accessed Transaction: 123
Log User: Agent_007 | Purpose: Ticket_#998 | Status: Authorized
This allows banks to answer, with confidence:
“Who accessed which customer data, during which transaction, and was it authorised?”
Step 2: Retain Logs for One Year. Accurately and at Scale
DPDP expectation:
Processing and access logs must be retained for at least one year, without compromise.
There is a fundamental conflict banks and financial institutions would encounter here:
DPDP demands data minimization, while RBI demands audit trails (PMLA [Prevention of Money Laundering Act] and RBI require 5-10 years of record-keeping). Observability platforms bridge this gap by offering Tiered Storage. Keep high-fidelity debug logs for 7 days (operational), but move audit-trail access logs to immutable, long-term cold storage (compliance) for the statutory period.
Bank-specific examples
- UPI:
Logs related to payer/payee identifiers, PSP routing, and failure reasons must be retrievable months later during disputes or investigations. The objective is not transaction replay, but visibility into access and processing of personal identifiers embedded in UPI telemetry. - Onboarding:
Logs showing consent capture, OTP validation, and KYC verification must remain intact for audit and grievance handling.
- Loans:
Decisioning, scoring, and approval workflow logs must be preserved to demonstrate authorised access and lawful processing of personal data during loan workflows.
What banks must do now?
- Move beyond short-term operational log retention
- Ensure logs are:
- Complete
- Tamper-resistant
- Searchable across time
- Plan for an Enterprise Data Lake where you can consolidate your telemetry data
Why observability matters
An observability-grade log platform ensures:
- No silent log drops during traffic spikes
- Accurate historical reconstruction
- Regulator-ready evidence — even a year later
Step 3: Enable On-Demand Log Access Without Fire Drills
DPDP expectation:
Banks must respond quickly to:
- User data access requests
- Regulatory audits
- Lawful government data requests
Bank-specific examples
- UPI dispute:
A customer challenges repeated debit failures — the bank must retrieve logs showing transaction flow, retries, and failure points. The compliance requirement is not the dispute itself, but the controlled access to personal data while resolving it. - Onboarding grievance:
A user asks why onboarding failed — logs must show consent, OTP, document upload, and validation outcomes. - Regulatory request:
Authorities request access logs tied to a specific customer or transaction window.
What banks must do now?
- Standardize log formats across legacy core banking and modern UPI microservices. You cannot grep your way through compliance. Enforce a schema that tags every PII interaction with a traceable Request_ID. Additionally, Index logs using business identifiers:
- Transaction IDs
- Mobile numbers (masked)
- Session IDs
- Account references
- Eliminate manual, team-dependent log retrieval
Why observability matters
Observability platforms enable:
- Single-pane search across systems
- Fast, consistent responses
- Reduced operational and reputational risk
Step 4: Erase Unnecessary Data and Prove Deletion
DPDP expectation:
Personal data must be deleted once its purpose is fulfilled — and deletion must be demonstrable.
Bank-specific examples
- UPI:
Temporary identifiers used for transaction retries should not persist indefinitely. - Onboarding:
Failed or abandoned onboarding attempts must have personal data erased after defined periods. - Loans:
Rejected applications should not retain sensitive personal information beyond regulatory needs.
What banks must do now?
- Implement 'Shift-Left' Privacy in Logging: Ensure developers are not dumping raw payloads into logs. Use your observability pipeline to detect and mask PII patterns (like PAN or Mobile Numbers) before they are written to disk. A clean log is a compliant log.
- Define purpose-driven retention timelines
- Track deletion eligibility and execution
- Maintain proof of erasure
Why observability matters
Observability platforms provide:
- Visibility into where personal data appears in telemetry
- Proof of deletion (via 'Delete_ACK' logs) without becoming a liability itself by storing the data you were supposed to erase
Why Business Observability Is DPDP-Critical
DPDP requires banks to demonstrate:
- Verifiable access
- Accurate logs
- Timely breach detection
- Audit readiness
- Data lifecycle control
This is exactly what business observability delivers:
- A unified audit layer across UPI, onboarding, lending, and core systems
- Early detection of abnormal access or processing behaviour
- Reliable, regulator-ready evidence
Final Takeaway
DPDP compliance is not a documentation exercise.
It is an operational accountability mandate.
Banks that invest early in observability and log management will:
- Simplify audits
- Reduce breach impact
- Respond faster to users and regulators
- Build durable trust in their digital ecosystems
Those that don’t will discover that DPDP failures often begin not with breaches — but with missing logs, fragmented visibility, and unverifiable actions.
