Paper Before Real Money: How My Finance Agent Earns the Right to Trade
By Arshad Ansari
Maou is the finance agent in AEGIS, the self-hosted agent platform I run my life on. A few weeks ago it learned to keep my books properly, and I wrote about why a ledger is not a database table. Now it has a second job: it runs a paper trading desk on real market prices.
The goal is simple. I have a trading system that decides what to hold each day. I want Maou to place those trades with real money. But not yet. First it has to show, on paper and over months, that the whole chain works and that the results are worth having.
This post covers both halves of what Maou now does with money, and what has to be true before the paper desk becomes a real one.
This is a write-up about engineering, not investment advice. The desk trades on paper, and this post deliberately does not show which stocks it holds.
The books: one view of where the money stands
The books are a plain-text double-entry journal in git, checked by hledger. Postgres is only an index over it. That was the last post. What changed since is that I can now see the money, not just trust it.

The figures are blurred because they are my real finances. The page shows:
- Net worth at each month end: everything I have, less everything I owe.
- Money in and money out, month by month.
- Where it went this month, by category. My business spending splits into its own categories rather than arriving as one bar called "business".
Every number comes from hledger, asked at the moment the page loads. Nothing is copied into a second table that could drift.
One rule mattered more than any chart. Some of my spending is in dollars and pounds, and the books have no exchange rate for those days yet. The easy move is to guess a rate and fold them in. Instead the page leaves them out of the chart and says so underneath: "left out of the charts because there is no rate for them: $, £". A wrong number that looks right is worse than a gap you can see.
Behind the charts are the parts that need action: bills still to pay, spending the books could not explain, and bank statements that have not been matched line by line. Maou raises those as tasks for me, and a task closes itself when its problem goes away.
The desk: who decides what
The split of responsibilities is the most important design choice, so here it is plainly:
- The trading system decides what to hold. Every evening it publishes a list of positions and how much of the portfolio each should be. That system is Ansaar, my market data platform, with its own models and its own risk manager.
- Maou decides nothing about the picks. It turns that list into orders for whole shares against the paper capital, places them, and fills them at the next session's opening price, using real prices.
- Maou scores the result against a benchmark every week and every month.
The agent is dumb on purpose. What I am testing is not whether an LLM can pick stocks. It is whether the full chain holds together: the trading system's decisions, the data they arrive on, the sizing, the fills, the costs and the scoring. When real money is involved, every link in that chain can lose it.

