Knowledge 09 — Banking Domain, Security & Responsible AI

Goal of this module. JD4 demands "prior experience implementing AI solutions in Banking or Financial Services." This is the module that turns a competent Azure AI engineer into a banking AI engineer — the domain vocabulary, the regulatory frame, the security posture, and the Responsible-AI discipline that every interviewer in financial services uses to separate "built a chatbot" from "I can be trusted with customer money and a regulator." It is the differentiator — most candidates can wire Azure OpenAI; few can answer "is this safe for a bank?" credibly.

Table of Contents

• 1. Why banking is different
• 2. The banking use-case map (speak the domain)
• 3. The vocabulary you must use correctly
• 4. The regulatory frame
• 5. Model risk management (SR 11-7 thinking)
• 6. Data: residency, privacy, PII/PCI, minimization
• 7. Security posture (defense in depth)
• 8. Responsible AI: fairness, transparency, human oversight
• 9. The five hard banking questions (and how to answer)
• 10. The GCC/UAE context
• 11. Common misconceptions
• 12. Interview Q&A
• 13. References

1. Why banking is different

In a consumer app, a wrong answer is annoying. In a bank, a wrong answer can:

• move money to the wrong place (a hallucinated IBAN, a mis-executed transfer),
• break a law (give unlicensed investment advice, mishandle PII, enable money laundering),
• leak another customer's data (a retrieval that wasn't access-trimmed),
• trigger a regulatory finding or fine, and reputational damage that outlasts any feature.

So banking AI is governed by a single overriding principle: the system must be safe, controllable, explainable, and auditable, even at the cost of capability. Every technical decision in this track — grounding over recall, tool calls over model memory, human-in-the-loop, eval gates, least-privilege, audit logging — is downstream of this principle. When you answer any JD4 question, append the relevant safeguard. That reflex is what "banking experience" sounds like.

2. The banking use-case map (speak the domain)

You should be able to discuss each fluently:

Pattern across all of them: the LLM assists and drafts; decisions and money-movement stay governed by deterministic rules, systems of record, and human oversight. "AI-assisted, human/rule-governed" is the safe framing.

3. The vocabulary you must use correctly

Using these naturally signals real domain exposure:

• KYC (Know Your Customer), CDD/EDD (Customer/Enhanced Due Diligence), AML (Anti-Money-Laundering), CFT (Counter-Financing of Terrorism), SAR/STR (Suspicious Activity/Transaction Report), PEP (Politically Exposed Person), sanctions screening.
• Core banking system (the system of record for accounts/balances — Finacle, Temenos T24, Flexcube, etc.), ledger, settlement/clearing, reconciliation.
• IBAN (International Bank Account Number, mod-97 checksummed), SWIFT/BIC, ISO 20022 (the payments messaging standard), MICR (cheque line), MT/MX messages.
• Trade finance: LC (Letter of Credit), bill of lading, KYC on counterparties.
• Regulators: central bank (e.g. CBUAE — Central Bank of the UAE), and globally FATF (sets AML standards), Basel (capital), PCI DSS (card data), GDPR/local data-protection law.
• Model risk: SR 11-7, model validation, EU AI Act, NIST AI RMF.
• Channels: branch, ATM, IVR, mobile, internet banking, WhatsApp/Teams.

You don't need to be a banker — you need to not sound naïve. Knowing that balances live in the core banking system (so you fetch them with a tool, never let the LLM recall them) is the single most important domain fact for this role.

4. The regulatory frame

You won't be the compliance officer, but you must design for compliance:

