TradeTrack2

TradeTrack2: The Financial-Correctness Core

2 min read Updated July 23, 2026
← TradeTrack2 on Projects

Financial software has no rounding room. I own the part of a portfolio analyzer where being exactly right is the whole job.

The Problem

Brokerage statements are messy and inconsistent. Your true positions, realized gains, and performance only exist if something parses them correctly, every time. Get the accounting wrong and every number downstream is wrong too.

What I Built

TradeTrack2 is an investment-portfolio analyzer I build with one other engineer. I own the financial-correctness core: the parsing and accounting that everything else trusts. Not the whole product - the half where a mistake is unacceptable.

Tech Stack

Languages
  • C#
  • Razor
  • JavaScript
  • Bicep
  • PowerShell
Runtime & frameworks
  • .NET 10
  • ASP.NET Core
  • Razor Pages
  • Blazor Server interactive components
  • SignalR
Data & storage
  • EF Core
  • SQLite portfolio.db
  • PostgreSQL
  • Npgsql
  • ASP.NET Data Protection file-backed secrets
Infra & deploy
  • Docker/Compose
  • GitHub Actions
  • GHCR package images
  • Azure Container Apps + Bicep/ACR/Key Vault
  • Cloudflare Worker update feed
AI / ML
  • OpenRouter
  • Google GenAI (Gemma/Gemini)
  • AI Router service
  • Microsoft Agents AI Workflows
Testing
  • xUnit v3
  • FluentAssertions
  • WebApplicationFactory integration tests
  • Testcontainers PostgreSQL
  • coverlet
  • Node/Bicep deployment contract tests
Notable libraries
  • SnapTrade.Net
  • PdfPig
  • Chart.js
  • Bootstrap
  • ExcelFinancialFunctions

How It Works

I own the broker-statement parsers (Fidelity and Schwab, PDF and CSV), a canonical symbol-normalization engine with OCC option formatting, and lot matching with realized gain/loss and holding-period tracking. Market data lives behind a standalone QuoteService the web app can only reach over HTTP, through an interface, with pre-shared-key auth and live health probes - so market data can never bleed into the accounting by accident. I also ran the SQLite-to-Postgres cutover.

TradeTrack2: the financial-correctness core, walled off from market data The financial-correctness core is a left-to-right pipeline: broker statements from Fidelity and Schwab, in PDF and CSV, feed parsers that produce canonical transactions; those feed a symbol-normalization engine handling OCC option formatting; that feeds a lot matcher computing realized gain and loss and holding-period tracking; and that writes to portfolio dot db, which moved from SQLite to Postgres. Below the core, portfolio.db feeds read-only positions and realized gains to the web app, the rest of the product built with another engineer. The web app separately reaches a standalone QuoteService for live market data, but only over HTTP, through an interface, with pre-shared-key authentication and live health probes. Critically, there is no connection at all from the correctness core to QuoteService - that missing path is drawn explicitly as a blocked stub, because market data must never bleed into the accounting by accident. TradeTrack2 the financial-correctness core, walled off from market data Financial-Correctness Core - mine Broker Statements Fidelity - PDF, CSV Schwab - PDF, CSV Parsers PDF + CSV parsing -> canonical transactions Symbol Normalizer OCC option formatting Lot Matcher realized gain / loss holding-period tracking portfolio.db SQLite -> Postgres cutover system of record: positions, gains never reaches QuoteService directly positions, realized gains (read) Web App - the rest of the product Razor Pages, Blazor Server, SignalR co-built with another engineer not part of the correctness core HTTP only QuoteService - standalone interface + pre-shared-key auth live health probes the only door to market data
The financial-correctness core never touches market data directly. QuoteService is reachable only from the web app, over HTTP, through an interface, with pre-shared-key auth and live health probes - so live prices can't bleed into the accounting by accident.

What Made It Hard

Correctness with no tolerance: lot matching and realized gains have to be exact, not close. Keeping market data decoupled so the web app never reaches into it directly. Working inside one codebase with another engineer and keeping the seams clean enough that neither of us breaks the other.

The Throughline

This is the collaboration piece. I do not need to own the whole product to do my part well. I took the half where correctness matters most, made it dependable, and drew a hard interface around it so the rest of the system can trust it without knowing how it works.

Status

Active, ongoing collaboration. My contributions concentrate in the parsing, accounting, and market-data boundary.