MaRisk for AI

What is MaRisk?

MaRisk stands for Mindestanforderungen an das Risikomanagement, the Minimum Requirements for Risk Management. It is a supervisory circular (Rundschreiben) issued by BaFin in coordination with the Deutsche Bundesbank.

MaRisk is not a statute. It is a supervisory expectation. In practical effect it has the force of law for German credit and financial services institutions, because BaFin enforces it through examinations, supervisory letters, and administrative measures. The legal basis is Section 25a of the Kreditwesengesetz (KWG, the German Banking Act), which requires every credit institution to have a proper business organisation including appropriate risk management.

The current version is the 7th MaRisk revision (2023), with a 2025 clarification aligning it with DORA. Further updates are expected as the EU AI Act high-risk obligations come into effect.

Who has to follow MaRisk

• Every credit institution licensed under the KWG: commercial banks, savings banks (Sparkassen), cooperative banks (Volksbanken, Raiffeisenbanken), Landesbanken, building societies, and specialised institutions
• Every financial services institution licensed under the KWG: investment firms, principal brokers, lending intermediaries, financial portfolio managers

Insurers are out of scope; the equivalent is VAIT plus MaGo. Asset managers have KAMaRisk under the KAGB. Payment institutions have ZAG-MaRisk. The DNA is the same across all four.

Structure: AT (General Part) and BT (Special Part)

MaRisk has two main parts. AT covers cross-cutting principles. BT covers specific risk types (BTO for credit and trading organisation, BTR for risk controlling per risk type).

For AI in a German bank, three AT modules carry most of the weight:

• AT 4.3.5 Model risk (the core module for AI models)
• AT 7.2 IT and information risk (overlaps with BAIT)
• AT 9 Outsourcing (overlaps with DORA Pillar 4)

AT 4.3.5: Model risk in practice

AT 4.3.5 captures every quantitative model in a German bank, including AI. The 7th revision tightened it. The expectations for any AI model used in a material business function:

• Documented model purpose, intended use, and limitations
• Risk classification of the model; high-impact models receive the strictest treatment
• Pre-deployment validation by a function organisationally independent of the developer
• Validation testing covering performance, robustness, stability, sensitivity, and discrimination effects
• Documented data quality and lineage assessment
• Ongoing performance monitoring with thresholds and breach actions
• Periodic revalidation, typically annual for material models
• Inventory of all models with classification and validation status
• Process to manage model issues, overrides, and limitations

The supervisory rigour is comparable to the US SR 11-7 model risk management standard.

AT 7.2: IT and information risk

AT 7.2 sets the IT risk principles that BAIT operationalises in detail. Expectations include:

• Documented IT strategy derived from business and risk strategy, board-approved, reviewed annually
• IT risk management framework with documented risk analysis, controls, monitoring, response
• Identification and protection of information assets through protection requirement assessment
• Information security management aligned with ISO 27001, BSI IT-Grundschutz, or NIST CSF
• Identity and access management with need-to-know, recertification, privileged access controls, logging
• Change management, capacity, performance, backup, asset inventory, contingency

AT 9: Outsourcing

AT 9 governs the outsourcing of activities and functions. It is aligned with the EBA outsourcing guidelines and with DORA's third-party rules. Expectations:

• Risk analysis and materiality assessment before contracting
• Due diligence on the provider
• Mandatory contractual provisions (access, audit, security, sub-outsourcing, exit, applicable law, data location)
• Ongoing monitoring of the outsourced function
• A central outsourcing register, reportable to BaFin on request
• Exit strategy for material outsourcings
• Management of concentration risk and sub-outsourcing

The AT 9 register and the DORA register overlap heavily but are not identical. Most German banks consolidate both into a single source of truth.

How MaRisk treats AI specifically

BaFin's line is consistent: AI is not a new risk type. The existing principles apply. Where AI introduces specific risks (data drift, lack of explainability, scale of automated decisioning), the institution must show how those risks are addressed inside the existing framework. MaRisk does not have an "AI module". AI is examined through AT 4.3.5, AT 7.2, and AT 9 with extra rigour.

The questions BaFin examiners actually ask:

• Where is AI used in the institution? (model inventory)
• Who validated each model? (independent validation)
• How is data quality monitored? (data lineage)
• How are drift and degradation detected? (ongoing monitoring)
• Who has overrides, and how are they recorded? (governance)
• How are customer-facing decisions explained? (transparency, GDPR Article 22)
• What is the IT environment around the model? (BAIT)
• Is the provider in the outsourcing register? (AT 9)

How MaRisk interacts with the other frameworks

• BAIT: the operational manual built on AT 7.2 principles. Read together with MaRisk
• DORA: substantial overlap on IT risk and outsourcing. Both apply in parallel. MaRisk-compliant firms have a head start, but DORA is tighter
• EU AI Act: a high-risk AI in a German bank sits inside both regimes. MaRisk is the supervisory hook; the EU AI Act is the product regulation
• ISO 42001: no direct overlap, but a structured AI management system supports AT 4.3.5 compliance
• BaFin: MaRisk is the rulebook BaFin enforces. The supervisory relationship is direct

What BaFin examiners commonly find on AI

• Model inventory incomplete or stale; shadow AI in production not registered
• Validation done by people too close to the developers
• Insufficient testing of bias and concentration effects
• Drift detection that is theoretical, not actually running in production
• Override logs that are missing, ad-hoc, or not aggregated
• Cloud sub-dependencies not traced in the outsourcing register
• Documentation that does not match the deployed code
• AI risk not integrated into the risk-bearing capacity framework

What to do next

• If you are a German bank: confirm your AI model inventory is current. Validate every material AI model with a function independent of the developers. Capture overrides systematically
• If you sell AI to a German bank: prepare a model card and validation pack your customers can drop into their AT 4.3.5 file
• Integrate AI risk into the risk-bearing capacity framework. Treat AI exposure as you would any other material risk
• Bring AI into the IT strategy under AT 7.2 explicitly. AI cannot be a footnote
• Consolidate the AT 9 outsourcing register with the DORA register where possible
• Use the classifier tool to map your AI against MaRisk and the related German rules