Gana Misra
By Gana Misra•CEO, Finrep
Fri Sep 25 2026

AI Vendor Due Diligence for Finance: A 2026 Practitioner Walkthrough

Share
AI Vendor Due Diligence for Finance: A 2026 Practitioner Walkthrough

AI Vendor Due Diligence for Finance: A 2026 Practitioner Walkthrough

Most AI vendor due diligence checklists were written for IT procurement teams. They ask about SOC 2 certificates, encryption standards, and uptime SLAs. For a general enterprise buyer, that might be enough. For a CFO, ESG lead, or compliance officer deploying AI in regulated financial workflows, it is nowhere near sufficient.

This guide covers what your IT team's checklist misses: the five risk domains that are uniquely material when AI touches financial reporting, audit support, ESG data, or regulatory compliance. Every section maps to a specific regulatory obligation, names the questions to ask, and flags the contractual traps to avoid before you sign.

Key takeaway: PwC's 2025 AI in Financial Services survey found that 73% of financial services executives call AI risk management a top priority, but only 35% have a formal AI vendor governance framework in place. The gap between intent and infrastructure is where regulatory exposure lives.

Why Standard Vendor Review Fails for Finance AI

The core problem is that financial firms cannot outsource their regulatory obligations to a vendor. The OCC's SR 11-7 model risk management guidance, jointly issued with the Federal Reserve in 2011 and still the primary US standard, is explicit: model risk management obligations cannot be outsourced. A bank remains responsible for any model used in material decisions, whether built internally or purchased from a vendor. Regulators have confirmed that AI and machine learning models fall squarely within SR 11-7's scope.

The 2023 interagency joint statement from the Federal Reserve, OCC, FDIC, NCUA, and CFPB reinforced this: model risk management, fair lending, consumer protection, and third-party risk management obligations all apply to AI systems regardless of whether they are built in-house or procured from a vendor.

The OCC Bulletin 2023-17 updated third-party risk management expectations, requiring due diligence proportionate to the risk of the relationship. AI tools used in material financial decisions sit at the high end of that risk spectrum and require correspondingly rigorous assessment.

For UK firms, the Bank of England PRA's Supervisory Statement SS1/23 on model risk management is equally direct: firms must have sufficient understanding of vendor models to challenge their outputs. A 'black box' AI tool is not acceptable for material decisions.

Deloitte's 2025 Global Risk Management Survey found that third-party AI risk ranked among the top five emerging risks for financial institutions, and that most existing third-party risk management frameworks were not designed to assess AI-specific risks such as model drift, hallucination, data poisoning, and algorithmic bias.

Step 1: Risk-Tier the AI Tool Before You Start

Not every AI tool requires the same depth of review. Start by classifying the use case, then calibrate the due diligence accordingly. This mirrors the proportionality principle in OCC Bulletin 2023-17 and the risk-tiering logic of the NIST AI Risk Management Framework (AI RMF 1.0), which structures AI governance around four functions: GOVERN, MAP, MEASURE, and MANAGE.

Risk TierExample Finance Use CasesRegulatory TriggersDue Diligence Depth
HighCredit decisioning, AML/compliance screening, CSRD/ESRS reporting, SOX-controlled process automationEU AI Act high-risk classification, SR 11-7, OCC 2023-17, ESRS methodology disclosureFull five-domain review, model validation, contractual AI addendum
MediumFinancial commentary drafting, earnings call summarisation, vendor invoice processingSEC AI disclosure expectations, SOX change managementCore domains: data governance, auditability, commercial risk
LowInternal knowledge search, meeting transcription, non-public research summarisationGeneral TPRM, data securityStandard IT vendor review plus AI-specific data use questions

The EU AI Act, which entered into force in August 2024 with phased application through 2026-2027, classifies AI used in creditworthiness assessment, insurance risk pricing, and certain AML/compliance applications as 'high-risk.' Critically, financial firms that purchase and deploy these tools are classified as deployers, not passive customers. Deployers bear independent obligations: conducting fundamental rights impact assessments, maintaining logs, ensuring human oversight, and registering systems in the EU AI database. Vendor compliance claims do not discharge your firm's obligations. For a full breakdown of what the EU AI Act requires from finance teams, see EU AI Act Finance and Accounting Compliance 2026.

