We live in extraordinary times. The software used by financial professionals, investors and traders is being reinvented before our eyes. Traditional desktop terminals and monolithic applications are being challenged by a wave of AI-native products that can answer complex questions, build applications, write code and automate workflows in seconds.
Many of these products began life as general purpose large language models. Over time they've learned the language of finance, and every week they become more capable. Connectors, Skills, Projects, MCP servers and agent frameworks now allow them to interact with internal and external systems, automate tasks and collaborate with other applications and each other; Anthropic just released Managed Agents - an orchestration layer that brings this all together.
Alongside the foundational models, an entire ecosystem of specialist startups has emerged. Many wrap the same underlying LLMs with polished user experiences, finance-specific workflows and proprietary data. Some are excellent. But underneath, they all share the same reality: the LLM itself has fundamental limits when it comes to finance.
By definition, the knowledge inside a foundational model is frozen at the point it was trained. Markets, however, change every millisecond. New securities are listed. Companies report earnings. Prices move. Corporate actions occur. Regulations evolve. For almost every serious financial use case, augmenting the model with trusted, real-time data isn't optional—it's fundamental.
Equally important, an LLM is not a database. Despite how convincing it sounds, it doesn't store or retrieve structured financial information in the way a market data platform does. It is an extraordinary reasoning engine, but it still needs access to authoritative, structured, permissioned data if it is going to produce reliable answers. Ask it to perform calculations over large datasets, reconstruct decades of financial history, or understand millions of continuously changing market events without the right architecture, and you quickly reach the limits of what an LLM alone was designed to do.
That's why we see the LLM as the interface, not the data platform. The intelligence comes from combining powerful reasoning with trusted, structured market data, efficient retrieval, and robust governance. And that's where many of the hardest engineering problems begin.
At a recent event in London, co-sponsored by 9fin, I presented what I think are the three problems we keep running into as agents meet market data, and how we think about - and build for - each of them at viaNexus. I've included several of those slides, and reach out if you would like the full deck!
The three failure modes
Every issue we see traces back to one of three root causes:
● Hallucination - models confidently fabricate financial facts.
● Token burn - agents burn enormous (and expensive) amounts of compute reasoning over data they were never set up to reason over.
● Audit, controls & entitlement - nobody has properly worked out who is allowed to access what once an autonomous agent is in the loop.
Here's how we map those problems to what's actually needed, and where viaNexus intervenes:
Some of these have a single fix. Token burn, in particular, needs a multi-pronged approach — there isn't one silver bullet. Let's take them one at a time.
1. Hallucination isn't just a model problem - it's a plumbing problem
The primary source of “knowledge” for an agent is a foundational model trained on a wide swath of text, with a cutoff date baked in. Give that model live internet access to build, say, a stock report, and you'll quickly run into made-up figures, or data quietly scraped from sources that were never licensed for professional use.
Our advice: turn off live web access, or put tight constraints on what the model can reach unassisted. Connect it instead to reliable, licensed data sources through viaNexus' Agentic Service Technology (vAST). It sounds obvious, but it's the single highest-leverage thing you can do.
The harder version of this problem shows up once an agent has to reason across datasets. Plumb six different MCP servers into a chat agent and you get different tickers, different timestamps, different field names for the same concept. The model ends up hallucinating joins between them, and - worse - you have no audit trail showing that it happened.
Agents are being asked to do more, to reason across more and more disparate datasets. In finance, these could be requiring the agent to reason across price and fundamental data. Maybe tickers and symbology are inconsistent. Maybe the underlying schemas. Maybe the documentation that the MCP client relies upon is just poor, incomplete or maybe too complex.
We call this MCP spaghetti, and it's the trap on one side of this diagram:
Our answer is a normalized data layer. Our reference data is the canonical symbol master, and datasets are mapped onto it on ingest so they join on the same key. We parse dozens of vendor date formats into a single storage format, and every dataset declares its time column so you can range-query them all the same way. The agent ends up talking to one model instead of six raw feeds, and every call is entitled and audited as it happens. Metadata is generated: we sample the real values in each column, match them against our symbol master, and when three quarters or more of them resolve we type that column as a securities identifier and record it as the dataset's join key. That's what our semantic layer runs on - and it's why datasets interoperate instead of leaving the agent to guess at the joins.
If you don't want to consume everything through us, that's fine too - the same principle holds if you onboard data yourself: normalize lightly on the way in, host it behind your own MCP server, and you'll see the same reduction in hallucination and token burn. (BTW we can also deploy viaNexus as your onboarding and normalization layer if that's a better fit - more on that in a future post!).
2. Token burn: the subsidy is real, and it won't last forever
Everyone has been amazed at the productivity gains from agents, and how affordable they've seemed. But much like the early days of cloud computing, it's increasingly clear that LLM providers are subsidizing a large share of the true cost. We're already seeing firms hit unexpected usage limits or costs blow out - some estimates put the real cost of a $200/month “pro” account closer to $20,000, roughly 100x.
Agents burn tokens fastest when they're not used thoughtfully: feed them inconsistent or ambiguous data, ask them to join datasets to do arithmetic, or tell them to continuously poll a market and watch for a change - and the outcome is delayed responses, and high costs.
Our suggested approach is to move the parts of this workload that shouldn't be inside a context window into a platform - or into a purpose built app (see below). And viaNexus can be that platform.
Pre-calculate the analytics
Give an agent raw ticks and ask it to compute a 50-day moving average on the fly, and you get two problems: it's unreliable and non-deterministic, and it's expensive. Instead, we build the common analytics like moving averages, crossovers, valuation ratios directly into the platform and expose the results to the agent.
Expecting the agent to do the mathematics means per-calc inference cost, seconds of latency, non-determinism, and math errors that compound at scale. Pre-computing it in the platform means deterministic, sub-millisecond results that are audited and composable across signals.
Stop making the agent stay awake
Market monitoring is one of the biggest potential token-burn offenders we see. Ask an agent to watch for a golden cross, a new filing for a company you are watching closely, or a multi-factor condition, and the naive approach is a polling loop: re-query the data on every tick, hold session state in memory the whole time, and let a non-deterministic model decide whether “now” is the moment something happened.
Originally built by a US exchange, viaNexus is essentially an event-processing platform - and the perfect place to hand off event monitoring to. Register a condition once - a price level, a technical crossover, a new filing, a multi-factor combination across datasets and viaNexus sets the query, and monitors it for you. This way the agent hands off the market monitoring to a platform built for the task!
The agent sleeps until the condition fires - triggering an email to the end user, or perhaps waking up an agent with a payload of data for it to reason over. No polling, no drift, no missed events because a sampling window happened to land in the wrong place.
And control can be directly from Claude - or your agent LLM of choice, once you have connected to the viaNexus MCP server.
Leave Rendering to the Experts
Just as LLMs need to hand off monitoring to platforms, downstream they should hand off display, calculations and analytics to apps that are built for that purpose.
If left to its own devices, Claude loves to build apps - charts, tables, whatever. Instead of allowing Claude to pull some stock price data into a chart application it builds on the fly – have it hand off the delivery of this data to an REST API. Maybe have Claude Code build the app for you!
LLMs are increasingly being configured to recognize certain types of data, and can invoke applications to render that data, which can then be persisted on a user’s desktop. The viaNexus agent SDK can play a role here - helping an agent direct that app to the correct API as opposed to populate it through the agent - burning tokens as it goes.
A few interesting projects in this space – for example technology company HERE (formerly OpenFin) has a project called Catalyst - which aims to help improve integration of LLMs with interoperable applications. Think "Minority Report" for finance.
3. Audit, controls & entitlement: the risk nobody's fully priced in yet
Data licensing was already a minefield before agents showed up - a maze of usage rules and traps designed by some vendors to maximize revenue from any given dataset, enforced by vendor audit teams that everyone dreads hearing from. Big firms frequently end up with multi-million-dollar true-up bills from licensing violations that were entirely unintentional. But it's also important for viaNexus - where we need to permission partner data to client accounts.
Autonomous agents raise the stakes considerably. Plug an agent into a vendor's MCP server to pull a financial statistic - say duration for a bond, and that same agent may technically be able to see related data like terms and conditions, or corporate actions data, that it was never entitled to use. Nothing stops it from doing exactly that unless the controls are enforced somewhere more durable than a prompt.
Our approach enforces entitlement at the credential, not the conversation. The same client account can issue many keys and run a research agent, a trading agent, and a compliance agent side by side, each restricted to its own named set of datasets - one sees news and transcripts, another sees pricing and flows - and every data request is checked against that key's grant list server-side before any data is returned. Grants are strictly subtractive: a key can never exceed the account's own entitlement. Agents exchange a signed, single-use software statement for an OAuth access token that expires in one hour, and every subsequent request is validated against the authorization server by token introspection, so entitlement is delegated, not inherited, and revocable on demand. This is enforced at the credential level, not the app and not the prompt - which means it holds even if someone builds an integration we never anticipated.
Where this all comes together: vAST
We have been fortunate in that our platform was largely ready for MCP. We already normalized data across a wide variety of source types. We already had a well designed approach to authentication. The system could already generate conditional alerts. And our engineering team were up for the challenge. This meant that rather than bolt on an MCP server - we built a set of services that built on this solid foundation: viaNexus Agentic Service Technology (vAST) is a multi-tenant MCP Server, a prebuilt Financial Chat Agent, and an open-source Agent SDK, all sitting behind one signed credential and a single token-introspection layer that resolves dataset permissions. Tools allow users to create alerts, change the coverage list, as well as retrieve data. We even added a tool to help Claude figure out the current data and time! Use all this to build your own chat agent, and check out AskNexus for inspiration.
For more info: https://vianexus.com/vast/
None of this makes hallucination, token burn, or entitlement risk disappear entirely - nothing does, yet. But treating them as plumbing problems rather than model problems has, in our experience, been the difference between an agent that's a genuinely useful colleague and one that's a confident, expensive liability.
We'll keep sharing what we learn as we go. If you want to dig into any of this in more technical detail, reach out — we're always happy to set up a briefing.
