Written by

Sumeshwar Pandey

View Profile
18 min read
India BFSI RBI KYC DPDP Act

KYC Refresh, Re-Consent, and Data Minimization

How Indian BFSI engineering teams can design KYC refresh and consent flows that satisfy RBI KYC Directions and the DPDP Act while keeping channels, risk engines, and data stores aligned.
Key takeaways
  • Treat KYC refresh, re-consent, and data minimization as a single event-driven control flow running across core banking, channels, and data platforms, rather than three separate compliance projects.
  • Encode RBI KYC risk categories and periodicity into schedulers and risk engines, while modelling DPDP lawful bases so systems can distinguish consent-based processing from legal obligations.
  • Use a dedicated consent service or platform as the system of record for consent artefacts, purpose binding, and withdrawals, with APIs that every channel and downstream system can query in real time.
  • Implement data minimization through attribute-level whitelisting, purpose-tagged data models, and layered retention policies that respect both DPDP erasure rights and RBI/SEBI/IRDAI record-keeping duties.
  • Build a validation matrix and telemetry that link common failure modes—stale consent, missed KYC triggers, over-retention—to concrete tests, dashboards, and audit artefacts.
Imagine your bank’s quarterly steering committee looking at a dashboard that shows a million retail customers due for periodic KYC updation over the next six months. At the same time, your DPDP implementation workstream is cataloguing personal data stores, and your marketing team is asking for granular consent-based campaigns. KYC refresh schedules live in the core, consent toggles sit in the mobile app and CRM, and retention rules are partially coded into your data lake but not into branch systems. Everything touches the same customer profile, but each control is running on a different logic and data model.
Engineering teams in Indian banks, NBFCs, and fintechs are feeling this collision directly. RBI’s KYC Directions expect risk-based periodic updation, with specific frequencies for high-, medium-, and low-risk customers. The DPDP Act expects verifiable, revocable consent for optional processing and strict data minimisation and retention. Account Aggregator rails introduce a separate consent artefact for financial-data sharing. When these obligations are implemented in silos, predictable operational issues show up: customers being spammed with duplicate KYC reminders across channels, stale consent states in downstream systems, and no single place where an auditor can see why a particular piece of data was collected, how long it will be kept, and under what lawful basis.
A more workable approach is to treat KYC refresh, re-consent, and data minimisation as one coherent control-flow and data-lifecycle problem. That means designing services that observe customer and risk events, decide whether KYC or consent actions are due, change customer state and data exposure across systems, and record every step in an auditable ledger. Once you frame the problem this way, it becomes clearer where to put the logic, what to delegate to external platforms, and how to keep customer experience predictable across branch, mobile, web, and call centre.
RBI’s KYC Master Direction requires regulated entities to classify customers into risk categories such as low, medium, and high, based on factors like product type, geography, business profile, and transaction behaviour. The same Direction prescribes that KYC for higher-risk customers must be updated more frequently than for lower-risk segments, with indicative periodicity—typically shorter cycles for high-risk customers and cycles that can extend close to a decade for low-risk segments. It also mandates event-based due diligence when there is a change in the customer’s profile, document expiry, or suspicion of money laundering or terrorist financing. For implementation, this translates into mandatory attributes in your customer profile store: risk category, last full KYC date, KYC method, list of KYC documents with expiry dates, and status flags for states such as “refresh due”, “reminder sent”, “account partially frozen”, and “account closed due to non-compliance”.[1]
The DPDP Act sits alongside this with a different lens. It defines your institution as a data fiduciary and sets out duties to collect only data that is necessary for a specified purpose, use it only for that purpose or other compatible purposes, and retain it only for as long as reasonably necessary for that purpose or for a legal obligation. It treats consent as one lawful basis for processing personal data, alongside others such as compliance with legal obligations, where KYC clearly falls. That means most core KYC processing is not optional and is not strictly consent-based; instead, your systems should record that KYC data is processed under a legal-obligation basis, while consent is typically required for secondary uses such as marketing, cross-selling, or sharing data with non-essential third parties.[2]
Consent under the DPDP Act must be free, specific, informed, unambiguous, and capable of being withdrawn as easily as it was given. Technically, you need a consent artefact with fields such as data principal identifier, purposes (each tagged to internal purpose codes), categories of personal data, processors or recipients, start and end time or condition, consent language version, and a timestamped proof of the individual’s affirmative action. You also need to model withdrawal as a first-class event that immediately changes what downstream systems may do with that data.[3]
Putting these guardrails together, a system-level view emerges. RBI KYC rules tell you when a KYC refresh must be triggered and what happens if the customer does not cooperate. DPDP tells you which attributes and uses should be minimised, which uses require consent, and when data must be erased or anonymised. For design, this means your orchestration layer must evaluate three questions on every relevant event: is a KYC refresh required under RBI rules, is new or updated consent required for any purpose under DPDP, and does any existing data or consent now exceed its retention or purpose boundary and need to be restricted or deleted.
Mapping key RBI KYC and DPDP obligations into system responsibilities.
Regulatory concept What it requires in practice System design implications
RBI KYC risk categorisation and periodic updation Classify customers into low, medium, and high risk and refresh KYC more frequently for higher-risk segments. Store risk category, last full KYC date, refresh due dates, and account restriction states; implement schedulers that compute when refresh is due per category.
RBI event-based due diligence Trigger additional KYC checks when there is document expiry, profile change, or suspicion of money laundering or terrorist financing. Subscribe the orchestrator to AML alerts, document-expiry feeds, and profile-change events so it can emit KYC_REFRESH_DUE events with appropriate reason codes.
DPDP lawful bases and legal obligation for KYC data Treat core KYC processing as based on legal obligation, not consent, while using consent for optional or secondary purposes such as marketing or certain data sharing. Model lawful basis at dataset and attribute level, so systems can distinguish mandatory processing from consent-based uses when evaluating withdrawals or erasure requests.
DPDP consent artefact quality and withdrawal rights Capture consent that is free, specific, informed, unambiguous, and easy to withdraw, and record withdrawals in a way that can be acted on quickly. Use a central consent ledger with versioned artefacts, purpose tags, processor lists, timestamps, and explicit withdrawal events that downstream systems can query or subscribe to.
DPDP data minimisation and storage limitation Collect only attributes necessary for defined purposes and retain them only for as long as required for that purpose or for a legal obligation such as KYC record-keeping or tax audits. Implement purpose–attribute matrices, attribute-level whitelisting in APIs and ETL jobs, dataset-level retention metadata, and automated archival/deletion jobs across primary and analytical stores.
Account Aggregator consent-based financial-information sharing Use a standardised consent artefact to control which financial information can be shared between Financial Information Providers and Financial Information Users for defined purposes and durations. Treat AA consents as an additional input to the orchestrator and consent ledger so that internal systems respect AA consent creation, expiry, and revocation events when pulling or reusing AA data.
A practical reference architecture for KYC refresh and re-consent in an Indian financial institution usually has a small number of clearly defined services. At the edge you have channels such as mobile banking, internet banking, branch teller systems, and call-centre desktops. Beneath that sits a KYC and Consent Orchestrator that owns the control flow for refresh journeys. It consumes events from a scheduler (for time-based periodicity), transaction-monitoring and risk engines (for risk or behaviour triggers), document stores (for ID expiry), product systems (for upgrades or cross-sell offers), and consent services (for withdrawals or scope changes). Core banking, LOS/LMS, and CRM systems act as primary systems of record for account and relationship data, while a dedicated consent service or platform is the system of record for consent artefacts. A data warehouse and log aggregation stack receive curated, minimised views of KYC and consent data for analytics and monitoring, and an immutable audit log records every KYC and consent decision with the relevant context.
Illustrative KYC refresh and re-consent control flow
for each incoming_event in event_stream:

    customer = load_customer_profile(incoming_event.customer_id)

    risk_profile = customer.risk_category
    last_kyc_date = customer.last_full_kyc_date
    documents = customer.kyc_documents
    consents = fetch_current_consents(customer.id)

    # 1. Evaluate KYC obligations
    if periodic_kyc_due(risk_profile, last_kyc_date):
        emit_event(
            type="KYC_REFRESH_DUE",
            customer_id=customer.id,
            reason="PERIODICITY",
            source_event=incoming_event.id
        )

    if any_document_expired(documents):
        emit_event(
            type="KYC_REFRESH_DUE",
            customer_id=customer.id,
            reason="DOCUMENT_EXPIRY",
            source_event=incoming_event.id
        )

    if risk_increased(incoming_event, risk_profile):
        update_customer_risk(customer.id, new_risk=incoming_event.new_risk)
        emit_event(
            type="KYC_REFRESH_DUE",
            customer_id=customer.id,
            reason="RISK_CHANGE",
            source_event=incoming_event.id
        )

    # 2. Evaluate consent coverage
    new_purposes = derive_purposes_from_event(incoming_event)
    missing_consent_purposes = purposes_not_covered(consents, new_purposes)

    if missing_consent_purposes:
        emit_event(
            type="RECONSENT_REQUIRED",
            customer_id=customer.id,
            purposes=missing_consent_purposes,
            source_event=incoming_event.id
        )

    if consent_withdrawn(incoming_event):
        revoke_consent(incoming_event.consent_id)
        emit_event(
            type="CONSENT_WITHDRAWN",
            customer_id=customer.id,
            consent_id=incoming_event.consent_id,
            source_event=incoming_event.id
        )

    # 3. Persist state and audit trail
    write_audit_log(
        customer_id=customer.id,
        event=incoming_event,
        decisions=derived_decisions_for_event()
    )