• Data protection — GDPR (EU) / local laws (UAE PDPL, DIFC/ADGM regimes): lawful basis, data minimization, subject rights, breach notification, cross-border transfer rules.
• Bank secrecy / confidentiality — customer data is strictly access-controlled; cross-customer leakage is a serious breach (→ security-trimmed retrieval, least-privilege).
• AML/CFT (FATF-aligned) — monitoring, screening, SAR filing; AI may assist but humans decide and the bank remains accountable.
• Consumer protection / fair treatment — no misleading info; clear disclosures; no unlicensed advice.
• PCI DSS — if card data (PAN) is involved, strict handling/segmentation; usually you avoid putting PAN near the LLM at all.
• EU AI Act — risk-tiers AI systems; credit-scoring and some financial uses can be high-risk, triggering documentation, human oversight, transparency, and monitoring obligations. Know that "high-risk AI" is a defined category.
• Auditability/record-keeping — regulators can demand the full reasoning and data behind a decision; your audit trail must deliver it.

The interview-ready framing: "I design assuming a regulator will later ask 'why did the system do this, what data did it use, who approved it, and can you prove it' — so grounding, access control, human oversight, and immutable audit are built in from day one."

5. Model risk management (SR 11-7 thinking)

SR 11-7 is the US Federal Reserve's Guidance on Model Risk Management — the canonical framework, influential worldwide. Even outside the US, banks apply its thinking. Core ideas you should invoke:

• A model is any quantitative method that produces an output used in decisions — LLMs/RAG/agents qualify. They carry model risk: the risk of loss from a model being wrong or misused.
• Three lines of defense — (1) model owners/developers, (2) independent model validation, (3) audit. AI systems go through validation before production.
• Development, validation, monitoring — document the model's purpose, data, limitations; validate performance and conceptual soundness independently; monitor in production for drift/degradation (ties directly to your eval-in-CI + continuous online eval — K08).
• Effective challenge — independent, competent review with authority to push back. Your eval evidence and documentation are what survive challenge.

How it lands in your work: maintain documentation (model card, data lineage, eval results, known limitations), versioned prompts/models, an independent eval set, and production monitoring — so when validators come, you have artifacts, not assertions. Saying "I'd produce a model card and eval evidence for validation under an SR 11-7-style process" is a senior-in-banking signal.

6. Data: residency, privacy, PII/PCI, minimization

• Residency — keep data in mandated regions; use Regional/Data-Zone Azure OpenAI deployments and in-region Search/Cosmos/Storage; a UAE bank typically pins to UAE North or an approved geography (K00 §9).
• Azure OpenAI commitments — prompts/outputs not used to train foundation models; abuse-monitoring opt-out available for sensitive data; processing in-geo. This is the compliance basis for using GenAI on customer data at all.
• PII minimization — detect and redact/tokenize PII before the model and before logs; pass only what's necessary; the model often works on tokens, not raw identifiers (K08 §8).
• PCI — avoid putting card PANs near the LLM; tokenize/segment; PCI scope is to be minimized, not handled by the AI.
• Retention — TTL/retention policies per regulation; right-to-erasure; immutable audit retained per record-keeping rules (these two tensions — erase PII vs retain audit — are resolved by redacting PII in the audit while keeping the decision record).
• Access control & encryption — encryption at rest/in transit (default on Azure), customer-managed keys where required, RBAC least-privilege, private networking.

7. Security posture (defense in depth)

A bank expects every one of these; recite them as a stack (K00, K07):

• Identity — Entra ID, Managed Identity (no keys), least-privilege RBAC, conditional access, MFA for admins, on-behalf-of so tools act with the user's permissions.
• Network — Private Endpoints, public access disabled, VNet integration, APIM as the audited choke point, egress through Azure Firewall, WAF.
• Secrets — Key Vault, rotation, OIDC in CI (no stored secrets).
• Application — input validation (Pydantic), security-trimmed retrieval, least-privilege tools, Content Safety + Prompt Shields, output filtering, rate limiting, idempotency.
• Data — encryption, PII redaction/tokenization, CMK, data classification.
• Detection & response — Microsoft Defender for Cloud, Microsoft Sentinel (SIEM), audit logging, anomaly alerts, an incident-response runbook.
• Supply chain — image scanning, signed images, dependency scanning, IaC review.

The reflex: when asked "how do you secure X," answer in layers (identity → network → secrets → app → data → detection), not a single control.

8. Responsible AI: fairness, transparency, human oversight

