A working guide to generative and agentic AI in finance

How the capabilities build. Machine learning predicts from data, such as whether a borrower will repay. Deep learning reads more complex patterns, such as documents or transaction sequences. Generative AI produces content, such as a draft credit memo. Agents use a model to select steps and call tools to carry out a task, such as gathering information, drafting a payment and submitting it for approval. The categories overlap and build on each other, and moving down the list does not automatically make a system better.

What changes when it can act. A chatbot gives a wrong answer on a screen, and a person can still ignore it. An agent takes a wrong action in a system, and it is already done. The convenience and the risk are the same feature. A research assistant that can only read documents has fewer ways to cause harm than one that can also send emails or place orders.

Check the whole task. An agent takes several steps for one request, and an early mistake flows into the later ones. If ten steps each succeed ninety-five per cent of the time and every one must succeed, the whole task completes about sixty per cent of the time. So measure success on complete tasks, and check that the system stayed within its permissions. Before reaching for an agent, ask whether the steps could be written as an ordinary workflow; a known sequence is easier to test and control.

Related on this site: agentic and generative AI for finance, the five S's of AI, and governing agentic AI.

In the ebook: Agentic and Generative AI for Finance.

One token at a time. A text model works by predicting the next token, a piece of text that might be a word, part of a word, or punctuation. Given the text so far it scores every possible next token, a method picks one, and it runs the loop again on the longer text. It does not have a finished reply stored anywhere before it begins.

Fluent is not the same as true. The process does not, by itself, check the answer against an authoritative record, so the same confident tone can carry a correct date and an invented one. These unsupported outputs are often called hallucinations. Tone is no substitute for verification: a confident explanation of a covenant needs checking against the agreement, just as a hesitant one does.

What training changes, and what it does not. Training happens in stages: pre-training learns the language from a huge corpus, fine-tuning learns the format from good answers, and preference tuning steers the model toward what people prefer. This improves how it follows instructions and refuses unsafe requests, but a helpful manner does not tell you a particular answer is correct, and a restriction that lives only in the model's instructions can fail under an unfamiliar or misleading input.

The window is all it sees. For one request the model works only from its context window: the application instructions, the user's message, the conversation so far, and any documents fetched for it. It has no memory between calls. More text is not always better, and models often use the start and end of a long input better than the middle, so test whether your system actually uses the material you supply.

Why the same prompt can differ. A decoding setting picks among the scored tokens: greedy decoding always takes the top one, sampling draws in proportion to the odds, and temperature changes how varied that choice is. None of these check whether a statement is true. For wording that must be exact, such as an approved disclosure, keep it in a controlled template rather than asking the model to regenerate it identically.

Related on this site: the risk of made-up answers, and agentic and generative AI for finance.

In the ebook: Agentic and Generative AI for Finance.

Its knowledge is frozen. During ordinary use the model's parameters are not updated each time a document changes, so it cannot know last week's fee or your private files unless you put them in its context window. Retraining is often unnecessary for this job; you can supply the relevant document with the question instead.

Retrieve, then generate. Retrieval-augmented generation, usually shortened to RAG, searches a document store with the question, selects the passages that match, and asks the model to answer from them. Updating the store makes a new fee available without retraining, but the update must reach the search index, and the search still has to select the right version. The search must also respect permissions: a relevant document is not necessarily one this user is allowed to see.

The answer is only as good as the fetch. Right passages give a grounded, right answer; wrong passages give a confident, wrong answer that does not look like an error, just a fluent answer to the wrong source. A citation is not proof: the passage may concern a different product, or the model may have left out an exception, so check that the cited text supports the claim. Test retrieval and generation separately, then test the complete interaction, including questions with no supported answer and questions where more than one policy might apply.

Related on this site: making AI safe in practice, and data leakage risk.

In the ebook: Agentic and Generative AI for Finance.

