Fallback design when AI services are unavailable

Plain language meaning

Fallback design when AI services are unavailable explains how banks continue critical operations when model serving, feature lookup, retrieval, external vendors, streaming consumers or decision-support tools fail.

This topic is about operational resilience for AI-enabled banking. It is not about pretending the AI layer will always be available or silently skipping controls.

In a real bank, this is not a loose technology choice. It affects customer outcomes, operational queues, payment execution, risk decisions, regulatory evidence, audit replay, privacy obligations and production resilience. AI should improve decision support and operating quality, but it must remain inside clear banking ownership and control boundaries.

Where it sits in the banking AI journey

This card belongs to Banking AI Architecture. The working flow is AI dependency, Failure detected, Fallback decision path, Controlled operation, and Recovery evidence.

Read the flow as a bank operating model. Every stage needs a business owner, a source system, a data definition, a timing rule, an exception path, a fallback option, a monitoring requirement and retained evidence. That is the difference between a useful AI pattern and an uncontrolled technology shortcut.

Banking data and evidence

The important data points are service health, error code, timeout, fallback rule, case severity, customer impact, recovery time, and missed score. These items matter because they can alter risk scoring, payment treatment, customer communication, operational priority, reconciliation status, compliance review, model monitoring and management reporting.

The evidence pack should include availability alert, fallback log, manual decision record, incident ticket, customer-impact note, recovery report, and lessons learned. A strong bank can replay the journey from source data to transformed input, model or rule output, human action, system outcome and monitoring result. A weak bank only knows that a process ran.

Controls that make AI adoption safe

The core controls are health check, circuit breaker, manual queue, default policy, incident escalation, customer-impact review, and post-incident learning. These controls stop AI from drifting away from banking purpose, approved policy, data governance, model-risk expectations, operational resilience, customer fairness and auditability.

The practical design should define what AI may recommend, what it must never decide alone, which deterministic rule remains authoritative, who owns overrides, how degraded service is handled and what evidence is retained. Without that, the bank may gain speed but lose explainability and control.

Data, architecture and resilience lens

AI in banking depends on the quality of the surrounding architecture. The model can only be as reliable as the data contracts, event meanings, feature definitions, API controls, batch controls, reconciliation rules, monitoring signals and fallback processes that feed and govern it.

A bank-grade design therefore connects channels, source systems, payment hubs, risk systems, data platforms, feature stores, model serving, policy engines, case tools, audit logs and reporting layers. It also defines degraded operation, recovery evidence and post-incident learning before production use.

Regulatory and governance lens

Federal Reserve SR 26-2, dated 17 April 2026, gives revised model-risk guidance for traditional models and non-generative AI models used by banking organisations, including development, validation, monitoring, change control and governance.

NIST AI RMF 1.0 uses Govern, Map, Measure and Manage functions for AI risk management, and NIST AI 600-1 adds generative-AI risk actions for source grounding, content provenance, data protection, security and human oversight.

BCBS 239 remains current for effective risk data aggregation and risk reporting, and the Basel Committee's January 2026 newsletter reiterates the importance of accurate, comprehensive and timely data capabilities in banks.

FFIEC Architecture, Infrastructure and Operations guidance expects financial-institution technology environments to be governed, resilient, secure, monitored, documented and aligned to business risk.

CPMI's February 2026 updated harmonised ISO 20022 data requirements show why consistent structured data matters for interoperable cross-border payment processing and monitoring.

CPMI-IOSCO Principles for Financial Market Infrastructures explain governance, comprehensive risk management, liquidity risk, settlement finality and operational reliability for payment, clearing and settlement systems.

OFAC's Framework for Compliance Commitments describes sanctions compliance programme components including management commitment, risk assessment, internal controls, testing and auditing, and training.

FFIEC BSA/AML examination guidance expects suspicious activity monitoring systems to be risk-based, explainable by management, periodically reviewed and independently validated where appropriate.

Diagram walkthrough

Read the diagram from left to right as AI dependency, Failure detected, Fallback decision path, Controlled operation, and Recovery evidence. It is a control map, not decoration. It shows how banking data, AI support, policy control, human accountability and audit evidence should connect.

Use it as a 30-minute study method. For each box, ask which system creates the data, which rule or model acts on it, what can go wrong, who can override it, how the fallback works, what customer or regulatory impact exists and what evidence proves the final state.

