A V2EX thread surfaced something quietly telling: someone noticed that a high-profile user manages finances through Claude's API, while retail customers get no programmatic access to their own transaction data. Alipay has a merchant MCP. Regular users get nothing.
The gap isn't surprising. Banks and payment platforms architect their systems around compliance boundaries, not developer convenience. But the need is real—people want to track spending, reconcile accounts, and run queries against their own money without logging into five separate apps.
Since the APIs won't open, the practical move is to build around what you can control: CSV exports and local storage.
What You Can Build
A personal finance aggregator on VicroCode works within these constraints. You run Python online to parse bank CSV files, normalize transaction formats across institutions, and write everything into a SQLite ledger. The SQLite editor gives you direct access to query, filter, and reconcile records without touching raw CSV files again.
On top of that, you build an HTML dashboard—monthly summaries, category breakdowns, duplicate detection, balance trends—and use web app hosting to keep it accessible from anywhere. The entire system runs in-platform: no server setup, no deployment pipeline, just functional software.
The limitation is upfront: this is not real-time. You manually export CSVs from each institution, upload them, and let the Python backend process the batch. If you need live balances or automatic syncing, you're back to waiting for APIs that probably won't arrive.
Why This Works
CSV import isn't elegant, but it's reliable. Every bank offers export. The formats vary—some use commas, others use semicolons, date parsing is a mess—but Python handles it. Once you normalize the data into SQLite, you have a single queryable ledger.
The benefit is control. You decide which fields matter, how to categorize transactions, and what counts as a duplicate. If your bank changes its export format, you update the parser. If you want to track something custom—shared expenses, tax-deductible purchases, foreign currency conversions—you add a column.
You also avoid vendor lock-in. Mint shuts down, budgeting apps change pricing, some new service wants to sell your spending patterns. A local SQLite file and a Python script don't have that problem.
What This Doesn't Solve
This setup will not connect directly to your bank. It will not pull transactions automatically. It will not sync in real time or send alerts when your balance drops.
If you need those features, you're dependent on third-party aggregators (Plaid, Yodlee) or hoping your institution eventually opens an API. For now, those remain out of reach for most retail users.
The CSV path also requires discipline. If you forget to export and upload for two months, your ledger falls behind. Automation here is limited to the processing step, not the data collection.
The Actual Workflow
You export CSVs from each account—checking, credit card, investment platform. Upload them to the VicroCode project. The Python backend reads each file, identifies the institution by format, parses dates and amounts, assigns categories based on merchant names or your own rules, checks for duplicates against existing records, and inserts new transactions into SQLite.
The dashboard reads from SQLite and renders charts, tables, and summaries. You can filter by date range, category, or account. You can export subsets for tax prep or reimbursement claims. If you want AI analysis—spending anomalies, budget recommendations—Model Center APIs can query the database and generate insights.
Because everything is hosted in-platform, you don't manage infrastructure. The trade-off is you work within VicroCode's execution environment: Python and SQLite, not Postgres or a custom backend language.
When It Makes Sense
This approach fits if you're already exporting statements for record-keeping, tired of fragmented app UIs, or want full control over your financial data without trusting a third party.
It doesn't fit if you need real-time alerts, automatic syncing, or investment portfolio tracking that depends on live market data. Those require APIs or integrations this setup can't provide.
The core idea is to build what's actually possible with the access you have, rather than waiting for the access you want. CSV imports are unglamorous, but they work. A local ledger isn't real-time, but it's yours.
If the API access gap bothers you, this is the functional alternative: a hosted finance tool built on manual exports, Python normalization, and SQLite persistence. It won't replace a professional service, but it will replace five browser tabs and a spreadsheet you never update.