AI Policy and Guidance Template for Finance

Start here: existing financial law and regulation still apply

Purpose

This section defines the organization’s approach to start here: existing financial law and regulation still apply and the controls needed to put that approach into practice.

Implementation considerations

• Maintain an applicability matrix by legal entity, financial activity, product, jurisdiction, charter and regulator.
• Record the source, interpretation owner and approval for each requirement applied to an AI use case.
• Reassess the matrix when the activity, customer, data, provider, jurisdiction or regulatory guidance changes.

Common pitfalls

• Copying another institution’s controls without confirming that its activities and regulators match.
• Treating a voluntary framework or vendor statement as a substitute for binding law or supervisory expectations.
• Failing to track effective dates, jurisdictional differences or conflicts among applicable requirements.

Stakeholders to involve

Legal, compliance, regulatory affairs, the affected business line, enterprise risk and internal audit.

Purpose and scope

Purpose

This section defines the organization’s approach to purpose and scope and the controls needed to put that approach into practice.

Implementation considerations

• Map the people, legal entities, business processes, systems, vendors and jurisdictions covered by the policy.
• State explicit inclusions and exclusions for employees, contractors, third parties, embedded features and agentic systems.
• Align the scope with acceptable-use, data, security, procurement, records and disciplinary policies.

Common pitfalls

• Limiting scope to generative AI while omitting predictive models, vendor features or automated agents.
• Using broad terms such as “finance use” without naming the covered activities and legal entities.
• Extending requirements to third parties without corresponding contract, access and enforcement mechanisms.

Stakeholders to involve

Policy owner, finance leadership, business-line owners, human resources, procurement, IT, legal and compliance.

What this template is and is not

Purpose

This section defines the organization’s approach to what this template is and is not and the controls needed to put that approach into practice.

Implementation considerations

• Perform a documented gap assessment between this template and the organization’s actual obligations and controls.
• Mark provisions as adopted, modified or not applicable and record the rationale for each material decision.
• Version and approve the adapted policy through the organization’s legal, compliance and governance process.

Common pitfalls

• Adopting the template verbatim without testing it against actual products, data, systems and regulators.
• Presenting use of the template as legal advice, regulator approval or evidence of compliance.
• Leaving placeholders, sample language or conflicting provisions in the approved policy.

Stakeholders to involve

Policy owner, legal, compliance, enterprise risk, internal audit and the qualified professionals responsible for the covered activities.

Definitions and AI inventory

Purpose

This section defines the organization’s approach to definitions and ai inventory and the controls needed to put that approach into practice.

Implementation considerations

• Assign each AI system a unique record with its owner, provider, purpose, users, data, integrations and risk tier.
• Use procurement, software discovery, architecture reviews and business attestations to identify embedded and unapproved AI.
• Track approval, testing, monitoring, incidents, material changes, suspension and retirement in the inventory.

Common pitfalls

• Inventorying only internally developed models and overlooking SaaS features, copilots and vendor updates.
• Recording a tool name without its version, integrations, data flows, owner or approved purpose.
• Maintaining a static spreadsheet that is not reconciled with procurement, access or technology records.

Stakeholders to involve

Business owners, enterprise architecture, IT asset management, procurement, information security, privacy, data governance and model risk.

Foundational principles

Purpose

This section defines the organization’s approach to foundational principles and the controls needed to put that approach into practice.

Implementation considerations

• Translate each principle into an enforceable control, named owner, evidence requirement and measurable review criterion.
• Define what fairness, transparency, accessibility and meaningful oversight require for each material use case.
• Establish how conflicts among legal, ethical, customer and business considerations will be escalated and resolved.

Common pitfalls

• Publishing aspirational principles without operational requirements or evidence of compliance.
• Applying one abstract fairness or transparency standard to every product, audience and decision.
• Using a general principle to override a specific legal, contractual or professional obligation.

Stakeholders to involve