For ESG-specific tools: EFRAG's ESRS under CSRD require disclosure of the methodologies, assumptions, and data sources underlying sustainability metrics. Where AI calculates or aggregates ESG data, companies must be able to explain and audit those outputs. The ISSB's IFRS S1 and S2 create a parallel obligation: methodology disclosure for sustainability-related risks effectively requires you to understand how your AI vendor's system works.

Step 2: Assess Model Risk and Explainability

The first question for any high-tier AI tool is whether you can defend its outputs to an auditor or regulator. SR 11-7 requires model validation, documentation, and ongoing governance. If you cannot explain how the model reaches a conclusion, you cannot satisfy that standard.

Ask the vendor for a model card: standardised documentation covering the model's intended use, performance characteristics, known limitations, and training data. McKinsey's 2025 analysis of AI in financial services recommends model cards as a baseline due diligence requirement, noting that while AI-driven pattern recognition can reduce credit losses by 20-40%, the same opacity that enables this performance creates model validation challenges for regulated institutions.

Key questions to put to the vendor:

  • What model architecture underlies this product, and is it a proprietary model or a third-party foundation model (e.g., an OpenAI or Anthropic API)?
  • Can you provide documentation of model validation, including out-of-sample performance testing and bias assessments?
  • How does the system handle inputs outside its training distribution, and does it signal uncertainty or low-confidence outputs?
  • Has the model been tested for algorithmic bias relevant to our use case? The CFPB and DOJ have flagged algorithmic bias as a specific concern for AI used in credit, underwriting, or customer-facing financial decisions.
  • What is the process for human override of AI outputs, and is that override logged?

The European Banking Authority's internal governance guidelines require institutions to ensure explainability, auditability, and human oversight of AI systems used in material decisions. 'The model said so' is not a defensible answer to a supervisor.

Step 3: Scrutinise Data Governance and Sovereignty

Where does your financial and ESG data go, and who owns it? This is the question most procurement reviews treat as a checkbox. For regulated financial firms, it is a material risk with direct regulatory consequences.

The standard vendor claim, 'we don't train on customer data,' almost always means something narrower than it sounds. The real question is what happens to your data in production, in logs, in fine-tuning pipelines, and in feedback loops. Get specific contractual answers to each of these:

  • Is data processed in your VPC, on-prem, a managed cloud environment, or the vendor's shared hosted stack?
  • Are prompts, retrieved documents, and outputs logged? For how long, and in what jurisdiction?
  • Can the vendor use your data for model improvement, fine-tuning, or evaluation, even in anonymised or aggregated form?
  • Where are the vendor's subprocessors located, and do any of them touch your data?
  • For EU-based firms: does data processing occur outside the EEA, and if so, what transfer mechanism applies under GDPR?

Data residency matters beyond GDPR. ESG data fed into AI tools may be processed in jurisdictions that create data sovereignty issues for firms subject to sector-specific localisation requirements. Map the full data flow before signing.

On deletion: confirm in writing that your data will be deleted within a defined period on contract termination, that deletion covers all copies including logs and fine-tuning datasets, and that the vendor can provide deletion verification. EY's 2025 analysis of AI vendor contracts found that most standard agreements lack adequate provisions for data deletion on termination.

Step 4: Verify Auditability for SOX, CSRD, and SEC Examination

An AI tool that cannot produce a sufficient audit trail is not deployable in a regulated financial workflow, regardless of how well it performs. This is the gap that generic checklists consistently miss.

For SOX-controlled processes, your external auditor will ask whether the AI system has adequate input validation, output review, and change management controls. The AICPA's 2025 guidance on AI in audit and assurance confirms that auditors are increasingly requesting documentation of AI vendor due diligence as part of FY2025 and FY2026 engagements. Audit committees should expect these requests.

For CSRD/ESRS reporting, EFRAG requires that the methodologies and data sources underlying sustainability metrics be explainable and auditable. An AI tool that aggregates Scope 3 emissions data or calculates ESRS datapoints must produce traceable outputs, not just a number.