This loop shows the orchestrator observing events, recalculating risk and KYC state, deciding which refresh or re-consent actions are due, emitting typed events to channels and back-office systems, and writing a single audit record that ties the input event to all derived decisions.
The heart of the design is this KYC and Consent Orchestrator. It evaluates each event against periodicity rules, document-expiry checks, risk changes from AML systems, and gaps in consent coverage for new or changed purposes. For every condition that evaluates to true, the orchestrator emits a typed event such as “KYC_REFRESH_DUE” or “RECONSENT_REQUIRED” with reason codes and suggested channels. Channel services pick up those events to present KYC or consent journeys, and back-office systems use them to schedule outreach or apply account-status changes when deadlines pass.
Cross-channel consistency depends on making the orchestrator and the consent service authoritative. Channels should not embed bespoke logic for when KYC refresh is due or when to ask for re-consent; instead, they query the orchestrator or subscribe to its events. When a mobile app completes a re-KYC journey, it calls the orchestrator with a signed payload of new KYC data; the orchestrator then updates the core customer record, recalculates risk, updates the last KYC date, and writes an audit-log entry with the source channel and evidence of verification. Similarly, when a branch user captures consent on a tablet, they should call the central consent service, which issues a consent identifier that is later referenced by CRM, data warehouses, and third-party processors. This pattern keeps each channel thin and reduces the chances of conflicting states across touchpoints.
Account Aggregator introduces an additional integration path. If you act as a Financial Information User, you may be pulling bank-statement or other financial data under an AA consent artefact to support underwriting or ongoing monitoring. Those consents are governed by RBI’s directions for NBFC-Account Aggregators and are limited to specific financial-information flows between Financial Information Providers and Users. Architecturally, you can treat AA consent artefacts as one more event source: when an AA consent is created, revoked, or expires, the orchestrator updates internal flags about which financial-data feeds are allowed. However, AA consents do not replace your obligations under the DPDP Act for other personal data or internal processing, so you still need your own consent and data-minimisation logic for non-AA datasets.[4]
A phased rollout keeps the orchestrator from destabilising existing core systems.
  1. Map regulatory triggers to internal events
    Catalogue all KYC- and consent-relevant triggers—time-based periodicity, document expiry, risk-score changes, product upgrades, consent withdrawal—and map each one to an internal event from core banking, AML, CRM, or Account Aggregator systems.
  2. Define orchestrator contracts and schemas
    Design the event schema, decision types such as KYC_REFRESH_DUE and RECONSENT_REQUIRED, and API contracts for channels and back-office systems, including the audit-log format.
  3. Centralise consent into a single service
    Either build or select a consent service that issues versioned consent identifiers, exposes query APIs, and can be called from every channel and data pipeline.
  4. Pilot with one segment and one channel
    Start with a constrained segment, such as high-risk retail customers in the mobile channel, to validate that events, journeys, and account-state transitions behave as expected before scaling out.
  5. Roll out to remaining channels with telemetry
    Extend coverage across web, branch, and call centre once dashboards show stable refresh rates, low error rates, and clean audit trails.

