# Test the Vendor
> The FCA lists overreliance on untested vendor assurances as an area for improvement. A broker can test a vendor's AI itself before it talks to clients.
**Published:** 2026-11-02  
**Reading time:** 11 min read  
**Tags:** brokers, fca, ai-oversight, vendor-due-diligence, compliance
On 19 October 2026 the FCA published examples of good practice and areas for improvement in firms' use of AI. One area for improvement is "overreliance on untested vendor assurances": firms that took a vendor's word without challenging or testing it. A week later, the Bank of England and FCA's 2026 survey of AI in UK financial services reported that for high-materiality AI systems supplied by third parties, the most common basis of understanding among respondents was assurance by the vendor and contractual arrangements (81%), and 24% reported deep knowledge of those systems, against 77% for systems built in-house. For a broker weighing an AI that will talk to its clients, much of the oversight can happen before launch, through tests the firm runs itself and checks built into the system. Reading calls afterwards cannot carry it alone: to have a 95% chance of hearing a fault that happens on 1 call in 1,000, a reviewer has to hear about 3,000 calls. So turn each assurance the vendor gives into a test the firm can run itself, before launch and on its own clients.

## What the FCA published on 19 October

The FCA's page, *AI in financial services: good practice and areas for improvement*, collects examples from its industry engagement, supervisory work and AI Lab. It groups them under three headings: the Consumer Duty and consumers in vulnerable circumstances, governance and accountability, and operational resilience. It is clear about its own status. The examples "do not create new requirements, prescribe a single model or replace firms' responsibility for considering what is appropriate and proportionate for their own AI use cases, risks and potential impact."

The page is plain about where responsibility sits when a firm buys AI instead of building it. The section on third-party relationships says: "Firms can outsource AI services, but remain responsible for them." Its first area for improvement reads:

**Financial Conduct Authority · 2026**
> Overreliance on untested vendor assurances. Some firms relied on vendors' assurances without challenging or testing them. Firms remain accountable for outsourced AI services. If they don't test assurances, they may not understand model limitations, resilience dependencies or whether fallback arrangements would work in practice.
> *Source: AI in financial services: good practice and areas for improvement, section 4.2, published 19 October 2026*

## What firms told the regulators a week later

The Bank of England and the FCA published their 2026 survey of AI in UK financial services on 26 October. Of 196 firms that responded, 105 completed the full questionnaire, which most of the figures come from, and the regulators describe the results as evidence from the firms that took part, not a complete picture of the sector.

The survey asked how firms reach a sufficient understanding of their high-materiality AI systems. For systems built in-house, 77% of respondents reported deep knowledge of the system. For systems supplied by third parties, 24% did. There, the most common answer was "assurance by the vendor and contractual arrangements", at 81%. Respondents also reported assurance of behaviour and outcomes, and limits on what the system can do, for third-party systems, alongside vendor assurance.

Read together, the two publications point at the same question. For the high-materiality AI that respondents buy, the most common basis of their understanding is the vendor's assurance and the contract, and the FCA lists relying on vendor assurances without testing them as an area for improvement. The question for a buyer is what can be tested, and by whom. Our [comparison of building and buying an AI coach](/blog/prop-firm-ai-coach-build-vs-buy) covers the other side of that choice.

## The review load

A compliance team weighing an AI that would speak to its clients has a fair first concern: the review load. Someone will have to watch what it says, every day, for as long as it runs. That is staff time, and it belongs in the business case before anything is switched on.

The picture behind that concern is a person checking the AI's output call by call. The FCA's page keeps a place for that: its good practice includes "Human-in-the-loop as a risk-based control". But it lists "Excessive reliance on human-in-the-loop controls" among its areas for improvement, where firms leaned on staff "without addressing underlying model risk or governance responsibilities". It explains that human review "may mask weaknesses in the model", and warns of review becoming "a 'box-ticking' exercise, rather than meaningful oversight." Elsewhere its good practice adds checks built into the system: "building proportionate technical checks and continuous monitoring into the AI system, rather than only relying on a person to review, approve, challenge or override its outputs or decisions." That passage ends with a sentence a buyer can put to any vendor: "Firms should be able to show that the controls they choose work in practice."

## What a sample of calls can tell you

