AnswerVault for Financial Services

The board has to certify what most AI tools can't evidence

A risk committee at a UK bank, insurer, or asset manager is now routinely asked to attest, in writing, that the firm's technology, including its AI tooling, is consistent with the firm's obligations under the Digital Operational Resilience Act and the operational-resilience expectations of the FCA and the PRA. The question is not "does the tool work". It is "can you show a regulator, on demand, which approved source an answer came from, where it was processed, and under whose jurisdiction".

Most AI knowledge tools deployed in financial services were bought before that question hardened into a procurement criterion. They answer fluently from whatever they can reach, with no notion of whether a document was the approved, current version, and they run inference on a US-controlled layer that a UK-regulated firm has to disclose in its third-party risk register. The technology demos well. It is the evidence trail that fails due diligence.

What financial services actually has to prove in 2026

Three regulatory regimes shape how a UK or EU financial firm buys and runs AI tooling. They overlap, but each adds its own evidence demand.

The common thread is evidenceability. A security review asks "is it secure". A regulated procurement asks "can you produce, for a specific answer on a specific date, the approved document it came from, the approver, and the jurisdiction it was processed in". A tool that cannot produce that record is non-evidenceable, which in regulated work amounts to non-compliant. The fuller treatment of how the four frameworks shape AI procurement is in our guide to AI knowledge management for regulated industries.

Why most AI tools fail the financial-services test

The gap rarely shows up in a feature demo. It shows up in the due-diligence questionnaire, and it tends to fail in four predictable places.

• No curated source set. General-purpose AI search answers from whatever it can index. It has no concept of an approved, current version, so it cannot tell a reviewer which documents were eligible to answer from on the date a decision was taken.
• Citations at the summary, not the sentence. A citation block at the end of an answer is weaker evidence than a clause-by-clause link to a specific document and version. Regulators reviewing a decision retrospectively rarely have time to re-read the source.
• Residency mistaken for sovereignty. Selecting a UK region addresses data residency, where data physically sits. It does not address data sovereignty, whose laws can compel access. Many tools achieve UK residency for documents at rest while sending the actual AI inference to a US-controlled model.
• An opaque subprocessor stack. If the AI tier depends on a third-party model API, that relationship flows into the firm's DORA register and has to be assessable. A vendor that cannot name its subprocessors creates work for the firm's compliance function.

The jurisdiction point is the one that narrows a shortlist most aggressively. The US CLOUD Act (2018) compels US-headquartered companies to produce customer data on demand, regardless of where that data physically sits, because the Act follows corporate control rather than data location. For a firm handling client money, market-sensitive material, or regulated records, that residual exposure is a legitimate procurement concern even where it is unlikely to be exercised. AnswerVault answers this with a UK-controlled Enterprise sovereign tier, described below; the standard tiers run on AWS and the Act applies to them, which a business case should state plainly rather than claim a UK region resolves it. We unpack the residency-versus-sovereignty distinction in full in our sovereign AI guide.

How AnswerVault fits financial services

AnswerVault is a governed AI knowledge layer that connects an organisation's existing document sources, including SharePoint, Google Drive, and Confluence, and delivers accurate, source-backed answers through web chat, Microsoft Teams, Slack, CLI, and API. It was originally built for a global pharmaceutical company with strict data governance requirements, and the same architecture answers the audit, citation, and jurisdiction demands that financial-services procurement now places on AI tooling.

The central artefact is the audit trail. A document does not become answerable because it sits in a connected library; it becomes answerable because a named owner approves it as the current, authoritative version, with that approval written into the record at the moment it happens. When a policy or procedure is superseded, the old version stops being used for answers and the change is preserved, so the question "which version was the firm's position on this date, and who approved it" has an answer a regulator can read.

Answers are cited at the sentence level, so a reviewer can trace each clause back to a specific document and version. The platform respects the existing permission model of the connected sources rather than flattening it, which keeps information-barrier and need-to-know boundaries intact.

On jurisdiction, the tier matters and the firm should match it to the data. The standard tiers provide UK or EU data residency on AWS infrastructure; the CLOUD Act applies to those tiers because AWS is US-headquartered, and a business case should state that plainly rather than claim a UK region resolves it. The Enterprise sovereign tier is UK-controlled, with the AI processing layer inside the sovereign boundary, for the material whose sensitivity makes jurisdiction a procurement-blocking concern. AnswerVault is ISO 27001 aligned and ISO 42001 underway, AI is included in every plan with no per-query charges or separate model keys required, and customer data is never used to train AI models. The detail a third-party risk assessment needs, including hosting, subprocessors, attestations, and audit rights, is documented on our security and compliance page.

The questions your second line will ask

By the time a governed AI knowledge tool reaches procurement in a financial firm, the second line of defence and the third-party risk team have a standard set of questions. A tool built for regulated work should answer all of them without special pleading, and the answers belong in the diligence pack, not a sales deck.

• Where does the AI processing run, and under whose jurisdiction? If any inference step is US-controlled, the firm has to accept or document the residual CLOUD Act exposure. The Enterprise sovereign tier keeps the processing layer inside a UK-controlled boundary for the material that needs it.
• Can you produce the curated source set as it stood on a given date? A defensible audit answer requires the platform to know which documents were eligible to answer from on a specific day, and who approved each of them.
• Are answers cited at the sentence level? Clause-by-clause links to a specific document and version are stronger evidence than a citation block appended to a summary.
• Who are the subprocessors, and how do they enter our DORA register? If the AI tier depends on a third-party model, that relationship has to be named and assessable. The detail sits on the security and compliance page for direct reference in a third-party assessment.
• What are the resilience and exit provisions? The firm has to evidence continuity for any important business service that comes to depend on the tool, including recovery objectives and a clean exit path for the data.
• Is customer data used to train models? It is not, by AnswerVault or by the underlying providers, and that should be stated in the contract rather than implied.

Where financial-services firms put it to work

• Compliance and policy lookup. First-line staff get an answer from the latest approved policy, procedure, or regulatory interpretation, with a citation, instead of emailing the compliance team or acting on a stale copy.
• Audit and regulatory support. When an auditor or a regulator asks how a decision was reached, the firm can produce the source set, the approval chain, and the per-answer citation, rather than a stack of PDFs and a meeting.
• Client-facing teams. Relationship managers and advisers query product terms, suitability guidance, and onboarding requirements from a governed set, so the answer a client receives is the approved one.
• Onboarding and knowledge continuity. New joiners self-serve from the institutional record instead of depending on the colleague who happens to remember, and the knowledge stays in the indexed source when that colleague leaves.

In financial services the conversation usually starts with the audit, jurisdiction, and resilience constraints, not the AI features, and that is the right order. If you are scoping AI knowledge against a DORA, FCA, or PRA obligation, the most useful first step is to map your framework exposure to the audit artefacts your current or candidate tooling can actually produce. Book a scoping call and we'll work through it, or compare tiers on the pricing page.