What is the VNX Price?

VNX Price is viaNexus's near real time predicted price for U.S. equities. It uses bid and ask observations across multiple venues to generate an implied market price, and gives you a cost effective input for portfolio views, dashboards, alerts, analytics and AI workflows that do not need every exchange tick, or exchange level licensing.

But what's going on behind the scenes and how good is it?

Why a screen full of quotes is NOT a price

If you’ve ever looked at raw market data, you know the struggle. A single stock trades across dozens of places at once, each screaming its own bid and ask. When markets are quiet, they mostly agree. But when things get spicy, those numbers pull apart fast. Somewhere in that mess is the actual price your product needs to display, but raw feeds leave you hanging.

Here are the three big culprits ruining your market view:

• Venues conflict: Pick one venue and you’re gambling; average them all and bad quotes pull your price off course.
• Delays creep in: Consolidated feeds can lag by 15 minutes. Great for a basic website, useless if you need live pricing.
• Feeds are full of noise: Tight trades mix with wild placeholder quotes, meaning a single stub quote can jerk your price around by dollars.

Most teams who reach out for the VNX Implied Price do not need more raw data. They already have feeds coming out of their ears. What they actually need is one trustworthy number they can confidently put in big bold font on screen.

It’s a semantics problem, not just quick math

Fusing quote streams sounds like basic averaging, right? Wrong. Before combining quotes, you must prove they refer to the exact same instrument right now. A simple ticker string is not enough. Symbols change across countries, securities cross-list on multiple venues, and corporate mergers constantly shift the landscape.

That’s why viaNexus treats securities as rich nodes in a real-time knowledge graph rather than flat strings. We map ISINs, CUSIPs, FIGIs, and exchange codes using explicit relationships like LISTED_ON and ISSUED_BY, tracking exact start and end timestamps for every link.

When a company delists or restructures, corporate action feeds update the graph automatically. No manual mapping tables, no outdated hacks, just clean traversal based lookup that always reflects reality today.

How the engine works: Three simple layers

1. Ingestion Engine: Normalizes raw vendor feeds into a single contract-governed envelope while carefully preserving original source provenance.
2. Semantic Layer: Resolves real-world asset identity on the fly using our graph so callers can request data using any identifier format.
3. Logic Layer: Runs real-time transformations and predictive pricing models on clean, enriched quote streams without waiting for overnight batch jobs.

The secret sauce: Accumulate, Predict, Adapt

Accumulate: We build a running picture of active quotes per symbol, throwing away stale or unusable placeholders.

Predict: We isolate genuine clusters of agreeing top-of-book quotes. Order book size acts as an anchor to anticipate where the next trade will land.

Adapt: Fast-moving stocks and quiet names need different rules. The system continuously measures quoting velocity to tune its publication thresholds per symbol.

Why silence is actually a feature

VNX Implied Price doesn't spout numbers just because a message came across the wire. It only publishes when there is solid, credible evidence. If a stock’s liquidity looks messy, the feed stays quiet. While a pause in updates might look like an outage at first glance, it’s intentionally designed that way: we’d much rather stay silent than hand you a bad price.

The Result

Through continuous refinement and adaptation of our predictive models, we achieve clear, measurable results. Our model delivers real-time price forecasts based on asset liquidity, producing updates in under two minutes even for less active equities.

For high-liquidity assets like S&P 500 constituents, our model outputs updated price estimates every few seconds.

The chart below illustrates AAPL price predictions compared against the 15-minute delayed SIP feed:

Not just an indicated price

viaNexus is not just a marketplace for a wide range of market and financial data. The platform also integrates with your favorite agent platform or LLM. That is not just for pulling the latest prices on demand, or for buildingyour own live market dashboard. Once you have access to the VNX Price feed you can ask the viaNexus platform, through that LLM, to monitor those prices for you:

"Tell me if any of my stocks move by more than 1% in a given day."

And that alert is set. It will ping you if and when it happens. The same thing watches for golden crosses, or for a new dividend declared on one of your stocks.

What you get out of the box

You get one simple, real time stream per symbol. Each update includes the implied price, synthetic bid and ask quotes with depth, high and low markers, and timestamp metadata, delivered over streaming sockets with no polling.

VNX Implied Price is a live estimate of where the market is pointing right now, backed by a platform that understands what each quote means before it relies on it.

Try it on a free 14 day trial, and start building.

Curious about the architecture behind viaNexus? Contact us or read the VNX Price documentation.

Start a free trial, add the connector in Cursor or Claude, and ask it for a live price.

What is a semantic layer for market data?

As Generative AI and Large Language Models (LLMs) transition from conversational interfaces to autonomous execution agents in financial markets, they hit a critical bottleneck: raw financial data is inherently messy, fragmented, and devoid of standardized context. When autonomous agents attempt to consume uncurated time-series or unstructured feeds, the result is predictable—astronomical token burn, context-window exhaustion, and dangerous factual fabrications ("hallucinations").

To make AI reliable for institutional finance, LLMs require three core architectural pillars:

viaNexus builds all three in at onboarding, before an agent ever sees the data.

At viaNexus, we built these requirements directly into the core platform architecture. By automatically organizing and semantically enriching any dataset upon onboarding, viaNexus provides an AI-ready data infrastructure that eliminates hallucinations, enables conceptual search, and natively resolves complex financial data anomalies such as temporal symbology overlap.

Why do financial LLMs hallucinate on market data?

Standard LLM architectures struggle with financial market data for three primary reasons:

By anchoring LLMs to normalized, pre-calculated analytics served through an intrinsic Semantic Layer, viaNexus eliminates the need for models to perform math in-context or guess entity relationships, effectively preventing hallucinations before they happen.

What happens when a dataset is onboarded?

In traditional architectures, establishing relationships across disparate datasets requires months of manual schema design and complex ETL pipelines.

On the viaNexus platform, every dataset—whether real-time streaming market ticks, corporate fundamentals, or alternative macro data—enters through a single, unified write path (the Record API). Upon ingestion:

• Data is automatically validated, normalized, and mapped to a standardized metadata framework.
• An intrinsic Knowledge Graph Service builds entity relationships based on intent and temporal validity.
• Data is made immediately queryable across consistent REST, WebSocket, and agent-native (MCP) interfaces.

This feed-agnostic architecture ensures that any new dataset automatically inherits the platform's semantic model and entitlement controls the moment it is onboarded.

How can an agent search by meaning instead of schema?

A major breakthrough of an ontology-driven platform is the shift from rigid string matching to conceptual search.

In an ontological view, data is not stored as isolated tables; it is structured as interconnected nodes representing financial entities, instruments, market events, and macroeconomic indicators. When an AI agent or quantitative model queries viaNexus, it does not need to know venue-specific internal codes or exact schema definitions. Instead, it can perform conceptual queries (e.g., "Retrieve capital structure and country risk factors for entities impacted by recent supply chain shifts"). The viaNexus platform resolves the conceptual query across underlying ontologies, retrieving precisely entitled, relevant data without unnecessary noise.

What happens when two companies share one ticker?

The necessity of temporal semantics is perfectly illustrated by a common financial data nightmare: Temporal Symbology Reuse.

How does ticker reuse corrupt a time series?

When SpaceX recently went public, the ticker symbol SPCX was assigned to the company. However, prior to the SpaceX IPO, the symbol SPCX belonged to a completely separate Special Purpose Acquisition Company (SPAC) ETF.

On the day of the SpaceX IPO, legacy data providers and standard financial APIs experienced severe data pollution:

• Historical pricing, trade history, and volatility metrics from the former ETF were erroneously blended into the new SpaceX IPO time-series.
• AI models relying on ticker lookups ingested the ETF's historical data, leading to completely hallucinated valuations, incorrect historical beta calculations, and invalid trading signals for SpaceX.

How does a temporal knowledge graph fix it?

viaNexus natively prevents this through its Temporally Embedded Knowledge Graph. Rather than treating ticker symbols as static primary keys, viaNexus models the temporal evolution of a symbol:

1. Canonical Entity Resolution: Each instrument and entity receives a distinct digital fingerprint, derived from its intricate web of interconnected relationships.
2. Defined Lifespan Boundaries: The ticker symbol SPCX maintains a distinct relational network tied to Entity A (the SPAC ETF) prior to its liquidating closure, and transitions to map exclusively to Entity B (SpaceX) effective from its public debut date forward.
3. Intent-Based Relationship Building: When an LLM or user requests historical data for SpaceX (SPCX), the Knowledge Graph enforces temporal boundaries, ensuring historical ETF data is strictly segregated from SpaceX's time-series.

By implementing true temporal semantics, viaNexus guarantees data integrity across corporate actions, ticker changes, and IPO re-assignments.

How does macro data fit alongside market data?

The power of an intrinsic ontology layer extends far beyond traditional equities and time-series financial spectrums. Because viaNexus builds proper semantics across ontologies, it seamlessly bridges market data with alternative, geopolitical, and global macroeconomic datasets.

A prime example is our partnership with EIU (Economist Intelligence Unit). EIU's world-leading macroeconomic country forecasts, operational risk indicators, business environment rankings, and sustainability indices are now fully productized and discoverable within the viaNexus Financial Data Marketplace:

viaNexus Adds EIU: Country Risk and Macro Forecasts on One Key

Country risk now sits next to your market data. EIU's macro forecasts, ESG scores and four country risk models are live on viaNexus for almost 200 countries, on the same key as the prices, fundamentals and news you already use.

viaNexus

Explore the EIU Country Macroeconomics Reference Dataset:viaNexus EIU Macro Economics Reference Documentation

By linking EIU's macroeconomic intelligence into the viaNexus Knowledge Graph, AI agents can cross-reference sovereign risk scores, GDP forecasts, and geopolitical indicators directly alongside company fundamentals and real-time market feeds in a single, semantically connected workflow.

What does AI-ready market data infrastructure require?

AI will only transform capital markets if the underlying data layer is purpose-built for machine consumption. By combining:

• Strict data modeling and consistent APIs
• A Temporally Embedded Knowledge Graph
• Native Model Context Protocol (MCP) and agentic entitlements

...viaNexus eliminates LLM hallucinations, solves complex temporal symbology challenges, and unleashes the full potential of autonomous AI workflows in finance.

Whether you are an exchange looking to modernize distribution, a hedge fund building agentic trading pods, or a data provider seeking friction-free monetization, viaNexus delivers the AI-ready infrastructure required for the future of capital markets.

