Agentic AI in BFSI: Governance for Loan Agents, Fraud Agents, and KYC Agents

Loan underwriting agents, fraud detection agents, KYC/AML agents, and customer service agents are already running in production at banks across India, the UK, and the US — this is not a 2027 planning problem. Each deployment pattern carries governance obligations that a generic "AI risk register" does not capture, and examiners are starting to ask use-case-specific questions rather than accepting a single framework-level answer. This guide works through what each of the four major BFSI agentic deployments actually requires, and where the regulatory citations commonly used for them get sloppy.

Why a single AI governance framework doesn't survive an RBI examination

A generic AI governance framework asks whether a system has a risk register, a validation report, and an audit trail. That bar is necessary but it is not what decides whether an examination goes well. A loan underwriting agent and a customer-FAQ chatbot are both "AI systems" on paper, but the questions an examiner asks about each are structurally different, and a bank that answers both with the same validation template will be asked to come back with specifics.

The loan agent sits inside the EU AI Act's high-risk category for creditworthiness assessment (Annex III, point 5(b)) if the bank has any EU-touching lending exposure, which brings explainability and bias-testing obligations that a FAQ bot never triggers. The fraud agent's defining risk is authorization scope — what it is allowed to do, not just what it predicts — which a document-summarization tool never faces. KYC/AML agents sit at the intersection of AI governance and data-protection law because they process Aadhaar, PAN, and passport data directly. Use-case-specific governance is how a bank closes the gap between its enterprise AI policy and the specific evidence an examiner will ask for on each deployment.

Loan Underwriting Agents: EU AI Act Annex III and RBI Fair Practices Obligations

Loan underwriting agents assess creditworthiness, extract income and asset data from documents, and recommend or make approval/rejection decisions. For any bank with EU-touching lending exposure, this is the clearest high-risk classification in the BFSI stack: EU AI Act Annex III, point 5(b) names "evaluating the creditworthiness of natural persons or establishing their credit score" as high-risk, explicitly excluding fraud-detection use (more on that exclusion below, because it matters for the next section). On the Indian side, RBI's Digital Lending Guidelines (2022) already require a Key Fact Statement disclosing the all-in cost of credit and a borrower cooling-off period — obligations that exist independently of whether an AI model made the underwriting call, and that an agentic pipeline does not get to skip.

What actually goes wrong:

• Discriminatory outcomes correlated with protected attributes (gender, religion, caste, disability, age) baked into training data or feature engineering, often indirectly through proxies like pincode or employer category
• Hallucinated document extraction — wrong income figures, asset values, or employment status fed straight into the decisioning layer with no independent check
• Indirect prompt injection via fraudulent loan documents engineered to manipulate the underwriting output
• No human-readable basis for a rejection, which fails both natural-justice expectations and RBI's Fair Practices Code requirement that lenders communicate reasons for declining a loan application
• A vendor-supplied scoring model validated only by the vendor's own attestation, with no independent check of its behavior on the bank's actual applicant population

What a bank has to actually build:

• Bias testing — demographic parity and equal-opportunity metrics computed across protected attributes before go-live and every quarter in production, not once at model sign-off
• Attribution for every decision (SHAP, LIME, or an equivalent method) retained long enough to survive a regulatory inquiry — most banks are defaulting to seven years to match other lending-record retention practice
• Injection scanning on every uploaded document before it enters the extraction-to-decision pipeline
• Independent validation of every model component in the pipeline, including third-party and vendor models — vendor attestation alone is not independent validation
• Mandatory human review for boundary-case scores (within a defined margin of the approval threshold) and for every rejection a customer can contest
• India-resident processing and storage of applicant data for Indian lending, consistent with RBI's existing payment and lending data-residency expectations

A CRO who has actually sat through an RBI model-risk discussion knows the question that lands hardest isn't "do you bias-test" — it's "show me the specific applicant who was rejected at the boundary, and show me the human who reviewed it." If that record doesn't exist, the bias-testing report doesn't help.

Relevant frameworks: EU AI Act Annex III(5)(b); RBI Digital Lending Guidelines 2022; RBI Fair Practices Code; DPDP Act 2023; SR 11-7 (for US-exposed entities).