Review by sampling has a limit that takes one line of arithmetic. Suppose a fault happens at random on 1 call in 1,000. The chance that a call does not contain it is 0.999, and the chance that a reviewer hears none of it across n calls picked at random is 0.999 multiplied by itself n times.

| Calls reviewed | Chance of hearing a 1-in-1,000 fault at least once |
|---|---|
| 100 | 9.5% |
| 300 | 25.9% |
| 900 | 59.4% |
| 2,995 | 95% |

So a fault on 1 call in 1,000 needs about 3,000 reviewed calls for a 95% chance of hearing it even once. Statisticians have a shortcut for the reverse question, known as the rule of three: when n observations show no problem, the upper end of the 95% confidence interval for the problem's rate is about 3 divided by n. Three hundred clean calls show, at that confidence, only that the fault rate is below about 1 in 100.

The rates here are illustrative, not measurements of any AI system, ours included. The arithmetic assumes the calls are picked at random and the fault occurs at a steady rate. Real faults often cluster, after a script change for example, and a reviewer misses a fault they do not recognise at any sample size.

For a compliance team, the useful question is which faults a sample finds. A fault on 1 call in 20 shows up in almost any sample of 100: the chance of missing it is under 1%. The faults a regulated firm worries about most are rare by design: a sentence that drifts towards advice, a missed sign that a client is in distress, a call that skips its opening disclosure. Those need testing before launch and checks that run on every call, with human review sampling on top.

## Turn each vendor assurance into a test

The usual advice for buying AI is a sharper questionnaire, and questions are where testing starts. We have published our own, for [AI that places orders](/blog/the-confirmation-step-checks-the-order-not-the-trader) and for [measuring whether a call says it is an AI](/blog/the-disclosure-gap). But a vendor's answer to "does it ever give advice?" is an assurance, whoever writes it, us included. The useful follow-up is how the firm can check that answer itself.

Try to break it before launch. Ask the AI for a trade idea, a price or a position size, and see what it does instead. Play a client who wants to [win a loss straight back](/glossary/revenge-trading), and see whether it coaches without advising. Play one who sounds distressed, and see whether it stops and hands over to a person. One firm in the FCA's examples opened a demo of its AI product to its own staff and offered a prize to anyone who could break it. The page also lists "Assuming an LLM can reliably identify vulnerability without sufficient testing or safeguards" as an area for improvement, so the distress scenarios belong in the firm's own test set. Our note on [what a coaching call says and never says](/blog/the-coaching-call-never-says-stop) is one place to draw test lines from.

Read the rules that decide when it acts. If the moments that trigger contact are fixed rules with limits the firm sets, such as a share of a [daily loss limit](/glossary/daily-loss-limit), they can be read, signed off and run against the firm's own trade history before launch, to see how often they would have fired, and in which groups of clients. A judgement made inside the vendor's model cannot be read that way, only sampled.

Find what can change without you. Ask what the vendor can change without the firm's sign-off: the wording, the rules, the model underneath. The FCA's good practice includes using contracts to get notice of significant model changes, which it says helped firms "test and integrate updates without disrupting services". Then check that the fixed parts stay fixed, for example by listening for the opening disclosure on calls months apart.

Test the claimed effect on your own clients. A result measured at another firm describes that firm's clients. A comparison between clients who get the AI and clients for whom it is held back at random, in the same book over the same weeks, measures what it does for these clients. [How many clients such a comparison needs](/blog/proof-has-a-sample-size) is its own question.

Switch it off. The FCA's page names whether fallback arrangements "would work in practice" among the things a firm that does not test may not understand. A planned period without the service shows what the fallback is.

## Where human review fits

Human review keeps a role, with a narrower job. Sample at a stated size, so the team knows what a clean sample can and cannot show. Record what reviewers did, not only that review happened. One of the FCA's smaller-firm examples stressed the need to record "whether staff needed to review AI outputs, whether this happened, and whether they approved the outputs, overrode them or escalated issues", which the page says created an audit trail of how oversight worked in practice. And review the checks as well as the calls: an automated check, such as one that flags advice-like wording, is itself something to test by feeding it examples it should catch.

## How Discentra is designed to be tested

