Financial Data
Personal data about a person’s accounts, transactions, income, credit and payments.
Financial data is personal information about money: bank accounts, cards, loans, salary, credit scores and transaction history. The DPDP Act covers it, and so do the rules of financial regulators such as the RBI, SEBI and IRDAI.
Meaning of Financial Data
Financial data is covered by the DPDP Act and by sector rules such as RBI, SEBI and IRDAI requirements. Both apply. Payment-card data also follows card-network standards.
Financial data includes account and card numbers, UPI handles, statements, salary slips, tax and PAN details, credit reports, loan and repayment records, investment holdings and insurance policy details. It also includes behavioural traces such as spending patterns or the apps used to repay a loan. Whenever the data relates to an identifiable person it is personal data under Section 2 of the DPDP Act, 2023.
As with health data, the DPDP Act has no separate "sensitive" tier. The earlier SPDI Rules 2011 treated passwords and financial information such as bank account and card details as sensitive, but that label is replaced as the DPDP Act comes into force. The ordinary scheme applies: notice (Section 5, Rule 3), consent or a legitimate use (Sections 6 and 7), reasonable security safeguards (Section 8(5), Rule 6), breach reporting (Section 8(6), Rule 7) and erasure (Section 8(7), Rule 8). Because the harm from misuse is immediate and monetary, the Board is likely to treat strong controls as part of what "reasonable" means here.
Financial institutions work under several overlapping regimes, which Section 38 keeps alive. RBI's KYC directions and the Prevention of Money Laundering Act require identity and transaction records to be retained for a prescribed period, often five years after the relationship ends, and that legal duty can override an erasure request while it lasts. RBI's payment-data storage direction requires payment system data to be stored only in India. RBI's digital lending rules restrict what a lending app may collect and require loan data to be stored on servers in India. Credit information companies work under the Credit Information Companies Act, 2005, and SEBI and IRDAI have their own cyber-security and records rules.
Card data has an extra layer. The PCI DSS standard, which card networks require, prohibits storing the security code after authorisation, and RBI's tokenisation framework generally stops merchants from keeping actual card numbers. These are not DPDP rules, but they show what "reasonable" looks like in practice. Where a firm becomes a Significant Data Fiduciary, Rule 13 adds annual audits, impact assessments and possible data localisation for specified data.
Examples of Financial Data
A lender processes salary slips and bank statements for a loan, and must secure them.
A lending app asks applicants to upload three months of bank statements. It explains the purpose in its notice, deletes unsuccessful applications after a short fixed period, and stores approved loan files in India as RBI's rules expect.
An online store stops saving customers' full card details and switches to network tokens through its payment gateway. A later database leak exposes only order histories, not card numbers, which limits the harm to customers.
A small investment adviser emails client portfolios using a shared mailbox. After a review it moves to a secured client portal with two-step login, removes old attachments from email, and records who viewed each report.
Why Financial Data matters
Financial data leaks lead directly to fraud: account takeovers, fake loans, SIM-swap scams and phishing that uses real transaction details. The victim bears the loss and the stress, and the organisation faces regulator action, compensation claims and loss of customers. Under the DPDP Act, weak security can mean a penalty of up to ₹250 crore, failing to notify a breach up to ₹200 crore, and any other breach of the Act up to ₹50 crore.
Financial firms face a double exposure, since a single incident can trigger action by the Data Protection Board and by the sector regulator, and CERT-In directions require cyber incidents to be reported within six hours. A clean data map, sound vendor oversight and tested incident drills are cheaper than defending two proceedings.
How it works in practice
- 1Collect only what the product needs. A budgeting app does not need a user's contact list, and a loan app should not read personal messages; collecting extra items weakens the case that your purpose is specific.
- 2Separate and mask. Keep account numbers, PAN and card data in dedicated, encrypted stores; show only the last four digits on screens and in reports; and use tokens in analytics systems.
- 3Control access and log it. Restrict statements and credit reports to roles that need them, require multi-factor authentication for staff, and retain logs for at least a year as Rule 6 expects.
- 4Reconcile retention. Build a table with each data type, the sector law that requires retention (for example KYC or tax rules) and the date for deletion afterwards, so you can answer erasure requests with a precise reason.
- 5Check every vendor. Collection agencies, credit-scoring partners, SMS gateways and cloud hosts all handle financial data, so contracts should cover security, India storage where required, breach alerts and deletion.
- 6Practise a breach. Rehearse who informs customers, the Board and the sector regulator, including the detailed report within 72 hours under Rule 7.
Where it appears in the DPDP Act and Rules
Common mistakes to avoid
Assuming financial regulation makes the DPDP Act irrelevant. Both apply under Section 38 unless there is an actual conflict, in which case the DPDP Act prevails to that extent.
Keeping full statements and salary slips forever "for audit". Keep them for the period a law requires and delete them once that period ends.
Sending financial documents over personal chat apps. Use channels that are encrypted, access-controlled and logged.
Forgetting aggregators and collection agents. They process financial data on your behalf, and under Section 8(1) you answer for their lapses.
Compliance tips
Add "financial data" as a field in your data inventory so security and retention controls can be targeted.
Do not use full account or card numbers as keys in logs, analytics or support tickets.
Review consent screens in your app so that credit-bureau checks, marketing and data sharing are each requested separately.
Use a Consent Manager for account-aggregator style sharing only after checking that it is registered with the Board once registration opens.
Common questions about Financial Data
Is bank account information sensitive data under the DPDP Act?
The DPDP Act has no sensitive category, so it is personal data. The earlier SPDI Rules 2011 treated it as sensitive. Either way, treat it with high care: encryption, access control and prompt breach reporting are what regulators expect.
Does RBI's rule override the DPDP Act for banks?
No. Under Section 38 the DPDP Act is in addition to other laws, so banks follow both. Only if a provision actually conflicts does the DPDP Act prevail to that extent. Retention duties under KYC rules usually remain in force.
Can a lender keep my data after I repay a loan?
Only as long as the purpose needs it or a law requires it, such as KYC or tax record rules. After that, Section 8(7) expects erasure. You can ask the lender what it holds and why.
Who is responsible if a payment vendor leaks card data?
The business that decided why and how the data is processed is the Data Fiduciary and stays responsible under Section 8(1), even if a vendor made the mistake. The contract may let it recover costs, but the duty to the customer and the Board stays with it.