Executive sponsor, legal, compliance, privacy, accessibility, enterprise risk, ethics or conduct leadership and affected business owners.

Governance, roles and accountability

Purpose

This section defines the organization’s approach to governance, roles and accountability and the controls needed to put that approach into practice.

Implementation considerations

• Document decision rights and a RACI for approval, validation, monitoring, incident response, suspension and retirement.
• Set committee quorum, escalation paths, reporting cadence and thresholds for executive or board attention.
• Preserve appropriate independence among business ownership, risk oversight, validation and internal audit.

Common pitfalls

• Assuming a governance committee owns business outcomes that remain the business owner’s responsibility.
• Allowing the same person to develop, approve and independently validate a high-impact system.
• Assigning internal audit responsibility for designing or operating controls it may later assess.

Stakeholders to involve

Executive sponsor, AI governance committee, business owners, legal, compliance, privacy, information security, model risk or validation and internal audit.

Risk classification and approval

Purpose

This section defines the organization’s approach to risk classification and approval and the controls needed to put that approach into practice.

Implementation considerations

• Define risk-tier criteria using decision impact, customer effect, financial materiality, data sensitivity, autonomy and reversibility.
• Specify the evidence, reviewers, testing and approval authority required for each tier.
• Reclassify and reapprove a use after material changes to purpose, data, model, provider, integration or operating context.

Common pitfalls

• Accepting the vendor’s product category or risk label without an organization-specific assessment.
• Classifying a high-impact use as low risk because a person appears somewhere in the workflow.
• Treating approval as permanent despite drift, incidents or material system changes.

Stakeholders to involve

Business owner, enterprise risk, compliance, legal, privacy, information security, model risk or validation and the designated approval authority.

Acceptable and prohibited use

Purpose

This section defines the organization’s approach to acceptable and prohibited use and the controls needed to put that approach into practice.

Implementation considerations

• Publish an approved-use catalog that identifies permitted tools, data categories, purposes and required human review.
• Use access, network, data-loss-prevention and procurement controls to restrict unapproved tools and prohibited actions.
• Provide a practical exception and escalation path for uses that do not fit the catalog.

Common pitfalls

• Writing vague prohibitions that employees cannot translate into day-to-day decisions.
• Allowing assistive use without applying the same data, records and review requirements to the resulting output.
• Omitting embedded AI and agentic features from tool restrictions and approval workflows.

Stakeholders to involve

Business operations, IT, information security, data governance, compliance, legal, human resources and internal audit.

Privacy, confidentiality and data governance

Purpose

This section defines the organization’s approach to privacy, confidentiality and data governance and the controls needed to put that approach into practice.

Implementation considerations

• Map restricted data categories to approved tools, purposes, environments, access levels and geographic locations.
• Document minimization, retention, deletion, logging, training-use and cross-border requirements before deployment.
• Test that prompts, outputs, logs, support records and vendor telemetry follow the approved data rules.

Common pitfalls

• Entering nonpublic personal, account, tax, payroll or confidential financial information into an unapproved service.
• Assuming a provider will not retain or train on data without verifying configuration and contract terms.
• Protecting prompts while overlooking sensitive information reproduced in outputs, logs or integrations.

Stakeholders to involve

Privacy, data governance, information security, legal, records management, system owners and the owners of each restricted data category.

Cybersecurity, identity and AI-enabled fraud

Purpose

This section defines the organization’s approach to cybersecurity, identity and ai-enabled fraud and the controls needed to put that approach into practice.

Implementation considerations

• Threat-model the model, application, plugins, agents, data stores, identities and external integrations before approval.
• Apply least privilege, multifactor authentication, secrets management, logging, content controls and tested stop mechanisms.
• Use trusted-channel verification and exercises for deepfake, impersonation, account-change and payment-fraud scenarios.

Common pitfalls