The connector is listed in the Claude directory and the Cursor plugin directory, and every dataset in this post is documented in the viaNexus catalog.

On price alone, Argentina looks like the obvious call. EIU sees it differently: it rates Argentina's macroeconomic risk at 75, a D grade, against a B for Chile.

Until now, putting those two facts side by side meant two vendors, two contracts and two integrations. Starting today, they sit behind the same viaNexus key. EIU, part of Economist Enterprise, is now a data partner, bringing country forecasts, sustainability scores and risk models for almost 200 countries onto the platform next to the prices, fundamentals and news you already use.

Here is what is inside, and what you can do with it.

What is new

EIU is our first move beyond markets into country and sovereign risk. Six products are live today, all keyed by country and all reachable through the same API, MCP server and credential as everything else on viaNexus.

Most teams start with the same question about any economy: where is it heading?

Macro forecasts, actual and forecast in one series

The annual and quarterly macro datasets cover almost 200 countries across 16 indicator categories, from GDP growth and fiscal policy to energy, trade, demographics and healthcare. More than 1,200 series in all.

History and outlook arrive together. Every value is tagged as real or forecast, so one call for Argentina's real GDP growth returns the contraction of 2023 and 2024, the 4.5% rebound in 2025, and EIU's projection out to 2031.

Growth tells you where an economy is going. It does not tell you how the country is governed, how exposed it is to climate risk, or how it treats its people. That is what the sustainability index measures.

ESG scores for more than 150 geographies

The Global Sustainability Index scores environmental, social and governance performance from 220 indicators. Each pillar breaks down further, into decarbonization, physical climate risk, access to services, civil rights, corporate governance and more, so you can see why a country scores the way it does rather than only the headline number.

A strong sustainability profile is not the same thing as low risk, though. For that, EIU publishes four separate models, each looking at risk from a different angle.

Four ways to measure country risk

• Operational risk across 180 markets, scoring 10 categories such as political stability, security, tax policy and infrastructure from 0 to 100, with A to E grades. Updated quarterly.
• Financial risk across more than 130 markets, built from 59 monetary, fiscal and banking factors, including separate banking sector and currency risk scores.
• Democracy index for around 100 countries, scoring electoral process, government functioning, political participation, political culture and civil liberties.
• Business environment rankings for around 80 countries, averaging 11 categories into one overall score.

Which brings us back to the question we started with. Chile scores better on every EIU measure, yet Argentina's market nearly doubled Chile's return. EIU alone cannot explain that gap, and neither can price data alone.

You need both, and viaNexus is the one place you can get them together.

Where it gets interesting: combining it with everything else

Country risk on its own is context. Next to live market data, it is a decision.

On viaNexus, EIU sits on the same key as every other dataset in the catalog: prices, fundamentals, stock statistics and news. That means you can put a risk grade beside a country ETF's one-year return, a local company's stock statistics and the latest newswire headline, and see the full picture in one place, with no second vendor and no second integration. A dashboard like this takes a handful of calls:

The same combination powers a range of products:

• Emerging market screens that weigh a country's return against its EIU risk grade before anyone allocates.
• ESG overlays for portfolios, scoring holdings by the sustainability profile of the countries they operate in.
• Country exposure monitors that flag when a market a company depends on moves down a risk grade.
• Research agents that answer macro and market questions in one pass instead of stitching sources together.

Or take it all the way to a product. Here is a country risk app built entirely on the same key, with a ranked watchlist on the desktop and a mobile view that flags what changed:

And if you would rather not build the dashboard at all, you do not have to.

Just ask your assistant

With the viaNexus connector in Claude or Cursor, you do not write the calls yourself. Ask a question that spans macro and markets, and the assistant pulls from EIU, prices, stock statistics and news together, then explains what it found:

That answer draws on five datasets that sit side by side on viaNexus, two from EIU and three from the rest of the catalog:

• EIU Operational Risk: risk scores and A to E grades for each country, including the macroeconomic risk score of 75 (D) for Argentina and 30 (B) for Chile.
• EIU Annual Macro Forecasts: historical and forecast economic indicators, used here for GDP growth through 2031.
• Historical Prices: end-of-day prices for global equities and ETFs, used for the one-year returns on ARGT and ECH.
• U.S. Stock Statistics: key stats for U.S.-listed stocks, including 52-week performance for YPF.
• MT Newswires Global: real-time company and market news worldwide, where the YPF LNG headline came from.

The full picture, in one place

Argentina or Chile was never a question one dataset could answer. The market said one thing and EIU said another. The real answer sat in between, in the growth forecasts, the energy rally and the headlines behind it.

That is what this launch is about. Country risk, macro forecasts and sustainability scores now sit beside prices, fundamentals and news on viaNexus, on one key, through one API and one connector. No separate vendor, login or integration.

Whether you are building a dashboard, screening sovereign risk, powering a research agent or just asking a question, viaNexus is where you see the whole story. Almost 200 countries are live today. Pick one and see what it tells you.

If you are evaluating country risk or macro data for your team, contact us about EIU access.

Start a free trial, add the connector in Cursor or Claude, and ask it about any of nearly 200 countries.

Source: Economist Enterprise (EIU). All country scores, grades and forecasts shown in this post are published by EIU. Whilst efforts have been taken to verify the accuracy of this information, neither The Economist Intelligence Unit Ltd. nor its affiliates can accept any responsibility or liability for reliance by any person on this information.

Most of them sell almost none of it directly. Not because the demand is missing, but because the distance between a raw multicast feed and something a developer can buy with a credit card has always been measured in years and millions of dollars. So the feed goes to an aggregator instead, and the aggregator keeps the customer.

That trade-off is now breaking down. The $40 billion global financial data industry has reached a tipping point: as capital markets move from human-driven terminals to autonomous, agent-driven workflows, the demand for structured, low-latency, contextually grounded data has climbed sharply, while the tooling required to package and deliver it has stayed complex and expensive. Exchanges, market makers and independent providers are all facing the same structural shift at once.

Historically, regional financial exchanges and market makers have sat on mountains of valuable raw data but shied away from commercializing it. The sheer effort to produce discernible, digestible, and reliable market data products required specialized expertise, multi-year development cycles, and millions of dollars in infrastructure costs.

That is precisely where viaNexus enters the picture. It is built on production infrastructure originally acquired from the US exchange IEX. viaNexus has since rebuilt it for performance and broken it into modules, so the work of productizing and monetizing data moves off the provider and into the platform. By embedding these capabilities directly into a modular platform—deployable across public cloud environments, on-premises systems, or secure private clouds—it significantly lowers operational expenditures, removes integration bottlenecks, and dramatically accelerates time-to-market.

The Legacy Monolith: Why Market Data Commercialization Was Broken

Traditionally, distributing financial data meant facing three critical barriers:

1. Astronomical Engineering Overhead: Building a modern API platform, an entitlement engine, and a billing stack from scratch is a massive undertaking. Exchanges were forced to spend valuable engineering capacity on infrastructure plumbing rather than core product innovation.
2. Loss of Control to Intermediaries: Because direct distribution was too complex, exchanges historically handed over their raw feeds to legacy aggregators (such as Bloomberg and Refinitiv). These aggregators marked up the data, controlled the client relationships, restricted pricing flexibility, and captured the lion's share of the profit margins. Retail investors lacked viable options; despite LLMs making financial analysis easily accessible, acquiring reliable, entitled market data remained impossible at an affordable price point.
3. The Consumption Divide: On the buy-side, data consumers had to map, normalize, and cache every single feed independently. B2B licensing was rigid, minimum subscription fees were high, and instant, self-service developer access was virtually nonexistent.

By taking a platform-centric approach, viaNexus bridges this divide, giving exchanges a "product factory" to package, license, and monetize their data directly with zero friction.

Under the Hood: The Complex Event Processing (CEP) Engine

Removing that burden only works if the thing underneath it can carry the load.

At its core, the viaNexus platform is designed as an event-driven, language-agnostic architecture optimized for high performance, scale, and resilience.

• High-Throughput, Ultra-Low Latency Ingestion: The platform is built to ingest real-time market data (such as raw multicast UDP or TCP exchange feeds) at high transaction rates exceeding 1 million transactions per second, maintaining sub-3ms latency for raw feeds and sub-250ms latency across normalized REST and WebSocket streaming APIs.
• Unified Write Path: Every feed, batch file, or third-party webhook enters the platform through a single, authenticated write API (the Record API). This single front door handles schema validation, data quality checks, de-duplication, and metering.
• The Replicated Event Log: Rather than writing directly to storage, the ingestion layer publishes all incoming records to a highly durable, replicated event log (replicated across three brokers). Independent consumer services (like real-time streaming, historical commit, or analytics engines) read from this log asynchronously. This ensures that a heavy query or ingestion load never degrades customer performance.
• Decoupled Lakehouse Storage: Historical data is written in an open table format on regionally redundant object storage, allowing storage and compute to scale independently and ensuring data remains accessible for query-in-place analytics.

Ontology & Semantics: Eliminating Contextual Confusion

Throughput solves speed. It does not solve meaning.

A common flaw in financial data distribution is the siloing of context. When a user or application interacts with a dataset, minor misalignments in symbology or metadata can lead to costly errors.

To solve this, viaNexus maintains a strict, standardized ontology and metadata structure across the entire platform. Whether a consumer is working with real-time streaming ticks, company fundamentals, or corporate actions, the semantic relationship between data points is maintained natively.

On the read path, a built-in Temporally Embedded Knowledge Graph acts as a symbology resolver. Instead of forcing clients to learn complex internal venue-specific codes, temporal evolution of a symbol, they can query using whatever identifier they already hold (e.g., Symbol, ISIN, or Figi). The platform maps the request to the canonical instrument identifier before reaching storage. This makes the ingestion and query pipeline completely feed-agnostic.

AI-Native by Design: Solving Hallucinations and Token Burn

That consistent view of an instrument matters most to the consumer arriving fastest: the model.

Generative AI and Large Language Models (LLMs) are rapidly becoming the dominant consumers of market data. However, standard LLMs struggle with financial data for three reasons: they confidently fabricate facts (hallucination) due to stale weights or unreliable web scraping; they consume massive amounts of context window (token burn) when forced to reason over un-normalized data; and they lack secure, entitlement-aware access controls.

