High-value transaction authentication via AI differs fundamentally from passive SMS OTP authentication. An SMS OTP confirms that someone with access to the registered mobile can enter a code — it does not confirm that the account holder knowingly initiated the transaction, understands where the funds are going, or is free from coercion. An AI voice call adds three dimensions that SMS cannot: intent confirmation (is the customer aware of this specific transaction?), social engineering detection (is the customer being coached, pressured, or deceived?), and beneficiary validation (does the stated purpose match the beneficiary?).

The agent integrates with the bank's transaction processing system, fraud detection engine (FICO Falcon, SAS AML, ACI Proactive Risk Manager), and CBS to receive the transaction event trigger within 15–30 seconds of the transaction being submitted. The call is placed before transaction processing completes — during the authentication hold window — so the transaction can be approved or blocked based on the call outcome.

The authentication call has four structured segments: identity verification (OTP or voice biometric — 20–30 seconds), transaction confirmation ('Can you confirm you are transferring ₹[amount] to [beneficiary name] at [bank]?'), intent and context check ('Can I ask what this transfer is for?' — a single open question that surfaces social engineering patterns), and risk signals assessment (the agent's NLP evaluates the customer's response for urgency, third-party coaching, and confusion patterns).

For transactions that pass all four segments, the agent approves the transaction in real time. For transactions where any segment raises a concern, the agent places a 4–24 hour hold and escalates to the bank's fraud investigation unit — which conducts a follow-up human call before the transaction is either approved or cancelled.

The trigger framework is a multi-condition ruleset that balances security with customer friction. Over-triggering authentication calls for routine low-value transactions degrades customer experience and desensitizes customers to the calls — the equivalent of setting off so many false alarms that customers ignore real ones. Under-triggering misses fraud. The optimal configuration triggers authentication for 3–8% of all transactions, representing the highest-risk subset.

Amount threshold is the primary trigger: banks configure a threshold above which every transaction requires authentication regardless of other conditions. Private sector banks typically set this at ₹1–₹2 lakh for NEFT/RTGS and ₹50,000–₹1 lakh for UPI and card transactions. PSU banks often configure higher thresholds. The threshold is configurable by customer segment — a HNI customer with regular ₹5 lakh transactions would have their threshold set higher to avoid constant calls.

New beneficiary triggers are the second most important category. The first transfer to any beneficiary added in the last 30 days is authenticated regardless of amount — because social engineering fraud overwhelmingly targets the first transfer to a new beneficiary. The fraud engine's beneficiary risk score also contributes: beneficiaries that match known fraud account patterns (recently opened accounts, accounts in fraud hotspot geographies, accounts with names that don't match stated purpose) trigger calls for smaller amounts.

Post-SIM-swap authentication is critical: if the bank's telecom partner data or TRAI SIM registration data shows a SIM port event in the last 24–48 hours, any transaction above ₹10,000 triggers an authentication call — because SIM swap is the primary mechanism fraudsters use to intercept OTPs. The call goes to the customer's alternate contact number (email-delivered OTP or registered landline) rather than the potentially compromised mobile.

RBI has progressively strengthened AFA requirements across digital payment channels. For card-not-present transactions, the 2FA requirement (Verified by Visa / Mastercard SecureCode / RuPay SafePay) mandates an OTP confirmation step. For internet banking NEFT/RTGS above ₹50,000, most banks require a transaction-specific OTP separate from the login OTP. For UPI transactions above the NPCI-defined limit, biometric or device-bound PIN is required.

The AI voice call adds a third dimension beyond the standard SMS OTP model: it is an active, out-of-band verification channel that requires the customer to be reachable by phone, in possession of the registered mobile, and able to verbally confirm the transaction details. An OTP intercepted by a fraudster via SIM swap or malware cannot pass the voice authentication call — because the fraudster would need to also answer the account holder's phone and correctly confirm transaction details under a conversational probing scenario.

For RTGS and large NEFT transactions, RBI has recommended (though not mandated) Callback Verification (CBV) as a supplementary control for corporate accounts. The AI agent operationalizes CBV at scale: every qualifying RTGS transaction triggers an outbound call to the registered corporate contact, confirming beneficiary details, amount, and authorization status before processing — a protocol that previously required dedicated back-office staff to execute manually.

The OTP delivery during the authentication call is a dual-channel confirmation: the OTP is sent via SMS to the registered mobile simultaneously with the call, and the customer reads the OTP back verbally. The call recording serves as a voice-authenticated audit trail — a stronger evidentiary record than a clicked 'I confirm' button in internet banking.

Authentication during a high-value call uses layered identity confirmation. The opening layer is possession confirmation — the customer has answered the call on the registered mobile number, which establishes that the registered number is in their possession. For most transactions, this combined with an OTP confirmation satisfies the authentication requirement.

The OTP layer works as follows: at call initiation, an OTP is simultaneously sent to the customer's registered mobile. The agent asks the customer to provide the OTP they just received. This confirms both possession of the registered mobile and active engagement with the authentication call. The OTP is transaction-specific (generated from the transaction reference, not a generic session OTP) — preventing reuse across different transactions.

Knowledge-based authentication (KBA) serves as the fallback when the customer does not have access to their OTP (different phone, not receiving SMS). The agent asks one to two of the following: date of birth, last four digits of the Aadhaar or PAN, amount of the last three transactions, or the account opening branch name. KBA is weaker than OTP and is used only as a fallback — not as a primary factor for transactions above ₹2 lakh.

