AI Prompting for Finance Analysts

Most members already use ChatGPT, Claude, Copilot, or Gemini for something — drafting an email, debugging a formula, summarising a 10-K. The gap between casual use and useful use is almost entirely about how the prompt is written. A senior analyst with a sharp prompt gets a defensible draft in two minutes; a junior with a vague one gets a paragraph of plausible-sounding filler and spends the next hour fact-checking it. The difference is not the model. It is the operator.

This session adapts a workshop given to PMC by Mário Silva Pereira (silvapereira.com). It is meant to be practical: a small set of mental models for what these systems actually are, a framework for talking to them, and a handful of habits that make the difference between AI that helps your pitch and AI that quietly puts garbage on your slide.

How the machine actually works

Before the prompting tactics, the mental model. Most of the bad prompts members write come from a misunderstanding of what is on the other end of the chat box.

When you send a prompt, the model does not read it the way you do. It first chops your text into tokens — chunks roughly the size of short syllables or common words — then maps each token to a numerical vector that encodes its meaning. The sentence "The market predicted a return" becomes roughly seven tokens; each token becomes a vector of several thousand numbers; those vectors get processed through dozens of transformer layers; the model outputs a probability distribution over the next token, samples one, and repeats.

Two consequences follow directly. First, every token costs compute — both yours sent in and the model's sent back. That is why API prices are quoted per million tokens, and why longer prompts and longer responses are not free. Second, the model has no privileged access to truth. It has only the statistical residue of its training data, plus whatever you provide in the prompt. If you do not give it the data, it will invent something plausible.

Why finance is well-suited to this

Finance work is unusually exposed to the things LLMs are genuinely good at. Most of what an analyst does in their first two years is data structured into reports, analysis under constraint, and writing for senior readers — and all three are amenable to AI assistance if the prompt is good.

None of this replaces judgement. All of it compresses the time between knowing what you want to say and having a defensible draft on the page. The quality of that compression is set, almost entirely, by the prompt.

The CSI-FBI framework

Six elements, every prompt, in roughly this order. The framework is adapted from a model proposed by Nicolas Boucher (nicolasboucher.kit.com) and is the single most useful prompt scaffold the workshop teaches. CSI is the request; FBI is how you want it back.

The order matters less than the completeness. A prompt that hits all six is rarely shorter than half a page, and that is a feature — the up-front investment is what makes the response usable.

Before and after — the Alstom example

The workshop walks one example end-to-end. The asset is Alstom S.A. (Euronext Paris ticker ALO), a listed European industrials issuer. The task is a credit read ahead of an internal investment committee.

The naive prompt — and what almost every member sends on a first attempt:

Can you analyse this company's financial health? Alstom S.A. (Ticker: ALO — Euronext Paris)

It will get a response. The response will be generic, will hedge on every number, and will not tell you anything you could not have found by typing the ticker into Google.

The CSI-FBI rewrite decomposes the same ask into the six fields:

The CSI-FBI version gets a tightly-structured response with named ratios, a verdict, and risks framed against credit thresholds the reader will recognise. Same model. Same minute of work. Materially more useful output.

Sharpening the loop

CSI-FBI gets you a usable first draft. Three additional techniques turn it into something defensible.

Devil's advocate

The default failure mode of an LLM is confirmation. Ask it whether your thesis is right and it will, with caveats, tell you it is. The fix is to instruct it explicitly to argue the other side.

A clean devil's-advocate prompt asks the model to surface counter-arguments, blind spots, alternative interpretations of the data, and the strongest version of the opposing case. The point is not to settle the debate — you do that with your own judgement. The point is to make sure the bear case got fair play before the slide is final.

Chain-of-thought

Generic answers skip steps, hide assumptions, and make silent maths errors. The cure is to require the model to show its working — step by step, formula by formula, assumption by assumption. The technique is called chain-of-thought (CoT).

A worked example: a project costs €10,000 today and returns €4,000 per year for three years at an 8% discount rate. Calculate the NPV and show your reasoning step by step. The CoT response will:

1. Identify each cash flow and its year.
2. State the discount factor formula and apply it to each year.
3. Compute the present value of each inflow.
4. Sum the inflows and subtract the initial investment.
5. State the final NPV and flag any rounding.