One project, several tasks. An AI portfolio assistant might look up prices, pull financial ratios, build comparison tables, calculate risk measures, and answer open-ended questions. That sounds like one application, but it is several tasks, and they do not all need the same complexity. Looking up prices is a query; ratios a database query; tables and risk measures are code; only the open-ended analysis may need a language model. Pick the method per feature, not per project.

Start with input, output, and what if it's wrong. For each task, write down what goes in, the required result, and what happens if the result is wrong. A fixed limit check belongs in ordinary code; estimating default risk may suit a statistical model; summarising a long agreement is where a generative model may help. Where there is an authoritative source or a tested calculation, use it, and if a model calls it, check that it chose the right inputs and reported the result faithfully.

Include the cost of review. Drafting is a useful place to start because a person can check the output before it is used, but review takes time and can fail. A credit memo that reads well may still omit a guarantee or misstate a covenant, and if the reviewer has to redo most of the work, the time saved is small. Measure the whole task, preparation, generation, checking and correction, and test the workload you expect after rollout, not just a handful of carefully reviewed cases.

Related on this site: AI use cases in finance, and the use-case explorer.

In the ebook: Agentic and Generative AI for Finance.

The data shapes the task. Sorting applications by the material they process helps you choose methods and tests: rows and columns (credit scoring, transaction monitoring), text (contracts, customer chat, KYC review), images and signals (ID verification, OCR, biometrics), time series (market prices, transaction sequences), graphs (fraud rings, counterparty networks), and multimodal (an insurance claim with forms and photos). Each type leans toward different methods, and each has its own failure to look for. Classify the use by its material first, then check whether the proposed method suits it.

Where generative AI can help. Document work (extracting covenant terms, comparing policy versions, summarising filings, drafting a credit memo), research assistants that sort transcripts and news, customer-service drafting, coding assistants, and summaries that help review financial-crime alerts. The reviewer needs access to the source and a way to check that material details were not omitted. The risk rises when the answer goes straight to the customer, and a correct summary of an incomplete set of sources can still mislead.

Reuse checks, but not the assumptions. Several uses may retrieve documents, extract fields or draft replies, and can share parts of the evaluation process and common access controls. But each use still needs its own test cases and permissions, a policy assistant for staff and a customer chatbot are not the same. Record the task, owner, data sources, model and connected tools for every live use, and keep vendor features in that inventory too.

Related on this site: AI use cases in finance, AI in credit decisioning, and the use-case explorer.

In the ebook: Agentic and Generative AI for Finance.

What actually helps. A lot of the advice sold as prompt engineering turns it into a search for special phrases. The useful work is usually much more ordinary: state the task plainly, supply the context it needs, show an example of a good answer, and set the limits, including what to leave out and when to ask for clarification or decline. Writing a good prompt is closer to writing a specification than finding a magic word.

A prompt can only do part of the work. If the application retrieves the wrong filing, a well-written prompt produces a good summary of the wrong company; if the source is out of date, rewriting the instruction will not update it. Look at the failure before changing the prompt: missing sources may need better retrieval, incorrect arithmetic a calculation tool, uncertain error rates evaluation. Record what changed, and retest on the same cases.

A prompt is also an attack surface. Your instruction, the user's message and a fetched document reach the model as one stream of text, so an instruction hidden in a retrieved document can tell the assistant to ignore its task or disclose information. This is prompt injection. Clear instructions help, but critical restrictions need enforcing outside the model: a document should not be able to grant access to another customer's records.

A chatbot is a system, not a model. It is the model plus the surrounding application: the instructions, retrieval, session handling, access controls, response checks and records. The risk lives in how those parts are wired. Before release, try incomplete questions, unsupported requests, conflicting sources, and attempts to obtain another customer's information, and check what the user sees when the model or a connected service fails.

Related on this site: prompt injection risk, and making AI safe in practice.

In the ebook: Agentic and Generative AI for Finance.

One request becomes many calls. An agent combines a model with tools and the software that runs the process, often called the harness. The model proposes a next step, the application checks whether it is permitted and runs it, returns the result to the model, and continues until a stopping condition is met. So a request that looks like one question can involve many model calls and several external services, and some of those calls change records or send information outside the system. This plan, act, observe pattern underlies most agent designs.