The viaNexus Agentic Services Technology (vAST) represents a paradigm shift in financial AI. Delivered natively alongside the low-latency APIs, vAST includes:

• Model Context Protocol (MCP) Server: A secure server enabling immediate connectivity for any MCP client (like Claude, Cursor, or custom setups) using a single signed software credential.
• Embedded Entitlements: Entitlements are evaluated on every single request, rather than once per session. This ensures that autonomous agents cannot violate compliance rules or access unlicensed datasets.
• Hallucination-Free Workflows: By anchoring the LLM's requests to normalized, pre-calculated analytics (such as VWAP, moving averages, or spreads) delivered in real-time, the platform eliminates the need for the model to do math in context or rely on outdated web data.
• Reduced Token Burn: vAST prevents "MCP spaghetti" and continuous polling loops. Agents can register triggers and go to sleep; the platform's CEP engine monitors the feeds and pushes structured, semantic alerts to wake the agent only when specific conditions are met.

Three Deployment Models to Scale

None of this helps a provider who cannot get it in the shape their business needs.

To maximize reach and address different market segment needs, the same underlying platform is offered in three distinct ways:

1. viaNexus MarketPlace: A multi-tenant, branded catalog where third-party and proprietary datasets are listed, priced, and monetized directly for prosumers, fintechs, and asset managers.
2. viaNexus Direct: A white-labeled "monetization-as-a-service" platform built specifically for exchanges, market makers, and publishers. It includes a fully branded storefront, automated client onboarding, usage tracking, and e-commerce integrations (e.g., Stripe payments and SAP billing connectors).
3. viaNexus MDM (Market Data Management): A secure, private-tenant instance deployed within an institution's private cloud (such as Google Cloud or Beeks co-location) to onboard, normalize, govern, and entitle data internally across complex trading environments.

Proven in Production: The SIX Group Landmark Partnership

All of which is a claim until somebody runs it in production.

The ultimate validation of viaNexus's model is its deployment with SIX Group (the Swiss Exchange). SIX needed to make its data more accessible to a broader ecosystem of developers and fintechs while reducing startup costs and operational complexity.

Instead of a multi-year build, viaNexus deployed a fully white-labeled version of the platform—brand-named "Market Signal"—which went live in July 2026 for private beta and launched fully on September 8, 2026.

The SIX deployment showcases the platform's agility:

• Multi-Venue Consolidation: Integrates market data from three venues across three geographies (SIX Swiss Exchange, Aquis UK, and BME Spain) in multiple currencies.
• Unified Products: Computes a consolidated Best Bid and Offer (1BBO) in real-time by capturing ticks, enriching them, and republishing them dynamically.
• Fully Automated Commercials: Powers an e-commerce site with self-service client onboarding, tiered universe-based pricing, and automated Stripe-to-SAP billing connectors.

Jan Zurcher, Global Head of Market Data at SIX Exchanges, noted: "Instead of building these capabilities from scratch, we can focus on expanding our offerings and reaching new customer segments faster, while relying on viaNexus' technology, expertise, and execution to bring this new distribution model to market efficiently."

Conclusion: The Direct GTM Future

The financial market data industry is shifting rapidly. The era of rigid terminal licenses and complex data procurement is giving way to affordable, API-first, and AI-ready data streams.

With viaNexus, exchanges no longer have to design custom schemas, maintain complex API connections, or build billing stacks from scratch. By shifting the complexity from the data provider into the platform, viaNexus empowers financial institutions to take back control of their data products, launch direct-to-consumer services in months instead of years, and capture higher margins in an increasingly competitive world.

If you are an exchange, market maker or publisher, contact us about what a deployment involves.

Start a free trial, browse the data catalog and API docs, add the connector in Cursor or Claude, and describe what you want to build.

They spend those months wiring up providers. One vendor for real-time quotes, another for historical bars, a third for fundamentals and corporate actions, a news feed on top. Four contracts, four authentication schemes, four ideas of what a symbol is, four response shapes. Then a normalisation layer to reconcile all of it, which nobody wanted to own and which somebody now owns forever.

By the time that layer works, the thing they actually wanted to make is still a sketch, and the roadmap has slipped a quarter.

We call this the integration tax. It is paid before a single feature ships, it is paid again every time a new dataset is added, and it never appears on the invoice from any of the four vendors.

The tax is not really about plumbing. Underneath it are three specific problems, and every team that assembles market data themselves hits all three.

• Identity — the same instrument has a different name in every feed, so nothing joins cleanly.
• Adjustment — price history lies unless corporate actions are folded into it correctly, and the events that break it are not the obvious ones.
• Reach — whatever you need next is always held by a vendor you have not signed yet.

Here is how each one bites, and what we do about it.

1. Identity is the problem underneath every other problem

Ask four vendors for Apple and you get four answers. One wants the ticker, one wants an ISIN, one has its own internal id, and the fourth returns a different code depending on which venue the line came from. None of that matters until you try to put a price next to a dividend next to a headline, at which point every join becomes a guess.

This is why teams end up maintaining a symbol master they never intended to build. It is also why bad joins are so hard to catch: nothing errors, the numbers just quietly belong to the wrong company.

Our answer is that the reference layer comes first. Global symbology sits underneath the catalogue and every dataset is mapped onto it on ingest, so they join on the same key. One instrument, one identity, whichever of the sixty-three datasets you pull it from. Exchange reference data, trading calendars, descriptions and logos sit in the same layer.

2. Your price history is probably wrong, and it will not tell you

Ask for five years of prices and compare last week to 2021. If the series has not been adjusted for every corporate action in between, the comparison is meaningless, and nothing in the response says so.

Most feeds hand you one price column and leave the reconstruction to you. Ours carries three on the same record for the same date: the price as it actually traded, the split adjusted series, and the fully adjusted series with dividends folded in.

The events that quietly break a series are rarely the plain ones. Most consolidated feeds carry dividends and splits and stop. A spinoff moves a price. So does a return of capital, a rights issue, a security swap. If your data does not carry them, your chart has a step in it that nobody can account for.

Our answer is ten event types rather than two, delivered per listing, so a company trading on a dozen venues gives you the event as it applies to each of them. And because every row carries its status, frequency and marker, separating a recurring dividend from a one-off is a filter rather than a research project. Sum the column naively on Costco and a single $15 special from December 2023 makes your yield nonsense.

3. The dataset you need next is always at another vendor

The third tax is the one that keeps being paid. You ship the screener, and then someone asks whether the move happened in the closing auction. Or what the street expects next quarter. Or what the market thinks the odds are. Each answer is a new vendor, a new contract, and the first two problems all over again.

Our answer is reach on the same key. Sixty-three datasets across eight groups, from the reference layer up to what happened on the tape this morning, all answering the same shape of request. Adding one to something you have already built is a dataset name, not an integration.

Each card below shows a real record from one group and what people do with it. Scroll sideways.

← scroll for all eight →

Two of those are worth pausing on, because few consolidators carry them at all. The tape classifies every trade by how it executed, so continuous trading, the auctions, off book and dark activity are separable instead of collapsed into one volume figure. If you are modelling execution or measuring your own fills, that is the difference between an estimate and a number. And prediction markets are a signal that exists in no price series: market implied probabilities on events, with daily history and reference data behind them.

What you build once the tax is gone

Take those three problems away and the work changes shape. The quarter you were going to spend on a normalisation layer goes into the product instead.

None of those needed a second vendor, a second contract, or a reconciliation step. The screener is the terminal with a list of symbols instead of one. The alerting product is the screener with a rule on top. The agent is all of it, reachable by something that reasons, answering from licensed data rather than whatever it found on the open web.

Getting at it

Every dataset answers the same shape of request. Pick the tier, pick the dataset, pass your symbols and a date range, and get JSON back, with the same authentication throughout.

GET /v1/data/{TIER}/{DATASET}/{SYMBOLS}?from=&to=

The consistency is deliberate. It means a person exploring in a browser and an agent working through the catalogue meet the same predictable surface, and it is why adding the next dataset is usually a one line change.

It also means you do not have to write the calls yourself. Our connector is available in Cursor and in Claude, so the assistant you already work in can query all sixty-three datasets while it writes your code. That is a real difference in practice: it is not reading documentation about our API and guessing, it is calling it, checking live responses and real field names as it builds. Wrong guesses get caught before they reach your file.

One of our developers used exactly that to build a full stock quote page, live prices and all, in fifteen minutes.

Start a free trial, add the connector in Cursor or Claude, and describe what you want to build. The integration tax is already paid.

It needs a live price that actually moves. A chart that works at one day and at five years. The statistics people check before they act: market cap, P/E, moving averages, the 52-week range. Dividend history, because income investors ask. The next earnings date, because everyone asks. And the headlines that explain why the number moved.

Building that has traditionally meant a vendor for real-time quotes, another for historical bars, a third for fundamentals and corporate actions, and a news provider on top. Four contracts, four schemas, four sets of quirks, and a normalization layer you own forever.

Last week one of our engineers had a working version on screen in fifteen minutes, using eight viaNexus datasets and a connector that plugs straight into the editor he was already working in.

Start With the Connector

The viaNexus MCP connector is now officially available in Cursor and in Claude. Add it once and your editor can query our datasets while it writes your code.

That changes how the code gets written. The assistant is not reading about our API, it is calling it, checking real responses and real field names as it goes. Wrong guesses get caught before they reach your file.

The endpoint is https://vast.blueskyapi.com/vianexus/mcp, authenticated with the same key as the REST API. One click from either directory listing and your editor has live market data.

What Actually Happened

Kai Gong, a developer at viaNexus, opened an AI coding assistant, pointed it at our documentation, and asked for a stock quote page.

Fifteen minutes later there was a page with a live, ticking price. By the thirty minute mark every panel was in: charts, statistics, dividends, earnings, news. Styling took another thirty to forty-five minutes, which is the only part that needed a human with opinions.

The assistant had never seen our API. It read the docs, worked out which datasets it needed, and wrote correct calls on the first pass. If a model can get from your documentation to working code with nobody translating in between, your developers can do it faster still.

The Calls Behind the Screen

The statistics grid is a single request. Not a rolling window you maintain, not a history you fetch and reduce. One row, already calculated:

GET /v1/data/CORE/STOCK_STATS_US/AAPL?last=1

