Beyond Reporting: Is Enterprise AI Set to Become the Enterprise Reasoning Layer?

Executive Summary

Much of today's discussion about enterprise AI focuses on adding natural-language or conversational interfaces to existing software, with every vendor appearing to ask the same question:

How do we add AI to our product?

As a primary goal, that framing invites AI-washing. A more productive question is:

How does enterprise software participate in enterprise reasoning?

This paper explores how AI may reshape the role of traditional enterprise systems.

Enterprise Data Management (EDM), portfolio accounting, treasury systems, document management platforms, and CRM systems are crucial components of the modern buy side firm and there's plenty of room for AI integration intra-platform, to improve their usefulness. But each of these best-of-breed components will likely remain separate and subordinate on the path towards delivering enterprise-level or whole of fund intelligence. Whether an organisation uses best-of-breed tools or an end-to-end platform, data must still be assembled and interpreted at the enterprise level by the business, including where analytics and data services are outsourced.

The fundamental question really is:

How do I provide trusted evidence to an enterprise reasoning / orchestration layer that can answer complex business questions and give the board and regulators a robust, timely total portfolio view?

Best-of-breed buy-side vendors have spent decades building better systems of record in response to the industry's expressed requirement for a golden copy: this is data the enterprise needs to operate to remain compliant and competitive. Each vendor has answered only part of that need though, leaving institutions to integrate the components themselves. The AI-enabled fund points to a significant architectural evolution. With new technology available, the industry can now offer a more ambitious response:

By combining governed systems of record with an enterprise reasoning layer, we can assemble evidence across the organisation and answer questions that no individual system can address by itself.

This is a central role for AI in the modern buy-side: not another system of record, but a more capable coordination, interpretation and orchestration layer across the systems already in place: particularly considering the refresh cycles of the underlying components will naturally lead to constant change. We propose that a governed enterprise reasoning system, combining a language model with controlled retrieval, deterministic business rules, validated calculations, and human approval is amongst the most valuable endeavours the buy side can embark on in 2026. This provides a practical architecture for extending a whole of enterprise lens across both structured data and unstructured knowledge. Regardless, funds are being asked for it.

The following definitions provide a useful guide to the terminology used in this paper:

• Probabilistic layer: interpretation, classification, synthesis, and language generation.
• Deterministic layer: calculations, eligibility rules, reconciliations, validation, source permissions, and output checks.
• Governance layer: provenance, versioning, access control, approval, audit history, and model evaluation.

The goal is therefore to deploy probabilistic model behaviour inside a controlled system composed of all three layers, not simply to make the LLM itself deterministic. Critically, this shift places pressure upstream of the application of AI, for trusted, provable inputs. In regulated environments, our thesis is that TPV, compliance, and regulatory reporting cannot rely on a probabilistic model working over loosely governed information. Particularly not using public language models. Unless inputs are authoritative and outputs are supported by provenance, validation and approval, conclusions cannot be reliably traced, explained, or defended. And public LLMs present a significant exposure to regulatory breaches.

Enterprise Software Was Built Around Transactions

For more than thirty years, enterprise software has become increasingly specialised. Financial institutions now typically run dozens, and often hundreds, of applications covering discrete functions such as portfolio accounting, EDM, treasury, custody, market data, risk management, CRM, data warehousing, document management, and workflow.

Each application performs its own task and owns part of the organisation's information; collectively, they offer a distributed view. Historically, this structure aligned with how software was used: systems executed predefined processes rather than answering open-ended questions. Reports were generated from structured databases using predefined logic: these are software processes. When requirements changed in this model over time, developers extended the data model, extended SQL queries, added ETL processes, or enhanced the data warehouse. The enterprise remained distributed despite a desire to resolve to a whole of fund view, but the questions were sufficiently well defined for this approach to work: so long as nobody wanted the firm to pull data from all those systems at once: which they now do.

