Most AI pilots in banking work. The difficulty starts in production, when an agent encounters a case whose answer depends on several sources at once: a policy, the procedure that applies it, an exception approved by the right authority, and a limit configured in a core system.

Each source may be correct. None, read alone, provides the full answer. The challenge is that the relationships between them are rarely recorded in a form an AI system can reliably follow.

Every rule in a bank runs along a thread—from the policy that establishes it, through the procedures that interpret it, to the code that enforces it. AI can only be governed effectively when the institution can trace that thread.

Banks carry a structural challenge that we call knowledge debt: the connections between rules, systems and approved decisions that experienced employees understand, but no system records in a connected, traceable form.

This has direct implications for AI governance, regulatory change and application modernisation. Intellect’s MSOCK — Multidimensional Multilayer System of Connected Knowledge — is designed to connect enterprise knowledge with application structures and dependencies, helping institutions understand how their systems work, assess the impact of change and support governed engineering.

The opportunity is to make institutional knowledge more visible, computable and usable—so AI can operate with context while remaining within defined authority and controls.

1. The Surprise in Week Three

Many AI programmes in banking follow a similar trajectory. The demonstration works. The pilot impresses. Then, a few weeks into a live workflow, the AI encounters a question that no single document can answer.

Consider a trade-finance discrepancy.

An AI agent reads a letter of credit, an invoice and the bank’s discrepancy policy. It identifies a mismatch in the goods description. The policy requires discrepancies to be referred. The desk procedure, approved under that policy, permits certain minor variations to be waived. An operational memo records that such waivers have been approved for qualifying clients on specific trade corridors.

An experienced officer understands how these sources fit together and when delegated authority permits an exception.

The officer is not working around policy. The officer is exercising judgement within an established governance framework, drawing on applicable rules, approved procedures and authority limits. Delegated judgement is an essential part of balancing operational speed with risk control.

An AI agent must establish the same context before it can recommend or undertake an action. It needs to determine which instruction applies, whether an exception is valid for this case, and whether it has permission to act or must refer the decision to an authorised person.

This is not necessarily a failure of governance. Banks maintain extensive policies, controls and audit processes. The difficulty is that the relationships between policy, procedure, approvals and systems are rarely recorded in a form that AI can reliably interpret.

A policy may be clear. A procedure may be accurate. An application may enforce the correct limit for its current release. Yet a decision may depend on the relationship between all three.

That relationship is the invisible thread connecting institutional intent to operational action.

2. Knowledge Debt: Structural Challenge to Scaling Responsible AI

Software engineers track technical debt, and data officers govern data lineage. Banks carry a counterpart to both that rarely appears on any register.

Call it knowledge debt: the connections between a bank’s rules, systems and approved decisions that experienced people understand, but no system records in a connected, traceable form.

A policy defines what should happen. A procedure explains how it should happen. An approved exception establishes when a different treatment is permitted. Application code determines how the rule is enforced.

Each may be accurate. What is missing is Knowledge Lineage: a traceable record of how these elements connect—which procedure implements which policy clause, which approved exception modifies which threshold, and which code enforces which limit.

This is not necessarily a problem of outdated or missing documentation. It is accurate knowledge whose relationships have never been recorded in a connected form.

Like technical debt, knowledge debt can accumulate through growth, mergers, regulatory change and system migrations. It is a structural consequence of institutional complexity, not in itself a sign of weak governance.

It shows up in four places:

For decades, people have bridged these gaps invisibly. An experienced officer reads several documents, recalls an earlier decision, checks the applicable authority and moves the transaction forward. The bank rarely sees the effort involved because it is paid for through judgement and experience.

AI cannot reproduce that judgement simply by gaining access to the same documents. It needs to establish how the sources relate, which instructions carry authority, and what actions it is permitted to take.

Without Knowledge Lineage, three failure patterns emerge.

The Gridlock Trap — excessive rigidity. AI applies the most literal reading of a single source and stops a case that experienced staff could resolve within their delegated authority. The result is unnecessary delay and friction for clients.

The Improvisation Trap — unsupported discretion. Faced with sources it cannot reconcile, AI produces a plausible interpretation or recommends an action without a clear basis in approved authority.

