Home / Security & trust
Security your team can check, control by control.
Certifications, the rules our controls are designed to support, and each control with its label. Questions: support@tuvel.co.
Certifications.
Held by Nagent for the platform Tuvel is built on. The ISO/IEC 27001:2022 certificate opens from its badge, and your security team can ask us for the SOC 2 Type II report.
Mapped to the rules you work under.
One set of controls, mapped line by line to RBI’s rules in India and to US, UK and EU rules, each designed to support the rule, for your risk and compliance teams to review.
India: RBI and the DPDP Act
FREE-AI, the Authentication Directions, e-mandates, prepaid instruments, Account Aggregator and the DPDP Act.
The map, line by lineUnited States, United Kingdom and EU
SR 11-7 and OCC 2011-12, the NIST AI RMF, ECOA and Regulation B, Regulation E, UDAAP, the UK Consumer Duty, PRA SS1/23 and the EU AI Act.
The map, line by line
The controls behind both maps.
| Control | What it does | Rules it is designed to support |
|---|---|---|
| An inventory of every agent | Role, desk, level, model, tools and approvers for each agent, in one place. | SR 11-7, SS1/23, EU AI Act, RBI FREE-AI |
| Levels per agent | Every action above an agent’s level waits for a person, and a person decides each step up. | SR 11-7, NIST AI RMF, EU AI Act |
| Checks before go-live | Sandbox, staging, live, with automated checks before each step. Only a bank admin puts an agent live. | SR 11-7, SS1/23, NIST AI RMF |
| The record | Every turn, tool call and decision, and a hash-chained trail of calls to bank systems. | EU AI Act, Reg E, UDAAP, Consumer Duty, RBI FREE-AI |
| A kill switch | Pause any agent in one click from the control plane, and its next action is refused; resume switches it back on. | SR 11-7, NIST AI RMF, EU AI Act |
| Maker-checker | Two-person approval for changes to connections and rules. | SR 11-7, SS1/23 |
| Your rules first | The bank’s own rulebook applies first, with the regulation as the floor, and each file cites the rule it used. | ECOA and Reg B, Consumer Duty, RBI rules |
Each line carries one of two labels.
- Available now
- In the product today.
- On the roadmap
- Being built.
Money actions
What has to be true before money moves.
Two keys on every money action
The customer’s level, the bank’s ceiling for that customer’s segment, and caps per payment and per day are all checked when an action runs, not only in what the advisor says.
Available nowNothing runs alone until the bank sets its rules
Until a bank saves its rules, every action waits for the customer’s tap, whatever level the customer picks.
Available nowCommitments always wait for a tap
Credit applications, balance transfers, redemptions, lump-sum investments, loan prepayment, any payment to a person and any new merchant wait for the customer, at every level.
Available nowOnly a tap confirms money
Voice and chat can ask for an action. Only a tap on the confirmation card confirms it.
Available nowConfirmation bound to amount and payee
A tap confirms one exact amount to one exact payee, and nothing else.
Available nowMoney maths in code
Totals, limits and other money calculations are done in code. The language model explains the numbers.
Available nowLoosening a rule needs a code
In the bank’s console, raising a ceiling or a limit waits for a one-time code sent to the admin. Tightening takes effect at once. Every change is versioned and can be rolled back.
Available nowKnown payments from the agent card, levels 4 and 5
Known bills and merchants are paid from the agent card without a tap, within both keys, and the customer is told which rule allowed it. A bank can require a PIN on every card payment instead.
Available nowAutopay and monthly investing, level 5
Set up within both keys, then the customer is told.
On the roadmap
Customer data
What reaches an AI model.
PINs and one-time codes stay out of the model
They are handled outside the conversation and are never sent to a language model.
Available nowPersonal identifiers masked
Identifiers Tuvel holds are masked before any text reaches a model.
Available nowConsent before linking
Accounts are linked through a consent journey modelled on Account Aggregator: what is shared, for what purpose, approve and revoke. Tuvel reads linked data only after consent.
Available nowDocuments read, not kept
An uploaded document is read on the server; the original file is not stored.
Available nowAgents see only what they were granted
Each agent sees only the customer details and tools it was granted.
Available nowCard numbers stay in your card systems
Card numbers are held in the bank’s own card platform, which carries its PCI DSS scope. Tuvel works alongside it, so card data sits outside Tuvel’s scope today.
Available now
Infrastructure
Where Tuvel runs and how its parts talk.
A private copy per bank
Each bank gets its own copy of Tuvel, with its own database.
Available nowYour cloud: GCP, AWS or Azure
Tuvel deploys inside the bank’s private VPC on Google Cloud, AWS or Azure, in the region the bank chooses.
Available nowSigned internal service calls
Tuvel’s services call each other with signed requests.
Available nowInternal-only services
Back-end services are reachable only from inside the deployment.
Available nowFixed outbound IP address
Calls leave from one fixed IP address a bank can allowlist.
Available nowYour choice of region
The bank picks the region, in India or anywhere else, and Tuvel and its data stay there.
Available nowAI model calls inside India
With an open-weight model hosted in India, every AI model call stays inside India.
Available nowSingle sign-on and multi-factor sign-in
Staff sign in through the bank’s identity provider, with multi-factor authentication, passkeys and recovery codes.
Available nowMutual TLS to bank systems
Calls to a bank’s APIs over mutual TLS, each request signed.
Available now
The record
What a bank can look back on.
Every turn on the record
Every turn, every tool call and every gate decision is recorded.
Available nowChecks before an agent goes live
Agents move from sandbox to staging to live, with automated checks before each step. Only a bank admin puts one live.
Available nowA tamper-evident log
Every call to a bank system is recorded in a trail where each entry is chained to the one before it by hash.
Available nowMaker-checker and your SIEM
Two-person approval for changes to connections and rules, and a signed export of calls to bank systems for the bank’s security monitoring.
Available nowAn independent adversarial evaluation
An outside test against MITRE ATLAS, the public knowledge base of attacks on AI systems.
On the roadmap
Questions.
How does Tuvel map to US, UK and EU rules?
Line by line, on our Responsible AI page: SR 11-7 and OCC 2011-12, the NIST AI RMF, ECOA and Regulation B, Regulation E, UDAAP, the UK Consumer Duty, the PRA’s SS1/23 and the EU AI Act, each designed to support the rule, with the controls behind it. Your risk and compliance teams review the map in the pilot.
Which controls support model risk management?
An inventory of every agent with its role, level, model, tools and approvers; checks before each agent goes live; levels and limits per agent; the record, each agent’s results score and a nightly level check for monitoring in use; maker-checker on changes to connections and rules; and a kill switch.
How is card data handled?
Card numbers stay in the bank’s own card platform, which carries its PCI DSS scope. Tuvel works alongside it, so card data sits outside Tuvel’s scope today. Card dispute agents work from the case the bank opens.
Can our security team test the controls?
Yes. In a walkthrough we go through each control, show the record for a session and answer your checklist line by line. In a pilot, your team tests them in your bank’s own private copy.
Test these controls with your security team.
We walk through each control, show the record for a session, and answer your checklist line by line.
Or write to demo@tuvel.co.