The harness is part of the system. Between calls, the harness decides what the model sees next, trims or summarises a filling context window, and stores material the agent can retrieve later, its memory. Those choices change behaviour as much as the model does: a summary that drops a payment condition can send a capable model down the wrong path. Two applications on the same model can behave very differently, so record the harness version with the model version and retest when either changes.

Tools, and least privilege. A tool is a function the application makes available: search documents, query a database, prepare a payment instruction. The same model supports very different applications depending on the tools and their permissions. Give the agent the narrowest set that does the job, look inside the tool permissions (a database tool with unrestricted queries grants more than its name suggests), check the restrictions where the action runs, and separate preparing an action from executing it, a person releasing a drafted payment rather than the agent releasing it.

Stopping conditions. Set limits on steps, time, spending and actions before the task begins, and decide what happens when each is reached. Confirm the agent cannot extend its own limits, and that stopping it prevents further actions, remembering that ending the loop does not cancel requests already sent to external systems.

Related on this site: the anatomy of an AI investing agent, AI agent patterns, and governing agentic AI.

In the ebook: Agentic and Generative AI for Finance.

Each step looks fine, the path is wrong. An agent retrieves an out-of-date price, uses it in a calculation, and prepares an order. The calculation may be correct for the price it received, and the order may follow the calculation exactly. The result is still wrong, because the first input was wrong. Checking each component in isolation can miss that sequence, so examine how information passes between steps.

Three places a failure can start. The model (misreads a figure, invents a field, chooses an unsuitable step), a tool or source (a stale balance, an incomplete record, a failed call that the application must tell apart from a real answer), or an attacker (instructions hidden in a document or email the agent reads). The causes overlap, a misleading tool response can look like valid data and also carry an instruction, so the system needs checks at more than one point.

A reasonable interpretation can exceed the task. Asked to reduce technology exposure, an agent sells current holdings and also cancels future purchases. The issue is not a fabricated fact; it acted on an interpretation no one authorised. Make the scope explicit, which accounts, whether standing instructions can change, and then enforce it in the available actions, not just the prompt.

Watch the scale and the sequence. An action can be permitted once and inappropriate when repeated; reading one customer record differs from downloading thousands. Order matters too, an approval after a payment is released is no control, and a retry of a transaction whose response was lost can send it twice. Keep an accountable owner for the whole use, even where several teams build its parts.

Related on this site: agentic AI risks, agentic AI risk management, and governing agentic AI.

In the ebook: Agentic and Generative AI for Finance.

The unit of governance is the trajectory. An agent can report a completed payment accurately, the payment did go through, while having used the wrong account to gather information, skipped a required approval, and sent the payment twice. The final reply does not reveal those failures. You inspect the sequence of actions, often called the trajectory: what the system did, in what order, and with whose authority. The unit of governance is no longer the output; it is the trajectory.

Record enough to reconstruct the task. Keep the request, the model and application versions, tool calls and their inputs, returned results, approval decisions and retries, each with a timestamp and linked to one task reference. A generated explanation of why an action was proposed is not a substitute for a record of what was actually executed. Protect sensitive content in the logs, and check the records before launch, since a logging tool installed is not evidence that every important step is captured.

Review at three levels. The operation (did each tool read the right account and reject invalid inputs), the sequence (did the required checks and approvals happen before execution, was an approval still valid after the details changed), and the outcome (did the intended payment happen once, for the right amount and recipient, with nothing else changed). A pass at one level does not establish a pass at the others.

Enforce restrictions during execution. Validation before launch establishes that the system meets requirements under tested conditions, but the application still checks permissions and limits on each live task. For consequential actions, define when approval is required, show the reviewer the exact action, recipient, amount and evidence, and obtain approval again if those details change. Ask what the agent can do without further approval, and whether that scope matches the firm's tolerance for failure.

Related on this site: runtime governance for agentic AI, governing agentic AI, and agentic AI risks.

