The lost card call is one of the most time-critical interactions in retail banking. Every minute between the theft and the block is a window in which the card can be used fraudulently. An AI agent that answers within 2 rings, 24/7, and completes the block in under 90 seconds from authentication removes that window regardless of when the loss is discovered.

Beyond the block itself, the agent handles the full downstream workflow: replacement card request with delivery preference captured, virtual card issuance if your card management system supports it, an SMS summary of linked UPI mandates and standing instructions that will be affected, and a dispute case reference number for any unauthorised transactions — all before the caller hangs up. Human agents handling the same call average 8–15 minutes including hold time.

Speed is the primary safety metric for card blocking. RBI's zero-liability framework uses the time of the customer's block report as the reference point for determining financial liability for unauthorised transactions — the faster the block is confirmed, the clearer the liability boundary. An AI that answers within 2 rings and completes the block in under 2 minutes is structurally faster than any human call centre that requires navigating an IVR, waiting on hold, and re-explaining the situation to an agent.

For comparison: in most Indian bank contact centres during peak hours, the average wait time before reaching a card blocking agent is 6–12 minutes. After connecting, human authentication and block processing adds 4–6 minutes. The AI eliminates both delays, reducing the window for fraudulent transactions to minutes rather than hours.

Standard banking authentication relies partly on physical possession of the card — its number, CVV, or PIN. A lost card call breaks that assumption entirely. The authentication flow we configure for card blocking uses knowledge factors and possession of the registered mobile only: OTP on registered mobile (proving the caller controls the registered number), date of birth (a knowledge factor), and one additional factor from a list your bank configures — Aadhaar last 4, PAN last 4, mother's maiden name, or last transaction amount.

For callers who have also lost their registered mobile along with the card — a common scenario in a bag theft — the AI flags the call as a 'dual-loss event' and immediately escalates to a human security agent with a priority flag. The AI does not attempt to authenticate without the registered mobile OTP in this scenario, as doing so would create a social engineering vulnerability.

Fraud data consistently shows that stolen cards are used most aggressively in the first 2–4 hours after theft, often late at night or in locations far from the victim's home city. Human contact centre staffing patterns are the inverse of this risk profile: skeleton night shifts, long queues during peak fraud periods like festival seasons, and full capability only during business hours. The AI maintains the same response capability at 2am on a public holiday as at 2pm on a Tuesday.

For banks with existing 24/7 human card blocking operations, the AI doesn't replace the overnight team — it handles the volume of routine block requests so human agents can focus on complex cases, dual-loss events, and high-value account escalations. Banks without 24/7 human coverage use the AI to provide genuine around-the-clock service without the cost of a full overnight shift.

Card type identification is handled by the agent, not the caller. After authentication, the agent retrieves all active cards linked to the account from your CMS and reads back a masked list — for example, 'I can see a Visa debit card ending 4821 and a RuPay credit card ending 7934. Which one are you reporting?' This prevents errors from callers who don't know their card network and ensures the right card is blocked.

For RuPay cards — the dominant debit card network for Jan Dhan accounts and government scheme beneficiaries — we support NPCI's card management API for blocking and replacement initiation. This is particularly important for public sector banks and NBFCs with large rural customer bases where RuPay penetration is highest.

The distinction between temporary block and permanent cancellation is important because many 'lost card' calls turn out to be misplaced cards. If the card is permanently cancelled and the caller finds it an hour later, they must wait for a replacement card — creating unnecessary friction and cost. The AI defaults to the reversible option and asks a single clarifying question: 'Do you believe this card has been stolen, or might you have misplaced it?' The answer determines whether a temporary block or permanent cancel is the appropriate action.

For stolen card reports where fraud is suspected, the agent always recommends permanent cancellation and a new card number — a temporary block does not help if the card number has been compromised. The agent explains this distinction in plain language: 'Since you believe it was stolen, I recommend permanently cancelling and issuing a new card, as the old card number could still be used for online transactions even if the physical card is blocked.'