Most important mistake to avoid

The common failure is designing AI as a mandatory step in a critical bank flow without defining what the bank does when the service is slow, unavailable, wrong or disconnected.

The correction is disciplined scope. Keep the topic anchored to banking purpose, prove the data path, make ownership visible, test failure behaviour, record the evidence and make the final outcome explainable without depending on memory or assumptions.

A fallback matched to the business decision

A fraud model stops responding during a busy payment window. The bank's fallback cannot be a single rule that says "continue". Some payments may need a deterministic control and a review queue; others may need a temporary hold under the approved policy. The decision depends on product, channel, risk, customer promise and the available control stack. The architecture should document those choices before the outage, including who can activate, change and end the fallback.

The payment hub needs to distinguish a timeout from a valid low-risk score. It records the failed request, elapsed time, model version and fallback path, then produces a clear payment status. A retry should not release a payment that was already held or send a duplicate instruction. Operations needs a queue of affected items and a method to reconcile their final outcomes. A customer-facing message should avoid claiming a decision that has not occurred.

Recovery is more than restarting a service. The owner checks whether requests made during the outage were processed under fallback, whether any scores arrived late and whether those late scores should be ignored or used for review. The team compares case counts with channel and payment-hub records. It then decides whether any customer communication, correction or additional investigation is required. A shadow replay can help measure model impact, but it must not quietly rewrite the original decision.

The analyst should test total outage, slow responses, partial feature failure and inconsistent versions across instances. Each case needs an observable control action and an owner. Monitoring should expose the proportion of decisions using fallback, their outcomes and the point at which normal processing resumed. A service availability percentage alone would miss a technically healthy model that returned unusable responses.

Define the failure before choosing the fallback

An AI service can be unavailable even when its HTTP endpoint returns success. A fraud model may score a payment with a stale feature snapshot. A credit model may receive an incomplete bureau record. A retrieval assistant may produce fluent text after its approved corpus stopped updating. A streaming consumer may lag while the model itself is healthy. The fallback plan should distinguish outage, timeout, malformed input, stale or missing data, low-confidence output, vendor failure, and a suspected integrity or security incident. Each has a different safe response.

Start with the decision's consequence and deadline. A payment may need a response within seconds. A mortgage application can often wait for a manual review. An AML alert should not disappear because a ranking model is unavailable. A treasury forecast may be deferred until the next data refresh, while the underlying ledger and limits still operate. An internal assistant can abstain, direct the user to an authoritative source or stop drafting. There is no universal rule that every model outage should fail open or fail closed. The owner must decide by use case, legal obligation and risk appetite.

Draw the dependency graph for a live request: channel, authentication, source feeds, feature lookup, model endpoint, policy service, case tool, notification, transaction system and evidence sink. Mark the dependencies that are essential to the underlying banking process and those introduced by AI. A feature store outage may require a different path from a policy engine outage. Deterministic sanctions controls and payment authorization cannot be bypassed simply because the fraud model failed. An audit-log failure may change whether a decision can lawfully or safely proceed even if the model can still score.

Classify degraded operating modes

An approved degraded mode can use a prior validated rule set, a conservative policy threshold, a human queue, a reduced payment limit, delayed processing or a complete pause. Specify the product, channel, transaction value, geography and customer segments to which the mode applies. A manual queue has finite capacity; it is not a magical substitute for an endpoint handling thousands of requests per second. A decision to hold payments has customer and liquidity effects. A decision to release them can increase fraud exposure. Evaluate both using plausible incident volumes and durations.

For a payment fraud score timeout, a bank might allow low-value, known-beneficiary transfers under deterministic limits while routing higher-risk or novel patterns to review. This is a design example, not a default recommendation. The bank should test the fallback on historical and simulated traffic, including holiday peaks and emerging scams, and measure losses, holds, throughput and customer complaints. Hard sanctions or legal holds remain separate mandatory controls. A fallback policy version and activation reason must be recorded for each affected instruction.

For credit decisions, abstaining and referring to an underwriter is often more defensible than replacing a missing model score with a fabricated value. The application should retain the submitted information and the exact missing dependencies. A specialist can request a refreshed bureau response or use an approved manual policy. If the bank uses a previous model version, it must confirm that the feature schema, calibration and approval state still match the live decision context. Rolling back code while keeping incompatible current features is not a valid fallback.

