Fragmented data and recurring manual corrections continue to burden banks’ risk reporting, according to the European Central Bank. Its February 2025 supervisory findings linked these problems to weaknesses in data controls and legacy infrastructure, affecting banks’ ability to respond quickly during periods of stress.

The Basel Committee on Banking Supervision’s November 2023 report found that only two of 31 global systemically important banks assessed were fully compliant with all its risk data aggregation and reporting principles. The assessment used data as of June 2022.

On the Emerj AI in Business Podcast, Nathaniel Bell, Data Management Director at Wells Fargo, joined host Yolandi de Weerdt to discuss the challenges of scaling automation across fragmented banking operations. The conversation examines how inconsistent data interpretations, gaps in execution evidence, and growing oversight demands affect leaders’ decisions about where to invest in AI and how to evaluate its operational value.

This article examines three directly applicable strategies for assessing and rolling out AI investments:

• Standardize workflows before scaling AI: Locate conflicting data definitions and unnecessary handoffs, then decide which steps to standardize, automate, or eliminate before investing in AI.
• Find control gaps and reduce manual verification: Define required actions, check records of what occurred, and investigate differences to identify where automated evidence collection could reduce verification and audit preparation.
• Reduce manual oversight while maintaining accountability: Separate automated monitoring from human investigation, assign owners to exceptions and control updates, and identify manual reviews that can be retired.

Listen to the full episode:

Episode: Managing Change Across Modern Financial Operations – with Nathaniel Bell of Wells Fargo

Guest: Nathaniel Bell, Data Management Director at Wells Fargo

Expertise: Enterprise Data Management, Data Governance, Data Risk Management, Risk Assessment

Brief Recognition: Nathaniel Bell is Data Management Director at Wells Fargo. He previously served as Senior Lead Business Risk & Control Officer for Data Management & Insights at Wells Fargo and Senior Audit Manager, VP of Data Risk Management at PNC. He holds a Master of Engineering in Nuclear Engineering from Penn State.

Standardize Workflows Before Scaling AI

Large financial institutions inherit processes and platforms through acquisitions, product expansion, regulatory requirements, and years of technology change. As Bell explains, teams may believe they are executing correctly within their own systems while the institution struggles to produce consistent outcomes across the complete workflow.

The problem concerns shared context as well as access to information. A process may pass through multiple systems and teams without establishing a consistent interpretation of the data being transferred. Regulatory requirements introduce another point of variation because institutions must translate written guidance into operational decisions.

Introducing AI can spread those inconsistencies across more users and interactions, a risk Bell describes as “industrializing bad data quality.” He recommends understanding and standardizing the complete workflow before deciding where to apply automation.

“Don’t automate the process until you standardize it. Once you understand the end-to-end, I think that gives you a much clearer picture of what you can automate and maybe more importantly, what you can change.”

— Nathaniel Bell, Data Management Director at Wells Fargo

For a banking leader, the investment decision concerns whether a proposed tool accelerates an existing handoff or removes the inconsistency that makes the handoff difficult. Bell cautions against adding new capabilities without examining how the process itself could change.

For example, for a customer-document review, suppose one team considers a document current while another applies a different validity period. An automated transfer moves the document faster, but the receiving team still has to resolve the conflicting interpretation. Agreeing on the acceptance rule changes the work required to complete the review.

Applied to that illustrative workflow, Bell’s standardization advice can be organized into three steps:

• Trace the complete handoff: Establish which information each team receives and which decision it must make before passing the case onward.
• Resolve conflicting interpretations: Identify where teams apply different meanings or requirements to the same information and agree on the applicable criteria.
• Choose what to automate or redesign: Determine whether the existing step remains necessary once those differences are resolved.

Where disagreement about the input creates repeated reconciliation, leaders can first address the conflicting definitions. Where a standardized step remains necessary, automation can be evaluated against the time and effort required to perform it.

This provides a practical decision rule drawn from Bell’s discussion: resolve ambiguity before increasing execution volume, and examine whether standardization makes any existing work unnecessary. In the document-review example, that means distinguishing the value of faster routing from the value of removing repeated checks caused by conflicting rules.

Find Control Gaps and Reduce Manual Verification

A demo can make a tool look effective without showing how the bank will check that it works in practice. Bell advises leaders to begin with the business objective and ask whether the outcome can be measured, monitored, and understood well enough to improve over time.