International lost card scenarios have two complications: the caller may not be able to receive an Indian mobile SMS for OTP, and they may need emergency cash or a replacement card in a foreign country. The AI handles the first by offering an alternative verification factor — Aadhaar last 4 or date of birth — if the caller confirms they cannot receive the OTP on their Indian number. This must be configured as an allowable fallback in your policy for international callers.

For emergency cash and emergency card replacement abroad, the agent captures the country, city and preferred contact method and creates a high-priority referral case for your bank's international assistance team or VISA/Mastercard emergency services. It provides the caller with the relevant network's international emergency assistance number — Visa Global Customer Assistance Services or Mastercard Global Service — so they have an immediate escalation path while the bank's team responds.

The dispute capture flow runs immediately after the block confirmation, while the caller is still on the line. The agent asks: 'Before I let you go, are you aware of any transactions on this card that you did not make?' If the caller says yes, it collects details for each transaction systematically — date, approximate amount, merchant name or transaction description — and creates a structured fraud case in your CRM without requiring a second call to the disputes team.

RBI's 2017 circular on limiting customer liability establishes that zero liability applies when the fraud is reported within 3 working days of the bank notifying the customer, and limited liability (capped at ₹5,000–₹25,000 depending on account type) applies in other scenarios. The precise timestamp logged by the AI becomes the formal evidence of when the report was made — making accurate, immediate logging a direct financial protection tool for the customer.

Replacement card initiation is a single API call to your card management system after the block is confirmed. The agent reads back the registered mailing address, asks the caller to confirm it or provide an alternate address, presents the delivery options available (standard or express, with timelines), and submits the replacement request — all within 45–60 seconds of the block being applied.

For cases where the customer needs immediate purchasing capability — they are traveling or have an urgent online payment — the agent asks whether a virtual card number would be helpful and, if the bank's CMS supports virtual card issuance via API, delivers the 16-digit virtual card number, expiry and CVV via a secure channel (encrypted WhatsApp message to the verified registered mobile or the bank's app push notification). This eliminates the days-long gap between block and replacement for customers with urgent need.

Virtual card issuance during the blocking call eliminates the most painful consequence of a lost card: the days-long gap between block and physical replacement during which the customer has no payment capability. For a customer who loses their card on a work trip, or whose card is the only payment method in their wallet, an immediately active virtual card is transformational — they can continue transacting online and via mobile wallets (Google Pay, PhonePe) within minutes of the report.

Security for virtual card delivery is critical. The virtual card number, expiry and CVV are never read aloud over the phone — they are delivered only through a secure, authenticated channel: an encrypted push notification to the bank's registered app on the customer's device, or an end-to-end encrypted WhatsApp message to the verified registered number. The delivery channel is agreed with your security team during onboarding and cannot be overridden during a call.

A blocked card creates silent failures downstream: UPI autopay mandates fail on execution, standing instructions for utility bills and insurance premiums bounce, and EMI debits decline — often triggering late payment fees and affecting credit scores without the customer realising the connection to the card block. Proactively surfacing this list during the blocking call is one of the highest-value actions the AI takes, because it gives the customer time to update payment methods before the next due date.

The agent does not automatically cancel any linked payments — it surfaces the list and advises. For UPI autopay mandates, it explains that the customer will need to update the payment source in the relevant app (PhonePe, GPay, BHIM) once the new card is activated. For standing instructions registered directly with the bank, it offers to create a service request for the customer's relationship manager to assist with the update.

Wallet theft — the most common physical card theft scenario — typically results in multiple cards being stolen at once. A customer whose wallet is stolen usually needs to block their debit card, credit card and any co-branded cards simultaneously. Requiring separate calls for each card creates both customer friction and risk: the unblocked cards remain active while the caller navigates multiple call flows.

The agent presents the masked card list — for example, 'I can see three cards: Visa debit ending 4821, HDFC credit card ending 7934, and a RuPay debit ending 2201. Would you like to block all three, or specific ones?' — and processes the blocks sequentially with a single CMS API call per card. The entire multi-card block takes under 60 seconds once authentication is complete.

