Building a Conversational Personal Finance Assistant: Architecture, Capabilities, and Boundaries

Personal finance data is naturally scattered across bank accounts, credit cards, payment tools, and various bills. Traditional expense tracking requires users to manually export statements, categorize transactions one by one, and reconcile across apps—time-consuming and error-prone. As large language models (LLMs) and account aggregation technology mature, a new interaction pattern is emerging: users ask questions in natural language, the system reads authorized account data, and delivers spending analysis, anomaly identification, and visualizations. This article does not discuss any specific product. Instead, it dissects the architecture, key capabilities, engineering considerations, and compliance boundaries of a conversational personal finance assistant from a general technical perspective.

1. Problem Definition: From Manual Bookkeeping to Conversational Analysis

The core problem a conversational personal finance assistant solves is not “replacing the bank,” but “reducing the cost of understanding financial data.” The basic pipeline can be abstracted as follows:

1. The user connects accounts proactively, completing identity verification and read-only authorization;
2. The system retrieves account and transaction data through a regulated account aggregation service;
3. Transactions are normalized, categorized, aggregated, and checked for anomalies;
4. The LLM converts the natural language question into an analysis intent and invokes the corresponding tools;
5. The system returns a plain-language explanation, along with verifiable transaction details or charts.

Three boundaries must be made explicit in this pipeline. First, the system should adhere to a read-only principle, offering no transfers, payments, money management, or investment execution. Second, its output is analytical assistance—not an official bank statement and not licensed investment advice. Third, model-generated results can contain errors; any important conclusion must be traceable back to transaction records, with information from the account institution taken as authoritative. Only by defining these boundaries up front can subsequent architecture and feature design avoid overstepping them.

2. System Architecture and Data Flow

2.1 Authorization and Account Connection: Least Privilege Is the Starting Point

Account connection is the most sensitive part of a personal finance assistant. A sound design should never ask users for their bank credentials. Instead, authorization handoff, identity verification, and token issuance should be handled through a regulated account aggregation service. Users should clearly see the scope of what they are granting—for example, permission to read only account names, account types, masked account numbers, balances, credit limits, and transaction records within a defined time window. Authorization tokens should be stored encrypted, access should be isolated by user, account, and purpose, and users should be able to revoke connections at any time. Once revoked, subsequent data access should immediately become invalid, and related caches and derived data should be deleted or anonymized according to policy.

The key engineering principle here is “least necessary.” The system should not read any information irrelevant to financial analysis, nor should the authorization scope extend to money movements. For historical transaction lookback windows, the range should be set based on business needs and compliance requirements—for example, a few months up to two years—and clearly stated in the user agreement. Authorization management also needs audit logs: who authorized which account, when, what data was read, and when it was revoked should all be traceable.

2.2 Data Normalization and Storage: Turning Multi-Source Statements into Analyzable Facts

Transaction fields, time formats, merchant descriptions, and categorization standards differ across account institutions. After ingestion, data needs to be normalized: unify transaction time, amount signs, currency, merchant name, transaction description, account identifiers, and transaction status; apply idempotent handling to duplicate pushes; and distinguish the states of special transactions such as refunds, reversals, and pre-authorizations. The storage layer should be logically isolated by user and account, encrypt sensitive fields, enforce access through unified authentication, and retain necessary audit records.

A simplified transaction fact table might include: a unique transaction ID, account ID, transaction time, posting time, amount, currency, merchant description, original category, normalized category, transaction status, and data source batch. Derived tables would include daily balances, monthly income and expenses, category summaries, and anomaly detection results. The benefit of this design is that the conversational layer does not need to parse raw statements directly—it queries stable, precomputed analysis results, and anomaly detection and chart generation can reuse the same set of fact data.

2.3 Analysis Layer: Classification, Aggregation, Trends, and Anomaly Detection

The analysis layer is responsible for “turning data into conclusions.” Transaction classification typically combines rules and models: rules cover stable merchants and common categories, while models handle vague descriptions or new merchants. Classification results should retain confidence scores and provide a user correction path. Aggregation capabilities include category-level spending statistics, monthly surplus calculation, comparisons with historical months, and identification of membership renewals and bill increases. Anomaly detection focuses on patterns such as duplicate charges, unexpected fees, sudden amount changes, and subscription price hikes. When outputting results, the system should attach the triggering reason and the related transactions—not just an “anomaly” label.

2.4 Conversational Layer: Intent Recognition and Tool Calling

The conversational layer should not let the model “do the math directly.” Instead, the model handles intent understanding, tool orchestration, and result explanation. When a user asks “Did I spend more than I earned this month?”, the system should parse out the time range, statistical criteria, and required data, invoke an aggregation tool to compute income, expenses, and balance, then explain the result in natural language. When a user asks “Which expenses are rising?”, the system should invoke a trend detection tool that lists merchants, growth rates, and historical transactions. Model output should reference transaction IDs or detail summaries wherever possible so users can verify results. For financial concepts such as annualized rates or interest calculations, the system can explain the definitions and provide estimates based on authorized transactions, but should clearly state the estimation methodology and its limitations.

