Why guardrails matter more than capabilities
Most AI demos show what an agent can do. In FinTech, the more important question is what it should not do. A support bot that gives investment advice, discusses competitors, or fails to escalate a fraud report is not just unhelpful — it creates regulatory, legal, and reputational risk.
The objective was to build a support agent that is genuinely useful for account queries, but equally rigorous about what it refuses — with every refusal visible, labelled, and explainable to a compliance team or product reviewer.
The Risk
An unguardrailed support bot in FinTech can inadvertently give regulated financial advice, fail to escalate fraud, or be manipulated via prompt injection — each carrying serious regulatory consequences under FCA rules.
The Objective
A grounded support agent with six active guardrails — each with a distinct trigger pattern, a scripted response, and a visible UI indicator — so every refusal is auditable, not invisible.
What the agent blocks and why
Each guardrail targets a specific failure mode. The UI makes them visible — when a guardrail fires, the response bubble changes colour and shows a labelled tag so a hiring manager, compliance reviewer, or product stakeholder can see exactly which rule triggered.
Detects any mention of unauthorised transactions, account compromise, scams, or suspicious contact. Immediately directs to freeze card and call the 24/7 fraud line. Does not attempt to resolve in chat.
Blocks any request for investment recommendations, savings decisions, or market opinions. Redirects to a qualified financial adviser. Required under FCA regulations for non-advised services.
Detects mentions of Monzo, Revolut, Starling, Wise, and major UK banks. Refuses to compare or comment. Redirects to Finsera features. Protects against both commercial and reputational risk.
Politely declines any query unrelated to Finsera banking and payments. Prevents scope creep and keeps the agent focused on its designated support function.
Detects attempts to override instructions, reveal the system prompt, or change the agent's identity. Responds with a security notice and refuses to comply. Critical for trust in a regulated context.
Detects customer distress or self-harm signals. Responds with empathy and provides Samaritans contact details. Required under FCA Consumer Duty regulations for fair treatment of vulnerable customers.
When multiple guardrails could fire
The system prompt defines an explicit priority order. When a message could trigger multiple guardrails simultaneously — for example, a distressed customer mentioning fraud — the agent follows this hierarchy:
Always fires first. No other guardrail overrides a fraud signal. Immediate human handoff every time.
Second priority. A customer in crisis gets a human-centred response before any account query is addressed.
Third. Manipulation attempts are blocked before the agent processes any content from the message.
Advice requests are refused cleanly with a redirect to a qualified adviser.
Competitor mentions redirected back to Finsera without commentary or comparison.
Everything else outside scope is politely declined and redirected.
How the guardrails are engineered
Each guardrail is implemented as a named rule in the system prompt with three components: a trigger definition (what to detect), a required response format (what to say), and a machine-readable tag (what the UI renders). The tag pattern [GUARDRAIL:TYPE] is parsed by the front end to apply the correct visual treatment.
// Each guardrail follows this pattern: GUARDRAIL 1 — FRAUD ESCALATION (HIGHEST PRIORITY) Triggers: "unauthorised transaction", "been scammed", "account hacked", "suspicious call from Finsera"... Required response format: "[GUARDRAIL:FRAUD] 🚨 This sounds like an urgent security issue..." // UI parses [GUARDRAIL:FRAUD] → applies red bubble + fraud label // Priority order enforced — fraud always fires before any other rule // Scripted response — no paraphrasing allowed
What this agent teaches
Six production-grade guardrails with explicit triggers, scripted responses, and priority ordering — the same pattern used in enterprise AI deployments in regulated industries.
Fraud detection triggers an immediate human handoff with specific instructions — not a generic "contact support" message. The escalation path is defined, tested, and visible.
All answers come from the Finsera knowledge base embedded in the system prompt. The agent cannot speculate, guess, or draw on general banking knowledge.
Detects and blocks attempts to override instructions, reveal internal configuration, or manipulate the agent's identity — a critical security requirement for any production AI system.
Guardrails map directly to FCA regulatory requirements — no regulated advice, fair treatment of vulnerable customers, fraud escalation. Compliance is baked into the agent design, not bolted on.
Every guardrail trigger is labelled and colour-coded in the UI. A compliance officer, product reviewer, or hiring manager can see exactly which rule fired and why — no black box.
What I would do differently
Guardrail triggers need to be exhaustive, not illustrative. The initial fraud trigger list was too narrow. Real customers describe fraud in dozens of ways — "someone used my card," "a transaction I don't recognise," "I think I've been hacked." In production, trigger lists need to be built from real support ticket data, not intuition.
Scripted escalation responses must be non-negotiable. Allowing the model to paraphrase a fraud escalation response is a liability. The exact wording — especially the fraud line number and the instruction not to make further transactions — must be reproduced verbatim every time. Scripted responses remove model discretion where it could cause harm.
Priority ordering is a product decision, not a technical one. Deciding that fraud beats distress, and distress beats injection, is a deliberate choice about what matters most to the business and the customer. In production, this priority order should be reviewed by legal, compliance, and customer experience teams — not just engineering.
Visible guardrails build trust with regulators. Making guardrail triggers visible in the UI is not just a demo feature — it's a compliance asset. If a regulator asks "how do you ensure your AI doesn't give investment advice?", being able to show a logged, labelled, colour-coded refusal in every session is far more compelling than describing a prompt rule.
Prompt injection is underestimated in enterprise AI. Most teams focus on what the agent can do — almost none think about what a malicious user can force it to do. In FinTech especially, where an injected instruction could expose account data or suppress a fraud alert, prompt injection defence is not optional. It belongs in the design brief, not the security review.