Echo

Echo — Engine for Consolidated Holdings and Optimization — is a live portfolio intelligence platform designed for wealth advisors, financial professionals, and firms that need to understand client investments without manually reconstructing information across PDFs, spreadsheets, calculators, and disconnected reporting tools.

The product began with a practical problem: investment data is available, but it is rarely ready for decision-making.

A Consolidated Account Statement may contain the details of a client's mutual fund holdings and transactions, but it does not directly tell an advisor what has changed, where the portfolio is concentrated, which holdings overlap, what risks require attention, or what should be discussed during the next client meeting.

Echo converts this fragmented financial information into structured portfolio intelligence.

Users can upload investment statements, reconstruct portfolios, analyse holdings, understand allocation and performance, and generate interactive reports. The underlying intelligence can also be exposed through APIs and MCP, allowing the same financial logic to power dashboards, internal tools, reports, and AI-assisted interfaces.

Financial advisors routinely work with information scattered across several systems:

• CAMS and KFintech statements
• Consolidated Account Statements
• Broker reports
• Portfolio-management tools
• Excel sheets
• Calculators
• Client notes
• Presentation decks
• Email and messaging threads

The information itself is not necessarily missing. The real problem is that it is fragmented, inconsistently formatted, and disconnected from the decisions an advisor must make.

A typical portfolio-review workflow may involve:

1. Collecting the latest statement from the client
2. Downloading or opening a password-protected PDF
3. Identifying folios, schemes and transactions
4. Reconstructing holdings in a spreadsheet
5. Calculating current values and returns
6. Reviewing allocation and exposure
7. Comparing funds and identifying overlap
8. Preparing observations manually
9. Converting those findings into a client presentation
10. Repeating much of the process during the next review

The workflow consumes significant effort before the advisor reaches the part that actually creates value: interpreting the portfolio and advising the client.

Most existing products also force users into a fixed interface. The underlying calculations, portfolio logic and recommendations remain trapped inside the application that created them.

This led to a broader design question:

What if portfolio intelligence were treated as reusable infrastructure rather than as a collection of dashboard screens?

Echo was built around three primary hypotheses.

1. Advisors do not need another passive dashboard

They need a system that transforms investment data into preparation, understanding and action.

2. Financial intelligence should not be tied to one interface

The same portfolio logic should be reusable across dashboards, reports, meeting-preparation tools, APIs and AI assistants.

3. Trust matters more than novelty

Financial recommendations cannot behave like unexplained AI output. Every figure and insight must remain traceable to portfolio data and deterministic calculations.

These principles pushed Echo beyond the initial idea of a statement parser.

The parser became the entry point. The actual product became the intelligence layer built on top of the parsed portfolio.

The research process combined domain exploration, workflow analysis, competitive review and product experimentation.

Understanding the advisor workflow

We examined how investment professionals prepare for client discussions and where the most repetitive work occurs.

The process revealed that advisors were not merely looking for cleaner charts. Their work involved several layers:

• Receiving and interpreting investment data
• Identifying portfolio issues
• Understanding the client context
• Converting findings into a coherent narrative
• Preparing suitable recommendations
• Presenting the analysis in a way the client could understand

A dashboard could help with one part of this workflow, but it could not solve the entire preparation cycle unless the underlying financial intelligence was structured and reusable.

Understanding the source data

CAS documents contain substantial financial information, but their structure creates several challenges:

• Different layouts and statement formats
• Inconsistent naming of schemes
• Multiple folios for the same fund
• Duplicate or incomplete records
• Purchase, redemption and switch transactions
• Dividend and reinvestment entries
• SIP transactions spread across long time periods
• Missing or inconsistent identifiers
• Password-protected files
• Documents containing several investors or account holders

This meant that the product could not begin at the dashboard. It had to begin with data normalization and portfolio reconstruction.

Competitive exploration

We looked at portfolio-management tools, reporting products, advisor platforms and statement parsers.

Many were useful for tracking investments, but several patterns appeared repeatedly:

• Data was locked inside the product
• Reports were heavily template-driven
• Interfaces exposed metrics without explaining implications
• Intelligence was difficult to reuse elsewhere
• AI features often operated as an additional chat layer rather than part of the product architecture
• Advisors still needed to translate raw metrics into meeting-ready observations

This reinforced the decision to separate the financial engine from the presentation layer.

Insight 1: Parsing is necessary, but not differentiated

Extracting values from a statement is technically important, but a parser alone creates limited ongoing value.

