FSB Sound Practices for Responsible AI Adoption: SWT3 Evidence Crosswalk

Request the AI-GOV.1 anchor chain for the past 12 months. Verify: (1) review frequency matches the institution's governance charter, (2) the approving authority is board-level or delegated committee, (3) no gaps in the review cycle. Cross-reference with the institution's AI strategy document to confirm the policy reflects the board's stated risk appetite for AI. A continuous chain of PASS verdicts demonstrates active governance. Any FAIL verdict or gap in the chain warrants inquiry into what changed and why.

Verify the AI-GOV.3 anchor exists for each AI use case in the institution's inventory. Confirm that the named accountable parties align with the institution's three-lines-of-defense model. Where AI governance responsibility has been delegated from the board, verify the delegation chain is documented. Institutions using AI across multiple business lines should have separate accountability registrations per line of business.

Agent identity is the foundation of accountability for agentic AI in financial services. Verify that every agent with operational authority (trade execution, payment initiation, customer interaction) has an AI-ID.1 anchor. Confirm the identity links to a named human responsible party and an organizational unit. For institutions using agent directories (Visa Agentic Directory, internal registries), verify the SWT3 agent identity matches the directory registration. An unidentified agent operating in production is an accountability failure -- if something goes wrong, the institution cannot demonstrate who was responsible.

For SP12 compliance, request AI-GOV.5 anchors for each third-party AI provider the institution depends on. Verify: (1) the assessment covers performance, transparency, and data handling, (2) concentration risk is evaluated (what happens if this provider fails?), (3) business continuity plans exist for critical AI dependencies. The FSB explicitly calls out concentration risk in third-party AI -- ask whether the institution has assessed what percentage of its AI-dependent processes rely on a single provider.

The FSB's proportionality principle is central to SP3 and SP5. Verify that AI-RISK.1 anchors exist for every AI use case in the institution's inventory, not just high-profile deployments. Confirm that risk classification drives control intensity -- a credit scoring model should have different controls than an internal chatbot. Ask the institution how it classifies "material" AI use cases and compare against the FSB's guidance on financial stability impact, consumer harm potential, and operational dependency.

SP3 requires that AI risk management goes beyond normal operations. Request AI-SAFE.1 anchors and verify they cover failure scenarios: What happens when the model returns unexpected outputs? What happens when the data feed is interrupted? What is the fallback when human oversight is unavailable? Institutions with high-materiality AI use cases should have tested these scenarios, not just documented them.

SP3's documentation requirement is not satisfied by a static policy document alone. Verify that AI-AUDIT.1 anchors demonstrate continuous, automatic event logging for each AI system in the institution's inventory. Confirm the audit trail covers: (1) inference events for high-materiality use cases, (2) configuration changes to models and guardrails, (3) access events for sensitive AI infrastructure. Ask the institution how long audit records are retained and whether the retention period meets the supervisory expectation for their jurisdiction. An AI system with no audit trail cannot satisfy SP3 regardless of how well its governance policy is written.

AI-FAIR.1 is critical for any institution using AI in credit decisions, insurance underwriting, hiring, or customer pricing. Verify: (1) the evaluation covers all protected attributes required by the institution's jurisdiction (race, gender, age, disability at minimum for US institutions under ECOA/fair lending), (2) the fairness metric is appropriate to the use case (disparate impact ratio, equalized odds, demographic parity), (3) evaluations are performed both pre-deployment and at regular production intervals -- not just once at launch. The FSB does not prescribe a specific fairness standard, but examiners in jurisdictions with fair treatment obligations will expect documented evidence. An institution that cannot produce AI-FAIR.1 anchors for its consumer-facing AI models has an unaddressed risk under SP3.

AI-DRIFT.1 provides direct evidence for SP9 (performance management) and indirect evidence for SP4 (adaptability). Organizational adaptability is primarily a governance process -- SWT3 does not witness whether the institution learned or restructured. What the drift anchor chain provides is the continuous monitoring evidence that demonstrates the organization is responding to findings: when drift is detected (FAIL verdicts), the subsequent actions (retrain, recalibrate, escalate) should be visible in the anchor timeline. The governance decision to adapt must be documented separately, but the evidence that adaptation was needed and that the institution responded is captured here. Review the drift time series: (1) monitoring frequency should be proportionate to materiality, (2) when FAIL verdicts appear, verify the institution took action, (3) the absence of FAIL verdicts over an extended period could indicate either a stable model or inadequate thresholds. Ask how thresholds were set and when they were last reviewed.

