AI compliance for fintech: what auditors actually look for

What fintech compliance teams actually need from AI

Fintech AI engagements get killed at compliance review more often than at engineering review. Not because the AI is dangerous — but because the compliance team's questions don't have clean answers, and "we'll figure it out" doesn't land in a regulated context.

Here's the compliance pattern we ship on every fintech engagement. It's not exotic; it's just non-optional.

Audit trails on every AI-generated decision

Every prompt, retrieval, tool call, and output gets logged with reasoning. Tied to a named user, named system, and a unique decision ID. Retained for the lifetime of the underlying record (not just 90 days).

Auditors don't ask "is the AI right?" They ask "can you show me what happened on March 14, account 4729?" If you can answer that with timestamps and reasoning, you pass. If not, you don't.

Model approval workflow

Before any production AI touches a regulated workflow, it gets reviewed and signed off by a named owner. We build the approval workflow into the deployment system — you literally can't deploy without a recorded approval.

Includes: model card, prompt version, eval scores, intended scope, refusal patterns, escalation path. Stored together. Versioned.

Refusal patterns + escalation

The AI must be able to say "I don't know — let me route this." More important: it must do this on every category your policy doesn't allow it to answer. Not via a model decision — via explicit policy at the orchestration layer.

We document refusal categories in plain English (the auditor reads them) and in code (the engineer enforces them). Both have to match.

Who signs off, and what happens when they leave

The approval workflow above assumes a named owner. The failure mode nobody plans for is that owner changing role, and it is common enough over the life of a regulated system to be worth designing against.

Approvals need to be attached to an accountable role, not just a person. "Approved by the Head of Credit Risk on 14 March" survives a personnel change in a way "approved by Priya" does not. Record both — the individual for the audit trail, the role for the continuity.

A departure should trigger a re-approval, not an inheritance. When the approving owner leaves, the successor has to actively re-approve the systems they now own, with the same artefacts in front of them. Silently transferring approval produces a system nobody currently in the building has actually agreed to, which is precisely the finding an auditor will write up.

Keep the approval scope narrow enough to be meaningful. An approval covering "the AI system" is not an approval of anything specific. Approve a named prompt version, a model version, a defined scope of use, and a refusal set. When any of those changes materially, the approval expires. This is more work up front and it is the difference between a control and a signature.

Diarise the review. Approvals with no expiry drift out of date invisibly. An annual re-approval, calendared, is the cheapest way to guarantee that what is running is still what was agreed.

Eval coverage with regulator-relevant cases

Eval suites include cases derived from past audit findings, internal control reviews, and known failure modes. Replayed weekly. Failure rate is a SOX-equivalent metric in our engagements.

What changes when the provider updates the model

The hardest question a fintech compliance team asks is the fourth one on the list above: how do you know the model is still doing what it was approved to do? It is hard because the honest answer involves something outside your change control.

Model identifiers are not always versions. Providers update models behind stable-looking names, adjust safety behaviour, and deprecate versions on their own schedule. A system approved against particular behaviour can therefore change without a single commit in your repository — which is exactly the scenario a change-management control is supposed to prevent.

Pin the version wherever the provider offers it, and treat that pinned identifier as a controlled configuration item with an owner and a review date. An unpinned model is an uncontrolled dependency sitting in the most behaviour-critical position in the system, and it is very difficult to defend that in an audit once it is pointed out.

Run the eval suite on a schedule, not only on change. Weekly is enough. It is the only mechanism that detects provider-side drift, because there is no internal event to trigger on, and the scheduled run is itself the evidence that the control operates.

Keep a frozen baseline of scored outputs. When numbers move, comparing against a stored artefact establishes within minutes whether the model changed or your scoring did. Under audit pressure that distinction is worth having available rather than reconstructing.

Write the deprecation path down before you need it. When a notice arrives with a date on it, the team that has already scored the successor model against the same suite has a controlled migration. The team that has not has an incident with a deadline.

Read your DPA. Then read it again.

Anthropic, OpenAI, and your other vendors have DPAs. They say specific things about data handling, training opt-outs, retention, and sub-processors. Your compliance team needs to read each one. We don't paper-over with "we use enterprise tiers" — we surface the actual document and walk through it.

