How to Run Due Diligence on an AI Vendor at a Financial Firm

Current as of October 29, 2026. This guide draws on US banking, insurance and securities rules and guidance, EU, UK and Canadian supervisory texts and NIST, as published on that date. Which of them apply depends on the firm; it is not legal advice.

Much of the AI a financial firm uses is built by someone else: a model inside a vendor's credit platform, a copilot added to software the firm already licenses, a notetaker, a claims tool. The bank, insurance and securities supervisory texts reviewed for this guide that address vendors make the same point in different words: using a vendor does not move the responsibility. One gap matters here: the US bank model risk guidance leaves generative and agentic AI, which includes most copilots and notetakers, outside its scope. EIOPA, the EU insurance and pensions authority, puts the principle plainly in an opinion addressed to national supervisors, which does not cover AI systems classed as high-risk under the EU AI Act: "Undertakings are ultimately responsible for the AI systems that they use, regardless of whether the AI systems are developed in-house or in collaboration with third party service providers."

This guide turns that responsibility into a working process: find the AI you are already buying, ask the right questions, test it yourself, write the answers into the contract, and keep watching.

Step 1: Find the AI you are already buying

Start with an inventory of vendor AI, including the features that arrive inside products the firm already uses. FINRA's guidance to its member firms is explicit that its rules apply "whether member firms are directly developing Gen AI tools for their proprietary use or when leveraging the technology of a third party, including through embedded features in existing third-party products." Canada's OSFI, in guidance that takes effect May 1, 2027, expects institutions to have "defined processes to periodically identify models used throughout the enterprise, including vendor and third-party models", and NIST's AI Risk Management Framework includes "GOVERN 6.1: Policies and procedures are in place that address AI risks associated with third-party entities".

Ask business owners and procurement, and read release notes: a vendor can add an AI feature to software the firm bought years ago without a new contract.

Step 2: Work out which rules apply to this vendor and this use

• Banks: for models within its scope, the 2026 interagency model risk guidance says "An important element of model risk management is the validation of vendor products, either by internal or outside parties." It does not cover generative or agentic AI, which the bank governs under its own practices. The guidance is non-binding and is expected to be most relevant to banking organizations above an asset threshold set in the guidance.
• Insurers: New York's Circular Letter No. 7, on AI and external data in underwriting and pricing, says "An insurer may not rely solely on a third-party's claim of non-discrimination or a proprietary third-party process to determine compliance with anti-discrimination laws." Colorado's regulation, which covers life, auto and health insurers' use of external consumer data and the algorithms and models that use it, keeps the insurer responsible when a third party is involved, "including the production of any documents or information that the Division deems necessary to ensure compliance with regulatory requirements."
• SEC-registered advisers and broker-dealers: Regulation S-P requires policies "reasonably designed to require oversight, including through due diligence and monitoring, of service providers." A vendor that receives, maintains or processes client information through services it provides directly to the firm typically fits the rule's definition of a service provider (interpretation). State-registered advisers are outside Regulation S-P and should check their state's rules.
• UK banks with internal model approval: the PRA's supervisory statement, which applies to UK banks, building societies and PRA-designated investment firms with internal model approval and not to insurers, expects firms to "satisfy themselves that the vendor models have been validated to the same standards as their own internal MRM expectations".
• EU insurers: for AI outside the AI Act's high-risk categories (life and health insurance pricing is inside them, so Step 6 applies), EIOPA's opinion says undertakings "should obtain adequate information and assurances from third-party service providers about the characteristics, capabilities, data used to train and test the AI systems, and the limitations of the AI systems used."

Step 3: Ask the questions that matter for AI

A standard security questionnaire may not cover the questions specific to AI. Add them, and ask for evidence rather than assurances. The texts in Step 2 point to a core set: what the system does and does not do, which data it was trained and tested on, and its known limitations. This guide adds (interpretation): which underlying models it uses and how version changes are handled, whether the firm's or its clients' data is used to train anything, which subprocessors handle the data, how outputs can be logged and kept, and what testing for bias or accuracy the vendor has done.

FINRA's 2026 oversight report lists, among practices firms may consider, "assessing the third-party vendor's use of GenAI". A NASAA Investment Adviser Section publication (which says it does not necessarily represent NASAA's views) suggests that "Before using any third-party AI tools, Advisers should investigate a vendor's data security protocols, regulatory compliance support, transparency around AI algorithms, and customer support and updates."

Step 4: Test it yourself