That returns RSI, beta, 50 and 200 day moving averages, the 52-week range and change, average volume, shares outstanding, trailing P/E and EPS. Eleven of the sixteen cells on screen come from that one response. Four more come off the quote. Exactly one is calculated, and only because it moves with the live price: market cap is shares outstanding times the last trade.

The chart is one call per range, and the range is a parameter:

GET /v1/data/EDGE/HISTORICAL_PRICES/AAPL?range=1y&sort=ASC

Split-adjusted open, high, low and close. Switch to 1D or 5D and the page swaps to intraday bars with the same shape, so the chart code does not change.

The live price is a websocket rather than a poll, so the number on screen moves with the market instead of waiting on a timer:

wss://api.blueskyapi.com/v1/data/CORE/QUOTE/AAPL

Dividends and news are where teams usually lose a week.

Pull two years of dividends for Costco and you get the regular quarterly payment plus the $15 special it paid in December 2023. Add that column up and the yield you put on screen is nonsense. The same feed carries supplementary payments, frequencies marked irregular, and rows with an amount of zero. Every row tells you which is which, because marker, frequency and status are populated on all of them. Filtering down to the recurring cash stream is a few lines, not a research project.

News has the same problem wearing a different hat. Ask for Apple's headlines and you also get "Sector Update: Tech Stocks Rise Late Afternoon" and "Google, Peacock, Apple Convince Maryland Court to Strike Down Ad Tax." Apple is in those stories. They are not about Apple. Every row carries isPrimary, so you decide whether to show that second kind or bury it, and storyType tells you whether it broke during the session or after hours.

Add the earnings calendar and the opening tick and that is the full inventory. Every link goes straight to that dataset's documentation, schema and example calls:

Same host, same key, same response shape. There is no reconciliation step because there is nothing to reconcile: the symbol that returns a quote returns the dividend history under the same identifier. That is where the fifteen minutes came from.

Now Do Something With It

A quote page is a browser tab. Stop thinking about one symbol at a time and the same eight datasets turn into something you can charge for.

Pass a list instead of a symbol. CORE/QUOTE takes AAPL,MSFT,NVDA and hands back a row for each. That one change turns the page into a watchlist, and a watchlist plus a login is a portfolio monitor. No new endpoint, no new contract.

Let the data tell your users when to look. Our rules engine sits on top of the statistics dataset and fires when a number moves past a line you drew: RSI clears seventy, the 50-day crosses the 200-day, a symbol comes within a percent of its 52-week high. Your users stop refreshing a screen and start getting told when something happened.

Put an agent in front of it. With the connector installed, an assistant can answer "why is NVDA down today" by reading the same licensed newswire your page renders, rather than whatever it found on the open web. That is the difference between a demo and something you would let a customer use.

Stack those and you have stopped building a dashboard:

Every screen there runs on the datasets already listed in this post. Nothing new was licensed, no second vendor was called, and the key is the same one from the free trial. The path runs docs to connector to working code to a shipped app, and you can walk the whole thing today.

Build One This Afternoon

If your roadmap has a market data surface on it, the question is no longer whether you can build it. It is what you would build if the first working version took fifteen minutes.

Here is the same path Kai took:

1. Get a key. Start a free trial.
2. Add the connector in Cursor or Claude, then describe the page you want. That is the whole prompt.
3. Browse the data catalog to see what else is on the same key.
4. Start from working code with our public Claude skills repository, including a live market dashboard skill.

Tell us what you build. We will feature it!

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.

🎥 Want to see this in action? Watch the two-minute demo: same Claude account, two viaNexus connectors, two different answers, because the credential is different.

Today's MCP-connected workloads are mostly chats — Claude, Cursor, custom clients. The same plumbing will carry tomorrow's agents: autonomous LLM systems running in loops, calling tools, accessing data with minimal human supervision. The credential model for both is the same. For regulated workflows — and especially for financial data — that credential needs to be tighter than the user's full account: signed, scoped, validated on every call, revocable on demand.

That's what viaNexus carries at the connector layer.

When a workload doesn't have a scoped credential of its own, it works until:

• It reaches data it was never meant to touch
• It inherits credentials it was never meant to hold
• Someone needs to prove what was permitted to access, and the answer lives in application logs that were never built for the question

This isn't hypothetical. A 2025 SailPoint survey found that 80% of organizations have already encountered risky AI agent behaviors, including improper data exposure and access to systems without authorization.

To see why that matters, look at how financial data has always worked. Every Bloomberg seat, every Reuters feed, every vendor contract is scoped by user, by use case, by redistribution rights. The vendor audits adherence. The firm controls access. Everyone has accountability. That infrastructure took decades to build, and it works because there's a clear chain of accountability at every step.

The 2025 Verizon DBIR found credential abuse is still the most common initial-access vector in breaches, and only 10% of organizations have a developed strategy for managing agentic identities.

LLM workloads need the same kind of credential chain — a signed, scoped credential per connection, validated on every call.

Picture an analyst at a buy-side firm who has terminal access to MT Newswires for research, and a separate license to a pricing feed for portfolio monitoring. They build an internal Claude workspace — or eventually, an autonomous agent — to summarize the morning's headlines. Without a scoped credential, that workload inherits both licenses, even though it only needs one. The first time someone asks it about a trade idea, it pulls pricing data the firm never licensed for that use case. Nobody notices until the data provider's audit flags it.

On viaNexus, the fix is to provision a connector scoped narrower than the analyst's full subscription — and the platform makes that a one-step operation, not a custom auth project.

The licensing infrastructure was built around humans. LLM workloads are a different shape, and the credential model has to extend to them. viaNexus extends it: each connector — whether the consumer is a chat or an agent — carries its own credential at the connector layer, signed, scoped, validated on every call, revocable on demand.

The MCP authorization spec gives you the building blocks for this: OAuth 2.1, dynamic client registration, signed software statements (RFC 7591). What it doesn't define is how to use them for licensed data. viaNexus does.

What viaNexus Carries at the Connector Layer

Four properties are true at the same time on every viaNexus MCP connector. Each one is enforced at the platform level, not built by the developer.

1. Scoped access — at the connector, not just the user

Every viaNexus MCP connector carries its own credential, called a software statement (a concept from RFC 7591, the OAuth 2.0 Dynamic Client Registration spec): a signed credential issued at the moment the connector is created, listing exactly which datasets that connector can touch.

A user with access to ten datasets can spin up a connector scoped to one. An internal workload that only needs newswires gets a software statement that names MT Newswires and nothing else.

The default Universal connector intentionally maps to your full subscription, because that's what most users want for their own Claude. The same platform issues the narrower MT Newswires connector — and any custom-scoped connector you provision — by writing a tighter software statement. The mechanism is the product.

2. Enforcement on every call

Every data request runs through a single validation point — the viaNexus auth server checks the software statement before the call reaches the data layer.

Because the credential is validated on every tool invocation, the entitlement model can't drift out of sync with the subscription. If a license is added, the next call sees it. If a license is removed, the next call fails. The check isn't optional and isn't bypassable from the application side.

3. Revocability

When a connector is decommissioned or a license expires, access goes with it.

Because the software statement is checked on every call, revoking it is the only step required. There's no cached entitlement table somewhere upstream that takes a nightly sync to catch up. The next call after revocation fails, and nothing the application code does can route around that.

4. Delegation, not inheritance

The connector isn't a separate first-class identity from the user — it's a scoped delegate. It carries a credential the user authorized, narrower than the user's subscription, and the data layer enforces that narrower scope on every call. The user remains the principal; the connector gets a credential that says "you can do this much, and no more."

That distinction matters because application code has bugs. A permissioning model that lives in your prompt or your orchestration logic fails the first time an edge case hits it. viaNexus pushes the boundary down into the auth server, where it can't be bypassed by a misconfigured app or a creative prompt.

These four properties are why we built viaNexus the way we did. Today the consumers are mostly chat clients — Claude, Cursor, custom MCP clients. As autonomous agents move from prototype to production, they'll consume the same MCP layer. The credential mechanism is ready for them: an agent built on the Anthropic SDK or any other framework can be given its own connector with its own software statement, scoped tighter than the user who provisioned it. The plumbing is the same. The discipline carries forward.

What That Looks Like in Practice

The video below is two MCP connectors running side by side in Claude, against the same viaNexus subscription. Claude here is the consumer — a chat client. The same credential mechanism applies when an autonomous agent is the consumer instead. The point isn't the chat. It's the credential boundary.

The first is the viaNexus Universal MCP Connector. One endpoint, full catalog access scoped to whatever the subscription covers — datasets from providers like MT Newswires, ExtractAlpha, Aiera, BMLL, SavaNet, and more, accessible through a single authenticated connection. Ask for a stock price, it pulls a stock price. Ask for the latest earnings transcript, it pulls the transcript. Whatever the account is licensed for, the connector can reach.

The second is scoped specifically to MT Newswires, a real-time financial newswire covering US, Canadian, and global markets, with every story tagged by ticker, timestamp, and market theme. Same account behind it. Different software statement. Ask that connector for a stock price and the request is denied.

Not because of a policy doc upstream. Not because Claude decided to refuse. Because the credential bound to that connector is narrower than the user's overall subscription, and the auth server validated the call against the connector's scope, not the user's.

Same account, same query, different connector, different result. That's not a feature flag. That's the architecture.

▶ Watch the demo

What That Means for What You're Building

This architecture changes what you can ship and how fast you can ship it, and the payoff looks different depending on which side of the workflow you're on.

• If you're a developer

Building a multi-agent product where each customer's agent needs its own scope used to mean a custom auth layer per tenant. With viaNexus, it means provisioning a new connector with a software statement narrower than the user's full subscription. The boundary lives in the credential, not your application code, so workloads don't bleed access across each other. Every call is validated through vAST — viaNexus' AI Agent services layer — so entitlement enforcement is built in before you write a line of code.

If you're not using a hosted client like Claude or Cursor, the viaNexus Agent Python SDK handles DCR, OAuth, callback server, and MCP auth out of the box — so you can wire any LLM up to scoped financial data without writing the auth layer.

• If you're a user

The surface area is "connect and go."

Open Claude, browse to the viaNexus connector, sign in, and the connection has exactly the data your subscription covers. Upgrade tomorrow and the new datasets are immediately available to every connection you've made. Let a license expire and that access cleanly drops away on the next call. Want a tighter scope for a specific workflow? Use a narrower connector — the MT Newswires one, or a custom one provisioned for that purpose. Nothing to configure on the application side.