The rules that make a paper result mean something
A paper account is easy to fool, because nothing stops it from trading on information it could never have had. These are the rules the desk enforces in code.
1. Decide before the price exists. The desk plans at 8:00 in the morning, before the market opens, and fills at that day's open. If it ever reaches the planning step after the open, it skips the day and raises a problem. Filling at a price that was set before the decision existed is the classic way a paper account flatters itself.
2. Never rewrite a stored price. My price source quietly revises past closing prices after a stock split. So the first price the desk sees for a day is the only one it keeps. A paper book repriced on revised history is scored on numbers nobody could have traded.
3. When in doubt, hold. If the day's decisions are late, missing or look wrong, the desk trades nothing and opens a task for me. There is one exception. If the trading system says its risk manager has stopped trading, the desk sells everything. Silence is not treated as a stop, though. A pipeline that failed looks exactly like one that decided to sit out, and selling the whole book over a glitch is the mistake all these checks exist to prevent.
4. One stuck order does not freeze the book. If one stock cannot be filled, only that stock waits. The rest keep trading, and the day's plan lists what was held back.
5. Charge real costs. Every buy and sell pays a cost modelled on a real account's charges, and the monthly score also shows what the book would be worth after tax if it were sold that day.
These rules have already earned their place. In its first two weeks the desk hit two problems that a less careful setup would have hidden:
- A trading day disappeared. My price source served one real trading day with an empty opening and closing price. The desk builds its calendar from the index's prices, so it read the day as a market holiday and skipped it without a word. It now counts a past day as a trading day if it stored that day's open itself, because that open is proof the session happened.
- Most of the money sat in cash. The trading system caps how much of the portfolio can be at risk, and the desk also skips the crypto part of its decisions. Together that left the desk about 60% in cash. On a paper account whose job is to test the picks, that is mostly testing cash. The desk can now invest a set share of its capital, scaling the trading system's weights up in proportion, with a limit on how much any single stock can take. From 25 September it is set to be fully invested.
Scoring: against a benchmark that does nothing clever
The desk is judged against SHARIABEES, a halal index ETF: the same money, bought on the desk's first day at the same kind of price, then simply held. That is the honest question. What would I have earned by doing nothing clever with this money?
The score has two readings, and they are not the same thing:
- The headline is the gap to the whole benchmark. That is the number I actually care about.
- The alarm is judged on the gap per rupee the desk actually had invested. A desk that holds a third of its money in shares will trail a fully invested ETF in any rising market, whatever its picks. Judging the alarm on the headline would fire it for the wrong reason.
The desk also tells me how much to trust its own number. Until it has twelve weeks of results, its verdict is literally "too early". Once a month it checks whether the live results have fallen more than two standard errors below what the trading system's backtest promised. If they have, it raises a task telling me to look at the trading system before trusting it with more money.
Right now the desk has less than two weeks behind it. It is slightly ahead of the benchmark, and that means nothing yet. The page says "too early", and it is right.
What has to be true before real money
The live switch is a single setting in the desk's configuration. But only paper mode is built, and I intend to keep it that way until these are true:
- At least twelve weeks scored, so the desk's own verdict has moved past "too early".
- The monthly check stays quiet the whole time. If it fires, the clock starts again.
- No unexplained trades. Every fill, every day it held back and every price problem has a reason I have read.
- The broker is the source of truth. In a live account, the value of the portfolio has to come from the broker, not from the desk's own arithmetic. The trading system already knows how to read a broker balance and to stop opening new positions when that balance is missing or stale. The desk's side of that feed is the piece still to build.
- Small money first. The first live capital will be an amount I would not miss, placed through my broker's API, running beside the paper desk so the two can be compared day by day.
None of this needs Maou to be smarter. It needs the boring parts to be proven: the calendar, the prices, the sizing, the costs and the score. That is what months of paper trading are for.
Common questions
- How long should you paper trade a strategy before going live?
- Long enough for the result to mean something, and decide what that means before you start. A few good weeks prove nothing. Weekly returns are noisy, so a difference that looks large after a month is usually luck. My desk will not give a verdict at all until it has twelve weeks of scored results, and even then it only says how much weight the number deserves. Set the bar in advance, in code, so that a lucky month cannot talk you into moving early.
- How do you avoid look-ahead bias in paper trading?
- Make the decision before the price you trade at exists. My desk plans its orders before the market opens and fills them at that session's opening price. If it plans later in the day, it skips the day rather than fill at an open that was set before the decision was made. It also never overwrites a price it has stored, because data providers rewrite past prices after splits, and a paper book priced on revised data is scored on numbers nobody could have traded.
- What should a paper trading bot be benchmarked against?
- The simplest thing you could have done with the same money instead. For me that is a halal index ETF, bought on the same day at the same kind of price and simply held. If the bot cannot beat doing nothing clever, it has not earned real money. Compare like with like too: a bot that holds a third of its capital in shares should be judged on the money it actually had at risk, or it will look worse than it is in a rising market.
Get new posts by email
Data engineering notes like this one — what breaks and what it costs, in production.
What breaks and what it costs — pipelines, warehouse bills, and the failures that only show up in production. A few a month, never padded to hit a schedule. No sequence, no pitch deck. Reply 'stop' once and you're off — it reaches me, not a queue.
Want the whole playbook?
If this was useful, the long version is my book. Local-First Analytics — 314 pages, runnable code for every chapter — is the full build: DuckDB, Parquet and Arrow, from install to production. On Amazon, and chapter 1 is free to read here.
Get the bookNot ready to buy? Read chapter 1 free — the whole chapter, no email required.
Rather talk it through? Book a free 30-minute call. No slot that suits your time zone? Email info@hikmahtech.in.