A vendor's own test results are a starting point, not a conclusion. The UK PRA expects firms within its scope to "validate their own use of vendor products and conduct ongoing monitoring and outcomes analysis of vendor model performance using their own outcomes." The US banking guidance, for the models it covers, accepts that "banking organizations may not receive from the vendor the underlying code, data, or methodology that they would have if a model were developed internally. Nevertheless, the principles of model risk management remain applicable."

In practice, run the tool on the firm's own data and cases before rollout, compare its outputs with known results, and test for the failures that matter in the use: wrong answers, unfair outcomes, data leakage. Keep the tests so they can be repeated when the vendor changes the model (interpretation).

Step 5: Write the answers into the contract

What the diligence found should become obligations. The texts reviewed point to several terms worth negotiating:

• Audit rights or audit reports. Illinois's AI bulletin for insurers points to contract terms that, where appropriate and available, "Provide audit rights and/or entitle the Insurer to receive audit reports by qualified auditing entities."
• Breach notice. Regulation S-P requires covered firms' policies to be reasonably designed to ensure service providers "take appropriate measures to" notify the firm "as soon as possible, but no later than 72 hours after becoming aware that a breach in security has occurred resulting in unauthorized access to a customer information system maintained by the service provider."
• Limits on data use. FINRA's 2026 report lists "adding language that prohibits firm or customer sensitive information from being ingested into a third-party vendor's open-source GenAI tool" among practices firms may consider.
• Records and regulators. FINRA's 2026 report lists "Not performing adequate due diligence to verify third-party vendors' ability to comply with recordkeeping requirements" among its books-and-records findings, and Illinois points to terms that "Require the third party to cooperate with the Insurer with regard to regulatory inquiries and investigations".
• Data on exit. FINRA's 2026 report lists, among practices firms may consider: "Incorporate procedures to return or destroy firm data at the termination or conclusion of a vendor contract."
• Notice of model changes. Notice before the vendor changes the underlying model or adds AI features is a sensible term that the texts reviewed do not state (interpretation).

Step 6: Watch for changes that change your obligations

Some changes on the firm's side shift responsibility further. Under the EU AI Act, a deployer can become a provider, with a provider's obligations, where "they make a substantial modification to a high-risk AI system that has already been placed on the market or has already been put into service in such a way that it remains a high-risk AI system pursuant to Article 6". Under Regulation (EU) 2026/1744, the Act's high-risk obligations for credit scoring of individuals and for life and health insurance risk assessment and pricing apply from December 2, 2027. Fine-tuning or reconfiguring a vendor's system is the kind of change to check against that test (interpretation).

Step 7: Monitor the vendor's AI in production

The US banking guidance describes "sound practice" for the vendor models it covers as "conducting ongoing monitoring and outcome analysis to assess whether vendor models are accurate, remain fit for purpose, and continue to be reliable." The same discipline fits other vendor AI (interpretation): sample outputs against the tests from Step 4, track incidents and complaints, and re-test when the vendor announces a change.

Step 8: Plan for incidents and exit before you need them

When something goes wrong at the vendor, the firm still owns the response (interpretation). For SEC-registered firms, Regulation S-P is explicit: "the obligation to ensure that affected individuals are notified in accordance with paragraph (a)(4) of this section rests with the covered institution." Agree in advance who does what in an incident, how the firm gets the information it needs, and how it would move off the product if it had to.

Checklist

• Vendor AI, including features embedded in existing products, is inventoried
• The rules that apply to each vendor and use are recorded, by firm type and jurisdiction
• The diligence questionnaire covers training and test data, limitations, underlying models, version changes, data use, subprocessors, logging and bias testing
• Evidence, not assurances, is on file for the answers
• The firm has tested the tool on its own data and cases before rollout
• Tests are kept so they can be repeated after vendor changes
• The contract includes audit rights or reports, breach notice terms consistent with Regulation S-P, data-use limits and records support
• The contract requires notice of model changes and sets out data return or deletion on exit
• EU AI Act provider obligations have been checked where the firm modifies a high-risk system
• Outputs are monitored in production, with re-testing on vendor changes
• An incident plan says who does what and how client notification will be handled
• The proposed interagency third-party guidance is tracked until finalized

How we sourced this guide: every factual statement in it is drawn from published rules, regulatory guidance and other public documents, and we keep a full set of sources and citations for it. If you would like them, or want to question a point, get in touch through our contact page and we will share them.