01 Investing AI
The Investing AI Agent Playbook
A strategic map for launching and scaling AI across digital investing experiences. It helps wealth, product, CX, and AI transformation leaders deploy faster, scale with confidence, and turn investing AI into measurable business value.
Playbook
4.1 Portfolio data
Portfolio data is where an investing AI project becomes real.
Most already have the data somewhere. The hard part is deciding what the agent needs first, how it should access it, which system remains the source of truth, and how to phase the implementation so the first version is useful without asking the bank to expose every portfolio, broker, custody, market-data, and order system on day one.
That last part matters. A credible first phase does not need the full investing app behind it. It needs enough authorised portfolio data to answer a small set of valuable questions correctly. Then the connection can expand, with controls and traces, into richer performance explanations, market context, user-led order flows, and recurring portfolio touchpoints.
In practice, portfolio data is often a broker or custodian connection. But it is also more than that. It is holdings, cash, transactions, valuations, instrument identifiers, order state, entitlements, timestamps, and the business rules around what a client may see or do. Charlie is built to connect to that reality in phases, using tools, connectors, APIs, MCP, and customer-specific plugins instead of forcing every institution into one data shape.
Charlie working with 3 different data providers
What Charlie needs first
The minimum viable data set depends on the first jobs you want Charlie to handle. A read-only portfolio pilot needs much less than a full execution rollout.
First user job | Minimum useful data | Not required on day one | Why this is enough to start |
|---|---|---|---|
Portfolio snapshot | Authorised portfolio ID, holdings, cash, base currency, valuation timestamp | Order routing, alerts, suitability changes | The user can understand what they own and where they stand |
Recent performance explanation | Valuation or performance feed, current positions, contribution data or transactions, market status | Full tax lots, all historical orders, advice workflow | The agent can explain what changed without guessing the number |
Transaction question | Transaction history, movement type, instrument ID, quantity, timestamp, status | Order placement, rebalancing workflow | The answer can match the official account record |
Held-instrument news | Positions, instrument identifiers, approved news or market-data source | All tradable instruments, open web search | The agent can connect market context to what the client actually holds |
Available cash question | Available cash, committed cash, currency, timestamp | Trade execution | The user can understand what is free to use before any order flow is enabled |
The first phase can be read-only
For many, the safest first implementation is a read-only portfolio assistant. Charlie can answer portfolio overview, performance, composition, transaction, and educational questions without placing orders or changing account state.
This is not a weak phase. It is often the phase that proves the hardest trust assumptions: can the agent retrieve authorised data, calculate portfolio figures deterministically, explain them clearly, respect the advice boundary, and produce a trace the institution can inspect?
Charlie’s current tool set includes portfolio overview, composition and diversification analysis, performance analysis, transaction history, news-related questions, market data, order flow, and operational services. Those tools do not all have to go live at once.
Phase | What goes live | Data and connections needed | What the bank learns |
|---|---|---|---|
Phase 0: scoping and sandbox | Mock or sample portfolio conversations | Sample users, sample portfolios, target questions, current API/MCP/service map | Which user jobs are valuable enough for phase 1 |
Phase 1: read-only clarity | Portfolio overview, holdings, cash, transactions, basic performance | Service that provides portfolio holdings, cash, transactions, performance data, and timestamps. | Whether portfolio answers can be grounded, friendly, and reviewable |
Phase 2: market context | Held-instrument news, instrument data, contribution explanation | Instrument identifiers, approved market-data/news provider, portfolio-position mapping | Whether the agent can explain movement without drifting into advice |
Phase 3: controlled order support | User-led order flow, order status, cash checks, confirmation steps | Order service, broker connector, available cash, committed cash, market hours, permissions | Whether action flows can be controlled and traced |
Phase 4: recurring touchpoints | Morning briefings, alerts, portfolio events, proactive education | Event logic, notification rules, review rules, user preferences | Which touchpoints reduce support load and improve engagement |
A simple implementation path
Charlie’s integration model is built around a shared core and a customer-specific plugin. The core handles the agent runtime, prompt configuration, conversation memory, model orchestration, API layer, and guardrails. The plugin handles the bank-specific part: tools, connectors, external tool servers, dependency wiring where needed, and the transport layer back to the host app.
That split is important because large banks and brokers rarely have identical infrastructure. One may expose a clean portfolio API. Another may split holdings, cash, and transactions across services. Another may prefer an MCP server. Another may require gRPC for operational services and HTTP/SSE for frontend updates.
How the connector should behave
A portfolio connector should not be a loose pipe into the model. It should be a narrow, named capability with permissions, input rules, output rules, freshness metadata, error behaviour, and trace logging.
A phase-one portfolio overview tool might look like this:
A real answer path should be inspectable
A client sees a friendly answer. The institution should be able to see the path behind it.
This is why implementation is not only an engineering topic. It is also a product, compliance, and operating-model topic. The system has to answer well, but it also has to show how it answered.
Portfolio data is not one integration
One of the reasons InvestSuite can help here is that we have spent years around the infrastructure behind digital investing: portfolio construction, reporting, robo-advice, self-directed investing, broker and custodian flows, market data, transaction records, and front-end embedding. Charlie builds on that experience.
Large banks and brokers often have several correct answers to the same integration question. Sometimes the right first path is the bank’s own middleware. Sometimes it is an existing InvestSuite product connection. Sometimes it is a broker or custodian connector. Sometimes an MCP layer is the fastest way to expose approved capabilities. Sometimes a mock connector is the right way to unblock product and compliance conversations while production access is prepared.
The point is to choose the path that fits the first phase, not to force a full rebuild before the first client question can be answered.
FAQ
Do you need all portfolio data before starting with Charlie?
Is portfolio data just a broker connection?
Why start read-only?
How does Charlie connect to existing infrastructure?
Can InvestSuite help with connection work?
When should order support come in?
Meet Charlie. The Investing AI Agent.
Give your clients an entire investing experience, rebuilt from the ground up as a conversational AI agent.