Voice biometric authentication operates passively in the background for enrolled customers. As the customer speaks during the call, their voiceprint is matched against the enrolled voiceprint in the biometric store. A match confidence score above the threshold (typically 94–97% for high-value decisions) provides an additional authentication signal — and crucially, a mismatch score can flag impostor risk even if the OTP was correctly provided. Voice biometrics catches cases where a fraudster who has intercepted the OTP is speaking on behalf of the account holder.

The beneficiary cooling period is one of the most effective fraud prevention controls for social engineering attacks. The attack pattern it is designed to stop: a fraudster calls the customer pretending to be a bank officer, convinces them to add a 'refund account' or 'security account' as a new beneficiary, then convinces them to immediately transfer funds to that account. The cooling period creates a mandatory delay — the fraudster cannot get the funds within the same session.

The AI agent's role in cooling period enforcement is active, not passive. When the transaction system identifies that the beneficiary was added within the cooling window, the agent's call explicitly names the cooling period and its protective purpose: 'I see you added this beneficiary [X] hours ago. For your security, your bank requires a [Y]-hour waiting period before the first transfer to any new beneficiary. This waiting period is designed to protect you from fraud, particularly calls from people claiming to be bank officers. Are you aware of this requirement?'

The question 'Are you aware of this requirement?' is a diagnostic question. A genuine customer transferring to a legitimately added beneficiary will typically say yes and understand. A customer in the middle of a social engineering attack — who added the beneficiary under instruction from a fraudster — often reveals the social engineering at this point: 'The person from the bank told me I had to do this right now' or 'They said the cooling period doesn't apply in this situation.'

For customers who acknowledge the cooling period and confirm no third party is involved, the agent offers a reminder call: 'Your cooling period expires at [time]. I can call you at that time to help you complete the transfer — would you like that?' This reminder call serves both as a customer convenience feature and as a second authentication check before the first transfer goes through.

Social engineering detection is the highest-value function of voice authentication over SMS OTP. Fraudsters have adapted to OTP-based authentication by simply coaching the victim through the OTP step while on the phone — the victim receives the legitimate OTP and reads it to the fraudster, who enters it on the fraudulent session. Voice authentication interrupts this attack chain by introducing an AI agent that the victim speaks to directly, creating an opportunity to surface the fraud.

The agent's NLP model is trained on 50,000+ annotated fraud call transcripts from Indian banking fraud databases, identifying linguistic patterns associated with social engineering. Key signal categories:

Urgency signals — 'I must do this immediately', 'it will be too late if I wait', 'my account will be frozen' — are the most common social engineering construct. Legitimate urgent financial transactions do exist, but they don't involve threats to the customer's own account status. The agent notes urgency signals without triggering immediate escalation.

Authority impersonation signals — references to 'RBI', 'CBI', 'ED', 'Income Tax Department', 'Cyber Crime Cell' — combined with transfer instructions are near-certain fraud indicators. No legitimate law enforcement or regulatory authority in India instructs citizens to transfer money to a 'safe account' or 'government-designated account.' The agent is trained to respond clearly: 'I want to be very clear — the RBI and no government agency will ever ask you to transfer funds to an account. This is a common fraud pattern. Is someone on another call or line with you right now?'

Coaching indicators — customer pausing to repeat a phrase, an audible third-party voice in the background, the customer asking someone for the next thing to say, or inconsistency between the stated purpose and the beneficiary details — are the subtlest but most diagnostic signals.

RTGS is India's real-time gross settlement system for transactions above ₹2 lakh. Once an RTGS transaction is settled, reversal requires bilateral agreement between both banks and is not guaranteed. This irreversibility makes RTGS authentication disproportionately important — a fraudulent RTGS transaction that settles is significantly harder to recover than a UPI transaction that can be escalated to NPCI for dispute.

The RBI-recommended Callback Verification protocol for RTGS works as follows: the sending bank's fraud operations team calls the account holder before releasing the transaction for settlement, verbally confirms the key transaction parameters, and logs the call as the authorization record. The AI agent scales this protocol to every qualifying RTGS transaction without requiring manual staff intervention.

The RTGS authentication call asks four specific questions: 'Can you confirm the beneficiary name is [name]?' — customer confirms or corrects; 'Can you confirm the beneficiary account number is [XXXX]?' — the agent reads only the last four digits for security; 'Can you confirm the beneficiary bank and IFSC is [bank/IFSC]?' — a mismatched IFSC is a strong fraud signal; 'Can you confirm the transfer amount is ₹[amount]?' The agent also asks the stated purpose: 'What is this transfer for?' — the response is recorded and analyzed for social engineering signals.

The RTGS cut-off time of 3:45 PM for same-day settlement creates urgency management. Authentication calls for RTGS transactions received between 3:00 PM and 3:45 PM are prioritized to a 5-minute response window — if the customer cannot be reached within 5 minutes, the transaction is held for next-day processing. The agent informs the customer of this when they call back after the cut-off: 'Your transfer will be processed tomorrow, Monday, as the same-day cut-off has passed.'

Corporate transaction authorization operates on a fundamentally different model from retail authentication. Corporate accounts have defined authorization matrices — who can initiate (maker), who must approve (checker), and what amounts require additional signatories — managed in the bank's CBS or corporate banking platform. The AI agent integrates with this authorization matrix to determine who must be called for any given transaction.

For standard corporate transactions (₹2 lakh to ₹1 crore): the agent calls the maker's registered contact first to confirm they initiated the transaction. This prevents CEO fraud / BEC (Business Email Compromise) attacks where a fraudster impersonates a senior executive and instructs a finance team member to initiate a large transfer — the agent's call to the person who actually initiated the transaction confirms the instruction came through legitimate internal channels. The agent then calls the designated checker for authorization.

