Architecture and Practice of a Conversational Personal Finance Analysis System

Combining large language models with real financial data so users can check balances, classify spending, track bills, and spot unusual charges in natural language is an important direction for personal finance tools. These systems are not as simple as “letting a model read bank messages.” They involve account authorization, data normalization, metric calculation, query orchestration, result explanation, privacy compliance, and auditability. This article takes a neutral technical view of the architecture and implementation points of a conversational personal finance analysis system.

1. Capability boundaries and core problems

Traditional bookkeeping often requires users to export statements, categorize transactions by hand, or switch among bank apps and budgeting tools. A conversational finance assistant is useful because it turns “aggregate data, classify spending, detect anomalies, and explain the result” into a single natural-language interaction. A user might ask how much more they spent on dining this month than last month, which memberships renew automatically, whether any charges were duplicated, or how much interest they paid over a year.

The capability boundary must be explicit. The system should be an analysis aid, not a funds-operation tool. Account connections should be read-only. The system should not ask for bank passwords, and it should not transfer money, manage funds, or invest. Results can be wrong, and important conclusions should be traceable to specific transactions. For complex financial decisions, the system should tell the user to consult a licensed professional rather than offer investment advice.

2. Layered architecture

A deployable system usually has five layers:

1. Authorization and ingestion. Identity verification and read-only consent are completed through a third-party financial data aggregator or a bank’s open interface. The system obtains account name, type, the last four digits of the account number, balance, credit limit, and transactions within a limited time window.
2. Data normalization. Time zones, currencies, amount signs, transaction direction, merchant names, and category fields are unified. Duplicate transactions, refunds, pre-authorizations, and postings that cross month boundaries are handled.
3. Analysis services. Parameterized metrics include balance summaries, category totals, period-over-period and year-over-year comparisons, monthly surplus, duplicate-charge detection, unusual-fee detection, and interest estimates.
4. Conversation orchestration. User intent is recognized, natural language is turned into a controlled query plan, analysis services are called, and an explanation is produced with references to transaction details.
5. Security and compliance. This covers encrypted transport and storage, token rotation, log redaction, access auditing, deletion after a user disconnects an account, and isolation from training data.

Architecturally, model generation and numeric calculation should be separated. The model understands the question, selects tools, and explains results. Actual amounts are computed by deterministic services so the model does not do mental arithmetic or emit unauditable queries.

3. Account connection and read-only permissions

Account access should follow least privilege. The user signs in at the financial institution to grant consent. The system receives only a read-only token and never sees the password. The grant should be limited to account information and transaction reads, and should not include payments, transfers, or investing. Tokens should support rotation and revocation. Only the last four digits of an account number should be kept for display. Logs must not contain full account numbers or sensitive credentials.

Authorization check, in pseudocode:

function canReadAccount(userId, accountId, scope):
    grant = tokenStore.getActiveGrant(userId, accountId)
    if grant is null or grant.revoked:
        return false
    if not scope.contains("transactions:read"):
        return false
    if grant.expiresAt < now():
        return false
    return true

After the user disconnects an account, the system should stop accessing it and delete or anonymize cached data according to policy. Whether conversations in a dedicated finance entry point are used for model training should be isolated by product design, with a privacy notice users can understand.

4. Transaction normalization and the data model

Raw transactions often have inconsistent fields and should be normalized first. A transaction model should at least include:

{
  "account_id_hash": "hash",
  "txn_id": "source_txn_id",
  "posted_at": "2025-11-01T10:00:00Z",
  "amount": -35.80,
  "currency": "USD",
  "direction": "debit",
  "merchant_normalized": "example coffee",
  "category_raw": "Dining",
  "category_final": "Dining/Coffee",
  "is_recurring_candidate": true,
  "source": "aggregator"
}

Key processing includes merchant-name normalization, matching refunds and reversals, cross-currency conversion, a single time zone, and subscription-cycle detection. Classification can combine rules, a model, and user feedback: rules cover frequent merchants, the model handles ambiguous descriptions, and user corrections flow back as feedback samples.

Duplicate charges can be identified from the same merchant, the same amount, and multiple debits in a short window, or from a close match of subscription cycle and amount. Unusual fees can include a sudden bill increase, unexpected service charges, late fees, and accumulated interest. Monthly surplus should be based on income and spending totals, and it should be explicit whether transfers, investment-account movements, and other non-consumption items are included.

5. From natural language to an auditable query plan

The conversation layer should not let the model generate and run arbitrary database queries. A safer approach is a controlled query plan: the model emits a structured intent and parameters, and the server validates them before calling a predefined analysis function. For example:

{
  "intent": "compare_category_spend",
  "category": "Dining",
  "period": {"current": "2025-10", "baseline": "2025-09"},
  "group_by": "merchant",
  "include_transactions": true
}

The server checks field allowlists, the time range, and the user’s permissions, then executes the plan. The response includes transaction references, data freshness, and the calculation definition. Natural-language flexibility is preserved, while results remain reviewable and auditable.

6. Presentation and engineering practice

The interface can offer weekly spending charts, a bill calendar, and a personal finance dashboard, and it can let users change the time range and category granularity. Engineering practice should pre-aggregate common metrics, generate charts asynchronously, cache stable results, and control model-call cost. Monitoring should cover authorization failure rate, data latency, classification accuracy, duplicate-charge recall, and explanation readability. General-purpose object storage, logging, and monitoring and alerting can support archival and observability.

The system should keep reminding users that results are only a reference and that important figures should follow what the financial institution provides. Anomaly thresholds should be configurable, and conclusions should drill down to transaction details whenever possible. Conversational personal finance analysis is operationally usable only when permissions, calculation, explanation, and audit form a closed loop.