The more valuable question is what the product can understand after the data has been parsed.

Design implication: Echo was structured around portfolio intelligence, with parsing treated as an ingestion capability.

Insight 2: Advisors need evidence before recommendations

A recommendation without supporting information creates risk.

Design implication: Insights need to connect back to holdings, allocation, transactions or calculations rather than appearing as unsupported conclusions.

Insight 3: Reports are not the final product

A report is one representation of the intelligence. The same analysis may also be needed in a dashboard, during a meeting, inside an AI assistant or through another application.

Design implication: Financial logic was separated from individual interfaces.

Insight 4: The platform must accommodate different advisory styles

Some advisors want detailed analysis. Others want a concise client summary. Some firms may want to build their own interface entirely.

Design implication: Echo was designed as a modular system rather than a rigid end-user application.

One of the most important parts of the project was determining what Echo should actually be.

Several form factors were explored.

Statement parser

The earliest and most direct form was a tool where a user uploads a CAS and receives a structured summary.

This was useful, but too narrow. It solved document processing without addressing the advisor's broader workflow.

Portfolio dashboard

The dashboard made holdings, allocation, returns and other metrics easier to explore.

However, a dashboard still required the advisor to interpret the information and manually carry it into other tools.

Interactive client report

Interactive reports helped convert portfolio data into a format that advisors could review or share.

This improved communication but still represented only one output.

Advisor copilot

An AI-assisted interface could allow advisors to ask questions about a portfolio, generate summaries, or prepare for meetings.

The weakness was that an AI interface without reliable underlying calculations would be difficult to trust.

Financial intelligence API

Separating portfolio calculations and insights into APIs made the intelligence reusable.

This created a more flexible foundation but required a clear product layer above the infrastructure.

MCP-connected intelligence

MCP allowed Echo's capabilities to become available inside compatible AI environments and development tools.

Instead of rebuilding every possible dashboard, users could connect Echo's financial logic to other interfaces and create workflows around the same underlying intelligence.

Final direction

Echo evolved into a combination of:

• A live portfolio-analysis product
• A deterministic financial engine
• A report and interface layer
• An API-accessible intelligence system
• An MCP-compatible capability layer

This allows Echo to exist both as a product and as infrastructure.

Echo is organised into several conceptual layers.

1. Data sources

The system receives investment information from sources such as:

• Consolidated Account Statements
• CAMS and KFintech documents
• PDF and spreadsheet uploads
• Potential broker or financial-data integrations

2. Parsing and normalisation

The platform identifies and structures:

• Investors
• Folios
• Mutual fund schemes
• Transactions
• Units
• Purchase values
• Current values
• Dates and transaction types

Different names and formats are normalised into a consistent portfolio model.

3. Portfolio reconstruction

Transactions are transformed into a current view of the client's holdings.

This layer establishes the data required for calculations and analysis.

4. Financial calculation engine

The engine calculates metrics such as:

• Invested value
• Current portfolio value
• Absolute gains
• Allocation
• Scheme-level exposure
• Category exposure
• SIP activity
• Portfolio performance
• XIRR or related return calculations where sufficient data is available

5. Portfolio intelligence

The platform converts metrics into interpretable findings, including:

• Concentration
• Allocation imbalance
• Fund overlap
• Sector exposure
• Portfolio composition
• Potential review opportunities
• Areas requiring advisor attention

6. Delivery layer

The same intelligence can be made available through:

• Interactive dashboards
• Client-ready reports
• APIs
• MCP tools
• AI interfaces
• Future embedded applications

Flow 1: Uploading a portfolio statement

The user uploads a supported investment statement.

The system then:

1. Validates the file
2. Extracts portfolio and transaction information
3. Normalises scheme and folio data
4. Identifies potential parsing issues
5. Reconstructs current holdings
6. Generates the portfolio view

The user should not need to understand the underlying document structure.

Flow 2: Reviewing the portfolio

Once processing is complete, the user can explore:

• Total invested value
• Current value
• Gains or losses
• Scheme distribution
• Asset and category allocation
• Historical transactions
• SIP activity
• Exposure and concentration

The goal is not simply to display every available metric. The hierarchy prioritises the questions an advisor is most likely to ask first.

Flow 3: Investigating a holding

The user can move from the portfolio level to a particular fund or holding.

This enables them to inspect:

• Contribution to the overall portfolio
• Transaction history
• Allocation
• Performance
• Potential duplication or overlap
• Relevant risks or observations