The Cascade Trap — errors propagated downstream. An upstream agent, such as one handling document extraction or KYC, misinterprets a rule and passes that interpretation to downstream systems. The error can then be repeated across connected workflows.

These are not simply model-performance problems. They arise when AI operates without a sufficiently connected understanding of the institution’s rules, decisions and systems.

AI does not create knowledge debt. It exposes it—in the decisions it makes and the exceptions it cannot safely resolve.

3. Why It Matters Now

Knowledge debt becomes more consequential as banks move from isolated AI assistance to agents participating in complex workflows and engineering activities.

Three considerations make it urgent.

The bank remains accountable for what its AI does

The US Consumer Financial Protection Bureau’s 2023 report, Chatbots in Consumer Finance, highlighted risks associated with inaccurate chatbot responses, inadequate customer support and potential consumer-protection violations.

The broader lesson applies to AI across banking: automating an answer does not transfer accountability for the outcome. A response can be wrong even when every passage retrieved by the model is accurate, if the system fails to establish which rule applies or whether the proposed action is authorised.

Governance must therefore go beyond whether a model produces a plausible response. It must establish what information the system relied on, which rule applies, what authority supports the decision and whether the proposed action is permitted.

Errors can scale and cascade

A person who misapplies a rule may make one mistake. An AI agent can repeat that mistake across many cases and pass it to downstream systems.

Imagine a KYC agent misinterpreting a customer classification rule and passing the result to an AML agent. If the downstream agent accepts that classification without checking its provenance or authority, the initial error can influence subsequent decisions.

The concern is not simply one incorrect answer. It is an incorrect interpretation of a customer, compliance or operational rule becoming the input to decisions that follow.

As workflows become more connected, the provenance and authority of the knowledge moving between agents become increasingly important.

Regulatory change must translate into operational controls

The National Institute of Standards and Technology’s AI Risk Management Framework provides a voluntary framework for managing AI risks across design, development, deployment, use and evaluation.

The Bank for International Settlements’ Financial Stability Institute has also examined the regulatory challenges of AI in finance, including governance, model risk management, data governance and third-party providers.

In Singapore, the Monetary Authority of Singapore published its Guidelines on Artificial Intelligence Risk Management for Financial Institutions on 7 October 2026, with the guidelines scheduled to take effect on 7 October 2027.

For banks, the operational implication is clear: every regulatory obligation must ultimately translate into business rules, data requirements, controls and application behaviour.

When a regulation or internal policy changes, technology teams need to establish which customer journeys, services, data elements, parameters and controls are affected. Without traceable connections between the rule and the systems implementing it, impact assessments can be slow and incomplete. Teams may miss a dependency or compensate for uncertainty with unnecessarily broad testing.

The executive question is simple:

When a rule changes, can the bank trace exactly where it is implemented and what the change will affect?

The answer links AI governance directly to application modernisation, operational resilience and the cost of regulatory change.

4. The Deepest Layer: Rules Embedded in Code

Some of a bank’s most consequential business knowledge is not contained in policy documents. It resides in software.

Core banking and other enterprise systems can run reliably for decades. Business rules are embedded in code: which customers qualify for a product, how a fee is calculated, when a payment requires additional review, and how limits are applied.

Documentation may describe the intended behaviour without capturing every detail of the implementation. Engineers who built the original systems may have moved on, while subsequent changes have introduced additional dependencies. Understanding how a system actually behaves can require specialist analysis of its code, configuration and connections to other applications.

This creates three challenges for CIOs.

Regulatory change becomes archaeology. When a rule changes, teams spend time tracing which journeys, services, data and controls it touches. The effort can be substantial, and confidence in the completeness of the assessment may remain limited.

Modernisation becomes harder to validate. Moving business logic from a legacy environment into a modern architecture requires teams to understand what the existing system actually does and demonstrate that the new implementation preserves intended behaviour, including important exceptions and edge cases.

Change risk becomes difficult to quantify. A technically connected component is not necessarily affected by every change. Without a precise understanding of dependencies, teams may miss relevant impacts or resort to broad regression testing to compensate for uncertainty.

When policy moves before the system

