BOOK A CALL
FINTECH · COMPLIANCE

AI in FinTech After Basel III: What Actually Passes Audit.

AppsGenii 5 min read

A senior auditor’s checklist. What model risk teams really look for, the documentation that earns approval, and architectural patterns that survive Basel III, PRA, OCC, and SAMA review.

Mudassir Saleem Malik Founder & CEO · AppsGenii

Every regulated FinTech I talk to is asking the same question: where can we deploy GenAI without getting blown up by our regulator? The honest answer is — almost anywhere, if you architect it right. The wrong answer — the one most vendors give — is to slap a chatbot on top of a customer portal and hope the model risk team is asleep.

This is a checklist. Built from working with regulated banks, payment institutions, and FinTech super-apps across the GCC, US, and UK. It is not legal advice. It is operational advice from someone who has shipped GenAI under SAMA, CBB, OCC, and PRA scrutiny.

The big shift — Post-Basel III, regulators no longer treat AI as a model — they treat it as an operational risk. That changes the documentation burden completely. You’re not validating a single model; you’re validating a system, an operating model, and a control environment.

What the auditor actually asks

The standard model-risk-management questions for traditional ML models still apply: provenance of training data, performance metrics, validation set, concept drift monitoring. For GenAI you need to layer on six new questions:

  1. What model are you using, and how do you handle the version dependency? Frontier models change. The version you validated last quarter may have been silently updated.
  2. What’s your prompt change-management process? A prompt is a model. A prompt change is a model change.
  3. How do you bound the output space? An LLM can generate any string. What guards prevent it from generating regulated claims?
  4. What’s your evaluation framework? How do you measure “the model is still working”?
  5. What’s your incident-response process for hallucinations? Detection, containment, customer notification, regulatory disclosure.
  6. What’s your audit trail? Can you reconstruct exactly what the model said to a customer six months ago?

Architecture patterns that pass

Pattern 1: The “frozen prompt” deployment

For high-risk surfaces (anything customer-facing about money), use a frozen prompt with strict output schema. The LLM generates structured JSON, not free text. A rules engine renders the customer message from the JSON. This collapses the output space from “any string” to “one of N templated responses with parameterized fields.”

Trade-off: less expressive. Reward: trivially auditable, defensibly bounded, easy to validate.

Pattern 2: The “human-in-the-loop” deployment

For medium-risk surfaces (internal copilots, agent assist), the LLM drafts and a human approves before the customer sees the output. This pattern earns approval easily because the human is the control. The trick is making the human review fast enough not to destroy the productivity gain — typically through good UI, suggested-edit interfaces, and approve-with-one-click defaults.

Pattern 3: The “bounded RAG” deployment

For knowledge surfaces (policy queries, documentation), use RAG with a controlled, versioned corpus. The LLM is constrained to answer only from documents in the corpus. Every response cites its sources. Every source is from a document with a known authority and effective date.

This pattern works even for customer-facing surfaces if you add: (a) confidence thresholding, (b) automatic escalation on low confidence, and (c) a deny-list of regulated topics that always escalate to humans.

The documentation burden

Regulators want to see, on paper, before deployment:

  • Model card. Provider, version, capabilities, known limitations, intended use.
  • Risk assessment. Inherent risk, residual risk after controls, accept/reject decision with sign-offs.
  • Control inventory. List every control mitigating model risk, with owner and test frequency.
  • Validation report. Evidence the model meets stated performance on representative test data.
  • Operating runbook. Who monitors, what they monitor, what they do when it breaks.
  • Change-management policy. How prompt and model changes are reviewed, tested, and approved.
  • Audit trail design. Where logs live, retention period, access controls.

Most of this paperwork is reusable across deployments — but you have to write it once, well, with input from second-line risk and compliance. Don’t ship without it.

The ten architectural choices that get you to “yes”

  1. Pin the LLM to a specific provider version. No “auto-update.”
  2. Treat prompts as code. Version control. Code review. Approval workflow.
  3. Bound outputs with structured schemas wherever possible.
  4. Cite every retrieval. Make citations machine-checkable.
  5. Implement a regulated-claims filter. Train it on your jurisdiction’s product disclosure rules.
  6. Log every prompt, every response, every tool call. Retain for the regulatory minimum (typically 7 years in banking).
  7. Run an LLM-as-judge on a sample of every day’s traffic. Track factuality, helpfulness, and policy adherence as time series.
  8. Define and rehearse your hallucination incident playbook before you go live.
  9. Have a kill switch. Real, tested, single-button rollback to a deterministic fallback.
  10. Hold a quarterly model-risk-committee review. With minutes. With actions. With sign-off.

The pattern we use

Across regulated FinTech deployments at AppsGenii — including digital wallet flows for clients like StcPay and bank-grade systems for Bank Respublika — we converge on a common shape:

Customer surface
   ↓
Policy filter (regulated claims, sanctions, vulnerable customer signals)
   ↓
Triage classifier → [self-serve | LLM | human]
   ↓
LLM (pinned version) + scoped RAG + structured output
   ↓
Output validator (schema check, regulated-language check, PII redaction)
   ↓
Customer response + immutable audit log + telemetry to risk dashboard

It’s not glamorous. It’s defensible. And every component has a named owner, a documented control, and a test that runs daily.

The wider point

GenAI in regulated FinTech is not blocked by the regulator. It is blocked by the vendor’s unwillingness to do the operational work. If your AI partner is showing you flashy demos and not asking about your model risk policy, change vendors. The deployments that survive an audit are boring on the inside — and that boring-ness is the entire point.

If you’re navigating an active model-risk review or scoping a new GenAI build under regulatory scrutiny, book a 30-minute conversation with our founder. We’ve been through the conversation often enough to skip the warm-up.