Where AI Actually Works in Banking: It's Not Where You Think

Everyone wants to make finance faster with AI. You hear it all the time: "Let's use a language model to automate this process." But if you're building anything in regulated lending, that instinct will steer you wrong.

Today—July 4, 2026—as more teams rush to add AI to their financial workflows, it's worth stepping back and asking: where does the AI actually belong? The answer might surprise you, especially if you've been assuming the language model should be the star of the show.

According to recent analysis of real lending workflows, a process that once took 2 to 3 weeks and produced a 40-page document is exactly the kind of thing companies want to automate with AI. But here's what most teams get wrong: they reach for the language model first. In practice, the language model is the last and smallest part of the pipeline. The hard parts come before it.

The Real Bottlenecks

When you actually map out a lending workflow, the work breaks into predictable stages. Most of the complexity isn't in drafting text—it's in everything that comes before.

The hard parts are:

• Ingesting messy documents reliably. Financial documents come in all shapes: PDFs, emails, image scans, sometimes handwritten notes. Getting data out of them without losing information is genuinely difficult.
• Extracting data into a canonical model. Once you've parsed a document, you need to fit its contents into a standard structure your system understands. That mapping process is nontrivial, especially when documents use inconsistent terminology.
• Validating and cross-reconciling the data. Financial accuracy means checking that numbers add up, that dates make sense, that conflicting information gets flagged. This is painstaking.
• Doing the actual financial calculations. Interest, fees, ratios, compliance thresholds—these must be computed precisely. One rounded number in the wrong place can break a loan decision.

Why Code Handles Money, Not Models

Here's the critical insight: financial calculations must be done in deterministic code, never by a language model. A model might quietly round a number wrong, apply a formula inconsistently, or make a decision that looks plausible but violates a regulation.

The order of operations in a well-designed system is:

1. Code ingests and validates. Deterministic software handles data parsing, extraction, and validation.
2. Code does the math. All financial calculations happen in code you can audit and test.
3. An LLM drafts prose. Once the numbers are solid, the model writes the loan summary, the risk explanation, or the customer-facing explanation.
4. A human owns the risk decision. Someone with real responsibility reviews the output and makes the final call.

That ordering isn't a limitation—under financial regulations like OSFI E-21, it's the only design allowed to exist. Regulators don't permit an AI model to own the decision; a human must.

The 10% Rule

Teams that actually win with AI in banking aren't the ones using the biggest model. They're the ones who know which 10% of the problem the model should touch.

If your workflow is document ingestion, data extraction, validation, calculation, and reporting, the language model probably owns the reporting part. Maybe the data extraction part if your documents are wildly varied and a model can learn the patterns. But the critical paths—validation and calculation—those stay in code.

This feels like a constraint, but it's actually a superpower. A team that understands this boundary spends its effort on the hard infrastructure work: building robust document pipelines, designing clean data models, writing tests for financial calculations. And then, at the end, the LLM makes the output more readable and natural.

A team that doesn't understand the boundary tries to make the model do everything, watches it make mistakes, and ends up rebuilding in code anyway—usually on a tight deadline, usually after a mistake made it to production.

Why This Matters Right Now

As AI hype continues in 2026, the pressure to "AI-ify" everything is real. Competitors are advertising AI features. Executives want faster turnaround. But in finance, faster and wrong is worse than slower and right.

The winning strategy isn't to move faster by using AI—it's to clarify what AI is actually good for in your workflow, and to do everything else correctly. That means investing in data infrastructure, validation, and compliance as much as (or more than) you invest in the language model itself.

Conclusion

The allure of AI in finance is understandable: imagine cutting a 3-week process down to hours. But the realistic payoff comes from understanding where AI actually helps and where deterministic code is required. The language model is powerful for drafting prose and finding patterns in messy input. For everything else—especially calculations and compliance—it's a footnote in a much larger system.

Merits

• Accuracy is preserved. Keeping calculations in deterministic code means financial decisions don't depend on LLM luck.
• Regulatory compliance is built in. OSFI E-21 and similar frameworks require human ownership; this architecture satisfies that requirement.
• The real problems get solved. Data ingestion and validation are hard; focusing engineering effort there fixes the actual bottleneck.
• LLM output is higher quality. When the model only handles prose, it's easier to test, review, and audit its output.
• Systems are easier to debug. A pipeline with clear boundaries between code and model is simpler to troubleshoot when something breaks.

Demerits

• Requires architectural discipline. Teams used to applying models end-to-end will need to refactor their thinking.
• More complex pipelines. Separating concerns means more components to build, integrate, and maintain.
• Still requires domain expertise. You can't hand the whole workflow to an ML team; financial domain knowledge is essential.
• Not "fully automated." A human still reviews the final decision—you won't eliminate the human reviewer.
• LLM doesn't seem to be "doing the work." The model feels like a small part of a larger system, which can be hard to sell if leadership expects AI to be the main event.

Caution

This article is educational and summarizes analysis from a DEV Community post. Any placeholder values in examples should be replaced with real, verified information before use. Readers should verify claims about OSFI E-21, regulatory requirements, and lending compliance against official regulatory sources and consult with legal and compliance experts before designing financial systems. Financial calculations and compliance are not areas for experimentation; always work with qualified professionals.

Frequently asked questions

• What is OSFI E-21 and why does it matter for AI in lending?
• How do you design a document ingestion pipeline for financial data?
• What are the data validation steps in a lending workflow?
• Can language models handle financial calculations accurately?
• Why do some teams try to use AI for calculations instead of code?
• How much of a lending workflow should be handled by an LLM?
• What does it mean to extract data into a "canonical model"?
• How do you reconcile conflicting information in financial documents?

Tags

#banking #ai #finance #lending #automation #fintech #regulation #LLM