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.

Agentic AI at scale is predicated on this foundation. Agents can only be built to act accurately and within authority when they are designed with a connected, computational view of the institution: its policies, rules, exceptions and the systems that enforce them. MSOCK is Intellect’s connected enterprise knowledge infrastructure, the platform that provides this context, so agents can be built to act accurately and scaled 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: A 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. This is the interest on knowledge debt: paid quietly in specialist time, slower change and broad testing.

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. In effect, AI raises the interest rate on knowledge debt: a gap an experienced officer bridges once, an agent can stumble over many times.

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 and configuration: 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.

Four levels illustrate how the autonomy that AI can safely be given grows with the state of the bank’s knowledge

Level 1: Knowledge held in experience or code. Rules live in the judgement of experienced staff or inside application code. AI must defer to a person.

Level 2: Knowledge is documented but not connected. Policies, procedures and exceptions are written down, but no one has recorded how they relate. AI can find and draft, but people must check its work.

Level 3: Knowledge connected and traceable. Each rule is linked to its source, its authority and the system that applies it. A rule can be traced from end to end. AI can explain which rule applies and recommend what to do, but people decide.

Level 4: Knowledge is a computational asset. Rules from documents and code are brought together into one connected view of the whole estate. Teams and AI can see every rule, system and dependency at once, and work out what a change will affect before making it. This is what allows AI to support engineering as systems are built, changed, run and modernised, acting within a defined scope under clear controls and human accountability.

This is not a universal maturity model, and connected knowledge does not by itself make AI safe. But the principle holds: AI can only be as autonomous as the bank’s knowledge allows.

A better model will not fill gaps in policy, authority or implementation. Turning institutional knowledge into a connected, computable asset is what earns AI greater autonomy.

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 do the same for enterprise knowledge: to make it connected and computable.

MSOCK connects what a bank knows with the systems that act on it. It links policies, processes, products, business rules, APIs and code across business, operations, compliance and technology, and organises them into Connected Knowledge Units. These units give engineering teams and AI agents the context of the institution as agents and systems are designed, built and tested.

MSOCK is not another copilot. It is a connected enterprise knowledge infrastructure platform that sits beneath the bank’s existing models, copilots, agents and AI development tools, giving them a shared, evidence-backed understanding of the estate they are working in.

This is the foundation agentic AI at scale depends on. An agent is only as accurate as the context it was built with, whether it handles trade-finance discrepancies or changes a limit engine. MSOCK supplies that context, connected and computable, from a single platform.

MSOCK serves both engineering and operations. Engineering teams query it as agents and code are built and changed, and MSOCK allows agents to act on that knowledge through forward engineering and testing: building agents and systems from the connected knowledge and testing them against it. Operations teams can query it in live operations, for example to understand why a system behaved as it did or what an incident could affect. Governance guardrails define what each agent may do, and where a person must review or approve.

How MSOCK works

MSOCK moves from understanding an estate to changing it safely, with governance across every step.

1. Understand — System of Connected Knowledge. Builds an evidence-backed understanding of a defined software estate, connecting institutional knowledge to the applications and code that implement it.

2. Visualise — 21-Dimensional Enterprise Spatial Graph. Shows the same estate from many perspectives, from business journeys and operational processes to applications, APIs and implementation evidence, so teams can see how their knowledge and systems fit together.

3. Assess — Precise Blast Radius. Before work begins, shows what a change could affect, why each dependency exists and how confident the assessment is.

4. Act — Four Engineering Machines. Apply this connected knowledge to engineering work as systems are built, changed, run and modernised.

5. Govern — Command Centre. Provides oversight, control and compliance across engineering activity, with approval gates, decision rights and an auditable record.

What this means for a bank

The invisible thread becomes visible. A policy, the procedure that applies it, an approved exception and the code that enforces it can be seen as one connected picture rather than separate fragments, so teams can see where knowledge is reflected in a system and where policy and production differ.

Knowledge Lineage can be established. Teams have a stronger basis for determining which policy or approved instruction applies, on what authority, and where it is implemented, including relevant jurisdiction, client category and timing.

Change can be assessed before it is made. When a rule or regulation changes, teams can investigate which journeys, services, data, parameters and controls may be affected, rather than reconstructing the answer each time. This is how knowledge debt is paid down: rather than being reconstructed for each change, knowledge is held in a living map of the technology estate that evolves with it, and that every agent and every change can draw on.

In the foreign-exchange example, MSOCK would trace the revised limit to the parameter in the limit engine, identify the connected systems and tests, and make the release gap visible. An agent built with that context is designed to recognise when policy has moved ahead of the system and to route such cases to the authorised officer, rather than halting without explanation or improvising an exception. The operations team handling the case can query the same connected view to confirm that a release is pending.

MSOCK does not process live transactions or replace model evaluation, security controls, human accountability or operational risk management. The precise traceability available depends on the connected sources and the implementation.

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.

Agentic AI will scale only as far as this foundation allows. MSOCK is Intellect’s connected enterprise knowledge infrastructure for providing it: the platform that provides the connected, computational context agents need to be built to act accurately and within authority across the bank.

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

Selected References