Implementing data minimization across KYC pipelines

Data minimisation in KYC contexts is less about deleting everything aggressively and more about being explicit about which attributes are needed for which purposes, and enforcing that mapping everywhere data flows. A practical first step is to build a purpose–attribute matrix: list core purposes such as onboarding KYC, ongoing customer due diligence, regulatory reporting, fraud and AML monitoring, credit-risk modelling, and marketing or cross-sell, then list which KYC attributes are strictly necessary for each. For example, PAN and date of birth are essential for onboarding and regulatory reporting, but may not be needed in raw form for certain aggregated marketing analytics; a full address may be required for KYC and card dispatch but not for email newsletter targeting. That matrix should live in a configuration or metadata service, not only in documentation, so that APIs and ETL jobs can automatically enforce attribute-level whitelisting.
Operational systems can then expose purpose-scoped views rather than raw tables. The KYC profile store might offer an internal API that takes a customer identifier and a declared purpose code, and returns only the attributes permitted for that purpose. For analytics, ETL pipelines can materialise separate datasets for AML, risk, and marketing, drawing from the same source but dropping or tokenising attributes that are not required. Tokenisation or pseudonymisation of identifiers for certain analytical use cases reduces exposure in the data lake while still supporting models and dashboards. Each dataset should carry metadata such as the primary purpose, lawful basis, linked consent identifiers where applicable, and a computed retention end date so that retention jobs can decide when to archive, anonymise, or delete records.[2]
Retention must balance DPDP storage limitation with sectoral regulations. RBI, securities, insurance, and tax regulators mandate that certain records, especially those related to KYC and transactions, be retained for defined periods after the end of the relationship or the relevant transaction. Engineering teams can model this by tying retention policies to legal bases: for data processed solely on the basis of consent, withdrawal should typically trigger immediate or near-term deletion or strong restriction, subject to operational records needed for proof. For data processed under legal obligation, such as KYC documents and key identifiers, consent withdrawal does not by itself require deletion, but it should restrict new secondary uses and schedule deletion once the statutory retention period ends. An implementation pattern that works well is to maintain an “active processing” flag and a separate “retention until” date for each dataset; withdrawal flips the active flag off for consent-based purposes, while legal-retention rules determine when the record is physically deleted or irreversibly anonymised.[1]
Downstream systems and logs are easy places to lose control of minimisation. Transaction-monitoring tools, CRM exports, call recordings, and debug logs often hold KYC attributes long after the original system has cleaned them up. A defensible design enumerates these sinks in the same purpose–attribute matrix, pushes masking or redaction as close to the source as possible, and subjects log and backup stores to the same retention engine as primary databases. In many institutions, a simple telemetry metric—such as tracking the number of customer records in long-term analytical stores by age bucket—quickly shows whether minimisation and retention rules are actually being enforced end-to-end.
Once you start wiring KYC refresh, consent lifecycle, and data minimisation together, certain failure modes recur. One common pattern is over-collection at onboarding: forms and APIs capture far more attributes than are needed for the product being opened, simply because they were designed for the most demanding product and then reused. This increases your attack surface and makes it hard to argue necessity under DPDP.
Another frequent failure is stale or inconsistent risk categorisation. AML alerts or behavioural-scoring engines may flag higher risk, but the core customer risk flag is not updated, so KYC periodicity logic continues to treat the customer as low or medium risk. A third pattern is missed or noisy KYC triggers: schedulers that do not account for certain customer types, or that run on unreliable reference dates, either leave some customers without timely refresh prompts or spam them with repeated requests.
Consent management adds its own problems. Without a single consent ledger, mobile apps, web portals, and branches may all capture consent in different formats and store it locally. That leads to inconsistent states, such as CRM believing a customer has opted into marketing while the mobile app shows them as opted out, or Account Aggregator consent revocation not propagating into internal data pulls. Withdrawal handling is another weak spot: some systems record withdrawal but do not cascade it to marketing clouds, analytics data stores, or partner APIs, so data continues to be processed beyond the individual’s expressed choice.
Data minimisation and retention failures are usually visible in your data warehouse and log infrastructure. ETL jobs may copy full KYC tables into analytical stores with no column pruning, or retention scripts may exist only for the core banking database but not for CRM or call recordings. Over time, this leads to multiple conflicting “last KYC date” fields, inconsistent treatment of the same attribute across systems, and personal data lingering in logs for many years beyond statutory periods. Another subtle failure mode is prematurely deleting or anonymising data that is still required for regulatory investigations or tax audits, which can create its own form of non-compliance.
A structured validation matrix helps move from anecdotal issues to systematic assurance. For KYC periodicity, maintain a test dataset of synthetic customers across risk categories, simulate date progression, and assert that the orchestrator emits refresh events at the expected intervals and no earlier. For risk-linked refresh, pipe synthetic high-risk transactions into AML systems and check that the resulting alerts cause customer risk categories and refresh schedules to update. For consent flows, tests should create, update, and withdraw consent across channels, then verify that the central consent service reflects the latest state and that CRM, marketing platforms, and data warehouses no longer process withdrawn data. For data minimisation and retention, QA and data-governance teams can run queries that sample tables and logs by age, checking that attributes not listed in the purpose–attribute matrix are absent and that records past their “retention until” date are either deleted or irreversibly anonymised. Instrumentation that reports counts of active, restricted, and pending-deletion records by system gives operations and compliance teams an ongoing view of whether controls are working.
Common failure modes in KYC refresh, consent, and data minimisation, with observable symptoms and validation approaches.
Failure mode Observable symptom Validation or monitoring check
Over-collection at onboarding Onboarding forms and APIs request many attributes that are unused for the specific product or segment. Compare forms and API schemas against the purpose–attribute matrix; flag attributes that are not required for any declared purpose and remove or segregate them.
Stale or inconsistent risk categorisation AML tools show a customer as high risk while the core system still marks them as low or medium risk, so KYC refresh is not accelerated. Inject synthetic AML alerts and verify that customer risk flags and refresh schedules update consistently across core banking, orchestrator, and reporting systems.
Missed or noisy KYC triggers from schedulers Some customers never receive refresh prompts; others receive repeated prompts in quick succession from different channels. Run time-shifted simulations on synthetic customers with varying last-KYC dates and verify exactly one refresh event per expected interval; monitor production for duplicate refresh events per customer and period.
Fragmented consent ledgers across channels CRM, mobile app, and branch systems disagree on whether a customer has opted into marketing or data sharing. Perform reconciliation jobs that compare per-customer consent state across all systems with the central consent ledger; treat any mismatch as a defect and trace which channel is not using the central APIs.
Consent withdrawal not cascaded to downstream systems Customers withdraw consent in one channel but still receive marketing messages or their data continues to appear in analytical datasets for that purpose. In test environments, withdraw consent and confirm that marketing platforms, partner APIs, and analytics tables no longer contain the individual’s data for the withdrawn purposes; monitor production for events where processing occurs after a withdrawal timestamp.
Uncontrolled analytical copies and log retention Historical KYC attributes appear in many data marts and log indices, with no clear ownership or retention policy; the same attribute shows different values in different places. Inventory analytical datasets and log indices containing KYC attributes; validate that each has purpose and retention metadata and that attributes not in the purpose–attribute matrix are masked or removed; monitor record counts by age bucket.
Premature deletion or anonymisation of records still needed for investigations Historical KYC or transaction records required for an audit or dispute are missing or irreversibly anonymised. Test retention logic with scenarios that include open investigations, unresolved disputes, or pending regulatory queries to confirm that these records are exempted or tagged for extended retention until closure.
A repeatable validation routine avoids regressions as regulations, products, and code evolve.
  1. Assemble synthetic customer and consent scenarios
    Define synthetic customers across risk categories, products, and channel preferences, along with representative consent states, including withdrawals and conflicting consents.
  2. Build an orchestrator test harness
    Drive the KYC and Consent Orchestrator with simulated time, AML alerts, AA consent events, and channel interactions, and assert on the emitted events and state transitions.
  3. Automate cross-system reconciliation checks
    Regularly compare key fields such as risk category, last KYC date, consent states, and retention flags across core banking, CRM, consent ledger, and analytical stores to detect drift.
  4. Wire validation into CI/CD and periodic audits
    Run these tests as part of CI/CD for orchestrator, consent, and data-pipeline changes, and schedule additional runs ahead of regulatory audits or major product launches.
