AI in financial services: the decision was already regulated
Financial services is the sector where the most important constraint has nothing to do with artificial intelligence. Almost every decision worth automating here already has a regulator with expectations attached to it: explain the outcome to the customer, keep a record of why, treat comparable cases consistently, and be able to demonstrate all three later. Those expectations predate the technology entirely and they do not relax because the process changed. That single fact reorders a project. A rulebook explains itself by construction; a probabilistic system does not, so the explanation has to be designed in from the beginning rather than added once someone asks for it. Teams that treat explainability as a compliance deliverable at the end discover that the system they built cannot produce one, and the remedy is a rebuild rather than a document.
Financial services, in short
| The constraint | Every decision that touches a customer outcome already has a regulator with expectations about explanation and record-keeping, and those expectations predate the technology. |
|---|---|
| The distraction | Fraud detection, which is already well served by existing models and is rarely where the unmet need is. |
| A first project that works | Document extraction in onboarding or claims: high volume, checkable output, and a person reviewing the result anyway. |
| Where ground truth lives | Cases already adjudicated by a human, with the reasoning recorded. Most institutions have years of this and have never used it as an evaluation set. |
What shows up most often, not a description of any particular organisation. No named clients and no case studies: see editorial policy.
Explanation is an architectural requirement
The question a regulator asks is not whether the model is accurate in aggregate. It is why this customer received this outcome, and a system that cannot answer at the level of the individual case has a problem no accuracy figure resolves.
This has concrete design consequences. Retrieval has to record which sources informed an answer, not merely produce a good one. The reviewer's screen has to show the basis, not only the conclusion, because a human oversight step where the human cannot see the reasoning is oversight in name only. And the log has to retain enough to reconstruct a decision months later, when the model version has changed.
None of this is expensive if decided at the start. All of it is close to a rebuild if retrofitted, which is why the classification question, what decision does this system participate in and who already regulates it, belongs in week one rather than in the review.
Model risk governance, which is a real advantage in disguise
Institutions with a mature model validation function often move faster on these projects than smaller ones, which surprises teams who expect size to mean slowness.
The reason is that the process exists. There is a defined path for introducing a model, a team whose job is to challenge it, and an established idea of what evidence is sufficient. A project entering that path is slowed by a known amount. A project at an institution inventing the process is slowed by an unknown one, and unknown is worse for planning even when the average is shorter.
The practical step is to find that function in week one and ask what they will need, rather than presenting them with a finished system. Validation teams asked early are collaborators; asked late they are the last gate before a deadline, which is a bad position for everyone.
Why the first project is document work
Onboarding packs, claims files, loan applications, corporate actions. High volume, structured output, a person reviewing the result anyway, and a decision that is checkable field by field.
Each of those properties matters. Volume makes the saving real. Structured output makes quality measurable rather than a matter of opinion. An existing human review means the system is not the last line of defence on day one. And field-level checkability means a disagreement about quality is settled by looking rather than by arguing.
Fraud detection has none of those properties and attracts the attention anyway. It is already served by mature models with a team that owns them, so a new system arrives as a competitor to something that works. The unmet need in this sector is nearly always in the unglamorous document layer, which is where the people actually are.
The archive nobody thinks of as data
Every institution holds years of adjudicated cases with the reasoning recorded, because retaining them is required. That archive is the evaluation set, and it is sitting there unused.
Building from it does two things at once. It gives a measurement instrument grounded in decisions the institution already stands behind, and it surfaces the internal disagreements: cases where two adjudicators decided differently on similar facts are visible immediately, and that finding is frequently more valuable to the business than the system.
The obstacle is the usual one. The archive belongs to a team with its own priorities, and access is a conversation rather than a ticket, which is exactly what stage two is about in every sector and is slowest in this one.