RBI's circular on customer liability establishes that a customer bears zero liability for fraud if the breach is in the bank's system — and limited liability (₹5,000–₹25,000 depending on account type) if the breach is at the customer end but reported within 3 working days. The precise timestamp of the loss report — not the call connection time, but the moment the block is confirmed — determines liability calculation. The AI logs this timestamp in your CMS with millisecond precision and includes it in the SMS confirmation sent to the customer, creating an auditable record.

For DPDP 2023, the card blocking call processes sensitive personal and financial data under the 'legitimate use' basis in a banking context. Call recordings, authentication logs and case notes are stored on AWS ap-south-1 (India) by default, processed only for the purpose of executing the card block and any associated fraud case, and retained according to your bank's document retention policy.

Lost card calls are inherently stressful, and stressed callers frequently fail authentication steps they would pass under normal conditions — forgetting security answers, misremembering dates, or mistyping OTPs. The AI is configured to be patient: it reads the options clearly, gives the caller time to respond, and offers a different factor if the first attempt fails, rather than repeating the same failed factor.

The escalation path after 3 failed attempts is designed specifically to avoid creating a social engineering gap: the AI does not give any indication of which factor was close or which was far off, does not offer unlimited retries, and does not allow the block to proceed without successful authentication. It places the account on a temporary security watch and escalates to a human agent who can complete manual verification through your bank's in-branch or video-KYC process.

Delivery timelines are determined by your card issuance and logistics configuration, not by the AI — the agent reads the options your CMS exposes. Standard delivery uses India Post or Blue Dart depending on your bank's contract. Express delivery, where available, typically uses a tier-1 courier (Delhivery, DTDC, Blue Dart Express) and is available in the top 25–30 cities.

For customers with urgent need — traveling, living alone, or in a medical situation — the agent flags the case as urgent in the replacement request, which may unlock priority processing in your bank's card issuance workflow. If virtual card issuance is available, it is offered alongside the physical replacement so the customer has payment capability immediately without waiting for the courier.

Temporary block reversal is one of the most common follow-up actions after a lost card report. Many 'lost' cards turn out to be misplaced at home, at a friend's place, or left in a hotel room — and found within hours or days of the block. The ability to reverse a temporary block via an AI call, without visiting a branch or waiting for a human agent, is a significant convenience improvement for customers and reduces the cost of handling these follow-up calls.

Permanently cancelled cards — those where a new card number has already been issued — cannot be reversed. The AI explains this clearly: 'Your card was permanently cancelled and a replacement is already in transit. The old card number can no longer be activated. You can use the virtual card while waiting for your physical replacement.' This prevents caller frustration from unclear expectations about what reversal is possible.

The confirmation SMS serves three purposes. For the customer, it is immediate assurance that the block was successfully applied — critical in a stressful situation. For liability purposes, it creates a customer-held record of the block timestamp that matches the bank's CMS log — important if a dispute about liability timing arises later. For your compliance and operations teams, it is auditable evidence of timely communication as required by RBI's customer protection guidelines.

The confirmation message is templated and pre-approved during onboarding. It includes: bank name, card type and last 4 digits, block confirmation time in IST (hours, minutes, seconds), case reference number, and a statement that the card is now declined for all transactions. It does not include sensitive data. If the customer's registered mobile is different from the number they called from — common when reporting from a borrowed phone — the SMS still goes to the registered number on file, which is the number that matters for RBI liability purposes.

Third-party reporting is a nuanced compliance area: banks must balance the urgency of protecting the customer's account against the social engineering risk of an unauthorised person blocking a card. Our standard configuration requires the OTP to be received on the account holder's registered mobile — which means either the account holder is present to receive it, or the family member has access to that device. This is the minimum authentication bar for a card block on behalf of another person.

For situations where both the card and the registered phone are lost — the highest-risk scenario — the AI declines to proceed with AI authentication and escalates immediately to a human security agent with a priority flag. The human agent can invoke your bank's alternative identity verification process, which may include video KYC, Aadhaar e-KYC, or in-branch identity verification. The AI explains this clearly to the caller and provides the escalation path.