For large transactions (above ₹1 crore, or above the bank's dual-authorization threshold): a second-level authority call is triggered. The agent calls the CFO, Finance Director, or designated second authority whose contact details are registered in the authorization matrix. This three-party confirmation (maker + checker + second authority) creates a strong authorization chain that prevents any single point of social engineering.

For transactions where the maker and checker are both unreachable within the authentication window, the transaction is placed in a pending queue with a 24-hour expiry. The agent sends WhatsApp notifications to all authorization parties with the transaction details and a callback request. If no authorization is received within 24 hours, the transaction is cancelled and the customer is notified via CBS-triggered communication.

BEC fraud detection is a specific capability: the agent is trained to flag cases where the checker expresses surprise at the transaction ('I didn't know about this transfer', 'The CEO didn't tell me about this') — a signal that the maker may have been socially engineered by someone impersonating a senior executive.

Authentication failure handling is risk-tiered to avoid blocking legitimate customers while maintaining fraud prevention effectiveness. A single OTP entry error by a genuine customer should not block a valid transaction — but multiple authentication failures combined with social engineering signals should trigger an immediate block. The agent's response scales to the risk level.

For low-risk technical failures (first OTP attempt failed due to delay, customer didn't receive SMS, customer was driving and couldn't read the OTP safely): the agent offers a retry within the same call or schedules a callback within 30 minutes. 'I can resend the OTP right now or call you back in 30 minutes when you're in a better position to complete this verification.' For transactions where time is not critical (non-urgent NEFT), the retry window can be up to 4 hours without holding the transaction — it remains pending and the customer is given a call-back window.

For medium-risk failures (OTP failed twice, but no social engineering signals, voice biometric inconclusive): the transaction is placed on a 4-hour hold and the fraud team is notified. The agent sends a WhatsApp message to the customer explaining that the transaction is pending verification and providing a bank fraud helpline number to call for immediate resolution. A fraud specialist calls the customer within 2 hours.

For high-risk failures (authentication failed + two or more social engineering signals, or authentication succeeded but transaction purpose is high-risk): the transaction is immediately blocked. The agent informs the customer: 'For your security, I have placed this transaction on hold. If you initiated this transfer intentionally and are not being asked to do so by a third party, please call [bank fraud helpline number] to speak with a specialist who can assist you immediately.' This framing protects the customer who is being coerced — it gives them an exit path without confirming to a watching fraudster that the transaction is blocked.

International wire transfers combine payment authentication with regulatory reporting obligations that don't apply to domestic transfers. The agent's FEMA compliance segment is a structured 3-minute addition to the standard authentication call, covering the most common compliance questions that customers have and the regulatory information the bank needs for its reporting obligations.

FEMA purpose codes are mandatory for all outward remittances. The agent presents the customer with the most relevant options based on stated purpose: 'P0012' for family maintenance remittance, 'S0012' for overseas education fees, 'S0001' for software/IT service exports, 'F0001' for outright purchase of equity/debt instruments under LRS. For complex transactions (business transactions, investment remittances), the agent clarifies purpose and routes to the bank's trade finance or forex desk for accurate coding.

LRS entitlement check: the agent queries the customer's YTD LRS utilization from CBS (or the RBI's LRS reporting system) and confirms whether the proposed transfer is within the $250,000 per-financial-year limit. For customers approaching the limit, the agent states the remaining entitlement clearly so the customer can adjust the amount if needed.

TCS (Tax Collected at Source) under the Finance Act 2023 applies to LRS remittances above ₹7 lakh per financial year at the rate of 20% (or 5% for education/medical purposes with documentation). The agent informs the customer of the applicable TCS amount, which will be collected by the bank at the time of transfer and reflected in Form 26AS for ITR credit. Many customers are unaware of this — the advisory prevents post-transfer confusion and dispute.

Fraud detection integration creates a risk-informed authentication flow rather than a rule-based one. The same ₹2 lakh transfer from a customer who transacts ₹2 lakh regularly with a long-established beneficiary should be treated differently from a ₹2 lakh transfer from an account with no transaction history to a beneficiary added yesterday. The fraud engine provides this context before the agent makes the call.

The API integration pulls three data points pre-call: the transaction risk score (0–100, with higher scores indicating greater fraud likelihood), the top three contributing risk signals (beneficiary risk, transaction velocity, geographic anomaly, device change, time-of-day anomaly, account age), and the fraud engine's recommended action tier (tier 1: standard authentication, tier 2: enhanced probing, tier 3: hold and escalate).

For tier 1 transactions (low risk score, known beneficiary, normal transaction pattern): the authentication call is brief — identity confirmation + OTP + transaction confirmation — and approval is automatic on pass. For tier 2 transactions (medium risk score, new beneficiary, unusual amount): the call includes the full social engineering detection segment — intent check, purpose question, and beneficiary validation. For tier 3 transactions (high risk score, fraud pattern match): the call is made but the transaction is held regardless of authentication outcome — the agent informs the customer and routes to a fraud specialist for human review.

Post-call, the agent sends outcome data back to the fraud engine: authentication result (pass/fail), social engineering signals detected (0–6), call duration, customer response patterns, and final disposition (approved/held/blocked). This feedback loop continuously improves the fraud engine's model accuracy — authentication call outcomes are among the highest-quality labeled fraud signals available.

Voice biometric authentication provides a passive, non-intrusive identity layer that works alongside OTP rather than replacing it. The customer does not need to say a specific passphrase — natural conversational speech during the authentication call is sufficient for a match decision after approximately 3–5 seconds of speech.