Flow 4: Identifying portfolio opportunities

Echo surfaces issues that may require professional review.

These are not presented as autonomous financial advice. They act as structured observations for the advisor to evaluate.

Flow 5: Creating a client-ready report

Portfolio information can be transformed into a more readable report.

The report is designed to help the advisor communicate:

• What the client owns
• How the portfolio is distributed
• What has changed
• What deserves attention
• Which topics should be discussed

Flow 6: Accessing Echo through AI tools

Through APIs and MCP, another interface can request portfolio calculations or structured insights from Echo.

The critical design decision is that the external AI system does not need to recreate the financial logic. It can use Echo as the trusted calculation and intelligence layer.

Echo required more than interface prototyping.

Workflow prototypes

Early prototypes explored how advisors would move between:

• Upload
• Portfolio overview
• Holdings
• Analysis
• Insights
• Reports

These prototypes helped reduce unnecessary navigation and clarified which information belonged at each level.

Data and calculation testing

Financial outputs were tested against source documents and expected calculations.

This was essential because a visually polished portfolio with incorrect values would have no practical value.

Testing focused on:

• Missing data
• Multiple folios
• Duplicate schemes
• Transaction classifications
• Irregular SIP activity
• Redemption and switch scenarios
• Calculation consistency
• Parsing failures

Form-factor testing

The team explored whether specific use cases were better served by a dashboard, report, API or conversational interface.

This helped avoid forcing every workflow into the same UI.

Live-product iteration

Because Echo is live, design decisions continue to evolve based on actual implementation constraints, observed workflows and new use cases.

The product remains active rather than frozen at a portfolio-case-study milestone.

Separating intelligence from interface

The most significant decision was to avoid embedding all domain logic inside the frontend.

This allows the same calculations to support multiple products and interfaces.

Tradeoff: The architecture is more involved than building a single dashboard.

Using deterministic calculations for financial outputs

AI may assist with interpretation or interaction, but core financial calculations must remain deterministic.

Tradeoff: This requires more explicit financial logic and testing than relying on generated summaries.

Prioritising progressive disclosure

A portfolio can contain hundreds or thousands of transactions. Displaying everything at once would create cognitive overload.

The interface begins with the portfolio-level picture and allows users to progressively investigate categories, schemes and transactions.

Designing around questions rather than datasets

The navigation and information hierarchy were structured around advisor questions:

• What does the client own?
• How is it performing?
• Where is the portfolio concentrated?
• What has changed?
• What should I review?

This is more useful than organising the product around database entities alone.

Avoiding an AI-first visual identity

Although Echo can connect to AI tools, the product is not positioned as a chatbot wrapped around investment data.

The interface foregrounds portfolio evidence and calculations.

Unstructured financial documents

CAS documents are not clean API responses. Parsing must accommodate layout and formatting variations.

Financial accuracy

Minor calculation or mapping errors can undermine the credibility of the entire product.

Large transaction histories

Long-standing investors may have extensive records that must be processed and presented without overwhelming the interface.

Explainability

The system must help users understand how a value or observation was produced.

Security and privacy

Investment statements contain sensitive personal and financial information. The product architecture must account for access control, storage security and responsible data handling.

AI reliability

AI-generated explanations must not alter deterministic calculations or fabricate financial information.

Extensibility

The intelligence layer must remain flexible enough to support interfaces and workflows that were not anticipated during the initial build.

Echo currently includes a working foundation for:

• CAS upload and processing
• Portfolio reconstruction
• Holdings and allocation analysis
• Performance and gain calculations
• SIP and transaction analysis
• Portfolio-level dashboards
• Interactive reporting
• Financial intelligence capabilities
• API-accessible logic
• MCP-enabled integrations
• Reusable infrastructure for future advisor workflows

Echo is live, but its direction continues to expand as new advisory use cases are identified.

Echo began as a solution to an information-processing problem, but the deeper opportunity was not document parsing.

The important shift was recognising that the product's value lies in making financial logic reusable.

Building only a dashboard would have produced a more conventional product. Building only an API would have made the product harder to experience. Echo needed both: a working application that demonstrates value and an intelligence layer that can support many future applications.

The project has also reinforced that financial products must earn trust structurally. Attractive interfaces and conversational AI cannot compensate for opaque calculations or unreliable source data.

The next phase is not simply to add more screens. It is to deepen the quality of the intelligence, expand the workflows that can be powered by it, and determine where advisors gain the most practical value from the system.