Common issues and practical fixes include:
  • Refresh events are emitted but customers do not see journeys in certain channels: verify that those channels subscribe to the orchestrator’s event bus or polling APIs, and that feature flags or campaign configurations are not filtering out the events.
  • Different systems show different consent states: confirm that all channels write to and read from the central consent ledger, not local flags; run reconciliation jobs and treat any direct writes to downstream systems as defects.
  • Data older than expected retention limits persists in logs or analytics: ensure that log indices and data marts are registered with the same retention engine as primary stores, and that their schemas include the necessary purpose and retention metadata.
  • High dropout in KYC refresh journeys: inspect telemetry by channel to distinguish UX problems (for example, long forms, poor document capture) from policy issues (for example, too-frequent prompts for low-risk customers) before changing triggers or applying restrictions.
Building a consent service in-house is feasible, but many Indian financial institutions are now evaluating specialised consent management platforms designed around the DPDP Act and its formal Consent Manager role. In the architecture described earlier, such a platform sits where the consent service appears: as the single system of record for consent artefacts, purpose binding, and withdrawals, with APIs used by channels, orchestrators, CRM, data platforms, and in some cases partner systems. The KYC and Consent Orchestrator still owns refresh logic and regulatory state machines, but delegates the creation, validation, and lookup of consent artefacts to the external platform.[2]
Digital Anumarti - Service is an example of a DPDP-focused consent management platform that an engineering team might evaluate for this role. Deployments in other regulated sectors show it used to digitise consent capture at the edge, maintain an API-driven consent ledger tied to operational systems, generate verifiable consent receipts, and enforce retention and revocation flows that move data from active stores into encrypted cold storage once legal obligations are satisfied. For a BFSI workload, evaluation criteria typically include the expressiveness of the purpose and attribute model, the quality of APIs and webhooks, support for multilingual consent interfaces, latency overhead when called synchronously from high-traffic channels, capabilities for mapping consent states into role-based access control, and the level of audit logging and reporting available to compliance and data-protection officers. Reviewing product documentation and deployment references on the Digital Anumarti - Service site can help your team scope a proof-of-concept before committing to deeper integration.[5]