The arithmetic is the same. The value is the audit trail. When the model is wrong — and on multi-step maths it sometimes is — you can find the line where it went wrong and correct it, rather than discarding the whole answer.

Clearing context

Long conversations accumulate context. By turn fifteen, the model is silently weighting everything you said in the first ten turns — including the assumptions you have since moved past. The result is context drift: responses get less focused, less specific, more contaminated by earlier framings.

The fix is simple. When you change topics or notice the responses degrading, start a new chat (or use /clear if your client supports it) and restate the objective, the constraints, and the desired output cleanly. The two minutes you spend rebuilding context are repaid in sharper responses for the next half hour.

Working language — Portuguese or English?

Modern LLMs are not separate per-language models; they are one multilingual system with most of their training data in English. That asymmetry has practical consequences for which language to prompt in.

The rule of thumb is straightforward: prompt in the language with more high-quality training data on the specific topic. For PMC's work, that is English for almost everything technical and Portuguese only when local context is genuinely the point.

Skills — packaging the prompts you reuse

After you have written the same CSI-FBI scaffold five times, you should not be writing it a sixth. Modern AI clients (Claude is the most polished example) support skills — packaged instruction sets that load automatically when relevant, so the next prompt can be a single sentence.

A skill is, conceptually, just a saved prompt with a trigger condition. It contains:

A representative example — the kind of skill a credit analyst would build once and use for the rest of the semester — looks roughly like this:

Once packaged, the analyst types "Run Credit Risk Memo on issuer X" and gets a memo in the firm's house style. The thirty minutes spent building the skill is paid back the second time it is used.

Privacy — what you put in, you have given away

The single largest risk in using AI tools at PMC is leaking material you should not have shared. The free tiers of every consumer chatbot train on user inputs by default, retain conversations for indefinite periods, and offer no enterprise-grade controls. The risk is not theoretical — it has happened at large firms with material consequences.

The defence is layered. Most of it is operator discipline, not tool selection.

For genuinely sensitive work — anything under NDA, anything pre-earnings, anything that would embarrass PMC if it leaked — the right answer is not to use a consumer chatbot at all. Run a model locally instead.

Running a model on your laptop

Ollama is the standard tooling for local LLMs. Combined with Docker, it gives you a model that runs entirely on your machine — no API calls, no logs on someone else's servers, no training on your input.

The whole setup is three commands. Install Docker from the official site, then in a terminal:

# Pull and run Ollama in a Docker container
docker run -d -v ollama:/root/.ollama -p 11434:11434 \
  --name ollama ollama/ollama

# Run a model interactively
docker exec -it ollama ollama run llama3.2
>>> <your prompt here>
>>> /bye

Local models trade some quality for total privacy. For sketching, summarising, and reformatting, modern 7-to-13-billion-parameter models are good enough. For final analytical work on a real deal, the quality gap with frontier models still matters — but for anything genuinely sensitive, "good enough on your laptop" beats "excellent in someone else's logs."

Where this is heading — agentic AI

Up to this point everything has been conversational — you ask, the model answers, you decide what to do next. The next layer, increasingly real, is agentic: AI that not only answers but acts. Reads your inbox. Schedules the meeting. Drafts the reply. Browses the website. Runs the script.

A representative example, drawn from the workshop, is the OpenClaw project (openclaw.ai) — an open-source local agent platform that combines a chat interface with browser automation, file-system access, and persistent memory. A single instruction like "review my unread emails, summarise the urgent finance requests, schedule a meeting with the professor tomorrow afternoon, and prepare a draft reply" becomes a multi-step plan that the agent executes, surfacing the draft for your approval.

Agentic tooling is moving fast and the failure modes are not yet well understood. For PMC work, the conservative posture is: experiment with these tools on low-stakes personal tasks (calendar, inbox triage, research scraping) and let the high-stakes finance workflows mature on the conversational side before moving them to autonomous execution.

What to take into your next prompt

Six habits that, taken together, separate analysts who get useful output from analysts who get plausible filler.

The original workshop deck is linked at the top of this page. Open it for the diagrams — the token-to-vector walkthrough and the privacy matrix in particular are worth reading in their original form.