Home / Responsible AI
Built for regulated markets.
Our design principles, and how the design maps to RBI’s published rules and to US, UK and EU rules, line by line, for your risk and compliance teams to review.
Six design principles.
Consent before data
Accounts are linked only after the customer sees what is shared and why, approves, and can revoke.
A person holds the last key
Commitments always wait for the customer’s tap; staff decisions wait for a person’s approval.
Autonomy, set twice
The customer chooses a level; the bank sets a ceiling per segment and caps. The gate checks both when an action runs.
A record that can be replayed
Every turn, tool call and gate decision is recorded, so anyone reviewing can see why an action ran, waited or was refused.
Credentials kept from models
PINs and one-time codes stay out of AI models. Identifiers are masked, and money maths is done in code.
Your copy, your rules
A private copy per bank. Loosening a rule needs a one-time code, and every change is versioned and can be rolled back.
India: the rules, and how Tuvel’s design responds.
| Rule | What it asks, in short | How Tuvel’s design responds | Label |
|---|---|---|---|
| RBI FREE-AI FrameworkCommittee report, August 2025 | Seven guiding principles (Sutras) and recommendations for responsible AI in financial services, including board-approved AI policies, governance and an AI sandbox. | Every turn, tool call and gate decision is recorded for review. Autonomy is graded, with the customer and the bank each holding a key. The AI Governance and Inventory agent keeps the bank’s register of AI systems for its own governance. | Available now |
| RBI Authentication Directions, 2025RBI/2025-26/79, in force 1 April 2026 | Digital payments are authenticated by at least two distinct factors unless a listed exemption applies. | PINs and one-time codes stay out of AI models. A spoken or typed yes never confirms money; a tap bound to the exact amount and payee does. Levels 1 to 3 always confirm with that tap. At levels 4 and 5, known payments run without a tap only from the agent card, built around the framework below, and a bank can require a PIN on every card payment instead. | Available now |
| RBI E-mandate Framework, 2026RBI/DPSS/2026-27/396 | Registering a recurring mandate needs an additional factor. Debits carry a pre-debit notice, and the customer can opt out or withdraw. | Autopay at level 5 is on the roadmap, within the customer’s limit and the bank’s ceiling, set up under the mandate rules. | On the roadmap |
| RBI Master Directions on Prepaid Payment Instruments, 2021As updated | Limits for prepaid instruments: a full-KYC instrument’s balance may not exceed ₹2,00,000, and general funds transfers are capped at ₹10,000 a month. | The agent card’s limits sit inside these: ₹10,000 by default, never above ₹2,00,000, and payments to people capped at ₹10,000 a month, each with a tap. The card runs in Tuvel today and is issued on the bank’s own full-KYC prepaid programme in its pilot. | Available nowPer deployment |
| RBI Master Direction for NBFC Account AggregatorsNBFC-AA | Financial information is shared only with the customer’s explicit consent, through a consent artefact. | Linking runs through a consent journey modelled on Account Aggregator: what is shared, for what purpose, approve or revoke. Tuvel reads linked data only after consent. The AA connection is set up per deployment. | Available nowPer deployment |
| Digital Personal Data Protection Act, 2023, and DPDP Rules, 2025India | Notice and consent, limits on purpose, security safeguards, and rights to access, correct and erase personal data. | Personal identifiers are masked before text reaches a model. Uploaded documents are read on the server and the original is not stored. Tuvel deploys inside the bank’s private VPC in an Indian region of Google Cloud, AWS or Azure, and with an open-weight model hosted in India every AI model call stays inside India. | Available now |
United States, United Kingdom and EU: the rules, and how Tuvel’s design responds.
Each line is designed to support the rule, with the controls behind it. Your risk, model validation and compliance teams review it against your own policies in the pilot.
| Rule | What it asks, in short | How Tuvel’s design responds | Label |
|---|---|---|---|
| SR 11-7 and OCC Bulletin 2011-12United States: Federal Reserve and OCC model risk guidance | Model risk management: an inventory of models, sound development, validation before use, monitoring in use, and governance with clear roles. | Designed to support it. Every agent sits in one inventory with its role, level, model, tools and approvers. Agents move from sandbox to staging to live with automated checks before each step, and only a bank admin puts one live. The record and each agent’s results score show how it performs in use, a nightly check drops an agent a level when its work slips, and a kill switch pauses it at once. | Available now |
| NIST AI Risk Management FrameworkUnited States: AI RMF 1.0, with its Generative AI Profile | Four functions across an AI system’s life: Govern, Map, Measure and Manage its risks. | Designed to support it. Govern: the bank sets levels, approvers and maker-checker. Map: each agent’s role, tools and the data it may see are written down. Measure: a results score per agent, the share of its counted results that went well, and a nightly check of dismissed or edited approval cards, agent-caused errors, people’s ratings and outcomes rated poor. Manage: budgets, guardrails, a level down when those checks trip, and a kill switch. | Available now |
| ECOA and Regulation BUnited States: 12 CFR Part 1002 | No discrimination in any part of a credit transaction, and the specific principal reasons given when credit is denied. | Designed to support it. The credit decision is a person’s, approved on a card with its reason on the record. Agents apply the bank’s own credit policy first and cite the rule behind each point, so the reasons for a decision can be traced. | Available now |
| Regulation EUnited States: 12 CFR Part 1005, electronic fund transfers | Error resolution on deadlines, with provisional credit, and protection against unauthorised transfers. | Designed to support it. The Fraud and Disputes Case Orchestrator tracks each claim’s deadlines, and the investigation copilot builds the timeline and drafts the note. Crediting an account and deciding liability stay with people. In the advisor, each transfer is confirmed by a tap bound to the exact amount and payee. | Available now |
| UDAAPUnited States: Dodd-Frank Act, sections 1031 and 1036 | No unfair, deceptive or abusive acts or practices toward consumers. | Designed to support it. On the staff side, anything a customer sees is a person’s decision. The advisor does money maths in code, and commitments always wait for the customer’s tap. Every turn is on the record for conduct review, and the Collections Conduct QA agent reviews transcripts against the code of conduct. | Available now |
| UK Consumer DutyUnited Kingdom: FCA, PRIN 2A | Good outcomes for retail customers: products and services, price and value, consumer understanding and consumer support. | Designed to support it. The advisor explains in plain language, in the customer’s own language. The customer chooses how much it may do, inside the bank’s ceiling and caps. Every turn is on the record, so the bank can review outcomes customer by customer. | Available now |
| PRA SS1/23United Kingdom: model risk management principles for banks | Five principles: model identification and classification, governance, development and use, independent validation, and risk mitigants. | Designed to support it. Each agent is identified in the inventory and classed by its level and the tools it holds. The bank names approvers and runs maker-checker on changes. Checks run before each step to live, the record supports the bank’s own validation, and budgets, guardrails and a kill switch act as mitigants. | Available now |
| EU AI ActEuropean Union: Regulation (EU) 2024/1689 | Duties by risk tier. Credit scoring of individuals is high-risk: risk management, logging, transparency, human oversight, accuracy and robustness. | Designed to support it. Credit decisions stay with people, approved on a card; agents prepare and propose. Every turn, tool call and decision is logged, and calls to bank systems sit in a tamper-evident trail. Oversight runs through levels, approvals and a kill switch, and the AI Governance and Inventory agent keeps the bank’s register of AI systems. | Available now |
A framework for agent-initiated payments.
For small, known, repeat payments, four controls that together could stand in for a per-payment second factor. We discuss it with banks and policy bodies.
An agent-bound instrument
Payments the advisor makes come from a prepaid instrument bound to the agent: loaded by the customer, never drawn from savings, frozen in one tap.
Graded autonomy as the risk control
The customer’s level, the bank’s ceiling per segment and caps per payment and per day stand in for a per-payment second factor, only for small, known, repeat payments.
Action-bound consent
Consent attaches to one action: an exact amount to an exact payee. New payees, people and commitments always return to the customer.
A replayable record
Every turn, tool call and gate decision is recorded, so the bank, an auditor or a regulator can replay why each payment happened.
Discuss the framework with us.
Banks, risk teams and policy bodies are welcome.
Or write to demo@tuvel.co.