SR 26-2 vs EU AI Act: How Do Banks With EU Credit Operations Reconcile Both?

Two regimes with different legal natures

SR 26-2 is a Federal Reserve Supervision and Regulation Letter. Its revised guidance sets out principles for effective model risk management and recognizes that practices appropriately vary among banking organizations based on their risk profiles and model usage. Examiners assess a bank against those principles through validation, governance and ongoing monitoring. The standard is proportionate and judgment-based.

The EU AI Act (Regulation (EU) 2024/1689) is a regulation, not guidance. Its recitals state that AI systems used to evaluate the credit score or creditworthiness of natural persons should be classified as high-risk, because they determine access to financial resources or essential services. High-risk status brings obligations on risk management, data governance, record-keeping, human oversight, logging, accuracy and robustness.

This difference shapes the program. SR 26-2 asks a bank to demonstrate sound practice in proportion to its model use. The AI Act sets obligations attached to a system classified as high-risk. A bank with EU credit operations must satisfy both, and neither answers the other's questions.

Side-by-side by control objective

The table is organized by what each control is meant to achieve, not by regulation. That makes overlap and divergence easier to see.

• Scope and definitions: SR 26-2 scope follows the bank's model usage and risk profile. The AI Act scope follows system classification, which includes creditworthiness assessment of natural persons. Build one inventory that records both attributes for each credit-related system.
• Risk management and data governance: SR 26-2 expects proportionate model risk management. The AI Act sets explicit risk management and data governance obligations for high-risk systems. Shared: documented risk ownership. Gap: AI Act data governance requirements need their own evidence.
• Human oversight: The AI Act requires human oversight of high-risk systems. SR 26-2 evaluates governance and accountability. Shared: named accountable roles. Keep approvals tied to named approvers and policy versions.
• Record-keeping and evidence: High-risk systems must technically allow automatic recording of events over their lifetime. Examiners review evidence of validation, governance and monitoring. One record set can serve both if it is designed for filtering.
• Third-party and vendor AI: Under the AI Act, provider duties sit with the vendor or the bank depending on role, and deployers must use systems per their instructions for use. Allocate roles per system and collect matching vendor evidence.
• Ongoing monitoring: SR 26-2 is examined through ongoing monitoring. The AI Act's lifetime logging supports observing system behavior in operation. Shared: monitoring inputs. Gap: each regime defines its own thresholds and reviews.

Shared controls and true gaps

The overlap is real in four places: accountable ownership, an inventory of systems, human oversight of consequential decisions, and evidence that the controls operated. A bank that already runs a disciplined model risk program has a foundation for each. The work is to extend it, not to build a second program.

The gaps are narrower than they first appear but they matter. The AI Act's classification is binary for a given use, so a credit system is either in high-risk scope or it is not, and the Commission's guidelines on high-risk classification are the reference for edge cases. SR 26-2 is proportionate and varies with the bank's own risk assessment. The AI Act also imposes data governance and accuracy and robustness obligations as regulatory duties, where SR 26-2 evidence comes through the examination process.

Timing is a separate question. The Digital Omnibus on AI entered into force on 27 July 2026 and delayed application of the high-risk rules. As of November 2026, Parliament's description of the omnibus gives fixed deadlines of 2 December 2027 for stand-alone high-risk systems and 2 August 2028 for high-risk systems embedded in products. Each credit system needs its applicable date assessed individually.

There is also a relevant EU principle. An ECB document states that credit institutions that are providers or deployers of high-risk systems are deemed to comply with certain AI Act provisions when they comply with similar obligations under Union financial services law. The ECB welcomes this because it prevents double reporting and conflicting supervisory views, and it calls for coordination between market surveillance authorities and prudential supervisors. That principle addresses EU law only. It does not resolve US and EU expectations, so the bank must own that reconciliation itself.

Evidence a bank can produce once

The practical goal is a single evidence set that answers both audiences. Four categories are the most reusable: decision records, policy enforcement records, human-approval records, and retention and data residency settings. Decision records show what the system produced for a given credit interaction. Policy enforcement records show which rules applied and what action was taken. Human-approval records show who approved an escalated action, under which policy version. Retention and residency settings show how long records persist and where they are held.

The AI Act's logging duty applies at the system level, over the system's lifetime. A bank cannot satisfy it only with after-the-fact documentation. That favors records generated as the system operates, rather than reconstructed for an examination.

Two design choices keep the effort from duplicating. First, use one schema with views for each audience, so an examiner request and an EU authority request draw from the same source. Second, assign a single point of ownership for evidence requests, since prudential supervisors and market surveillance authorities may take different views of the same record. No source confirms that a given regulator will accept a particular record format, so treat acceptance as something to test with each supervisor.

Where runtime enforcement helps and where it stops

Runtime policy enforcement works at the level of individual interactions and tool calls. Policy is enforced in the execution path, so an action is allowed, redacted, blocked or escalated for human approval as it happens, not reviewed after the fact. Each enforcement decision generates audit-ready evidence. That supports logging and human-oversight obligations directly, and it gives examiners a record of what the AI was permitted to do and what it did. Trussed does this, and its evidence is mapped to the EU AI Act and NIST. Insurance, a regulated financial sector, is where Trussed is deepest.

The boundary matters. Runtime enforcement does not perform model validation. It does not provide model lineage or dataset provenance, and it does not replace technical documentation or conformity work. Those remain with model risk, data governance and compliance teams. A validation report and a record of an enforced policy answer different questions, and an examiner or EU authority will ask for both.

The sound architecture keeps runtime evidence separate from model-development artifacts, then links them by system identifier. Runtime controls cover the operating behavior of the system. The model risk function covers whether the model was fit for purpose to begin with.