Building an AI Assistant That Must Not Give Financial Advice

Guardrails for financial AI assistants are not a UX afterthought. They are a legal and architectural requirement. Here is how to build one that actually holds.

Why "Just Add a Disclaimer" Is Not Enough

A disclaimer at the bottom of a chat UI does not protect you. Regulators — FCA, SEBI, SEC — look at the substance of what a system outputs, not the fine print underneath it. If your AI assistant says "you should put 60% of your portfolio in equities given your age," that is financial advice, disclaimer or not, and in most jurisdictions it requires a licence to dispense.

The failure mode most teams hit is treating this as a prompt engineering problem: add "do not give financial advice" to the system prompt and ship it. That works until a user rephrases their question cleverly, or the model reasoning drifts mid-conversation, or you upgrade the underlying model and the guardrail behaviour shifts.

What you actually need is a layered architecture where no single point of failure can produce a compliant-looking but legally dangerous output.

What Counts as Financial Advice, Technically?

This matters because your intent classifier needs a precise target.

In most common law jurisdictions, financial advice is roughly: a recommendation to buy, sell, or hold a specific financial instrument, personalised to an individual's circumstances. Generic educational content ("index funds have historically returned around 7% annually after inflation in the US market") is not advice. "Given that you are 34 and earning £80,000 a year, you should buy VWRP" is advice.

The line is personalisation plus recommendation. Your classifier needs to detect both together, not either alone.

Some edge cases that trip teams up:

• Responding to "is this a good time to buy gold?" with a directional view is advice even without knowing the user's profile
• Comparing two funds on performance metrics and then saying "Fund A is better for your situation" is advice
• Repeating back a user's stated plan and saying "that sounds sensible" may be construed as endorsement in some jurisdictions

Get your legal team to produce 50–80 labelled examples covering the edge cases before you train or tune any classifier. Do not leave this to the engineers to define.

How Do You Actually Architect the Guardrail Layer?

This is where most of the engineering work sits.

Input Classification

Before any user query reaches your LLM, run it through a lightweight intent classifier. A fine-tuned distilbert-base-uncased or a small LoRA adapter on a 7B model works well here. You want latency under 50ms on this step because it runs synchronously on every message.

The classifier outputs one of three labels: safe, borderline, and block. Safe queries go straight to the LLM. Borderline queries get a modified system prompt that tightens the response constraints. Block queries return a canned response and log the event.

Train this classifier on your legal team's labelled examples plus synthetic data generated by asking an LLM to paraphrase known-bad queries in 20 different ways. Expect to need around 2,000–4,000 labelled examples to get F1 above 0.92 on your test set. Below that, you'll have too many false negatives in production.

Output Validation

The LLM's response goes through a second pass before it reaches the user. This is a separate model call, not a prompt trick on the same call. Use a smaller, faster model (GPT-4o-mini or an equivalent open-weight model running locally) with a binary classification prompt: does this response constitute financial advice?

If it flags positive, you have two options: suppress the response entirely and return a safe fallback, or run a rewrite pass. Rewrites are tempting but dangerous — a rewrite that removes the recommendation but leaves the reasoning intact can still be problematic. Suppression is safer. Log everything that gets suppressed for weekly review.

Conversation Memory Constraints

Multi-turn conversations create a compounding risk. A user can feed personal financial details across five messages and then ask a sixth question that, taken in isolation, looks safe. Your context window now contains a full financial profile and a question about asset allocation.

The fix is conversation-level state tracking. Tag any message where the user discloses financial details (income, asset holdings, age, risk appetite) and apply a stricter output policy for the remainder of that session. You can also periodically summarise and sanitise the context, stripping disclosed financials before passing history to the model.

What Does the Fallback UX Actually Look Like?

When a query is blocked or suppressed, you need a response that is honest, not condescending. "I can't help with that" without explanation causes users to rephrase and retry, which generates more blocked attempts and a worse dataset to review.

A better pattern: explain the category of thing you cannot do, and redirect to something you can do.

"I'm not able to recommend specific investments or tell you what to do with your money — that requires a licensed adviser. I can explain how index funds work, what expense ratios mean, or help you compare two products on factual criteria. Which of those would be useful?"

This reduces retry loops and gives users a legitimate path forward. It also keeps the assistant useful, which is the whole point.

Logging, Monitoring and Model Updates

Risk event	What to log	Review cadence
Input blocked	Query, user session ID, classifier confidence	Daily
Output suppressed	Full prompt + response, reason code	Daily
Borderline input passed	Query, modified prompt, final output	Weekly
Model update deployed	Before/after eval on held-out test set	Per deployment

The held-out test set is critical. Every time you update the underlying LLM, fine-tune the classifier, or change the system prompt, run the full guardrail eval before deploying. Model updates from providers change behaviour in ways that are not always documented. GPT-4 Turbo behaved meaningfully differently from GPT-4 on instruction-following tasks; assume any major version bump requires a fresh eval.

Set up automated regression tests that hit the classifier and output validator with your 50+ known-bad queries on every CI run. This catches prompt drift early.

Conclusion

The architecture is not complicated, but it requires discipline in three places: precise legal definitions of what you're blocking, a layered technical guardrail that doesn't rely on a single model to behave itself, and continuous eval tied to your deployment pipeline.

If you're designing this system now, start with the legal labelling exercise before writing any code. The classifier is only as good as its training signal, and that signal has to come from people who understand financial regulation, not from engineers guessing at edge cases.

If you want to talk through the classifier architecture or the output validation layer in more detail, the team at Sodio has built this kind of system and is happy to get into the specifics.

FAQ

Does adding "do not give financial advice" to the system prompt work as a guardrail? Not reliably. System prompt instructions can be circumvented through prompt injection, clever rephrasing, or multi-turn context manipulation. They also break silently when the underlying model is updated. A system prompt instruction is a starting point, not a control.

What's the difference between input classification and output validation — do I need both? Yes. Input classification is fast and catches obvious cases before they hit the LLM. Output validation catches cases where the model produces advice despite a safe-looking input. Each layer catches failures the other misses. Skipping either one leaves a meaningful gap.

How do I handle users who deliberately try to extract financial advice through indirect questions? Conversation-level state tracking helps here. Tag sessions where the user has disclosed personal financial details and apply tighter output policies. Log persistent attempts — a user sending 15 borderline queries in one session is a signal worth reviewing, both for product and compliance reasons.

What if the guardrail is too aggressive and blocks legitimate educational queries? Tune your classifier's decision threshold on a precision-recall curve, not just accuracy. For financial AI, you typically want higher recall on the "block" class, which means accepting some false positives. Track the false positive rate in your weekly review logs and adjust the borderline-to-block threshold based on real suppression data.

When does this architecture become the wrong choice? If you're building a tool strictly for licensed financial advisers who use it internally, the regulatory exposure is different and some of these constraints may be over-engineered for your context. The layered guardrail approach is designed for consumer-facing or semi-public deployments where users have no assumed professional context.

Have a project in mind? Contact Sodio Technologies to discuss your requirements and explore the right technology solution for your business.