Trading Solution

1. About the Service

AI Trading Solution is a quant research system that we are developing.

• Structure: Market data collection layer + strategy backtest layer
• How strategies are described: Conditions are described in declaration files, not in code
• Current stage: In development, with collection targets and validation methods being expanded

2. Background

When building a quant strategy, the most time-consuming part is not coming up with the strategy but getting the data in place. Disclosures, prices, news and macroeconomic indicators each have to be fetched from a different place, and each source has its own format and update cycle. Between filling in missing values and aligning ticker codes, the time left for actually validating the strategy shrinks.

Maintaining is harder than collecting

The harder part is not collecting the data once but keeping it up to date continuously. If collection scripts are run by hand, the data falls out of sync within a few days. The worse case is when collection fails silently, and validation is run on stale data and the result is trusted.

Strategy validation has the same problem. If a strategy is implemented directly in code, the code has to be modified every time a single condition changes, and it becomes hard to trace which version produced which result.

Separating collection from validation

AI Trading Solution, our in-house solution, approaches this problem by dividing it into data collection and strategy validation. It is currently in development, and the structure and validation methods are still being adjusted.

In one line The most dangerous thing is not wrong data, but data you do not know is wrong.

3. Key Features

The system is divided into a collection layer and a backtest layer. The two layers live in the same repository, but their execution environments are separated. Collection deals with several external APIs and backtesting depends on numerical computing libraries, so if the dependencies are mixed, both sides become unstable.

The collection layer fetches market data on a set cycle and normalizes it. Collection units are registered and called by name, so the way it runs does not change even when a new data source is added.

The backtest layer takes a strategy as a declarative structure and runs it. When entry and exit conditions are described in a file, the engine interprets them, validates the strategy and produces a report of the result. The strategy file itself is under version control, so which conditions produced which result can be traced file by file.

Main features

Automated collection

Collection is not started by a person; it runs on a reserved schedule. The cycle differs by data type, so data updated daily and data released quarterly are not run at the same frequency.

Format normalization

Formats that differ by source are unified at the collection stage. The analysis layer downstream handles the data the same way regardless of which source it came from.

Data freshness check

We provided a separate procedure for checking whether a particular dataset has stopped updating. The most dangerous failure in automated collection is not an error but a silent halt.

Declarative strategy validation

Strategies are described as a declarative structure, not as code. It is easy to validate the same strategy repeatedly with only the conditions changed, and the validation history remains as files.

Report generation

Validation results are provided as a report, not as a list of numbers. The equity curve and performance by period are shown together, so the character of the strategy can be judged.

4. Outcome

We have put in place a structure that handles data collection and strategy validation within a single framework. The goal is to create an environment where the time spent on data preparation is reduced so that the focus can be on strategy validation.

Because strategies are described declaratively and execution is handled by a separate layer, we secured both strategy readability and validation speed. When repeated validation with changing conditions gets faster, the number of strategies that can be reviewed increases.

Thanks to the separation of the collection layer and the backtest layer, each can be improved independently. A new data source is handled by adding a collection unit, and a new strategy by adding a declaration file.

It is currently in development, and we continue to broaden the collection targets and validation methods.

5. Technology

Language / Runtime — Python is the primary language. Computation-intensive sections are implemented in Rust and called from Python, which keeps the declarations easy to read while securing execution speed.

Structural separation — The execution environments of the collection layer and the backtest layer are separated. This is so that a library version change on one side does not break the other.

Criteria for technology choices — The most dangerous thing in this system is not wrong data, but data you do not know is wrong. The criterion when deciding the structure was also "does the problem become visible?". Consolidating the collection entry point into one and keeping the freshness check separate, and splitting strategies into declaration files so that they correspond one-to-one with results, are all decisions that came from this.

6. Project Information

Item	Details
Project name	AI Trading Solution Development
Scope of work	Data pipeline and backtest engine development
Technologies	Python, Rust, declarative strategy definition, automated scheduling