Your AI Program Is Probably a Veneer

I've now sat through enough AI demos in financial services to recognize the shape of most of them.

A chatbot on the portal. A copilot that summarizes the case. Retrieval wired up to the documentation. A model that drafts the answer an analyst would have written anyway.

They are good demos. Some of them save real time. And almost none of them change what the product is.

The AI veneer: a bright AI layer of chatbot, copilot, RAG and analyst drafts above the same product underneath — fragmented systems still navigated, data still stale and duplicated, approvals and queues still defining cycle time, product changes still riding long release trains, implementation knowledge still tribal, controls still checked after the fact — Impressive at the edge. Untouched underneath.

The test I keep coming back to

Here is the question I ask after every demo now: if this thing can explain the broken process, can it safely change the outcome of that process?

Usually the answer is no. The same fragmented systems still have to be navigated. The same data is still stale or duplicated. The same approvals and queues still define the cycle time. The same product change still rides the same release train. The same implementation knowledge still lives in three people's heads. The same controls still get checked after the fact.

If AI can explain a broken process but cannot safely change its outcome, you have improved assistance. You have not transformed the product.

I've started calling this the AI veneer. Real activity at the edge, no structural change in cycle time, unit economics, adaptability or operational leverage. And it is remarkably easy to fund, because every conventional indicator looks healthy while it happens. Usage is up. Employees like it. There are pilots everywhere.

What "rewrite" does and doesn't mean

The word rewrite scares people in this industry, and it should. Nobody sane wants to replace a ledger, an authorization engine or a sanctions control with a language model. Ledger posting, settlement finality, entitlements, legal terms, accounting treatment: these have to be deterministic. Full stop.

So the thesis is narrower than it sounds, and I think more defensible: rewrite the intelligence layer, not the laws of finance.

The architecture I'd argue for is a dual system. A system of intelligence that interprets intent, reasons over context, plans the work, recommends or initiates bounded actions, and learns from outcomes. And a system of control and record that defines legal and financial truth, enforces hard constraints, executes the authorized state change, and preserves the evidence.

AI decides what the situation means and what should happen next, inside a mandate. Deterministic services decide what is permitted, make the change, and keep the record.

The model never becomes the ledger.

Dual system diagram: a system of intelligence that interprets intent, reasons across data, plans work, recommends bounded actions and learns from outcomes, separated by a control boundary from a system of control and record that defines legal and financial truth, enforces constraints and entitlements, executes authorized transactions, validates and audits, and maintains deterministic state — Every consequential action crosses the boundary. AI operates over context and invokes governed capabilities; deterministic services execute and keep the evidence.

Seven shifts, one principle

Once you accept that split, the rest follows. I count seven shifts a product has to make to become AI-native, and they are all versions of the same move: pull intelligence out of the places it's been hiding and give it a governed home.

From application-centric to capability-centric, so pricing, KYC, payment initiation and reconciliation are exposed as governed tools an orchestrator can compose. From database access to governed context, because a model with more data is not better; a model with the right context, scoped and traceable, is. From workflow automation to orchestration that chooses the bounded path, asks for what's missing and escalates uncertainty. From embedded rules to policy-as-code, externalized, versioned, testable. From model deployment to evaluation infrastructure that runs in production, not once before launch.

From human processing to human governance, with people at the points where judgment and accountability create value instead of transporting information between screens. And from releases to learning loops, where outcomes, overrides and corrections flow back into prompts, tools and policies through a governed mechanism.

Seven architectural shifts: application-centric to capability-centric, database access to governed context, workflow automation to orchestration, embedded rules to policy-as-code, model deployment to evaluation infrastructure, human processing to human governance, and product releases to learning loops — Seven shifts. One principle: separate intelligence from authority.

Stack those up and you get a reference architecture with seven layers. Systems of record at the bottom, then the event and integration fabric, then business capabilities as tools, then context and knowledge, then policy and guardrails, then agents and orchestration, then experience on top. The lower layers protect institutional truth. The upper layers add interpretation. Every consequential action crosses the control boundary between them.

Seven-layer AI-native financial product reference architecture, from systems of record, event and integration fabric, business capabilities as tools and context and knowledge below a deterministic control boundary, up to policy and guardrails, agents and orchestration, and experience above it — Seven layers. Truth at the bottom, interpretation on top, a control boundary in between.

Governance moves into the runtime

This is the part where AI programs in regulated industries usually stall, and it's the part I care most about.