• Testing model accuracy while ignoring prompt injection, malicious files, insecure plugins and supply-chain compromise.
• Giving an AI agent broader access or transaction authority than the employee or service account requires.
• Treating voice, video, email or chat as sufficient verification for a sensitive request.

Stakeholders to involve

Information security, identity and access management, fraud, treasury, incident response, application owners and critical vendors.

Model and AI lifecycle governance

Purpose

This section defines the organization’s approach to model and ai lifecycle governance and the controls needed to put that approach into practice.

Implementation considerations

• Determine and document whether each model falls within applicable model-risk requirements, including the scope of SR 26-2.
• Maintain design, data-lineage, validation, limitation, monitoring, change and retirement records against an approved baseline.
• Apply separate risk-appropriate controls to generative and agentic systems that SR 26-2 places outside its scope.

Common pitfalls

• Citing SR 26-2 as if it directly governs every generative or agentic AI system.
• Skipping independent assessment because a model or service was supplied by a third party.
• Changing prompts, retrieval data, integrations or providers without assessing whether revalidation is required.

Stakeholders to involve

Model owner, model risk management or independent validation, data science, IT, compliance, enterprise risk and internal audit.

Explainability, traceability and records

Purpose

This section defines the organization’s approach to explainability, traceability and records and the controls needed to put that approach into practice.

Implementation considerations

• Record the system and version, approved purpose, material inputs, source data, output, reviewer and decision rationale.
• Map AI records to applicable retention, legal-hold, supervision, audit and customer-explanation requirements.
• Test explanations with the intended audience and confirm that they accurately reflect the factors actually used.

Common pitfalls

• Saving an output without the source, configuration, model version or human review needed to reconstruct it.
• Providing a generic explanation that does not match the actual basis for a material decision.
• Deleting prompts, logs or review evidence before applicable recordkeeping obligations expire.

Stakeholders to involve

Records management, legal, compliance, business owners, model risk or validation, data governance and internal audit.

Consumer finance, lending and credit

Purpose

This section defines the organization’s approach to consumer finance, lending and credit and the controls needed to put that approach into practice.

Implementation considerations

• Confirm that adverse-action reasons are specific, accurate and tied to the factors actually used in the decision.
• Monitor inputs, proxies, outcomes, overrides, complaints and disparate effects at meaningful segment levels.
• Provide documented review, notice, dispute, correction and escalation procedures for affected consumers.

Common pitfalls

• Allowing a language model to invent, simplify or substitute an adverse-action reason.
• Relying on aggregate performance that conceals errors or unequal effects in particular groups or products.
• Using human overrides as evidence of oversight without reviewing their consistency, rationale and outcomes.

Stakeholders to involve

Credit risk, fair-lending and consumer compliance, servicing, legal, model risk or validation, data governance and complaint management.

Securities, investments and regulated communications

Purpose

This section defines the organization’s approach to securities, investments and regulated communications and the controls needed to put that approach into practice.

Implementation considerations

• Map each use to applicable supervision, communications, records, fiduciary, conflict, suitability or best-interest requirements.
• Require review and approval of public, customer and investor communications, including claims about AI capabilities.
• Log source material, reviewer actions, conflicts, corrections and required books-and-records evidence.

Common pitfalls

• Making vague or unsupported “AI-powered” claims that create AI-washing risk.
• Using generated research or recommendations without validating sources, balance, conflicts and required disclosures.
• Treating an AI chat, summary or personalized message as outside communications and recordkeeping controls.

Stakeholders to involve

Chief compliance officer, legal, supervisory principals, investment or brokerage leadership, records management, marketing and communications reviewers.

Accounting, financial reporting, audit and tax

Purpose

This section defines the organization’s approach to accounting, financial reporting, audit and tax and the controls needed to put that approach into practice.

Implementation considerations

• Restrict research to approved authoritative literature and trace each conclusion, figure and calculation to its source.
• Reconcile AI-assisted work to systems of record and retain evidence of calculation, review, correction and approval.
• Require qualified sign-off before journal entries, reports, tax positions, filings or audit conclusions are released.