Digital Anumarti - Service patterns relevant to BFSI evaluators

Digital Anumarti - Service

1

API-driven consent ledger used as a system of record

Digital Anumarti - Brand describes deployments where Digital Anumarti - Service provided an API-driven consent ledger integrated directly with an Electronic Health Records platform, replacing paper consent forms with versioned, queryable consent artefacts.

Why it matters for you

For KYC refresh, the same pattern can be applied to core banking or LOS/LMS systems so that every service queries one ledger for current consent state rather than relying on channel-specific flags.

2

Hashed consent receipts for legal defensibility

In a diagnostic-labs deployment, Digital Anumarti - Service generated secure, hashed consent receipts that were stored and presented alongside final reports to demonstrate that data was processed on a valid consent basis.

Why it matters for you

A similar pattern could support BFSI audits by giving teams tamper-evident proof that marketing or data-sharing consents were in place at the time of processing.

3

Automated retention and deletion pipelines after retention expiry

Digital Anumarti - Brand documents automated pipelines where Digital Anumarti - Service identified records that had reached the end of their legal retention period and purged or archived them in line with data-minimisation principles.

Why it matters for you

This shows how retention logic can be externalised from individual applications while still enforcing DPDP-aligned deletion across multiple stores.

4

Revocation flows that move data out of active processing