Clearing levels are SWT3's mechanism for proportionality. Verify that high-materiality AI use cases (credit decisions, fraud detection, AML) are assigned Clearing Level 2 or 3, not Level 0 or 1. Ask why each level was chosen and whether the assignment has been reviewed since deployment. A consumer-facing chatbot at Level 3 and a credit scoring model at Level 0 would be a red flag for proportionality failures.

Model registration is the foundation of SP6. Verify that AI-MDL.1 anchors exist for every AI model in production. Confirm the registration captures: model type, version, training data description, intended use, and known limitations. For institutions using third-party models, verify the registration includes the provider's model card or equivalent documentation. An unregistered model in production is a governance failure regardless of its performance.

SP6 requires evaluation before deployment, not just after. Verify the AI-MDL.3 anchor timestamp precedes the model's production deployment date. Confirm the evaluation covered the FSB's three dimensions: business objectives (does it solve the right problem?), explainability (can the institution explain outputs to stakeholders?), and operational resilience (what happens when it fails?). A model deployed without a pre-deployment evaluation anchor is a governance gap.

Weight integrity is critical for institutions using open-weight models or fine-tuned variants. Verify the AI-MDL.5 hash matches the hash recorded at evaluation time (AI-MDL.3). Any mismatch indicates the production model has been modified since evaluation -- this could be legitimate (a planned update) or a governance failure (an uncontrolled change). Ask the institution how it controls the path from evaluation to production deployment.

SP7 is one of the FSB's most detailed practices. Verify AI-DATA.1 anchors cover: (1) training data quality at model development time, (2) ongoing production data quality at inference time, (3) data lineage from source to model input. For institutions using third-party data providers, verify the data quality assessment covers the provider's data handling practices. The FSB specifically calls out data privacy and security -- confirm that data handling evidence addresses both.

For institutions operating across jurisdictions, verify that AI-DATA.2 evidence addresses the data protection requirements of each jurisdiction where the AI system operates. The FSB does not prescribe a specific data protection standard, but institutions are expected to demonstrate that data handling meets local requirements (GDPR, CCPA, PDPA, PIPL as applicable).

RAG provenance is increasingly relevant for financial institutions using AI assistants that query internal knowledge bases, regulatory databases, or market data. Verify that AI-RAG.1 anchors document which sources were consulted for each high-stakes inference. If the institution uses RAG for customer-facing advice or compliance determinations, the provenance chain must be complete enough to explain the output.

The FSB acknowledges that not all AI systems are equally explainable. Verify: (1) AI-EXPL.1 anchors exist for high-materiality use cases, (2) the explainability method is appropriate to the model architecture (SHAP for tabular models, attention visualization for transformers), (3) explanations are generated for the right audience -- a board summary differs from an examiner's technical report. If the institution uses "compensating controls" instead of direct explainability (as the FSB permits), verify those controls are documented and the rationale is explicit.

AI-EXPL.2 distinguishes between "explanation generated" and "explanation understood." For consumer-facing applications (credit decisions, insurance underwriting), verify the interpretability assessment reflects whether a typical consumer could understand the reason for the decision. For board reporting, verify the summary is meaningful to non-technical directors. The FSB's "stakeholder-tailored transparency" requires different evidence for different audiences.

Verify that AI-TRANS.1 evidence covers all three FSB stakeholder groups: (1) customers who interact with AI-driven decisions, (2) supervisors who need governance documentation, (3) internal functions (risk, compliance, audit) who need operational visibility. Ask whether the institution discloses AI use to customers in plain language, not just in buried terms of service.

SP9's proportionality requirement means monitoring frequency and depth should scale with materiality. A credit scoring model should have daily or weekly performance monitoring; an internal document classifier might be monthly. Verify: (1) AI-PERF.1 anchors exist at the expected frequency, (2) the metrics monitored are appropriate to the use case, (3) threshold breaches triggered action (retrain, escalate, or decommission). The FSB specifically mentions testing -- ask for evidence of pre-deployment testing, not just production monitoring.

