The fraud alert call is the fastest and most effective customer communication in financial crime response. Every minute between flag and confirmation is a window in which further fraudulent transactions can occur. An AI that calls within 60 seconds, gets a binary yes or no, and acts on that answer immediately is structurally faster than any human-staffed fraud operations centre — particularly during overnight hours, weekends and public holidays when fraud analysts are at minimum staffing.

Beyond the confirmation call itself, the agent handles the full downstream workflow: card or account block if fraud confirmed, dispute case creation with structured data, warm transfer to the fraud team with case context pre-loaded, and a multi-channel alert (SMS + WhatsApp) confirming the action taken. For false positives — the customer confirms they made the transaction — the call ends in under 60 seconds with no friction, no case created, and the customer's confidence in their bank's fraud protection reinforced.

Speed is the defining metric of fraud alert effectiveness. UPI fraud is irreversible within minutes of a payment settling. Card-not-present fraud can run up multiple transactions in the time it takes a human fraud analyst to pick up a case from a queue. The AI's sub-60-second response is made possible by direct integration with your fraud detection system via webhook — the moment a transaction is flagged, the webhook fires to Kallix, and the AI initiates the call in the same breath.

For banks that currently rely on SMS alerts or batch-processed outbound calls, the shift to AI-initiated calls within 60 seconds represents a fundamental change in fraud response capability. Production data across our banking customers shows that the average interval between fraud flag and first customer contact dropped from 23 minutes (human team) to 47 seconds (AI) after deployment — a 29x improvement in response speed.

The confirmation call script is deliberately short, specific and non-alarming. Customers who receive vague 'suspicious activity' calls without specifics either dismiss them as spam or panic unnecessarily. By leading with the exact amount, merchant and timestamp, the agent gives the customer everything they need to make an immediate, confident yes or no decision — in most cases within 15–20 seconds of the question being asked.

The call structure is: greeting with bank name (5 seconds), transaction details read back clearly (10 seconds), authorisation question (5 seconds), customer response (5–15 seconds), action branch — either close gracefully for a yes or begin the block/dispute flow for a no. A clean 'yes, I made that' call is complete in under 45 seconds. The brevity of a legitimate false-positive call is one of the key design choices that keeps customer friction low and call acceptance rates high.

Triggers are organised into three tiers by your fraud operations team during onboarding. Tier 1 (mandatory call): high-confidence fraud signals — international transaction on a card with no travel notification, transaction at a known high-risk merchant, or ML model score above 90%. Tier 2 (call if above threshold): medium-confidence signals — transaction amount significantly above the customer's usual spend, new device login followed by high-value transfer. Tier 3 (SMS or WhatsApp only): low-confidence signals — mildly unusual but not alarming, such as a new merchant category.

Trigger calibration is one of the most important ongoing activities after deployment. Triggers that are too sensitive generate excessive false positives and erode customer trust. Triggers that are too conservative miss genuine fraud. We review trigger hit rates, false positive rates and fraud escape rates weekly during the first 3 months and quarterly thereafter.

False positives are managed at two levels. At the trigger level, threshold calibration during onboarding uses your historical data to find the score and rule settings that achieve your target false-positive rate — typically expressed as a ratio of false alerts to genuine fraud alerts (a 10:1 ratio means 10 false positives for every genuine fraud alert caught). We target the ratio agreed with your fraud team, not a universal benchmark, because the right ratio depends on your customer segment and fraud profile.

At the call experience level, the brevity and specificity of the confirmation call minimises friction for legitimate customers. A false-positive call that asks 'Did you make a ₹2,300 purchase at Swiggy at 7:15pm?' and closes on 'Yes, I did' in 30 seconds is experienced very differently from a lengthy automated call that asks multiple questions before reaching the point. Our call design philosophy is: make the false-positive call so brief and specific that even frequent false-positive recipients don't find it annoying.

The fraud-confirmed flow is engineered for speed and completeness. Once the customer says no to the authorisation question, the agent does three things simultaneously (via API): initiates the card block, creates the CRM case, and queues the warm transfer. By the time the agent tells the customer what it is doing ('I am blocking your card now and opening a fraud case'), the block API call has already been submitted.

The agent then asks one follow-up question before transferring: 'Are there any other transactions in the past 24 hours that you did not authorise?' This captures additional fraud scope that your fraud team may not have flagged yet, and the customer's answer is added to the case before the transfer connects. The fraud team receives: caller name, account last 4, authenticated status, specific transactions confirmed fraudulent, any additional transactions flagged by the customer, block confirmation, and a 3-sentence case summary.