In one hospital deployment, when a patient revoked consent, Digital Anumarti - Service triggered a cascading update that moved records from active operational databases into encrypted cold-storage logs, removing them from day-to-day processing while keeping them for medico-legal obligations.

Why it matters for you

For financial institutions, a similar revocation pipeline can separate active-processing datasets from legal-retention-only datasets when customers withdraw optional consents.

5

Multilingual and server-side consent capture at the edge

Case studies describe Digital Anumarti - Service deployments with multilingual consent capture on front-desk tablets and a server-side preference centre that used event-driven syncing and webhooks to update CRM platforms when individuals opted out of secondary uses.

Why it matters for you

These patterns are directly relevant to Indian BFSI channels where consent must be captured in multiple languages and propagated in real time into CRM and marketing stacks without exposing raw consent logic in client applications.

Evidence Healthcare case study – consent ledger integration

Governance patterns, open questions, and limitations of this approach

Even with a clean architecture, refresh and consent controls will drift without clear ownership. Many institutions treat KYC and consent orchestration as a shared responsibility between a platform engineering team and a central compliance or data-governance function. The engineering team owns the services, APIs, and data models; compliance and legal own the mappings from regulations to configuration, such as risk-scoring criteria, refresh-periodicity tables, and retention durations. A change-control process should ensure that whenever RBI updates the KYC Directions or the data-protection authority issues new guidance, someone explicitly assesses whether any configuration or code in the orchestrator, consent service, or retention engine needs to change, and tracks those changes through testing and deployment.
Monitoring and reporting are the other side of governance. Dashboards that show KYC refresh status by risk category, channel-level completion and dropout rates for refresh and consent journeys, counts of customers with conflicting consent states across systems, and volumes of data nearing or exceeding retention limits help teams spot problems early. Periodic internal audits can sample customer files end-to-end—from onboarding through re-KYC, consent changes, and eventual closure—to check whether recorded events and data states match policy. Integrations with Account Aggregator and external consent platforms should be included in those audits, with particular attention to how AA consents map to internal purposes and how external consent withdrawals propagate into your systems.
There are also areas where technical design cannot fully resolve ambiguity. For example, how to treat partial KYC in complex corporate structures, how much anonymisation is sufficient to take data outside DPDP scope for certain analytical models, or how to interpret compatibility of purposes when reusing KYC data for new digital services are questions that depend on evolving regulatory and supervisory views. An architecture that keeps legal bases, purposes, and retention policies configurable, and that maintains accurate data lineage, makes it easier to change course when interpretations shift, but it does not make those policy decisions for you.
Any decision to adopt a dedicated consent management platform should still assume that you retain architectural responsibility. A platform can centralise artefacts and make DPDP alignment more operationally manageable, but it will not decide your lawful bases, retention periods, or risk models; those remain design choices that engineering, risk, and legal teams must make together.
FAQs

