What a conversational layer does to fragmented systems
The major AI labs have begun offering products for financial services. These initiatives target the professional's work — researching, preparing, drafting, reviewing — and operate at the same layer. None of them sets out to be the system of record where the firm's official data lives. They are access layers added on top of infrastructure that remains separate.
As we covered in our analysis of architecture and data control in wealth management, this is the source of the structural limitation that matters to anyone running portfolios: a conversational layer answers on the version of the data it can reach.
In equity research that is enough, because the source is a published document and there is only one version of it. In wealth management there is no finished version sitting in a document: there is a continuous process of determination. The connector reaches several sources; it doesn't decide between them.
That distinction marks the dividing line between two architectural approaches: integrating fragmented systems through an external access layer, and a native front-to-back platform with a conversational engine built into the operation.
The source of truth is not a document. It's a process.
Ask an advisor where the market value in a client's consolidated report came from. The correct answer never points to a static statement.
That number did not exist until it was actively produced.
This is where the processing layer does its work:
Looking through structures. Rather than stopping at the wrapper of an offshore vehicle or a dedicated fund, the structure is opened up to map the real exposure of the underlying assets.
Handling illiquids and alternatives. Assets whose official value arrives weeks late, in different currencies and under different methodologies, are handled automatically.
Continuous processing of operational data. Hundreds of data sources and operational connections are consolidated and cross-checked on an ongoing basis to produce a clean, auditable base.
The custodian's statement is not the end result. It is one of the inputs reconciled daily through double-entry logic: the position the custodian declares against the position calculated from the transactions.
Mature consolidation platforms determine the position with equivalent rigour. The difference shows up in how far that determination reaches inside the firm. An external connector, operating apart from the processing layer, reads the data without establishing where in the reconciliation cycle it stood at that moment. It carries an error with the same elegance as it carries a correct figure.
Genuine front-to-back: removing the firm's fragmentation
Even when a firm uses a specialised portfolio consolidation platform to determine positions accurately, the rest of the operating cycle usually remains scattered:
- Onboarding runs in one tool
- CRM and meeting records in another
- Financial planning in a third
- Trading and rebalancing in a fourth
- Billing and reporting in spreadsheets or legacy systems
The result is that the firm ends up with five different photographs of the same client circulating internally, each taken at a different moment. Bolting a conversational connector onto that structure unifies the access interface, but the conflict between the photographs remains.
The front-to-back approach: a workflow without internal borders
The architectural alternative is to remove the borders between stages. The same reconciled base that calculates the portfolio's position is the one that feeds onboarding, CRM, planning, order execution and report generation.
That removes file exports, dependence on external API integrations, and duplicated databases.
In the software-mosaic approach, the external connector captures snapshots from multiple providers. If the data is in a break at source, the conversational layer answers on the discrepancy without flagging it, and the user has to switch systems to investigate or act. In Pivolt's integrated front-to-back approach, the daily control displays the confidence state of each position, so the conversation takes place in an environment where it is possible to query, analyse, decide and execute within the same flow.
Operational natural language: conversation as the system's interface
Architecture shows up directly in the workflow. As we covered in Why an LLM Should Never Compute Your TWR, the language model explains a number, it doesn't produce one. What changes is where the request lands and what it can set in motion.
In generic connectors, the conversational interface is built for querying data or drafting text. When the conversational engine is native to the platform, the natural language layer operates the system directly:
- Questions about risk, return or performance attribution across multi-custodian portfolios are answered on the official determination, with no context limits and no manual pasting of files.
- The report generator writes the portfolio narrative from the same figures shown in the determination tables, so commentary and report come from one source.
- The operator carries out tasks without leaving the interface, instructing a portfolio rebalance, resolving a reconciliation break, or issuing reports in batch, all through text.
- A new account is created in the same environment where it will be administered, structured to receive proposals and analysis from day one.
Sentence and action become the same thing. Every command executed in natural language leaves a full audit trail, recording author, timestamp and scope of the change.
Unifying access is not unifying data
Generic conversational layers do an efficient job wherever public or static information is enough: looking up a fund's prospectus, summarising a published report, working through a third-party document.
But most of what a wealth manager delivers to a client depends on the official position: the quarterly report, the allocation proposal, the rationale for a rebalance, the billing. For that critical layer, an external connector offers ease of access over data that remains scattered.
The connector unifies the point where the question is asked. It does not unify the data the answer is calculated from. It acts on the need to switch between screens, which is the symptom, without changing the existence of multiple photographs of the same client, which is the cause.
Pivolt took the opposite approach: rather than layering a chat over assorted systems, it built a platform where the reconciliation engine, the operational suite and the conversational interface sit in the same architecture.
When assessing an AI layer for wealth management, the central question goes beyond how fast the answer arrives. What matters is:
Which version of the data is the intelligence answering on? A position reconciled daily against transactions, or a snapshot captured from a statement?
Who produced that version within the firm's workflow? The platform that runs the operation, or a third-party system the connector merely reads a result from?
What happens when a number has to be acted on or corrected? Does the adjustment require navigating other systems, or is it executed directly in the flow, in natural language, with an audit trail?
The answers to those three questions mark the boundary between tools that carry data and the infrastructure that answers for it.
