why banks can't just use ChatGPT

i get this question more than almost any other.

a CTO at a bank or a fintech or an insurance company has seen the demos. they have used ChatGPT themselves. it is impressive. it handles complex queries, summarizes documents, generates reports. and it is available right now, via API, with no infrastructure investment required.

so why not just use it?

the answer is not simple. it involves regulation, architecture, data governance, and some fundamental properties of how large language models work in production. i want to try to give the complete answer here because the incomplete version, "it is a compliance issue," undersells how deep the problem actually goes.

the data problem

start with the most obvious issue. banking data is among the most tightly regulated data in existence.

in nepal, NRB directives govern how customer data can be stored, processed, and transmitted. in india, RBI frameworks impose similar constraints. in europe, GDPR. in the US, GLBA and FFIEC guidance. the details differ by jurisdiction but the core principle is consistent: you cannot send customer financial data to a third-party system without a set of legal, contractual, and technical safeguards that most API-based AI providers do not provide and are not designed to provide.

when you call the ChatGPT API with a prompt that contains a customer's transaction history, account balance, or identity information, that data travels to OpenAI's infrastructure, gets processed by their systems, and potentially, depending on your agreement terms, contributes to model training or is retained for some period. even in the best case, with a proper data processing agreement, you have moved regulated data outside your perimeter. that has audit implications, breach notification implications, and regulatory examination implications that most banks are not willing to accept.

this is not a hypothetical concern. it is the first thing a bank's legal and compliance team will flag, usually before the technical conversation has even started.

the explainability problem

the second issue is less discussed but more fundamental.

when a bank makes a credit decision, denies a loan, flags a transaction as suspicious, or freezes an account, it is legally required in most jurisdictions to be able to explain why. not in general terms. specifically. which factors led to the decision. how those factors were weighted. why the outcome was what it was.

large language models, as currently deployed, cannot provide this. not reliably, not in the form that regulators require.

you can prompt a model to explain its reasoning and it will produce an explanation. but that explanation is generated text. it is not a causal account of the computation that produced the decision. the model does not have access to a ground-truth explanation of why it produced a particular output. it has access to its weights and its context, and it generates text that sounds like an explanation.

this is fine for many applications. it is not fine for regulated financial decisions where the explanation is a legal requirement, not a nice-to-have.

the consistency problem

in production, large language models are not deterministic.

the same input, given to the same model, at two different times, will not necessarily produce the same output. the temperature parameter introduces stochasticity by design. even with temperature set to zero, model behavior can vary across versions, across hardware configurations, and as models are updated.

for a bank that needs to demonstrate to an examiner that its AI systems behave consistently and predictably, this is a significant problem. you cannot tell a regulator that your credit decisioning system "usually" produces the same answer for the same inputs. you need to be able to demonstrate that it produces the correct answer, consistently, and that you can detect when it does not.

this requires a level of evaluation infrastructure, version pinning, behavioral monitoring, and rollback capability that sits entirely outside what a standard API integration provides.

the latency and reliability problem

banking systems have availability and latency requirements that are non-negotiable.

a core banking system that processes transactions needs response times in the low hundreds of milliseconds. a KYC verification system needs to complete in seconds, not minutes. an account freeze triggered by fraud detection needs to happen before the fraudulent transaction completes.

api-based AI systems introduce an external network dependency into critical-path financial workflows. that dependency adds latency, adds a failure mode, and creates a situation where your uptime is bounded by the uptime of someone else's infrastructure. if OpenAI has a service disruption, your fraud detection goes down with it.

for most SaaS applications this is an acceptable tradeoff. for financial infrastructure it is not.

what actually has to happen

the combination of these constraints points toward a specific architecture.

the model has to run inside your perimeter. not the API. the actual model, running on hardware you control, in a data center you control or have a colocation agreement with, where you can make guarantees about data residency and access control.

this is what on-premises AI actually means. it means running inference infrastructure: the model itself, the serving layer, the evaluation and monitoring stack, the version management, all inside the institution's control boundary.

it also means the model has to be the right model. the model has to be small enough to run cost-effectively on the hardware available. it has to be fine-tuned or otherwise adapted to the specific domain and language requirements of the institution. it has to have been evaluated extensively on the types of inputs it will actually encounter in production, not just on generic benchmarks.

and it needs a governance layer. audit logging for every inference. version tracking. behavioral monitoring that flags when outputs are outside expected distributions. a clear rollback procedure.

none of this is exotic. all of it is engineering work that has to be done and maintained and updated as the model evolves.

the deeper issue

i think there is a mental model error that leads people to treat ChatGPT and enterprise AI as the same category of thing.

ChatGPT is a consumer product. it is designed for a user interacting with a general-purpose system through a chat interface. the failure mode is that it produces a bad answer. the consequence is that the user is mildly annoyed or mildly misled.

enterprise AI in a regulated industry is infrastructure. it is embedded in workflows where decisions have legal and financial consequences for real people. the failure mode is that it produces a wrong decision. the consequence can be a denied loan, an incorrect fraud flag that freezes a legitimate account, a regulatory fine, or a data breach.

these are not the same problem. they do not have the same solution. treating them as the same problem because they both involve large language models is like treating a calculator and a nuclear plant as the same engineering problem because they both involve electricity.

the interesting work in enterprise AI is not the model. the model is solved, or close enough to solved for most applications. the interesting work is the architecture, the governance, the evaluation infrastructure, the integration with existing systems, and the institutional trust-building that makes any of it usable in a context where being wrong actually matters.

that is the work we are doing.