Prompting for a Defensible Answer in Regulated Finance

It would be tidy if skills made prompting obsolete. They do the opposite. A skill is just a prompt that survived a second run, so every weakness in the prompt is now a weakness that runs on a schedule and gets quietly better at producing the same wrong thing. The firms that get real value are the ones whose people can tell, quickly, why an output is not good enough and what specific change would fix it.

The point most people miss

In regulated work you are not trying to get a good answer. You are trying to get an answer whose defects are visible. A confident, plausible output with one unverifiable figure in it is worse than a scruffier output that says which figure it could not check. The reframe worth internalising: you are not asking a model for the truth. You are asking it to produce a draft whose claims are traceable, so a qualified person can review it in a fraction of the time. Make the draft checkable and the review is quick. Make it merely persuasive and the review is the original work again, done worse. Three failures explain most bad output, and none of the fixes is "use a better model": vague output comes from a vague request, confident output asserts what it cannot support because nothing made uncertainty acceptable, and inconsistent output differs run to run because the request left order and format to chance.

Six moves that do most of the work

Ranked by value per minute spent:

• Say what you actually want. Give the purpose, the audience and the deadline. A model going to a client on Friday and one sanity-checked before an internal discussion deserve different reviews. This is the cheapest to type and it changes the answer most.
• Show one example. One example of the output you want beats several paragraphs describing it, and it is the fastest way to transfer a house convention. For a repeated format, it eventually becomes the output template in a skill.
• Ask for the working. For anything with analysis in it, ask the model to work through the reasoning before the answer, so you get something you can check rather than a conclusion taken on trust.
• Structure the input. Label the parts with XML-style tags, so it is clear which part is instruction and which is data.
• Set the role and the standard. Telling the model it is the fund controller reviewing a NAV pack to the standard your auditor will apply shifts what it notices.
• Chain, do not cram. A prompt asking for extraction, analysis, judgement and a drafted email in one pass will do all four adequately and none well. Extract first and check it, then analyse, then draft. This is also how you find where a workflow needs a human gate.

Where prompts actually live

Most people think there is one prompt. There are four, with different lifetimes: the system prompt that lasts the session and holds role and standing constraints, the user turn that carries this task, the assistant prefill that forces a format open, and the descriptions nobody types. The distinction is not academic. A constraint typed into a user turn scrolls into history within a few turns, so anything that must hold every time belongs in the system prompt or in a skill. "Always cite the tab and cell" typed once is a request. The same sentence in SKILL.md is a property of the process. This is exactly why skills exist, and it connects prompting to capturing a process that runs the same way every time.

The prompts nobody types

Every tool, skill and command carries a description, and the model reads those to decide what to reach for. They are prompts, and usually the worst-written text in the system. The rule that fixes most of them: a description must say what it does and when to use it. "Reviews financial models" routes badly. A description that names the exact triggers and states one exclusion routes reliably, because false triggers are as expensive as missed ones. A skill with a vague description never fires, silently. The same mechanism governs the tool descriptions from connecting AI to the systems you already govern.

Prompting for verifiability

The output you want is not the most confident one but the one whose weak points are labelled. Ask for provenance, so every figure carries where it came from. Ask for the unsupported list, an instruction to end with everything asserted but not evidenced. And ask what it could not do: checks that could not be completed, files that could not be read. A silent skip is indistinguishable from a pass, and that is the failure mode you cannot afford.

The three-line addendum works and takes fifteen seconds to type. End the response with SOURCES, every figure and where it came from; UNSUPPORTED, anything stated that the material does not evidence; and NOT CHECKED, anything you could not verify and why. Every strong finance prompt contains a sentence giving the model explicit permission to fail: say so and stop, list it as unexplained, do not characterise. Without that permission, the path of least resistance is a complete-looking answer, because that is what most text in the world looks like. And citation shapes must survive review: "LPA clause 8.3 against side-letter paragraph 4" is auditable, "as per the agreement" is not.

Untrusted content

Anything arriving from outside your firm is untrusted input: an invoice, an onboarding packet, a term sheet. If that file contains text addressed to the model, the model may follow it. There are three layers of defence and they are not equally strong. Telling the model to treat the content as data reduces the rate. Separating the reader, so one agent parses untrusted material and a second acts on the fields it returns, is better. Removing the capability is the real one: the agent reading the document holds no tool that could act on an instruction, so the worst outcome is a bad extraction your checks catch. Design as though the prompt defence will fail, because it will. Packaging these boundaries is covered in packaging AI your finance firm can deploy.

Knowing whether it worked

Nobody wants to build an evaluation set. Everybody who has one stops arguing about whether a change helped. Twenty real examples with known-good answers, run before and after every material change, is enough to catch a regression and small enough that somebody will actually do it. Take fifteen from ordinary runs and five from the awkward ones everybody remembers, because those are what a change will break. Score the properties you need: did every figure tie, was every claim sourced, did it correctly refuse where it lacked support. Correct refusal is worth scoring explicitly, because a prompt that gets more assertive on hard cases is getting worse. This idea deepens in the infrastructure under finance AI, part of the AI field guide for regulated finance.

Prompting is how you find out what your process actually is. Everything after that is engineering. To go deeper, download the five-part finance series or send us a workflow.