Ask the vendor to demonstrate:

  • Log completeness: Are prompts, retrieved sources, tool calls, and outputs all logged? Are admin actions and configuration changes captured?
  • Log retention: What is the retention period, and can it be extended to match your audit cycle (typically seven years for SOX documentation)?
  • Export format: Can logs be exported in a format usable by your external auditors and regulators? Proprietary log formats that require vendor assistance to read are a red flag.
  • Sensitive data masking: Can PII or MNPI be redacted from logs without destroying the audit trail?
  • Change management: Is there a versioned record of model updates, prompt changes, and configuration changes, with timestamps and responsible parties?

For a deeper treatment of what audit trail requirements look like for SEC filers specifically, see AI Audit Trail Requirements for SEC Filers.

The model change notification problem deserves specific attention. Most AI vendor contracts allow the vendor to update, retrain, or replace the underlying model without notice. For a regulated financial institution, an undisclosed model change can invalidate prior model validation work, produce unexplained changes in outputs, and trigger regulatory notification obligations. Legal experts at Clifford Chance have flagged this as a critical contractual risk for financial services firms. Negotiate for explicit model change notification rights, with a defined notice period before any material model update takes effect.

Step 5: Evaluate Commercial and Exit Risk

The hidden costs of AI vendor relationships in finance are not in the headline price. They are in the pricing model, the lock-in architecture, and the exit terms. As Data-Pilot.com's 2026 checklist puts it: 'Buying an AI tool or service is easy. Living with it is the hard part.'

Pricing transparency

AI pricing models are structurally opaque. Per-token, per-call, per-context-window, and per-retrieval charges can compound in ways that make total cost of ownership difficult to forecast. Push for:

  • A breakdown of every cost driver: tokens, context length, retrieval calls, fine-tuning, evaluations, logging
  • Visibility into cost by use case, team, or workflow
  • Confirmation of what happens during usage spikes: throttling, rate limits, or surge pricing
  • Minimum commit terms, overage mechanics, and year-two renewal pricing

Lock-in risk

Lock-in in AI is often a technical problem, not just a contractual one. Once your prompts, connectors, evaluation harnesses, and vector stores live inside one platform, migration becomes a multi-quarter project. Ask what is proprietary and non-portable:

  • Agent logic, orchestration, and workflow builders
  • Vector stores and embedding formats
  • Prompt management and evaluation tooling

Then ask for exit terms in writing: export format, timelines, deletion proof, and what support is included during transition.

Vendor financial stability and concentration risk

For AI tools embedded in critical financial reporting workflows, vendor insolvency or discontinuation is a material operational risk. Assess the vendor's financial condition, funding runway, and customer concentration. For early-stage AI vendors, consider escrow arrangements for model weights or source code.

At the portfolio level, the FSB's 2023 report on AI in financial services identified a systemic concern: a small number of AI infrastructure providers serve the majority of financial institutions globally, creating correlated operational risk across the financial system. If your firm relies on multiple AI tools that all sit on the same underlying LLM infrastructure, a single provider outage or policy change affects all of them simultaneously. Map your AI supply chain for concentration risk and bring the finding to your board risk committee.

KPMG's 2026 AI Governance report notes that regulators globally are moving toward requiring financial institutions to maintain an 'AI inventory': a register of all AI systems in use, including vendor-supplied tools, with documentation of their purpose, risk classification, validation status, and oversight arrangements. Building this inventory is no longer optional.

Step 6: Document the Process and Build Ongoing Monitoring

Due diligence that is not documented did not happen, from a regulator's perspective. Structure your documentation so it can be presented to internal audit, external auditors, and regulators without reconstruction.

For each high-tier AI vendor, maintain a file that includes:

  1. The risk classification rationale (why this tool is high/medium/low risk)
  2. Responses to all due diligence questions, with vendor attestations where relevant
  3. The model card or equivalent validation documentation
  4. Data flow mapping, including subprocessors and jurisdictions
  5. Contractual protections negotiated (model change notification, data deletion, audit rights, exit terms)
  6. Approval sign-off from the relevant risk owner (CRO, CFO, or compliance officer)
  7. Scheduled review date

