Domain-native AI vs. generic AI and why the difference will determine whether banks merely automate work or genuinely change how banking works 

A generic AI can explain why a payment failed. A domain-native AI can resolve it.

That distinction may determine which banks achieve real transformation and which merely automate existing work.

Now ask the same AI to resolve the failure.

Suddenly, language is the easy part. The system must know which payment rail was used, whether the transaction was authorized, posted, settled, rejected, returned or reversed, which balance was evaluated, whether a fraud rule was triggered, what customer agreement applies, what evidence is required, who is allowed to act and how the bank will explain the outcome later.

That is the line banks are beginning to encounter.

On one side is AI that can talk about banking. On the other is AI that can operate within a bank.

The two are not the same.

Banking AI paradox

Banking has no shortage of AI activity. Employees are using assistants to summarize documents, draft emails, search knowledge, generate code and prepare meeting notes. These tools are useful. Some are extremely useful.

But usefulness is not transformation.

A faster employee is not necessarily a different operating model. A better chatbot is not necessarily a redesigned customer journey. A policy assistant is not yet a decision engine. And an impressive demonstration is not a production banking capability.

This explains the strange gap we see across the industry: AI capabilities are advancing rapidly, while many banks remain stuck in what might politely be called pilot abundance—and less politely, pilot purgatory.

McKinsey has made a similar observation: capturing material value requires banks to move beyond isolated use cases and rewire business domains, including their workflows, data, technology and operating models. Technology matters. But the surrounding system determines whether it creates enterprise value.

The debate, therefore, should not be “Which model is smartest?” It should be “What does the model need to understand, access, control and prove before we trust it with banking work?”

We are debating the wrong distinction

The phrase “domain-specific AI” often sends the conversation in the wrong direction. It sounds like a debate between a smaller specialist model and a larger general-purpose model.

That debate is already becoming obsolete.

A bank may use a frontier model, a smaller open model, a specialized financial model or several models routed dynamically by task. The underlying model will keep changing. The bank’s responsibility will not.

What matters is whether the complete AI system understands the domain in which it is being asked to operate.

That is why I prefer the term domain-native AI.

Domain-native AI is not simply an AI model trained on banking documents. It is an AI capability built around banking semantics, institution-specific knowledge, customer and transaction context, operational workflows, permissions, policies, risk thresholds and evidence requirements.

Put differently: domain nativeness is a system property—not simply a model property.

Generic AI and domain-native AI are built for different jobs

Generic AI is horizontal by design. That is its superpower. It can write, summarize, extract, translate, reason, search and code across thousands of contexts. It is ideal when the task is broad, the consequence is limited and a human remains responsible for validating the output.

Domain-native banking AI is designed for a narrower but more consequential purpose. It must understand the meaning of the request within a banking process and produce an outcome that is appropriate for that bank, that customer, that transaction and that moment.

A generic system is usually optimized to produce a plausible response.

A domain-native system must produce an appropriate banking outcome.

Figure 1. Generic AI is designed to answer broadly. Domain-native AI is designed to act appropriately within a banking context.

Banking context is not a better prompt

There is a comforting belief that we can make generic AI “banking ready” by giving it a longer prompt, attaching a few policy documents and adding a compliance disclaimer.

We cannot.

Prompts are useful. Retrieval is essential. Fine-tuning can improve task performance. But none of them, alone, creates the operating context required for banking.

A bank must assemble five types of context.

1. Banking semantics

The system must understand that authorized is not the same as posted; posted is not the same as settled; a return is not necessarily a reversal; available balance is not always ledger balance; a suspicious transaction is not automatically a fraudulent one; and a complaint is not always a dispute.

2. Institutional context

Two banks can offer the same product and still process it differently. Product configurations, core systems, customer agreements, risk appetite, approval authorities, geographic rules and exception practices vary. Industry knowledge is not bank knowledge.

3. Workflow state

A customer request is rarely a single interaction. It sits inside a process involving systems, queues, deadlines, handoffs, documents, approvals and downstream accounting consequences. The AI must know where the case is now—not merely what the customer typed.

4. Authority to act

Knowing what should happen is different from being authorized to make it happen. A banking AI needs identity, entitlements, transaction limits, segregation of duties, approval rules and clear escalation paths.

5. Evidence and accountability

The bank must be able to reconstruct what the AI saw, which policy and model version it used, what it recommended or executed, who approved it and what happened afterward. In banking, “the model said so” is not an explanation.

The five-layer domain-native banking AI stack

The architecture that emerges is less glamorous than a model launch—and far more important.

At the bottom sits foundation intelligence: language, reasoning and multimodal capability. Above it sits banking knowledge: regulations, procedures, data definitions, products and exception patterns. Then comes institutional context: the particular bank’s policies, customer state, product configuration and risk appetite. Next is workflow and tool integration: the controlled ability to retrieve data, update cases, route approvals, initiate actions and communicate outcomes. Finally, the entire system is enclosed by control and evidence: permissions, thresholds, monitoring, human intervention and auditability.

This stack explains why domain-native AI cannot be purchased as a single model license. It must be assembled as an institutional capability.

The best model can still be the wrong banking system.

Figure 2. The model is only the foundation. Banking transformation requires context, workflow integration, control and evidence.

One request, two outcomes

Return to the failed-payment question.

A generic AI can explain common causes, summarize the customer’s complaint and draft a polished response. That may reduce time for handling. It may improve consistency. It may help an employee think.