Corporate card programmes introduce an organisational layer that personal card blocking doesn't have: the card is a company asset, and the block decision may require authorisation from the card programme administrator, not just the individual cardholder. We configure the corporate card blocking flow during onboarding in collaboration with your corporate banking team: typically the cardholder completes personal authentication, the agent confirms the company card programme account, and a pre-registered administrator PIN or approval code is required before the block is executed.

For fleet card programmes — where cards are assigned to vehicles rather than individuals — the identification flow uses vehicle registration or fleet ID rather than personal details. The block and replacement request are routed to the fleet programme manager simultaneously with cardholder notification. Corporate and fleet card replacement timelines may differ from personal card timelines if your bank has a separate issuance process for corporate cards.

Card skimming is distinct from card loss: the physical card is still in the customer's possession, but the card data has been compromised and cloned. The AI recognises this scenario when a caller says they have their card but noticed unauthorised transactions — and routes to the 'card compromised' flow rather than 'card lost'. The immediate action is the same (block the card), but the fraud case is flagged differently: as a potential skimming incident requiring ATM investigation or merchant fraud reporting.

For ATM skimming specifically, the agent captures the ATM location (bank name, branch or area) and approximate date of the suspicious transaction, which helps your fraud team identify the compromised terminal and potentially protect other customers who used the same ATM. This information is logged in the fraud case and forwarded to your fraud intelligence team as a potential card skimming incident report.

Card-not-present (CNP) fraud — where the card number, expiry and CVV are stolen and used for online transactions without the physical card being taken — is the fastest-growing card fraud category. A customer who notices an unrecognised online transaction on their statement, or receives a transaction alert for a purchase they did not make, may still have their physical card. The AI explains that the card number itself has been compromised and must be replaced, even though the physical card is in hand.

The card-still-in-hand flow is identical to the standard block flow in terms of CMS actions: the current card number is blocked and a replacement is initiated. The difference is in the fraud case: it is flagged as CNP fraud, and the agent asks whether the card details may have been exposed through a phishing site, a data breach notification, or an unsecured online transaction — capturing the suspected channel of compromise for your fraud analytics team.

Escalation logic for card blocking calls is conservative by design: when in doubt, escalate. A human agent can take additional verification steps that the AI cannot — video KYC, asking the caller to describe a recent in-branch interaction, or routing to a branch for in-person verification. The AI never refuses to help a genuine customer because authentication failed; it always provides a human escalation path.

For violent theft reports — 'I was mugged' or 'someone grabbed my bag at knife point' — the agent's first response is to ask whether the caller is safe and whether they need emergency services, before proceeding to the card block. This is configured as a priority escalation flag: the card is blocked immediately using minimum-friction authentication, and the call is flagged for the fraud team as a robbery-related card loss, which may involve police FIR requirements in some banks' fraud protocols.

Card blocking analytics serve two distinct purposes. Operationally, they show how well the AI is performing: block speed, authentication success rate, containment versus escalation rate, and whether the replacement flow is completing without errors. These metrics drive weekly tuning and configuration improvements.

For fraud intelligence, the call data reveals patterns invisible to human agents handling individual calls: geographic clustering of block reports at specific ATMs (indicating a skimmer), time-of-day patterns in card theft reports, or a spike in CNP fraud reports following a merchant data breach. Aggregated and anonymised block report data can be fed into your fraud analytics platform via webhook to enrich fraud detection models in real time.

NRI customers using Indian debit or credit cards while travelling often face a dual problem: their card is lost abroad and they may not have an active Indian SIM to receive OTPs. We configure a specific NRI authentication path during onboarding: the agent identifies when a caller is dialling from an international number, asks whether they can receive an OTP on their registered Indian mobile, and — if not — falls through to Aadhaar or PAN-based verification with heightened secondary factor requirements.

For Visa cardholders, the agent provides the Visa Global Customer Assistance Services number for the country they are in — available in 150+ countries. For Mastercard holders, the equivalent Mastercard Global Service number is provided. These network-level services can issue emergency replacement cards in many countries within 24–48 hours, independent of the issuing bank's own processes. The AI captures the caller's current country and city to provide the correct local contact information.