Enrollment is the first requirement. Kallix collects voiceprint enrollment during the customer's welcome call — the 6–10 minutes of natural speech provides more than sufficient audio for a high-quality enrollment sample. Enrollment requires explicit DPDP 2023 consent, which is collected as part of the biometric data processing consent at onboarding. Enrolled customers are flagged in the CBS customer profile; unenrolled customers go through OTP-only authentication.

During the authentication call, the voice biometric engine runs in the background from the first spoken word. The match decision is available within 3–5 seconds of speech. The agent does not announce the biometric check — it is passive. The match confidence score is logged against the transaction record.

The highest value of voice biometrics is the impostor detection scenario: a fraudster who has stolen the customer's OTP and is attempting to impersonate them on the authentication call will have a different voiceprint. The OTP entry may be correct, but the biometric mismatch flags the call for additional scrutiny. The agent's behavior in this scenario: the agent does not reveal that a mismatch was detected (which would allow the fraudster to modify their strategy). Instead, the agent escalates to enhanced probing — asking more specific transaction purpose questions — while simultaneously alerting the fraud operations team in real time.

False rejection rate (genuine customer declined due to biometric mismatch) is managed by setting the biometric threshold as a contributing signal rather than a binary gate. A voiceprint mismatch adds to the risk score but does not alone block the transaction — it must be combined with other risk signals to trigger a hold.

SIM swapping is one of the most sophisticated fraud vectors targeting Indian banking customers. The attack works by convincing a mobile operator to transfer the victim's mobile number to a new SIM card held by the fraudster, who then uses the new SIM to receive all OTPs and authentication codes. By the time the victim notices their phone has lost service, the fraudster may have already initiated and authenticated multiple transactions.

The defense mechanism relies on detecting the SIM port event and triggering alternative authentication before any transaction can be processed. Kallix's fraud detection integration pulls SIM registration status updates from telecom operator APIs — the same data that TRAI requires operators to maintain for number portability compliance. A SIM port event on the customer's registered mobile triggers an immediate flag in the customer's CBS profile.

For the 24–48 hours following a detected SIM port, the standard OTP channel (SMS to registered mobile) is replaced with an alternate channel: OTP delivered to the registered email address, a voice OTP delivered to a registered alternate mobile number, or a hardware token TOTP if enrolled. This ensures the fraudster who now controls the registered mobile SIM cannot receive the OTP.

The voice authentication call in the post-SIM-swap period includes an explicit advisory: 'I'm calling about a large transaction on your account. Before we proceed, I want to mention that your mobile number appears to have been recently transferred to a new SIM card. Were you aware of this change? If not, please contact your mobile operator's fraud line immediately, as this could indicate your number has been taken over by a third party.' This advisory is critical — many victims learn about the SIM swap for the first time through this call.

UPI's real-time settlement design makes authentication timing the primary engineering challenge for high-value UPI transactions. A standard UPI payment completes in 2–10 seconds — there is no built-in authentication window like the one that exists for RTGS (which has a processing queue). AI authentication for UPI requires either a pre-authorization hold in the bank's UPI processing layer or a post-authorization block-and-reverse mechanism.

The pre-authorization hold approach: when a UPI transaction above the threshold is submitted, the bank's UPI processing layer places the transaction in a 'pending authentication' state before sending the response to NPCI. The authentication call is made immediately — the bank has a configurable window (typically 30–120 seconds, within NPCI's timeout tolerance) to complete authentication before the transaction either proceeds or times out. If authentication completes within the window with a pass, the UPI response is sent to NPCI and the transaction settles. If authentication fails or the window expires, the transaction returns a failure code.

The post-authorization approach (for banks that cannot implement pre-authorization holds): the UPI transaction is processed normally, but a simultaneous outbound call is placed. If the call reveals fraud or the customer is unreachable, the bank initiates an immediate freeze on the credit to the beneficiary account via NPCI's dispute mechanism — which must happen before the beneficiary withdraws. This approach has a lower recovery rate but is simpler to implement.