• If you're a data provider

Your content is protected at the connector layer rather than the application layer, which is where most leaks actually happen.

viaNexus distributes your data only to users with active, valid subscriptions, with the software statement validated automatically on every call. MT Newswires uses this to push their newswire into LLM workflows without losing control of who's reading it and under what license. Aiera, ExtractAlpha, BMLL, and SavaNet are doing the same thing for transcripts, alpha factors, market microstructure, and fundamentals. The platform handles entitlement enforcement at the point of access, not after the fact.

What Gets Built On Top of This

Once permissioning is solved at the connector layer, a class of workflows that couldn't exist before suddenly becomes shippable:

• Research workflows that reads news but not pricing
• Trading workflows that touch pricing but not transcripts
• Compliance workflows with read-only access to specific datasets, running unattended because their scope is provably narrow
• Internal tools that share a single viaNexus account but route different teams to different connectors based on what their work actually needs
• Multi-tenant agentic products where each customer's agent has its own connector and its own enforcement point
• Workloads operating inside regulated firms whose entitlement boundary the compliance team can actually attest to, the first time

These workflows ship the moment the connection has a credential narrower than its user's, validated on every call. That's what viaNexus carries by default.

The fragmentation of financial data was never going to be solved by another API. It needed an entitlement layer that LLM workloads could speak to natively, and a delivery protocol that didn't pretend permissioning was someone else's problem.

viaNexus is that layer. The MCP connectors are how you reach it. The software statement is what makes the whole thing work.

MCP gave LLM workloads the door. viaNexus carries the lock. Now you can hand out keys.

Interested in building on viaNexus? We'd love to hear what you're working on. Reach out here or connect with us on LinkedIn.

🔗 Sign up for viaNexus to explore the full data catalog
🔗 Connect Claude with the viaNexus MCP Connector
🔗 Build your own agent with the viaNexus Python SDK

One of the most intensive tasks - prep for a meeting with company management. This works for both the sell side (covered company) or the buyside (portfolio company).

The prompt was just this. “𝘠𝘰𝘶 𝘢𝘳𝘦 𝘩𝘦𝘭𝘱𝘪𝘯𝘨 𝘢𝘯 𝘦𝘲𝘶𝘪𝘵𝘺 𝘳𝘦𝘴𝘦𝘢𝘳𝘤𝘩 𝘢𝘯𝘢𝘭𝘺𝘴𝘵 𝘱𝘳𝘦𝘱𝘢𝘳𝘦 𝘧𝘰𝘳 𝘢 𝘮𝘦𝘦𝘵𝘪𝘯𝘨 𝘸𝘪𝘵𝘩 𝘵𝘩𝘦 𝘊𝘌𝘖 𝘢𝘯𝘥 𝘊𝘍𝘖 𝘰𝘧 𝘔𝘔𝘔. 𝘤𝘳𝘦𝘢𝘵𝘦 𝘢 𝘣𝘳𝘪𝘦𝘧𝘪𝘯𝘨 𝘯𝘰𝘵𝘦 𝘧𝘰𝘳 𝘵𝘩𝘦 𝘮𝘦𝘦𝘵𝘪𝘯𝘨, 𝘶𝘴𝘪𝘯𝘨 𝘥𝘢𝘵𝘢 𝘧𝘳𝘰𝘮 𝘵𝘳𝘢𝘯𝘴𝘤𝘳𝘪𝘱𝘵𝘴, 𝘯𝘦𝘸𝘴, 𝘧𝘪𝘭𝘪𝘯𝘨𝘴 𝘢𝘯𝘥 𝘳𝘦𝘤𝘦𝘯𝘵 𝘱𝘳𝘪𝘤𝘦 𝘩𝘪𝘴𝘵𝘰𝘳𝘺. 𝘐𝘯𝘤𝘭𝘶𝘥𝘦 𝘧𝘪𝘯𝘢𝘯𝘤𝘪𝘢𝘭𝘴 𝘢𝘯𝘥 𝘳𝘢𝘵𝘪𝘰𝘴. 𝘪𝘥𝘦𝘯𝘵𝘪𝘧𝘺 𝘴𝘰𝘮𝘦 𝘵𝘰𝘶𝘨𝘩 𝘲𝘶𝘦𝘴𝘵𝘪𝘰𝘯𝘴 𝘧𝘳𝘰𝘮 𝘵𝘩𝘦 𝘭𝘢𝘴𝘵 2 𝘦𝘢𝘳𝘯𝘪𝘯𝘨𝘴 𝘤𝘢𝘭𝘭𝘴".

What came back in 5 minutes is the briefing attached below.

𝗜 𝘄𝗮𝘀 𝗯𝗹𝗼𝘄𝗻 𝗮𝘄𝗮𝘆. But the interesting part is how it was built. I asked Claude and her was the response:

"viaNexus MCP Tools The foundational data layer. I used the viaNexus:fetch tool across eight separate dataset calls — QUOTE, STOCK_STATS_US, COMPANY_DESCRIPTIONS, SUMMARY_NORMALIZED_FINANCIALS (quarterly and annual), NORMALIZED_FUNDAMENTALS, TRUEBEATS_EPS_REVENUE_FORECASTS, EVENTS_CALENDAR, and HISTORICAL_EVENTS_TRANSCRIPTS — plus MT Newswires for analyst coverage. All fetched in sequence to populate every data point in the report with live, sourced figures rather than recalled knowledge.

The Equity Research Report Skill (/mnt/skills/user/equity-research-report/SKILL.md) A custom skill you built in a prior session. It defined the exact data fetch sequence, the report structure (12 sections), formatting rules (human-readable numbers, no invented figures), and quality checks. Without reading that skill first, the report would have been structurally different and likely missed several datasets.

Transcript Parsing via Bash The AIERA transcript files for Q4 2025 (767 entries, ~1MB) and Q3 2025 (719 entries) were too large for direct context. I used bash_tool with Python to decompress and navigate the JSON structure, extract the full transcript text, locate the Q&A sections by position, and read specific 8,000-character windows to surface the key management exchanges — the Jeff Sprague footprint question, Steve Tusa on litigation costs, Julian Mitchell on macro vs. self-help, Scott Davis on NPI quality.

The Frontend Design Skill (/mnt/skills/public/frontend-design/SKILL.md) Governed the visual output. Rather than producing a plain markdown document, I read the design skill and applied it to produce a production-grade HTML briefing with a considered aesthetic — Playfair Display / IBM Plex Sans type pairing, a dark masthead with red accent, structured color-coded sections, bull/bear boxes, and a distinct question format with source tagging.

Synthesis and Judgment The data and transcripts provided the raw material, but constructing the 11 questions, the bull/bear cases, and the analyst summary required integrating across sources — connecting a pricing comment in the Q3 call to a margin guidance assumption in Q4, or linking the Wolfe Research target raise to the RBC bear case in the same week. That analytical layer sits outside any single tool.

In short: the skill files told me what to build and how to structure it, the MCP tools provided the data, bash gave me access to the transcripts, and the synthesis layer turned it into something useful for an actual meeting."

The "reasoning" is getting really powerful, and exceeds what most analysts would do coming to this company raw. A seasoned analyst covering the company might say otherwise. Connecting guidance shifts, analyst positioning, and management commentary into questions you’d actually ask in the room. ie

▶️ Can NPI really carry growth in 2026 given the shift from commercial execution?

▶️ When do litigation costs realistically inflect lower—if at all?

▶️ What does footprint consolidation actually mean for the P&L?

Now here’s the part that should make people pause - the estimated cost of this report (excluding the source content): Token Usage as estimated by Claude is estimated as per below:

The approximate Cost Using Claude Sonnet 4.6 API pricing as a reference point:

The data behind it came from real partners—normalized, permissioned, reliable: SavaNet for fundamentals, Aiera for transcripts & events, ExtractAlpha TrueBeats for forward estimates and MT Newswires for news - all flowing through and normalized by viaNexus. All accessible from a single prompt.

The takeaway isn’t “AI is impressive.” It’s that the architecture matters.

No specialized copilot. No heavy desktop. No brittle workflows. No unreliable, unlicensed data scraped from the internet!

Just Claude + Skills + permissioned data—configured once, usable every time.

Try it for your self - with a free trial, or your subscription, connect the viaNexus MCP: https://vast-mcp.blueskyapi.com/mcp

I spent years as an equity research analyst through the 90s and 2000s—long days, fragmented workflows, and a constant race just to get to the starting line. Before you could think, you had to assemble. Data from everywhere. Notes stitched together. Models built under time pressure. Even at full tilt, coverage capped out at ~10–12 names.

Fast forward to today, and the structure of the day is still the same. What’s changed is how quickly you can move through it—and increasingly, whether you need to do it at all.

In a series of posts, I'll be reliving my days as a publishing analyst - but using viaNexus marketplace data and the modern tools available to all of us. I'll simplify a bit because I was also reading some of the content in Spanish!

6:00–7:00 AM — The Morning Brief, Reimagined

The first task of the day was always simple: Take stock.

• What happened overnight?
• Where are my names?
• What matters today and for the next few days?

That hour is now collapsing into minutes. Using Claude + Skills + viaNexus and partner data, we’ve rebuilt the morning brief from the ground up.

At its core, a Skill is a structured, repeatable workflow—essentially a highly tuned prompt that knows:

• What to pull (prices, news, events, estimates)
• Where to pull it from (permissioned, normalized datasets via viaNexus)
• How to present it (structured, interactive output)

A typical Morning Brief Skill pulls together data from multiple sources, and where necessary joins and reasons over that data:

• Stock and sector performance across your coverage
• Premium news (e.g., MT Newswires)
• Company context and prior earnings summaries
• Upcoming earnings with confirmed call times and calendar integration (e.g., Aiera, ExtractAlpha)

In this case, I had Claude write the skill for me - at least to do a first cut. Then I edited it directly once I had a good first stab from Claude. All in all took about 15 minutes! Then it's just "rinse-repeat".

Type “Morning Brief” and within 5 minutes you get a fully interactive dashboard—generated on demand, inside your context window. The video below shows the 5 minutes speeding up!

Not a PDF. Not a static report. A live, structured, filterable workspace.

Under the hood, it’s dynamically:

• Reading your coverage universe
• Pulling normalized data across datasets
• Joining and enriching in real time
• Rendering signals, summaries, and forward-looking workflows

