Banking, fintech and payments

Sector regulation

The correct RBI and payment overlay depends on legal entity, licence and activity. A bank, NBFC, payment aggregator, PPI issuer, Account Aggregator, lending service provider and unregulated technology vendor do not receive one generic profile.

Data and systems

Typical data includes KYC/AML identity, account and transaction, bureau and underwriting, income, device/fraud, location, communication, nominee, merchant, employee and grievance data. Systems include core banking, LOS/LMS, card/payment switch, CRM, KYC/AML, fraud, bureau, AA/FIU/FIP, collections, call centre, DLT messaging, data lake and outsourced cloud/SaaS.

The first implementation output is a flow by legal entity and activity:

flowchart LR
  C[Customer / merchant] --> CH[App, web, branch, partner]
  CH --> K[KYC / AML]
  CH --> L[LOS / LMS or core]
  L --> B[Credit bureau]
  L --> A[Account Aggregator ecosystem]
  L --> P[Payment and collections]
  L --> V[Outsourced IT / cloud]
  K --> D[Fraud and data platform]
  P --> D

Instrument stack

• DPDP Act/Rules, by commencement cohort;
• CERT-In Directions for applicable cyber incidents/logs;
• RBI IT Governance Directions for the entity classes listed in paragraph 2;
• RBI IT Outsourcing Directions for covered arrangements;
• activity-specific RBI payment data, digital lending, KYC/AML, customer service/ombudsman and cyber instruments after entity-specific research;
• TCCCPR for commercial communications.

Do not infer that every fintech is RBI-regulated. Capture licence/registration number, activity, regulated partner and contractual allocation.

Consent and non-consent

Separate:

• product/service and mandatory KYC processing, assessed against DPDP consent or an exact section 7 use and other legal duties;
• optional bureau, AA, marketing, analytics or partner uses;
• Account Aggregator consent artefacts under their own RBI/DEPA framework;
• TCCCPR marketing consent/preferences.

Link artefacts; do not convert an AA consent into a general DPDP marketing receipt.

Retention and erasure

Configure per record class: KYC/AML, transaction, loan/collection, bureau, fraud, complaint, regulatory return, security log, call recording and marketing profile. On erasure/withdrawal, retain only the record required by the exact banking/AML/tax/evidence source, suppress prohibited reuse, show the Principal the scoped exception and propagate deletion to processors.

Incident and outsourcing

The incident case runs DPDP, CERT-In, RBI/payment-system and contract clocks separately. The outsourcing record captures materiality, due diligence, concentration, audit/regulator access, data location, subcontracting, continuity, exit and verified purge. A cloud deployment is not approved merely by selecting “India region.”

Minimum configuration

Configuration	Required detail
entity profile	RBI category/licence, products, branches, partners
purpose pack	onboarding/KYC, servicing, credit, fraud, collections, marketing
system map	core, LOS/LMS, payments, KYC, bureau, AA, CRM, lake
retention pack	source/provision per record class and trigger
processor pack	cloud, KYC, bureau gateway, contact centre, messaging
incident pack	authority tests, clocks, contacts, portal/manual fallback
rights path	subject matching across customer/merchant IDs without new excessive KYC

Integration workflow

Start with LOS/LMS plus CRM or core read-only adapters. A rights request produces scoped tasks; correction writes only after source-system approval; withdrawal posts idempotent suppression to CRM/messaging and stops optional downstream use; deletion remains task-based until a system supports verified APIs.

Audit evidence

Entity/applicability approval, purpose/notice versions, receipt, AA/TCCCPR linkage, processor contract mapping, system fulfilment results, retention exception, incident clocks/submission, access reviews and exit certificates.

Counsel questions

• Which exact RBI/payment/KYC circular version applies to each entity/activity?
• Which payment or transaction datasets have location restrictions?
• When is the fintech an independent Fiduciary versus the regulated entity’s Processor?
• Which disclosure/access rights are limited by fraud, AML, investigation or third-party data?
• What retention source and trigger govern every KYC, lending, payments and call record?