IndiaLaw by assureOffice
Card-Data Sharing

Card-Data Sharing: RBI Purpose-Specific Consent, Outsourcing Necessity and Customer-Information Controls

Map each card-data disclosure to its recipient and purpose, check explicit consent and outsourcing necessity, and retain evidence beyond a generic vendor agreement.

Reviewed by CA BB Gupta · Chartered Accountant & Company Secretary | 45+ years in corporate matters

Indian small business owner manages store records

A vendor relationship is not blanket permission to share

Paragraph 86 of RBI’s Commercial Banks card Directions restricts disclosure of customer information obtained at account opening or card issue without explicit consent covering the purpose and recipient organisations. Paragraph 89 separately requires outsourcing-related card-data sharing to be essential to the assigned functions and requires explicit consent. This guide uses the Directions updated on 1 October 2026, checked on 26 October 2026. It concerns these controls, not a complete statement of every statutory disclosure duty or data-protection law. RBI Commercial Banks card Directions: paragraphs 3, 86 and 89; updated 1 October 2026.

Confirm the regulated population and information

Paragraph 3’s Commercial Banks definition excludes Small Finance Banks, Payment Banks and Local Area Banks. Identify the actual issuer, product, data fields, recipients and route before using this framework. Paragraph 86 addresses the stated customer information; paragraph 89 expressly includes transaction data within card data. Do not assume that calling an export operational or describing a recipient as an affiliate removes the need to analyse the actual disclosure.

Consent must identify purpose and organisations

Under paragraph 86, a consent record should connect the actual customer to the intended purposes and organisations receiving information. The issuer must clearly explain the meaning and implications of the disclosure clause where the customer consents. A broad checkbox whose retained wording cannot be retrieved is weak evidence. These are evidence controls applying the Directions; the examples do not prescribe a new mandatory screen layout or a universal expiry period for consent.

Test outsourcing necessity separately

Paragraph 89 limits sharing to data essential for the functions assigned to the outsourcing partner, alongside explicit consent. Begin with the actual outsourced function and justify the fields it needs. Remove surplus fields and prevent later reuse for an unrelated function without the applicable legal assessment. A consent record alone does not establish essentiality, and a vendor’s confidentiality contract does not itself prove customer consent. Storage and ownership must remain with the issuer under the stated paragraph.

Do not turn this into a substitute for other law

Paragraph 86 also requires compliance with the extant data-protection framework and addresses banking secrecy and data correctness. Evaluate an independently applicable legal disclosure requirement or permission on its actual basis; do not invent a blanket exemption here for every regulatory, marketing or recovery request. Co-branding has additional provisions and is not the outsourcing shortcut considered in this guide. Keep customer-information accuracy, access controls and incident handling connected to the real workflow.

Build a recipient-and-purpose disclosure register

For each data flow, retain the function, essential fields, recipient identity, customer-consent wording/version, explanation, approval and actual released file. Compare the intended and actual columns and population before release. The following quantities are fictional audit samples and data-volume calculations, not RBI tolerance limits. A low exception percentage is not permission to disclose the affected customers’ information.

Applicable primary references

RBI Commercial Banks card Directions: paragraphs 3, 86 and 89; updated 1 October 2026

Six worked illustrations

All facts and amounts below are fictional. Assumptions describe the model, not additional statutory rules.

Illustrative example 1: Match both consent dimensions

A sample has 120 customer records. Ninety have evidence covering both the intended purpose and recipient, twenty have purpose wording but no matching recipient evidence, and ten have no relevant consent record. Thirty records, or 25%, require resolution before relying on that consent basis.

Illustrative example 2: Remove surplus data fields

An export contains eighteen fields; the documented outsourced function needs seven. Eleven fields are surplus to the assumed necessity assessment. With 2,000 records, that is 22,000 unnecessary field values. Count alone is not the legal test; record why each retained field is essential.

