Owning the Explanation in Sell-Side Ops

Operational leaders in sell-side firms will likely recognize a scenario like this. The client onboarding team relies on an AI tool that triages documentation exceptions and flags most of them correctly. The trouble surfaces during a periodic regulatory review, when examiners pull a sample of onboarding decisions and ask the team to walk them through each one. In one file, the tool cleared a client account on a Tuesday and flagged the same account for review on Thursday, with nothing changed in between.

When issues emerge, examiners want to understand why. But the team using this AI tool can’t answer with certainty because the tool reasons from scratch on each run and keeps no run record of its path to either result. On its own, either decision might have been defensible, since a flag only sends the account to a person for review. Side by side, though, they reveal a result the tool couldn’t reproduce, making it hard to explain or stand behind.

Operations has to be able to explain any exception it clears or holds when asked by a client or an examiner. A trader can treat a model’s signal as one input and make the call. But when an AI agent in operations flags an account, that flag becomes the firm’s decision, and operations has to say why, on the record. In an agentic world, operations owes the same explanation of the tool’s reasoning as it would for an analyst’s.

This problem was central to my panel remarks at Sell Side Ops in London on September 17, 2026. In conversations after the panel and throughout the event, operations leaders returned to it from two directions. They asked how they can prove where their data came from, a question we hear repeatedly. They also wanted to know whether AI can deliver deterministic, reproducible outcomes, where the same input produces the same output through a process the team can validate.

One system at a time

The difficulty of tracing a result is often a symptom of the way most banks’ data architecture has evolved, one regulation, product launch, and acquisition at a time. Banks commonly bolt on each addition and rarely finish the integration beyond what is necessary. Over time, a single onboarding exception can involve the same client sitting in several systems under different identifiers. That fragmentation forces the team to reconcile records by hand, often on spreadsheets.

Supervisors have raised the bar on these issues, as well. In its guide on risk data aggregation and risk reporting, the ECB asks banks to track how data move and change from capture to report, and to keep risk reporting on time in a crisis without fragmented systems or manual aggregation slowing it down.ⁱ

Shorter settlement cycles add pressure, too. On October 11, 2027, the EU and U.K. move to T+1 settlement. ESMA has set December 7, 2026, as the first deadline for allocation and confirmation processes.ⁱⁱ In the U.S., central clearing of eligible Treasury cash trades begins on December 31, 2026, with eligible repo following on June 30, 2027. Those deadlines will further expose the cracks in records built one system at a time, because a team that traces breaks by hand has less time before a break becomes a failed settlement.

Explaining decisions

AI agents can take much of that manual work off the team, but examiners will still ask how individual decisions were made. When an analyst clears an exception, the file records who made the call and on what basis, so the bank can reconstruct it when that file turns up in an examiner’s sample. If an analyst makes an inconsistent call, the bank can find the error and retrain one person.

Once agents work the same queue, software makes those calls while the examiners’ questions stay the same. If an agent’s reasoning varies, the inconsistency repeats across every case the agent touches. Without a run record for each decision, the team can’t show examiners which cases it affected.

That limit explains why many operations teams exploring AI for documentation triage and exception handling have been cautious. When a market operations lead or an onboarding manager asks whether the team could explain a tool’s result to an examiner, the honest answer today is usually no. Keeping that tool out of production is the right call. However, the work stays manual, the backlog stays slow, and the desk keeps hiring for work that agents could absorb.

But the limit isn’t inevitable. Whether AI can be explained depends on how it’s built, and specifically on where the probabilistic work happens. The tool in the examiners’ sample reasoned afresh on every case, so its path could change from one run to the next. The alternative uses the model before any case comes through, to help discover the deterministic rule sets, sequencing, and tolerances the workflow will follow. Once a person has checked those rules, a harness, the governed layer that runs the workflow, enforces them on every case, so the team can reproduce any result and point to the exact rule that fired.

In onboarding, those rules still depend on the documents a client submits to open an account. The model reads each document and turns it into a simple set of recorded fields. The approved deterministic rule set then determines the account’s status from those fields. When examiners sample an account, the run record shows exactly what the model read and which rule fired. If the Tuesday and Thursday results differed, the team would see whether the extracted fields or the rule had changed.

Building the case for reproducible automation

Deterministic rule sets deliver reproducible answers only when the data they read stay consistent, too. A rule that checks an account’s status against a client record held in several systems, under different identifiers, can reach different answers depending on which version it reads. So, each core entity, whether a security, a counterparty, or an account, should have one governed record that every system and every rule reads from, rather than several versions reconciled after the fact. That record should have an owner with a name, someone whose job treats data as a product with internal clients, service levels, and accountability.

With that record in place, the team can trace any number’s lineage back through the systems that touched it. When a client or an examiner asks where a number came from, the team answers in minutes, where the same question used to take weeks and a task force. Banks that have built this base are adopting automation that more cautious banks hold back on and clear the same queues faster with the same level of control.

The head of operations at a global bank discussed the situation with me at Sell Side Ops. He shared that each product had its own operations team, which told technology what it needed, waited for the build, then passed its data along for someone else to use. In his view, that model can’t hold, because technology now shapes how operations work and data feed regulatory answers and client conversations in real time.

He wants operations, technology, and data in the same conversation. He also wants specialists who stay deep in one asset class and become fluent across the rest, because a client may call about collateral posted against an OTC derivative, a loan, and a structured credit product at once and needs one person to solve it. These views are increasingly common as banks respond to accelerating pressures, increased supervision, and broader cost and competitive pressures.

With governed records and a harness enforcing approved rule sets, the onboarding team in the examiners’ sample could have reproduced each result and shown the fields and rule behind it. We believe reproducibility has become the operations job itself, and the condition for automating the queues that careful managers have kept manual. Until that base exists, the manager who says no is still making the right call. Ask your own team whether, pressed by a client or an examiner about why an AI-assisted process did what it did, it could answer with a specific rule in place of a general assurance.