AI in Banking: Where It Is Allowed to Decide

Banks have used statistical models for decades, so the arrival of machine learning is less of a departure than it appears. What has changed is that modern models are harder to explain, and explanation is a regulatory requirement rather than a nice-to-have in most of the decisions that matter.

That single fact determines where AI is genuinely deployable in banking and where it stalls in a proof of concept that everyone agreed was impressive.

The explainability requirement is specific

In most jurisdictions, a declined credit application entitles the applicant to a reason. Not a general description of the model, but the principal factors in their particular case. That is a requirement on the individual decision, and it rules out any approach where the answer cannot be attributed to inputs.

This is why credit decisioning remains dominated by scorecards and gradient-boosted trees with constrained interactions rather than deep networks. Not conservatism — the simpler model can produce a defensible reason code, and the alternative cannot. Post-hoc explanation methods produce plausible attributions, and "plausible" is a difficult position to defend to a regulator asking why this applicant was declined.

Fair lending is a testing obligation

Models can produce discriminatory outcomes without any protected attribute in the training data, because other variables correlate with them. Postcode carries ethnicity. Purchase patterns carry age and sometimes gender. A model given enough behavioural data will reconstruct what it was not given.

Testing for this is an ongoing obligation rather than a launch gate. It means measuring outcome disparities across protected groups, keeping the data needed to do that measurement even though you are not permitted to use it as an input, and having a documented process for what happens when a disparity appears. That last part is where most programmes are weakest — detecting a problem without an agreed remediation path leaves the organisation knowingly non-compliant, which is worse than not measuring.

Where AI is straightforwardly useful

Fraud detection is the clearest case. The decision is the bank's own risk appetite rather than an entitlement question, the feedback loop is fast because confirmed fraud arrives as labels, and the cost of a false positive is a declined transaction rather than a denied entitlement. Model performance improvements translate directly into money.

Anti-money-laundering triage is similarly good, though for a different reason: the model is not making the decision. It is ranking alerts for human investigators, most of which are false positives under traditional rules. Reordering a queue so investigators reach genuine cases sooner is valuable and carries none of the automated-decision burden.

Document processing — extracting terms from agreements, classifying correspondence, checking completeness of an application pack — is reliable, validatable, and replaces work people dislike. It also has natural checks, since extracted figures usually have to reconcile with something.

Customer service, with a boundary

Language models handle informational queries well: explaining a fee, describing a product, walking through a process. The boundary that needs enforcing is between explaining and advising, because financial advice is regulated and a model does not know when it has crossed the line.

The workable pattern is a hard scope restriction rather than a prompt instruction. The assistant answers from a defined corpus and hands off to a human for anything touching suitability, complaints or hardship. Hardship in particular matters — a customer in financial difficulty is one the bank has specific obligations toward, and routing them to a chatbot is both a compliance risk and a poor way to treat someone.

Model risk management applies

Banks in most jurisdictions operate under model risk frameworks that predate machine learning and apply to it regardless. Independent validation, documented assumptions and limitations, ongoing performance monitoring, and a defined owner.

Teams coming from a product background are often surprised by the weight of this, and it is the most common reason a successful pilot does not reach production. The practical response is to involve model risk at design time rather than presenting a finished model for approval — the documentation burden is far lower when the requirements shaped the build.

Drift is a control failure, not a maintenance task

A fraud model degrades because fraud adapts. A credit model degrades because economic conditions change. In banking, degradation is not merely a performance issue; a model operating outside its validated conditions is a control that is no longer working, with consequences for the risk position it supports.

That requires monitoring on input distributions as well as outcomes, and a defined threshold at which the model is revalidated or withdrawn. Deciding that threshold before deployment is much easier than deciding it during a period when performance is visibly deteriorating and the business depends on the model staying live.

Vendor models bring the same obligations

Buying a model rather than building one does not transfer the regulatory responsibility. If a third-party fraud engine or decisioning service influences outcomes for your customers, it falls inside your model risk framework, and you are the party the regulator asks.

That creates a due diligence requirement most procurement processes are not built for. You need to understand what the model was trained on, how it was validated, what its known limitations are, and how you would detect degradation — and vendors are frequently reluctant to disclose enough to answer those questions properly.

Two contractual provisions are worth insisting on: the right to audit model performance on your own population, and notification before material model changes. A vendor updating their model silently is a change to a control in your environment that you did not approve.

Data quality limits what is achievable

Banking data is rarely as clean as a modelling plan assumes. Customer records are duplicated across systems acquired at different times. Transaction descriptions are inconsistent free text. Historical labels reflect the decisions of previous processes, which means a model trained on them learns to reproduce those decisions rather than to improve on them.

That last point deserves attention in credit especially. If historical approvals were biased, a model trained to predict them will absorb that bias and still score well, since it reproduces the past faithfully. Accuracy against historical outcomes is not the same as correctness, and separating the two requires deliberate work rather than a better algorithm.

A reasonable sequence

Start where the decision is the bank's own and the feedback is fast: fraud, alert triage, document processing. Establish the model risk and monitoring practice on those, where the regulatory exposure is lower. Approach credit decisioning with explainability as a design constraint from the first line rather than a problem to solve later.

The pattern to avoid is a capable model built without the governance around it, presented for approval, and rejected — which is a common and expensive way to learn that the constraint was never the modelling.