The block during the call is synchronous: the API call returns a success or failure confirmation before the agent tells the customer their card is blocked. This prevents the worst outcome — telling a customer their card is blocked when the block failed. If the CMS API returns an error, the agent immediately tells the customer the block could not be applied and provides the bank's emergency card block number, then creates a high-priority incident in your operations system.

Block scope is configured during onboarding and can range from a temporary hold (card declined for new transactions, reversible) to a permanent cancellation with replacement initiation, to a full account freeze for suspected account takeover. The agent applies the configured default for the trigger type — card-not-present fraud typically warrants a card block, account takeover indicators warrant a full account freeze — and can take alternative action based on the customer's specific instructions during the call.

Account takeover (ATO) is a distinct threat from transaction fraud: the attacker gains access to the account and changes credentials before making transactions, which means the subsequent transactions may not look anomalous to standard fraud rules. Catching ATO requires monitoring the change events themselves — mobile number updates, password resets, new device registrations, beneficiary additions — and calling the genuine account holder before transactions begin.

The ATO detection trigger is configured to fire on a combination of signals rather than a single event, to avoid false positives on routine profile updates. A common rule: mobile number change + first transaction within 30 minutes on the new device triggers an immediate call to the old registered number. If that number is no longer active (a sign that the attacker may have already changed it), the agent falls back to calling via email OTP or escalating directly to the fraud team for manual investigation.

The webhook integration is the preferred pattern for real-time fraud response because it eliminates polling latency. When your fraud detection system flags a transaction, it sends a structured payload to the Kallix webhook endpoint: transaction ID, amount, merchant, card last 4, customer mobile, and the fraud score or rule that triggered the flag. Kallix uses this payload to personalise the alert call ('a ₹8,400 transaction at Amazon.in') and makes the outbound call immediately.

The return write is equally important for fraud model improvement. After each alert call, Kallix writes the outcome back to your fraud system: customer confirmed fraud (true positive), customer denied fraud (false positive), or customer did not answer (inconclusive). This feedback loop allows your ML model to learn from the confirmation outcome — a confirmed false positive provides a negative training signal for the triggering rule, improving model precision over time.

UPI fraud has a structural urgency that card fraud does not: once a UPI payment settles, the funds are in the beneficiary's account and the chargeback process requires NPCI dispute resolution, which can take 5–30 business days with no guarantee of recovery. Pre-debit confirmation — calling the customer before the payment settles — is the most effective intervention, and it is possible for UPI transactions above a configured amount where the settlement window allows.

For post-debit UPI fraud alerts (where the transaction has already settled), the AI captures the complete UTR, transaction amount, beneficiary UPI ID and VPA, and creates a structured case for your payments team to file with NPCI. The case includes the exact timestamp of the customer's fraud report, which is the reference point for NPCI's dispute resolution SLA. The agent also advises the customer on the NPCI customer dispute portal as a parallel escalation path.

Social engineering via vishing — fake bank or RBI officer calls — is the fastest-growing fraud category in India, accounting for a significant share of all reported digital fraud losses. The challenge is that the fraud alert AI may call a customer who is simultaneously on a vishing call believing they are speaking with the bank. The AI is configured to identify this scenario: if the customer hesitates to answer the authorisation question and mentions they are 'already talking to someone from the bank', the AI immediately identifies itself clearly, states the safety message, and asks whether the other caller asked for OTP or card details.

For customers who have already shared OTPs or credentials with a vishing caller, the agent treats this as an active account compromise: account freeze is initiated immediately (not just a card block), the case is flagged as a social engineering incident for your fraud intelligence team, and a referral is made to your bank's cyber fraud reporting channel and the national cyber crime portal (cybercrime.gov.in) for the customer's benefit.

Transaction bombardment — multiple fraud alerts firing in rapid succession — is a real risk in high-velocity fraud scenarios like card cloning, where the attacker runs multiple small transactions before a larger one. Making a separate call for each transaction would be both technically inefficient and extremely frustrating for a customer who may be getting 3–5 calls in the span of 2 minutes.

The consolidation window is configurable: your fraud team decides the maximum interval between transactions that qualifies them for grouping. Transactions outside the window (for example, one transaction at 2pm and another at 9pm) generate separate calls because the fraud patterns may be distinct incidents. Within the consolidated call, the agent asks about each transaction in sequence, captures the confirmation for each separately, and creates one combined case if multiple transactions are confirmed fraudulent — or separate cases if the fraud scope varies.