3. Core Capabilities

3.1 Income and Expense Classification and Monthly Surplus

Income and expense classification is the foundation of financial analysis. The system needs to distinguish income, expenses, transfers, refunds, and credit card payments, avoiding misclassifying account-to-account transfers as spending. Classification results should support user corrections, which can feed back into rules or personalized preferences. Monthly surplus is not simply income minus expenses; refunds, pending transactions, and credit card payment cycles must also be considered. From an engineering standpoint, the system should provide a “data cutoff time” and pending-transaction notices, preventing users from treating incomplete data as final conclusions.

3.2 Detecting Duplicate Charges and Anomalous Fees

Duplicate charge detection can use rules like “same merchant, same amount, multiple occurrences within a short time window,” or combine historical frequency with statistical deviation detection. Unexpected fee detection focuses on uncommon fee types, unusual merchant descriptions, and sudden amount changes. Subscription renewal identification requires maintaining a mapping between merchants and subscription cycles, combined with patterns of fixed amounts at fixed intervals. Every anomaly should come with an evidence chain: which transactions are involved, why it was flagged, and what the user should verify. The system should never automatically declare “this must be refunded”—it should prompt the user to investigate.

3.3 Trend Comparison and Interest Statistics

Trend comparison requires consistent criteria: the same categories, the same time windows, and the same account scopes. The system can compare month over month or week over week to identify steadily rising bills. Interest statistics need to distinguish purchase interest, installment fees, and other charges, estimate based on transaction and account information, and clearly state that “the account institution’s statement is authoritative.” For concepts like annualized rates, the system can provide educational explanations but cannot replace licensed financial advice.

3.4 Visualization and Adjustable Presentation

Beyond natural language answers, the system can generate weekly spending charts, bill calendars, and personal finance dashboards on request. The visualization layer should support further adjustments, such as switching time ranges, category dimensions, or account scopes. Chart data must come from auditable aggregation results—never numbers invented by the model. For key charts, the system should offer data downloads or drill-downs to transaction details so users can verify the numbers.

4. Engineering Implementation Points

4.1 Tool-Based Analysis, Not “Direct Model Calculation”

The recommended approach is to encapsulate financial analysis capabilities as controlled tools that the conversational layer orchestrates. Illustrative pseudocode:

def answer_finance_question(user_id, question):
    intent = parse_intent(question)
    accounts = auth_store.list_readonly_accounts(user_id)
    txns = tx_store.query(accounts, time_range=intent.range)
    facts = aggregate(txns, by=intent.dimension)
    anomalies = detect_anomalies(txns)
    citations = collect_transaction_ids(facts, anomalies)
    return compose_answer(facts, anomalies, citations)

This pseudocode highlights three points: permissions come before queries, aggregation comes before explanation, and conclusions come with citations. The model handles only intent and expression; numerical computation is done by deterministic tools, which significantly reduces the risk of hallucination.

4.2 Privacy and Training Data Isolation

Financial conversations are highly sensitive data. Sound practices include: clearly informing users how their data is used; providing entry points to revoke authorization and delete data; excluding financial analysis conversations from model training, or offering an explicit opt-in mechanism; masking sensitive fields in logs; and restricting internal access while retaining audit records. If the data is needed for quality improvement, de-identification and aggregate statistics should be used rather than raw transaction data.

4.3 Explainability and Error Handling

Every analytical conclusion should be as traceable as possible: which transactions were cited, what time range was used, and what classification criteria were applied. For questions the model is uncertain about, it should proactively state its limitations and recommend that users verify against their account institution’s information. The system should also enforce safety filters to prevent output of investment advice, money-movement instructions, or anything beyond the authorized scope.

5. Compliance, Risks, and Evaluation Metrics

A personal finance assistant involves financial data and user trust, so compliance must be built in throughout: user consent, least necessary access, purpose limitation, revocability, deletability, and auditability. The system should not claim to replace bank statements or imply that it provides licensed financial services. For more complex financial decisions, the general direction is collaboration with licensed professionals and regulated financial institutions, though specific partnership models require separate evaluation.

Evaluation metrics may include: transaction classification accuracy and user correction rate, anomaly detection recall and false positive rate, conclusion citation coverage, latency for authorization revocation to take effect, audit completeness of sensitive data access, and user feedback on how understandable the explanations are. For rollout, a pragmatic path is to start with read-only account aggregation, basic classification, natural language Q&A, and anomaly alerts, then gradually add trend analysis, visualization, and personalized rules, continuously calibrating through staged rollouts and monitoring.

Overall, the technical value of a conversational personal finance assistant lies in combining the natural language interaction capabilities of LLMs with real account data, letting users complete spending analysis through conversation that previously required switching between multiple account portals and bookkeeping tools. But its engineering success depends not on how convincingly the model “talks,” but on whether authorization is minimal, data is auditable, conclusions are explainable, and boundaries are clear. Only under read-only, controlled, revocable, and verifiable premises does this kind of capability have long-term viability.