RBI’s KYC Directions expect regulated entities to impose graduated restrictions on accounts where customers do not cooperate with periodic updation, typically moving from reminders to partial restrictions and eventually to freezing or closing accounts, subject to customer notice and applicable product rules. Technically, this argues for modelling account–KYC status as a state machine rather than a binary flag. The KYC and Consent Orchestrator can track key dates such as refresh due date, reminder sent dates, and hard cutoff date, and emit events like “KYC_REMINDER_DUE”, “KYC_SOFT_RESTRICTION_DUE”, and “KYC_HARD_RESTRICTION_DUE”. Core banking and channel systems then consume those events to apply specific actions, such as restricting cash withdrawals or disallowing new transactions while still permitting credits. Audit logs should capture every transition, along with evidence of customer communication, so that you can explain your actions in an inspection or dispute.

The key is to separate purposes and lawful bases in your data model. KYC attributes such as PAN, address, and ID documents are generally processed under a legal-obligation basis, not consent, so withdrawal of marketing or other optional consents does not automatically require deletion of those attributes while the legal retention period is still running. However, the same attributes might previously have been used for consent-based purposes such as targeted marketing or sharing with certain partners. When a customer withdraws consent, systems should immediately mark those consent-based purposes as inactive and ensure that marketing platforms, partner APIs, and analytical datasets stop using the data for those purposes. The records themselves can move into a “legal-retention-only” or “restricted processing” state, where they are retained and used solely for regulatory and operational necessities until their retention period expires, at which point they can be deleted or anonymised. Implementations that explicitly store both “allowed purposes” and “legal-retention-only” flags for each dataset handle this nuance more reliably than those that simply flip a single consent bit.

Conflicts usually arise when channels maintain their own consent records instead of relying on a central ledger. The mitigation is architectural: designate a single consent service or platform as the source of truth, and require all channels and systems, including Account Aggregator integrations, to create, update, and query consent via that service. Each consent-granting interaction should result in a new versioned consent artefact, with a monotonic sequence or timestamp that allows you to determine which artefact is latest. If a customer changes consent in the mobile app after having given consent in a branch, the mobile interaction simply creates a new artefact that supersedes the older one; downstream systems poll or receive a webhook to update their local view. For AA specifically, treat AA consent artefacts as covering only the regulated financial-information flows between FIPs and FIUs, and map them explicitly into internal purposes. Any internal processing outside the scope of AA needs its own lawful basis in your consent ledger. Regular reconciliation jobs can compare per-customer consent states across CRM, marketing tools, and the central ledger to detect and correct inconsistencies.