Microsoft's Responsible AI principles (fairness, reliability & safety, privacy & security, inclusiveness, transparency, accountability) map cleanly onto banking requirements:

• Fairness — guard against biased outcomes, especially in credit/lending (fair-lending law). Test across demographic slices; document; keep humans accountable for decisions.
• Transparency/explainability — disclose AI use to users ("you're chatting with a virtual assistant"); provide citations and the ability to explain a decision; avoid black-box autonomous decisions on consequential matters.
• Human oversight — human-in-the-loop on high-risk/irreversible actions and on consequential decisions; AI assists, humans decide and are accountable. This is both an EU AI Act requirement for high-risk systems and basic banking prudence.
• Reliability & safety — grounding, guardrails, eval gates, monitoring (K08).
• Accountability — clear ownership, model governance, audit, documented limitations.
• Inclusiveness — Arabic/English parity, accessibility, dialect handling (K05).

"AI assists; humans remain accountable" is the sentence that resolves most Responsible-AI questions in banking.

9. The five hard banking questions (and how to answer)

Memorize these — they're the interview's safety gauntlet:

1. "How do you guarantee it never gives a customer a wrong balance?" Live balances come from a tool call to the core banking system (the system of record), never the LLM's memory; the model only phrases the returned value. Plus grounding instructions, groundedness eval, and audit of the tool call. The model is never the source of truth for a money fact.

2. "How do you prevent one customer seeing another's data?" Security-trimmed retrieval (ACL filters on every query), on-behalf-of auth so tools use the user's permissions, per-tenant isolation, least-privilege RBAC, private networking. Access control is enforced in data/retrieval/tools — never by asking the LLM to "not reveal" it.

3. "How do you prove to a regulator why the system did something?" End-to-end immutable audit: prompt+version, retrieved chunks+scores, tool calls+args+results, model+params, guardrail triggers, decision+citations, approver — PII-redacted, retained per policy. Plus model documentation and eval evidence (SR 11-7-style). I can reconstruct any interaction.

4. "What if the model is jailbroken or a document contains a hidden instruction?" Layered: Prompt Shields detect jailbreak/indirect injection; system/user trust separation; but the real safety is architectural — least-privilege tools + human approval mean an injected "transfer funds" can't execute, and output filtering catches leakage. I contain blast radius, not just filter text. (K06 §7)

5. "How do you keep it from giving investment/legal advice?" Scope it in the system prompt (enumerated refusals), classify intent and route advice-seeking to a refusal/disclaimer or human, eval the refusal-correctness as a metric, and disclose AI use. The bot stays in licensed-scope; consequential advice goes to a qualified human.

Answer every technical question with the matching safeguard, and you sound like someone who has shipped in a bank.

10. The GCC/UAE context

The Arabic requirement strongly suggests a Gulf/UAE bank. Useful context:

• Regulator: the Central Bank of the UAE (CBUAE); also free-zone regulators DIFC (Dubai) and ADGM (Abu Dhabi) with their own data-protection regimes (DIFC DPL, ADGM DPR) plus the federal UAE PDPL.
• Data residency is commonly required in-country; Azure UAE North (Dubai) / UAE Central regions exist for this.
• Bilingual by default — Arabic + English across all channels; Arabic often the primary customer language. Dialect (Gulf Arabic) vs MSA matters (K05 §6).
• Islamic banking — some institutions offer Sharia-compliant products (no interest/riba; profit-sharing structures like murabaha, ijara); your RAG/assistant must handle that product vocabulary correctly.
• Strong digital-banking adoption and ambitious national AI strategies (the UAE has a national AI agenda) → high expectations, real production scale.

Mentioning CBUAE, in-region residency (UAE North), Arabic dialect handling, and (if relevant) Islamic-banking products shows you understand this bank's world, not a generic one.

11. Common misconceptions

