Your AI Feature Is Stuck in Bank Vendor Review. Written Answers Won't Unstick It.

If you sell an AI feature to banks or insurers, you already know the moment. The pilot went well, the business sponsor wants to sign, and then the third-party risk team sends a questionnaire. Somewhere in it are the questions that stall the deal: can your model be manipulated by user input, can it leak one customer's data to another, what do you keep and for how long. You answer in writing. They come back with follow-ups. Weeks pass.

The problem is rarely that the vendor has bad answers. It is that written answers are claims, and a reviewer at a regulated institution is trained to discount claims.

What the reviewer is working from

Bank reviewers do not invent these questions. US banks operate under the 2023 Interagency Guidance on Third-Party Relationships, which expects due diligence and ongoing monitoring of vendors in proportion to risk. For generative AI specifically, FS-ISAC published a Generative AI Vendor Risk Assessment Guide in February 2024 whose vendor questionnaire covers data privacy and deletion, model lifecycle, information security, integration and fourth-party use. On the technical side, the OWASP Top 10 for LLM Applications 2025 ranks prompt injection first and sensitive information disclosure second, and adds system prompt leakage and excessive agency as named risks.

Put those together and the reviewer's real question is simple: has anyone actually tried to break this, and what happened?

Why written answers stall

• They describe intent, not behaviour. "We use guardrails to prevent prompt injection" says what you meant to build. The reviewer wants to know what the live system did when someone tried.
• They are not dated. Models, prompts and retrieval sources change often. An answer with no date and no version tells the reviewer nothing about the system they are about to connect.
• They overreach. A vendor who writes "our system cannot leak data" has made a promise that is very hard to keep, because language models take instructions and data through the same channel. Overclaiming costs more credibility than an honest, bounded finding.
• They miss indirect attacks. Many teams test what a user types. Fewer test what happens when a document, email or web page the feature reads contains instructions of its own.

A self-test to run before the reviewer does

Run these against your live feature, in a test tenant, with your own security lead's approval. Write down the date, the version and exactly what you saw.

1. Direct injection. Ask the feature, in several phrasings, to ignore its instructions and reveal or do something it should not. Record which attempts changed its behaviour.
2. Indirect injection. Put instructions inside content the feature reads: an uploaded file, a retrieved record, a pasted email. Does it follow them?
3. System prompt extraction. Can a user get the feature to print its own instructions or configuration? Assume anything in that prompt will eventually be read.
4. Cross-tenant leakage. Using two test accounts, plant a distinctive string in one and try to retrieve it from the other, through questions, search and summaries.
5. Action limits. If the feature can call tools, send messages or change records, try to make it do so outside the user's permissions.
6. Retention. Submit a marked test record, request deletion, then check logs, caches, vector stores and any model provider's retention against what your contract says.
7. Answer only what you observed. Go back through your questionnaire. Every answer should point to a test like the ones above, or say plainly that it was not tested.

How Riskernel runs this as a fixed-scope assessment

The AI Feature Attack Test for Bank Review is a dated attack test of your live AI feature, run in 48 hours with your written permission. It covers prompt injection, data leakage and retention. You receive an answer pack for the reviewer that cites only what was observed: what was tried, on which version and date, and what happened, including anything that failed. It does not certify the feature or promise it is safe. It gives the reviewer evidence instead of assurances. Scope and fees are agreed on a short call.