For UPI collect requests (where a merchant or individual sends a collect request to the customer's UPI app and the customer approves it), authentication is especially important: social engineering via fake collect requests is the fastest-growing UPI fraud vector. The agent is specifically trained to ask: 'Did you initiate this payment, or did someone send you a request to approve?'

Unreachable customers are a significant operational scenario — customers may be in meetings, traveling, or simply not near their phone. The challenge is balancing fraud prevention (holding unverified high-value transactions) with customer convenience (legitimate customers whose transactions are delayed by inability to receive a call).

The two-attempt cascade works as follows: the first call at T+0 seconds (transaction submission). If unanswered after 30 seconds, the agent attempts a second call at T+3 minutes. If both attempts are unanswered, the transaction enters a hold queue. The hold duration is risk-tiered: low fraud-score transactions (routine amount, established beneficiary) are held for 4 hours; medium-risk transactions for 12 hours; high-risk transactions for 24 hours.

WhatsApp notification serves as the hold advisory: 'A transaction of ₹[amount] to [beneficiary name] from your account ending [XXXX] has been placed on hold for security verification. To approve this transaction, please call [bank fraud helpline] or reply to this message.' The WhatsApp reply option routes to the AI authentication agent, allowing the customer to authenticate via the messaging channel if they can't take a voice call.

For time-sensitive transactions — particularly RTGS approaching the 3:45 PM cut-off — the fraud team escalates the unreachable case after the first unanswered attempt rather than waiting for the second attempt. A fraud specialist makes a manual callback within 10 minutes.

For customers who are genuinely unavailable for 24+ hours (travel abroad, medical emergency), the bank offers in-branch transaction authorization as an alternative — the customer can visit any branch and provide in-person authorization for the held transaction. This procedure is explained in the WhatsApp notification.

Managing legitimate urgency is one of the most nuanced aspects of high-value authentication. The tension is real: an overly cautious agent that delays every 'urgent' transaction frustrates genuine customers and creates friction that drives them to less secure channels. An agent that responds to urgency by relaxing authentication enables the most common social engineering attack vector — fraudsters almost always create urgency to pressure victims through authentication steps quickly.

The resolution is procedural rigor regardless of urgency, with expedited processing for verified transactions. The agent's authentication steps are fixed — OTP, transaction confirmation, intent check — and the duration of these steps is already brief (2–3 minutes for a straightforward call). A customer with a legitimate urgent transaction completes authentication in 2–3 minutes and gets immediate approval. The 'urgency' has no impact on the authentication process itself, only on how quickly the approval is released after authentication.

The agent is specifically trained not to apologize for the authentication call on urgent transactions and not to abbreviate the authentication steps because the customer expresses time pressure. The response to 'I need this approved right now, every second counts' is: 'I understand, and I can get you verified in under 3 minutes right now. Let me just confirm your OTP first.' The authentication proceeds at normal pace.

For transactions where the customer cannot complete authentication in the moment (customer is driving, in a meeting, in a poor reception area), the agent offers a specific expedited callback time — 'I can call you back in 15 minutes — will that work for you?' This gives the customer a concrete resolution timeline while maintaining authentication requirements.

Card transaction authentication is complicated by the speed of authorization and the diversity of transaction contexts — in-store card swipe, e-commerce checkout, recurring subscription charge, and international POS are all different scenarios with different fraud profiles and authentication needs.

For e-commerce card-not-present transactions above the threshold, the authentication call supplements the standard 3DS/OTP flow — not replaces it. The customer has already entered the OTP in the browser or app; the voice call is a secondary confirmation that the customer both received and understood what they were authorizing. This is particularly valuable for e-commerce transactions where the 3DS OTP screen may have been triggered on a device that has been compromised (malware-redirected browser session).

For in-store (card-present) transactions above the threshold, authentication calls are triggered when the card-present transaction matches a fraud pattern — transaction above the customer's typical in-store spend, geographic anomaly (card used in a city different from the customer's registered address), or after a previous high-value authentication in a different location within 60 minutes (speed testing). For these scenarios, the agent asks: 'I see a card transaction at [merchant] in [city/area] for ₹[amount]. Are you currently at this location?'

For international POS transactions above the threshold, the authentication call is placed to the customer's registered Indian mobile number. If the customer is traveling and has roaming active, the call reaches them abroad. If the phone is switched off or out of coverage, the transaction is placed on hold — the customer can call the bank's international toll-free number to authenticate.

Joint account authentication complexity depends entirely on the account operation mandate — the instruction given at account opening for how transactions are to be authorized. The three common operation mandates in Indian banking are E or S (either or survivor — any one account holder can authorize), Joint (all account holders must authorize), and F or S (former or survivor — primary holder authorizes; secondary only inherits).

For E or S accounts (most common for joint savings accounts): the authentication call goes to whichever account holder initiated the transaction. If the transaction was initiated via one holder's net banking login, the call goes to that holder's registered mobile. A single authentication pass is sufficient.

For Joint operation accounts (common for joint current accounts and investment accounts): the agent calls the first account holder and collects authentication, then immediately calls the second account holder. The transaction is held until both authentications are complete. The hold window for the second holder is 30–60 minutes — if the second holder cannot authenticate within this window, the transaction remains pending and both holders receive a WhatsApp notification with the pending status and an authentication callback option.

For business partnerships with specific authorization mandates (any two of three directors, for example), the CBS authorization matrix defines the valid authorization combinations. The agent calls account holders in sequence until the required combination of authorizations is achieved.

The joint account authentication design also handles domestic disputes: if one account holder is attempting to initiate a large transaction without the other's knowledge (in a disputed relationship or divorce proceeding), the second holder's authentication call effectively functions as a notification — giving the second holder the opportunity to refuse authorization. This is a protective feature, not an incidental one.

Fraud pattern recognition is the product of training the NLP model on annotated call transcripts from real fraud incidents. Each fraud type has characteristic language patterns that appear consistently across victims — because fraudsters use scripts that are effective, and they iterate on what works.

Safe account fraud: the fraudster claims the customer's bank account has been 'compromised' or 'flagged for suspicious transactions' and instructs them to move funds to a 'safe account.' Language signature: 'your account is compromised', 'we will protect your funds', 'transfer to RBI Safe Account' or 'Cyber Crime Safe Account'. The agent's specific response: 'Banks and government agencies never ask you to transfer your own money to a different account for safety. This is a recognized fraud pattern. Please hang up if someone is telling you this.'

RBI/CBI/ED impersonation: fraudsters claim to be from regulatory authorities and threaten legal action unless the customer pays a fine or moves money. Language signature: 'RBI has issued a directive', 'your account is under ED investigation', 'you must transfer immediately to avoid arrest', 'this is an official government instruction.' Response: 'RBI, CBI, and ED do not collect fines or direct payments over the phone. If you have received such a call, please report it at cybercrime.gov.in.'

Business Email Compromise (for corporate accounts): an employee has been instructed by a convincing fake email from a senior executive to initiate an urgent wire transfer. Language signature: 'the CEO asked me to do this', 'it is confidential, don't tell anyone', 'this needs to be done before [CEO name] returns'. The agent specifically asks for the second authorization call to the CEO directly: 'I need to confirm this instruction with your CEO directly — can you provide their registered contact number?'