Consider a bank changing its intraday foreign-exchange exposure limit for a defined category of multinational corporate clients.

The risk committee raises the limit from $50 million to $75 million. The updated policy is published on day one, but the production limit engine requires governed change control and regression testing. The new parameter is scheduled for a release 30 days later.

During that window, a qualifying client requests a $65 million trade. The production system correctly applies the existing $50 million limit and raises an exception.

An authorised risk officer confirms that the client qualifies under the newly approved policy and approves the trade through the bank’s defined transition procedure, within delegated authority.

An AI agent preparing the same trade reads the updated policy, runs the pre-trade limit check and receives a hard response: EXPOSURE_LIMIT_EXCEEDED (MAX_LIMIT: 50M).

It now has two facts that appear contradictory. Without knowing that a release is pending, it may halt the workflow or, worse, attempt to find another route.

What good looks like: the agent recognises that the policy has changed ahead of the system, presents both sources and routes the case to the officer with authority. It does not bypass the control or infer permission from the new policy alone.

Meanwhile, the bank can investigate whether the release window can be shortened. By tracing the policy change to the parameter that enforces it, and to the dependencies and tests affected, the bank has a stronger basis for accelerating implementation safely.

This is not necessarily a compliance failure or a software defect. It can be a normal, managed transition that experienced bankers handle routinely—one that AI without connected knowledge may mistake for an irreconcilable error.

AI coding tools make this challenge more consequential. They can generate code quickly, but they do not automatically understand the bank they are changing.

5. Why Standard AI Search Is Not Enough

The usual response to scattered knowledge is to load documents into a search index and let AI retrieve what it needs. This helps with finding information, but retrieval alone does not resolve knowledge debt.

There are four reasons.

No reliable hierarchy of authority. A board-approved policy and a regional desk email may both appear relevant to the same question, even though they do not carry equivalent authority.

No automatic understanding of precedence. A later regional addendum may qualify or supersede an older master policy. Similarity of wording does not establish which instruction governs a particular case.

No inherent link to execution. A document may describe a limit without identifying the application parameter that enforces it. An approved exception may have no recorded connection to the code or configuration affected by it.

The risk of blended answers. Faced with conflicting fragments, a model may combine them into a plausible response rather than establish which source governs. In a regulated process, plausibility is not sufficient evidence of authority.

Retrieval can be strengthened through metadata, permissions, explicit rules and temporal context. These capabilities are valuable, but the institution still needs connected knowledge that links rules to their authority, history, applicability and implementation.

For consequential banking workflows, the objective is not simply to retrieve the right passage. It is to establish why that passage governs the decision and what the system is permitted to do with it.

6. Codification Earns Autonomy

Most debates about AI autonomy ask how accurate the model is. The more consequential
question is how explicit the governing policy is, and whether anyone can see where it is enforced.

Consider a progression through four levels of institutional readiness.

Level 1: Knowledge held in experience or code. When the rule exists mainly in employee
judgement or embedded application logic, AI must defer to a person who can establish the
applicable context.

Level 2: Knowledge documented but disconnected. When policies, procedures and exceptions
exist across sources that are not fully aligned, AI can assist with retrieval and drafting, but
outputs require careful review.

Level 3: Knowledge connected and traceable. When rules are linked to their authority,
implementation and controls, AI can recommend changes, surface supporting evidence and
show which components may be affected.

Level 4: Rules executable and governed. Where rules are explicit, tested, executable and subject
to change control, AI may be permitted to act within a defined scope, with appropriate access
controls, monitoring, human accountability and escalation.

This is not a universal maturity model or a guarantee that connected knowledge makes a system
safe. It is a way of thinking about the relationship between institutional knowledge and permitted
autonomy.

AI can only be as autonomous as its governing knowledge allows. A more capable model will
not, by itself, resolve gaps in policy, authority or implementation. Connecting and codifying
institutional knowledge creates the foundation for greater autonomy under control.

7. MSOCK: Making the Invisible Thread Visible

Relational databases made enterprise data structured and queryable. Intellect developed MSOCK
— Multidimensional Multilayer System of Connected Knowledge — to make enterprise knowledge connected and computable, linking what an institution knows with the application
structures in which rules are represented and enforced.