Chargeback initiation requires structured data that your disputes team submits to the card network (Visa, Mastercard, RuPay). The AI collects that data systematically during the call: for each disputed transaction, it asks the date, approximate amount, merchant name or description, and the reason ('I didn't make this purchase' is a reason code 10.4 — card-not-present fraud; 'I made this purchase but was charged the wrong amount' is a different reason code). This structured capture means your disputes team receives a fully formed case, not a free-text summary.

RBI mandates that banks acknowledge dispute registration within a defined window and resolve it within 45–90 days depending on transaction type. The AI's case creation timestamps the dispute registration — the formal start of the RBI clock. The case reference number given to the customer is the tracking number they can use with your disputes team for follow-up.

A caller who fails all verification attempts is in one of two situations: they are a genuine customer under extreme stress who has temporarily forgotten their details, or they are an unauthorised person attempting social engineering. The AI's response must protect against the second without abandoning the first — which is why escalation to a human security agent is always the outcome, never disconnection.

The security hold is separate from a card block: it flags the account for elevated monitoring but does not immediately restrict transactions. The human security agent can then complete manual verification through your bank's identity verification protocols — video KYC, Aadhaar e-authentication, or a branch visit — and, once identity is confirmed, apply the card block retrospectively timed to the original call. This maintains the RBI liability protection timeline for the genuine customer.

Confirmation reliability is a first-order design requirement for card blocking. A caller who is told the card is blocked, but the block was not actually applied due to a system error, is in a far worse position than if they had been told the block failed and given an alternative path. Our integration with the CMS API uses synchronous confirmation: the block request returns a success or failure code in real time, and the agent acts on that code before confirming to the caller.

In the rare case of a CMS API failure — network timeout, system maintenance — the agent tells the caller immediately that the block could not be confirmed, advises them to contact the bank's emergency number or visit the nearest branch for an immediate block, and creates a high-priority incident ticket in your operations system. It does not tell the caller the block was successful if it was not.

Each alternative has a critical failure mode in the specific context of card loss. A branch visit requires knowing the branch is open, travelling there safely — potentially problematic if the card was stolen in a threatening situation — and waiting in a queue. For a card stolen at 11pm on a Sunday, the branch option may not be available for 10+ hours.

Net banking and mobile banking apps require credentials — username, password, and often a device PIN. Many customers don't memorise these, rely on saved credentials on their phone, or are locked out of their app after being in a different city. Voice is the most universally accessible channel: anyone with access to any phone, regardless of location or device, can call the helpline. The AI's 24/7 availability and sub-2-minute block speed make it structurally superior to both alternatives in the specific scenario of card loss or theft.

The time breakdown is: greeting and reason capture (15–20 seconds), authentication (60–90 seconds across two factors), card identification from account (10 seconds), block confirmation and verbal confirmation (30 seconds including API response), replacement preference and address confirmation (45 seconds), SMS confirmation triggered (10 seconds), and closing (10 seconds). Total for a clean call: approximately 3 minutes.

With dispute triage — capturing details of unauthorised transactions — add 60–90 seconds per transaction. A caller with three disputed transactions adds approximately 3–4 minutes. The AI handles this efficiently by asking for all transactions before creating cases for each, rather than creating a case after each transaction, which reduces redundant steps.

The cost calculation has two components: per-call cost and coverage cost. Per-call, AI is 5–8x cheaper than a human agent for a straightforward card blocking interaction. Coverage, however, is where the financial advantage compounds: a human contact centre that provides 24/7 card blocking requires a night shift team — typically 3–5 agents at ₹20,000–₹35,000 per month each — adding ₹60,000–₹1.75L per month just for overnight coverage. The AI's 24/7 capability is included at no additional cost.

For banks that currently provide card blocking only during business hours — and route after-hours callers to a voicemail or a limited IVR — the AI unlocks the revenue-protective value of immediate card blocking at all hours. A single prevented fraud incident of ₹50,000 (well within the range of a night's worth of card fraud on an unblocked stolen card) covers months of AI operating cost.