Loan processing fee fraud: fraudsters offer pre-approved loans and ask for processing fees or insurance premiums to be deposited before disbursement. Language signature: 'advance payment to secure the loan', 'refundable deposit', 'RBI-approved loan'. Response: 'Legitimate banks and NBFCs never collect fees before loan disbursement. This is a common fraud.'

Wealth and investment account fraud has distinct characteristics from retail banking fraud. The transactions are larger, the customers are more financially sophisticated, and the fraud vectors are often more elaborate — investment scam operators present convincing trading platforms, fake regulatory credentials, and sophisticated returns fabrications. The AI agent's authentication for wealth transactions needs to address these specific vectors.

For large equity trades and portfolio transactions, SEBI's investor protection framework requires that brokers have reasonable confidence the customer is making an informed decision — not acting under duress or based on misleading advice. The authentication call includes a SEBI-framed disclosure: 'Before I approve this trade, I want to confirm that this is your decision, made without pressure from any third party or guarantee of returns from any individual or platform.' This disclosure is a single sentence — it is not intrusive — but it creates a documented record that the customer confirmed informed consent.

For mutual fund redemptions above ₹10 lakh: large-scale redemptions are sometimes the result of social engineering (fraudster convinces the customer to redeem their MF holdings and transfer the proceeds to a 'safe account' or 'guaranteed return' scheme). The agent asks specifically: 'Are you planning to reinvest these funds elsewhere?' — not as an investment advisory question but as a social engineering detection signal. A customer who is being redirected to a fraudulent scheme typically reveals it here.

For international investment remittances (LRS-funded foreign securities, overseas mutual funds): the FEMA purpose code and LRS utilization check from the international wire authentication flow applies, plus a SEBI AIF/PMS confirmation for institutional product investments.

Post-authentication disputes are some of the most complex in Indian banking because the bank has evidence of customer authorization — an OTP was correctly entered, the transaction was confirmed — while the customer claims they were deceived. The resolution depends on what can be established about the customer's state of knowledge and consent at the time of authentication.

The call recording from the authentication call is the primary evidence artifact. Unlike a digital OTP entry log which only shows that the correct code was entered, the voice call recording captures the full interaction: the customer's verbal confirmation of the transaction details, what they said the transfer purpose was, any social engineering signals the agent detected, and the customer's emotional state (distress, confusion, scripted responses). This is significantly richer evidence than digital logs alone.

If the authentication call recording reveals social engineering signals that the AI agent detected but that were insufficient to block the transaction (one signal flagged but not two), the recording supports the customer's claim that they were coerced. In these cases, RBI's Zero Liability framework may apply — particularly if the fraud resulted from a third-party breach rather than the customer's own negligence.

For cases where the customer provided OTP to a third party while on a live call with a fraudster (a common scenario where the fraud call and the bank authentication call overlap), the customer's narration during the authentication call often contains telling details: the customer was distracted, gave the OTP immediately without appearing to read it, or the purpose stated was vague or inconsistent with the beneficiary. These signals support a finding of third-party fraud rather than customer negligence.

Post-authentication disputes feed directly into the fraud model training — cases where the AI agent's social engineering detection score was below the blocking threshold but later confirmed as fraud are used to recalibrate the detection thresholds.

NRI authentication has two operational challenges beyond standard authentication: time zone misalignment and registered mobile inactive in India. An NRI living in Dubai whose registered mobile number is an Indian SIM card they don't carry with them will not receive SMS OTPs or voice calls on that number. The authentication system must have an alternate contact channel pre-registered.

Kallix's NRI authentication setup collects an overseas contact number and email address during the account onboarding journey, stored in CBS as the NRI alternate authentication contact. When a high-value transaction trigger fires for an NRI account, the system checks whether the registered Indian mobile is active (via telecom reachability data) before placing the call. If inactive, the call is placed to the overseas mobile number.

For time zone management: the authentication call timing logic for NRI accounts checks the customer's declared country of residence and schedules calls during local waking hours (9 AM–10 PM local time) rather than IST. This avoids authentication calls at 3 AM local time, which is a customer experience failure that also creates security risk — a groggy customer receiving a 3 AM fraud call may be less capable of identifying social engineering signals.