Legacy paper and scanned KYC records are still personal data under the DPDP Act and RBI’s KYC Directions. From a systems perspective, the problem is that they are often invisible to automated retention and data-subject rights workflows. One pragmatic pattern is to index these records into a minimal digital registry: store identifiers such as customer ID, document type, document date, and storage location (physical or digital), along with purpose and expected retention end date. You do not need to OCR and load every attribute into operational systems if there is no business need, but you should at least know that the records exist and when they can be destroyed. When a customer requests access or erasure, or when retention deadlines approach, this registry allows manual or semi-automated actions against the underlying paper or scanned store. Over time, as customers complete digital re-KYC, you can migrate away from legacy artefacts by marking them for destruction once all legal and audit dependencies are satisfied.

Account Aggregator consents are designed for a specific purpose: controlled sharing of financial information between Financial Information Providers and Financial Information Users under RBI’s AA Directions. The consent artefact specifies which financial data types can be shared, between which parties, for what purpose, and for how long. While this artefact clearly has privacy implications and should be integrated into your internal consent and data-minimisation logic, it does not automatically serve as a blanket DPDP consent for all internal processing of that data. For example, using AA-fetched data to assess a loan application may be covered by the stated purpose, but using the same detailed data for unrelated marketing analytics might not be. A careful design treats AA consent as one input into your central consent ledger, maps each AA purpose into one or more internal purposes, and ensures that other uses either rely on a different lawful basis recognised by the DPDP Act or obtain separate, explicit consent. This prevents over-extension of AA consents and makes it easier to honour revocation or expiry events coming from the AA ecosystem.

Sources
  1. Digital Anumati – DPDP Act Compliant Consent Management - Digital Anumati
  2. Master Direction – Know Your Customer (KYC) Direction, 2016 (Updated as on August 14, 2025) - Reserve Bank of India
  3. Updation/ Periodic Updation of KYC – Revised Instructions (DOR.AML.REC.31/14.01.001/2025-26) - Reserve Bank of India
  4. DPDP Act 2023 – Digital Personal Data Protection Act 2023 (Ministry of Law and Justice) - Ministry of Law and Justice (India) / DPDP Act 2023 portal
  5. Principle (c): Data minimisation - Information Commissioner’s Office (ICO), UK
  6. Guidance on Anti-Money Laundering, Terrorist Financing Measures and Financial Inclusion - Financial Action Task Force (FATF) / OECD
  7. Event-driven KYC refresh: why periodic review fails operationally - Finextra

Related pages

Updated At May 17, 2026

What the DPDP Act Means for Indian Businesses in 2026

In 2026, India’s DPDP Act and 2025 Rules move from policy to enforcement. See how they reshape governance, data operations, vendors and risk—and what leadership teams must build now.

 Updated At May 18, 2026

What Counts as a Reasonable Security Safeguard under DPDP?

A strategic guide for Indian CXOs on how DPDP’s “reasonable security safeguards” duty translates into concrete controls, governance, vendor oversight, and audit-ready evidence.

 Updated At Apr 18, 2026

Purpose Limitation in Practice: How to Stop Teams from Reusing Data

A business-style piece for business buyers that explains purpose limitation in practice— how to stop teams from reusing data and turns policy requirements into

 Updated At Jun 2, 2026

Consent Fatigue: Why Good UX Matters for Compliance

For Indian procurement and compliance teams: how consent fatigue in web and mobile UX affects DPDP and global privacy compliance, and what to demand from vendors.

 Updated At May 31, 2026

Role-Based Access Meets Purpose-Based Access: Designing Internal Controls

A technical guide for Indian engineering leaders on combining role-based and purpose-based access to enforce DPDP-aligned consent, purpose limitation, and audit-ready logs across apps, data platforms, and third parties.

 Updated At Apr 18, 2026

Log Retention, Deletion, and Audit Trails: Building an Evidence Program

A business-style piece for technical evaluators that explains log retention, deletion, and audit trails— building an evidence program and turns policy

 Updated At May 16, 2026

RBI vs DPDP: Erasure When KYC Retention Still Applies

How Indian banks, NBFCs, and fintechs can honour DPDP erasure rights without breaching RBI KYC and PMLA retention rules, using a practical data-governance and architecture model.

 Updated At May 17, 2026

Fraud Detection vs Privacy: When Can You Rely on Legitimate Use?

For Indian BFSI leaders: how to decide when fraud detection and transaction monitoring can rely on DPDP Act legitimate uses and Section 17 exemptions, and when you still need consent—while satisfying RBI KYC/AML, auditors, and customers.