Skip to content
TMX Group2025–26

Data Feeds

Redesigning how a client’s request for TMX market data becomes a live feed.

Here’s how it came together

Overview

Challenge

Clients waited an average of 106 days from requesting a market-data feed to having it live, which left approvals and handoffs stuck where nobody could see.

Opportunity

Treat the request journey as a product funnel, with defined stages, owners and service levels, so delays become visible and routine work moves on its own.

Date of Project

2025 to 2026

Role

Product Manager, Market Data

Responsibilities

  • Workflow mapping
  • Funnel and KPI design
  • SLA definition
  • Status and ageing reporting
  • AI-assisted automation

Tools

  • Salesforce
  • Data BP
  • Jira
  • Slack
Days, average request cycle
106 → <45
Shorter cycle time
~60%
Revenue recognition pulled forward
$700K+
Funnel stages defined
7

What a data feed is, and why the wait costs money

TMX Datalinx is the TMX Group’s market-data business. It distributes real-time Canadian equity data from the TSX, TSX Venture, TSX Alpha and the Montréal Exchange to banks, brokers, trading firms and data vendors globally.

A feed isn’t a login. It’s a stream a client wires into its own systems, governed by licences, usage rights and connectivity. A Data Feed Request turns a client’s order into live access, and the recurring revenue only starts once the feed is live.

  1. Exchange activity

    Quotes, trades and order books on TSX, TSXV, TSX Alpha and MX

  2. TMX market-data feed

    Level 1, Level 2, QuantumFeed, consolidated products

  3. Licence, rights, connectivity

    What the client may receive, and how it arrives

  4. Client systems

    Trading, pricing, risk, analytics, redistribution

  • Brokers
  • Trading firms
  • Data vendors
  • Wealth platforms
  • Asset managers
Exchange activity becomes a feed that clients build on. Every downstream use waits on the request.

The problem wasn’t one slow team

Clients waited an average of 106 days. Requests were stuck in approvals and handoffs that nobody could see, and delays were handled one escalation at a time.

Escalation can move one request while leaving the system unchanged. The loudest client gets attention, and older or higher-value requests stay hidden, thus delaying revenue recognition.

  1. Client approves

  2. Data Feed Request opened

  3. Approvals and handoffs

  4. Feed goes live

  5. Revenue recognition begins

Where the 106 days sat: between a client approving and the feed going live, with revenue waiting behind it.

Mapping every handoff

I mapped the journey end to end: where a request starts, every stage it can enter, who owns each one, what must be complete before it moves, and where it waits instead of being worked.

Requests were tracked across Data BP and Salesforce, with owners, notes and ageing kept by hand. Two teams could both call a request “in progress” and mean entirely different things.

Before

  1. IntakeOwner unclear
  2. Commercial & product reviewOwner unclear
  3. Agreement & entitlementOwner unclear
  4. Technical provisioningOwner unclear
  5. Client testingOwner unclear
  6. Go-liveOwner unclear
  7. BillingOwner unclear

After

  1. IntakeOwner · SLA

    AI reads and standardizes the request

  2. Commercial & product reviewOwner · SLA

    Missing-information check

  3. Agreement & entitlementOwner · SLA

    Fixed rules decide what’s required

  4. Technical provisioningOwner · SLA

    Jira ticket created automatically

  5. Client testingOwner · SLA

    Slack status updates

  6. Go-liveOwner · SLA

    Status update to the client team

  7. BillingOwner · SLA

    Activation feeds revenue reporting

Before, handoffs were invisible. After, every stage has an owner, a service level and, where the work is routine, automation. Stage names are functional, not TMX’s internal labels.

A defined lifecycle instead of heroics

I redefined the funnel stages, KPIs and SLAs: Intake, Commercial & Product Review, Agreement & Entitlement Review, Technical Provisioning, Client Testing, Go-Live and Billing.

With one shared definition of where a request is and who owns the next step, “this seems slow” became a measurable condition, and bottlenecks showed up by stage instead of by complaint.

Stop escalating; redesign the system

Option A

Keep escalating case by case

Quick relief for the loudest request.

Nothing is learned, and the next request waits just as long.

Option B

Add reviewers to the queue

More hands on the backlog.

The same hidden handoffs, at a higher cost.

Option C

Redesign the lifecycle

Chosen

Stages, owners, SLAs, shared visibility and automation for routine work.

Teams have to agree on shared definitions first.

Status and ageing everyone could see

I rebuilt the reporting around status and ageing: how long each request had sat in its stage, who owned it and whether it was inside its service level. A queue of 50 means something very different if 20 of them have waited three months.

Data feed requests · ageing
ClientFeedStageOwnerIn stageTotal ageSLA
Client ALevel 2 · TSXTechnical provisioningJM6d31dOn track
Client BQuantumFeedAgreement & entitlementAK12d27dAt risk
Client CCDF · TMX IPCommercial & product reviewSR3d9dOn track
Client DLevel 1 · TSXVClient testingJM15d44dOver SLA
Client ELevel 2 · MXIntakeRK1d1dOn track
Illustrative reconstruction of the ageing view. Clients, owners and ages are placeholders.

AI for the reading, rules and people for the controls

I automated parts of triage and status updates with AI-assisted workflows: reading a request, standardizing its fields, flagging missing information, creating the Jira ticket and posting Slack updates.

Market data is governed by licences and rights, so the line mattered. AI prepares and routes the work; fixed rules and people make the entitlement and approval decisions.

AI prepares

  • Reads the request
  • Standardizes the fields
  • Flags missing information
  • Creates the Jira ticket
  • Posts Slack status updates

Fixed rules decide

  • Which agreements are required
  • Entitlement checks
  • When a stage can start or finish

People own

  • Approvals
  • Exceptions
  • Client conversations
Who does what in the redesigned triage: AI prepares, fixed rules decide, people own the calls.

What it changed

Before106 days

After the redesignunder 45 days

About 60% shorter, with $700K+ in revenue recognition pulled forward

Average request cycle, before and after the redesign.
  1. Average request cycle cut from 106 days to under 45, about 60% shorter
  2. $700K+ in associated revenue recognition pulled forward
  3. A shared view of every request’s stage, owner and age
  4. Routine triage and status updates automated, with the controls kept with people
  5. Delays managed as a system, not a string of escalations

What did I learn?

Key takeaways

  • The hard part wasn’t automation. It was a shared definition of where a request is and who owns it.
  • Once the workflow was observable, automation became easier and safer.
  • In a governed product, AI should prepare and route the work, not make the control decisions.

Next time

  • Start with instrumentation and ownership definitions earlier.
  • Separate client waiting from internal waiting in the metrics from day one.

Next project

Market Data Calendar

TMX Group · 2025–26