A wearable remains subject to card safeguards
RBI’s Commercial Banks Credit Cards and Debit Cards Directions, 2025, paragraphs 51–53, permit other form factors, including wearables, in place of or in addition to plastic cards after explicit customer consent. The respective card guidelines continue to apply, and disabling or blocking options must be provided. This guide uses the directions updated to 1 October 2026, checked on 27 October 2026. Its commercial-bank population excludes Small Finance Banks, Payment Banks and Local Area Banks. RBI Commercial Banks card directions: paragraphs 3, 51–53 and 67–70.
Trace consent to the actual form factor
Keep the customer, account, product, device or form-factor identifier, consent wording and event record linked. A pre-existing plastic card does not by itself evidence explicit consent to a newly issued wearable. Suggested control fields here are a working-paper design, not a prescribed RBI technical schema. Do not claim that any specific token, app or network implements these controls without evidence.
Inventory each usable instrument
Map the account to its plastic card and additional form factors. Prevent a device inventory from being mistaken for a customer count. Replacements and discontinued devices should remain traceable in history, while the active inventory identifies what can still be used. Check whether a displayed inactive status is supported by the actual processing state.
Test blocking scope without assuming system behaviour
Provide and test the required options. Record what the customer requested, what was blocked, when it took effect and what confirmation was sent. The interaction between one wearable, a plastic card and the overall account needs evidence from the issuer’s implementation and applicable procedures. Do not promise that one device can always be blocked independently or that blocking one necessarily blocks everything.
Preserve the distinction between blocking and closure
The card directions distinguish temporary blocking or deactivation from ending an account relationship. Review the applicable general loss-reporting, immediate blocking and confirmation requirements as well as paragraphs 51–53. This article does not calculate unauthorised-transaction liability or advertise a wearable-specific fee or transaction limit; those require their own verified terms and law.
Applicable primary references
RBI Commercial Banks card directions: paragraphs 3, 51–53 and 67–70
Six worked illustrations
All facts and amounts below are fictional. Assumptions describe the model, not additional statutory rules.
Illustrative example 1: Consent population
An issuer adds 120 wearable form factors. Evidence supports explicit consent for 112 and eight are unmatched. Evidence coverage is 93.33%, rounded to two decimals, and the eight gaps require investigation rather than assumed consent.
Illustrative example 2: Customers versus instruments
Eighty customers each hold a plastic card; 30 also hold one wearable. There are 80 customers and 110 instruments, not 110 customers. The additional form-factor population is 30.
Illustrative example 3: Inventory movement
Opening active wearables are 200. Forty are added and 15 are confirmed deactivated. Closing active inventory is 225. A system display of 230 leaves five instruments to reconcile.
Illustrative example 4: Replacement history
Ten wearables are replaced one-for-one. Ten new identifiers should link to ten old identifiers. If two old ones remain active, the physical replacement activity is ten but the active-instrument excess is two. Investigate the processing state before concluding remediation.
Illustrative example 5: Blocking elapsed time
A request is recorded at 14:10 and effective blocking at 14:14. Elapsed time is four minutes. This is a factual latency measure, not an RBI-approved grace period or a conclusion about customer liability.
Illustrative example 6: Test coverage
A control test covers six product/channel combinations with five successful blocking confirmations and one unresolved failure. Success coverage is 83.33%, rounded to two decimals. Retest the failed combination; do not average it away as an acceptable statutory tolerance.
Ten-step verification table
| Step | Action | Evidence |
|---|---|---|
| 1 | Confirm issuer scope | Applicable directions and version |
| 2 | Inventory form-factor products | Actual issuer product records |
| 3 | Map account and instruments | Customer and identifier reconciliation |
| 4 | Verify explicit consent | Wording, event and customer link |
| 5 | Match issuance to consent | Complete issuance population |
| 6 | Check active and replaced identifiers | Lifecycle and processing records |
| 7 | Inspect disable or block options | Customer-facing procedure and tests |
| 8 | Verify effective blocking and confirmation | Timestamp and response evidence |
| 9 | Investigate gaps and failures | Exception owner and resolution |
| 10 | Retest and retain the control pack | Verified outputs and current procedures |
Sixteen practitioner FAQs
1. Does a wearable escape the ordinary card rules?
No. Paragraph 52 keeps the respective card guidelines applicable.
2. Is explicit consent required?
Paragraph 51 requires it for the other form factor.
3. Does consent to a plastic card prove wearable consent?
Do not assume it; establish the actual form-factor consent.
4. Does the rule require a particular technology brand?
The cited provisions do not endorse a specific product or implementation.
5. Can wearables be issued in addition to plastic?
Paragraph 51 permits additional or replacement form factors subject to consent and applicable rules.
6. What options must be available?
Paragraph 53 requires disabling or blocking options in line with applicable RBI instructions.
7. Does blocking one wearable always block the whole account?
Verify the implementation and request scope; do not invent a universal result.
8. Does a blocked account necessarily mean closure?
The directions distinguish blocking or deactivation from closure.
9. Why retain old device identifiers?
They support replacement tracing and checks that obsolete instruments are no longer usable.
10. Is an inactive label enough evidence?
Test the actual processing effect and supporting logs.
11. Do sample percentages create tolerances?
No. They describe evidence and test coverage only.
12. Is four minutes an approved blocking window?
No; that example measures latency without creating a grace period.
13. Does this guide decide fraud-loss reimbursement?
No. Apply the relevant unauthorised-transaction framework separately.
14. Are wearable fees and limits standardised here?
No such product terms are asserted; verify actual terms and applicable rules.
15. What should a blocking test retain?
Request scope, identifiers, effective time, result and customer confirmation.
16. Which institutions need a different scope check?
Issuers outside the specified commercial-bank definition require their own applicable directions.
Conclusion
Reconcile wearable card issuance to explicit consent and test whether customers can disable or block the form factor under the applicable card framework.