The Fintech Trust Stack: What AI Changes About Building in Regulated Finance

The Fintech Trust Stack

In regulated finance, trust is not a feature you add. It is the product.

Strip away the app, the rates, the onboarding flow, and what a customer is actually buying is a belief: that their money and their data are being handled correctly by people and systems that will still be accountable tomorrow. Everything else is packaging on top of that belief.

For most of my career, I have built products where that belief was the entire game. Cloud access security and data loss prevention systems that decided what enterprise information could go where. Secure browsing used inside regulated institutions. Retirement products that touched other people’s savings, and later a fintech startup I founded from zero. The technology changed every few years. The underlying question never did: why should anyone trust this system with something that matters to them?

AI does not change that question. It changes where the answer is won or lost.

Trust has always been a stack

The trust that holds a fintech product together is not one thing. It is a stack of layers, each depending on the one beneath it. Data sits at the bottom. Accountability sits at the top. A weakness in a lower layer undermines everything above it, which is why a company with beautiful compliance reporting and a leaky data foundation is not actually trustworthy. It just looks that way until it doesn’t.

For most of fintech’s history, teams knew which layer was fragile. The hard problems lived near the bottom: securing data, controlling access, passing the audit. The upper layers were comparatively mechanical.

AI does not knock this stack over. It does something subtler and easier to miss. It moves the fragile layer. And most teams are still pouring their effort into defending the layer that used to be weak, rather than the one that is weak now. Walking the stack from the bottom up is the fastest way to see where the ground has shifted.

Layer 1: Data trust

The foundation has always been the data layer. Encryption, access control, PCI-DSS, knowing exactly where your sensitive records live and who can reach them. In my CASB and DLP years, this was most of the job: mapping where regulated data flowed and stopping it from going somewhere it shouldn’t.

Here is what AI changes. Your training data is now part of both your attack surface and your compliance surface. A model trained on customer financial data carries that data’s obligations forward into every decision it makes, and often into places your data governance was never designed to watch.

I spent years helping enterprises fight shadow IT, the unsanctioned tools employees adopted faster than security could track. Shadow AI is the same pattern with higher stakes. A team fine-tunes a model on a spreadsheet of customer records to ship a feature faster, and now regulated data lives inside model weights that no one has classified, inventoried, or consented for.

Data lineage used to answer one question: where is this record and who touched it. Now it has to answer a harder one: did this record train the model that made this decision, and was it ever permitted to? If you cannot answer that, you do not have a data governance program. You have a data governance program with an AI-shaped hole in the floor.

The product takeaway: treat your model’s data supply chain with the same rigor you already apply to your payment data supply chain. Same provenance discipline, same consent tracking, same inventory. It is not a new problem. It is your oldest problem wearing new clothes.

Layer 2: Decision trust

The next layer up is explainability. Can you say why the system did what it did?

This layer used to be tedious but simple. Fintech ran on rules engines. A declined application produced a reason code. Adverse-action notices under the Equal Credit Opportunity Act (ECOA) and the Fair Credit Reporting Act (FCRA) were a compliance chore, but a mechanical one, because the logic was written down and a human had approved it.

AI breaks this in a specific and dangerous way: a model can be more accurate than your old rules engine and completely unable to tell you why it reached a given decision. In a consumer product, that tradeoff might be acceptable. In regulated finance, it is often illegal. You cannot deny someone credit, freeze a transaction, or price a loan on logic you cannot explain to a regulator and, increasingly, to the customer. The U.S. regulator has been explicit that a creditor cannot hide behind a black-box model it does not understand, and in the EU, systems that evaluate creditworthiness are classified as high-risk under the AI Act, carrying an explicit right to a meaningful explanation of the decision.

This is why I treat explainability as a product constraint, not a compliance afterthought. Sometimes the correct product decision is the less accurate, more explainable model, because a decision you cannot defend is not a feature. It is a liability with a good demo.

There is a business edge to this too, not just a regulatory one. Think about false declines in fraud prevention. A model that is highly accurate in aggregate but opaque in the individual case will occasionally decline a legitimate customer at exactly the wrong moment, and then be unable to tell that customer why. You lose the transaction, the trust, and often the relationship. The accuracy metric looked great in the review. The customer still left.

The product takeaway: own the explainability budget explicitly. Decide, per decision type, how much interpretability you are willing to trade for accuracy, and treat that as a first-class product requirement rather than something the data science team optimizes away.

Layer 3: Access trust

Above data and decisions sits access: who, or what, is allowed to act.