For NRE account large transfers to overseas accounts (repatriation of NRE savings): the agent confirms the transfer purpose, verifies the receiving account belongs to the NRI (the most common repatriation is NRI's own overseas account — the agent notes the beneficiary name match with account holder name). For NRO account transfers above $1 million equivalent, the CA certificate requirement under FEMA is flagged and the customer is directed to the bank's forex operations team before the transfer can proceed.

Authentication measurement is a two-sided optimization problem. Improving fraud catch rate (catching more fraud) increases false positives (more legitimate transactions held). The target is to maximize catch rate while keeping false positive rate below a customer experience threshold — typically below 2% of triggered calls resulting in a hold that is later found to be legitimate.

Fraud catch rate is measured as: confirmed fraud transactions that were stopped at authentication as a percentage of all confirmed fraud transactions that would have qualified for authentication call. A catch rate of 85–92% means 8–15% of social engineering fraud transactions pass the authentication call — either because the victim was too well-coached to reveal social engineering signals, or because the call was unanswered and the fraud proceeded through an alternate transaction channel.

False positive rate is the commercially sensitive metric: every legitimate transaction incorrectly held costs customer satisfaction, potentially transaction value (if the customer gives up and uses a different payment method), and RM relationship capital. Banks with false positive rates above 5% of all authentication-triggered transactions see measurable NPS decline from authentication friction. The target is 1–3% false positive rate.

Authentication completion rate measures whether the customer successfully authenticates when reached — as opposed to hanging up, failing OTP repeatedly, or timing out. A completion rate below 75% suggests the authentication flow is too complex or the OTP delivery is unreliable. Target: 88–93% completion rate.

Post-authentication dispute rate is the lagging indicator: transactions that were authenticated and later disputed by the customer as social engineering fraud. A post-authentication dispute rate above 0.5% of authenticated high-value transactions suggests social engineering detection thresholds are too lenient.

Transaction authentication sits at the intersection of payment regulation, data privacy, and cybersecurity — each requiring specific compliance treatment.

RBI AFA guidelines have evolved over multiple circulars since 2009. The current framework requires a second authentication factor for all card-not-present transactions (not card-present where PIN serves as the second factor), and strongly recommends enhanced authentication for large internet banking transfers. RBI's 2021 guidelines on internet banking security specifically reference Callback Verification for large RTGS transactions as a recommended control. Kallix's authentication agent implements CBV and documents each call as the AFA audit record.

Voice biometric data is classified as sensitive personal data under DPDP Act 2023, requiring explicit, separate consent for collection and processing. The consent language must specify: that the voiceprint will be used for identity verification, how long the voiceprint will be retained, whether it will be shared with third parties, and the customer's right to withdraw consent. Kallix provides compliant DPDP consent language for all biometric enrollment flows.

Call recordings from authentication calls have a dual regulatory status: they are customer interaction recordings under DPDP (standard 2-year retention) and evidence records for potential fraud disputes (RBI audit requirement of up to 8 years). Banks must apply the longer retention standard — 8 years — to authentication call recordings associated with transactions that were later disputed or investigated.

CERT-In's cybersecurity guidelines for the financial sector (2022) require multi-factor authentication for high-value transactions, periodic security audits of authentication systems, and incident reporting for authentication bypass events within 6 hours. Kallix's authentication agent generates automated incident reports for all authentication bypass attempts (transactions that bypassed authentication and were later confirmed as fraud) within the CERT-In reporting timeline.

The ROI case for high-value transaction authentication has two components: cost reduction on the authentication process itself, and fraud loss prevention that vastly exceeds the authentication cost.

Authentication cost: a manual fraud operations callback requires a trained fraud analyst, averaging 5–8 minutes per call at ₹40–₹50/minute loaded cost = ₹200–₹400 per call. AI authentication is ₹25–₹60 per call including all voice infrastructure, NLP processing, and fraud engine API calls. For a bank making 5,000 authentication calls per month, the annual cost reduction is ₹8.4–₹20.4 crore.

Fraud prevention value: the primary ROI. If 3–8% of ₹50 crore daily transfers are triggered for authentication (₹1.5–₹4 crore daily in authenticated transactions), and 85–92% of social engineering fraud in that pool is caught, the daily fraud prevention value is approximately ₹25–₹80 lakh (assuming 5–8% of triggered transactions are actual social engineering fraud attempts based on industry base rates). Annually, this is ₹90 crore to ₹300 crore in prevented fraud loss — dwarfing the authentication infrastructure cost by a factor of 50–200x.

The dispute cost avoidance is the secondary driver: each prevented fraud avoids a dispute investigation (₹600–₹900 per case), chargeback processing (₹500–₹1,200 per case for card chargebacks), and potential provisional credit (full transaction amount outstanding for the investigation period). For 100 prevented fraud transactions per month at an average ₹2 lakh value, the avoided provisional credit exposure is ₹2 crore per month.

Regulatory risk avoidance is the tertiary driver: RBI can impose penalties on banks where fraud losses from internet banking are disproportionate to industry benchmarks, and where banks have not implemented recommended controls (CBV, AFA). Implementing AI authentication demonstrates good-faith compliance with RBI security recommendations.

High-value transaction authentication is among the more complex Kallix deployments because it requires write access to the transaction processing layer — the agent must be able to hold a transaction pending authentication and release it upon success. This write access requires a thorough information security review by the bank's CISO team, which is typically the longest single phase.

Weeks 1–2 cover the integration layer: CBS read access for account and transaction data, fraud detection engine API for pre-call risk scores and post-call feedback, transaction hold/release API (requires InfoSec approval and security penetration testing), and authentication delivery infrastructure (OTP generation and delivery, voice biometric enrollment store).

Week 3 covers authentication flow configuration: threshold setup by product type and customer segment, social engineering detection model calibration to the bank's transaction data, BEC detection rules for corporate accounts, and language configuration for all 10 supported languages. The social engineering detection model is pre-trained on 50,000+ annotated transcripts but requires bank-specific calibration — the threshold at which a fraud signal triggers a hold versus an enhanced probing question is set during this phase based on the bank's risk appetite and customer profile.

Week 4 covers compliance and security: DPDP consent language for call recording and voice biometric enrollment, CERT-In compliance documentation, RBI Outsourcing Guidelines compliance review, and penetration testing of the transaction hold/release API. This is a non-negotiable phase — no bank will accept an authentication agent touching live transactions without a security review.

Weeks 5–6 cover UAT and pilot: parallel-running the AI authentication alongside existing manual processes for 500–1,000 authentication events, with Kallix security specialists reviewing all flagged transactions and escalation decisions in real time.

SMS OTP is a strong authentication factor against account takeover — where a fraudster obtains the customer's credentials and attempts to initiate transactions without the customer's knowledge. But the dominant Indian banking fraud today is not account takeover — it is social engineering, where the customer is manipulated into initiating and authenticating the transaction themselves. For social engineering, SMS OTP provides zero protection: the fraudster simply instructs the victim to read the OTP aloud.

The five capabilities that AI voice authentication adds: (1) Intent confirmation — the agent verbally confirms the customer is aware of and intended this specific transaction. A customer who says 'no, I didn't initiate this transfer' immediately on a confirmation question is protected in a way that entering an OTP cannot provide. (2) Beneficiary validation — verbal confirmation of beneficiary name, bank, and purpose. Beneficiary errors (wrong account, wrong bank) are caught; fraudulent beneficiaries that don't match stated purpose are flagged. (3) Social engineering detection — NLP analysis of verbal responses detects the language patterns of coached victims, fear-based coercion, and authority impersonation. (4) SIM swap resistance — if the registered mobile SIM has been swapped, the voice call and OTP go to an alternate contact, and the voiceprint of the person answering can be compared against the enrolled customer voiceprint. (5) Audit trail quality — a voice recording of 'I confirm I am transferring ₹2 lakh to ABC Construction for my kitchen renovation' is a dramatically richer authorization record than a digital log entry of 'OTP: entered correctly.'

For the 96–98% of high-value transactions that are legitimate, AI voice authentication is only 2–3 minutes longer than SMS OTP. For the 2–4% that are social engineering attempts, it is the primary line of defense.

Authentication friction is a real cost for corporate treasury teams and high-net-worth individuals who make regular large payments. Repeated callbacks for the same vendor payment at the same amount on the same day-of-month are operationally disruptive and create customer satisfaction problems without a meaningful fraud benefit — because repeat-pattern transactions to known beneficiaries have a fraud rate below 0.01% in bank production data.

Kallix whitelisted beneficiary framework:
- Eligibility: beneficiary must appear in 3 prior authenticated transactions within 90 days, with consistent amount range (within 20% variance) and consistent day-of-month (within 5 days)
- Whitelist approval: the initial whitelist registration is confirmed via an authenticated voice call — the customer explicitly approves the beneficiary for auto-approval above the standard trigger threshold
- Anomaly override: even for whitelisted beneficiaries, Kallix re-triggers authentication if the amount exceeds the approved range by more than 30%, the originating account changes, or the fraud engine flags the transaction
- Whitelist expiry: whitelist entries expire after 12 months of inactivity and require re-authentication to reactivate

For corporate multi-approver transactions (Maker-Checker), the whitelisted beneficiary approval applies to the Checker step — the Maker still initiates the transaction in the CBS, and the Checker receives a simplified confirmation call rather than a full authentication flow.

Lenders and banks using the whitelisted beneficiary framework see 35–45% reduction in authentication call volume for corporate customers, with no measurable increase in fraud on whitelisted beneficiary transactions.

Standard authentication flows assume a customer can respond within 8–10 seconds, process multi-step verification instructions, and navigate an IVR confidently. For elderly customers (typically 65+) or customers with cognitive or hearing impairments, these assumptions fail — leading to authentication abandonment and escalation to a branch, which defeats the purpose of voice authentication.

Kallix adaptive authentication features for vulnerable customers:

Extended timeouts: the system waits 30 seconds for a response rather than 8–10 seconds. The agent repeats the question once before escalating: 'I did not hear your response — please take your time and repeat [the verification detail].'

Simplified language: for accounts flagged as senior citizen or accessibility-enabled, the agent uses shorter sentences, slower speech rate (configurable to 0.8x standard rate), and confirms each step before proceeding.

Trusted contact authentication: a customer can register a trusted family member or caregiver with the bank. For high-value transactions, the trusted contact receives a parallel SMS notification and can confirm or flag the transaction from their registered mobile number — adding a second human layer without requiring the primary account holder to navigate a complex IVR.

Voice biometric exemption: elderly customers with voice changes due to health conditions (post-stroke, Parkinson's, post-COVID vocal cord changes) may fail voice biometric matching. Kallix allows the bank to set a lower biometric confidence threshold for accounts flagged for voice changes, with a corresponding uplift in other authentication factors.

RBI Banking Ombudsman data shows accessibility-related complaints are the third-fastest-growing complaint category — Kallix's adaptive flow directly addresses this regulatory risk.

High-value transaction authentication generates a legal record of the bank's fraud prevention process. When a customer subsequently disputes a transaction they authorised ('I was tricked into confirming it'), the bank's defence depends on demonstrating that reasonable fraud detection steps were taken and that the customer explicitly confirmed the transaction details.

Kallix authentication audit log fields:
- Timestamp: UTC + IST, millisecond precision
- Caller CLI: the phone number from which the customer was called (or called in)
- Channel: outbound AI callback, inbound IVR, WhatsApp OTP
- Authentication method: OTP, voice biometric, security question, out-of-wallet question
- Biometric confidence score (if voice biometric used)
- Fraud engine score at time of authentication decision
- Authentication outcome: passed, failed, partial (step-down authentication)
- Transaction details confirmed: amount, beneficiary name, account last 4 digits — the agent repeats these and the customer confirms
- Call recording reference: stored in lender's cloud storage with hash verification
- CBS transaction reference: links the authentication event to the specific transaction in the core banking system

Storage: RBI requires transaction records to be maintained for 8 years. Kallix authentication logs are stored in the lender's cloud environment (not Kallix infrastructure) to ensure the lender retains full custody of regulatory records.

Admissibility: the combination of call recording + transcript + timestamp + CBS link meets the electronic record admissibility standard under Section 65B of the Indian Evidence Act. Kallix provides a Section 65B certificate template for lenders to use when producing records in court or Ombudsman proceedings.