AI inside the walls: building agents when the data cannot leave
Fintechs and financial services can't send customer data to a SaaS AI tool. What actually changes in the architecture, and the three problems that survive the constraint.
by Zechim
Most AI vendor conversations in financial services end the same way. The demo is good, the team is interested, and then someone from risk asks where the data goes. The answer is "our cloud", and the conversation is over.
That is the right instinct. It is also why financial teams end up believing AI is not for them, which is wrong. The constraint is real, and it changes the architecture. It does not remove the use cases.
The constraint, stated properly
The internal policy is usually some version of: customer data does not leave our infrastructure, every access is logged, and we must be able to explain any automated decision to a regulator or an auditor.
Three consequences follow.
Deployment is not optional. The model runs inside your VPC or on infrastructure you control, or it does not run. That rules out most SaaS AI products, which is fine, because it does not rule out the models themselves. Every serious provider offers a deployment path that keeps data in your boundary, and open-weight models run wherever you put them.
Logging is a feature, not an afterthought. Every prompt, every tool call, every piece of retrieved data, every response. With personal data masked in the log itself, not just in the UI. If you cannot reconstruct why the system said what it said, six months later, you do not have an auditable system.
Autonomy has a ceiling. An agent can gather, summarize, propose, and draft. Where money moves or a customer is denied something, a human signs. This is not a technical limitation, it is a governance choice, and building the handoff properly is most of the design work.
The three problems worth solving anyway
Support that scales with headcount
Support teams in financial services grow in proportion to the customer base, because the questions are repetitive but the answers are specific. Balance, statement, status of an operation, second copy of a document. The existing bot says "I did not understand that" more often than it helps, so customers learn to skip straight to the human, and the bot becomes a speed bump.
The difference between that bot and an agent is data access. A scripted bot matches keywords against a decision tree. An agent reads the question, queries the actual system of record for that customer, and answers with their real number. When the question touches something sensitive, or when confidence is low, it hands over to a person with the conversation already summarized.
Every turn goes to an audit log. Personal data is masked before the log is written.
Fraud review that makes honest customers wait
An operation trips a risk rule and goes into the queue. An analyst gets to it eventually. Meanwhile the legitimate customer, who is the overwhelming majority of that queue, sits blocked and starts to consider your competitor.
An agent can open the case immediately: contact the customer, request the documentation, validate what can be validated automatically against the sources you already subscribe to, and either clear the low-risk cases or hand the analyst a case that is already assembled. The analyst stops doing document collection and starts doing judgment, which is what you hired them for.
The escalation rule is the whole design. Nothing gets auto-denied. Clearing thresholds are set by your risk team, not by us, and they are visible and changeable without a deploy.
Analysis that lives in spreadsheets
Risk has a spreadsheet. Compliance has a different one. Sales has a third. Reconciliation between core banking, the BPO, and the ERP happens by hand at month end. Somebody asks about the P&L on a specific product line and the answer takes days, by which point the decision was made without it.
The fix here is the same one as in every other sector: land the sources in one warehouse, then put a conversational layer on top so that risk, compliance, and sales can ask in plain language and get an answer in seconds. What differs in financial services is what sits around it: row-level access control so people only query what their role permits, query logging, and the masking rules applied at the data layer rather than the presentation layer.
There is a fourth that comes up often enough to mention: drafting the textual sections of regulatory and accounting reports from structured data. The agent assembles, a human reviews and signs. Days become hours, and accountability stays exactly where it was.
Why the extra rigor is not a tax
Teams outside financial services sometimes treat this discipline as overhead. It is not. Access control, audit logs, masked PII, explicit escalation thresholds, and reproducible decisions are what let you leave a system running unattended without anxiety.
The financial version of this work is just the version where somebody checks. That has made our financial engagements better engineered than the ones where nobody was going to look.
The catalog of what we build for financial services has the full list with the guardrails spelled out.
If your policy says the data stays inside and you have been told that means no AI, thirty minutes is enough to map your stack and your regulatory situation and tell you what is actually available to you. NDA before the call if you need one.