AI Architecture in Banking: Architecture Before Agents

An agentic system is only as reliable as the data it consumes. Where the underlying data estate is fragmented, definitions are inconsistent, lineage is incomplete or source validation is weak, the result is not just lower performance. It is weaker explainability, auditability and control.

This is not simply a data management issue. In banking, governance, validation and monitoring all depend on institutions being able to understand the inputs to a decision, how they were transformed and where accountability sits. Where automated decisions have legal or similarly significant effects, firms also need to think carefully about explainability, contestability and documentation. None of that is achievable without well-governed data underneath.

The practical implication here is straightforward. In the AI enabled bank, data architecture is not just a reporting utility. Rather, it becomes part of the operational backbone for governable autonomy, with every material input into an autonomous decision having a traceable source, a documented transformation history and a monitored quality standard.

Illustrative failure mode

An AML agent flags a customer for enhanced due diligence (EDD). The compliance team cannot determine which underlying data source triggered the flag, because multiple upstream systems contain conflicting records with incomplete lineage. As a result, the decision can neither be explained clearly, nor defended with confidence.

Agentic systems do not operate in isolation. They interact across functions, workflows and, in some cases, organisational boundaries. That creates a need for orchestration: a layer capable of sequencing tasks, enforcing policy, managing hand-offs and escalating exceptions in real-time. Without it, autonomy does not eliminate inconsistency. It simply amplifies it at machine speed.

In a banking context, this matters for more than just operational efficiency. Firms need to show that customer outcomes, control requirements and escalation paths are being handled coherently across end-to-end processes. For example, UK regulators require, amongst other things, that institutions deliver fair, comprehensible outcomes for their retail customers and actively avoid foreseeable harms¹. In that context, compliance cannot sit entirely after the event. It must also be expressed in workflow design, decision logic and intervention thresholds, designing control into the architecture itself.

Illustrative failure mode

An AML agent and a credit decisioning agent act on the same customer journey without a shared orchestration layer, reaching conflicting conclusions and triggering contradictory customer-facing actions before anyone at the bank can intervene.

Autonomy does not remove accountability. It raises the bar for how clearly accountability must be defined. In the UK, responsibility for all activities ultimately rests with named individuals, who must be able to demonstrate appropriate oversight and control of the areas they are responsible for. Regulated firms must understand for each AI enabled activity where that ultimate responsibility sits, how escalation works and when human intervention is required. That makes clear human-in-the-loop checkpoints, documented override paths and auditable decision logs essential.

The principle is simple: if a decision cannot be traced, it cannot be defended. And if it cannot be overridden, it cannot be governed. Oversight must also extend beyond initial validation. Model drift, changing data distributions and edge case behaviours are not one-off deployment issues. They are ongoing operational realities that require monitoring, review and escalation built into the architecture from the ground up.

Illustrative failure mode

A mortgage pre-approval agent performs well for several months, then begins declining an unusual proportion of applications from a particular customer segment. No alert is triggered because monitoring focuses on headline model performance rather than outcome patterns. The issue surfaces only later in review.

Agentic systems depend on APIs, shared data layers, cloud infrastructure and external model providers. As autonomy scales, so too does that web of dependency, bringing with it rising concentration risk, correlation risk and the greater possibility of cascading failure if one component behaves unexpectedly.

Regulators require firms to identify important business services and ensure they can withstand severe but plausible disruptions. For banks, resilience thinking therefore needs to extend far beyond infrastructure uptime. Firms also need to consider dependencies, fallback arrangements and failure points embedded in the logic of AI-enabled workflows.

A particular related issue is third-party concentration, with much of the market building on a relatively small number of cloud and model providers. That is not inherently a problem, but it does raise the stakes around testing, oversight, contingency planning and transparency concerning where common dependencies sit.

Illustrative failure mode

A third-party model provider releases an update that changes behaviour in a narrow set of edge cases. Several institutions using the same service for credit-related workflows see anomalous outputs before the issue is identified. In this scenario, the dependency is neither fully incorporated into resilience testing nor fallback planning.