Common pitfalls

• Accepting fabricated or outdated accounting, audit or tax citations because the output appears plausible.
• Allowing AI to prepare and post an entry without segregation of duties and supporting evidence.
• Treating an AI summary as a substitute for professional judgment or sufficient appropriate audit evidence.

Stakeholders to involve

Controller, chief financial officer, accounting policy, tax, financial reporting, internal and external audit, compliance and finance systems owners.

Payments, treasury and transaction authorization

Purpose

This section defines the organization’s approach to payments, treasury and transaction authorization and the controls needed to put that approach into practice.

Implementation considerations

• Keep payment initiation, approval and release in separate authorized roles, with enforced limits and audit logs.
• Verify new or changed payee and account instructions through an established out-of-band channel.
• Test sanctions, fraud, exception and PCI DSS controls across every AI-enabled payment or card-data integration.

Common pitfalls

• Giving an AI agent permission to create and release the same transaction.
• Trusting urgent email, voice or video instructions without independent callback or account verification.
• Sending payment-card data through an AI service or integration not approved for the card-data environment.

Stakeholders to involve

Treasury, accounts payable, payment operations, fraud, information security, sanctions or compliance, card-data owners and internal audit.

Customer-facing AI and marketing

Purpose

This section defines the organization’s approach to customer-facing ai and marketing and the controls needed to put that approach into practice.

Implementation considerations

• Limit responses to approved product information, disclosures and knowledge sources with a clear human-escalation route.
• Test rates, terms, product claims, edge cases, consistency, fairness and accessibility before and after launch.
• Monitor complaints, corrections, escalations and confidential-data exposure by channel and use case.

Common pitfalls

• Allowing a customer-facing system to invent rates, returns, eligibility, commitments or product capabilities.
• Hiding the nature of an AI interaction or making it difficult for a customer to reach a person.
• Using customer conversations for training or evaluation without approved notice, authority and data controls.

Stakeholders to involve

Customer service, product owners, marketing, legal, compliance, privacy, accessibility and information security.

Third-party, cloud and embedded AI

Purpose

This section defines the organization’s approach to third-party, cloud and embedded ai and the controls needed to put that approach into practice.

Implementation considerations

• Complete risk-based due diligence and contract review before procurement, activation or a material provider change.
• Inventory embedded AI features and require approval before enabling new models, copilots, agents or data connections.
• Test incident notification, regulatory access, business continuity, data return or deletion and exit procedures.

Common pitfalls

• Enabling a bundled AI feature through a click-through update without governance review.
• Accepting provider terms that conflict with approved retention, training-use, audit or incident requirements.
• Assuming outsourcing transfers accountability for customer, regulatory, security or model outcomes.

Stakeholders to involve

Procurement, third-party risk, legal, compliance, privacy, information security, enterprise architecture, business continuity and the business owner.

Human oversight and high-impact decisions

Purpose

This section defines the organization’s approach to human oversight and high-impact decisions and the controls needed to put that approach into practice.

Implementation considerations

• Name a qualified reviewer with sufficient information, time, authority and independence to challenge or stop the outcome.
• Define review evidence, confidence, exception, sampling, override and escalation thresholds for each high-impact use.
• Record what the reviewer examined, the rationale for the final decision and any correction or override.

Common pitfalls

• Using a required approval click as evidence of meaningful review.
• Assigning review to a person who lacks the subject-matter knowledge or authority to reject the output.
• Treating a confidence score as a substitute for evidence, professional judgment or investigation.

Stakeholders to involve

The accountable decision owner, qualified reviewers, legal, compliance, model risk or validation and the relevant credit, investment, payment, accounting or customer function.

Testing, validation and monitoring

Purpose

This section defines the organization’s approach to testing, validation and monitoring and the controls needed to put that approach into practice.

Implementation considerations

