Trading and market making | Illustrative scenario

AI-assisted revenue estimation: an illustrative scenario

How a market maker or proprietary trading firm could use its own activity data to estimate revenue earlier, and to inform capital and risk conversations.

How the scenario could flowStep 1: Trading activity (Intraday positions and flows). Step 2: Feature store (Shared definitions). Step 3: Estimate model (Versioned and validated). Step 4: Labeled estimate (Range and drivers). Step 5: Reconciliation (Compared to official books).TradingactivityIntraday positionsand flows1Feature storeShared definitions2Estimate modelVersioned andvalidated3LabeledestimateRange and drivers4ReconciliationCompared toofficial books5How the scenario could flowStep 1: Trading activity (Intraday positions and flows). Step 2: Feature store (Shared definitions). Step 3: Estimate model (Versioned and validated). Step 4: Labeled estimate (Range and drivers). Step 5: Reconciliation (Compared to official books).Trading activityIntraday positions and flows1Feature storeShared definitions2Estimate modelVersioned and validated3Labeled estimateRange and drivers4ReconciliationCompared to official books5
Fig. 1 Intraday activity becomes a labeled estimate with a range, and every estimate is reconciled to the official numbers afterward.

Illustrative scenario. Based on industry exploration and typical engagement design; not a client result or a guarantee of outcomes.

The situation

A trading business learns its official revenue only after end-of-day processing and reconciliation. In between, desk heads and finance rely on partial P&L views and experience to judge how the day is going.

Leaders would like a credible, earlier read, along with an honest sense of how uncertain it is.

What the organization wants to achieve

  • Provide an earlier, well-labeled estimate of revenue and its drivers.
  • Help leaders compare capital use against risk-adjusted contribution.
  • Be clear about uncertainty and how the estimate is built.
  • Reconcile estimates with official numbers so trust can grow.

Approach

ARCHR would typically run this through its four phases: Discovery and Strategy, Pilot and Validation, Build and Scale, then Optimize and Evolve. In this scenario that could look like:

  • Discovery: document how revenue is calculated today, which data is available intraday and who relies on the figures.
  • Pilot: build a baseline estimate for one desk using historical activity and official results, and measure how it differs from the final numbers.
  • Pilot: show uncertainty ranges and drivers to users and gather feedback on usefulness.
  • Build: automate data feeds with change data capture from trade capture systems, keep inputs in a feature store so training and intraday scoring share the same definitions, and publish the estimate with clear labels.
  • Build: add reconciliation views so finance can compare every estimate with the official books.
  • Optimize: monitor accuracy, retrain on schedule under MLOps controls and consider further desks.

Technology and governance considerations

Modeling and data services on AWS, Microsoft Azure or Google Cloud could host the pipeline. Estimates would be labeled as estimates, kept separate from the official books, and reconciled to them. Models would carry versioning in a model registry, validation and drift monitoring.

Explainability would be treated as a design requirement. Each published estimate would show its main drivers, the data cut-off time and the model version, so a reader can see what the number does and does not include and finance can reproduce it later.

Because the estimate could influence capital and risk decisions, model risk management would be central. For prudentially regulated entities, model risk expectations, for example the Office of the Superintendent of Financial Institutions (OSFI) in Canada or the Office of the Comptroller of the Currency (OCC) guidance in the United States, would be a reference point, and market conduct requirements from securities regulators would be considered as context. Access to firm financial data would be tightly restricted. This is not financial or investment advice.

What success could look like

A pilot would agree measures and a baseline before any work starts. Qualitative signals the team could track include:

  • Leaders find the estimate a useful early indicator rather than a distraction.
  • Gaps between estimate and official figures are measured and explained.
  • Finance and risk trust the method after reviewing documentation.
  • Discussions about capital allocation draw on shared, consistent information.

Actual results depend on an organization's data, systems and objectives. This page is not legal, financial or investment advice.

Technologies that could fit

Tools we commonly work with include the examples below. We recommend what fits your estate, and the choice stays yours.

Cloud

The three major clouds we design and build on, shaped around the estate you already run.

  • AWSAmazon Web Services: broad infrastructure, data and AI services.
  • Microsoft AzureMicrosoft's cloud, closely tied to Microsoft 365, Fabric and Entra ID.
  • Google CloudGoogle's cloud, known for BigQuery, Dataplex and Vertex AI.
  • Cloud object storageAmazon S3, Azure Data Lake Storage and Google Cloud Storage as lake foundations.

Data platforms

Warehouses, lakes and lakehouses where governed data is stored, modeled and shared.

  • DatabricksLakehouse platform for data engineering, SQL analytics and machine learning.
  • SnowflakeCloud data platform for warehousing, sharing and analytics.
  • Microsoft FabricUnified analytics platform with OneLake, pipelines and Power BI.
  • Google BigQueryServerless data warehouse with built-in machine learning.
  • Amazon RedshiftCloud data warehouse in the AWS ecosystem.
  • Azure Synapse AnalyticsAnalytics service combining warehousing and big data on Azure.
  • Delta LakeOpen table format that adds reliability to data lake storage.
  • Apache IcebergOpen table format for large analytic tables across engines.

AI and GenAI

Machine learning, generative AI and agents, built with evaluation, guardrails and human review.

  • Azure OpenAI ServiceLarge language models delivered through Azure with enterprise controls.
  • Amazon BedrockManaged access to foundation models, agents and guardrails on AWS.
  • Google Vertex AIGoogle Cloud platform for machine learning and generative AI.
  • Amazon SageMakerManaged service to build, train and deploy machine learning models.
  • Azure Machine LearningAzure service for training, deploying and monitoring models.
  • Hugging FaceOpen models, datasets and libraries for machine learning.
  • LangChainFramework for building retrieval and agent workflows.
  • MLflowExperiment tracking and model registry for MLOps.
  • Vector databasesEmbedding stores such as pgvector, Azure AI Search and OpenSearch for retrieval.

These tools are examples of what we commonly work with, listed as text only. We are vendor-neutral and recommend what fits your estate. Product names belong to their owners, and their appearance here does not imply a partnership, endorsement or certification.

FAQ

Frequently asked questions

Would the estimate replace official revenue reporting?

No. It would sit alongside official reporting, be clearly labeled, and be reconciled to it.

What if the model is wrong on a volatile day?

That is why uncertainty is shown and accuracy is tracked. The pilot would examine volatile periods specifically and set rules for when the estimate is not shown.

Let's talk about your data and AI priorities

Tell us what you are trying to solve. We aim to reply within one business day.