In the ebook: Agentic and Generative AI for Finance.

The test set changes shape, not the discipline. You can write the same valid summary in several ways, so comparing its wording with one reference answer will not tell you enough. But you can still build a test set: the document, the request, the facts that must be covered, and criteria for judging the response. These are usually called evals. Generative AI changes how some results are assessed; it does not remove the need for repeatable tests.

Build the tests from the work. Use representative questions, documents and tasks, including incomplete requests, outdated sources, conflicting information, and cases where the system should ask for help. For a covenant summary, specify which clauses must appear; for a fee question, record the correct amount, conditions and source. Public benchmarks help shortlist a model, but the release decision needs evidence from your own tasks, and some benchmark material may have appeared in training.

Check the grader. People can assess answers, and another model can help grade larger sets, usually called LLM-as-a-judge. But a model judge can miss errors or favour a response for its length, position or style. Give either grader clear criteria and examples, compare a sample of its grades with people who know the subject, especially where a grade would change the release decision, and record the judge's version and instructions.

Repeat, and weigh the consequences. A single successful run gives limited evidence; repeat tasks whose outputs or action sequences may vary, and report the number of attempts, successes and failures rather than a single rate. Examine the consequences too, one unauthorised transfer may matter more than several incomplete summaries, and an average score can hide that. Set acceptance criteria before reviewing results, keep the failed cases, and rerun after changes to the model, prompts, documents, tools or permissions.

Related on this site: AI testing, evaluation and assurance, and making AI safe in practice.

In the ebook: Agentic and Generative AI for Finance.

Enforce the critical rules in the application. A guardrail is a check around a request, source, proposed action or response that can block the step, remove sensitive information, or refer the case for review. Some use fixed rules, some use a model, and both need testing. For access and payment limits, enforce the rule directly in the service, not in the model's instructions.

Make human review workable. A reviewer needs enough time, evidence and authority to make a decision, usually called human-in-the-loop. Putting a person on an approval screen does not establish that they can catch an error. Show the exact action and the supporting records, place the review before the action it controls, and watch how review works: if reviewers rarely change a recommendation, that may mean the output is good, or the checking is weak.

Watch for changes and failures. Choose measures that relate to the task and have an owner who can act on them: input changes, output quality on a reviewed sample, blocked-request patterns, time and cost, and agent actions such as repeated attempts, unusual recipients or approval failures. An indicator you cannot act on is a statistic. A spike in blocked requests could be an attack, a change in usage, or a faulty guardrail update, so investigate it rather than assuming the cause.

Keep the evidence, and practise the response. Retain what you need to investigate an incident, with protection for sensitive content, then practise: can the team identify affected customers, stop further actions, and fall back when the main provider is unavailable? After an incident, add representative failures to the test set, so monitoring feeds back into evaluation.

Related on this site: making AI safe in practice, monitoring after go-live, and guardrails and metrics.

In the ebook: Agentic and Generative AI for Finance.

One system becomes many. A firm runs many chatbots and agents, built by different teams, often on the same few providers. Each has its own checks, but catching the failures that matter across all of them, the shared provider, the common weakness, the use no one registered, is the work of AI governance and risk management.

The machinery here sits inside that programme. This guide has stayed close to the machinery: how the model works, where it helps, and the checks around one chatbot or one agent. The wider programme, the lifecycle from proposal to retirement, the inventory, the organisation-wide risk framework, is where those checks are made consistent across the firm, without the paperwork growing faster than the AI. For finance in Singapore, the MAS AI Risk Management Guidelines set the expectations, finalised in October 2026 and in force from October 2027, phased.

Where to go next on this site. The companion self-paced courses and the full frameworks are openly available here: AI risk governance for risk and control functions for the second and third line, the executive guide for the board and senior management, the AIRG explained and the final AIRG, and the complete guide to AI risk management in finance in Singapore.

In ebooks: the companion books carry the wider programme, AI Risk Management for Risk and Compliance, AI Risk Management for Directors, and Scaling AI Governance.