Non-response is treated as an unresolved risk, not a resolved one. The escalation cascade is: attempt 1 (immediate), attempt 2 (3 minutes later), attempt 3 (7 minutes later), then WhatsApp with transaction details and a one-tap reply option, then SMS with the same content. The retry interval and attempt count are configurable by transaction risk level — a 95% fraud score transaction with a potential ₹50,000 loss has a more aggressive retry pattern than a borderline 70% score on a ₹2,000 transaction.

The precautionary hold after no response is a temporary block on new transactions above a configured amount, not a full account freeze. It allows the customer's existing standing instructions and low-value transactions to continue while preventing a potentially fraudulent high-value transaction from clearing. When the customer does call back — or the fraud team reaches them — the hold is reviewed and either confirmed as a block or lifted.

RBI's Digital Payment Security Controls direction specifies that banks must implement real-time fraud monitoring and customer notification for transactions above risk thresholds. It does not prescribe the channel — SMS, call, or app notification — but specifies that notification must occur and the bank must maintain a record of when it occurred. An AI-initiated voice call with a timestamped confirmation record and an SMS confirmation to the customer satisfies both the notification requirement and the audit trail requirement more robustly than an SMS alone.

For customer liability, RBI's 2017 circular establishes that zero liability applies when the fraud is not attributable to the customer's negligence and is reported promptly. The AI's call — with millisecond-precision timestamp logged in your fraud system — creates an unambiguous record of when the bank notified the customer and when the customer's fraud report was received. This is the evidentiary record that protects both the customer's zero-liability claim and the bank's compliance position in a dispute.

Vishing fraud education during a live call is more effective than generic awareness messaging because it reaches the customer at the precise moment they are at risk. A customer who is currently on a vishing call needs to hear the safety message now, not in a future awareness campaign. The AI is configured to recognise the trigger phrases associated with active vishing: 'they said my account will be blocked', 'the officer asked me to share my OTP', 'they said it is a KYC update'.

The safety message is scripted, approved by your compliance team, and delivered calmly and clearly — not in a way that panics the customer. After delivering the message, the agent asks one clarifying question: 'Have you shared any OTP, card number or account password with anyone on the phone today?' If yes, the response escalates to account freeze rather than card block, because credential sharing indicates potential account takeover, not just a single fraudulent transaction.

Overnight and holiday fraud is disproportionately damaging for two reasons: the customer doesn't discover the fraud until the morning, allowing more transactions to accumulate, and human fraud teams are at minimum staffing, meaning the response chain is slower. AI eliminates both problems — it detects, calls and acts regardless of the hour, and its response speed does not degrade at night.

For low-risk alerts where the urgency is lower — a slightly unusual transaction that may well be legitimate — customers can configure a 'do not disturb' window, typically 10pm to 7am, where the alert is delivered via WhatsApp or SMS instead of a voice call. The customer sees the message when they wake up and can confirm or report at their convenience. High-risk alerts (ML score above 90%, high transaction value, account takeover indicators) always trigger an immediate voice call regardless of the DND window.

Elderly customers face a dual vulnerability in the fraud alert context. They are disproportionately targeted by vishing scammers, which means they may receive a fake fraud alert call from a criminal and then receive a genuine one from the AI in close succession — creating dangerous confusion about which call is legitimate. They are also more likely to say 'no I didn't make that' out of caution or confusion, when they actually did make the transaction.

The AI handles this with a specific elderly-customer protocol: if the customer segment is flagged as senior (configured per customer record or detected from voice patterns), the agent confirms each step explicitly, uses a confirmation prompt before blocking ('Before I proceed, I want to confirm — you are saying you did not make this ₹4,200 transaction at Big Bazaar today?'), and transfers to a human agent if the caller's confirmation sounds uncertain. Acting on an ambiguous 'no' and blocking a legitimate customer's card is worse than taking an extra 2 minutes to confirm with a human.

Multi-channel alert strategy is configured at the trigger tier level. High-risk alerts (account takeover indicators, large-value CNP fraud, transactions in foreign countries) always lead with a voice call because voice demands immediate attention and enables the binary confirmation flow. Medium-risk alerts use WhatsApp as the primary channel with a structured reply button — 'Yes I made this' or 'No, report fraud' — which feeds the same confirmation logic as the voice call.

WhatsApp fraud alerts include the complete transaction details (amount, merchant, timestamp), the bank's verified brand name and checkmark, and two action buttons. If the customer taps 'Report fraud', the AI initiates a follow-up voice call within 60 seconds to complete the fraud case creation and card block — the WhatsApp tap is not sufficient on its own to trigger a block, because it requires active confirmation rather than a passive non-response.