Fraud Detection Agents: Why "High-Risk Under the EU AI Act" Is the Wrong Citation

Fraud detection agents monitor transaction streams, flag anomalies, and — in agentic deployments — take enforcement action directly: blocking a transaction, freezing an account, opening an investigation workflow. That enforcement capability, not the underlying model, is what makes the deployment agentic rather than just another classifier sitting behind a human analyst.

What actually goes wrong:

• Authorization creep: an agent scoped to flag transactions gets exploited — or simply misconfigured — into blocking them without human sign-off, because the capability boundary was never enforced in code
• False-positive scale: even a seemingly small false-positive rate compounds fast against India's transaction volumes — a bank processing millions of transactions daily can generate tens of thousands of wrongly-flagged legitimate transactions in a single day if the rate drifts
• Adversarial evasion: fraud rings that reverse-engineer a detection model's thresholds craft transactions specifically to sit under them — ordinary drift monitoring, built to catch gradual change, does not catch a deliberately engineered evasion pattern
• No attribution per flag: investigators working the queue need a reason, not a bare probability score, or the investigation backlog grows faster than the team can clear it
• Fraud patterns move on a weekly cycle; a quarterly re-validation schedule is validating a model against a threat landscape that no longer exists by the time the report is filed

What a bank has to actually build:

• Hard separation of capability tiers — flag, block, and investigate are distinct authorization levels enforced at the system layer, not left to the agent's own judgment about what it should do next
• Continuous false-positive-rate measurement on live traffic, with an alert threshold that triggers human review of the flag queue, not just a quarterly report
• Quarterly adversarial red-teaming against known evasion patterns — velocity manipulation, transaction splitting, account-takeover sequences — run by a team that is explicitly trying to beat the model
• Human confirmation required before any account freeze or transaction block executes; the agent can recommend, it cannot unilaterally act on money movement
• Weekly behavioral drift monitoring rather than quarterly re-validation, because the gap between those two cadences is exactly where fraud rings operate

Relevant frameworks: RBI's fraud risk management and cyber security expectations for regulated entities; MITRE ATLAS (adversarial technique catalog — see the authorization-boundary discussion below for the correct citation format); DPDP Act 2023.

KYC/AML Agents: Where DPDP, PMLA, and AI Governance Actually Overlap

KYC/AML agents verify customer identity, run document OCR and cross-matching, screen against sanctions lists, and flag suspicious activity for SAR filing. They touch the most sensitive personal data in the banking stack — Aadhaar, PAN, passport, and financial history — which means they sit under AI governance and data-protection obligations at the same time, not one after the other.

What actually goes wrong:

• Aadhaar, PAN, and passport numbers sitting in raw model context well past the point where the extraction task needed them, with no masking or tokenization — a purpose-limitation problem even where processing itself was lawful
• Sanctions-screening false negatives create direct regulatory exposure under PMLA; false positives create customer harm and operational drag — a bank needs to measure both, not just the one that shows up in an audit
• Document injection: a fraudulent KYC document engineered to manipulate the OCR/extraction output is a live, demonstrated attack vector, not a theoretical one
• Cross-border processing of Indian KYC data by a foreign-hosted model may trip a sector-specific localization rule even where DPDP itself does not require it — see the flag above
• SARs and KYC verification records have to be audit-trailable for PMLA investigation, which means the AI's decision basis has to be preserved in a form that survives legal scrutiny, not summarized away

What a bank has to actually build:

• Masking or tokenizing Aadhaar, PAN, and passport data at the inference layer by default, lifting the mask only for the specific extraction task that requires it
• Enforced purpose limitation — KYC data used for identity verification cannot flow into credit scoring or marketing models without a separate, explicit consent basis
• A clear determination of which localization mandate (if any) actually applies to the specific KYC dataset, rather than a blanket "DPDP requires it" assumption
• Document-injection scanning on the OCR/extraction pipeline before output reaches the verification workflow
• Continuous false-negative monitoring against updated OFAC, UN, and RBI sanctions lists — a quarterly refresh cycle is too slow for list updates that happen weekly
• A tamper-evident SAR audit trail — decision basis, evidence used, and human review steps — built to survive a PMLA proceeding, not just an internal audit

