The question every risk committee asks, and the answer that's been missing
Every bank risk committee evaluating generative AI eventually asks the same question: how do we know our AI is safe enough to put in front of customers? Until now, most institutions have had no precise way to answer it — they've relied on vendor assurances, generic safety benchmarks built for open-domain chat, or nothing at all. FinProof is our attempt to close that gap with an open, reproducible adversarial benchmark built specifically for banking and financial services: 5,389 prompts across seven BFSI attack categories and three deployment registers.
So what: if your current AI safety sign-off process relies on a vendor's own marketing claims rather than a benchmark you can inspect, you don't have an evaluation process — you have a trust exercise. That's a gap worth closing before your next model goes into production, not after an incident.
Generic safety benchmarks miss the failure modes that actually matter in banking
Open-domain safety benchmarks measure whether a model refuses obviously toxic content. A banking assistant fails in subtler, costlier ways that those benchmarks never test for: giving unlicensed investment advice, being talked through a KYC bypass, fabricating a regulatory disclosure, or leaking one customer's data to another.
The inverse failure matters just as much. A guardrail that blocks a legitimate customer asking "what's my loan balance" destroys the product experience and gets quietly disabled by the first product manager who notices the complaint volume. A benchmark that measures attack detection without measuring false positives rewards models that are unusable the moment they touch real traffic.
So what: when you evaluate any AI safety model — ours or a competitor's — demand both numbers together: attack recall and false-positive rate on realistic traffic. Either one alone tells you almost nothing about production readiness.
What's actually inside FinProof
FinProof v1 organises adversarial coverage across seven categories specific to financial services: investment advice, KYC bypass, regulatory misrepresentation, document hallucination, data rights, transaction integrity, and account bypass. Each prompt targets one of three deployment registers — professional compliance, retail customer mobile, and relationship-manager internal — because the same attack phrasing reads very differently depending on which channel it arrives through.
The benchmark is tiered by design: Tier 1 is public and includes the evaluation harness plus 782 benign examples for calibrating false-positive rate; Tier 2, available behind an email gate, adds 1,606 direct-difficulty attacks; Tier 3 is a research tier of 2,036 medium-difficulty attacks generated through a quantum-augmented sampling process intended to broaden phrasing diversity beyond what static datasets capture; Tier 4 — 1,747 hard attacks — is withheld entirely and evaluated only by Zytra, specifically so no model can be trained against the official test set.
So what: if you're comparing safety models on a leaderboard, check whether the score came from a tier the vendor could have trained on. A benchmark whose hard tier isn't withheld from model developers isn't measuring generalisation — it's measuring memorisation.
Why we generate part of the benchmark rather than only curating it
Static attack datasets get memorised by models that are fine-tuned against them, which quietly inflates benchmark scores without improving real-world robustness. We built a quantum-augmented generation process specifically to widen the long tail of attack phrasing in the medium-difficulty tier, so the benchmark stays harder to overfit than a fixed, published list of known jailbreaks.
Open by default, honest by design
Tiers 1 and 2, along with the full attack taxonomy, are available now on Hugging Face for self-evaluation. Tier 4 stays withheld, and official leaderboard scores come only from Zytra's own evaluation runs — a deliberate constraint that keeps the leaderboard meaningful rather than a race to overfit a public test set.
A four-point action checklist before your next AI safety sign-off
- Run any safety model you're evaluating against FinProof's public Tier 1/2 set, and ask the vendor for their performance on both attack categories and the benign false-positive set — not just one.
- Treat any vendor-reported benchmark score with an unclear or non-withheld test set as unverified until you reproduce it independently.
- Require false-positive rate on in-domain BFSI traffic as a hard gate before any safety model goes into production, not a secondary metric.
- If you're submitting your own model for official evaluation, budget time for the Tier 4 withheld-set review — that's the number your risk committee should actually care about.