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.

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.

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.

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 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.