Large Language Model Personal Finance Assistants: Technical Architecture and Implementation Practices

Traditional budgeting tools have two fundamental problems: high data-entry costs and a steep analysis barrier. Users often need to export statements manually, categorize transactions one by one, or rely on fixed reports to understand their income and expenses.

A large language model (LLM)-powered personal finance assistant changes the interaction model to natural language. Users can ask questions such as:

• “Where did my money go this month?”
• “Do I have any duplicate charges?”
• “Have any subscription services increased their prices?”

With controlled permissions, the system can read data from connected accounts and perform queries, calculations, summaries, and explanations.

The core of this capability is not allowing the model to “do the accounting” directly. It is an engineering combination of controlled data access, deterministic computation, and LLM-based explanation.

1. Product Scope and Boundaries: A Read-Only Analysis Assistant

A personal finance assistant should initially be defined as a read-only analysis assistant. It may:

• Summarize account balances
• Categorize spending
• Compare the current month with historical periods
• Identify recurring subscription payments
• Detect duplicate charges or unusual fees
• Generate charts, bill calendars, or financial summaries on request

However, it should not automatically support transfers, payments, investments, or account-profile changes.

Financial errors can have serious consequences. Any write operation would require stronger identity verification, secondary confirmation, transaction limits, and compliance auditing. Keeping the assistant read-only reduces risk and focuses the product on three core activities: reading, calculating, and explaining.

LLM-generated analysis should be treated as supporting information, not as a replacement for bank statements or professional financial advice. The product should clearly explain that users must verify important conclusions against the underlying transactions and that the financial institution’s records are authoritative.

For complex financial decisions, the assistant may direct users to regulated professionals rather than provide definitive investment recommendations. Clear boundaries reduce risk while keeping the technical scope manageable.

2. End-to-End Architecture: From Natural Language to Verifiable Conclusions

A production-oriented system typically includes the following modules:

1. Client interaction layer: Receives natural-language questions and displays analysis results, charts, and supporting transactions.
2. Identity and authorization layer: Handles user authentication, account-linking authorization, permission scopes, and disconnection.
3. Account aggregation layer: Retrieves accounts and transaction data that users have explicitly connected through a general-purpose financial data aggregation service.
4. Data normalization layer: Standardizes fields, currencies, timestamps, transaction states, and merchant information across different accounts.
5. Analysis and computation layer: Performs aggregation, categorization, comparison, deduplication, and anomaly detection using deterministic logic.
6. Conversation orchestration layer: Identifies intent, creates query plans, invokes analytical capabilities, and organizes explanations.
7. Security and audit layer: Records access behavior, data scope, evidence used for analysis, and authorization status.

A representative data flow looks like this:

User question
  -> Intent detection and clarification
  -> Query plan: account scope, time range, and metrics
  -> Controlled data retrieval
  -> Deterministic computation and anomaly detection
  -> Evidence binding: transaction ID, date, amount, and category
  -> LLM-generated explanation
  -> User verification and feedback

The key principle is:

The LLM handles understanding and expression; the computation engine handles numerical accuracy.

For example, when a user asks, “How much did I spend on dining this month?”, the model should not estimate the answer from conversational context. Instead, the analysis module should aggregate transactions according to defined categorization rules, then provide the result and supporting evidence to the model for explanation. This significantly reduces hallucinations and calculation errors.

3. Account Linking and Least-Privilege Access

Account connections should use read-only authorization whenever possible. Users should authenticate directly with their financial institutions and authorize the system to access the required data. The assistant should not ask users to provide account passwords and should not receive permissions for transfers, payments, or investments.

A permission matrix can follow the principle of least privilege:

Data or operation	Default authorization	Design consideration
Account type and balance	Yes	Used for overviews and income/expense analysis
Transaction history	Yes	Limit retrieval to the smallest necessary time window
Sensitive account identifiers	Masked	Display only necessary last-four digits or aliases
Transfers and payments	No	Write operations are disabled by default
Investment transactions	No	Keep them separate from read-only analysis
Disconnecting an account	User-controlled	Stop access and clean up tokens after disconnection

Authorization tokens should be stored separately and bound to the user’s granted scope. After an account is disconnected, the system should stop accessing its data.

Data-retention policies should be explicit. Data that can be deleted should be removed promptly. Data that must be retained for auditing should be de-identified or masked and subject to access restrictions.

For users with multiple accounts, authorization should be manageable at the account level rather than requiring users to grant access to every account at once.

4. Transaction Normalization and Categorization

Transaction fields vary across financial institutions. Passing raw data directly to an LLM can easily produce incorrect interpretations.

The engineering pipeline should first normalize:

• Transaction timestamps
• Amounts
• Currencies
• Income and expense direction
• Merchant names
• Transaction status
• Refund indicators
• Installment information

