LLM Red Teaming for Banking in the UAE: Nine Harms, Five Gates, Open Tools

Because the dangerous prompt in a bank rarely looks like an attack. It looks like a customer. Polite. Plausible. Very plausible.

Take a look at the research. The RAHS paper (Dimino, Sarmah, Pasquali) says existing evaluations "rely on binary attack-success rates and domain-agnostic taxonomies," which leaves financial deployments "exposed to failures elicited through legally or professionally plausible framing." In that study, unlicensed or improper advice in legally plausible language was the most vulnerable category for every model tested. Every one.

A generic jailbreak list won't catch that. A keyword filter won't catch that. And a report full of screenshots with an "attack success rate" on top? I call it the Screenshot Report. Tons of evidence. Zero decisions. Pretty. Useless. WEAK!

Here's the deal. The bar is ALREADY written down. The CBUAE guidance note on AI and ML for licensed financial institutions was issued on 11 Feb 2026. It never says "red teaming." Not once. But it describes exactly what a red-teaming programme has to deliver:

• Stress testing and validation so AI does "not produce unsafe or unintended outputs" (§5d).
• Testing of automatic updates before implementation (§6c).
• Periodic challenge by independent third parties (§6b).
• "The clear and immediate ability, with human intervention, to cease use" of an AI system (§6f).
• Customer disclosures in Arabic and English (§4b), and a pointer to the rules on data retained in the country (§5c).

Arabic and English decide what you test. Data residency decides where the system runs. I covered the hosting side on my AI architect in Dubai page. This is my reading of the note, not legal advice.

Nine categories. Two are finance-specific. Seven map straight to the OWASP Top 10 for LLM Applications (2025). The categories are public. The test content stays internal. ALWAYS.

#	Harm category	OWASP LLM Top 10 (2025)
1	Financial-crime facilitation	(finance-specific)
2	Conduct and suitability breaches	(finance-specific)
3	Sensitive information disclosure	LLM02
4	System prompt leakage	LLM07
5	Prompt injection through content the system reads	LLM01
6	Retrieval-layer weaknesses	LLM08
7	Excessive agency	LLM06
8	Misinformation	LLM09
9	Unbounded consumption	LLM10

And you test the SYSTEM, not just the model. The system prompt. The retrieval corpus. The tools and agents. The guardrails. The channel. Once an agent can act, a bad answer becomes a bad action. Big difference.

Frankly, this is where most test plans fall apart. One prompt. One language. One pass. Party time.

These aren't my numbers. In the RAHS study, nine open-weight models up to 72B parameters were tested, and four extra turns of conversation eventually broke a median of 89% of the prompts that had SURVIVED single-turn testing. Worse, multi-turn pressure produced "not only more jailbreaks but more operationally severe disclosures." More severe. Not just more.

Language matters too. FinSafetyBench found models more susceptible in Chinese than in English. Same model, different language, different result. It didn't test Arabic. So here's my inference, and it's mine, not the paper's: test every language your customers use. In the UAE that means Arabic and English at minimum. Test English and assume Arabic? DISASTER!

By severity. Not by a binary score. A harmless slip and a customer-data leak are NOT the same event, so they can't get the same weight.

Two numbers from the research back this up. FinRedTeamBench, used in the RAHS study, has 989 prompts across seven banking, financial-services and insurance risk areas and 34 sub-categories. And in the FinRED study, a finance-specific, expert-written rubric cut critical false negatives from 28 to 12 compared with a generic rubric. From 28 to 12. HUGE!

Then five gates. Agree them with risk and compliance BEFORE the first run:

1. Critical findings: zero open at go-live.
2. High findings: each has a fix or a compensating control, and a named owner.
3. Coverage: every harm category × every language served × single-turn and multi-turn. With Arabic and English, that's 9 × 2 × 2 = 36 cells.
4. Kill switch: tested end to end, time to disable recorded.
5. Monitoring: production logging and alerting for the same categories.

Any gate red, the release waits. Plus an eight-item go-live checklist on top. Seven out of eight? Not done. No severity, no decision. Simple.

Anybody can write "we red-team our AI" on a website. Anybody. I'd rather hand you the tools. Everything below is public, dated and checkable.

What	Where	Date
LLM Red Teaming for Banking: A UAE Go-Live Checklist. The full method: CBUAE mapping, nine harm categories, severity scoring, five gates, six re-test triggers, the eight-item checklist	Hugging Face article	18 Oct 2026
LLM Red Teaming for Banking Severity Scorer. Free Gradio tool (Apache-2.0). Score findings, run the five gates, list missing evidence, export a markdown evidence pack. No attack prompts, no model calls, nothing stored	Hugging Face Space · Projects	18 Oct 2026
Turn Your LLM Red-Team Findings Into Code: An Open-Source Severity Scorer for Banking and a pytest CI Gate. The scorer's data model, the gate logic and a GitHub Actions workflow	Medium · dev.to copy	20 Oct 2026
llm-redteam-banking-checklist. Open-source go-live gate for LLM red teaming in banking: severity scorer, five gates, pytest + GitHub Actions. Apache-2.0	GitHub repository	21 Oct 2026

