{ "dataset": { "meta": { "domain": "finance", "domain_slug": "finance", "domain_number": 9, "title": "Apeiris Finance Control Matrix", "description": "Apeiris Finance Control Matrix: 48 machine-readable controls across 6 layers.", "version": "1.1.0", "published": "2026-07-02", "layers": 6, "controls_count": 48, "baseline_controls": [ "MR-01", "MR-08", "MV-01", "MV-08", "FD-01", "FD-08", "FC-01", "FC-08", "FP-01" ], "canonical_prefix": "apeiris://finance/controls/", "attestation_artifact": "FinanceAttestation", "attestation_control": "FG-08", "alias_domain": "financeverifier.ai", "frameworks": [ "anthropic_rsp", "aws_financial", "bcbs_239", "cfpb_ai", "coso_icfr", "eu_ai_act", "ffiec", "finra", "google_financial", "microsoft_rai", "occ_ai", "okta_financial", "omb_a_123", "openai_enterprise", "pcaob_as_2201", "sec_ai", "soc2", "sox", "sr26_2" ], "lenses": [ "financial_controller", "model_risk_officer", "compliance_officer", "internal_audit", "it_operations" ], "license": "CC BY 4.0", "source": "https://apeiris.ai/domains/finance/", "integration_endpoint": "https://apeiris.ai/integration/domains/finance-controls-full.json", "source_freshness": { "status": "current", "checked_on": "2026-07-02", "review_cadence": "quarterly" }, "baseline_control_count": 9, "generated_at": "2026-07-02T00:00:00.000Z", "subtitle": "apeiris.ai/domains/finance \u2014 Apeiris Finance", "site": "https://apeiris.ai/domains/finance", "corpus_url": "https://apeiris.ai/integration/domains/finance-controls-full.json", "schema_version": "1.1.0", "schema_extended_on": "2026-06-29", "extended_schema_fields": [ "validation_objective", "evidence_required", "machine_tests", "human_review", "blocking_effect", "normative_status", "anti_patterns", "update_status" ] }, "controls": [ { "id": "MR-01", "layer": "MR", "plane": "control", "name": "SR 26-2 Model Inventory and Risk Tiering", "plain": "Every financial AI model deployed in the enterprise must be registered in a comprehensive model inventory with assigned risk tiers following Federal Reserve SR 26-2 guidance, including model purpose, owner, validation status, materiality classification, and lifecycle stage.", "threat": { "tags": [ "untracked-model-deployment", "risk-tier-misclassification", "regulatory-inventory-gap", "shadow-ai" ], "desc": "Without a complete model inventory, untracked models make financial decisions with no oversight or validation. Risk tier misclassification leads to insufficient validation rigor for high-impact models. Supervisors expect a complete, accurate inventory consistent with SR 26-2; gaps expose institutions to supervisory criticism." }, "standard": [ { "id": "sr26_2", "section": "\u00a7VI (Model Inventory)", "title": "Model inventory (common industry practice)" }, { "id": "bcbs_239", "section": "Principle 2", "title": "Data architecture and IT infrastructure" }, { "id": "eu_ai_act", "section": "Art. 49", "title": "Registration of high-risk AI systems (EU database, Art. 71)" }, { "id": "coso_icfr", "section": "Component 2", "title": "Risk assessment \u2014 identifying and analyzing relevant risks" } ], "sources": [ { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://finance/controls/MR-01 SR 26-2 Model Inventory and Risk Tiering control.", "reviewed_on": "2026-07-01" }, { "id": "google_cloud_financial_services_ai_2024", "title": "Google Cloud Explainable AI", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/explainable-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_financial_services_ai_2024", "relationship": "informative_reference", "rationale": "Google Cloud's Explainable AI and Vertex AI model governance documentation describes platform capabilities relevant to the apeiris://finance/controls/MR-01 SR 26-2 Model Inventory and Risk Tiering control.", "reviewed_on": "2026-07-02" }, { "id": "aws_financial_services_compliance_2024", "title": "AWS User Guide to Financial Services Regulations & Guidelines in the United States", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/financial-services/security-compliance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_financial_services_compliance_2024", "relationship": "informative_reference", "rationale": "AWS's financial services regulatory guide and compliance tooling document infrastructure-layer capabilities relevant to the apeiris://finance/controls/MR-01 SR 26-2 Model Inventory and Risk Tiering control.", "reviewed_on": "2026-07-02" }, { "id": "occ_2024_7", "title": "OCC Comptroller's Handbook \u2014 Model Risk Management", "authority": "Office of the Comptroller of the Currency (OCC)", "source_type": "guidance", "normative_force": "supervisory-guidance", "version": "1.0", "published_on": "2021-08-18", "retrieved_on": "2026-06-29", "canonical_url": "https://www.occ.gov/publications-and-resources/publications/comptrollers-handbook/files/model-risk-management/index-model-risk-management.html", "license": "public-domain", "status": "current", "flagship": false, "source_id": "occ_2024_7", "relationship": "supporting_guidance", "rationale": "The OCC Comptroller's Handbook Model Risk Management booklet (2021) sets examiner expectations for model inventory and risk-based governance, informing the apeiris://finance/controls/MR-01 SR 26-2 Model Inventory and Risk Tiering control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Centralized model registry with mandatory registration workflow; risk tiering algorithm assigns Low/Medium/High/Critical based on materiality, complexity, and usage context; integration with change management gates deployment of unregistered models.", "steps": [ "Deploy a centralized model registry system with fields for model ID, purpose, owner, training data, validation status, risk tier, and lifecycle stage.", "Define risk tiering criteria based on SR 26-2 materiality factors: financial impact, decision criticality, data sensitivity, regulatory applicability, and model complexity.", "Integrate registry into deployment pipelines so unregistered or untiered models cannot be promoted to production financial systems.", "Establish quarterly reconciliation process to identify models in production that are absent from or inconsistent with the registry." ], "model_risk_officer": { "summary": "The model inventory is the foundation of SR 26-2 alignment. Every model used in a financial decision must appear in the registry with a validated risk tier.", "actions": [ "Define and document risk tiering criteria aligned to SR 26-2 materiality thresholds.", "Conduct semi-annual inventory sweeps to discover unregistered models across all business lines.", "Review and approve risk tier assignments for all High and Critical tier models." ], "failure_signals": [ "Inventory completeness below 98% at any quarterly review.", "More than 5% of production models carrying an unvalidated or expired risk tier.", "Discovery of production models absent from the registry during regulatory examination." ] }, "compliance_officer": { "summary": "The model inventory is the primary regulatory artifact demonstrating SR 26-2 and EU AI Act adherence. Gaps become supervisory findings.", "actions": [ "Map inventory fields to SR 26-2 sections and EU AI Act Article 49 registration requirements.", "Include inventory completeness metrics in quarterly MRM reporting to the board risk committee.", "Ensure EU AI Act high-risk classifications are cross-referenced against SR 26-2 High/Critical tiers." ], "metrics": [ "Inventory completeness rate: target 100% of known production models.", "Risk tier validation rate: 100% of High/Critical models with current validated tier.", "Time to register new model: target \u2264 5 business days from deployment request." ], "failure_signals": [ "Inventory completeness below 98%.", "EU AI Act high-risk models without corresponding inventory registration.", "Supervisory criticism citing inventory gaps." ] }, "internal_audit": { "summary": "The model inventory is the primary population from which audit samples are drawn. Its completeness and accuracy are auditable facts.", "actions": [ "Annually test inventory completeness by cross-referencing against IT asset management, cloud cost data, and vendor contracts.", "Sample 15% of inventory entries and verify accuracy of risk tier, owner, and validation status fields.", "Report inventory gaps as control deficiencies with remediation timelines." ], "failure_signals": [ "Cross-reference discrepancy rate exceeding 2% between inventory and IT asset records.", "Sampled entries with stale (>12 months) validation status exceeding 5%.", "Inventory system lacking audit trail for tier change events." ] }, "financial_controller": { "summary": "The model inventory determines which models require the most rigorous financial controls and SOX-scoping decisions for model-driven financial reporting.", "actions": [ "Review inventory for models that feed financial statements and ensure they are scoped into SOX ICFR assessments.", "Flag Critical-tier models that affect material financial estimates for enhanced CFO sign-off." ], "failure_signals": [ "SOX-scoped models not reflected in the model inventory.", "Material financial models with risk tier below their actual impact level." ] }, "it_operations": { "summary": "IT Operations runs the central model registry behind the enterprise model inventory and risk-tiering register \u2014 integrating it with deployment pipelines, enforcing the automated gates, and keeping the supporting data flows reliable and auditable.", "actions": [ "Integrate the central model registry with CI/CD and runtime tooling so that unregistered or untiered models cannot be promoted to production.", "Automate collection and retention of registry records and tier-change events in immutable, hash-verified storage.", "Monitor pipeline and integration health and alert when production model deployments lack a matching registry entry." ], "failure_signals": [ "Production changes bypass the automated gate so that it is no longer true that unregistered or untiered models cannot be promoted to production.", "Gaps or outages in registry records and tier-change events collection exceeding 24 hours.", "Manual, untracked edits to the central model registry records." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Many institutions maintain spreadsheet-based inventories that lack integration with deployment controls and automated reconciliation." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "Model Risk Management", "IT Operations", "Compliance", "Business Line Owners" ], "frameworks": [ { "framework": "sr26_2", "requirement_id": "\u00a7VI (Model Inventory)", "fit": "direct", "rationale": "SR 26-2 \u00a7VI (Governance and Controls) describes maintaining a model inventory under its Model Inventory subheading \u2014 the guidance itself calls a comprehensive model inventory 'common industry practice' rather than a requirement, and it is principles-based and non-enforceable. Applicability note: the guidance applies to banking organizations with more than $30 billion in total assets; it may also be relevant to smaller organizations with significant model risk exposure.", "normative_force": "supervisory-guidance", "source_version": "2026-04-17", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "eu_ai_act", "requirement_id": "Art. 49", "fit": "direct", "rationale": "EU AI Act Art. 49 requires registration of high-risk AI systems in the EU database established under Art. 71 before placing on the market or putting into service \u2014 an obligation that falls on providers (and on deployers that are public authorities). For financial institutions, a model inventory with EU AI Act classifications per Annex VIII information fields is the prerequisite artifact for meeting or verifying that registration. Note the Act's high-risk net in finance is specific: Annex III point 5(b) covers creditworthiness/credit scoring of natural persons, and 5(c) risk assessment and pricing in life and health insurance.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "bcbs_239", "requirement_id": "Principle 2", "fit": "partial", "rationale": "BCBS 239 Principle 2 (Data architecture and IT infrastructure) requires banks to establish integrated data taxonomies and architecture, including information on the characteristics of the data. A model inventory is the architecture artifact that records which models exist and which data they consume; at BCBS 239 institutions the inventory should be integrated with the broader data architecture; the fit is partial.", "normative_force": "supervisory-guidance", "source_version": "2013", "reviewed_on": "2026-07-02", "basis": "asserted", "relation": "satisfies" }, { "framework": "coso_icfr", "requirement_id": "Component 2", "fit": "partial", "rationale": "COSO ICIF Component 2 (Risk Assessment) requires organizations to identify and analyze risks relevant to financial reporting objectives. Models that drive financial estimates are a risk category requiring enumeration and assessment. The model inventory is the mechanism by which COSO risk assessment extends to AI-driven financial calculations.", "normative_force": "voluntary-standard", "source_version": "2013", "reviewed_on": "2026-06-28", "basis": "asserted", "relation": "informs" }, { "framework": "sox", "requirement_id": "\u00a7404", "fit": "adjacent", "rationale": "SOX Section 404 requires management and auditors to assess the effectiveness of internal controls over financial reporting. Models that contribute to material financial estimates fall within the ICFR scope and must be inventoried to support that assessment. The model inventory is the prerequisite for scoping SOX model-related controls.", "normative_force": "binding-law", "source_version": "2002", "reviewed_on": "2026-06-28", "basis": "asserted", "relation": "satisfies" }, { "framework": "microsoft_rai", "requirement_id": "A1", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal A1 (Impact assessment) requires documented impact assessments identifying intended uses, stakeholders, and potential harms. For institutions using Azure AI services, this goal produces vendor-side governance artifacts that align with the enterprise model inventory and risk-tiering register. The Standard is Microsoft's published internal policy offered as reference practice, not regulatory guidance.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "google_financial", "requirement_id": "Vertex AI Model Registry", "fit": "partial", "rationale": "Vertex AI Model Registry provides versioned model registration, aliases, and deployment state tracking on Google Cloud. For GCP-hosted financial AI systems, this capability supplies the platform-layer support for the enterprise model inventory and risk-tiering register. This is vendor product documentation, not regulatory guidance; it does not address model-layer regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "aws_financial", "requirement_id": "AWS Audit Manager", "fit": "adjacent", "rationale": "AWS Audit Manager automates evidence collection against control frameworks for AWS workloads, and AWS CloudTrail records account-level API activity. For AWS-hosted financial AI systems, this supplies the infrastructure-layer support and evidence stream for the enterprise model inventory and risk-tiering register. This is vendor documentation of real AWS capabilities \u2014 it does not substitute for model-layer validation or regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "occ_ai", "requirement_id": "Model Risk Management booklet (2021)", "fit": "direct", "rationale": "The OCC's Comptroller's Handbook 'Model Risk Management' booklet (version 1.0, August 2021) is the examiner guide for model risk management at national banks and federal savings associations, and describes model inventory and risk-based governance expectations consistent with the interagency model risk guidance. MR-01's inventory and tiering register is the primary artifact an OCC examiner would review under that booklet. The OCC also co-issued the 2026 revised interagency model risk management guidance that the Federal Reserve transmits as SR 26-2.", "normative_force": "supervisory-guidance", "source_version": "1.0 (2021-08)", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" } ], "canonical_id": "apeiris://finance/controls/MR-01", "meta": { "authored_on": "2026-06-29", "schema_version": "1.1.0" }, "validation_objective": "Every financial AI model in production must appear in the centralized model registry with a validated risk tier, owner, validation status, and lifecycle stage assigned; the inventory must achieve 100% completeness as confirmed by cross-reference against deployment pipeline records and IT asset management data, with no unregistered production models identified.", "evidence_required": [ "model_registry_export showing model_id, owner, risk_tier, validation_status, and lifecycle_stage for every registered entry", "cross_reference_reconciliation_report comparing registry entries against IT asset management and cloud cost records, confirming discrepancy rate \u2264 2%", "risk_tiering_decision_record for each High/Critical tier model documenting the materiality factors and criteria applied to the tier assignment with MRO approval timestamp", "deployment_gate_audit_log confirming no production promotions occurred for models without a registry record in the prior quarter", "quarterly_inventory_reconciliation_sign_off signed by Model Risk Officer attesting to completeness" ], "machine_tests": [ "Query production deployment system for all models promoted in the last 90 days \u2192 assert 100% appear in model registry with non-null risk_tier and validation_status fields", "Pull IT asset records tagged as AI/ML systems \u2192 assert cross-reference discrepancy rate against model registry is \u2264 2%", "Query registry for High/Critical tier models \u2192 assert each has a risk_tiering_decision_record with materiality factors and mro_approval_timestamp", "Attempt to trigger deployment pipeline for a model with no registry entry \u2192 assert deployment is blocked with error code=unregistered_model" ], "human_review": [ "Review risk tiering criteria documentation to confirm it addresses SR 26-2 materiality factors including financial impact, regulatory applicability, decision criticality, and model complexity", "Assess quarterly inventory reconciliation report for completeness and verify MRO sign-off attests to no known gaps", "Confirm EU AI Act high-risk classifications in the registry are cross-referenced against SR 26-2 High/Critical tier assignments with no classification mismatches" ], "blocking_effect": "blocks-deployment", "normative_status": "supervisory-guidance", "anti_patterns": [ "Maintaining the model inventory as a spreadsheet without integration into the deployment pipeline, allowing models to be deployed to production without triggering registration", "Assigning risk tiers based solely on developer judgment without applying documented, board-approved materiality criteria aligned to SR 26-2", "Including only internally developed models while excluding vendor-supplied, embedded, or API-accessed AI models from the inventory", "Allowing risk tier assignments to go stale beyond 12 months without re-validation following material model changes or use-case expansions", "Treating the model inventory as a one-time project artifact rather than a continuously maintained operational control with automated reconciliation" ], "update_status": "current", "layer_code": "MR" }, { "id": "MR-02", "layer": "MR", "plane": "control", "name": "Model Risk Governance Policy Framework", "plain": "The institution must maintain a board-approved Model Risk Management policy that governs the full lifecycle of financial AI models \u2014 development, validation, approval, deployment, monitoring, and retirement \u2014 with defined roles, responsibilities, and escalation paths.", "threat": { "tags": [ "governance-vacuum", "policy-gap", "accountability-diffusion", "ungoverned-model-lifecycle" ], "desc": "Without a comprehensive MRM policy, model development proceeds with inconsistent standards, validation is bypassed under business pressure, and no one has clear accountability for model failures. Policy gaps allow business lines to deploy models without independent validation, leading to undetected model errors affecting financial decisions. Regulators treat absent or inadequate MRM policies as a core supervisory finding." }, "standard": [ { "id": "sr26_2", "section": "\u00a7VI (Governance and Controls)", "title": "Governance and controls \u2014 policies and roles" }, { "id": "coso_icfr", "section": "Component 1", "title": "Control environment \u2014 governance and oversight" }, { "id": "eu_ai_act", "section": "Art. 9", "title": "Risk management system for high-risk AI" }, { "id": "sox", "section": "\u00a7302", "title": "Corporate responsibility for financial reports" } ], "sources": [ { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://finance/controls/MR-02 Model Risk Governance Policy Framework control.", "reviewed_on": "2026-07-01" }, { "id": "google_cloud_financial_services_ai_2024", "title": "Google Cloud Explainable AI", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/explainable-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_financial_services_ai_2024", "relationship": "informative_reference", "rationale": "Google Cloud's Explainable AI and Vertex AI model governance documentation describes platform capabilities relevant to the apeiris://finance/controls/MR-02 Model Risk Governance Policy Framework control.", "reviewed_on": "2026-07-02" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Anthropic's Responsible Scaling Policy v3.3 documents the vendor's capability thresholds and safeguards, cited as third-party AI due diligence context for the apeiris://finance/controls/MR-02 Model Risk Governance Policy Framework control.", "reviewed_on": "2026-07-02" }, { "id": "aws_financial_services_compliance_2024", "title": "AWS User Guide to Financial Services Regulations & Guidelines in the United States", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/financial-services/security-compliance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_financial_services_compliance_2024", "relationship": "informative_reference", "rationale": "AWS's financial services regulatory guide and compliance tooling document infrastructure-layer capabilities relevant to the apeiris://finance/controls/MR-02 Model Risk Governance Policy Framework control.", "reviewed_on": "2026-07-02" }, { "id": "ffiec_it_handbook_da", "title": "FFIEC IT Examination Handbook \u2014 Development, Acquisition, and Maintenance", "authority": "Federal Financial Institutions Examination Council (FFIEC)", "source_type": "guidance", "normative_force": "supervisory-guidance", "version": "2024-08", "published_on": "2024-08-29", "retrieved_on": "2026-06-29", "canonical_url": "https://ithandbook.ffiec.gov/", "license": "public-domain", "status": "current", "flagship": false, "source_id": "ffiec_it_handbook_da", "relationship": "supporting_guidance", "rationale": "The FFIEC IT Examination Handbook 'Development, Acquisition, and Maintenance' booklet (2024) sets examiner expectations for technology lifecycle governance, informing the apeiris://finance/controls/MR-02 Model Risk Governance Policy Framework control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Tiered policy structure: board-level MRM policy sets risk appetite and accountability; management-level MRM standard defines lifecycle requirements and validation standards; operational procedures define workflows. Annual review cycle with board risk committee approval.", "steps": [ "Draft a board-level Model Risk Management Policy covering scope, risk appetite, governance structure, and accountability matrix aligned to SR 26-2 (Governance and Controls).", "Develop an MRM Standard that operationalizes the policy with specific lifecycle requirements: development standards, validation requirements by risk tier, approval authorities, deployment gates, and retirement criteria.", "Define and publish roles and responsibilities: Model Owner, Model Developer, Independent Validator, Model Risk Officer, and Validation Committee.", "Establish escalation paths for policy exceptions and model risk limit breaches, including board risk committee escalation thresholds." ], "model_risk_officer": { "summary": "The MRM policy is the governance charter for all model risk activities. The MRO is responsible for maintaining it, ensuring it reflects current regulatory expectations, and enforcing it across all business lines.", "actions": [ "Own the MRM Policy and Standard; lead annual review with input from Legal, Compliance, and Business Lines.", "Maintain the RACI matrix for all model lifecycle activities and communicate it to all stakeholders.", "Report policy exceptions and waivers to the board risk committee with remediation timelines." ], "failure_signals": [ "MRM Policy not reviewed or approved by the board within the last 12 months.", "More than 3 unresolved policy exception waivers open for more than 90 days.", "Validation bypasses not captured under the exception management process." ] }, "compliance_officer": { "summary": "The MRM policy is the primary artifact demonstrating institutional governance of AI model risk to regulators. Its adequacy is assessed during SR 26-2 and EU AI Act compliance reviews.", "actions": [ "Review MRM Policy against current SR 26-2 guidance and EU AI Act Article 9 risk management system requirements annually.", "Ensure the policy explicitly addresses generative AI and LLM models as a distinct risk category.", "Include MRM Policy adequacy assessment in the annual compliance risk assessment." ], "metrics": [ "Policy review cycle completion: target 100% annually.", "Regulatory findings related to MRM policy adequacy: target zero.", "Coverage of all active model risk categories in policy scope: target 100%." ], "failure_signals": [ "Policy scope that excludes AI/ML models or generative AI systems.", "EU AI Act high-risk AI governance requirements not reflected in MRM policy.", "Regulatory examination finding policy inadequate for current model risk profile." ] }, "internal_audit": { "summary": "The MRM Policy is the control standard against which audit tests model risk practices. Audit must assess whether policy requirements are consistently implemented.", "actions": [ "Annually audit a sample of models against MRM Policy lifecycle requirements to assess compliance.", "Test whether independent validation is occurring as required and exceptions are properly documented.", "Assess whether the policy has kept pace with the institution's current AI model risk profile including LLMs." ], "failure_signals": [ "Models in production without evidence of policy-compliant development or validation processes.", "Policy exception process not consistently used for validation bypasses.", "Policy scope not updated to reflect current generative AI and agentic model deployments." ] }, "financial_controller": { "summary": "The MRM policy must address models that affect financial reporting. The Controller must confirm that financially material models are within policy scope and that validation requirements align with SOX ICFR standards.", "actions": [ "Confirm that the MRM Policy scope explicitly includes models affecting financial statement preparation.", "Ensure policy-required validation and approval processes for financial models satisfy SOX 404 control requirements." ], "failure_signals": [ "MRM Policy that excludes models used in financial close or reporting processes.", "Policy validation requirements insufficient to satisfy external auditor expectations for ICFR." ] }, "it_operations": { "summary": "IT Operations runs the policy repository and its control mappings behind the board-approved model risk management policy framework \u2014 integrating it with deployment pipelines, enforcing the automated gates, and keeping the supporting data flows reliable and auditable.", "actions": [ "Integrate the policy repository and its control mappings with CI/CD and runtime tooling so that policy-mandated controls (registration, validation, approval) are enforced as pipeline checks.", "Automate collection and retention of policy-control enforcement logs in immutable, hash-verified storage.", "Monitor pipeline and integration health and alert when pipeline checks mapped to policy requirements are disabled or bypassed." ], "failure_signals": [ "Production changes bypass the automated gate so that it is no longer true that policy-mandated controls (registration, validation, approval) are enforced as pipeline checks.", "Gaps or outages in policy-control enforcement logs collection exceeding 24 hours.", "Manual, untracked edits to the policy repository and its control mappings records." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Many institutions have outdated MRM policies written before LLMs and agentic AI existed; policy refresh to cover generative AI is a current priority gap." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "Model Risk Management", "Legal", "Compliance", "Board Risk Committee" ], "frameworks": [ { "framework": "sr26_2", "requirement_id": "\u00a7VI (Governance and Controls)", "fit": "direct", "rationale": "SR 26-2 \u00a7VI (Governance and Controls) describes board-approved policies and defined roles and responsibilities spanning the model lifecycle as elements of sound model risk management. A board-level MRM policy framework operationalizes those supervisory expectations; the guidance is principles-based and does not mandate a specific policy structure.", "normative_force": "supervisory-guidance", "source_version": "2026-04-17", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "eu_ai_act", "requirement_id": "Art. 9", "fit": "direct", "rationale": "EU AI Act Article 9 requires providers of high-risk AI systems to establish, implement, document, and maintain a risk management system throughout the AI system lifecycle. A formal MRM policy framework is the organizational prerequisite for fulfilling this obligation at scale across multiple model deployments. The policy must address the full lifecycle including post-market monitoring.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-06-28", "basis": "anchored", "relation": "satisfies" }, { "framework": "coso_icfr", "requirement_id": "Component 1", "fit": "partial", "rationale": "COSO ICIF Component 1 (Control Environment) establishes governance, tone, and accountability as foundational to internal controls. An MRM Policy Framework is a control environment artifact establishing accountability for model risk. COSO-aligned entities must demonstrate that model risk governance is reflected in their overall control environment.", "normative_force": "voluntary-standard", "source_version": "2013", "reviewed_on": "2026-06-28", "basis": "asserted", "relation": "informs" }, { "framework": "sox", "requirement_id": "\u00a7302", "fit": "adjacent", "rationale": "SOX Section 302 requires CEOs and CFOs to certify the effectiveness of disclosure controls and procedures, including controls over model-driven financial disclosures. An MRM policy that governs models used in financial reporting is a prerequisite for these certifications. Regulatory examination of MRM governance policy deficiencies can create SOX certification risk.", "normative_force": "binding-law", "source_version": "2002", "reviewed_on": "2026-06-28", "basis": "asserted", "relation": "satisfies" }, { "framework": "omb_a_123", "requirement_id": "Section II.A", "fit": "partial", "rationale": "OMB Circular A-123 requires federal agencies and government-sponsored entities to establish enterprise risk management frameworks. For GSEs and federally chartered financial institutions, an MRM policy aligned to A-123 demonstrates integration of model risk into enterprise risk governance. The circular's requirement for documented management controls applies to model governance.", "normative_force": "supervisory-guidance", "source_version": "2016", "reviewed_on": "2026-06-28", "basis": "asserted", "relation": "satisfies" }, { "framework": "microsoft_rai", "requirement_id": "A2", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal A2 (Oversight of significant adverse impacts) requires defined review and oversight processes for AI systems that can cause significant adverse impact. For institutions using Azure AI services, this goal produces vendor-side governance artifacts that align with the board-approved model risk management policy framework. The Standard is Microsoft's published internal policy offered as reference practice, not regulatory guidance.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "google_financial", "requirement_id": "Google Cloud compliance offerings", "fit": "partial", "rationale": "Google Cloud's compliance offerings catalog documents the platform's third-party attestations (SOC 1/2/3, ISO/IEC 27001, PCI DSS) available to customers. For GCP-hosted financial AI systems, this capability supplies the platform-layer support for the board-approved model risk management policy framework. This is vendor product documentation, not regulatory guidance; it does not address model-layer regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "aws_financial", "requirement_id": "AWS User Guide to Financial Services Regulations & Guidelines in the United States", "fit": "adjacent", "rationale": "The 'AWS User Guide to Financial Services Regulations & Guidelines in the United States' whitepaper maps AWS services and shared-responsibility considerations to US financial regulatory expectations. For AWS-hosted financial AI systems, this supplies the infrastructure-layer support and evidence stream for the board-approved model risk management policy framework. This is vendor documentation of real AWS capabilities \u2014 it does not substitute for model-layer validation or regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "ffiec", "requirement_id": "IT Handbook \u2014 Development, Acquisition, and Maintenance", "fit": "direct", "rationale": "The FFIEC IT Examination Handbook's 'Development, Acquisition, and Maintenance' booklet (August 2024) sets examiner expectations for governance over development, acquisition, and maintenance of technology systems at supervised institutions, including AI-based systems. An MRM policy framework covering the full model lifecycle addresses the booklet's governance expectations; the booklet replaced the retired 'Development and Acquisition' booklet.", "normative_force": "supervisory-guidance", "source_version": "2024-08", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" } ], "canonical_id": "apeiris://finance/controls/MR-02", "meta": { "authored_on": "2026-06-29", "schema_version": "1.1.0" }, "validation_objective": "A current, board-approved Model Risk Management policy must be in force that explicitly covers the full model lifecycle \u2014 including LLM and agentic AI model types \u2014 with documented roles, responsibilities, escalation paths, and an operational exception management process; the policy must have been reviewed and re-approved by the board risk committee within the last 12 months.", "evidence_required": [ "board_risk_committee_approval_record showing policy title, version, approval date, and approving members, with approval_date within the last 12 months", "mrm_policy_document containing an explicit scope statement that covers AI/ML, LLM, and generative AI model types", "raci_matrix documenting Model Owner, Developer, Independent Validator, Model Risk Officer, and Validation Committee roles with named function or individual assignments", "exception_management_log recording all active waivers with remediation timelines, escalation status, and MRO sign-off", "annual_policy_review_sign_off signed by CRO and board risk committee chair attesting to review completion" ], "machine_tests": [ "Query policy management system for MRM Policy record \u2192 assert approval_date is within last 365 days and approver_role=board_risk_committee", "Parse MRM policy scope statement for explicit reference to LLM, generative AI, or agentic AI \u2192 assert at least one of these terms is present in the scope definition", "Query exception management system for open waivers \u2192 assert no waiver has been open for more than 90 days without an escalation_record attached", "Pull RACI matrix from policy system \u2192 assert Model_Owner, Independent_Validator, and MRO roles are each assigned to a named function or individual" ], "human_review": [ "Review MRM Policy scope and lifecycle coverage against current SR 26-2 Governance and Controls expectations and EU AI Act Article 9 risk management system requirements to identify gaps for current AI model types", "Assess whether the escalation path to board risk committee is clearly defined with quantitative thresholds that reflect the institution's current model risk profile including frontier AI", "Evaluate whether the policy exception process is operational and all documented waivers have active remediation plans with board visibility" ], "blocking_effect": "requires-review", "normative_status": "supervisory-guidance", "anti_patterns": [ "Maintaining a legacy MRM policy written before LLM and agentic AI deployments that does not address these model types in its scope", "Treating board approval as a one-time event rather than an annual renewal, allowing the policy to become stale relative to current regulatory expectations", "Defining roles and responsibilities in policy text without maintaining an operational RACI matrix communicated to all stakeholders and updated when personnel change", "Allowing validation bypasses without capturing them formally under the exception management process, making the bypass rate invisible to governance functions", "Writing an MRM policy that references SR 26-2 by name but does not operationalize its requirements into specific lifecycle obligations, validation standards, and approval authorities" ], "update_status": "current", "layer_code": "MR" }, { "id": "MR-03", "layer": "MR", "plane": "lifecycle", "name": "Pre-Deployment Model Risk Assessment", "plain": "Every financial AI model must undergo a comprehensive, independent risk assessment before deployment in financial decision-making processes, evaluating model conceptual soundness, data quality, validation evidence, and risk controls commensurate with its assigned risk tier.", "threat": { "tags": [ "unvalidated-model-deployment", "conceptual-soundness-failure", "data-quality-risk", "pre-production-gate-bypass" ], "desc": "Models deployed without independent pre-deployment assessment embed undetected errors, conceptual flaws, or data quality problems into live financial decisions. Business pressure to deploy quickly routinely overrides validation requirements without a formal gate process. Financially material models with undetected errors can produce systematic mispricing, credit mis-scoring, or regulatory capital miscalculation." }, "standard": [ { "id": "sr26_2", "section": "\u00a7V (Validation and Monitoring)", "title": "Model validation and monitoring" }, { "id": "eu_ai_act", "section": "Art. 9(6)", "title": "Testing for pre-deployment risk management" }, { "id": "coso_icfr", "section": "Component 2", "title": "Risk assessment \u2014 analyzing risks before deployment" }, { "id": "bcbs_239", "section": "Principle 7", "title": "Accuracy of reporting \u2014 reconciliation and validation" } ], "sources": [ { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Anthropic's Responsible Scaling Policy v3.3 documents the vendor's capability thresholds and safeguards, cited as third-party AI due diligence context for the apeiris://finance/controls/MR-03 Pre-Deployment Model Risk Assessment control.", "reviewed_on": "2026-07-02" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://finance/controls/MR-03 Pre-Deployment Model Risk Assessment control.", "reviewed_on": "2026-07-01" }, { "id": "google_cloud_financial_services_ai_2024", "title": "Google Cloud Explainable AI", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/explainable-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_financial_services_ai_2024", "relationship": "informative_reference", "rationale": "Google Cloud's Explainable AI and Vertex AI model governance documentation describes platform capabilities relevant to the apeiris://finance/controls/MR-03 Pre-Deployment Model Risk Assessment control.", "reviewed_on": "2026-07-02" }, { "id": "aws_financial_services_compliance_2024", "title": "AWS User Guide to Financial Services Regulations & Guidelines in the United States", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/financial-services/security-compliance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_financial_services_compliance_2024", "relationship": "informative_reference", "rationale": "AWS's financial services regulatory guide and compliance tooling document infrastructure-layer capabilities relevant to the apeiris://finance/controls/MR-03 Pre-Deployment Model Risk Assessment control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Staged pre-deployment gate: (1) model documentation review, (2) independent validation execution, (3) validation committee approval, (4) sign-off authority aligned to risk tier. No deployment to production without all gate stages passed and documented.", "steps": [ "Define pre-deployment assessment requirements by risk tier: Low tier requires owner attestation and peer review; Medium tier requires independent validation team review; High and Critical tiers require full independent validation with validation committee approval.", "Create standardized pre-deployment assessment templates covering conceptual soundness, development data quality, testing results, sensitivity analysis, and limitations documentation.", "Build a deployment gate in the model registry that blocks production deployment until the pre-deployment assessment record is complete and approved.", "Document independent validation findings, model limitations, compensating controls, and ongoing monitoring requirements as a pre-deployment validation report filed in the model inventory." ], "model_risk_officer": { "summary": "Pre-deployment assessment is the primary control for preventing unvalidated models from entering production, consistent with SR 26-2 (Model Validation and Monitoring). The MRO must ensure independence of validation teams and completeness of assessment documentation.", "actions": [ "Approve the pre-deployment assessment framework and validation requirements by risk tier.", "Conduct or oversee independent validation for all High and Critical tier models.", "Review and approve validation reports before deployment authorization is granted." ], "failure_signals": [ "Any High or Critical tier model deployed without a complete, MRO-approved validation report.", "Validation findings of conceptual unsoundness not blocking deployment without formal exception.", "Pre-deployment assessments completed by model developers rather than independent validators." ] }, "compliance_officer": { "summary": "Pre-deployment validation documentation is the primary evidence artifact for demonstrating SR 26-2 alignment and EU AI Act pre-market conformity assessment readiness.", "actions": [ "Verify that pre-deployment assessment documentation satisfies EU AI Act Article 9(6) testing requirements for high-risk AI systems.", "Include pre-deployment gate compliance rates in quarterly MRM reporting.", "Ensure validation reports reference applicable regulatory standards." ], "metrics": [ "Pre-deployment gate compliance rate: 100% of High/Critical models validated before deployment.", "Mean time from validation completion to deployment authorization: target \u2264 10 business days.", "Open validation findings at deployment: target zero unresolved High-severity findings." ], "failure_signals": [ "Production models with no pre-deployment validation record in the model inventory.", "EU AI Act high-risk systems deployed without documented conformity assessment.", "Validation bypass rate exceeding 5% without formal exception documentation." ] }, "internal_audit": { "summary": "Pre-deployment assessment compliance is a primary audit objective for MRM. Audit must verify independence, completeness, and gate effectiveness.", "actions": [ "Sample 20% of models deployed in the prior year and verify completeness of pre-deployment assessment records.", "Test independence of validation by confirming validator was not on the development team.", "Test gate effectiveness by confirming no production deployment occurred without registry-recorded assessment approval." ], "failure_signals": [ "Sampled models missing pre-deployment assessment documentation.", "Validators who also participated in model development for High/Critical tier models.", "Evidence of production deployment bypassing the registry gate." ] }, "it_operations": { "summary": "IT Operations enforces the deployment gate technically \u2014 the registry integration must prevent production promotion without a completed assessment record.", "actions": [ "Implement a hard deployment gate in the CI/CD pipeline that checks the model registry for a valid pre-deployment assessment record before allowing production deployment.", "Log all deployment attempts against models lacking assessment records as security events." ], "failure_signals": [ "Deployment pipeline capable of promoting models to production without registry gate check.", "Registry gate bypass discovered during audit or incident review." ] }, "financial_controller": { "summary": "Pre-deployment assessment is the controller's assurance that a new model cannot silently start driving material financial figures.", "actions": [ "Confirm that models feeding material financial estimates cannot reach production without a completed pre-deployment assessment.", "Review assessment conclusions before relying on a new model's outputs in period-end reporting." ], "failure_signals": [ "A model feeding financial statements deployed without assessment sign-off.", "Period-end estimates relying on models whose assessments flagged unresolved material issues." ] } }, "maturity": { "current": "defined", "target": "managed", "notes": "Institutions often have pre-deployment validation processes on paper but lack automated deployment gates that enforce them technically." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "Model Risk Management", "Independent Validation Team", "IT Operations", "Business Line Model Owners" ], "frameworks": [ { "framework": "sr26_2", "requirement_id": "\u00a7V (Validation and Monitoring)", "fit": "direct", "rationale": "SR 26-2 \u00a7V (Validation and Monitoring) describes validation performed with appropriate independence and rigor before models are placed into use and after significant changes. A pre-deployment assessment gate operationalizes that supervisory expectation for financial AI models.", "normative_force": "supervisory-guidance", "source_version": "2026-04-17", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "eu_ai_act", "requirement_id": "Art. 9(6)", "fit": "direct", "rationale": "EU AI Act Article 9(6) requires that high-risk AI systems be tested prior to deployment to identify appropriate risk management measures. The testing must be performed against defined metrics and probabilistic thresholds using realistic target populations. Financial AI systems classified as high-risk must satisfy this pre-deployment testing obligation before being put into service.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-06-28", "basis": "anchored", "relation": "satisfies" }, { "framework": "bcbs_239", "requirement_id": "Principle 7", "fit": "partial", "rationale": "BCBS 239 Principle 7 (Accuracy of reporting) requires risk management reports to accurately convey aggregated risk data and to be reconciled and validated. Pre-deployment validation of models whose outputs feed risk reporting is part of the validation discipline Principle 7 expects before report consumers rely on model-derived figures.", "normative_force": "supervisory-guidance", "source_version": "2013", "reviewed_on": "2026-07-02", "basis": "asserted", "relation": "satisfies" }, { "framework": "coso_icfr", "requirement_id": "Component 2", "fit": "partial", "rationale": "COSO 2013 Component 2 (Risk Assessment; Principles 6-9) requires the organization to identify and analyze risks to the achievement of its objectives as a basis for determining how risks should be managed. Pre-deployment model risk assessment is that risk analysis applied to a new model before it can affect financial reporting objectives.", "normative_force": "voluntary-standard", "source_version": "2013", "reviewed_on": "2026-07-02", "basis": "asserted", "relation": "informs" }, { "framework": "pcaob_as_2201", "requirement_id": "\u00b6.39", "fit": "adjacent", "rationale": "AS 2201 \u00b6.39 has the auditor select controls to test based on the importance of the control to the auditor's conclusion about whether relevant assertions are addressed. Pre-deployment model risk assessment is a control an auditor would likely select where a model materially affects financial-statement assertions; the fit is adjacent \u2014 AS 2201 addresses the auditor, not management's assessment design.", "normative_force": "certification-standard", "source_version": "2007", "reviewed_on": "2026-07-02", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "microsoft_rai", "requirement_id": "RS1", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal RS1 (Reliability and safety guidance) requires following reliability and safety guidance when developing and deploying systems, including defining safe operating parameters. For institutions using Azure AI services, this goal produces vendor-side governance artifacts that align with pre-deployment model risk assessment and validation gating. The Standard is Microsoft's published internal policy offered as reference practice, not regulatory guidance.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "google_financial", "requirement_id": "Explainable AI", "fit": "partial", "rationale": "Google Cloud's Explainable AI documentation (cloud.google.com/explainable-ai) describes feature attribution and explanation tooling available through Vertex AI. For GCP-hosted financial AI systems, this capability supplies the platform-layer support for pre-deployment model risk assessment and validation gating. This is vendor product documentation, not regulatory guidance; it does not address model-layer regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "aws_financial", "requirement_id": "AWS Artifact", "fit": "adjacent", "rationale": "AWS Artifact provides on-demand access to AWS's third-party compliance reports (SOC 1/2, PCI DSS, ISO). For AWS-hosted financial AI systems, this supplies the infrastructure-layer support and evidence stream for pre-deployment model risk assessment and validation gating. This is vendor documentation of real AWS capabilities \u2014 it does not substitute for model-layer validation or regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://finance/controls/MR-03", "meta": { "authored_on": "2026-06-29", "schema_version": "1.1.0" }, "validation_objective": "Every High and Critical tier financial AI model must have a completed, MRO-approved pre-deployment validation report on file in the model registry before any production deployment is authorized; the report must document conceptual soundness assessment, data quality findings, testing results, and model limitations, and must have been produced by validators who are independent of the development team.", "evidence_required": [ "pre_deployment_validation_report with sections covering conceptual soundness, development data quality, testing methodology, sensitivity analysis, and documented limitations, signed by independent validator with validator_role=independent_validation_team", "model_registry_gate_record showing deployment_authorized_by=MRO and linked validation_report_id for each production deployment of a High/Critical tier model", "independence_attestation confirming the validator was not a member of the development team for the model being validated", "validation_finding_resolution_record showing all High-severity findings resolved or documented as accepted risk with MRO approval before deployment authorization", "eu_ai_act_conformity_checklist for high-risk AI systems assessed against Article 9(6) pre-deployment testing requirements with all items signed off" ], "machine_tests": [ "Query model registry for all models deployed to production in the last 180 days \u2192 assert 100% of High/Critical tier models have a linked pre_deployment_validation_report_id with validator_role=independent_validation_team", "Pull pre-deployment validation reports for sampled High/Critical models \u2192 assert approval_date on each report is earlier than the production deployment_date", "Query validation finding records for models in production \u2192 assert zero High-severity open findings exist at the recorded time of deployment authorization", "Attempt to execute production deployment via CI/CD pipeline for a High-tier model without a registry-linked assessment record \u2192 assert deployment is blocked with error code=missing_validation_record" ], "human_review": [ "Review a sample of pre-deployment validation reports to assess depth and independence of conceptual soundness assessment, and confirm validators are not from the development team", "Evaluate whether the staged deployment gate process is documented and enforced technically, with evidence that production authorization is only granted after all gate stages are complete and signed off", "Assess EU AI Act high-risk AI system validation packages for completeness against Article 9(6) pre-deployment testing requirements, including evidence of testing on realistic target populations" ], "blocking_effect": "blocks-deployment", "normative_status": "supervisory-guidance", "anti_patterns": [ "Allowing the model development team to perform or directly influence their own pre-deployment validation, contrary to the validation-independence expectation of SR 26-2 (Model Validation and Monitoring)", "Completing validation documentation after deployment as a retrospective compliance exercise rather than as a genuine gate that must pass before production access is granted", "Applying full pre-deployment assessment requirements only to traditional statistical models while treating LLMs, generative AI, and agentic AI as exempt from independent validation", "Closing High-severity validation findings with waivers that lack MRO approval and board-level exception documentation before the model is deployed", "Treating pre-deployment validation as a document-collection exercise rather than an evidence-based assessment of conceptual soundness, data quality, and real-world performance" ], "update_status": "current", "layer_code": "MR" }, { "id": "MR-04", "layer": "MR", "plane": "control", "name": "Model Risk Appetite and Material Model Thresholds", "plain": "The board must define and approve quantitative model risk appetite statements and materiality thresholds that determine which models require the highest validation rigor, what level of model error loss is acceptable, and when model risk limits trigger escalation or model suspension.", "threat": { "tags": [ "undefined-risk-appetite", "materiality-ambiguity", "limit-breach-non-escalation", "governance-threshold-gap" ], "desc": "Without defined risk appetite and materiality thresholds, model risk decisions are made inconsistently and subjectively, allowing high-impact models to receive insufficient oversight. Undefined limits mean limit breaches are not recognized or escalated. Regulators expect explicit, board-approved model risk appetite statements as evidence of mature MRM governance." }, "standard": [ { "id": "sr26_2", "section": "\u00a7III", "title": "Risk-based model risk management" }, { "id": "coso_icfr", "section": "Component 2", "title": "Risk assessment \u2014 risk tolerance setting" }, { "id": "sox", "section": "\u00a7404", "title": "Management assessment of internal controls" }, { "id": "omb_a_123", "section": "Section II.B", "title": "Risk tolerance and risk appetite framework" } ], "sources": [ { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://finance/controls/MR-04 Model Risk Appetite and Material Model Thresholds control.", "reviewed_on": "2026-07-01" }, { "id": "google_cloud_financial_services_ai_2024", "title": "Google Cloud Explainable AI", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/explainable-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_financial_services_ai_2024", "relationship": "informative_reference", "rationale": "Google Cloud's Explainable AI and Vertex AI model governance documentation describes platform capabilities relevant to the apeiris://finance/controls/MR-04 Model Risk Appetite and Material Model Thresholds control.", "reviewed_on": "2026-07-02" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Anthropic's Responsible Scaling Policy v3.3 documents the vendor's capability thresholds and safeguards, cited as third-party AI due diligence context for the apeiris://finance/controls/MR-04 Model Risk Appetite and Material Model Thresholds control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Board-approved Model Risk Appetite Statement with quantitative thresholds: (1) materiality criteria for model classification, (2) maximum tolerable model error impact in dollars or basis points, (3) maximum acceptable proportion of material models with outstanding validation findings, (4) escalation triggers to board from MRM function.", "steps": [ "Define materiality criteria for model classification as Material vs. Non-Material using factors: financial statement impact, regulatory capital sensitivity, revenue at risk, customer population affected, and regulatory classification as high-risk AI.", "Quantify model risk appetite: set maximum acceptable financial impact from model error (e.g., dollar cap per material model and aggregate), maximum proportion of material models with High validation findings, and time limits for remediation.", "Have the Model Risk Appetite Statement reviewed by the CRO and approved by the board risk committee; embed it in the MRM Policy.", "Establish automated monitoring of model risk metrics against appetite thresholds with escalation triggers to the MRO and board risk committee when thresholds are breached." ], "model_risk_officer": { "summary": "Risk appetite statements give the MRO operational authority to escalate, halt, or require remediation for models that breach defined thresholds. They transform MRM from a subjective review into a quantifiable risk discipline.", "actions": [ "Lead development of quantitative risk appetite metrics and materiality thresholds; present to board risk committee for approval.", "Monitor model risk metrics against appetite thresholds monthly and escalate breaches immediately.", "Review and update thresholds annually to reflect changes in the institution's model risk profile." ], "failure_signals": [ "No board-approved quantitative model risk appetite statement in effect.", "Material model thresholds not updated to reflect generative AI or LLM model deployments.", "Model risk limit breaches not escalated to the board risk committee within defined timeframes." ] }, "compliance_officer": { "summary": "Board-approved risk appetite and materiality thresholds are evidence of mature MRM governance required by SR 26-2 and expected by EU AI Act conformity assessment.", "actions": [ "Verify that the Model Risk Appetite Statement is board-approved and updated annually.", "Map risk appetite thresholds to EU AI Act prohibited and high-risk AI classifications.", "Include risk appetite compliance in annual MRM compliance assessment." ], "metrics": [ "Board approval currency: risk appetite statement approved within last 12 months.", "Threshold breach escalation rate: 100% of breaches escalated within defined timeframe.", "Material model identification rate: all models meeting materiality criteria classified accordingly." ], "failure_signals": [ "Risk appetite statement not board-reviewed in more than 12 months.", "Materiality thresholds that exclude AI/ML models from material classification.", "No automated monitoring of model risk metrics against appetite thresholds." ] }, "internal_audit": { "summary": "Audit must verify that model risk appetite statements are in effect, operationalized, and functioning as designed to escalate when thresholds are breached.", "actions": [ "Confirm board approval documentation for the current Model Risk Appetite Statement.", "Test that model risk monitoring systems correctly flag and escalate breaches of defined thresholds.", "Assess whether material model thresholds appropriately capture the institution's highest-risk AI deployments." ], "failure_signals": [ "Board approval documentation absent or more than 12 months old.", "Documented threshold breach with no evidence of escalation.", "Threshold definitions that would exclude known high-impact AI models from material classification." ] }, "financial_controller": { "summary": "Model risk appetite statements are a prerequisite for quantifying model risk exposure in the institution's risk disclosures and for ensuring financially material models are scoped into SOX ICFR assessments.", "actions": [ "Review model risk appetite thresholds for alignment with financial reporting materiality standards used for SOX scoping.", "Ensure model error impact thresholds are consistent with financial statement materiality thresholds for audit purposes." ], "failure_signals": [ "Model materiality thresholds inconsistent with financial reporting materiality standards.", "SOX-scoped models not included in material model classification under the risk appetite framework." ] }, "it_operations": { "summary": "IT Operations runs the risk-tiering service and threshold configuration behind model risk appetite and materiality threshold setting \u2014 integrating it with deployment pipelines, enforcing the automated gates, and keeping the supporting data flows reliable and auditable.", "actions": [ "Integrate the risk-tiering service and threshold configuration with CI/CD and runtime tooling so that threshold breaches automatically flag models for enhanced review.", "Automate collection and retention of threshold-breach events and tier assignments in immutable, hash-verified storage.", "Monitor pipeline and integration health and alert when materiality thresholds change without an approved configuration change." ], "failure_signals": [ "Production changes bypass the automated gate so that it is no longer true that threshold breaches automatically flag models for enhanced review.", "Gaps or outages in threshold-breach events and tier assignments collection exceeding 24 hours.", "Manual, untracked edits to the risk-tiering service and threshold configuration records." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most institutions have qualitative risk appetite statements; quantitative model-specific thresholds that translate to operational escalation triggers are rare." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai" ], "implementers": [ "Model Risk Management", "Chief Risk Officer", "Board Risk Committee", "Finance / Controller" ], "frameworks": [ { "framework": "sr26_2", "requirement_id": "\u00a7III (Overview of Model Risk and MRM)", "fit": "direct", "rationale": "SR 26-2 \u00a7III (Overview of Model Risk and Model Risk Management) frames model risk management as risk-based \u2014 with intensity of governance, validation, and monitoring commensurate with a model's materiality and complexity. Explicit risk appetite and materiality thresholds are the mechanism institutions use to operationalize that risk-based framing.", "normative_force": "supervisory-guidance", "source_version": "2026-04-17", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "coso_icfr", "requirement_id": "Component 2", "fit": "direct", "rationale": "COSO ICIF Component 2 requires organizations to specify risk tolerances at appropriate levels of specificity to support risk assessment. Model risk appetite thresholds are COSO-aligned risk tolerance statements at the model-class level. For COSO-based ICFR assessments, quantitative risk tolerances for model risk enable consistent application of control procedures.", "normative_force": "voluntary-standard", "source_version": "2013", "reviewed_on": "2026-06-28", "basis": "asserted", "relation": "informs" }, { "framework": "sox", "requirement_id": "\u00a7404", "fit": "adjacent", "rationale": "SOX Section 404 ICFR assessments require management to establish and maintain adequate controls over financial reporting. Model risk appetite thresholds determine which model-driven processes require the most rigorous ICFR controls and testing. External auditors assess whether management's risk tolerance framework adequately identifies and responds to model risk in financial reporting.", "normative_force": "binding-law", "source_version": "2002", "reviewed_on": "2026-06-28", "basis": "asserted", "relation": "satisfies" }, { "framework": "omb_a_123", "requirement_id": "Section II.B", "fit": "partial", "rationale": "OMB Circular A-123 requires agencies and qualifying financial entities to define risk tolerance as part of their enterprise risk management framework. A board-approved Model Risk Appetite Statement aligned to A-123 risk tolerance requirements demonstrates integration of model risk into enterprise-level risk governance. This alignment is expected by federal financial regulators.", "normative_force": "supervisory-guidance", "source_version": "2016", "reviewed_on": "2026-06-28", "basis": "asserted", "relation": "satisfies" }, { "framework": "eu_ai_act", "requirement_id": "Art. 9(2)", "fit": "partial", "rationale": "EU AI Act Article 9(2) requires that the risk management system identify and analyse reasonably foreseeable risks and estimate and evaluate residual risks. Model risk appetite thresholds are the quantitative expression of how much residual model risk the institution accepts, and they define when EU AI Act high-risk systems must be suspended or escalated. They are a prerequisite for the proportionality assessments required under the Act.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-06-28", "basis": "anchored", "relation": "satisfies" }, { "framework": "microsoft_rai", "requirement_id": "A1", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal A1 (Impact assessment) requires documented impact assessments identifying intended uses, stakeholders, and potential harms. For institutions using Azure AI services, this goal produces vendor-side governance artifacts that align with model risk appetite and materiality threshold setting. The Standard is Microsoft's published internal policy offered as reference practice, not regulatory guidance.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "google_financial", "requirement_id": "Model Cards", "fit": "partial", "rationale": "Model Cards provide structured, versioned documentation of a model's purpose, performance characteristics, and limitations. For GCP-hosted financial AI systems, this capability supplies the platform-layer support for model risk appetite and materiality threshold setting. This is vendor product documentation, not regulatory guidance; it does not address model-layer regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://finance/controls/MR-04", "meta": { "authored_on": "2026-06-29", "schema_version": "1.1.0" }, "validation_objective": "A board-approved Model Risk Appetite Statement must be in force specifying quantitative materiality thresholds and a maximum acceptable model error impact expressed in dollars or basis points; model risk metrics must be actively monitored against these thresholds with documented escalation events occurring within the SLA defined in the statement whenever thresholds are breached.", "evidence_required": [ "board_risk_appetite_statement with explicit materiality criteria, maximum tolerable model error impact thresholds in quantitative terms, and escalation trigger definitions, showing board_approval_date within the last 12 months", "model_risk_monitoring_report showing current model risk metrics measured against defined appetite thresholds with Red/Amber/Green status per model, dated within the last calendar month", "threshold_breach_escalation_record for any breach events in the prior 12 months showing escalation_initiated_timestamp within the SLA and board_notification_record", "material_model_classification_list showing all models meeting materiality criteria with classification rationale and assigning Model Owner accountability", "annual_threshold_review_record documenting MRO assessment of threshold appropriateness and board re-approval of updated risk appetite thresholds" ], "machine_tests": [ "Query policy management system for Model Risk Appetite Statement \u2192 assert board_approval_date within last 365 days and document contains quantitative materiality_threshold and error_impact_cap fields with numeric values", "Pull current model risk monitoring dashboard \u2192 assert all material model metrics are present with last_refresh_timestamp within the last business day", "Query threshold breach event log for last 12 months \u2192 assert all breach events have escalation_initiated_timestamp within the SLA defined in the appetite statement", "Pull material model classification list \u2192 assert all models with financial impact above the defined materiality threshold have a Classification=Material record with rationale documentation" ], "human_review": [ "Review the Model Risk Appetite Statement to confirm materiality criteria are quantified with specific thresholds capable of operationally classifying models, including LLM and generative AI deployments", "Assess whether model risk monitoring systems correctly measure current model risk metrics against defined appetite thresholds and would automatically detect a threshold breach requiring escalation", "Evaluate whether the escalation path from threshold breach to board risk committee notification is documented, tested, and has been exercised or scenario-tested in the last 12 months" ], "blocking_effect": "requires-review", "normative_status": "supervisory-guidance", "anti_patterns": [ "Defining model risk appetite only in qualitative terms such as 'low tolerance' or 'moderate' without quantitative thresholds that can be operationally monitored and breached", "Setting materiality thresholds using only financial statement materiality percentages without adjusting for the unique risk characteristics of AI model error propagation across large decision populations", "Failing to update materiality thresholds to reflect LLM, generative AI, and agentic AI model types which do not fit traditional statistical model risk parameters", "Tracking model risk metrics on a static periodic report without automated alerting that triggers defined escalation procedures when thresholds are exceeded", "Treating the Model Risk Appetite Statement as a compliance document approved once and never operationalized in model risk monitoring workflows or tested through escalation drills" ], "update_status": "current", "layer_code": "MR" }, { "id": "MR-05", "layer": "MR", "plane": "control", "name": "Ongoing Model Risk Monitoring", "plain": "All production financial AI models must be subject to continuous monitoring of performance, stability, and risk metrics, with automated alerting when models exhibit drift, degradation, or anomalous output patterns that could indicate elevated model risk.", "threat": { "tags": [ "model-drift", "performance-degradation", "silent-model-failure", "monitoring-coverage-gap" ], "desc": "Models validated at deployment may degrade significantly over time as economic conditions, market regimes, or data distributions change. Silent model failure \u2014 where a model produces systematically wrong outputs without triggering visible errors \u2014 is among the most dangerous financial AI risks. Unmonitored production models continue making consequential decisions long after their performance has deteriorated below acceptable thresholds." }, "standard": [ { "id": "sr26_2", "section": "\u00a7V (Ongoing Model Monitoring)", "title": "Ongoing model monitoring" }, { "id": "eu_ai_act", "section": "Art. 72", "title": "Post-market monitoring of high-risk AI systems" }, { "id": "bcbs_239", "section": "Principle 8", "title": "Risk data completeness and monitoring" }, { "id": "aicpa_soc2", "section": "CC7.2", "title": "Monitoring of system performance and anomalies" } ], "sources": [ { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://finance/controls/MR-05 Ongoing Model Risk Monitoring control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Anthropic's Responsible Scaling Policy v3.3 documents the vendor's capability thresholds and safeguards, cited as third-party AI due diligence context for the apeiris://finance/controls/MR-05 Ongoing Model Risk Monitoring control.", "reviewed_on": "2026-07-02" }, { "id": "openai_enterprise_data_governance_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "OpenAI's enterprise privacy and compliance documentation records vendor-side data handling and audit-log capabilities relevant to the apeiris://finance/controls/MR-05 Ongoing Model Risk Monitoring control.", "reviewed_on": "2026-07-02" }, { "id": "google_cloud_financial_services_ai_2024", "title": "Google Cloud Explainable AI", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/explainable-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_financial_services_ai_2024", "relationship": "informative_reference", "rationale": "Google Cloud's Explainable AI and Vertex AI model governance documentation describes platform capabilities relevant to the apeiris://finance/controls/MR-05 Ongoing Model Risk Monitoring control.", "reviewed_on": "2026-07-02" }, { "id": "aws_financial_services_compliance_2024", "title": "AWS User Guide to Financial Services Regulations & Guidelines in the United States", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/financial-services/security-compliance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_financial_services_compliance_2024", "relationship": "informative_reference", "rationale": "AWS's financial services regulatory guide and compliance tooling document infrastructure-layer capabilities relevant to the apeiris://finance/controls/MR-05 Ongoing Model Risk Monitoring control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Automated model monitoring pipeline with drift detection, performance tracking, and anomaly alerting; tiered monitoring frequency by risk tier (daily/weekly/monthly); automated alerts routed to model owners and MRM team; monthly monitoring reports to validation committee.", "steps": [ "Implement automated monitoring dashboards for each production model tracking: prediction accuracy, output distribution, feature importance stability, population stability index (PSI), and outcome rates versus validation benchmarks.", "Define monitoring thresholds by risk tier: Critical/High models monitored daily with automated alerts for PSI > 0.25 or accuracy degradation exceeding 5% versus validation baseline.", "Route monitoring alerts to model owners for acknowledgment within 24 hours and to the MRM team for triage; escalate unacknowledged alerts to the MRO within 48 hours.", "Produce monthly model performance reports for the validation committee covering all material models with Red/Amber/Green status and recommended actions for any models in Red status." ], "model_risk_officer": { "summary": "Ongoing monitoring -- described in SR 26-2 under Ongoing Model Monitoring -- is the control that catches post-deployment model deterioration before it causes material financial harm. The MRO must ensure monitoring coverage is complete and that alert escalation is functioning.", "actions": [ "Approve monitoring thresholds and alert escalation rules for all material models.", "Review monthly model performance reports and escalate Red-status models to business line heads and the CRO.", "Require re-validation of any model that exceeds drift or performance degradation thresholds." ], "failure_signals": [ "Material models without active monitoring dashboards or automated performance tracking.", "Monitoring alerts not acknowledged within SLA thresholds.", "Models in Red monitoring status for more than 30 days without re-validation or suspension decision." ] }, "compliance_officer": { "summary": "Ongoing monitoring documentation and alert records are the primary post-deployment compliance evidence for SR 26-2 and EU AI Act Article 72 post-market monitoring obligations.", "actions": [ "Verify that all EU AI Act high-risk AI systems have post-market monitoring plans satisfying Article 72.", "Review monitoring coverage against material model population quarterly.", "Include monitoring adequacy in annual MRM compliance assessment." ], "metrics": [ "Monitoring coverage rate: 100% of material models with active automated monitoring.", "Alert acknowledgment SLA compliance: >95% of alerts acknowledged within 24 hours.", "Red-status model remediation rate: 100% resolved within 30 days of Red designation." ], "failure_signals": [ "EU AI Act high-risk systems lacking post-market monitoring plans.", "Monitoring coverage gaps for any material model class.", "Supervisory criticism citing absent or inadequate ongoing monitoring." ] }, "it_operations": { "summary": "IT Operations deploys and maintains the model monitoring infrastructure, ensuring reliability, data pipeline integrity, and alert delivery.", "actions": [ "Maintain monitoring data pipelines with SLA commitments for data freshness (daily pipelines complete within 2 hours of business day close).", "Implement redundant alerting to ensure monitoring alerts are delivered even during platform incidents.", "Log all monitoring alert events, acknowledgments, and escalations for audit trail purposes." ], "failure_signals": [ "Monitoring data pipeline failures causing gaps in model performance data exceeding 48 hours.", "Monitoring alerts silently failing to deliver to model owners.", "Audit trail for alert acknowledgments missing or incomplete." ] }, "internal_audit": { "summary": "Audit must verify monitoring coverage, alert effectiveness, and that the monitoring function detects model deterioration before material financial harm occurs.", "actions": [ "Confirm monitoring dashboards exist and are actively maintained for all material models.", "Test a sample of past alerts to verify they were acknowledged within SLA and escalated appropriately.", "Back-test monitoring thresholds against known model deterioration events to assess threshold adequacy." ], "failure_signals": [ "Material models without monitoring dashboards or with monitoring coverage gaps.", "Alert acknowledgment SLA breaches not documented or escalated.", "No evidence of MRM review and action following Red-status monitoring alerts." ] }, "financial_controller": { "summary": "Monitoring alerts on models that feed the ledger are early warnings of misstatement risk; the controller needs them wired into the close process.", "actions": [ "Subscribe period-close checklists to monitoring alerts for models feeding financial statements.", "Require monitoring status review for reporting-critical models before certifying period results." ], "failure_signals": [ "Financial-statement models with expired or absent monitoring coverage.", "Close completed while a reporting-critical model had an open severe monitoring alert." ] } }, "maturity": { "current": "defined", "target": "managed", "notes": "Monitoring tooling is increasingly available but coverage gaps remain for newer AI model types including LLMs, where traditional statistical drift metrics are not directly applicable." }, "capability_risk": { "capability_level": "low" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "Model Risk Management", "IT Operations", "Model Owners / Business Lines", "Data Engineering" ], "frameworks": [ { "framework": "sr26_2", "requirement_id": "\u00a7V (Ongoing Model Monitoring)", "fit": "direct", "rationale": "SR 26-2 \u00a7V (Validation and Monitoring) addresses ongoing model monitoring under its Ongoing Model Monitoring subheading \u2014 tracking whether a model performs as intended and addressing performance issues promptly. This control implements that expectation with quantitative metrics and alert escalation.", "normative_force": "supervisory-guidance", "source_version": "2026-04-17", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "eu_ai_act", "requirement_id": "Art. 72", "fit": "direct", "rationale": "EU AI Act Article 72 requires providers of high-risk AI systems to have a post-market monitoring system that actively collects, documents, and analyses data to ensure the system continues to comply with the requirements of the regulation. For financial AI systems, this requires systematic monitoring of model performance against the conditions assessed during conformity assessment. The monitoring data must be reported to market surveillance authorities in certain circumstances.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-06-28", "basis": "anchored", "relation": "satisfies" }, { "framework": "bcbs_239", "requirement_id": "Principle 8", "fit": "partial", "rationale": "BCBS 239 Principle 8 (Comprehensiveness) requires risk reports to cover all material risk areas \u2014 for institutions with material model portfolios, that includes model performance risk. Ongoing model monitoring generates the performance metrics that keep model risk visible in comprehensive risk reporting; the fit is partial, since BCBS 239 addresses reporting rather than monitoring methodology.", "normative_force": "supervisory-guidance", "source_version": "2013", "reviewed_on": "2026-07-02", "basis": "asserted", "relation": "satisfies" }, { "framework": "soc2", "requirement_id": "CC7.2", "fit": "partial", "rationale": "AICPA SOC 2 CC7.2 requires entities to monitor system components for anomalies that are indicative of malicious acts, natural disasters, or errors affecting the entity's ability to meet its objectives. Model monitoring for anomalous outputs aligns with CC7.2 in the context of AI-driven financial systems. Financial technology providers subject to SOC 2 Type II assessments should include model monitoring in their CC7.2 evidence.", "normative_force": "certification-standard", "source_version": "2022", "reviewed_on": "2026-06-28", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "microsoft_rai", "requirement_id": "RS3", "fit": "adjacent", "rationale": "Microsoft Responsible AI Standard v2 Goal RS3 (Ongoing monitoring, feedback, and evaluation) requires ongoing monitoring, feedback collection, and evaluation of deployed systems. For institutions using Azure AI services, this goal produces vendor-side governance artifacts that align with ongoing post-deployment model performance monitoring. The Standard is Microsoft's published internal policy offered as reference practice, not regulatory guidance.", "normative_force": "best-practice", "source_version": "2022", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "openai_enterprise", "requirement_id": "Enterprise Compliance API \u2014 audit logs", "fit": "partial", "rationale": "ChatGPT Enterprise and the OpenAI API expose workspace audit-log data through the Compliance API and audit logs endpoint, exportable to SIEM and evidence stores. Institutions using OpenAI models in financial workflows can incorporate this vendor capability into ongoing post-deployment model performance monitoring. This is vendor capability documentation, not regulatory guidance; it covers the vendor side only.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_financial", "requirement_id": "Vertex AI Model Monitoring", "fit": "partial", "rationale": "Vertex AI Model Monitoring detects prediction drift and training-serving skew for models deployed on Google Cloud. For GCP-hosted financial AI systems, this capability supplies the platform-layer support for ongoing post-deployment model performance monitoring. This is vendor product documentation, not regulatory guidance; it does not address model-layer regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "aws_financial", "requirement_id": "AWS CloudTrail", "fit": "adjacent", "rationale": "AWS CloudTrail records API activity across AWS accounts with actor, action, and timestamp detail, exportable for retention and analysis. For AWS-hosted financial AI systems, this supplies the infrastructure-layer support and evidence stream for ongoing post-deployment model performance monitoring. This is vendor documentation of real AWS capabilities \u2014 it does not substitute for model-layer validation or regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://finance/controls/MR-05", "meta": { "authored_on": "2026-06-29", "schema_version": "1.1.0" }, "validation_objective": "All production financial AI models classified as material must have active automated monitoring dashboards with data refreshed within the last business day pipeline cycle, all monitoring alerts must be acknowledged by model owners within 24 hours, and no material model may remain in Red monitoring status for more than 30 days without a documented re-validation decision or suspension record signed by the MRO.", "evidence_required": [ "model_monitoring_dashboard_record for each material model showing last_data_refresh_timestamp within 26 hours of the most recent business day close", "alert_acknowledgment_log showing alert_id, alert_generated_timestamp, acknowledged_by, and acknowledgment_timestamp for all alerts in the prior 90 days, with acknowledgment latency \u2264 24 hours for \u2265 95% of entries", "monthly_model_performance_report with Red/Amber/Green status for all material models, signed by MRM team and submitted to validation committee within 5 business days of month end", "red_status_remediation_record for any model designated Red, showing decision_date, remediation_plan or suspension_decision, and MRO_approval within 30 days of Red designation", "eu_ai_act_post_market_monitoring_plan for each high-risk AI system confirming monitoring scope, metrics tracked, and reporting obligations under Article 72" ], "machine_tests": [ "Query model monitoring system for all material models \u2192 assert last_data_refresh_timestamp is within 26 hours for \u2265 98% of material models", "Pull alert acknowledgment log for last 90 days \u2192 assert acknowledgment rate within 24 hours is \u2265 95%", "Query production model list for models in Red monitoring status \u2192 assert no model has been in Red status for more than 30 days without a remediation_decision_record or suspension_record", "Inject a synthetic prediction distribution shift (PSI > 0.25) into a test model monitoring endpoint \u2192 assert monitoring system generates an alert within the configured detection interval" ], "human_review": [ "Review monitoring threshold calibration for material models to confirm PSI and accuracy degradation thresholds are set at levels that detect financially material performance deterioration before harm occurs", "Assess monthly model performance reports for evidence that MRM team reviews Red/Amber status models and takes documented remediation action within defined SLAs", "Evaluate whether EU AI Act Article 72 post-market monitoring plans for high-risk AI systems are implemented and whether monitoring data collected would satisfy regulatory disclosure obligations" ], "blocking_effect": "advisory", "normative_status": "supervisory-guidance", "anti_patterns": [ "Deploying monitoring dashboards that track only infrastructure metrics such as API latency and error rates without measuring model performance against financial output benchmarks and validation baselines", "Setting monitoring thresholds so wide that models with significant performance degradation do not generate alerts until the failure is catastrophic and has already affected financial outputs", "Generating so many low-sensitivity alerts that model owners experience alert fatigue and routinely dismiss or ignore genuine performance degradation signals", "Treating LLM and generative AI outputs as exempt from monitoring because traditional PSI and accuracy metrics are not directly applicable, without developing adapted monitoring metrics for these model types", "Running model monitoring as a periodic manual review exercise rather than as automated continuous monitoring with real-time alerting and documented escalation triggers" ], "update_status": "current", "layer_code": "MR" }, { "id": "MR-06", "layer": "MR", "plane": "control", "name": "Third-Party and Vendor AI Model Risk Management", "plain": "Financial institutions must apply model risk management discipline consistent with SR 26-2 to all AI models obtained from third-party vendors \u2014 including commercially available LLMs, scoring models, and embedded AI capabilities \u2014 with risk assessments, contractual validation rights, and ongoing monitoring proportionate to their risk tier. SR 26-2 covers vendor models in its vendor and third-party products section, but footnote 3 excludes generative AI from the guidance's stated scope; this control extends the vendor-model discipline to LLMs as institutional practice.", "threat": { "tags": [ "vendor-model-opacity", "third-party-validation-gap", "llm-api-dependency-risk", "supply-chain-model-risk" ], "desc": "Vendor AI models are often deployed without the same rigor as internally developed models, creating blind spots where critical financial decisions rely on unvalidated third-party logic. LLM APIs introduce novel risks including prompt injection, hallucinated outputs in financial contexts, and vendor-side model updates that change behavior without notice. SR 26-2 extends model risk management expectations to third-party models (Vendor and Other Third-Party Products), though footnote 3 excludes generative AI systems from the guidance's stated scope." }, "standard": [ { "id": "sr26_2", "section": "\u00a7VII", "title": "Vendor and other third-party products" }, { "id": "eu_ai_act", "section": "Art. 25", "title": "Responsibilities along the AI value chain" }, { "id": "anthropic_rsp", "section": "Capability Thresholds and Required Safeguards", "title": "Vendor risk-governance disclosure (RSP v3.3)" }, { "id": "openai_enterprise", "section": "Enterprise privacy commitments", "title": "Vendor data handling and audit-log capabilities" } ], "sources": [ { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Anthropic's Responsible Scaling Policy v3.3 documents the vendor's capability thresholds and safeguards, cited as third-party AI due diligence context for the apeiris://finance/controls/MR-06 Third-Party and Vendor AI Model Risk Management control.", "reviewed_on": "2026-07-02" }, { "id": "openai_enterprise_data_governance_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "OpenAI's enterprise privacy and compliance documentation records vendor-side data handling and audit-log capabilities relevant to the apeiris://finance/controls/MR-06 Third-Party and Vendor AI Model Risk Management control.", "reviewed_on": "2026-07-02" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://finance/controls/MR-06 Third-Party and Vendor AI Model Risk Management control.", "reviewed_on": "2026-07-01" }, { "id": "aws_financial_services_compliance_2024", "title": "AWS User Guide to Financial Services Regulations & Guidelines in the United States", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/financial-services/security-compliance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_financial_services_compliance_2024", "relationship": "informative_reference", "rationale": "AWS's financial services regulatory guide and compliance tooling document infrastructure-layer capabilities relevant to the apeiris://finance/controls/MR-06 Third-Party and Vendor AI Model Risk Management control.", "reviewed_on": "2026-07-02" }, { "id": "google_cloud_financial_services_ai_2024", "title": "Google Cloud Explainable AI", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/explainable-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_financial_services_ai_2024", "relationship": "informative_reference", "rationale": "Google Cloud's Explainable AI and Vertex AI model governance documentation describes platform capabilities relevant to the apeiris://finance/controls/MR-06 Third-Party and Vendor AI Model Risk Management control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Third-party model inventory integrated with main model registry; vendor due diligence checklist; contract requirements for validation support and change notification; compensating controls for opaque models; ongoing monitoring covering vendor model updates.", "steps": [ "Extend the model inventory to capture all third-party vendor models with fields for: vendor name, model version, API endpoint, change notification SLA, validation documentation provided, and contractual validation rights.", "Develop a vendor AI model due diligence checklist covering: model documentation quality, validation evidence provided, bias and fairness testing results, EU AI Act classification and conformity documentation, change notification process, and data handling terms.", "Include model risk management contract clauses in all vendor AI agreements: right to audit, advance notice of model updates that could affect outputs, data residency requirements, and incident notification obligations.", "Implement compensating controls for opaque third-party models: output validation layers, shadow model comparison, human review thresholds, and usage monitoring for LLM API calls in financial contexts." ], "model_risk_officer": { "summary": "SR 26-2 applies model risk expectations to vendor models as well as internal ones (generative AI is outside the guidance's stated scope per footnote 3). The MRO must ensure third-party models are inventoried, assessed, and monitored, with contractual rights that support ongoing validation.", "actions": [ "Review and approve the third-party model due diligence framework and vendor contract requirements.", "Conduct or oversee risk assessments for all High and Critical tier third-party models.", "Maintain oversight of vendor model change notifications and assess impact of vendor updates on institutional model risk." ], "failure_signals": [ "Third-party models in production without inventory records and risk tier assignments.", "Vendor model updates deployed without MRM impact assessment.", "No contractual right to validation documentation or change notification for material vendor models." ] }, "compliance_officer": { "summary": "Third-party AI model risk is a growing regulatory focus under SR 26-2, EU AI Act Article 25, and third-party risk management guidance. Compliance must ensure vendor model obligations are contractually secured and documented.", "actions": [ "Map all vendor AI models to EU AI Act Article 25 responsibilities along the value chain \u2014 determine whether the institution acts as deployer, provider, or both.", "Review vendor AI contracts for the validation-support and change-notification provisions this control requires and flag gaps for legal remediation.", "Include third-party model risk in annual vendor risk assessment and third-party risk management reporting." ], "metrics": [ "Third-party model inventory completeness: 100% of vendor AI models in scope registered.", "Vendor contracts with required validation-support provisions: target 100% of material vendor models.", "Time to impact assess a vendor model update: target \u2264 5 business days from notification." ], "failure_signals": [ "Material vendor AI models without contractual change notification provisions.", "EU AI Act high-risk AI deployer obligations not identified for third-party AI systems.", "Third-party model risk not included in vendor risk management reporting." ] }, "internal_audit": { "summary": "Audit must verify that third-party model risk management is applied consistently with internal model standards, with particular focus on LLM API integrations and opaque vendor models.", "actions": [ "Audit a sample of vendor AI models for completeness of due diligence documentation and risk assessment.", "Review vendor contracts for required validation support and change notification clauses.", "Test effectiveness of compensating controls for opaque vendor models used in material financial decisions." ], "failure_signals": [ "Third-party models used in credit, trading, or financial reporting without MRM documentation.", "Vendor contracts lacking change notification or audit rights provisions.", "LLM API integrations without output validation controls in financial decision workflows." ] }, "it_operations": { "summary": "IT Operations manages vendor AI API integrations and must implement technical controls that detect and respond to vendor-side model changes that could affect financial outputs.", "actions": [ "Implement version pinning for vendor AI API calls where the vendor supports it, preventing automatic model updates from reaching production.", "Monitor vendor API response characteristics for statistical changes that could indicate a model update.", "Log all vendor AI API calls for LLMs used in financial contexts with full input/output retention per data governance policy." ], "failure_signals": [ "Vendor AI APIs called without version pinning where vendor supports it.", "No technical detection of vendor model changes via response distribution monitoring.", "LLM API call logs absent for financial decision workflows." ] }, "financial_controller": { "summary": "Vendor models embedded in the reporting chain are still the institution's misstatement risk; the controller cannot outsource reliance.", "actions": [ "Identify vendor AI models whose outputs reach financial statements and confirm they are in the inventory with validation evidence.", "Require compensating reconciliation controls where vendor model transparency is limited." ], "failure_signals": [ "Vendor model outputs entering financial reports without independent validation evidence.", "Vendor model changes discovered only after period-end variances." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Third-party model risk management is a common weak point in model risk programs; LLM API risk management practices are nascent across the financial services industry." }, "capability_risk": { "capability_level": "low" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "Model Risk Management", "Vendor / Third-Party Risk Management", "Legal / Contracts", "IT Operations" ], "frameworks": [ { "framework": "sr26_2", "requirement_id": "\u00a7VII (Vendor and Third-Party)", "fit": "direct", "rationale": "SR 26-2 \u00a7VII addresses models obtained from vendors and other third parties, describing expectations that institutions understand vendor models, their limitations, and their appropriate use, and apply commensurate validation and monitoring. Footnote 3 of the guidance excludes generative AI and agentic systems from its stated scope, so vendor LLMs are covered by this control as institutional practice extending the \u00a7VII discipline, not by the guidance itself.", "normative_force": "supervisory-guidance", "source_version": "2026-04-17", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "eu_ai_act", "requirement_id": "Art. 25", "fit": "direct", "rationale": "EU AI Act Article 25 establishes responsibilities along the AI value chain, clarifying that deployers of high-risk AI systems bear compliance obligations even when using third-party AI. Financial institutions that deploy vendor AI systems in high-risk use cases are responsible for ensuring conformity with EU AI Act requirements and cannot delegate this responsibility entirely to the vendor. This creates direct compliance obligations for third-party AI model governance.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-06-28", "basis": "anchored", "relation": "satisfies" }, { "framework": "anthropic_rsp", "requirement_id": "Capability Thresholds and Required Safeguards", "fit": "adjacent", "rationale": "Anthropic's Responsible Scaling Policy v3.3 defines Capability Thresholds and the Required Safeguards that apply when models cross them \u2014 the vendor's own published risk-governance framework. For institutions consuming Anthropic models, the RSP is a vendor-governance artifact to review during third-party AI due diligence; it documents the vendor's controls and disclosure posture, not the institution's model risk management obligations.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "openai_enterprise", "requirement_id": "Enterprise privacy \u2014 compliance commitments", "fit": "partial", "rationale": "OpenAI's enterprise privacy documentation records its compliance commitments (SOC 2 Type 2, encryption, retention controls) for enterprise customers. Institutions using OpenAI models in financial workflows can incorporate this vendor capability into third-party and vendor AI model risk management. This is vendor capability documentation, not regulatory guidance; it covers the vendor side only.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "A2", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal A2 (Oversight of significant adverse impacts) requires defined review and oversight processes for AI systems that can cause significant adverse impact. For institutions using Azure AI services, this goal produces vendor-side governance artifacts that align with third-party and vendor AI model risk management. The Standard is Microsoft's published internal policy offered as reference practice, not regulatory guidance.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_financial", "requirement_id": "Financial Services Industry Lens \u2014 AWS Well-Architected", "fit": "partial", "rationale": "The Financial Services Industry Lens for the AWS Well-Architected Framework describes design principles, risk considerations, and shared-responsibility boundaries for regulated financial workloads on AWS. For AWS-hosted financial AI systems, this supplies the infrastructure-layer support and evidence stream for third-party and vendor AI model risk management. This is vendor documentation of real AWS capabilities \u2014 it does not substitute for model-layer validation or regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_financial", "requirement_id": "Google Cloud compliance offerings", "fit": "partial", "rationale": "Google Cloud's compliance offerings catalog documents the platform's third-party attestations (SOC 1/2/3, ISO/IEC 27001, PCI DSS) available to customers. For GCP-hosted financial AI systems, this capability supplies the platform-layer support for third-party and vendor AI model risk management. This is vendor product documentation, not regulatory guidance; it does not address model-layer regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://finance/controls/MR-06", "meta": { "authored_on": "2026-06-29", "schema_version": "1.1.0" }, "validation_objective": "All third-party vendor AI models used in material financial decisions must be registered in the model inventory with a completed MRM due diligence record; contractual provisions for change notification and validation support must be confirmed in place for all material vendor models; and compensating controls must be documented and technically operational for opaque vendor models where direct validation access is unavailable.", "evidence_required": [ "third_party_model_inventory_record for each vendor AI model showing vendor_name, model_version, api_endpoint, risk_tier, due_diligence_status, and contract_review_date", "vendor_due_diligence_checklist_completed covering model documentation quality, validation evidence provided, bias and fairness testing results, EU AI Act conformity documentation, and change notification process assessment", "vendor_ai_contract_review_record confirming presence of change_notification_clause, audit_rights_clause, and data_residency_requirements for each material vendor model contract", "compensating_control_documentation for opaque vendor models showing output_validation_layer_design, shadow_model_comparison_methodology, and human_review_threshold_definitions", "vendor_change_notification_log recording all received vendor model update notifications with linked mrm_impact_assessment_records showing assessment_date within 5 business days of notification_date" ], "machine_tests": [ "Query model inventory for models where source=third_party \u2192 assert 100% have a linked due_diligence_record with completion_date within last 12 months", "Pull vendor AI contract metadata for material vendor models \u2192 assert change_notification_clause=present and audit_rights_clause=present for all material vendor model contracts", "Query vendor change notification log for last 12 months \u2192 assert all notifications have a linked mrm_impact_assessment_record with assessment_date within 5 business days of notification_date", "Test compensating control for an opaque LLM API in a financial decision workflow \u2192 assert output validation layer intercepts responses containing financial data outside defined confidence bounds and flags for review" ], "human_review": [ "Review the third-party model due diligence framework to assess whether it applies validation standards consistently to vendor models including LLMs and generative AI (which SR 26-2 footnote 3 excludes from the guidance's stated scope), not only to traditional credit scoring models", "Evaluate vendor contracts for material AI models to confirm change notification SLAs and audit rights are operationally enforceable and aligned to the institution's MRM impact assessment timelines", "Assess compensating controls for opaque vendor models to determine whether they would detect and contain financially material errors produced by the vendor model before they propagate to decisions" ], "blocking_effect": "requires-review", "normative_status": "supervisory-guidance", "anti_patterns": [ "Treating vendor AI models as exempt from model risk management because the institution did not build the model, when SR 26-2's vendor and third-party products section applies validation expectations to vendor-provided models as well", "Signing vendor AI contracts without negotiating change notification clauses, resulting in vendor model updates reaching production financial workflows without any MRM impact assessment", "Applying due diligence only to traditional third-party credit scoring models while treating LLM API integrations as commodity software outside MRM scope", "Using version-unpinned LLM API calls in production financial decision workflows, allowing vendor-side model updates to modify financial outputs without any technical detection or assessment gate", "Documenting compensating controls for opaque vendor models on paper without implementing them technically in the production API integration layer so they function as described" ], "update_status": "current", "layer_code": "MR" }, { "id": "MR-07", "layer": "MR", "plane": "control", "name": "Emerging Model Risk Identification", "plain": "The institution must maintain a structured process for identifying, assessing, and incorporating emerging AI model risks \u2014 including risks from large language models, generative AI, agentic AI systems, and novel AI capabilities \u2014 into the MRM framework before these risks materialize in production.", "threat": { "tags": [ "emerging-capability-blind-spot", "llm-hallucination-risk", "agentic-ai-uncontrolled-action", "framework-currency-gap" ], "desc": "Financial institutions deploying frontier AI capabilities face risks that do not fit traditional MRM frameworks designed for statistical models. LLMs can hallucinate plausible but incorrect financial data; agentic AI systems can take consequential actions autonomously; generative models can produce outputs that expose institutions to regulatory liability. Organizations that fail to evolve their MRM frameworks are exposed to novel risks that existing controls do not address." }, "standard": [ { "id": "sr26_2", "section": "\u00a7III", "title": "Overview of model risk and model risk management" }, { "id": "eu_ai_act", "section": "Art. 9(2)", "title": "Risk identification for new AI capabilities" }, { "id": "anthropic_rsp", "section": "Capability assessments", "title": "Vendor capability assessment commitments (RSP v3.3)" }, { "id": "microsoft_rai", "section": "T1-T3", "title": "Transparency goals \u2014 intelligibility, communication, disclosure" } ], "sources": [ { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://finance/controls/MR-07 Emerging Model Risk Identification control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Anthropic's Responsible Scaling Policy v3.3 documents the vendor's capability thresholds and safeguards, cited as third-party AI due diligence context for the apeiris://finance/controls/MR-07 Emerging Model Risk Identification control.", "reviewed_on": "2026-07-02" }, { "id": "google_cloud_financial_services_ai_2024", "title": "Google Cloud Explainable AI", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/explainable-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_financial_services_ai_2024", "relationship": "informative_reference", "rationale": "Google Cloud's Explainable AI and Vertex AI model governance documentation describes platform capabilities relevant to the apeiris://finance/controls/MR-07 Emerging Model Risk Identification control.", "reviewed_on": "2026-07-02" }, { "id": "openai_enterprise_data_governance_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "OpenAI's enterprise privacy and compliance documentation records vendor-side data handling and audit-log capabilities relevant to the apeiris://finance/controls/MR-07 Emerging Model Risk Identification control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Emerging AI risk horizon scanning program: quarterly review of AI capability developments, regulatory guidance, and industry incidents; MRM framework gap analysis; fast-track risk assessment procedures for novel AI model types; MRO-led emerging risk briefings to board risk committee.", "steps": [ "Establish a quarterly AI emerging risk horizon scanning program that reviews: regulatory guidance updates from the Federal Reserve, OCC, CFPB, and EU AI Office; academic literature on AI risk; financial industry incident reports; and vendor AI capability announcements.", "Define a fast-track risk assessment procedure for novel AI model types that can onboard a new model category into the MRM framework within 30 days of identification as a material risk.", "Maintain a living catalogue of AI capability risk profiles covering LLM hallucination risk, generative AI output risk, agentic AI action risk, multimodal AI risk, and model distillation risk \u2014 with financial-services-specific impact scenarios.", "Deliver quarterly emerging AI risk briefings to the board risk committee and conduct annual MRM framework gap assessments identifying where current policy and procedures do not address emerging model risks." ], "model_risk_officer": { "summary": "Emerging model risk identification is the forward-looking component of MRM that prevents novel AI capabilities from outpacing governance. The MRO must proactively scan for new risks and update the framework to address them.", "actions": [ "Lead the quarterly emerging AI risk horizon scanning program and produce briefings for the board risk committee.", "Maintain and update the AI capability risk profile catalogue as new capabilities become relevant to financial services.", "Initiate MRM framework updates when emerging risk assessments identify governance gaps." ], "failure_signals": [ "No formal emerging AI risk horizon scanning process in place.", "LLM or generative AI model deployments not addressed in MRM policy or procedures.", "Board risk committee not receiving emerging AI risk briefings at least quarterly." ] }, "compliance_officer": { "summary": "Emerging model risk identification supports regulatory readiness by ensuring MRM frameworks evolve to address new regulatory guidance and novel AI risks before examination.", "actions": [ "Monitor regulatory guidance from the Fed, OCC, CFPB, and EU AI Office for new model risk expectations and integrate into the compliance monitoring calendar.", "Verify that emerging AI risk assessments address EU AI Act prohibited and high-risk AI categories as they are clarified by the EU AI Office.", "Include emerging AI risk identification process maturity in annual MRM compliance assessment." ], "metrics": [ "Horizon scanning frequency: minimum quarterly review with documented output.", "Days from regulatory guidance issuance to MRM framework assessment: target \u2264 30 days.", "New AI model types assessed before production deployment: target 100%." ], "failure_signals": [ "New regulatory guidance on AI model risk not reviewed within 30 days of issuance.", "Novel AI model types deployed in financial workflows without emerging risk assessment.", "MRM framework not updated for more than 12 months despite material AI capability changes." ] }, "internal_audit": { "summary": "Audit must assess whether the institution's MRM emerging risk processes are functioning and whether they have successfully identified and responded to emerging AI risks before deployment.", "actions": [ "Review documented outputs of quarterly horizon scanning reviews and assess completeness.", "Test whether novel AI model deployments such as LLMs and generative AI have documented emerging risk assessments.", "Assess whether MRM policy and procedures have been updated to address current AI capability risks." ], "failure_signals": [ "No documented emerging AI risk scanning activity in the prior 12 months.", "LLM or agentic AI deployments without documented emerging risk assessments.", "MRM framework that still treats statistical regression models as the primary model type without addressing generative AI." ] }, "financial_controller": { "summary": "Emerging AI risks include models that could affect financial statement accuracy. The Controller must ensure emerging AI risks with financial reporting implications are captured in the ICFR risk assessment.", "actions": [ "Participate in emerging AI risk horizon scanning reviews to identify novel AI risks with potential ICFR implications.", "Flag emerging AI risks affecting financially material models for accelerated ICFR assessment." ], "failure_signals": [ "Emerging AI risks affecting financial reporting models not identified in annual ICFR risk assessment.", "Novel AI capabilities used in financial close without dedicated emerging risk and ICFR assessment." ] }, "it_operations": { "summary": "IT Operations runs the emerging-risk watchlist and model telemetry behind emerging model risk identification and horizon scanning \u2014 integrating it with deployment pipelines, enforcing the automated gates, and keeping the supporting data flows reliable and auditable.", "actions": [ "Integrate the emerging-risk watchlist and model telemetry with CI/CD and runtime tooling so that new model types and capabilities are detected and routed to the horizon-scanning process.", "Automate collection and retention of capability-change telemetry from vendors and platforms in immutable, hash-verified storage.", "Monitor pipeline and integration health and alert when new AI services appear in cloud usage without a corresponding risk review." ], "failure_signals": [ "Production changes bypass the automated gate so that it is no longer true that new model types and capabilities are detected and routed to the horizon-scanning process.", "Gaps or outages in capability-change telemetry from vendors and platforms collection exceeding 24 hours.", "Manual, untracked edits to the emerging-risk watchlist and model telemetry records." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Emerging model risk identification programs are nascent; most MRM frameworks were designed for traditional statistical models and have not been updated to systematically address LLM, generative, and agentic AI risks." }, "capability_risk": { "capability_level": "low" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector", "eu-high-risk-ai" ], "implementers": [ "Model Risk Management", "Chief Risk Officer", "Compliance", "Technology / AI Center of Excellence" ], "frameworks": [ { "framework": "sr26_2", "requirement_id": "\u00a7III (Overview of Model Risk and MRM)", "fit": "direct", "rationale": "SR 26-2 \u00a7III describes model risk broadly and frames model risk management as needing to keep pace with changes in the institution's model landscape. Note the scope boundary: footnote 3 excludes generative AI and agentic systems from the guidance's stated scope, so an emerging-risk identification process is the institution's own mechanism for extending MRM discipline to model types the guidance does not cover.", "normative_force": "supervisory-guidance", "source_version": "2026-04-17", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "eu_ai_act", "requirement_id": "Art. 9(2)", "fit": "direct", "rationale": "EU AI Act Article 9(2) requires that the risk management system include processes for identifying risks that may emerge after deployment or from novel capability combinations. For frontier AI systems such as LLMs and multimodal models, this emerging risk identification obligation is ongoing and must be systematically addressed. The EU AI Office's iterative guidance on general-purpose AI also creates an ongoing emerging-risk identification obligation.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-06-28", "basis": "anchored", "relation": "satisfies" }, { "framework": "anthropic_rsp", "requirement_id": "Capability assessments", "fit": "adjacent", "rationale": "RSP v3.3 commits Anthropic to capability assessments that determine whether models cross defined Capability Thresholds. Tracking vendor capability assessments and threshold determinations is one input to emerging model risk identification for institutions running Anthropic-backed systems; the fit is adjacent \u2014 the RSP governs frontier-model safety, not financial model risk.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "T1-T3", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Transparency Goals T1-T3 require system intelligibility for decision making, communication of capabilities and limitations to stakeholders, and disclosure of AI interaction. For institutions using Azure AI services, this goal produces vendor-side governance artifacts that align with emerging model risk identification and horizon scanning. The Standard is Microsoft's published internal policy offered as reference practice, not regulatory guidance.", "normative_force": "best-practice", "source_version": "2022", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "coso_icfr", "requirement_id": "Component 2", "fit": "adjacent", "rationale": "COSO ICIF Component 2 requires organizations to identify and analyze new or changing risks on an ongoing basis. Emerging AI capabilities represent a change in the risk landscape that must be incorporated into COSO-aligned risk assessments. The emerging risk identification process is the operational mechanism for fulfilling this COSO requirement with respect to AI-specific risks.", "normative_force": "voluntary-standard", "source_version": "2013", "reviewed_on": "2026-06-28", "basis": "asserted", "relation": "informs" }, { "framework": "google_financial", "requirement_id": "Model Cards", "fit": "partial", "rationale": "Model Cards provide structured, versioned documentation of a model's purpose, performance characteristics, and limitations. For GCP-hosted financial AI systems, this capability supplies the platform-layer support for emerging model risk identification and horizon scanning. This is vendor product documentation, not regulatory guidance; it does not address model-layer regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "openai_enterprise", "requirement_id": "Enterprise Compliance API \u2014 audit logs", "fit": "adjacent", "rationale": "ChatGPT Enterprise and the OpenAI API expose workspace audit-log data through the Compliance API and audit logs endpoint, exportable to SIEM and evidence stores. Institutions using OpenAI models in financial workflows can incorporate this vendor capability into emerging model risk identification and horizon scanning. This is vendor capability documentation, not regulatory guidance; it covers the vendor side only.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://finance/controls/MR-07", "meta": { "authored_on": "2026-06-29", "schema_version": "1.1.0" }, "validation_objective": "A structured emerging AI risk horizon scanning program must be operational and producing documented quarterly review outputs that assess new AI capabilities, regulatory guidance updates, and industry incidents; any novel AI model type identified as materially relevant must have a completed emerging risk assessment and MRM framework gap analysis on file before it is permitted in production financial workflows.", "evidence_required": [ "quarterly_horizon_scan_report documenting AI capability developments reviewed, regulatory guidance assessed, industry incidents analyzed, and emerging risks identified, with mro_signoff_date for each quarter in the prior 12 months", "ai_capability_risk_profile_catalogue showing current entries for LLM hallucination risk, generative AI output risk, agentic AI action risk, and multimodal AI risk with financial-services-specific impact scenarios and last_updated_date within 90 days", "emerging_risk_assessment_record for each novel AI model type deployed in production showing risk_identification_date, assessment_completion_date before production_deployment_date, and MRM_framework_gap_findings", "mrm_framework_gap_analysis document updated within the last 12 months comparing current MRM policy coverage against novel AI model types in production or under evaluation with remediation_action_items", "board_risk_committee_briefing_record for emerging AI risk briefings showing at least quarterly delivery frequency in the prior 12 months" ], "machine_tests": [ "Query emerging risk program records \u2192 assert a horizon_scan_report with mro_signoff_date exists for each calendar quarter in the prior 12 months", "Pull list of novel AI model types deployed in production in the last 12 months \u2192 assert each has a linked emerging_risk_assessment_record with assessment_complete_date before production_deployment_date", "Query board risk committee meeting records \u2192 assert emerging AI risk agenda item appears at least once per quarter in the prior 12 months", "Check AI capability risk profile catalogue \u2192 assert last_updated_date for LLM_hallucination_risk and agentic_ai_action_risk profiles is within 90 days" ], "human_review": [ "Review a sample of quarterly horizon scan reports to assess whether they reflect genuine analysis of current AI capability developments and regulatory guidance from Fed/OCC/CFPB/EU AI Office, rather than pro forma documentation", "Assess whether the AI capability risk profile catalogue addresses risks specific to generative AI, agentic AI, and frontier models in financial services contexts with actionable and institution-specific impact scenarios", "Evaluate whether MRM framework gap analyses have resulted in documented policy updates for identified novel AI model types, and whether gaps identified in prior assessments have been remediated within target timelines" ], "blocking_effect": "blocks-deployment", "normative_status": "supervisory-guidance", "anti_patterns": [ "Deploying LLM, generative AI, or agentic AI models in financial workflows without conducting an emerging risk assessment, treating them as extensions of traditional statistical models that require only standard MRM validation procedures", "Conducting emerging AI risk horizon scanning only reactively after an incident or supervisory criticism, rather than as a proactive recurring program (quarterly is a common internal cadence) that anticipates risks before they materialize", "Limiting the horizon scanning program to internal analysis without systematically incorporating regulatory guidance from the Fed, OCC, CFPB, and EU AI Office as primary structured inputs", "Maintaining an AI capability risk profile catalogue that covers only LLMs without addressing agentic AI, multimodal models, or model distillation risks increasingly relevant to financial services decision-making", "Treating MRM framework gap analysis as a one-time activity rather than an ongoing process that updates as new AI capabilities are identified and evaluated for deployment" ], "update_status": "current", "layer_code": "MR" }, { "id": "MR-08", "layer": "MR", "plane": "both", "name": "Model Risk Evidence Package", "plain": "The institution must compile and maintain a Model Risk Evidence Package \u2014 a structured collection of attestations, validation reports, monitoring records, and governance artifacts from MR-01 through MR-07 \u2014 demonstrating that model risk management practices satisfy SR 26-2 and EU AI Act requirements at any point in time.", "threat": { "tags": [ "evidence-gap", "regulatory-examination-failure", "attestation-staleness", "governance-artifact-fragmentation" ], "desc": "Model risk governance activities may be performed diligently but leave no consolidated, auditable evidence trail. During regulatory examinations or audit engagements, fragmented or missing evidence draws supervisory criticism even when the underlying practices are adequate. An MR evidence package that cannot be assembled on-demand creates reputational and regulatory risk disproportionate to actual governance quality." }, "standard": [ { "id": "sr26_2", "section": "\u00a7VI (Documentation)", "title": "Documentation supporting model risk management" }, { "id": "eu_ai_act", "section": "Art. 11", "title": "Technical documentation for high-risk AI systems" }, { "id": "pcaob_as_2201", "section": "\u00b6.46", "title": "Risk-based evidence for control effectiveness" }, { "id": "sox", "section": "\u00a7404(b)", "title": "External auditor attestation on internal controls" } ], "sources": [ { "id": "openai_enterprise_data_governance_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "OpenAI's enterprise privacy and compliance documentation records vendor-side data handling and audit-log capabilities relevant to the apeiris://finance/controls/MR-08 Model Risk Evidence Package control.", "reviewed_on": "2026-07-02" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://finance/controls/MR-08 Model Risk Evidence Package control.", "reviewed_on": "2026-07-01" }, { "id": "aws_financial_services_compliance_2024", "title": "AWS User Guide to Financial Services Regulations & Guidelines in the United States", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/financial-services/security-compliance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_financial_services_compliance_2024", "relationship": "informative_reference", "rationale": "AWS's financial services regulatory guide and compliance tooling document infrastructure-layer capabilities relevant to the apeiris://finance/controls/MR-08 Model Risk Evidence Package control.", "reviewed_on": "2026-07-02" }, { "id": "google_cloud_financial_services_ai_2024", "title": "Google Cloud Explainable AI", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/explainable-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_financial_services_ai_2024", "relationship": "informative_reference", "rationale": "Google Cloud's Explainable AI and Vertex AI model governance documentation describes platform capabilities relevant to the apeiris://finance/controls/MR-08 Model Risk Evidence Package control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Centralized evidence repository with automated artifact ingestion from model registry, validation management system, and monitoring platform; quarterly evidence package assembly; on-demand regulatory examination package generation; automated evidence completeness scoring.", "steps": [ "Define the MR Evidence Package schema: required artifacts by control (MR-01 through MR-07), required fields per artifact, retention requirements, and completeness scoring criteria.", "Integrate the evidence repository with the model registry (MR-01), validation management system (MR-03), monitoring dashboards (MR-05), and vendor risk management system (MR-06) for automated artifact ingestion.", "Produce a quarterly MR Evidence Package completeness score for each material model covering: inventory currency, risk tier validation, pre-deployment assessment record, monitoring coverage, and ongoing monitoring status.", "Maintain a regulatory examination-ready evidence package that can be exported for any material model within 2 business days, including all MR-01 through MR-07 artifacts and a model risk attestation signed by the MRO." ], "model_risk_officer": { "summary": "The MR Evidence Package is the MRO's primary artifact for demonstrating SR 26-2 alignment to regulators, auditors, and the board. The MRO attests to the completeness and accuracy of the package.", "actions": [ "Review and sign the quarterly MR Evidence Package completeness report for all material models.", "Maintain examination-ready evidence packages for all High and Critical tier models.", "Attest to the completeness of MR-layer evidence as part of the annual Model Risk Attestation." ], "failure_signals": [ "Evidence packages for High/Critical tier models with completeness scores below 90%.", "MRO unable to produce regulatory examination package for a material model within 2 business days.", "Quarterly completeness reports not produced or reviewed for more than one reporting period." ] }, "compliance_officer": { "summary": "The MR Evidence Package is the compliance artifact that maps to SR 26-2 sections and EU AI Act technical documentation requirements, enabling regulatory examination readiness.", "actions": [ "Map evidence package fields to SR 26-2 documentation expectations and EU AI Act Article 11 technical documentation obligations.", "Include MR evidence package completeness rates in quarterly regulatory compliance reporting.", "Conduct semi-annual evidence package readiness review to confirm regulatory examination preparedness." ], "metrics": [ "Evidence package completeness score for material models: target \u2265 95%.", "Time to produce examination-ready package: target \u2264 2 business days.", "Supervisory criticism citing evidence gaps: target zero." ], "failure_signals": [ "Material models with evidence package completeness below 90%.", "EU AI Act Article 11 technical documentation requirements not mapped to evidence package fields.", "Evidence package not producible in time for regulatory examination requests." ] }, "internal_audit": { "summary": "Audit uses the MR Evidence Package as the primary population and artifact source for MRM audit engagements. Its completeness and accuracy are independent audit objectives.", "actions": [ "Annually audit MR Evidence Package completeness for a sample of material models, testing artifact authenticity and currency.", "Assess whether evidence package fields satisfy the documentation expectations described in SR 26-2 (Documentation, within Governance and Controls).", "Report evidence gaps as control deficiencies with specific artifact-level remediation requirements." ], "failure_signals": [ "Sampled evidence packages with stale (>12 months) validation artifacts not flagged by automated completeness scoring.", "Evidence packages missing key artifacts described in SR 26-2 such as the pre-deployment validation report or ongoing monitoring records.", "Evidence repository lacking audit trail for artifact changes or access." ] }, "financial_controller": { "summary": "The MR Evidence Package for financially material models is a prerequisite for SOX 404 management assessment and supports external auditor testing of model-related ICFR.", "actions": [ "Ensure that MR Evidence Packages for SOX-scoped models satisfy PCAOB AS 2201 documentation requirements for management's assessment of internal controls.", "Provide MR Evidence Packages for financially material models to external auditors as part of annual ICFR audit support." ], "failure_signals": [ "SOX-scoped models without complete MR Evidence Packages at the time of annual ICFR assessment.", "External auditors citing model risk evidence gaps as a control deficiency in the ICFR opinion." ] }, "it_operations": { "summary": "IT Operations maintains the evidence repository infrastructure, ensuring artifact ingestion pipelines are reliable, data is retained per policy, and the system supports on-demand package generation.", "actions": [ "Maintain evidence repository with high availability SLA and automated artifact ingestion pipelines from source systems.", "Implement data retention policies aligned to regulatory retention requirements (a multi-year internal retention standard for model risk documentation; SR 26-2 itself sets no retention period).", "Provide access controls ensuring evidence artifact integrity \u2014 prevent modification after creation with cryptographic hash verification." ], "failure_signals": [ "Evidence repository outages exceeding 4 hours in any month.", "Artifact ingestion pipeline failures causing gaps in evidence records for more than 24 hours.", "Evidence artifacts modifiable post-creation without cryptographic integrity protection." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Most institutions manage model risk evidence in fragmented systems and spreadsheets; automated evidence packages with completeness scoring are an emerging best practice driven by regulatory examination pressure." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "Model Risk Management", "Compliance", "IT Operations", "Internal Audit" ], "frameworks": [ { "framework": "sr26_2", "requirement_id": "\u00a7VI (Documentation)", "fit": "direct", "rationale": "SR 26-2 \u00a7VI (Governance and Controls) addresses documentation under its Documentation subheading \u2014 sufficient for a knowledgeable third party to understand a model's development, validation, and use. The MR evidence package operationalizes that documentation expectation across the model portfolio.", "normative_force": "supervisory-guidance", "source_version": "2026-04-17", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "eu_ai_act", "requirement_id": "Art. 11", "fit": "direct", "rationale": "EU AI Act Article 11 requires providers of high-risk AI systems to draw up and keep up-to-date technical documentation that demonstrates compliance with the requirements of the regulation. Annex IV of the Act specifies the content of this technical documentation. An MR Evidence Package for high-risk financial AI systems must satisfy these Annex IV requirements to support EU AI Office market surveillance and notified body assessments.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-06-28", "basis": "anchored", "relation": "satisfies" }, { "framework": "pcaob_as_2201", "requirement_id": "\u00b6.46", "fit": "direct", "rationale": "AS 2201 \u00b6.46 states that the evidence necessary to persuade the auditor that a control is effective depends upon the risk associated with the control. A consolidated model risk evidence package is the mechanism by which management makes model-related ICFR control evidence available at the depth \u00b6.46's risk-based evidence standard demands.", "normative_force": "certification-standard", "source_version": "2007", "reviewed_on": "2026-07-02", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "sox", "requirement_id": "\u00a7404(b)", "fit": "direct", "rationale": "SOX Section 404(b) requires external auditors to attest to management's assessment of internal controls over financial reporting. For model-driven ICFR processes, the MR Evidence Package is the primary artifact supporting both management's assessment and auditor testing. Inadequate model risk evidence documentation is a common cause of SOX 404 deficiencies for financial institutions with model-dependent financial reporting.", "normative_force": "binding-law", "source_version": "2002", "reviewed_on": "2026-06-28", "basis": "asserted", "relation": "satisfies" }, { "framework": "soc2", "requirement_id": "CC4.1", "fit": "partial", "rationale": "AICPA SOC 2 CC4.1 requires entities to monitor controls through ongoing and separate evaluations and to communicate deficiencies in a timely manner. An MR Evidence Package with automated completeness scoring functions as a control monitoring system for model risk controls, satisfying the spirit of CC4.1. Financial technology providers subject to SOC 2 Type II assessments should include MRM evidence management in their CC4.1 control monitoring narrative.", "normative_force": "certification-standard", "source_version": "2022", "reviewed_on": "2026-06-28", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "bcbs_239", "requirement_id": "Principle 11", "fit": "adjacent", "rationale": "BCBS 239 Principle 11 (Distribution) requires risk management reports to be distributed to the relevant parties while ensuring confidentiality. A consolidated model risk evidence package with controlled distribution to board, audit, and supervisory consumers applies that distribution-with-confidentiality discipline to model risk documentation; the fit is partial.", "normative_force": "supervisory-guidance", "source_version": "2013", "reviewed_on": "2026-07-02", "basis": "asserted", "relation": "satisfies" }, { "framework": "openai_enterprise", "requirement_id": "Enterprise privacy \u2014 compliance commitments", "fit": "partial", "rationale": "OpenAI's enterprise privacy documentation records its compliance commitments (SOC 2 Type 2, encryption, retention controls) for enterprise customers. Institutions using OpenAI models in financial workflows can incorporate this vendor capability into the consolidated model risk evidence package. This is vendor capability documentation, not regulatory guidance; it covers the vendor side only.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "T2", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal T2 (Communication to stakeholders) requires communicating system capabilities and limitations to stakeholders. For institutions using Azure AI services, this goal produces vendor-side governance artifacts that align with the consolidated model risk evidence package. The Standard is Microsoft's published internal policy offered as reference practice, not regulatory guidance.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_financial", "requirement_id": "AWS Artifact", "fit": "partial", "rationale": "AWS Artifact provides on-demand access to AWS's third-party compliance reports (SOC 1/2, PCI DSS, ISO). For AWS-hosted financial AI systems, this supplies the infrastructure-layer support and evidence stream for the consolidated model risk evidence package. This is vendor documentation of real AWS capabilities \u2014 it does not substitute for model-layer validation or regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_financial", "requirement_id": "Google Cloud compliance offerings", "fit": "partial", "rationale": "Google Cloud's compliance offerings catalog documents the platform's third-party attestations (SOC 1/2/3, ISO/IEC 27001, PCI DSS) available to customers. For GCP-hosted financial AI systems, this capability supplies the platform-layer support for the consolidated model risk evidence package. This is vendor product documentation, not regulatory guidance; it does not address model-layer regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://finance/controls/MR-08", "meta": { "authored_on": "2026-06-29", "schema_version": "1.1.0" }, "validation_objective": "The institution must maintain a Model Risk Evidence Package for each material model that can be assembled and provided to regulatory examiners within 2 business days, achieving a completeness score of 95% or greater across all required artifact categories spanning MR-01 through MR-07. Evidence package completeness must be verifiable on-demand through automated scoring without manual reconstruction of artifacts.", "evidence_required": [ "evidence_package_index per material model listing all required artifact categories (MR-01 through MR-07), presence status, artifact_id, and last_updated timestamp for each slot", "automated_completeness_score_report per model showing percentage of required artifact slots populated, scored against the defined MR evidence package schema with currency checks", "artifact_integrity_log showing cryptographic hash verification records for all evidence artifacts, confirming no post-creation modification", "examination_readiness_drill_record documenting the elapsed time to assemble and export the evidence package for at least one material model per quarter", "mro_attestation_signature record on the quarterly completeness report for all material models, with sign-off timestamp and any noted deficiencies" ], "machine_tests": [ "Query evidence repository for all High/Critical tier models \u2192 assert completeness_score >= 95% for each model", "Request examination-ready evidence package export for a material model \u2192 assert full package generated and delivered within 172800 seconds (2 business days)", "Attempt to modify a finalized evidence artifact \u2192 assert modification rejected with immutable hash mismatch record written to audit trail", "Compare stored SHA-256 hash values against recomputed hashes for a sample of 10 evidence artifacts \u2192 assert 0 hash mismatches" ], "human_review": [ "Verify that the MR Evidence Package schema maps completely to SR 26-2 documentation expectations (Documentation, within Governance and Controls) and EU AI Act Article 11 / Annex IV technical documentation fields", "Assess whether automated completeness scoring criteria correctly reflect regulatory examination expectations including artifact currency thresholds (validation reports not older than defined maximum ages)", "Review MRO attestation practice to confirm sign-off is substantive and that deficiencies noted in completeness reports are tracked to documented remediation" ], "blocking_effect": "requires-review", "normative_status": "supervisory-guidance", "anti_patterns": [ "Storing model risk artifacts in fragmented spreadsheets and email threads that cannot be assembled into a coherent evidence package within 2 business days under regulatory examination pressure", "Scoring evidence package completeness by checking artifact existence without verifying artifact currency, allowing outdated validation reports from prior years to count as complete", "Treating MR evidence packages as one-time compilation exercises assembled at examination time rather than continuously maintained repositories updated as governance activities complete", "Excluding vendor-layer evidence artifacts such as third-party AI API audit logs and cloud compliance reports from the evidence package, leaving gaps regulators will flag", "Maintaining evidence packages only for High/Critical tier models while omitting Medium tier models that collectively represent material aggregate exposure" ], "update_status": "current", "layer_code": "MR" }, { "id": "MV-01", "layer": "MV", "plane": "control", "name": "Independent Validation Function Charter", "plain": "The enterprise must establish and maintain a model validation function that is organizationally independent of model development and business lines, with a formal charter defining scope, authority, resources, and reporting lines.", "threat": { "tags": [ "validation-capture", "governance-bypass", "conflict-of-interest", "model-risk-blind-spot" ], "desc": "Without organizational independence, validators face implicit pressure to approve models developed by the same teams. Captured validation functions fail to surface material model weaknesses, enabling flawed models to enter production and drive consequential financial decisions. Inadequate resourcing leads to shallow reviews that miss conceptual errors in complex AI models." }, "standard": [ { "id": "sr26_2", "section": "\u00a7V (Validation and Monitoring)", "title": "Validation independence and rigor" }, { "id": "sox", "section": "\u00a7404", "title": "Management assessment of internal controls" }, { "id": "coso_icfr", "section": "Principle 3", "title": "Establishment of structure, authority, and responsibility" }, { "id": "eu_ai_act", "section": "Art. 9", "title": "Risk management system requirements" } ], "sources": [ { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Anthropic's Responsible Scaling Policy v3.3 documents the vendor's capability thresholds and safeguards, cited as third-party AI due diligence context for the apeiris://finance/controls/MV-01 Independent Validation Function Charter control.", "reviewed_on": "2026-07-02" }, { "id": "openai_enterprise_data_governance_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "OpenAI's enterprise privacy and compliance documentation records vendor-side data handling and audit-log capabilities relevant to the apeiris://finance/controls/MV-01 Independent Validation Function Charter control.", "reviewed_on": "2026-07-02" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://finance/controls/MV-01 Independent Validation Function Charter control.", "reviewed_on": "2026-07-01" }, { "id": "aws_financial_services_compliance_2024", "title": "AWS User Guide to Financial Services Regulations & Guidelines in the United States", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/financial-services/security-compliance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_financial_services_compliance_2024", "relationship": "informative_reference", "rationale": "AWS's financial services regulatory guide and compliance tooling document infrastructure-layer capabilities relevant to the apeiris://finance/controls/MV-01 Independent Validation Function Charter control.", "reviewed_on": "2026-07-02" }, { "id": "google_cloud_financial_services_ai_2024", "title": "Google Cloud Explainable AI", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/explainable-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_financial_services_ai_2024", "relationship": "informative_reference", "rationale": "Google Cloud's Explainable AI and Vertex AI model governance documentation describes platform capabilities relevant to the apeiris://finance/controls/MV-01 Independent Validation Function Charter control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Board-approved validation charter with explicit independence requirements, defined scope covering all in-scope models, dedicated headcount, and direct reporting to an independent risk committee or CRO.", "steps": [ "Draft and obtain board or senior risk committee approval of a model validation charter specifying independence requirements, scope, authority, and resource commitments.", "Establish organizational reporting lines that route validation leadership directly to the CRO or independent risk committee, segregated from model development lines.", "Define minimum staffing ratios and required competencies for the validation function, including AI/ML expertise for modern model types.", "Conduct an annual charter review to ensure scope covers new model types including LLMs and agentic AI systems." ], "model_risk_officer": { "summary": "The validation charter is the foundational governance document that grants independence and authority to the validation function. It must be actively maintained and enforced.", "actions": [ "Maintain the board-approved charter and ensure it is updated annually.", "Report validation function independence metrics to the risk committee at least quarterly.", "Escalate any organizational pressures that compromise validator independence to the CRO." ], "failure_signals": [ "Validation reports reviewed and approved by model development management.", "Validation findings consistently overridden without documented senior approval.", "Charter not updated in more than 12 months." ] }, "compliance_officer": { "summary": "SR 26-2 and related guidance describe supervisory expectations for demonstrable independence of the validation function. The charter is the primary artifact evidencing this independence to regulators.", "actions": [ "Review the validation charter annually for alignment with SR 26-2 expectations and EU AI Act Article 9 and SOX 404 requirements.", "Include validation independence assessment in the annual compliance testing program.", "Verify charter provisions are reflected in actual organizational structure and reporting relationships." ], "metrics": [ "Charter approval status: board-approved within the last 12 months.", "Validation independence incidents: target zero overrides without documented senior approval.", "Annual charter review completion rate: 100%." ], "failure_signals": [ "Charter not reviewed in over 12 months.", "Organizational chart shows validation reporting into model development.", "Supervisory criticism citing validation independence deficiencies." ] }, "internal_audit": { "summary": "Audit must independently verify that the validation function operates as described in the charter and that independence is not compromised in practice.", "actions": [ "Test that validation personnel have no functional reporting relationship to model development teams.", "Review a sample of validation reports for evidence of independent judgment and documented disagreements.", "Assess whether validation staffing levels are adequate relative to the model inventory size and complexity." ], "failure_signals": [ "Validation staff annually reviewed by model development managers.", "No documented instances of validation challenging model development conclusions.", "Validation backlog indicates staffing shortfall." ] }, "it_operations": { "summary": "IT Operations runs validation workflow tooling and access separation behind the independent validation function charter \u2014 integrating it with deployment pipelines, enforcing the automated gates, and keeping the supporting data flows reliable and auditable.", "actions": [ "Integrate validation workflow tooling and access separation with CI/CD and runtime tooling so that validation sign-off is recorded by an identity outside the development team before promotion.", "Automate collection and retention of validation sign-off records in immutable, hash-verified storage.", "Monitor pipeline and integration health and alert when the same identity appears as both developer and validator on a model." ], "failure_signals": [ "Production changes bypass the automated gate so that it is no longer true that validation sign-off is recorded by an identity outside the development team before promotion.", "Gaps or outages in validation sign-off records collection exceeding 24 hours.", "Manual, untracked edits to validation workflow tooling and access separation records." ] }, "financial_controller": { "summary": "Validation independence is what makes model outputs defensible support for management's ICFR certifications.", "actions": [ "Confirm that models supporting material estimates were validated by the chartered independent function.", "Treat validation-independence exceptions on reporting models as certification risks and escalate them." ], "failure_signals": [ "Reporting models validated by their own developers.", "Certification support relying on validations performed outside the chartered function." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Many organizations have nominal validation functions without true independence; AI/ML coverage is often an afterthought." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "Model Risk Officer", "Chief Risk Officer", "Compliance Team" ], "frameworks": [ { "framework": "sr26_2", "requirement_id": "\u00a7V (Validation and Monitoring)", "fit": "direct", "rationale": "SR 26-2 \u00a7V describes validation carried out with appropriate independence from model development and use, with the validation function having the authority, competence, and resources to evaluate models effectively. A formal charter is the artifact that establishes and evidences that independence.", "normative_force": "supervisory-guidance", "source_version": "2026-04-17", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "sox", "requirement_id": "\u00a7404", "fit": "partial", "rationale": "SOX Section 404 requires management to assess the effectiveness of internal controls over financial reporting. An independent validation function is a key internal control for financial models that feed into financial statements or disclosures.", "normative_force": "binding-law", "source_version": "2002", "reviewed_on": "2026-06-28", "basis": "asserted", "relation": "satisfies" }, { "framework": "coso_icfr", "requirement_id": "Principle 3", "fit": "partial", "rationale": "COSO Principle 3 requires management to establish structures, reporting lines, and appropriate authorities and responsibilities. Independence of the validation function directly satisfies this principle for model risk governance.", "normative_force": "industry-framework", "source_version": "2013", "reviewed_on": "2026-06-28", "basis": "asserted", "relation": "informs" }, { "framework": "eu_ai_act", "requirement_id": "Art. 9(1)", "fit": "partial", "rationale": "EU AI Act Article 9 requires a risk management system for high-risk AI systems, which includes independent review mechanisms. An independent validation charter establishes the governance structure required for compliant high-risk AI deployment in financial services.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-06-28", "basis": "anchored", "relation": "satisfies" }, { "framework": "pcaob_as_2201", "requirement_id": "\u00b6.24-.28", "fit": "adjacent", "rationale": "AS 2201 \u00b6.24-.28 direct the auditor to test entity-level controls, whose effectiveness influences the scope of other testing. An independent validation function chartered with authority and reporting independence is an entity-level control over model-dependent financial reporting; the fit is adjacent \u2014 the standard addresses auditors, and validation independence itself comes from supervisory guidance.", "normative_force": "certification-standard", "source_version": "2007", "reviewed_on": "2026-07-02", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "openai_enterprise", "requirement_id": "Enterprise Compliance API \u2014 audit logs", "fit": "partial", "rationale": "ChatGPT Enterprise and the OpenAI API expose workspace audit-log data through the Compliance API and audit logs endpoint, exportable to SIEM and evidence stores. Institutions using OpenAI models in financial workflows can incorporate this vendor capability into the independent validation function charter. This is vendor capability documentation, not regulatory guidance; it covers the vendor side only.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "A2", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal A2 (Oversight of significant adverse impacts) requires defined review and oversight processes for AI systems that can cause significant adverse impact. For institutions using Azure AI services, this goal produces vendor-side governance artifacts that align with the independent validation function charter. The Standard is Microsoft's published internal policy offered as reference practice, not regulatory guidance.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_financial", "requirement_id": "Financial Services Industry Lens \u2014 AWS Well-Architected", "fit": "partial", "rationale": "The Financial Services Industry Lens for the AWS Well-Architected Framework describes design principles, risk considerations, and shared-responsibility boundaries for regulated financial workloads on AWS. For AWS-hosted financial AI systems, this supplies the infrastructure-layer support and evidence stream for the independent validation function charter. This is vendor documentation of real AWS capabilities \u2014 it does not substitute for model-layer validation or regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_financial", "requirement_id": "Vertex AI Model Registry", "fit": "partial", "rationale": "Vertex AI Model Registry provides versioned model registration, aliases, and deployment state tracking on Google Cloud. For GCP-hosted financial AI systems, this capability supplies the platform-layer support for the independent validation function charter. This is vendor product documentation, not regulatory guidance; it does not address model-layer regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://finance/controls/MV-01", "meta": { "authored_on": "2026-06-29", "schema_version": "1.1.0" }, "validation_objective": "The model validation function must be established with a board- or risk-committee-approved charter documenting organizational independence from model development and business lines, with all validation staff reporting to the CRO or an independent risk committee rather than to technology or business leadership. The charter must define scope, authority, minimum staffing levels, and escalation rights enabling validators to require model suspension.", "evidence_required": [ "board_or_risk_committee_approved_charter document with effective date, scope statement, reporting line definition, and named escalation authority for validation override decisions", "organizational_chart confirming the validation function reporting line is separate from model development and business line management chains with no shared manager below the CRO level", "headcount_and_competency_record listing all validation function staff, their qualifications, and attestation that none hold concurrent model development responsibilities", "annual_charter_review_record documenting review date, reviewer role, findings, and any charter amendments approved by the risk committee", "validation_authority_exercise_log showing instances where the validation function raised adverse findings, suspended models, or escalated to the board" ], "machine_tests": [ "Query HR system for validation staff reporting lines \u2192 assert no validation staff report to model development or business line managers below CRO level", "Check model registry for production models without a linked completed independent validation report \u2192 assert zero production models with no validation record from the independent function", "Verify charter document currency in document management system \u2192 assert charter last reviewed within 12 months and in approved (not draft) status" ], "human_review": [ "Interview validation team members to confirm they experience no organizational pressure from model development or business lines when issuing adverse or conditional validation findings", "Review a sample of validation reports with adverse or conditional findings to assess whether charter authority was exercised without interference and findings were documented without dilution", "Assess whether validation function headcount and technical expertise are adequate relative to the complexity, volume, and AI/ML proportion of the model portfolio" ], "blocking_effect": "blocks-deployment", "normative_status": "supervisory-guidance", "anti_patterns": [ "Placing the validation function within the same organizational unit as model development with validators reporting to the same CTO or Chief Data Officer as model builders", "Relying on an informal independence agreement rather than a board-approved charter, leaving validation independence vulnerable to organizational restructuring or management override", "Using a single team for both model development and model validation justified by resource constraints, eliminating the independence that SR 26-2 expects of the validation function", "Defining the validation charter scope narrowly to exclude third-party or vendor AI models used in material financial decisions, creating blind spots in independent oversight", "Granting business lines the authority to override validation findings without a formal escalation pathway requiring risk committee or board approval" ], "update_status": "current", "layer_code": "MV" }, { "id": "MV-02", "layer": "MV", "plane": "control", "name": "Conceptual Soundness Assessment", "plain": "Every model must undergo a conceptual soundness assessment that evaluates the theoretical basis, design assumptions, mathematical formulation, data inputs, and suitability for intended use before production deployment and at each major version change.", "threat": { "tags": [ "model-misspecification", "assumption-drift", "scope-creep", "theoretical-failure" ], "desc": "Models built on flawed theoretical foundations or inappropriate assumptions can produce systematically biased outputs that appear statistically valid in the short term. Scope creep \u2014 applying a model outside its intended use \u2014 amplifies conceptual failures. For AI/ML models, undocumented assumptions about data stationarity or feature relevance can cause silent degradation during market regime changes." }, "standard": [ { "id": "sr26_2", "section": "\u00a7V (Conceptual Soundness)", "title": "Conceptual soundness" }, { "id": "bcbs_239", "section": "Principle 3", "title": "Accuracy and integrity of risk data" }, { "id": "eu_ai_act", "section": "Art. 10", "title": "Data and data governance for high-risk AI" }, { "id": "coso_icfr", "section": "Principle 10", "title": "Design and implementation of control activities" } ], "sources": [ { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://finance/controls/MV-02 Conceptual Soundness Assessment control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Anthropic's Responsible Scaling Policy v3.3 documents the vendor's capability thresholds and safeguards, cited as third-party AI due diligence context for the apeiris://finance/controls/MV-02 Conceptual Soundness Assessment control.", "reviewed_on": "2026-07-02" }, { "id": "aws_financial_services_compliance_2024", "title": "AWS User Guide to Financial Services Regulations & Guidelines in the United States", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/financial-services/security-compliance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_financial_services_compliance_2024", "relationship": "informative_reference", "rationale": "AWS's financial services regulatory guide and compliance tooling document infrastructure-layer capabilities relevant to the apeiris://finance/controls/MV-02 Conceptual Soundness Assessment control.", "reviewed_on": "2026-07-02" }, { "id": "google_cloud_financial_services_ai_2024", "title": "Google Cloud Explainable AI", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/explainable-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_financial_services_ai_2024", "relationship": "informative_reference", "rationale": "Google Cloud's Explainable AI and Vertex AI model governance documentation describes platform capabilities relevant to the apeiris://finance/controls/MV-02 Conceptual Soundness Assessment control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Structured conceptual soundness review template covering theoretical basis, assumptions inventory, data input assessment, use-case boundary documentation, and a formal suitability opinion signed by the validation lead.", "steps": [ "Develop and maintain a conceptual soundness review template requiring documentation of the model's theoretical basis, key assumptions, mathematical formulation, and intended use boundaries.", "Require model developers to submit a Model Development Document covering all conceptual soundness elements prior to initiating validation.", "Validate each assumption independently by testing sensitivity to assumption violations and documenting risk-of-use limitations.", "Issue a formal conceptual soundness opinion with a suitability determination for the stated intended use." ], "model_risk_officer": { "summary": "Conceptual soundness assessment is the technical core of model validation. The validation function must have staff with sufficient quantitative expertise to independently evaluate model theory.", "actions": [ "Review and approve the conceptual soundness template annually for coverage of emerging model types including LLMs.", "Ensure validators have access to the full Model Development Document and all supporting research.", "Track conceptual soundness findings by model tier and report to the risk committee." ], "failure_signals": [ "Validators unable to articulate the theoretical basis of models they validated.", "Conceptual soundness assessments completed without access to original development documentation.", "Models deployed with open conceptual soundness findings." ] }, "compliance_officer": { "summary": "SR 26-2 identifies conceptual soundness assessment as a core element of validation. Documented assessments provide the evidentiary basis for regulatory examination responses.", "actions": [ "Confirm that every model in the Tier 1 and Tier 2 inventory has a completed conceptual soundness assessment on file.", "Review the template for EU AI Act Article 10 data governance requirements when AI/ML models are assessed.", "Include conceptual soundness completion rate in the quarterly model risk dashboard." ], "metrics": [ "Conceptual soundness assessment coverage: 100% of Tier 1 and Tier 2 models.", "Average time from model submission to conceptual soundness opinion: target \u226430 business days.", "Open conceptual soundness findings in production models: target zero." ], "failure_signals": [ "Models promoted to production without a signed conceptual soundness opinion.", "Conceptual soundness assessments not refreshed after major model modifications.", "Supervisory criticism citing inadequate conceptual soundness documentation." ] }, "internal_audit": { "summary": "Audit should test the quality and independence of conceptual soundness assessments, not merely their existence.", "actions": [ "Sample 15% of completed conceptual soundness assessments and test whether validator conclusions are independently supported.", "Verify that assumption sensitivity analyses are documented and not merely referenced.", "Confirm that suitability opinions address the actual deployed use case, not a broader or different use." ], "failure_signals": [ "Conceptual soundness opinions that restate developer conclusions without independent analysis.", "Missing assumption sensitivity documentation.", "Suitability opinions that do not address the actual production use case." ] }, "it_operations": { "summary": "IT Operations runs validation environments and model metadata behind conceptual soundness assessment of model design \u2014 integrating it with deployment pipelines, enforcing the automated gates, and keeping the supporting data flows reliable and auditable.", "actions": [ "Integrate validation environments and model metadata with CI/CD and runtime tooling so that a conceptual soundness sign-off is present before first production deployment.", "Automate collection and retention of assessment documents linked to model versions in immutable, hash-verified storage.", "Monitor pipeline and integration health and alert when models reach production without a linked soundness assessment." ], "failure_signals": [ "Production changes bypass the automated gate so that it is no longer true that a conceptual soundness sign-off is present before first production deployment.", "Gaps or outages in assessment documents linked to model versions collection exceeding 24 hours.", "Manual, untracked edits to validation environments and model metadata records." ] }, "financial_controller": { "summary": "Conceptual soundness of estimate models (allowances, valuations, accruals) is the foundation for defending those estimates to auditors.", "actions": [ "Review soundness assessments for models behind significant accounting estimates each cycle.", "Challenge estimate models whose design assumptions no longer match the portfolio or market." ], "failure_signals": [ "Significant estimates produced by models without a current soundness assessment.", "Auditor challenge to an estimate model's design that the assessment never addressed." ] } }, "maturity": { "current": "defined", "target": "managed", "notes": "Traditional statistical model conceptual soundness is mature; coverage of LLM and agentic model conceptual soundness is nascent." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "federated-enterprise" ], "implementers": [ "Model Risk Officer", "Quantitative Analyst", "Validation Team" ], "frameworks": [ { "framework": "sr26_2", "requirement_id": "\u00a7V (Conceptual Soundness)", "fit": "direct", "rationale": "SR 26-2 \u00a7V (Validation and Monitoring) identifies conceptual soundness \u2014 evaluating the quality of a model's design, theory, and construction \u2014 under its Conceptual Soundness subheading as a core element of validation. This control directly implements that element.", "normative_force": "supervisory-guidance", "source_version": "2026-04-17", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "bcbs_239", "requirement_id": "Principle 3", "fit": "partial", "rationale": "BCBS 239 Principle 3 (Accuracy and Integrity) requires risk data to be accurate and reliable, aggregated on a largely automated basis to minimise errors. Conceptual soundness assessment includes evaluating whether a model's data inputs meet the accuracy and integrity properties the model design assumes \u2014 for G-SIBs, Principle 3 is the data-quality baseline that assessment relies on.", "normative_force": "supervisory-guidance", "source_version": "2013", "reviewed_on": "2026-07-02", "basis": "asserted", "relation": "satisfies" }, { "framework": "eu_ai_act", "requirement_id": "Art. 10", "fit": "partial", "rationale": "EU AI Act Article 10 imposes data and data governance requirements for high-risk AI systems, which directly intersects with conceptual soundness assessment of data inputs and their suitability for the model's intended purpose.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-06-28", "basis": "anchored", "relation": "satisfies" }, { "framework": "coso_icfr", "requirement_id": "Principle 10", "fit": "adjacent", "rationale": "COSO 2013 Principle 10 requires selecting and developing control activities that contribute to mitigating risks to acceptable levels. Conceptual soundness assessment functions as a design-stage control activity over models that feed financial reporting: it verifies that the model's design is appropriate before its outputs are relied upon.", "normative_force": "industry-framework", "source_version": "2013", "reviewed_on": "2026-07-02", "basis": "asserted", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "RS1", "fit": "adjacent", "rationale": "Microsoft Responsible AI Standard v2 Goal RS1 (Reliability and safety guidance) requires following reliability and safety guidance when developing and deploying systems, including defining safe operating parameters. For institutions using Azure AI services, this goal produces vendor-side governance artifacts that align with conceptual soundness assessment of model design. The Standard is Microsoft's published internal policy offered as reference practice, not regulatory guidance.", "normative_force": "best-practice", "source_version": "2022", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_financial", "requirement_id": "AWS Artifact", "fit": "partial", "rationale": "AWS Artifact provides on-demand access to AWS's third-party compliance reports (SOC 1/2, PCI DSS, ISO). For AWS-hosted financial AI systems, this supplies the infrastructure-layer support and evidence stream for conceptual soundness assessment of model design. This is vendor documentation of real AWS capabilities \u2014 it does not substitute for model-layer validation or regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_financial", "requirement_id": "Explainable AI", "fit": "partial", "rationale": "Google Cloud's Explainable AI documentation (cloud.google.com/explainable-ai) describes feature attribution and explanation tooling available through Vertex AI. For GCP-hosted financial AI systems, this capability supplies the platform-layer support for conceptual soundness assessment of model design. This is vendor product documentation, not regulatory guidance; it does not address model-layer regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://finance/controls/MV-02", "meta": { "authored_on": "2026-06-29", "schema_version": "1.1.0" }, "validation_objective": "Every model must have a documented conceptual soundness assessment completed by the independent validation function before initial production deployment and before each major version change, concluding with an explicit suitability opinion stating whether the model is appropriate for its intended use. All identified conceptual weaknesses must be documented with assigned owners and tracked to verified remediation before or concurrent with deployment approval.", "evidence_required": [ "conceptual_soundness_report per model version signed by the validation lead, covering theoretical basis, assumptions inventory, data input assessment, mathematical formulation review, and a formal suitability opinion", "assumptions_inventory record listing all model design assumptions with validity conditions and the date each assumption was validated against current production data conditions", "use_case_boundary_document defining intended use, out-of-scope applications, and conditions under which the model must not be used, approved by the validation function", "deficiency_tracking_record for any conceptual weaknesses identified, showing remediation status, responsible owner, and target resolution date with closure evidence" ], "machine_tests": [ "Query model registry for models promoted to production in the past 12 months \u2192 assert each has a linked conceptual_soundness_report with completed_date before production_deployment_date", "Identify models with a major version change in the past 12 months \u2192 assert each has a new conceptual_soundness_report dated after the version change and before re-deployment", "Check conceptual soundness reports for explicit suitability_opinion field \u2192 assert zero reports with opinion=null or opinion='pending' for any production model" ], "human_review": [ "Review a sample of conceptual soundness reports to assess whether the theoretical basis evaluation demonstrates genuine understanding of model mechanics rather than pro-forma checklist completion", "Assess whether assumptions inventories for AI/ML models include data distribution assumptions that may not hold in production, and whether MV-03 monitoring explicitly covers those assumptions", "Verify that conceptual soundness assessments for LLM-based models address prompt injection risk and behavioral consistency as unique soundness concerns specific to generative architectures" ], "blocking_effect": "blocks-deployment", "normative_status": "supervisory-guidance", "anti_patterns": [ "Conducting conceptual soundness assessments as documentation exercises without validators independently testing model logic against the stated mathematical formulations", "Treating LLM-based models as unvalidated software components because SR 26-2 footnote 3 excludes generative AI from the guidance's scope, allowing them to bypass conceptual soundness assessment entirely", "Issuing conditional suitability opinions without tracking the conditions to verified closure, allowing conditionally-approved models to enter production with unresolved issues outstanding", "Reusing a prior conceptual soundness assessment for a materially changed model version without a new assessment, citing a minor version designation to avoid reassessment", "Defining model assumptions so broadly that the assumptions inventory cannot be falsified or monitored, providing no operational signal when production conditions deviate" ], "update_status": "current", "layer_code": "MV" }, { "id": "MV-03", "layer": "MV", "plane": "control", "name": "Outcome Analysis and Backtesting", "plain": "All production models must be subject to ongoing outcome analysis comparing model predictions against realized outcomes, with formal backtesting protocols that establish pass/fail thresholds, test frequency, and escalation procedures when tests fail.", "threat": { "tags": [ "predictive-degradation", "silent-model-failure", "backtesting-manipulation", "regime-shift-blindness" ], "desc": "Models that produce plausible-looking outputs while diverging from actual outcomes create the highest category of financial risk because degradation is invisible to users. Silent model failure enables compounding errors in credit decisions, risk reserves, and trading models. Backtesting conducted by model owners introduces manipulation risk \u2014 developers can adjust test windows to avoid unfavorable periods." }, "standard": [ { "id": "sr26_2", "section": "\u00a7V (Outcomes Analysis)", "title": "Outcomes analysis" }, { "id": "bcbs_239", "section": "Principle 8", "title": "Risk data accuracy and completeness for outcome testing" }, { "id": "sox", "section": "\u00a7302", "title": "Disclosure controls and model output accuracy" }, { "id": "aicpa_soc2", "section": "CC7.2", "title": "Monitoring of model performance and anomalies" } ], "sources": [ { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Anthropic's Responsible Scaling Policy v3.3 documents the vendor's capability thresholds and safeguards, cited as third-party AI due diligence context for the apeiris://finance/controls/MV-03 Outcome Analysis and Backtesting control.", "reviewed_on": "2026-07-02" }, { "id": "openai_enterprise_data_governance_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "OpenAI's enterprise privacy and compliance documentation records vendor-side data handling and audit-log capabilities relevant to the apeiris://finance/controls/MV-03 Outcome Analysis and Backtesting control.", "reviewed_on": "2026-07-02" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://finance/controls/MV-03 Outcome Analysis and Backtesting control.", "reviewed_on": "2026-07-01" }, { "id": "aws_financial_services_compliance_2024", "title": "AWS User Guide to Financial Services Regulations & Guidelines in the United States", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/financial-services/security-compliance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_financial_services_compliance_2024", "relationship": "informative_reference", "rationale": "AWS's financial services regulatory guide and compliance tooling document infrastructure-layer capabilities relevant to the apeiris://finance/controls/MV-03 Outcome Analysis and Backtesting control.", "reviewed_on": "2026-07-02" }, { "id": "google_cloud_financial_services_ai_2024", "title": "Google Cloud Explainable AI", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/explainable-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_financial_services_ai_2024", "relationship": "informative_reference", "rationale": "Google Cloud's Explainable AI and Vertex AI model governance documentation describes platform capabilities relevant to the apeiris://finance/controls/MV-03 Outcome Analysis and Backtesting control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Independent outcome analysis conducted by the validation function using production actuals sourced independently of model development. Backtesting thresholds defined in the model's validation report, with automated monitoring dashboards and exception-triggered escalation.", "steps": [ "Define outcome analysis protocols at model validation time, specifying comparison metrics, test windows, minimum sample sizes, and pass/fail thresholds.", "Source actual outcome data independently through the validation function's data access, segregated from model owner-supplied data.", "Implement automated backtesting dashboards that produce exception alerts when models breach defined thresholds.", "Conduct formal annual outcome analyses for all Tier 1 and Tier 2 models, with results reported to the model risk committee." ], "model_risk_officer": { "summary": "Outcome analysis is the primary mechanism for detecting model performance degradation in production. The validation function must own the data sourcing and testing process to prevent manipulation.", "actions": [ "Establish and maintain outcome analysis protocols for each model type in the inventory.", "Review automated backtesting results monthly and escalate exceptions to the risk committee.", "Ensure that outcome data is sourced independently and cannot be modified by model owners before testing." ], "failure_signals": [ "Backtesting conducted by model development teams without validation oversight.", "Outcome analysis sample sizes below minimum thresholds defined in validation reports.", "Models with consecutive backtesting failures remaining in production without escalation." ] }, "financial_controller": { "summary": "Backtesting results directly affect the reliability of model outputs used in financial statements. The controller function must understand which models support financial reporting and whether their outcome analyses are passing.", "actions": [ "Maintain a mapping of financial statement line items to the models that produce or influence them.", "Review outcome analysis results for all models that support financial reporting disclosures.", "Include model backtesting status in the quarterly sub-certification process." ], "failure_signals": [ "Financial statement models with no outcome analysis on file.", "Backtesting failures for financial reporting models not disclosed in the risk disclosure framework.", "Controller sub-certifications that do not reference model performance status." ] }, "compliance_officer": { "summary": "Outcome analysis and backtesting are core validation elements described in SR 26-2 and are scrutinized in regulatory examinations. Documented results with defined protocols are the primary regulatory evidence.", "actions": [ "Confirm that all Tier 1 and Tier 2 models have documented outcome analysis protocols on file.", "Review backtesting results for AI/ML models used in high-risk decisions for EU AI Act compliance.", "Include backtesting completion and pass rates in quarterly model risk reporting." ], "metrics": [ "Backtesting completion rate: 100% of Tier 1 models annually.", "Backtesting pass rate: track trend; investigate any model with consecutive failures.", "Days between backtesting failure detection and escalation: target \u22645 business days." ], "failure_signals": [ "No documented outcome analysis for models that have been in production over 12 months.", "Backtesting protocols not updated after model modifications.", "Supervisory criticism citing inadequate outcome monitoring." ] }, "internal_audit": { "summary": "Audit must test the independence of outcome analysis data sourcing and the adequacy of backtesting protocols, not just their existence.", "actions": [ "Test that outcome data used in backtesting is sourced independently of model owners.", "Verify that backtesting thresholds are pre-defined and not adjusted post-hoc.", "Review escalation records for any model that experienced backtesting failures in the audit period." ], "failure_signals": [ "Outcome data sourced from systems controlled by model development teams.", "Backtesting thresholds changed after initial results were known.", "No escalation records despite documented backtesting failures." ] }, "it_operations": { "summary": "IT Operations runs backtesting pipelines and outcome data feeds behind outcome analysis and backtesting of model performance \u2014 integrating it with deployment pipelines, enforcing the automated gates, and keeping the supporting data flows reliable and auditable.", "actions": [ "Integrate backtesting pipelines and outcome data feeds with CI/CD and runtime tooling so that scheduled backtests run and publish results automatically.", "Automate collection and retention of backtest runs and threshold evaluations in immutable, hash-verified storage.", "Monitor pipeline and integration health and alert when a scheduled backtest fails to run or outcome feeds go stale." ], "failure_signals": [ "Production changes bypass the automated gate so that it is no longer true that scheduled backtests run and publish results automatically.", "Gaps or outages in backtest runs and threshold evaluations collection exceeding 24 hours.", "Manual, untracked edits to backtesting pipelines and outcome data feeds records." ] } }, "maturity": { "current": "defined", "target": "managed", "notes": "Traditional credit and market risk models typically have backtesting; AI/ML and LLM outcome analysis frameworks are less mature." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "federated-enterprise" ], "implementers": [ "Model Risk Officer", "Validation Team", "Data Engineering" ], "frameworks": [ { "framework": "sr26_2", "requirement_id": "\u00a7V (Outcomes Analysis)", "fit": "direct", "rationale": "SR 26-2 \u00a7V (Validation and Monitoring) describes outcomes analysis \u2014 comparing model outputs to actual results \u2014 under its Outcomes Analysis subheading as a core element of validation. Formal backtesting protocols with defined thresholds implement that element.", "normative_force": "supervisory-guidance", "source_version": "2026-04-17", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "bcbs_239", "requirement_id": "Principle 8", "fit": "partial", "rationale": "BCBS 239 Principle 8 (Comprehensiveness) requires risk reports to cover all material risk areas, including emerging risks. Backtesting results that reveal model underperformance are material inputs to comprehensive risk reporting; the mapping is partial \u2014 BCBS 239 governs the reporting, not the backtesting protocol itself.", "normative_force": "supervisory-guidance", "source_version": "2013", "reviewed_on": "2026-07-02", "basis": "asserted", "relation": "satisfies" }, { "framework": "sox", "requirement_id": "\u00a7302", "fit": "partial", "rationale": "SOX Section 302 certifications require that financial disclosures fairly represent financial condition. For organizations that rely on models for financial reporting estimates, backtesting provides evidence that model outputs are reliable for disclosure purposes.", "normative_force": "binding-law", "source_version": "2002", "reviewed_on": "2026-06-28", "basis": "asserted", "relation": "satisfies" }, { "framework": "soc2", "requirement_id": "CC7.2", "fit": "adjacent", "rationale": "AICPA SOC 2 CC7.2 requires entities to evaluate their detection and monitoring activities. Outcome analysis and automated backtesting dashboards directly implement the monitoring requirements of this criterion for model risk.", "normative_force": "certification-standard", "source_version": "2022", "reviewed_on": "2026-06-28", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 9(6)-(8), Art. 15", "fit": "partial", "rationale": "EU AI Act Art. 9(6)-(8) requires testing of high-risk AI systems against defined metrics and probabilistic thresholds, as appropriate throughout development and prior to being placed on the market; Art. 15 requires appropriate levels of accuracy declared and consistent performance. Outcome analysis and backtesting are the operational disciplines that evidence both.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "openai_enterprise", "requirement_id": "Enterprise Compliance API \u2014 audit logs", "fit": "partial", "rationale": "ChatGPT Enterprise and the OpenAI API expose workspace audit-log data through the Compliance API and audit logs endpoint, exportable to SIEM and evidence stores. Institutions using OpenAI models in financial workflows can incorporate this vendor capability into outcome analysis and backtesting of model performance. This is vendor capability documentation, not regulatory guidance; it covers the vendor side only.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "RS3", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal RS3 (Ongoing monitoring, feedback, and evaluation) requires ongoing monitoring, feedback collection, and evaluation of deployed systems. For institutions using Azure AI services, this goal produces vendor-side governance artifacts that align with outcome analysis and backtesting of model performance. The Standard is Microsoft's published internal policy offered as reference practice, not regulatory guidance.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_financial", "requirement_id": "AWS Artifact", "fit": "partial", "rationale": "AWS Artifact provides on-demand access to AWS's third-party compliance reports (SOC 1/2, PCI DSS, ISO). For AWS-hosted financial AI systems, this supplies the infrastructure-layer support and evidence stream for outcome analysis and backtesting of model performance. This is vendor documentation of real AWS capabilities \u2014 it does not substitute for model-layer validation or regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_financial", "requirement_id": "Vertex AI Model Monitoring", "fit": "partial", "rationale": "Vertex AI Model Monitoring detects prediction drift and training-serving skew for models deployed on Google Cloud. For GCP-hosted financial AI systems, this capability supplies the platform-layer support for outcome analysis and backtesting of model performance. This is vendor product documentation, not regulatory guidance; it does not address model-layer regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://finance/controls/MV-03", "meta": { "authored_on": "2026-06-29", "schema_version": "1.1.0" }, "validation_objective": "All production models must be enrolled in a continuous outcome analysis program comparing model predictions against realized outcomes using actuals sourced independently of the model development team, with pre-defined pass/fail thresholds that trigger formal escalation workflows when breached. Backtesting results must be documented at all defined intervals, reviewed by the validation function, and any threshold breach must initiate escalation within the defined response window.", "evidence_required": [ "backtesting_report per model per test cycle showing test period, prediction-vs-actual comparison metrics, pass/fail verdict against pre-defined thresholds, and escalation actions triggered by any breach", "outcome_data_lineage_record confirming that production actuals used in backtesting are sourced independently from model development, with attestation from an independent data custodian", "backtesting_threshold_specification per model defining pass/fail thresholds, test frequency, breach escalation procedure, and the date thresholds were approved by the validation function", "escalation_log for all backtesting threshold breaches documenting breach date, severity classification, escalation recipient, response action taken, and closure date" ], "machine_tests": [ "Query backtesting system for all Tier 1 production models \u2192 assert a backtesting report exists for each within the last 12 months with a documented pass/fail verdict", "Inject synthetic prediction data with error rate exceeding the defined threshold \u2192 assert escalation workflow triggered within the defined maximum response window", "Attempt to source backtesting actuals from the model development team's data warehouse \u2192 assert data lineage controls reject this pathway and require independent data sourcing confirmation" ], "human_review": [ "Review backtesting threshold specifications for a sample of models to confirm thresholds are calibrated to detect material model degradation rather than set so loosely as to be unenforceable", "Examine escalation log entries for threshold breaches to assess whether escalation responses were proportionate, timely, and resulted in documented remediation actions or model restriction", "Assess whether backtesting protocols for LLM-based models address the distinct challenge of comparing generative output quality against realized outcome quality metrics" ], "blocking_effect": "requires-review", "normative_status": "supervisory-guidance", "anti_patterns": [ "Using actuals sourced from the model development team for backtesting, creating a conflict of interest where the team whose model is being tested controls the comparison data", "Setting backtesting thresholds so wide that the test cannot detect practically significant model degradation before it affects consequential financial decisions at scale", "Performing backtesting only at annual validation cycles rather than continuously, allowing model drift to persist undetected for up to 12 months between assessments", "Treating threshold breaches as informational events without a mandatory escalation and response workflow, leaving remediation to discretionary management action", "Excluding LLM-based models from outcome analysis programs on the grounds that generative outputs cannot be compared to discrete realized outcomes, without defining alternative measurement methods" ], "update_status": "current", "layer_code": "MV" }, { "id": "MV-04", "layer": "MV", "plane": "control", "name": "Benchmarking and Challenger Models", "plain": "The validation function must assess production model performance against defined benchmarks and challenger models at each validation cycle, documenting relative performance and providing an opinion on whether the production model remains the best available option for its intended use.", "threat": { "tags": [ "model-entrenchment", "suboptimal-model-lock-in", "benchmark-gaming", "comparative-blindness" ], "desc": "Without challenger model comparison, production models can persist long after superior alternatives exist, creating competitive disadvantage or systematic miscalibration relative to market norms. Developers may design production models to outperform specifically chosen benchmarks while underperforming on held-out metrics. LLM-powered models are especially susceptible to benchmark gaming through prompt engineering." }, "standard": [ { "id": "sr26_2", "section": "\u00a7V (Conceptual Soundness)", "title": "Benchmarking within validation" }, { "id": "bcbs_239", "section": "Principle 7", "title": "Comprehensiveness of risk coverage" }, { "id": "eu_ai_act", "section": "Art. 9(6)", "title": "Testing of high-risk AI systems" }, { "id": "coso_icfr", "section": "Principle 16", "title": "Performing ongoing monitoring activities" } ], "sources": [ { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://finance/controls/MV-04 Benchmarking and Challenger Models control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Anthropic's Responsible Scaling Policy v3.3 documents the vendor's capability thresholds and safeguards, cited as third-party AI due diligence context for the apeiris://finance/controls/MV-04 Benchmarking and Challenger Models control.", "reviewed_on": "2026-07-02" }, { "id": "google_cloud_financial_services_ai_2024", "title": "Google Cloud Explainable AI", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/explainable-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_financial_services_ai_2024", "relationship": "informative_reference", "rationale": "Google Cloud's Explainable AI and Vertex AI model governance documentation describes platform capabilities relevant to the apeiris://finance/controls/MV-04 Benchmarking and Challenger Models control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Challenger model program managed by the validation function, with defined comparison metrics selected at validation time, held-out test sets inaccessible to model development, and a formal comparative opinion issued at each validation cycle.", "steps": [ "Establish a challenger model program policy specifying when challenger comparisons are required, who selects benchmarks, and what comparison metrics must be evaluated.", "Require that benchmark selection and held-out test set construction occur before challenger evaluation begins to prevent gaming.", "Document the comparative performance analysis in the validation report with a formal opinion on production model fitness relative to challengers.", "Require model owners to present a remediation plan if the production model is materially outperformed by a challenger on primary metrics." ], "model_risk_officer": { "summary": "The challenger model program is a key mechanism for ensuring production models remain fit for purpose. The validation function must select benchmarks independently to preserve comparison integrity.", "actions": [ "Maintain a challenger model library with documented alternatives for each major production model type.", "Ensure benchmark selection is documented and finalized before challenger evaluation data is analyzed.", "Report challenger comparison outcomes to the model risk committee with a recommendation on production model replacement where appropriate." ], "failure_signals": [ "Challenger benchmarks selected by model development teams.", "No challenger comparison conducted in the last full validation cycle.", "Production models materially outperformed by challengers with no documented remediation plan." ] }, "financial_controller": { "summary": "For financial models, the challenger comparison provides assurance that the organization is using the most reliable available models for financial estimates, supporting audit defensibility.", "actions": [ "Request challenger comparison results for all models supporting material financial estimates.", "Include model competitive fitness in the annual review of model reliance for financial reporting." ], "failure_signals": [ "No challenger comparison on file for models supporting material financial statement estimates.", "Challenger comparisons show material underperformance without documented management response." ] }, "compliance_officer": { "summary": "SR 26-2 references benchmarking as a component of validation. For EU AI Act high-risk systems, periodic review must include assessment of whether better-performing alternatives exist.", "actions": [ "Confirm that challenger comparison policy covers all Tier 1 model types.", "Review challenger program coverage in the annual model risk compliance assessment.", "Verify that benchmark selection procedures prevent gaming by model development teams." ], "metrics": [ "Challenger comparison coverage: 100% of Tier 1 models at each full validation cycle.", "Models with open material underperformance findings: target zero without remediation plans.", "Average time from challenger outperformance finding to management response: target \u226430 days." ], "failure_signals": [ "Tier 1 models without challenger comparison in the current validation cycle.", "Benchmarks selected post-hoc after challenger evaluation data was available.", "No remediation plans for models with documented challenger underperformance." ] }, "internal_audit": { "summary": "Audit must test the independence of benchmark selection and held-out test set construction, and verify that challenger comparison findings are acted upon.", "actions": [ "Verify that benchmark selection documentation predates the challenger evaluation data run.", "Test that held-out test sets were not accessible to model development teams during model training.", "Review follow-up actions for any models where challenger comparisons showed material underperformance." ], "failure_signals": [ "No dated documentation of benchmark selection prior to challenger evaluation.", "Challenger test set overlaps with model training data.", "Open challenger underperformance findings with no management response after 60 days." ] }, "it_operations": { "summary": "IT Operations runs challenger-model execution infrastructure behind benchmarking and challenger model comparison \u2014 integrating it with deployment pipelines, enforcing the automated gates, and keeping the supporting data flows reliable and auditable.", "actions": [ "Integrate challenger-model execution infrastructure with CI/CD and runtime tooling so that challenger runs execute against the same input snapshots as production models.", "Automate collection and retention of benchmark comparison outputs in immutable, hash-verified storage.", "Monitor pipeline and integration health and alert when challenger runs diverge from production input snapshots." ], "failure_signals": [ "Production changes bypass the automated gate so that it is no longer true that challenger runs execute against the same input snapshots as production models.", "Gaps or outages in benchmark comparison outputs collection exceeding 24 hours.", "Manual, untracked edits to challenger-model execution infrastructure records." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Formal challenger model programs are common in large financial institutions but rare in mid-market firms; AI/ML challenger comparisons are emerging practice." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai" ], "implementers": [ "Model Risk Officer", "Validation Team", "Quantitative Research" ], "frameworks": [ { "framework": "sr26_2", "requirement_id": "\u00a7V (Conceptual Soundness)", "fit": "direct", "rationale": "SR 26-2 \u00a7V discusses benchmarking \u2014 comparison of a model's outputs to alternative estimates \u2014 within the validation elements under Conceptual Soundness. A systematic challenger-model program formalizes that comparison discipline.", "normative_force": "supervisory-guidance", "source_version": "2026-04-17", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "bcbs_239", "requirement_id": "Principle 7", "fit": "partial", "rationale": "BCBS 239 Principle 7 (Accuracy of reporting) requires reports to be reconciled and validated, with reasonableness checks including comparison against alternative estimates. Challenger-model benchmarking is exactly that comparison discipline applied to model outputs feeding risk reports.", "normative_force": "supervisory-guidance", "source_version": "2013", "reviewed_on": "2026-07-02", "basis": "asserted", "relation": "satisfies" }, { "framework": "eu_ai_act", "requirement_id": "Art. 9(6)", "fit": "partial", "rationale": "EU AI Act Art. 9(6) requires that high-risk AI systems be tested to identify the most appropriate and targeted risk management measures. Benchmarking against challenger models is a testing discipline that evidences whether the production model remains the appropriate choice for its intended purpose.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "coso_icfr", "requirement_id": "Principle 16", "fit": "adjacent", "rationale": "COSO Principle 16 requires ongoing monitoring activities to ascertain whether components of internal control are present and functioning. Periodic challenger model comparison is an ongoing monitoring activity for the model selection and maintenance control environment.", "normative_force": "industry-framework", "source_version": "2013", "reviewed_on": "2026-06-28", "basis": "asserted", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "RS1", "fit": "adjacent", "rationale": "Microsoft Responsible AI Standard v2 Goal RS1 (Reliability and safety guidance) requires following reliability and safety guidance when developing and deploying systems, including defining safe operating parameters. For institutions using Azure AI services, this goal produces vendor-side governance artifacts that align with benchmarking and challenger model comparison. The Standard is Microsoft's published internal policy offered as reference practice, not regulatory guidance.", "normative_force": "best-practice", "source_version": "2022", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "anthropic_rsp", "requirement_id": "Capability Thresholds", "fit": "adjacent", "rationale": "RSP v3.3 frames Anthropic's model risk decisions around Capability Thresholds \u2014 capability levels that trigger stronger Required Safeguards. The thresholds concept is only loosely parallel to challenger-model benchmarking: it governs Anthropic's own frontier-risk decisions, and is cited here as vendor context for evaluating vendor-model capability changes, not as a benchmarking methodology.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_financial", "requirement_id": "Vertex AI Model Monitoring", "fit": "partial", "rationale": "Vertex AI Model Monitoring detects prediction drift and training-serving skew for models deployed on Google Cloud. For GCP-hosted financial AI systems, this capability supplies the platform-layer support for benchmarking and challenger model comparison. This is vendor product documentation, not regulatory guidance; it does not address model-layer regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://finance/controls/MV-04", "meta": { "authored_on": "2026-06-29", "schema_version": "1.1.0" }, "validation_objective": "At each validation cycle the validation function must assess production model performance against at least one defined benchmark and one challenger model using held-out test sets inaccessible to model development teams, and issue a formal comparative performance opinion documenting whether the production model remains the best available option for its intended use. Challenger selection criteria and comparison metrics must be specified and approved before each cycle begins.", "evidence_required": [ "challenger_program_record per validation cycle defining challenger candidates, approved comparison metrics, and test set specification approved by the validation lead before the cycle begins", "comparative_performance_report per validation cycle showing production model vs. benchmark vs. challenger results across all defined metrics, with statistical significance indicators", "held_out_test_set_access_log confirming test sets used for benchmarking were not accessible to model development team members prior to validation cycle completion", "validation_comparative_opinion_record per cycle with the validator's signed conclusion on whether the production model remains optimal, including rationale for any recommendation to replace or maintain" ], "machine_tests": [ "Query model registry for all Tier 1 models with validation cycles in the past 24 months \u2192 assert each cycle has a linked comparative_performance_report with documented challenger results", "Check access control logs for validation-controlled held-out test sets \u2192 assert model development team members have zero read access prior to validation cycle completion", "Review validation_comparative_opinion_records for completeness \u2192 assert zero records missing challenger_metrics_comparison or with opinion field null" ], "human_review": [ "Review challenger model selection criteria to assess whether challengers represent genuinely competitive alternatives rather than strawman models designed to make the production model appear superior", "Assess whether comparison metrics for each cycle are selected by the validation function independently rather than proposed by model development to avoid metric selection bias", "Evaluate cases where the validation function concluded the production model should remain despite challenger outperformance to verify the rationale is business-justified and fully documented" ], "blocking_effect": "requires-review", "normative_status": "supervisory-guidance", "anti_patterns": [ "Allowing model development teams to select the benchmarks and metrics used to assess their own models against challengers, enabling cherry-picking of favorable comparison dimensions", "Using the same test data for both model training or tuning and subsequent benchmarking validation, inflating production model performance relative to challengers tested on unfamiliar data", "Selecting challengers known to underperform the production model rather than best-available alternatives, producing benchmarking comparisons with no meaningful discriminative power", "Conducting benchmarking exercises without a pre-specified metric set, allowing post-hoc metric selection to justify a predetermined conclusion about model optimality", "Omitting benchmarking from validation cycles for AI/ML models by classifying them as outside the challenger program scope to avoid maintaining challenger model infrastructure" ], "update_status": "current", "layer_code": "MV" }, { "id": "MV-05", "layer": "MV", "plane": "lifecycle", "name": "Validation Frequency and Trigger-Based Review", "plain": "The enterprise must define a risk-tiered validation frequency schedule for all models and a defined set of events that trigger ad-hoc validation reviews outside the regular cycle, ensuring that changes in model environment, use, or performance are promptly assessed.", "threat": { "tags": [ "stale-validation", "trigger-gap", "regime-change-exposure", "validation-calendar-drift" ], "desc": "Fixed calendar-based validation schedules without trigger-based review leave models exposed during the periods of highest risk \u2014 when markets shift, use cases expand, or model inputs change. Models deployed in new contexts without re-validation carry unknown risk profiles. AI/ML models face additional trigger events such as training data distribution shifts and provider API changes that have no analog in traditional statistical models." }, "standard": [ { "id": "sr26_2", "section": "\u00a7V (Ongoing Model Monitoring)", "title": "Ongoing monitoring and periodic review" }, { "id": "eu_ai_act", "section": "Art. 9(2), 9(6)", "title": "Regular systematic review and testing of the risk management system" }, { "id": "coso_icfr", "section": "Principle 16", "title": "Ongoing monitoring of internal controls" }, { "id": "aicpa_soc2", "section": "CC4.1", "title": "Ongoing and separate evaluations of controls" } ], "sources": [ { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Anthropic's Responsible Scaling Policy v3.3 documents the vendor's capability thresholds and safeguards, cited as third-party AI due diligence context for the apeiris://finance/controls/MV-05 Validation Frequency and Trigger-Based Review control.", "reviewed_on": "2026-07-02" }, { "id": "openai_enterprise_data_governance_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "OpenAI's enterprise privacy and compliance documentation records vendor-side data handling and audit-log capabilities relevant to the apeiris://finance/controls/MV-05 Validation Frequency and Trigger-Based Review control.", "reviewed_on": "2026-07-02" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://finance/controls/MV-05 Validation Frequency and Trigger-Based Review control.", "reviewed_on": "2026-07-01" }, { "id": "aws_financial_services_compliance_2024", "title": "AWS User Guide to Financial Services Regulations & Guidelines in the United States", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/financial-services/security-compliance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_financial_services_compliance_2024", "relationship": "informative_reference", "rationale": "AWS's financial services regulatory guide and compliance tooling document infrastructure-layer capabilities relevant to the apeiris://finance/controls/MV-05 Validation Frequency and Trigger-Based Review control.", "reviewed_on": "2026-07-02" }, { "id": "google_cloud_financial_services_ai_2024", "title": "Google Cloud Explainable AI", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/explainable-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_financial_services_ai_2024", "relationship": "informative_reference", "rationale": "Google Cloud's Explainable AI and Vertex AI model governance documentation describes platform capabilities relevant to the apeiris://finance/controls/MV-05 Validation Frequency and Trigger-Based Review control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Risk-tiered validation frequency matrix (Tier 1: annual full validation, Tier 2: biennial, Tier 3: triennial or material change triggered) combined with a maintained trigger event catalog that automatically initiates ad-hoc review workflows.", "steps": [ "Define a model tier classification based on materiality, complexity, and use \u2014 Tier 1 highest risk requiring annual validation, Tier 2 biennial, Tier 3 triennial or trigger-based.", "Document a trigger event catalog covering at minimum: material model modification, change in use case, change in data inputs, adverse outcome analysis results, significant market regime change, and regulatory change.", "Implement a trigger event monitoring workflow that routes events to the validation function for triage within 5 business days.", "Maintain a validation calendar for all models with planned validation dates, actual completion dates, and open trigger event reviews." ], "model_risk_officer": { "summary": "Validation frequency management is a core operational responsibility. The validation calendar must be actively managed, and trigger events must be triaged rapidly to prevent validation gaps during high-risk periods.", "actions": [ "Maintain and publish the model validation calendar with planned dates for all in-scope models.", "Review trigger event submissions weekly and initiate ad-hoc validation reviews within 5 business days for qualifying events.", "Report validation calendar status, overdue validations, and open trigger reviews to the risk committee monthly." ], "failure_signals": [ "Tier 1 models with validations overdue by more than 30 days.", "Trigger events submitted but not triaged within 5 business days.", "Validation calendar not updated in the current quarter." ] }, "compliance_officer": { "summary": "SR 26-2 describes ongoing monitoring and periodic review expectations, and the EU AI Act requires them for high-risk systems. The validation frequency schedule and trigger catalog are the primary evidence artifacts for demonstrating these practices.", "actions": [ "Review the validation frequency schedule annually against SR 26-2 expectations and EU AI Act Article 9 requirements.", "Confirm that the trigger event catalog covers all regulatory-specified event categories.", "Include validation timeliness metrics in the quarterly model risk compliance report." ], "metrics": [ "Tier 1 model validation timeliness: \u226595% completed within the scheduled window.", "Trigger event triage completion within 5 business days: target 100%.", "Average days overdue for validations not completed on schedule: target \u226415 days." ], "failure_signals": [ "Tier 1 validation timeliness below 90%.", "Trigger catalog not updated for new model types such as LLMs deployed in the past 12 months.", "Supervisory criticism citing stale validations." ] }, "internal_audit": { "summary": "Audit must test that the validation frequency schedule is adhered to in practice and that trigger events result in actual ad-hoc review, not just triage acknowledgment.", "actions": [ "Sample the model inventory and verify that each model's last validation date falls within the scheduled window for its tier.", "Test a sample of trigger events and confirm that ad-hoc validation reviews were initiated and completed.", "Verify that the trigger event catalog was updated when new model types or data sources were introduced." ], "failure_signals": [ "Tier 1 models with last validation date more than 14 months ago.", "Trigger events closed with triage acknowledgment but no ad-hoc review initiated.", "Trigger catalog does not include events specific to AI/ML or LLM model types." ] }, "it_operations": { "summary": "IT Operations runs the validation scheduler and trigger detection behind risk-tiered validation frequency and trigger-based review \u2014 integrating it with deployment pipelines, enforcing the automated gates, and keeping the supporting data flows reliable and auditable.", "actions": [ "Integrate the validation scheduler and trigger detection with CI/CD and runtime tooling so that validation due dates and trigger events open review tasks automatically.", "Automate collection and retention of trigger events and validation task records in immutable, hash-verified storage.", "Monitor pipeline and integration health and alert when a trigger condition fires without a review task being created." ], "failure_signals": [ "Production changes bypass the automated gate so that it is no longer true that validation due dates and trigger events open review tasks automatically.", "Gaps or outages in trigger events and validation task records collection exceeding 24 hours.", "Manual, untracked edits to the validation scheduler and trigger detection records." ] }, "financial_controller": { "summary": "Stale validations on reporting models undermine reliance on their outputs; the controller tracks validation currency for the reporting stack.", "actions": [ "Track validation expiry for models feeding financial statements and escalate before staleness.", "Confirm trigger-based reviews fired for reporting models after material market or portfolio shifts." ], "failure_signals": [ "Financial-statement models operating past their validation due date.", "A trigger event on a reporting model with no follow-up review." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Most organizations have calendar-based validation schedules but lack mature trigger event programs, particularly for AI/ML-specific triggers." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "federated-enterprise" ], "implementers": [ "Model Risk Officer", "Validation Team", "Model Owners" ], "frameworks": [ { "framework": "sr26_2", "requirement_id": "\u00a7V (Ongoing Model Monitoring)", "fit": "direct", "rationale": "SR 26-2 \u00a7V describes ongoing monitoring and periodic review with frequency commensurate with model risk under its Ongoing Model Monitoring subheading. Risk-tiered validation schedules and trigger-based reviews operationalize that expectation.", "normative_force": "supervisory-guidance", "source_version": "2026-04-17", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "eu_ai_act", "requirement_id": "Art. 9(2), 9(6)", "fit": "direct", "rationale": "EU AI Act Art. 9(2) requires the risk management system to be a continuous iterative process subject to regular systematic review and updating, and Art. 9(6) requires testing to identify the most appropriate risk management measures. Tiered validation frequency with trigger-based review operationalizes both the review-and-update and testing duties for high-risk financial AI systems.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "coso_icfr", "requirement_id": "Principle 16", "fit": "partial", "rationale": "COSO Principle 16 requires that ongoing monitoring evaluations assess whether controls are present and functioning. Validation frequency management is the mechanism for ensuring model risk controls are evaluated with appropriate regularity.", "normative_force": "industry-framework", "source_version": "2013", "reviewed_on": "2026-06-28", "basis": "asserted", "relation": "informs" }, { "framework": "soc2", "requirement_id": "CC4.1", "fit": "partial", "rationale": "SOC 2 CC4.1 requires the entity to select, develop, and perform ongoing and/or separate evaluations to ascertain whether controls are present and functioning. Risk-tiered validation frequency with trigger-based review is exactly that evaluation cadence applied to models.", "normative_force": "certification-standard", "source_version": "2022", "reviewed_on": "2026-07-02", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "bcbs_239", "requirement_id": "Principle 9", "fit": "adjacent", "rationale": "BCBS 239 Principle 9 requires timely and frequency-appropriate risk reporting. Validation timeliness directly affects the reliability of risk reports produced by models, making validation frequency a prerequisite for BCBS 239 compliance.", "normative_force": "supervisory-guidance", "source_version": "2013", "reviewed_on": "2026-06-28", "basis": "asserted", "relation": "satisfies" }, { "framework": "openai_enterprise", "requirement_id": "API model versioning & deprecation policy", "fit": "partial", "rationale": "OpenAI publishes model versioning and deprecation documentation for its API, including dated model snapshots and deprecation timelines. Institutions using OpenAI models in financial workflows can incorporate this vendor capability into risk-tiered validation frequency and trigger-based review. This is vendor capability documentation, not regulatory guidance; it covers the vendor side only.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "RS3", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal RS3 (Ongoing monitoring, feedback, and evaluation) requires ongoing monitoring, feedback collection, and evaluation of deployed systems. For institutions using Azure AI services, this goal produces vendor-side governance artifacts that align with risk-tiered validation frequency and trigger-based review. The Standard is Microsoft's published internal policy offered as reference practice, not regulatory guidance.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_financial", "requirement_id": "AWS Audit Manager", "fit": "partial", "rationale": "AWS Audit Manager automates evidence collection against control frameworks for AWS workloads, and AWS CloudTrail records account-level API activity. For AWS-hosted financial AI systems, this supplies the infrastructure-layer support and evidence stream for risk-tiered validation frequency and trigger-based review. This is vendor documentation of real AWS capabilities \u2014 it does not substitute for model-layer validation or regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_financial", "requirement_id": "Vertex AI Model Monitoring", "fit": "partial", "rationale": "Vertex AI Model Monitoring detects prediction drift and training-serving skew for models deployed on Google Cloud. For GCP-hosted financial AI systems, this capability supplies the platform-layer support for risk-tiered validation frequency and trigger-based review. This is vendor product documentation, not regulatory guidance; it does not address model-layer regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://finance/controls/MV-05", "meta": { "authored_on": "2026-06-29", "schema_version": "1.1.0" }, "validation_objective": "The enterprise must maintain a documented risk-tiered validation frequency schedule assigning each model to a validation tier with Tier 1 validated at least annually, Tier 2 at least biennially, and Tier 3 at least triennially or on material change. A defined trigger event catalog must cause any trigger event to initiate an ad-hoc validation review workflow within the defined maximum response window, with zero trigger events left unactioned.", "evidence_required": [ "model_tier_assignment_record per model showing assigned validation tier, assignment date, tier rationale, and scheduled next validation date", "trigger_event_catalog document specifying all defined trigger events including performance degradation, data regime change, regulatory update, and use-case expansion, with maximum response timelines per event type", "trigger_event_log for the past 12 months showing each trigger event, affected model, review initiation date, and review completion date", "validation_schedule_compliance_report for the past 12 months listing all models with scheduled validation dates and their completion status, with overdue items flagged and exemptions documented" ], "machine_tests": [ "Query model registry for models with scheduled validation dates in the past 12 months \u2192 assert zero models with overdue status lacking a documented exemption approved by the head of validation", "Inject a synthetic trigger event (e.g., simulated performance degradation alert) into the trigger management system \u2192 assert ad-hoc review workflow initiated within the defined maximum response window", "Check trigger_event_log for open entries beyond the maximum review initiation window \u2192 assert zero trigger events with status=open past the defined SLA" ], "human_review": [ "Review the trigger event catalog to assess whether defined events are comprehensive, covering data distribution shift, use-case expansion, regulatory updates, significant incidents, and material upstream system changes", "Examine the validation schedule compliance report for systematic patterns of overdue validations by tier or business line, indicating structural governance gaps rather than isolated scheduling failures", "Assess whether trigger-to-review workflows result in reviews completing within defined timelines or whether reviews are formally initiated but allowed to stall without completion" ], "blocking_effect": "requires-review", "normative_status": "supervisory-guidance", "anti_patterns": [ "Assigning all models to Tier 3 triennial validation to minimize validation workload rather than applying risk-based tiering by model materiality, complexity, and regulatory classification", "Defining the trigger event catalog narrowly to exclude operational events such as significant changes in input data distributions or upstream system changes that affect model inputs", "Treating trigger events as advisory notifications reviewed when validator bandwidth permits rather than mandatory workflow initiators with defined maximum response SLAs", "Allowing scheduled validation dates to slip indefinitely for models claimed to be in active redevelopment without a maximum deferral limit or compensating risk controls", "Maintaining the trigger event catalog as a static policy document rather than an active workflow rule that automatically initiates review workflows when trigger conditions are detected" ], "update_status": "current", "layer_code": "MV" }, { "id": "MV-06", "layer": "MV", "plane": "control", "name": "Validation Scope for AI/ML and LLM Models", "plain": "The validation function must maintain an adapted methodology for AI/ML and LLM models that addresses the unique validation challenges of these architectures, including training data assessment, feature importance analysis, fairness testing, prompt injection risk, and behavioral consistency evaluation.", "threat": { "tags": [ "ai-validation-gap", "prompt-injection-blindness", "training-data-bias", "black-box-deployment" ], "desc": "Traditional statistical model validation methods are insufficient for ML models and LLMs. Black-box model architectures lack interpretable coefficients, making conceptual soundness evaluation qualitatively different. LLMs introduce novel failure modes including prompt injection, output hallucination, and behavioral inconsistency that have no analog in traditional models. Deploying AI/ML systems without adapted validation creates material governance gaps that regulators are increasingly scrutinizing." }, "standard": [ { "id": "eu_ai_act", "section": "Art. 9 & 10", "title": "Risk management and data governance for high-risk AI" }, { "id": "sr26_2", "section": "\u00a7V (Validation and Monitoring)", "title": "Validation commensurate with model complexity (GenAI excluded per fn. 3)" }, { "id": "microsoft_rai", "section": "RS1", "title": "Reliability & safety guidance for system evaluation" }, { "id": "bcbs_239", "section": "Principle 7", "title": "Validated reporting where AI/ML models contribute" } ], "sources": [ { "id": "google_cloud_financial_services_ai_2024", "title": "Google Cloud Explainable AI", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/explainable-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_financial_services_ai_2024", "relationship": "informative_reference", "rationale": "Google Cloud's Explainable AI and Vertex AI model governance documentation describes platform capabilities relevant to the apeiris://finance/controls/MV-06 Validation Scope for AI/ML and LLM Models control.", "reviewed_on": "2026-07-02" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://finance/controls/MV-06 Validation Scope for AI/ML and LLM Models control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Anthropic's Responsible Scaling Policy v3.3 documents the vendor's capability thresholds and safeguards, cited as third-party AI due diligence context for the apeiris://finance/controls/MV-06 Validation Scope for AI/ML and LLM Models control.", "reviewed_on": "2026-07-02" }, { "id": "openai_enterprise_data_governance_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "OpenAI's enterprise privacy and compliance documentation records vendor-side data handling and audit-log capabilities relevant to the apeiris://finance/controls/MV-06 Validation Scope for AI/ML and LLM Models control.", "reviewed_on": "2026-07-02" }, { "id": "aws_financial_services_compliance_2024", "title": "AWS User Guide to Financial Services Regulations & Guidelines in the United States", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/financial-services/security-compliance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_financial_services_compliance_2024", "relationship": "informative_reference", "rationale": "AWS's financial services regulatory guide and compliance tooling document infrastructure-layer capabilities relevant to the apeiris://finance/controls/MV-06 Validation Scope for AI/ML and LLM Models control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Supplemental AI/ML validation playbook appended to the standard validation methodology, covering training data assessment, explainability requirements by model tier, fairness testing protocols, LLM-specific behavioral testing, and third-party model due diligence.", "steps": [ "Develop and maintain an AI/ML validation playbook that specifies adapted validation steps for gradient boosting, neural network, and LLM model types.", "Require training data assessment for all ML models including data provenance, class balance analysis, and distribution shift testing between training and production data.", "Implement fairness testing protocols for AI models used in credit, underwriting, or other decisions with potential disparate impact, documented against applicable protected class requirements.", "For LLM-based models, conduct behavioral consistency testing across adversarial prompts, prompt injection scenarios, and output hallucination rate measurement.", "Apply third-party model due diligence requirements for externally-sourced AI models, including vendor validation documentation review." ], "model_risk_officer": { "summary": "AI/ML model validation requires specialized expertise and adapted methodology. The validation function must build or acquire this capability to maintain effective oversight of the growing AI model inventory.", "actions": [ "Maintain the AI/ML validation playbook and update it as new model types are deployed.", "Ensure the validation function includes staff with ML engineering, data science, and AI safety expertise.", "Require AI/ML validation reports to document which adapted methodology elements were applied; any element not applied must be documented with rationale." ], "failure_signals": [ "AI/ML models validated using standard statistical validation templates without adaptation.", "No training data assessment on file for ML models in the Tier 1 inventory.", "LLM-based models deployed without behavioral consistency or prompt injection testing." ] }, "compliance_officer": { "summary": "EU AI Act imposes specific requirements for high-risk AI systems in financial services. The adapted validation methodology is the primary mechanism for demonstrating regulatory compliance for AI models.", "actions": [ "Map AI/ML validation playbook elements to EU AI Act Articles 9 and 10 requirements.", "Review fairness testing protocols against applicable US and EU anti-discrimination frameworks.", "Include AI/ML validation coverage in the annual model risk compliance report." ], "metrics": [ "AI/ML model coverage under adapted validation methodology: 100% of Tier 1 AI models.", "Fairness testing completion rate for applicable models: 100%.", "LLM behavioral testing completion rate: 100% before production deployment." ], "failure_signals": [ "AI models in production without completed adapted validation.", "Fairness testing gaps for credit or underwriting AI models.", "Third-party AI models deployed without vendor due diligence documentation." ] }, "it_operations": { "summary": "IT operations must support validation function access to model artifacts, training data, and inference infrastructure needed to conduct adapted AI/ML validation.", "actions": [ "Provide the validation team with read-only access to model training data sources, feature pipelines, and model registry.", "Maintain audit logs of model inference calls accessible to the validation function for behavioral testing.", "Ensure model versioning systems capture the exact model artifact validated for reproducibility." ], "failure_signals": [ "Validation team unable to access training data or feature pipelines for ML model assessment.", "Model inference logs not retained for a duration sufficient to support backtesting.", "Model registry does not capture artifact hashes tied to validated model versions." ] }, "financial_controller": { "summary": "Where LLM outputs enter financial processes, the controller needs evidence the supplemental validation actually ran before relying on them.", "actions": [ "Identify LLM-assisted steps in financial reporting workflows and confirm supplemental validation coverage.", "Restrict unvalidated LLM outputs to advisory use outside the ICFR boundary." ], "failure_signals": [ "LLM-generated content entering financial records without supplemental validation.", "ICFR narratives unable to state how AI/ML components were validated." ] }, "internal_audit": { "summary": "Internal audit tests whether the supplemental AI/ML methodology exists, is versioned, and was actually applied \u2014 not merely referenced \u2014 for each in-scope model.", "actions": [ "Sample AI/ML and LLM validations and verify each supplemental domain has pass/fail findings.", "Verify the methodology supplement is versioned and its updates are governance-approved.", "Test that models classified as traditional are not misclassified to evade the supplement." ], "failure_signals": [ "Validation reports citing the supplement without per-domain findings.", "LLM-based systems classified as non-models to bypass validation.", "Methodology supplement unchanged despite material new model types in production." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "AI/ML adapted validation is an emerging practice; most organizations are building capability in this area. LLM validation methodology is nascent industry-wide." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "cloud-native" ], "implementers": [ "Model Risk Officer", "Data Science Team", "Validation Team" ], "frameworks": [ { "framework": "eu_ai_act", "requirement_id": "Art. 9 & 10", "fit": "direct", "rationale": "EU AI Act Articles 9 and 10 impose specific risk management and data governance requirements for high-risk AI systems. The adapted validation methodology is the mechanism for operationalizing these requirements, including training data assessment and ongoing performance monitoring requirements.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-06-28", "basis": "anchored", "relation": "satisfies" }, { "framework": "sr26_2", "requirement_id": "\u00a7V (Validation and Monitoring)", "fit": "partial", "rationale": "Scope note: SR 26-2 footnote 3 excludes generative AI and agentic systems from the guidance's stated scope, so SR 26-2 does not itself cover LLM validation. \u00a7V's validation elements (conceptual soundness, outcomes analysis, ongoing monitoring) remain the closest supervisory reference point; MV-06 exists to fill the gap the guidance leaves by extending validation methodology to AI/ML and LLM models as institutional practice.", "normative_force": "supervisory-guidance", "source_version": "2026-04-17", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "microsoft_rai", "requirement_id": "RS1", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal RS1 (Reliability and safety guidance) requires following reliability and safety guidance when developing and deploying systems, including defining safe operating parameters. For institutions using Azure AI services, this goal produces vendor-side governance artifacts that align with the supplemental validation methodology for AI/ML and LLM models. The Standard is Microsoft's published internal policy offered as reference practice, not regulatory guidance.", "normative_force": "best-practice", "source_version": "2022", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "bcbs_239", "requirement_id": "Principle 7", "fit": "partial", "rationale": "BCBS 239 Principle 7 (Accuracy of reporting) expects reported risk data to be validated. Where AI/ML or LLM components contribute to risk reports at a BCBS 239 institution, MV-06's supplemental validation methodology is what makes Principle 7's validation expectation meaningful for those model types; the fit is partial \u2014 BCBS 239 itself says nothing about model validation methodology.", "normative_force": "supervisory-guidance", "source_version": "2013", "reviewed_on": "2026-07-02", "basis": "asserted", "relation": "satisfies" }, { "framework": "anthropic_rsp", "requirement_id": "Capability assessment methodology", "fit": "adjacent", "rationale": "RSP v3.3 describes Anthropic's evaluation methodology for frontier model capabilities. It illustrates the behavior-level testing discipline that LLM validation supplements such as MV-06 require and that conventional statistical validation does not cover; the fit is adjacent \u2014 the RSP is the vendor's own evaluation program, not a validation standard for deployers.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_financial", "requirement_id": "Explainable AI", "fit": "adjacent", "rationale": "Google Cloud's Explainable AI documentation (cloud.google.com/explainable-ai) describes feature attribution and explanation tooling available through Vertex AI. For GCP-hosted financial AI systems, this capability supplies the platform-layer support for the supplemental validation methodology for AI/ML and LLM models. This is vendor product documentation, not regulatory guidance; it does not address model-layer regulatory obligations.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "openai_enterprise", "requirement_id": "Zero data retention (API)", "fit": "partial", "rationale": "The OpenAI API offers zero-data-retention handling for eligible endpoints, documented in OpenAI's enterprise privacy commitments. Institutions using OpenAI models in financial workflows can incorporate this vendor capability into the supplemental validation methodology for AI/ML and LLM models. This is vendor capability documentation, not regulatory guidance; it covers the vendor side only.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "aws_financial", "requirement_id": "Financial Services Industry Lens \u2014 AWS Well-Architected", "fit": "partial", "rationale": "The Financial Services Industry Lens for the AWS Well-Architected Framework describes design principles, risk considerations, and shared-responsibility boundaries for regulated financial workloads on AWS. For AWS-hosted financial AI systems, this supplies the infrastructure-layer support and evidence stream for the supplemental validation methodology for AI/ML and LLM models. This is vendor documentation of real AWS capabilities \u2014 it does not substitute for model-layer validation or regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://finance/controls/MV-06", "meta": { "authored_on": "2026-06-29", "schema_version": "1.1.0" }, "validation_objective": "The validation function must maintain a versioned AI/ML and LLM validation methodology supplement that extends a standard SR 26-2-style validation framework -- which by its footnote 3 does not cover generative AI -- to training data assessment, feature importance and explainability, fairness and bias testing, prompt injection risk, and behavioral consistency. Every AI/ML and LLM model must be validated against this supplemental methodology before production deployment, with the validation report explicitly addressing each supplemental domain with pass/fail findings.", "evidence_required": [ "ai_ml_validation_methodology_document versioned and approved by the head of model validation, covering training data assessment, tier-based explainability requirements, fairness testing protocols, LLM behavioral testing, and third-party model due diligence procedures", "training_data_assessment_report per AI/ML model showing data provenance, class distribution analysis, bias assessment results, and documented known training data limitations", "fairness_testing_report per model per validation cycle showing protected attribute disparate impact metrics against defined thresholds and remediation actions for identified disparate effects", "llm_behavioral_testing_report for LLM-based models showing prompt injection resistance test results, behavioral consistency scores under adversarial prompt reformulations, and output quality evaluation against defined rubrics", "explainability_assessment per model documenting the explainability method, its adequacy for the model tier and use-case, and evidence that the method supports meaningful explanations for decision subjects" ], "machine_tests": [ "Query model registry for AI/ML models promoted to production \u2192 assert each has a linked ai_ml_validation_report with all supplemental sections completed: training_data, fairness, and explainability", "Execute automated fairness testing suite against model API with defined protected attribute test cases \u2192 assert all disparate impact ratios are within defined acceptance thresholds", "Run prompt injection test harness against LLM-based model endpoints \u2192 assert zero injection attempts succeed in causing out-of-scope behavior or bypassing defined output constraints", "Run behavioral consistency tests with semantically equivalent prompt reformulations against LLM endpoints \u2192 assert output similarity scores meet the defined minimum consistency threshold" ], "human_review": [ "Review AI/ML validation methodology to confirm it is updated at least annually to reflect emerging techniques such as new fairness metrics and LLM-specific attack vectors rather than remaining static since adoption", "Assess fairness testing thresholds for protected attributes to confirm they reflect legal requirements under ECOA, FCRA, and EU AI Act non-discrimination provisions rather than solely statistical conventions", "Review LLM behavioral testing results for a sample of production models to assess whether test scenarios are adversarially realistic rather than confirmatory of expected behavior only" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Applying a standard statistical validation template to LLM-based models without any supplemental AI/ML methodology, treating generative models (outside SR 26-2's stated scope per footnote 3) as equivalent to traditional regression models", "Conducting fairness testing only on protected attributes in isolation rather than testing intersectional combinations where disparate impacts are most likely to emerge", "Using the training data evaluation prepared by the model development team as the validation function's training data assessment without independent validation-controlled data examination", "Classifying third-party LLM APIs as out of scope for the AI/ML validation methodology because model weights are unavailable, without requiring equivalent third-party due diligence documentation", "Limiting behavioral consistency testing to predetermined prompt templates model developers confirmed produce expected outputs rather than adversarially diverse prompt sets" ], "update_status": "current", "layer_code": "MV" }, { "id": "MV-07", "layer": "MV", "plane": "control", "name": "Validation Finding Escalation and Remediation", "plain": "The validation function must operate a formal finding management process that classifies validation findings by severity, defines escalation paths to appropriate decision-makers, tracks remediation status, and requires documented management acceptance or remediation for all open findings before or concurrent with continued model use.", "threat": { "tags": [ "finding-suppression", "remediation-drift", "management-override-opacity", "governance-gap" ], "desc": "Validation findings that are not formally tracked and escalated are effectively invisible to senior management and regulators. Informal finding resolution allows model owners to address findings on their own timeline or to informally negotiate them down without accountability. In regulated financial institutions, untracked validation findings represent a significant examination risk and can indicate systemic model governance failures." }, "standard": [ { "id": "sr26_2", "section": "\u00a7V + \u00a7VI", "title": "Communication of validation findings and governance response" }, { "id": "sox", "section": "\u00a7302 & \u00a7404", "title": "Management assertion on internal control effectiveness" }, { "id": "pcaob_as_2201", "section": "\u00b6.62-.70", "title": "Evaluation of identified control deficiencies" }, { "id": "coso_icfr", "section": "Principle 17", "title": "Evaluation and communication of internal control deficiencies" } ], "sources": [ { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Anthropic's Responsible Scaling Policy v3.3 documents the vendor's capability thresholds and safeguards, cited as third-party AI due diligence context for the apeiris://finance/controls/MV-07 Validation Finding Escalation and Remediation control.", "reviewed_on": "2026-07-02" }, { "id": "openai_enterprise_data_governance_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "OpenAI's enterprise privacy and compliance documentation records vendor-side data handling and audit-log capabilities relevant to the apeiris://finance/controls/MV-07 Validation Finding Escalation and Remediation control.", "reviewed_on": "2026-07-02" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://finance/controls/MV-07 Validation Finding Escalation and Remediation control.", "reviewed_on": "2026-07-01" }, { "id": "aws_financial_services_compliance_2024", "title": "AWS User Guide to Financial Services Regulations & Guidelines in the United States", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/financial-services/security-compliance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_financial_services_compliance_2024", "relationship": "informative_reference", "rationale": "AWS's financial services regulatory guide and compliance tooling document infrastructure-layer capabilities relevant to the apeiris://finance/controls/MV-07 Validation Finding Escalation and Remediation control.", "reviewed_on": "2026-07-02" }, { "id": "google_cloud_financial_services_ai_2024", "title": "Google Cloud Explainable AI", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/explainable-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_financial_services_ai_2024", "relationship": "informative_reference", "rationale": "Google Cloud's Explainable AI and Vertex AI model governance documentation describes platform capabilities relevant to the apeiris://finance/controls/MV-07 Validation Finding Escalation and Remediation control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Finding severity taxonomy (Critical/High/Moderate/Low/Informational) documented in a findings register with required management response SLAs, formal acceptance-of-risk process for findings not remediated, and escalation to the model risk committee for all Critical and High findings.", "steps": [ "Define a finding severity taxonomy with clear criteria for each level and corresponding management response SLA timelines.", "Maintain a centralized finding register that tracks all open validation findings with assigned owner, severity, due date, and remediation status.", "Require formal written management response for all validation findings within the SLA, including either a remediation commitment with timeline or a documented acceptance-of-risk.", "Escalate all Critical and High findings to the model risk committee within 5 business days of issuance.", "Produce a monthly open findings summary report for senior management showing aging, owner, and remediation status." ], "model_risk_officer": { "summary": "The finding management process is the accountability mechanism that gives the validation function its teeth. Without formal escalation and tracking, validation is advisory rather than governing.", "actions": [ "Maintain the finding register and ensure all findings are entered within 2 business days of validation report issuance.", "Escalate Critical findings to the CRO and model risk committee immediately upon identification.", "Produce monthly open findings aging reports for the risk committee." ], "failure_signals": [ "Critical findings not escalated to the risk committee within the required timeframe.", "Finding register contains entries with no management response after the SLA has elapsed.", "Models with open Critical findings continuing in production without documented senior management acceptance." ] }, "financial_controller": { "summary": "For financial reporting models, open validation findings are potential internal control deficiencies that must be assessed for SOX disclosure implications.", "actions": [ "Review the open findings register quarterly for any findings related to models supporting financial reporting.", "Assess whether any open High or Critical findings constitute significant deficiencies or material weaknesses under SOX 404.", "Include model risk finding status in sub-certifications provided to the CFO." ], "failure_signals": [ "Open Critical findings for financial reporting models not assessed against SOX deficiency thresholds.", "Controller sub-certifications that do not reference open model validation findings.", "Financial statement restatement risk arising from models with open validation findings." ] }, "compliance_officer": { "summary": "SR 26-2 describes communicating validation findings to management and tracking them to resolution. The finding management process is the primary evidence artifact for demonstrating this practice.", "actions": [ "Review the finding register quarterly for completeness and timeliness of management responses.", "Confirm that escalation procedures align with SR 26-2 expectations and applicable EU AI Act requirements.", "Include open findings metrics in the quarterly model risk compliance report." ], "metrics": [ "Management response timeliness rate: \u226595% of findings receive management response within SLA.", "Critical finding escalation timeliness: 100% escalated within 5 business days.", "Open High+ findings with overdue management response: target zero." ], "failure_signals": [ "Management response timeliness below 90%.", "Critical findings not escalated within the required timeframe.", "Finding register entries without owner assignment." ] }, "internal_audit": { "summary": "Audit must independently verify that the finding management process operates as documented and that management responses reflect genuine remediation rather than paper compliance.", "actions": [ "Test a sample of closed findings to verify that remediation was completed as documented.", "Verify that acceptance-of-risk findings were approved at the appropriate management level.", "Review escalation records for Critical and High findings to confirm timely committee notification." ], "failure_signals": [ "Closed findings where purported remediation cannot be confirmed through independent testing.", "Acceptance-of-risk approvals signed below the required management level.", "Critical findings with no documented risk committee discussion." ] }, "it_operations": { "summary": "IT Operations runs the finding-tracking system behind validation finding escalation and remediation tracking \u2014 integrating it with deployment pipelines, enforcing the automated gates, and keeping the supporting data flows reliable and auditable.", "actions": [ "Integrate the finding-tracking system with CI/CD and runtime tooling so that unresolved critical findings block redeployment of the affected model.", "Automate collection and retention of finding lifecycle records in immutable, hash-verified storage.", "Monitor pipeline and integration health and alert when finding due dates pass without escalation." ], "failure_signals": [ "Production changes bypass the automated gate so that it is no longer true that unresolved critical findings block redeployment of the affected model.", "Gaps or outages in finding lifecycle records collection exceeding 24 hours.", "Manual, untracked edits to the finding-tracking system records." ] } }, "maturity": { "current": "defined", "target": "managed", "notes": "Finding tracking exists in many institutions but formalized escalation and acceptance-of-risk processes are inconsistently implemented." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "federated-enterprise" ], "implementers": [ "Model Risk Officer", "Validation Team", "Compliance Team" ], "frameworks": [ { "framework": "sr26_2", "requirement_id": "\u00a7V + \u00a7VI", "fit": "direct", "rationale": "SR 26-2 \u00a7V (Validation and Monitoring) describes communicating validation results, and \u00a7VI (Governance and Controls) describes governance processes for acting on them. A finding-escalation process with documented management response and remediation tracking operationalizes both expectations.", "normative_force": "supervisory-guidance", "source_version": "2026-04-17", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "sox", "requirement_id": "\u00a7302 & \u00a7404", "fit": "direct", "rationale": "SOX Sections 302 and 404 require management to assess and certify the effectiveness of internal controls. Unresolved model validation findings are potential internal control deficiencies, and the finding management process provides the documentation needed for SOX deficiency assessment and disclosure.", "normative_force": "binding-law", "source_version": "2002", "reviewed_on": "2026-06-28", "basis": "asserted", "relation": "satisfies" }, { "framework": "pcaob_as_2201", "requirement_id": "\u00b6.62-.70", "fit": "partial", "rationale": "AS 2201 \u00b6.62-.70 govern the evaluation of identified control deficiencies, including severity assessment and whether deficiencies constitute material weaknesses. Validation finding escalation with documented management response is the management-side process that parallels that deficiency-evaluation discipline and supplies the auditor its inputs.", "normative_force": "certification-standard", "source_version": "2007", "reviewed_on": "2026-07-02", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "coso_icfr", "requirement_id": "Principle 17", "fit": "direct", "rationale": "COSO Principle 17 requires that internal control deficiencies be identified, communicated to those responsible for corrective action, and corrected promptly. The finding management process is the operational implementation of this principle for model risk controls.", "normative_force": "industry-framework", "source_version": "2013", "reviewed_on": "2026-06-28", "basis": "asserted", "relation": "informs" }, { "framework": "eu_ai_act", "requirement_id": "Art. 9(2)(d)", "fit": "partial", "rationale": "EU AI Act Article 9(2)(d) requires identification of risk mitigation measures and procedures for addressing residual risks. The validation finding escalation and remediation process directly addresses this requirement by ensuring identified model risks are formally tracked and mitigated.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-06-28", "basis": "anchored", "relation": "satisfies" }, { "framework": "openai_enterprise", "requirement_id": "Enterprise privacy \u2014 compliance commitments", "fit": "adjacent", "rationale": "OpenAI's enterprise privacy documentation records its compliance commitments (SOC 2 Type 2, encryption, retention controls) for enterprise customers. Institutions using OpenAI models in financial workflows can incorporate this vendor capability into validation finding escalation and remediation tracking. This is vendor capability documentation, not regulatory guidance; it covers the vendor side only.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "A2", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal A2 (Oversight of significant adverse impacts) requires defined review and oversight processes for AI systems that can cause significant adverse impact. For institutions using Azure AI services, this goal produces vendor-side governance artifacts that align with validation finding escalation and remediation tracking. The Standard is Microsoft's published internal policy offered as reference practice, not regulatory guidance.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_financial", "requirement_id": "AWS Audit Manager", "fit": "partial", "rationale": "AWS Audit Manager automates evidence collection against control frameworks for AWS workloads, and AWS CloudTrail records account-level API activity. For AWS-hosted financial AI systems, this supplies the infrastructure-layer support and evidence stream for validation finding escalation and remediation tracking. This is vendor documentation of real AWS capabilities \u2014 it does not substitute for model-layer validation or regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_financial", "requirement_id": "Vertex AI Model Registry", "fit": "partial", "rationale": "Vertex AI Model Registry provides versioned model registration, aliases, and deployment state tracking on Google Cloud. For GCP-hosted financial AI systems, this capability supplies the platform-layer support for validation finding escalation and remediation tracking. This is vendor product documentation, not regulatory guidance; it does not address model-layer regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://finance/controls/MV-07", "meta": { "authored_on": "2026-06-29", "schema_version": "1.1.0" }, "validation_objective": "The finding management system must maintain a centralized finding register where every validation finding is classified by severity within 2 business days of issuance, has an assigned owner and management response SLA, and where all Critical and High findings have documented escalation to the model risk committee within 5 business days of issuance. No model with open Critical findings may remain in production without documented senior management acceptance-of-risk on file.", "evidence_required": [ "validation_finding_register with canonical finding_id, severity classification, assigned owner, SLA due date, management response record, and remediation status for each open finding", "model_risk_committee_escalation_records showing Critical and High finding notifications with timestamps confirming escalation within 5 business days of finding issuance", "acceptance_of_risk_documentation for findings not remediated, signed at the required management level and including a residual risk acknowledgment", "monthly_open_findings_aging_report distributed to senior management showing finding age, owner assignment, and remediation progress", "finding_severity_taxonomy_document defining classification criteria and required management response SLA timelines for each severity level" ], "machine_tests": [ "Query finding register for all Critical findings \u2192 assert each has a documented model_risk_committee_escalation_timestamp within 5 business days of finding_issuance_date", "Query finding register for entries past their SLA due date \u2192 assert zero entries lack a management_response_record or acceptance_of_risk_document", "Query active model inventory for models with open Critical findings \u2192 assert each has either an accepted_risk_document signed at required management level or an active remediation plan with approved completion date", "Verify finding severity taxonomy document is current and accessible \u2192 assert all severity levels have defined SLA timelines and named escalation paths" ], "human_review": [ "Review a sample of closed findings to verify that purported remediation evidence is substantive and not merely a paper acknowledgment without underlying control changes", "Assess whether acceptance-of-risk approvals were signed at the required management level and contain genuine risk analysis rather than boilerplate language", "Verify that finding escalation records reflect actual model risk committee discussion and not only a notification receipt with no documented response" ], "blocking_effect": "requires-review", "normative_status": "supervisory-guidance", "anti_patterns": [ "Maintaining validation findings in informal channels such as email threads or shared documents without a centralized register capturing status, owner, and SLA timelines", "Closing findings upon receipt of management acknowledgment rather than verification that substantive remediation occurred and the underlying control deficiency was resolved", "Allowing model owners to self-assess and close their own validation findings without independent confirmation from the validation function", "Treating all findings as equal severity without a documented taxonomy, resulting in Critical issues receiving the same response timeline as informational observations", "Granting open-ended extensions on Critical finding remediation without re-approval at the required governance level and without updated residual risk documentation" ], "update_status": "current", "layer_code": "MV" }, { "id": "MV-08", "layer": "MV", "plane": "both", "name": "Model Validation Evidence Package", "plain": "The validation function must compile and maintain a structured evidence package for each validated model demonstrating that validation was independent, comprehensive, and effective across all MV layer controls, and that this package is available for regulatory examination, internal audit, and senior management review.", "threat": { "tags": [ "evidence-fragmentation", "examination-readiness-gap", "validation-integrity-repudiation", "governance-documentation-failure" ], "desc": "Without a consolidated evidence package, validation activities are invisible to regulators, auditors, and senior management. Fragmented documentation across emails, shared drives, and tribal knowledge cannot withstand regulatory examination. When model failures occur, the absence of structured evidence makes it impossible to demonstrate that adequate validation was performed, exposing the institution to enforcement action and reputational risk." }, "standard": [ { "id": "sr26_2", "section": "\u00a7VI (Documentation)", "title": "Documentation of validation" }, { "id": "sox", "section": "\u00a7302 & \u00a7404", "title": "Documentation of internal control effectiveness" }, { "id": "pcaob_as_2201", "section": "\u00b6.46", "title": "Risk-based evidence for ICFR documentation" }, { "id": "eu_ai_act", "section": "Art. 11 & 18", "title": "Technical documentation and record-keeping obligations" } ], "sources": [ { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Anthropic's Responsible Scaling Policy v3.3 documents the vendor's capability thresholds and safeguards, cited as third-party AI due diligence context for the apeiris://finance/controls/MV-08 Model Validation Evidence Package control.", "reviewed_on": "2026-07-02" }, { "id": "openai_enterprise_data_governance_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "OpenAI's enterprise privacy and compliance documentation records vendor-side data handling and audit-log capabilities relevant to the apeiris://finance/controls/MV-08 Model Validation Evidence Package control.", "reviewed_on": "2026-07-02" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://finance/controls/MV-08 Model Validation Evidence Package control.", "reviewed_on": "2026-07-01" }, { "id": "aws_financial_services_compliance_2024", "title": "AWS User Guide to Financial Services Regulations & Guidelines in the United States", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/financial-services/security-compliance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_financial_services_compliance_2024", "relationship": "informative_reference", "rationale": "AWS's financial services regulatory guide and compliance tooling document infrastructure-layer capabilities relevant to the apeiris://finance/controls/MV-08 Model Validation Evidence Package control.", "reviewed_on": "2026-07-02" }, { "id": "google_cloud_financial_services_ai_2024", "title": "Google Cloud Explainable AI", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/explainable-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_financial_services_ai_2024", "relationship": "informative_reference", "rationale": "Google Cloud's Explainable AI and Vertex AI model governance documentation describes platform capabilities relevant to the apeiris://finance/controls/MV-08 Model Validation Evidence Package control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Standardized model validation evidence package template covering MV-01 through MV-07 artifacts, stored in a versioned document management system with access controls, retention policy, and a signed attestation page certifying completeness and independence.", "steps": [ "Define a model validation evidence package template listing required artifacts from each MV-layer control, including the independence charter excerpt, conceptual soundness opinion, backtesting results, challenger comparison, frequency schedule entry, adapted methodology checklist, and findings register extract.", "Store all evidence packages in a versioned document management system with role-based access controls preventing modification by model owners.", "Require the validation lead to sign an attestation page certifying that the package is complete, that validation was conducted independently, and that findings are accurately represented.", "Establish a retention policy of at least 7 years for validation evidence packages, aligned with regulatory examination lookback periods.", "Produce a validation evidence index for each model that maps package contents to SR 26-2 documentation expectations and SOX 404 and EU AI Act requirements for examination responses." ], "model_risk_officer": { "summary": "The evidence package is the definitive record of validation activity. It must be maintained in a state ready for regulatory examination at all times, not assembled retrospectively when an examination is announced.", "actions": [ "Review evidence package completeness for all Tier 1 models quarterly.", "Require package completion within 10 business days of each validation report finalization.", "Ensure evidence packages are stored with access controls that prevent modification by model owners." ], "failure_signals": [ "Evidence packages assembled retrospectively after an examination notice is received.", "Packages that reference artifacts not actually on file in the document management system.", "Evidence packages not updated following material model changes or re-validation." ] }, "financial_controller": { "summary": "For financial reporting models, the validation evidence package is a supporting document for SOX 404 management assertions. The controller must ensure packages for in-scope models are complete and accessible.", "actions": [ "Confirm that validation evidence packages exist for all models supporting material financial statement estimates.", "Review the attestation page for financial reporting model packages as part of the SOX 404 assessment.", "Request evidence package index reports prior to each annual audit cycle." ], "failure_signals": [ "Financial reporting model validation packages missing or incomplete at the start of the SOX 404 assessment cycle.", "Attestation pages unsigned or signed by personnel with conflicts of interest.", "External auditors unable to locate requested validation evidence during ICFR testing." ] }, "compliance_officer": { "summary": "SR 26-2 describes documentation of validation activities as part of governance and controls. EU AI Act Article 11 imposes technical documentation obligations. The evidence package is the primary artifact for satisfying both requirements.", "actions": [ "Review the evidence package template annually against SR 26-2 documentation expectations and EU AI Act and SOX requirements.", "Confirm that evidence packages for EU AI Act high-risk AI systems include all Article 11 technical documentation elements.", "Produce an evidence package inventory report for the model risk committee quarterly." ], "metrics": [ "Evidence package completeness rate: 100% of Tier 1 models have current packages on file.", "Average days from validation completion to package finalization: target \u226410 business days.", "Packages with signed attestation page: 100%." ], "failure_signals": [ "Evidence packages missing for any Tier 1 model.", "Packages older than the model's required re-validation interval.", "Supervisory criticism citing inadequate validation documentation." ] }, "internal_audit": { "summary": "Audit must independently verify that evidence packages accurately represent validation activities and that the contents match the documentation in the underlying systems of record.", "actions": [ "Select a sample of evidence packages and test that each referenced artifact is present, dated, and unmodified.", "Verify that the attestation page was signed by a validator with no organizational conflict of interest.", "Confirm that the document management system's access control logs show no unauthorized modifications to evidence packages." ], "failure_signals": [ "Evidence package artifacts that differ from the versions in underlying systems of record.", "Attestation pages signed by personnel who had a development role on the validated model.", "Access control logs showing evidence package modifications by model owners." ] }, "it_operations": { "summary": "IT operations must maintain the document management infrastructure hosting validation evidence packages, including access controls, version control, audit logging, and retention enforcement.", "actions": [ "Configure the document management system with role-based access controls that prohibit modification by model owners.", "Implement retention policies of at least 7 years for validation evidence packages with automated enforcement.", "Maintain audit logs of all access and modification events for evidence packages, retained for at least 3 years." ], "failure_signals": [ "Document management system without role-based access controls separating model owners from validation artifacts.", "Retention policies not configured or manually bypassable.", "Audit log gaps for evidence package access events." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Validation documentation exists in most institutions but is rarely compiled into examination-ready structured packages with complete artifact linkage." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "federated-enterprise" ], "implementers": [ "Model Risk Officer", "Validation Team", "IT Operations" ], "frameworks": [ { "framework": "sr26_2", "requirement_id": "\u00a7VI (Documentation)", "fit": "direct", "rationale": "SR 26-2 \u00a7VI addresses documentation under its Documentation subheading \u2014 validation work documented in enough detail for a knowledgeable third party to understand its scope, findings, and conclusions. The validation evidence package implements that documentation standard.", "normative_force": "supervisory-guidance", "source_version": "2026-04-17", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "eu_ai_act", "requirement_id": "Art. 11 & 18", "fit": "direct", "rationale": "EU AI Act Articles 11 and 18 impose mandatory technical documentation and record-keeping obligations for high-risk AI systems throughout their lifecycle. The validation evidence package provides the structured documentation framework required to satisfy these obligations for financial AI.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-06-28", "basis": "anchored", "relation": "satisfies" }, { "framework": "sox", "requirement_id": "\u00a7302 & \u00a7404", "fit": "direct", "rationale": "SOX Sections 302 and 404 require management to document the basis for their assertions about internal control effectiveness. For model-dependent financial reporting processes, the validation evidence package is the primary supporting document for these assertions.", "normative_force": "binding-law", "source_version": "2002", "reviewed_on": "2026-06-28", "basis": "asserted", "relation": "satisfies" }, { "framework": "pcaob_as_2201", "requirement_id": "\u00b6.46", "fit": "direct", "rationale": "AS 2201 \u00b6.46 ties the evidence the auditor needs to the risk associated with the control being tested. Validation evidence packages for models feeding financial reporting give the auditor the risk-proportionate evidence base \u00b6.46 contemplates for model-dependent controls.", "normative_force": "certification-standard", "source_version": "2007", "reviewed_on": "2026-07-02", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "bcbs_239", "requirement_id": "Principle 11", "fit": "partial", "rationale": "BCBS 239 Principle 11 (Distribution) requires reports to reach the relevant parties while ensuring confidentiality. The validation evidence package is the distributable artifact through which validation results reach management, audit, and supervisors under access control; the fit is partial.", "normative_force": "supervisory-guidance", "source_version": "2013", "reviewed_on": "2026-07-02", "basis": "asserted", "relation": "satisfies" }, { "framework": "soc2", "requirement_id": "CC2.2", "fit": "partial", "rationale": "SOC 2 CC2.2 requires the entity to internally communicate information, including objectives and responsibilities for internal control. The validation evidence package is the internal communication vehicle through which validation results and responsibilities reach management and oversight functions.", "normative_force": "certification-standard", "source_version": "2022", "reviewed_on": "2026-07-02", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "openai_enterprise", "requirement_id": "Enterprise Compliance API \u2014 audit logs", "fit": "partial", "rationale": "ChatGPT Enterprise and the OpenAI API expose workspace audit-log data through the Compliance API and audit logs endpoint, exportable to SIEM and evidence stores. Institutions using OpenAI models in financial workflows can incorporate this vendor capability into the model validation evidence package. This is vendor capability documentation, not regulatory guidance; it covers the vendor side only.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "T2", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal T2 (Communication to stakeholders) requires communicating system capabilities and limitations to stakeholders. For institutions using Azure AI services, this goal produces vendor-side governance artifacts that align with the model validation evidence package. The Standard is Microsoft's published internal policy offered as reference practice, not regulatory guidance.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_financial", "requirement_id": "AWS Artifact", "fit": "partial", "rationale": "AWS Artifact provides on-demand access to AWS's third-party compliance reports (SOC 1/2, PCI DSS, ISO). For AWS-hosted financial AI systems, this supplies the infrastructure-layer support and evidence stream for the model validation evidence package. This is vendor documentation of real AWS capabilities \u2014 it does not substitute for model-layer validation or regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_financial", "requirement_id": "Model Cards", "fit": "partial", "rationale": "Model Cards provide structured, versioned documentation of a model's purpose, performance characteristics, and limitations. For GCP-hosted financial AI systems, this capability supplies the platform-layer support for the model validation evidence package. This is vendor product documentation, not regulatory guidance; it does not address model-layer regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://finance/controls/MV-08", "meta": { "authored_on": "2026-06-29", "schema_version": "1.1.0" }, "validation_objective": "A complete, structured evidence package must exist for each validated model demonstrating that validation was independent, comprehensive, and effective across all MV layer controls. The package must be assembled and retrievable within 24 hours for a regulatory examination request, and a completeness certification signed by the lead validator must confirm that no required MV layer controls were excluded without documented rationale.", "evidence_required": [ "model_validation_evidence_package_index listing all constituent artifacts, per-artifact SHA-256 hashes, and a completeness_certification signed by the lead validator", "independence_confirmation_record establishing that validators had no material involvement in model development and no reporting relationship with model owners during the validation period", "validation_scope_checklist confirming all MV layer controls were addressed, with documented rationale for any controls excluded or scoped out", "examination_readiness_drill_record showing the package was assembled and retrieved within a 24-hour SLA during a simulated regulatory request exercise", "senior_management_distribution_log confirming the evidence package summary was delivered to the model risk committee and appropriate senior stakeholders within the required timeframe" ], "machine_tests": [ "Query model inventory for each model in production status \u2192 assert a corresponding validation_evidence_package record exists with completeness_status of 'complete' and a validator_sign_off_timestamp", "Retrieve a sample validation evidence package \u2192 assert all required sections are present: independence declaration, scope checklist, findings register, performance benchmarks, and ongoing monitoring plan", "Hash all artifacts in a sample evidence package \u2192 assert stored hashes in the package index match current artifact hashes, confirming no post-validation modification of evidence", "Query evidence package retrieval log \u2192 assert at least one retrieval drill has been performed in the preceding 12 months with documented SLA compliance" ], "human_review": [ "Review the independence declaration for a sample of validators to assess whether any material conflicts of interest exist that should have disqualified them from the validation engagement", "Assess the validation scope checklist for any control exclusions to verify that exclusion rationale is substantive and not a mechanism for avoiding difficult assessments", "Verify that the assembled evidence package would satisfy a regulatory examiner's request without requiring supplemental documentation to be created post-hoc" ], "blocking_effect": "blocks-deployment", "normative_status": "supervisory-guidance", "anti_patterns": [ "Assembling the validation evidence package retroactively during examination preparation rather than as a concurrent output of the validation process itself", "Storing validation artifacts across disconnected locations such as email, local drives, and shared folders without a centralized indexed package that can be retrieved as a single unit", "Signing off on a validation evidence package before all MV layer controls have been addressed, treating the package as a documentation exercise rather than a deployment completeness gate", "Allowing validators who contributed substantively to model development to compile the evidence package, compromising the independence attestation", "Omitting artifact hashes from the package index, making post-validation modification of evidence undetectable during regulatory examination" ], "update_status": "current", "layer_code": "MV" }, { "id": "FD-01", "layer": "FD", "plane": "control", "name": "AI-Driven Decision Transparency and Auditability", "plain": "Every AI-driven financial decision must be explainable, auditable, and traceable to the specific inputs, model version, and logic that produced it, with records retained for the period required by applicable financial regulation.", "threat": { "tags": [ "black-box-decision", "audit-trail-gap", "regulatory-opacity", "unexplainable-outcome" ], "desc": "AI models that produce financial decisions without traceable reasoning expose institutions to regulatory censure, consumer litigation, and inability to respond to examiner inquiries. When a decision cannot be reconstructed from retained artifacts, the institution cannot demonstrate it was lawful, fair, or consistent with its stated policies." }, "standard": [ { "id": "sox", "section": "Section 302", "title": "CEO/CFO certification of internal control effectiveness" }, { "id": "eu_ai_act", "section": "Art. 13", "title": "Transparency and provision of information to deployers" }, { "id": "bcbs_239", "section": "Principle 2", "title": "Data architecture and IT infrastructure" } ], "sources": [ { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Anthropic's Responsible Scaling Policy v3.3 documents the vendor's capability thresholds and safeguards, cited as third-party AI due diligence context for the apeiris://finance/controls/FD-01 AI-Driven Decision Transparency and Auditability control.", "reviewed_on": "2026-07-02" }, { "id": "openai_enterprise_data_governance_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "OpenAI's enterprise privacy and compliance documentation records vendor-side data handling and audit-log capabilities relevant to the apeiris://finance/controls/FD-01 AI-Driven Decision Transparency and Auditability control.", "reviewed_on": "2026-07-02" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://finance/controls/FD-01 AI-Driven Decision Transparency and Auditability control.", "reviewed_on": "2026-07-01" }, { "id": "aws_financial_services_compliance_2024", "title": "AWS User Guide to Financial Services Regulations & Guidelines in the United States", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/financial-services/security-compliance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_financial_services_compliance_2024", "relationship": "informative_reference", "rationale": "AWS's financial services regulatory guide and compliance tooling document infrastructure-layer capabilities relevant to the apeiris://finance/controls/FD-01 AI-Driven Decision Transparency and Auditability control.", "reviewed_on": "2026-07-02" }, { "id": "google_cloud_financial_services_ai_2024", "title": "Google Cloud Explainable AI", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/explainable-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_financial_services_ai_2024", "relationship": "informative_reference", "rationale": "Google Cloud's Explainable AI and Vertex AI model governance documentation describes platform capabilities relevant to the apeiris://finance/controls/FD-01 AI-Driven Decision Transparency and Auditability control.", "reviewed_on": "2026-07-02" }, { "id": "okta_financial_services_access_2025", "title": "Okta for Financial Services", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://www.okta.com/solutions/financial-services/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_financial_services_access_2025", "relationship": "informative_reference", "rationale": "Okta's identity products (System Log, access management, Adaptive MFA, Privileged Access) supply identity-layer enforcement and evidence relevant to the apeiris://finance/controls/FD-01 AI-Driven Decision Transparency and Auditability control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Decision-level audit log captured at inference time, including model version hash, input feature vector, output score, decision threshold, and the human-readable rationale string. Logs stored immutably with tamper-evident hashing and linked to downstream action records.", "steps": [ "Instrument every AI inference endpoint to emit a structured decision record (model_id, version_hash, input_hash, output_score, threshold, timestamp, decision_id) to an append-only log store.", "Generate a human-readable rationale summary for each decision using a standardized explainability method (SHAP, LIME, or rule extraction) and attach it to the decision record.", "Implement a decision replay API that allows examiners or internal auditors to reconstruct any decision from retained artifacts without requiring access to live production systems.", "Enforce retention of decision records for the longer of seven years or the applicable regulatory retention period, with quarterly integrity verification of the log store." ], "financial_controller": { "summary": "Decision audit trails are a financial reporting control: they substantiate that AI-driven transactions and credit decisions were executed under documented, authorized logic consistent with financial statements.", "actions": [ "Confirm that decision log retention periods align with SOX Section 802 document retention requirements.", "Review quarterly reports on decision audit coverage rate and escalate gaps to the Chief Risk Officer.", "Include AI decision auditability status in the annual ICFR assessment narrative." ], "failure_signals": [ "Decision audit coverage below 100% for any regulated product line.", "Replay API unavailable during examiner request windows.", "Log integrity verification failures in any quarter." ] }, "model_risk_officer": { "summary": "Traceability to model version and input features is the foundation of model risk management \u2014 without it, outcomes monitoring and validation are impossible.", "actions": [ "Require model deployment packages to include the explainability method specification as a mandatory artifact.", "Validate that decision logs capture the full input feature vector, not just the output score, to enable retroactive analysis.", "Include decision log completeness in model performance monitoring dashboards reviewed at model risk committee meetings." ], "failure_signals": [ "Model version hash in decision log does not match the validated model registry entry.", "Input feature vectors missing or truncated in more than 0.1% of decision records.", "Explainability method not documented for any production model." ] }, "compliance_officer": { "summary": "Regulatory examiners expect to receive a complete decision record for any individual transaction on request; the institution must be able to produce it within the examiner's timeline.", "actions": [ "Establish a documented examiner-response procedure specifying how decision records are retrieved and formatted for regulatory production.", "Test the decision replay API quarterly by randomly sampling 25 decisions and verifying that reconstructed outputs match original records.", "Confirm that the human-readable rationale string satisfies the specificity requirements of applicable adverse action notice rules." ], "metrics": [ "Decision audit coverage rate: target 100% across all regulated product lines.", "Examiner request fulfillment time: target under 48 hours for individual decision records.", "Quarterly replay test pass rate: target 100%." ], "failure_signals": [ "Any decision record irretrievable within 48 hours of examiner request.", "Rationale strings flagged as insufficiently specific in a consumer complaint or examination finding.", "Replay test failure rate above 0% in any quarter." ] }, "internal_audit": { "summary": "Internal audit must independently verify that the decision audit log is complete, tamper-evident, and capable of supporting regulatory production without operational dependency on the AI team.", "actions": [ "Sample 50 decisions per regulated product per audit cycle and verify that each record contains all required fields.", "Attempt independent replay of sampled decisions using only retained artifacts and confirm output consistency.", "Test log immutability by attempting an authorized write to a historical record and confirming the control prevents modification." ], "failure_signals": [ "Any sampled decision missing required fields.", "Replay inconsistency in any sampled decision.", "Log immutability control bypassed during penetration test." ] }, "it_operations": { "summary": "IT Operations runs decision logging pipelines behind decision-level audit trails for AI-driven financial decisions \u2014 integrating it with deployment pipelines, enforcing the automated gates, and keeping the supporting data flows reliable and auditable.", "actions": [ "Integrate decision logging pipelines with CI/CD and runtime tooling so that every AI financial decision writes a complete, immutable log record before the decision takes effect.", "Automate collection and retention of decision-level audit records in immutable, hash-verified storage.", "Monitor pipeline and integration health and alert when decision log write failures or coverage gaps appear." ], "failure_signals": [ "Production changes bypass the automated gate so that it is no longer true that every AI financial decision writes a complete, immutable log record before the decision takes effect.", "Gaps or outages in decision-level audit records collection exceeding 24 hours.", "Manual, untracked edits to decision logging pipelines records." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Most institutions have model-level documentation but lack decision-level audit trails with replay capability." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "Model Risk Management", "Compliance", "Data Engineering", "Internal Audit" ], "frameworks": [ { "framework": "sox", "requirement_id": "Section 302", "fit": "direct", "rationale": "SOX Section 302 requires officers to certify the effectiveness of disclosure controls including those governing AI-driven financial decisions. Traceable audit trails are the evidentiary foundation for that certification.", "normative_force": "binding-law", "source_version": "2002", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "satisfies" }, { "framework": "eu_ai_act", "requirement_id": "Art. 13", "fit": "direct", "rationale": "EU AI Act Article 13 requires high-risk AI systems used in credit and financial decisions to be transparent, with sufficient information provided to deployers to enable them to interpret outputs and exercise appropriate oversight. Decision-level logging and replay capability satisfy this requirement.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "bcbs_239", "requirement_id": "Principle 2", "fit": "partial", "rationale": "BCBS 239 Principle 2 (Data architecture and IT infrastructure) requires data architecture with clear ownership and documented flows. Decision-level audit trails are a data-architecture artifact: they record the lineage from inputs through model version to decision output, which is the traceability BCBS 239's architecture expectations point at; the fit is partial.", "normative_force": "supervisory-guidance", "source_version": "2013", "reviewed_on": "2026-07-02", "basis": "asserted", "relation": "satisfies" }, { "framework": "coso_icfr", "requirement_id": "Component 3 \u2014 Control Activities", "fit": "direct", "rationale": "COSO ICIF 2013 requires control activities that ensure management directives are carried out. Decision audit trails are the control activity ensuring AI systems execute only authorized, documented logic and that execution is verifiable.", "normative_force": "industry-framework", "source_version": "2013", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "informs" }, { "framework": "openai_enterprise", "requirement_id": "Enterprise Compliance API \u2014 audit logs", "fit": "partial", "rationale": "ChatGPT Enterprise and the OpenAI API expose workspace audit-log data through the Compliance API and audit logs endpoint, exportable to SIEM and evidence stores. Institutions using OpenAI models in financial workflows can incorporate this vendor capability into decision-level audit trails for AI-driven financial decisions. This is vendor capability documentation, not regulatory guidance; it covers the vendor side only.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "T1", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal T1 (System intelligibility for decision making) requires that systems supporting consequential decisions about people be designed so stakeholders can interpret system behavior. For institutions using Azure AI services, this goal produces vendor-side governance artifacts that align with decision-level audit trails for AI-driven financial decisions. The Standard is Microsoft's published internal policy offered as reference practice, not regulatory guidance.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_financial", "requirement_id": "AWS CloudTrail", "fit": "partial", "rationale": "AWS CloudTrail records API activity across AWS accounts with actor, action, and timestamp detail, exportable for retention and analysis. For AWS-hosted financial AI systems, this supplies the infrastructure-layer support and evidence stream for decision-level audit trails for AI-driven financial decisions. This is vendor documentation of real AWS capabilities \u2014 it does not substitute for model-layer validation or regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_financial", "requirement_id": "Explainable AI", "fit": "partial", "rationale": "Google Cloud's Explainable AI documentation (cloud.google.com/explainable-ai) describes feature attribution and explanation tooling available through Vertex AI. For GCP-hosted financial AI systems, this capability supplies the platform-layer support for decision-level audit trails for AI-driven financial decisions. This is vendor product documentation, not regulatory guidance; it does not address model-layer regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "okta_financial", "requirement_id": "Okta System Log", "fit": "adjacent", "rationale": "The Okta System Log records authentication and access events with actor, target, outcome, and timestamp detail, exportable for audit retention. Where access to financial AI systems is brokered through Okta, this capability supplies the identity-layer enforcement and evidence for decision-level audit trails for AI-driven financial decisions. This is vendor product documentation, not a financial-services control framework.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://finance/controls/FD-01", "meta": { "authored_on": "2026-06-29", "schema_version": "1.1.0" }, "validation_objective": "Every AI-driven financial decision must generate a decision audit record at execution time capturing the model_id, model_version, complete input feature set hash, output value, confidence score, and a decision rationale reference sufficient to reconstruct the decision logic. These records must be retained for the period required by applicable financial regulation and must be retrievable within the timeframes required for regulatory examination, litigation hold, and consumer dispute resolution.", "evidence_required": [ "decision_audit_log entries for each AI-driven financial decision containing model_id, model_version, decision_timestamp, input_features_hash, output_value, confidence_score, and decision_rationale_reference", "retention_policy_document specifying retention periods by decision type mapped to applicable regulatory requirements including ECOA, SOX, and applicable state statutes", "decision_retrieval_drill_record demonstrating that individual decision records can be retrieved by decision_id within the required response timeframe under simulated examination conditions", "model_version_registry confirming that every model_version referenced in decision audit records corresponds to a documented and validated model artifact" ], "machine_tests": [ "Trigger a sample AI-driven financial decision \u2192 assert a decision_audit_record is created within 1 second with all required fields populated: model_id, model_version, timestamp, input_features_hash, output_value, and decision_rationale_reference", "Query decision audit log for records approaching the retention threshold \u2192 assert no records have been purged or modified before their retention period has elapsed", "Retrieve a decision record by decision_id \u2192 assert response latency is under 30 seconds and the record contains sufficient detail to reconstruct the decision without requesting supplemental context", "Attempt to execute an AI financial decision with audit logging disabled or bypassed \u2192 assert the request is rejected before execution and an operations alert is raised" ], "human_review": [ "Review a sample of decision audit records to assess whether the captured rationale is sufficient to explain the decision to a regulator, auditor, or affected consumer without supplemental documentation", "Verify that the retention policy maps to each applicable regulatory requirement and has been reviewed by legal counsel within the past 12 months", "Assess the decision retrieval process to confirm it can support concurrent requests during examination activity without degraded performance or queue delays" ], "blocking_effect": "blocks-runtime-action", "normative_status": "supervisory-guidance", "anti_patterns": [ "Logging only the final model output without capturing the specific input features and model version used, making post-hoc decision reconstruction impossible", "Storing decision audit records in the same mutable system as the model output, allowing simultaneous modification of both the decision and its audit trail", "Applying uniform retention periods to all decision types without mapping to the specific regulatory retention requirement for each decision category", "Treating explainability as a post-hoc capability to be generated on demand rather than capturing decision rationale as a durable artifact at execution time", "Excluding from audit logging AI decisions framed as recommendations to a human approver when the AI output is the effective determinant of the consumer outcome" ], "update_status": "current", "layer_code": "FD" }, { "id": "FD-02", "layer": "FD", "plane": "control", "name": "ECOA/Reg B Adverse Action Notice for AI Decisions", "plain": "When an AI model is the primary decision-maker in a credit determination resulting in denial, counterproductive terms, or incomplete application, the institution must generate a legally compliant adverse action notice that identifies the specific, principal reasons for the AI decision in plain language.", "threat": { "tags": [ "adverse-action-deficiency", "regulatory-violation", "fair-credit-noncompliance", "unexplained-denial" ], "desc": "ECOA and Regulation B require that applicants denied credit or offered less favorable terms receive written notice of the specific principal reasons within prescribed timeframes. AI models that produce composite scores without mapped reason codes fail this requirement. Institutions that issue generic or technically inaccurate adverse action reasons face CFPB enforcement, private litigation under ECOA's actual and punitive damages provisions, and CRA examination downgrades. The absence of a machine-readable reason-code mapping from AI model outputs to ECOA-compliant reasons is the most common compliance gap in AI-driven credit origination." }, "standard": [ { "id": "eu_ai_act", "section": "Art. 86", "title": "Right to explanation for individual decision-making" }, { "id": "coso_icfr", "section": "Component 2", "title": "Risk Assessment \u2014 identifying compliance risk" } ], "sources": [ { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://finance/controls/FD-02 ECOA/Reg B Adverse Action Notice for AI Decisions control.", "reviewed_on": "2026-07-01" }, { "id": "openai_enterprise_data_governance_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "OpenAI's enterprise privacy and compliance documentation records vendor-side data handling and audit-log capabilities relevant to the apeiris://finance/controls/FD-02 ECOA/Reg B Adverse Action Notice for AI Decisions control.", "reviewed_on": "2026-07-02" }, { "id": "aws_financial_services_compliance_2024", "title": "AWS User Guide to Financial Services Regulations & Guidelines in the United States", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/financial-services/security-compliance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_financial_services_compliance_2024", "relationship": "informative_reference", "rationale": "AWS's financial services regulatory guide and compliance tooling document infrastructure-layer capabilities relevant to the apeiris://finance/controls/FD-02 ECOA/Reg B Adverse Action Notice for AI Decisions control.", "reviewed_on": "2026-07-02" }, { "id": "google_cloud_financial_services_ai_2024", "title": "Google Cloud Explainable AI", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/explainable-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_financial_services_ai_2024", "relationship": "informative_reference", "rationale": "Google Cloud's Explainable AI and Vertex AI model governance documentation describes platform capabilities relevant to the apeiris://finance/controls/FD-02 ECOA/Reg B Adverse Action Notice for AI Decisions control.", "reviewed_on": "2026-07-02" }, { "id": "cfpb_adverse_action_2022", "title": "Consumer Financial Protection Circular 2022-03 \u2014 Adverse action notification requirements in connection with credit decisions based on complex algorithms", "authority": "Consumer Financial Protection Bureau (CFPB)", "source_type": "guidance", "normative_force": "supervisory-guidance", "version": "2022-03", "published_on": "2022-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.consumerfinance.gov/compliance/circulars/circular-2022-03-adverse-action-notification-requirements-in-connection-with-credit-decisions-based-on-complex-algorithms/", "license": "public-domain", "status": "current", "flagship": false, "source_id": "cfpb_adverse_action_2022", "relationship": "supporting_guidance", "rationale": "CFPB Circular 2022-03 confirms ECOA/Regulation B adverse action notice duties apply to credit decisions based on complex algorithms, informing the apeiris://finance/controls/FD-02 ECOA/Reg B Adverse Action Notice for AI Decisions control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Reason-code mapping layer sits between the AI model output layer and the adverse action notice generation system. The mapping translates model feature contributions (SHAP values or equivalent) into a ranked list of ECOA-approved reason codes, selects the top four, and passes them to the notice template. All mappings are validated by compliance counsel and versioned with the model.", "steps": [ "Build a reason-code mapping library that translates the top contributing features from the AI model's explainability output into ECOA/Reg B-approved adverse action reason codes, updated whenever the model is retrained.", "Implement a notice generation service that ingests the ranked reason codes, applicant information, and decision record, and produces a Regulation B-compliant notice with the required disclosure elements (creditor name, ECOA notice, reasons, date) within the statutory 30-day window.", "Establish a quality-assurance review workflow in which a compliance analyst reviews a random sample of 5% of AI-generated adverse action notices monthly for accuracy, specificity, and legal sufficiency.", "Maintain a complete log of all adverse action notices issued, linked to the underlying decision record, for the two-year retention period required by Regulation B \u00a7 202.12." ], "financial_controller": { "summary": "ECOA adverse action notice deficiencies are a contingent liability that must be assessed as part of ICFR; systemic deficiencies may require accrual of litigation reserves and disclosure in financial filings.", "actions": [ "Confirm that the adverse action notice control is included in the Regulation B compliance control inventory reviewed annually under ICFR.", "Request a summary of QA review findings and any consumer complaints related to adverse action notice adequacy each quarter.", "Assess whether any adverse action class action exposure requires disclosure under ASC 450 loss contingency standards." ], "failure_signals": [ "QA review identifying more than 1% of notices with legally deficient reason codes.", "CFPB examination finding related to adverse action notice adequacy.", "Consumer litigation filed alleging ECOA adverse action violations." ] }, "compliance_officer": { "summary": "The compliance officer owns the Regulation B adverse action program and is responsible for ensuring the AI reason-code mapping is accurate, current, and produces notices that satisfy the specificity standard under official CFPB commentary.", "actions": [ "Review and approve the reason-code mapping library before each model deployment; document approval in the model change log.", "Conduct monthly QA sampling of AI-generated notices and report findings to the fair lending committee.", "Maintain a remediation log for any notices identified as deficient and confirm corrective re-notice is issued within the regulatory cure period." ], "metrics": [ "Adverse action notice legal sufficiency rate: target 100% on QA sampling.", "Notice issuance timeliness: target 100% within 30 days of adverse decision.", "Reason-code mapping version lag: target zero \u2014 mapping updated with every model version." ], "failure_signals": [ "Any notice issued beyond the 30-day Regulation B deadline.", "Reason-code mapping not updated within 10 business days of model retraining.", "QA sufficiency rate below 99% in any month." ] }, "model_risk_officer": { "summary": "The reason-code mapping is a model output artifact subject to independent validation; its accuracy directly determines whether the institution's adverse action program is compliant.", "actions": [ "Include reason-code mapping accuracy in the scope of each model validation, testing whether the top-ranked SHAP features align logically with the mapped reason codes.", "Require model developers to provide a compliance attestation that the reason-code mapping was reviewed by legal counsel before each production deployment.", "Monitor for model drift that could cause previously validated reason-code mappings to misrepresent the actual driving factors in adverse decisions." ], "failure_signals": [ "Validation finding that reason codes do not correspond to actual top model contributors.", "Model drift detected without a corresponding review of the reason-code mapping.", "Reason-code mapping not included in model documentation package." ] }, "it_operations": { "summary": "The notice generation service is a regulatory-critical system requiring high availability, version-controlled configuration, and an audit trail of every notice issued.", "actions": [ "Deploy the notice generation service with 99.9% availability SLA and automated failover.", "Version-lock the reason-code mapping configuration to the model version identifier so that a mapping rollback is automatically triggered on model rollback.", "Implement access controls ensuring that only the compliance-approved mapping configuration is used in production, with change approvals required for any modification." ], "failure_signals": [ "Notice generation service downtime causing notices to miss the 30-day statutory window.", "Configuration drift between production mapping and compliance-approved version.", "Unauthorized modification to the reason-code mapping library." ] }, "internal_audit": { "summary": "Internal audit verifies that adverse action notices for AI decisions are accurate, specific, and traceable to the models that produced the decisions.", "actions": [ "Sample adverse action notices and trace reason codes back to model factors and decision records.", "Test notice timeliness and content against Regulation B requirements.", "Verify the reason-code mapping is versioned and matched to deployed model versions." ], "failure_signals": [ "Notices with reason codes that do not correspond to actual model drivers.", "Reason-code mapping out of sync with the deployed model version.", "Notice timeliness breaches concentrated in AI-decisioned applications." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Many institutions using AI for credit origination have not yet built a validated reason-code mapping layer and rely on generic codes that regulators have found insufficient." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "federated-enterprise" ], "implementers": [ "Compliance", "Model Risk Management", "Credit Technology", "Legal" ], "frameworks": [ { "framework": "eu_ai_act", "requirement_id": "Art. 86", "fit": "direct", "rationale": "Article 86 of the EU AI Act establishes the right to explanation for AI-driven decisions significantly affecting persons, specifically including creditworthiness assessments. The adverse action notice control operationalizes this right in the US context, and Article 86 provides the comparable EU obligation.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "coso_icfr", "requirement_id": "Component 2 \u2014 Risk Assessment", "fit": "direct", "rationale": "COSO requires organizations to identify and assess risks to achieving compliance objectives. Adverse action notice deficiency is a high-impact, high-likelihood compliance risk for AI-driven credit programs that must be assessed and controlled under the ICFR framework.", "normative_force": "industry-framework", "source_version": "2013", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "F1, F2", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Fairness Goals F1 and F2 require similar quality of service and minimized allocation disparities across identified demographic groups. For institutions using Azure AI services, this goal produces vendor-side governance artifacts that align with ECOA/Regulation B adverse action notices for AI credit decisions. The Standard is Microsoft's published internal policy offered as reference practice, not regulatory guidance.", "normative_force": "best-practice", "source_version": "2022", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_financial", "requirement_id": "AWS User Guide to Financial Services Regulations & Guidelines in the United States", "fit": "partial", "rationale": "The 'AWS User Guide to Financial Services Regulations & Guidelines in the United States' whitepaper maps AWS services and shared-responsibility considerations to US financial regulatory expectations. For AWS-hosted financial AI systems, this supplies the infrastructure-layer support and evidence stream for ECOA/Regulation B adverse action notices for AI credit decisions. This is vendor documentation of real AWS capabilities \u2014 it does not substitute for model-layer validation or regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_financial", "requirement_id": "Explainable AI", "fit": "partial", "rationale": "Google Cloud's Explainable AI documentation (cloud.google.com/explainable-ai) describes feature attribution and explanation tooling available through Vertex AI. For GCP-hosted financial AI systems, this capability supplies the platform-layer support for ECOA/Regulation B adverse action notices for AI credit decisions. This is vendor product documentation, not regulatory guidance; it does not address model-layer regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "cfpb_ai", "requirement_id": "Circular 2022-03 \u2014 adverse action for credit decisions based on complex algorithms", "fit": "direct", "rationale": "CFPB Circular 2022-03 confirms that ECOA and Regulation B adverse action notice requirements apply in full when creditors use complex algorithms: creditors must provide specific and accurate reasons for adverse actions and cannot invoke model complexity as a defense. Circular 2023-03 adds that reasons may not be limited to the sample-form checklist. FD-02's reason-code mapping is the artifact that satisfies those expectations for AI credit decisions.", "normative_force": "supervisory-guidance", "source_version": "2022-03", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" } ], "canonical_id": "apeiris://finance/controls/FD-02", "meta": { "authored_on": "2026-06-29", "schema_version": "1.1.0" }, "validation_objective": "When an AI model issues a credit denial, counter-offer, or incomplete application determination, the system must automatically generate an adverse action notice identifying the specific principal reasons for the AI decision in plain language, satisfying the requirements of 12 CFR Part 202 (Regulation B), and delivered to the applicant within the required regulatory timeframe. Each notice must be traceable to the specific decision_id and model_version that generated it.", "evidence_required": [ "adverse_action_notice_generation_log linking each notice to its decision_id, model_version, principal_reasons_list, generation_timestamp, and delivery_timestamp", "reason_code_mapping_document showing how AI model feature importance outputs are translated into legally compliant Regulation B principal reason codes, reviewed by compliance or legal counsel", "delivery_confirmation_record for each notice showing delivery method and timestamp confirming delivery within the required 30-day window from the credit decision date", "legal_counsel_review_record confirming the reason code mapping and notice language satisfy ECOA and Regulation B requirements, reviewed within the past 12 months", "adverse_action_notice_compliance_audit_sample with compliance review findings on reason code accuracy relative to underlying AI model feature importance outputs" ], "machine_tests": [ "Trigger an AI credit denial decision \u2192 assert an adverse_action_notice is generated within 1 second with all required fields: applicant_id, principal_reason_codes, model_id, model_version, and generation_timestamp", "Compare generated reason codes to the AI model's feature importance values for the same decision \u2192 assert reason codes reflect the top-weighted features driving the denial within the defined mapping tolerance", "Query adverse_action_notice_log for decisions in the past 30 days \u2192 assert all credit denials have a corresponding notice with delivery_timestamp within 30 days of the credit_decision_timestamp", "Attempt to complete an AI credit denial workflow without triggering notice generation \u2192 assert the workflow is blocked and a compliance alert is raised before any denial status is recorded" ], "human_review": [ "Review a sample of adverse action notices alongside their corresponding AI model feature importance outputs to assess whether reason codes reflect the true principal drivers of each denial", "Assess whether the plain-language notice text would be understandable to the affected applicant and would satisfy a CFPB examiner reviewing the institution's AI credit decisioning practices", "Verify that the reason code mapping process is updated and re-reviewed by compliance when the underlying model is retrained, reconfigured, or replaced" ], "blocking_effect": "blocks-runtime-action", "normative_status": "regulation", "anti_patterns": [ "Mapping AI model outputs to generic Regulation B reason codes such as 'insufficient credit history' without verifying the code reflects the specific principal reason the AI model assigned the denial", "Generating adverse action notices using reason codes from a prior model version when the production model has been updated, creating a mismatch between the notice and the actual decision rationale", "Treating AI model decisions as loan officer recommendations to avoid Regulation B notice obligations when the AI output is the effective decision-maker in the credit determination", "Applying identical reason codes to every denial from a particular model regardless of the applicant-specific feature importance values for that decision", "Delegating reason code mapping to engineering teams without compliance or legal review, producing technically derived but legally insufficient reason code selections" ], "update_status": "current", "layer_code": "FD" }, { "id": "FD-03", "layer": "FD", "plane": "control", "name": "Fair Lending AI Explainability", "plain": "AI credit decision models must be capable of producing feature-level explanations demonstrating that protected class characteristics did not drive adverse outcomes, and those explanations must be tested for consistency, fairness, and legal sufficiency as a condition of model deployment.", "threat": { "tags": [ "disparate-impact", "proxy-variable-discrimination", "unexplainable-fair-lending", "model-bias-concealment" ], "desc": "Machine learning models used in credit underwriting frequently encode protected class correlations through proxy variables \u2014 geography, behavioral patterns, or device characteristics that are statistically associated with race, national origin, or sex. Without explainability controls, institutions cannot detect or disprove proxy discrimination, cannot respond to examiner disparate impact findings, and cannot comply with ECOA's effects test. Regulators have increasingly required institutions to demonstrate affirmatively that their AI models are fair, rather than accepting the absence of explicit protected class inputs as sufficient." }, "standard": [ { "id": "eu_ai_act", "section": "Art. 10", "title": "Data and data governance for high-risk AI" }, { "id": "microsoft_rai", "section": "F2", "title": "Fairness \u2014 minimized allocation disparities" } ], "sources": [ { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://finance/controls/FD-03 Fair Lending AI Explainability control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Anthropic's Responsible Scaling Policy v3.3 documents the vendor's capability thresholds and safeguards, cited as third-party AI due diligence context for the apeiris://finance/controls/FD-03 Fair Lending AI Explainability control.", "reviewed_on": "2026-07-02" }, { "id": "aws_financial_services_compliance_2024", "title": "AWS User Guide to Financial Services Regulations & Guidelines in the United States", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/financial-services/security-compliance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_financial_services_compliance_2024", "relationship": "informative_reference", "rationale": "AWS's financial services regulatory guide and compliance tooling document infrastructure-layer capabilities relevant to the apeiris://finance/controls/FD-03 Fair Lending AI Explainability control.", "reviewed_on": "2026-07-02" }, { "id": "google_cloud_financial_services_ai_2024", "title": "Google Cloud Explainable AI", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/explainable-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_financial_services_ai_2024", "relationship": "informative_reference", "rationale": "Google Cloud's Explainable AI and Vertex AI model governance documentation describes platform capabilities relevant to the apeiris://finance/controls/FD-03 Fair Lending AI Explainability control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Fair lending explainability suite integrated into model validation pipeline. Suite includes: (1) protected class proxy detection scan on input features, (2) intersectional SHAP analysis identifying whether protected-class-correlated features are among top contributors in any demographic segment, (3) adverse impact ratio calculation by prohibited basis group, and (4) explainability consistency test confirming that reasons given for adverse decisions are not systematically different across protected class groups.", "steps": [ "Integrate a proxy variable detection module into the model validation workflow that flags any input feature with a Pearson correlation above 0.3 with a protected class variable from the HMDA or application dataset.", "Run intersectional SHAP analysis on a held-out validation set stratified by protected class, and require model owners to document and justify any case where a protected-class-correlated feature appears in the top five contributors for a demographic segment.", "Calculate adverse impact ratios (AIR) for each prohibited basis group at model deployment and at quarterly model monitoring intervals, with AIR below 0.80 triggering automatic escalation to the fair lending committee.", "Conduct a reason-code consistency test comparing the distribution of adverse action reasons across protected class groups to detect systematic differences in explanation patterns that could indicate disparate treatment in the explainability layer." ], "model_risk_officer": { "summary": "Fair lending explainability is a first-order model validation requirement; a model that cannot demonstrate the absence of prohibited basis discrimination cannot receive a validation opinion supporting production deployment.", "actions": [ "Include proxy variable detection, intersectional SHAP analysis, AIR calculation, and reason-code consistency testing as mandatory components of the model validation report for all credit models.", "Require model owners to respond in writing to any proxy variable flag before the model receives a satisfactory validation opinion.", "Track AIR trends over time and escalate any quarter-over-quarter deterioration to the fair lending committee regardless of whether the threshold has been breached." ], "failure_signals": [ "Model deployed to production without a completed fair lending explainability section in the validation report.", "AIR below 0.80 for any prohibited basis group without documented escalation and remediation plan.", "Proxy variable flag unresolved at time of validation opinion issuance." ] }, "compliance_officer": { "summary": "Fair lending explainability controls must satisfy the regulatory standard for an affirmative demonstration of non-discrimination, not merely the absence of explicit protected class inputs in the model.", "actions": [ "Review the fair lending explainability analysis before each model deployment approval and document the compliance sign-off in the model change control record.", "Report AIR results and proxy variable findings to the fair lending committee quarterly and maintain a remediation log for any findings requiring corrective action.", "Coordinate with outside counsel to ensure the explainability methodology used would be defensible in a regulatory examination or private litigation context." ], "metrics": [ "Models in production with current fair lending explainability analysis: target 100%.", "Adverse impact ratio: target at or above 0.80 for all prohibited basis groups across all credit products.", "Proxy variable flags resolved before deployment: target 100%." ], "failure_signals": [ "Any credit model in production without a current fair lending explainability analysis (stale if model has been retrained).", "AIR persistently between 0.80 and 0.90 without a documented business necessity analysis.", "CFPB or OCC examination finding related to fair lending model governance." ] }, "internal_audit": { "summary": "Internal audit must independently verify that fair lending explainability controls are operating effectively and that the model validation pipeline is not being bypassed for expedited deployments.", "actions": [ "Annually test whether every credit model in production has a current fair lending explainability analysis in the model inventory.", "Sample validation reports for 20% of credit models and verify that proxy variable detection, AIR calculation, and reason-code consistency testing were completed with documented results.", "Test the AIR escalation workflow by reviewing whether any quarter in the prior 12 months had an AIR below 0.80 and confirming that the escalation and remediation records exist." ], "failure_signals": [ "Credit model in production without a fair lending explainability analysis in the model inventory.", "Validation report missing required fair lending analysis components.", "AIR escalation required but not documented in the fair lending committee records." ] }, "it_operations": { "summary": "IT Operations runs explainability tooling and fairness test jobs behind fair lending explainability and disparate impact testing \u2014 integrating it with deployment pipelines, enforcing the automated gates, and keeping the supporting data flows reliable and auditable.", "actions": [ "Integrate explainability tooling and fairness test jobs with CI/CD and runtime tooling so that disparate-impact test runs complete for each credit model release.", "Automate collection and retention of fairness and proxy-variable test outputs in immutable, hash-verified storage.", "Monitor pipeline and integration health and alert when fairness test jobs fail or are skipped for a release." ], "failure_signals": [ "Production changes bypass the automated gate so that it is no longer true that disparate-impact test runs complete for each credit model release.", "Gaps or outages in fairness and proxy-variable test outputs collection exceeding 24 hours.", "Manual, untracked edits to explainability tooling and fairness test jobs records." ] }, "financial_controller": { "summary": "Fair lending failures become financial exposure \u2014 remediation programs, reserves, and settlements \u2014 so testing evidence matters to the controller.", "actions": [ "Confirm remediation reserves reflect open fair-lending findings on credit models.", "Review disparate-impact testing status for models whose outcomes could create contingent liabilities." ], "failure_signals": [ "Contingent liabilities from fair-lending issues surfacing without prior testing signals.", "Credit models in production with overdue fairness testing." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "The industry has moved from disparate treatment to disparate impact analysis, but intersectional explainability and proxy variable scanning at the feature level remain rare outside of the largest institutions." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "Model Risk Management", "Fair Lending / CRA Team", "Compliance", "Data Science" ], "frameworks": [ { "framework": "eu_ai_act", "requirement_id": "Art. 10", "fit": "direct", "rationale": "Article 10 requires that high-risk AI systems, including credit scoring, be trained on datasets that are free from discriminatory patterns and that data governance processes address potential biases. Fair lending explainability controls provide the technical means to satisfy this requirement.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "microsoft_rai", "requirement_id": "F2", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal F2 (Allocation of resources and opportunities) requires minimizing disparities in how systems allocate resources and opportunities across demographic groups. For institutions using Azure AI services, this goal produces vendor-side governance artifacts that align with fair lending explainability and disparate impact testing. The Standard is Microsoft's published internal policy offered as reference practice, not regulatory guidance.", "normative_force": "best-practice", "source_version": "2022", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "coso_icfr", "requirement_id": "Component 5 \u2014 Monitoring Activities", "fit": "partial", "rationale": "COSO 2013 Component 5 (Monitoring Activities; Principles 16-17) requires ongoing and separate evaluations that ascertain whether controls are present and functioning, with deficiencies communicated. Recurring disparate impact testing of credit models is a separate-evaluation discipline over the fairness properties of a control-relevant model; findings feed the deficiency-communication path.", "normative_force": "industry-framework", "source_version": "2013", "reviewed_on": "2026-07-02", "basis": "asserted", "relation": "informs" }, { "framework": "aws_financial", "requirement_id": "AWS User Guide to Financial Services Regulations & Guidelines in the United States", "fit": "partial", "rationale": "The 'AWS User Guide to Financial Services Regulations & Guidelines in the United States' whitepaper maps AWS services and shared-responsibility considerations to US financial regulatory expectations. For AWS-hosted financial AI systems, this supplies the infrastructure-layer support and evidence stream for fair lending explainability and disparate impact testing. This is vendor documentation of real AWS capabilities \u2014 it does not substitute for model-layer validation or regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_financial", "requirement_id": "Explainable AI", "fit": "partial", "rationale": "Google Cloud's Explainable AI documentation (cloud.google.com/explainable-ai) describes feature attribution and explanation tooling available through Vertex AI. For GCP-hosted financial AI systems, this capability supplies the platform-layer support for fair lending explainability and disparate impact testing. This is vendor product documentation, not regulatory guidance; it does not address model-layer regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://finance/controls/FD-03", "meta": { "authored_on": "2026-06-29", "schema_version": "1.1.0" }, "validation_objective": "Every AI credit decision model must be capable of producing at inference time a feature-level explanation identifying the principal factors driving the output and demonstrating that protected class characteristics did not materially contribute to adverse outcomes. Explanation consistency, proxy variable absence, and legal sufficiency must be validated before model deployment, and explanations must be regenerable for any historical decision within the retention period.", "evidence_required": [ "feature_importance_explanation_records for a representative sample of credit decisions showing the contribution of each input feature to the model output, generated at inference time and stored with the decision record", "disparate_impact_analysis_report demonstrating that explanations for similarly situated applicants differing only on protected class characteristics show no material difference in principal feature importance drivers", "proxy_variable_screen_results showing that no model input feature exceeds the defined statistical correlation threshold with any protected class characteristic", "explanation_consistency_test_results verifying that the explainability method produces identical outputs for the same input across repeated calls with no non-determinism", "legal_sufficiency_review_record from fair lending counsel confirming that explanation outputs satisfy ECOA, Regulation B, and applicable state fair lending requirements" ], "machine_tests": [ "Submit identical credit applications differing only on a protected class characteristic \u2192 assert that feature importance explanations show equivalent principal drivers with zero contribution attributed to the protected characteristic", "Submit a credit application through the model and explainability module \u2192 assert a feature importance explanation is returned within the inference SLA identifying no more than the configured number of principal drivers", "Run proxy variable detection scan against the model's full feature set \u2192 assert no feature exceeds the defined correlation threshold with any protected class characteristic", "Call the explainability method 100 times with the same input \u2192 assert all 100 explanation outputs are byte-identical, confirming deterministic behavior" ], "human_review": [ "Review the disparate impact analysis methodology with fair lending counsel to confirm it meets the evidentiary standard required for regulatory examination by the CFPB or OCC", "Assess whether the explanation output for a sample of denied applications would satisfy a fair lending examiner reviewing the institution's AI credit decisioning practices", "Verify that the proxy variable detection threshold was established by a qualified methodologist and has been approved by both the model risk officer and fair lending counsel before each model deployment" ], "blocking_effect": "blocks-deployment", "normative_status": "supervisory-guidance", "anti_patterns": [ "Using a high-variance explainability method such as LIME with small sample sizes that produces inconsistent explanations for the same input, making fair lending analysis unreliable", "Conducting proxy variable analysis only at model development time rather than re-running the screen after each model retraining or feature set change", "Treating disparate impact testing as a separate compliance exercise rather than requiring fair lending explainability evidence as a condition of validation sign-off", "Relying on global feature importance statistics such as mean SHAP values across the population as a substitute for individual-level explanation capability at inference time", "Permitting model deployment where the explanation method cannot regenerate explanations for historical decisions, exposing the institution to fair lending litigation without a defensible evidentiary record" ], "update_status": "current", "layer_code": "FD" }, { "id": "FD-04", "layer": "FD", "plane": "lifecycle", "name": "Model Output Disclosure to Financial Regulators", "plain": "The institution must maintain documented procedures, pre-staged disclosure packages, and a defined escalation pathway enabling timely, accurate disclosure of AI model information \u2014 including architecture, validation findings, performance metrics, and known limitations \u2014 in response to requests from financial regulators.", "threat": { "tags": [ "examiner-information-gap", "regulatory-production-failure", "model-documentation-deficiency", "supervisory-delay" ], "desc": "Financial regulators including the Federal Reserve, OCC, FDIC, CFPB, and SEC are increasingly issuing information requests specifically focused on AI model governance. Institutions that cannot produce organized, current model documentation within examiner-specified timeframes receive Matters Requiring Attention, lose examiner trust, and risk formal enforcement action. Disorganized or incomplete responses often result in expanded examination scope. The complexity of ML model documentation \u2014 spanning training data lineage, validation reports, performance monitoring, and override records \u2014 creates a disclosure readiness gap that does not exist for traditional statistical models." }, "standard": [ { "id": "sr26_2", "section": "\u00a7VI (Documentation)", "title": "Model documentation" }, { "id": "sox", "section": "Section 404", "title": "Management assessment of internal controls" }, { "id": "bcbs_239", "section": "Principle 9", "title": "Clarity and usefulness (incl. forward-looking content)" } ], "sources": [ { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Anthropic's Responsible Scaling Policy v3.3 documents the vendor's capability thresholds and safeguards, cited as third-party AI due diligence context for the apeiris://finance/controls/FD-04 Model Output Disclosure to Financial Regulators control.", "reviewed_on": "2026-07-02" }, { "id": "openai_enterprise_data_governance_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "OpenAI's enterprise privacy and compliance documentation records vendor-side data handling and audit-log capabilities relevant to the apeiris://finance/controls/FD-04 Model Output Disclosure to Financial Regulators control.", "reviewed_on": "2026-07-02" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://finance/controls/FD-04 Model Output Disclosure to Financial Regulators control.", "reviewed_on": "2026-07-01" }, { "id": "aws_financial_services_compliance_2024", "title": "AWS User Guide to Financial Services Regulations & Guidelines in the United States", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/financial-services/security-compliance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_financial_services_compliance_2024", "relationship": "informative_reference", "rationale": "AWS's financial services regulatory guide and compliance tooling document infrastructure-layer capabilities relevant to the apeiris://finance/controls/FD-04 Model Output Disclosure to Financial Regulators control.", "reviewed_on": "2026-07-02" }, { "id": "google_cloud_financial_services_ai_2024", "title": "Google Cloud Explainable AI", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/explainable-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_financial_services_ai_2024", "relationship": "informative_reference", "rationale": "Google Cloud's Explainable AI and Vertex AI model governance documentation describes platform capabilities relevant to the apeiris://finance/controls/FD-04 Model Output Disclosure to Financial Regulators control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Model disclosure package pre-staged in a regulatory production repository for every model in production. Package updated within 30 days of any model change event. A regulatory affairs function with defined authority to respond to examiner requests within SLA, supported by a production checklist ensuring all required elements are included.", "steps": [ "Define the standard regulatory disclosure package for AI models: model purpose, developer, validation date and findings, current performance metrics, known limitations, material changes since last examination, training data governance summary, and decision volume statistics.", "Maintain a regulatory production repository \u2014 separate from the model development environment \u2014 containing current disclosure packages for every production model, updated within 30 days of any model change or quarterly at minimum.", "Establish a documented examiner request response procedure assigning responsibility, specifying response SLAs (24 hours for urgent requests, five business days for standard requests), and requiring senior management sign-off before regulatory production.", "Conduct an annual regulatory readiness exercise in which the model risk function simulates an examiner request for three randomly selected models and verifies that the disclosure package is complete, current, and producible within SLA." ], "model_risk_officer": { "summary": "The model risk officer is accountable for the completeness and accuracy of the regulatory disclosure package; it is the primary artifact demonstrating that the MRM program is consistent with SR 26-2 expectations.", "actions": [ "Maintain a disclosure package completeness checklist and verify it against the regulatory production repository quarterly.", "Ensure that every model change event \u2014 retraining, threshold adjustment, feature addition \u2014 triggers an update to the disclosure package within 30 days.", "Lead the annual regulatory readiness exercise and report results to the model risk committee." ], "failure_signals": [ "Disclosure package for any production model stale by more than 90 days.", "Model change event not reflected in disclosure package within 30 days.", "Annual readiness exercise revealing a gap that could not be resolved within the production SLA." ] }, "compliance_officer": { "summary": "The compliance officer ensures that the regulatory disclosure program satisfies the specific requirements of each applicable regulator and that the institution's response posture does not create adversarial dynamics with examiners.", "actions": [ "Map examiner disclosure requirements by regulator and update the standard disclosure package checklist to reflect any guidance issued since the last update.", "Review the examiner request response procedure annually and confirm that the legal review step does not create bottlenecks that would prevent timely production.", "Track all examiner requests related to AI models in a regulatory tracking log and report open items to senior management monthly." ], "metrics": [ "Disclosure package completeness rate: target 100% across all production models.", "Examiner request response rate within SLA: target 100%.", "Annual readiness exercise completion: target 100% with documented findings." ], "failure_signals": [ "Any examiner request response delivered outside the defined SLA.", "Disclosure package found to be incomplete or inaccurate during examination.", "Regulatory tracking log not updated within five business days of an examiner request." ] }, "internal_audit": { "summary": "Internal audit validates that the regulatory disclosure infrastructure is maintained in a state of continuous readiness, independent of whether an examination is currently in progress.", "actions": [ "Audit the regulatory production repository annually, sampling disclosure packages for 20% of production models and verifying completeness against the defined checklist.", "Verify that model change events in the model inventory are reflected in corresponding disclosure package updates within the defined 30-day window.", "Review the regulatory tracking log to confirm all prior examiner requests were responded to within SLA and that findings were remediated." ], "failure_signals": [ "Disclosure packages sampled that are missing required elements.", "Model change events not triggering disclosure package updates.", "Prior examiner requests with responses delivered outside SLA and no documented explanation." ] }, "it_operations": { "summary": "IT Operations runs the disclosure package repository behind examiner-ready model documentation disclosure packages \u2014 integrating it with deployment pipelines, enforcing the automated gates, and keeping the supporting data flows reliable and auditable.", "actions": [ "Integrate the disclosure package repository with CI/CD and runtime tooling so that package assembly jobs can regenerate a current package on demand.", "Automate collection and retention of versioned disclosure packages in immutable, hash-verified storage.", "Monitor pipeline and integration health and alert when package staleness exceeds the defined refresh window." ], "failure_signals": [ "Production changes bypass the automated gate so that it is no longer true that package assembly jobs can regenerate a current package on demand.", "Gaps or outages in versioned disclosure packages collection exceeding 24 hours.", "Manual, untracked edits to the disclosure package repository records." ] }, "financial_controller": { "summary": "Examiner-ready documentation shortens examinations and prevents surprises that would otherwise land in the financial statements as contingencies.", "actions": [ "Confirm disclosure packages exist and are current for models the examiners are likely to request.", "Review package contents for models supporting material financial estimates." ], "failure_signals": [ "Examiner requests requiring multi-week scrambles to assemble documentation.", "Disclosure packages inconsistent with the financial figures the models actually produced." ] } }, "maturity": { "current": "repeatable", "target": "managed", "notes": "Institutions with mature MRM programs have model inventories but often lack a pre-staged, examiner-ready disclosure package distinct from the internal model documentation repository." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "federated-enterprise" ], "implementers": [ "Model Risk Management", "Regulatory Affairs", "Compliance", "Legal" ], "frameworks": [ { "framework": "sr26_2", "requirement_id": "\u00a7VI (Documentation)", "fit": "direct", "rationale": "SR 26-2 \u00a7VI describes model documentation expectations under its Documentation subheading. Honest scope note: the guidance addresses documentation quality for internal governance and supervisory review; it does not prescribe regulator-disclosure packages. FD-04's pre-staged examiner packages are institutional practice built on the \u00a7VI documentation base.", "normative_force": "supervisory-guidance", "source_version": "2026-04-17", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "sox", "requirement_id": "Section 404", "fit": "partial", "rationale": "SOX Section 404 requires management to assess and report on the effectiveness of internal controls over financial reporting. For institutions using AI in financial reporting processes, the ability to disclose model governance documentation to auditors and regulators is part of that assessment.", "normative_force": "binding-law", "source_version": "2002", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "satisfies" }, { "framework": "bcbs_239", "requirement_id": "Principle 9", "fit": "partial", "rationale": "BCBS 239 Principle 9 (Clarity and usefulness) requires risk reports to communicate information in a clear and concise manner, useful to recipients including supervisors, and to include forward-looking elements where relevant. Examiner-ready model documentation packages apply that clarity-and-usefulness discipline to supervisory information requests; the fit is partial.", "normative_force": "supervisory-guidance", "source_version": "2013", "reviewed_on": "2026-07-02", "basis": "asserted", "relation": "satisfies" }, { "framework": "omb_a_123", "requirement_id": "Section IV.A", "fit": "adjacent", "rationale": "OMB Circular A-123 (M-16-17) Section IV.A addresses documentation of internal controls \u2014 maintaining documentation sufficient to support management's assurances. Examiner-ready model documentation packages implement the same documentation-readiness discipline for financial AI.", "normative_force": "supervisory-guidance", "source_version": "2016", "reviewed_on": "2026-07-02", "basis": "asserted", "relation": "satisfies" }, { "framework": "openai_enterprise", "requirement_id": "Enterprise Compliance API \u2014 audit logs", "fit": "partial", "rationale": "ChatGPT Enterprise and the OpenAI API expose workspace audit-log data through the Compliance API and audit logs endpoint, exportable to SIEM and evidence stores. Institutions using OpenAI models in financial workflows can incorporate this vendor capability into examiner-ready model documentation disclosure packages. This is vendor capability documentation, not regulatory guidance; it covers the vendor side only.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "A1", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal A1 (Impact assessment) requires documented impact assessments identifying intended uses, stakeholders, and potential harms. For institutions using Azure AI services, this goal produces vendor-side governance artifacts that align with examiner-ready model documentation disclosure packages. The Standard is Microsoft's published internal policy offered as reference practice, not regulatory guidance.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_financial", "requirement_id": "AWS Artifact", "fit": "partial", "rationale": "AWS Artifact provides on-demand access to AWS's third-party compliance reports (SOC 1/2, PCI DSS, ISO). For AWS-hosted financial AI systems, this supplies the infrastructure-layer support and evidence stream for examiner-ready model documentation disclosure packages. This is vendor documentation of real AWS capabilities \u2014 it does not substitute for model-layer validation or regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://finance/controls/FD-04", "meta": { "authored_on": "2026-06-29", "schema_version": "1.1.0" }, "validation_objective": "The institution must maintain, for each AI model in production, a pre-staged regulatory disclosure package containing the model architecture summary, validation findings, current performance metrics, known limitations, and data lineage sufficient to respond to a regulatory examination request. Disclosure procedures must be tested annually and must enable package delivery within the response timeframe required by the institution's primary regulator.", "evidence_required": [ "regulatory_disclosure_package for each production model containing architecture_summary, validation_findings_summary, current_performance_metrics_report, known_limitations_register, and data_lineage_document", "disclosure_procedure_document specifying escalation path, responsible officers, and required response timelines by regulator type including OCC, Federal Reserve, FDIC, and SEC", "annual_disclosure_drill_record showing the package was assembled and reviewed within the required response SLA without creating new documents after the drill commenced", "model_disclosure_inventory_index mapping each production model to its corresponding disclosure package with package version and last_updated_timestamp", "legal_and_compliance_review_record confirming disclosure packages were reviewed for regulatory sufficiency within the past 12 months" ], "machine_tests": [ "Query model inventory \u2192 assert every model in production status has a corresponding regulatory_disclosure_package with package_completeness_status of 'complete' and last_updated_date within 90 days of the model's most recent production change", "Retrieve a sample regulatory disclosure package \u2192 assert all required sections are present with substantive content and no placeholder text in any required field", "Query model deployment log \u2192 assert no model entered production without a corresponding disclosure package being created or updated at or before deployment time", "Measure disclosure package retrieval latency for a sample of models \u2192 assert the complete package is retrievable and deliverable within 4 hours for all tested models" ], "human_review": [ "Review a sample of regulatory disclosure packages from an experienced examiner's perspective to assess whether they would satisfy an OCC or Federal Reserve examination request without requiring supplemental documentation", "Assess the annual disclosure drill results to verify that response timelines were met and that no documents required creation or revision after the drill commenced", "Verify that each model's disclosure package is updated after model retraining, material feature changes, or issuance of new significant validation findings" ], "blocking_effect": "requires-review", "normative_status": "supervisory-guidance", "anti_patterns": [ "Maintaining model documentation across disconnected systems such as model repositories, email threads, and SharePoint folders that cannot be assembled into a coherent regulatory response package within examination timeframes", "Creating regulatory disclosure documents reactively during an examination rather than maintaining pre-staged packages that reflect the current state of each production model", "Including only favorable performance metrics in disclosure packages while omitting known limitations, degraded subpopulation performance, or open validation findings", "Treating the disclosure package as a static artifact that is not updated when the model is retrained, reconfigured, or when new validation findings are issued", "Delegating disclosure package maintenance exclusively to model owners without independent compliance review, creating a conflict between complete disclosure and model continuation interests" ], "update_status": "current", "layer_code": "FD" }, { "id": "FD-05", "layer": "FD", "plane": "control", "name": "Financial Consumer Notification and Rights", "plain": "Consumers affected by consequential AI-driven financial decisions must receive timely notification that AI was involved in the decision, a plain-language explanation of how to contest or request human review, and information about their rights under applicable consumer protection law.", "threat": { "tags": [ "consumer-rights-violation", "ai-opacity", "contestation-barrier", "informed-consent-gap" ], "desc": "Consumers subjected to AI-driven decisions affecting credit, insurance pricing, account management, or fraud disposition are often unaware that an automated system made the decision or that they have the right to contest it. Failure to notify consumers of AI involvement and their contestation rights exposes institutions to CFPB unfair, deceptive, and abusive acts or practices (UDAAP) findings, state consumer protection enforcement, and reputational harm. Emerging EU AI Act requirements and proposed federal rulemaking are moving toward mandatory AI disclosure in consumer financial services, making proactive notification controls a forward-looking compliance necessity." }, "standard": [ { "id": "eu_ai_act", "section": "Art. 50", "title": "Obligations for providers and deployers as regards transparency" }, { "id": "coso_icfr", "section": "Component 1", "title": "Control Environment \u2014 ethical obligations" }, { "id": "aicpa_soc2", "section": "P1.1", "title": "Privacy notice to data subjects" } ], "sources": [ { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://finance/controls/FD-05 Financial Consumer Notification and Rights control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Consumer-facing notification module integrated into the decisioning workflow. Notification includes: AI involvement disclosure, plain-language decision summary, contestation options (human review request form, regulatory complaint pathway), and link to the institution's AI rights notice. Notification is delivered through the consumer's preferred channel at the time of decision communication.", "steps": [ "Identify every consumer-facing AI decision point in the product lifecycle \u2014 credit origination, account closure, limit decrease, fraud hold, insurance pricing \u2014 and map the notification requirement and delivery channel for each.", "Draft a standardized AI involvement disclosure and rights notice, reviewed by legal counsel, that meets UDAAP plain-language standards and includes: statement of AI use, factors considered, how to request human review, regulatory complaint contact, and applicable rights under federal and state law.", "Integrate the notification module into the decision workflow so that notification is generated and delivered automatically at the time the decision is communicated, with delivery confirmation logged.", "Establish a human review request handling process with a defined SLA (maximum 30 days), a dedicated intake pathway, and a governance requirement that human reviewers have the authority to override AI decisions." ], "financial_controller": { "summary": "Consumer notification controls reduce the contingent liability exposure associated with UDAAP enforcement; their operational status is relevant to the ICFR assessment for consumer-facing AI products.", "actions": [ "Confirm that the consumer notification control is included in the ICFR control inventory for each consumer-facing product line using AI.", "Review the human review request handling SLA compliance rate quarterly and escalate persistent non-compliance to the Chief Risk Officer.", "Assess UDAAP enforcement risk exposure when evaluating contingent liabilities in financial reporting." ], "failure_signals": [ "Notification module not integrated with any consumer-facing AI decision point.", "Human review request backlog exceeding the 30-day SLA.", "CFPB or state attorney general inquiry related to AI consumer notification." ] }, "compliance_officer": { "summary": "The compliance officer must ensure the AI notification program satisfies both current UDAAP standards and anticipates the emerging regulatory trajectory toward mandatory AI disclosure in consumer financial services.", "actions": [ "Review the AI rights notice and notification templates annually and after any material regulatory guidance affecting consumer AI disclosure requirements.", "Monitor the human review request queue and report SLA compliance, override rates, and consumer satisfaction metrics to the compliance committee quarterly.", "Conduct a UDAAP risk assessment for each consumer-facing AI decision point annually, documenting the conclusion and any remediation actions." ], "metrics": [ "Notification delivery rate: target 100% for all regulated AI decision communications.", "Human review request SLA compliance: target 100% within 30 days.", "UDAAP risk assessments current for all consumer AI decision points: target 100%." ], "failure_signals": [ "Notification delivery failure rate above 0.1% in any month.", "Human review requests not acknowledged within five business days.", "UDAAP risk assessment stale for any consumer AI decision point." ] }, "it_operations": { "summary": "The notification module is a customer-communication system requiring high availability, channel redundancy, and an immutable delivery log to support regulatory inquiries.", "actions": [ "Deploy the notification module with 99.9% availability and automated fallback to secondary delivery channels if the primary channel fails.", "Maintain an immutable delivery log for all consumer notifications with timestamp, channel, content hash, and delivery confirmation.", "Implement monitoring alerts for notification delivery failures and escalate to the compliance team within one hour of any failure affecting a regulated decision type." ], "failure_signals": [ "Notification delivery log showing gaps in coverage for any regulated decision type.", "Delivery failure rate above 0.1% without automated escalation.", "Notification module unavailable during business hours." ] }, "model_risk_officer": { "summary": "Consumer notification and contest rights depend on models whose limitations the MRO documents; contested decisions are also a model-quality signal.", "actions": [ "Feed contested-decision outcomes back into model performance review as an outcomes-analysis input.", "Confirm consumer-facing decision models document limitations that notification language must reflect." ], "failure_signals": [ "Contested decisions overturned at a rate suggesting undetected model weaknesses.", "Notification language promising explanations the model documentation cannot support." ] }, "internal_audit": { "summary": "Internal audit tests whether consumer notification and contest processes work end-to-end, not just exist on paper.", "actions": [ "Trace sampled consumer contests through intake, human review, and resolution.", "Verify notification content matches actual system behavior and disclosed rights.", "Test that contest outcomes feed back into model and process review." ], "failure_signals": [ "Contests resolved without the documented human review.", "Notification language misdescribing when and how AI is used.", "No feedback path from contest outcomes to model governance." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most institutions satisfy the adverse action notice requirement but have not yet implemented a broader AI involvement disclosure and rights notification program for the full range of consequential AI decisions." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai" ], "implementers": [ "Compliance", "Product Management", "Customer Experience", "Legal" ], "frameworks": [ { "framework": "eu_ai_act", "requirement_id": "Art. 50", "fit": "direct", "rationale": "Article 50 of the EU AI Act requires that persons subject to AI-driven decisions significantly affecting them be informed of this fact and of their right to a human review. This control directly implements Article 50 and its parallel obligations under US consumer protection law.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "soc2", "requirement_id": "P1.1", "fit": "direct", "rationale": "SOC 2 P1.1 (Privacy) requires notice to data subjects about the entity's privacy practices. Consumer notification about AI involvement in decisions and available contest rights parallels that notice discipline; the fit is partial \u2014 P1.1 covers privacy practices rather than AI-decision disclosure.", "normative_force": "certification-standard", "source_version": "2022", "reviewed_on": "2026-07-02", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "coso_icfr", "requirement_id": "Component 1 \u2014 Control Environment", "fit": "adjacent", "rationale": "COSO Component 1 requires that the control environment reflect the organization's commitment to integrity and ethical values. Proactive consumer notification of AI involvement and rights is an expression of that commitment and forms part of the ethical foundation of the AI governance program.", "normative_force": "industry-framework", "source_version": "2013", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "T3", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal T3 (Disclosure of AI interaction) requires disclosure when people are interacting with an AI system. For institutions using Azure AI services, this goal produces vendor-side governance artifacts that align with consumer notification and contestability rights for AI decisions. The Standard is Microsoft's published internal policy offered as reference practice, not regulatory guidance.", "normative_force": "best-practice", "source_version": "2022", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" } ], "canonical_id": "apeiris://finance/controls/FD-05", "meta": { "authored_on": "2026-06-29", "schema_version": "1.1.0" }, "validation_objective": "When an AI model makes a consequential financial decision affecting a consumer, the system must deliver a notification at or before the time of the decision disclosing AI involvement in plain language, explaining how to contest the decision or request human review, and referencing applicable consumer rights. Notification delivery must be logged with a delivery_timestamp and delivery_confirmation_status, and the human review pathway must be operational, staffed, and respond within a documented SLA.", "evidence_required": [ "consumer_ai_notification_log showing notification_id, consumer_id, decision_id, model_id, notification_text, delivery_channel, delivery_timestamp, and delivery_confirmation_status for each consequential AI financial decision", "human_review_pathway_documentation describing the consumer invocation process, escalation steps, assigned reviewer qualifications, and the documented response SLA", "human_review_request_log showing each request received with assigned_reviewer, completion_timestamp, and outcome for all completed reviews within the retention period", "notification_language_review_record from legal or compliance counsel confirming notification text satisfies applicable consumer protection laws and EU AI Act transparency obligations", "consequential_decision_threshold_definition document identifying which AI decision types trigger the notification obligation with compliance-approved rationale for each classification" ], "machine_tests": [ "Trigger a consequential AI financial decision \u2192 assert a consumer_notification record is created within 1 second with all required fields: AI involvement disclosure, contest pathway description, consumer rights reference, and delivery_timestamp", "Query consumer_ai_notification_log for the past 90 days \u2192 assert every consequential AI decision has a corresponding notification record with delivery_confirmation_status of 'delivered' or 'failed-with-retry-initiated'", "Submit a simulated human review request through the consumer-facing pathway \u2192 assert the request is received, an acknowledgment is sent to the consumer within 24 hours, and the request is routed to a qualified reviewer", "Attempt to complete a consequential AI financial decision workflow without triggering notification \u2192 assert the workflow is blocked before decision status is recorded and an operations alert is raised" ], "human_review": [ "Review the consumer notification text with legal counsel to confirm it meets plain-language disclosure requirements under applicable consumer protection law and EU AI Act Article 50 transparency obligations", "Assess the human review pathway end-to-end as a simulated consumer to verify it is operational, accessible, and results in genuine human reconsideration rather than automated re-scoring", "Verify that the consequential decision threshold definitions have been reviewed and approved by compliance and that all AI decision types with material adverse consumer impact are included" ], "blocking_effect": "blocks-runtime-action", "normative_status": "binding-law", "anti_patterns": [ "Burying AI involvement disclosure in a dense terms-of-service update rather than delivering a clear, specific notification at the time of the consequential decision", "Providing a human review pathway that routes consumer requests to an automated re-scoring process rather than a qualified human reviewer with authority to override the AI decision", "Classifying AI-assisted decisions as human decisions supported by AI tools to avoid notification obligations when the AI output is the effective determinant of the consumer outcome", "Failing to log consumer notification delivery and confirmation, making it impossible to demonstrate compliance during regulatory examination or consumer litigation", "Defining consequential decision thresholds narrowly to exclude AI decisions with material adverse impact such as credit limit reductions, adverse pricing, or account restriction" ], "update_status": "current", "layer_code": "FD" }, { "id": "FD-06", "layer": "FD", "plane": "control", "name": "AI System Disclosure in Financial Filings", "plain": "Publicly reporting financial institutions must disclose material AI-related risks, dependencies, and capabilities in SEC filings and financial reports, with disclosures reviewed by subject matter experts and updated to reflect material changes in the AI risk profile.", "threat": { "tags": [ "material-omission", "sec-disclosure-deficiency", "investor-information-asymmetry", "ai-risk-concealment" ], "desc": "The SEC has issued guidance requiring registrants to disclose material AI-related risks under existing disclosure obligations, and enforcement actions for inadequate cyber and technology risk disclosure have established that AI is within scope. Institutions that fail to disclose material AI dependencies \u2014 including concentration risk in AI vendors, model performance degradation risk, regulatory uncertainty around AI use, and the potential for AI-driven decisions to be challenged \u2014 expose their officers to Section 10(b) liability and the institution to SEC enforcement. The pace of AI adoption has outstripped disclosure practice, creating a widespread gap between the materiality of AI risk and its representation in public filings." }, "standard": [ { "id": "sox", "section": "Section 302 & 404", "title": "Disclosure controls and procedures; ICFR assessment" }, { "id": "coso_icfr", "section": "Component 5", "title": "Monitoring Activities \u2014 disclosure controls" }, { "id": "eu_ai_act", "section": "Art. 53", "title": "Obligations for providers of general-purpose AI models" }, { "id": "aicpa_soc2", "section": "CC2.3", "title": "Communication with external parties" } ], "sources": [ { "id": "openai_enterprise_data_governance_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "OpenAI's enterprise privacy and compliance documentation records vendor-side data handling and audit-log capabilities relevant to the apeiris://finance/controls/FD-06 AI System Disclosure in Financial Filings control.", "reviewed_on": "2026-07-02" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://finance/controls/FD-06 AI System Disclosure in Financial Filings control.", "reviewed_on": "2026-07-01" }, { "id": "aws_financial_services_compliance_2024", "title": "AWS User Guide to Financial Services Regulations & Guidelines in the United States", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/financial-services/security-compliance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_financial_services_compliance_2024", "relationship": "informative_reference", "rationale": "AWS's financial services regulatory guide and compliance tooling document infrastructure-layer capabilities relevant to the apeiris://finance/controls/FD-06 AI System Disclosure in Financial Filings control.", "reviewed_on": "2026-07-02" }, { "id": "google_cloud_financial_services_ai_2024", "title": "Google Cloud Explainable AI", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/explainable-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_financial_services_ai_2024", "relationship": "informative_reference", "rationale": "Google Cloud's Explainable AI and Vertex AI model governance documentation describes platform capabilities relevant to the apeiris://finance/controls/FD-06 AI System Disclosure in Financial Filings control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Annual AI risk disclosure review process integrated into the SEC filing preparation workflow. Review committee includes model risk, compliance, legal, and finance representatives. AI risk inventory mapped to disclosure items. Material changes trigger an interim disclosure assessment outside the annual cycle.", "steps": [ "Establish an AI risk disclosure committee with representation from model risk management, compliance, legal, and finance, meeting at least annually before each 10-K filing and on an ad hoc basis when material AI risk events occur.", "Maintain an AI risk inventory cataloging model types, decision volumes, regulatory dependencies, vendor concentrations, and known performance limitations \u2014 updated quarterly \u2014 that serves as the basis for disclosure materiality assessment.", "Implement a materiality assessment framework for AI-related risks that maps inventory items to disclosure items (Item 1A risk factors, MD&A, financial statement notes) and documents the basis for each inclusion or exclusion decision.", "Require that all AI-related risk factor language and MD&A disclosures be reviewed by the model risk officer for technical accuracy before filing, with sign-off documented in the disclosure preparation record." ], "financial_controller": { "summary": "The financial controller is directly responsible for the adequacy of disclosure controls and procedures; AI risk disclosure must be treated as a material component of those controls for institutions with significant AI exposure.", "actions": [ "Include AI risk disclosure review in the quarterly sub-certification process for the CEO/CFO Section 302 certification.", "Confirm that the AI risk inventory is updated before each quarterly earnings release and that any material changes are assessed for disclosure in the 10-Q.", "Document the basis for materiality determinations for all AI-related risk factors and retain the documentation for five years as support for the Section 302 certification." ], "failure_signals": [ "AI risk disclosure not reviewed by model risk officer before filing.", "Material AI risk event not assessed for disclosure within 10 business days of occurrence.", "SEC comment letter questioning the adequacy or accuracy of AI-related disclosures." ] }, "compliance_officer": { "summary": "Compliance must monitor evolving SEC guidance on AI disclosure and ensure that the institution's disclosure practice keeps pace with regulatory expectations and peer practice.", "actions": [ "Review SEC staff guidance, comment letters to peer institutions, and enforcement actions related to AI disclosure at least quarterly and update the disclosure framework accordingly.", "Facilitate the annual AI risk disclosure committee meeting and document conclusions in the disclosure preparation record.", "Assess whether the institution's AI disclosure is consistent with peer practice and escalate any significant gap to legal counsel and the CFO." ], "metrics": [ "AI risk inventory current as of the filing date: target 100%.", "Materiality assessment documented for all AI risk inventory items: target 100%.", "Model risk officer sign-off on AI disclosure language: target 100% before each filing." ], "failure_signals": [ "AI risk inventory not updated within 30 days of a material AI risk event.", "Model risk officer sign-off absent from the disclosure preparation record for any filing.", "Disclosure materially inconsistent with the AI risk inventory without documented justification." ] }, "internal_audit": { "summary": "Internal audit provides independent assurance that the AI disclosure process is operating effectively and that the institution's public statements about AI are supported by the underlying risk inventory and governance documentation.", "actions": [ "Annually audit the disclosure preparation process, verifying that the committee met, the inventory was current, materiality assessments were documented, and the model risk officer sign-off was obtained.", "Compare disclosed AI risk factors to the AI risk inventory to identify any material risk categories present in the inventory but absent from the disclosure.", "Review SEC comment letters and management responses related to AI disclosure and confirm that any required changes were implemented in subsequent filings." ], "failure_signals": [ "Disclosure preparation committee meeting not held before annual filing.", "Material risk category in the AI risk inventory with no corresponding disclosure and no documented materiality exclusion.", "SEC comment letter finding not reflected in subsequent filing." ] }, "it_operations": { "summary": "IT Operations runs the filing-support evidence store behind disclosure of material AI reliance in financial filings \u2014 integrating it with deployment pipelines, enforcing the automated gates, and keeping the supporting data flows reliable and auditable.", "actions": [ "Integrate the filing-support evidence store with CI/CD and runtime tooling so that AI-reliance disclosures trace to system-of-record inventories.", "Automate collection and retention of disclosure-support extracts in immutable, hash-verified storage.", "Monitor pipeline and integration health and alert when filing extracts diverge from the model inventory." ], "failure_signals": [ "Production changes bypass the automated gate so that it is no longer true that AI-reliance disclosures trace to system-of-record inventories.", "Gaps or outages in disclosure-support extracts collection exceeding 24 hours.", "Manual, untracked edits to the filing-support evidence store records." ] }, "model_risk_officer": { "summary": "Filing disclosures about AI reliance must match the model inventory; the MRO is the source of truth for what is actually material.", "actions": [ "Reconcile AI-reliance statements in filings against the model inventory and materiality tiers each period.", "Flag inventory changes (new material models, retirements) to the disclosure process." ], "failure_signals": [ "Filings describing AI reliance inconsistent with the inventory.", "Material model additions absent from the next filing cycle's disclosure review." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "AI disclosure practice in financial institution filings is rapidly evolving; most institutions have added boilerplate AI risk factors but lack the process infrastructure to ensure accuracy and completeness." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai" ], "implementers": [ "Financial Reporting / IR", "Model Risk Management", "Legal / Securities Counsel", "Compliance" ], "frameworks": [ { "framework": "sox", "requirement_id": "Section 302 & 404", "fit": "direct", "rationale": "SOX Sections 302 and 404 require that disclosure controls and procedures be designed and operating effectively to ensure material information about the registrant is communicated to the officers making the certifications. AI risk disclosure is within scope of this requirement for institutions with material AI exposure.", "normative_force": "binding-law", "source_version": "2002", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "satisfies" }, { "framework": "coso_icfr", "requirement_id": "Component 5 \u2014 Monitoring Activities", "fit": "direct", "rationale": "COSO Component 5 requires ongoing monitoring of internal controls to ensure they remain effective. The AI risk disclosure review process is the monitoring activity for the disclosure control, and the annual committee meeting is the primary monitoring event.", "normative_force": "industry-framework", "source_version": "2013", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "informs" }, { "framework": "eu_ai_act", "requirement_id": "Art. 53", "fit": "partial", "rationale": "Article 53 requires providers of general-purpose AI models to maintain technical documentation sufficient to allow understanding of the model's capabilities and limitations. For institutions deploying GPAI in financial products, the disclosure obligation under Article 53 has a parallel in the materiality assessment for SEC filings.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "soc2", "requirement_id": "CC2.3", "fit": "partial", "rationale": "SOC 2 CC2.3 requires the entity to communicate with external parties regarding matters affecting the functioning of internal control. Disclosure of material AI reliance in financial filings is an external-communication control consistent with CC2.3's discipline.", "normative_force": "certification-standard", "source_version": "2022", "reviewed_on": "2026-07-02", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "microsoft_rai", "requirement_id": "T2", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal T2 (Communication to stakeholders) requires communicating system capabilities and limitations to stakeholders. For institutions using Azure AI services, this goal produces vendor-side governance artifacts that align with disclosure of material AI reliance in financial filings. The Standard is Microsoft's published internal policy offered as reference practice, not regulatory guidance.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_financial", "requirement_id": "AWS Audit Manager", "fit": "partial", "rationale": "AWS Audit Manager automates evidence collection against control frameworks for AWS workloads, and AWS CloudTrail records account-level API activity. For AWS-hosted financial AI systems, this supplies the infrastructure-layer support and evidence stream for disclosure of material AI reliance in financial filings. This is vendor documentation of real AWS capabilities \u2014 it does not substitute for model-layer validation or regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_financial", "requirement_id": "Google Cloud compliance offerings", "fit": "partial", "rationale": "Google Cloud's compliance offerings catalog documents the platform's third-party attestations (SOC 1/2/3, ISO/IEC 27001, PCI DSS) available to customers. For GCP-hosted financial AI systems, this capability supplies the platform-layer support for disclosure of material AI reliance in financial filings. This is vendor product documentation, not regulatory guidance; it does not address model-layer regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://finance/controls/FD-06", "meta": { "authored_on": "2026-06-29", "schema_version": "1.1.0" }, "validation_objective": "The institution must maintain an AI risk inventory updated within 30 days of any material AI risk event, and every SEC filing (10-K and 10-Q) must include AI risk disclosures reviewed and signed off by the model risk officer before submission, with a documented materiality assessment for each inventory item.", "evidence_required": [ "AI risk inventory record showing all model types, decision volumes, vendor dependencies, and known limitations, timestamped within 30 days of each filing date", "Materiality assessment worksheet mapping each AI risk inventory item to disclosure line items (Item 1A, MD&A, financial statement notes) with documented inclusion or exclusion rationale", "Model risk officer sign-off document with name, date, and attestation statement for each 10-K and 10-Q filing cycle", "AI risk disclosure committee meeting minutes confirming quorum, agenda items reviewed, and conclusions reached before each annual 10-K filing", "SEC comment letter log with management response records and evidence of subsequent filing updates for any AI-related comment" ], "machine_tests": [ "Query AI risk inventory last_updated timestamp against filing date \u2192 assert delta is \u226430 days for all records", "Parse SEC filing XML for AI-related risk factor language and cross-reference against inventory items flagged as material \u2192 assert no material inventory item is absent from filed disclosures without documented exclusion justification", "Check disclosure preparation record for model_risk_officer_signoff field \u2192 assert field is present and non-null for every filing cycle in the trailing 12 months", "Scan SEC EDGAR filings for peer registrant AI risk factor language and compare coverage breadth \u2192 assert institution's AI disclosure covers all material risk categories present in \u22653 peer filings" ], "human_review": [ "Review the materiality assessment framework to confirm that threshold criteria are calibrated to the institution's specific AI exposure profile and not set at a level that systematically excludes disclosures", "Assess the AI risk disclosure committee composition and meeting cadence to confirm that model risk, compliance, legal, and finance are all represented and that the ad hoc trigger mechanism for material events is operational", "Compare the institution's AI risk factor language in the most recent 10-K against the underlying AI risk inventory to verify completeness and technical accuracy of the public disclosure" ], "blocking_effect": "requires-review", "normative_status": "binding-law", "anti_patterns": [ "Boilerplate AI risk factor language copied from prior-year filings without review against the current AI risk inventory, resulting in disclosures that do not reflect material changes in AI use", "Materiality threshold set at a fixed dollar amount without considering the qualitative materiality of AI-driven decisions that affect regulatory compliance, fair lending, or investor confidence", "Model risk officer sign-off treated as a formality obtained after the filing is submitted rather than as a prerequisite gate in the disclosure preparation workflow", "AI risk inventory scoped only to internally-developed models, excluding third-party AI vendor dependencies that represent material concentration risk", "Interim disclosure assessment process lacking a defined trigger so that material AI risk events occurring between annual filings are not assessed for disclosure in the next 10-Q" ], "update_status": "current", "layer_code": "FD" }, { "id": "FD-07", "layer": "FD", "plane": "both", "name": "Model Transparency Dashboard for Senior Management", "plain": "Senior management and the board must have access to a consolidated view of AI model performance, risk indicators, and governance status across the institution's AI portfolio, presented in a format appropriate for executive oversight and board-level risk governance.", "threat": { "tags": [ "management-information-gap", "board-oversight-failure", "model-risk-concentration-blindness", "governance-reporting-deficiency" ], "desc": "When senior management and the board lack a consolidated, accessible view of AI model performance and risk, they cannot exercise meaningful oversight, cannot detect emerging concentrations of model risk, and cannot make informed decisions about AI investment and remediation priorities. SR 26-2 describes reporting of model risk to senior management and the board as part of sound governance; absent executive-level reporting, that oversight expectation goes unmet. The gap between technical model monitoring (performed by model risk teams) and executive visibility is a common AI governance weakness." }, "standard": [ { "id": "sr26_2", "section": "\u00a7V (Ongoing Model Monitoring)", "title": "Monitoring results reported to management" }, { "id": "sox", "section": "Section 302", "title": "Officer certification of disclosure controls" }, { "id": "bcbs_239", "section": "Principle 9", "title": "Clarity and usefulness of risk reports for the board" }, { "id": "coso_icfr", "section": "Component 5", "title": "Monitoring Activities \u2014 board-level reporting" } ], "sources": [ { "id": "openai_enterprise_data_governance_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "OpenAI's enterprise privacy and compliance documentation records vendor-side data handling and audit-log capabilities relevant to the apeiris://finance/controls/FD-07 Model Transparency Dashboard for Senior Management control.", "reviewed_on": "2026-07-02" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://finance/controls/FD-07 Model Transparency Dashboard for Senior Management control.", "reviewed_on": "2026-07-01" }, { "id": "aws_financial_services_compliance_2024", "title": "AWS User Guide to Financial Services Regulations & Guidelines in the United States", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/financial-services/security-compliance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_financial_services_compliance_2024", "relationship": "informative_reference", "rationale": "AWS's financial services regulatory guide and compliance tooling document infrastructure-layer capabilities relevant to the apeiris://finance/controls/FD-07 Model Transparency Dashboard for Senior Management control.", "reviewed_on": "2026-07-02" }, { "id": "google_cloud_financial_services_ai_2024", "title": "Google Cloud Explainable AI", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/explainable-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_financial_services_ai_2024", "relationship": "informative_reference", "rationale": "Google Cloud's Explainable AI and Vertex AI model governance documentation describes platform capabilities relevant to the apeiris://finance/controls/FD-07 Model Transparency Dashboard for Senior Management control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "A model transparency dashboard providing two reporting tiers: (1) a technical operations view for model risk management showing granular performance metrics, validation status, and monitoring alerts; and (2) an executive summary view for senior management and the board showing risk-rated model inventory status, key performance indicators, material findings, and remediation progress.", "steps": [ "Define the executive dashboard KPI set: total models in production, models with open validation findings (by severity), models past scheduled revalidation date, models with performance deterioration alerts, adverse impact ratio compliance status, and top-risk model narrative summaries.", "Build or configure a dashboard platform that ingests data from the model inventory, validation tracking system, and performance monitoring system, refreshed at least monthly for the executive view and daily for the operations view.", "Establish a board reporting cadence: quarterly model risk summary to the risk committee, annual comprehensive model risk report to the full board, and immediate escalation for any Tier 1 model risk event (model failure, regulatory inquiry, material performance deterioration).", "Train the model risk officer and CFO on dashboard interpretation and ensure they can explain each metric in plain language appropriate for board-level discussion." ], "financial_controller": { "summary": "The CFO relies on the model transparency dashboard to understand AI-related risk exposure relevant to financial reporting and to support the Section 302 certification that disclosure controls are effective.", "actions": [ "Review the executive dashboard monthly and escalate any model risk indicator that may affect financial reporting controls or require SEC disclosure.", "Include the model transparency dashboard review in the quarterly sub-certification process.", "Ensure that the dashboard's AIR compliance view is reviewed before each fair lending committee meeting." ], "failure_signals": [ "Dashboard not reviewed by CFO in the quarter preceding a 10-K or 10-Q filing.", "Material model risk event not reflected in the dashboard within five business days.", "Dashboard KPIs not linked to the AI risk inventory used for disclosure purposes." ] }, "model_risk_officer": { "summary": "The model risk officer is the dashboard owner and must ensure it accurately represents the current state of the model portfolio and communicates risk in a form that enables executive action.", "actions": [ "Maintain the dashboard with monthly refresh for executive metrics and daily refresh for operational metrics.", "Prepare the quarterly risk committee report by annotating dashboard outputs with qualitative context explaining trends and recommended management actions.", "Review dashboard accuracy quarterly by cross-referencing displayed metrics against source system data and correcting any discrepancies." ], "failure_signals": [ "Dashboard data more than 45 days stale for any KPI.", "Board risk committee receiving model risk reports without dashboard support.", "Dashboard accuracy audit identifying discrepancies above 2% in any metric." ] }, "compliance_officer": { "summary": "The compliance officer uses the dashboard to monitor regulatory compliance indicators \u2014 particularly AIR metrics and validation timeliness \u2014 that feed into the overall compliance program assessment.", "actions": [ "Review the compliance-relevant dashboard views (AIR, adverse action notice coverage, disclosure package completeness) monthly.", "Flag any compliance KPI trending toward a threshold breach and initiate a remediation plan before the breach occurs.", "Include dashboard-derived compliance metrics in the quarterly compliance committee report." ], "metrics": [ "Dashboard refresh timeliness: target monthly for executive view, daily for operations view.", "Board risk committee model risk report delivery: target 100% on schedule each quarter.", "Compliance KPI threshold breach events with documented remediation plans: target 100%." ], "failure_signals": [ "Compliance KPI breach not escalated within five business days of detection.", "Board risk committee not receiving quarterly model risk reports.", "Dashboard unavailable during a regulatory examination." ] }, "internal_audit": { "summary": "Internal audit validates that the model transparency dashboard is accurate, that board reporting is occurring consistent with SR 26-2 expectations, and that executive oversight of model risk is substantive rather than nominal.", "actions": [ "Annually review board and risk committee minutes to verify that model risk reporting occurred on schedule and that material findings were escalated appropriately.", "Test dashboard data accuracy by sampling five KPIs and tracing each to its source system data.", "Interview the model risk officer and a member of the board risk committee to assess whether board-level oversight of AI model risk is substantive." ], "failure_signals": [ "Board minutes showing no model risk reporting in any quarter.", "Dashboard data inaccuracy found in more than one KPI during accuracy testing.", "Board or senior management unable to articulate the institution's top model risk exposures." ] }, "it_operations": { "summary": "IT Operations runs the dashboard data pipelines behind the executive model transparency dashboard \u2014 integrating it with deployment pipelines, enforcing the automated gates, and keeping the supporting data flows reliable and auditable.", "actions": [ "Integrate the dashboard data pipelines with CI/CD and runtime tooling so that dashboard KPIs refresh from authoritative monitoring sources.", "Automate collection and retention of KPI snapshots and feed-health checks in immutable, hash-verified storage.", "Monitor pipeline and integration health and alert when dashboard feeds go stale or diverge from source systems." ], "failure_signals": [ "Production changes bypass the automated gate so that it is no longer true that dashboard KPIs refresh from authoritative monitoring sources.", "Gaps or outages in KPI snapshots and feed-health checks collection exceeding 24 hours.", "Manual, untracked edits to the dashboard data pipelines records." ] } }, "maturity": { "current": "repeatable", "target": "managed", "notes": "Technical model monitoring is common in institutions with SR 26-2 programs; executive dashboard reporting that bridges technical detail to board-appropriate KPIs is significantly less mature." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "Model Risk Management", "Finance / CFO Office", "Board Risk Committee", "Compliance" ], "frameworks": [ { "framework": "sr26_2", "requirement_id": "\u00a7V (Ongoing Model Monitoring)", "fit": "direct", "rationale": "SR 26-2 \u00a7V describes ongoing monitoring whose results should reach the levels of management able to act on them, and \u00a7VI describes board and senior management oversight roles. An executive transparency dashboard is the reporting mechanism that connects \u00a7V monitoring output to that oversight.", "normative_force": "supervisory-guidance", "source_version": "2026-04-17", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "sox", "requirement_id": "Section 302", "fit": "direct", "rationale": "Executive certifications under SOX Section 302 require officers to confirm that disclosure controls and procedures are effective. The model transparency dashboard provides the information basis for officers to make an informed assessment of AI-related disclosure controls.", "normative_force": "binding-law", "source_version": "2002", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "satisfies" }, { "framework": "bcbs_239", "requirement_id": "Principle 9", "fit": "direct", "rationale": "BCBS 239 Principle 9 (Clarity and usefulness) requires reports tailored to recipients' needs \u2014 the board should receive clear, concise risk information it can act on. The executive model transparency dashboard is the mechanism that converts technical model monitoring into board-usable reporting.", "normative_force": "supervisory-guidance", "source_version": "2013", "reviewed_on": "2026-07-02", "basis": "asserted", "relation": "satisfies" }, { "framework": "coso_icfr", "requirement_id": "Component 5 \u2014 Monitoring Activities", "fit": "direct", "rationale": "COSO Component 5 requires that the organization select, develop, and evaluate ongoing monitoring activities to ascertain whether controls are present and functioning. The model transparency dashboard is the primary monitoring activity providing senior management and the board with visibility into model risk control effectiveness.", "normative_force": "industry-framework", "source_version": "2013", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "informs" }, { "framework": "eu_ai_act", "requirement_id": "Art. 9 \u2014 Risk Management System", "fit": "partial", "rationale": "Article 9 requires providers of high-risk AI systems to implement a risk management system including monitoring and evaluation. Executive transparency dashboards satisfy the monitoring and evaluation reporting obligation at the governance level, feeding into the AI risk management system required under Article 9.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "openai_enterprise", "requirement_id": "Enterprise Compliance API \u2014 audit logs", "fit": "partial", "rationale": "ChatGPT Enterprise and the OpenAI API expose workspace audit-log data through the Compliance API and audit logs endpoint, exportable to SIEM and evidence stores. Institutions using OpenAI models in financial workflows can incorporate this vendor capability into the executive model transparency dashboard. This is vendor capability documentation, not regulatory guidance; it covers the vendor side only.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "A2", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal A2 (Oversight of significant adverse impacts) requires defined review and oversight processes for AI systems that can cause significant adverse impact. For institutions using Azure AI services, this goal produces vendor-side governance artifacts that align with the executive model transparency dashboard. The Standard is Microsoft's published internal policy offered as reference practice, not regulatory guidance.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_financial", "requirement_id": "Financial Services Industry Lens \u2014 AWS Well-Architected", "fit": "adjacent", "rationale": "The Financial Services Industry Lens for the AWS Well-Architected Framework describes design principles, risk considerations, and shared-responsibility boundaries for regulated financial workloads on AWS. For AWS-hosted financial AI systems, this supplies the infrastructure-layer support and evidence stream for the executive model transparency dashboard. This is vendor documentation of real AWS capabilities \u2014 it does not substitute for model-layer validation or regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_financial", "requirement_id": "Vertex AI Model Monitoring", "fit": "partial", "rationale": "Vertex AI Model Monitoring detects prediction drift and training-serving skew for models deployed on Google Cloud. For GCP-hosted financial AI systems, this capability supplies the platform-layer support for the executive model transparency dashboard. This is vendor product documentation, not regulatory guidance; it does not address model-layer regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://finance/controls/FD-07", "meta": { "authored_on": "2026-06-29", "schema_version": "1.1.0" }, "validation_objective": "Senior management and the board must receive a consolidated AI model risk dashboard at least quarterly, covering performance metrics, risk indicators, and governance status for the full AI portfolio, with dashboard content reviewed for accuracy by the model risk function before distribution.", "evidence_required": [ "Board AI risk dashboard report with distribution timestamp, recipient list, and version number for each quarterly reporting cycle", "Model inventory extract used to populate the dashboard, showing model count, risk tier, validation status, and outstanding findings for each model in the portfolio", "Dashboard accuracy review sign-off from the model risk officer or designated MRM reviewer, dated before each distribution", "Board or risk committee meeting minutes confirming receipt, review, and any questions or escalations arising from the dashboard for the trailing four quarters" ], "machine_tests": [ "Query dashboard distribution log for last_distributed timestamp per reporting cycle \u2192 assert dashboard was sent to board distribution list within 30 days of each quarter-end", "Compare model inventory record count against dashboard model count field \u2192 assert counts match within defined tolerance (allowing for models entering/exiting portfolio during the period)", "Check dashboard data for MRM_review_signoff field and review_date \u2192 assert both fields are present and review_date precedes distribution_date for each quarterly report", "Scan dashboard for models with validation_status='overdue' or outstanding_findings_count > threshold \u2192 assert all such models are flagged in the executive summary section" ], "human_review": [ "Review the dashboard format and content to confirm it provides actionable information at the appropriate level of abstraction for board and senior management decision-making, without requiring technical expertise to interpret", "Assess whether the model risk indicators on the dashboard (validation currency, performance drift, findings aging) are calibrated to surface emerging concentrations of risk before they become material", "Verify that the dashboard escalation process \u2014 from monitoring team to senior management to board \u2014 operates within defined time windows and that recent escalations were acted upon" ], "blocking_effect": "advisory", "normative_status": "supervisory-guidance", "anti_patterns": [ "Dashboard produced by the same team responsible for model development and deployment, with no independent MRM review before distribution to senior management, creating a reporting conflict of interest", "Dashboard aggregating only models formally registered in the model inventory while excluding AI tools, vendor-provided AI features, and AI components embedded in purchased software that affect financial outputs", "Reporting frequency reduced to annual or semi-annual without documented justification, defeating the ability to detect and escalate emerging model risk concentrations in time for corrective action", "Dashboard presented to the board as a compliance artifact rather than a risk management tool, with no mechanism for board members to request deeper dives or escalate concerns to the model risk function", "Performance metrics on the dashboard lagging by more than one reporting cycle, so the board is reviewing stale data that does not reflect the current state of the portfolio" ], "update_status": "current", "layer_code": "FD" }, { "id": "FD-08", "layer": "FD", "plane": "lifecycle", "name": "Financial Disclosure Evidence Package", "plain": "The institution must compile and maintain a Financial Disclosure Evidence Package that aggregates evidence from FD-01 through FD-07, demonstrating that disclosure obligations across AI decision auditability, adverse action notice, fair lending explainability, regulatory disclosure, consumer notification, SEC filing, and executive reporting are being met.", "threat": { "tags": [ "evidence-fragmentation", "disclosure-assurance-gap", "regulatory-examination-unreadiness", "compliance-evidence-staleness" ], "desc": "Financial disclosure obligations for AI-driven institutions span multiple regulatory regimes, product lines, and internal governance functions. Evidence demonstrating compliance is typically scattered across model risk systems, compliance tracking tools, filing systems, and consumer complaint management platforms. During examinations, institutions that cannot rapidly assemble a coherent, cross-referenced evidence package are perceived as having weak controls regardless of the underlying operational reality. Fragmented evidence also prevents management from assessing the aggregate disclosure compliance posture across the FD layer, creating blind spots that persist until an examination or litigation event forces discovery." }, "standard": [ { "id": "sr26_2", "section": "\u00a7VI (Documentation)", "title": "Documentation and oversight reporting" }, { "id": "sox", "section": "Section 302 & 404", "title": "Disclosure controls certification and ICFR documentation" }, { "id": "pcaob_as_2201", "section": "\u00b6.46", "title": "Risk-based evidence supporting ICFR assessment" }, { "id": "eu_ai_act", "section": "Art. 18", "title": "Documentation obligations for high-risk AI" } ], "sources": [ { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Anthropic's Responsible Scaling Policy v3.3 documents the vendor's capability thresholds and safeguards, cited as third-party AI due diligence context for the apeiris://finance/controls/FD-08 Financial Disclosure Evidence Package control.", "reviewed_on": "2026-07-02" }, { "id": "openai_enterprise_data_governance_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "OpenAI's enterprise privacy and compliance documentation records vendor-side data handling and audit-log capabilities relevant to the apeiris://finance/controls/FD-08 Financial Disclosure Evidence Package control.", "reviewed_on": "2026-07-02" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://finance/controls/FD-08 Financial Disclosure Evidence Package control.", "reviewed_on": "2026-07-01" }, { "id": "aws_financial_services_compliance_2024", "title": "AWS User Guide to Financial Services Regulations & Guidelines in the United States", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/financial-services/security-compliance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_financial_services_compliance_2024", "relationship": "informative_reference", "rationale": "AWS's financial services regulatory guide and compliance tooling document infrastructure-layer capabilities relevant to the apeiris://finance/controls/FD-08 Financial Disclosure Evidence Package control.", "reviewed_on": "2026-07-02" }, { "id": "google_cloud_financial_services_ai_2024", "title": "Google Cloud Explainable AI", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/explainable-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_financial_services_ai_2024", "relationship": "informative_reference", "rationale": "Google Cloud's Explainable AI and Vertex AI model governance documentation describes platform capabilities relevant to the apeiris://finance/controls/FD-08 Financial Disclosure Evidence Package control.", "reviewed_on": "2026-07-02" }, { "id": "okta_financial_services_access_2025", "title": "Okta for Financial Services", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://www.okta.com/solutions/financial-services/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_financial_services_access_2025", "relationship": "informative_reference", "rationale": "Okta's identity products (System Log, access management, Adaptive MFA, Privileged Access) supply identity-layer enforcement and evidence relevant to the apeiris://finance/controls/FD-08 Financial Disclosure Evidence Package control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "A structured FD Evidence Package compiled semi-annually and updated within 30 days of any material control event. Package organized by control (FD-01 through FD-07) with a cover attestation signed by the model risk officer and compliance officer. Each section contains the required artifacts, their version or date, the custodian, and a pass/fail/findings-noted status against the control objective.", "steps": [ "Define the evidence manifest for each FD control: FD-01 (decision audit log coverage report, replay test results), FD-02 (reason-code mapping version log, QA notice review results, notice timeliness report), FD-03 (fair lending explainability analysis, AIR reports, proxy variable scan results), FD-04 (disclosure package completeness report, examiner response log), FD-05 (notification delivery report, human review request SLA compliance), FD-06 (AI risk inventory, materiality assessment, model risk officer sign-off record), FD-07 (board risk committee model risk report, dashboard accuracy test results).", "Build a FD evidence repository with a defined folder structure, access controls, and version control ensuring that each semi-annual package is retained for seven years and that current evidence artifacts are updated within 30 days of a triggering event.", "Implement a FD cover attestation process in which the model risk officer and compliance officer jointly certify the completeness and accuracy of the package before it is finalized, with the attestation stored in the repository as a signed document.", "Conduct a quarterly evidence gap review comparing required evidence artifacts against those present in the repository, generating a gap report that is reviewed by the model risk committee and tracked to remediation." ], "financial_controller": { "summary": "The FD Evidence Package is the documentary support for the financial controller's assessment that AI-related disclosure controls are effective; it must be producible in response to auditor requests under SOX and PCAOB standards.", "actions": [ "Review the FD Evidence Package cover attestation before finalizing the annual ICFR assessment narrative.", "Confirm that external auditors have been informed of the FD Evidence Package as a source document for AI-related ICFR testing.", "Escalate any evidence gap identified in the quarterly gap review that could affect the completeness of the SOX Section 302 certification." ], "failure_signals": [ "FD Evidence Package not finalized before the ICFR assessment sign-off deadline.", "External auditors unable to access required FD evidence artifacts on request.", "Cover attestation missing signatures from both required signatories." ] }, "compliance_officer": { "summary": "The compliance officer co-signs the FD Evidence Package attestation and is responsible for ensuring the package accurately represents the compliance status of the FD layer across all applicable regulatory regimes.", "actions": [ "Review each FD control section of the evidence package before co-signing the cover attestation, confirming that artifacts are current and accurately reflect control operating effectiveness.", "Report the FD evidence gap review results to the compliance committee quarterly and track remediation to closure.", "Maintain a regulatory correspondence log in the FD evidence package documenting all examiner requests and responses related to disclosure obligations." ], "metrics": [ "FD Evidence Package completeness rate: target 100% of required artifacts present at semi-annual compilation.", "Evidence artifact staleness: target zero artifacts more than 90 days old at time of package finalization.", "Evidence gap remediation rate: target 100% within 30 days of gap identification." ], "failure_signals": [ "Cover attestation not signed by both signatories before package finalization.", "Evidence artifact staleness exceeding 90 days for any FD control at time of package compilation.", "Evidence gap outstanding more than 30 days without a documented remediation plan." ] }, "model_risk_officer": { "summary": "The model risk officer co-signs the FD Evidence Package attestation and owns the model-specific evidence artifacts (FD-01, FD-02, FD-03, FD-04, FD-07) that constitute the majority of the package.", "actions": [ "Maintain current evidence artifacts for the model-specific FD controls and confirm their presence in the repository before each semi-annual compilation.", "Review the evidence gap report for model-specific controls and escalate any gap that cannot be remediated within 30 days to the Chief Risk Officer.", "Co-sign the cover attestation after reviewing the complete package and confirming that the model risk evidence accurately represents the current state of the model portfolio." ], "failure_signals": [ "Model-specific evidence artifact missing or stale at time of semi-annual compilation.", "Evidence gap in model controls remaining open beyond 30 days without CRO escalation.", "Attestation signed before all model-specific sections have been reviewed." ] }, "internal_audit": { "summary": "Internal audit independently assesses the completeness and accuracy of the FD Evidence Package, providing the board with assurance that the institution's disclosure compliance posture is as represented.", "actions": [ "Annually audit the FD Evidence Package by verifying the presence and currency of required artifacts for each FD control against the defined evidence manifest.", "Sample five decision records from FD-01 evidence and independently verify they can be retrieved and replayed from the audit log.", "Review the quarterly evidence gap reports and confirm that identified gaps were remediated within the defined SLA, and that persistent gaps were escalated appropriately." ], "failure_signals": [ "FD Evidence Package missing required artifacts for more than one FD control at time of annual audit.", "Decision record sampling revealing gaps in the decision audit log not reflected in the FD-01 evidence artifacts.", "Evidence gap remediation SLA breaches not escalated in the prior 12 months." ] }, "it_operations": { "summary": "IT Operations maintains the FD evidence repository infrastructure, ensuring access controls, version control, retention enforcement, and availability for regulatory production.", "actions": [ "Configure the FD evidence repository with role-based access controls, immutable versioning, and seven-year retention enforcement.", "Implement automated staleness alerts that notify the model risk officer and compliance officer when any evidence artifact approaches the 90-day staleness threshold.", "Ensure the repository is accessible to authorized examiners through a defined production portal with access logging and review." ], "failure_signals": [ "Repository access control audit identifying unauthorized access to FD evidence artifacts.", "Staleness alerts not functioning, resulting in stale artifacts at package compilation.", "Repository unavailable or inaccessible during a regulatory examination." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Institutions with mature MRM programs have the underlying evidence but typically lack a consolidated, cross-functional evidence package designed specifically to demonstrate FD-layer compliance as an integrated whole." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "Model Risk Management", "Compliance", "Internal Audit", "Legal" ], "frameworks": [ { "framework": "sr26_2", "requirement_id": "\u00a7VI (Documentation)", "fit": "direct", "rationale": "SR 26-2 \u00a7VI addresses documentation of model risk management activities under its Documentation subheading, and describes board and senior management oversight in Roles and Responsibilities. Honest scope note: the guidance does not address public or regulator disclosure processes; the FD evidence package uses the \u00a7VI documentation discipline as its foundation.", "normative_force": "supervisory-guidance", "source_version": "2026-04-17", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "sox", "requirement_id": "Section 302 & 404", "fit": "direct", "rationale": "SOX Sections 302 and 404 require that management maintain documentation supporting the assessment that disclosure controls and ICFR are effective. The FD Evidence Package is the primary documentary support for the AI-related components of the SOX certification.", "normative_force": "binding-law", "source_version": "2002", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "satisfies" }, { "framework": "pcaob_as_2201", "requirement_id": "\u00b6.46", "fit": "direct", "rationale": "AS 2201 \u00b6.46 conditions the evidence needed on the risk associated with the control. The financial disclosure evidence package provides the risk-proportionate documentation for disclosure-related AI controls that the auditor evaluates under that standard.", "normative_force": "certification-standard", "source_version": "2007", "reviewed_on": "2026-07-02", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 18", "fit": "direct", "rationale": "Article 18 requires providers of high-risk AI to retain technical documentation, logs, and conformity assessment records for 10 years after the AI system is placed on the market. The FD Evidence Package satisfies the documentation retention and organization requirements for the disclosure-related obligations under the EU AI Act.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "coso_icfr", "requirement_id": "Component 5 \u2014 Monitoring Activities", "fit": "direct", "rationale": "COSO Component 5 requires that monitoring activities generate documentation supporting management's assessment of control effectiveness. The quarterly evidence gap review and semi-annual evidence package compilation are the COSO-required monitoring activities for the FD layer.", "normative_force": "industry-framework", "source_version": "2013", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "informs" }, { "framework": "soc2", "requirement_id": "CC4.1", "fit": "partial", "rationale": "SOC 2 CC4.1 requires that the organization selects, develops, and performs ongoing and separate evaluations to ascertain whether control components are present and functioning. The FD Evidence Package compilation and gap review process satisfies this criterion for the disclosure control domain.", "normative_force": "certification-standard", "source_version": "2022", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "openai_enterprise", "requirement_id": "Enterprise Compliance API \u2014 audit logs", "fit": "partial", "rationale": "ChatGPT Enterprise and the OpenAI API expose workspace audit-log data through the Compliance API and audit logs endpoint, exportable to SIEM and evidence stores. Institutions using OpenAI models in financial workflows can incorporate this vendor capability into the financial disclosure evidence package. This is vendor capability documentation, not regulatory guidance; it covers the vendor side only.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "T2", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal T2 (Communication to stakeholders) requires communicating system capabilities and limitations to stakeholders. For institutions using Azure AI services, this goal produces vendor-side governance artifacts that align with the financial disclosure evidence package. The Standard is Microsoft's published internal policy offered as reference practice, not regulatory guidance.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_financial", "requirement_id": "AWS Artifact", "fit": "partial", "rationale": "AWS Artifact provides on-demand access to AWS's third-party compliance reports (SOC 1/2, PCI DSS, ISO). For AWS-hosted financial AI systems, this supplies the infrastructure-layer support and evidence stream for the financial disclosure evidence package. This is vendor documentation of real AWS capabilities \u2014 it does not substitute for model-layer validation or regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_financial", "requirement_id": "Model Cards", "fit": "partial", "rationale": "Model Cards provide structured, versioned documentation of a model's purpose, performance characteristics, and limitations. For GCP-hosted financial AI systems, this capability supplies the platform-layer support for the financial disclosure evidence package. This is vendor product documentation, not regulatory guidance; it does not address model-layer regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "okta_financial", "requirement_id": "Okta System Log", "fit": "partial", "rationale": "The Okta System Log records authentication and access events with actor, target, outcome, and timestamp detail, exportable for audit retention. Where access to financial AI systems is brokered through Okta, this capability supplies the identity-layer enforcement and evidence for the financial disclosure evidence package. This is vendor product documentation, not a financial-services control framework.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://finance/controls/FD-08", "meta": { "authored_on": "2026-06-29", "schema_version": "1.1.0" }, "validation_objective": "The institution must maintain a Financial Disclosure Evidence Package that aggregates current, signed evidence artifacts from FD-01 through FD-07, with each artifact dated within the evidence freshness window, and the package must be producible within five business days upon regulatory examination request.", "evidence_required": [ "Financial Disclosure Evidence Package index file listing all constituent artifacts with artifact_id, control_reference (FD-01 through FD-07), version, dated_on, and producing_team fields", "Package completeness attestation signed by the Chief Compliance Officer or designated evidence owner confirming all FD-layer controls are represented with current evidence", "Evidence freshness report showing the dated_on field for each artifact compared against the applicable freshness window (e.g., adverse action sample \u226490 days, disclosure committee sign-off \u2264filing cycle)", "Chain-of-custody log recording who assembled the package, when, and any artifacts replaced or updated since the prior examination cycle" ], "machine_tests": [ "Query evidence package index for all FD-layer controls (FD-01 through FD-07) \u2192 assert each control has at least one artifact entry with status='current'", "Compare artifact dated_on field against defined freshness window per control \u2192 assert no artifact exceeds its maximum age threshold at the time of package compilation", "Verify package completeness attestation record exists with signatory field, signature_date, and package_version \u2192 assert signature_date is within 30 days of the most recently updated artifact", "Attempt package retrieval simulation by querying the evidence repository for all FD-tagged artifacts \u2192 assert retrieval completes within a defined SLA and all expected artifact types are returned" ], "human_review": [ "Review the evidence package assembly process to confirm that artifact collection is systematic and automated where possible, reducing the risk that manual assembly errors leave gaps during examination", "Assess the freshness window definitions for each FD-layer control to confirm they are calibrated to the underlying risk cadence and regulatory examination expectations, not set to minimize collection burden", "Verify that the package has been tested in a mock examination exercise within the past 12 months and that any gaps identified were remediated before the current examination cycle" ], "blocking_effect": "requires-review", "normative_status": "binding-law", "anti_patterns": [ "Evidence package assembled reactively upon examination notice rather than maintained on a rolling basis, resulting in stale artifacts or last-minute substitutions that undermine the integrity of the package", "Package index maintained as an uncontrolled spreadsheet with no version history, making it impossible to demonstrate that the package reflects the state of controls at a specific point in time", "Artifacts from FD-01 through FD-07 stored in disparate systems with no single-pane index, requiring manual aggregation under time pressure during examination and increasing the risk of omission", "Evidence freshness windows defined identically for all FD-layer controls regardless of the underlying risk cadence, so time-sensitive artifacts (e.g., adverse action samples) are treated with the same staleness tolerance as annual governance artifacts", "Package completeness attestation signed by the evidence assembler rather than an independent control owner, removing the oversight layer that would detect cross-control coverage gaps" ], "update_status": "current", "layer_code": "FD" }, { "id": "FC-01", "layer": "FC", "plane": "control", "name": "SOX 302/404 Controls over AI-Generated Financial Data", "plain": "Internal controls over financial reporting (ICFR) must explicitly account for AI-generated data that enters financial statements, disclosures, or management assertions, requiring documented control objectives, owners, testing procedures, and deficiency escalation paths specific to AI data production.", "threat": { "tags": [ "icfr-gap", "unattested-ai-output", "material-misstatement", "control-design-deficiency" ], "desc": "Without explicit ICFR controls scoped to AI-generated data, management certifications under SOX Section 302 and auditor attestations under Section 404 may rest on assertions that do not account for AI model error, drift, or manipulation. Undetected deficiencies in AI data production pipelines can propagate into audited financial statements, creating material misstatement risk and potential securities law liability for certifying officers." }, "standard": [ { "id": "sox", "section": "\u00a7302, \u00a7404", "title": "Management and auditor attestation of ICFR" }, { "id": "coso_icfr", "section": "Principle 10-12", "title": "Control activities over AI-generated financial data" }, { "id": "pcaob_as_2201", "section": "\u00b6.14-.18", "title": "Planning the ICFR audit \u2014 risk-based scoping" }, { "id": "sr26_2", "section": "\u00a7V (Validation and Monitoring)", "title": "Model validation applied to financial reporting models" } ], "sources": [ { "id": "openai_enterprise_data_governance_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "OpenAI's enterprise privacy and compliance documentation records vendor-side data handling and audit-log capabilities relevant to the apeiris://finance/controls/FC-01 SOX 302/404 Controls over AI-Generated Financial Data control.", "reviewed_on": "2026-07-02" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://finance/controls/FC-01 SOX 302/404 Controls over AI-Generated Financial Data control.", "reviewed_on": "2026-07-01" }, { "id": "aws_financial_services_compliance_2024", "title": "AWS User Guide to Financial Services Regulations & Guidelines in the United States", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/financial-services/security-compliance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_financial_services_compliance_2024", "relationship": "informative_reference", "rationale": "AWS's financial services regulatory guide and compliance tooling document infrastructure-layer capabilities relevant to the apeiris://finance/controls/FC-01 SOX 302/404 Controls over AI-Generated Financial Data control.", "reviewed_on": "2026-07-02" }, { "id": "google_cloud_financial_services_ai_2024", "title": "Google Cloud Explainable AI", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/explainable-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_financial_services_ai_2024", "relationship": "informative_reference", "rationale": "Google Cloud's Explainable AI and Vertex AI model governance documentation describes platform capabilities relevant to the apeiris://finance/controls/FC-01 SOX 302/404 Controls over AI-Generated Financial Data control.", "reviewed_on": "2026-07-02" }, { "id": "okta_financial_services_access_2025", "title": "Okta for Financial Services", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://www.okta.com/solutions/financial-services/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_financial_services_access_2025", "relationship": "informative_reference", "rationale": "Okta's identity products (System Log, access management, Adaptive MFA, Privileged Access) supply identity-layer enforcement and evidence relevant to the apeiris://finance/controls/FC-01 SOX 302/404 Controls over AI-Generated Financial Data control.", "reviewed_on": "2026-07-02" }, { "id": "finra_rn_24_09", "title": "FINRA Regulatory Notice 24-09 \u2014 Generative AI and Large Language Models", "authority": "Financial Industry Regulatory Authority (FINRA)", "source_type": "guidance", "normative_force": "supervisory-guidance", "version": "2024", "published_on": "2024-06-27", "retrieved_on": "2026-06-29", "canonical_url": "https://www.finra.org/rules-guidance/notices/24-09", "license": "public-domain", "status": "current", "flagship": false, "source_id": "finra_rn_24_09", "relationship": "supporting_guidance", "rationale": "Establishes FINRA Regulatory Notice 24-09 \u2014 Generative AI and Large Language Models requirements informing the apeiris://finance/controls/FC-01 SOX 302/404 Controls over AI-Generated Financial Data control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Extend the ICFR control library to include an AI-data-in-scope inventory; map each AI-generated data element to a financial statement line item; assign control owners; document testing procedures; integrate AI control test results into the annual 404 assessment package.", "steps": [ "Inventory all AI systems whose outputs influence financial statement line items, disclosures, or management estimates; record model ID, data element, line item, and materiality threshold.", "For each in-scope AI system, design a preventive or detective control addressing input validation, output reasonableness, override monitoring, and change notification; assign a named control owner.", "Integrate AI-specific control test results, deficiency logs, and remediation evidence into the consolidated ICFR assessment submitted to external auditors under SOX 404." ], "financial_controller": { "summary": "You are the certifying officer under SOX 302. Your certification must reflect the actual state of controls, including controls over AI-generated data. Ensure the AI control inventory is complete before signing.", "actions": [ "Review the AI-data-in-scope inventory quarterly and confirm completeness with the model risk officer.", "Attest that AI-specific ICFR controls have been tested and any deficiencies disclosed in the Section 302 certification memo.", "Escalate any untested AI control to external auditors as a scope limitation before period close." ], "failure_signals": [ "AI system producing financial data not present in the ICFR control library.", "Control owner vacancies for AI-data controls exceeding 30 days.", "External auditor identifies AI data source not included in management's 404 assessment." ] }, "model_risk_officer": { "summary": "Model risk governance artifacts are the primary evidence base for ICFR controls over AI outputs. Align model validation cycles with financial reporting calendars.", "actions": [ "Provide the financial controller with model inventory exports scoped to financial-reporting use cases ahead of each reporting period.", "Flag models approaching end-of-validation or with open high-severity findings to the ICFR control owner before period close.", "Deliver model performance metrics and exception counts as control evidence for the 404 assessment." ], "failure_signals": [ "Model validation overdue for any in-scope financial model at period close.", "High-severity model finding unresolved at time of 302 certification.", "Model output deviation exceeding materiality threshold not escalated within SLA." ] }, "compliance_officer": { "summary": "Monitor regulatory developments in SOX guidance covering AI-generated financial data. Maintain the control library mapping between COSO principles and AI-specific controls.", "actions": [ "Map each AI-specific ICFR control to a COSO principle and document the rationale.", "Track SEC staff guidance and PCAOB inspection findings related to AI in financial reporting and update controls accordingly.", "Conduct annual readiness review of AI ICFR controls prior to external audit kickoff." ], "metrics": [ "AI ICFR control coverage: percentage of AI-generated financial data elements with a mapped control \u2014 target 100%.", "Deficiency rate: number of AI ICFR control deficiencies per reporting period \u2014 target zero material weaknesses.", "Timely remediation: percentage of significant deficiencies remediated within 90 days \u2014 target 100%." ], "failure_signals": [ "Control mapping not updated within 60 days of a material AI system change.", "Regulatory guidance issued without a corresponding control library review.", "Repeat deficiency in the same AI control for two consecutive annual assessments." ] }, "internal_audit": { "summary": "Internal audit is responsible for testing AI-specific ICFR controls and reporting deficiencies. Design test procedures that validate both design effectiveness and operating effectiveness.", "actions": [ "Select a sample of AI-generated financial data elements each quarter; trace outputs back to source model, validate against independent data, and document findings.", "Test override logs for AI-generated data: verify all overrides were approved, documented, and reviewed by a control owner.", "Report AI ICFR test results to the audit committee with explicit pass/fail for each control objective." ], "failure_signals": [ "AI control test coverage below 80% of in-scope controls in any quarter.", "Override logs missing approvals for more than 2% of sampled transactions.", "Deficiency reported to management but not reflected in 404 assessment package." ] }, "it_operations": { "summary": "IT Operations runs controls automation over AI data flows into financial systems behind SOX 302/404 controls over AI-generated financial data \u2014 integrating it with deployment pipelines, enforcing the automated gates, and keeping the supporting data flows reliable and auditable.", "actions": [ "Integrate controls automation over AI data flows into financial systems with CI/CD and runtime tooling so that AI-generated figures enter financial systems only through controlled, logged interfaces.", "Automate collection and retention of interface logs and control-execution records in immutable, hash-verified storage.", "Monitor pipeline and integration health and alert when uncontrolled paths write AI outputs into financial systems." ], "failure_signals": [ "Production changes bypass the automated gate so that it is no longer true that AI-generated figures enter financial systems only through controlled, logged interfaces.", "Gaps or outages in interface logs and control-execution records collection exceeding 24 hours.", "Manual, untracked edits to controls automation over AI data flows into financial systems records." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Most enterprises have ICFR frameworks that predate widespread AI adoption; AI-specific controls are typically informal or absent from the control library." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai" ], "implementers": [ "Financial Controller", "Model Risk Officer", "Internal Audit", "External Auditors" ], "frameworks": [ { "framework": "sox", "requirement_id": "\u00a7302, \u00a7404", "fit": "direct", "rationale": "SOX Sections 302 and 404 require management to establish, assess, and certify ICFR. AI systems that produce data entering financial statements are in scope for this requirement. Explicit AI-specific controls are necessary to support valid management certifications.", "normative_force": "binding-law", "source_version": "2002 as amended", "reviewed_on": "2026-06-28", "basis": "asserted", "relation": "satisfies" }, { "framework": "coso_icfr", "requirement_id": "Principles 10-12", "fit": "direct", "rationale": "COSO ICIF 2013 Principles 10-12 address control activities, including the selection and development of controls over technology. AI systems that influence financial reporting are a class of technology requiring explicit control design under COSO's framework.", "normative_force": "industry-framework", "source_version": "2013", "reviewed_on": "2026-06-28", "basis": "asserted", "relation": "informs" }, { "framework": "pcaob_as_2201", "requirement_id": "\u00b6.14-.18", "fit": "direct", "rationale": "AS 2201 \u00b6.14-.18 require the auditor to plan the ICFR audit and use a risk-based approach in determining scope. AI systems generating financial data are within that planning scope; FC-01's control inventory over AI-generated financial data is the management-side artifact that supports audit scoping. Category note: AS 2201 governs the auditor \u2014 management's own assessment duties come from SEC rules under SOX \u00a7404(a).", "normative_force": "certification-standard", "source_version": "2007 as amended", "reviewed_on": "2026-07-02", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "sr26_2", "requirement_id": "\u00a7V (Validation and Monitoring)", "fit": "partial", "rationale": "SR 26-2 \u00a7V describes the validation elements \u2014 conceptual soundness, outcomes analysis, ongoing monitoring \u2014 that produce the artifacts FC-01 reuses as ICFR control evidence. The guidance is addressed to banking organizations and is non-enforceable, but it remains the most operationally mature reference for validating models used in financial reporting.", "normative_force": "supervisory-guidance", "source_version": "2026-04-17", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "omb_a_123", "requirement_id": "Section III.A", "fit": "adjacent", "rationale": "OMB Circular A-123 (M-16-17) Section III.A describes governance and the integration of risk management with internal control processes. SOX-style control governance over AI-generated financial data parallels the circular's internal-control governance expectations for federal reporting entities.", "normative_force": "supervisory-guidance", "source_version": "2016", "reviewed_on": "2026-07-02", "basis": "asserted", "relation": "satisfies" }, { "framework": "openai_enterprise", "requirement_id": "Enterprise Compliance API \u2014 audit logs", "fit": "partial", "rationale": "ChatGPT Enterprise and the OpenAI API expose workspace audit-log data through the Compliance API and audit logs endpoint, exportable to SIEM and evidence stores. Institutions using OpenAI models in financial workflows can incorporate this vendor capability into SOX 302/404 controls over AI-generated financial data. This is vendor capability documentation, not regulatory guidance; it covers the vendor side only.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "A3", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal A3 (Fit for purpose) requires evidence that the system is fit for the purpose it will serve. For institutions using Azure AI services, this goal produces vendor-side governance artifacts that align with SOX 302/404 controls over AI-generated financial data. The Standard is Microsoft's published internal policy offered as reference practice, not regulatory guidance.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_financial", "requirement_id": "AWS Audit Manager", "fit": "partial", "rationale": "AWS Audit Manager automates evidence collection against control frameworks for AWS workloads, and AWS CloudTrail records account-level API activity. For AWS-hosted financial AI systems, this supplies the infrastructure-layer support and evidence stream for SOX 302/404 controls over AI-generated financial data. This is vendor documentation of real AWS capabilities \u2014 it does not substitute for model-layer validation or regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_financial", "requirement_id": "Vertex AI Model Registry", "fit": "partial", "rationale": "Vertex AI Model Registry provides versioned model registration, aliases, and deployment state tracking on Google Cloud. For GCP-hosted financial AI systems, this capability supplies the platform-layer support for SOX 302/404 controls over AI-generated financial data. This is vendor product documentation, not regulatory guidance; it does not address model-layer regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "okta_financial", "requirement_id": "Okta System Log", "fit": "adjacent", "rationale": "The Okta System Log records authentication and access events with actor, target, outcome, and timestamp detail, exportable for audit retention. Where access to financial AI systems is brokered through Okta, this capability supplies the identity-layer enforcement and evidence for SOX 302/404 controls over AI-generated financial data. This is vendor product documentation, not a financial-services control framework.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "finra", "requirement_id": "Regulatory Notice 24-09 (GenAI and LLMs)", "fit": "partial", "rationale": "FINRA Regulatory Notice 24-09 reminds member firms that use of generative AI and large language models remains subject to existing obligations \u2014 including Rule 3110 supervision of AI-supported functions. Firms incorporating GenAI outputs into books-and-records or financial reporting workflows should treat FC-01's ICFR controls as part of the reasonably designed supervisory system the notice describes.", "normative_force": "supervisory-guidance", "source_version": "2024-06-27", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" } ], "canonical_id": "apeiris://finance/controls/FC-01", "meta": { "authored_on": "2026-06-29", "schema_version": "1.1.0" }, "validation_objective": "Every AI system whose outputs enter financial statements, disclosures, or management assertions must have a documented ICFR control objective, a named control owner, and evidence of operating effectiveness testing, with no AI-generated financial data reaching the general ledger or disclosed externally without passing through a documented ICFR control point.", "evidence_required": [ "ICFR control inventory record for each in-scope AI system, including system_id, control_objective, control_owner, control_type (preventive/detective), and testing_frequency fields", "Control operating effectiveness test results for each AI-related ICFR control, signed by the tester and reviewed by internal audit, for the trailing four quarters", "SOX scoping decision memo documenting the rationale for including or excluding each AI system from ICFR scope, approved by the CFO or Controller", "Deficiency log for AI-related ICFR controls, including deficiency classification (deficiency / significant deficiency / material weakness), remediation plan, and remediation completion date" ], "machine_tests": [ "Query ICFR control inventory for all AI systems tagged as affecting financial reporting \u2192 assert each has a control_owner field, a testing_frequency field, and at least one completed test in the trailing 12 months", "Cross-reference AI system IDs in the model inventory against ICFR control inventory \u2192 assert every model with financial_reporting_impact=true has at least one corresponding ICFR control record", "Check deficiency log for any AI-related ICFR deficiency classified as significant_deficiency or material_weakness \u2192 assert each has a remediation_plan_date within 30 days of identification and a remediation_completion_date within the disclosed remediation window", "Verify SOX scoping decision memo exists for each AI system added to or removed from ICFR scope in the trailing 12 months \u2192 assert memo is signed by CFO or Controller" ], "human_review": [ "Review the ICFR scoping process to confirm that AI systems affecting financial reporting are identified through a systematic inventory sweep rather than relying on business units to self-report AI use", "Assess the design effectiveness of each AI-related ICFR control to confirm that the control objective is specific enough to detect the material misstatement scenarios identified in the risk assessment", "Verify that external auditors have been informed of all in-scope AI systems and that the external auditor's reliance on management's assessment does not exclude AI-related controls from their testing scope" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Treating AI systems as IT general controls rather than application-level ICFR controls, resulting in the ICFR program testing infrastructure availability but not the accuracy and completeness of AI-generated financial data", "Scoping AI systems out of ICFR by defining the financial reporting boundary at the point where AI output enters a human review step, then documenting that human review as the only ICFR control while leaving the AI output itself untested", "Relying on the AI vendor's SOC 2 Type II report as the sole ICFR control evidence for an AI system, without evaluating whether the SOC 2 scope covers the specific financial data processing functions in use", "Documenting control objectives at the system level ('the model produces accurate estimates') without decomposing to the assertion level (existence, completeness, valuation) required for ICFR testing", "Allowing AI model updates to take effect in the production financial reporting environment without triggering a reassessment of the ICFR control design for the updated model" ], "update_status": "current", "layer_code": "FC" }, { "id": "FC-02", "layer": "FC", "plane": "control", "name": "AI-Generated Output Materiality Assessment", "plain": "A formal materiality assessment process must evaluate whether AI-generated financial data or AI-driven decisions could, individually or in aggregate, be material to financial reporting, investor disclosures, or regulatory submissions, and must trigger heightened controls and disclosure review when the materiality threshold is approached or crossed.", "threat": { "tags": [ "undisclosed-material-ai", "aggregation-blindness", "misstatement-accumulation", "investor-harm" ], "desc": "Individually immaterial AI outputs may aggregate into a material misstatement that evades detection because no single output crosses the disclosure threshold. Without a formal aggregation process, management may certify financial statements that are collectively misleading. Additionally, SEC disclosure obligations around material AI risks may be triggered without management's awareness if no process exists to evaluate materiality of AI-driven financial data." }, "standard": [ { "id": "sox", "section": "\u00a7302(a)(4)", "title": "Disclosure of material information to auditors and audit committee" }, { "id": "coso_icfr", "section": "Principle 6", "title": "Risk assessment \u2014 specification of objectives" }, { "id": "pcaob_as_2201", "section": "\u00b6.20", "title": "Materiality in the audit of internal control" }, { "id": "sr26_2", "section": "\u00a7III", "title": "Risk-based intensity of model risk management" } ], "sources": [ { "id": "openai_enterprise_data_governance_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "OpenAI's enterprise privacy and compliance documentation records vendor-side data handling and audit-log capabilities relevant to the apeiris://finance/controls/FC-02 AI-Generated Output Materiality Assessment control.", "reviewed_on": "2026-07-02" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://finance/controls/FC-02 AI-Generated Output Materiality Assessment control.", "reviewed_on": "2026-07-01" }, { "id": "aws_financial_services_compliance_2024", "title": "AWS User Guide to Financial Services Regulations & Guidelines in the United States", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/financial-services/security-compliance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_financial_services_compliance_2024", "relationship": "informative_reference", "rationale": "AWS's financial services regulatory guide and compliance tooling document infrastructure-layer capabilities relevant to the apeiris://finance/controls/FC-02 AI-Generated Output Materiality Assessment control.", "reviewed_on": "2026-07-02" }, { "id": "google_cloud_financial_services_ai_2024", "title": "Google Cloud Explainable AI", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/explainable-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_financial_services_ai_2024", "relationship": "informative_reference", "rationale": "Google Cloud's Explainable AI and Vertex AI model governance documentation describes platform capabilities relevant to the apeiris://finance/controls/FC-02 AI-Generated Output Materiality Assessment control.", "reviewed_on": "2026-07-02" }, { "id": "sec_predictive_analytics_2023", "title": "SEC \u2014 Conflicts of Interest Associated with the Use of Predictive Data Analytics by Broker-Dealers and Investment Advisers", "authority": "U.S. Securities and Exchange Commission (SEC)", "source_type": "guidance", "normative_force": "informative-reference", "version": "2023 Proposed Rule", "published_on": "2023-07-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.sec.gov/rules/proposed/2023/34-97990.pdf", "license": "public-domain", "status": "withdrawn", "flagship": false, "source_id": "sec_predictive_analytics_2023", "relationship": "supporting_guidance", "rationale": "The SEC's 2023 predictive data analytics proposal (Release 34-97990) was withdrawn on 2025-06-12 and imposes no obligations; retained as historical context for the apeiris://finance/controls/FC-02 AI-Generated Output Materiality Assessment control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Establish a quantitative materiality threshold (typically 5% of pre-tax income or an audit-committee-approved figure); map all AI-generated financial data elements to this threshold; implement an automated aggregation monitor that sums AI-originated values per financial statement line and alerts when aggregate exposure exceeds 50% or 75% of the threshold; conduct a formal materiality conclusion at each period close.", "steps": [ "Define quantitative and qualitative materiality thresholds in coordination with external auditors; document the rationale and obtain audit committee approval.", "Build an aggregation ledger that records every AI-generated data element, its financial statement line item, and its dollar value; compute rolling aggregates per line item and per reporting period.", "Implement threshold alerts at 50% and 75% of materiality; require a formal written materiality conclusion from the financial controller before period close when AI aggregate exposure exceeds 25% of threshold." ], "financial_controller": { "summary": "Materiality conclusions are your direct responsibility as certifying officer. The aggregation ledger must be reviewed and signed off before each period close.", "actions": [ "Review the AI aggregation ledger output at each month-end and quarter-end; document the materiality conclusion in the period-close checklist.", "Escalate to external auditors and the audit committee when AI-originated data aggregate exceeds 50% of the quantitative materiality threshold.", "Update the materiality threshold document annually or when a significant change in the AI system portfolio occurs." ], "failure_signals": [ "Aggregation ledger not reviewed before period-close sign-off.", "AI-originated aggregate crossing 75% of threshold without formal escalation.", "Materiality threshold not updated for more than 18 months." ] }, "model_risk_officer": { "summary": "Model risk classification must incorporate materiality \u2014 models whose outputs are material to financial reporting require the highest validation rigor and the shortest revalidation cadence.", "actions": [ "Tag each model in the inventory with its financial-reporting materiality classification: non-material, approaching-material, or material.", "Escalate any model reclassification from non-material to approaching-material to the financial controller within five business days.", "Ensure material-classification models undergo validation at least annually and after any significant change." ], "failure_signals": [ "Model contributing to a material financial line item classified as non-material in the inventory.", "Reclassification notification delayed beyond five business days.", "Material model missing annual validation." ] }, "compliance_officer": { "summary": "Monitor SEC guidance on AI materiality disclosures and ensure the materiality assessment process triggers required disclosures to investors and regulators.", "actions": [ "Review SEC Staff Accounting Bulletins and comment letter trends on AI materiality; update assessment methodology accordingly.", "Confirm that the materiality conclusion is reflected in 10-K/10-Q MD&A disclosures when AI-originated data is material.", "Maintain a log of materiality conclusions and disclosure decisions for regulator examination." ], "metrics": [ "Materiality conclusion completion rate: percentage of period closes with a documented AI materiality conclusion \u2014 target 100%.", "Threshold alert response time: hours from alert trigger to formal escalation \u2014 target under 24 hours.", "Disclosure accuracy: number of required AI materiality disclosures omitted from filings \u2014 target zero." ], "failure_signals": [ "Period close completed without documented materiality conclusion.", "SEC comment letter identifying missing AI materiality disclosure.", "Threshold alert unresolved at period close." ] }, "internal_audit": { "summary": "Test the completeness of the aggregation ledger and the integrity of the materiality conclusion process.", "actions": [ "Annually sample AI-generated data flows and verify each is captured in the aggregation ledger; report coverage gaps.", "Test the threshold alert mechanism by injecting test values; verify alerts fire and are escalated per procedure.", "Review materiality conclusion documentation for three prior periods; assess consistency and completeness." ], "failure_signals": [ "Aggregation ledger coverage below 95% of known AI data flows.", "Threshold alert mechanism fails test injection.", "Materiality conclusion documentation missing or unsigned for any reviewed period." ] }, "it_operations": { "summary": "IT Operations runs materiality tagging in data pipelines behind materiality assessment of AI-generated financial outputs \u2014 integrating it with deployment pipelines, enforcing the automated gates, and keeping the supporting data flows reliable and auditable.", "actions": [ "Integrate materiality tagging in data pipelines with CI/CD and runtime tooling so that AI outputs carry their materiality classification through the reporting stack.", "Automate collection and retention of classification records and propagation checks in immutable, hash-verified storage.", "Monitor pipeline and integration health and alert when material outputs lose their classification in transit." ], "failure_signals": [ "Production changes bypass the automated gate so that it is no longer true that AI outputs carry their materiality classification through the reporting stack.", "Gaps or outages in classification records and propagation checks collection exceeding 24 hours.", "Manual, untracked edits to materiality tagging in data pipelines records." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Formal AI materiality aggregation processes are rare; most enterprises rely on qualitative judgment without a structured aggregation ledger." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai" ], "implementers": [ "Financial Controller", "Model Risk Officer", "Compliance Officer", "External Auditors" ], "frameworks": [ { "framework": "sox", "requirement_id": "\u00a7302(a)(4)", "fit": "direct", "rationale": "SOX 302(a)(4) requires certifying officers to disclose material information to auditors and the audit committee. A formal AI materiality assessment is necessary for certifying officers to fulfill this obligation when AI generates data included in financial statements.", "normative_force": "binding-law", "source_version": "2002 as amended", "reviewed_on": "2026-06-28", "basis": "asserted", "relation": "satisfies" }, { "framework": "coso_icfr", "requirement_id": "Principle 6", "fit": "direct", "rationale": "COSO Principle 6 requires management to specify objectives with sufficient clarity to identify and assess risks. Materiality is the quantitative anchor for this risk assessment; without a defined threshold applied to AI data, risk identification is incomplete.", "normative_force": "industry-framework", "source_version": "2013", "reviewed_on": "2026-06-28", "basis": "asserted", "relation": "informs" }, { "framework": "pcaob_as_2201", "requirement_id": "\u00b6.20", "fit": "direct", "rationale": "AS 2201 \u00b6.20 requires the auditor to use the same materiality in the ICFR audit as in the financial statement audit. FC-02's materiality assessment of AI-generated outputs determines which model outputs fall within that materiality lens and therefore which model-dependent controls the auditor must address.", "normative_force": "certification-standard", "source_version": "2007 as amended", "reviewed_on": "2026-07-02", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "bcbs_239", "requirement_id": "Principle 2", "fit": "partial", "rationale": "BCBS 239 Principle 2 (Data architecture and IT infrastructure) requires banks to design data architecture and IT infrastructure that fully supports risk data aggregation in normal times and stress. Knowing which AI-generated outputs are material \u2014 FC-02's purpose \u2014 is a scoping prerequisite for deciding which data flows that architecture must cover; the fit is partial.", "normative_force": "supervisory-guidance", "source_version": "2013", "reviewed_on": "2026-07-02", "basis": "asserted", "relation": "satisfies" }, { "framework": "eu_ai_act", "requirement_id": "Art. 9, Annex III point 5(b)", "fit": "adjacent", "rationale": "EU AI Act Art. 9 requires a risk management system for high-risk AI systems; in finance the high-risk classification is specific \u2014 Annex III point 5(b) covers AI used to evaluate creditworthiness or establish credit scores of natural persons (and 5(c) life/health insurance risk assessment and pricing). Materiality assessment determines which AI outputs warrant that treatment and which financial-reporting outputs are material under ICFR.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "microsoft_rai", "requirement_id": "T2", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal T2 (Communication to stakeholders) requires communicating system capabilities and limitations to stakeholders. For institutions using Azure AI services, this goal produces vendor-side governance artifacts that align with materiality assessment of AI-generated financial outputs. The Standard is Microsoft's published internal policy offered as reference practice, not regulatory guidance.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_financial", "requirement_id": "AWS Artifact", "fit": "partial", "rationale": "AWS Artifact provides on-demand access to AWS's third-party compliance reports (SOC 1/2, PCI DSS, ISO). For AWS-hosted financial AI systems, this supplies the infrastructure-layer support and evidence stream for materiality assessment of AI-generated financial outputs. This is vendor documentation of real AWS capabilities \u2014 it does not substitute for model-layer validation or regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_financial", "requirement_id": "Explainable AI", "fit": "partial", "rationale": "Google Cloud's Explainable AI documentation (cloud.google.com/explainable-ai) describes feature attribution and explanation tooling available through Vertex AI. For GCP-hosted financial AI systems, this capability supplies the platform-layer support for materiality assessment of AI-generated financial outputs. This is vendor product documentation, not regulatory guidance; it does not address model-layer regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "sec_ai", "requirement_id": "Proposed rule, Release 34-97990 (withdrawn 2025-06-12)", "fit": "adjacent", "rationale": "The SEC's 2023 proposed conflicts-of-interest rule for predictive data analytics (Release No. 34-97990) would have required broker-dealers and investment advisers to evaluate and neutralize conflicts arising from covered technologies. The Commission withdrew the proposal on 2025-06-12; it never took effect and imposes no obligations. It is retained here only as historical context for the materiality-assessment discipline FC-02 implements \u2014 no current SEC rule requires this control.", "normative_force": "informative-reference", "source_version": "34-97990 (2023; withdrawn 2025)", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" } ], "canonical_id": "apeiris://finance/controls/FC-02", "meta": { "authored_on": "2026-06-29", "schema_version": "1.1.0" }, "validation_objective": "A formal materiality assessment must be completed for each AI system whose outputs could affect financial reporting, documenting both quantitative and qualitative materiality factors, and the assessment must be reviewed by the CFO or Controller before the institution makes any public assertion that AI-generated data is not material.", "evidence_required": [ "Materiality assessment worksheet for each in-scope AI system, including quantitative materiality calculation (volume \u00d7 average output value as a percentage of net income or total assets) and qualitative factors (regulatory sensitivity, investor focus, precedent)", "Aggregation analysis record showing combined materiality of all AI-generated financial outputs assessed individually as immaterial, signed by the Controller", "CFO or Controller review sign-off on each materiality assessment with date and any override or escalation decisions documented", "Materiality threshold policy document defining quantitative thresholds, qualitative factors, and the aggregation methodology, approved by the Audit Committee" ], "machine_tests": [ "Query materiality assessment records for all AI systems with financial_reporting_impact=possible \u2192 assert each has a completed quantitative_materiality_calculation field and a qualitative_factors field with at least one entry", "Compute aggregated AI output volume across all individually-immaterial AI systems and compare against institutional materiality threshold \u2192 assert aggregation result is captured in the aggregation analysis record and reviewed", "Check CFO_review_signoff field and review_date on each materiality assessment \u2192 assert field is present and review_date is within the current fiscal period for assessments supporting the most recent filing", "Cross-reference materiality assessment conclusions against AI risk inventory materiality flags \u2192 assert no inconsistency between the assessment conclusion and the inventory flag for any system" ], "human_review": [ "Review the materiality threshold policy to confirm that qualitative factors (regulatory sensitivity, reputational risk, investor expectations) are given appropriate weight alongside quantitative thresholds, and that the policy has been reviewed by external auditors", "Assess the aggregation analysis methodology to confirm it captures all AI-generated outputs that could combine to produce a material misstatement, including outputs from different systems that feed the same financial statement line item", "Verify that materiality assessments are refreshed when AI system scope, output volume, or business context changes materially, not only on the annual fiscal year cycle" ], "blocking_effect": "requires-review", "normative_status": "binding-law", "anti_patterns": [ "Applying a single fixed quantitative materiality threshold (e.g., 5% of net income) to all AI outputs without considering qualitative factors that can make individually immaterial items material in context", "Assessing each AI system's output in isolation without conducting an aggregation analysis, allowing individually immaterial AI-generated items to accumulate into a material misstatement that was never assessed", "Treating the materiality assessment as a one-time exercise performed at AI system deployment rather than an ongoing process that is refreshed when the system's output volume, use cases, or business context change", "Delegating the materiality conclusion to the model development team rather than finance leadership, removing the independence required for a credible CFO certification", "Excluding AI outputs that pass through a human review step from the materiality assessment on the grounds that human review eliminates the AI-generated risk, without verifying that the review is substantive enough to detect errors" ], "update_status": "current", "layer_code": "FC" }, { "id": "FC-03", "layer": "FC", "plane": "control", "name": "Reconciliation Controls for AI-Influenced Financial Outputs", "plain": "AI-generated financial outputs must be reconciled against independent sources \u2014 including ledger systems, human analyst estimates, or prior-period benchmarks \u2014 on a defined frequency, with unexplained variances above a tolerance threshold investigated, documented, and escalated before the data is used in financial reporting.", "threat": { "tags": [ "undetected-model-error", "data-pipeline-corruption", "silent-drift", "unreconciled-variance" ], "desc": "AI models can produce plausible-looking but incorrect financial outputs due to data pipeline corruption, silent model drift, or adversarial manipulation of input data. Without independent reconciliation, these errors propagate directly into financial statements. Unlike human calculation errors, AI errors can be systematic and consistently wrong across many transactions, amplifying financial statement impact before detection." }, "standard": [ { "id": "sox", "section": "\u00a7404(a)", "title": "Management assessment of ICFR including reconciliation controls" }, { "id": "coso_icfr", "section": "Principle 10-11", "title": "Control activities \u2014 reconciliation and verification" }, { "id": "aicpa_soc2", "section": "CC6.1, CC7.2", "title": "Logical access and change detection for financial data" }, { "id": "bcbs_239", "section": "Principle 3", "title": "Accuracy and integrity \u2014 reconciliation of risk and accounting data" } ], "sources": [ { "id": "openai_enterprise_data_governance_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "OpenAI's enterprise privacy and compliance documentation records vendor-side data handling and audit-log capabilities relevant to the apeiris://finance/controls/FC-03 Reconciliation Controls for AI-Influenced Financial Outputs control.", "reviewed_on": "2026-07-02" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://finance/controls/FC-03 Reconciliation Controls for AI-Influenced Financial Outputs control.", "reviewed_on": "2026-07-01" }, { "id": "aws_financial_services_compliance_2024", "title": "AWS User Guide to Financial Services Regulations & Guidelines in the United States", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/financial-services/security-compliance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_financial_services_compliance_2024", "relationship": "informative_reference", "rationale": "AWS's financial services regulatory guide and compliance tooling document infrastructure-layer capabilities relevant to the apeiris://finance/controls/FC-03 Reconciliation Controls for AI-Influenced Financial Outputs control.", "reviewed_on": "2026-07-02" }, { "id": "google_cloud_financial_services_ai_2024", "title": "Google Cloud Explainable AI", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/explainable-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_financial_services_ai_2024", "relationship": "informative_reference", "rationale": "Google Cloud's Explainable AI and Vertex AI model governance documentation describes platform capabilities relevant to the apeiris://finance/controls/FC-03 Reconciliation Controls for AI-Influenced Financial Outputs control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Define a reconciliation frequency (daily for high-materiality outputs, weekly/monthly for others); pair each AI output with an independent reference source; compute variance; apply a tolerance threshold; route above-threshold variances to an investigation queue with mandatory resolution before period close.", "steps": [ "Map every AI-generated financial output to an independent reference source (GL system of record, prior model version, human analyst estimate, or regulatory benchmark); document the pairing and tolerance threshold for each.", "Implement automated daily or period-end reconciliation jobs that compute AI-output vs. reference-source variance; log results to an immutable reconciliation ledger accessible to both internal and external auditors.", "Establish a variance investigation workflow: variances above threshold trigger a case in the financial exception management system (FC-06); cases must be resolved with root-cause documentation before the AI output is accepted into financial reporting." ], "financial_controller": { "summary": "Reconciliation sign-off is a pre-condition for period-close certification. No AI-generated data element may enter a financial statement without a completed reconciliation record.", "actions": [ "Review the reconciliation ledger dashboard weekly; confirm all above-threshold variances have open investigation cases.", "Approve or reject AI-generated financial outputs for period-close inclusion based on reconciliation status.", "Ensure the reconciliation ledger is provided to external auditors as supporting evidence for the 404 assessment." ], "failure_signals": [ "AI-generated data accepted into financial reporting with an unresolved above-threshold variance.", "Reconciliation job failures not remediated within 24 hours.", "Reconciliation ledger not accessible to external auditors at audit kickoff." ] }, "model_risk_officer": { "summary": "Persistent reconciliation variances are a signal of model degradation. Use reconciliation results as an early-warning input to the model performance monitoring program.", "actions": [ "Subscribe to above-threshold variance alerts for all in-scope financial AI systems; assess whether variances indicate model drift requiring revalidation.", "Track variance trend over time; escalate to the financial controller and request emergency revalidation when variance trend is increasing across three consecutive periods.", "Update model validation test coverage to include the most frequent variance scenarios identified in reconciliation." ], "failure_signals": [ "Persistent above-threshold variance not triggering a model revalidation review.", "Variance trend increasing for three periods without escalation.", "Reconciliation gap not included in model risk report." ] }, "internal_audit": { "summary": "Test the completeness, accuracy, and timeliness of the reconciliation process. Verify that above-threshold variances are investigated and resolved before period close.", "actions": [ "Sample 20% of reconciliation records each quarter; verify the AI output, reference source value, variance, and investigation case linkage are all correctly populated.", "Confirm that all above-threshold variances from the sampled period have closed investigation cases with root-cause documentation.", "Assess reconciliation control design: verify the tolerance thresholds are calibrated to materiality and refreshed annually." ], "failure_signals": [ "Reconciliation records missing reference source linkage for more than 5% of samples.", "Open variance cases at period close for any in-scope AI output.", "Tolerance thresholds not refreshed within 18 months or after a significant AI system change." ] }, "it_operations": { "summary": "Maintain the reliability and availability of reconciliation jobs. Pipeline failures that delay reconciliation must be escalated immediately.", "actions": [ "Monitor reconciliation job execution logs; alert the financial controller and model risk officer within one hour of any job failure.", "Maintain reconciliation infrastructure with 99.5% availability SLA during financial reporting periods.", "Ensure reconciliation ledger storage is append-only and access-controlled to prevent tampering." ], "failure_signals": [ "Reconciliation job failure not escalated within one hour.", "Reconciliation infrastructure availability falling below 99.5% during a reporting period.", "Reconciliation ledger audit log showing unauthorized write access." ] }, "compliance_officer": { "summary": "Reconciliation evidence is what compliance produces when regulators or auditors ask how AI-influenced figures are verified.", "actions": [ "Map reconciliation controls to the regulatory and ICFR requirements they evidence.", "Review unresolved reconciliation variances involving AI outputs for reportability." ], "metrics": [ "Reconciliation variance rate for AI-influenced outputs: trend to zero unresolved items at close.", "Controls mapped to requirements: 100% of AI-relevant reconciliations." ], "failure_signals": [ "Unexplained AI-output variances open at certification time.", "Auditor unable to trace an AI-influenced figure to its reconciliation evidence." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Traditional reconciliation controls exist for human-generated data but are rarely extended to AI-generated outputs with appropriate reference-source pairings and automated variance workflows." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "cloud-native", "eu-high-risk-ai" ], "implementers": [ "Financial Controller", "IT Operations", "Model Risk Officer", "Internal Audit" ], "frameworks": [ { "framework": "sox", "requirement_id": "\u00a7404(a)", "fit": "direct", "rationale": "SOX 404(a) requires management to assess the effectiveness of ICFR. Reconciliation controls are a foundational ICFR control activity; their extension to AI-generated outputs is necessary for the assessment to cover all significant data flows into financial statements.", "normative_force": "binding-law", "source_version": "2002 as amended", "reviewed_on": "2026-06-28", "basis": "asserted", "relation": "satisfies" }, { "framework": "coso_icfr", "requirement_id": "Principles 10-11", "fit": "direct", "rationale": "COSO Principles 10 and 11 require organizations to select and develop control activities that mitigate financial reporting risks. Reconciliation is explicitly cited as a detective control activity in COSO guidance and is directly applicable to AI-generated financial data.", "normative_force": "industry-framework", "source_version": "2013", "reviewed_on": "2026-06-28", "basis": "asserted", "relation": "informs" }, { "framework": "bcbs_239", "requirement_id": "Principle 3", "fit": "direct", "rationale": "BCBS 239 Principle 3 (Accuracy and Integrity) requires accurate, reliable risk data with reconciliation of risk data with other sources, including accounting data, so that discrepancies are identified and explained. Reconciliation controls over AI-influenced financial outputs directly implement that reconciliation discipline.", "normative_force": "supervisory-guidance", "source_version": "2013", "reviewed_on": "2026-07-02", "basis": "asserted", "relation": "satisfies" }, { "framework": "soc2", "requirement_id": "CC6.1, CC7.2", "fit": "partial", "rationale": "SOC 2 CC6.1 restricts logical access to protect information assets, and CC7.2 requires monitoring system components for anomalies indicative of malicious acts or errors. Reconciliation controls detect anomalies in AI-influenced financial outputs (CC7.2's discipline), with CC6.1 protecting the integrity of the reconciliation data itself; the fit is partial.", "normative_force": "certification-standard", "source_version": "2022", "reviewed_on": "2026-07-02", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "pcaob_as_2201", "requirement_id": "\u00b6.39-.40", "fit": "adjacent", "rationale": "AS 2201 \u00b6.39-.40 govern selecting controls to test based on their importance to the relevant assertions. Reconciliation controls over AI-influenced outputs are classic detective controls over completeness and accuracy assertions that an ICFR auditor would select and test under those paragraphs.", "normative_force": "certification-standard", "source_version": "2007 as amended", "reviewed_on": "2026-07-02", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "openai_enterprise", "requirement_id": "API model versioning & deprecation policy", "fit": "partial", "rationale": "OpenAI publishes model versioning and deprecation documentation for its API, including dated model snapshots and deprecation timelines. Institutions using OpenAI models in financial workflows can incorporate this vendor capability into reconciliation controls for AI-influenced financial outputs. This is vendor capability documentation, not regulatory guidance; it covers the vendor side only.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "RS2", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal RS2 (Failures and remediations) requires processes for identifying, reporting, and remediating failures and predictable misuse. For institutions using Azure AI services, this goal produces vendor-side governance artifacts that align with reconciliation controls for AI-influenced financial outputs. The Standard is Microsoft's published internal policy offered as reference practice, not regulatory guidance.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_financial", "requirement_id": "AWS Audit Manager", "fit": "partial", "rationale": "AWS Audit Manager automates evidence collection against control frameworks for AWS workloads, and AWS CloudTrail records account-level API activity. For AWS-hosted financial AI systems, this supplies the infrastructure-layer support and evidence stream for reconciliation controls for AI-influenced financial outputs. This is vendor documentation of real AWS capabilities \u2014 it does not substitute for model-layer validation or regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_financial", "requirement_id": "Vertex AI Model Monitoring", "fit": "partial", "rationale": "Vertex AI Model Monitoring detects prediction drift and training-serving skew for models deployed on Google Cloud. For GCP-hosted financial AI systems, this capability supplies the platform-layer support for reconciliation controls for AI-influenced financial outputs. This is vendor product documentation, not regulatory guidance; it does not address model-layer regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://finance/controls/FC-03", "meta": { "authored_on": "2026-06-29", "schema_version": "1.1.0" }, "validation_objective": "AI-generated financial outputs must be reconciled against at least one independent source on a defined schedule, with all variances above the defined tolerance threshold investigated and resolved before outputs are used in financial reporting, and the reconciliation record retained as an ICFR control artifact.", "evidence_required": [ "Reconciliation control record for each AI-generated financial output stream, including output_stream_id, independent_source, reconciliation_frequency, tolerance_threshold, and responsible_team fields", "Completed reconciliation worksheets for each reconciliation cycle in the trailing four quarters, showing AI output value, independent source value, variance amount, variance percentage, and disposition (accepted/investigated)", "Variance investigation log for all variances exceeding the tolerance threshold, including investigation findings, root cause classification, and resolution action for each variance", "Escalation log for variances that could not be resolved within the defined investigation window or that indicate a systematic model error" ], "machine_tests": [ "Query reconciliation control records for all AI output streams tagged as affecting financial reporting \u2192 assert each stream has a defined independent_source, reconciliation_frequency \u2264monthly, and tolerance_threshold", "Check reconciliation worksheets for the trailing four quarters \u2192 assert no quarter has a missing reconciliation cycle for any in-scope output stream and all worksheets have a completion_date within the defined frequency window", "Scan variance investigation log for variances above tolerance \u2192 assert each has an investigation_findings field, a root_cause field, and a resolution_action field with non-null values", "Query escalation log for variances classified as systematic_model_error \u2192 assert each has a notification record sent to the model risk function within 24 hours of classification" ], "human_review": [ "Review the selection of independent sources for each reconciliation to confirm they are genuinely independent of the AI system being reconciled and are not derived from the same underlying data feed", "Assess the tolerance threshold calibration to confirm thresholds are set based on materiality analysis and not set so high that they systematically suppress investigation of variances that are material in aggregate", "Verify that the reconciliation control has been tested for operating effectiveness and that the test sample covered a representative selection of output streams and variance scenarios" ], "blocking_effect": "advisory", "normative_status": "binding-law", "anti_patterns": [ "Reconciling AI-generated outputs against a data source that shares the same upstream data feed as the AI system, so a corrupted input silently produces matching values in both the AI output and the 'independent' source", "Setting tolerance thresholds by convention (e.g., 1% of output value) without anchoring them to the financial materiality of the output stream, allowing individually immaterial variances to accumulate into a material misstatement", "Treating reconciliation as a month-end close activity only, leaving AI-generated outputs unreconciled for the entire reporting period and unable to detect mid-period model drift before financial statements are prepared", "Closing variance investigations with 'rounding difference' or 'timing difference' root cause classifications without substantive analysis, masking systematic model errors under routine administrative explanations", "Allowing unresolved variances above tolerance to proceed into financial reporting when the reconciliation deadline conflicts with the close schedule, without escalating to finance leadership for an override decision" ], "update_status": "current", "layer_code": "FC" }, { "id": "FC-04", "layer": "FC", "plane": "lifecycle", "name": "Change Management Controls for Financial AI Systems", "plain": "Any change to an AI system that affects financial reporting \u2014 including model updates, training data changes, hyperparameter tuning, pipeline configuration changes, and inference environment updates \u2014 must pass through a rigorous change management process that includes impact assessment, control re-evaluation, testing, approval by a financially-qualified reviewer, and post-implementation validation before changes take effect in production.", "threat": { "tags": [ "unauthorized-model-change", "icfr-control-bypass", "silent-recalibration", "change-induced-misstatement" ], "desc": "Unauthorized or inadequately tested changes to financial AI systems can alter the financial outputs those systems produce without triggering ICFR re-evaluation. Model updates that shift valuation assumptions, retrained models that embed data from a manipulated dataset, or pipeline configuration changes that alter aggregation logic can produce materially different financial outputs without any visible code deployment. Without change management controls, these modifications bypass the control framework entirely." }, "standard": [ { "id": "sox", "section": "\u00a7404(b)", "title": "External auditor attestation covering IT general controls including change management" }, { "id": "coso_icfr", "section": "Principle 12", "title": "Technology change controls as control activities" }, { "id": "sr26_2", "section": "\u00a7V", "title": "Change-triggered revalidation" } ], "sources": [ { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Anthropic's Responsible Scaling Policy v3.3 documents the vendor's capability thresholds and safeguards, cited as third-party AI due diligence context for the apeiris://finance/controls/FC-04 Change Management Controls for Financial AI Systems control.", "reviewed_on": "2026-07-02" }, { "id": "openai_enterprise_data_governance_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "OpenAI's enterprise privacy and compliance documentation records vendor-side data handling and audit-log capabilities relevant to the apeiris://finance/controls/FC-04 Change Management Controls for Financial AI Systems control.", "reviewed_on": "2026-07-02" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://finance/controls/FC-04 Change Management Controls for Financial AI Systems control.", "reviewed_on": "2026-07-01" }, { "id": "aws_financial_services_compliance_2024", "title": "AWS User Guide to Financial Services Regulations & Guidelines in the United States", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/financial-services/security-compliance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_financial_services_compliance_2024", "relationship": "informative_reference", "rationale": "AWS's financial services regulatory guide and compliance tooling document infrastructure-layer capabilities relevant to the apeiris://finance/controls/FC-04 Change Management Controls for Financial AI Systems control.", "reviewed_on": "2026-07-02" }, { "id": "google_cloud_financial_services_ai_2024", "title": "Google Cloud Explainable AI", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/explainable-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_financial_services_ai_2024", "relationship": "informative_reference", "rationale": "Google Cloud's Explainable AI and Vertex AI model governance documentation describes platform capabilities relevant to the apeiris://finance/controls/FC-04 Change Management Controls for Financial AI Systems control.", "reviewed_on": "2026-07-02" }, { "id": "okta_financial_services_access_2025", "title": "Okta for Financial Services", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://www.okta.com/solutions/financial-services/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_financial_services_access_2025", "relationship": "informative_reference", "rationale": "Okta's identity products (System Log, access management, Adaptive MFA, Privileged Access) supply identity-layer enforcement and evidence relevant to the apeiris://finance/controls/FC-04 Change Management Controls for Financial AI Systems control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Define a change classification taxonomy for financial AI systems (major/minor/emergency); require a formal change request with impact assessment for all classes; gate production deployment on approval from a financially-qualified reviewer (financial controller or delegate) and evidence of testing; implement post-implementation review within five business days of deployment.", "steps": [ "Classify all changes to financial AI systems into major (model architecture, training data schema, control logic), minor (hyperparameter, threshold, configuration), and emergency (critical defect fix); define approval and testing requirements per class.", "Require a financial impact statement for every major and minor change, documenting the expected effect on financial output values, any control objective affected, and the re-testing plan; obtain written approval from the financial controller or designated alternate before production deployment.", "Conduct post-implementation validation within five business days: compare financial outputs pre- and post-change against the expected impact statement; document any unexpected variance; escalate deviations exceeding the materiality threshold to the financial controller and external auditors." ], "financial_controller": { "summary": "You must approve all major and minor changes to financial AI systems before they deploy to production. This is a preventive ICFR control and must not be delegated to technical staff alone.", "actions": [ "Review financial impact statements for all change requests; approve only after confirming the stated impact is within expectations and testing evidence is attached.", "Receive post-implementation validation reports within five business days of each change; escalate deviations immediately.", "Maintain a change log for all financial AI systems as a permanent ICFR evidence artifact." ], "failure_signals": [ "Production deployment to a financial AI system without a financial controller approval record.", "Post-implementation validation not completed within five business days.", "Deviation between expected and actual post-change output exceeding materiality threshold without escalation." ] }, "model_risk_officer": { "summary": "Change management for financial AI systems must be integrated with the model validation lifecycle. Major changes require re-validation; minor changes require at minimum a validation review.", "actions": [ "Gate major model changes on completion of at least a targeted re-validation covering affected control objectives.", "Maintain a change-to-validation linkage log; ensure every production change has an associated validation record.", "Advise the financial controller on the technical risk implications of changes where the financial impact is difficult to pre-assess." ], "failure_signals": [ "Major model change deployed without a targeted re-validation.", "Change-to-validation linkage log showing gaps for more than 5% of changes.", "Model risk report not updated to reflect post-change validation status within 10 business days." ] }, "it_operations": { "summary": "Enforce the change management gate in the deployment pipeline. No deployment to a financial AI system should be possible without an approved change ticket and attached evidence artifacts.", "actions": [ "Implement deployment pipeline gates that require an approved change ticket ID and a financial controller approval timestamp before deploying to any financial AI production environment.", "Maintain immutable deployment logs showing who approved, who deployed, and when; make logs available to internal and external audit.", "Alert the financial controller and model risk officer immediately on any deployment that bypasses the gate (emergency break-glass), and initiate post-deployment review within 24 hours." ], "failure_signals": [ "Deployment pipeline gate disabled or bypassable without a break-glass audit record.", "Deployment log missing for any production change to a financial AI system.", "Break-glass deployment without post-deployment review initiated within 24 hours." ] }, "internal_audit": { "summary": "Test the change management control design and operating effectiveness; verify no unauthorized changes reached production.", "actions": [ "Quarterly, pull the deployment log for all financial AI systems and cross-reference against the approved change log; flag any deployment without a corresponding approved ticket.", "Sample five change requests per quarter; verify financial impact statements, approval records, testing evidence, and post-implementation validation reports are all present and complete.", "Report change management control exceptions to the audit committee with a severity classification." ], "failure_signals": [ "Deployment without a corresponding approved change ticket.", "Sample with missing financial impact statement or post-implementation validation.", "Repeat change management deficiency in two consecutive audit periods." ] }, "compliance_officer": { "summary": "Change management over financial AI is a standing examiner and auditor question; compliance owns the evidence that the gate operates.", "actions": [ "Verify change tickets for financial AI systems carry required approvals and revalidation decisions.", "Sample changes each quarter for policy conformance and evidence completeness." ], "metrics": [ "Changes with complete approval evidence: 100% of sampled financial AI changes.", "Emergency changes with retrospective review completed: 100% within policy window." ], "failure_signals": [ "Financial AI changes deployed without the required approval chain.", "Emergency-change volume rising as a share of all model changes." ] } }, "maturity": { "current": "repeatable", "target": "managed", "notes": "Most enterprises have IT change management processes, but they rarely require financially-qualified approval or post-implementation financial impact validation for AI system changes." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "cloud-native", "eu-high-risk-ai" ], "implementers": [ "Financial Controller", "IT Operations", "Model Risk Officer", "DevOps" ], "frameworks": [ { "framework": "sox", "requirement_id": "\u00a7404(b)", "fit": "direct", "rationale": "SOX 404(b) requires external auditors to attest to management's ICFR assessment, which includes IT general controls. Program change controls over financial AI systems are an IT general control that must operate effectively for the auditor's attestation to be unqualified.", "normative_force": "binding-law", "source_version": "2002 as amended", "reviewed_on": "2026-06-28", "basis": "asserted", "relation": "satisfies" }, { "framework": "coso_icfr", "requirement_id": "Principle 12", "fit": "direct", "rationale": "COSO Principle 12 specifically calls out technology change controls as a required control activity. Financial AI system change management directly fulfills this principle by ensuring that technology changes are authorized, tested, and documented before affecting financial reporting.", "normative_force": "industry-framework", "source_version": "2013", "reviewed_on": "2026-06-28", "basis": "asserted", "relation": "informs" }, { "framework": "sr26_2", "requirement_id": "\u00a7V", "fit": "direct", "rationale": "SR 26-2 \u00a7V (Validation and Monitoring) describes validation after significant model changes as part of its validation and monitoring elements. FC-04 extends that change-triggered revalidation expectation with the financial controller approval and post-implementation verification steps ICFR requires.", "normative_force": "supervisory-guidance", "source_version": "2026-04-17", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "eu_ai_act", "requirement_id": "Art. 9(4), Art. 15", "fit": "partial", "rationale": "EU AI Act Article 9(4) requires that risk management systems be updated throughout the AI system lifecycle, including after changes. Article 15 requires accuracy, robustness, and cybersecurity to be maintained post-change. This control's post-implementation validation step directly addresses these requirements for high-risk financial AI.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-06-28", "basis": "anchored", "relation": "satisfies" }, { "framework": "openai_enterprise", "requirement_id": "API model versioning & deprecation policy", "fit": "partial", "rationale": "OpenAI publishes model versioning and deprecation documentation for its API, including dated model snapshots and deprecation timelines. Institutions using OpenAI models in financial workflows can incorporate this vendor capability into change management controls for financial AI systems. This is vendor capability documentation, not regulatory guidance; it covers the vendor side only.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "A2", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal A2 (Oversight of significant adverse impacts) requires defined review and oversight processes for AI systems that can cause significant adverse impact. For institutions using Azure AI services, this goal produces vendor-side governance artifacts that align with change management controls for financial AI systems. The Standard is Microsoft's published internal policy offered as reference practice, not regulatory guidance.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_financial", "requirement_id": "Financial Services Industry Lens \u2014 AWS Well-Architected", "fit": "partial", "rationale": "The Financial Services Industry Lens for the AWS Well-Architected Framework describes design principles, risk considerations, and shared-responsibility boundaries for regulated financial workloads on AWS. For AWS-hosted financial AI systems, this supplies the infrastructure-layer support and evidence stream for change management controls for financial AI systems. This is vendor documentation of real AWS capabilities \u2014 it does not substitute for model-layer validation or regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_financial", "requirement_id": "Vertex AI Model Registry", "fit": "partial", "rationale": "Vertex AI Model Registry provides versioned model registration, aliases, and deployment state tracking on Google Cloud. For GCP-hosted financial AI systems, this capability supplies the platform-layer support for change management controls for financial AI systems. This is vendor product documentation, not regulatory guidance; it does not address model-layer regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "okta_financial", "requirement_id": "Okta Privileged Access", "fit": "adjacent", "rationale": "Okta Privileged Access governs and records privileged sessions and credentials for sensitive infrastructure. Where access to financial AI systems is brokered through Okta, this capability supplies the identity-layer enforcement and evidence for change management controls for financial AI systems. This is vendor product documentation, not a financial-services control framework.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://finance/controls/FC-04", "meta": { "authored_on": "2026-06-29", "schema_version": "1.1.0" }, "validation_objective": "Any change to an AI system affecting financial reporting must be reviewed and approved through the ICFR change management process before deployment to the production financial reporting environment, with a documented change record, approval chain, and post-change ICFR control effectiveness confirmation.", "evidence_required": [ "Change request record for each AI system change affecting financial reporting, including change_id, change_type, change_description, financial_reporting_impact_assessment, and requested_by fields", "Approval chain record showing sign-offs from model risk, finance, and IT change management \u2014 with names, dates, and approval decisions \u2014 before each production deployment", "Post-change ICFR control effectiveness test results confirming that reconciliation controls, output validation controls, and audit trail controls are operating correctly after the change", "Rollback plan document and rollback capability test result for each change, confirming that the prior production state can be restored within the defined recovery time objective" ], "machine_tests": [ "Query AI system deployment log for all production deployments in the trailing 12 months \u2192 assert each deployment record has a corresponding approved change request record with approval_date before deployment_date", "Check change request records for financial_reporting_impact_assessment field \u2192 assert field is present and non-null for all changes to AI systems in the ICFR inventory", "Query post-change ICFR effectiveness test records \u2192 assert a test record exists for each production deployment within 5 business days of deployment_date and test result is 'pass' or has an open remediation plan", "Verify rollback plan document exists for each change record \u2192 assert document is present and rollback_test_date is within 90 days of change_deployment_date" ], "human_review": [ "Review the change management process to confirm that the definition of a 'change affecting financial reporting' is broad enough to capture model hyperparameter tuning, training data updates, and inference environment changes, not just major version releases", "Assess the approval chain composition to confirm that finance representation (Controller or designated reviewer) is required for all changes that could affect the accuracy of AI-generated financial outputs, not just IT-classified changes", "Verify that emergency change procedures include a compensating control \u2014 such as enhanced reconciliation or temporary manual override \u2014 that activates automatically when a financial AI system change bypasses standard pre-approval due to time constraints" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Classifying model hyperparameter tuning and training data refreshes as 'maintenance' rather than 'changes' so they bypass the ICFR change management approval process, silently altering model behavior without ICFR documentation", "Scoping ICFR change management to cover only the AI system's inference API while excluding changes to the data pipeline, feature engineering code, and post-processing logic that directly affect output accuracy", "Relying on the AI vendor's deployment cadence and change notification emails as the institution's change record, without independently maintaining a change register that maps vendor releases to ICFR-scope components", "Conducting post-change ICFR effectiveness testing using the same test data and thresholds as pre-change baseline testing, without including test cases designed to detect the specific risk introduced by the change", "Emergency change procedures that allow production deployment with verbal approval documented retroactively, creating a documentation gap that cannot be remediated and that external auditors treat as a control deficiency" ], "update_status": "current", "layer_code": "FC" }, { "id": "FC-05", "layer": "FC", "plane": "control", "name": "Access Controls for Financial AI Systems", "plain": "Role-based access controls must limit who can modify model parameters, training data, inference pipeline configuration, or financial output approval workflows for AI systems that affect financial reporting, with all privileged access logged, reviewed quarterly, and requiring dual-approval for changes to production financial AI environments.", "threat": { "tags": [ "unauthorized-model-manipulation", "insider-threat", "privilege-escalation", "segregation-of-duties-violation" ], "desc": "Overprivileged access to financial AI systems allows insiders or compromised accounts to manipulate model parameters, substitute training data, or alter inference pipeline logic in ways that change financial outputs without triggering change management controls. Segregation of duties violations \u2014 where the same person can change a model and approve its output for financial reporting \u2014 create conditions for undetected fraud. Privileged access to financial AI infrastructure is a high-value target for external attackers seeking to manipulate financial results." }, "standard": [ { "id": "sox", "section": "\u00a7404", "title": "Access controls as IT general controls within ICFR scope" }, { "id": "coso_icfr", "section": "Principle 11", "title": "General control activities over technology \u2014 access" }, { "id": "okta_financial", "section": "Okta access management", "title": "Role-based access policies for financial systems" } ], "sources": [ { "id": "okta_financial_services_access_2025", "title": "Okta for Financial Services", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://www.okta.com/solutions/financial-services/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_financial_services_access_2025", "relationship": "informative_reference", "rationale": "Okta's identity products (System Log, access management, Adaptive MFA, Privileged Access) supply identity-layer enforcement and evidence relevant to the apeiris://finance/controls/FC-05 Access Controls for Financial AI Systems control.", "reviewed_on": "2026-07-02" }, { "id": "openai_enterprise_data_governance_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "OpenAI's enterprise privacy and compliance documentation records vendor-side data handling and audit-log capabilities relevant to the apeiris://finance/controls/FC-05 Access Controls for Financial AI Systems control.", "reviewed_on": "2026-07-02" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://finance/controls/FC-05 Access Controls for Financial AI Systems control.", "reviewed_on": "2026-07-01" }, { "id": "aws_financial_services_compliance_2024", "title": "AWS User Guide to Financial Services Regulations & Guidelines in the United States", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/financial-services/security-compliance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_financial_services_compliance_2024", "relationship": "informative_reference", "rationale": "AWS's financial services regulatory guide and compliance tooling document infrastructure-layer capabilities relevant to the apeiris://finance/controls/FC-05 Access Controls for Financial AI Systems control.", "reviewed_on": "2026-07-02" }, { "id": "google_cloud_financial_services_ai_2024", "title": "Google Cloud Explainable AI", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/explainable-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_financial_services_ai_2024", "relationship": "informative_reference", "rationale": "Google Cloud's Explainable AI and Vertex AI model governance documentation describes platform capabilities relevant to the apeiris://finance/controls/FC-05 Access Controls for Financial AI Systems control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Define four roles for financial AI systems: model-developer (read model, write development environment), model-approver (approve model changes, cannot write to production), pipeline-operator (run inference, cannot modify model), financial-approver (approve output for reporting, cannot modify model or pipeline); enforce segregation so no individual holds both developer and approver roles; require dual-approval for any production write access; review all access grants quarterly.", "steps": [ "Define and implement role-based access control with at least four roles \u2014 model-developer, model-approver, pipeline-operator, financial-approver \u2014 ensuring no individual can hold both a production-write role and a financial-output-approval role simultaneously.", "Enforce dual-approval for all production write operations to financial AI systems: any privileged action (model weight update, training data replacement, pipeline configuration change) must be authorized by a second named approver before execution; log both authorizations immutably.", "Conduct quarterly access reviews: enumerate all accounts with production access to financial AI systems; revoke any access not justified by current role assignment; document review completion and share results with internal audit and the financial controller." ], "financial_controller": { "summary": "Segregation of duties in financial AI access controls is an ICFR requirement. Review access control configurations and quarterly access review results before signing period-close certifications.", "actions": [ "Review the quarterly access report for financial AI systems; confirm no individual holds conflicting roles.", "Approve exceptions to segregation-of-duties requirements (e.g., small-team emergency access) in writing; document compensating controls.", "Include access control review status in the Section 302 certification memo each period." ], "failure_signals": [ "Individual with model-developer and financial-approver roles simultaneously.", "Quarterly access review not completed before period-close certification.", "Production write access granted without dual-approval record." ] }, "model_risk_officer": { "summary": "Model risk governance must verify that access controls prevent unauthorized model changes. Model validation should include a review of access logs for changes made between validation cycles.", "actions": [ "Include access log review as part of each model validation: confirm no production model changes occurred outside the change management process.", "Flag access control exceptions discovered during validation to the financial controller and IT operations immediately.", "Require access control attestation from IT operations before signing off on model validation reports." ], "failure_signals": [ "Undocumented model change found in access logs during validation.", "Access control attestation missing from model validation package.", "Access exception not escalated within two business days of discovery." ] }, "compliance_officer": { "summary": "Access controls for financial AI systems must satisfy both ICFR and data privacy requirements. Maintain a documented policy covering role definitions, segregation rules, and exception handling.", "actions": [ "Maintain and annually review the access control policy for financial AI systems; ensure it covers role definitions, segregation-of-duties requirements, dual-approval procedures, and exception handling.", "Monitor for regulatory updates to access control requirements for financial AI and update the policy accordingly.", "Include access control policy compliance in the annual SOX readiness assessment." ], "metrics": [ "Segregation-of-duties compliance rate: percentage of financial AI system users with no conflicting role assignments \u2014 target 100%.", "Access review completion rate: percentage of quarterly reviews completed on schedule \u2014 target 100%.", "Exception rate: number of production write operations without dual-approval \u2014 target zero." ], "failure_signals": [ "Access control policy not reviewed within 18 months.", "Quarterly access review completion rate below 100% in two consecutive quarters.", "Regulatory update to access control requirements not reflected in policy within 90 days." ] }, "it_operations": { "summary": "Enforce access controls technically: implement RBAC in the AI infrastructure layer; configure dual-approval workflows in deployment tooling; maintain immutable access logs.", "actions": [ "Implement RBAC in all financial AI infrastructure components (model registry, training platform, inference serving, pipeline orchestrator) with role definitions aligned to the four-role taxonomy.", "Configure deployment tooling to require dual-approval for any production write operation; ensure approvals are logged with timestamps, approver identities, and action details.", "Provide quarterly access reports to the financial controller and internal audit within five business days of quarter-end." ], "failure_signals": [ "RBAC not implemented in any financial AI infrastructure component.", "Dual-approval workflow bypassed or not configured in deployment tooling.", "Quarterly access report delivered more than five business days after quarter-end." ] }, "internal_audit": { "summary": "Internal audit tests access controls over financial AI systems as ITGCs: provisioning, recertification, privileged access, and log integrity.", "actions": [ "Test joiner/mover/leaver timeliness for identities with access to financial AI systems.", "Verify periodic access recertification completion and revocation follow-through.", "Sample privileged sessions for approval, recording, and review evidence." ], "failure_signals": [ "Orphaned accounts retaining access to financial AI systems.", "Recertifications rubber-stamped without change activity.", "Privileged access without session evidence." ] } }, "maturity": { "current": "repeatable", "target": "managed", "notes": "Standard RBAC exists in most enterprises but is rarely extended to AI-specific roles with SOX-aligned segregation-of-duties requirements and dual-approval for production model changes." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "cloud-native", "multi-tenant", "eu-high-risk-ai" ], "implementers": [ "IT Operations", "Financial Controller", "Compliance Officer", "Internal Audit" ], "frameworks": [ { "framework": "sox", "requirement_id": "\u00a7404", "fit": "direct", "rationale": "SOX \u00a7404 requires management to assess, and the auditor to attest to, the effectiveness of internal control over financial reporting. The statute itself does not enumerate IT general controls \u2014 ITGC (including logical access) is the assessment construct under which access controls over financial AI systems fall within the \u00a7404 scope in practice (see PCAOB AS 2201 for the audit treatment).", "normative_force": "binding-law", "source_version": "2002 as amended", "reviewed_on": "2026-07-02", "basis": "asserted", "relation": "satisfies" }, { "framework": "coso_icfr", "requirement_id": "Principle 11", "fit": "direct", "rationale": "COSO 2013 Principle 11 requires the organization to select and develop general control activities over technology to support the achievement of objectives \u2014 including security management controls that restrict access to authorized users. Access controls over financial AI systems are Principle 11 technology general controls.", "normative_force": "industry-framework", "source_version": "2013", "reviewed_on": "2026-07-02", "basis": "asserted", "relation": "informs" }, { "framework": "okta_financial", "requirement_id": "Okta access management", "fit": "partial", "rationale": "Okta's access management products enforce role- and attribute-based access policies for applications and APIs. Where access to financial AI systems is brokered through Okta, this capability supplies the identity-layer enforcement and evidence for access controls for financial AI systems. This is vendor product documentation, not a financial-services control framework.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "eu_ai_act", "requirement_id": "Art. 15", "fit": "partial", "rationale": "EU AI Act Art. 15 requires high-risk AI systems to achieve appropriate resilience against unauthorised third-party attempts to alter their use, outputs, or performance \u2014 the Act's cybersecurity requirement. Access controls with least-privilege enforcement and privileged-access management over financial AI systems implement that requirement at the deployment layer.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "openai_enterprise", "requirement_id": "Data Processing Addendum", "fit": "partial", "rationale": "OpenAI's Data Processing Addendum sets contractual data-handling terms for enterprise customers. Institutions using OpenAI models in financial workflows can incorporate this vendor capability into access controls for financial AI systems. This is vendor capability documentation, not regulatory guidance; it covers the vendor side only.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "PS2", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Privacy & Security Goal PS2 requires compliance with Microsoft's security policies and standards for AI systems. For institutions using Azure AI services, this goal produces vendor-side governance artifacts that align with access controls for financial AI systems. The Standard is Microsoft's published internal policy offered as reference practice, not regulatory guidance.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_financial", "requirement_id": "Financial Services Industry Lens \u2014 AWS Well-Architected", "fit": "partial", "rationale": "The Financial Services Industry Lens for the AWS Well-Architected Framework describes design principles, risk considerations, and shared-responsibility boundaries for regulated financial workloads on AWS. For AWS-hosted financial AI systems, this supplies the infrastructure-layer support and evidence stream for access controls for financial AI systems. This is vendor documentation of real AWS capabilities \u2014 it does not substitute for model-layer validation or regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_financial", "requirement_id": "Cloud IAM", "fit": "adjacent", "rationale": "Cloud IAM provides role-based access control, and Cloud Audit Logs record administrative and data access events, for Google Cloud resources including Vertex AI. For GCP-hosted financial AI systems, this capability supplies the platform-layer support for access controls for financial AI systems. This is vendor product documentation, not regulatory guidance; it does not address model-layer regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://finance/controls/FC-05", "meta": { "authored_on": "2026-06-29", "schema_version": "1.1.0" }, "validation_objective": "All accounts with access to financial AI systems must be assigned to exactly one of four defined roles (model-developer, model-approver, pipeline-operator, financial-approver) with no individual holding both a production-write and a financial-output-approval role simultaneously; every production write operation must have an immutable dual-approval record; and quarterly access reviews must be completed and documented before each period-close certification.", "evidence_required": [ "rbac_role_assignment_report listing all accounts with access to financial AI systems, their assigned role(s), and role grant date \u2014 verified that no individual holds both a production-write role (model-developer or pipeline-operator) and a financial-approver role simultaneously", "dual_approval_log for all production write operations (model weight updates, training data replacements, pipeline configuration changes) showing action timestamp, requester identity, approver identity, and approval timestamp", "quarterly_access_review_record documenting completion date, reviewer name, accounts reviewed, revocations performed, and financial controller sign-off", "role_definition_document specifying the four-role taxonomy with permitted actions per role and enumerated segregation-of-duties constraints", "access_exception_register documenting any temporary exceptions to segregation-of-duties requirements with compensating control description and approver" ], "machine_tests": [ "Query RBAC system for all accounts holding both a production-write role and financial-approver role simultaneously \u2192 assert zero accounts returned", "Attempt a production write operation with only single-approver authorization \u2192 assert operation is blocked with error_code=dual_approval_required", "Query access log for production write operations missing a second approver record in the current period \u2192 assert zero operations found", "Check quarterly_access_review_record most recent completion date against period-close date \u2192 assert review was completed before or on period-close date" ], "human_review": [ "Verify that the four-role taxonomy is accurately implemented in the RBAC system and that role definitions precisely match documented segregation-of-duties requirements with no overlapping permission grants", "Assess whether quarterly access review process is substantively rigorous \u2014 confirm revocations were performed for terminated employees and role changes, not merely that a sign-off form was completed", "Confirm that dual-approval workflow is technically enforced rather than procedurally required, and that approvals are immutably logged with sufficient non-repudiation metadata" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Granting a single 'admin' or 'superuser' role that combines model-developer and financial-approver capabilities in one account, eliminating segregation of duties entirely", "Implementing dual-approval as an email or chat acknowledgment rather than a technically enforced workflow that prevents execution without the second signature being recorded", "Conducting access reviews only annually or at audit time rather than quarterly, allowing role drift to accumulate undetected across multiple reporting periods", "Exempting service accounts or pipeline automation accounts from RBAC scope, creating unmonitored privileged access paths into financial AI infrastructure", "Logging access grants but not access usage, making it impossible to demonstrate that privileged access was not exercised outside authorized contexts" ], "update_status": "current", "layer_code": "FC" }, { "id": "FC-06", "layer": "FC", "plane": "control", "name": "AI Operational Error and Financial Exception Management", "plain": "A structured exception management process must detect, triage, investigate, and resolve operational errors in AI-driven financial processes \u2014 including inference failures, anomalous outputs, pipeline errors, and threshold breaches \u2014 with mandatory root-cause documentation, financial impact quantification, and escalation to the financial controller when errors affect financial reporting.", "threat": { "tags": [ "unresolved-financial-exception", "error-accumulation", "late-detection", "audit-trail-gap" ], "desc": "AI-driven financial processes fail in ways that differ from traditional software failures: a model may produce outputs that are technically valid but financially wrong due to distributional shift, bad input data, or undetected bugs in post-processing logic. Without a structured exception management process, these errors may accumulate across many transactions before detection, creating large aggregate financial misstatements. Late detection also means the error evidence trail degrades, making root-cause analysis and auditor explanation difficult." }, "standard": [ { "id": "sox", "section": "\u00a7302(a)(5)", "title": "Disclosure of significant changes in ICFR including corrective actions" }, { "id": "coso_icfr", "section": "Principle 16-17", "title": "Monitoring activities and deficiency evaluation" }, { "id": "sr26_2", "section": "\u00a7V (Ongoing Model Monitoring)", "title": "Ongoing monitoring and outcome analysis" }, { "id": "aicpa_soc2", "section": "CC7.4, CC7.5", "title": "Incident response and remediation for financial data systems" } ], "sources": [ { "id": "openai_enterprise_data_governance_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "OpenAI's enterprise privacy and compliance documentation records vendor-side data handling and audit-log capabilities relevant to the apeiris://finance/controls/FC-06 AI Operational Error and Financial Exception Management control.", "reviewed_on": "2026-07-02" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://finance/controls/FC-06 AI Operational Error and Financial Exception Management control.", "reviewed_on": "2026-07-01" }, { "id": "aws_financial_services_compliance_2024", "title": "AWS User Guide to Financial Services Regulations & Guidelines in the United States", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/financial-services/security-compliance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_financial_services_compliance_2024", "relationship": "informative_reference", "rationale": "AWS's financial services regulatory guide and compliance tooling document infrastructure-layer capabilities relevant to the apeiris://finance/controls/FC-06 AI Operational Error and Financial Exception Management control.", "reviewed_on": "2026-07-02" }, { "id": "google_cloud_financial_services_ai_2024", "title": "Google Cloud Explainable AI", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/explainable-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_financial_services_ai_2024", "relationship": "informative_reference", "rationale": "Google Cloud's Explainable AI and Vertex AI model governance documentation describes platform capabilities relevant to the apeiris://finance/controls/FC-06 AI Operational Error and Financial Exception Management control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Deploy an exception management queue fed by automated anomaly detectors, reconciliation variance alerts (FC-03), and manual reports; classify each exception by severity (critical/high/medium/low); enforce resolution SLAs; require root-cause documentation and financial impact quantification before closing; aggregate open exceptions into a weekly report for the financial controller.", "steps": [ "Implement automated anomaly detectors on AI inference pipelines for financial data: monitor output distribution statistics, pipeline latency, error rates, and null output rates; route all alerts to a centralized exception management queue with severity classification.", "Establish resolution SLAs by severity \u2014 critical (same business day), high (three business days), medium (ten business days), low (next period close) \u2014 and require root-cause documentation and financial impact quantification before any exception is closed.", "Produce a weekly exception management report aggregating open exceptions, resolution status, and cumulative financial impact; route to the financial controller; escalate critical and high exceptions to the audit committee when cumulative financial impact exceeds 25% of the materiality threshold." ], "financial_controller": { "summary": "The weekly exception report is a key input to your period-close decision. No period should close with unresolved critical or high exceptions related to financial AI systems.", "actions": [ "Review the weekly exception report; confirm all critical and high exceptions are being actively worked and have assigned owners.", "Block period close for any unresolved critical exception; require written justification and a remediation plan before approving a close with unresolved high exceptions.", "Disclose to external auditors any exception with a financial impact exceeding the materiality threshold, regardless of resolution status." ], "failure_signals": [ "Period close approved with unresolved critical exception affecting a financial AI system.", "Exception with above-threshold financial impact not disclosed to external auditors.", "Weekly exception report not reviewed before period-close sign-off." ] }, "model_risk_officer": { "summary": "Exception patterns are leading indicators of model degradation. Use exception data to prioritize model reviews and revalidation.", "actions": [ "Subscribe to the exception management queue for all financial AI systems; assess whether exception patterns indicate model drift, data quality issues, or pipeline bugs.", "Initiate targeted model review when a model generates more than three high-severity exceptions in a calendar month.", "Include exception frequency and financial impact in the quarterly model risk report." ], "failure_signals": [ "Model generating recurring high-severity exceptions without triggering a review.", "Exception root cause attributed to model drift but no revalidation initiated.", "Exception data absent from quarterly model risk report." ] }, "it_operations": { "summary": "Maintain the reliability of exception detection infrastructure. False negatives \u2014 undetected errors \u2014 are more dangerous than false positives. Tune detectors to favor sensitivity.", "actions": [ "Maintain anomaly detection coverage for all financial AI inference pipelines; test detectors monthly by injecting synthetic anomalies and verifying alerts fire.", "Ensure exception management queue has 99.9% availability during business hours; alert engineering on-call immediately for queue failures.", "Preserve all exception records and supporting logs for seven years in an immutable, auditable store." ], "failure_signals": [ "Anomaly detector monthly test failing to fire for any financial AI pipeline.", "Exception management queue downtime exceeding SLA during business hours.", "Exception records older than six months not accessible to internal audit." ] }, "internal_audit": { "summary": "Test the completeness and timeliness of exception detection, classification, and resolution. Verify that financial impact quantification is accurate and that disclosures were made when required.", "actions": [ "Quarterly, sample ten closed exceptions and verify root-cause documentation, financial impact quantification, and resolution evidence are present and complete.", "Test anomaly detector coverage by reviewing the exception log against known AI system error events from the same period; identify any events not captured.", "Assess SLA compliance: compute the percentage of exceptions resolved within their SLA and report exceptions to management." ], "failure_signals": [ "Closed exception missing root-cause documentation or financial impact quantification.", "Known error event not captured by anomaly detectors.", "SLA compliance rate below 90% for high-severity exceptions in any quarter." ] }, "compliance_officer": { "summary": "Operational AI errors with financial impact can trip disclosure and notification duties; compliance needs the exception feed, not just IT.", "actions": [ "Review high-severity AI exceptions for regulatory notification and disclosure implications.", "Confirm exception records capture financial impact quantification for escalation decisions." ], "metrics": [ "High-severity exceptions assessed for reportability: 100% within SLA.", "Exception records with quantified financial impact: 100% of escalated items." ], "failure_signals": [ "A reportable AI error identified late because exception triage skipped compliance.", "Escalated exceptions missing financial impact quantification." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most enterprises have incident management processes for IT systems but lack the financial-impact quantification and period-close integration required for AI-driven financial process exceptions." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "cloud-native", "eu-high-risk-ai" ], "implementers": [ "Financial Controller", "IT Operations", "Model Risk Officer", "Internal Audit" ], "frameworks": [ { "framework": "sox", "requirement_id": "\u00a7302(a)(5)", "fit": "direct", "rationale": "SOX 302(a)(5) requires certifying officers to disclose significant changes in ICFR including any corrective actions. A structured exception management process with documented root causes and financial impacts provides the evidence base for this disclosure obligation.", "normative_force": "binding-law", "source_version": "2002 as amended", "reviewed_on": "2026-06-28", "basis": "asserted", "relation": "satisfies" }, { "framework": "coso_icfr", "requirement_id": "Principles 16-17", "fit": "direct", "rationale": "COSO Principles 16 and 17 address monitoring activities and the evaluation and communication of control deficiencies. The exception management process directly operationalizes these principles by detecting control failures, evaluating their financial significance, and escalating to responsible parties.", "normative_force": "industry-framework", "source_version": "2013", "reviewed_on": "2026-06-28", "basis": "asserted", "relation": "informs" }, { "framework": "sr26_2", "requirement_id": "\u00a7V (Ongoing Model Monitoring)", "fit": "direct", "rationale": "SR 26-2 \u00a7V describes ongoing model monitoring and acting on identified performance issues under its Ongoing Model Monitoring subheading. FC-06 extends that expectation with financial impact quantification and a period-close escalation path for ICFR purposes.", "normative_force": "supervisory-guidance", "source_version": "2026-04-17", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "soc2", "requirement_id": "CC7.4, CC7.5", "fit": "partial", "rationale": "AICPA SOC 2 CC7.4 and CC7.5 require incident response and remediation processes that include identification, analysis, containment, and recovery. The exception management SLAs, root-cause documentation, and remediation tracking in this control align with these criteria for financial data systems.", "normative_force": "certification-standard", "source_version": "2022", "reviewed_on": "2026-06-28", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 73", "fit": "partial", "rationale": "EU AI Act Art. 73 requires providers of high-risk AI systems to report serious incidents to market surveillance authorities within defined deadlines, and deployers to inform providers. FC-06's operational error and exception management process is the mechanism that detects, quantifies, and escalates AI errors so incident-reporting duties can be met for in-scope systems.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "openai_enterprise", "requirement_id": "Enterprise Compliance API \u2014 audit logs", "fit": "partial", "rationale": "ChatGPT Enterprise and the OpenAI API expose workspace audit-log data through the Compliance API and audit logs endpoint, exportable to SIEM and evidence stores. Institutions using OpenAI models in financial workflows can incorporate this vendor capability into AI operational error and financial exception management. This is vendor capability documentation, not regulatory guidance; it covers the vendor side only.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "RS2", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal RS2 (Failures and remediations) requires processes for identifying, reporting, and remediating failures and predictable misuse. For institutions using Azure AI services, this goal produces vendor-side governance artifacts that align with AI operational error and financial exception management. The Standard is Microsoft's published internal policy offered as reference practice, not regulatory guidance.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_financial", "requirement_id": "AWS CloudTrail", "fit": "partial", "rationale": "AWS CloudTrail records API activity across AWS accounts with actor, action, and timestamp detail, exportable for retention and analysis. For AWS-hosted financial AI systems, this supplies the infrastructure-layer support and evidence stream for AI operational error and financial exception management. This is vendor documentation of real AWS capabilities \u2014 it does not substitute for model-layer validation or regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_financial", "requirement_id": "Vertex AI Model Monitoring", "fit": "partial", "rationale": "Vertex AI Model Monitoring detects prediction drift and training-serving skew for models deployed on Google Cloud. For GCP-hosted financial AI systems, this capability supplies the platform-layer support for AI operational error and financial exception management. This is vendor product documentation, not regulatory guidance; it does not address model-layer regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://finance/controls/FC-06", "meta": { "authored_on": "2026-06-29", "schema_version": "1.1.0" }, "validation_objective": "Every operational error or anomalous output from AI-driven financial processes must be captured in a centralized exception management queue within one business day of detection, classified by severity with an assigned owner, resolved within defined SLAs with documented root-cause analysis and financial impact quantification, and reported weekly to the financial controller \u2014 with no period close approved while a critical exception remains open.", "evidence_required": [ "exception_management_queue_record for each exception showing exception_id, detection_timestamp, severity_classification, assigned_owner, financial_impact_estimate, root_cause_summary, resolution_timestamp, and closure_approver", "weekly_exception_report delivered to financial controller showing open exceptions by severity, resolution status, cumulative financial impact, and SLA breach count for the current period", "period_close_certification showing financial controller attestation that no unresolved critical exception is outstanding at close", "anomaly_detector_configuration_record documenting detection thresholds, alert routing rules, and last-calibration date for automated exception sources feeding the queue" ], "machine_tests": [ "Inject a synthetic anomalous inference output exceeding the configured threshold \u2192 assert exception is created in the queue within 15 minutes with severity_classification=critical and assigned_owner populated", "Query exception queue for critical exceptions with resolution_timestamp null and age exceeding one business day \u2192 assert zero records returned", "Query period-close certification records for periods where critical exceptions had open status at close_date \u2192 assert zero records returned" ], "human_review": [ "Review weekly exception reports from the last quarter to verify that financial impact quantification is completed before exceptions are closed, not left null or marked 'under assessment' at closure", "Assess root-cause documentation for a sample of closed exceptions to verify root causes are specific and actionable (not 'system error') and that documented remediation actions were actually implemented", "Verify that escalation records confirm exceptions exceeding 25% of materiality threshold were routed to the audit committee, not only to the financial controller" ], "blocking_effect": "requires-review", "normative_status": "binding-law", "anti_patterns": [ "Closing exceptions without root-cause documentation or financial impact quantification, treating AI operational failures as routine noise rather than ICFR control events requiring investigation", "Using a single catch-all severity level for all exceptions rather than a tiered SLA system, causing critical financial errors to wait in the same queue as low-priority anomalies", "Routing exception alerts exclusively to engineering teams and not to the financial controller, creating a gap between operational incident management and ICFR reporting obligations", "Aggregating cumulative financial impact of exceptions only at audit time rather than weekly, allowing material aggregate misstatements to accumulate undetected across multiple reporting periods", "Marking exceptions as resolved based on technical fix deployment without verifying that financial impact was actually corrected in the ledger or reporting output" ], "update_status": "current", "layer_code": "FC" }, { "id": "FC-07", "layer": "FC", "plane": "data", "name": "Financial Data Integrity Monitoring", "plain": "Continuous integrity monitoring must be applied to all data flowing into and out of financial AI systems \u2014 including training datasets, inference inputs, feature stores, and model outputs \u2014 using cryptographic checksums, provenance tracking, anomaly detection, and lineage verification to detect unauthorized modification, corruption, or substitution before data affects financial reporting.", "threat": { "tags": [ "data-poisoning", "pipeline-tampering", "provenance-loss", "integrity-violation" ], "desc": "Financial AI systems are high-value targets for data integrity attacks because manipulating the data that flows through them can alter financial outputs in ways that are hard to detect through traditional controls. Training data poisoning can embed persistent biases. Inference input manipulation can cause incorrect valuations or risk calculations. Feature store corruption can affect many models simultaneously. Without continuous integrity monitoring, these attacks may succeed silently and persist across multiple reporting periods." }, "standard": [ { "id": "sox", "section": "\u00a7404", "title": "Data integrity as an IT general control within ICFR" }, { "id": "bcbs_239", "section": "Principles 2-4", "title": "Data accuracy, completeness, and integrity for financial data" }, { "id": "aicpa_soc2", "section": "CC6.6, CC6.7, CC7.2", "title": "Data integrity controls and change detection" }, { "id": "sr26_2", "section": "\u00a7IV", "title": "Data quality in model development and use" } ], "sources": [ { "id": "openai_enterprise_data_governance_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "OpenAI's enterprise privacy and compliance documentation records vendor-side data handling and audit-log capabilities relevant to the apeiris://finance/controls/FC-07 Financial Data Integrity Monitoring control.", "reviewed_on": "2026-07-02" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://finance/controls/FC-07 Financial Data Integrity Monitoring control.", "reviewed_on": "2026-07-01" }, { "id": "aws_financial_services_compliance_2024", "title": "AWS User Guide to Financial Services Regulations & Guidelines in the United States", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/financial-services/security-compliance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_financial_services_compliance_2024", "relationship": "informative_reference", "rationale": "AWS's financial services regulatory guide and compliance tooling document infrastructure-layer capabilities relevant to the apeiris://finance/controls/FC-07 Financial Data Integrity Monitoring control.", "reviewed_on": "2026-07-02" }, { "id": "google_cloud_financial_services_ai_2024", "title": "Google Cloud Explainable AI", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/explainable-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_financial_services_ai_2024", "relationship": "informative_reference", "rationale": "Google Cloud's Explainable AI and Vertex AI model governance documentation describes platform capabilities relevant to the apeiris://finance/controls/FC-07 Financial Data Integrity Monitoring control.", "reviewed_on": "2026-07-02" }, { "id": "okta_financial_services_access_2025", "title": "Okta for Financial Services", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://www.okta.com/solutions/financial-services/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_financial_services_access_2025", "relationship": "informative_reference", "rationale": "Okta's identity products (System Log, access management, Adaptive MFA, Privileged Access) supply identity-layer enforcement and evidence relevant to the apeiris://finance/controls/FC-07 Financial Data Integrity Monitoring control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Compute SHA-256 checksums at every data handoff point in the financial AI pipeline (training data ingestion, feature store write, inference input, model output); store checksums in an append-only integrity log; verify checksums at each consumption point; alert on mismatch; maintain data lineage graph from source to financial statement line item; run automated provenance verification daily.", "steps": [ "Instrument all data handoff points in financial AI pipelines to compute and record SHA-256 checksums; store checksums in an append-only integrity log with handoff timestamp, source system, destination system, and data element identifier.", "Implement checksum verification at each data consumption point \u2014 feature store reads, inference input preprocessing, model output post-processing; route any mismatch alert to the exception management queue (FC-06) as a critical exception.", "Maintain an automated data lineage graph mapping each financial AI data element from its originating source through all transformation steps to its final financial statement line item; run automated provenance completeness verification daily and report gaps to the model risk officer and financial controller." ], "financial_controller": { "summary": "Data integrity is the foundation of reliable AI-generated financial data. Integrity violations must be treated as critical exceptions and must block financial data from entering reporting until resolved.", "actions": [ "Review the daily data integrity monitoring summary; confirm zero unresolved integrity violations before approving AI-generated data for period-close use.", "Require the model risk officer and IT operations to provide written confirmation of data integrity for all in-scope AI systems before signing the Section 302 certification.", "Disclose any integrity violation with a financial impact above the materiality threshold to external auditors within one business day of discovery." ], "failure_signals": [ "Period close proceeding with an unresolved data integrity violation in a financial AI pipeline.", "Section 302 certification signed without written data integrity confirmation from model risk and IT operations.", "Material integrity violation not disclosed to external auditors within one business day." ] }, "model_risk_officer": { "summary": "Data integrity violations are potential indicators of training data poisoning or input manipulation attacks affecting model outputs. Investigate all integrity alerts with a model-risk lens.", "actions": [ "Review all data integrity alerts for financial AI systems; assess whether the violation could affect model training, validation, or inference outputs.", "Initiate model revalidation for any integrity violation affecting training data or feature store data used by a financial reporting model.", "Include data integrity violation history in the quarterly model risk report." ], "failure_signals": [ "Training data integrity violation not triggering a model revalidation assessment.", "Data integrity violation history absent from quarterly model risk report.", "Integrity violation root cause investigation exceeding five business days." ] }, "it_operations": { "summary": "Own the integrity monitoring infrastructure: checksum computation, append-only log storage, verification jobs, and lineage graph maintenance. These are critical financial controls infrastructure.", "actions": [ "Maintain checksum instrumentation at all financial AI pipeline data handoff points; test instrumentation coverage monthly.", "Ensure the integrity log is append-only, access-controlled, and retained for seven years; provide read access to internal audit and external auditors on request.", "Monitor the lineage graph completeness daily; alert the financial controller and model risk officer when any financial data element loses traceable lineage to its source." ], "failure_signals": [ "Checksum instrumentation coverage below 100% of financial AI pipeline handoff points.", "Integrity log not append-only or accessible to auditors.", "Lineage gap alert not escalated within two business hours." ] }, "internal_audit": { "summary": "Test the completeness and effectiveness of data integrity monitoring. Verify that the integrity log is tamper-proof and that violations are escalated and resolved appropriately.", "actions": [ "Annually, map all financial AI pipeline data handoff points and verify each is instrumented for checksum monitoring; report coverage gaps.", "Test the tamper-proof integrity log by attempting a write operation with a non-privileged account; verify the attempt is rejected and logged.", "Sample five integrity alerts from the prior quarter; verify each was routed to the exception queue, investigated, and resolved with documented root cause." ], "failure_signals": [ "Financial AI pipeline handoff point not instrumented for integrity monitoring.", "Integrity log write attempt by non-privileged account succeeds.", "Integrity alert without a corresponding exception queue record or resolved root cause." ] }, "compliance_officer": { "summary": "Data integrity failures upstream of financial AI become compliance events when they corrupt reported figures; monitoring evidence is the defense.", "actions": [ "Map integrity monitoring coverage to the data flows behind regulated reports.", "Review integrity incidents affecting financial AI inputs for downstream reporting impact." ], "metrics": [ "Integrity monitoring coverage of regulated-report data flows: 100%.", "Integrity incidents with completed downstream impact assessment: 100%." ], "failure_signals": [ "Regulated reports produced from pipelines with known unresolved integrity failures.", "Integrity incidents closed without downstream reporting impact review." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Checksum verification exists for file transfers in many enterprises, but end-to-end cryptographic integrity monitoring across AI pipeline data handoffs is largely absent from current practice." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "cloud-native", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "IT Operations", "Model Risk Officer", "Financial Controller", "Internal Audit" ], "frameworks": [ { "framework": "sox", "requirement_id": "\u00a7404", "fit": "direct", "rationale": "SOX \u00a7404 requires assessment of internal control over financial reporting. Data integrity over inputs to AI systems that produce financial figures is evaluated in practice as an IT general control supporting ICFR \u2014 a construct from the auditing literature (AS 2201), not from the statutory text, which is why this control cites plain \u00a7404.", "normative_force": "binding-law", "source_version": "2002 as amended", "reviewed_on": "2026-07-02", "basis": "asserted", "relation": "satisfies" }, { "framework": "bcbs_239", "requirement_id": "Principles 2-4", "fit": "direct", "rationale": "BCBS 239 Principles 2, 3, and 4 require data accuracy, completeness, and integrity for risk data aggregation. The checksum-based integrity monitoring and lineage verification required by this control directly operationalize these principles for financial AI data flows.", "normative_force": "supervisory-guidance", "source_version": "2013", "reviewed_on": "2026-06-28", "basis": "asserted", "relation": "satisfies" }, { "framework": "soc2", "requirement_id": "CC6.6, CC6.7, CC7.2", "fit": "direct", "rationale": "AICPA SOC 2 CC6.6 and CC6.7 address logical access and transmission integrity, while CC7.2 requires monitoring for unauthorized access and anomalies. The integrity log and checksum verification required by this control provide the technical evidence base for these criteria.", "normative_force": "certification-standard", "source_version": "2022", "reviewed_on": "2026-06-28", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "sr26_2", "requirement_id": "\u00a7IV", "fit": "direct", "rationale": "SR 26-2 \u00a7IV (Model Development and Use) describes assessing data quality and relevance during model development and use. Continuous input-data integrity monitoring with checksums and lineage tracking operationalizes that data quality expectation for production financial AI pipelines.", "normative_force": "supervisory-guidance", "source_version": "2026-04-17", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "eu_ai_act", "requirement_id": "Art. 10(3)", "fit": "partial", "rationale": "EU AI Act Art. 10(3) requires that training, validation, and testing data sets be relevant, sufficiently representative, and to the best extent possible free of errors and complete in view of the intended purpose. Continuous data integrity monitoring over financial AI input pipelines is the operational control that sustains those data quality properties in production.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "openai_enterprise", "requirement_id": "Zero data retention (API)", "fit": "partial", "rationale": "The OpenAI API offers zero-data-retention handling for eligible endpoints, documented in OpenAI's enterprise privacy commitments. Institutions using OpenAI models in financial workflows can incorporate this vendor capability into financial data integrity monitoring for AI pipelines. This is vendor capability documentation, not regulatory guidance; it covers the vendor side only.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "RS1", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal RS1 (Reliability and safety guidance) requires following reliability and safety guidance when developing and deploying systems, including defining safe operating parameters. For institutions using Azure AI services, this goal produces vendor-side governance artifacts that align with financial data integrity monitoring for AI pipelines. The Standard is Microsoft's published internal policy offered as reference practice, not regulatory guidance.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_financial", "requirement_id": "AWS CloudTrail", "fit": "partial", "rationale": "AWS CloudTrail records API activity across AWS accounts with actor, action, and timestamp detail, exportable for retention and analysis. For AWS-hosted financial AI systems, this supplies the infrastructure-layer support and evidence stream for financial data integrity monitoring for AI pipelines. This is vendor documentation of real AWS capabilities \u2014 it does not substitute for model-layer validation or regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_financial", "requirement_id": "Vertex AI Model Monitoring", "fit": "partial", "rationale": "Vertex AI Model Monitoring detects prediction drift and training-serving skew for models deployed on Google Cloud. For GCP-hosted financial AI systems, this capability supplies the platform-layer support for financial data integrity monitoring for AI pipelines. This is vendor product documentation, not regulatory guidance; it does not address model-layer regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "okta_financial", "requirement_id": "Okta System Log", "fit": "adjacent", "rationale": "The Okta System Log records authentication and access events with actor, target, outcome, and timestamp detail, exportable for audit retention. Where access to financial AI systems is brokered through Okta, this capability supplies the identity-layer enforcement and evidence for financial data integrity monitoring for AI pipelines. This is vendor product documentation, not a financial-services control framework.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://finance/controls/FC-07", "meta": { "authored_on": "2026-06-29", "schema_version": "1.1.0" }, "validation_objective": "All data entering and exiting financial AI systems \u2014 including training datasets, inference inputs, feature store values, and model outputs \u2014 must have cryptographic integrity hashes computed and verified at each ingestion and output point, with any hash mismatch triggering an immediate alert and pipeline suspension before processing continues.", "evidence_required": [ "integrity_hash_log showing hash algorithm, hash value, computation_timestamp, and verification_result for each dataset, inference_input batch, and model_output batch processed by financial AI systems in the monitoring period", "hash_mismatch_alert_record for each integrity violation detected, including affected data asset, mismatch detected_at timestamp, pipeline_suspension_timestamp, investigation_outcome, and resolution_action", "data_integrity_monitoring_configuration document showing which data flows are covered by cryptographic monitoring, the hash algorithm used, and alert routing configuration", "integrity_monitoring_coverage_report demonstrating that all financial AI data inputs and outputs are within scope of hash-based integrity monitoring with no uncovered data flows" ], "machine_tests": [ "Inject a tampered inference input batch with a deliberately mismatched hash into the financial AI pipeline \u2192 assert pipeline suspends within 60 seconds and hash_mismatch_alert_record is created with severity=critical", "Query integrity_hash_log for any financial AI data flow with no hash_verification_result in the current monitoring period \u2192 assert zero uncovered flows exist", "Modify a training dataset record without updating its registered hash \u2192 assert integrity monitor detects the mismatch on the next scheduled verification scan and raises an alert" ], "human_review": [ "Verify that the integrity monitoring coverage report accounts for all data flows including batch ETL pipelines, real-time feature store updates, and model output delivery channels \u2014 not only the primary inference API", "Assess the hash mismatch investigation process: confirm investigations produce a documented root cause distinguishing data corruption from unauthorized modification rather than simply reprocessing the data", "Review whether the hash algorithm in use meets current cryptographic standards and whether a documented rotation schedule exists for algorithm migration" ], "blocking_effect": "blocks-runtime-action", "normative_status": "binding-law", "anti_patterns": [ "Computing integrity hashes only on training datasets at rest while omitting real-time verification of inference inputs and model outputs, leaving the live inference pipeline unprotected against data manipulation", "Logging hash values without performing automated verification at each ingestion point, creating an appearance of integrity monitoring without actual mismatch detection capability", "Using weak or deprecated hash algorithms (MD5, SHA-1) for financial data integrity verification, making hash collision attacks feasible for sophisticated adversaries targeting financial outputs", "Treating hash mismatches as operational incidents to be retried rather than security events requiring investigation, allowing data manipulation to go undetected through retry exhaustion", "Excluding feature store data from integrity monitoring scope on the basis that it is derived data, when feature corruption is a primary vector for manipulating live model behavior on financial data" ], "update_status": "current", "layer_code": "FC" }, { "id": "FC-08", "layer": "FC", "plane": "both", "name": "Financial Controls Evidence Package", "plain": "At each reporting period close, a Financial Controls Evidence Package must be compiled from FC-01 through FC-07 artifacts, assembling a complete, auditor-ready evidence set demonstrating that SOX and financial controls requirements are met by the enterprise's financial AI systems, signed by the financial controller, and retained for seven years.", "threat": { "tags": [ "audit-evidence-gap", "incomplete-icfr-assessment", "regulatory-exposure", "attestation-failure" ], "desc": "Without a deliberate evidence compilation process, individual control artifacts from FC-01 through FC-07 may be complete in isolation but fail to provide the integrated picture auditors require for a SOX 404 assessment. Missing or inconsistent evidence across controls creates audit qualification risk. Inadequate evidence retention exposes the enterprise to regulatory penalties and litigation risk if financial AI system decisions are later challenged." }, "standard": [ { "id": "sox", "section": "\u00a7302, \u00a7404", "title": "Management certification and ICFR assessment evidence requirements" }, { "id": "coso_icfr", "section": "Principle 17", "title": "Communication of control deficiencies \u2014 reporting requirements" }, { "id": "pcaob_as_2201", "section": "\u00b6.72-.76", "title": "Written representations from management" }, { "id": "omb_a_123", "section": "Section IV.A", "title": "Documentation of internal controls" } ], "sources": [ { "id": "openai_enterprise_data_governance_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "OpenAI's enterprise privacy and compliance documentation records vendor-side data handling and audit-log capabilities relevant to the apeiris://finance/controls/FC-08 Financial Controls Evidence Package control.", "reviewed_on": "2026-07-02" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://finance/controls/FC-08 Financial Controls Evidence Package control.", "reviewed_on": "2026-07-01" }, { "id": "aws_financial_services_compliance_2024", "title": "AWS User Guide to Financial Services Regulations & Guidelines in the United States", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/financial-services/security-compliance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_financial_services_compliance_2024", "relationship": "informative_reference", "rationale": "AWS's financial services regulatory guide and compliance tooling document infrastructure-layer capabilities relevant to the apeiris://finance/controls/FC-08 Financial Controls Evidence Package control.", "reviewed_on": "2026-07-02" }, { "id": "google_cloud_financial_services_ai_2024", "title": "Google Cloud Explainable AI", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/explainable-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_financial_services_ai_2024", "relationship": "informative_reference", "rationale": "Google Cloud's Explainable AI and Vertex AI model governance documentation describes platform capabilities relevant to the apeiris://finance/controls/FC-08 Financial Controls Evidence Package control.", "reviewed_on": "2026-07-02" }, { "id": "okta_financial_services_access_2025", "title": "Okta for Financial Services", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://www.okta.com/solutions/financial-services/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_financial_services_access_2025", "relationship": "informative_reference", "rationale": "Okta's identity products (System Log, access management, Adaptive MFA, Privileged Access) supply identity-layer enforcement and evidence relevant to the apeiris://finance/controls/FC-08 Financial Controls Evidence Package control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Define a standard FC Evidence Package structure with eight sections (one per control FC-01 through FC-07 plus a summary attestation); automate collection of evidence artifacts from each control's systems; assemble the package in a document management system with access logging; obtain financial controller sign-off; submit to external auditors at 404 assessment kickoff; retain for seven years.", "pattern_extended": "The evidence package serves as the primary artifact for external auditor testing under PCAOB AS 2201 and provides the documentary basis for management's Section 302 and 404 certifications. It must be complete, consistent, and cross-referenced so auditors can navigate from a control objective to its test results and underlying evidence without gaps.", "steps": [ "Define the FC Evidence Package structure: eight sections covering (1) AI-in-scope ICFR control library and test results (FC-01), (2) materiality assessment and conclusions (FC-02), (3) reconciliation ledger and variance resolution (FC-03), (4) change management log and approvals (FC-04), (5) access control quarterly review and exception log (FC-05), (6) exception management report and resolution log (FC-06), (7) data integrity monitoring log and lineage graph (FC-07), and (8) financial controller attestation with sign-off.", "Automate evidence collection from each control's source system \u2014 ICFR control library, aggregation ledger, reconciliation ledger, change management system, access review tool, exception queue, integrity log \u2014 into a pre-populated package template; flag any section with missing or incomplete evidence for manual remediation before the package is finalized.", "Obtain financial controller sign-off on the completed package no later than five business days before the external auditor 404 assessment kickoff; submit the package to auditors with an index cross-referencing each section to the relevant PCAOB AS 2201 requirement; retain the signed package in an access-controlled document management system for seven years." ], "financial_controller": { "summary": "Your signature on the FC Evidence Package is a formal attestation that the evidence is complete and that the controls described therein were operating effectively during the reporting period. Review every section before signing.", "actions": [ "Review each section of the FC Evidence Package for completeness: confirm all required artifacts are present, all deficiencies are documented, and all remediation actions are recorded.", "Sign the attestation section of the package; retain a personal copy in addition to the system record.", "Submit the signed package to external auditors at 404 assessment kickoff and be available to answer auditor questions about any section." ], "failure_signals": [ "FC Evidence Package submitted to auditors without financial controller sign-off.", "Section with missing or incomplete evidence not flagged before sign-off.", "Package not submitted to external auditors within five business days before 404 assessment kickoff." ] }, "compliance_officer": { "summary": "Monitor the FC Evidence Package for regulatory completeness. Ensure the package covers all requirements for the applicable regulatory frameworks and is updated when new guidance is issued.", "actions": [ "Review the FC Evidence Package template annually; update section requirements to reflect new SOX, PCAOB, or SEC guidance on AI in financial reporting.", "Confirm that the package cross-reference index is current and correctly maps to the applicable version of PCAOB AS 2201.", "Maintain a retention log confirming that signed packages from each reporting period are stored and accessible." ], "metrics": [ "Package completion rate: percentage of reporting periods with a completed, signed FC Evidence Package submitted on time \u2014 target 100%.", "Evidence completeness: percentage of required artifacts present in the package at time of financial controller sign-off \u2014 target 100%.", "Retention compliance: percentage of prior-period packages retrievable within 24 hours upon auditor or regulator request \u2014 target 100%." ], "failure_signals": [ "Package template not updated within 90 days of material new guidance.", "Prior-period package not retrievable within 24 hours upon request.", "Package completion rate below 100% in any reporting period." ] }, "internal_audit": { "summary": "Internal audit is responsible for independently verifying the completeness and accuracy of the FC Evidence Package before it is submitted to external auditors.", "actions": [ "Conduct an independent pre-submission review of the FC Evidence Package: sample artifacts from each section, verify consistency between sections, and confirm all deficiencies are disclosed.", "Provide a written pre-submission opinion to the financial controller \u2014 acceptable for submission or requires remediation before submission.", "After external audit, review auditor findings related to the FC Evidence Package and recommend improvements to the collection and assembly process." ], "failure_signals": [ "FC Evidence Package submitted to external auditors without an internal audit pre-submission review.", "Internal audit pre-submission opinion not documented in writing.", "Auditor finding that was identifiable in pre-submission review not caught by internal audit." ] }, "model_risk_officer": { "summary": "Provide model risk artifacts \u2014 validation reports, exception summaries, change logs \u2014 to the FC Evidence Package on schedule. Delays from model risk functions are the most common cause of late package submissions.", "actions": [ "Deliver all model risk artifacts (validation reports, exception frequency summaries, change management records) to the evidence package assembly team at least ten business days before the financial controller sign-off deadline.", "Confirm that model risk artifacts are consistent with the corresponding sections of the FC Evidence Package (e.g., exception counts match between FC-06 and model risk report).", "Flag any model risk finding that has not yet been reflected in the FC Evidence Package during the pre-submission window." ], "failure_signals": [ "Model risk artifacts delivered less than ten business days before sign-off deadline.", "Inconsistency between model risk report and FC Evidence Package exception counts.", "Model risk finding not reflected in FC Evidence Package at time of submission." ] }, "it_operations": { "summary": "IT Operations runs the controls evidence repository behind the financial controls evidence package \u2014 integrating it with deployment pipelines, enforcing the automated gates, and keeping the supporting data flows reliable and auditable.", "actions": [ "Integrate the controls evidence repository with CI/CD and runtime tooling so that control-execution evidence is captured automatically at run time.", "Automate collection and retention of control-execution logs and evidence snapshots in immutable, hash-verified storage.", "Monitor pipeline and integration health and alert when evidence capture gaps appear for in-scope controls." ], "failure_signals": [ "Production changes bypass the automated gate so that it is no longer true that control-execution evidence is captured automatically at run time.", "Gaps or outages in control-execution logs and evidence snapshots collection exceeding 24 hours.", "Manual, untracked edits to the controls evidence repository records." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Most enterprises compile SOX evidence packages, but few have a structured process for assembling AI-specific controls evidence into an integrated, auditor-ready package with cross-references to all FC-layer controls." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai" ], "implementers": [ "Financial Controller", "Compliance Officer", "Internal Audit", "Model Risk Officer" ], "frameworks": [ { "framework": "sox", "requirement_id": "\u00a7302, \u00a7404", "fit": "direct", "rationale": "The FC Evidence Package is the primary documentary artifact that supports management's Section 302 certification and Section 404 assessment. Its completeness and accuracy are directly required by both SOX provisions; deficiencies in the package constitute deficiencies in management's ICFR assessment.", "normative_force": "binding-law", "source_version": "2002 as amended", "reviewed_on": "2026-06-28", "basis": "asserted", "relation": "satisfies" }, { "framework": "pcaob_as_2201", "requirement_id": "\u00b6.72-.76", "fit": "direct", "rationale": "AS 2201 \u00b6.72-.76 require the auditor to obtain written representations from management about ICFR, including that management has disclosed all deficiencies. The financial controls evidence package is the artifact base that lets management make those representations about AI-dependent controls with support.", "normative_force": "certification-standard", "source_version": "2007 as amended", "reviewed_on": "2026-07-02", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "coso_icfr", "requirement_id": "Principle 17", "fit": "direct", "rationale": "COSO Principle 17 requires organizations to communicate control deficiencies to responsible parties and to document the evaluation and reporting process. The FC Evidence Package fulfills this principle by assembling all deficiency disclosures, remediation records, and control test results into a single governed document.", "normative_force": "industry-framework", "source_version": "2013", "reviewed_on": "2026-06-28", "basis": "asserted", "relation": "informs" }, { "framework": "omb_a_123", "requirement_id": "Section IV.A", "fit": "adjacent", "rationale": "OMB Circular A-123 (M-16-17) Section IV.A requires documentation of internal controls to support the assessment and assurance process. A financial controls evidence package is that documentation discipline applied to AI-dependent controls.", "normative_force": "supervisory-guidance", "source_version": "2016", "reviewed_on": "2026-07-02", "basis": "asserted", "relation": "satisfies" }, { "framework": "eu_ai_act", "requirement_id": "Art. 18, Annex IV", "fit": "partial", "rationale": "EU AI Act Article 18 and Annex IV require providers of high-risk AI systems to maintain technical documentation demonstrating compliance. For financial AI systems, the FC Evidence Package provides a significant portion of the documentation required under Annex IV, supporting both internal compliance and notified body assessments.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-06-28", "basis": "anchored", "relation": "satisfies" }, { "framework": "soc2", "requirement_id": "CC4.1, CC4.2", "fit": "adjacent", "rationale": "AICPA SOC 2 CC4.1 and CC4.2 require that the organization evaluate and communicates control deficiencies. The FC Evidence Package, with its cross-referenced control test results and deficiency disclosures, provides the documentation base for a SOC 2 audit covering financial AI systems.", "normative_force": "certification-standard", "source_version": "2022", "reviewed_on": "2026-06-28", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "openai_enterprise", "requirement_id": "Enterprise Compliance API \u2014 audit logs", "fit": "partial", "rationale": "ChatGPT Enterprise and the OpenAI API expose workspace audit-log data through the Compliance API and audit logs endpoint, exportable to SIEM and evidence stores. Institutions using OpenAI models in financial workflows can incorporate this vendor capability into the financial controls evidence package. This is vendor capability documentation, not regulatory guidance; it covers the vendor side only.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "A1", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal A1 (Impact assessment) requires documented impact assessments identifying intended uses, stakeholders, and potential harms. For institutions using Azure AI services, this goal produces vendor-side governance artifacts that align with the financial controls evidence package. The Standard is Microsoft's published internal policy offered as reference practice, not regulatory guidance.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_financial", "requirement_id": "AWS Artifact", "fit": "partial", "rationale": "AWS Artifact provides on-demand access to AWS's third-party compliance reports (SOC 1/2, PCI DSS, ISO). For AWS-hosted financial AI systems, this supplies the infrastructure-layer support and evidence stream for the financial controls evidence package. This is vendor documentation of real AWS capabilities \u2014 it does not substitute for model-layer validation or regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_financial", "requirement_id": "Google Cloud compliance offerings", "fit": "partial", "rationale": "Google Cloud's compliance offerings catalog documents the platform's third-party attestations (SOC 1/2/3, ISO/IEC 27001, PCI DSS) available to customers. For GCP-hosted financial AI systems, this capability supplies the platform-layer support for the financial controls evidence package. This is vendor product documentation, not regulatory guidance; it does not address model-layer regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "okta_financial", "requirement_id": "Okta System Log", "fit": "adjacent", "rationale": "The Okta System Log records authentication and access events with actor, target, outcome, and timestamp detail, exportable for audit retention. Where access to financial AI systems is brokered through Okta, this capability supplies the identity-layer enforcement and evidence for the financial controls evidence package. This is vendor product documentation, not a financial-services control framework.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://finance/controls/FC-08", "meta": { "authored_on": "2026-06-29", "schema_version": "1.1.0" }, "validation_objective": "At each reporting period close, a complete Financial Controls Evidence Package assembled from FC-01 through FC-07 artifacts must be reviewed and signed by the financial controller and Chief Compliance Officer before the period-close certification is signed, with all evidence gaps formally documented in a gap register with compensating controls \u2014 and no certification signed until the package is complete or gaps are formally accepted.", "evidence_required": [ "financial_controls_evidence_package index document listing all included artifacts (FC-01 through FC-07 control evidence), their file references, completeness status, and financial controller sign-off date", "evidence_gap_register documenting any FC-01 through FC-07 evidence items that could not be obtained, with risk assessment, compensating control description, and named approver sign-off", "auditor_delivery_record confirming the package was delivered to external auditors with delivery timestamp, recipient names, and package hash for integrity verification", "period_close_certification signed by financial controller attesting that the evidence package is complete or that all gaps are documented with accepted compensating controls" ], "machine_tests": [ "Check evidence package index for completeness: verify artifacts for all seven FC controls (FC-01 through FC-07) are referenced and have status=complete or status=gap-documented \u2192 assert no controls have status=missing", "Verify financial_controls_evidence_package index has financial_controller_signature and cco_signature fields populated with non-null values and valid timestamps \u2192 assert both signatures present", "Query period-close certification timestamps against evidence_package completion timestamp \u2192 assert certification was not signed before evidence package was marked complete" ], "human_review": [ "Review the evidence gap register to assess whether compensating controls for any missing FC-01 through FC-07 artifacts are genuinely compensating or are merely acknowledgments that the control was not met", "Verify that the evidence package format and content satisfies external auditor fieldwork requirements \u2014 not just internal standards \u2014 by confirming with the engagement audit team", "Assess year-over-year trends in evidence gaps: persistent gaps in the same control across multiple periods may indicate a systemic control failure requiring process redesign rather than recurring compensating control workarounds" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Assembling the evidence package after auditor fieldwork has started rather than before period-close sign-off, forcing auditors to work from incomplete evidence and increasing the risk of material audit findings", "Treating the evidence package as a document collection rather than a verified chain of evidence by omitting hash verification of included artifacts, allowing undetected substitution of prior-period evidence", "Signing the period-close certification before the evidence package is complete on the assumption that remaining items will be gathered during the audit \u2014 violating the pre-certification completeness requirement", "Failing to document evidence gaps in a formal gap register and instead verbally informing auditors of missing items without a written compensating control assessment", "Reusing prior-period evidence artifacts for controls that require current-period re-evaluation, creating an appearance of current-period testing without actual current-period evidence" ], "update_status": "current", "layer_code": "FC" }, { "id": "FP-01", "layer": "FP", "plane": "control", "name": "AI Use Policy for Financial Decision-Making", "plain": "The organization must maintain a board-approved policy that explicitly classifies each financial decision type as AI-driven, AI-assisted, or human-only, and defines the conditions, limits, and oversight requirements for each classification.", "threat": { "tags": [ "unauthorized-ai-decision", "human-oversight-bypass", "decision-accountability-gap", "regulatory-non-compliance" ], "desc": "Without an explicit policy classifying AI authority in financial decisions, systems may autonomously execute consequential actions\u2014such as credit approvals, trade executions, or write-offs\u2014without required human review. This creates accountability gaps that regulators identify as material control failures and exposes the organization to enforcement action under SOX and the EU AI Act, and to supervisory criticism under SR 26-2." }, "standard": [ { "id": "sox", "section": "Section 302 & 404", "title": "Management assessment of internal controls over financial reporting" }, { "id": "sr26_2", "section": "\u00a7VI (Governance and Controls)", "title": "Model-use policy" }, { "id": "eu_ai_act", "section": "Art. 9", "title": "Risk management system for high-risk AI systems" }, { "id": "coso_icfr", "section": "Principle 12", "title": "Control activities over financial reporting processes" } ], "sources": [ { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://finance/controls/FP-01 AI Use Policy for Financial Decision-Making control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Anthropic's Responsible Scaling Policy v3.3 documents the vendor's capability thresholds and safeguards, cited as third-party AI due diligence context for the apeiris://finance/controls/FP-01 AI Use Policy for Financial Decision-Making control.", "reviewed_on": "2026-07-02" }, { "id": "aws_financial_services_compliance_2024", "title": "AWS User Guide to Financial Services Regulations & Guidelines in the United States", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/financial-services/security-compliance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_financial_services_compliance_2024", "relationship": "informative_reference", "rationale": "AWS's financial services regulatory guide and compliance tooling document infrastructure-layer capabilities relevant to the apeiris://finance/controls/FP-01 AI Use Policy for Financial Decision-Making control.", "reviewed_on": "2026-07-02" }, { "id": "google_cloud_financial_services_ai_2024", "title": "Google Cloud Explainable AI", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/explainable-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_financial_services_ai_2024", "relationship": "informative_reference", "rationale": "Google Cloud's Explainable AI and Vertex AI model governance documentation describes platform capabilities relevant to the apeiris://finance/controls/FP-01 AI Use Policy for Financial Decision-Making control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Tiered decision taxonomy with per-tier approval authority, override logging, and annual policy review cycle anchored to the model risk governance calendar.", "steps": [ "Inventory all financial decision processes and classify each as AI-driven, AI-assisted, or human-only using a documented risk-tiering rubric reviewed by the Model Risk Officer.", "Draft and obtain board or audit committee approval for the AI Use Policy, specifying materiality thresholds, escalation paths, and sunset review dates.", "Embed the policy classification into workflow systems so that AI-driven decisions trigger automated logging and AI-assisted decisions surface the AI recommendation with a mandatory human acknowledgment field.", "Schedule an annual policy review tied to the model risk governance cycle and document outcomes as FP-08 evidence." ], "financial_controller": { "summary": "The policy directly governs which financial outputs may rely on AI without human sign-off. The CFO's office must own the materiality thresholds and decision classifications.", "actions": [ "Review and approve the decision taxonomy, focusing on materiality thresholds for AI-driven decisions.", "Confirm that AI-driven decisions below materiality are logged and sampled in monthly close reviews.", "Escalate any AI decision classification change to the Audit Committee." ], "failure_signals": [ "Material AI-driven financial decisions executed without a logged human acknowledgment.", "Policy not reviewed within 13 months of last approval date.", "Decision taxonomy not updated following a new model deployment." ] }, "model_risk_officer": { "summary": "The MRO must ensure that model capabilities align with the policy classification and that models are not used outside their approved decision scope.", "actions": [ "Map each model in the inventory to one or more decision classifications and flag any scope mismatch.", "Define the criteria for reclassifying a decision from AI-assisted to AI-driven, requiring MRO sign-off.", "Track policy exceptions and escalate patterns to the risk committee." ], "failure_signals": [ "Model deployed for a decision type not covered by the current policy classification.", "Exception rate for human override of AI-driven decisions exceeds 5% in any quarter.", "No documented rationale for AI-driven classification for any high-materiality decision." ] }, "compliance_officer": { "summary": "Compliance must verify that the policy meets supervisory expectations described in SR 26-2 and binding requirements under SOX and EU AI Act Article 9, and that evidence of board approval is audit-ready.", "actions": [ "Map each policy section to the applicable regulatory requirement and document the mapping in the compliance register.", "Confirm that board or audit committee approval minutes reference the policy version.", "Prepare the policy and approval evidence as part of the FP-08 evidence package." ], "metrics": [ "Policy coverage: 100% of financial AI decision types classified.", "Board approval currency: policy approved within the last 12 months.", "Regulatory mapping completeness: all applicable requirements mapped." ], "failure_signals": [ "Financial AI decision type identified in operations not covered by the policy.", "Board approval document missing or older than 12 months.", "Regulatory mapping not updated after a new regulatory guidance publication." ] }, "it_operations": { "summary": "IT Operations runs policy-enforcement points in decision workflows behind the AI use policy classifying decision authority \u2014 integrating it with deployment pipelines, enforcing the automated gates, and keeping the supporting data flows reliable and auditable.", "actions": [ "Integrate policy-enforcement points in decision workflows with CI/CD and runtime tooling so that decision types are checked against their authorized AI authority level at run time.", "Automate collection and retention of authority-level enforcement logs in immutable, hash-verified storage.", "Monitor pipeline and integration health and alert when decisions execute above their authorized authority level." ], "failure_signals": [ "Production changes bypass the automated gate so that it is no longer true that decision types are checked against their authorized AI authority level at run time.", "Gaps or outages in authority-level enforcement logs collection exceeding 24 hours.", "Manual, untracked edits to policy-enforcement points in decision workflows records." ] }, "internal_audit": { "summary": "Internal audit verifies the AI use policy is enforced in systems, not just approved by the board.", "actions": [ "Test that decision workflows enforce the authority classifications the policy assigns.", "Verify policy exceptions carry documented approvals and expirations.", "Confirm annual policy review actually assessed classification accuracy." ], "failure_signals": [ "Decisions executing at higher autonomy than their policy classification.", "Open-ended policy exceptions without expiry or review.", "Policy reviews that never changed a classification despite system changes." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Most organizations classify decisions informally; a board-approved, tiered taxonomy is the key maturity step." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "federated-enterprise" ], "implementers": [ "CFO Office", "Model Risk Officer", "Compliance Officer", "Legal" ], "frameworks": [ { "framework": "sox", "requirement_id": "Section 302 & 404", "fit": "direct", "rationale": "SOX Sections 302 and 404 require management to assess and certify the effectiveness of internal controls over financial reporting. An explicit AI use policy is a prerequisite control for demonstrating that AI-driven financial outputs are subject to appropriate oversight. Without it, auditors cannot assess the reliability of AI-influenced financial statements.", "normative_force": "binding-law", "source_version": "2002", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "satisfies" }, { "framework": "sr26_2", "requirement_id": "\u00a7VI (Governance and Controls)", "fit": "direct", "rationale": "SR 26-2 \u00a7VI describes policies that define how models are used and governed, including appropriate restrictions, as part of governance and controls. Classifying financial decisions by AI authority level is an implementation of that model-use policy discipline.", "normative_force": "supervisory-guidance", "source_version": "2026-04-17", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "eu_ai_act", "requirement_id": "Art. 9", "fit": "direct", "rationale": "The EU AI Act Article 9 requires that high-risk AI systems operating in financial services have a documented risk management system. An AI use policy that defines human oversight requirements for each decision type is a core component of that system. Organizations deploying high-risk financial AI in the EU must demonstrate this policy is documented and operative.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "coso_icfr", "requirement_id": "Principle 12", "fit": "direct", "rationale": "COSO ICIF Principle 12 requires that the organization deploys control activities through policies that establish what is expected. An AI use policy that classifies decision authority is a policy-level control activity directly supporting financial reporting reliability. It establishes clear expectations for when AI outputs require human review before being recorded in financial systems.", "normative_force": "industry-framework", "source_version": "2013", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "A2", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal A2 (Oversight of significant adverse impacts) requires defined review and oversight processes for AI systems that can cause significant adverse impact. For institutions using Azure AI services, this goal produces vendor-side governance artifacts that align with the AI use policy classifying decision authority. The Standard is Microsoft's published internal policy offered as reference practice, not regulatory guidance.", "normative_force": "best-practice", "source_version": "2022", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_financial", "requirement_id": "AWS Audit Manager", "fit": "adjacent", "rationale": "AWS Audit Manager automates evidence collection against control frameworks for AWS workloads, and AWS CloudTrail records account-level API activity. For AWS-hosted financial AI systems, this supplies the infrastructure-layer support and evidence stream for the AI use policy classifying decision authority. This is vendor documentation of real AWS capabilities \u2014 it does not substitute for model-layer validation or regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_financial", "requirement_id": "Vertex AI Model Registry", "fit": "partial", "rationale": "Vertex AI Model Registry provides versioned model registration, aliases, and deployment state tracking on Google Cloud. For GCP-hosted financial AI systems, this capability supplies the platform-layer support for the AI use policy classifying decision authority. This is vendor product documentation, not regulatory guidance; it does not address model-layer regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://finance/controls/FP-01", "meta": { "authored_on": "2026-06-29", "schema_version": "1.1.0" }, "validation_objective": "The organization must have a current board-approved policy that explicitly classifies each financial decision type as AI-driven, AI-assisted, or human-only, and the classification must be operationally enforced \u2014 meaning AI-driven and AI-assisted decisions are technically constrained to operate only within the authorized limits defined in the policy \u2014 with the policy reviewed and re-approved by the board at least annually.", "evidence_required": [ "board_approval_record for the AI Use Policy for Financial Decision-Making showing board meeting date, resolution text, and signatures of authorizing board members or formally delegated committee representatives", "financial_decision_classification_table listing each financial decision type in scope, its classification (AI-driven/AI-assisted/human-only), the conditions and limits under which AI may operate, and the oversight requirements for each decision class", "policy_enforcement_configuration showing how AI-driven and AI-assisted decision limits are technically enforced in production systems \u2014 including approval thresholds, override requirements, and audit trail configuration", "annual_policy_review_record documenting the review date, reviewer names, changes made, and board re-approval confirmation" ], "machine_tests": [ "Submit an AI-driven financial decision request that exceeds the policy-defined decision limit for that decision class \u2192 assert the system blocks the decision and routes to human approval workflow", "Attempt to execute a decision classified as human-only through the AI inference pipeline \u2192 assert the request is rejected with error_code=human_only_decision_class", "Query board_approval_record for the current policy version \u2192 assert approval_date is within the last 12 months" ], "human_review": [ "Verify that the financial decision classification table covers all material financial decision types actually made by AI systems in current production, not only the decision types anticipated at the time the policy was originally drafted", "Assess whether the oversight requirements specified for AI-assisted decisions are operationally feasible and are being met in practice \u2014 not merely documented requirements that are not enforced at runtime", "Confirm that the board approval process was substantive by reviewing board meeting minutes to verify the board reviewed the classification table itself, not only a summary presentation" ], "blocking_effect": "blocks-deployment", "normative_status": "supervisory-guidance", "anti_patterns": [ "Publishing a high-level AI use policy that describes principles but omits a specific decision-type classification table, leaving AI system operators to self-determine what financial decisions AI may make", "Classifying financial decision types at policy launch and never updating the classification as AI system capabilities expand, causing AI systems to operate in decision domains not authorized at the time of board approval", "Treating board approval as a one-time event rather than an annual re-approval requirement, allowing the policy to remain unchanged while the AI system's scope and risk profile evolve materially", "Defining decision limits in the policy document but not technically enforcing them in the AI system, relying on procedural compliance awareness without a technical enforcement backstop", "Applying the AI use policy only to externally-deployed customer-facing AI systems while exempting internal financial reporting AI from the same classification and oversight requirements" ], "update_status": "current", "layer_code": "FP" }, { "id": "FP-02", "layer": "FP", "plane": "control", "name": "Prohibited AI Use Cases in Financial Services", "plain": "The organization must maintain an explicitly enumerated list of AI use cases that are prohibited in financial services contexts, including the rationale for each prohibition, the regulatory or risk basis, and the process for seeking an exemption.", "threat": { "tags": [ "prohibited-use-case-execution", "regulatory-violation", "discriminatory-ai-outcome", "unlawful-model-deployment" ], "desc": "Without an explicit prohibition list, teams may deploy AI for use cases that are barred by law, regulation, or board risk policy\u2014such as using AI for credit decisions without adverse action notice capability, social scoring, or automated individual profiling in contexts prohibited by EU AI Act Annex III. Such deployments expose the organization to regulatory enforcement, civil liability, and reputational damage that can be catastrophic for financial institutions." }, "standard": [ { "id": "eu_ai_act", "section": "Art. 5 & Annex III", "title": "Prohibited AI practices and high-risk classification" }, { "id": "sr26_2", "section": "\u00a7VI (Governance and Controls)", "title": "Model-use restrictions" }, { "id": "sox", "section": "Section 404", "title": "Internal control effectiveness over financial reporting" }, { "id": "coso_icfr", "section": "Principle 8", "title": "Assessment of fraud risk including technology-related risks" } ], "sources": [ { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://finance/controls/FP-02 Prohibited AI Use Cases in Financial Services control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Anthropic's Responsible Scaling Policy v3.3 documents the vendor's capability thresholds and safeguards, cited as third-party AI due diligence context for the apeiris://finance/controls/FP-02 Prohibited AI Use Cases in Financial Services control.", "reviewed_on": "2026-07-02" }, { "id": "openai_enterprise_data_governance_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "OpenAI's enterprise privacy and compliance documentation records vendor-side data handling and audit-log capabilities relevant to the apeiris://finance/controls/FP-02 Prohibited AI Use Cases in Financial Services control.", "reviewed_on": "2026-07-02" }, { "id": "aws_financial_services_compliance_2024", "title": "AWS User Guide to Financial Services Regulations & Guidelines in the United States", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/financial-services/security-compliance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_financial_services_compliance_2024", "relationship": "informative_reference", "rationale": "AWS's financial services regulatory guide and compliance tooling document infrastructure-layer capabilities relevant to the apeiris://finance/controls/FP-02 Prohibited AI Use Cases in Financial Services control.", "reviewed_on": "2026-07-02" }, { "id": "google_cloud_financial_services_ai_2024", "title": "Google Cloud Explainable AI", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/explainable-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_financial_services_ai_2024", "relationship": "informative_reference", "rationale": "Google Cloud's Explainable AI and Vertex AI model governance documentation describes platform capabilities relevant to the apeiris://finance/controls/FP-02 Prohibited AI Use Cases in Financial Services control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Maintained prohibition register with regulatory basis, effective date, and exemption workflow; integrated as a blocking gate in the model onboarding process before development resources are allocated.", "steps": [ "Compile the initial prohibition list by reviewing EU AI Act Article 5, the institution's model-use policy restrictions, applicable consumer protection law, and the board-approved risk appetite statement (FP-03).", "Assign each prohibition a regulatory basis, a severity classification (absolute prohibition versus conditional restriction), and a responsible owner who maintains currency.", "Integrate the prohibition register into the AI model onboarding workflow so that any proposed use case is checked against the register before development resources are allocated, with a hard block on absolute prohibitions.", "Establish an exemption process requiring Legal, Compliance, and MRO sign-off for any request to reclassify a prohibited use case, with all documentation archived in the evidence system." ], "compliance_officer": { "summary": "Compliance owns the prohibition register and must keep it current with evolving regulatory requirements. The register is a primary artifact in regulatory examinations.", "actions": [ "Maintain the prohibition register and publish updates within 30 days of new regulatory guidance affecting AI use in financial services.", "Review the register quarterly and confirm no deployed model maps to a prohibited use case.", "Prepare the prohibition register and any exemption records as part of the FP-08 evidence package." ], "metrics": [ "Register currency: updated within 30 days of material regulatory change.", "Deployment compliance: zero deployed models mapped to an absolute prohibition.", "Exemption tracking: 100% of exemption requests documented with outcome and rationale." ], "failure_signals": [ "Deployed model identified performing a use case on the absolute prohibition list.", "Register not reviewed in the last 90 days.", "Exemption granted without documented Legal and MRO sign-off." ] }, "model_risk_officer": { "summary": "The MRO must verify that each model in the inventory is not performing a prohibited function, including through use-case drift or expanded deployment scope.", "actions": [ "During model onboarding, certify that the proposed use case is not on the prohibition list and document the review.", "Include use-case scope review in ongoing model monitoring to detect prohibited function drift.", "Escalate any suspected prohibited use immediately to Compliance and Legal." ], "failure_signals": [ "Model expanded to a new use case without a prohibition check documented.", "Use-case scope review absent from the ongoing monitoring plan.", "Escalation SLA for suspected prohibited use exceeded 24 hours." ] }, "internal_audit": { "summary": "Internal Audit must independently verify that the prohibition register is complete, current, and enforced at the model onboarding gate.", "actions": [ "Annually test the model onboarding gate by submitting a test request for a prohibited use case and confirming it is blocked.", "Sample deployed models and verify their use cases against the current prohibition register.", "Report any gap between the prohibition register and model inventory to the Audit Committee." ], "failure_signals": [ "Onboarding gate test fails to block a prohibited use case submission.", "Deployed model found performing a use case not reviewed against the prohibition register.", "Gap between prohibition register update date and last audit test exceeds 12 months." ] }, "it_operations": { "summary": "IT Operations runs the prohibition-list enforcement gate behind the prohibited AI use case list and its enforcement gate \u2014 integrating it with deployment pipelines, enforcing the automated gates, and keeping the supporting data flows reliable and auditable.", "actions": [ "Integrate the prohibition-list enforcement gate with CI/CD and runtime tooling so that prohibited use cases are blocked at model registration and at run time.", "Automate collection and retention of gate decisions and block events in immutable, hash-verified storage.", "Monitor pipeline and integration health and alert when a registered use case matches a prohibition-list entry." ], "failure_signals": [ "Production changes bypass the automated gate so that it is no longer true that prohibited use cases are blocked at model registration and at run time.", "Gaps or outages in gate decisions and block events collection exceeding 24 hours.", "Manual, untracked edits to the prohibition-list enforcement gate records." ] }, "financial_controller": { "summary": "Prohibited-use enforcement protects financial processes from AI acting where policy says it must not \u2014 a control-environment fact the controller attests to.", "actions": [ "Verify no prohibited use case touches financial reporting or payment execution workflows.", "Review prohibition-gate block events affecting finance systems each quarter." ], "failure_signals": [ "A prohibited use case discovered running inside a financial process.", "Prohibition list not enforced at the gates in front of finance systems." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most organizations have informal restrictions; a maintained, versioned prohibition register with an enforcement gate is the key maturity step." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai" ], "implementers": [ "Compliance Officer", "Model Risk Officer", "Legal", "Risk Management" ], "frameworks": [ { "framework": "eu_ai_act", "requirement_id": "Art. 5 & Annex III", "fit": "direct", "rationale": "EU AI Act Article 5 establishes absolute prohibitions on specific AI practices, including social scoring and certain biometric identification uses. Annex III classifies credit scoring and insurance risk assessment as high-risk, imposing additional requirements. Organizations must maintain explicit documentation of which prohibited and high-risk use cases have been reviewed, and a prohibition register is the direct implementation artifact.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "sr26_2", "requirement_id": "\u00a7VI (Governance and Controls)", "fit": "direct", "rationale": "SR 26-2 \u00a7VI describes model-use policies within governance and controls; identifying uses that are not approved is the complement of defining approved uses. A maintained prohibition list enforced at the inventory gate operationalizes that policy discipline.", "normative_force": "supervisory-guidance", "source_version": "2026-04-17", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "sox", "requirement_id": "Section 404", "fit": "partial", "rationale": "SOX Section 404 requires that management identify and assess risks that could lead to material misstatement. AI performing prohibited or unconstrained use cases in financial workflows represents such a risk. A prohibition register is an internal control that mitigates this risk by preventing AI use cases that could compromise financial reporting integrity.", "normative_force": "binding-law", "source_version": "2002", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "satisfies" }, { "framework": "microsoft_rai", "requirement_id": "A3", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal A3 (Fit for purpose) requires evidence that the system is fit for the purpose it will serve. For institutions using Azure AI services, this goal produces vendor-side governance artifacts that align with the prohibited AI use case list and its enforcement gate. The Standard is Microsoft's published internal policy offered as reference practice, not regulatory guidance.", "normative_force": "best-practice", "source_version": "2022", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "anthropic_rsp", "requirement_id": "Usage Policy (separate document) \u2014 restricted high-risk uses", "fit": "adjacent", "rationale": "Use-case restrictions for Anthropic models are set by the Anthropic Usage Policy \u2014 a separate document from the RSP \u2014 which restricts specified high-risk uses and requires human oversight for consumer-affecting decisions in regulated domains such as finance. Institutions building prohibition lists should map vendor usage-policy restrictions into their own prohibited-use register. Cited as vendor contractual terms, not supervisory guidance.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "openai_enterprise", "requirement_id": "Enterprise privacy \u2014 compliance commitments", "fit": "adjacent", "rationale": "OpenAI's enterprise privacy documentation records its compliance commitments (SOC 2 Type 2, encryption, retention controls) for enterprise customers. Institutions using OpenAI models in financial workflows can incorporate this vendor capability into the prohibited AI use case list and its enforcement gate. This is vendor capability documentation, not regulatory guidance; it covers the vendor side only.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "aws_financial", "requirement_id": "AWS User Guide to Financial Services Regulations & Guidelines in the United States", "fit": "adjacent", "rationale": "The 'AWS User Guide to Financial Services Regulations & Guidelines in the United States' whitepaper maps AWS services and shared-responsibility considerations to US financial regulatory expectations. For AWS-hosted financial AI systems, this supplies the infrastructure-layer support and evidence stream for the prohibited AI use case list and its enforcement gate. This is vendor documentation of real AWS capabilities \u2014 it does not substitute for model-layer validation or regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_financial", "requirement_id": "Google Cloud compliance offerings", "fit": "adjacent", "rationale": "Google Cloud's compliance offerings catalog documents the platform's third-party attestations (SOC 1/2/3, ISO/IEC 27001, PCI DSS) available to customers. For GCP-hosted financial AI systems, this capability supplies the platform-layer support for the prohibited AI use case list and its enforcement gate. This is vendor product documentation, not regulatory guidance; it does not address model-layer regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://finance/controls/FP-02", "meta": { "authored_on": "2026-06-29", "schema_version": "1.1.0" }, "validation_objective": "The organization must maintain an explicitly enumerated register of prohibited AI use cases in financial services contexts with regulatory or risk basis documented for each prohibition, and the system must technically enforce each prohibition by preventing any AI system deployment or runtime invocation for a prohibited use case \u2014 with the register reviewed and updated within 30 days of any new regulatory prohibition taking effect.", "evidence_required": [ "prohibited_use_case_register listing each prohibited AI use case with use_case_id, description, prohibition_basis (regulatory_reference or risk_rationale), effective_date, and approver name", "enforcement_control_record demonstrating how each prohibition is technically enforced (use case classifier, deployment gate, request-level filter) rather than relying solely on policy acknowledgment", "prohibition_register_review_record documenting review date, reviewer, regulatory updates assessed, and any additions or modifications made to the register in the current period", "use_case_clearance_log showing that each deployed financial AI use case was checked against the prohibition register before deployment approval was granted" ], "machine_tests": [ "Submit a request to deploy an AI system for a use case listed in the prohibited_use_case_register \u2192 assert deployment is blocked with reference to the applicable prohibition_basis and use_case_id", "Submit a runtime inference request invoking a prohibited use case \u2192 assert request is rejected with error_code=prohibited_use_case and the invocation is logged with the matched use_case_id", "Check prohibition_register_review_record most recent review date \u2192 assert review occurred within the last 12 months or within 30 days of the most recent applicable regulatory update" ], "human_review": [ "Review the prohibited_use_case_register against current EU AI Act Annex III, CFPB guidance, and FTC AI guidance to verify that newly enacted prohibitions have been added within the required 30-day window", "Assess whether the technical enforcement mechanisms for each prohibition are genuinely preventing prohibited use cases or are bypass-able through alternative invocation paths not covered by the classifier", "Verify that the register covers both external customer-facing AI and internal financial reporting AI, not only the externally visible use cases that would surface during a routine regulatory examination" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Maintaining a prohibition list that describes prohibited use cases at a high level (e.g., 'discriminatory lending') without mapping them to specific AI system types or invocation patterns that would trigger the prohibition in practice", "Relying on policy acknowledgment training as the sole enforcement mechanism for prohibitions rather than implementing technical controls that prevent prohibited use cases from being deployed or invoked at all", "Defining prohibitions based on the regulatory landscape at policy drafting time and not updating the register when new regulations take effect, causing the organization to unknowingly operate prohibited AI systems", "Restricting the prohibition register to use cases prohibited by external regulation while omitting use cases the organization has internally determined to be too high risk, leaving those decisions to individual AI system owners without governance oversight", "Approving AI system deployments without a documented clearance check against the prohibition register, making it impossible to demonstrate to regulators or auditors that prohibitions were considered before deployment" ], "update_status": "current", "layer_code": "FP" }, { "id": "FP-03", "layer": "FP", "plane": "control", "name": "Financial AI Risk Appetite Statement", "plain": "The board or its designated risk committee must approve and publish a Financial AI Risk Appetite Statement that articulates the maximum acceptable exposure from AI use in financial decision-making, including quantitative thresholds, qualitative risk tolerance boundaries, and conditions for suspension of AI decision authority.", "threat": { "tags": [ "undefined-risk-appetite", "unconstrained-ai-exposure", "board-accountability-gap", "risk-tolerance-drift" ], "desc": "Without a board-approved risk appetite statement, operational teams have no authoritative reference for determining whether a proposed AI deployment is within acceptable risk bounds. This leads to incremental accumulation of AI risk that is never surfaced to the board, creating material exposure to model failures, regulatory censure, and financial loss that the board has not knowingly accepted." }, "standard": [ { "id": "coso_icfr", "section": "Principle 6", "title": "Risk tolerance specification in objective-setting" }, { "id": "sr26_2", "section": "\u00a7III", "title": "Model risk tolerance" }, { "id": "sox", "section": "Section 302", "title": "CEO/CFO certification of internal control adequacy" }, { "id": "omb_a_123", "section": "Section II.B", "title": "Risk profiles \u2014 appetite and tolerance" } ], "sources": [ { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Anthropic's Responsible Scaling Policy v3.3 documents the vendor's capability thresholds and safeguards, cited as third-party AI due diligence context for the apeiris://finance/controls/FP-03 Financial AI Risk Appetite Statement control.", "reviewed_on": "2026-07-02" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://finance/controls/FP-03 Financial AI Risk Appetite Statement control.", "reviewed_on": "2026-07-01" }, { "id": "aws_financial_services_compliance_2024", "title": "AWS User Guide to Financial Services Regulations & Guidelines in the United States", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/financial-services/security-compliance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_financial_services_compliance_2024", "relationship": "informative_reference", "rationale": "AWS's financial services regulatory guide and compliance tooling document infrastructure-layer capabilities relevant to the apeiris://finance/controls/FP-03 Financial AI Risk Appetite Statement control.", "reviewed_on": "2026-07-02" }, { "id": "google_cloud_financial_services_ai_2024", "title": "Google Cloud Explainable AI", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/explainable-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_financial_services_ai_2024", "relationship": "informative_reference", "rationale": "Google Cloud's Explainable AI and Vertex AI model governance documentation describes platform capabilities relevant to the apeiris://finance/controls/FP-03 Financial AI Risk Appetite Statement control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Board-approved risk appetite statement with quantitative thresholds per decision category, annual refresh cycle, and escalation triggers that automatically suspend AI decision authority when thresholds are breached.", "steps": [ "Draft the Financial AI Risk Appetite Statement by synthesizing the board's existing enterprise risk appetite with AI-specific risk dimensions: model accuracy risk, data quality risk, regulatory risk, and operational risk.", "Define quantitative thresholds for each AI decision category, such as maximum allowable error rate for AI-driven credit decisions, maximum single-transaction value for autonomous execution, and maximum aggregate exposure from AI-driven decisions in any reporting period.", "Obtain formal board or risk committee approval, document in board minutes, and distribute the approved statement to all teams with AI deployment authority.", "Implement automated monitoring to detect when AI system performance approaches or breaches appetite thresholds, with escalation to the CRO and CFO and documented suspension procedures." ], "financial_controller": { "summary": "The CFO is a primary stakeholder in the risk appetite statement, particularly for thresholds governing AI-driven financial reporting decisions and materiality limits.", "actions": [ "Provide input on materiality thresholds for AI-driven financial close processes and journal entry automation.", "Confirm that risk appetite thresholds are reflected in financial planning assumptions and disclosed in management's discussion and analysis where required.", "Review quarterly monitoring reports to confirm AI exposure remains within the approved appetite." ], "failure_signals": [ "No quantitative threshold defined for AI-driven financial close decisions.", "Risk appetite statement not referenced in the SOX 302 certification process.", "Quarterly monitoring report shows AI exposure exceeding appetite without documented escalation." ] }, "model_risk_officer": { "summary": "The MRO translates the risk appetite statement into model-level risk limits and monitors aggregate AI risk exposure against the board-approved appetite.", "actions": [ "Map each approved AI use case to the applicable risk appetite threshold and document the mapping in the model inventory.", "Report aggregate AI risk exposure to the risk committee quarterly, flagging any use case approaching its threshold.", "Define and test the procedures for suspending AI decision authority when an appetite threshold is breached." ], "failure_signals": [ "AI use case deployed without a documented risk appetite threshold mapping.", "Aggregate AI exposure report not delivered to risk committee in any quarter.", "Suspension procedure not tested in the last 12 months." ] }, "internal_audit": { "summary": "Internal Audit must verify that the risk appetite statement is board-approved, current, and that monitoring against it is operating effectively.", "actions": [ "Review board minutes to confirm risk appetite statement approval and version currency.", "Test that automated monitoring generates escalations when AI performance approaches appetite thresholds.", "Sample AI deployment decisions and verify each was assessed against the applicable appetite threshold before approval." ], "metrics": [ "Board approval currency: statement approved within the last 12 months.", "Threshold coverage: 100% of AI decision categories have an approved threshold.", "Monitoring effectiveness: escalation generated for 100% of threshold breach events tested." ], "failure_signals": [ "Risk appetite statement older than 12 months without documented board reaffirmation.", "AI decision category found without a corresponding appetite threshold.", "Threshold breach occurred without a documented escalation." ] }, "it_operations": { "summary": "IT Operations runs risk-appetite threshold monitoring behind the board-approved financial AI risk appetite statement \u2014 integrating it with deployment pipelines, enforcing the automated gates, and keeping the supporting data flows reliable and auditable.", "actions": [ "Integrate risk-appetite threshold monitoring with CI/CD and runtime tooling so that appetite metrics are computed from production telemetry on schedule.", "Automate collection and retention of threshold evaluations and breach events in immutable, hash-verified storage.", "Monitor pipeline and integration health and alert when appetite metrics breach board-approved thresholds without escalation." ], "failure_signals": [ "Production changes bypass the automated gate so that it is no longer true that appetite metrics are computed from production telemetry on schedule.", "Gaps or outages in threshold evaluations and breach events collection exceeding 24 hours.", "Manual, untracked edits to risk-appetite threshold monitoring records." ] }, "compliance_officer": { "summary": "The risk appetite statement is a governance artifact examiners read first; compliance keeps it current, approved, and demonstrably enforced.", "actions": [ "Verify annual board reapproval of the appetite statement and document the review.", "Test that appetite thresholds are actually wired to monitoring and escalation." ], "metrics": [ "Appetite statement age since last board approval: within 12 months.", "Thresholds with live monitoring linkage: 100% of quantitative statements." ], "failure_signals": [ "Appetite statement thresholds that no system actually monitors.", "Board approval lapsed while AI risk-taking continued to expand." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Most organizations have general risk appetite statements that do not address AI-specific dimensions; a quantified, AI-specific statement is the maturity target." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "CFO Office", "Board Risk Committee", "Model Risk Officer", "Internal Audit" ], "frameworks": [ { "framework": "coso_icfr", "requirement_id": "Principle 6", "fit": "direct", "rationale": "COSO ICIF Principle 6 requires that the organization specifies objectives with sufficient clarity that risks to achieving them can be identified and assessed. A Financial AI Risk Appetite Statement is the mechanism by which the board specifies acceptable risk exposure for AI use, enabling subsequent identification and assessment of deviations. Without it, risk assessments lack a reference point against which to measure severity.", "normative_force": "industry-framework", "source_version": "2013", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "informs" }, { "framework": "sr26_2", "requirement_id": "\u00a7III (Overview of Model Risk and MRM)", "fit": "direct", "rationale": "SR 26-2 \u00a7III frames model risk as a risk to be managed like other risks \u2014 identified, measured, and kept within tolerance. A board-approved risk appetite statement for financial AI operationalizes that framing; the guidance itself does not mandate a specific appetite artifact.", "normative_force": "supervisory-guidance", "source_version": "2026-04-17", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "sox", "requirement_id": "Section 302", "fit": "partial", "rationale": "SOX Section 302 requires CEO and CFO to certify the adequacy of internal controls. A board-approved AI risk appetite statement is evidence that management has identified, assessed, and bounded the risk from AI use in financial processes\u2014directly supporting the basis for management's certification and reducing the risk of a material weakness finding.", "normative_force": "binding-law", "source_version": "2002", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "satisfies" }, { "framework": "omb_a_123", "requirement_id": "Section II.B", "fit": "direct", "rationale": "OMB Circular A-123 (M-16-17) Section II.B describes risk profiles \u2014 identifying risks and defining risk appetite and tolerance as part of enterprise risk management. A board-approved financial AI risk appetite statement is the same appetite-setting artifact the circular expects in an agency risk profile.", "normative_force": "supervisory-guidance", "source_version": "2016", "reviewed_on": "2026-07-02", "basis": "asserted", "relation": "satisfies" }, { "framework": "eu_ai_act", "requirement_id": "Art. 9(4)", "fit": "partial", "rationale": "The EU AI Act Article 9(4) requires that the risk management system for high-risk AI systems identify and analyze known and foreseeable risks. A board-approved risk appetite statement defines the acceptable residual risk level after mitigation, which is a prerequisite for completing the Article 9 risk management cycle and demonstrating proportionate risk treatment decisions.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "microsoft_rai", "requirement_id": "A1", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal A1 (Impact assessment) requires documented impact assessments identifying intended uses, stakeholders, and potential harms. For institutions using Azure AI services, this goal produces vendor-side governance artifacts that align with the board-approved financial AI risk appetite statement. The Standard is Microsoft's published internal policy offered as reference practice, not regulatory guidance.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_financial", "requirement_id": "Financial Services Industry Lens \u2014 AWS Well-Architected", "fit": "partial", "rationale": "The Financial Services Industry Lens for the AWS Well-Architected Framework describes design principles, risk considerations, and shared-responsibility boundaries for regulated financial workloads on AWS. For AWS-hosted financial AI systems, this supplies the infrastructure-layer support and evidence stream for the board-approved financial AI risk appetite statement. This is vendor documentation of real AWS capabilities \u2014 it does not substitute for model-layer validation or regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_financial", "requirement_id": "Vertex AI Model Monitoring", "fit": "adjacent", "rationale": "Vertex AI Model Monitoring detects prediction drift and training-serving skew for models deployed on Google Cloud. For GCP-hosted financial AI systems, this capability supplies the platform-layer support for the board-approved financial AI risk appetite statement. This is vendor product documentation, not regulatory guidance; it does not address model-layer regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://finance/controls/FP-03", "meta": { "authored_on": "2026-06-29", "schema_version": "1.1.0" }, "validation_objective": "The board or its designated risk committee must have approved a current Financial AI Risk Appetite Statement that quantifies the maximum acceptable exposure from AI use in financial decision-making \u2014 including materiality thresholds, error rate tolerances, and category-specific limits \u2014 with AI systems configured to alert when operating parameters approach appetite boundaries and to escalate to the board when limits are breached.", "evidence_required": [ "financial_ai_risk_appetite_statement board_approval_record showing approval date, approving body, vote record or unanimous consent confirmation, and version number", "risk_appetite_parameter_table showing each quantified risk metric (maximum AI-driven decision error rate, materiality threshold, maximum model output variance tolerance, category-specific exposure limits) with current measured values and defined breach thresholds", "risk_appetite_monitoring_report showing current AI system risk metrics against appetite limits, breach events in the current period, and escalation actions taken for each breach", "annual_risk_appetite_review_record documenting the review cycle, risk appetite changes approved, and triggering events (material model changes, regulatory updates, loss events) that prompted out-of-cycle reviews" ], "machine_tests": [ "Configure a test financial AI system to produce outputs at the maximum acceptable error rate \u2192 assert risk appetite monitoring system raises a warning alert before the threshold is breached", "Query board_approval_record for the current Financial AI Risk Appetite Statement version \u2192 assert approval_date is within the last 12 months", "Query risk_appetite_monitoring_report for breach events in the current period \u2192 assert each breach has a documented escalation_action with a non-null timestamp" ], "human_review": [ "Verify that the risk appetite statement is operationally translated into specific AI system configuration parameters \u2014 not only a high-level narrative \u2014 by reviewing the risk_appetite_parameter_table against actual system monitoring configuration", "Assess whether the risk appetite review cadence reflects actual changes in the AI system's risk profile: confirm that material model changes, significant loss events, or applicable regulatory changes triggered out-of-cycle reviews", "Confirm that the risk appetite statement was approved by the full board or a formally delegated risk committee with documented authority, not signed off by senior management as a substitute for board engagement" ], "blocking_effect": "requires-review", "normative_status": "supervisory-guidance", "anti_patterns": [ "Publishing a risk appetite statement that describes risk philosophy in qualitative terms without defining quantified limits (e.g., 'we accept moderate risk' rather than 'maximum AI-driven credit decision error rate of 0.5% per quarter')", "Setting risk appetite limits at levels never approached in practice, creating a formally compliant statement that does not constrain actual AI system behavior or trigger escalation for any realistic operating scenario", "Treating the risk appetite statement as a one-time board deliverable that is not re-approved when material AI systems change, causing the approved appetite to become misaligned with the actual risk profile of current deployments", "Failing to translate risk appetite limits into AI system monitoring thresholds, leaving compliance dependent on manual periodic reviews rather than automated detection of appetite boundary approaches", "Limiting the risk appetite statement to credit and market risk while omitting operational risk from AI failures, model risk, and reputational risk from AI-driven financial decisions \u2014 addressing only the traditional risk categories and excluding AI-specific risk types" ], "update_status": "current", "layer_code": "FP" }, { "id": "FP-04", "layer": "FP", "plane": "control", "name": "AI Procurement and Vendor Management Policy for Finance", "plain": "The organization must maintain a policy governing the selection, due diligence, contracting, onboarding, ongoing monitoring, and offboarding of AI vendors and models used in financial services, including minimum security, compliance, and performance requirements that vendors must satisfy before deployment.", "threat": { "tags": [ "unvetted-vendor-risk", "third-party-model-exposure", "supply-chain-ai-risk", "vendor-lock-in-risk" ], "desc": "AI models and platforms procured without adequate due diligence may embed biases, lack required audit trails, fail to meet data residency requirements, or be operated by vendors without adequate security controls. In financial services, third-party model failures are attributed to the deploying institution by regulators\u2014not the vendor\u2014making vendor governance a direct institutional risk that cannot be contracted away." }, "standard": [ { "id": "sr26_2", "section": "\u00a7VII", "title": "Vendor and third-party model risk" }, { "id": "sox", "section": "Section 404", "title": "Internal controls over third-party financial processes" }, { "id": "eu_ai_act", "section": "Art. 25", "title": "Responsibilities along the AI value chain" }, { "id": "aicpa_soc2", "section": "CC9.2", "title": "Vendor and business partner risk management" } ], "sources": [ { "id": "google_cloud_financial_services_ai_2024", "title": "Google Cloud Explainable AI", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/explainable-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_financial_services_ai_2024", "relationship": "informative_reference", "rationale": "Google Cloud's Explainable AI and Vertex AI model governance documentation describes platform capabilities relevant to the apeiris://finance/controls/FP-04 AI Procurement and Vendor Management Policy for Finance control.", "reviewed_on": "2026-07-02" }, { "id": "aws_financial_services_compliance_2024", "title": "AWS User Guide to Financial Services Regulations & Guidelines in the United States", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/financial-services/security-compliance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_financial_services_compliance_2024", "relationship": "informative_reference", "rationale": "AWS's financial services regulatory guide and compliance tooling document infrastructure-layer capabilities relevant to the apeiris://finance/controls/FP-04 AI Procurement and Vendor Management Policy for Finance control.", "reviewed_on": "2026-07-02" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Anthropic's Responsible Scaling Policy v3.3 documents the vendor's capability thresholds and safeguards, cited as third-party AI due diligence context for the apeiris://finance/controls/FP-04 AI Procurement and Vendor Management Policy for Finance control.", "reviewed_on": "2026-07-02" }, { "id": "openai_enterprise_data_governance_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "OpenAI's enterprise privacy and compliance documentation records vendor-side data handling and audit-log capabilities relevant to the apeiris://finance/controls/FP-04 AI Procurement and Vendor Management Policy for Finance control.", "reviewed_on": "2026-07-02" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://finance/controls/FP-04 AI Procurement and Vendor Management Policy for Finance control.", "reviewed_on": "2026-07-01" }, { "id": "okta_financial_services_access_2025", "title": "Okta for Financial Services", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://www.okta.com/solutions/financial-services/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_financial_services_access_2025", "relationship": "informative_reference", "rationale": "Okta's identity products (System Log, access management, Adaptive MFA, Privileged Access) supply identity-layer enforcement and evidence relevant to the apeiris://finance/controls/FP-04 AI Procurement and Vendor Management Policy for Finance control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Tiered vendor due diligence based on AI risk classification, with standardized assessment questionnaire, contractual minimum requirements, and ongoing monitoring scorecard integrated into the vendor management lifecycle.", "steps": [ "Define vendor risk tiers for AI procurement based on the AI use case risk classification from FP-01, applying the most rigorous due diligence to vendors supplying models for high-risk financial decisions.", "Create a standardized AI vendor assessment questionnaire covering: model documentation, independent validation capability, data handling practices, security certifications, regulatory compliance posture, financial stability, and incident response capabilities.", "Embed minimum contractual requirements for AI vendors in financial services: right to audit model performance, model documentation delivery obligations, data residency commitments, incident notification SLA, and compliance with applicable financial services regulations.", "Implement an ongoing vendor monitoring scorecard reviewed quarterly, tracking performance SLAs, security incidents, regulatory actions against the vendor, and model update notifications." ], "financial_controller": { "summary": "The CFO must ensure that AI vendor contracts include sufficient financial protection and that vendor risk is captured in the third-party risk register.", "actions": [ "Review AI vendor contracts for financial liability clauses, limitation of liability provisions, and indemnification terms before execution.", "Confirm that AI vendor spend is tracked in the vendor register and subject to the standard financial approval workflow.", "Ensure vendor concentration risk for AI providers is reported to the Audit Committee." ], "failure_signals": [ "AI vendor contract executed without financial controller review.", "AI vendor spend not reflected in the approved budget or vendor register.", "Vendor concentration risk not disclosed in board reporting." ] }, "model_risk_officer": { "summary": "The MRO must validate that vendor AI models are documented to the level SR 26-2's vendor and third-party products section describes and that the organization has sufficient model transparency to perform ongoing monitoring.", "actions": [ "Require vendors to supply model documentation meeting the institution's SR 26-2-aligned standards before production deployment.", "Assess vendor capability to support the organization's independent validation requirements and document the assessment outcome.", "Maintain a vendor model inventory cross-referenced against the internal model inventory." ], "failure_signals": [ "Vendor model deployed without documentation meeting the institution's SR 26-2-aligned standards.", "Independent validation of vendor model not completed within 12 months of deployment.", "Vendor model not listed in the internal model inventory." ] }, "compliance_officer": { "summary": "Compliance must verify that AI vendor contracts and practices satisfy regulatory requirements for third-party risk management and that deployer obligations under the EU AI Act are fulfilled.", "actions": [ "Review each AI vendor agreement for compliance with EU AI Act Article 25 value-chain responsibilities and Article 26 deployer obligations, including access to technical documentation.", "Confirm that vendor assessments cover data protection, anti-discrimination, and regulatory notification requirements.", "Maintain the AI vendor compliance register as part of the FP-08 evidence package." ], "metrics": [ "Vendor assessment completion: 100% of production AI vendors assessed before deployment.", "Contract compliance: 100% of AI vendor contracts include minimum regulatory requirements.", "Monitoring currency: vendor scorecards reviewed within the last 90 days for all production vendors." ], "failure_signals": [ "AI vendor in production without a completed compliance assessment.", "Vendor contract missing EU AI Act deployer obligation provisions.", "Vendor scorecard not updated in the last quarter." ] }, "it_operations": { "summary": "IT Operations must enforce technical onboarding requirements for AI vendors, including security assessments, access controls, and integration testing before production access is granted.", "actions": [ "Require completion of a security assessment (penetration test or SOC 2 Type II) before granting production access to AI vendor systems.", "Implement and test the offboarding playbook for each AI vendor, including data deletion verification.", "Monitor vendor API and integration endpoints for availability and anomalous behavior." ], "failure_signals": [ "AI vendor granted production access without a current security assessment.", "Vendor offboarding playbook not tested in the last 12 months.", "Vendor integration anomaly not escalated within the defined SLA." ] }, "internal_audit": { "summary": "Internal audit tests whether AI procurement requirements are applied before contracts are signed, and whether vendor evidence is current afterward.", "actions": [ "Sample AI vendor onboarding files for completed assessments and required contract clauses.", "Verify vendor documentation and attestation currency for production AI vendors.", "Test that procurement bypasses (expansions, renewals) still triggered AI review." ], "failure_signals": [ "Production AI vendors without completed due diligence files.", "Contracts missing validation-support or change-notification clauses.", "Vendor attestations expired without follow-up." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Many organizations apply general vendor management processes to AI vendors without AI-specific requirements; a tiered AI vendor policy is the maturity target." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "cloud-native", "multi-tenant" ], "implementers": [ "Procurement", "Model Risk Officer", "IT Operations", "Compliance Officer" ], "frameworks": [ { "framework": "sr26_2", "requirement_id": "\u00a7VII (Vendor and Third-Party)", "fit": "direct", "rationale": "SR 26-2 \u00a7VII describes expectations for models obtained from vendors and third parties, including understanding vendor model design and limitations and securing appropriate support. A procurement policy with contractual documentation and validation-support requirements is the mechanism that secures those expectations before deployment.", "normative_force": "supervisory-guidance", "source_version": "2026-04-17", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "eu_ai_act", "requirement_id": "Art. 25", "fit": "direct", "rationale": "EU AI Act Art. 25 allocates responsibilities along the AI value chain, including when a distributor, importer, deployer, or other third party is treated as a provider, and requires written agreements specifying information and assistance from suppliers of components. AI procurement policy is the instrument through which financial institutions secure those value-chain terms contractually.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "soc2", "requirement_id": "CC9.2", "fit": "direct", "rationale": "AICPA SOC 2 CC9.2 requires that the entity assesses and manages risks associated with vendors and business partners. AI vendors represent a category of third-party relationship with unique risk dimensions\u2014model behavior, data handling, and regulatory compliance\u2014that require specialized assessment criteria beyond standard vendor due diligence checklists.", "normative_force": "certification-standard", "source_version": "2022", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "sox", "requirement_id": "Section 404", "fit": "partial", "rationale": "SOX Section 404 requires assessment of controls over all processes affecting financial reporting, including those performed by third parties. AI vendors whose models influence financial outputs are covered entities, and the procurement policy is the control that ensures adequate governance of these relationships before they produce financial data the organization certifies.", "normative_force": "binding-law", "source_version": "2002", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "satisfies" }, { "framework": "aws_financial", "requirement_id": "Financial Services Industry Lens \u2014 AWS Well-Architected", "fit": "adjacent", "rationale": "The Financial Services Industry Lens for the AWS Well-Architected Framework describes design principles, risk considerations, and shared-responsibility boundaries for regulated financial workloads on AWS. For AWS-hosted financial AI systems, this supplies the infrastructure-layer support and evidence stream for AI procurement and vendor management policy requirements. This is vendor documentation of real AWS capabilities \u2014 it does not substitute for model-layer validation or regulatory obligations.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_financial", "requirement_id": "Google Cloud compliance offerings", "fit": "adjacent", "rationale": "Google Cloud's compliance offerings catalog documents the platform's third-party attestations (SOC 1/2/3, ISO/IEC 27001, PCI DSS) available to customers. For GCP-hosted financial AI systems, this capability supplies the platform-layer support for AI procurement and vendor management policy requirements. This is vendor product documentation, not regulatory guidance; it does not address model-layer regulatory obligations.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_rsp", "requirement_id": "Capability Thresholds and Required Safeguards", "fit": "adjacent", "rationale": "RSP v3.3 publishes Anthropic's Capability Thresholds, Required Safeguards, and capability assessment commitments. Procurement due diligence for Anthropic models should review the current RSP version and the completeness of Anthropic's published evaluation disclosures as part of the standardized AI vendor assessment; the RSP is the vendor's own governance disclosure, not documentation produced to a deployer's validation standard.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "openai_enterprise", "requirement_id": "Data Processing Addendum", "fit": "partial", "rationale": "OpenAI's Data Processing Addendum sets contractual data-handling terms for enterprise customers. Institutions using OpenAI models in financial workflows can incorporate this vendor capability into AI procurement and vendor management policy requirements. This is vendor capability documentation, not regulatory guidance; it covers the vendor side only.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "A2", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal A2 (Oversight of significant adverse impacts) requires defined review and oversight processes for AI systems that can cause significant adverse impact. For institutions using Azure AI services, this goal produces vendor-side governance artifacts that align with AI procurement and vendor management policy requirements. The Standard is Microsoft's published internal policy offered as reference practice, not regulatory guidance.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "okta_financial", "requirement_id": "Okta Adaptive MFA", "fit": "adjacent", "rationale": "Okta Adaptive MFA enforces risk-based multi-factor authentication policies. Where access to financial AI systems is brokered through Okta, this capability supplies the identity-layer enforcement and evidence for AI procurement and vendor management policy requirements. This is vendor product documentation, not a financial-services control framework.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://finance/controls/FP-04", "meta": { "authored_on": "2026-06-29", "schema_version": "1.1.0" }, "validation_objective": "The organization maintains a documented AI vendor procurement policy that governs the full vendor lifecycle from risk-tiered due diligence through offboarding, and every production AI vendor has a completed assessment on file with contractual minimums for data residency, audit rights, and incident notification satisfied before production access is granted.", "evidence_required": [ "AI vendor policy document dated within 12 months with risk-tiered due diligence criteria, minimum contractual requirements section, and board or executive approval signature", "Vendor assessment questionnaire completed for each production AI vendor, including security certification status, data residency declaration, and confirmation of SR 26-2-aligned model documentation", "Executed AI vendor contracts containing right-to-audit, data residency, incident notification SLA, and EU AI Act Article 25 value-chain / Article 26 deployer obligation clauses", "Vendor monitoring scorecard for each production AI vendor updated within the last 90 days", "Vendor model inventory cross-referenced against the internal model inventory with no unmatched vendor models in production" ], "machine_tests": [ "Query vendor register for all production AI vendor records \u2192 assert each record contains completed_assessment=true, contract_executed=true, security_certification_status in [soc2_type2, pen_test_current], and data_residency_committed=true", "Query production AI model inventory \u2192 assert each vendor-supplied model has a corresponding entry in the vendor model inventory with vendor_assessment_id and contract_reference populated", "Pull vendor scorecard records \u2192 assert no production AI vendor has a scorecard_last_updated date older than 90 days", "Retrieve AI vendor contracts sample \u2192 assert 100% contain EU AI Act Article 25 value-chain / Article 26 deployer obligation clauses and right-to-audit provisions" ], "human_review": [ "Review each vendor's model documentation package against SR 26-2-aligned documentation standards, assessing whether documentation depth is sufficient to support independent validation without vendor cooperation", "Assess vendor concentration risk across production AI vendors and confirm that concentration risk is disclosed in board risk reporting with appropriate thresholds", "Evaluate whether vendor offboarding playbooks include data deletion verification steps and have been tested within the last 12 months" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Applying standard IT vendor due diligence checklists to AI model vendors without AI-specific requirements covering model documentation, independent validation support, and explainability obligations", "Treating EU AI Act Article 25 value-chain responsibilities and Article 26 deployer obligations as vendor responsibilities rather than non-delegable institutional obligations in AI procurement contracts", "Deploying vendor AI models in production without a completed SR 26-2-aligned model documentation package from the vendor", "Allowing AI vendor scorecards to lapse beyond the quarterly review cycle without triggering a governance escalation", "Failing to cross-reference the vendor model inventory against the internal model inventory, leaving vendor-supplied models unregistered and unvalidated" ], "update_status": "current", "layer_code": "FP" }, { "id": "FP-05", "layer": "FP", "plane": "data", "name": "Data Governance Policy for Financial AI", "plain": "The organization must maintain a data governance policy that defines which data sources, data types, and data lineage standards are required for training, validating, and operating financial AI systems, including restrictions on personal data use, data quality minimums, and data provenance documentation requirements.", "threat": { "tags": [ "training-data-contamination", "unauthorized-data-use", "data-lineage-gap", "regulatory-data-breach" ], "desc": "Financial AI systems trained on incomplete, biased, or improperly governed data produce unreliable outputs that may systematically disadvantage protected classes, violate data protection law, or generate financial statements that do not reflect economic reality. Without a data governance policy, there is no mechanism to ensure that AI training data meets the quality and provenance standards described in SR 26-2 and BCBS 239 and required by applicable data protection regulations." }, "standard": [ { "id": "bcbs_239", "section": "Principles 2 & 3", "title": "Data architecture; accuracy and integrity of risk data" }, { "id": "sr26_2", "section": "\u00a7IV", "title": "Data assessment in model development" }, { "id": "eu_ai_act", "section": "Art. 10", "title": "Data and data governance requirements for high-risk AI" }, { "id": "aicpa_soc2", "section": "PI1.1", "title": "Processing integrity \u2014 quality information for processing objectives" } ], "sources": [ { "id": "openai_enterprise_data_governance_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "OpenAI's enterprise privacy and compliance documentation records vendor-side data handling and audit-log capabilities relevant to the apeiris://finance/controls/FP-05 Data Governance Policy for Financial AI control.", "reviewed_on": "2026-07-02" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Anthropic's Responsible Scaling Policy v3.3 documents the vendor's capability thresholds and safeguards, cited as third-party AI due diligence context for the apeiris://finance/controls/FP-05 Data Governance Policy for Financial AI control.", "reviewed_on": "2026-07-02" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://finance/controls/FP-05 Data Governance Policy for Financial AI control.", "reviewed_on": "2026-07-01" }, { "id": "aws_financial_services_compliance_2024", "title": "AWS User Guide to Financial Services Regulations & Guidelines in the United States", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/financial-services/security-compliance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_financial_services_compliance_2024", "relationship": "informative_reference", "rationale": "AWS's financial services regulatory guide and compliance tooling document infrastructure-layer capabilities relevant to the apeiris://finance/controls/FP-05 Data Governance Policy for Financial AI control.", "reviewed_on": "2026-07-02" }, { "id": "google_cloud_financial_services_ai_2024", "title": "Google Cloud Explainable AI", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/explainable-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_financial_services_ai_2024", "relationship": "informative_reference", "rationale": "Google Cloud's Explainable AI and Vertex AI model governance documentation describes platform capabilities relevant to the apeiris://finance/controls/FP-05 Data Governance Policy for Financial AI control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Data domain classification with per-class governance rules, automated data lineage tracking integrated into ML pipelines, and data quality gates enforced at ingestion and at model training initiation.", "steps": [ "Classify all data used in financial AI systems into data domains\u2014transaction data, market data, customer data, macro-economic data\u2014and define governance rules for each domain including approved sources, prohibited sources, retention limits, and personal data handling requirements.", "Implement automated data lineage tracking in all ML training and inference pipelines, capturing source system, transformation steps, and validation outcomes for every dataset version used in production.", "Define data quality minimum thresholds (completeness, accuracy, consistency, timeliness) for each data domain and implement automated quality gates that block model training or inference when data quality falls below the approved threshold.", "Establish a data governance review process for each new AI use case that documents which data sources are approved, which are explicitly prohibited, and the regulatory basis for each prohibition." ], "model_risk_officer": { "summary": "The MRO must verify that all models in the inventory are trained and operated on data that meets governance policy requirements and that data lineage is documented to a level sufficient for independent validation.", "actions": [ "During model validation, review the training data documentation for compliance with the data governance policy.", "Require data lineage artifacts as a mandatory component of the model documentation package.", "Flag any model where training data provenance cannot be fully reconstructed and suspend production use until resolved." ], "failure_signals": [ "Model validation completed without a data lineage review.", "Training dataset includes a data source not approved in the data governance policy.", "Data quality gate not implemented or bypassed for a production model." ] }, "compliance_officer": { "summary": "Compliance must verify that the data governance policy satisfies EU AI Act Article 10, BCBS 239, and applicable data protection requirements, and that evidence is maintained.", "actions": [ "Review the data governance policy annually against current regulatory requirements including GDPR, CCPA, EU AI Act Article 10, and BCBS 239.", "Confirm that personal data used in AI training or inference has a documented legal basis.", "Include data governance policy and data classification artifacts in the FP-08 evidence package." ], "metrics": [ "Policy coverage: 100% of data domains used in financial AI have documented governance rules.", "Legal basis documentation: 100% of AI uses of personal data have a documented legal basis.", "Data quality gate compliance: zero production models operating with data quality below the approved threshold." ], "failure_signals": [ "Data domain used in production AI without documented governance rules.", "Personal data in AI training without a documented legal basis.", "Data quality below threshold detected without model suspension or escalation." ] }, "it_operations": { "summary": "IT Operations must implement and maintain the technical controls required by the data governance policy, including lineage tracking infrastructure, quality gates, and access controls on approved data sources.", "actions": [ "Deploy and maintain automated data lineage tooling integrated with all ML pipelines in the AI platform.", "Implement access controls on approved AI training data repositories, limiting write access to authorized data engineering roles.", "Monitor data quality metrics for all production AI data feeds and escalate quality breaches to the MRO within the defined SLA." ], "failure_signals": [ "Data lineage tooling not integrated with a production ML pipeline.", "Unauthorized write access detected on an approved AI training data repository.", "Data quality breach not escalated within the SLA." ] }, "financial_controller": { "summary": "Data quality behind estimate models is data quality behind the financial statements; the controller relies on the lineage evidence.", "actions": [ "Confirm lineage documentation exists for data feeding models behind significant estimates.", "Escalate data-quality threshold breaches on reporting-critical pipelines into the close process." ], "failure_signals": [ "Significant estimates built on data failing documented quality thresholds.", "Lineage unknown for inputs to a financial-statement model." ] }, "internal_audit": { "summary": "Internal audit tests data governance for financial AI by tracing sampled models' data to documented sources, quality checks, and approvals.", "actions": [ "Trace training and input data for sampled models to lineage records and quality results.", "Verify quality thresholds are defined, measured, and enforced for critical pipelines.", "Test exception handling when data fails quality gates." ], "failure_signals": [ "Models trained on data with no lineage record.", "Quality thresholds defined but never measured.", "Failed-quality data flowing to production models without exception approval." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Most organizations have general data governance frameworks not adapted for AI training data requirements; AI-specific data governance with automated quality gates is the maturity target." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "Data Governance Team", "Model Risk Officer", "Compliance Officer", "IT Operations" ], "frameworks": [ { "framework": "bcbs_239", "requirement_id": "Principles 2 & 3", "fit": "direct", "rationale": "BCBS 239 Principle 2 (Data architecture and IT infrastructure) requires architecture that supports risk data aggregation, and Principle 3 (Accuracy and Integrity) requires accurate, reliable data with documented, single-source-of-truth flows. Data governance standards for financial AI training and input data apply the same architecture and accuracy disciplines to model data pipelines.", "normative_force": "supervisory-guidance", "source_version": "2013", "reviewed_on": "2026-07-02", "basis": "asserted", "relation": "satisfies" }, { "framework": "eu_ai_act", "requirement_id": "Art. 10", "fit": "direct", "rationale": "EU AI Act Article 10 requires that training, validation, and testing datasets for high-risk AI systems meet standards of relevance, representativeness, freedom from errors, and completeness. A data governance policy that defines approved data sources, quality thresholds, and documentation requirements is the primary implementation artifact for this article for financial AI systems operating in the EU.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "sr26_2", "requirement_id": "\u00a7IV", "fit": "direct", "rationale": "SR 26-2 \u00a7IV (Model Development and Use) describes assessing the quality, relevance, and suitability of data used in model development, including testing of data. Data governance standards with lineage documentation and quality thresholds operationalize that expectation for financial AI training and input data.", "normative_force": "supervisory-guidance", "source_version": "2026-04-17", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "soc2", "requirement_id": "PI1.1", "fit": "partial", "rationale": "SOC 2 PI1.1 (Processing Integrity) requires the entity to obtain or generate, use, and communicate relevant, quality information regarding the objectives related to processing. Data governance standards over financial AI training and input data implement that data-quality expectation for model processing.", "normative_force": "certification-standard", "source_version": "2022", "reviewed_on": "2026-07-02", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "microsoft_rai", "requirement_id": "F1-F3", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Fairness Goals F1-F3 require similar quality of service, minimized allocation disparities, and minimized stereotyping or demeaning outputs across demographic groups. For institutions using Azure AI services, this goal produces vendor-side governance artifacts that align with data governance standards for financial AI training and input data. The Standard is Microsoft's published internal policy offered as reference practice, not regulatory guidance.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_financial", "requirement_id": "Financial Services Industry Lens \u2014 AWS Well-Architected", "fit": "partial", "rationale": "The Financial Services Industry Lens for the AWS Well-Architected Framework describes design principles, risk considerations, and shared-responsibility boundaries for regulated financial workloads on AWS. For AWS-hosted financial AI systems, this supplies the infrastructure-layer support and evidence stream for data governance standards for financial AI training and input data. This is vendor documentation of real AWS capabilities \u2014 it does not substitute for model-layer validation or regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_financial", "requirement_id": "Vertex AI Model Monitoring", "fit": "partial", "rationale": "Vertex AI Model Monitoring detects prediction drift and training-serving skew for models deployed on Google Cloud. For GCP-hosted financial AI systems, this capability supplies the platform-layer support for data governance standards for financial AI training and input data. This is vendor product documentation, not regulatory guidance; it does not address model-layer regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://finance/controls/FP-05", "meta": { "authored_on": "2026-06-29", "schema_version": "1.1.0" }, "validation_objective": "The organization maintains a data governance policy that classifies all data domains used in financial AI, defines approved and prohibited sources for each domain, specifies data quality thresholds, and every production AI model can demonstrate automated lineage tracking from source system through training and inference with no data quality gate bypasses in the prior audit period.", "evidence_required": [ "Data governance policy document covering all data domains used in production financial AI, with approved source lists, prohibited source restrictions, quality thresholds, and regulatory basis for each personal data use", "Automated data lineage reports for each production AI model showing source system, transformation steps, and quality validation outcomes for the training dataset version currently in use", "Data quality gate execution logs showing all threshold checks run at ingestion and training initiation, with no bypassed gates in the production record", "Legal basis documentation for each use of personal data in AI training or inference, referencing applicable GDPR or CCPA lawful processing ground", "EU AI Act Article 10 conformity evidence demonstrating that training datasets for high-risk AI systems meet relevance, representativeness, and error-freedom standards" ], "machine_tests": [ "Query ML pipeline lineage store for each production model \u2192 assert lineage_complete=true and source_approved=true for all training dataset versions, with no prohibited_source_flag entries", "Pull data quality gate logs for the last 30 days \u2192 assert zero records with status=bypassed or quality_below_threshold for any production AI data feed", "Query personal data use registry \u2192 assert each record has legal_basis populated and no AI system processing personal financial data has legal_basis=undocumented", "Submit synthetic training data batch below defined quality threshold \u2192 assert pipeline returns quality_gate_blocked=true and escalation_triggered=true" ], "human_review": [ "Review the data governance policy against current GDPR, CCPA, EU AI Act Article 10, and BCBS 239 requirements, confirming the policy is current and maps to each regulatory data obligation", "Assess whether automated lineage tooling covers all ML pipelines in production, identifying any pipeline where lineage tracking is absent or incomplete", "Review the annual data governance review outcomes for each AI use case and confirm that approved and prohibited source classifications are current and reflect current regulatory posture" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Applying general enterprise data governance policies to AI training data without AI-specific requirements for lineage documentation, approved source lists, or data quality thresholds at training initiation", "Relying on manual data quality assessment for AI training datasets rather than automated quality gates that block training when thresholds are not met", "Using personal data in AI model training without a documented legal basis, treating model training as a secondary processing activity that does not require separate lawful basis documentation", "Allowing AI training pipelines to ingest data from unapproved or prohibited sources because the approved source list has not been updated since initial policy creation", "Completing data governance review for new AI use cases without documenting the regulatory basis for each data classification decision, leaving the rationale unauditable" ], "update_status": "current", "layer_code": "FP" }, { "id": "FP-06", "layer": "FP", "plane": "lifecycle", "name": "Financial AI Change Control Policy", "plain": "The organization must maintain a change control policy governing all changes to financial AI systems\u2014including model updates, hyperparameter modifications, training data refreshes, integration changes, and infrastructure changes\u2014requiring impact assessment, validation, approval, and rollback capability before any change is promoted to production.", "threat": { "tags": [ "uncontrolled-model-change", "unauthorized-parameter-update", "change-approval-bypass", "validation-gate-bypass" ], "desc": "Uncontrolled changes to financial AI systems can silently alter model behavior in ways that affect financial outputs without triggering standard financial controls. A parameter update or retraining event that shifts model behavior constitutes a material change to an internal control over financial reporting and must be governed as such. Without a formal change control policy, such changes may bypass validation, fail to be documented, and create audit trail gaps that are indistinguishable from intentional manipulation." }, "standard": [ { "id": "sox", "section": "Section 404", "title": "Change management controls over systems affecting financial reporting" }, { "id": "coso_icfr", "section": "Principle 12", "title": "Deployment of control activities through policies and procedures" }, { "id": "sr26_2", "section": "\u00a7V", "title": "Recalibration, redevelopment, and revalidation" } ], "sources": [ { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Anthropic's Responsible Scaling Policy v3.3 documents the vendor's capability thresholds and safeguards, cited as third-party AI due diligence context for the apeiris://finance/controls/FP-06 Financial AI Change Control Policy control.", "reviewed_on": "2026-07-02" }, { "id": "openai_enterprise_data_governance_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "OpenAI's enterprise privacy and compliance documentation records vendor-side data handling and audit-log capabilities relevant to the apeiris://finance/controls/FP-06 Financial AI Change Control Policy control.", "reviewed_on": "2026-07-02" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://finance/controls/FP-06 Financial AI Change Control Policy control.", "reviewed_on": "2026-07-01" }, { "id": "aws_financial_services_compliance_2024", "title": "AWS User Guide to Financial Services Regulations & Guidelines in the United States", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/financial-services/security-compliance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_financial_services_compliance_2024", "relationship": "informative_reference", "rationale": "AWS's financial services regulatory guide and compliance tooling document infrastructure-layer capabilities relevant to the apeiris://finance/controls/FP-06 Financial AI Change Control Policy control.", "reviewed_on": "2026-07-02" }, { "id": "google_cloud_financial_services_ai_2024", "title": "Google Cloud Explainable AI", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/explainable-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_financial_services_ai_2024", "relationship": "informative_reference", "rationale": "Google Cloud's Explainable AI and Vertex AI model governance documentation describes platform capabilities relevant to the apeiris://finance/controls/FP-06 Financial AI Change Control Policy control.", "reviewed_on": "2026-07-02" }, { "id": "okta_financial_services_access_2025", "title": "Okta for Financial Services", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://www.okta.com/solutions/financial-services/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_financial_services_access_2025", "relationship": "informative_reference", "rationale": "Okta's identity products (System Log, access management, Adaptive MFA, Privileged Access) supply identity-layer enforcement and evidence relevant to the apeiris://finance/controls/FP-06 Financial AI Change Control Policy control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Tiered change classification (minor/major/emergency) with per-tier approval authority, mandatory revalidation triggers, immutable change audit log, and automated rollback capability verified quarterly.", "steps": [ "Define a change taxonomy for financial AI systems classifying changes as minor (configuration, threshold tuning), major (model update, training data refresh, architecture change), or emergency (immediate risk mitigation), with per-tier approval authority and validation requirements.", "Require that all major changes undergo impact assessment by the Model Risk Officer before approval, documenting the expected behavioral change, affected decision types, and validation plan.", "Implement an immutable change log that captures the requester, approver, change artifact hash, validation outcome, and deployment timestamp for every change to a production financial AI system.", "Test automated rollback capability for each production financial AI system at least quarterly, confirming that a prior validated state can be restored within the defined RTO and documenting test outcomes." ], "model_risk_officer": { "summary": "The MRO must define revalidation triggers for each model and review all major change impact assessments before approval. The MRO is the authoritative voice on whether a change requires full revalidation or can be assessed through targeted testing.", "actions": [ "Define revalidation triggers for each model in the inventory and document them in the model file.", "Review and approve or reject impact assessments for all major AI changes before they are submitted to the change advisory board.", "Confirm that post-change monitoring is implemented and active for the defined stabilization period after every major change." ], "failure_signals": [ "Major AI change approved without MRO impact assessment review.", "Change deployed to production without validation documentation in the change log.", "Post-change monitoring not active during the stabilization period." ] }, "compliance_officer": { "summary": "Compliance must verify that the change control policy satisfies SOX, COSO, and PCAOB expectations for change management over systems affecting financial reporting, and that the change log is available for audit.", "actions": [ "Map the AI change control policy to SOX 404 change management requirements and document the mapping.", "Review the change log quarterly to confirm all production changes are documented with required approvals.", "Prepare change log samples and policy documentation for the FP-08 evidence package." ], "metrics": [ "Change documentation completeness: 100% of production changes documented in the immutable log.", "Approval compliance: 100% of major changes with documented MRO impact assessment.", "Rollback test success rate: 100% of quarterly tests executed and successful." ], "failure_signals": [ "Production change identified without a corresponding change log entry.", "Major change deployed without documented MRO approval.", "Rollback test failed or not executed in the last quarter." ] }, "internal_audit": { "summary": "Internal Audit must independently test the change control policy by sampling production changes and verifying that each followed the required process end to end.", "actions": [ "Annually sample 20% of production AI changes and verify that each has a complete change log entry with required approvals and validation documentation.", "Test the emergency change process by reviewing any emergency changes deployed in the period and confirming post-hoc validation was completed within the required timeframe.", "Report change control deficiencies to the Audit Committee with remediation tracking." ], "failure_signals": [ "Sampled change without complete change log documentation.", "Emergency change without completed post-hoc validation within the required timeframe.", "Repeat change control deficiency not remediated within the agreed timeline." ] }, "it_operations": { "summary": "IT Operations must implement the technical infrastructure required by the change control policy, including immutable logging, access controls on production AI systems, and automated rollback capability.", "actions": [ "Implement access controls on production AI system configuration, ensuring that changes require a change ticket and cannot be applied directly without the change management workflow.", "Deploy and maintain immutable audit logging for all production AI system changes, with write-once storage and periodic integrity verification.", "Test automated rollback capability quarterly and document test outcomes in the change management system." ], "failure_signals": [ "Production AI configuration modified without a change ticket.", "Immutable log integrity check failed.", "Rollback capability not tested in the last 90 days." ] }, "financial_controller": { "summary": "Uncontrolled model changes are uncontrolled changes to the reporting stack; the controller co-owns the change gate for reporting models.", "actions": [ "Approve material changes to models feeding financial statements before deployment.", "Verify post-implementation validation completed for reporting-model changes each period." ], "failure_signals": [ "Reporting-model changes deployed without controller approval.", "Period-end variances traced to unapproved model changes." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most organizations apply IT change control to AI infrastructure but not to model parameters and training data; AI-specific change control covering model-layer changes is the key maturity step." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "cloud-native", "eu-high-risk-ai" ], "implementers": [ "IT Operations", "Model Risk Officer", "Internal Audit", "Change Advisory Board" ], "frameworks": [ { "framework": "sox", "requirement_id": "Section 404", "fit": "direct", "rationale": "SOX Section 404 requires assessment of all controls over financial reporting, including change management controls for systems that produce or influence financial data. AI model changes that affect financial outputs are in scope and must be subject to the same rigor as changes to ERP systems or financial reporting applications\u2014the control operates at the model layer, not only the infrastructure layer.", "normative_force": "binding-law", "source_version": "2002", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "satisfies" }, { "framework": "coso_icfr", "requirement_id": "Principle 12", "fit": "direct", "rationale": "COSO 2013 Principle 12 requires deploying control activities through policies that establish what is expected and procedures that put policies into action. A financial AI change control policy is precisely such a policy-and-procedure deployment for model changes affecting financial reporting.", "normative_force": "industry-framework", "source_version": "2013", "reviewed_on": "2026-07-02", "basis": "asserted", "relation": "informs" }, { "framework": "sr26_2", "requirement_id": "\u00a7V", "fit": "direct", "rationale": "SR 26-2 \u00a7V (Validation and Monitoring) discusses recalibration, redevelopment, and revalidation in response to monitoring results and model changes. A change taxonomy with proportionate revalidation triggers operationalizes that discipline.", "normative_force": "supervisory-guidance", "source_version": "2026-04-17", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "eu_ai_act", "requirement_id": "Art. 9(4) & Art. 43", "fit": "partial", "rationale": "The EU AI Act requires that substantial modifications to high-risk AI systems trigger reassessment and potentially re-conformity assessment. The change control policy implements this requirement by classifying changes, triggering revalidation for major changes, and maintaining documentation that supports reassessment decisions by the deploying institution.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "openai_enterprise", "requirement_id": "API model versioning & deprecation policy", "fit": "partial", "rationale": "OpenAI publishes model versioning and deprecation documentation for its API, including dated model snapshots and deprecation timelines. Institutions using OpenAI models in financial workflows can incorporate this vendor capability into the financial AI change control policy. This is vendor capability documentation, not regulatory guidance; it covers the vendor side only.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "RS2", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal RS2 (Failures and remediations) requires processes for identifying, reporting, and remediating failures and predictable misuse. For institutions using Azure AI services, this goal produces vendor-side governance artifacts that align with the financial AI change control policy. The Standard is Microsoft's published internal policy offered as reference practice, not regulatory guidance.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_financial", "requirement_id": "AWS Audit Manager", "fit": "partial", "rationale": "AWS Audit Manager automates evidence collection against control frameworks for AWS workloads, and AWS CloudTrail records account-level API activity. For AWS-hosted financial AI systems, this supplies the infrastructure-layer support and evidence stream for the financial AI change control policy. This is vendor documentation of real AWS capabilities \u2014 it does not substitute for model-layer validation or regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_financial", "requirement_id": "Vertex AI Model Registry", "fit": "adjacent", "rationale": "Vertex AI Model Registry provides versioned model registration, aliases, and deployment state tracking on Google Cloud. For GCP-hosted financial AI systems, this capability supplies the platform-layer support for the financial AI change control policy. This is vendor product documentation, not regulatory guidance; it does not address model-layer regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "okta_financial", "requirement_id": "Okta Privileged Access", "fit": "partial", "rationale": "Okta Privileged Access governs and records privileged sessions and credentials for sensitive infrastructure. Where access to financial AI systems is brokered through Okta, this capability supplies the identity-layer enforcement and evidence for the financial AI change control policy. This is vendor product documentation, not a financial-services control framework.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://finance/controls/FP-06", "meta": { "authored_on": "2026-06-29", "schema_version": "1.1.0" }, "validation_objective": "Every change to a production financial AI system is recorded in an immutable change log with requester, approver, artifact hash, validation outcome, and deployment timestamp; all major changes have a documented MRO impact assessment prior to approval; and automated rollback to a prior validated state has been successfully tested within the last 90 days for all in-scope systems.", "evidence_required": [ "Immutable change log with write-once storage covering all production AI system changes, each entry containing: requester, approver, change_artifact_sha256, validation_outcome, deployment_timestamp, and change_classification", "MRO impact assessment documents for all major changes deployed in the assessment period, each signed by the Model Risk Officer with affected_decision_types and validation_plan populated before deployment_timestamp", "Quarterly rollback test execution records for each production AI system confirming a prior validated state was restored within the defined RTO", "Change taxonomy policy document defining minor/major/emergency classification criteria with per-tier approval authority levels and revalidation triggers", "Post-change monitoring reports confirming monitoring was active throughout the stabilization period following each major change" ], "machine_tests": [ "Query immutable change log for all production changes in the last 90 days \u2192 assert each entry has requester, approver, change_artifact_sha256, validation_outcome, and deployment_timestamp populated with no null fields", "Pull major-change records from the change log \u2192 assert each has an associated mro_impact_assessment_id where assessment_status=approved with mro_signature_date before deployment_timestamp", "Query rollback test records \u2192 assert each production AI system has a rollback_test_date within the last 90 days with result=success", "Attempt to modify a production AI system configuration without a change ticket \u2192 assert the action is blocked with error=change_ticket_required" ], "human_review": [ "Review a sample of major AI changes deployed in the period and assess whether MRO impact assessments accurately captured the behavioral change, affected decision types, and validation scope", "Evaluate the change taxonomy classification criteria for completeness, confirming that model parameter updates, training data refreshes, and vendor-initiated model version upgrades are explicitly classified as major changes", "Assess whether the immutable change log's write-once storage mechanism meets the integrity requirements expected by SOX auditors and PCAOB AS 2201 reviewers" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Applying IT change management processes to AI infrastructure changes while treating model parameter updates, training data refreshes, and hyperparameter tuning as informal configuration changes outside the change control scope", "Allowing vendor-initiated model version upgrades to be applied to production financial AI systems without triggering an organizational impact assessment and approval cycle", "Maintaining a mutable change log in a system where records can be edited after the fact, defeating the immutability requirement that makes the log credible for SOX 404 and PCAOB AS 2201 audit purposes", "Classifying all AI changes as minor to avoid the MRO impact assessment requirement, bypassing the change-revalidation gate that SR 26-2 describes for material changes", "Testing rollback capability annually during planned exercises rather than quarterly, leaving gaps during which rollback failure would be undetected" ], "update_status": "current", "layer_code": "FP" }, { "id": "FP-07", "layer": "FP", "plane": "control", "name": "AI Exception and Escalation Policy", "plain": "The organization must maintain a policy defining the conditions under which AI financial decisions must be escalated to human review, the procedures for processing exceptions to AI decisions, the authority levels required for overrides, and the documentation requirements for all escalation and exception events.", "threat": { "tags": [ "escalation-bypass", "unreviewed-ai-decision", "exception-policy-gap", "override-authority-abuse" ], "desc": "Without a defined escalation and exception policy, AI-generated financial decisions in edge cases\u2014novel customer profiles, stressed market conditions, ambiguous regulatory classifications\u2014may be applied automatically without human judgment. Conversely, without documented override procedures, human reviewers may override AI decisions without accountability, creating opportunities for bias, fraud, or regulatory non-compliance that are harder to detect than model errors." }, "standard": [ { "id": "sr26_2", "section": "\u00a7VI (Governance and Controls)", "title": "Governance of model use and oversight" }, { "id": "eu_ai_act", "section": "Art. 14", "title": "Human oversight of high-risk AI systems" }, { "id": "coso_icfr", "section": "Principle 14", "title": "Internal communication supporting control functioning" }, { "id": "sox", "section": "Section 302", "title": "Management certification of control adequacy" } ], "sources": [ { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://finance/controls/FP-07 AI Exception and Escalation Policy control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Anthropic's Responsible Scaling Policy v3.3 documents the vendor's capability thresholds and safeguards, cited as third-party AI due diligence context for the apeiris://finance/controls/FP-07 AI Exception and Escalation Policy control.", "reviewed_on": "2026-07-02" }, { "id": "openai_enterprise_data_governance_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "OpenAI's enterprise privacy and compliance documentation records vendor-side data handling and audit-log capabilities relevant to the apeiris://finance/controls/FP-07 AI Exception and Escalation Policy control.", "reviewed_on": "2026-07-02" }, { "id": "google_cloud_financial_services_ai_2024", "title": "Google Cloud Explainable AI", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/explainable-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_financial_services_ai_2024", "relationship": "informative_reference", "rationale": "Google Cloud's Explainable AI and Vertex AI model governance documentation describes platform capabilities relevant to the apeiris://finance/controls/FP-07 AI Exception and Escalation Policy control.", "reviewed_on": "2026-07-02" }, { "id": "okta_financial_services_access_2025", "title": "Okta for Financial Services", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://www.okta.com/solutions/financial-services/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_financial_services_access_2025", "relationship": "informative_reference", "rationale": "Okta's identity products (System Log, access management, Adaptive MFA, Privileged Access) supply identity-layer enforcement and evidence relevant to the apeiris://finance/controls/FP-07 AI Exception and Escalation Policy control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Trigger-based escalation with defined authority levels per decision type, mandatory documentation for all overrides, periodic review of escalation patterns for model improvement, and integration with the incident management process for systematic escalation failures.", "steps": [ "Define escalation triggers for each AI decision type: confidence score below threshold, decision falls outside the model's training distribution, decision involves a sanctioned entity, decision value exceeds materiality, or decision has a regulatory classification implication.", "Map each escalation trigger to an authority level\u2014relationship manager, branch manager, credit committee\u2014and document the expected response time and required documentation for each level.", "Implement a logging system that captures every escalation event, the trigger, the reviewing authority, the outcome, the rationale, and the time to resolution, integrated with the immutable change log from FP-06.", "Review escalation patterns monthly to identify systematic triggers indicating model drift, data quality issues, or risk appetite misalignment, and feed findings into the model risk monitoring process." ], "financial_controller": { "summary": "The financial controller must ensure that AI escalations related to financial reporting decisions are routed appropriately and that exception documentation is available for audit.", "actions": [ "Define escalation thresholds for AI-driven financial close decisions, including journal entry automation and account reconciliation.", "Confirm that financial reporting escalations are logged and reviewed as part of the monthly close process.", "Ensure that escalation rates are included in the SOX 302 certification supporting evidence." ], "failure_signals": [ "Financial reporting AI decision overridden without a documented rationale.", "Escalation log not reviewed in the monthly close process.", "Escalation rate materially different from prior periods without documented explanation." ] }, "model_risk_officer": { "summary": "The MRO must analyze escalation patterns to detect model performance degradation and adjust revalidation schedules based on escalation trends.", "actions": [ "Review monthly escalation reports for each production AI model and assess whether escalation rates indicate model drift.", "Trigger an expedited revalidation when the escalation rate for a model exceeds the defined threshold.", "Report escalation trends to the risk committee quarterly with root cause analysis for any anomalous patterns." ], "failure_signals": [ "Escalation rate exceeds threshold without triggering an expedited revalidation.", "Monthly escalation report not produced or reviewed for a production model.", "Escalation pattern indicating systematic model failure not escalated to the risk committee." ] }, "compliance_officer": { "summary": "Compliance must verify that the escalation policy satisfies EU AI Act Article 14 human oversight requirements and that exception documentation is maintained for regulatory review.", "actions": [ "Map the escalation policy to EU AI Act Article 14 requirements and confirm that all high-risk AI decision types have defined escalation triggers and authority levels.", "Review a sample of escalation records quarterly to verify completeness of documentation.", "Include escalation policy, escalation log samples, and trend reports in the FP-08 evidence package." ], "metrics": [ "Trigger coverage: 100% of AI decision types have defined escalation triggers.", "Documentation completeness: 100% of escalation events have logged rationale and outcome.", "Trend review currency: monthly escalation review completed within 10 business days of period end." ], "failure_signals": [ "AI decision type identified without defined escalation triggers.", "Escalation event logged without outcome or rationale.", "Monthly escalation review overdue by more than 10 business days." ] }, "internal_audit": { "summary": "Internal Audit must independently test the escalation process by sampling escalation events and confirming that triggers, routing, documentation, and resolution meet policy requirements.", "actions": [ "Annually sample 15% of escalation events and verify that each was triggered, routed, and resolved according to the policy.", "Test the escalation trigger logic by submitting synthetic edge-case decisions and confirming they are correctly escalated.", "Report any systematic escalation policy failure to the Audit Committee with root cause analysis." ], "failure_signals": [ "Sampled escalation event without complete documentation.", "Synthetic edge-case decision not escalated when it met a defined trigger condition.", "Systematic escalation failure not reported to the Audit Committee within the required timeframe." ] }, "it_operations": { "summary": "IT Operations runs escalation routing and queue tooling behind AI exception handling and human escalation policy \u2014 integrating it with deployment pipelines, enforcing the automated gates, and keeping the supporting data flows reliable and auditable.", "actions": [ "Integrate escalation routing and queue tooling with CI/CD and runtime tooling so that exceptions route to the correct authority level with full decision context.", "Automate collection and retention of escalation queue records in immutable, hash-verified storage.", "Monitor pipeline and integration health and alert when escalations breach response-time targets or route incorrectly." ], "failure_signals": [ "Production changes bypass the automated gate so that it is no longer true that exceptions route to the correct authority level with full decision context.", "Gaps or outages in escalation queue records collection exceeding 24 hours.", "Manual, untracked edits to escalation routing and queue tooling records." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most organizations have ad hoc escalation practices; a documented, monitored escalation policy with systematic pattern review is the maturity target." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "federated-enterprise" ], "implementers": [ "Model Risk Officer", "Compliance Officer", "Financial Controller", "Operations Management" ], "frameworks": [ { "framework": "eu_ai_act", "requirement_id": "Art. 14", "fit": "direct", "rationale": "EU AI Act Article 14 requires that high-risk AI systems be designed and operated to allow effective human oversight, including the ability to decide not to use the AI output or to override it. The escalation and exception policy is the operational implementation of Article 14 human oversight requirements, translating the legal obligation into specific triggers, authority levels, and documentation procedures.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "sr26_2", "requirement_id": "\u00a7VI (Governance and Controls)", "fit": "direct", "rationale": "SR 26-2 \u00a7VI describes governance and control mechanisms over model use, including internal controls that ensure models are used as intended with appropriate oversight. An exception and escalation policy specifying when human judgment supplements or overrides model output implements that discipline; the guidance does not prescribe a specific escalation design.", "normative_force": "supervisory-guidance", "source_version": "2026-04-17", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "coso_icfr", "requirement_id": "Principle 14", "fit": "direct", "rationale": "COSO 2013 Principle 14 (Information & Communication) requires the organization to internally communicate information, including objectives and responsibilities for internal control, necessary to support its functioning. An AI exception and escalation policy defines exactly those communication paths \u2014 who must be informed, at what authority level, when model output requires human judgment.", "normative_force": "industry-framework", "source_version": "2013", "reviewed_on": "2026-07-02", "basis": "asserted", "relation": "informs" }, { "framework": "sox", "requirement_id": "Section 302", "fit": "partial", "rationale": "SOX Section 302 certifications require management to disclose any significant deficiencies or material weaknesses in internal controls. Systematic failures in AI escalation processes constitute control deficiencies that may require disclosure, making the escalation policy a critical element of the SOX control environment and its documentation a prerequisite for an informed management certification.", "normative_force": "binding-law", "source_version": "2002", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "satisfies" }, { "framework": "microsoft_rai", "requirement_id": "A5", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal A5 (Human oversight and control) requires that systems support effective human oversight and control over system behavior. For institutions using Azure AI services, this goal produces vendor-side governance artifacts that align with AI exception handling and human escalation policy. The Standard is Microsoft's published internal policy offered as reference practice, not regulatory guidance.", "normative_force": "best-practice", "source_version": "2022", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "openai_enterprise", "requirement_id": "Enterprise Compliance API \u2014 audit logs", "fit": "partial", "rationale": "ChatGPT Enterprise and the OpenAI API expose workspace audit-log data through the Compliance API and audit logs endpoint, exportable to SIEM and evidence stores. Institutions using OpenAI models in financial workflows can incorporate this vendor capability into AI exception handling and human escalation policy. This is vendor capability documentation, not regulatory guidance; it covers the vendor side only.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_financial", "requirement_id": "Explainable AI", "fit": "adjacent", "rationale": "Google Cloud's Explainable AI documentation (cloud.google.com/explainable-ai) describes feature attribution and explanation tooling available through Vertex AI. For GCP-hosted financial AI systems, this capability supplies the platform-layer support for AI exception handling and human escalation policy. This is vendor product documentation, not regulatory guidance; it does not address model-layer regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "okta_financial", "requirement_id": "Okta System Log", "fit": "partial", "rationale": "The Okta System Log records authentication and access events with actor, target, outcome, and timestamp detail, exportable for audit retention. Where access to financial AI systems is brokered through Okta, this capability supplies the identity-layer enforcement and evidence for AI exception handling and human escalation policy. This is vendor product documentation, not a financial-services control framework.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://finance/controls/FP-07", "meta": { "authored_on": "2026-06-29", "schema_version": "1.1.0" }, "validation_objective": "Every AI financial decision type has documented escalation triggers with mapped authority levels; all escalation events are logged with trigger, reviewing authority, outcome, and resolution time; and the monthly escalation pattern review is current within 10 business days for all production models.", "evidence_required": [ "Escalation policy document mapping each AI decision type to defined escalation triggers (confidence threshold, distributional outlier, sanctioned entity, materiality breach, regulatory classification) with authority levels and response time SLAs", "Escalation event log with complete records for all events in the assessment period, each containing: trigger_type, authority_level, outcome, rationale, time_to_resolution, and reviewing_authority_id", "Monthly escalation pattern reports for each production AI model, each dated within 10 business days of the period end and signed by the Model Risk Officer", "Expedited revalidation records for any model where escalation rate exceeded the defined threshold, with revalidation initiated within the defined SLA of threshold breach", "EU AI Act Article 14 human oversight mapping document confirming each high-risk AI decision type has defined escalation triggers and authority levels" ], "machine_tests": [ "Submit synthetic AI decision with confidence_score below the defined threshold \u2192 assert escalation_triggered=true with trigger_type=low_confidence and routing to the correct authority level", "Submit synthetic AI decision flagged against a sanctioned entity \u2192 assert decision_blocked=true and escalation_created=true with trigger_type=sanctioned_entity_hit before any financial action is taken", "Query escalation log for the last 30 days \u2192 assert every record has outcome, rationale, and reviewing_authority_id populated with zero records where outcome=null", "Query monthly escalation reports \u2192 assert each production model has a report dated within 10 business days of the most recent period end" ], "human_review": [ "Review escalation trigger coverage for each AI decision type, assessing whether defined triggers capture the full range of edge cases where human judgment should supplement model output", "Assess monthly escalation pattern reports for evidence of model drift, data quality deterioration, or risk appetite misalignment that should trigger an expedited revalidation or policy revision", "Verify that override authority levels are enforced at the system level rather than relying on voluntary self-reporting, confirming that lower-authority reviewers cannot action escalations above their authority level" ], "blocking_effect": "requires-review", "normative_status": "binding-law", "anti_patterns": [ "Defining escalation triggers only for model confidence scores while omitting distributional outlier detection, sanctioned entity checks, materiality thresholds, and regulatory classification edge cases", "Logging escalation events without capturing the reviewing authority identity, outcome, and rationale, producing records that demonstrate process existence but not operating effectiveness", "Allowing human reviewers to override AI financial decisions informally outside the documented escalation process, creating an undocumented shadow override channel indistinguishable from unauthorized manipulation", "Treating escalation rate increases as individual anomalies rather than indicators of systematic model performance degradation, failing to trigger the expedited revalidation this control requires", "Reviewing escalation patterns quarterly rather than monthly, allowing model drift or data quality failures to persist for an extended period before the governance process detects them" ], "update_status": "current", "layer_code": "FP" }, { "id": "FP-08", "layer": "FP", "plane": "both", "name": "Financial Policy Evidence Package", "plain": "The organization must compile and maintain a Financial Policy Evidence Package that aggregates approved policy documents, board approval artifacts, compliance mapping records, monitoring reports, and exception logs from FP-01 through FP-07 into a single, versioned, audit-ready evidence set demonstrating that all financial AI policies are documented, approved, and operating effectively.", "threat": { "tags": [ "evidence-gap", "policy-completeness-failure", "audit-readiness-failure", "regulatory-examination-risk" ], "desc": "Even when individual financial AI policies exist and are operating, the absence of a consolidated, versioned evidence package means that compliance status cannot be demonstrated quickly during a regulatory examination or audit. Examiners who cannot access organized policy evidence within the expected timeframe may draw adverse inferences about control quality. An incomplete evidence package is also a genuine indicator of governance fragmentation\u2014policies that exist on paper but lack implementation evidence." }, "standard": [ { "id": "sox", "section": "Section 404", "title": "Documentation requirements for internal control assessment" }, { "id": "pcaob_as_2201", "section": "\u00b6.39-.42", "title": "Selecting controls to test; design effectiveness" }, { "id": "coso_icfr", "section": "Principle 17", "title": "Communication of internal control information" }, { "id": "eu_ai_act", "section": "Art. 11 & 18", "title": "Technical documentation and record-keeping obligations" } ], "sources": [ { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Anthropic's Responsible Scaling Policy v3.3 documents the vendor's capability thresholds and safeguards, cited as third-party AI due diligence context for the apeiris://finance/controls/FP-08 Financial Policy Evidence Package control.", "reviewed_on": "2026-07-02" }, { "id": "openai_enterprise_data_governance_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "OpenAI's enterprise privacy and compliance documentation records vendor-side data handling and audit-log capabilities relevant to the apeiris://finance/controls/FP-08 Financial Policy Evidence Package control.", "reviewed_on": "2026-07-02" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://finance/controls/FP-08 Financial Policy Evidence Package control.", "reviewed_on": "2026-07-01" }, { "id": "aws_financial_services_compliance_2024", "title": "AWS User Guide to Financial Services Regulations & Guidelines in the United States", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/financial-services/security-compliance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_financial_services_compliance_2024", "relationship": "informative_reference", "rationale": "AWS's financial services regulatory guide and compliance tooling document infrastructure-layer capabilities relevant to the apeiris://finance/controls/FP-08 Financial Policy Evidence Package control.", "reviewed_on": "2026-07-02" }, { "id": "google_cloud_financial_services_ai_2024", "title": "Google Cloud Explainable AI", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/explainable-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_financial_services_ai_2024", "relationship": "informative_reference", "rationale": "Google Cloud's Explainable AI and Vertex AI model governance documentation describes platform capabilities relevant to the apeiris://finance/controls/FP-08 Financial Policy Evidence Package control.", "reviewed_on": "2026-07-02" }, { "id": "okta_financial_services_access_2025", "title": "Okta for Financial Services", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://www.okta.com/solutions/financial-services/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_financial_services_access_2025", "relationship": "informative_reference", "rationale": "Okta's identity products (System Log, access management, Adaptive MFA, Privileged Access) supply identity-layer enforcement and evidence relevant to the apeiris://finance/controls/FP-08 Financial Policy Evidence Package control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Structured evidence repository with per-control evidence folders, version control, access logging, and a quarterly completeness assessment that produces a coverage scorecard against FP-01 through FP-07 requirements.", "steps": [ "Create a structured evidence repository with a dedicated folder for each FP-layer control (FP-01 through FP-07), defining the required evidence artifacts for each control and the responsible owner for populating each folder.", "Implement automated evidence collection where possible\u2014pulling board meeting minutes, model inventory exports, change log summaries, and escalation statistics into the evidence repository on a defined schedule.", "Produce a quarterly FP Evidence Completeness Scorecard assessing each FP control against its required evidence list, calculating a coverage percentage, and identifying gaps with assigned remediation owners and due dates.", "Conduct an annual evidence package review with Internal Audit to confirm that the evidence demonstrates operating effectiveness\u2014not just policy existence\u2014and that any gaps identified in the quarterly scorecard have been remediated before the annual SOX assessment." ], "financial_controller": { "summary": "The financial controller must confirm that the evidence package includes sufficient documentation to support the SOX 302 and 404 certifications for AI-related financial controls.", "actions": [ "Review the FP evidence package before signing the SOX 302 certification and document reliance on the package.", "Confirm that materiality thresholds and board approval artifacts are current in the package.", "Escalate any evidence completeness gap that could affect the SOX 404 conclusion to the Audit Committee." ], "failure_signals": [ "SOX 302 certification signed without a documented review of the FP evidence package.", "Board approval artifact for any FP control older than 12 months at the time of the SOX 404 assessment.", "Evidence completeness below 90% at the time of the annual SOX assessment." ] }, "compliance_officer": { "summary": "Compliance owns the FP Evidence Package and is responsible for its completeness, currency, and accessibility to regulators and auditors on demand.", "actions": [ "Maintain the structured evidence repository and assign evidence collection responsibilities for each FP control.", "Produce the quarterly FP Evidence Completeness Scorecard and distribute it to the CFO, MRO, and Internal Audit.", "Respond to regulatory examination evidence requests from the FP evidence package within the defined SLA." ], "metrics": [ "Evidence completeness: target 100% of required artifacts present for all FP controls.", "Currency: 100% of time-sensitive artifacts dated within the required refresh period.", "Scorecard delivery: quarterly scorecard delivered within 15 business days of quarter end.", "Examination response SLA: evidence provided to examiners within the committed timeframe in 100% of requests." ], "failure_signals": [ "Required evidence artifact missing for any FP control at the time of a scheduled examination.", "Quarterly scorecard not delivered within 15 business days of quarter end.", "Evidence request from regulator not fulfilled within the committed SLA." ] }, "internal_audit": { "summary": "Internal Audit must independently assess the completeness and quality of the FP evidence package annually and report findings to the Audit Committee.", "actions": [ "Conduct an annual independent review of the FP evidence package, assessing both completeness and evidence quality\u2014whether the evidence demonstrates operating effectiveness, not just policy existence.", "Test a sample of evidence artifacts for authenticity, version currency, and traceability to the underlying control.", "Report evidence package findings to the Audit Committee with a risk-rated gap list and remediation recommendations." ], "failure_signals": [ "Annual evidence package review not completed before the SOX 404 assessment.", "Evidence artifact found to be outdated, incomplete, or unverifiable during the annual review.", "Audit Committee not informed of evidence package gaps before the SOX 404 conclusion." ] }, "it_operations": { "summary": "IT Operations runs the policy evidence repository behind the financial policy evidence package \u2014 integrating it with deployment pipelines, enforcing the automated gates, and keeping the supporting data flows reliable and auditable.", "actions": [ "Integrate the policy evidence repository with CI/CD and runtime tooling so that policy artifacts and approvals are ingested automatically.", "Automate collection and retention of policy version and approval records in immutable, hash-verified storage.", "Monitor pipeline and integration health and alert when policy artifacts lack current approval records." ], "failure_signals": [ "Production changes bypass the automated gate so that it is no longer true that policy artifacts and approvals are ingested automatically.", "Gaps or outages in policy version and approval records collection exceeding 24 hours.", "Manual, untracked edits to the policy evidence repository records." ] }, "model_risk_officer": { "summary": "The policy evidence package is where the MRO proves the model risk program's governance layer actually operates.", "actions": [ "Contribute current policy attestations, exception logs, and approval records to the package each cycle.", "Verify package coverage of every policy the MRM framework claims to enforce." ], "failure_signals": [ "Policies claimed in the MRM framework with no operating evidence in the package.", "Exception decisions missing from the policy evidence trail." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Most organizations have policy documents scattered across systems without a consolidated evidence package; a structured, scored, and regularly reviewed package is the maturity target." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai" ], "implementers": [ "Compliance Officer", "Internal Audit", "Model Risk Officer", "CFO Office" ], "frameworks": [ { "framework": "sox", "requirement_id": "Section 404", "fit": "direct", "rationale": "SOX Section 404 requires management to assess and document the effectiveness of internal controls over financial reporting. The FP evidence package is the consolidated documentation that supports this assessment for AI-related financial controls. Without a complete, current evidence package, management cannot make an informed 404 assertion about the AI control environment.", "normative_force": "binding-law", "source_version": "2002", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "satisfies" }, { "framework": "pcaob_as_2201", "requirement_id": "\u00b6.39-.42", "fit": "direct", "rationale": "AS 2201 \u00b6.39-.42 cover selecting controls to test and testing design effectiveness through inquiry, observation, and inspection of relevant documentation. A policy evidence package gives the auditor the documentation base for design-effectiveness testing of AI-related policy controls.", "normative_force": "certification-standard", "source_version": "2007", "reviewed_on": "2026-07-02", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "coso_icfr", "requirement_id": "Principle 17", "fit": "direct", "rationale": "COSO ICIF Principle 17 requires that the organization communicates relevant information about internal controls to those who need it, including auditors and senior management. The FP evidence package is the communication artifact that makes financial AI policy compliance visible to governance bodies, auditors, and regulators in a structured, retrievable format.", "normative_force": "industry-framework", "source_version": "2013", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "informs" }, { "framework": "eu_ai_act", "requirement_id": "Art. 11 & 18", "fit": "direct", "rationale": "EU AI Act Articles 11 and 18 require providers and deployers of high-risk AI systems to maintain technical documentation and records demonstrating compliance. The FP evidence package satisfies these record-keeping obligations for the financial policy layer, and its structured format facilitates the market surveillance authority access required by Article 74 without requiring ad hoc document assembly under time pressure.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "soc2", "requirement_id": "CC2.2 & CC4.1", "fit": "partial", "rationale": "AICPA SOC 2 CC2.2 requires that the entity communicates internally about internal control matters and CC4.1 requires ongoing monitoring of control performance. The FP evidence package and quarterly completeness scorecard directly implement these criteria for financial AI policy controls, providing the communication and monitoring artifacts that a SOC 2 Type II examination expects.", "normative_force": "certification-standard", "source_version": "2022", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "sr26_2", "requirement_id": "\u00a7VI (Documentation)", "fit": "partial", "rationale": "SR 26-2 \u00a7VI describes documentation of model risk management activities under its Documentation subheading. The FP evidence package extends that documentation discipline to the policy governance layer so the policies governing the model risk program are themselves evidenced.", "normative_force": "supervisory-guidance", "source_version": "2026-04-17", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "openai_enterprise", "requirement_id": "Enterprise Compliance API \u2014 audit logs", "fit": "partial", "rationale": "ChatGPT Enterprise and the OpenAI API expose workspace audit-log data through the Compliance API and audit logs endpoint, exportable to SIEM and evidence stores. Institutions using OpenAI models in financial workflows can incorporate this vendor capability into the financial policy evidence package. This is vendor capability documentation, not regulatory guidance; it covers the vendor side only.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "A1", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal A1 (Impact assessment) requires documented impact assessments identifying intended uses, stakeholders, and potential harms. For institutions using Azure AI services, this goal produces vendor-side governance artifacts that align with the financial policy evidence package. The Standard is Microsoft's published internal policy offered as reference practice, not regulatory guidance.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_financial", "requirement_id": "AWS Artifact", "fit": "partial", "rationale": "AWS Artifact provides on-demand access to AWS's third-party compliance reports (SOC 1/2, PCI DSS, ISO). For AWS-hosted financial AI systems, this supplies the infrastructure-layer support and evidence stream for the financial policy evidence package. This is vendor documentation of real AWS capabilities \u2014 it does not substitute for model-layer validation or regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_financial", "requirement_id": "Model Cards", "fit": "adjacent", "rationale": "Model Cards provide structured, versioned documentation of a model's purpose, performance characteristics, and limitations. For GCP-hosted financial AI systems, this capability supplies the platform-layer support for the financial policy evidence package. This is vendor product documentation, not regulatory guidance; it does not address model-layer regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "okta_financial", "requirement_id": "Okta System Log", "fit": "partial", "rationale": "The Okta System Log records authentication and access events with actor, target, outcome, and timestamp detail, exportable for audit retention. Where access to financial AI systems is brokered through Okta, this capability supplies the identity-layer enforcement and evidence for the financial policy evidence package. This is vendor product documentation, not a financial-services control framework.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://finance/controls/FP-08", "meta": { "authored_on": "2026-06-29", "schema_version": "1.1.0" }, "validation_objective": "A structured, versioned Financial Policy Evidence Package exists containing all required artifacts for FP-01 through FP-07, achieves 100% completeness on the quarterly scorecard, and every required time-sensitive artifact is within its defined refresh period at the time of any regulatory examination or SOX 404 assessment.", "evidence_required": [ "Structured evidence repository with per-control folders for FP-01 through FP-07, each containing required artifacts with version history and access logs", "Quarterly FP Evidence Completeness Scorecard showing per-control coverage percentage, gap list with remediation owners and due dates, delivered within 15 business days of quarter end", "SOX 302 certification documentation referencing the FP evidence package, with financial controller sign-off confirming review of the package before certification", "Annual Internal Audit evidence quality assessment confirming completeness and operating effectiveness of the package, delivered before the SOX 404 assessment", "Regulatory examination readiness log showing response time for evidence requests, confirming all requests fulfilled within the committed SLA" ], "machine_tests": [ "Query evidence repository structure \u2192 assert each of FP-01 through FP-07 has a dedicated folder and each folder contains the minimum required artifact count defined in the evidence manifest", "Pull quarterly scorecard records \u2192 assert the most recent scorecard was delivered within 15 business days of quarter end and shows completeness_pct >= 90 for all FP controls", "Query time-sensitive evidence artifacts (board approvals, vendor scorecards, monitoring reports) \u2192 assert no artifact has a last_updated date outside the defined refresh period for that artifact type", "Verify SOX 302 certification records \u2192 assert each contains evidence_package_reviewed=true with financial_controller_sign_off_date before certification_signed_date" ], "human_review": [ "Review the most recent quarterly FP Evidence Completeness Scorecard to assess whether gaps have been assigned to owners with realistic due dates and are on track for remediation", "Evaluate whether evidence artifacts demonstrate operating effectiveness rather than just policy existence, assessing whether monitoring reports, exception logs, and test results constitute genuine proof of control operation", "Assess the accessibility and organization of the evidence repository from the perspective of a regulatory examiner who needs to reconstruct the full financial AI governance posture within a short timeframe" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Maintaining policy documents in a shared drive without version control, access logging, or a completeness scorecard, treating document storage as equivalent to an evidence package", "Assembling evidence in response to regulatory examination requests rather than maintaining a continuously updated package, producing artifacts that reflect the current state rather than operating effectiveness over the examination period", "Achieving high completeness scores by including policy documents as evidence without collecting monitoring reports, exception logs, and test results that demonstrate controls were operating rather than merely designed", "Delaying the quarterly completeness scorecard beyond 15 business days of quarter end, allowing evidence gaps to remain undetected and unassigned for extended periods", "Signing SOX 302 certifications without documenting reliance on the FP evidence package, weakening traceability between the financial controller attestation and the underlying AI control evidence" ], "update_status": "current", "layer_code": "FP" }, { "id": "FG-01", "layer": "FG", "plane": "control", "name": "Finance AI Governance Structure", "plain": "The enterprise must establish a model risk committee \u2014 or equivalent governance body \u2014 with chartered authority over AI financial controls, clearly mapped roles (model owner, validator, senior risk officer), accountability assignments, and documented oversight of the full financial AI control program.", "threat": { "tags": [ "governance-gap", "shadow-ai-deployment", "unaccountable-model-decisions", "oversight-failure" ], "desc": "Without a chartered governance structure, financial AI decisions are made without designated accountability. Model owners proliferate without senior oversight. When a model produces erroneous financial outputs, responsibility diffuses across teams, delaying remediation. Regulators cite governance absence as evidence of systemic control deficiency." }, "standard": [ { "id": "sr26_2", "section": "\u00a7VI (Governance and Controls)", "title": "Governance and controls" }, { "id": "coso_icfr", "section": "Component 1", "title": "Control environment \u2014 tone at top and accountability structure" }, { "id": "sox", "section": "\u00a7404", "title": "Management assessment of internal controls" }, { "id": "eu_ai_act", "section": "Art. 9", "title": "Risk management system for high-risk AI" } ], "sources": [ { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Anthropic's Responsible Scaling Policy v3.3 documents the vendor's capability thresholds and safeguards, cited as third-party AI due diligence context for the apeiris://finance/controls/FG-01 Finance AI Governance Structure control.", "reviewed_on": "2026-07-02" }, { "id": "openai_enterprise_data_governance_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "OpenAI's enterprise privacy and compliance documentation records vendor-side data handling and audit-log capabilities relevant to the apeiris://finance/controls/FG-01 Finance AI Governance Structure control.", "reviewed_on": "2026-07-02" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://finance/controls/FG-01 Finance AI Governance Structure control.", "reviewed_on": "2026-07-01" }, { "id": "aws_financial_services_compliance_2024", "title": "AWS User Guide to Financial Services Regulations & Guidelines in the United States", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/financial-services/security-compliance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_financial_services_compliance_2024", "relationship": "informative_reference", "rationale": "AWS's financial services regulatory guide and compliance tooling document infrastructure-layer capabilities relevant to the apeiris://finance/controls/FG-01 Finance AI Governance Structure control.", "reviewed_on": "2026-07-02" }, { "id": "google_cloud_financial_services_ai_2024", "title": "Google Cloud Explainable AI", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/explainable-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_financial_services_ai_2024", "relationship": "informative_reference", "rationale": "Google Cloud's Explainable AI and Vertex AI model governance documentation describes platform capabilities relevant to the apeiris://finance/controls/FG-01 Finance AI Governance Structure control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Charter a Model Risk Committee with named senior officers, documented scope covering all financial AI systems, a governance policy ratified at executive level, and a register of all AI systems within scope.", "steps": [ "Draft and ratify a Model Risk Committee charter naming the Chief Financial Officer as ultimate accountable party with the Model Risk Officer as day-to-day program lead.", "Produce a role-accountability matrix mapping each AI financial system to a named model owner, a named validator, and a named senior risk officer.", "Establish a quarterly governance meeting cadence with documented minutes, action tracking, and escalation thresholds.", "Maintain a comprehensive AI system register scoped to financial operations, updated at each deployment or material change.", "Integrate the governance structure into the enterprise risk framework and confirm alignment with the board risk charter annually." ], "financial_controller": { "summary": "The governance structure defines who is accountable when AI-driven financial outputs are questioned. The CFO must be the named ultimate accountable party.", "actions": [ "Co-sign the Model Risk Committee charter as ultimate accountable officer.", "Ensure AI system outcomes that affect financial statements are reviewed by the governance body before period close.", "Escalate any AI governance gaps to the board audit committee." ], "failure_signals": [ "Model Risk Committee has not met in the prior 90 days.", "Governance charter has not been reviewed or reaffirmed in over 12 months.", "AI systems affecting financial statements lack a named model owner." ] }, "model_risk_officer": { "summary": "The MRO is responsible for operating the governance program day-to-day, maintaining the AI system register, and ensuring validation independence.", "actions": [ "Maintain the AI system register and ensure every in-scope system has an assigned owner and validator.", "Report governance coverage metrics to the Model Risk Committee quarterly.", "Escalate systems with no assigned owner to the CFO within five business days of discovery." ], "failure_signals": [ "AI system register completeness below 95%.", "Validator independence requirements not met for one or more high-risk systems.", "Governance policy not updated following a material regulatory or organizational change." ] }, "compliance_officer": { "summary": "Compliance verifies that the governance structure satisfies regulatory expectations from SR 26-2, EU AI Act, and SOX and that all documentation is examination-ready.", "actions": [ "Map the governance charter against SR 26-2 Governance and Controls expectations and EU AI Act Art. 9 requirements and document gaps.", "Verify the AI system register is available for regulatory examination within 48 hours of request.", "Confirm that the governance structure is referenced in the annual SOX \u00a7404 assessment." ], "metrics": [ "Regulatory examination readiness: governance package available within 48 hours \u2014 target 100%.", "Charter review cycle: completed annually \u2014 target 100%.", "AI system register completeness: target 100% of in-scope systems." ], "failure_signals": [ "Governance documentation not produced within 48 hours of a regulatory request.", "SOX \u00a7404 assessment does not reference AI governance structure.", "EU AI Act Art. 9 risk management system not documented for high-risk AI systems." ] }, "internal_audit": { "summary": "Internal Audit independently assesses the governance structure against SR 26-2 expectations, SOX requirements, and board-approved risk appetite at least annually.", "actions": [ "Audit the AI system register for completeness and accuracy against deployment records.", "Assess whether the Model Risk Committee charter assigns clear roles and whether accountability gaps exist.", "Issue findings and track remediation to closure." ], "metrics": [ "Governance audit coverage: all in-scope domains audited annually \u2014 target 100%.", "Open findings resolved within agreed remediation timelines \u2014 target 90%." ], "failure_signals": [ "Governance audit not completed in the prior 12 months.", "Repeated findings in consecutive audit cycles with no sustainable remediation.", "AI system register last reconciled more than 90 days ago." ] }, "it_operations": { "summary": "IT Operations runs the AI system register and committee tooling behind the chartered finance AI governance structure \u2014 integrating it with deployment pipelines, enforcing the automated gates, and keeping the supporting data flows reliable and auditable.", "actions": [ "Integrate the AI system register and committee tooling with CI/CD and runtime tooling so that register entries stay synchronized with production inventories.", "Automate collection and retention of register snapshots and committee records in immutable, hash-verified storage.", "Monitor pipeline and integration health and alert when production AI systems are absent from the register." ], "failure_signals": [ "Production changes bypass the automated gate so that it is no longer true that register entries stay synchronized with production inventories.", "Gaps or outages in register snapshots and committee records collection exceeding 24 hours.", "Manual, untracked edits to the AI system register and committee tooling records." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most enterprises have informal AI governance. Formalizing a Model Risk Committee with chartered scope is the critical transition step." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "Model Risk Officer", "Chief Financial Officer", "Chief Compliance Officer", "Board Risk Committee" ], "frameworks": [ { "framework": "sr26_2", "requirement_id": "\u00a7VI (Governance and Controls)", "fit": "direct", "rationale": "SR 26-2 \u00a7VI describes governance and controls \u2014 board and senior management oversight, policies and procedures, and defined roles and responsibilities. A chartered Model Risk Committee with named accountable parties operationalizes those expectations. The guidance is supervisory and principles-based, not an enforceable rule.", "normative_force": "supervisory-guidance", "source_version": "2026-04-17", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "coso_icfr", "requirement_id": "Principle 2 \u2014 Control Environment", "fit": "direct", "rationale": "COSO ICIF 2013 Principle 2 requires the board to oversee internal control, including the control environment. Establishing governance structure for AI financial controls is a direct expression of this principle. Senior accountability mapping is a required element of the control environment component.", "normative_force": "industry-framework", "source_version": "2013", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "informs" }, { "framework": "sox", "requirement_id": "\u00a7404", "fit": "direct", "rationale": "SOX \u00a7404 requires management and the external auditor to assess the effectiveness of internal controls over financial reporting. Governance structure for AI systems that affect financial outputs is a prerequisite for a credible \u00a7404 assessment. Absence of documented governance is a material weakness indicator.", "normative_force": "binding-law", "source_version": "2002", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "satisfies" }, { "framework": "eu_ai_act", "requirement_id": "Art. 9", "fit": "direct", "rationale": "EU AI Act Art. 9 mandates a risk management system for high-risk AI, including clear allocation of responsibilities and documented governance. Financial AI systems meeting the high-risk threshold require this governance structure as a legal prerequisite to deployment. The governance charter is the primary artifact satisfying this obligation.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "omb_a_123", "requirement_id": "Section II.A", "fit": "partial", "rationale": "OMB Circular A-123 requires federal agencies to establish and maintain enterprise risk management structures including clearly defined management roles and responsibilities. The governance body for financial AI directly maps to the management accountability requirements. This framework is applicable to federal agencies and provides an authoritative model for enterprise governance design.", "normative_force": "supervisory-guidance", "source_version": "2016", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "satisfies" }, { "framework": "openai_enterprise", "requirement_id": "Enterprise privacy \u2014 compliance commitments", "fit": "partial", "rationale": "OpenAI's enterprise privacy documentation records its compliance commitments (SOC 2 Type 2, encryption, retention controls) for enterprise customers. Institutions using OpenAI models in financial workflows can incorporate this vendor capability into the chartered finance AI governance structure. This is vendor capability documentation, not regulatory guidance; it covers the vendor side only.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "A2", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal A2 (Oversight of significant adverse impacts) requires defined review and oversight processes for AI systems that can cause significant adverse impact. For institutions using Azure AI services, this goal produces vendor-side governance artifacts that align with the chartered finance AI governance structure. The Standard is Microsoft's published internal policy offered as reference practice, not regulatory guidance.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_financial", "requirement_id": "Financial Services Industry Lens \u2014 AWS Well-Architected", "fit": "partial", "rationale": "The Financial Services Industry Lens for the AWS Well-Architected Framework describes design principles, risk considerations, and shared-responsibility boundaries for regulated financial workloads on AWS. For AWS-hosted financial AI systems, this supplies the infrastructure-layer support and evidence stream for the chartered finance AI governance structure. This is vendor documentation of real AWS capabilities \u2014 it does not substitute for model-layer validation or regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_financial", "requirement_id": "Vertex AI Model Registry", "fit": "partial", "rationale": "Vertex AI Model Registry provides versioned model registration, aliases, and deployment state tracking on Google Cloud. For GCP-hosted financial AI systems, this capability supplies the platform-layer support for the chartered finance AI governance structure. This is vendor product documentation, not regulatory guidance; it does not address model-layer regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://finance/controls/FG-01", "meta": { "authored_on": "2026-06-29", "schema_version": "1.1.0" }, "validation_objective": "A chartered Model Risk Committee exists with named senior officers, board-level accountability, documented scope covering all financial AI systems, and the AI system register is complete and examination-ready; the committee has met within the last 90 days with documented minutes and action tracking.", "evidence_required": [ "Model Risk Committee charter signed by the CFO and ratified at executive level, containing scope definition, named senior officers, accountability assignments, and governance meeting cadence", "AI system register listing all in-scope financial AI systems with named model owner, named validator, and named senior risk officer for each system, last reconciled within 90 days", "Quarterly governance meeting minutes with attendance record, action item log, and escalation threshold documentation for the last four quarters", "Role-accountability matrix mapping each AI financial system to its named model owner, validator, and senior risk officer", "Annual governance charter review documentation confirming alignment with the enterprise risk framework and board risk charter" ], "machine_tests": [ "Query the AI system register \u2192 assert each record has model_owner_id, validator_id, and senior_risk_officer_id populated and that none are null or set to unassigned", "Query governance meeting records \u2192 assert the most recent meeting_date is within 90 days of today and meeting_minutes_status=finalized with action_items_tracked=true", "Query AI system register last_reconciled_date \u2192 assert value is within 90 days and reconciliation_against_deployment_records=true", "Query governance charter version history \u2192 assert charter_last_reviewed_date is within 12 months and cfo_signature_date matches the most recent review cycle" ], "human_review": [ "Review the Model Risk Committee charter for completeness, confirming that scope covers all financial AI systems including vendor-supplied models and that accountability assignments are unambiguous for edge cases such as multi-use models and shared services", "Assess whether quarterly governance meeting minutes reflect substantive review of AI risk exposure and governance metrics rather than administrative process compliance", "Evaluate validator independence for all high-risk AI systems in the register, confirming that no validator is also the model owner or has a reporting relationship that would compromise the independence SR 26-2 expects" ], "blocking_effect": "blocks-deployment", "normative_status": "supervisory-guidance", "anti_patterns": [ "Designating an existing IT governance committee as the Model Risk Committee without updating the charter to include AI-specific scope, accountability requirements, or SR 26-2 Governance and Controls elements", "Maintaining an AI system register that covers internally developed models but excludes vendor-supplied AI models, leaving third-party model risk outside the governance structure", "Assigning model validator roles to individuals within the model development team, contrary to the independence SR 26-2 expects of validation functions", "Allowing the AI system register to go unreconciled for more than 90 days, creating a gap where shadow AI deployments operating outside governance are undetected", "Treating Model Risk Committee meetings as administrative sign-offs on pre-approved decisions rather than substantive risk review sessions, producing minutes that demonstrate meeting existence but not effective oversight" ], "update_status": "current", "layer_code": "FG" }, { "id": "FG-02", "layer": "FG", "plane": "control", "name": "Senior and Named Accountability for Financial AI Decisions", "plain": "Every AI system that influences material financial decisions, financial statements, or regulatory filings must have a named C-suite or senior vice president accountable for its outcomes, documented in the AI system register with a signed accountability acknowledgment.", "threat": { "tags": [ "diffuse-accountability", "financial-misstatement-risk", "unowned-model-decisions", "regulatory-attribution-failure" ], "desc": "When AI financial decisions lack named senior accountability, errors propagate without triggering appropriate escalation. Financial misstatements caused by model failures are attributed to process gaps rather than identifiable decision-makers, delaying regulatory reporting. Regulators and auditors require named individuals who can attest to the adequacy of controls over AI-influenced financial outputs." }, "standard": [ { "id": "sox", "section": "\u00a7302", "title": "Corporate responsibility for financial reports" }, { "id": "sr26_2", "section": "\u00a7VI (Roles and Responsibilities)", "title": "Senior management accountability" }, { "id": "coso_icfr", "section": "Principle 3", "title": "Management establishment of structures and reporting lines" }, { "id": "eu_ai_act", "section": "Art. 16", "title": "Obligations of providers of high-risk AI" } ], "sources": [ { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Anthropic's Responsible Scaling Policy v3.3 documents the vendor's capability thresholds and safeguards, cited as third-party AI due diligence context for the apeiris://finance/controls/FG-02 Senior and Named Accountability for Financial AI Decisions control.", "reviewed_on": "2026-07-02" }, { "id": "openai_enterprise_data_governance_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "OpenAI's enterprise privacy and compliance documentation records vendor-side data handling and audit-log capabilities relevant to the apeiris://finance/controls/FG-02 Senior and Named Accountability for Financial AI Decisions control.", "reviewed_on": "2026-07-02" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://finance/controls/FG-02 Senior and Named Accountability for Financial AI Decisions control.", "reviewed_on": "2026-07-01" }, { "id": "aws_financial_services_compliance_2024", "title": "AWS User Guide to Financial Services Regulations & Guidelines in the United States", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/financial-services/security-compliance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_financial_services_compliance_2024", "relationship": "informative_reference", "rationale": "AWS's financial services regulatory guide and compliance tooling document infrastructure-layer capabilities relevant to the apeiris://finance/controls/FG-02 Senior and Named Accountability for Financial AI Decisions control.", "reviewed_on": "2026-07-02" }, { "id": "google_cloud_financial_services_ai_2024", "title": "Google Cloud Explainable AI", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/explainable-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_financial_services_ai_2024", "relationship": "informative_reference", "rationale": "Google Cloud's Explainable AI and Vertex AI model governance documentation describes platform capabilities relevant to the apeiris://finance/controls/FG-02 Senior and Named Accountability for Financial AI Decisions control.", "reviewed_on": "2026-07-02" }, { "id": "okta_financial_services_access_2025", "title": "Okta for Financial Services", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://www.okta.com/solutions/financial-services/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_financial_services_access_2025", "relationship": "informative_reference", "rationale": "Okta's identity products (System Log, access management, Adaptive MFA, Privileged Access) supply identity-layer enforcement and evidence relevant to the apeiris://finance/controls/FG-02 Senior and Named Accountability for Financial AI Decisions control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Maintain a signed accountability register mapping each material financial AI system to a named senior officer with documented scope of accountability, updated at each material change or annual review.", "steps": [ "Enumerate all AI systems that influence financial statements, regulatory capital calculations, credit decisions, fraud detection outcomes, or regulatory filings and classify each as material or non-material.", "For each material system, assign a named C-suite or SVP accountable officer and obtain a signed accountability acknowledgment covering the scope of their responsibility.", "Store signed acknowledgments in a tamper-evident register accessible to Internal Audit and external auditors.", "Require that the accountable officer certifies model performance is within acceptable bounds before each period-close financial statement sign-off.", "Define a succession and interim-coverage process so that accountability is never vacated when the named officer is unavailable." ], "financial_controller": { "summary": "The financial controller ensures that every AI system that feeds financial statements has a named officer who has signed an accountability acknowledgment and is prepared to attest to SOX \u00a7302 certifications.", "actions": [ "Maintain a register of material AI systems cross-referenced against financial statement line items.", "Confirm each system's accountable officer has signed an acknowledgment before each quarterly SOX \u00a7302 certification.", "Escalate unresolved accountability gaps to the CFO and board audit committee." ], "failure_signals": [ "Any material AI system lacks a signed accountability acknowledgment at period close.", "Accountable officer succession plan is not documented for any material system.", "Accountability register has not been reconciled with the AI system inventory in the prior 90 days." ] }, "model_risk_officer": { "summary": "The MRO administers the accountability acknowledgment process and tracks completeness of named assignments across all in-scope AI systems.", "actions": [ "Maintain and version-control the accountability register in the AI system inventory.", "Notify the CFO within five business days when a material system has no named accountable officer.", "Produce a quarterly completeness report showing coverage rate against the total material AI system population." ], "failure_signals": [ "Accountability coverage rate falls below 100% for material systems.", "Signed acknowledgments are more than 12 months old without renewal.", "Named officer has departed without a documented successor." ] }, "compliance_officer": { "summary": "Compliance verifies that the accountability structure satisfies SOX \u00a7302 and \u00a7404 requirements and that acknowledgments are available for examination.", "actions": [ "Confirm that SOX \u00a7302 certifications reference AI system accountability acknowledgments.", "Map the accountability register to SR 26-2 Roles and Responsibilities senior management accountability expectations.", "Ensure accountability acknowledgments are producible for regulatory examination within 48 hours." ], "metrics": [ "Accountability acknowledgment coverage for material systems: target 100%.", "Renewal cycle compliance: all acknowledgments renewed within 12 months \u2014 target 100%.", "Regulatory examination readiness: accountability package delivered within 48 hours \u2014 target 100%." ], "failure_signals": [ "SOX \u00a7302 certifier cannot identify the accountable officer for a material AI system.", "Accountability acknowledgments not renewed following a material system change.", "Regulatory examiner request for accountability documentation not fulfilled within 48 hours." ] }, "internal_audit": { "summary": "Internal Audit independently tests whether accountability assignments are complete, current, and backed by genuine officer awareness rather than administrative paperwork.", "actions": [ "Select a sample of material AI systems and interview named accountable officers to assess their actual awareness of system scope and performance.", "Verify that accountability acknowledgments are current and stored in a tamper-evident system.", "Test whether accountability gaps are escalated and resolved within the defined SLA." ], "metrics": [ "Accountability awareness rate among sampled officers: target 100%.", "Acknowledgment currency: all material systems renewed within 12 months \u2014 target 100%." ], "failure_signals": [ "Named officer cannot describe the scope or performance thresholds of their assigned system.", "Acknowledgment store does not meet tamper-evidence requirements.", "Escalation SLA for accountability gaps is breached in more than one instance per quarter." ] }, "it_operations": { "summary": "IT Operations runs the accountability register behind named senior accountability for financial AI decisions \u2014 integrating it with deployment pipelines, enforcing the automated gates, and keeping the supporting data flows reliable and auditable.", "actions": [ "Integrate the accountability register with CI/CD and runtime tooling so that each production AI system carries a current named accountable officer.", "Automate collection and retention of signed accountability acknowledgments in immutable, hash-verified storage.", "Monitor pipeline and integration health and alert when systems whose accountable officer has left or changed roles remain unreassigned." ], "failure_signals": [ "Production changes bypass the automated gate so that it is no longer true that each production AI system carries a current named accountable officer.", "Gaps or outages in signed accountability acknowledgments collection exceeding 24 hours.", "Manual, untracked edits to the accountability register records." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Named accountability for AI financial decisions is absent in most enterprises. SOX certifiers rarely trace their attestations to specific AI systems." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "federated-enterprise" ], "implementers": [ "Chief Financial Officer", "Model Risk Officer", "Chief Compliance Officer", "General Counsel" ], "frameworks": [ { "framework": "sox", "requirement_id": "\u00a7302", "fit": "direct", "rationale": "SOX \u00a7302 requires the principal executive and financial officers to personally certify that financial reports fairly present financial condition and that internal controls are effective. Named accountability for AI systems that influence financial outputs is a prerequisite for these certifications to be credible. Absence of named accountability creates a material gap in the \u00a7302 attestation chain.", "normative_force": "binding-law", "source_version": "2002", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "satisfies" }, { "framework": "sr26_2", "requirement_id": "\u00a7VI (Roles and Responsibilities)", "fit": "direct", "rationale": "SR 26-2 \u00a7VI describes senior management responsibility for model risk under its Roles and Responsibilities subheading, including clear assignment of responsibilities across development, validation, and use. Named C-suite accountability with signed acknowledgments operationalizes and evidences that expectation.", "normative_force": "supervisory-guidance", "source_version": "2026-04-17", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "coso_icfr", "requirement_id": "Principle 3", "fit": "direct", "rationale": "COSO Principle 3 requires management to establish structures, reporting lines, and authorities to pursue objectives. Named accountability for AI financial decisions is a direct application of this principle. The control environment assessment under COSO expects clear ownership and documented accountability.", "normative_force": "industry-framework", "source_version": "2013", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "informs" }, { "framework": "eu_ai_act", "requirement_id": "Art. 16", "fit": "direct", "rationale": "EU AI Act Art. 16 places obligations on providers of high-risk AI systems, including maintaining documentation and ensuring human oversight. Named accountability is a structural requirement for demonstrating that human oversight is genuine rather than nominal. Financial AI meeting the high-risk threshold requires identifiable responsible persons.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "pcaob_as_2201", "requirement_id": "\u00b6.24-.28", "fit": "partial", "rationale": "AS 2201 \u00b6.24-.28 include the control environment \u2014 whether management's philosophy and assignment of authority and responsibility are sound \u2014 among the entity-level controls the auditor tests. Named senior accountability for financial AI decisions is control-environment evidence under those paragraphs; the fit is adjacent.", "normative_force": "certification-standard", "source_version": "2007", "reviewed_on": "2026-07-02", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "openai_enterprise", "requirement_id": "Data Processing Addendum", "fit": "partial", "rationale": "OpenAI's Data Processing Addendum sets contractual data-handling terms for enterprise customers. Institutions using OpenAI models in financial workflows can incorporate this vendor capability into named senior accountability for financial AI decisions. This is vendor capability documentation, not regulatory guidance; it covers the vendor side only.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "A2", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal A2 (Oversight of significant adverse impacts) requires defined review and oversight processes for AI systems that can cause significant adverse impact. For institutions using Azure AI services, this goal produces vendor-side governance artifacts that align with named senior accountability for financial AI decisions. The Standard is Microsoft's published internal policy offered as reference practice, not regulatory guidance.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_financial", "requirement_id": "AWS Audit Manager", "fit": "partial", "rationale": "AWS Audit Manager automates evidence collection against control frameworks for AWS workloads, and AWS CloudTrail records account-level API activity. For AWS-hosted financial AI systems, this supplies the infrastructure-layer support and evidence stream for named senior accountability for financial AI decisions. This is vendor documentation of real AWS capabilities \u2014 it does not substitute for model-layer validation or regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_financial", "requirement_id": "Vertex AI Model Registry", "fit": "partial", "rationale": "Vertex AI Model Registry provides versioned model registration, aliases, and deployment state tracking on Google Cloud. For GCP-hosted financial AI systems, this capability supplies the platform-layer support for named senior accountability for financial AI decisions. This is vendor product documentation, not regulatory guidance; it does not address model-layer regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "okta_financial", "requirement_id": "Okta System Log", "fit": "adjacent", "rationale": "The Okta System Log records authentication and access events with actor, target, outcome, and timestamp detail, exportable for audit retention. Where access to financial AI systems is brokered through Okta, this capability supplies the identity-layer enforcement and evidence for named senior accountability for financial AI decisions. This is vendor product documentation, not a financial-services control framework.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://finance/controls/FG-02", "meta": { "authored_on": "2026-06-29", "schema_version": "1.1.0" }, "validation_objective": "Every AI system that influences material financial decisions has a named C-suite or SVP accountable officer with a current signed accountability acknowledgment stored in the tamper-evident register, the accountability coverage rate is 100% for material systems, and every named officer can describe the scope and performance thresholds of their assigned system.", "evidence_required": [ "Signed accountability acknowledgments for each material AI financial system, each containing: system_id, officer_name, officer_title (C-suite or SVP), scope_of_accountability, performance_threshold_summary, and acknowledgment_date within the last 12 months", "Tamper-evident accountability register listing all material AI systems cross-referenced against financial statement line items, with version history and access logs", "Quarterly accountability completeness report showing coverage rate against total material AI system population, signed by the Model Risk Officer", "Period-close certification records for each material AI system confirming that the named accountable officer certified model performance within acceptable bounds before financial statement sign-off", "Succession and interim-coverage plan for each material AI system documenting the named interim officer when the primary accountable officer is unavailable" ], "machine_tests": [ "Query accountability register \u2192 assert each material AI system has accountable_officer_id populated, acknowledgment_date within 12 months, and officer_title matching C-suite or SVP classification", "Query period-close certification records \u2192 assert each material AI system has a certification record for each quarter-end with officer_certification_date before financial_statement_signoff_date", "Query accountability register store integrity \u2192 assert write_once_protected=true and last_integrity_check_passed=true with integrity_check_date within 30 days", "Query material AI systems \u2192 assert each has a succession_plan_id populated with interim_officer_id and succession_trigger_conditions documented" ], "human_review": [ "Interview a sample of named accountable officers to assess whether they can accurately describe the scope of their assigned AI system, the performance thresholds they are responsible for monitoring, and the process for escalating performance breaches", "Review period-close certification records for substantive content, confirming that officers reviewed performance data before certifying rather than signing certifications as administrative formalities", "Assess whether the materiality classification of AI systems is current and captures all systems that influence financial statement line items, regulatory capital calculations, or regulatory filings" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Obtaining accountability acknowledgments as administrative paperwork signed by officers who have not been briefed on the scope, performance thresholds, or escalation obligations of the assigned AI system", "Assigning accountability for multiple material AI financial systems to a single officer at a level of abstraction where they cannot realistically monitor all assigned systems performance before each period-close certification", "Maintaining the accountability register in a mutable document management system where records can be edited after the fact, undermining the tamper-evidence requirement that makes the register credible for SOX and PCAOB review", "Failing to update the accountability register when a named accountable officer departs, leaving material AI systems without a named owner during a succession gap that may persist across a period-close cycle", "Treating named accountability as an annual exercise triggered by SOX certification rather than a continuous governance obligation requiring quarterly completeness review and period-close officer certification" ], "update_status": "current", "layer_code": "FG" }, { "id": "FG-03", "layer": "FG", "plane": "control", "name": "Board-Level Oversight of Financial AI Risk", "plain": "The board of directors, through its audit or risk committee, must receive regular structured reporting on AI risk in financial operations, including model inventory status, material model failures, validation backlogs, and significant governance changes \u2014 with sufficient depth to enable informed oversight decisions.", "threat": { "tags": [ "board-visibility-gap", "systemic-risk-accumulation", "inadequate-oversight", "governance-capture" ], "desc": "Without structured board-level reporting on AI financial risk, boards approve financial statements without understanding that AI systems are material inputs whose failure modes have not been independently validated. Systemic model risk accumulates invisibly until a market stress event surfaces failures simultaneously. Regulators increasingly hold boards accountable for inadequate AI oversight." }, "standard": [ { "id": "sr26_2", "section": "\u00a7VI (Roles and Responsibilities)", "title": "Board oversight of model risk" }, { "id": "sox", "section": "\u00a7301", "title": "Public company audit committees" }, { "id": "coso_icfr", "section": "Principle 2", "title": "Board oversight of internal control" }, { "id": "eu_ai_act", "section": "Art. 9(2)", "title": "Senior management review of AI risk management" } ], "sources": [ { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://finance/controls/FG-03 Board-Level Oversight of Financial AI Risk control.", "reviewed_on": "2026-07-01" }, { "id": "aws_financial_services_compliance_2024", "title": "AWS User Guide to Financial Services Regulations & Guidelines in the United States", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/financial-services/security-compliance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_financial_services_compliance_2024", "relationship": "informative_reference", "rationale": "AWS's financial services regulatory guide and compliance tooling document infrastructure-layer capabilities relevant to the apeiris://finance/controls/FG-03 Board-Level Oversight of Financial AI Risk control.", "reviewed_on": "2026-07-02" }, { "id": "google_cloud_financial_services_ai_2024", "title": "Google Cloud Explainable AI", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/explainable-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_financial_services_ai_2024", "relationship": "informative_reference", "rationale": "Google Cloud's Explainable AI and Vertex AI model governance documentation describes platform capabilities relevant to the apeiris://finance/controls/FG-03 Board-Level Oversight of Financial AI Risk control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Establish a board-approved AI risk reporting package delivered to the audit or risk committee at least quarterly, with a defined minimum content set, an escalation protocol for material incidents, and board attestation that they have reviewed and acted on the reporting.", "steps": [ "Define the minimum content of the board AI risk reporting package: model inventory size and change, validation backlog, material model failures and remediation status, regulatory developments, and key risk indicators with trend.", "Establish a quarterly delivery cadence with the option for emergency reporting when a material AI incident occurs.", "Require the board risk or audit committee to formally acknowledge receipt and confirm any required actions in meeting minutes.", "Produce a board-level summary distinct from technical model risk reporting \u2014 calibrated for non-technical directors.", "Incorporate AI risk into the board's annual enterprise risk management review and ensure the risk appetite statement addresses AI." ], "financial_controller": { "summary": "The financial controller ensures that AI-driven impacts on financial statements are surfaced in board reporting with sufficient transparency for directors to understand their exposure.", "actions": [ "Identify which financial statement line items are materially influenced by AI systems and ensure this is disclosed in board reporting.", "Flag any AI model failures that could affect period-close accuracy to the CFO for board escalation.", "Confirm that board reporting package accurately reflects the current state of AI controls over financial reporting." ], "failure_signals": [ "Board reporting does not identify AI systems that influence material financial statement line items.", "A material AI model failure was not escalated to the board within the defined SLA.", "Board AI risk report has not been updated in the prior quarter despite significant model changes." ] }, "model_risk_officer": { "summary": "The MRO is responsible for preparing the technical content that feeds the board reporting package, translated into board-appropriate language.", "actions": [ "Produce a quarterly model risk summary report suitable for board consumption, covering inventory, validation status, and material issues.", "Maintain an escalation log of issues requiring board awareness and track board acknowledgment.", "Ensure the board risk appetite statement is reviewed for AI risk coverage at least annually." ], "failure_signals": [ "Board report has not been prepared in the prior quarter.", "Material model failures are not included in the board reporting package.", "Board risk appetite statement does not address AI or model risk." ] }, "compliance_officer": { "summary": "Compliance ensures board oversight obligations under SOX \u00a7301 and the EU AI Act, and supervisory expectations under SR 26-2, are met and that board meeting minutes document AI risk discussions.", "actions": [ "Review board meeting minutes to confirm AI risk is discussed at the required frequency.", "Verify that the board reporting package addresses SR 26-2 board oversight expectations (Roles and Responsibilities).", "Confirm that EU AI Act Art. 9(2) senior management review of the AI risk management system is documented." ], "metrics": [ "Board AI risk reporting delivery compliance: quarterly cadence met \u2014 target 100%.", "Board acknowledgment documentation: confirmed in meeting minutes \u2014 target 100%.", "Risk appetite statement AI coverage: reviewed annually \u2014 target 100%." ], "failure_signals": [ "Quarterly board AI risk report not delivered in two consecutive quarters.", "Board meeting minutes do not reflect AI risk discussion.", "EU AI Act Art. 9(2) senior management review not conducted or documented." ] }, "internal_audit": { "summary": "Internal Audit assesses whether board reporting is substantive, whether the board demonstrates actual engagement, and whether escalation protocols are triggered appropriately.", "actions": [ "Review a sample of board reporting packages and assess completeness against the defined minimum content standard.", "Interview board committee members to assess their understanding of AI risk in financial operations.", "Test whether material AI incidents resulted in timely board notification and documented response." ], "metrics": [ "Board reporting completeness: minimum content standard met in each quarterly package \u2014 target 100%.", "Incident escalation timeliness: material incidents notified to board within SLA \u2014 target 100%." ], "failure_signals": [ "Board reporting packages consistently omit required content elements.", "Board committee members cannot describe the AI risk profile of the enterprise.", "Material incident not reported to board within defined SLA on more than one occasion per year." ] }, "it_operations": { "summary": "IT Operations runs board reporting data pipelines behind board-level oversight of financial AI risk \u2014 integrating it with deployment pipelines, enforcing the automated gates, and keeping the supporting data flows reliable and auditable.", "actions": [ "Integrate board reporting data pipelines with CI/CD and runtime tooling so that board package figures are generated from authoritative sources.", "Automate collection and retention of report generation runs and source snapshots in immutable, hash-verified storage.", "Monitor pipeline and integration health and alert when board package numbers diverge from source-of-record data." ], "failure_signals": [ "Production changes bypass the automated gate so that it is no longer true that board package figures are generated from authoritative sources.", "Gaps or outages in report generation runs and source snapshots collection exceeding 24 hours.", "Manual, untracked edits to board reporting data pipelines records." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Boards typically receive technology risk reports that do not distinguish AI model risk. Creating a dedicated AI risk reporting track with board-appropriate content is the gap." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai" ], "implementers": [ "Board Risk Committee", "Chief Financial Officer", "Model Risk Officer", "Internal Audit" ], "frameworks": [ { "framework": "sr26_2", "requirement_id": "\u00a7VI (Roles and Responsibilities)", "fit": "direct", "rationale": "SR 26-2 \u00a7VI describes the board's oversight role \u2014 understanding significant model risk, approving the framework, and receiving reporting from senior management \u2014 under Roles and Responsibilities. Structured board reporting supports that expectation; the quarterly cadence in this control is an internal practice choice, not a cadence set by the guidance.", "normative_force": "supervisory-guidance", "source_version": "2026-04-17", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "sox", "requirement_id": "\u00a7301", "fit": "direct", "rationale": "SOX \u00a7301 establishes audit committee responsibilities including oversight of accounting and financial reporting processes and internal controls. AI systems that materially influence financial reporting are within the audit committee's oversight mandate. The committee must be informed enough to fulfill its statutory responsibilities.", "normative_force": "binding-law", "source_version": "2002", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "satisfies" }, { "framework": "coso_icfr", "requirement_id": "Principle 2", "fit": "direct", "rationale": "COSO Principle 2 requires the board to oversee the design and operating effectiveness of internal controls, including systems that process financial information. Board AI risk reporting is the mechanism through which this oversight is exercised for AI-driven financial controls. Without it, the board cannot fulfill its governance responsibility under COSO.", "normative_force": "industry-framework", "source_version": "2013", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "informs" }, { "framework": "eu_ai_act", "requirement_id": "Art. 9(2)", "fit": "direct", "rationale": "EU AI Act Art. 9(2) requires the risk management system to be a continuous, iterative process planned and run throughout the system's lifecycle, with regular systematic review and updating. Board oversight of financial AI risk is the governance layer that reviews whether that process is operating; the Act assigns the underlying duties to providers rather than boards.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "omb_a_123", "requirement_id": "Section III.A", "fit": "partial", "rationale": "OMB Circular A-123 (M-16-17) Section III.A describes governance structures for enterprise risk management, including senior-level oversight bodies and their reporting lines. Board-level oversight of financial AI risk mirrors that governance expectation for federal entities and federally supervised programs.", "normative_force": "supervisory-guidance", "source_version": "2016", "reviewed_on": "2026-07-02", "basis": "asserted", "relation": "satisfies" }, { "framework": "microsoft_rai", "requirement_id": "A2", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal A2 (Oversight of significant adverse impacts) requires defined review and oversight processes for AI systems that can cause significant adverse impact. For institutions using Azure AI services, this goal produces vendor-side governance artifacts that align with board-level oversight of financial AI risk. The Standard is Microsoft's published internal policy offered as reference practice, not regulatory guidance.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_financial", "requirement_id": "AWS Audit Manager", "fit": "partial", "rationale": "AWS Audit Manager automates evidence collection against control frameworks for AWS workloads, and AWS CloudTrail records account-level API activity. For AWS-hosted financial AI systems, this supplies the infrastructure-layer support and evidence stream for board-level oversight of financial AI risk. This is vendor documentation of real AWS capabilities \u2014 it does not substitute for model-layer validation or regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_financial", "requirement_id": "Vertex AI Model Monitoring", "fit": "partial", "rationale": "Vertex AI Model Monitoring detects prediction drift and training-serving skew for models deployed on Google Cloud. For GCP-hosted financial AI systems, this capability supplies the platform-layer support for board-level oversight of financial AI risk. This is vendor product documentation, not regulatory guidance; it does not address model-layer regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://finance/controls/FG-03", "meta": { "authored_on": "2026-06-29", "schema_version": "1.1.0" }, "validation_objective": "The board risk or audit committee has received a structured AI risk reporting package at least quarterly, containing model inventory status, material model failures, validation backlogs, and key risk indicators with trend, and has formally acknowledged receipt in board meeting minutes. The board risk appetite statement must explicitly address AI or model risk and have been reviewed within the prior 12 months.", "evidence_required": [ "board_ai_risk_report with delivery_date, content_checklist_completion_status, and committee_recipient_identification for each quarter in scope", "board_meeting_minutes confirming AI risk discussion with date, attending_committee_members, and formal_acknowledgment_of_reporting_package for each quarter", "board_risk_appetite_statement with ai_risk_section present, last_reviewed_date within 12 months, and approving_body identifier", "incident_escalation_log showing any material AI failures with board_notification_date and board_response_documented flag for each high-severity event" ], "machine_tests": [ "Query board_reporting_log for prior 90 days \u2192 assert at least one AI risk report delivered to audit or risk committee with required content elements (model inventory, validation backlog, material failures, KRI trend) all present", "Check board_meeting_minutes records for AI risk discussion entries \u2192 assert at least one documented formal acknowledgment per quarter for each quarter in scope", "Read risk_appetite_statement.last_reviewed_date \u2192 assert value is within 12 months of current date and ai_risk_section is non-null", "Query incident_escalation_log for high-severity events \u2192 assert board_notification_date is within defined SLA for each event where board notification was required" ], "human_review": [ "Review board reporting packages against the defined minimum content standard and assess whether the content is substantive and calibrated for non-technical directors rather than a repurposed management-level model risk report", "Interview board committee members to assess whether they can describe the enterprise's AI risk profile, recent material model failures, and validation backlog status from the prior period's reporting", "Assess whether the risk appetite statement addresses AI risk with specific thresholds and indicators rather than generic language, and verify the annual review and board approval process is documented" ], "blocking_effect": "requires-review", "normative_status": "supervisory-guidance", "anti_patterns": [ "Routing AI risk to the board through a generic technology risk summary that does not distinguish AI model risk, model validation status, or validation backlog from broader IT risk", "Preparing a board AI risk report that lists model counts and activity without disclosing material model failures, escalated validation findings, or outstanding high-severity remediation items from the quarter", "Recording board acknowledgment in meeting minutes as a single line noting the report was received without evidence that the committee engaged with content or assigned action items", "Omitting AI systems from the board risk appetite statement while model systems materially influence financial statement line items or drive material customer-facing financial decisions", "Treating SR 26-2 board oversight expectations as satisfied by management-level Model Risk Committee reporting alone without a separate board-level reporting package calibrated for directors" ], "update_status": "current", "layer_code": "FG" }, { "id": "FG-04", "layer": "FG", "plane": "control", "name": "Regulatory Relationship Management", "plain": "The enterprise must maintain a proactive, documented regulatory engagement program for financial AI, including advance notification procedures for material AI developments, a regulatory inquiry log, and a named regulatory liaison responsible for AI-related communications with financial supervisors.", "threat": { "tags": [ "regulatory-surprise", "undisclosed-model-change", "enforcement-risk", "supervisory-trust-erosion" ], "desc": "Enterprises that do not proactively engage regulators on AI developments risk supervisory findings when examiners discover undisclosed model changes or AI governance gaps. Reactive engagement after regulatory inquiry signals weak governance and often triggers deeper examination. Regulatory trust, once damaged, results in heightened scrutiny of all subsequent submissions." }, "standard": [ { "id": "eu_ai_act", "section": "Art. 26(5)", "title": "Deployer duty to inform provider and market surveillance authority" } ], "sources": [ { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Anthropic's Responsible Scaling Policy v3.3 documents the vendor's capability thresholds and safeguards, cited as third-party AI due diligence context for the apeiris://finance/controls/FG-04 Regulatory Relationship Management control.", "reviewed_on": "2026-07-02" }, { "id": "openai_enterprise_data_governance_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "OpenAI's enterprise privacy and compliance documentation records vendor-side data handling and audit-log capabilities relevant to the apeiris://finance/controls/FG-04 Regulatory Relationship Management control.", "reviewed_on": "2026-07-02" }, { "id": "aws_financial_services_compliance_2024", "title": "AWS User Guide to Financial Services Regulations & Guidelines in the United States", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/financial-services/security-compliance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_financial_services_compliance_2024", "relationship": "informative_reference", "rationale": "AWS's financial services regulatory guide and compliance tooling document infrastructure-layer capabilities relevant to the apeiris://finance/controls/FG-04 Regulatory Relationship Management control.", "reviewed_on": "2026-07-02" }, { "id": "google_cloud_financial_services_ai_2024", "title": "Google Cloud Explainable AI", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/explainable-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_financial_services_ai_2024", "relationship": "informative_reference", "rationale": "Google Cloud's Explainable AI and Vertex AI model governance documentation describes platform capabilities relevant to the apeiris://finance/controls/FG-04 Regulatory Relationship Management control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Establish a regulatory engagement policy for financial AI covering notification triggers, designated liaison roles, inquiry response SLAs, examination preparation procedures, and a regulatory correspondence log maintained by Compliance.", "steps": [ "Define notification triggers: material model changes, new high-risk AI deployments, significant model failures, changes to validation governance, and AI-related regulatory examinations at peer institutions.", "Assign a named regulatory liaison with authority to communicate with financial supervisors and back them up with a designated alternate.", "Maintain a regulatory correspondence log capturing all AI-related communications, requests, responses, and commitments with date tracking.", "Develop and test an examination preparation playbook covering AI governance documentation, model inventory export, and governance artifacts.", "Conduct annual regulatory landscape scanning to identify emerging AI-related supervisory expectations and update the engagement policy accordingly." ], "financial_controller": { "summary": "The financial controller supports regulatory relationship management by ensuring that AI systems affecting financial reporting are appropriately disclosed when regulators examine internal controls.", "actions": [ "Confirm that external auditors are informed of AI systems influencing financial statement preparation.", "Ensure that material AI model changes are disclosed to auditors in the management representation letter.", "Flag any AI-related regulatory inquiries touching financial reporting to the CFO." ], "failure_signals": [ "External auditors are unaware of AI systems material to financial statement preparation.", "Management representation letter does not address AI-influenced financial processes.", "AI-related regulatory inquiry touching financial reporting not escalated to CFO within one business day." ] }, "compliance_officer": { "summary": "Compliance owns the regulatory engagement program, including the liaison relationship, the correspondence log, and the advance notification process for material AI developments.", "actions": [ "Maintain the regulatory correspondence log and ensure all AI-related communications are captured within 24 hours.", "Assess notification triggers against the current AI system portfolio quarterly and determine whether proactive disclosures are required.", "Prepare and rehearse examination response procedures at least annually." ], "metrics": [ "Notification trigger assessment conducted quarterly \u2014 target 100%.", "Regulatory correspondence log completeness: all AI-related communications captured within 24 hours \u2014 target 100%.", "Examination preparation playbook tested annually \u2014 target 100%." ], "failure_signals": [ "A material AI development occurred without assessing whether regulatory notification was required.", "Regulatory inquiry response was delayed beyond the defined SLA.", "Examination preparation playbook has not been tested in the prior 12 months." ] }, "model_risk_officer": { "summary": "The MRO provides technical input to the regulatory engagement program, including documentation of model changes, validation findings, and governance improvements relevant to examiner questions.", "actions": [ "Maintain a log of material model changes and significant validation findings ready for regulatory examination.", "Support the regulatory liaison with technical briefing preparation when supervisors request information on specific models.", "Participate in examination entrance and exit conferences to provide technical accuracy on model risk program status." ], "failure_signals": [ "Material model change log is not current at the time of a regulatory examination.", "Technical briefing documentation for a model cannot be produced within the examination response window.", "MRO participation in regulatory examination was not coordinated with the compliance liaison." ] }, "internal_audit": { "summary": "Internal Audit tests the effectiveness of the regulatory engagement program, including whether notification triggers are appropriately defined and whether the correspondence log is complete.", "actions": [ "Review the regulatory correspondence log for completeness against known AI-related communications.", "Assess whether notification trigger criteria are appropriate relative to current supervisory expectations.", "Test whether examination preparation procedures would produce required documentation within the defined SLA." ], "metrics": [ "Correspondence log completeness: no undocumented AI-related communications \u2014 target 100%.", "Examination readiness drill results: required documentation produced within SLA \u2014 target 100%." ], "failure_signals": [ "Correspondence log is missing documented AI-related communications.", "Notification triggers have not been reviewed against current supervisory guidance in more than 12 months.", "Examination readiness drill reveals documentation gaps that would delay regulatory response." ] }, "it_operations": { "summary": "IT Operations runs the regulatory correspondence tracker behind proactive regulatory relationship management for AI \u2014 integrating it with deployment pipelines, enforcing the automated gates, and keeping the supporting data flows reliable and auditable.", "actions": [ "Integrate the regulatory correspondence tracker with CI/CD and runtime tooling so that notification-trigger events are detected from monitoring data.", "Automate collection and retention of trigger detections and correspondence records in immutable, hash-verified storage.", "Monitor pipeline and integration health and alert when a trigger event lacks a corresponding notification decision." ], "failure_signals": [ "Production changes bypass the automated gate so that it is no longer true that notification-trigger events are detected from monitoring data.", "Gaps or outages in trigger detections and correspondence records collection exceeding 24 hours.", "Manual, untracked edits to the regulatory correspondence tracker records." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most enterprises manage regulatory relationships reactively. A proactive AI-specific engagement program with named liaisons and documented notification triggers is the maturity target." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "high-risk-sector", "eu-high-risk-ai", "federated-enterprise", "universal-enterprise" ], "implementers": [ "Chief Compliance Officer", "General Counsel", "Chief Financial Officer", "Model Risk Officer" ], "frameworks": [ { "framework": "eu_ai_act", "requirement_id": "Art. 26(5)", "fit": "direct", "rationale": "EU AI Act Art. 26(5) requires deployers that identify a risk under Art. 79(1) to inform the provider and the relevant market surveillance authority and suspend use, and Art. 73 governs serious-incident reporting. FG-04's regulator-communication process is the institutional mechanism for meeting those notification duties for in-scope systems.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "openai_enterprise", "requirement_id": "Enterprise privacy \u2014 compliance commitments", "fit": "partial", "rationale": "OpenAI's enterprise privacy documentation records its compliance commitments (SOC 2 Type 2, encryption, retention controls) for enterprise customers. Institutions using OpenAI models in financial workflows can incorporate this vendor capability into proactive regulatory relationship management for AI. This is vendor capability documentation, not regulatory guidance; it covers the vendor side only.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "aws_financial", "requirement_id": "AWS User Guide to Financial Services Regulations & Guidelines in the United States", "fit": "partial", "rationale": "The 'AWS User Guide to Financial Services Regulations & Guidelines in the United States' whitepaper maps AWS services and shared-responsibility considerations to US financial regulatory expectations. For AWS-hosted financial AI systems, this supplies the infrastructure-layer support and evidence stream for proactive regulatory relationship management for AI. This is vendor documentation of real AWS capabilities \u2014 it does not substitute for model-layer validation or regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_financial", "requirement_id": "Google Cloud compliance offerings", "fit": "partial", "rationale": "Google Cloud's compliance offerings catalog documents the platform's third-party attestations (SOC 1/2/3, ISO/IEC 27001, PCI DSS) available to customers. For GCP-hosted financial AI systems, this capability supplies the platform-layer support for proactive regulatory relationship management for AI. This is vendor product documentation, not regulatory guidance; it does not address model-layer regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://finance/controls/FG-04", "meta": { "authored_on": "2026-06-29", "schema_version": "1.1.0" }, "validation_objective": "A named regulatory liaison with documented authority exists and is backed by a designated alternate, a regulatory correspondence log captures all AI-related communications within 24 hours, and notification trigger criteria have been assessed against the current AI system portfolio within the prior 90 days. The examination preparation playbook must have been tested within the prior 12 months and confirmed to produce required documentation within the defined SLA.", "evidence_required": [ "regulatory_liaison_register with named_liaison, alternate_liaison, appointment_date, and scope_of_authority documentation for AI-related financial supervisory communications", "regulatory_correspondence_log with entry_timestamp, communication_type, regulator_identifier, and response_deadline_tracked flag for each AI-related communication in scope", "notification_trigger_assessment report dated within prior 90 days identifying which AI systems in the current portfolio were evaluated against each defined trigger criterion", "examination_preparation_playbook_drill_record with drill_date within prior 12 months, documentation_types_produced list, SLA_met flag, and gaps_identified notation" ], "machine_tests": [ "Query regulatory_liaison_register \u2192 assert named_liaison and alternate_liaison fields are populated with active employee identifiers and appointment_date is not null", "Query regulatory_correspondence_log entries for prior 90 days \u2192 assert capture_timestamp minus communication_date is less than or equal to 24 hours for all AI-related communication entries", "Query notification_trigger_assessment records \u2192 assert most recent assessment_date is within 90 days of current date", "Query examination_preparation_playbook_drill_record \u2192 assert most recent drill_date is within 12 months and SLA_met equals true" ], "human_review": [ "Review notification trigger criteria against current supervisory expectations and EU AI Act Art. 26(5) / Art. 73 notification duties, and assess whether the criteria are specific enough to capture material AI developments objectively rather than requiring subjective judgment at the time of each event", "Assess correspondence log completeness by cross-referencing against known AI developments, model change logs, and examination records to determine whether informal supervisory contacts and industry consultation responses are captured alongside formal inquiries", "Evaluate the examination preparation playbook against a realistic regulatory request scenario, reviewing whether required documentation would be produced within the defined SLA and whether the playbook accounts for multi-regulator examinations" ], "blocking_effect": "advisory", "normative_status": "supervisory-guidance", "anti_patterns": [ "Managing regulatory relationships through ad hoc communications without a named liaison, correspondence log, or defined notification triggers, leaving the enterprise unable to demonstrate a systematic engagement process during examination", "Defining notification triggers so broadly (e.g., 'significant model changes') that each application requires subjective interpretation rather than measurable criteria tied to materiality thresholds or defined change categories", "Maintaining a regulatory correspondence log only for formal written regulatory examinations rather than all AI-related communications, missing informal supervisory meetings, industry consultation responses, and verbal supervisory inquiries", "Testing examination preparation by reviewing internal documentation availability without simulating the regulator's request format, deadline pressure, and scope, producing a false confidence in examination readiness", "Allowing the named regulatory liaison role to be unfilled or held without a designated alternate, creating a single point of failure that leaves the enterprise unable to respond within required timelines during personnel transitions" ], "update_status": "current", "layer_code": "FG" }, { "id": "FG-05", "layer": "FG", "plane": "both", "name": "Finance AI Incident Response Integration", "plain": "AI-related financial incidents \u2014 including model failures causing erroneous outputs, unauthorized model changes, and AI-driven fraud events \u2014 must be integrated into the enterprise incident management process with defined classification criteria, regulatory notification procedures, and post-incident review requirements.", "threat": { "tags": [ "uncontained-financial-model-failure", "delayed-regulatory-notification", "incident-escalation-failure", "post-incident-blind-spot" ], "desc": "Financial AI incidents that are classified as IT incidents rather than model risk events bypass the validation and regulatory notification procedures required for financial AI. Regulatory notification deadlines \u2014 often 36 to 72 hours \u2014 are missed when AI incident classification is ambiguous. Post-incident reviews that do not involve model risk teams fail to identify systemic weaknesses in the validation program." }, "standard": [ { "id": "eu_ai_act", "section": "Art. 73", "title": "Serious incident reporting obligations" }, { "id": "sox", "section": "\u00a7302", "title": "Management attestation covering material control failures" }, { "id": "aicpa_soc2", "section": "CC7.3", "title": "Incident response procedures" } ], "sources": [ { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Anthropic's Responsible Scaling Policy v3.3 documents the vendor's capability thresholds and safeguards, cited as third-party AI due diligence context for the apeiris://finance/controls/FG-05 Finance AI Incident Response Integration control.", "reviewed_on": "2026-07-02" }, { "id": "openai_enterprise_data_governance_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "OpenAI's enterprise privacy and compliance documentation records vendor-side data handling and audit-log capabilities relevant to the apeiris://finance/controls/FG-05 Finance AI Incident Response Integration control.", "reviewed_on": "2026-07-02" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://finance/controls/FG-05 Finance AI Incident Response Integration control.", "reviewed_on": "2026-07-01" }, { "id": "aws_financial_services_compliance_2024", "title": "AWS User Guide to Financial Services Regulations & Guidelines in the United States", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/financial-services/security-compliance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_financial_services_compliance_2024", "relationship": "informative_reference", "rationale": "AWS's financial services regulatory guide and compliance tooling document infrastructure-layer capabilities relevant to the apeiris://finance/controls/FG-05 Finance AI Incident Response Integration control.", "reviewed_on": "2026-07-02" }, { "id": "okta_financial_services_access_2025", "title": "Okta for Financial Services", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://www.okta.com/solutions/financial-services/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_financial_services_access_2025", "relationship": "informative_reference", "rationale": "Okta's identity products (System Log, access management, Adaptive MFA, Privileged Access) supply identity-layer enforcement and evidence relevant to the apeiris://finance/controls/FG-05 Finance AI Incident Response Integration control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Extend the enterprise incident management policy with an AI-specific classification tier, a decision tree for regulatory notification, a cross-functional incident response team that includes model risk, and mandatory post-incident review with root-cause analysis for all high-severity AI financial incidents.", "steps": [ "Define AI financial incident classification criteria distinguishing high-severity (material financial impact or regulatory notification required), medium (significant operational impact), and low (contained with no financial impact).", "Integrate AI incident classification into the existing enterprise ticketing system with mandatory routing to Model Risk and Compliance for high- and medium-severity events.", "Document regulatory notification thresholds and timelines for each applicable regulator and jurisdiction, and assign notification ownership to Compliance.", "Establish a cross-functional AI incident response team comprising Model Risk, Compliance, IT Security, Finance, and Legal with defined roles and an escalation ladder.", "Require a post-incident review report within 30 days for all high-severity AI financial incidents, including root-cause analysis, control failure identification, and remediation plan with owner and deadline." ], "financial_controller": { "summary": "The financial controller must ensure that AI incidents affecting financial statement accuracy or period-close processes are immediately escalated and that affected line items are assessed for restatement risk.", "actions": [ "Maintain a watch list of AI systems whose failure would require financial statement review or potential restatement.", "Confirm that incident classification criteria include financial statement impact as a high-severity trigger.", "Engage with Internal Audit and external auditors when an AI incident may affect the reliability of financial reporting." ], "failure_signals": [ "AI incident affecting a financial statement input was not identified as high-severity.", "Potential restatement risk from an AI incident was not communicated to external auditors.", "Financial controller was not included in the post-incident review for a high-severity AI financial incident." ] }, "model_risk_officer": { "summary": "The MRO leads the technical investigation of AI financial incidents, including root-cause analysis of model failures and assessment of whether the validation program detected or should have detected the failure.", "actions": [ "Triage all high- and medium-severity AI financial incidents within four business hours to determine model failure versus data versus infrastructure root cause.", "Lead the post-incident root-cause analysis and identify whether the validation program had any gaps that allowed the failure to reach production.", "Track remediation commitments from post-incident reviews and report status to the Model Risk Committee quarterly." ], "failure_signals": [ "Root-cause analysis for a high-severity incident was not completed within 30 days.", "Post-incident review identified validation gaps that were previously reported but not remediated.", "Remediation commitments from post-incident reviews are not tracked in the model risk management system." ] }, "compliance_officer": { "summary": "Compliance owns the regulatory notification process for AI financial incidents, including assessing notification thresholds, drafting notifications, and tracking regulatory responses.", "actions": [ "Assess regulatory notification requirements within four business hours of a high-severity AI incident classification.", "Draft and deliver required regulatory notifications within applicable timelines.", "Maintain a notification log tracking all AI-related regulatory notifications and regulatory responses." ], "metrics": [ "Regulatory notification delivery within applicable timelines: target 100%.", "Post-incident review completion for high-severity incidents within 30 days: target 100%.", "Notification log completeness: all notifications documented \u2014 target 100%." ], "failure_signals": [ "Regulatory notification deadline was missed for any high-severity AI incident.", "Notification threshold assessment was not performed within four business hours of a high-severity classification.", "Regulatory notification log is not current or cannot be produced for examination." ] }, "internal_audit": { "summary": "Internal Audit evaluates the effectiveness of AI incident response integration by reviewing incident classifications, notification timeliness, and post-incident review quality.", "actions": [ "Review a sample of AI-related incidents and assess whether classification criteria were applied correctly.", "Test whether regulatory notifications were delivered within required timelines.", "Assess whether post-incident reviews identify systemic issues and whether remediation commitments are tracked." ], "metrics": [ "Incident classification accuracy: correct tier applied \u2014 target 95%.", "Post-incident review completion rate for high-severity incidents: target 100%." ], "failure_signals": [ "High-severity AI incidents were classified at a lower tier, bypassing regulatory notification assessment.", "Post-incident reviews are not completed within 30 days for high-severity incidents.", "Remediation commitments from post-incident reviews are not tracked to closure." ] }, "it_operations": { "summary": "IT Operations runs incident tooling integration for AI events behind finance AI incident response integration \u2014 integrating it with deployment pipelines, enforcing the automated gates, and keeping the supporting data flows reliable and auditable.", "actions": [ "Integrate incident tooling integration for AI events with CI/CD and runtime tooling so that AI incident types route into enterprise incident management with model context attached.", "Automate collection and retention of incident records with model linkage in immutable, hash-verified storage.", "Monitor pipeline and integration health and alert when AI-related incidents lack model inventory linkage." ], "failure_signals": [ "Production changes bypass the automated gate so that it is no longer true that AI incident types route into enterprise incident management with model context attached.", "Gaps or outages in incident records with model linkage collection exceeding 24 hours.", "Manual, untracked edits to incident tooling integration for AI events records." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Enterprises typically handle AI incidents through IT incident management without model risk routing or regulatory notification assessment. A dedicated AI incident tier is the gap." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "federated-enterprise" ], "implementers": [ "Model Risk Officer", "Chief Information Security Officer", "Chief Compliance Officer", "Chief Financial Officer" ], "frameworks": [ { "framework": "eu_ai_act", "requirement_id": "Art. 73", "fit": "direct", "rationale": "EU AI Act Art. 73 requires providers and deployers of high-risk AI to report serious incidents to relevant national authorities without undue delay, and within defined timelines. An AI incident response process with embedded regulatory notification assessment and ownership is the mechanism for meeting this obligation. Financial entities operating high-risk AI must have a tested notification process.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "sox", "requirement_id": "\u00a7302", "fit": "partial", "rationale": "SOX \u00a7302 certifiers must be able to identify material weaknesses in internal controls. An AI model failure that affects financial statement accuracy is a material control failure requiring disclosure. The incident classification and escalation process ensures that SOX certifiers are informed of AI-related control failures in time to make disclosure decisions.", "normative_force": "binding-law", "source_version": "2002", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "satisfies" }, { "framework": "soc2", "requirement_id": "CC7.3", "fit": "direct", "rationale": "AICPA SOC 2 CC7.3 requires that entities evaluate security events and determine whether they constitute security incidents, identify the impact, and respond appropriately. AI financial incidents are a category of events requiring defined response procedures. SOC 2 auditors examining financial data processing systems will assess incident response capabilities including AI-specific procedures.", "normative_force": "certification-standard", "source_version": "2022", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "bcbs_239", "requirement_id": "Principle 10", "fit": "adjacent", "rationale": "BCBS 239 Principle 10 requires that risk data aggregation capabilities be resilient, including the ability to identify and report data quality issues. AI financial incidents that affect risk data quality are within scope of this principle. The post-incident review requirement ensures that risk data quality failures arising from AI are systematically analyzed and remediated.", "normative_force": "supervisory-guidance", "source_version": "2013", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "satisfies" }, { "framework": "openai_enterprise", "requirement_id": "Enterprise Compliance API \u2014 audit logs", "fit": "partial", "rationale": "ChatGPT Enterprise and the OpenAI API expose workspace audit-log data through the Compliance API and audit logs endpoint, exportable to SIEM and evidence stores. Institutions using OpenAI models in financial workflows can incorporate this vendor capability into finance AI incident response integration. This is vendor capability documentation, not regulatory guidance; it covers the vendor side only.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "RS2", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal RS2 (Failures and remediations) requires processes for identifying, reporting, and remediating failures and predictable misuse. For institutions using Azure AI services, this goal produces vendor-side governance artifacts that align with finance AI incident response integration. The Standard is Microsoft's published internal policy offered as reference practice, not regulatory guidance.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_financial", "requirement_id": "Financial Services Industry Lens \u2014 AWS Well-Architected", "fit": "partial", "rationale": "The Financial Services Industry Lens for the AWS Well-Architected Framework describes design principles, risk considerations, and shared-responsibility boundaries for regulated financial workloads on AWS. For AWS-hosted financial AI systems, this supplies the infrastructure-layer support and evidence stream for finance AI incident response integration. This is vendor documentation of real AWS capabilities \u2014 it does not substitute for model-layer validation or regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "okta_financial", "requirement_id": "Okta System Log", "fit": "partial", "rationale": "The Okta System Log records authentication and access events with actor, target, outcome, and timestamp detail, exportable for audit retention. Where access to financial AI systems is brokered through Okta, this capability supplies the identity-layer enforcement and evidence for finance AI incident response integration. This is vendor product documentation, not a financial-services control framework.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://finance/controls/FG-05", "meta": { "authored_on": "2026-06-29", "schema_version": "1.1.0" }, "validation_objective": "All AI-related financial incidents are classified using defined three-tier criteria within four business hours of detection, regulatory notification requirements are assessed and notifications are delivered within applicable deadlines for all high-severity incidents, and post-incident review reports are completed within 30 days. The enterprise ticketing system must demonstrate automatic routing of AI financial incidents to Model Risk and Compliance queues upon high- or medium-severity classification.", "evidence_required": [ "ai_incident_log with incident_id, classification_tier, classification_timestamp, model_risk_routing_confirmed flag, and regulatory_notification_assessment_timestamp for each AI-related financial incident", "regulatory_notification_record with incident_id, applicable_regulator, notification_deadline, notification_delivery_timestamp, and notification_content_reference for each high-severity incident requiring regulatory notification", "post_incident_review_report with incident_id, root_cause_classification (model/data/infrastructure), validation_gap_identified flag, remediation_plan with named_owner and deadline, and report_completion_date for each high-severity incident", "incident_response_team_activation_log with incident_id, team_member_identifiers, role_assignments, and escalation_ladder_compliance flag for high-severity incidents" ], "machine_tests": [ "Submit a test incident record with AI financial impact keywords into enterprise ticketing system \u2192 assert automatic routing to Model Risk and Compliance queues occurs within the defined response SLA without manual intervention", "Query ai_incident_log for high-severity incidents in prior 90 days \u2192 assert classification_timestamp minus incident_reported_timestamp is less than or equal to four business hours for all entries", "Query post_incident_review_report records for high-severity incidents \u2192 assert report_completion_date minus incident_classification_date is less than or equal to 30 calendar days for all entries", "Query regulatory_notification_record for high-severity incidents requiring notification \u2192 assert notification_delivery_timestamp is before notification_deadline for every entry" ], "human_review": [ "Review a sample of AI-related incident classifications and assess whether three-tier criteria were applied correctly, specifically evaluating whether AI model failures affecting financial statement inputs or period-close processes were classified as high-severity", "Review post-incident review reports for root-cause analysis quality, assessing whether reports substantively distinguish model failure from data and infrastructure causes and whether validation program gaps are candidly identified rather than attributed solely to external factors", "Assess whether the cross-functional incident response team composition and escalation ladder reflect the current AI system risk profile and whether all team members have role-specific training for AI financial incident response" ], "blocking_effect": "requires-review", "normative_status": "binding-law", "anti_patterns": [ "Classifying AI model failures that produce erroneous financial outputs as general IT incidents rather than model risk events, routing them through IT service management without triggering model risk review or regulatory notification assessment", "Beginning regulatory notification assessment only after incident remediation is complete rather than within four business hours of high-severity classification, systematically missing mandatory reporting deadlines", "Conducting post-incident reviews without model risk function involvement, resulting in root-cause analyses that attribute failures to data or infrastructure without assessing whether the validation program should have detected the failure before production", "Mapping regulatory notification requirements to a single generic deadline rather than per-regulator and per-jurisdiction timelines, causing missed notifications for regulators with shorter mandatory reporting windows", "Closing high-severity incident records after containment without completing a post-incident review report, treating remediation completion as the end of the incident response lifecycle and losing the systemic improvement opportunity" ], "update_status": "current", "layer_code": "FG" }, { "id": "FG-06", "layer": "FG", "plane": "control", "name": "Financial AI Program Metrics and Board Reporting", "plain": "The financial AI governance program must produce and report a defined set of key risk indicators to the board on a quarterly basis, covering model risk coverage rate, validation timeliness, outstanding findings severity, control effectiveness scores, and regulatory examination readiness status.", "threat": { "tags": [ "metrics-gap", "invisible-model-risk", "board-information-asymmetry", "governance-theater" ], "desc": "Without defined metrics tied to board reporting, financial AI governance becomes compliance theater \u2014 committees meet but risk accumulation is not visible. Boards cannot exercise meaningful oversight without quantitative indicators showing whether the program is operating within defined risk appetite. Metric absence is a common examination finding that signals governance is nominal rather than substantive." }, "standard": [ { "id": "sr26_2", "section": "\u00a7VI (Roles and Responsibilities)", "title": "Reporting to board and senior management" }, { "id": "coso_icfr", "section": "Principle 16", "title": "Monitoring activities and communication" }, { "id": "sox", "section": "\u00a7404", "title": "Management assessment including control effectiveness metrics" }, { "id": "bcbs_239", "section": "Principle 8", "title": "Comprehensiveness of risk reporting" } ], "sources": [ { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://finance/controls/FG-06 Financial AI Program Metrics and Board Reporting control.", "reviewed_on": "2026-07-01" }, { "id": "aws_financial_services_compliance_2024", "title": "AWS User Guide to Financial Services Regulations & Guidelines in the United States", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/financial-services/security-compliance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_financial_services_compliance_2024", "relationship": "informative_reference", "rationale": "AWS's financial services regulatory guide and compliance tooling document infrastructure-layer capabilities relevant to the apeiris://finance/controls/FG-06 Financial AI Program Metrics and Board Reporting control.", "reviewed_on": "2026-07-02" }, { "id": "google_cloud_financial_services_ai_2024", "title": "Google Cloud Explainable AI", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/explainable-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_financial_services_ai_2024", "relationship": "informative_reference", "rationale": "Google Cloud's Explainable AI and Vertex AI model governance documentation describes platform capabilities relevant to the apeiris://finance/controls/FG-06 Financial AI Program Metrics and Board Reporting control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Define a financial AI program metrics framework with five to ten mandatory KRIs, establish automated or semi-automated data collection, produce quarterly board-level reports and monthly management-level reports, and set thresholds triggering management or board escalation.", "steps": [ "Define the mandatory KRI set: model risk coverage rate (percentage of in-scope systems with current validation), validation timeliness (percentage completed within SLA), outstanding high/medium findings rate, control effectiveness score (rolling average from quarterly assessments), and regulatory examination readiness score.", "Establish data collection procedures for each KRI, including system of record, collection frequency, and responsible owner.", "Set risk appetite thresholds for each KRI \u2014 green (within tolerance), amber (approaching threshold), and red (breach) \u2014 with corresponding escalation actions.", "Produce a quarterly board-level KRI dashboard and a monthly management-level metrics report with trend analysis.", "Require that red-status KRIs trigger a management action plan within five business days with a defined remediation timeline and owner." ], "financial_controller": { "summary": "The financial controller uses program metrics to assess whether AI controls over financial reporting are operating effectively and to inform SOX \u00a7404 control effectiveness conclusions.", "actions": [ "Review the control effectiveness score for AI systems influencing financial statements before each SOX \u00a7404 assessment.", "Ensure that any red-status KRI affecting financial reporting controls is documented in the SOX deficiency assessment.", "Confirm that board reporting metrics are consistent with the representations made in management certifications." ], "failure_signals": [ "SOX \u00a7404 assessment does not reference AI program control effectiveness metrics.", "Red-status KRI affecting financial reporting is not documented as a potential SOX deficiency.", "Management certifications contradict the current KRI status for AI financial controls." ] }, "model_risk_officer": { "summary": "The MRO is responsible for producing the underlying model risk data that feeds the KRI framework and ensuring the metrics accurately reflect program status.", "actions": [ "Maintain the data sources for all model risk KRIs and ensure data quality and timeliness.", "Produce the monthly management metrics report and the quarterly board KRI dashboard.", "Trigger the red-status action plan process within five business days of any KRI breaching the red threshold." ], "failure_signals": [ "KRI data sources are not current or have known accuracy issues not disclosed in the report.", "Monthly management metrics report was not produced in the prior month.", "Red-status KRI did not trigger an action plan within five business days." ] }, "compliance_officer": { "summary": "Compliance ensures the KRI framework is aligned with regulatory expectations and that metrics reported to the board are examination-ready.", "actions": [ "Map the KRI framework against SR 26-2 reporting expectations and EU AI Act obligations and document alignment.", "Confirm that the board reporting format and content would satisfy a regulatory examiner request for evidence of board oversight.", "Review the KRI framework annually against emerging regulatory guidance and update as needed." ], "metrics": [ "KRI framework regulatory alignment review: completed annually \u2014 target 100%.", "Board reporting package examination readiness: available within 48 hours \u2014 target 100%.", "Red-status KRI action plan completion within defined timeline: target 90%." ], "failure_signals": [ "KRI framework has not been reviewed against current regulatory guidance in more than 12 months.", "Board reporting package cannot be produced for regulatory examination within 48 hours.", "Red-status KRI action plans are consistently not completed within the defined timeline." ] }, "internal_audit": { "summary": "Internal Audit independently validates the accuracy and completeness of reported KRIs and assesses whether the metrics framework provides genuine insight into program risk.", "actions": [ "Select a sample of KRIs and independently recompute values from source data to verify accuracy.", "Assess whether the KRI set provides sufficient coverage of material model risk dimensions.", "Test whether red-status KRI action plans are completed within the required timeline." ], "metrics": [ "KRI accuracy validation: sampled KRIs match reported values \u2014 target 95%.", "Red-status action plan completion rate within timeline: target 90%." ], "failure_signals": [ "Independently computed KRI values diverge materially from reported values.", "KRI set does not cover material model risk dimensions identified in the institution's model risk framework.", "Red-status action plans are repeatedly not completed within the defined timeline." ] }, "it_operations": { "summary": "IT Operations runs the KRI computation pipeline behind financial AI program metrics and board reporting \u2014 integrating it with deployment pipelines, enforcing the automated gates, and keeping the supporting data flows reliable and auditable.", "actions": [ "Integrate the KRI computation pipeline with CI/CD and runtime tooling so that KRIs compute automatically from production data on schedule.", "Automate collection and retention of KRI time series and computation runs in immutable, hash-verified storage.", "Monitor pipeline and integration health and alert when KRI computations fail or use stale inputs." ], "failure_signals": [ "Production changes bypass the automated gate so that it is no longer true that KRIs compute automatically from production data on schedule.", "Gaps or outages in KRI time series and computation runs collection exceeding 24 hours.", "Manual, untracked edits to the KRI computation pipeline records." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Most enterprises report qualitative risk summaries to the board rather than quantitative KRIs. Establishing a defined, data-backed KRI framework is the key maturity advancement." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "federated-enterprise" ], "implementers": [ "Model Risk Officer", "Chief Financial Officer", "Board Risk Committee", "Internal Audit" ], "frameworks": [ { "framework": "sr26_2", "requirement_id": "\u00a7VI (Roles and Responsibilities)", "fit": "direct", "rationale": "SR 26-2 \u00a7VI describes board and senior management receiving reporting sufficient to oversee the institution's model risk profile. A defined KRI framework with quantitative indicators and trend reporting is one way to make that reporting substantive; the guidance does not prescribe specific metrics or cadences.", "normative_force": "supervisory-guidance", "source_version": "2026-04-17", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "coso_icfr", "requirement_id": "Principle 16", "fit": "direct", "rationale": "COSO Principle 16 requires that organizations select, develop, and perform ongoing and separate evaluations and communicate deficiencies in internal control. A KRI framework with defined thresholds and escalation triggers is the monitoring activity that satisfies this principle. Board reporting of KRI status is the communication mechanism.", "normative_force": "industry-framework", "source_version": "2013", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "informs" }, { "framework": "sox", "requirement_id": "\u00a7404", "fit": "partial", "rationale": "SOX \u00a7404 requires management to assess the effectiveness of internal controls over financial reporting. Control effectiveness metrics for AI financial systems are a direct input to this assessment. A defined KRI framework provides the quantitative evidence base for management's \u00a7404 conclusions.", "normative_force": "binding-law", "source_version": "2002", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "satisfies" }, { "framework": "bcbs_239", "requirement_id": "Principle 8", "fit": "partial", "rationale": "BCBS 239 Principle 8 (Comprehensiveness) requires risk management reports to cover all material risk areas, with depth consistent with the size and complexity of operations. A KRI framework for financial AI ensures model risk appears in board risk reporting with the comprehensiveness Principle 8 expects at BCBS 239 institutions.", "normative_force": "supervisory-guidance", "source_version": "2013", "reviewed_on": "2026-07-02", "basis": "asserted", "relation": "satisfies" }, { "framework": "omb_a_123", "requirement_id": "Section VI", "fit": "adjacent", "rationale": "OMB Circular A-123 (M-16-17) Section VI covers the assessment and reporting cycle through which management monitors internal control and reports results. A KRI framework with defined thresholds and board reporting supplies the quantitative substance for that reporting cycle.", "normative_force": "supervisory-guidance", "source_version": "2016", "reviewed_on": "2026-07-02", "basis": "asserted", "relation": "satisfies" }, { "framework": "microsoft_rai", "requirement_id": "T2", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal T2 (Communication to stakeholders) requires communicating system capabilities and limitations to stakeholders. For institutions using Azure AI services, this goal produces vendor-side governance artifacts that align with financial AI program metrics and board reporting. The Standard is Microsoft's published internal policy offered as reference practice, not regulatory guidance.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_financial", "requirement_id": "AWS Audit Manager", "fit": "partial", "rationale": "AWS Audit Manager automates evidence collection against control frameworks for AWS workloads, and AWS CloudTrail records account-level API activity. For AWS-hosted financial AI systems, this supplies the infrastructure-layer support and evidence stream for financial AI program metrics and board reporting. This is vendor documentation of real AWS capabilities \u2014 it does not substitute for model-layer validation or regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_financial", "requirement_id": "Vertex AI Model Monitoring", "fit": "partial", "rationale": "Vertex AI Model Monitoring detects prediction drift and training-serving skew for models deployed on Google Cloud. For GCP-hosted financial AI systems, this capability supplies the platform-layer support for financial AI program metrics and board reporting. This is vendor product documentation, not regulatory guidance; it does not address model-layer regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://finance/controls/FG-06", "meta": { "authored_on": "2026-06-29", "schema_version": "1.1.0" }, "validation_objective": "A defined KRI set covering at minimum model risk coverage rate, validation timeliness, outstanding findings severity, control effectiveness score, and regulatory examination readiness is computed from documented source systems, reported to the board quarterly with trend data, and any KRI breaching its red threshold triggers a management action plan within five business days. At least one quarterly board KRI dashboard must exist for the prior period with documented board committee acknowledgment.", "evidence_required": [ "kri_framework_definition with at least five KRIs, each having data_source, collection_frequency, responsible_owner, and green/amber/red threshold values defined", "quarterly_board_kri_dashboard for each quarter in scope with KRI values, trend_direction, threshold_status, and board_committee_delivery_date", "red_status_action_plan with kri_identifier, breach_detection_date, action_plan_owner, action_plan_creation_date within five business days of breach, and remediation_deadline", "kri_data_quality_certification signed by the MRO confirming data sources are current and disclosing any known accuracy limitations for each reporting period" ], "machine_tests": [ "Query kri_framework_definition \u2192 assert at least five KRIs are defined with data_source, green/amber/red threshold values, and responsible_owner populated for each", "Query quarterly_board_kri_dashboard records \u2192 assert at least one dashboard exists with board_committee_delivery_date within the prior 90 days and all required KRI categories present", "Query red_status_action_plan records for KRIs that breached red threshold \u2192 assert action_plan_creation_date minus breach_detection_date is less than or equal to five business days for all entries", "Independently compute two sampled KRI values from documented source systems \u2192 assert independently computed values match reported dashboard values within the defined tolerance range" ], "human_review": [ "Assess whether the KRI set provides genuine coverage of material model risk dimensions described in SR 26-2 and EU AI Act expectations, or whether the metrics are operationally easy to collect but fail to surface meaningful governance risk accumulation", "Review red-status action plans for completeness and feasibility, assessing whether remediation timelines are realistic, owners have accepted accountability, and root causes are addressed rather than just the symptom that triggered the threshold breach", "Evaluate board reporting format and content depth against the standard of what a regulatory examiner would require as evidence of substantive board oversight, including whether the board receives trend data enabling assessment of risk trajectory" ], "blocking_effect": "advisory", "normative_status": "supervisory-guidance", "anti_patterns": [ "Defining KRIs that measure governance activity volume (e.g., number of models validated this quarter) rather than program outcomes (e.g., percentage of in-scope models with current validation), producing green metrics while material risk coverage gaps accumulate", "Setting red thresholds so conservatively that no KRI ever reaches red status in practice, creating the appearance of a fully controlled environment while governance gaps go unescalated to the board", "Computing KRIs manually from spreadsheets without a documented source system of record, enabling reported values to be adjusted or smoothed before delivery to avoid triggering escalation thresholds", "Producing quarterly board KRI dashboards that present only current-period point-in-time values without trend data or period-over-period comparison, preventing the board from detecting whether risk is improving or deteriorating", "Treating board delivery of the KRI dashboard as completion of the reporting requirement without obtaining documented committee acknowledgment, leaving no evidence that the board engaged with the metrics or acted on red-status findings" ], "update_status": "current", "layer_code": "FG" }, { "id": "FG-07", "layer": "FG", "plane": "lifecycle", "name": "Annual AI Governance Review", "plain": "The financial AI governance program must undergo a comprehensive annual assessment evaluating the governance structure, policies, role assignments, board reporting adequacy, regulatory alignment, and program effectiveness against current regulatory expectations and industry best practices \u2014 with findings reported to the board.", "threat": { "tags": [ "governance-drift", "regulatory-misalignment", "stale-program", "undetected-control-decay" ], "desc": "Governance programs that are established but not annually reviewed drift from regulatory expectations as guidance evolves. Role changes, technology evolution, and regulatory updates create gaps between documented governance and actual practice. Annual reviews detect these drifts before they are discovered by regulators in examination, and reset accountability in governance roles that have experienced personnel change." }, "standard": [ { "id": "sr26_2", "section": "\u00a7VI (Governance and Controls)", "title": "Maintaining policies and governance" }, { "id": "eu_ai_act", "section": "Art. 9(6)", "title": "Continuous update of risk management system" }, { "id": "omb_a_123", "section": "Section VI.A", "title": "Annual assurance on internal control" }, { "id": "coso_icfr", "section": "Principle 17", "title": "Evaluation and communication of deficiencies" } ], "sources": [ { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Anthropic's Responsible Scaling Policy v3.3 documents the vendor's capability thresholds and safeguards, cited as third-party AI due diligence context for the apeiris://finance/controls/FG-07 Annual AI Governance Review control.", "reviewed_on": "2026-07-02" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://finance/controls/FG-07 Annual AI Governance Review control.", "reviewed_on": "2026-07-01" }, { "id": "aws_financial_services_compliance_2024", "title": "AWS User Guide to Financial Services Regulations & Guidelines in the United States", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/financial-services/security-compliance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_financial_services_compliance_2024", "relationship": "informative_reference", "rationale": "AWS's financial services regulatory guide and compliance tooling document infrastructure-layer capabilities relevant to the apeiris://finance/controls/FG-07 Annual AI Governance Review control.", "reviewed_on": "2026-07-02" }, { "id": "google_cloud_financial_services_ai_2024", "title": "Google Cloud Explainable AI", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/explainable-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_financial_services_ai_2024", "relationship": "informative_reference", "rationale": "Google Cloud's Explainable AI and Vertex AI model governance documentation describes platform capabilities relevant to the apeiris://finance/controls/FG-07 Annual AI Governance Review control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Conduct an annual structured review of the financial AI governance program covering eight dimensions: governance structure adequacy, policy currency, role assignment completeness, board reporting quality, regulatory alignment, incident response effectiveness, KRI framework adequacy, and validation program coverage \u2014 with a written findings report to the board.", "steps": [ "Schedule the annual review at a fixed point in the calendar year, with completion before the annual board risk review.", "Define the eight-dimension assessment framework and assign a review lead for each dimension \u2014 typically Internal Audit leads or co-leads with Compliance.", "Collect evidence for each dimension from the prior year: governance meeting minutes, model risk reports, incident records, KRI trend data, and regulatory correspondence.", "Produce a written annual review report with findings classified by severity, a comparison to the prior year's findings, and a remediation plan with named owners and deadlines.", "Present the annual review report to the board risk or audit committee and obtain documented acknowledgment and approval of the remediation plan." ], "financial_controller": { "summary": "The financial controller ensures that the annual governance review covers the adequacy of AI controls over financial reporting and that any identified gaps are assessed for SOX \u00a7404 implications.", "actions": [ "Participate in the annual review as a subject matter expert for AI controls over financial reporting.", "Assess whether annual review findings include any items that rise to the level of SOX \u00a7404 deficiencies.", "Confirm that the remediation plan for financial reporting-related findings is resourced and scheduled before the next annual assessment." ], "failure_signals": [ "Annual review does not assess AI controls over financial reporting adequacy.", "SOX \u00a7404 deficiency implications of annual review findings were not assessed.", "Prior year remediation commitments for financial reporting-related findings were not completed." ] }, "model_risk_officer": { "summary": "The MRO provides evidence and input for the annual review dimensions related to validation coverage, model risk policy, and program effectiveness.", "actions": [ "Compile model risk program evidence package for the annual review: validation coverage statistics, policy documents, role assignment register, and KRI trend data.", "Participate in the assessment of the validation program coverage dimension and provide context for any coverage gaps.", "Track and report on remediation plan items assigned to the model risk function." ], "failure_signals": [ "Model risk evidence package is not complete or current for the annual review.", "Annual review identifies validation coverage gaps that were not reported to the Model Risk Committee during the year.", "MRO-owned remediation items are not completed within the agreed timeline." ] }, "compliance_officer": { "summary": "Compliance leads the regulatory alignment dimension of the annual review, assessing program adequacy against current SR 26-2 expectations and EU AI Act and SOX requirements.", "actions": [ "Conduct a gap assessment of the current governance program against the most recent versions of SR 26-2, EU AI Act, and applicable SOX guidance.", "Identify any regulatory developments in the prior year that require governance program updates.", "Ensure the annual review report is structured to be presentable to regulatory examiners as evidence of program oversight." ], "metrics": [ "Annual review completion: completed and reported to board annually \u2014 target 100%.", "Regulatory alignment gap assessment: completed for all applicable frameworks \u2014 target 100%.", "Prior year remediation commitment completion rate: target 85%." ], "failure_signals": [ "Annual review was not completed before the board's annual risk review.", "Regulatory alignment assessment did not cover all applicable frameworks.", "More than 15% of prior year remediation commitments were not completed within agreed timelines." ] }, "internal_audit": { "summary": "Internal Audit leads or co-leads the annual review to provide independence and objectivity, and assesses whether prior year findings have been genuinely remediated.", "actions": [ "Lead the annual governance review and produce the written findings report.", "Independently assess whether prior year remediation commitments were completed effectively and sustainably.", "Present findings and remediation plan to the board audit committee and obtain documented acknowledgment." ], "metrics": [ "Annual review report delivered to board before annual risk review: target 100%.", "Prior year finding remediation effectiveness: assessed for all closed items \u2014 target 100%." ], "failure_signals": [ "Annual review was not led or co-led by Internal Audit.", "Prior year findings were closed without evidence of genuine remediation.", "Board audit committee did not formally acknowledge the annual review report." ] }, "it_operations": { "summary": "IT Operations runs review evidence collection behind the annual AI governance review \u2014 integrating it with deployment pipelines, enforcing the automated gates, and keeping the supporting data flows reliable and auditable.", "actions": [ "Integrate review evidence collection with CI/CD and runtime tooling so that annual-review inputs assemble from live systems rather than manual extracts.", "Automate collection and retention of review input snapshots in immutable, hash-verified storage.", "Monitor pipeline and integration health and alert when review inputs cannot be traced to source systems." ], "failure_signals": [ "Production changes bypass the automated gate so that it is no longer true that annual-review inputs assemble from live systems rather than manual extracts.", "Gaps or outages in review input snapshots collection exceeding 24 hours.", "Manual, untracked edits to review evidence collection records." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most enterprises do not conduct a structured annual review of their AI governance program distinct from the general IT audit. A dedicated financial AI governance review with board reporting is the gap." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai" ], "implementers": [ "Internal Audit", "Chief Compliance Officer", "Model Risk Officer", "Board Risk Committee" ], "frameworks": [ { "framework": "sr26_2", "requirement_id": "\u00a7VI (Governance and Controls)", "fit": "direct", "rationale": "SR 26-2 \u00a7VI describes maintaining policies, procedures, and governance arrangements that remain appropriate as the model landscape changes. A structured annual review of the AI governance program operationalizes that maintenance expectation; the annual frequency is an internal practice choice.", "normative_force": "supervisory-guidance", "source_version": "2026-04-17", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "eu_ai_act", "requirement_id": "Art. 9(6)", "fit": "direct", "rationale": "EU AI Act Art. 9(6) requires testing to identify appropriate risk management measures, within the Art. 9(2) requirement that the risk management system be regularly and systematically reviewed and updated. An annual governance review is the institutional cadence for that review-and-update duty across the financial AI portfolio.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "omb_a_123", "requirement_id": "Section VI.A", "fit": "direct", "rationale": "OMB Circular A-123 (M-16-17) Section VI.A addresses the annual assurance process \u2014 management's yearly assessment and statement of assurance over internal control. An annual AI governance review is the equivalent periodic assessment discipline applied to the financial AI program.", "normative_force": "supervisory-guidance", "source_version": "2016", "reviewed_on": "2026-07-02", "basis": "asserted", "relation": "satisfies" }, { "framework": "coso_icfr", "requirement_id": "Principle 17", "fit": "direct", "rationale": "COSO Principle 17 requires that deficiencies in internal controls be communicated to parties responsible for taking corrective action. An annual review that identifies findings, classifies them by severity, and reports to the board with a remediation plan directly satisfies this communication obligation. The board acknowledgment requirement ensures the communication loop is closed.", "normative_force": "industry-framework", "source_version": "2013", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "informs" }, { "framework": "pcaob_as_2201", "requirement_id": "\u00b6.24-.28", "fit": "partial", "rationale": "AS 2201 \u00b6.24-.28 direct the auditor to test entity-level controls, including the period-end and monitoring components of the control environment, whose strength affects the testing of other controls. An annual AI governance review is an entity-level monitoring control over the AI governance program that an auditor would evaluate under those paragraphs.", "normative_force": "certification-standard", "source_version": "2007", "reviewed_on": "2026-07-02", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "microsoft_rai", "requirement_id": "A2", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal A2 (Oversight of significant adverse impacts) requires defined review and oversight processes for AI systems that can cause significant adverse impact. For institutions using Azure AI services, this goal produces vendor-side governance artifacts that align with the annual AI governance review. The Standard is Microsoft's published internal policy offered as reference practice, not regulatory guidance.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_financial", "requirement_id": "AWS Artifact", "fit": "partial", "rationale": "AWS Artifact provides on-demand access to AWS's third-party compliance reports (SOC 1/2, PCI DSS, ISO). For AWS-hosted financial AI systems, this supplies the infrastructure-layer support and evidence stream for the annual AI governance review. This is vendor documentation of real AWS capabilities \u2014 it does not substitute for model-layer validation or regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_financial", "requirement_id": "Google Cloud compliance offerings", "fit": "partial", "rationale": "Google Cloud's compliance offerings catalog documents the platform's third-party attestations (SOC 1/2/3, ISO/IEC 27001, PCI DSS) available to customers. For GCP-hosted financial AI systems, this capability supplies the platform-layer support for the annual AI governance review. This is vendor product documentation, not regulatory guidance; it does not address model-layer regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://finance/controls/FG-07", "meta": { "authored_on": "2026-06-29", "schema_version": "1.1.0" }, "validation_objective": "A comprehensive annual governance review has been completed within the prior 12 months, producing a written findings report covering all eight defined assessment dimensions with findings classified by severity and a year-over-year comparison, accompanied by a remediation plan with named owners and deadlines, and confirmed by documented board audit committee acknowledgment. The review must have been led or co-led by Internal Audit.", "evidence_required": [ "annual_governance_review_report with review_completion_date within prior 12 months, eight_dimension_coverage_checklist with all dimensions assessed, findings classified by severity, prior_year_comparison section, and internal_audit_lead_confirmed flag", "remediation_plan with finding_id, owner, deadline, and current_status for all findings identified in the most recent annual review", "board_audit_committee_acknowledgment record with meeting_date, resolution_or_minute_reference, and acknowledgment_type (reviewed/approved remediation plan)", "prior_year_remediation_closure_evidence showing completion_date and substantive_evidence_reference for each remediation commitment closed from the N-1 annual review" ], "machine_tests": [ "Query annual_governance_review_report records \u2192 assert most recent review_completion_date is within 12 months of current date and internal_audit_lead_confirmed equals true", "Query annual_governance_review_report.eight_dimension_coverage_checklist \u2192 assert all eight dimensions are marked as assessed with a non-null evidence_reference for each", "Query board_audit_committee_acknowledgment records \u2192 assert most recent acknowledgment_date is within 30 days of the most recent review_completion_date", "Query prior_year_remediation_closure_evidence for all items closed from the N-1 review \u2192 assert substantive_evidence_reference is present and non-null for each closed item" ], "human_review": [ "Assess the independence and depth of the annual review by evaluating whether Internal Audit's assessment of prior-year remediation items confirmed genuine operational remediation or merely confirmed that closure documentation was filed without testing whether the underlying control gap was resolved", "Evaluate the regulatory alignment dimension of the review report against current SR 26-2, EU AI Act Art. 9, and any supervisory guidance published since the prior review, and determine whether identified gaps are material and appropriately prioritized in the remediation plan", "Review the board audit committee's engagement with annual review findings by examining meeting minutes for evidence of substantive discussion, questions, and action direction rather than perfunctory acknowledgment of receipt" ], "blocking_effect": "requires-review", "normative_status": "supervisory-guidance", "anti_patterns": [ "Conducting the annual governance review as a compliance self-certification exercise by business lines without independent Internal Audit oversight, producing a consistently positive assessment that cannot detect governance drift", "Closing prior-year remediation commitments based on policy document updates or documentation submission without testing whether the underlying control gap was substantively remediated and is operating effectively in practice", "Scheduling the annual review after the board's annual risk review, depriving the board of current governance assessment information at the time they set risk appetite and allocate resources to remediation", "Limiting review scope to governance documentation and policy currency rather than assessing whether documented governance arrangements match actual operational practice for each of the eight assessment dimensions", "Carrying forward the same findings across multiple annual reviews without escalating persistent non-remediation as a governance deficiency requiring board-level intervention and potential action plan restructuring" ], "update_status": "current", "layer_code": "FG" }, { "id": "FG-08", "layer": "FG", "plane": "both", "name": "FinanceAttestation Production", "plain": "The FinanceAttestation artifact (FG-08) must be produced by aggregating validated evidence across all finance domain control layers (MR, MV, FD, FC, FP, FG), computing a composite verdict and confidence score, applying a cryptographic signature, and publishing the artifact with a defined validity window \u2014 certifying that financial AI governance is implemented and evidenced.", "threat": { "tags": [ "attestation-gap", "unverified-governance-claim", "incomplete-evidence-chain", "signature-spoofing" ], "desc": "Without a formally produced and cryptographically signed FinanceAttestation, claims about financial AI governance adequacy are assertions rather than evidence. Downstream relying parties \u2014 auditors, regulators, and counterparties \u2014 cannot verify that governance controls were actually operating at the time of a financial decision. Attestation produced without aggregating all six finance domain layers creates a false certification that misrepresents actual evidence coverage." }, "standard": [ { "id": "sox", "section": "\u00a7302 & \u00a7404", "title": "Management attestation on financial internal controls" }, { "id": "pcaob_as_2201", "section": "\u00b6.68-.76", "title": "Forming an opinion; representations; deficiency communication" }, { "id": "sr26_2", "section": "\u00a7VI (Documentation)", "title": "Documentation and evidence standards" }, { "id": "eu_ai_act", "section": "Art. 11", "title": "Technical documentation for high-risk AI" } ], "sources": [ { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Anthropic's Responsible Scaling Policy v3.3 documents the vendor's capability thresholds and safeguards, cited as third-party AI due diligence context for the apeiris://finance/controls/FG-08 FinanceAttestation Production control.", "reviewed_on": "2026-07-02" }, { "id": "openai_enterprise_data_governance_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "OpenAI's enterprise privacy and compliance documentation records vendor-side data handling and audit-log capabilities relevant to the apeiris://finance/controls/FG-08 FinanceAttestation Production control.", "reviewed_on": "2026-07-02" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://finance/controls/FG-08 FinanceAttestation Production control.", "reviewed_on": "2026-07-01" }, { "id": "aws_financial_services_compliance_2024", "title": "AWS User Guide to Financial Services Regulations & Guidelines in the United States", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/financial-services/security-compliance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_financial_services_compliance_2024", "relationship": "informative_reference", "rationale": "AWS's financial services regulatory guide and compliance tooling document infrastructure-layer capabilities relevant to the apeiris://finance/controls/FG-08 FinanceAttestation Production control.", "reviewed_on": "2026-07-02" }, { "id": "google_cloud_financial_services_ai_2024", "title": "Google Cloud Explainable AI", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/explainable-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_financial_services_ai_2024", "relationship": "informative_reference", "rationale": "Google Cloud's Explainable AI and Vertex AI model governance documentation describes platform capabilities relevant to the apeiris://finance/controls/FG-08 FinanceAttestation Production control.", "reviewed_on": "2026-07-02" }, { "id": "okta_financial_services_access_2025", "title": "Okta for Financial Services", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://www.okta.com/solutions/financial-services/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_financial_services_access_2025", "relationship": "informative_reference", "rationale": "Okta's identity products (System Log, access management, Adaptive MFA, Privileged Access) supply identity-layer enforcement and evidence relevant to the apeiris://finance/controls/FG-08 FinanceAttestation Production control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Produce FinanceAttestation as a signed JSON artifact aggregating layer-level evidence packages from MR, MV, FD, FC, FP, and FG with a composite verdict, Ed25519 signature, SHA-256 integrity hash, validity window, and publishing endpoint at the canonical attestation URI.", "steps": [ "Define the FinanceAttestation schema extending the base Apeiris evidence ontology with finance-specific fields: layer_coverage (array of six layer evidence references), composite_verdict, composite_confidence, financial_statement_scope, regulatory_frameworks_covered, and governance_certification_scope.", "Build an attestation assembly pipeline that collects the most recent validated evidence artifact from each of the six finance domain layers and verifies that each layer's evidence is within its defined validity window.", "Compute the composite verdict using the most conservative layer verdict: if any layer returns 'fail' the composite verdict is 'fail'; if any layer returns 'conditional' the composite is 'conditional'; all layers must return 'pass' for a 'pass' composite.", "Apply an Ed25519 signature using the finance governance signing key and compute a SHA-256 hash of the canonical JSON serialization, then publish the artifact to the attestation endpoint at apeiris://finance/controls/FG-08.", "Set the validity window to 90 days from issuance and configure automated re-issuance triggers when any constituent layer evidence expires, when a layer control status changes to 'fail', or when a material AI system change is registered." ], "financial_controller": { "summary": "The FinanceAttestation is the machine-readable equivalent of the SOX \u00a7302 certification for AI financial controls. The financial controller must understand its scope, confirm it covers all material AI systems, and reference it in management certifications.", "actions": [ "Confirm that the FinanceAttestation scope covers all AI systems that influence financial statements before each SOX \u00a7302 certification.", "Reference the current FinanceAttestation artifact identifier in management representation letters to external auditors.", "Treat a 'conditional' or 'fail' composite verdict in FinanceAttestation as a potential SOX \u00a7404 deficiency requiring assessment." ], "failure_signals": [ "FinanceAttestation composite verdict is 'fail' or 'conditional' and no SOX deficiency assessment has been initiated.", "FinanceAttestation scope does not cover all AI systems material to financial statement preparation.", "Management representation letter to external auditors does not reference the FinanceAttestation artifact." ] }, "model_risk_officer": { "summary": "The MRO is responsible for ensuring that model risk layer evidence (MR and MV layers) is current, validated, and available for FinanceAttestation assembly.", "actions": [ "Maintain the MR and MV layer evidence packages in a state ready for attestation assembly at all times.", "Trigger re-assessment of any MR or MV layer control when a material model change is registered that could affect layer evidence validity.", "Review FinanceAttestation composite results for model risk layer contributions and ensure any 'conditional' or 'fail' layer outcomes are escalated to the governance body." ], "failure_signals": [ "MR or MV layer evidence is expired at the time of FinanceAttestation assembly.", "A material model change did not trigger re-assessment of affected layer controls.", "Model risk layer 'fail' or 'conditional' verdict was not escalated within five business days of FinanceAttestation issuance." ] }, "compliance_officer": { "summary": "Compliance ensures that FinanceAttestation is produced at the required frequency, covers all applicable regulatory frameworks, and is available for regulatory examination.", "actions": [ "Confirm FinanceAttestation is produced at least quarterly and whenever a material governance change occurs.", "Map FinanceAttestation regulatory_frameworks_covered field against all applicable frameworks and identify any gaps.", "Maintain an attestation issuance log and ensure current and prior-period attestations are available for regulatory examination within 24 hours." ], "metrics": [ "FinanceAttestation issuance frequency: at least quarterly \u2014 target 100%.", "Attestation availability for examination: delivered within 24 hours \u2014 target 100%.", "Regulatory framework coverage: all applicable frameworks included \u2014 target 100%." ], "failure_signals": [ "FinanceAttestation has not been issued in the prior 90 days.", "Attestation cannot be produced for regulatory examination within 24 hours.", "Applicable regulatory frameworks are not reflected in the regulatory_frameworks_covered field." ] }, "internal_audit": { "summary": "Internal Audit independently validates the integrity of the FinanceAttestation production process \u2014 including evidence completeness, composite verdict logic, and cryptographic integrity \u2014 at least annually.", "actions": [ "Audit the FinanceAttestation assembly pipeline to confirm that all six layer evidence packages are required before issuance.", "Independently verify a sample of FinanceAttestation artifacts by re-computing the SHA-256 hash and confirming the Ed25519 signature against the published public key.", "Assess whether the composite verdict logic conservatively reflects the most restrictive layer verdict." ], "metrics": [ "FinanceAttestation integrity audit: conducted annually \u2014 target 100%.", "Artifact cryptographic integrity verification: sampled artifacts pass hash and signature checks \u2014 target 100%." ], "failure_signals": [ "FinanceAttestation was issued without evidence from one or more of the six finance domain layers.", "Cryptographic signature verification fails for any sampled attestation artifact.", "Composite verdict logic produced a 'pass' result despite a constituent layer returning 'fail' or 'conditional'." ] }, "it_operations": { "summary": "IT Operations runs the attestation production pipeline behind FinanceAttestation production and evidence aggregation \u2014 automating artifact collection from all six layers, signing, and publication, and keeping the pipeline itself auditable.", "actions": [ "Automate artifact aggregation from the MR/MV/FD/FC/FP evidence packages into the attestation build with source-hash verification.", "Protect signing keys and attestation publication with least-privilege access and dual control.", "Monitor attestation build health and alert when required artifacts are missing, stale, or fail integrity checks." ], "failure_signals": [ "Attestations produced with missing or stale layer artifacts.", "Signing operations performed outside the controlled pipeline.", "Attestation build failures unresolved past the publication SLA." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "FinanceAttestation production is a novel capability. Most enterprises have no machine-readable governance attestation for financial AI. Building the assembly pipeline and evidence aggregation infrastructure is the primary implementation challenge." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "federated-enterprise" ], "implementers": [ "Model Risk Officer", "Chief Financial Officer", "Chief Compliance Officer", "Internal Audit" ], "frameworks": [ { "framework": "sox", "requirement_id": "\u00a7302 & \u00a7404", "fit": "direct", "rationale": "SOX \u00a7302 and \u00a7404 require that management assess and certify the effectiveness of internal controls over financial reporting. FinanceAttestation is the machine-readable, cryptographically verifiable artifact that documents this certification for AI financial controls. A signed attestation with a defined scope and validity window provides a durable evidence record that supports both management certification and external audit.", "normative_force": "binding-law", "source_version": "2002", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "satisfies" }, { "framework": "pcaob_as_2201", "requirement_id": "\u00b6.68-.76", "fit": "direct", "rationale": "AS 2201 \u00b6.68-.76 address wrapping up the ICFR audit \u2014 forming an opinion, obtaining written representations, and communicating identified deficiencies. FinanceAttestation packages the management-side evidence those closing steps consume for AI-dependent controls; the fit is adjacent, since AS 2201 addresses the auditor's duties.", "normative_force": "certification-standard", "source_version": "2007", "reviewed_on": "2026-07-02", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "sr26_2", "requirement_id": "\u00a7VI (Documentation)", "fit": "direct", "rationale": "SR 26-2 \u00a7VI describes documentation demonstrating that model risk management activities \u2014 development, validation, governance \u2014 are operating. FinanceAttestation aggregates that documentation into a single verifiable artifact spanning all six layers of the finance domain.", "normative_force": "supervisory-guidance", "source_version": "2026-04-17", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "eu_ai_act", "requirement_id": "Art. 11", "fit": "direct", "rationale": "EU AI Act Art. 11 requires providers of high-risk AI to establish and maintain technical documentation demonstrating compliance with the AI Act requirements. FinanceAttestation, combined with its constituent layer evidence packages, constitutes the technical documentation artifact for financial AI governance compliance. The artifact's canonical URI and cryptographic signature support the auditability requirements.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "soc2", "requirement_id": "CC2.2", "fit": "partial", "rationale": "AICPA SOC 2 CC2.2 requires that entities communicate information internally including objectives and responsibilities for internal controls. FinanceAttestation is the machine-readable communication artifact that conveys control status across the organization and to relying parties. SOC 2 auditors examining financial data processing will consider the existence of a formal attestation artifact as evidence of structured internal communication.", "normative_force": "certification-standard", "source_version": "2022", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "coso_icfr", "requirement_id": "Principle 16", "fit": "adjacent", "rationale": "COSO Principle 16 requires ongoing monitoring of internal controls and communication of results. FinanceAttestation is the artifact that documents the outcome of this monitoring across all six finance domain control layers. The 90-day validity window and automated re-issuance triggers implement the ongoing monitoring requirement by ensuring the attestation reflects current control status.", "normative_force": "industry-framework", "source_version": "2013", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "informs" }, { "framework": "openai_enterprise", "requirement_id": "Enterprise Compliance API \u2014 audit logs", "fit": "partial", "rationale": "ChatGPT Enterprise and the OpenAI API expose workspace audit-log data through the Compliance API and audit logs endpoint, exportable to SIEM and evidence stores. Institutions using OpenAI models in financial workflows can incorporate this vendor capability into FinanceAttestation production and evidence aggregation. This is vendor capability documentation, not regulatory guidance; it covers the vendor side only.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "T2", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal T2 (Communication to stakeholders) requires communicating system capabilities and limitations to stakeholders. For institutions using Azure AI services, this goal produces vendor-side governance artifacts that align with FinanceAttestation production and evidence aggregation. The Standard is Microsoft's published internal policy offered as reference practice, not regulatory guidance.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_financial", "requirement_id": "AWS Artifact", "fit": "partial", "rationale": "AWS Artifact provides on-demand access to AWS's third-party compliance reports (SOC 1/2, PCI DSS, ISO). For AWS-hosted financial AI systems, this supplies the infrastructure-layer support and evidence stream for FinanceAttestation production and evidence aggregation. This is vendor documentation of real AWS capabilities \u2014 it does not substitute for model-layer validation or regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_financial", "requirement_id": "Google Cloud compliance offerings", "fit": "partial", "rationale": "Google Cloud's compliance offerings catalog documents the platform's third-party attestations (SOC 1/2/3, ISO/IEC 27001, PCI DSS) available to customers. For GCP-hosted financial AI systems, this capability supplies the platform-layer support for FinanceAttestation production and evidence aggregation. This is vendor product documentation, not regulatory guidance; it does not address model-layer regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "okta_financial", "requirement_id": "Okta System Log", "fit": "adjacent", "rationale": "The Okta System Log records authentication and access events with actor, target, outcome, and timestamp detail, exportable for audit retention. Where access to financial AI systems is brokered through Okta, this capability supplies the identity-layer enforcement and evidence for FinanceAttestation production and evidence aggregation. This is vendor product documentation, not a financial-services control framework.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://finance/controls/FG-08", "meta": { "authored_on": "2026-06-29", "schema_version": "1.1.0" }, "validation_objective": "A FinanceAttestation artifact exists, was issued within the prior 90 days, aggregates validated evidence from all six finance domain layers (MR, MV, FD, FC, FP, FG) with each layer's evidence confirmed within its defined validity window, bears a valid Ed25519 signature verifiable against the published finance governance signing public key, and reflects a composite verdict computed as the most conservative layer verdict. The artifact must be retrievable at the canonical attestation URI within 24 hours of request.", "evidence_required": [ "finance_attestation_artifact with evidence_id, composite_verdict, composite_confidence, layer_coverage array containing six entries each with layer_id, evidence_reference, validity_window, and individual_verdict, plus valid_from, valid_until, and integrity fields containing sha256_hash and ed25519_signature", "attestation_assembly_pipeline_log showing layer_evidence_collection_timestamps, validity_window_check results for each layer, composite_verdict_computation_trace, and signing_timestamp for the most recent issuance", "governance_signing_key_registry with key_id, public_key, key_creation_date, and key_custodian for the active finance domain signing key", "attestation_issuance_log with artifact_id, issuance_timestamp, validity_window_start, validity_window_end, and trigger_type (scheduled/layer_expiry/material_change) for the past two issuance cycles", "layer_evidence_currency_snapshot confirming all six layer evidence packages were within their defined validity windows at the moment of attestation assembly" ], "machine_tests": [ "Retrieve the most recent FinanceAttestation artifact from the canonical URI apeiris://finance/controls/FG-08 \u2192 assert valid_until is a future timestamp and valid_from is within the prior 90 days", "Verify Ed25519 signature on the retrieved artifact using the published finance governance signing public key and recompute SHA-256 hash over canonical JSON serialization \u2192 assert both signature validation and hash comparison return true", "Inspect layer_coverage array in the retrieved artifact \u2192 assert exactly six entries are present with layer_ids MR, MV, FD, FC, FP, FG each having a non-null evidence_reference and a non-null individual_verdict", "Simulate a layer control status change to 'fail' in the attestation assembly pipeline test environment \u2192 assert the composite_verdict in the produced artifact resolves to 'fail' regardless of all other layer verdicts" ], "human_review": [ "Review the attestation assembly pipeline implementation to confirm that all six layer evidence packages are mandatory inputs and that the pipeline raises a blocking error and does not produce an artifact when any layer evidence is expired, missing, or fails validity window checks", "Assess the composite verdict computation logic to verify it conservatively applies the most restrictive layer verdict and that no conditional override, weighting, or averaging logic could produce a 'pass' composite while any constituent layer is in 'conditional' or 'fail' status", "Evaluate the FinanceAttestation scope definition against the complete current inventory of AI systems influencing financial statements, verify the regulatory_frameworks_covered field reflects all applicable regulatory frameworks, and confirm the governance signing key registry is current and the custodian is actively maintained" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Producing FinanceAttestation artifacts from stale layer evidence that is nominally within a validity window but was assessed before material model changes were made, creating a signed attestation that no longer accurately reflects the current governance posture", "Computing composite verdict as a weighted average or majority verdict across layers rather than as the most conservative layer verdict, enabling a 'pass' composite to be issued while a constituent layer is in 'fail' or 'conditional' status", "Issuing FinanceAttestation by substituting a placeholder, waiver, or exception notation for any of the six required layer evidence packages when evidence collection is incomplete, producing a partial attestation that misrepresents coverage", "Maintaining the Ed25519 signing key without a key registry or custody log, preventing auditors from tracing which key signed historical attestation artifacts and confirming that key rotation events are accounted for", "Treating FinanceAttestation as an annual compliance document rather than a 90-day validity artifact with automated re-issuance triggers, resulting in a stale attestation that does not reflect governance status changes from material model changes or layer control failures between annual issuance cycles" ], "update_status": "current", "cross_domain": { "feeds": [ "apeiris://compliance/controls/AU-08" ] }, "layer_code": "FG" } ] } }