Regulation Is Changing the Nature of the Problem

Increasingly, regulators are doing just that. Along with funds managing to a TPV of the world: asking organisations questions that span multiple domains. APRA's SRS 551 liquidity reporting framework perfectly illustrates this broader trend. SRS 551 demonstrates that regulatory reporting depends on governed information assembled across custodians, investment managers, investment books of record, treasury systems, classifications, and internal controls. But it does not prescribe that an LLM, or any AI, is a requirement to complete a regulatory return. The wider process - investigating exceptions, interpreting policy, documenting judgements, explaining movements, and preparing board assurance - is where enterprise reasoning can add substantial value.

The reporting framework requires information about liquidity supply and demand, stress events, funding sources, and governance decisions. APRA remains technology-neutral: it specifies reporting outcomes and definitions rather than prescribing the technology institutions must use to collect, integrate and govern the underlying information. There's no argument with that approach, but the impact of the requirement can be profound, where the fund's operating model is based on best-of-breed, desegregated systems.

In practice, producing liquidity reports may require information from numerous structured systems, such as:

• portfolio accounting
• custodian holdings
• treasury
• market data
• EDM
• risk systems
• security master data

…from semi-structured information, such as:

• liquidity classifications
• investment mandates
• pricing methodologies
• counterparty information
• operational spreadsheets

…and unstructured information, such as:

• Investment Committee papers
• board minutes
• liquidity policies
• operational procedures
• legal agreements
• side letters
• internal emails
• regulatory correspondence
• audit findings

Structured systems provide quantitative data, while documents and communications provide context, interpretation, and intent.

This Is a Reasoning Workflow

The workflow increasingly involves finding relevant information, interpreting it, cross-referencing sources, resolving conflicts, applying rules, producing evidence, and generating the final report. Reporting is therefore the output of a broader knowledge process, and each step in it must be traceable and reproducible - meeting regulated-environment requirements such as jurisdiction-specific data hosting, data sovereignty, access control, record retention, and evidentiary audit trails.

The Emerging Enterprise Architecture

Historically, enterprise architecture looked something like this:

Operational Systems
        │
        ▼
       ETL
        │
        ▼
Enterprise Data Warehouse
        │
        ▼
Analytics and Business Intelligence
        │
        ▼
     Reporting

The emerging architecture expands this model:

Structured Data + Policies + Documents + Emails +
Governance + Regulation + External Information
        │
        ▼
Enterprise Knowledge Layer
        │
        ▼
Enterprise Reasoning Engine
        │
        ▼
Reports + Board Papers + Risk Analysis +
Regulatory Responses + Operational Insights +
Executive Decision Support

The focus therefore extends beyond integrating financial data (numbers) to integrating knowledge. The knowledge layer itself must be governed through clear lineage, permissions, versioning, and semantic consistency - forming the evidentiary foundation for controlled reasoning and total fund outputs.

The Evolving Role of Enterprise Data Management

EDM still plays a significant role in this architecture. Its core task of ensuring that downstream applications receive clean, consistent, and validated structured data is preserved. In an AI-enabled enterprise, that responsibility becomes even more important: reasoning systems depend on accurate structured inputs and authoritative identifiers, classifications, and hierarchies.

However, legacy EDM platforms have often struggled to adapt quickly to new business requirements. A familiar industry example illustrates the point:

A front-office user requested two new fields in a legacy EDM data model. The request entered the standard governance and development pipeline, requiring data-model changes, integration updates, testing, and release coordination. By the time the fields were implemented (two years later), the original requester had left the organisation. The capability was technically delivered, but the business case had moved on.

This sanitised example highlights a structural limitation of heavily governed legacy platforms: rigidity and long delivery cycles can undermine enterprise responsiveness. Newer low-code and no-code platforms improve schema evolution and bring business users closer to data capabilities. That is valuable progress, but it does not by itself solve the wider problem of assembling and reasoning the contents of EDM across enterprise knowledge outside of numerical financial data.