SOC 2 readiness ≠ SOC 2 audit

"SOC 2 ready" means we build to controls the auditor will look for. The audit is between you and your auditor — we're not the auditor, and any vendor claiming "SOC 2 certified" without the report is doing word-play.

We have the controls. The report is yours to commission.

Data residency

For most fintech clients we keep inference in the region of record. Anthropic and OpenAI both offer regional inference now. Edge gateway + open-source models when even the regional cloud is too much.

This is a 30-minute discussion at the start of every engagement. Don't skip it.

Incident response for an AI decision

The fifth question — what happens when the AI is wrong — is the one most builds answer weakest, because it is the only one that cannot be satisfied with documentation alone.

Decide in advance what counts as an incident. A single wrong answer caught by a human reviewer is not one. A wrong answer that reached a customer, moved money, or entered a regulated record is. Writing that threshold down beforehand prevents the argument that otherwise happens while the clock is running.

The audit trail is the investigation. If your logging carries the prompt, the retrieved context, the tool calls, the model version, and the approved policy in force at the time, an investigation is a query. If any of those are missing, it becomes an exercise in inference — and "we believe the model probably saw" is not a sentence you want in a regulator-facing report.

Have a kill switch that a non-engineer can operate. The ability to disable an AI decision path and fall back to the manual process, without a deployment, is what converts a serious incident into a contained one. It should be tested, not theoretical, and the person on call at 2am should know where it is.

Plan the remediation sweep. If a defect ran for three weeks, the affected population is every decision in that window, not just the one that surfaced. Being able to identify that set from the decision log — by model version, prompt version, and date range — is the difference between a bounded remediation and a full manual review.

Feed it back into the evals. Every incident produces at least one permanent eval case. Auditors respond well to a suite whose provenance includes past findings, because it demonstrates the control loop actually closes.

What compliance teams actually ask

Real questions we've gotten from regulated-finance compliance teams, in our experience:

1. "How do you stop the model from making things up about our policy?"
2. "Show me an example audit trail end-to-end."
3. "Who approved the prompt? What did they approve specifically?"
4. "How do you know the model is still doing what it was approved to do?"
5. "What happens when the AI is wrong?"

If your AI build doesn't have clean, unambiguous answers to all five, it's not production-ready in a fintech context — regardless of how good the model is.

What to ask an AI vendor before compliance does

Compliance review goes badly when the engineering team learns the answers at the same time as the reviewers. These are the questions worth putting to any vendor — including us — early enough that the answers can shape the build.

Where does inference physically happen, and can you prove it? Not the vendor's headquarters, the inference region. Ask for it in writing, and ask what happens on failover, because a regional endpoint that spills to another region under load is a data-residency finding waiting to be written.

Is our data used for training, and what is the contractual basis for that answer? Enterprise tiers generally say no. The answer that matters is the clause, not the marketing page, and your compliance team will want the document rather than the assurance.

Who are the sub-processors, and how are we told when they change? Sub-processor lists change. A DPA that permits silent additions is a different risk profile from one requiring notice, and the difference only becomes visible after it matters.

What is the retention on prompts and outputs at the provider? Separate from your own logging. Some retain for abuse monitoring for a defined window; your compliance team needs that number, because it is data you sent that you no longer control.

How are model deprecations communicated, and with what notice? This determines whether a forced migration is a planned change or an incident, and it is rarely asked until the notice arrives.

What happens to our data if we leave? Deletion timelines, format of export, and whether logs are included. Exit provisions are the least interesting part of a contract to negotiate and the most expensive to have skipped.

None of these are hostile questions, and any serious vendor answers them readily. The reason to ask them upfront is simpler than diligence theatre: every one of them can change the architecture, and all of them are cheaper to accommodate before the build than after the review. The pattern we see repeatedly is a build that was technically sound being sent back for a residency or retention reason that a single question in week one would have surfaced, costing weeks that nobody budgeted.

What this adds to the build cost

Compliance-grade AI adds 20-40% to a standard build, mostly in the audit-trail plumbing, the approval workflow, and the eval coverage. We don't strip those costs even on small engagements — the cost of building them in after the fact is much higher.

If your compliance team is upstream of your engineering team in priority, that's the right order. Build for the audit. The engineering work falls out of it.