Skip to content

See the structure in the stream.

Analyze tick histories, market quality and event patterns with qSQL and vector operations. l provides the programmable calculation layer for moving between individual market messages, session statistics and surveillance research.

01 / The workload

Make event histories easier to question.

  • Tick histories
  • Session activity
  • Market events

The summary matters. So does the sequence.

A busy market creates many records for one underlying event. Session-level statistics reveal broad changes, while an investigation needs the exact interval, instrument and message sequence. Useful analytics must support both views without discarding the detail needed to explain a result.

Tick history and event reconstruction

Select recorded events by instrument, event type and interval. Sort and inspect the relevant sequence to understand what happened before and after a market change.

  • Extract an instrument-level event window
  • Compare auction and continuous-session activity

Liquidity and market quality

Derive activity, price and volume measures from normalized observations. Compare distributions across sessions and market segments to understand how participation changes.

  • Study spread and depth observations
  • Compare volume and event-density profiles

Surveillance rule development

Express candidate patterns using filters, groups and numerical thresholds. Examine matching events and compare the rule across a defined historical dataset as part of your own review process.

  • Study order, trade and cancellation patterns
  • Inspect matched events and their context

Capacity and operational research

Analyze recorded message counts, processing timestamps and application metrics. Investigate the relationship between activity bursts and measured system behavior.

  • Characterize peak session intervals
  • Compare measured processing-time distributions

02 / From data to analysis

From a market-wide pattern to the messages behind it.

An analytical investigation can keep the event-level record available while narrowing the set of intervals that deserve attention.

  1. 01Source data

    Start with a recorded session

    Use normalized messages with event times, sequence identifiers and the classifications needed for the analysis.

    • Event time & sequence
    • Instruments & types
    • Recorded observations
  2. l>Compute with l

    Find the relevant windows

    Filter the history, group activity and calculate the measures or rule conditions that define the investigation.

    • Interval selection
    • Activity aggregates
    • Analytical predicates
  3. 03Analytical result

    Review the supporting events

    Compare session summaries and extract the contributing messages for your own visualization, investigation or reporting application.

    • Market-quality tables
    • Candidate matches
    • Supporting event rows
Query an event history
/ Query an event history

l>seq:1+til 6

l>kind:`add`fill`add`cancel`add`fill

l>where kind=`fill
1 5

l>seq where kind=`fill
2 6

l>count each group kind
add   | 3
fill  | 2
cancel| 1

l>

03 / Why l

The expression stays simple.
The layout does the work.

You write q/k. The runtime considers the physical representation of the data, choosing encoding-aware operations where supported and materializing values when needed.

Column operations across event histories
Filters, grouping and reductions share the same array model. Compression-aware execution can preserve useful layout information while operating on supported columns.
Explicit connections to existing systems
Bring Arrow or Parquet files through the native interop libraries and return analytical results to your application. Data capture and the review process remain under your control.
Read the research

04 / Your first evaluation

Start with a result
you can verify.

Choose a normal session and a busy interval with known event counts, expected ordering and an analytical rule you can verify by inspection.

Available as a research preview for local evaluation.

Questions to answer with your sample

  1. Are event counts, timestamps and sequence order retained exactly?
  2. Can each aggregate or candidate match be traced to its input events?
  3. How do query time and memory change during the busiest interval?

Your data. Your next question.

What patterns are waiting in your event history?

Let’s talk