EDM in the new world order therefore evolves from being solely a provider of structured data to being a provider of trusted evidence: governance-enabled structured data. EDM retains responsibility for accuracy, validation, and control, while the reasoning layer – which sits outside of EDM – assumes more of the burden of cross-system orchestration. To a large extent it offers EDM a reprieve from demands to extend the data model beyond investment data into partially structured or unstructured data. Speed, adaptability and usability become increasingly important alongside data quality, positioning EDM as a foundational component of enterprise reasoning and TPV, whilst additionally offering EDM vendors the opportunity to participate in the creation of an enterprise reasoning layer. The irony of an EDM provider's next big leap forward being the deployment of services outside of the EDM is rich.

We'd propose that EDM, chiefly amongst its peer components, should own the creation of golden copy data, but instead of extending the data model, it abstracts the data model and business logic out into enterprise AI. So instead of adding AI to look inwardly to data storage, it adds AI to orchestrate the retrieval of data from data storage in combination with knowledge from the rest of the data ecosystem.

The Difference Between Query Translation and Enterprise Knowledge Reasoning (EKR)

There is still value in using an AI interface to convert natural language to SQL queries for a specific example, the answers of which are contained in structured systems. That's a very specific use-case. The bigger question though for Enterprise Knowledge Reasoning (EKR) is to answer questions that require evidence and orchestration across multiple sources. Compare:

What is our largest Australian equity holding?

… which requires retrieval from structured data – which could be converted to an SQL query – while also answering:

Why did our reported liquidity position decline despite increased cash balances?

… which involves multiple perspectives, including holdings data from portfolio systems, cash balances from treasury systems, liquidity classifications from policies, governance context from committee papers and temporary exceptions documented in communications.

AI can also strengthen data stewardship, exception management, classification, reconciliation, anomaly detection, and workflow automation.

An EKR platform assembles all these elements into a coherent, explainable response. It extends beyond retrieval by selecting evidence, applying rules, reconciling conflicts, and synthesising a conclusion.

Experimentation is Not a Production Architecture – the Argument Against Using Public Models in Production

During discovery and experimentation, a public frontier model such as Claude can be extremely useful. It can help an organisation explore a workflow, test whether a model can interpret the relevant material, identify where human judgement is needed, and show the potential value of an innovative approach. Conducted with synthetic, de-identified or otherwise approved information, this is a sensible way to experiment.

What should be dispensed with beyond that phase, however, is the assumption that the same broadly capable public model should be embedded directly into a regulated production process.

And if it is embedded into production processes – you have to wonder, how on Earth you're going to pull it out.

From the institution's perspective, important aspects of public models may sit outside its control, including model and version changes, data handling and retention, tool access, service availability, and the consistency of model behaviour. Prompt instructions and user caution are useful safeguards, but they do not turn a general-purpose assistant into a controlled enterprise application.

Australian regulators have not prohibited frontier models or prescribed any particular AI architecture. However, APRA's 2026 industry review did call for a step-change in AI risk management and governance, while ASIC has warned that governance arrangements are failing to keep pace with adoption. The regulatory direction is towards clear accountability, proportionate risk management, security, testing, assurance, human oversight, and the ability to explain and evidence outcomes. Directly embedding a public AI assistant into a materially regulated workflow makes those obligations extremely hard to meet.

The production architecture should therefore treat the language model as a bounded and replaceable part, inside an institution-controlled system. Approved models should run through enterprise access controls and governed retrieval, with tightly limited tool permissions, deterministic calculations and rules, complete logging, model and prompt versioning, continuous evaluation, human approval and defined fallback procedures. The institution must own the workflow, evidence, and control framework rather than relying on the frontier-model provider to supply them.

Claude and comparable models may therefore be excellent environments in which to discover what is possible. They should not, by default, become the production architecture. The relevant test is not whether the model can produce an impressive answer; it is whether the complete process can be governed, reproduced, challenged, and defended.

