Monday, 9.40 a.m.
The scene that follows is illustrative. It describes no particular bank or customer.
A customer opens her banking app and finds a card payment she does not recognise, made on Saturday night. She writes to the bank in the app: she did not make it, she still has the card, please reverse it. She adds her card number and her income-tax PAN, because she thinks it will help.
In the disputes team, forty such messages arrived over the weekend. Each needs the same file: the transaction as the bank recorded it, the alert the bank sent and when, when the customer reported it, what she has said before, and what the bank's own policy says about cases like hers. Each ends in a decision a person must be able to defend, perhaps to an ombudsman, perhaps a year from now.
The file is clerical. The decision is not. The trouble starts when the two are done by the same tired person at the end of a queue.
One dispute, six steps
Each step names the part of the platform that does the work.
1 · The message comes in through one door
At the Agent Universal Gateway, every request is authenticated, scoped and checked against the bank's policies before it reaches a model or tool. The designated fields the platform detects, here the card number and the PAN, are masked before any model sees them, and the same call is inspected for prompt injection.
2 · Agents assemble the file, as services with contracts
The Orchestrator runs an intake agent, an evidence agent and a recommendation agent. Each declares what it accepts and what it emits, and the handoffs between them are typed and validated at run time. Adapters reach the systems the bank already runs, such as core banking and the CRM.
3 · The recommendation is drafted from the bank's own policy
A model the bank has approved reads the file and the bank's policies and circulars and drafts a recommendation, with citations to the source. Talk to us about Kuber, our model family for banking, financial services and insurance, grounded in your own policies and circulars.
4 · Policy outside the model says what may happen
Policy enforced outside the model at the Gateway blocks actions that must never happen, regardless of what the model recommends. Which actions those are is the bank's to write. Two examples of what a bank might write: no agent closes a dispute against the customer, and any credit waits for approval.
5 · A named officer decides
The flow stops at a checkpoint with an explicit queue, a named approver group, escalation rules and an SLA timer. The officer approves or rejects, and the approval state lives in the run record.
6 · The action is taken once, and the record is closed
Every step has an idempotency key, so a re-run does not double-charge, double-write or double-message. The mask and the approval each write a signed Trust Receipt; the action itself is in the run record.
Who built this, and who owns it
It runs inside the bank's perimeter: your cloud, your jurisdiction, your keys, region-pinned or air-gapped. Models and agents execute on your infrastructure; your data does not go to an external API.
The people who own the process
The disputes flow is designed in Flow Studio by the operations team that owns it: the steps, the branch logic and the human checkpoints.
Every save is a draft version in the Registry. Production is reached only through approval.
A change surfaces as a diff to the named owner and stays unreachable from production until the owner approves.
The people who wire it in
Engineers work in Agent Lab on the same artifact: the adapters, structured prompts, golden tests and contract checks.
They can mock the model and the tools, replay production traces and run the suite in CI, where failures block the merge.
Neither surface is a downgrade of the other. Both edit one versioned flow.
When something fails half-way
A core-banking call times out between the approval and the credit. This is the ordinary bad day, and it is where a hand-built integration credits twice or not at all.
Workflow state survives restarts and deployments, and long-running workflows checkpoint after every consequential step. Every step declares its retry policy, its fallback step, its escalation path and its SLA. When something fails, the failure is a typed event in the run record, not a line lost in a log. A workflow that breaches its SLA is routed to a handler the bank configures: page on-call, queue for review, or mark as degraded.
A run is a record you can replay, not a process you lost.
Six months later
The customer is not satisfied and escalates. Someone inside the bank, and perhaps someone outside it, now asks what happened that Monday.
What the record holds. Every mask, every block, every approval and every deployment writes a Trust Receipt: who, what, which model, which policy, when. Receipts are signed, versioned and chained to the one before; change one character and every receipt after it fails verification. They export as JSON and PDF.
What it is tied to. The Registry ties the receipts to the artifacts: which version of the flow ran, with which prompt, against which model, approved by whom. An artifact can be retired, but it cannot be deleted from production history, so the bank can see what was running on a given day even if it has since been replaced.
Who can check it. The audit trail is queryable and exportable, and designed for an external party to verify without trusting us. Governance describes the model behind it.
What it does not hold. A value the platform did not detect leaves no masking receipt. The record shows what the system did and who approved; it does not show that the decision was right.
Which rules apply, and where the platform helps
One row per text, as read on 7 and 8 October 2026. The table covers outsourcing, cybersecurity, the Reserve Bank's AI report, data protection, card data and, if applicable, one European regulation. It does not cover the Reserve Bank's rules on customer liability in a disputed transaction or on ombudsman review; read those with your own compliance function.
| The rule | Who the text addresses | What it asks for | Where the platform helps | What it does not cover |
|---|---|---|---|---|
| The rule: Reserve Bank of India (Commercial Banks – Managing Risks in Outsourcing) Directions, 2025, paragraphs 9, 24 and 27 1 | Commercial banks. | The bank stays responsible for an outsourced activity. A provider's access to customer information is on a need-to-know basis. The bank's information is isolated. | The platform runs inside the bank's own perimeter, so the question of what a model's operator receives is narrower, and the designated fields it detects are masked before any model call. | The outsourcing agreement, due diligence, and the bank's right to audit. |
| The rule: Reserve Bank of India (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, paragraph 51 2 | Commercial banks. | Measures against data leakage. | Masking at the point of the call, and a record of each mask. | The rest of the framework, and data that was not detected. |
| The rule: Report of the Reserve Bank's committee on a Framework for Responsible and Ethical Enablement of AI (FREE-AI), August 2025 3 | Regulated entities, as recommendations. It is a committee's report, not a direction. | Among other things: a board-approved AI policy; a comprehensive internal AI inventory, updated at least half-yearly and available for supervisory inspection and audit (Recommendation 23); and a risk-based AI audit framework (Recommendation 24). | The Registry is an inventory with a named owner for every agent, flow, prompt, model and policy. Receipts and the run record are material for an audit. Our plain-English guide covers the report. | Your board's policy, your risk categorisation and your own audit. |
| The rule: Digital Personal Data Protection Act, 2023, section 8, and DPDP Rules, 2025, Rule 6 4 | The bank as data fiduciary. These provisions come into force in May 2027. | Responsibility for processing done on its behalf, and reasonable security safeguards. Rule 6 lists masking and virtual tokens among its examples. | It is one of the safeguards the rule names, with a record to show for it. | Notice, consent, retention, rights and breach reporting. |
| The rule: Card data: Reserve Bank circulars of 7 September 2021 and 28 July 2022 5; PCI DSS 6 | Entities in the card payment chain. PCI DSS is a contractual standard. | No entity in the chain other than card issuers and networks stores actual card data; the last four digits may be kept. A card number is masked when displayed. | A card number the platform detects in a message is masked before the call, keeping the last four digits. | A card number it does not detect. Your own storage. PCI DSS scope, which is for your assessor. |
| The rule: If applicable: EU Digital Operational Resilience Act, Articles 28(1)(a) and 30(2) 7 | Financial entities in the European Union. | The financial entity remains fully responsible, and its ICT contracts state where data is processed and how it is protected. | The platform runs where you deploy it. | The contract. |
This table states what the texts say and where one platform helps. It is not legal advice.
What it does not do
It does not decide the dispute. The agents assemble and recommend. An officer of the bank decides, and is named in the record.
It does not make the recommendation correct. The platform makes an agent accountable, which is what lets you find out whether it was correct.
It does not catch everything. A field the policy did not designate, or a value that was not detected, reaches the model as written. No guardrail catches every manipulated input.
It does not replace your core systems. Adapters reach what you have.
It does not turn governance off to go faster. There is no governance-off mode, because the runtime does not have one.
It is not a certification of your deployment. ShepHertz operates a control environment credentialed for SOC 2, ISO 27001, HIPAA and GDPR. These are advisory alignments to inform your own assessment, not certifications of your deployment or binding regulatory claims.
More on the same floor: AI agents for banking, customer data and AI in Indian banking, orchestrating AI agents and the agent registry.
Frequently asked questions
Can an AI agent resolve a banking dispute on its own?
On this platform, no. Agents gather the file and draft a recommendation. Consequential actions wait for a named human approver at a checkpoint in the flow, and policy outside the model blocks actions that must never happen, whatever the model recommends.
What stops an agent from crediting a customer twice when a system times out?
Every step has an idempotency key. The runtime guarantees at-least-once execution and the step contract guarantees exactly-once observable effect, so a re-run does not double-charge, double-write or double-message.
How does a bank show an auditor what an AI agent did on one case?
Each mask, block, approval and deployment writes a signed, chained Trust Receipt, and the Registry ties the receipts to the version of the flow, the prompt and the model that ran and to who approved them. The trail is queryable and exportable, and designed for an external party to verify.
Does customer data leave the bank?
The platform runs inside your perimeter, on your cloud, in your jurisdiction and under your keys, region-pinned or air-gapped. Models and agents execute on your infrastructure.
Who designs the dispute workflow: operations or engineering?
Both, on one artifact. Operations designs the flow and its checkpoints in Flow Studio; engineers add adapters, prompts and tests in Agent Lab. Every change is a draft in the Registry and reaches production only through approval.
Do we have to replace our core banking system?
No. Adapters connect agents to the systems you already run, such as core banking, CRM, ticketing and document stores.
Sources
The texts as read on 7 and 8 October 2026.
- 1Reserve Bank of India: Reserve Bank of India (Commercial Banks – Managing Risks in Outsourcing) Directions, 2025, RBI/DOR/2025-26/171, 28 November 2025.
- 2Reserve Bank of India: Reserve Bank of India (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, RBI/DoS/2026-27/410, 31 July 2026.
- 3Reserve Bank of India: Report of the Committee to develop a Framework for Responsible and Ethical Enablement of Artificial Intelligence (FREE-AI) in the Financial Sector, 13 August 2025; Recommendations 23 and 24.
- 4Parliament of India: Digital Personal Data Protection Act, 2023, section 8, and Ministry of Electronics and Information Technology: Digital Personal Data Protection Rules, 2025, G.S.R. 846(E), November 2025; Rules 1 and 6.
- 5Reserve Bank of India: Tokenisation – Card Transactions: Permitting Card-on-File Tokenisation (CoFT) Services, RBI/2021-22/96, 7 September 2021, and Restriction on Storage of Actual Card Data, RBI/2022-23/95, 28 July 2022.
- 6PCI Security Standards Council: PCI DSS v4.0 Self-Assessment Questionnaire D for Merchants, April 2022, which reproduces Requirements 3.3.1 and 3.4.1.
- 7European Union: Regulation (EU) 2022/2554, Digital Operational Resilience Act, applicable from 17 January 2025; Articles 28(1)(a) and 30(2).
Written by
AgentAnywhere Research
The team that builds the platform and the models
AgentAnywhere Research writes about the platform, the model families and the trust layer we build and run in India. Where a figure is ours, it says what it covers; where something is a demonstration, it says so.