Fraud alert analytics serve three distinct purposes. For your fraud operations team, the key metrics are true positive rate and false positive rate per trigger rule — these determine whether your fraud model is catching fraud effectively without over-alerting legitimate customers. For your technology and risk team, time-to-alert and time-to-block metrics quantify the speed of the fraud response chain. For senior management and RBI reporting, the aggregate fraud prevention statistics — transactions flagged, confirmed fraud, average loss per confirmed fraud case, and cases where block prevented further loss — provide the evidence base for compliance reporting.

The most operationally valuable output is the false positive analysis by rule: which specific trigger rules are generating the most false alerts, and for which customer segments. This drives the weekly trigger calibration discussion with your fraud analytics team. Within 90 days of deployment, most banks have identified 2–3 trigger rules that accounted for a disproportionate share of false positives and recalibrated them, improving the true positive rate while reducing customer friction.

The one-call dispute initiation is one of the most operationally valuable features of the AI fraud alert system. In a human-handled fraud alert, the fraud analyst typically creates a preliminary case during the call, but the disputes team must call the customer back to collect the detailed transaction information needed for the formal chargeback filing. This callback loop adds 24–48 hours to the dispute initiation timeline and creates significant customer friction — they have to relive the fraud experience on a second call.

The AI collects all necessary dispute data during the alert call: each disputed transaction's date, amount, merchant name and dispute reason classification (Visa/Mastercard/NPCI dispute reason codes are mapped to simple customer-facing descriptions). The structured case data is formatted for direct submission by your disputes team to the card network — no reformatting required. For UPI disputes, the UTR and beneficiary VPA are captured and the case is formatted for NPCI dispute portal submission.

Language appropriateness is especially important in fraud alert calls because the call arrives unexpectedly and must immediately establish legitimacy. A fraud alert delivered in heavily accented English to a Hindi-speaking customer in tier-2 India is more likely to be dismissed as spam or generate confusion than to produce a quick, accurate confirmation. Our Hindi and Hinglish fraud alert scripts are written by native speakers with banking experience, not translated from English templates.

Tone calibration is distinct from language: the alert call's tone is calm, factual and authoritative — not alarmist. Callers who are panicked by the call's tone make less accurate confirmations and are more susceptible to follow-on social engineering. The script says 'We noticed a transaction that we want to verify with you' rather than 'Your account may have been compromised'. The specificity of the transaction details does the work of establishing urgency without inflammatory language.

The authentication design for outbound fraud calls reflects the asymmetry of the interaction: the bank is calling the customer, not the other way around. The standard inbound authentication model — multiple factors to prove the caller is who they say they are — is reversed: the customer needs to verify that the calling bank is legitimate, and the bank needs a light-touch confirmation of the customer's identity before acting.

The agent proves bank legitimacy by stating specific, non-public transaction details that only the bank could know. The customer is not asked to share sensitive credentials — the call should be short enough and specific enough that it resembles a trusted contact confirming a detail rather than a verification interrogation. If the customer volunteers suspicion that the call may itself be a fraud attempt ('How do I know you are really the bank?'), the agent immediately provides the bank's official callback number and invites the customer to hang up and call it back before confirming anything.

Escalation logic for fraud alert calls is risk-tiered rather than binary. Routine confirmed fraud — card-not-present transaction the customer did not authorise, standard amount — is handled end-to-end by the AI: block, case creation, reference number, call end. High-complexity fraud — social engineering in progress, multiple simultaneous compromised transactions, suspected account takeover — is escalated to a human with the AI-created case already loaded on the agent's screen.

Warm transfer quality is critical in fraud escalation because a customer who has just discovered fraud is already stressed. The human fraud agent receives: caller name and account, specific transactions confirmed fraudulent, block status (applied or pending), any credentials shared (for social engineering cases), the AI's case reference and a 3-sentence summary. The customer should never need to repeat the fraud details to the human agent.

The integration with ML models goes beyond simply receiving a fraud flag. The fraud score and the model's top-contributing features — 'unusual geography', 'new device', 'spending velocity spike' — are passed to Kallix along with the flag. The AI uses this context to tailor the confirmation call: for a 'new device login + high-value transfer' trigger, the agent specifically asks about both events ('We noticed you logged in from a new device this morning and made a ₹45,000 transfer — can you confirm both of these?') rather than asking only about the transaction.

The feedback loop from confirmation outcomes to model retraining is one of the most valuable long-term capabilities of the integration. A fraud detection model that learns from confirmed true positives and false positives improves its precision over time. The AI's structured confirmation outcome — confirmed fraud, confirmed legitimate, no response — is a high-quality label that is more reliable than rule-based post-hoc labelling, because it captures the customer's own statement about each transaction.