It's also worth building the CERT-In angle into the incident response plan now rather than after an incident: CERT-In's 2022 directions require reporting qualifying cyber incidents within six hours of detection, and a KYC-data breach caused by a manipulated extraction agent is exactly the kind of incident that clock applies to.

Relevant frameworks: DPDP Act 2023 §4, §6, §8; PMLA and its Rules on customer due diligence; CERT-In 2022 incident-reporting directions; RBI's 2018 payment-data localization circular (where applicable).

Customer Service and Advisory Agents: The SEBI/IRDAI Advice Boundary

Customer service agents answer product queries, handle complaints, pull up account information, and — in more advanced deployments — offer guidance on products, rates, and financial decisions. The governance line that matters here is the one between information and advice: the moment an agent moves from describing a product to recommending one, SEBI's Investment Adviser framework (for securities) or IRDAI's point-of-sale and advice rules (for insurance) start to apply, and most banks have not drawn that line explicitly inside their own agent design.

What actually goes wrong:

• An agent crosses from product description into investment, insurance, or credit recommendation without the licensing, disclosure, or suitability checks that regulated advice requires — frequently without anyone on the product team noticing the agent had crossed that line
• Hallucinated rates, terms, or fee details create mis-selling exposure even when the agent never makes an explicit recommendation — a wrong number stated as fact is still a wrong number
• Prompt injection aimed at extracting system-prompt content, internal pricing logic, or product configuration the customer isn't supposed to see
• Factual accuracy degrades over long conversations — a customer whose decision gets made on turn 20 may be relying on a detail the agent distorted on turn 4
• Conversation logs accumulate significant personal and financial data, which pulls DPDP Act retention limits and data-principal rights directly into the customer-service stack

What a bank has to actually build:

• A regulated-activity guardrail that detects and blocks investment advice, specific product recommendations, and financial-planning guidance, routing instead to a licensed human advisor with the required disclosure
• Quarterly sampling of customer-service conversations for hallucination rate on product-specific information — rates, fees, terms — scored against the actual product documentation
• Injection detection active on every customer-facing turn, not just the first message of a session
• A defined maximum conversation length, with factual claims in long conversations flagged for re-verification before the conversation continues
• DPDP-compliant conversation data governance: retention limits enforced, data-principal access and deletion requests supported, and Aadhaar/PAN never retained in conversation logs in the first place
• A human escalation path with a defined SLA for every customer dispute of an AI-generated answer

Relevant frameworks: SEBI (Investment Advisers) Regulations, 2013; IRDAI point-of-sale and distance-marketing guidelines; RBI FREE-AI Framework (August 2025 report); DPDP Act 2023; OWASP Top 10 for LLM Applications, LLM01 (Prompt Injection).

The Governance Architecture Common to All Four Agents

The four use cases differ in which layer carries the most risk, but the underlying governance architecture is the same across all of them, and building it once — rather than four times — is the actual cost-saving move here.

Action checklist

1. Declare and enforce capability scope architecturally for every agent — what it can call, read, write, or block — rather than relying on system-prompt instructions that a determined user or a bad document can override.
2. Put injection detection at every content entry point, not just the user's first message: retrieved documents, email bodies, API responses, and database query results all need scanning before they enter agent context.
3. Measure the metric that matches the failure mode — false-positive rate for fraud agents, factual precision for advisory agents, demographic parity for underwriting agents — because a generic "accuracy" number hides the specific way each use case actually fails.
4. Require human confirmation before any consequential action executes — transaction blocks, loan rejections, SAR filings — and build that gate into the system, not into a policy document the agent has no mechanism to obey.
5. Build forensic replay before you need it: the ability to reconstruct an agent's exact context state at the moment of a specific decision is the difference between a defensible examination answer and a guess about what probably happened.

Zytra's risk atlas maps all four use-case categories to their actual applicable obligations — loan underwriting against EU AI Act Annex III(5)(b) and RBI's Fair Practices Code, fraud detection against authorization-scope and adversarial-evasion controls, KYC/AML against DPDP and PMLA, and customer service against the SEBI/IRDAI advice boundary — with evidence packs built for examination, not for a vendor pitch deck.