It’s effectively rebuilding the institutional morning process—without the manual stitching.

Nothing special in that - I can just use Claude or OpenAI and give it access to the web. Let it scrape away. Well - aside from the fact that data is all over the place on the web, not normalized and will therefor requires a ton of reasoning to figure it out - if you are a professional that scraped data is also not licensed for professional use.... which you legal team won't appreciate!

The Breakthrough… and the Problem

This is where things get interesting. Because while this works—it works too literally. Every time you run the Skill:

• The data is pulled through the MCP protocol (vs a fast API)
• The same joins are re-reasoned (not a big deal for viaNexus data since its so standardized)
• The same interface is rebuilt from scratch (well its mainly the same)
• Multiple MCP calls fire in sequence

It’s elegant. But it’s also Slow, Expensive, and Wasteful. You’re rebuilding the same application… every single morning. At scale, that’s not just inefficient.

Imagine a department of 30 PMs and analysts all building skills the same way.

The right tool for the right job.

Skills are handy short cuts for often repeated prompts, but not idea for more complex queries - unless they are used infrequently. For more complex workflows, they are great at:

• Validating user experience
• Defining data dependencies
• Iterating quickly with AI

But once the workflow is proven, the path forward becomes might be:

• Take the Skill
• Hand it to Claude Code (or your dev stack, or IT team)
• Build a lightweight, persistent application
• Have the app connect directly to viaNexus APIs
• Have the app running continuously if you like.....

Instead of recomputing everything, every time. Same outcome, dramatically faster at a fraction of the cost with no redundant compute.

Why the Data Layer Matters

None of this works without the right data foundation. Skills—and the applications they evolve into—depend on:

• Permissioned, licensed datasets
• Reliable, high-quality sources
• Normalized structures across providers

That’s where viaNexus comes in—bringing together datasets from providers like:

• MT Newswires (for news)
• Aiera (for earnings transcripts and future events)
• ExtractAlpha (for earnings estimates)
• Exchange Data International (for reference data)
• BMLL Technologies (for pre-trade analytics)
• and more coming soon....

All normalized, permissioned, and ready to be consumed - by humans, applications, or agents. Most likely a combination.

The Payoff

The real outcome isn’t just efficiency—it’s capacity. For a publishing analyst:

• 12 covered stocks becomes 20 or more
• Manual prep becomes automated context
• Time shifts back to where it matters:
  • Insight generation
  • Company engagement
  • Differentiated research

And maybe—just maybe - the analyst makes it home in time to tuck the kids into bed!

Getting Started:

While we are getting our own listing sorted, here is how to manually get started with viaNexus, our partners, Claude and Skills:

Go to Claude desktop, or claudu.ai

1) From your profile, go to settings

2) Select "Connectors"

3) Select "Go to customize"

4) hit + and "Add custom connector"

5) Name: whatever you like, the remote MCP server URL is https://vast.blueskyapi.com/vianexus/mcp. Also make sure all the Tools are enabled.

If you don't have an account, select viaNexus, and you'll be guided to sign up for free, 14 day trial.

Don't miss the next exciting episode: 7:00–8:00 AM

At viaNexus, we already distribute as-reported fundamentals and filings, drawn directly from the 10-Q and 10-K filings submitted by public companies. That data is faithful to the source and valuable for traceability.  But it is not sufficient for serious analysis.

As-reported data reflects the inconsistencies of the filings themselves. Companies use different labels, structures, and interpretations for the same accounting concepts. The result is a dataset that mirrors filings accurately—but becomes difficult to compare across companies or across time.

That works for inspection. It breaks down for analysis. Anyone building valuation models, financial dashboards, or AI-driven research workflows quickly encounters the same issue: raw filings are not analytically consistent. If fundamentals were going to be added to viaNexus properly, they would need to be normalized, structured, and delivered in a form that analytical systems—and increasingly AI systems—can rely on.

Doing that properly is far from trivial.

Rather than take shortcuts, we partnered with SavaNet, combining their deep domain expertise in financial reporting with the viaNexus platform for normalization, API delivery, and agent-ready infrastructure.

This approach reflects a broader philosophy. When complex datasets require deep subject-matter expertise, we believe the best solution is to combine domain specialists with modern data infrastructure. You should expect to see more datasets built this way on viaNexus going forward.

 From As-Reported to Analyzable

The distinction between as-reported and normalized data matters.

As-reported fundamentals tell you what a company filed, according to its interpretation of accounting standards, its industry context, and sometimes its narrative choices.

Normalized fundamentals translate those filings into a consistent analytical framework.

Serious financial analysis requires:

• A standard financial statement schema
• Consistent definitions across companies and time
• Stable line items that behave predictably

Only once financial statements are normalized into a coherent structure can you reliably:

• Perform statement-level analysis
• Compare operating performance across peers
• Calculate accounting ratios
• Derive valuation metrics

Normalization isn’t a convenience. It is the foundation that makes analysis possible.

The Illusion of “Standard” XBRL

We began by examining the obvious starting point: U.S. filings.

In theory, XBRL provides a standardized language for financial reporting. In practice, it behaves more like a flexible taxonomy framework than a true standard.

Across U.S. filings, there are more than 10,000 XBRL tags currently in use. Companies frequently describe the same economic concept using different tags, structures, or contextual assumptions.

Consider the first line of the income statement:

• us-gaap:RevenueFromContractWithCustomerExcludingAssessedTax (most common)
• us-gaap:SalesRevenueNet (Common for manufacturers or retailers)
• us-gaap:RevenuesNetOfInterestExpense (Used by financial institutions or special structures)
• us-gaap:InterestIncome (Banks often treat interest income as revenue)
• us-gaap:OperatingRevenue (Sometimes used for regulated industries or utilities)

But some companies use custom extensions - that fits their statement wording - eg:

• aapl:NetSales
• tsla:AutomotiveSalesRevenue

These may represent the same economic concept—or slightly different ones—depending on the filer. Multiply that ambiguity across balance sheets, cash flow statements, industry-specific disclosures, and footnotes, and the problem becomes clear:

XBRL does not produce comparable fundamentals out of the box.

For most analytical use cases, the raw output is simply not usable.

There Is No Shortcut Around the Hard Work

Workflow for better fundamentals

SavaNet’s founder, Eric Linder CFA, has worked with regulatory filings and institutional financial data for decades. Early in the evolution of XBRL, he developed IFRICS, a purpose-built financial taxonomy designed to impose consistent structure on real-world filings.

IFRICS is a five-level hierarchy that maps filings into a standardized financial statement framework.

Rather than simply mapping tags, the framework:

• Resolves semantic ambiguity
• Separates economic meaning from filing convention
• Preserves industry nuance while enforcing consistency

Every reported XBRL item is mapped into this hierarchy through a deterministic process. Edge cases are explicitly handled, and granularity is preserved rather than flattened prematurely.

In many competing datasets, a significant number of items ultimately end up grouped into generic “Other” categories due to insufficient taxonomy depth. The IFRICS approach avoids that outcome by maintaining detailed structural mappings across the hierarchy.

To validate the framework, we tested it rigorously across the Russell 1000, iterating through thousands of disclosures until the dataset formed a consistent and internally coherent structure.

It is meticulous work—but it is the only reliable way to build a truly analyzable fundamentals dataset.

Once the framework is established, however, the methodology scales efficiently across the broader equity universe.

Deterministic by Design

One point is worth emphasizing.  The normalization process does not rely on large language models or manual interpretation.

LLMs are probabilistic by nature. Human interpretation introduces judgment drift over time. Neither approach is well suited for producing datasets that must remain consistent across decades of filings, thousands of companies, and repeated reporting cycles.

Instead, the process is:

• Rule-driven
• Taxonomy-based
• Deterministic and repeatable

Once a filing element is mapped into the schema, it will map the same way tomorrow, next quarter, and five years from now.  This way consistency is not an emergent property, it is designed into the system.

 Why the Schema Matters

The real innovation in the dataset is not just normalization—it is schema design.

The IFRICS taxonomy is deliberately deep, with five levels of abstraction:

• Levels 1–2: Universally comparable financial concepts
• Levels 3–4: Industry-aware financial structure
• Level 5: Filing-level granularity and edge-case detail

This structure allows financial data to be rolled up into consistent, comparable metrics—or drilled into at a very granular level when needed.

Through the viaNexus API, we expose the first two levels of the hierarchy to provide a clean analytical interface. Behind the scenes, the deeper layers preserve the detailed mappings required to maintain structural integrity.

For clients that need full transparency, the deeper mappings can also be made available.

Clean Inputs Create Deterministic Outcomes

Many downstream analytical errors originate upstream in the data.

By resolving ambiguity once—deterministically and at scale—we reduce:

• Reconciliation work for analysts
• Semantic confusion for AI models
• Inconsistent outputs across time and universe

Better inputs lead to more reliable outputs.

This principle becomes even more important as financial workflows increasingly incorporate AI-driven analysis.

Why This Matters for Agentic Workflows

viaNexus is designed to support agentic financial workflows through the vAST services layer.

Agent-driven systems depend on predictable inputs. Ambiguity compounds quickly. Inconsistent datasets lead to inconsistent outputs.

By eliminating ambiguity at the data layer, we give both humans and AI systems a stable analytical foundation.

The reliability of AI systems does not improve simply because the models improve. It improves because the data feeding those systems becomes cleaner, more structured, and more deterministic.

Try It Yourself

You can explore the dataset directly through a free viaNexus account - or dive straight in with a paid tier - tailored for individuals and enterprises.

Sign up at viaNexus.com and browse the catalog.

The dataset currently includes:

• Coverage of more than 3,000 U.S. companies
• More than 250 fields spanning income statement, balance sheet, and cash-flow metrics, along with derived valuation and accounting ratios
• Industrials, banks, and insurance companies (each with their own schemas)
• Five years of financial history, with deeper historical coverage planned

Full documentation is available in the viaNexus API console and here: 

https://console.blueskyapi.com/docs/EDGE/fundamentals/NORMALIZED_FUNDAMENTALS

Fundamentals, Rebuilt as Infrastructure

As-reported fundamentals are useful.

Normalized fundamentals are essential.

This dataset was not designed to sit inside a spreadsheet. It was built as financial data infrastructure—for analysis, valuation, and intelligent systems that require clean, deterministic inputs.

With the right partners and a willingness to do the hard work, what once seemed complex becomes scalable.

