This NBFC client case study shows how Discovery Studio helped map customer data across databases, CSVs, emails, Google Drive, Microsoft 365, paper-to-digital consent records, Postgres tables, MongoDB logs and vendor contracts. The outcome was a DPDP-ready data inventory, RoPA activity map, vendor processor view and Consent Management implementation blueprint.
Overview
For one of our NBFC clients, DPDP readiness did not begin with a consent banner or a privacy policy rewrite.
It began with a more difficult question:
Where is customer data actually sitting across the organisation?
The NBFC initially came in with the common DPDP concerns many financial services companies are facing today.
Should the privacy policy be rewritten? Should the terms and conditions be updated? What should the consent language say? How should old paper-based consent be handled? Which vendors are data processors? Which systems need to sync with a future consent management platform?
But as the Discovery Studio exercise progressed, it became clear that the real challenge was deeper than drafting documents.
The NBFC’s customer data was not sitting in one clean database.
It was spread across core systems, CSV exports, emails, Google Drive folders, Microsoft 365 files, scanned paper forms, Postgres tables, MongoDB logs, marketing lists, support records and vendor workflows.
Some of the data was structured. Much of it was unstructured. Some was actively used. Some was historical. Some was shared with processors. Some existed because older paper-led workflows had slowly shifted into digital files without a formal data map.
This is exactly where Discovery Studio by OpenBlockAI helped the NBFC move from DPDP confusion to implementation readiness.
The goal was not to complete another questionnaire.
The goal was to create a working DPDP baseline: what data exists, where it is stored, why it is processed, who owns it, which vendors receive it, which purposes it supports, what needs consent, what needs review and what must be prepared before Consent Management implementation.
What DPDP problems was the NBFC facing?
The NBFC had multiple teams looking at DPDP from different angles.
The legal team was looking at privacy policy updates, terms and conditions rewriting, consent notices and data protection clauses.
The compliance team wanted to understand what evidence would be required if customer data processing was questioned later.
The technology team needed to know which databases, logs, APIs and internal systems would be affected.
The operations team had customer records in files, spreadsheets, emails and scanned documents.
The business team wanted to continue servicing borrowers, sending reminders, supporting collections, running campaigns and working with vendors without breaking customer journeys.
The problem was not lack of intent.
The problem was that DPDP readiness was being approached from the document layer first.
But policy drafting becomes weak when the underlying data reality is unclear.
The NBFC needed answers to practical questions:
- Which customer data fields are collected during onboarding?
- Which data is used for KYC, underwriting, loan servicing, collections, support and marketing?
- Which personal data is sitting in CSV exports and spreadsheets?
- Which emails and shared folders contain borrower information?
- Which data exists in Postgres tables and MongoDB logs?
- Which old paper consent records were scanned and stored digitally?
- Which vendors receive customer data?
- Which vendor contracts require DPDP-specific review?
- Which processing activities need to be captured for RoPA?
- Which purposes need to be prepared for Consent Management?
Without these answers, rewriting policies and terms would only create a surface-level DPDP response.
Discovery Studio helped shift the NBFC from what should we write to what do we actually process.
Where was customer data actually stored?
The biggest finding was that customer data was far more distributed than expected.
Like many NBFCs, the organisation had structured data inside core platforms, but a large part of the DPDP risk was sitting outside traditional databases.
Structured data was found across core systems and databases.
- Customer master records.
- Loan application data.
- KYC and verification fields.
- Repayment and mandate details.
- Collections data.
- Support and grievance records.
- Postgres tables.
- MongoDB logs and application events.
Unstructured data was spread across operational workflows.
- CSV exports used by operations and business teams.
- Email attachments containing borrower information.
- Google Drive folders with scanned customer forms.
- Microsoft 365 files used for reporting and reconciliation.
- Old paper consent forms converted into scanned files.
- Vendor-shared spreadsheets.
- Marketing campaign lists.
- Support escalations containing customer identifiers.
- Internal trackers used by collections, onboarding and service teams.
This mattered because NBFC DPDP readiness cannot focus only on databases.
A borrower’s phone number may exist in the CRM, but also in a collections spreadsheet.
A KYC document may exist in the onboarding system, but also inside a scanned folder.
A customer email may exist in the loan system, but also inside support tickets, campaign lists and vendor files.
A consent record may have started on paper, then moved into a scanned PDF, then into a shared drive, then into a system field.
If these locations are not discovered and mapped, Consent Management implementation becomes incomplete.
The NBFC needed a full view of structured and unstructured customer data before implementing any consent, preference or privacy workflow.
How did Discovery Studio solve it?
Discovery Studio created a structured DPDP readiness baseline across systems, files, workflows, purposes and vendors.
The first step was data discovery.
Customer data was identified across databases, CSV files, emails, Google Drive, Microsoft 365, scanned documents, Postgres tables, MongoDB logs and internal operating files.
The second step was AI-based attribute mapping.
Instead of treating every customer field as one generic data point, Discovery Studio mapped attributes into business and compliance categories.
- Identity data.
- Contact data.
- Financial data.
- KYC and verification data.
- Loan servicing data.
- Collections data.
- Marketing and cross-sell data.
- Support and grievance data.
- Vendor-shared data.
- Operational and audit data.
This attribute mapping helped the NBFC understand which data supported which business activity.
It also became the base for RoPA activity mapping.
Discovery Studio linked processing activities to purpose, system, data category, owner, vendor involvement, retention consideration and evidence requirement.
The third step was policy and terms alignment.
Once the real processing map was visible, the NBFC could update its privacy policy, terms and conditions, consent notices and internal DPDP documentation with more confidence.
The fourth step was vendor and processor review.
Over 30 vendor contracts and data-sharing relationships were reviewed from a DPDP perspective.
The review focused on what customer data was shared, why it was shared, whether the vendor acted as a processor, whether the purpose was documented, whether data protection obligations were covered and where DPDP-protected agreement terms were required.
The fifth step was Consent Management implementation readiness.
Discovery Studio created a clear implementation blueprint for Consentica.
This included purpose-wise consent requirements, old consent review, paper-to-digital consent transition, preference categories, system dependencies, vendor sync requirements, consent-status mapping and audit evidence needs.
By the end of the engagement, the NBFC had a practical answer to the questions that mattered most:
- Where is customer data stored?
- How is customer data processed?
- Which data is used for financial, marketing, servicing, collections and support purposes?
- Which structured and unstructured systems hold customer data?
- Which vendors receive customer data?
- Which contracts need DPDP protection clauses?
- Which processing activities support RoPA documentation?
- Which journeys require Consent Management?
- Which gaps must be closed before Consentica goes live?
The outcome was not just a DPDP report.
It was an implementation-ready data governance foundation.
The NBFC moved from scattered policies, files and assumptions to a clear view of data inventory, data flows, vendor exposure, RoPA inputs, consent requirements and audit evidence.
That is the value of Discovery Studio.
It helps NBFCs understand their data reality before they implement consent management, rewrite policies or respond to DPDP obligations.
Book Demo
For NBFCs, DPDP readiness is not only about rewriting policies or adding consent text to forms.
It is about knowing where borrower and customer data exists, how it flows, who processes it, which vendors receive it and what evidence supports every decision.
Discovery Studio by OpenBlockAI helps NBFCs build this foundation before Consent Management implementation.
Use Discovery Studio to map structured and unstructured data, review vendor exposure, prepare RoPA inputs, identify policy gaps, assess paper-to-digital consent records and build an implementation blueprint for Consentica.
Explore Discovery Studio for NBFC DPDP readiness.
Book a DPDP readiness demo with OpenBlockAI.
If your NBFC is preparing to move from scattered spreadsheets, paper consent, unclear vendor sharing and fragmented systems to a structured DPDP-ready operating model, this is the right place to start.