From Data Pipeline to Decision Pipeline: Making Banking AI Explainable Before the Model Runs

AI governance keeps starting at the model layer, but explainability often starts with the file that fed the decision, before scoring ever runs.

If you work in financial services, AI is probably already making decisions for you. A loan gets approved, a transaction gets flagged for fraud, and often no human signs off in between. So, a fair question: when one of those models turns a customer down, could you give an auditor the specific reason for the decision, not a general description of how the system works?

If the honest answer is no, you are in good company, and the fix is not what you would expect. You do not need to be a machine-learning engineer or pry open the model to explain its call. The explanation an auditor wants starts earlier, with the data that fed the decision: where it came from, when it arrived, whether anyone checked it and who approved it before scoring ran. That part you can trace.

Explainability Starts Before Scoring

In many banking workflows, the data behind a decision does not stream in live; it arrives as a file, often a partner feed or a credit-bureau extract, handed off from an upstream system before the model touches anything. The score comes later. If that handoff is invisible, the score is a confident story about a number you cannot vouch for. Follow the file upstream, and you usually land on a ticket and a shared drive nobody owns. The decision may have already gone out, while the evidence behind it wasn’t reviewed.

A credit decision becomes explainable when the file behind it was demonstrably expected, checked, approved and logged before scoring ever began. Narrating the score after the fact is not the same thing.

Regulators have been saying a version of this for a decade. The industry keeps hearing it as a model problem. That is the whole point of BCBS 239, the Basel Committee’s principles for risk data aggregation and reporting: know your numbers, and be able to show your work.

How is that going? Not well. The Committee’s 2023 progress report assessed 31 of the world’s largest banks and found exactly two fully compliant.

Weak models were not the reason those banks fell short. They could not trace their own data. The report put the blame on fragmented IT, the connections between systems no team maintains.

SR 26-2, the 2026 interagency model risk guidance that replaced SR 11-7, presses from the other direction: sound development, validation, governance and controls. If the path a file took upstream is fuzzy, the model still runs. It just runs on an assumption (and “assumption” is a generous word for a guess).

U.S. and EU regulators have stopped treating this as optional. In the U.S., the Consumer Financial Protection Bureau told lenders in Circular 2022-03 that a complex or “black-box” model is not a hall pass: deny someone credit and you owe them the specific, accurate reason you relied on. You cannot name a reason you cannot trace. In the EU, the AI Act files credit scoring under high-risk and, from August 2026, expects documented data governance and automatic event logging.

Neither regulator is impressed by a clever model. They want the input path, governed and on the record.

The Transfer Layer Is Where Proof Lives

Between the system that sends the file and the model that scores it sits the transfer layer. It is not glamorous, which is exactly why it gets skipped. It is also where the evidence is born. Progress MOVEit Automation and Progress Automate MFT turn the file handoff into something you can audit instead of something you have to remember—the move gets recorded. That transfer record is what compliance and operations will want to see.

Let’s say a partner quietly changes a file format on a Tuesday, and the model starts making odd calls on Wednesday. Before anyone digs into the model’s scoring, the first thing worth ruling out is whether the upstream path changed at all. A Task Runs report in MOVEit Automation shows when a task executed and its completion status, offering visibility into whether a handoff occurred as scheduled. This is usually the fastest way to confirm the handoff moved. It will not solve the problem, yet it gives you somewhere defensible to start.

None of this requires your risk team to live in a transfer console. The automation layer exposes a REST API: a monitoring or governance, risk and compliance (GRC) system authenticates, then collects job details and status updates on a schedule and lands them next to the decisions they explain. The same interface runs the transfer reports your auditors will eventually request. One nightly call that copies task statuses into the audit workspace keeps the evidence current. Nobody stands up a second monitoring console, and nobody babysits a dashboard.

That does not mean turning every transfer into a project. Surface the handful of facts that either prove the file was handled correctly or catch when it was not:

Skip those, and explainability becomes paperwork you write after the incident, the worst possible time to write it.

The rule is blunt. If a file can change a decision, its status should be queryable before the decision engine ever touches it. Hold the score until the file clears validation, not the other way around.

The Skeptic Is Right About One Thing

A sharp skeptic will push back: the model already has monitoring and explainability tooling, plus human review, so the upstream plumbing is someone else’s problem. The tools are real and they matter. They also answer the wrong question. They inspect what the model did with the data, but none of them can prove the data earned its place in the decision to begin with.

That monitoring watches the model’s output and catches score drift. Whether a partner changed the schema, or a half-failed transfer sat behind an approval queue that never closed—that’s a different layer entirely, one output monitoring cannot reach.

The cost of such a blind spot is quiet: a stale, unapproved file clears as if it were clean and nobody notices until the gap surfaces months later, when an auditor asks for the record behind a decision and the answer is no one captured it.

Transfer status and validation outcomes belong in the decision record. Treating them as back-office plumbing buries the one artifact an auditor will actually ask for. An audit report that shows who changed what and when turns the transfer path from a story people tell into lineage a reviewer can inspect. Put that record where your risk and compliance teams already work, and you have given them something better than reassurance.

Before the next model review, make sure transfer status and validation outcomes are queryable inside the workflow system that owns the decision. Add audit history to the same view. If that record is still scattered across dashboards and email threads, the model is running ahead of its controls, and you are explaining decisions you cannot defend.

Learn more about the solutions from Progress Software: MOVEit for banking and Automate MFT for banking.