AI Vendor Risk in Capital Markets Requires Runtime Supervision

An analyst places an unpublished earnings draft beside a chat window and asks a vendor model to tighten the risk factors. The request leaves under an authenticated corporate account, carrying information that the firm's restricted-list controls were designed to contain. That model call is the mechanism behind ai vendor risk capital markets. Procurement approved a supplier, while supervision still has to establish who sent the request, which model received it, what information was present and which policy allowed the transfer.

I want to connect the vendor file to those live facts, because capital-markets obligations follow the business use rather than the logo on the contract.

TL;DR

• FINRA Regulatory Notice 24-09 says existing rules continue to apply to generative AI used directly, through a third party, or through an embedded feature.
• Rule 3110 supervision should address model risk, data privacy, integrity, reliability and accuracy when AI supports a supervisory system.
• Regulation S-P requires covered institutions to maintain an incident-response programme and notify affected individuals within the rule's deadline.
• A defensible vendor review joins contract and use-case approval to authenticated request records containing identity, data class, model route, policy and outcome.

FINRA supervision follows third-party AI

FINRA Regulatory Notice 24-09, published June 27, 2024, states that FINRA rules apply when member firms use generative AI in their business. The notice expressly covers proprietary tools, third-party technology, and AI embedded inside an existing third-party product.

For Rule 3110 supervision, FINRA says policies and procedures should address technology governance when a generative AI tool forms part of the supervisory system. The notice names model risk management, data privacy and integrity, plus the reliability and accuracy of the model. It also tells firms to evaluate the tool before deployment and maintain compliance with the rules applicable to the business use.

The vendor assessment therefore needs a use-case register beside the supplier record. Research summarisation, correspondence review and trade-surveillance support create different supervisory evidence. A broad approval for generative AI erases the distinctions the notice asks the firm to manage. The governance layer is covered in AI governance for capital markets.

Regulation S-P reaches the vendor incident path

The SEC's Regulation S-P amendments require covered institutions to develop, implement and maintain written incident-response policies and procedures designed to detect, respond to and recover from unauthorized access to or use of customer information. Covered institutions include broker-dealers, investment companies, registered investment advisers and transfer agents.

The amendments also require notice to affected individuals as soon as practicable and no later than 30 days after the institution becomes aware that unauthorized access or use has occurred, or is reasonably likely to have occurred, subject to the rule's exceptions. Required notice must describe the incident, the affected data and protective steps available to the individual.

An AI vendor file should map how the firm learns about an incident involving customer information in a prompt or response. That means named contacts, notification mechanics, the data needed for scoping, and a testable route into the firm's incident-response process. A generic support mailbox is thin evidence for a 30-day customer-notice clock.

The vendor inventory needs the real model route

Capital-markets products increasingly include AI behind familiar controls. Research platforms can add document summarisation, while a communications archive can introduce review assistance. Surveillance products may send selected alerts to a model. Each capability can create a separate provider, model, region, retention posture and subprocessor path.

The inventory should record the business use, owner, approved data classes, source application, receiving legal entity, model route, region, retention setting, review date and reassessment triggers. For an analyst, the yellow restricted-list banner beside an issuer name is a useful visual control. Policy enforcement still needs that classification attached to the outbound request.

My view is that embedded AI deserves more scrutiny than a standalone AI tool because its network path hides behind a vendor the firm already trusts. Familiar procurement history can conceal a new recipient of customer information or material nonpublic information. Shadow AI in capital markets covers the unapproved routes; embedded AI creates a similar evidence problem inside an approved application.

Runtime evidence turns approval into supervision

A vendor questionnaire records a point-in-time representation. Supervision requires evidence of business use after approval. The join between those records should be explicit.

For every authenticated HTTP call to a model, the runtime record should identify the associated person or agent, role, application, use case, destination provider, model version, information classification, policy version, outcome and timestamp. A stable vendor and use-case identifier connects the call to the approved supplier record and supervisory procedure.

That structure lets compliance sample correspondence-review calls for one month, isolate requests involving a restricted issuer, or retrieve every call to a model version under reassessment. A denied request belongs in the evidence too. It demonstrates that the policy operated when an analyst or automated workflow attempted an unapproved route.

This request-level approach complements the broader AI vendor risk management programme. Financial viability, concentration risk, contract negotiation and vendor resilience stay in third-party risk management. The HTTP record supplies the operational slice.

Reassessment should start when the facts change

Calendar reviews remain useful, but material changes can happen between them. The approved control should name events that open reassessment: a different model, a new region, altered retention, a new subprocessor with access to content, or use of the service in another regulated workflow.

Some triggers are visible in vendor notices, while traffic reveals others first. If a route begins returning a new model identifier, the runtime system can flag the approved-use owner before weeks of calls accumulate. If an agent begins sending a higher information class than the use case allows, inline policy can deny the request while compliance reviews the change.

DeepInspect has a specific boundary: authenticated HTTP AI traffic between the firm's users or agents and LLMs. Vendor solvency analysis, models hosted entirely inside a third-party application with no customer-controlled traffic path, and the firm's legal determination about MNPI sit outside that boundary.

DeepInspect

DeepInspect sits inline between authenticated capital-markets users or agents and HTTP-based LLM endpoints. It evaluates caller identity, application, use case, information classification, destination model and policy before transmission. Requests containing a restricted data class can be denied or routed to an approved endpoint.

Each decision creates a signed record with the caller, role, vendor and use-case identifiers, model version, classification, policy version, outcome and timestamp. Compliance can retrieve records by person, issuer classification, application, vendor, model or time window. Third-party risk decisions, supervisory design and Regulation S-P notifications remain with the firm.

Book a demo today.