A domain-native AI must go further. It identifies the rail and transaction state. It distinguishes an authorization decline from a posting issue, a return from a reversal and a servicing issue from possible fraud. It retrieves the relevant records, applies the bank’s policy, determines deadlines and provisional actions, routes the case, records the evidence and prepares communication that reflects what the bank actually decided.

The difference is not that one system writes better English. The difference is that one system answers a question while the other participates in a controlled banking process.

Figure 3. Fluency creates a useful answer. Domain intelligence combines the answer with transaction state, policy, authority and workflow.

Why the distinction becomes more important as AI gains agency

The distinction matters even more as banks move from copilots that recommend to agents that act.

The 2026 Global AI in Financial Services Report from the Cambridge Centre for Alternative Finance found a meaningful split between financial services specialists and general-purpose AI providers. Financial services specifically vendors were more prevalent in event-detection capabilities such as anomaly and fraud detection. They also reported higher levels of human-on-the-loop or fully autonomous workflows. The report suggests a straightforward reason: workflow-specific providers embed regulatory rules, risk thresholds and compliance guardrails that allow more autonomy in well-defined tasks.

That does not prove specialist vendors are always better. It proves something more useful: autonomy follows context.

An AI can be trusted with more action only when the institution has reduced ambiguity around the data, rules, authority and expected outcome.

This is also why governance cannot sit outside the product as a final approval ceremony. NIST’s AI Risk Management Framework treats governance as a cross-cutting function across the AI lifecycle and emphasizes validity, reliability, safety, resilience, accountability, transparency, explainability and privacy. The U.S. Treasury has likewise highlighted financial-services-specific concerns involving operational risk, fraud, cybersecurity, data practices and sector-level coordination.

In practical terms, banking controls are not friction around domain-native AI. They are part of what makes the AI domain native.

The market is already moving in this direction

The more interesting banking AI deployments are not simply exposing a general model to employees. They are wrapping models in proprietary knowledge, approved data, institutional controls and daily workflows.

Morgan Stanley’s AskResearchGPT uses a general foundation model, but the value comes from grounding it in the firm’s proprietary research and placing it inside the workflows of investment-banking, sales-and-trading and research staff. JPMorganChase describes the next stage of its LLM Suite as integrating more internal data and combining generative AI with workflows so agents can complete sequences of actions. BNY describes Eliza as model-agnostic, connected to approved datasets and embedded within a governance framework—an architecture that deliberately separates the durable banking capability from whichever model is currently best.

These examples point out an important design principle: banks should not try to win by permanently attaching themselves to one model. They should build a domain-intelligence layer that can use different models while preserving the bank’s knowledge, controls, interfaces, evaluations and audit trail.

The model is rented intelligence. The domain layer is the bank’s asset.

Generic AI is not the enemy

None of this means every banking use case requires a bespoke model, deep workflow integration or autonomous execution.

That would be expensive, slow and unnecessary.

Generic AI is often the right answer for drafting, summarization, research, coding support, meeting notes and low-risk knowledge assistance. The mistake is not using generic AI. The mistake is asking it to perform domain-critical work without building the context and control that the work requires.

A useful rule is this:

The higher the financial, customer, operational or regulatory consequences, the more domain-native the AI must become.

Figure 4. Banking AI matures from task assistance to controlled execution and, eventually, AI-native process redesign.

What should banks do next?

The path forward is not to launch another enterprise chatbot and wait for transformation to appear. Banks need to build domain-native capabilities deliberately.

Choose a domain, not a collection of disconnected use cases

Start with a business domain such as payment exceptions, commercial onboarding, disputes, fraud operations or mortgage servicing. Map the end-to-end outcome, the decisions, the data, the systems, the controls and the handoffs. Then determine where AI changes the process—not merely where it can generate text.

Build a reusable banking-context layer

Convert product definitions, policies, procedures, data dictionaries, regulatory obligations, risk thresholds and exception logic into governed assets that can be reused across AI solutions. Retrieval is part of this layer, but so are semantics, identity, event state and policy logic.

Evaluate outcomes, not eloquence

A banking AI should not be judged mainly on whether its response sounds convincing. Test whether it identifies the right state, applies the right rule, chooses the right action, escalates the right exception and produces sufficient evidence. The unit of evaluation is the banking outcome.

Design control as a product capability

Human review, confidence thresholds, restricted actions, step-up approvals, reason codes, monitoring and incident response should be designed into the workflow from the beginning. A control that is added after the use case is built will usually be treated as an obstacle. A control designed with the use case becomes part of the experience.

Keep the model replaceable

The model market will continue to change. Banks should preserve the ability to route tasks across models and replace them without rebuilding the domain layer. The durable advantage lies in the bank’s data, workflow knowledge, evaluations and governance—not in permanent dependence on one provider.

The real transformation question

For the past two years, much of the AI conversation has focused on intelligence: bigger models, better reasoning, larger context windows and more capable agents.

Banks need to shift the conversation toward fitness for purpose.

Can the system understand the transaction state? Can it distinguish similar but legally different events? Can it access only the right data? Can it apply the bank’s policy? Can it act within its authority? Can a human intervene? Can the bank reconstruct the decision months later?

Those questions sound less exciting than a model demonstration. They are also the questions that determine whether AI reaches production.

The winners in banking AI will not be the institutions with access to the smartest models.

They will be the institutions that best connect intelligence to context, workflow, authority and accountability.

Models generate answers.

Domain-native AI delivers outcomes.