Fund governance does not usually fail in one dramatic collapse. It weakens when one untested output becomes the basis for another, then another, until decisions rest on a chain of reliance no one has fully examined.
A liquidity classification becomes a committee report. A valuation input becomes a NAV. A compliance report becomes the basis for a CCO certification. A service provider representation becomes part of an annual review. A subadviser risk summary becomes the basis for adviser oversight. Each step may look reasonable in isolation. The fragility sits in the connections.
Every governance framework in asset management rests on a quiet assumption: the people overseeing a function can evaluate what they are being asked to approve, certify, escalate, or rely on.
That assumption has not disappeared. But it has become harder to satisfy.
The human accountability structure the fund industry built over decades remains intact. The legal and governance responsibilities still sit with people. What has changed is the evidence those people are working from.
Technology is increasingly embedded in the analytical work that feeds investment, compliance, valuation, liquidity, operational, disclosure, and risk functions. Outputs that experienced professionals rely on are increasingly generated, filtered, classified, summarized, or tested by systems they may not be able to fully interrogate. In many cases, they may not have reliable visibility into when those systems changed — because of a vendor update, a new data feed, a revised rule, model retraining, parameter reconfiguration, or drift in performance over time.
That gap — between human accountability and technology-mediated analysis — is where oversight begins to weaken. Not because people are careless. Because the infrastructure was built for a different operating environment.
This disconnect is not simply a technical-skills gap. Technical expertise matters, and firms will need data scientists, model-risk specialists, and vendor experts at the table. But oversight cannot be delegated to technical experts. Business and functional leaders hold the accountability — and accountability means two things: knowing precisely what evidence is required before any output can be relied on, and understanding the full landscape of who produces it and how it connects. Neither is a technical question. Both are leadership responsibilities.
A well-designed governance framework will give capable people at every level a defensible basis for the judgments their roles already require.
Let's begin with lessons learned from earlier technology adaptations.
Rules-Based Canaries — Early Signs of Tech Moving Faster than People
The failure of firms to re-wire their governance infrastructure was visible before generative AI entered the picture.
One early example involved Betterment's automated tax-loss harvesting service. According to the SEC, the service changed its scanning frequency without adequate client disclosure. A programming constraint then prevented tax-loss harvesting for certain accounts, and two coding errors compounded the problem. More than 25,000 client accounts were affected, and clients lost approximately $4 million in potential tax benefits.
The technology mattered, but the deeper failure was the control environment around it. Betterment had compliance personnel reviewing disclosures and engineers designing and updating the algorithms, but no effective mechanism connecting the two. The system changed. The client-facing description did not keep up. The issue was not merely whether the algorithm ran. It was whether anyone was monitoring whether the automated service was operating as described.
Schwab's robo-adviser case shows the opposite problem: the system did not fail. It worked.
Schwab Intelligent Portfolios was marketed on a powerful promise: no advisory fee, no hidden fees. But the portfolios were designed to hold significant cash allocations. That cash was swept to an affiliated Schwab bank, where Schwab earned revenue from the spread between what the bank earned on the cash and what it paid clients.
The conflict was embedded in the product architecture. The more cash the portfolios held, the more revenue Schwab could generate through its affiliate bank. Yet the cash allocation was presented as part of a disciplined portfolio-construction methodology designed to seek optimal returns. According to the SEC, Schwab's own internal analysis showed that under most market conditions the cash would cause clients to make less money while taking on the same amount of risk.
As the SEC's Enforcement Director put it, Schwab claimed the cash allocation was determined by "sophisticated economic algorithms" designed to optimize client returns, when in reality it was driven by "how much money the company wanted to make."
That is why the case matters here. The failure was not technical. The algorithm did not malfunction. It systematically implemented a conflicted product design that generated revenue for an affiliate while clients were told the product had no hidden fees and sought optimal returns. The failure was fiduciary: an automated product operationalized a conflict that was not adequately disclosed.
Together, the cases show two sides of the same oversight problem. In Betterment, the system changed and the oversight framework did not catch the consequences. In Schwab, the system worked and the oversight framework did not force the conflict, the client impact, and the public promise into the same conversation.
Both cases involved rule-based systems. Their logic could have been reconstructed. The evidence was there. It just never reached the right people.
Know Your Agents
Betterment and Schwab involved rule-based systems. However complex the products were, the logic could be reconstructed. A setting changed. A constraint applied. A coding error occurred. A cash allocation was built into the product design. The evidence existed, even if the governance infrastructure did not surface it soon enough.
AI changes the evidentiary problem.
A machine-learning model may leave logs, but not necessarily a human-readable rationale. It may show what data went in, what output came out, when the model ran, and which version was used. But that is not the same as being able to explain why a particular input produced a particular output in a way that supports compliance, fiduciary, operational, or board-level reliance.
Twenty years ago, many oversight questions were still mediated through people and documents. A service provider produced a report. An operations team reviewed breaks. A compliance officer reviewed exceptions. A portfolio manager explained a trade. The process was not perfect, but the trail was largely human-readable. If something looked wrong, the path back to the person, file, calculation, or control was usually clearer.
Ten years ago, the industry had become far more platform-dependent. Compliance systems, risk engines, order-management systems, liquidity tools, reconciliation platforms, and administrator dashboards could process larger volumes of information with greater speed and consistency. But oversight increasingly depended on coded rules, data feeds, security master mappings, system configurations, and exception logic.
Today, the fund ecosystem is more integrated still. One platform's output becomes another function's input. A custodian cash field can affect trading decisions. A security master mapping can affect compliance testing. A risk-system output can influence management's investment oversight posture. A liquidity classification can move from an adviser workflow into committee materials. If the upstream output is wrong, the downstream consequence may be a failed trade, a missed investment restriction, an inaccurate liquidity position, a derivatives exposure calculation that makes the fund look farther from its limit than it is, a misleading board report, or a disclosure built on bad information.
Oversight is no longer just reviewing a report. It is understanding enough about the chain that produced the report to know whether it can be relied on.
AI pushes this one step further. It can classify, summarize, recommend, prioritize, detect anomalies, draft explanations, and suppress noise. That can improve speed and scale. But it also makes the evidence behind the output harder to see.
The issue is not whether the system produced an answer. The issue is whether those accountable can understand why that answer was produced, what changed, and whether it is reasonable to rely on it.
That is why the question is rarely abstract:
- Why did the liquidity tool move this holding into a different classification bucket?
- Why did the pre-trade compliance system approve an order that would have failed the same guideline last quarter?
- Why did the risk platform show lower projected losses after the fund's interest-rate exposure increased?
- Why did the custodian's platform show cash as available for trading when it was needed for pending settlement activity?
- Why did the compliance report show no exceptions after the data feed, security master mapping, or rule library changed?
- Why did the administrator's reconciliation workflow auto-clear a cash break that previously required human review?
- Why did an AI-generated board or compliance summary omit the one change that mattered?
Each of those outputs can become the basis for a real governance decision. A portfolio manager trades. A compliance officer signs off. An officer certifies. A board receives a report. A disclosure is prepared. A service provider is deemed to be performing. The output moves forward because it appears clean, complete, or authoritative.
A false sense of comfort is the risk. In a technology-enabled control environment, a clean report is not the same thing as a tested report. A dashboard, score, classification, cash availability field, exception report, or AI-generated summary is not self-validating simply because it came from a sophisticated platform.
The business or functional leader relying on the output needs enough information to understand where it came from, what changed, whether it was tested against expectations, and why reliance on it was reasonable.
Don't accept "the system said so" as an answer. Keep asking why until you reach something a human decided.
The Oversight Paradox — More Outsourcing, More Oversight
Delegation was supposed to make oversight more manageable. In some ways it has. But it has also moved the evidence further from the people who are accountable for it.
Service providers are no longer just performing operational tasks or transmitting data. They are producing the classifications, calculations, exception reports, reconciliations, and summaries that become part of the fund's governance evidence. A platform may determine what is flagged, what is cleared, what is escalated, and what is summarized before the adviser, CCO, officer, or board ever sees it.
That changes the oversight question. It is no longer enough to know that a provider has controls, or that a subadviser has a process, or that a vendor will notify the firm of "material" changes. Blind reliance is another word for "hope."
The fund complex should know where third-party outputs enter its own governance chain: what decisions they support, what rules or assumptions shape them, what changes could affect them, who reviews them, and what evidence would support reliance if the output were wrong.
This gap is where traditional service-provider oversight can fall short and is where many firms are still lagging in their evolution. A model update, data-source change, rule-library revision, exception-threshold adjustment, or new AI-generated reporting layer may look operational to the provider. But if it affects the evidence used for key business and functional decisions and monitoring, it is a governance matter — regardless of how the provider classifies it.
You can't effectively oversee what you don't understand.
Subadvisers raise the same problem in a different form. A primary adviser may have retained a subadviser under an oversight framework designed around people, policies, performance, and periodic reporting. But the subadviser's research, risk monitoring, portfolio construction, trade execution, or compliance process may now be shaped by AI-enabled tools. The adviser does not need to manage the subadviser's technology stack. But it does need to understand when technology is materially shaping the outputs the adviser relies on to oversee the mandate.
In a fund ecosystem, the most important technology may not be inside the adviser's four walls. But the accountability often still is.
Fund ecosystems have one of the most rigorous governance infrastructures within financial services — in part due to the highly regulated nature of investment companies and their service providers. The securities laws, including the Investment Company Act of 1940, are designed to protect investors — including strict rules aimed at eliminating or mitigating conflicts and a robust disclosure regime. The predominantly principles-based framework has endured because, while the world changes, the core principles remain relevant and mostly intact.
When in doubt, firms should start back at the beginning. Think policies and principles first — why do these rules exist and what problem are they designed to solve — and then reimagine what oversight looks like in new operating models. Avoid siloed scaffolding. Strive for integration and connectivity. Focusing on fundamentals and rebuilding is smart innovation — same principles, agile application.
The Mechanics of Failure
The practical question is not whether a fund complex uses AI. It almost certainly uses technology that classifies, reconciles, tests, summarizes, scores, routes, or escalates information somewhere in the ecosystem.
The better question is whether the fund complex knows where those outputs enter its own governance chain.
A vendor tool may look operational to the provider. A dashboard may look informational to management. A summary may look like a convenience to the board. But if the output supports a trade, a liquidity determination, a compliance conclusion, a valuation judgment, a derivatives risk calculation, a board report, or a regulatory filing, it is no longer just a technology output. It is part of the evidence of oversight.
That is where the house of cards can begin.
The custodian cash field — not what it used to mean
A portfolio manager sees that a fund has cash available for trading on the custodian platform and places orders based on that number. The field appears routine. It has been used for years.
But the custodian has changed how pending settlement activity is reflected in the available-cash field. Unsettled sale proceeds appear earlier in the workflow, while a pending purchase or FX settlement is reflected later. The platform may be operating according to its configuration, but the adviser's trading desk has been treating the field as investable cash.
The result is not a theoretical technology issue. It can become a failed trade, a settlement problem, an overdraft concern, a liquidity issue, or an internal escalation. The question is not simply whether the custodian has controls. The question is whether the fund complex knew that this particular field had become part of its own trading and liquidity control environment.
Which custodian cash fields are used for trading, liquidity monitoring, overdraft review, or board reporting — and who reviews changes to their definitions?
The security master mapping change — tinkering without telling
A fund has an investment restriction limiting exposure to a particular issuer, industry, country, or related group. Compliance testing depends on security master data that maps each holding to the right issuer, asset type, sector, geography, maturity, derivative exposure, or restricted-security flag.
A vendor changes its security master mapping logic. A structured note, loan, derivative, or ETF is now mapped differently. The compliance system continues to run. The report shows no exceptions.
But the fund's economic exposure may not have changed. Only the data classification changed. Because the coded compliance rule depends on the mapping, the position no longer gets picked up in the same test.
The clean report may be technically accurate under the new mapping. But it may no longer answer the governance question the adviser thought it was asking.
When a data feed, security master mapping, or rule library changes, does anyone review whether compliance tests, investment restrictions, liquidity classifications, or exposure reports are affected?
The liquidity classification tool — deceptively calm waters
An adviser uses a vendor-supported liquidity tool to help classify portfolio holdings. The tool incorporates trading volume, market depth, dealer quotes, bid-ask spreads, asset type, issue size, and other inputs.
The vendor updates its methodology. Several bank loans, thinly traded bonds, or private credit positions move into more liquid buckets. The dashboard improves. The liquidity committee receives a cleaner report.
Nothing looks broken. The model may even be more sophisticated than the prior version. But if no one asks why the classification changed, the committee may not know whether the movement reflects market improvement, portfolio activity, cleaner data, or a methodology change.
That distinction matters. A fund that appears more liquid than it is may make different decisions about trading, cash management, liquidity risk monitoring, escalation, or board reporting.
When liquidity classifications change materially, can the adviser tell whether the change was caused by market conditions, portfolio activity, data quality, or vendor methodology?
The subadviser risk dashboard — the invisible trend
A primary adviser oversees a subadviser managing a large-cap growth sleeve of a multi-manager fund. The fund has a fundamental policy against concentrating its investments in any single industry — the policy threshold under the Investment Company Act of 1940 that defines industry concentration at 25% of total fund assets. The primary adviser has also established a non-fundamental internal early-warning guideline of 20% for any single sector in the sleeve.
The subadviser has adopted an AI-enabled analytics tool that generates a quarterly risk summary and flags what it identifies as material changes — defined within the system as a sector-weight shift of more than 5 percentage points in a single quarter. The dashboard becomes easier to read. The summary reports no material changes for four consecutive quarters.
But the sleeve's technology sector weight has been drifting: 13% in Q1, 17% in Q2, 21% in Q3, 24% in Q4. Each quarterly increment — 4, 4, and 3 percentage points — stays below the 5-point alert threshold. The primary adviser reads the AI summary and continues to report that subadviser risk remains within expectations.
What no one escalates: the sleeve passed through the fund's 20% internal guideline in Q3 without triggering any alert. By Q4 it sits at 24% technology — one percentage point from the fund's fundamental industry concentration limit. The drift built in plain sight of a tool that was watching for something else.
The adviser does not need to audit the subadviser's technology stack. But it does need to understand when an AI-generated summary is defining "material" in a way that misses what the fund's own policies are designed to catch.
If a subadviser uses AI-enabled summaries or risk tools, does the primary adviser understand how "material change" is defined within those tools — and whether that definition aligns with the fund's own investment restrictions and fundamental policies?
The administrator's reconciliation workflow — the problem with pattern recognition
Every business day, the cash and holdings in a fund's books need to match across multiple record-keeping systems — the fund accountant's records, the custodian's records, and the adviser's own data. When a line item doesn't match, it is called a "break." Most breaks are harmless: a trade placed today settles two business days later, creating a temporary mismatch that resolves on its own. Others require immediate attention. When a fund has derivatives positions, counterparties may issue margin calls — demands that the fund post cash collateral the same day. A margin-call break and a settlement timing break can look nearly identical in the data. But they are fundamentally different problems.
The administrator introduces AI-assisted exception management. The tool reads each break, matches it against historical patterns, and auto-clears anything below certain thresholds that resembles something it has seen before. Monthly metrics improve. Open exceptions go down. The report looks cleaner.
But the fund's derivatives activity has grown, and what is now generating the recurring "cash timing difference" breaks is not a settlement lag. It is cash movement related to margin calls on swap positions. The label is the same. The size and timing look similar. The AI matches the pattern and clears the break.
The difference is consequential. A settlement timing break resolves on its own in two business days — no action needed. An unresolved margin call means the fund may have failed to post required collateral to a swap counterparty, potentially creating a contractual issue with the counterparty, an operational escalation, and a compliance concern under the fund's derivatives risk management framework. That kind of break should reach the operations desk and the CCO. Instead, it disappears.
The service-provider report shows fewer open exceptions. Nine breaks over two quarters reached no human reviewer.
When a provider automates exception clearing, does the fund complex know which exceptions can be auto-cleared, what thresholds apply, and which categories still require human review?
These examples are not edge cases. They are the ordinary mechanics of modern fund governance: cash, data, mappings, classifications, dashboards, reconciliations, exceptions, and summaries.
That is the point. AI risk in fund governance will not always arrive as a dramatic model failure. It may arrive as a cleaner dashboard, a shorter report, a faster reconciliation, a quieter exception queue, or a more confident summary.
The question is whether the governance framework can tell the difference between genuine assurance and automated silence.
A useful oversight program does not need to chase every system change. It needs to identify the outputs that matter and make reliance on them defensible:
- What governance decision does this output support?
- Who owns review of the output?
- What assumptions, rules, models, or data sources shape it?
- What changes could affect it?
- What testing occurs before and after those changes?
- What exceptions are escalated, and what is suppressed?
- What evidence would show that reliance was reasonable?
That is the practical discipline. Not more paperwork. Not technology fluency for its own sake. Evidence strong enough to support the judgment being made.
The principles that fund governance was built on have not changed. What has changed is the environment in which they must be applied. The work now is to architect an evidence infrastructure strong enough to support them — deliberately, not by default.