Illustrative example 3: Do not add overlapping exceptions twice

There are 200 disclosures, fifteen with purpose-evidence exceptions and twelve with recipient-evidence exceptions; five appear in both groups. The unique exception count is twenty-two, or 11%. Adding fifteen and twelve would overstate the number of affected disclosures.

Illustrative example 4: Consent does not settle necessity

Out of eighty records with explicit consent for the intended flow, only sixty-five have a supported essential-function mapping; fifteen do not. Mapping coverage is 81.25%. Resolve the fifteen necessity gaps rather than treating the eighty consents as proof of both conditions.

Illustrative example 5: Recipient lists require reconciliation

The approved workflow names three recipient organisations, but access records show five organisations, including the approved three. Two additional recipients need a specific legal and consent assessment. A vendor group’s common brand does not itself prove that all five match the authorised recipient description.

Illustrative example 6: Control the actual released columns

An approved file contains eight essential columns for 500 customers, or 4,000 field values. The generated file contains ten columns for the same population, or 5,000 values. The 1,000-value difference represents two unexpected columns requiring correction before release on these facts.

Ten-step verification table

StepActionEvidence
1Confirm issuer scopeCovered Commercial Bank and applicable card product.
2Inventory the data flowActual fields, customers, route and intended recipients.
3Identify the legal basisApplicable paragraph and separately relevant legal duties.
4Define the precise purposeAssigned function and permitted intended use.
5Check recipient identityLegal organisations rather than only vendor branding.
6Retrieve explicit-consent evidenceCustomer, wording/version, purpose and recipients.
7Verify the explanation recordMeaning and implications communicated to the customer.
8Assess outsourcing essentialityField-by-field need for assigned functions.
9Compare approved and actual releaseColumns, population, recipients and access evidence.
10Close exceptions and retain accountabilityCorrectness, issuer ownership/storage and unresolved flows.

Sixteen practitioner FAQs

1. Does a vendor contract itself prove customer consent?

No. Retain the actual customer-consent evidence.

2. Which version of RBI’s Directions is used?

The Commercial Banks card Directions updated as on 1 October 2026.

3. Does the stated Commercial Banks definition include every bank category?

No. Paragraph 3 expressly excludes the specified SFB, Payment Bank and Local Area Bank categories.

4. What two dimensions does paragraph 86 identify for consent?

The purpose of use and the organisations with which information will be shared.

5. Must the implications of the disclosure clause be explained?

Paragraph 86 requires a clear explanation of the full meaning and implications.

6. Can the issuer rely on an untraceable generic checkbox?

An inaccessible wording/version leaves a material evidence gap.

7. Does an affiliate label eliminate the disclosure analysis?

No. Identify the actual recipient and flow.

8. Does paragraph 89 cover transaction data?

Yes, it expressly includes transaction data within card data.

9. What outsourcing necessity test does it impose?

Sharing must be essential to the functions assigned to that partner.

10. Does explicit consent alone prove essentiality?

No. Document the assigned-function and field mapping separately.

11. Who retains storage and ownership under paragraph 89?

The card-issuer, under the paragraph’s stated requirement.

12. Does this article settle every legally compelled disclosure?

No. Assess an actual separate legal requirement on its own terms.

13. Can audit sample percentages become permitted breach limits?

No. The figures measure review exceptions, not regulatory tolerances.

14. Why deduplicate exception populations?

One disclosure can fail both purpose and recipient checks without becoming two separate disclosures.

15. Does a co-branding arrangement automatically follow this outsourcing analysis alone?

No. Additional co-branding provisions require separate examination.

16. What is the key pre-release control?

Match actual customers, fields and recipients to the supported purpose, applicable basis, explicit consent and essentiality evidence.

Conclusion

Map each card-data disclosure to its recipient and purpose, check explicit consent and outsourcing necessity, and retain evidence beyond a generic vendor agreement.

Sources and primary references