How NumbyAI Is Built: Architecture Walkthrough

NumbyAI is designed to turn bank statements into trustworthy, editable finance data without uploading sensitive files to a remote service. The architecture splits into a chain: Ingest → Process → Review → Insights.

1) Ingest: absorbing data shape chaos

Bank exports vary by country, bank portal, CSV style, and how they treat signs and decimals. The ingest stage uses heuristic detection to normalize everything into one stable internal shape: detect preamble vs. data rows, parse delimiters and date variants, separate debit/credit while preserving provenance, and keep currency info per row.

2) Process: rule-first classification with LLM fallback

The confidence ladder: high-confidence match from rules gets auto-applied, low-confidence goes to AI assist, no match gets queued for human review. This keeps AI from becoming the only oracle and creates a cheap feedback path — human corrections become future rule upgrades.

3) Review Queue: the control room

Most tools treat categorization as final output. NumbyAI treats it as a candidate result. The review queue is where weak model guesses get fixed, recurring mistakes become visible, and human decisions get stored back into operational logic.

4) Database layer

SQLite for local-first lightweight runs. PostgreSQL when scale or team usage needs stronger capabilities. The app is not a one-shot script — it is a small service with durable state.

5) LLM integration

Ollama runs locally by default. If Ollama is available, inference runs on your machine first. Cloud options stay as controlled fallback, not default behavior.

The same pattern is useful for any local-first AI data app: deterministic detection first, then model reasoning when confidence is low.