And this is just the beginning.  Expect more datasets on viaNexus built using the same model: deep domain expertise paired with modern normalization and delivery infrastructure.

Because the future of financial data is not simply more data, it is better-structured data, delivered as infrastructure.

The Gap Nobody Solved

For the past two years, everyone has talked about AI agents in finance. Here's the truth: they haven't truly worked.

Not because the AI wasn't capable — but because the infrastructure wasn't ready. Data lived behind manual credentialing. Payments required human approval. Every time an agent needed something new, the workflow stopped and waited. These weren't autonomous agents. They were assistants waiting for permission.

Closing that gap requires three things working in concert: data, programmable payments, and an open workspace that doesn't make you reinvent the wheel. No single firm can own all of that. But when the right pieces connect, the loop closes.

What viaNexus Brings to the Stack

viaNexus is a producer-consumer marketplace powered by universe-based pricing. 40+ datasets from providers like MT Newswires, Aiera, ExtractAlpha, and SavaNet, delivered through high-performance APIs and an agentic services layer called vAST.

vAST handles agent-to-data authentication autonomously. The agent determines what it needs, accesses the right datasets, and keeps operating — no credential re-entry, no manual approvals, no broken workflows. When paired with a programmable payments layer, agents can pay for data in real time as they consume it. When deployed into an open workspace, they reason across live data rather than just retrieve it.

The result: user asks a question, viaNexus delivers the data, billing is handled automatically, the agent returns the answer. One seamless workflow with whatever stack you're building in.

The full agentic loop — a user asks a question, viaNexus delivers the data via vAST, payment is triggered automatically through Paygentic, and the answer is returned. No manual steps, no interruptions. Build applications, access 40+ datasets, and pay autonomously.

What It Looks Like in Practice

To make this concrete: we connected three pieces that each bring something distinct to the workflow. The demos below came out of a conversation over coffee, not a deep integration project. Here's what we used:

• viaNexus — a producer-consumer data marketplace delivering 40+ datasets from providers like MT Newswires, Aiera, ExtractAlpha, and SavaNet through a single unified API and agentic services layer.
• OpenBB — an open, programmable financial workspace that renders viaNexus data as live charts, tables, and dashboards, and provides the environment for deploying AI agents.
• Paygentic — a programmable payments platform built for agentic workflows, handling per-action billing in real time as the agent consumes data.

If this is what's possible in an afternoon, imagine what you could build with a week. 

Connect a viaNexus token and you're immediately looking at rendered charts, live tables, and interactive dashboards — not raw JSON. Real-time quotes render as live charts. Earnings and Events Calendars surface confirmed dates, webcast links, and transcripts. TrueBeats EPS forecasts from ExtractAlpha sit alongside prior quarter actuals from SavaNet. MT Newswires streams real-time headlines filtered by ticker.

The result adapts to whoever is using it. An investor builds a morning portfolio dashboard. A founder shapes it into a monetized research product. An analyst collapses multiple tabs and spreadsheets into one clean interface. Same data layer, different application.

The workflow is straightforward. Open OpenBB, drop in your viaNexus endpoint and token, and the data is live. From there the agent handles the rest — querying datasets, building widgets, and reasoning across them in response to natural language prompts. When you need to top up, ask the agent directly in the workspace, follow the Paygentic link, add funds, and keep going. The whole thing stays in one place, and the agent never stops.

The Agent Is Just One Example

The viaNexus financial agent — built on the viaNexus Agent SDK — is a useful illustration of what's possible on top of this infrastructure. It's not the product. It's a demonstration of what the data layer enables.

It reasons across widgets rather than just reading them. Ask it to summarize weekly performance, compare consensus expectations to last quarter's actuals, or surface estimate revisions ahead of earnings. It can create widgets, analyze existing ones, and pull from the full viaNexus catalog to deliver what would otherwise take hours of manual work.

More importantly, it can watch markets for you. Tell it to alert you when anything in your portfolio forms a death cross, or moves more than X% in a day — and it sends a full data payload to your email the moment that condition is met. The data watches itself. That's not a feature. That's a different way of working.

Every viaNexus subscription includes core datasets: 15-minute delayed pricing, filings, and basic fundamentals. Edge datasets — premium news, transcripts, expanded fundamentals — layer in seamlessly, and the agent incorporates them immediately once enabled.

Built for Anyone With an Idea Worth Building

This doesn't require a large engineering team. A solo developer, a three-person startup, a buy-side analyst who has never touched a data pipeline — everyone gets access to the same institutional-grade layer at a fraction of the historical cost.

viaNexus is the data layer. Plug it into your own app, build your own agent, wire it into an existing workflow. The API is the same either way.

The barriers are coming down. The only question is what you'll build when it happens.

Interested in building on viaNexus? We'd love to hear what you're working on — reach out here or connect with us on LinkedIn!

🔗 Sign up for viaNexus

🔗 Get started with openbb.co

🔗 Explore paygentic.io

Think about what goes into a useful earnings application. Your users need to know when calls are happening—not just the date, but the actual time, the dial-in details, the webcast URL. They need context:

What did the company report last quarter? What's the consensus this time? What's the news sentiment heading into the call? And how on earth do they monitor multiple calls simultaneously, maybe even get real-time transcripts as executives speak.

Building that used to mean stitching together data from half a dozen sources. You'd pull filings from EDGAR for confirmed dates. You'd integrate an estimates provider for consensus numbers. You'd add a news feed for sentiment. You'd find a transcript vendor for call content. Each source has its own schema, its own update cadence, its own quirks. By the time you've normalized everything and built the integrations, earnings season is half over.

The Old Model Is Breaking Down

The traditional approach—pick a primary vendor, supplement with a few feeds, build your own normalization layer— that kind of worked when data moved slower and applications were simpler. But the pace has changed. AI-driven workflows need clean, structured data they can reason over. Modern applications need to react in real time. Portfolio managers want to track thirty earnings calls at once, switching between live transcripts and historical performance. The data infrastructure that powered Bloomberg terminals in 2015 isn't built for the applications people are building in 2026.

What's needed is a different model entirely: pre-normalized data from multiple authoritative sources, accessible through a single API layer, designed from the ground up to support the way developers actually build.

How viaNexus Approaches Earnings Data

viaNexus treats earnings season as what it is: a mosaic. No single dataset tells the complete story. What matters is how the pieces can be integrated into user experience, or “agent experiences”.

We provide two earnings calendars because they solve different problems. Our in-house Earnings Calendar is built directly from 8-K filings—the official announcements companies file with the SEC. When a company confirms an earnings date, we capture it. When they haven't filed yet, we use historical patterns to predict the timing with confidence labels. It's authoritative, fast, and designed for both human readers and AI agents who need to know what's confirmed versus what's forecast.

The AIERA Events Calendar complements this with a different lens. Our partner AIERA tracks not just when earnings are scheduled, but the full event lifecycle. You get the webcast URLs, the dial-in details, the actual start times—everything your users need to actually attend the call. And AIERA doesn't stop when the call begins. Through their Real-Time Events Transcripts dataset, you can stream the earnings call as it happens, word by word, giving your users the ability to monitor multiple calls simultaneously or build AI agents that react to what management says in real time.

Here's what a simple API call to the AIERA Events Calendar looks like:

GET /data/edge/events_calendar/AAPL/earnings

That returns the full schedule—past and future—with metadata your application can act on immediately.

For historical context, our Summary Normalized Financials dataset gives you the prior quarter's actual EPS and revenue, standardized across all companies. It's the baseline your users need to understand if this quarter was better or worse. Want to add consensus expectations? The TrueBeats EPS Revenue Forecasts from Extract Alpha provides the street's numbers—what analysts are expecting, what would constitute a beat or a miss.

And then there's the news layer. The MT Newswires Global dataset gives you the narrative context: what's been written about this company in the run-up to earnings? What are analysts focusing on? What are the risks everyone's watching? News isn't just sentiment—it's the questions your users will be asking when they tune into the call.

What You Can Build

In the following  section we demonstrate weaving together several viaNexus products like NEWS from MT NEWSWIRES, EPS from Extract Alpha, Earnings Transcripts from AIERA, to build an Earnings Dashboard in 3-5min.

1. viaNexus Earnings Calendar – Confirmed and predicted earnings dates from 8-K filings
2. Summary Normalized Financials – Last quarter's actual EPS and revenue
3. TrueBeats EPS Revenue Forecasts – This quarter's consensus expectations
4. MT Newswires Global – Recent headlines for earnings context
5. Reported Financials – Direct URLs to SEC filings (10-Ks, 10-Qs, 8-Ks)
6. AIERA Events Calendar – Press release URLs and event metadata

The code is straightforward because the data already fits together. For example, here's what fetching normalized financials looks like: 

GET /data/core/SUMMARY_NORMALIZED_FINANCIALS/MSFT/quarterly?last=4

That gives you four quarters of history in a consistent schema. No custom parsing. No wondering if revenue is in thousands or millions. It just works.

This is the foundation and it's just scratching the surface. From here, you could layer in more sophisticated features. Use AIERA's event metadata to let users join live calls directly—complete with real-time transcripts that stream word-by-word as executives speak. Build portfolio-wide views that surface every earnings call for a watchlist. Add intelligent alerts that trigger when a company beats consensus by a meaningful margin.

The Investment Process Deserves Better Tools

Earnings season is intense. The information flow is relentless. Investors are trying to make sense of dozens of data points in compressed time windows. The tools they use—whether it's a professional terminal, a self-directed trading app, or an AI-powered research assistant—need fast, clean, integrated data.

That's what viaNexus provides. All the raw materials. Pre-normalized. From trusted sources. Accessible through APIs designed for exactly this kind of multi-dataset integration.

Whether you're building an app or agent to support internal users, building a SaaS app to sell into the buy or sell side, or even building something just for you—viaNexus gives you everything you need to ship fast. The data is ready. The documentation shows you exactly how to call it. The examples prove it works.

The infrastructure is ready. What you build is up to you.

🔗 Learn more: https://vianexus.com
📧 Contact us: support@vianexus.com

AI has lowered the barrier to building powerful applications almost to zero.

You can spin up an agent in an afternoon. Wire it to an LLM. Give it a prompt, a tool, a dataset. Suddenly, it sounds intelligent!

This is true whether you’re:

• vibe-coding a personal project at home, or
• building a production-grade “GPT” intended to support traders, analysts, portfolio managers, or risk teams.

But here’s the uncomfortable truth:

Most AI applications fail not because the model is weak — but because the foundation is.

That’s where the viaNexus Agentic Services Technology (vAST) comes in.

The hidden risk: confidence without competence

There’s a well-documented cognitive bias called the Dunning–Kruger effect:
people with limited knowledge tend to overestimate their competence, while true experts are more aware of uncertainty and limits.

AI unintentionally amplifies this effect.

Modern LLMs produce:

• fluent language
• confident reasoning
• polished outputs

But fluency is not understanding.

In complex, regulated domains like finance, the danger isn’t hallucinations in isolation — it’s confident conclusions drawn from weak, misaligned, or unauthorized data, and then acted upon at scale.

A little bit of knowledge has always been dangerous. AI just makes it faster.

What most AI stacks get wrong

Most AI tooling focuses on:

• model selection
• prompt engineering
• orchestration
• UX

Dangerously, less attention is paid to:

• where the data comes from
• whether it’s licensed for the intended use
• how reliable or authoritative it is
• whether it’s normalized and comparable
• what market or regulatory semantics apply

As a result, agents often reason over:

• scraped or synthetic content
• inconsistent identifiers
• mismatched timestamps
• unclear real-time vs delayed status
• data they were never entitled to use in the first place!

The output may look impressive — until it’s scrutinized by a professional, a compliance team, or a regulator! GULP

 vAST: the missing layer for agentic finance

vAST (viaNexus Agentic Services Technology) exists to solve this problem.

Not just by making AI smarter — but by making AI more disciplined, grounded, and professional.

vAST sits between:

• high-quality data sources (our own and from trusted and vetted partners), and
• the agents and applications that consume them

providing the structural guardrails that AI workflows typically lack.

 Curated data, not random inputs

viaNexus curates best-in-class third-party data from:

• exchanges and reference data sources
• news providers
• analytics specialists
• alternative data vendors

This is not a data dump.

We select providers that:

• are authoritative in their domain
• operate under clear licensing frameworks
• meet professional expectations for accuracy, timeliness, and reliability

That data is then normalized and enriched, so agents aren’t reasoning over disconnected fragments.

 Normalization + reference data = shared reality

One of the most common failure modes in AI systems is silent inconsistency:

• different identifiers for the same instrument
• mismatched symbology
• incompatible calendars
• conflicting entity definitions

viaNexus addresses this by combining curated partner content with highly reliable reference and symbology data.

The result:

• a single, coherent view of markets
• consistent identifiers across datasets
• shared semantics that both humans and agents can rely on
• lower "reasoning" costs

This matters far more than most people realize — especially when decisions carry real financial or regulatory consequences.

Entitlements: knowing what an agent is allowed to know

AI systems are very good at overreaching. Just ask ChatGPT to tell you where it fetched its data from - all over the internet - and from sources that have licensed data solely for non-professional use. So if that data shows up in a response from a GPT from inside your firm - then you have created a licensing issue.

vAST enforces entitlement-aware access, ensuring that agents:

• only see data they are licensed to access
• only use data in permitted ways
• respect display vs non-display rules
• inherit the same constraints a human professional would

This does something subtle but important: It prevents agents from hallucinating authority where none exists.

That alone eliminates a major source of overconfidence.

 Domain semantics baked in, not hand-waved

Complex domains like finance are full of distinctions that matter:

• authoritative vs contextual
• primary vs derived
• fact vs opinion
• point-in-time vs revised
• source-specific vs aggregated

These nuances are easy to gloss over — and novices often do. Experts never do.

viaNexus encodes this domain context directly into the data layer, so agents operating through vAST don’t have to infer or guess. They inherit the structure, provenance, and intent of the data automatically.

This is how you avoid outcomes that are technically plausible, but professionally wrong — and why discipline at the data layer matters as much as intelligence at the model layer.

Designed friction is a feature, not a bug

Most AI platforms optimize relentlessly for speed.

vAST is optimized for appropriate hesitation.

That means:

• clear provenance
• visible assumptions
• entitlement checks
• signals when confidence should pause

This mirrors how real professionals work. And it quietly nudges users — human or agent — away from Dunning–Kruger territory and toward real competence.

From vibe-coding to production, without changing foundations

One of the most powerful aspects of vAST is continuity.

The same foundation can support:

• a weekend experiment
• an internal proof of concept
• a regulated, production-grade system

You don’t have to rewrite your architecture when:

• compliance gets involved
• clients ask hard questions
• regulators appear
• the stakes increase

You’ve already built on solid ground.

 The bottom line

AI makes it easy to sound right.
vAST helps ensure you are right — or at least minimally uncertain!

Whether you’re:

• vibe-coding an app at home, or
• building a professional GPT to support finance professionals

you need:

• high-quality, curated data
• normalized and grounded in reliable reference datasets
• delivered with clear provenance
• governed by entitlements
• and embedded with real market semantics

That’s what viaNexus and vAST provides.

In a world racing to make everyone feel like an expert, we’re focused on something harder — and far more valuable: Scaling intelligence without scaling overconfidence. 

Learn more here: https://vianexus.com/vast/

They mark when companies disclose performance, reset expectations, move prices, and trigger analysis across portfolios, models, and news systems. For many workflows, from research and monitoring to AI driven agents, knowing when earnings happen matters just as much as the earnings themselves.

In the United States, those moments are formally captured through earnings related 8 K filings. These filings are the earliest authoritative signal that earnings information has been released. They are not estimates or announcements. They are the regulatory record.

That makes earnings 8 Ks the ground truth for earnings timing.

The challenge is that while earnings 8 Ks are reliable, they are not predictable. Companies rarely announce dates far in advance. Filing behavior varies. Most earnings calendars rely on assumptions or static schedules rather than regulatory evidence.

The ViaNexus Earnings Calendar Events system exists to close that gap by learning directly from historical earnings 8 K behavior and turning it into a clear, machine readable schedule of what is likely to happen next.

Turning Regulatory Signals Into Reliable Schedules

Most earnings calendars answer a surface level question:
What is the earnings date?

They do not answer the questions that actually matter.
Is this date predicted or confirmed?
How confident should I be?
What happens when a real filing arrives?
How does the system adapt after the event passes?

For humans, that ambiguity is frustrating. For AI systems, agents, and automation, it is a breaking point. Without clear state and confidence, earnings dates become brittle signals that cannot be safely acted on.

The mission of the Earnings Calendar Events system is simple and strict.

Take authoritative regulatory signals, earnings 8 Ks, and convert them into a living, trustworthy earnings schedule.

That means tracking only real earnings events, not guesses. Learning filing cadence from actual company behavior. Explicitly distinguishing what is predicted from what is confirmed. Updating automatically as new filings arrive. Publishing one clear answer per company at any point in time.

This system does not forecast performance.
It forecasts timing, with transparency.

Everything downstream depends on that clarity.

An Agent First, Predictive Earnings Pipeline

The system begins with an 8 K classification agent. This agent is purpose-built to identify earnings-related 8-K filings only. It filters out all other 8-K event types and ensures that predictions are generated exclusively from filings that actually correspond to earnings releases, not press updates, restructurings, or unrelated disclosures.

Every day, thousands of 8-K filings are published, the majority of which are not earnings-related. The classifier continuously scans incoming filings and selects only those that explicitly correspond to earnings releases, ensuring that downstream predictions are driven solely by true earnings events.

This upfront filtering defines what the system trusts. Noise is removed before it ever reaches prediction logic. Once a filing is classified as earnings related, it flows into the rest of the pipeline as a high signal event.

Classified filings are stored and from there, an ETL process aggregates historical earnings filings by company and analyzes filing cadence using median intervals. Median intervals are deliberately chosen because they are more robust to late filings, amendments, and one off delays.

Based on that history, the system predicts the next plausible earnings filing date and assigns a confidence score that reflects how consistent that behavior has been over time.

Why This Algorithmic Approach Works

Earnings filings are not scheduled events in the traditional sense. They are behavioral signals shaped by company practice, reporting cycles, and regulatory timing. Treating them as fixed calendar dates introduces assumptions that break as soon as behavior changes.

Rather than imposing a schedule, the Earnings Calendar Events system models filing cadence directly. It looks at how a company has actually behaved and treats those intervals as signals rather than rules.

Using medians instead of averages preserves the central tendency of behavior without allowing outliers to distort the result. The confidence score is not a claim of certainty. It is a measure of stability. Companies with consistent filing patterns produce high confidence predictions. Companies with irregular behavior surface that uncertainty explicitly.

Nothing is smoothed away for convenience. Uncertainty is preserved rather than hidden.

Confirmation, State, and Transparency

Predicted and confirmed dates are never mixed.

Each earnings record is always in one of two states.
Predicted, generated by the algorithm.
Confirmed, backed by an actual earnings 8 K filing.

When a new earnings 8 K arrives, the system confirms the actual filing date, clears the prediction, and sets confidence to certainty. After a short expiration window, the system automatically transitions back into prediction mode for the next earnings cycle.

State transitions are driven by direct comparison between newly classified filings and the sources used in the prior prediction, ensuring that confirmation is tied to regulatory evidence rather than timing heuristics.

To ensure transparency, each record also includes the historical earnings 8 K filings used in the calculation. Users can see exactly which dates informed the prediction and how the system arrived at its result. Nothing is treated as a black box.

For downstream systems, this provides clear temporal truth instead of silent ambiguity.

How Customers Use This

Customers use the Earnings Calendar Events system to power earnings aware agents and LLM workflows, trigger alerts ahead of likely earnings windows, drive dashboards with confidence labeled event timing, reduce false positives in event driven strategies, and reliably schedule analysis, reporting, and automation pipelines.

Instead of asking whether a date is real, systems get the answer directly in the data.

From Signals to Schedules

Predicting earnings dates is not about precision for its own sake. It is about context.

The Earnings Calendar Events dataset is designed to work alongside ViaNexus filings, news, and event datasets, giving systems a unified, time-aware view of market activity without hiding uncertainty or overfitting behavior.

If you’re building workflows that depend on earnings events, market timing, or event-driven signals, we’d love to connect and hear your thoughts. The Earnings Calendar Events dataset is available to explore with a free trial on ViaNexus.

🔗 Learn more: https://vianexus.com/
📧 Contact us: support@vianexus.com