For an AML prioritization model, an outage should not suppress the creation of underlying alerts. A rules engine may continue producing cases, and the operations team can use an approved queue order while model ranking is unavailable. Capacity and service-level breaches should be escalated. If a screening service itself fails, the relevant legal and policy controls determine whether affected transactions are held. A machine-learning failure and a sanctions-list failure must be diagnosed and governed separately.

For a generative-AI policy assistant, a safe response to retrieval failure is to abstain or link directly to an authoritative document when possible. The assistant should not answer from its general language-model memory as if it had checked the bank's latest policy. If a reviewer is required, a draft should not be treated as final merely because the review workflow is slow. A vendor outage may allow work to continue through the existing human process with clear communications and capacity planning.

Signals and circuit breakers

A health check that merely calls the model endpoint misses data failures. Monitor feature freshness, completeness, schema compatibility, score distributions, model error codes, latency and response validity. Monitor policy actions and downstream case or payment acknowledgments too. Define an error budget or service-level objective for each decision path, with a window and owner. A trigger such as repeated timeout, missing mandatory feature or elevated stale-data rate should activate a documented operating mode. Avoid a trigger that switches back and forth as traffic fluctuates.

A circuit breaker can stop repeated calls to a failing dependency and protect upstream capacity. Its states should be visible to operators and captured in request records. Define how many failures open it, how long it remains open, what limited probe closes it and who may override it. If the service recovers technically but its feature feed is still stale, reopening the circuit should not resume automated decisions. Recovery requires a data and business check, not just a green network probe.

Timeouts need a full latency budget. If the payment hub has 200 milliseconds, a model call cannot consume 195 milliseconds while feature lookup, policy checks and logging still need time. Retries can amplify an incident: thousands of queued requests may repeatedly hit a struggling vendor. Define bounded retries, backoff, idempotent instruction IDs and a final fallback deadline. A late model response should not modify an already executed payment action. Measure queue age as well as endpoint latency.

Missingness deserves its own branch. A zero velocity feature may mean no prior payments or a failed ingestion feed. The feature contract should carry freshness and validity flags. If a critical input is missing, the model may reject the request, use a validated missing-data strategy or escalate. Which route is allowed depends on the validation evidence for that model and the decision's risk. Filling every blank with zero during an outage can shift an entire population into an apparently low-risk band.

Human capacity is a dependency

An incident plan should estimate how many decisions will arrive per hour and how many trained reviewers can resolve them. If a model normally triages 100,000 alerts into a small review queue, reverting all of them to manual review is impossible. Define tiers: immediate critical review, deferred lower-priority cases, customer notices where appropriate and a maximum backlog age. Preserve the original alert population so that deferred items do not vanish when the model returns.

Human reviewers need usable evidence. The case screen should say which dependency failed, which facts are current, which model output is absent or unreliable, what rules still applied and what authority the reviewer has. An operator should not be asked to guess a missing score. Overrides should record reason and user identity. Escalation to legal, compliance, fraud, model risk and customer operations should be tied to concrete incident conditions rather than an indiscriminate notification list.

Shift handovers matter. A degraded mode may last overnight or across a holiday. Record active policy version, affected population, backlog, sampled errors, decisions pending and next review time. A runbook must identify who can activate, restrict and end the fallback. If only one engineer knows how to switch paths, the resilience design has a single human point of failure.

Failure exercise: feature store lag

At 09:00, a stream processor stops updating beneficiary-velocity features. The model endpoint continues to return scores, so API availability stays at 100 percent. At 09:04, a freshness monitor sees the latest processed event falling behind. At 09:06, the alert owner confirms that the issue is not just delayed telemetry. The policy engine enters an approved stale-feature mode for transactions whose freshness watermark exceeds the limit. Some known-beneficiary low-value transfers remain eligible under independent rules; higher-risk payments enter a bounded queue. The exact actions reflect the bank's approved policy, not an improvised engineer decision.

The incident record should include the affected interval, source partition, watermark, feature versions, model requests, fallback actions, customer outcomes and queue age. If recovery occurs at 09:30, the team should not replay old feature events and retroactively overwrite already executed decisions. Instead it computes which decisions used stale inputs, assesses their outcomes and determines whether cases or customer remediation are needed. A clean dashboard after replay does not prove the decisions made during the gap were sound.

