10decoders
Why SR 26-2's exclusion of generative AI creates the compliance gap, not closes it
SR 11-7, the model risk management guidance that governed US financial institutions from 2011, defined a model broadly enough to cover any quantitative method used to inform a financial decision. When teams started using LLMs for credit analysis summaries, fraud narrative explanations, and customer-facing financial guidance, those applications fell within that definition. SR 26-2, issued April 2026, narrowed its own scope and explicitly carved out generative and agentic AI, noting that the agencies would issue separate guidance for those technologies.
The gap this creates is not theoretical. Examiners reviewing an institution's MRM program in 2026 and 2027 will ask about every model and AI tool in production that influences financial decisions. When they encounter an LLM-based application outside SR 26-2's formal scope, the question is not "did you comply with the guidance" but "what controls did you apply and why are they appropriate." An institution with no documentation of that decision is in a weaker position than one with a well-reasoned framework, even if the framework is not formally required. The institutions that will have the most difficult examination conversations are the ones that treated SR 26-2's exclusion as permission to skip validation entirely.
The EU AI Act adds a parallel obligation for FinTech teams operating in Europe. High-risk AI classification under the Act covers credit scoring, insurance underwriting, and fraud detection systems whose outputs directly influence financial decisions without adequate human review. High-risk AI obligations became enforceable on August 2, 2026, and require technical documentation covering accuracy metrics per demographic subgroup, validation methodology, and evidence of independent review. Penalties for non-compliant high-risk AI run up to 35 million euros or 7% of global annual turnover.
"SR 26-2 did not exempt generative AI from scrutiny. It told banks to figure out the appropriate controls themselves and document why they are adequate."
The 5 validation decisions and what regulatory examination looks like for each
These five decisions apply to any LLM application that informs, summarizes, or explains a financial decision in a regulated context. Teams that have made these decisions explicitly and documented the rationale are well-positioned for examination. Teams that have defaulted or skipped them will need to reconstruct documentation retroactively, which is both more expensive and less convincing to examiners than contemporaneous records.
| Validation decision | What most teams do | The regulatory exposure | Examination failure pattern | Risk level |
|---|---|---|---|---|
| Classify the LLM application against the institution's model inventory | LLM applications are treated as software tools, not models. They are deployed outside the model inventory without a materiality assessment or classification decision | Examiners ask for the model inventory. The LLM application is absent. The institution cannot demonstrate that a decision was made to exclude it, only that the question was never asked. That is a governance finding regardless of whether the application would have qualified | Examiner review of a credit underwriting summary tool finds it absent from the model inventory. When asked, the team explains that it was classified as a "reporting tool." Examiner notes that the output was used in 34% of manual review decisions in Q3. Finding: inadequate model inventory governance | Critical |
| Apply the same validation expectations to vendor LLM APIs as to internally built models | Teams using an LLM via API (GPT-4o, Claude, Gemini) treat the model as a black box and do not perform or commission validation on it. The assumption is that the vendor's own model card or responsible use documentation satisfies due diligence | Both SR 26-2 and EU AI Act require equivalent validation rigor for vendor-supplied models as for in-house models. Institutions cannot fully inspect the vendor model's weights or training data, but they are expected to validate the application-layer behavior, test for failure modes on domain-specific data, and document what they were and were not able to validate and why | Examiner asks for validation documentation on a fraud detection LLM deployed via a vendor API. Team produces the vendor's model card. Examiner notes the absence of institution-specific validation on the application's behavior on the institution's own transaction data. Finding: third-party model validation gap | Critical |
| Test for disparate impact on protected-class segments before deployment | LLM accuracy is measured on overall held-out performance. No breakdown by demographic group is produced. The assumption is that because the LLM does not use protected-class attributes as inputs, disparate impact cannot occur | ECOA, FCRA, and the EU AI Act all require that credit-related AI outputs be tested for disparate impact regardless of whether protected-class attributes are direct inputs. LLMs can produce disparate impact through proxy variables embedded in the training corpus. Without testing, the institution cannot demonstrate compliance with existing fair lending obligations, independent of any AI-specific guidance | Fair lending examination reviews a loan decisioning summary tool. Examiner requests accuracy breakdown by race, age, and gender on the institution's own decisioning data. No breakdown exists. Finding: fair lending compliance gap. Referral to fair lending specialist for expanded review | High |
| Conduct independent validation of model conceptual soundness | Validation is performed by the same team that built and deployed the LLM application. Accuracy on a held-out test set is treated as the validation output | SR 26-2, like SR 11-7 before it, requires that model validation be performed by a function independent of model development. For LLM applications, conceptual soundness validation includes assessing whether the model's training objective and architecture are appropriate for the financial task, not just whether its current accuracy is acceptable on a test set the development team selected | Examiner reviews validation reports for a credit risk summarization tool. All validation work was performed by the same ML engineering team that built the tool. Examiner notes the absence of independent review. Finding: inadequate model validation independence. Required remediation: commission independent review before next exam cycle | High |
| Build ongoing monitoring and outcome analysis into the deployment plan before go-live | Monitoring is planned as a future phase. The go-live plan includes accuracy tracking at some point, but no monitoring is operating when the application first touches live financial decisions | Both SR 26-2 and EU AI Act require ongoing performance monitoring for in-scope models and high-risk AI. For LLM applications, this means tracking accuracy against labeled samples, monitoring for distributional shift in inputs, and conducting periodic outcome analysis connecting the LLM's outputs to actual financial outcomes. Institutions that go live without monitoring cannot demonstrate that the application remained within acceptable performance bounds during its production period | Examiner asks for monitoring records covering the first six months of the LLM application's production use. No monitoring was implemented until month four following an internal quality review. The institution cannot demonstrate performance bounds for months one through three. Finding: gaps in ongoing model risk monitoring. Required remediation: reconstruct performance history where possible and document the period without monitoring in the model risk report | Moderate |
The two Critical-level decisions share a structural cause. Both result from treating the LLM application as categorically different from the models the MRM team already manages. That framing is understandable: an LLM deployed via API feels different from a traditional statistical credit model. But from a regulatory standpoint, what matters is whether the application's output influences a financial decision. If it does, the institution's MRM function is expected to have asked the classification and validation questions, documented the answers, and applied controls proportionate to the application's materiality and risk.
Not sure how your LLM applications map to SR 26-2 and EU AI Act requirements?
10decoders builds model risk documentation frameworks specifically for LLM applications in regulated FinTech contexts. We map your current AI inventory, produce the validation documentation that SR 26-2 requires you to determine independently, and design the ongoing monitoring architecture that satisfies both US and EU regulatory expectations. Our FinTech practice has worked with institutions operating under OCC, Fed, and EBA oversight.
Book a Free AI Assessment →The vendor LLM problem is bigger than most FinTech teams realize
The assumption that using an LLM via a vendor API reduces the institution's validation obligation is widespread and incorrect. Both SR 26-2 and its predecessor explicitly stated that institutions must apply the same validation rigor to vendor-supplied models as to models built in-house. The practical constraint is real: institutions cannot access a foundation model's weights, training data, or the specifics of its RLHF process. But that constraint does not eliminate the obligation. It redirects it.
What institutions can and must validate when using a vendor LLM is the application-layer behavior on the institution's own data. That means testing whether the model's outputs on the institution's own transaction records, loan files, or customer interactions are accurate, consistent, and free of disparate impact. The validation must also cover what the vendor does and does not disclose about training and known failure modes, and what that uncertainty means for the application's acceptable use cases. A written determination, signed by a named MRM owner, of whether the application falls within or outside the model inventory is the last step, and it is frequently the missing one.
None of this requires access to the vendor's weights. It requires the institution to treat the vendor LLM the same way it would treat any black-box external model: validate the outputs, document the limits of what can be validated, determine acceptable use cases within those limits, and monitor performance on an ongoing basis. Institutions that can produce this documentation for a vendor LLM application are in a materially better examination position than those who assumed the vendor's responsible use documentation was sufficient.
Unclassified deployment
LLM applications are in production outside the model inventory: no classification decision was made, validation was never commissioned, and neither disparate impact testing nor independent review happened. When the first examiner asks, findings land across all five decision areas at once.
Inventory and accuracy monitoring
LLM applications are in the model inventory and overall accuracy is tracked. Vendor models are still treated as outside the validation requirement. Neither disparate impact testing nor independent review has been conducted. Examination produces targeted findings on those gaps, which are more manageable than Stage 1 but still require remediation before the next cycle.
Documented, validated, monitored
All five decisions are made and documented before go-live. Vendor LLMs are validated at the application layer, with documentation of what could and could not be verified. The institution has disparate impact results on its own data, an independent review on file, and monitoring running from the first day in production.
The LLM model risk documentation checklist
This checklist covers the documentation an institution should have on file for each LLM application that informs financial decisions, before that application is examined. These are the records most likely to be requested in an MRM-focused examination and most likely to be absent when teams have treated their LLM applications as software tools rather than models.
"SR 26-2 tells banks to determine suitable controls for generative AI themselves. That determination is a document the examiner will ask for. Most teams have not written it."
What to do this week
01 Inventory every LLM application that informs a financial decision and assess each one against the classification criteria
Start with a list of every LLM application, chatbot, summarization tool, or AI-assisted workflow that produces an output a financial professional reads before making a credit, fraud, risk, or compliance decision. For each, determine whether it meets the institution's model definition under SR 26-2. Record the determination and the rationale, signed by the MRM owner. This inventory will almost certainly include applications the MRM team was not previously aware of. Finding them now, before an examination, is worth considerably more than finding them in response to an examiner's request.
02 Commission application-layer validation for any vendor LLM in production financial use
Identify every LLM application where the model is supplied via a vendor API and the application informs financial decisions. For each, determine what institution-specific validation has been conducted. If the answer is that the vendor's model card or responsible use documentation is the only validation record, commission an application-layer validation using the institution's own data before the next examination cycle. The validation does not require vendor cooperation and can be conducted entirely from the institution's side by testing the application's outputs on a labeled sample drawn from the institution's operational data.
03 Run a disparate impact screen on current production LLM outputs this quarter
Pull a sample of the last 90 days of outputs from any LLM application that informs credit, insurance, or fraud decisions. For US institutions, segment by race, age, gender, and national origin. For EU-regulated applications, follow the EU AI Act's technical documentation requirements for the specific high-risk use case. Produce accuracy and outcome metrics broken down by segment and document the results. If this screen surfaces a disparity, the institution is better positioned having found it internally than having it surface in a fair lending examination. If it surfaces no disparity, the documentation of that finding is itself a compliance asset.
04 Schedule the independent validation review before go-live for any LLM application currently in development
For any LLM application currently in development or pilot, add an independent validation review to the go-live gate. Identify the reviewer, whether internal or third-party, before the application reaches the final stages of development. Waiting until development is complete to find a validator adds delay, but more importantly it removes any opportunity for the validator's findings to influence the application's design before the final architecture is set. The independent review should be scoped and scheduled before development is complete, not after the team has committed to a specific architecture and go-live date.
Let 10decoders build your LLM model risk framework before the examination
We produce the model inventory classification, application-layer validation documentation, disparate impact analysis, and ongoing monitoring architecture that SR 26-2 requires FinTech teams to determine and document independently. Our FinTech AI practice has worked with institutions under OCC, Fed, and EBA oversight. We deliver documentation that holds up to examiner review, not just internal review.