The system should then perform deduplication. The same transaction may appear once on the statement date and again on the posting date. Refunds must be associated with their original purchases, while recurring subscriptions should be identified by merchant, amount, and payment frequency.

A hybrid categorization approach combining rules, models, and user corrections is generally appropriate:

• Rules handle high-confidence cases, such as known merchant categories, fixed keywords, and recurring charges.
• Models handle ambiguous merchants and long-tail categories.
• User corrections feed back into the personalization loop and help improve future categorization.

Every categorization result should retain its confidence level and supporting rationale. Low-confidence classifications should not be presented as definitive conclusions.

5. Conversational Analysis Orchestration: Plan, Retrieve, Then Explain

The conversation layer should not simply insert a user’s question into a prompt and let the model generate an unrestricted answer. A more reliable workflow is:

Intent detection → query planning → data retrieval → computation → explanation

intent = classify(question)
plan = build_query_plan(intent, user_scope, time_range)
facts = execute_deterministic_analysis(plan)
evidence = select_supporting_transactions(facts)
answer = llm_explain(facts, evidence, uncertainty)

When a question is ambiguous, the system should ask for clarification.

For example:

• “I’ve been spending too much lately” requires a time range and a comparison baseline.
• “What is this charge?” requires locating the specific transaction and showing its merchant, date, amount, and category.

A controlled conversation state should be maintained across multiple turns. However, the system should not place complete transaction histories into the model context without filtering. A better approach is to provide aggregate results, evidence IDs, and only the necessary fields. This reduces unnecessary exposure of sensitive financial data.

6. Implementation Considerations for Key Analysis Scenarios

Spending Summaries and Comparisons

Transactions can be aggregated by category, merchant, and time period, with support for month-over-month and year-over-year comparisons.

The system must account for refunds, installment payments, and pending transactions during comparisons. Otherwise, totals may be overstated or incomplete.

Subscription Detection

Recurring charges can be identified using merchant names, amounts, payment intervals, and repeated occurrence patterns. The assistant can then highlight services that users may have forgotten to cancel.

Duplicate Charges and Unusual Fees

Duplicate charges should be evaluated using merchant, amount, and time-window comparisons.

Unusual fees can be assessed using historical distributions, fee types, and the degree to which an amount deviates from normal patterns. The output should include supporting evidence rather than presenting only a conclusion.

Bill Calendars and Charts

Chart data should be generated by the computation layer. The model can select an appropriate visualization and explain the observed trends, but it should not independently generate the underlying numbers.

Interest Calculations

When the user provides the required information, or when the account data includes details such as an annual interest rate, the system may perform general interest estimates. It must clearly state the assumptions and avoid presenting an estimate as an actual statement amount.

7. Security, Privacy, and Compliance

Financial data is highly sensitive. The system should provide encryption in transit and at rest, role-based access control, and audit logs for events such as:

• Authorization
• Data queries
• Exports
• Account disconnections

The product should also define whether conversation data may be used for model training. If users can opt out of training use, this policy should be explained clearly in the interface and relevant agreements.

For cloud deployments, general-purpose cloud services can support foundational capabilities such as object storage, logging, monitoring and alerting, and access control. General cloud product categories provided by Baidu AI Cloud can also be used for infrastructure in this type of application.

Regardless of the infrastructure provider, the essential principles remain the same:

• Minimize the data collected
• Minimize the permissions granted
• Make access and analysis auditable

8. Reliability Evaluation and Product Disclosures

Evaluation should cover:

• Intent classification accuracy
• Categorization accuracy
• Anomaly recall
• Evidence consistency
• Response latency
• Operating cost

Evidence consistency is particularly important. Every key number in the model’s explanation should be traceable to an underlying transaction or an aggregated computation result.

The user interface should provide a way to view the supporting transactions. Low-confidence conclusions should include uncertainty notices.

When data is missing, authorization has expired, or an account is experiencing an error, the system should tell the user clearly instead of generating an apparently complete analysis.

9. A Phased Engineering Roadmap

A staged rollout is recommended:

1. Phase one: Implement read-only account overviews, balance queries, and basic spending summaries.
2. Phase two: Add multi-account normalization, category corrections, subscription detection, and duplicate-charge identification.
3. Phase three: Add charts, bill calendars, unusual-fee alerts, and evidence-chain views.
4. Final phase: Complete audit logging, permission governance, and reliability evaluation.

Each phase should preserve manual verification and feedback mechanisms. This helps prevent the product from expanding its automation boundaries too quickly.

Conclusion

The value of an LLM-powered personal finance assistant is not to replace traditional budgeting tools. Its value lies in organizing data access, deterministic analysis, and natural-language explanation into a verifiable conversational experience.

Only with least-privilege access, traceable evidence, strong privacy protection, and clearly defined boundaries can this type of personal assistant achieve a reliable foundation for long-term use.