How MAIA provides a governed, permission-aware foundation for client-controlled AI

MAIA gives investment managers a controlled route from live portfolio data to AI-enabled research, analytics and operational workflows—without positioning the model as the system of record or the calculation engine.

The opportunity

Investment firms are increasingly exploring AI across research, portfolio analysis, development and investment operations. Access to a capable model is only part of the challenge. The model also needs timely, reliable context and a controlled way to retrieve it.

For many firms, portfolio context is assembled through overnight files, periodic exports, duplicated data stores and bespoke integrations. Those approaches remain useful for reporting and control, but they can introduce latency when the objective is to investigate the portfolio as it stands now.

MAIA addresses this data-access problem at its source. Its event-driven architecture continuously processes changes in positions, cash, exposures, PnL, orders and lifecycle events. Through the Client Gateway, approved applications can retrieve supported data programmatically, subject to the permissions of the authenticated user.

“MAIA is the trusted data and integration foundation—not the client’s LLM. The client selects the model, controls where it runs and determines how its outputs are validated and used.”

Tobe Awagu, CTO MAIA

Why MAIA is well suited to AI-enabled workflows

MAIA is a distributed network of Java processes known as engines. Each engine typically encapsulates a defined business capability—such as IBOR, PnL, compliance or order management—and reacts to relevant events as they occur.

A proprietary high-performance messaging framework propagates precise changes, or deltas, between subscribed engines. Instead of repeatedly redistributing complete objects, MAIA can communicate the fields that changed. The append-only event model also supports detailed auditability where required.

This architecture creates a consistent event-driven data fabric across the platform. New capabilities can subscribe to the information they need without requiring every existing engine to be redesigned. The Client Gateway is an example: it extends MAIA’s internal data model into multi-language client APIs while preserving the underlying platform architecture.

• Continuously updated portfolio state. Data moves through the platform as trades, prices and lifecycle events are processed.
• Deterministic calculations. Core values such as positions, exposures and PnL continue to be calculated by MAIA’s tested business engines rather than delegated to a language model.
• Single-tenant deployment. Every client has a segregated AWS environment, supporting clear operational and data boundaries.
• Extensible access. The Client Gateway provides a secure bridge between client applications and the client’s dedicated MAIA environment.

A permission-aware route from MAIA to AI

MAIA does not send a client’s portfolio to a public model or provide an unrestricted AI connection. Instead, the client decides which AI service is approved and how it is deployed. The integration then uses MAIA’s existing access path and permission model.

• Choose the AI environment. The client selects the model, provider, hosting arrangement and internal governance appropriate to the use case.
• Authenticate through the Client Gateway. The integration connects as the logged-in MAIA user.
• Use MAIA-provided skills and plugins. For supported AI tools, these extensions help the agent understand the API structure, available operations and recommended workflows. They guide usage; they do not grant additional access.
• Retrieve permissioned data. MAIA returns data according to the entitlements of the gateway user. The AI application cannot use the skill or plugin to bypass those permissions.
• Validate and apply the output. The client determines how results are checked, approved and incorporated into research, analytics or operational processes.

Current and expanding integration options

our capabilities and what they mean for you:

• Event-driven portfolio platform
  Domain engines continuously process positions, cash, exposures, PnL, orders and lifecycle events.
• Client Gateway and APIs
  Programmatic access to supported MAIA data and workflows, subject to the permissions of the authenticated gateway user.
• MAIA skills and plugins
  Reusable guidance and tooling that help supported AI assistants understand MAIA APIs and carry out defined client workflows.
• Client-hosted MCP server*
  Clients can use MAIA with MCP-compatible AI tools today by building a client-hosted MCP layer around MAIA’s permission-aware APIs. MAIA’s planned out-of-the-box MCP server will standardise and simplify that deployment.

* The planned MCP server will provide compatible AI applications with a structured set of MAIA tools. Clients will run it within their own infrastructure, keeping model choice, external-provider credentials and the AI execution environment under client control. Access to MAIA will continue to be governed by the authenticated user’s permissions.

Illustrative use cases

The following examples illustrate how clients may combine MAIA’s data foundation with approved AI or analytical tools. They are not claims that MAIA itself generates investment decisions.

1. Portfolio-aware research

An approved research assistant can retrieve a permissioned view of current holdings, exposures or recent activity from MAIA and use it to prioritise research from the client’s licensed sources. The portfolio data supplies context; the research service supplies the content. The portfolio manager remains responsible for interpretation and investment decisions.

Potential benefit: research can be organised around the portfolio as it stands now, rather than a previous-day export.

2. Natural-language portfolio interrogation

A client-controlled assistant can translate a user’s question into defined MAIA API calls—for example, retrieving current exposure by fund, strategy, asset class or counterparty. The response can explain or summarise values calculated by MAIA without asking the language model to recreate the underlying financial logic.

Potential benefit: faster discovery and explanation while retaining MAIA as the source of the underlying portfolio calculations.

3. Operational analysis and exception support

Operations teams can use AI-assisted scripts to investigate exceptions, assemble relevant MAIA records and draft investigation notes. This can be combined with internal client data for better context.

Potential benefit: less manual data gathering and faster investigation, while controlled calculations and approvals remain in the established workflow.

4. Client-defined analytics and quantitative models

Client models can consume current positions and exposures through MAIA’s APIs. Coding agents such as OpenAI Codex or Claude Code may help a client’s developers create, test and refine the integration, but the resulting model or script runs as a client-controlled application rather than as a native MAIA calculation.

Potential benefit: development teams can build on a consistent portfolio-data source without requiring a change to MAIA’s core engines for every client-specific analysis.

5. Reporting and explanation

An approved assistant can draft commentary around portfolio changes, PnL movements or attribution results already calculated by MAIA. The output can include the underlying values and timestamps used, making it easier for a reviewer to validate the narrative before distribution.

Potential benefit: reduced effort in producing first drafts while preserving human review and accountability.

Control remains with the client

A credible AI deployment must address more than connectivity. MAIA’s role is to provide accurate platform data through the client’s existing security boundary. The client remains in control of the wider AI solution, including model approval, provider terms, data residency, retention, monitoring and human oversight.

• Existing permissions remain authoritative. API and future MCP requests are limited by the entitlements of the authenticated gateway user.
• MAIA calculations remain deterministic. Language models can retrieve, explain and organise results without replacing tested position, PnL, exposure, compliance or risk logic.
• AI deployment is client controlled. The model and, in future, the MCP server operate within infrastructure and governance chosen by the client.
• Third-party rights still apply. Clients remain responsible for the permitted use of market data, research and other externally licensed information supplied to an AI workflow.
• Material outputs require appropriate review. The level of testing and human approval should reflect the impact of the use case.

The MAIA advantage

The firms that obtain durable value from AI will not do so through model choice alone. They will combine capable models with current data, deterministic calculations, controlled access and clear accountability.

MAIA provides that foundation through its event-driven architecture, real-time IBOR, permission-aware Client Gateway and extensible API ecosystem. Skills and plugins make those APIs easier for supported AI tools to use today. The planned client-hosted MCP server will extend the same approach through a standard tool interface while keeping the AI deployment under client control.

“MAIA enables clients to add AI incrementally and responsibly: start with permissioned access to trusted portfolio data, retain deterministic calculations in the platform, and apply AI where it can improve discovery, explanation and workflow productivity.”

Tobe Awagu, CTO MAIA