MSOCK connects enterprise knowledge across 21 dimensions. Its purpose is to help teams
understand application estates, investigate relationships between business rules and
implementation, and assess the potential consequences of engineering change.

For AI agents and engineering teams working in a bank, this has four practical implications.

Rules connected to the systems that enforce them. MSOCK is designed to connect business
rules and institutional knowledge with application structures and parameters, helping teams
investigate where a policy is reflected in a system and identify discrepancies between policy and
production.

Rule lineage. Connected knowledge can help establish the relationship between a rule, its
source, its context and its implementation. This gives teams a stronger basis for determining
which policy or approved instruction applies, including relevant jurisdiction, client category and
timing.

Governed transition paths. Where approved transition procedures exist and are represented in
the connected knowledge, an AI-enabled workflow can surface the relevant evidence and route a
case to the authorised person rather than halting without explanation or improvising an
exception. The bank’s authority and operational controls remain decisive.

Traceable engineering decisions. Connecting business knowledge with application
dependencies can support impact analysis and provide evidence for engineering review, testing
and audit. The precise traceability available depends on the connected sources and the
implementation.

Five stages of connected engineering

MSOCK’s operating model can be understood through five stages:

1. Understand. Connect business rules to the application structures and code that implement
them, with evidence supporting the relationships.

2. Visualise. Present the connected knowledge in views that help teams understand the
application and its relationships.

3. Assess. Investigate the potential blast radius of a change before engineering work begins.

4. Act. Support engineering workflows across BUILD, CHANGE, RUN and MODERNISE, helping
teams build, change, fix and modernise systems with greater context.

5. Govern. Manage progression through appropriate approval gates, decision rights and an
auditable record of engineering activity.

In the foreign-exchange example, the objective is to trace the revised limit to the parameter in the
limit engine, identify connected systems and tests, and make the release gap visible. This
supports a more informed assessment of the change and a controlled path to implementation.

MSOCK sits alongside AI agents, copilots and AI development tools, providing connected
knowledge about the enterprise estate. It does not process live transactions itself or replace
model evaluation, security controls, human accountability or operational risk management.

Connecting knowledge strengthens the context in which these controls operate. It does not
remove the need for them.

8. What to Do on Monday

Banks do not need to connect every source of institutional knowledge before beginning. A
focused exercise can reveal where knowledge debt is constraining AI and engineering.

1. Pick the system that is hardest to explain. Every bank has a critical, long-serving system
understood in depth by a relatively small group of specialists. That is often a valuable place
to start.

2. Ask the question that matters. For the next regulatory or policy change on the roadmap,
identify which journeys, code, data and controls it will affect. Assess how confident the
organisation is in that answer.

3. Open a knowledge-debt register. Log cases AI pilots cannot resolve from available sources,
rules whose details exist only in code, exceptions whose authority is difficult to trace, and
dependencies that are hard to establish.

4. Put connected knowledge in the business case. Evaluate the investment required to make
the application estate understandable alongside the investment in models, agents and
integration. The connected knowledge can remain useful as individual AI models and tools
evolve.

Intellect has proposed a focused MSOCK challenge for financial institutions: bring one complex
application module and, subject to agreed scope and product-team confirmation, use a three-
week engagement to map the application and its connected knowledge.

The goal is to answer the question every CIO wants answered before a change:

If we change this, what exactly could be affected?

Conclusion: Give AI the Context Your Bank Has

Banks have spent decades building the policies, procedures, applications and controls that
govern their operations. The knowledge exists, but it is distributed across documents, systems,
code and people.

The next phase of enterprise AI depends on making that knowledge connected, traceable and
usable by machines without losing the authority and governance that regulated banking
demands.

That is the gap between AI ambition and governed AI at scale. Institutions that close it can treat
their own knowledge as infrastructure: connected, evidenced, current and governed.

Once knowledge is connected, the institution has a stronger basis for understanding what AI
relies on, what it is permitted to do, and where human judgement must remain in control.

The goal is not to eliminate human judgement. It is to make the knowledge behind that
judgement more visible, so it can be understood, tested and applied consistently under the right
controls.

The path to responsible AI begins by paying down knowledge debt: making the
invisible thread visible.