Test a correlated failure too: the same message broker feeds features and audit events. A broker outage can impair both scoring quality and evidence capture. Independent health probes, local decision records and bounded durable queues can reduce the risk, but each has capacity limits. The runbook should say what happens when the evidence path is unavailable.

Failure exercise: model vendor timeout

A third-party scoring service begins timing out during a payment peak. The bank distinguishes a vendor network problem from invalid requests and watches the proportion of decisions affected. It uses a circuit breaker to avoid exhausting connection pools, invokes the approved local policy path and tracks payment holds, releases, fraud referrals and customer contacts. A vendor status page is useful context but is not proof of the bank's actual impact. The bank's own traces and reconciliation counts establish which instructions took the fallback.

When the vendor returns, the team sends synthetic and controlled live probes, checks response schema and version, and compares scores on a sample of inputs where lawful and appropriate. It gradually restores traffic while watching latency, distributions and exception rates. It does not replay model calls as if they were new payment instructions. An incident review estimates additional fraud exposure and customer friction under the fallback, allowing for delayed labels and uncertain attribution.

Failure exercise: retrieval integrity

A policy assistant's index pipeline succeeds technically but ingests an obsolete draft procedure as current. The service is available, and it cites the wrong document convincingly. A reviewer spots the mismatch. Operators freeze the affected corpus version, disable the topic or assistant if needed, and direct staff to the approved source. The incident team identifies drafts generated from the erroneous index, checks whether any were used, and corrects affected communications through the bank's process.

Recovery requires the source owner to validate effective dates, the retrieval team to rebuild or filter the index, and a reviewer to test representative questions, including conflicting versions and no-answer cases. The bank should preserve the problematic responses for investigation under access and retention controls. This is a fallback triggered by output integrity, not a server outage.

Evidence and measurement

For every degraded decision record, retain the reason the normal AI path was unavailable, detection timestamp, active fallback version, source validity, decision owner, final action and later outcome link. Count eligible requests, successfully scored requests, rejected inputs, fallbacks, manual referrals and unresolved cases. Reconcile them against transaction or application populations. A timeout metric alone cannot show whether customers were blocked or risky payments were released.

Measure the distribution of fallback effects. Compare fraud losses and false holds over a relevant mature period, credit referral duration by segment, AML case backlog and assistant correction frequency. Because outage traffic can differ from ordinary traffic, a raw before/after rate may mislead. Segment by channel, value, customer history and time; disclose uncertainty and delayed outcomes. Review impacts on vulnerable customers and the availability of human assistance where relevant.

Track time to detect, time to activate the approved mode, time to recover service, time to clear backlog and time to complete customer-impact review. Recovery is not complete when an API turns green; outstanding decisions, duplicate messages, stale caches and communications may remain. An incident owner should close each workstream with evidence.

Pre-release tabletop and live drills

Run a tabletop with business, technology, model risk, fraud, compliance, operations and customer teams. Inject a slow model, a stale feature feed, a malformed vendor response, a logging sink outage and an unexpectedly large manual queue. Ask who sees the signal, who decides the mode, what the customer experiences and how to find the affected population. Resolve missing authority or runbook steps before production.

Then run controlled drills in a safe environment, and where appropriate a bounded live exercise. Verify circuit-breaker thresholds, queue capacity, idempotent recovery, monitoring, alert routing, access to case evidence and rollback. A drill should include a late model response and a partial recovery so that operators cannot rely on an unrealistically clean restart. Store results, defects and owners with the approved release record.

The final acceptance question is whether the bank can operate the underlying service for a defined period under the approved degraded mode, explain every affected AI decision, and restore normal processing without duplicating actions or losing cases. If the answer is unknown, the fallback has not been proven.

Decisions by use case

In card fraud detection, an unavailable model can affect authorization in a narrow time window. The issuer may have network-level rules, merchant and customer limits, and independent authentication controls. A fallback must state whether a transaction is approved, challenged or declined when its risk score is missing. It should account for card-present versus remote purchases, cross-border use, customer history and amount. A blanket decline can block legitimate customers at scale. A blanket approval invites losses. Simulate both on representative transaction populations and test against the scheme and issuer's operational constraints.

