Tracking Smart Money in Real Time: Building a Minute-Level Capital Flow Engine | by DolphinDB | Jun, 2026 | MediumSitemapOpen in appSign up<br>Sign in

Medium Logo

Get app<br>Write

Search

Sign up<br>Sign in

Tracking Smart Money in Real Time: Building a Minute-Level Capital Flow Engine

DolphinDB

15 min read·<br>Just now

Listen

Share

Every trading day, millions of orders flood through the stock exchange — and buried inside that noise is a signal serious traders care about: where the big money is moving, minute by minute. Is smart money quietly accumulating a position through large buy orders, or are large sell orders signaling an exit? Catching this in real time, at scale, is a classic streaming data problem — and it’s exactly what we’ll build in this tutorial.<br>Press enter or click to view image in full size

We’ll use DolphinDB’s built-in stream processing framework, which handles publishing, subscribing, and preprocessing streaming data, real-time in-memory computation, and rolling/sliding/cumulative window aggregations out of the box.<br>Press enter or click to view image in full size

Using simulated tick-by-tick trade data from the Shanghai Stock Exchange on a single trading day in 2020, we’ll calculate minute-level capital flow — splitting buy and sell orders into “large” and “small” buckets based on a 50,000-share threshold — and stream the results live into a dashboard.<br>1. Scenario Overview<br>Using simulated tick-by-tick trades from the Shanghai Stock Exchange (SSE) on a trading day in 2020 as the data source, this tutorial demonstrates how to calculate minute-level capital flow in real time with DolphinDB’s stream processing framework. This example calculates the trading value of large and small orders (buy or sell) over a 1-minute rolling window, classifying orders by trading volume with a threshold of 50,000 shares.<br>1.1 Data Source<br>The schema of the DolphinDB table used to store tick-by-tick trades from SSE is as follows:

1.2 Metrics<br>Now that we know what the raw tick-by-tick data looks like, the next question is obvious: what exactly do we want to extract from it? This tutorial calculates the following metrics:<br>Press enter or click to view image in full size

Rules for classifying large and small orders in capital flow analysis vary across stock market software, but they are generally based on the quantity of shares traded or the trading value. For example, common stock market software in China uses the following rules:<br>Eastmoney<br>Extra-large order: >500,000 shares or CNY 1,000,000<br>Large order: 100,000–500,000 shares or CNY 200,000–1,000,000<br>Medium order: 20,000–100,000 shares or CNY 40,000–200,000<br>Small order: Sina Finance<br>Extra-large order: >CNY 1,000,000<br>Large order: CNY 200,000–1,000,000<br>Small order: CNY 50,000–200,000<br>Very small order: Note: In this tutorial, orders are classified solely by trading volume into two categories: large and small. The threshold is set arbitrarily for demonstration purposes, so you must adjust it to suit your actual use case.<br>1.3 Real-Time Calculation Solution<br>With the target metrics defined, the remaining challenge is execution — how do we compute these numbers continuously as new trades stream in? That’s exactly what DolphinDB’s stream processing framework is designed for. This tutorial calculates capital flow in real time using a user-defined aggregate function. Here’s how the pipeline is structured:<br>Press enter or click to view image in full size

Workflow description:<br>tradeOriginalStream, tradeProcessStream, and capitalFlowStream are all shared, asynchronously persisted stream tables.<br>tradeOriginalStream : Receives and publishes real-time streaming data for tick-by-tick stock trades.<br>tradeProcessStream : Receives and publishes intermediate data processed by the reactive stateful engine.<br>capitalFlowStream : Receives and publishes capital flow metrics for a 1-minute rolling window processed by the time-series engine.<br>Tables are shared in-memory so they’re accessible to all other sessions on the current node. When real-time streaming data is written to DolphinDB stream tables through the API, the session connected to the DolphinDB server may differ from the session that defined the tables, so the tables must be shared.<br>Persisting a stream table serves two main purposes. First, it limits the table’s maximum memory usage. By setting the cacheSize parameter in the enableTableShareAndPersistence function, you can control the maximum number of records retained in memory and therefore the table's maximum memory usage. Second, in the event of an unexpected node shutdown, you can recover data that was written to the stream table but not yet consumed from the persisted data files, ensuring the streaming data is consumed at least once.<br>Stream tables use asynchronous persistence, which effectively improves write throughput. Only stream tables can be subscribed to and consumed, so tradeOriginalStream, tradeProcessStream, and capitalFlowStream must all be defined as stream...