For CNP fraud, the agent asks one additional clarifying question after the customer denies authorisation: 'Do you have an account with [merchant name]?' This helps distinguish between 'I made this purchase and forgot' (the customer does have an account with the merchant), 'I made this purchase from a different device' (requires no action other than confirmation), and 'I have never used this merchant' (strongest indicator of fraud). The answer informs the fraud case classification and the chargeback reason code.

For EMI-based e-commerce fraud — where a fraudster uses stolen card details to take a loan-linked instalment purchase — the AI captures the merchant name, EMI tenure and first instalment amount for the dispute case. These cases are more complex for the disputes team because they may involve both a card network chargeback and a coordinated reversal with the e-commerce lending platform. The AI's structured capture ensures all relevant information is in the case before the disputes team picks it up.

Customer-level whitelist management is one of the most important usability features of the fraud alert system. A customer who frequently travels internationally and keeps getting fraud alerts for foreign transactions is a false-positive factory: every alert is legitimate travel, but the rules cannot distinguish it from genuine foreign fraud. After 3 confirmed false positives on international transactions, the analytics dashboard flags this customer for your fraud team to review and whitelist for the specific geography.

The self-service whitelist flag during the call is a lightweight mechanism: when the customer says 'Yes I made this — I always shop at this merchant', the agent notes this as a whitelist signal without acting on it immediately. The whitelist decision is made by your fraud team after reviewing the pattern, not by the AI unilaterally. This preserves human oversight while capturing the data needed to make intelligent whitelist decisions.

DPDP 2023's purpose limitation principle is central to fraud alert data handling: data accessed for a fraud alert — the specific transaction details and the customer's confirmation — can only be used for fraud prevention and dispute resolution purposes. It cannot be repurposed for marketing, cross-selling or customer analytics. We enforce this at the architecture level: fraud alert call recordings and case data are stored in a separate data partition from general customer service data, with access controls that prevent cross-purpose access.

For fraud data specifically, DPDP 2023 intersects with RBI's fraud reporting requirements: transaction fraud data must be reported to RBI in the format specified in the Master Direction on Fraud, with specific fields and timelines. The AI's structured case creation ensures that the data captured during the alert call is in the format required for RBI fraud reporting, reducing manual reformatting by your fraud compliance team.

The cost advantage of AI for fraud alerts compounds across two dimensions. Direct cost: per-call economics are 5–10x better than human fraud analysts, and the 24/7 coverage requires no additional staffing cost for overnight or holiday shifts. Indirect cost: the speed improvement — 47 seconds vs 23 minutes average response time — directly reduces fraud losses by shortening the window in which a compromised card can be used. Every ₹50,000 fraud loss prevented by a faster block adds to the return calculation.

For NBFCs and smaller banks with limited fraud operations headcount, the economic case is even stronger: a team of 3–5 fraud analysts cannot provide true 24/7 real-time alert response. AI provides institutional-grade fraud response at a cost point that is viable for banks with 50,000 customers, not just the large private sector banks with dedicated fraud operations centres.

Pre-authorisation fraud confirmation is the strongest fraud prevention mechanism available, because it stops the transaction before it settles — eliminating the need for a chargeback entirely. It works for card transactions where the authorisation request creates a brief hold (typically a few seconds) and for UPI transactions where the payment request is pending confirmation. The AI must complete the confirmation within the authorisation timeout window, which requires the call to be initiated immediately and the customer to respond within 30–45 seconds.

Pre-authorisation confirmation is configured for specific risk profiles rather than all transactions, because calling a customer to confirm every purchase would be unacceptably disruptive. Typical trigger configuration: first-ever international transaction, first purchase above ₹25,000 on a new merchant, or any transaction triggering a 95%+ fraud score from your ML model. For these specific cases, the 30-second friction of a confirmation call is justified by the fraud risk and the customer expectation that their bank would flag an unusual transaction.

The fundamental limitation of passive alerts is that they require the customer to take action: read the SMS, decide it is legitimate, navigate to the app, tap 'Report fraud', and hope the response reaches the fraud team in time. Every step in that chain is a drop-off point. Many SMS fraud alerts are dismissed as spam, read hours after delivery, or acted on after additional transactions have already occurred.

A voice call cuts through every friction point: it rings the customer's phone, speaks the specific transaction details, and asks one question that can be answered in three words. The response is captured in real time, acted on immediately, and logged with a timestamp. For the customer, a confirmation call that closes in 45 seconds when they made the transaction is less disruptive than discovering a fraudulent charge on their statement three days later. For the bank, the confirmation call creates an evidence record that no passive alert channel can match.