For account-to-account payments, the bank may receive an irrevocable instruction with a tight processing deadline. The fraud score may be one input to an orchestration policy; other checks such as account status, sufficient funds and legal restrictions remain authoritative. A decision log needs the model-call deadline and the point after which a late answer cannot influence settlement. If the payment is held for review, the customer-facing status should accurately reflect the hold rather than implying that funds have arrived. The queue must reconcile to the payment hub so that cases do not remain unresolved after a model service recovers.

For onboarding identity verification, a document-recognition model may become unavailable while identity checks remain necessary. A branch or specialist review may be a suitable path at low volume, subject to approved controls and access to documents. If a large digital campaign creates a surge, the manual team may be unable to absorb it. A controlled pause with a truthful pending status may be safer than approving applicants without the required check. The bank should distinguish model failure from image quality or customer-supplied evidence gaps.

In a credit line management system, a batch model may refresh scores overnight. Missing a single refresh should have a clearly defined effect on eligibility and limits. Carrying a previous score forward may be permissible only within a validated age window and policy; a stale score for a newly delinquent customer is not equivalent to a freshly observed score. New or materially changed applications can be referred, while routine unchanged accounts may continue under existing approved limits. The owner should define the age threshold and the population for which the last good value can be used.

For collections prioritization, a ranking model can fail without stopping all customer contact. The team can use an approved non-model queue and maintain protections on contact frequency, hardship treatment and consent. The fallback should not reorder cases solely by expected balance if it ignores customer vulnerability. Evaluate who waits longer and who receives additional contact. A new model score computed after the fact must not be used to pretend the earlier contact order was model-driven.

For treasury liquidity forecasting, the bank can retain the last validated forecast as a reference while staff use current ledger balances, cash-flow schedules and liquidity limits to make decisions. The forecast's age should be visible; a stale prediction should not appear as a current estimate. A missing forecast during a market stress period has greater consequence than during a quiet period. Establish escalation thresholds based on uncertainty and exposure rather than a simple uptime percentage.

For an operations copilot, the fallback may be the documented manual procedure. This is workable only if staff know where the authoritative procedure lives and its current version. An assistant outage should not remove access to the underlying source. If the model generated a draft before failing, the human reviewer should know whether its citations were verified. Avoid a workflow in which an unreviewed draft automatically advances because the model or review service timed out.

Avoid hidden fallback paths

Software teams often add implicit defaults for resilience: a missing field becomes zero, a timeout is treated as a low score, an old cache entry is used, or a failed policy call is silently ignored. These paths may never appear in the business runbook. Inventory defaults in every integration layer and test them with fault injection. The status vocabulary should distinguish no score, score zero, rejected input, timeout and stale input. A score zero can be a legitimate output; using it as a missing-value sentinel makes later analysis unreliable.

The fallback should also be idempotent. A retry of the same payment request must refer to the same business instruction and must not create a second transfer or case. If a model response arrives after a timeout, the orchestrator should record it as late and apply the already chosen action unless an approved separate process calls for review. A replay for investigation is not an authorization to re-execute the original instruction. Use distinct identifiers for business request, model attempt, decision and execution.

Dependencies can fail together. A shared cloud region may host the feature store, model endpoint and case queue. A shared identity provider may prevent both automated and manual reviewers from accessing the system. An external vendor may provide both scoring and the data needed by the fallback rule. Test the actual independence of the fallback with failure-domain diagrams and drills. A manual path in the same unavailable interface is not independent.

Governance of an emergency change

If an incident requires a policy outside the approved fallback menu, identify the authorized decision maker and record the rationale, duration, scope and compensating controls. Emergency change management can be faster than normal release management, but it should still preserve who approved the action and which transactions it affected. A temporary threshold change is a model-use change with potential fraud, fairness and customer impacts. It should have an expiry and post-incident review.

Model risk teams should know how a degraded mode changes the validated use. A model trained on complete transaction history may be unreliable when only partial history is available; using its score under those inputs is a different use case. A previous model version may have been retired because of known weaknesses. Validation documents should identify permissible fallback input conditions and versions before an outage, so operators do not improvise based on technical availability alone.

The business owner should set a maximum duration for each mode, a point for management escalation and a point where continuing the service is no longer acceptable. A manual queue may operate for two hours before backlog makes timely review impossible. A low-value rule path may be acceptable during a brief network disruption but unsafe after a prolonged data outage. The actual thresholds must be based on the bank's volumes, obligations and evidence, and reviewed after incidents.