Traditional governance is a sequence of committees, documents and approvals before release. Those still matter. But a control that only exists in a document cannot constrain what an agent does at 2 a.m. on a Tuesday. Governance has to be executable while the system runs.

Concretely: every agent and action runs under a scoped identity. Tool access is allowlisted and value-limited. Human approval is mandatory at checkpoints defined by risk, value and confidence. Retrieval comes from authoritative sources with provenance. Deterministic validation runs before every consequential action. Prompts, context, tool calls and policy decisions are traced. There's a kill switch at the agent, tool, workflow and model level. And there's a fallback to deterministic or human-led processing when a model, a provider or a context source fails.

Governance is not a gate around the architecture. Governance is part of the architecture.

If your risk team is reviewing a finished prototype, you've already discovered your constraints at the most expensive possible moment. I wrote about this from the delivery side in The One Number That Tells You If Your AI Deployment Team Is Actually Working; this is the same argument from the product side.

How you actually get there

Nobody should read "rewrite" as "big bang." The safer strategy is progressive recomposition, and it has a sequence.

Encapsulate the core behind governed APIs and events and stop adding coupling. Build the context layer without duplicating authority. Externalize policy into services you can test. Expose business capabilities as narrowly scoped tools. Then, and only then, introduce AI in shadow mode: it recommends, humans execute, you compare and collect the failure data. Move to bounded execution for low-risk actions inside explicit limits. Recompose the journey by removing the screens, queues and manual checks the intelligence made obsolete. Retire legacy workflow as traffic moves.

Eight-step migration path: encapsulate the core, create the context layer, externalize policy, expose capabilities as tools, then shadow mode, bounded execution, recompose the journey and retire legacy workflow — with steps five and six highlighted as the ones most programs skip — Progressive recomposition. Shadow mode before bounded execution, always.

Where to start matters as much as how. The domains worth rewriting first are the ones with heavy interpretive work, large exception queues, fragmented knowledge, cycle times measured in days because of handoffs, and, critically, a clean control boundary. Client onboarding and implementation. Fraud and disputes. KYC and AML operations. Payments exception handling. Product configuration and change. These are places where AI can change the operating model and deterministic controls can bound the risk.

Measure the product, not the AI

Adoption, prompts, users, hours saved. Useful. Insufficient. An AI-native rewrite should be held to product economics: time-to-onboard, cost per case, cost per implementation, first-time-right, capacity per team, loss avoided, audit findings, and the reuse rate of tools, agents, policies and context components across products.

The strategic test isn't "did employees use AI?" It's "did the product become faster, cheaper, safer, more adaptive and easier to change?"

Five-level maturity ladder for the AI-native rewrite: assisted, embedded, orchestrated, recomposed and adaptive platform, with most institutions still at level one where copilots and summaries assist but humans still execute — Five levels. Most institutions are at Level 1 and calling it transformation.

The uncomfortable part

Most institutions are at Level 1 of this. Copilots, summaries, search, humans still executing. And a lot of them are describing that as transformation.

The gap between Level 1 and Level 4, where journeys are redesigned and legacy workflow is actually removed, is not a model upgrade. It's a product decision, an architecture decision, a data-contract decision, a controls decision and an operating-model decision, made together, by people who are willing to retire something.

That last part is the tell. Before funding any of this, I'd want one question answered in writing: what legacy workflow or cost will actually be retired if this succeeds? If the answer is "nothing, it sits alongside," you're funding a veneer.

Quote card asking what legacy workflow or cost will actually be retired if this succeeds, noting that if the answer is nothing and it sits alongside, you're funding a veneer — The question I'd want answered in writing before funding any of this.

If AI sits on top of the legacy process instead of replacing it, you're not transforming the business. You're decorating the past.

Financial services has modernized channels, infrastructure, APIs, data platforms and cloud. The next modernization is deeper: the logic by which products interpret context, coordinate work, respond to exceptions and improve. The future product is neither purely deterministic nor purely probabilistic. It's a governed composition of both. AI for interpretation and orchestration. Deterministic systems for authority and execution. Humans for accountability and judgment.

That is the AI-native rewrite. It is a product transformation, not a feature release.

This article was developed with AI support and reflects my personal views and independent analysis. It is not written on behalf of, affiliated with, endorsed by, or representative of any current or former employer or organization with which I have been affiliated. The discussion draws solely on publicly available information, general industry observations, and conceptual analysis, and does not disclose or rely on confidential, proprietary, or non-public information.