For most of my career, this layer had two kinds of actors. Humans and services. The whole CASB discipline was built around governing them: who can touch what, from where, with which permissions, and how do you catch the over-broad grant before it becomes a breach.

AI introduces a third kind of actor, and this is the shift I think is most underappreciated. Autonomous agents that act on a customer’s behalf. An agent that moves money, opens accounts, disputes charges, or rebalances a portfolio is not a human and not a traditional service. It is something new sitting inside your access model.

And every failure mode I spent years mitigating comes back with it. Over-broad permissions. Standing access that never gets revoked. Invisible third-party connections. Except now the actor exploiting those weaknesses is not a person who takes coffee breaks. It is software that acts continuously, at machine speed, and does not get tired or cautious.

The product takeaway: design an agent’s authority the way you would design a new junior employee’s. Least privilege by default. A clearly scoped mandate. A complete audit trail of every action. And a way to revoke everything instantly when something looks wrong. If you would not give a new hire unsupervised, unlimited, unlogged access to customer accounts on their first day, do not give it to an agent either.

Layer 4: Perceived trust

Near the top of the stack is something quieter and easy to dismiss as soft: how safe the product feels, independent of how safe it actually is.

A product can be genuinely secure and feel alarming. It can be mediocre underneath and feel reassuring. This gap between real and perceived security has always existed, and good fintech design has always worked it deliberately.

AI widens the gap. When a customer knows that an algorithm, rather than a person, made the decision about their money, their mental model shifts. People extend a human loan officer a kind of grace they will not extend to a model. A judgment call from a person reads as fallible but fair. The same call from an opaque system reads as arbitrary, even when it is more accurate.

What restores trust here is not more accuracy. It is perceived control. Can the customer see the decision, question it, appeal it, and reach a human when it matters? Those affordances are not legal requirements dressed up as features. They are the difference between a customer who feels handled and one who feels processed.

The product takeaway: design the felt experience of an AI decision as carefully as you design its correctness. The moment a customer encounters an automated decision about their money is a trust event, and it deserves the same attention you would give a checkout flow.

Layer 5: Accountability trust

At the top of the stack is accountability. When something goes wrong, can you trace what happened, and is someone answerable for it?

This layer assumed deterministic systems. Same input, same output, every time. Incident response meant reading logs and finding the line of code or the misconfiguration responsible. Hard, but bounded.

Probabilistic systems fail probabilistically, and that is a genuinely different problem. Models drift. Performance degrades silently as the world shifts underneath the training data. A system that behaved correctly for a year can slide into unfair or simply wrong behavior without a single line of code changing. Model risk management, once the concern of a few large banks living under SR 11-7, now applies to any fintech that lets a model make consequential decisions.

Auditability has to expand to match. It is no longer enough to log what the code did. You have to be able to answer, a year later, why the system reached a specific decision on a specific date, which means versioning your models and logging their decisions with the same discipline you already apply to financial transactions.

The product takeaway is one I keep coming back to: build the accountability layer before you need it, not after your first incident forces you to. Version your models. Log your decisions. Make sure that when a regulator, a customer, or your own team asks why the system did this, you have an answer that goes deeper than a shrug.

Governance is product design, not a brake

This is where I part ways with how the subject usually gets framed.

Most writing about AI in regulated finance treats governance as a brake: the thing the legal and risk teams bolt on at the end to slow the builders down. Under that framing, every control is friction, and the goal is to accept as little of it as you can get away with.

I have come to see it the other way around. In a regulated market, governance is the set of constraints that let you ship at all. The trust stack is not overhead you tolerate. It is product surface you design. This is not just my framing: the recognized standard, the NIST AI Risk Management Framework, is organized around the same characteristics the stack is built on, from accountability and transparency to explainability and managing harmful bias. The teams that win in fintech are not the ones that move fastest by ignoring the stack. They are the ones that treat each layer as something to build deliberately and well, because they understand that in this industry the constraints are the product.

That reframing changes who owns this work. If governance is a brake, it belongs to legal. If the trust stack is product surface, it belongs to product. I think it belongs to product, and I think the teams that internalize that will build the fintech products people actually trust over the next decade.

The stack is old. The fragile layer is new.

None of these five layers is new. Data, decisions, access, perception, accountability: fintech has always been built on them, in roughly this order, whether or not anyone drew the stack explicitly.

What AI changes is where the stack is weak. The fragile point has moved up from the data floor toward the decision and access layers, and into the newer territory of explaining and accounting for systems that do not behave deterministically. The failure most teams are about to make is defending the layer that used to be fragile while the ground gives way one level up.

Build for where trust breaks now. That is the whole job, and it always has been. The only thing that ever changes is where the break is.