Recovery and reconciliation

Recovery begins by verifying dependency health, data freshness, model and policy versions, and downstream capacity. Process held items in a controlled order, honoring deadlines and customer communication. Reconcile source instructions to model requests, fallback decisions, case records, final payment or application status and customer messages. Do not simply drain a queue as quickly as possible: a burst can recreate the vendor overload or pass stale feature snapshots into the restored model.

Some deferred decisions may need current data and a new assessment; others must retain the policy and facts that governed the original request. Document which time semantics apply. For an unexecuted payment, a fresh screening or fraud check may be needed before release. For a settled payment, later scoring may be useful for investigation but cannot retroactively change settlement. For an application awaiting manual review, a refreshed bureau record may require consent or a new decision process. The runbook should make these distinctions explicit.

Close the incident only after the backlog is reconciled, customer-impact analysis is complete and monitoring windows show stable behavior. Keep an affected-decision register with owner and disposition. Where outcomes take months to mature, schedule later analysis of losses, defaults or complaints rather than declaring no impact immediately. Feed findings into capacity planning, feature design, model validation and future drills.

Review questions

Can an operator identify a stale input while the model API is healthy? Can the bank show precisely which customers took a fallback path? Does every permitted mode have an owner, population, duration and customer treatment? Can manual staff access the evidence they need under a shared infrastructure outage? Does recovery avoid duplicate actions? Are mandatory non-AI controls still enforced? Can independent reviewers reproduce the outage's decision and outcome population?

If any answer relies on an assumption that has never been tested, turn it into a drill with observable pass criteria. The fallback is part of the AI system's behavior, and it deserves the same design, validation and monitoring attention as the normal model path.

Worked acceptance record

Consider a controlled drill of 1,000 payment instructions. The test population includes ordinary repeat beneficiaries, new beneficiaries, high-value transfers, duplicate retries, invalid inputs and cases requiring mandatory screening. The exercise injects a feature-store lag at a known time and a model timeout later. The team states beforehand which instructions should be automatically released, reviewed, held or rejected under each approved mode. It records the expected number in each bucket, the maximum queue age and the required customer status. Afterward it compares the payment ledger, policy decisions, model-call log and case queue using instruction IDs. Any unmatched instruction is investigated, even if aggregate percentages look good.

The test also checks that a rule-only release never overrides a screening hold, a late model answer never causes a second execution, and a case worker cannot resolve a payment that is already terminal without an appropriate correction process. Reviewers inspect a sample of customer messages for accurate wording. They compare affected groups and values against the baseline population, and they record where the simulation cannot capture live adversary behavior. Passing the drill requires evidence of both decision correctness and complete accounting.

Repeat the exercise after a significant feature-contract change, a new serving vendor, a major policy update or a change in payment-hub semantics. The last successful drill of an older architecture is not proof that the current route works. Name an owner for each failed assertion, keep the incident and drill artifacts together, and confirm remediation in a later controlled run. Include a drill of access loss to the manual review tool: if staff cannot see or resolve queued decisions, switch to the separately approved pause or communication path. Reconcile the queue after access returns and verify that no item crossed a deadline without an accountable disposition.

Fallback load exercise

Assume a fraud model normally scores 10,000 instant transfers per hour, with 2 percent referred to analysts. During a feature-store outage, sending every transfer to the same queue would create 10,000 cases per hour. The bank must predefine a feasible limited mode by risk, value and mandatory controls, with explicit capacity and customer treatment. The exact rule depends on its validated evidence; a blanket release or hold is not a universal answer.

Inject a stale feature feed while the model API remains healthy. Check that freshness, not endpoint uptime, triggers the mode. Record every instruction's fallback reason and final status. When the feed recovers, validate state and reconcile pending cases before normal routing. Recomputed scores are analytical evidence, not authority to re-execute settled payments. The drill should measure time to detect, backlog age, false holds and possible losses, then assign owners to any unmet operating limit. Add a late response after a payment has already settled and verify that it is retained for analysis without changing the execution. Reconcile the case queue at restoration so no instruction is abandoned between fallback and normal service.

Primary sources for further study

• NIST AI RMF Measure playbook: data and model evidence
• U.S. Federal Reserve SR 26-2: revised model-risk guidance