Financial services — consumer fintechAgentic text-to-SQL & MCP data integration

An analytics agent that turns plain-language questions into checked SQL and answers

Every data question at a large consumer fintech went through someone who could write SQL. We built an agent that writes the query, validates it, runs it inside the client’s own boundary and explains the result in chat — delivered in five weeks.

Three example business questions — sales by region last week, late deliveries this month, and tickets over SLA by team — go to a ReAct agent built on Agno, which reads the schema and domain terms, writes the SQL and retries when a query is rejected with a reason. Every query then passes four stages: a SQL validator with a table allow-list and row-limit policy, a SQL executor running over a private link with role-based access and row-level security, a result interpreter that turns rows into a plain-language answer, and secure delivery as a chat reply or a short-lived link. All of them share one context layer, connected through MCP, of cached schema metadata, domain terminology and session memory, while the database stays on the client side. Only validated SQL reaches the database and every query is logged for audit. Results along the bottom: 4 minutes from question to insight, 75% accuracy on 50+ queries, 90% of workflows completed, and two tries or fewer for 80% of users.
The user asks the way they would ask a colleague. The agent writes the SQL; the rules decide whether it runs.

Project snapshot

Client
A large consumer fintech platform
Industry
Financial services — consumer fintech
Business function
Business analytics across sales, logistics and operations
Challenge
Every data question from the business — sales by region, late deliveries, queues over SLA — needed someone who could write SQL against a large production schema. Question-to-insight took around ten minutes even when an analyst was free, and non-technical stakeholders could not get answers on their own.
Solution
A chat-based analytics agent built on Agno. A ReAct orchestrator reads cached schema metadata and a domain terminology store, writes the SQL and retries on feedback. A rule-based validator enforces a table allow-list, forbidden clauses and row limits; an executor runs approved queries over a private link under role-based access and row-level security; the result comes back as a plain-language answer or a short-lived encrypted link. MCP connects the agent to the data, and the client holds the encryption keys.
Result
Question-to-insight cut from 10 to 4 minutes, 75% accuracy across 50+ benchmark queries in three domains, 90% of agent workflows completed end to end, and 80% of stakeholders getting accurate results in two tries or fewer — delivered in five weeks.

Key outcomes

60%
Faster from question to insight
75%
Accuracy on the query benchmark
90%
Agent workflows completed end to end
80%
Of stakeholders answered in ≤ 2 tries

The client

A fintech where every team runs on data

A large consumer fintech platform. Its sales, logistics and operations teams make decisions from its data every day.

The data was there. Getting a number out of it was the slow part.

The challenge

Every question queued behind someone who writes SQL

A regional sales figure, a count of late deliveries, a list of queues over SLA — each one needed a person who knew both SQL and the schema. Even with an analyst free, going from question to insight took around ten minutes. Without one, the question waited.

The starting point

10 min
from question to insight, by hand
3
domains — sales, logistics, operations

The people with the questions were not the people who could answer them, so analysts spent their time as translators.

Constraints

What we had to design around

  • Data stays homeThe production database sits inside the client’s own boundary. Nothing could be copied out to make the model’s job easier — the agent had to send a query in and get only the result back.
  • Safe by constructionA language model writing SQL against live financial data is only safe if a bad query cannot run. Write statements, unbounded scans and tables outside the agreed set had to be impossible, not unlikely.
  • House languagePeople ask in the words the business uses, not the column names. The agent had to learn that vocabulary and keep it, so the same term means the same thing next week.
  • Keys and auditIn financial services the client holds the keys. Encryption had to use client-managed keys, and every query had to leave a record someone can inspect.
  • Where people already areBusiness users would not adopt another dashboard. Questions had to go in, and answers come out, in the chat app they already use every day.

Our approach

Let the model write SQL. Let rules decide if it runs.

Text-to-SQL fails quietly: a plausible query that answers the wrong question, or a correct one that scans a whole table. Better prompting reduces that. It does not remove it.

So we split generation from permission. One ReAct agent does the reasoning — reading the schema, mapping house terms to columns, writing and rewriting the query. A separate, rule-based validator decides what may run, and an executor inside the client’s boundary is the only thing that touches the data. MCP keeps the agent’s view of that data consistent, and a single agent kept the system simple enough to test end to end.

The solution

