At the Global FinTech Fest (GFF) 2026, SBI Chairman C.S. Setty drew attention to a governance gap that has been quietly widening across Indian banking and FinTech: as AI agents gain the ability to contact customers, initiate payments, modify loan accounts, and execute trades — who is accountable for what the agent does, and how do you stop it when something goes wrong?
Setty specifically highlighted six controls: agent identity, authentication, consent, transaction limits, audit trails, and revocation. The framing was deliberate. The industry already has KYC — Know Your Customer. The next framework is KYA: Know Your Agent.
"The question is not whether AI agents will operate in banking. They already do. The question is whether we have the governance architecture to operate them responsibly — and right now, most institutions do not." — GFF 2026
This article breaks down each of the six KYA controls, explains why they matter under India's existing regulatory framework, and describes what a compliant AI agent build looks like in practice.
Why "Know Your Agent" Is Not Optional
AI agents in banking are not hypothetical. Today, they are making outbound calls to borrowers, generating credit memos, triaging customer complaints, checking documents for LC presentations, and routing payment exceptions. In many deployments, the institution's staff does not review individual agent actions — they review the agent's outputs and escalations.
This creates three regulatory exposures that India's existing frameworks already address, even without a dedicated AI agent regulation:
| Regulatory Framework | What It Requires from AI Agents | Risk if Missing |
|---|---|---|
| RBI Digital Lending Guidelines 2022 | All automated credit decisions must be explainable and auditable. Borrower must be informed of automated processing. | High — RBI audit finding, potential licence action |
| DPDP Act 2023 | Explicit consent before automated processing of personal data. Right to know when a decision is automated. | High — DPDP Board fine up to ₹250Cr |
| RBI Fair Practices Code (Collections) | All collection contact must be within authorised hours, by authorised personnel, with full audit trail. | High — Collections agent calling outside hours is an FPC violation regardless of whether it is AI or human |
| SEBI Algo Trading Circular 2024 | Automated financial actions must have pre-approved order limits, audit trails, and kill-switch mechanisms. | Medium — Applies to any agent that places or modifies financial transactions |
The Six KYA Controls
These are not aspirational governance principles — they are engineering requirements that must be built into the agent at the infrastructure level, not in the LLM prompt.
Agent Identity
Every agent instance must have a unique, verifiable identifier (Agent ID) that is recorded in every action it takes. This is not the same as the model name or version — it is the specific deployed instance. When something goes wrong, the audit log must show which agent instance acted, not just that "the AI did it."
Authentication
The agent must authenticate to every system it calls — the CRM, LMS, telephony API, core banking — using a signed credential (mTLS certificate or short-lived JWT), not a shared service account password. A compromised shared credential gives unlimited access. A per-agent token can be revoked in isolation.
Consent & Scope
The agent must be issued a defined capability scope at deployment — specifying exactly what it can read, what it can notify, and what it can execute. This scope must be tied to prior consent from the customer (for agents acting on their behalf) or the institution's compliance-approved policy. Scope must be enforced at the infrastructure layer — not left to the LLM to respect.
Transaction Limits
Hard limits on what the agent can execute autonomously: maximum payment amount, maximum number of collection calls per day, maximum accounts it can modify in a single session. These must be enforced as infrastructure-level constraints — a hard check before execution, not a prompt instruction that can be bypassed by prompt injection or model drift.
Immutable Audit Trail
Every action taken by the agent — every API call, every message sent, every decision made — must be written to an append-only, tamper-evident store. The audit trail must include: Agent ID, timestamp, action type, parameters (what the agent did), the reasoning or rule that triggered the action, and the outcome. AWS S3 Object Lock or equivalent is the standard implementation.
Revocation
A single API call (or button in an admin console) must be able to immediately stop all active sessions for a given agent instance, a given customer's agents, or all agents of a given type. This is the kill switch — and it must work in under 30 seconds, not require a code deployment or infrastructure restart.
The Difference Between Prompt-Level and Infrastructure-Level Controls
The most common mistake in AI agent governance is building controls at the prompt level: "You are an AI assistant. You must not initiate payments above ₹50,000 without human approval." This instruction can be overridden — by a jailbreak, by model drift after fine-tuning, by a sufficiently creative user prompt, or simply by the model misinterpreting an edge case.
KYA controls must be enforced at the infrastructure layer — in the code that executes the agent's actions, not in the text that instructs the agent to behave. The distinction:
- Prompt-level (not sufficient for compliance): "Do not call customers before 8am." A prompt instruction. Can drift. Cannot be audited as a hard guarantee.
- Infrastructure-level (compliant): The telephony API call is wrapped in a function that checks the current time against RBI Fair Practices Code calling hours before dialling. If the check fails, the call is blocked at the code level and the failure is logged. The agent cannot bypass this regardless of what its reasoning says.
This distinction matters especially for RBI audit purposes. An auditor asking "how do you ensure your collections AI does not call outside permitted hours?" needs a code-level answer, not a prompt-level one.
What Changes When Agents Can Act on Behalf of Customers
The governance challenge doubles when the agent acts on behalf of a customer rather than on behalf of the institution. An AI agent that a borrower authorises to negotiate a settlement, update an address, or request a foreclosure quote is acting as an attorney-in-fact — and India's IT Act, Contract Act, and DPDP Act all have something to say about how that authorisation is captured, stored, and revoked.
The practical requirements: the customer must have given explicit, informed consent before the agent acts. That consent must be time-limited (not a blanket "the AI can always act for me"). The customer must be able to revoke it without needing to contact the institution's call centre. And every action the agent took under that consent must be retrievable by the customer on request — this is a DPDP data access right.
How XPndAI Builds KYA Controls into FinTech AI Agents
Every AI agent XPndAI builds for banking and FinTech clients includes the six KYA controls as standard engineering requirements, not optional add-ons. The audit trail is append-only from day one. The capability scope is defined in a configuration file that compliance can review without reading code. The revocation endpoint is documented in the handover documentation with response time tested during UAT.
The reason these controls exist as standard in XPndAI's builds: the clients who deploy these agents — NBFCs, digital lenders, banks — will face RBI audits. An audit finding about an uncontrolled AI agent is an existential business risk, not a technical checkbox. Building the controls in during development is orders of magnitude cheaper than retrofitting them after a regulatory incident.
If you are building or procuring an AI agent for a banking or FinTech use case, ask your development partner six questions: How is the agent identified in logs? How does it authenticate to your systems? How is its scope enforced at the code level (not the prompt level)? What are its transaction limits and where are they enforced? Where is the audit trail stored and how long is it retained? How do you stop it in under 30 seconds?
If the answers are vague — you have a governance gap.
Frequently Asked Questions
What is "Know Your Agent" in banking AI?
"Know Your Agent" (KYA) is the emerging governance framework for AI agents operating within banking and financial services. Just as KYC governs who can open an account, KYA governs which AI agents can operate, what they can access, and what they can do. The six KYA controls are: agent identity, authentication, consent and scope, transaction limits, audit trails, and revocation.
Is RBI likely to regulate AI agents in banking?
Regulatory signal is already present. RBI's Digital Lending Guidelines (2022) require automated credit decisions to be explainable and auditable. The DPDP Act (2023) requires consent before automated processing of personal data. The RBI Fair Practices Code requires collections contact to be auditable and within authorised hours. An AI agent operating in any of these domains is already subject to these frameworks — formal AI-specific guidance will follow the pattern set by the Bank of England, EBA, and MAS.
How does XPndAI build agent governance controls?
Every production FinTech AI agent XPndAI builds includes: unique Agent ID in every log entry, mTLS or JWT authentication to each connected system, infrastructure-enforced capability scope (not prompt-level), hard-coded transaction limits at the code layer, append-only audit log with full action trail, and a revocation endpoint tested during UAT. These are standard build requirements, not optional add-ons.