Point-in-time assessments are not sufficient for AI vendors. As third-party risk management literature notes, 'the next day, even a small environmental change may render the audit obsolete.' Build continuous monitoring into your vendor management programme: track vendor news, regulatory actions, financial condition changes, and model update notifications on an ongoing basis. Annual reviews should be the floor, not the ceiling, for high-tier AI tools.

For the governance policy that sits above individual vendor reviews, see AI Agent Governance Policy for Finance: 2026 Practitioner Walkthrough. For model risk management at the programme level, see AI Model Risk Management in Finance: The 2026 Practitioner's Framework.

AI Vendor Due Diligence: Finance-Specific Checklist

Use this as a gate before any high-tier AI vendor approval.

Model risk and explainability

  • Model card or equivalent documentation received and reviewed
  • Model validation evidence (performance testing, bias assessment) obtained
  • Human override mechanism confirmed and logged
  • Algorithmic bias testing relevant to use case documented
  • Model change notification rights negotiated in contract

Data governance and sovereignty

  • Full data flow mapped, including subprocessors and jurisdictions
  • Training/fine-tuning data use confirmed in writing (opt-out or prohibition)
  • GDPR transfer mechanism confirmed for EU data
  • Data deletion on termination confirmed, with verification mechanism
  • Log retention period confirmed and matched to audit requirements

Regulatory alignment

  • EU AI Act risk classification determined (high-risk vs. limited-risk)
  • Deployer obligations under EU AI Act assigned to named internal owner
  • SR 11-7 model validation scope confirmed with model risk team
  • OCC Bulletin 2023-17 proportionality assessment completed
  • SEC AI disclosure obligations reviewed for reporting-adjacent tools

Auditability

  • Log completeness verified (prompts, outputs, tool calls, admin actions)
  • Log export format confirmed as auditor-readable
  • Change management versioning confirmed
  • AICPA audit readiness documentation prepared

Commercial and exit risk

  • Full cost model documented (all pricing drivers)
  • Portability of prompts, embeddings, and evaluation sets confirmed
  • Exit terms in writing (export format, timeline, deletion proof)
  • Vendor financial stability assessed
  • AI supply chain concentration risk mapped

FAQ

Does SR 11-7 apply to AI tools we buy from a vendor, not build ourselves? Yes. The OCC has confirmed that SR 11-7 applies to all models used in material decisions at regulated institutions, regardless of whether they are built internally or procured from a vendor. The institution remains responsible for model validation, documentation, and ongoing governance even when the model is vendor-supplied.

What does the EU AI Act require from financial firms that buy AI tools? Financial firms that purchase and deploy AI tools are classified as 'deployers' under the EU AI Act. For high-risk AI systems (which include AI used in creditworthiness assessment and certain compliance applications), deployers must conduct fundamental rights impact assessments, maintain logs, ensure human oversight, and register systems in the EU AI database. Vendor compliance claims do not discharge these obligations.

What contractual protections should we require from AI vendors in finance? At minimum: model change notification rights (with a defined notice period before material updates), data deletion on termination with verification, audit rights over AI system logs, liability allocation for AI errors in regulated outputs, and explicit prohibition on using your data for model training or fine-tuning without consent. EY's 2025 analysis found most standard vendor agreements lack all of these.

How do we assess whether an AI tool's outputs are auditable enough for SOX or CSRD? Ask the vendor to demonstrate log completeness (prompts, outputs, tool calls, configuration changes), log retention matching your audit cycle, export in auditor-readable formats, and versioned change management records. For CSRD/ESRS, the methodology and data sources underlying AI-generated ESG metrics must be explainable and traceable to satisfy EFRAG's disclosure requirements.

What is the model change notification problem, and why does it matter? Most AI vendor contracts allow the vendor to update or replace the underlying model without notice. For a regulated financial institution, an undisclosed model change can invalidate prior model validation work and produce unexplained changes in outputs, potentially triggering regulatory notification obligations. Negotiate for explicit notification rights before any material model update takes effect.

How often should we review AI vendors after onboarding? Annual reviews are the regulatory floor for high-risk AI vendors, but continuous monitoring is the expectation. Track vendor news, financial condition, regulatory actions, and model update notifications on an ongoing basis. Point-in-time assessments become stale almost immediately in a fast-moving AI supply chain.

Run your financial reporting on Finrep