The Role of MCP and Other Integration Standards

A Model Context Protocol (MCP) connection can provide a standard way for a reasoning system to discover and invoke approved data, tools, and workflows exposed by enterprise platforms. In practical terms, an MCP server for an EDM or another system can make governed capabilities – such as retrieving a security record, running a validation rule or requesting a calculation – available through a consistent interface.

MCP does not replace data governance, entitlements, semantic mapping or system-specific controls, and it does not make every platform automatically interoperable. Its value is narrower and more practical: it can reduce bespoke point-to-point integration, preserve the source system's authority and allow the reasoning layer to request evidence or execute approved functions without copying every underlying dataset into a new platform.

For BackPro, MCP is therefore an enabling interface rather than the product thesis itself. The differentiating capability lies in governed orchestration: deciding which sources and tools to use, applying permissions and deterministic controls, retaining provenance, and presenting an answer that a human reviewer can verify.

Broader Reporting

Once established, this architecture supports broader reporting, including board reporting, trustee decision-support, Investment Committee analysis, due diligence questionnaires, whole-of-fund portfolio analysis, risk investigations, operational resilience, liquidity analysis, ESG reporting, audit preparation, merger due diligence, and regulatory-change impact assessments. Each use case requires the organisation to synthesise information across systems and documents.

Across these use cases, the requirement remains consistent: outputs must be explainable, defensible and grounded in authoritative sources. The level of human review and deterministic control should increase with the materiality and risk of the decision.

Conclusion

The evolution of enterprise AI is closely tied to how organisations structure, govern and interpret information. Achieving that requires more than adding an AI interface: TPV cannot depend on probabilistic output alone. It requires governed knowledge, controlled retrieval, deterministic calculations and rules, provenance, approval, and ongoing evaluation. Organisations that build this capability will improve their ability to understand, explain, and act on complex information, in effect, becoming enterprises capable of reasoning about themselves.

BackPro's Skin in This Game

As above, modern regulatory obligations - including APRA liquidity reporting, RG 271 complaints handling, DDQs, investment governance, ESG disclosures and internal board reporting - rarely depend on a single system of record; they draw on exactly the mix of structured and unstructured information described above.

Traditional EDM and other peer platforms remain essential, but were not designed to interpret policy, reconcile conflicting documents or assemble evidence across an entire technology estate. Frontier language models excel at interpreting and synthesising language, but cannot on their own provide the governance, reproducibility, auditability, or data custody demanded by regulated financial institutions. The future is therefore more like EDM and AI, not EDM or AI: taken together with the other systems already in place, each performing the role to which it is best suited – reducing the need to force every item of enterprise knowledge into one all-encompassing data model or ETL pipeline.

BackPro sits above an organisation's EDM and existing technology estate as a governed orchestration and reasoning layer. It does not replace EDM, data warehouses, document management systems, or operational platforms. It can connect to them, combining trusted structured data with controlled retrieval of unstructured knowledge to produce evidence-based answers that are traceable to source.

This architecture enables organisations to:

• Answer complex regulatory and operational questions that span dozens of disconnected systems.
• Generate reports supported by paragraph-level evidence rather than unsupported AI-generated text.
• Reduce weeks of manual investigation to minutes while preserving governance and auditability.
• Democratise access to enterprise data through natural-language interfaces, allowing business users to query governed information without requiring SQL expertise.
• Preserve existing investments in EDM while dramatically increasing the value those investments deliver.

In this model, EDM and peer systems continue to own their respective domains. BackPro provides the enterprise reasoning layer that connects structured data, unstructured knowledge, rules, and evidence. As regulatory obligations expand, advantage will increasingly flow to institutions that can assemble trustworthy answers quickly, explain how those answers were reached, and reproduce them when challenged.

That is the problem BackPro is built to solve.