AI Agent Governance for Fintech: A Practical Checklist
A fintech scale-up in Amsterdam deployed an AI agent for automated credit pre-screening in late 2025. The system was well-built, accurate, and fast. By Q1 2026, it was handling 40% of initial credit assessments with no human review.
The DNB examination team asked for six months of decision logs, bias analysis by demographic subgroup, and documentation of the human oversight mechanism. The engineering team spent three weeks reconstructing what should have been on file. The audit outcome: remediation required within 90 days.
The system worked. The governance didn’t exist.
TL;DR
- Fintech AI agents face overlapping regulatory requirements: EU AI Act (high-risk classification), EBA Guidelines on ML, GDPR automated decision rights, and national supervisory expectations
- Most fintech AI governance failures are documentation and evidence failures, not technical ones
- The practical gaps: missing authorization records, no bias analysis, weak human oversight architecture, no audit-ready evidence
- This checklist maps specific controls to specific regulatory requirements for credit, fraud, and customer service agents
Why Fintech AI Governance Is Different
Most industries face one or two regulatory frameworks for AI. Fintech teams typically face four to six, operating simultaneously:
- EU AI Act — Credit scoring and similar systems likely qualify as high-risk under Annex III, triggering full Articles 9–17 compliance requirements
- EBA Guidelines on Internal Governance — Apply to firms under EBA supervision; address model risk management, validation, and documentation
- EBA Guidelines on Machine Learning for IRB Models — Specific to credit risk models using ML; address data quality, model performance, and governance
- GDPR Article 22 — Right not to be subject to automated decision-making; right to explanation; specific requirements for consent or legitimate interest
- PSD2 / Open Banking — Specific requirements for AI agents handling payment data or facilitating payment decisions
- National supervisory requirements — DNB, FCA, BaFin, and other national authorities have issued AI-specific guidance or apply existing frameworks to AI
These frameworks overlap but don’t align perfectly. An AI agent that satisfies EU AI Act requirements may not satisfy GDPR’s automated decision-making rules in the same configuration.
The Fintech AI Governance Checklist
1. Risk Classification and Scope Definition
□ Confirm EU AI Act high-risk classification Credit scoring, creditworthiness assessment, and determination of access to financial resources are listed in Annex III. If your AI agent informs any of these decisions — directly or as input to a human decision — it likely qualifies as high-risk.
□ Document the agent’s intended purpose with regulatory precision “Credit pre-screening” is a purpose. “Automated assessment of personal loan applications for amounts up to €50,000 for natural persons residing in the Netherlands and Germany, with a decision that determines initial eligibility for human underwriter review” is an Annex IV-compliant purpose statement.
□ Map your agent’s outputs to decision types For each output your agent produces: what decision does it inform, who makes the final decision, and is the human decision meaningful or effectively automated? GDPR Article 22 applies to decisions that are “solely” automated — define where in your workflow human judgment is genuinely exercised.
2. Authorization and Policy Controls
□ Define and document permitted decision boundaries Which credit decisions can the agent automate? Which require human escalation? Document these boundaries in a governance constitution that specifies thresholds, conditions, and the regulatory basis for each boundary.
□ Implement pre-decision authorization checks Each credit assessment should be evaluated against the constitutional rules before the output is produced. The evaluation must be logged with policy reference and decision rationale.
□ Build escalation gates for high-risk decisions Applications above amount thresholds, applications from customers with specific risk factors, and applications where model confidence is below defined thresholds must route to human underwriters. Document the routing criteria.
□ Log authorization with tamper-evident records Every credit decision must have a signed, hash-chained evidence record that documents: inputs, policy version, model version, confidence score, decision, rationale, and human reviewer (if applicable).
3. Bias and Fairness Controls
□ Define protected characteristics for bias monitoring EU AI Act and EBA requirements both address discriminatory outcomes. Define which characteristics (age, gender, nationality, residence) are monitored for differential impact. This requires collecting or inferring these attributes — address GDPR implications of collection.
□ Implement ongoing bias monitoring Bias analysis is not a one-time pre-deployment test. Monitor approval rates, interest rate offers, and adverse action rates by protected characteristic on an ongoing basis. Define acceptable disparity thresholds and the action triggered when exceeded.
□ Document bias test results in Annex IV documentation Pre-deployment bias analysis results, methodology, and acceptable disparity justification must appear in your EU AI Act technical documentation.
□ Implement adverse action notification GDPR Article 22 requires that data subjects have the right to obtain human review of automated decisions. Your workflow must support adverse action notifications with an explanation and a pathway to human review.
4. Audit Evidence and Logging
□ Article 12 logging for all credit decision events Log: application inputs, model version, governance constitution version, decision, policy rules evaluated, confidence score, and outcome. Retain for minimum 10 years (Annex IV requirement) or longer if required by local law.
□ Retain model versions and their evaluation results Every model version that made production decisions must be retained with its validation results. When a dispute arises about a decision made two years ago, you must be able to demonstrate what model made it and what its validated performance was.
□ Log human review events separately When a human underwriter reviews or overrides an agent’s recommendation, log: reviewer identity, review timestamp, recommendation reviewed, action taken, and the basis for any override.
□ Implement query capability for regulatory inspection Regulators will ask for: all decisions in a time period, decisions by customer segment, decisions where a specific policy version was applied, decisions that were overridden. Build query capability for these patterns before you need it.
5. Human Oversight Architecture
□ Define oversight roles and qualifications Who has oversight authority over the credit agent? Credit analysts? Risk officers? Document required qualifications per Article 14.
□ Build meaningful override capability Human overseers must be able to review the agent’s recommendation and override it before it affects the customer. A “review” that occurs after the adverse action notification is sent is not meaningful oversight for the decision.
□ Track and analyze override rates Monitor override rates over time. A very low override rate may indicate nominal rather than effective oversight. Investigate and document the basis for low override periods.
6. Customer Rights
□ GDPR Article 22 mechanism Implement a process for customers to request human review of automated credit decisions. Define SLA, review process, and documentation requirements for each request.
□ Explanation capability Customers subject to adverse automated decisions have a right to “meaningful information about the logic involved.” Implement an explanation generation capability that produces a compliant adverse action explanation — not a generic statement, but a decision-specific explanation.
For the full regulatory coverage required by EU AI Act Articles 9–15 that underpins this checklist, see EU AI Act Article 9: Continuous Risk Management and EU AI Act Annex IV: Documentation Checklist.
Common Fintech-Specific Gaps
Gap 1: Model validation performed at deployment, not continuously. EBA guidelines on ML models require ongoing validation, not just pre-deployment testing. Build periodic revalidation into your governance calendar.
Gap 2: Governance constitution not reviewed by compliance. Engineering teams often write governance rules without compliance sign-off. EU AI Act requires that risk management measures (which include governance rules) address the risks identified in the Article 9 assessment. Compliance must review the constitution.
Gap 3: GDPR and EU AI Act addressed separately. GDPR Article 22 and EU AI Act Article 14 both address automated decision-making oversight. Building separate mechanisms for each is inefficient and creates inconsistency. A unified human oversight workflow satisfies both.
Gap 4: Training data documentation incomplete. EBA and EU AI Act both require documentation of training data. For credit models, this includes: source institutions, time period, data quality measures, and analysis of training data for discriminatory patterns.
FAQ
Q: Does the EU AI Act override GDPR for AI systems?
No. Both apply. Where they address the same subject (automated decision-making oversight), compliance with both is required. The EU AI Act is not a replacement for GDPR; it operates alongside it.
Q: What is the EBA ML Guidelines’ relationship to the EU AI Act?
The EBA Guidelines on Machine Learning for IRB Models apply to credit institutions using ML under the Capital Requirements Regulation. The EU AI Act applies to high-risk AI systems placed on the EU market. Both can apply to the same system. The EBA guidelines predate the EU AI Act and focus on model risk management; the EU AI Act focuses on systemic requirements for high-risk AI. Compliance with one does not guarantee compliance with the other.
Q: Our agent provides a recommendation, not a final decision. Does EU AI Act still apply?
Providing a significant input to a consequential decision can qualify as high-risk under Annex III even if the final decision is made by a human. The test is whether the AI system’s output materially determines the outcome. A pre-screening result that accepts or rejects the majority of applications before human review qualifies.
Q: How do we handle the period before our full governance system is built?
Operate at reduced automation scope. The governance gap is highest where automation is highest and oversight is lowest. Reducing automation scope (fewer automated decisions, lower thresholds for human review) reduces regulatory exposure while governance infrastructure is built.
By Nikola Kovtun, founder of Infracortex AI Studio. We implement fintech AI governance infrastructure — authorization gates, bias monitoring, audit evidence, and human oversight workflows — designed for the specific regulatory overlap fintech teams face. Book a call to discuss your compliance posture.
See also: EU AI Act Article 12: Logging Requirements Decoded | AI Agent Governance for Healthcare: HIPAA + EU AI Act | Why Runtime is Commodity and Governance is the Moat
Cortex build: 0.1.35-260423