• "The LLM can hold the customer's balance." Never — it's a tool call to the core banking system; the LLM only phrases it.
• "Tell the model not to reveal other customers' data." Access control is enforced in retrieval/tools/RBAC, never by prompt.
• "AI can decide AML/credit outcomes." AI assists; humans decide and remain accountable; consequential automated decisions are governed/often high-risk under the EU AI Act.
• "Compliance is the compliance team's job." You must design for compliance (grounding, access control, audit, oversight) from the start.
• "Residency is a checkbox." It dictates regions, deployment types, and which services you can use; get it wrong and the project is illegal.
• "Banking AI is just RAG + a nice prompt." It's RAG + tools to systems of record + least-privilege + human oversight + eval gates + immutable audit + model governance.
• "Arabic is a translation feature." It's a first-class requirement touching tokenization, OCR, dialects, RTL, and eval (K05).

12. Interview Q&A

Q: You have banking experience — what makes AI in a bank different from a startup? The cost of being wrong (money movement, legal breach, data leakage, regulatory fines) forces a posture of safety, control, explainability, and auditability over raw capability. Concretely: money facts come from systems of record via tools, not the model; retrieval is access-trimmed; high-risk actions need human approval; everything is immutably audited; models go through validation (SR 11-7-style) with documentation and eval evidence; data residency and PII minimization are mandatory. AI assists; humans/rules govern decisions.

Q: A product manager wants the assistant to autonomously approve fee waivers. Your response? I'd keep the LLM as the drafter/recommender and require human (or deterministic-rule) approval for the actual waiver, because it's a consequential money decision needing accountability and audit. The agent gathers context (tool calls), checks policy (RAG + rules), proposes a decision with rationale and citations, then pauses (human-in-the-loop) for approval; the approver and reasoning are logged. Autonomy only for low-risk, reversible, rule-bounded actions.

Q: How do you handle customer PII end to end? Minimize and classify it; redact/tokenize before the model and before logging (Azure AI Language PII / Presidio with banking entities); pass only what's needed; residency-pinned regions; Azure OpenAI's no-training + abuse-monitoring opt-out; encryption + CMK; least-privilege access; immutable but PII-redacted audit; retention/erasure per PDPL/GDPR. Security-trimmed retrieval so PII is never surfaced across customers.

Q: What's model risk management and how does it apply to your LLM app? It's the discipline (SR 11-7) of managing the risk that a model is wrong or misused, via development standards, independent validation, and ongoing monitoring, with three lines of defense and "effective challenge." For my LLM app: documented purpose/data/limitations (model card), versioned prompts/models, an independent eval set, pre-prod validation, and continuous production monitoring for drift/degradation — so the system survives independent challenge and audit.

Q: How would you localize a banking assistant for the UAE? Arabic + English parity with Gulf-dialect handling and RTL/bidi UI; Arabic-capable OCR/Document Intelligence for IDs/cheques; multilingual embeddings and Arabic eval sets with native reviewers; in-region data residency (UAE North) under CBUAE/PDPL (and DIFC/ADGM if applicable); correct Islamic-banking product vocabulary where relevant; and the full safety/audit posture. Disclose AI use and provide human escalation in both languages.

13. References

• Model risk — US Federal Reserve / OCC SR 11-7, "Guidance on Model Risk Management" (2011).
• EU AI Act — Regulation (EU) 2024/1689 (risk tiers, high-risk obligations, human oversight).
• NIST AI RMF (2023) and Generative AI Profile (2024).
• FATF — International Standards on Combating Money Laundering (40 Recommendations).
• PCI DSS v4.x — Payment Card Industry Data Security Standard.
• Microsoft Responsible AI — Standard & principles; Azure OpenAI Data, privacy, and security and Responsible AI docs.
• Basel Committee — principles on the sound management of risks (context).
• UAE — CBUAE regulations; UAE PDPL (Federal Decree-Law 45/2021); DIFC DPL / ADGM DPR.
• OWASP Top 10 for LLM Applications; ISO/IEC 42001 (AI management systems).
• Related modules: K00 Platform, K06 Prompting/Injection, K08 Eval & Safety.