The rest of my articles, including sovereign GenAI and DIFC Regulation 10: Writing.

BTW, the scorer does NOT invent severity weights. The checklist says weight by severity but gives no numbers, so the tool asks you for yours. Set all four and it computes a score. Skip them and it tells you plainly the score wasn't computed. Honest. That's how it should be, imo.

Every finding becomes a record: harm category, severity, multi-turn yes or no, language, human-reviewed, fixed, compensating control, owner. Then evaluate() returns GO or NO-GO. It's a pure function, so you test it straight with pytest.

One open critical finding? The test fails. The build goes red. The release stops. Done. I ran the sample test against the live scorer.py on 20 Oct 2026, with synthetic findings: 2 passed. The full walkthrough, with the workflow file, is in the Medium article.

The scorer also flags missing evidence on every run. A critical or high finding nobody reviewed. Multi-turn marked "Not checked." A hole found in English and never tested in Arabic. A kill switch tested with no time to disable recorded. The test that isn't there is a finding too. Just as REAL.

Every time something material changes. A passing assessment is a snapshot. A snapshot is NOT a control. One run before launch, one PDF, never reopened? That's Red-Team Theater. SAD!

Six re-test triggers:

1. The model or its version (including provider-side automatic updates)
2. The system prompt
3. The retrieval corpus
4. Tools or agent permissions
5. Guardrail configuration
6. The languages served

In the scorer, any recorded change since the last run means NO-GO until you re-test. Wire that to change detection in CI, and a pull request that bumps the model version demands a re-test on its own.

Here's the short version. If an LLM system touches customers or bank data in the UAE, a demo is not evidence. Red-team it by severity before go-live, and again after every material change.

• Inventory the whole system, not just the model.
• Test nine harm categories, multi-turn, in Arabic and English.
• Score by severity, with a human on every high-severity finding.
• Agree five gates before the first run.
• Keep an evidence pack per release, and keep the test prompts access-controlled.

Start with the checklist. Score your findings in the Space. Put the gate in CI. Found a gap in the method or a bug in the scorer? Tell me. I'll fix it. Fast.

The architecture behind all of this: AI architect in Dubai.

What is LLM red teaming for banking?

Structured adversarial testing of an LLM-based banking system against finance-specific harms, such as financial-crime facilitation, mis-selling, customer-data disclosure and unauthorised actions. Findings are scored by severity and tied to go/no-go decisions, before go-live and after every material change.

Does the Central Bank of the UAE require LLM red teaming?

Not by name. The CBUAE guidance note issued on 11 February 2026 expects AI to be stress-tested and validated so it does not produce unsafe or unintended outputs, automatic updates to be tested before implementation, and periodic challenge by independent third parties. A finance-specific red-teaming programme is a practical way to meet those expectations. This is my reading, not legal advice.

Which languages should a UAE bank red-team in?

Every language its customers actually use, and Arabic and English at minimum, the two languages the CBUAE note names for customer disclosures. Research such as FinSafetyBench found the same models behaved differently by language, so English results do not cover Arabic.

How often should a bank re-run LLM red teaming?

Every time something material changes: the model or its version, the system prompt, the retrieval corpus, tools or agent permissions, guardrail configuration, or the languages served. A passing result is a snapshot, not a control.

Is the LLM Red Teaming for Banking Severity Scorer free?

Yes. It is free and Apache-2.0 licensed, on Hugging Face. It holds no attack prompts, calls no model and stores nothing you enter. It is an educational tool, not regulatory or legal advice.

1. Dimino, F., Sarmah, B., Pasquali, S. Risk-Adjusted Harm Scoring for Automated Red Teaming of LLMs in Financial Services. arXiv:2603.10807. https://arxiv.org/abs/2603.10807
2. Central Bank of the UAE. Guidance Note on the Consumer Protection and Responsible Adoption and Use of Artificial Intelligence and Machine Learning by Licensed Financial Institutions in the U.A.E., issued 11 Feb 2026. https://rulebook.centralbank.ae/en/rulebook/guidance-note-consumer-protection-and-responsible-adoption-and-use-artificial-intelligence
3. OWASP Gen AI Security Project. Top 10 for LLM Applications (2025). https://genai.owasp.org/llm-top-10/
4. Park, D.-Y., Kim, C., et al. FinRED: An Expert-Guided Benchmark Generation and Evaluation Framework for Financial LLM Red-Teaming. arXiv:2606.19887. https://arxiv.org/abs/2606.19887
5. Hou, Y., et al. FinSafetyBench: Evaluating LLM Safety in Real-World Financial Scenarios. Findings of ACL 2026. https://aclanthology.org/2026.findings-acl.694/