Quant Trading for Programmers 20: Generate Paper-Trading Daily Reports And Alert Summaries

Articles 16-19 already have the ledger, snapshot, risk checks, and rebalance plan.

Article 20 combines these structures into one stable paper-trading daily report. It does not send the message yet. It only generates the message content.

Format The Message First

Many systems rush to connect Lark, WeCom, email, or SMS first.

I prefer to turn message content into a pure function first. As long as title, body, and severity are stable, connecting any sending channel later becomes much easier.

The daily report is not for decoration. It is for review. It should let the reader see at least three things clearly: what the account looks like now, whether risk is abnormal, and whether the next step needs action. A notification channel is only the carrier. The report content itself is the stable interface.

Message Object

Chapter 20 adds app/alert_messages.py.

@dataclass(frozen=True)
class PaperAlertMessage:
    title: str
    body: str
    severity: str

It is small, but the boundary is clear: the formatting module produces messages and does not care where they are sent.

Daily Report Content

format_paper_daily_alert() receives an account snapshot, a risk report, and an optional rebalance plan.

The body includes:

• Total equity.
• Cash and cash ratio.
• Position market value.
• Risk status.
• Risk violations.
• Rebalance suggestions.

If there is no rebalance plan, it does not invent a suggestion. If the plan is empty, it clearly says no rebalancing is needed.

Why Keep Plain Text

Plain text has several practical advantages:

• Easy to test.
• Easy to paste into articles and logs.
• Easy to send through different notification channels.
• Does not require deciding the final UI first.

If Markdown, HTML, or Lark rich text is needed later, a new renderer can be added on top of this stable object.

Current Mainline Integrated Run

Article 20 combines the previous four steps into a daily report:

uv run python -m scripts.chapter_examples paper-flow

Real output:

This daily report shows total equity, cash, position market value, risk status, violation reasons, and rebalance suggestions at the same time. It is not the final UI, but it is already good enough for logs, Lark messages, or daily review records. When multi-channel sending is added later, these fields should not be reconstructed. The system should reuse PaperAlertMessage.

Chapter Update And Repository

This chapter adds:

• app/alert_messages.py.
• A paper-trading daily report message object and formatting function.
• Combined output from account snapshots, risk reports, and rebalance plans.
• tests/test_alert_messages.py, covering risk violations and no-rebalance scenarios.
• A real current-mainline screenshot for the paper-trading daily report integrated example.
• Context on the daily report as a review interface.
• A stage review for articles 16-20.

Repository:

https://github.com/ax2/zi-quant-platform

Code for this chapter:

git clone https://github.com/ax2/zi-quant-platform.git
cd zi-quant-platform
git checkout chapter-20
uv sync --extra dev
uv run pytest tests/test_alert_messages.py

Chapter 20 is commit 2a9647e, tagged as chapter-20. The full test suite currently passes with 201 passed, with only existing FastAPI deprecation warnings.

Stage Review: Articles 16-20

The fourth group of five articles completes the loop from paper-trading state to daily report summary.

Article 16 implements the paper-trading ledger, giving account cash, positions, buy/sell executions, and equity calculation a testable foundation.

Article 17 generates account snapshots, unifying cash ratio, position market value, floating PnL, and weight definitions.

Article 18 adds risk checks, outputting structured violations for total exposure, cash buffer, and single-stock weight.

Article 19 converts target weights into rebalance plans and makes clear that a plan is not execution.

Article 20 combines snapshots, risk controls, and rebalance suggestions into a plain-text daily report, preparing for notification channels later.

The point of this group is not to make paper trading look complete. It is to separate four boundaries clearly: state, checks, plans, and messages. With these boundaries clear, real market data, schedulers, and notification channels will be much less likely to pollute one another later.

Summary

The paper-trading daily report is not the final step. It is an integration point.

Article 20 links the structures from the previous four articles so the system can produce one readable summary every day. The next group continues into recommendations, reviews, and notification channels, moving paper trading from “able to calculate” to “able to be observed continuously.”

WeChat

Follow ZiCode on WeChat

If this post was useful, you can follow later updates on WeChat as well.

X / Twitter

Follow @ax2_zicode

Faster technical notes, short thoughts, and new-post alerts are posted on X.

X Open X Profile @ax2_zicode