Five layers, from a chat message to a checked result

  1. Chat interface — A Telegram bot. The user types a question; the answer comes back as a short explanation, a formatted table, or a link to the full result when it is too large for a message.
  2. ReAct agent — Built on Agno. It reads the cached schema and the terminology store, reasons about which tables answer the question, writes the SQL, and rewrites it when the validator sends it back with a reason.
  3. SQL validator — Rule-based and schema-aware. A table allow-list, forbidden clauses and a row-limit policy — checked before anything touches the database, with a clear error fed back to the agent.
  4. Executor and MCP — Approved queries travel over a private link to an executor on the client side, which runs them under role-based access and row-level security. MCP gives the agent one consistent interface to the data and its metadata.
  5. Memory and security — A session store holds user instructions and conversation context; domain terms live as vector embeddings. Storage is encrypted with client-managed keys, large results go out as 15-minute signed links, and every query is audit-logged.
The system architecture. An end user sends a query to a Telegram bot, which calls an API gateway with a web application firewall over HTTPS. The gateway passes the request, signed with AWS Signature V4, to an LLM orchestrator running on ECS or Lambda that contains the ReAct agent and the SQL validator. The orchestrator writes only session data and metadata to a Redis or PostgreSQL session store, and sends validated SQL over Direct Connect or VPN to the client side, where a SQL executor with role-based access and row-level security runs the query against the client database. Results are uploaded as CSV or JSON to a KMS-encrypted S3 bucket, and the user receives a pre-signed URL that expires after 15 minutes.
The executor lives on the client side. Only validated SQL crosses the private link, and only an encrypted, expiring result comes back.
Seven epics over five weeks. Week one: the single-agent core — a ReAct orchestrator with the SQL generation and validation loop, session memory and retry on error. Week two, the foundation: a private link to the client database, an executor service, and cached schema metadata. Week three: a rule-based SQL validator with a table allow-list, forbidden clauses and a row-limit policy, then the Telegram chat interface with formatted answers and per-user sessions. Week four: session memory and a terminology store with vector embeddings for domain terms. Weeks four and five: client-managed encryption keys, encrypted volumes and objects, short-lived signed links and audit logging. Week five: documentation, training, automated deployment and handover.
The database link lands in week two because the validator, the chat interface and the memory all run against it.
5 weeksfrom kick-off to business users asking questions in chat, across seven epics

Responsible by design

Four rules for an agent near financial data

  • Validate

    No generated SQL runs unchecked.

    Every query passes the rule-based validator first. The model writes; the rules decide what is allowed to reach the database.

  • Contain

    The data never leaves the client’s boundary.

    The executor runs on the client side. The agent sees schema metadata and the rows it asked for — not a copy of the database.

  • Restrict

    Users see only what they are entitled to.

    Role-based access and row-level security apply to every query, so the agent cannot widen anyone’s view of the data by phrasing a question cleverly.

  • Record

    Every question leaves a trail.

    Queries are audit-logged and session stores hold metadata, not results. Anyone reviewing the system can see what was asked and what ran.

The first rule carries the others. The agent is free to be creative about how it phrases a query. It has no say in whether that query runs.

Results

What changed for the business teams

  • Question to insight cut from 10 minutes to 4 — 60% faster than writing the SQL by hand, and without waiting for an analyst to be free.
  • 75% accuracy across 50+ benchmark queries in three domains — sales, logistics and operations — answered from the live schema.
  • 90% of agent workflows completed end to end: generate, validate, run and interpret, with no hand-off to a person.
  • 80% of stakeholders got accurate results in two tries or fewer, asking in plain language through the chat interface — most of them people who do not write SQL.
  • Delivered in five weeks, with client-managed encryption, row-level security and audit logging in place from the start.

Analysts stopped translating routine questions into SQL, and the people asking stopped waiting for them.

Beyond the numbers

What else changes

A question that used to cost an analyst’s attention now costs a message. That changes which questions get asked. The follow-up — “and by week?” — happens in the same conversation instead of a new request.

And because the terminology store grows with use, every term the business teaches the agent makes the next question in that domain easier to answer correctly.

If your analysts spend their day translating questions into SQL

The first step is a benchmark: a few dozen of your real questions, run against your schema. That shows what an agent can answer before anything reaches production.