Robustness testing goes beyond standard performance monitoring. Verify that AI-ROBUST.1 evidence covers adversarial scenarios relevant to the use case: prompt injection for LLM-based systems, data poisoning for training pipelines, distribution shift for market-sensitive models. Institutions using AI in critical financial infrastructure should demonstrate regular stress testing, not just one-time evaluation at deployment.

SP10 ties human oversight intensity to five dimensions: materiality, risk, autonomy, complexity, and explainability. Verify: (1) high-autonomy systems have stronger oversight than advisory systems, (2) complex or opaque models have more human checkpoints than transparent models, (3) the reviewer is qualified to evaluate the AI output (a compliance officer reviewing a compliance decision, not a helpdesk operator rubber-stamping). Ask the institution how it determines which decisions require AI-HITL.2 (explicit approval) versus AI-HITL.1 (review only).

Delegation evidence is critical for agentic AI deployments in financial services. Verify: (1) the delegation has a named human authority, (2) scope limits are explicit (transaction size, decision type, time window), (3) the delegation has been reviewed within its stated cycle. An AI agent executing trades under delegated authority without a current AI-DEL.1 anchor is operating outside documented governance.

AI-FIN.1 is the critical anchor for agentic commerce in banking. Verify: (1) every agent-initiated transaction above the institution's materiality threshold has an AI-FIN.1 anchor, (2) the anchor timestamp precedes the payment execution timestamp (authorization before action), (3) for transactions above the delegation limit (AI-DEL.1), an AI-HITL.2 anchor confirms human approval occurred. Cross-reference with the payment rail's transaction record -- the payment rail proves the money moved; the SWT3 anchor proves why the agent moved it and whether governance was active. If a transaction dispute arises, the AI-FIN.1 anchor is the institution's evidence that governance existed at the moment of decision.

SP11 is specifically about AI-related cyber risks, not general cybersecurity. Verify that AI-CYBER.1 evidence covers threats unique to AI: model theft/extraction, training data poisoning, adversarial inputs designed to manipulate financial decisions, and prompt injection for LLM-based systems. Ask whether the institution has incorporated AI-specific scenarios into its annual penetration testing and tabletop exercises, as the FSB recommends.

Guardrails are the operational implementation of cyber controls for AI. Verify that AI-GRD.1 anchors are generated continuously (not just at deployment), confirming that guardrails remain active during production operation. A guardrail that was enabled at deployment but disabled during a system update is a common failure pattern. Ask whether the institution tests guardrail bypass scenarios.

AI-SEC.1 complements AI-CYBER.1 by focusing on standard security controls applied to AI infrastructure. Verify that the AI system's access controls are as rigorous as other critical financial systems. Model endpoints, training data stores, and inference APIs should have the same authentication and authorization standards as core banking systems.

Tool execution is where AI risk becomes operational risk. An agent that queries a customer database, initiates a wire transfer, or calls a third-party API is performing actions with real-world consequences. Verify that AI-TOOL.1 anchors exist for every tool call in high-materiality workflows. Confirm: (1) the tool call was within the agent's authorized scope, (2) the tool identity matches an approved tool registry, (3) sensitive tool calls (payment APIs, customer data access) have additional controls (AI-GRD.1 guardrails, AI-HITL.2 approval). An agent executing unwitnessed tool calls is an uncontrolled operational risk.

SP12 is one of the FSB's most operationally significant practices. Verify: (1) the institution has identified all third-party AI components in its stack -- including foundation models, fine-tuning services, data providers, and inference hosting, (2) concentration risk is assessed at the component level (how many critical systems depend on a single model provider?), (3) business continuity plans exist for third-party AI failure. The FSB specifically warns about concentration risk in AI supply chains -- this is the examiner question most likely to reveal gaps.

HBOM-INV.1 provides the component-level inventory that makes SP12 auditable. Verify the HBOM covers: model provider and version, training framework and version, inference runtime, GPU/TPU hardware (relevant for on-premise deployments), and all middleware between the model and the business application. Ask the institution when the inventory was last updated -- a stale HBOM is worse than no HBOM because it creates false confidence.