Field guide
AI governance & compliance in finance
The EU AI Act, model risk management and supervisory expectations, turned into engineering you can ship.
From December 2027 the EU AI Act’s high-risk obligations bite, and credit scoring, insurance pricing and fraud detection sit squarely inside them. In the US, model risk management has moved on from SR 11-7. In Germany, BaFin now treats AI as an ICT risk under DORA. None of this is abstract policy: it lands as concrete requirements on systems you are building now.
This guide turns that regulatory weight into engineering: what high-risk classification actually demands, how to validate and monitor a model so it survives an examiner, and the documentation and human-oversight that has to exist before go-live, not after.
Current signals
- The AI Act's transparency duties have applied since 2 August 2026, with a transition to 2 December 2026 for systems already on the market; high-risk duties for creditworthiness and credit scoring start on 2 December 2027.
- SR 26-2 supersedes SR 11-7 with materiality-based oversight and drops blanket annual revalidation, while leaving generative and agentic AI out of scope.
- Germany's implementing law took effect on 29 July 2026, making BaFin the market-surveillance authority for certain AI systems in financial services alongside its DORA remit for critical ICT.
- US state bank supervisors issued an AI supervisory framework in September 2026 that tells examiners to test AI use, vendor dependence and consumer impact, not only the model.
In this guide
AI on the trading desk: ESMA raises the evidence bar
ESMA's February 2026 supervisory briefing converges scrutiny of algorithmic and AI-assisted trading. Firms must now evidence controls in live trading.
ReadAI vendor contracts after the liability directive
The AI Liability Directive is withdrawn. The revised PLD, the AI Act, and DORA now decide how AI risk is allocated in financial services vendor contracts.
PSD3 and the PSR: what to build before the rules apply
The EU payments package is agreed but not yet in force. What the 2028 application window means for payee verification, fraud reimbursement, and SCA.
US AI guidance for financial institutions, mid-2026
SR 26-2 replaced SR 11-7 and carved generative AI out of model risk. Treasury, the SEC, and Colorado fill the gap. How to map the layered US regime.
The Digital Omnibus and the new EU AI Act timeline
The Digital Omnibus moves Annex III high-risk obligations to December 2027. What still applies now, what can wait, and what finance teams should keep building.
Running AI incident postmortems in finance
A model incident without a postmortem is an incident you will repeat. Here is the blameless postmortem process we run for finance AI failures.
Consumer Duty and AI in UK financial services
The FCA's Consumer Duty reshapes what an AI-driven decision must be able to show. Here is how we engineer for good outcomes and fair value.
An AI governance operating model for a finance team
Governance fails when it is a committee with no wiring. Here is the operating model, roles and gates we help finance teams put around AI.
AI vendor due diligence: the questions that matter
Buying an AI vendor imports their model risk into your firm. Here is the due-diligence checklist we use before a finance team signs.
GDPR and automated decisions in finance AI
Article 22 and the right to an explanation shape what a finance model may decide alone. Here is how we engineer for it without stalling the workflow.
Designing human oversight for high-risk AI
The EU AI Act demands effective human oversight, not a rubber stamp. Here is how we design review points a person can actually exercise.
A bias audit workflow for lending models
Disparate-impact testing, the less-discriminatory-alternative search, and production monitoring: the fairness workflow we run for credit models.
Writing EU AI Act technical documentation that holds up
High-risk classification means a documentation package, not a slide. Here is what Annex IV actually asks for and how we assemble it as engineering evidence.
Model cards that actually help finance governance
A model card is documentation a reviewer can act on, not marketing. Here is what we put on one for a finance model, and why each field earns its place.
Audit trails that make finance AI reproducible
When an examiner asks why the model said that, you need to reconstruct it exactly. Here is the logging and versioning that makes a decision reproducible.
Red-teaming AI systems in financial services
Adversaries probe finance AI for jailbreaks, data leaks and biased outputs. Here is how we red-team a system before an attacker or an examiner does.
Shadow AI: governing the tools staff already use
Your team is pasting data into chatbots whether you approved it or not. Here is the usage policy and controls we help finance firms put around it.
Continuous model monitoring that satisfies a regulator
Annual revalidation is not enough for a model that drifts weekly. Here is the monitoring, alerting and evidence trail we build for supervised finance models.
DORA incident response when AI is the ICT risk
Under DORA, an AI outage is an ICT incident with reporting clocks. Here is the detection, classification and reporting workflow we build for AI systems.
Standing up an AI model inventory and registry
You cannot govern what you cannot list. Here is the model inventory, registry and metadata we build so risk and audit can see every model in production.
BaFin now reads AI as ICT risk: what DORA asks of your models
BaFin's December 2025 guidance files AI inside DORA's ICT risk regime, not a separate ethics box. Here is what that means for registers, incidents and testing.
When the model is someone else's: third-party AI and vendor model risk
A hosted model API is an ICT service, not a feature. Here is how we treat vendor model risk, concentration, and silent updates under DORA-style scrutiny.
What the EU AI Act's August 2026 deadline asks you to build
Credit scoring and insurance-pricing systems are headed into the high-risk regime, and the date is now in flux. Here is what that means for the system you are building.
MiCA for stablecoins and crypto payments: what engineering teams must build
MiCA turns crypto-asset rules into concrete controls for issuers and payment firms. Here is the monitoring, reporting and data-lineage engineering it actually requires.
If a credit model can't explain a denial, it can't issue one
ECOA Regulation B requires specific reasons within 30 days of a credit denial. Here is what that demands from the model that made the decision, not the paperwork around it.
How to actually test a credit or pricing model for fairness
Dropping a protected attribute does not make a model fair. Here is how we test credit and pricing models for disparate impact and proxy discrimination, and keep the evidence.
Model risk management when the model is an LLM
SR 11-7 was written for deterministic models. Its 2026 replacement, SR 26-2, modernised model risk management but left generative AI out of scope. Here is how to extend it to an LLM.
Explainability methods that survive a model validation review
Most explainability work satisfies the data scientist who built the model and nobody else. Here is how we make it hold up for a validator, a regulator and the customer who got declined.
Working on something similar?
Tell us about your data and the workflow around it, and we will give you a straight read.
Book a 30-min intro call