• Approve a baseline, representative test set, metric definitions and thresholds before production use.
• Test normal, edge, adversarial and changed conditions for accuracy, stability, fairness, security, privacy and explainability as relevant.
• Monitor drift, errors, overrides, complaints, incidents and business impact with defined suspension and revalidation triggers.

Common pitfalls

• Treating a vendor demonstration or one-time pilot as production validation.
• Measuring average accuracy while ignoring false positives, false negatives, subgroup effects or material outliers.
• Continuing use after a material model, prompt, data, integration or provider change without required retesting.

Stakeholders to involve

Independent validation or quality assurance, business owners, data science, information security, privacy, compliance, legal and operations monitoring.

Training and AI literacy

Purpose

This section defines the organization’s approach to training and ai literacy and the controls needed to put that approach into practice.

Implementation considerations

• Map training requirements to specific roles, tools, data access, review duties and incident responsibilities.
• Require training before access, at defined intervals and after material policy, tool or risk changes.
• Use practical exercises or knowledge checks and retain completion and remediation records.

Common pitfalls

• Providing one general awareness course to users, developers, validators and high-impact decision-makers.
• Teaching generic AI concepts without the organization’s actual tools, restricted data and escalation procedures.
• Excluding contractors, temporary staff or vendor personnel who can access covered systems or data.

Stakeholders to involve

Learning and development, human resources, policy owner, business managers, compliance, privacy, information security and system owners.

Incident response and escalation

Purpose

This section defines the organization’s approach to incident response and escalation and the controls needed to put that approach into practice.

Implementation considerations

• Define AI incident categories, severity levels, reporting channels, decision authority and notification timelines.
• Provide tested procedures to disable access, contain harm, preserve evidence and identify affected systems, data and people.
• Assess legal, regulatory, contractual and customer notices and require remediation and reapproval before restoration.

Common pitfalls

• Routing an AI incident through an ordinary IT ticket without fraud, privacy, legal or compliance assessment.
• Deleting prompts, outputs, logs or model evidence during containment.
• Restoring the system without addressing root cause, affected decisions and required retesting.

Stakeholders to involve

Incident response, information security, privacy, legal, compliance, fraud, communications, business owners and records management.

Exceptions, enforcement and non-retaliation

Purpose

This section defines the organization’s approach to exceptions, enforcement and non-retaliation and the controls needed to put that approach into practice.

Implementation considerations

• Require each exception to state the business need, scope, risk, compensating controls, approver, owner and expiration date.
• Use an approval authority independent enough to challenge the request and prohibit self-approval.
• Maintain an exception register and review recurring requests, overdue remediation and concentration of risk.

Common pitfalls

• Allowing temporary exceptions to become permanent through automatic renewal or missing expiration dates.
• Accepting an exception without testing whether its compensating controls actually reduce the stated risk.
• Discouraging good-faith reporting or retaliating against personnel who raise an AI concern.

Stakeholders to involve

Policy owner, enterprise risk, compliance, legal, human resources or employee relations, the affected business owner and internal audit.

Review and continuous improvement

Purpose

This section defines the organization’s approach to review and continuous improvement and the controls needed to put that approach into practice.

Implementation considerations

• Set an annual review calendar plus event-driven reviews for incidents, regulatory changes, new high-impact uses and material vendor changes.
• Provide leadership with inventory, testing, drift, override, complaint, incident, exception and remediation metrics.
• Version the policy, record approval and communicate resulting changes to training, contracts, systems and procedures.

Common pitfalls

• Completing a date-only annual review without assessing evidence, incidents, control performance or changed activities.
• Leaving regulatory sources, risk thresholds or vendor assumptions unchanged after the underlying facts change.
• Approving a revised policy without updating dependent controls, training, contracts and operating procedures.

Stakeholders to involve

Policy owner, AI governance committee, legal and regulatory change management, compliance, enterprise risk, internal audit, business leaders and training owners.