Those questions determine what evidence the organization needs. A process document describes the intended sequence of actions, but reconstructing the actual sequence becomes harder as work moves between systems.

Bell identifies the challenge as establishing “what actually happened and then reconciling those two,” referring to the comparison between execution evidence and the expected workflow. He proposes using automated logs to help demonstrate that required actions occurred and identify whether exceptions arose.

For example, a bank’s procedure might require a customer’s documents to be reviewed before their application advances. If teams use separate systems, staff may need to gather records manually to confirm that the review occurred. Recording the completed review and the application’s subsequent transfer would let staff check whether it advanced only after the required review.

A practical evidence review drawn from his explanation has three parts:

• Define the expected action: State the check or decision required before the workflow proceeds.
• Locate the execution evidence: Identify the record showing whether that action occurred in the relevant case.
• Reconcile the difference: Establish whether the actual path met the expectation or produced an exception requiring investigation.

For the illustrative approval step, the question is whether the institution can connect a case’s advancement to the required review. That determines which records are useful for evaluating the control and where staff may still need to investigate gaps.

Collecting those records also requires choices. Bell raises the question of whether large workflows should retain all operational information or only information associated with exceptions. His discussion leaves that choice open, directing attention to the evidence needed to understand actual execution.

Manual evidence production creates work beyond completing the original transaction. Bell describes producing and maintaining that evidence as a “heavy tax.” Applying that observation to an investment review means examining the activities an evidence-capture capability could change:

• Evidence preparation: Compare the staff effort required to reconstruct completed work with the effort needed to retrieve and review execution records.
• Exception investigation: Examine whether reviewers can establish where the actual workflow departed from its intended path and how much investigation remains necessary.
• Documentation maintenance: Identify which records still require manual updates when the underlying process changes.

These comparisons connect the investment to a specific operational burden. Faster case processing would leave part of Bell’s concern unresolved if staff still had to reconstruct the same events afterward. The business case therefore needs to account for both transaction execution and the work required to demonstrate what occurred.

Reduce Manual Oversight While Maintaining Accountability

Growing regulatory complexity can introduce additional controls, audit expectations, and review activities. Bell argues that institutions cannot keep meeting that burden by adding manual oversight. He proposes embedding controls directly into workflows and the data products supporting them.

That approach changes what governance professionals do. He hopes to spend less time reviewing documents and coordinating work, and more time understanding how systems operate and recognizing signals that something may be going wrong.

A pattern that differs from historical behavior could indicate a potential problem requiring investigation. Understanding the signal requires knowledge of what the data represents, where it originated, how it changed, and which business outcome or control it affects.

The resulting workflow connects detection with investigation. Governance staff would examine signals from the operating system and investigate potential breaks, supported by an understanding of metadata, data lineage, controls, and business outcomes.

For leaders applying Bell’s discussion, three responsibilities need to be connected:

• Monitoring: Assign responsibility for reviewing signals associated with the workflow and its controls.
• Investigation: Identify who determines whether a changed pattern reflects a legitimate change or a potential failure.
• Maintenance: Establish who updates the control and its supporting information as the process changes.

These responsibilities clarify where human judgment remains necessary. A system may identify a changed pattern, while a reviewer needs to interpret it in the context of the business process. Assigning that responsibility makes the signal part of an operating workflow rather than another item awaiting attention.

Bell compares adopting technology to buying exercise equipment, where the benefit depends on changing habits and using it consistently. He argues that organizations likewise need to change how people and teams work to achieve the intended business outcomes.

In the illustrative review process, a team might continue maintaining a parallel spreadsheet after the workflow begins generating execution records. Leaders would need to determine whether the new records meet the team’s evidence requirements and whether the old activity can be retired. Otherwise, introducing the tool could leave the original documentation burden in place.

Leaders can assess the investment by identifying which manual tasks the embedded controls could replace, what records would verify the work, and who would investigate exceptions. This makes the potential reduction in oversight work clear while preserving responsibility for resolving problems.

Bell’s advice connects expansion decisions with changes in the underlying work. Standardization addresses conflicting interpretations, execution records support verification, and embedded controls shift oversight toward monitoring and investigation. A business case built around those changes can show which reconciliation and evidence-production activities should decrease, alongside the human responsibilities required to maintain control.