trAIder: an AI trading system, built like production software.

trAIder is our own AI-driven trading system for US equities. Every trading day it evaluates thousands of stocks, decides for itself what to buy and sell, and is designed to run without a human in the loop. We have been developing and testing it since 2025. trAIder is an application in development and testing that is currently not offered to third parties; it is not an investment offer, and this page says nothing about returns.

Why we show it: trAIder is our lab. Here we are client and developer at the same time, and every mistake hits us. Everything we tell clients about data pipelines, LLM infrastructure, model validation and operations we tried on ourselves first. And because we document every result, this page also says what did not work.

Status September 2026: trAIder runs in forward paper trading with several parallel books that are rolled forward automatically every night. The broker connection is built and tested. A first pilot with real money is prepared and tied to criteria set in advance.

Approach 1: news, language models and reinforcement learning

The idea was that an agent can recognise strong price moves if, besides the price, it also knows what is being reported about a company. That took three things: a news pipeline that turns articles into machine-readable features, a training environment for the agent, and a platform on which both scale.

The news pipeline. The starting point is GDELT, a project that indexes news worldwide in over 100 languages but, for copyright reasons, only supplies metadata and URLs. The news data loader, written in Python and run as Kubernetes jobs, queries the GDELT API and automatically narrows time windows because the API returns only 250 hits per request. It then downloads the articles itself: with a real Chrome browser via undetected-chromedriver, because many financial sites are JavaScript-heavy and lock out simple HTTP clients. Every download is classified before it is processed further: valid article, cookie wall, bot challenge, Cloudflare error, access denied. Cookie walls are clicked away automatically in four stages, from known consent selectors through a CMP-independent overlay search to iframes. Domains that block permanently lock themselves out after five failed attempts. Several downloader pods work in parallel and fetch their work from PostgreSQL with SELECT … FOR UPDATE SKIP LOCKED, without coordination overhead and without duplicate downloads.

The raw HTML pages land in MinIO, an S3-compatible object store, metadata in TimescaleDB, and the cleaned texts as Parquet in a data lake that can be queried with SQL via Apache Drill. Cleaning is done by a language model: Meta-Llama-3.1-8B-Instruct, AWQ-quantised to INT4, removes advertising, navigation and newsletter boxes and returns structured JSON with paragraphs, lists and tables in which numbers must remain unchanged. This is how we processed 2.65 million articles. The language models run as vLLM servers on our own GPU platform.

From articles to features. Reinforcement learning needs observations of fixed length; news has none. So articles are not used as text but as a feature vector per stock and day. Two models share the work: a small model (Qwen2.5-7B-Instruct, AWQ) cheaply checks whether an article reports on company results or regulatory events at all. Only then does a large financial model based on Llama 3.1 with 70 billion parameters analyse the text: surprise positive or negative, guidance raised or lowered, strength of the statement, plus tone, promotional character and rumour flags. All answers are strictly schema-bound JSON, categorical values are one-hot encoded, with upstream checks against the most common misinterpretations. The result is a fixed-length vector per day and stock with temporal decay, stored in the database. There are no LLM calls during training. Every feature group carries a version number and a computation timestamp, so that when a prompt or model changes only the affected part needs recomputing.

The agent. The training environment is built in PyTorch. The agent is a Double DQN with experience replay; as networks we compared multi-layer perceptrons and a Conv1D-LSTM variant over time windows. Episodes are time windows per stock in which the agent can buy, hold or sell. The real work was in what textbooks leave out: outlier candles that dominate training, rewards that have to be clipped, a portfolio value that needs lower and upper bounds, fixed random seeds for reproducibility, a universe filter against illiquid and structurally unstable stocks, and a training GUI that draws every step of the agent live onto the chart via WebSocket (see below).

Why we stopped. The agent learned the training data, but not the market. On known stocks and known periods it looked good; on new stocks it was close to zero or below. Eight pre-registered experiments with different configurations changed nothing. A targeted counter-test, a supervised model on the same observations, then showed that the problem was not the training but the input data: it did not contain the signal we were looking for in usable strength, with or without news features. We froze the RL path and shut down the news pipeline. Both are recorded in the documentation, with date and reasoning.

The interface: trAIder GUI

An autonomous system does not need a control interface, but it needs an observation interface. The trAIder GUI is exactly that, and expressly not a place where a human overrides the system’s decisions. For every stock and every day it shows the price, above it the actual events as bands, the model score as a second band, buy and sell markers, holding phases and the cumulative profit and loss. Hits, false alarms, missed events and delay can be read directly from comparing the two bands. Added to that are one page per paper book with key figures, equity curve and order book, annual views for all backtests from 2018 to 2026 with automatic assignment of the correct out-of-sample model, and a walk-forward view that sets the return curves of all annual windows on a logarithmic axis against the band of the random control.

Technically the GUI is deliberately lean: one FastAPI process under Uvicorn on Python 3.12, server-rendered Jinja2 templates and hand-written ES modules without a build step, TradingView Lightweight Charts 5 with a custom canvas layer for the bands and a second chart pane for the model score, three WebSocket channels for live updates from running trainings, and psycopg 3 with a connection pool directly on PostgreSQL, without an ORM. Long lists are rendered in blocks of 500 rows and loaded via infinite scroll; an order book with around 3,700 rows per year loads its pages in about 16 instead of 590 milliseconds after a switch to a materialised CTE with lateral joins, measured on the development database.

We built the login ourselves, after weighing it against Keycloak, which is recorded in the documentation: Argon2id for passwords, server-side sessions instead of JWT so that a session can be revoked immediately, mandatory TOTP with ten one-time recovery codes, lockout after ten failed attempts and an audit log. The connection is secured with TLS using certificates from our own PKI, renewed automatically by cert-manager. The access rules live in a single middleware that denies everything by default; a test runs over the real route table and checks that every writing route requires administrator rights and every WebSocket authenticates before the connection is established. Exactly this test found three unprotected WebSockets. And one rule is written down as a test: the interface can only downgrade a broker account, from live to paper to off, never upgrade it.

The most unusual part is an MCP server that runs in the same process. Through it an AI assistant can list and clone experiments, activate a configuration, start a training run on the GPU cluster, query its progress and read the evaluated results, in the same export format the GUI’s download button delivers, so that the two never drift apart. The guard rails are deliberately hard: a run starts only with explicit confirmation, only for a previously activated configuration, and never while another run is active. The progress display computes its remaining time from the observed arrival rates and would rather report „stalled“ than a wrong estimate.

Technologies