Discentra builds AI voice coaching for [brokers](/brokers) and prop firms: coaching, not financial advice. It is designed so that a firm can run these tests on us. The [warning signs](/glossary/behavioural-trigger) that trigger a call are rules written into the contract. The firm declares its daily loss limit and maximum position size at onboarding, and the contract requires notice to the firm, though not the firm's sign-off, before we change a rule. Every call is designed to open with a fixed disclosure that the caller is the firm's AI coach and does not give financial advice, which the firm cannot switch off. The statement of work makes call transcripts available on the firm's dashboard, and voice data is not used for model training. The contract judges a pilot by comparing warning signs followed by a call with warning signs where the call was held back at random (a one-in-three chance each, never on a crisis event), and the firm can exclude any client from the hold-back.

Don't take our word for it, or anyone's. Before an AI talks to your clients, find out what you can test yourself, then test it.

## Sources and notes

- **FCA (2026).** *AI in financial services: good practice and areas for improvement*, published 19 October 2026, last updated 20 October 2026 (an editorial amendment to section 4.1). [fca.org.uk](https://www.fca.org.uk/publications/good-poor-practice/ai-financial-services). Evidence type: regulator publication of examples. It states that its examples do not create new requirements; it does not mention voice calls, coaching or trading. Read 30 October 2026.
- **Bank of England and FCA (2026).** *Artificial intelligence in UK financial services - 2026*, published 26 October 2026, section 7.3. [bankofengland.co.uk](https://www.bankofengland.co.uk/report/2026/artificial-intelligence-in-uk-financial-services-2026). Evidence type: regulator survey. 196 respondents, 105 of them completing the full questionnaire; the regulators describe the results as evidence from participating firms, not a complete assessment of the sector. The 81%, 24% and 77% concern high-materiality systems, and respondents reported other approaches alongside vendor assurance. Read 30 October 2026.
- **The rule of three.** Hanley, J. A. and Lippman-Hand, A. (1983). If nothing goes wrong, is everything all right? Interpreting zero numerators. *JAMA* 249(13), 1743-1745. Restated in Eypasch, E., Lefering, R., Kum, C. K. and Troidl, H. (1995). Probability of adverse events that have not yet occurred: a statistical reminder. *BMJ* 311, 619-620. Evidence type: statistical rule. The table above is our own arithmetic, with illustrative fault rates that are not measurements of any system.
- **Discentra's design.** Our client contract and statement of work templates (warning signs, the limits the firm declares, notice before a rule changes, transcripts on the dashboard, the pilot hold-back) and our Compliance FAQ (the opening disclosure, model training). Evidence type: our own documents, not independent evidence.
## Frequently asked questions

### What did the FCA publish about AI in financial services on 19 October 2026?

A page of examples titled AI in financial services: good practice and areas for improvement, drawn from industry engagement, supervisory work and the FCA's AI Lab. It groups them under the Consumer Duty and consumers in vulnerable circumstances, governance and accountability, and operational resilience, and says the examples do not create new requirements. One area for improvement is overreliance on untested vendor assurances.

### What does the FCA mean by overreliance on untested vendor assurances?

Firms that relied on a vendor's assurances about an AI service without challenging or testing them. The FCA's page adds that firms remain accountable for outsourced AI services, and that a firm which does not test assurances may not understand the model's limitations, its resilience dependencies, or whether fallback arrangements would work in practice.

### How many calls does a reviewer need to hear to catch a rare fault?

More than most review plans allow. If a fault happens on 1 call in 1,000, a reviewer needs to hear about 3,000 calls, picked at random, for a 95% chance of hearing it at least once; after 300 calls the chance is about 26%. And 300 calls with nothing wrong show, at 95% confidence, only that the fault rate is below about 1 in 100, a shortcut statisticians call the rule of three. The rates are illustrative, not measurements of any system.

### How can a broker test an AI vendor before it talks to clients?

Turn each assurance into a test the firm runs itself. Try to make the AI say what it must not, such as a trade idea, a price or a position size, and play a client who sounds distressed. Read the rules that decide when it acts and run them against the firm's own history. Find out what the vendor can change without the firm's sign-off. Compare clients who get the AI with clients for whom it is held back at random. And switch it off for a planned period to see whether the fallback works.


---

This is a Markdown mirror of [https://discentra.ai/blog/test-the-vendor](https://discentra.ai/blog/test-the-vendor). Provided for LLM citation. © Discentra Ltd. Coaching, not financial advice.