Connecting LLMs to Account Data: Building a Personal Finance Analysis Assistant

This article discusses a general-purpose technical capability: an LLM assistant that, with explicit user authorization, connects to bank and credit card account data in read-only mode and uses natural language conversation to handle balance inquiries, spending categorization, bill tracking, duplicate charge detection, and unexpected fee analysis. The goal is not to replace bookkeeping software, but to combine structured transaction data scattered across multiple accounts with natural language interaction, rule engines, and visualization, lowering the barrier to personal finance analysis.

Problem Definition and Capability Boundaries

Traditional personal finance analysis typically relies on manually exporting statements, entering transactions one by one, or switching between different apps. The value of an LLM assistant is that users can simply ask questions like “How much more did I spend on dining this month than last month?”, “Are there any duplicate charges?”, or “How much interest did I pay this year?”, and the system can aggregate accounts, categorize transactions, compare against historical records, and provide plain-language explanations—all within authorized data.

However, capability boundaries must be made explicit. Such systems should adhere to the principles of read-only access, least privilege, explainability, and verifiability: they must never ask for banking credentials, and they must have no ability to transfer money, manage investments, or move funds. They only read data from accounts the user has actively connected. Analysis results are intended as reference only; important conclusions should be traceable to specific transactions, and information provided by financial institutions always takes precedence. For complex financial decisions, the system should direct users to consult licensed professionals rather than offering definitive investment advice.

Overall Architecture

A deployable personal finance assistant typically consists of the following modules:

1. Authorization and connection layer: Handles user identity verification and account linking through standard authorization protocols or compliant data channels, obtaining read-only tokens without ever touching user passwords.
2. Data sync layer: Pulls account balances, credit limits, and transaction records on demand, performing deduplication, currency and timezone normalization, and refund/transfer tagging.
3. Data storage layer: Applies field minimization and encryption for sensitive data—for example, storing only the last four digits of account numbers, account type, balance, and transactions within the authorized window.
4. Analysis service layer: Includes transaction categorization, recurring bill detection, anomaly detection, period-over-period comparisons, and interest calculations.
5. Conversation orchestration layer: Converts natural language questions into query plans, invokes analysis services, and generates answers backed by evidence chains.
6. Visualization layer: Generates spending charts, bill calendars, and financial dashboards on demand, with support for further adjustments.
7. Security and audit layer: Logs authorization, access, unlinking, and sensitive operations, and allows users to revoke connections and stop data access at any time.

When deploying in the cloud, you can compose general-purpose infrastructure services. For example, with Baidu AI Cloud, you might use object storage for encrypted archiving, message queues for asynchronous syncing, log services for auditing, key management for token custody, and monitoring and alerting for sync job health. The specific choices should be evaluated against compliance, cost, and operational requirements.

Account Connection and Authorization Design

Account linking should follow a flow of “user-initiated connection, explicit authorization, revocable at any time.” After the user completes identity verification on the financial institution’s page, a compliant data channel returns a read-only access token to the assistant. The system must not store user passwords or obtain payment or transfer permissions.

The authorization scope should be granular down to the field level: bank name, account name, account type, last four digits of the account number, balance, credit limit, and transaction records within the authorized historical window. Non-essential fields—such as full account numbers or government ID information—should not be collected by default. Once an account is unlinked, the system must stop accessing that account’s data and handle previously stored data according to its privacy policy.

Data Model and Sync Strategy

An illustrative data model:

Account {
  account_id: string
  institution_label: string
  account_type: "checking" | "credit"
  masked_number: string        // last four digits only
  balance: number
  credit_limit?: number
}
Transaction {
  transaction_id: string
  account_id: string
  posted_at: datetime
  merchant_key: string         // normalized merchant identifier
  amount: number
  currency: string
  category?: string
  is_refund: boolean
  is_transfer: boolean
  raw_description: string
}

The sync process needs to handle multi-account aggregation, transaction deduplication, refund reversals, exclusion of internal transfers, and timezone and currency differences. Recurring bills can be identified based on merchant, amount, and time interval. For categorization, users should be able to correct results, and those corrections should feed back into rule optimization—though sensitive conversation data must not be used for model training without explicit consent.

Conversational Analysis Workflow

The conversation layer should not dump raw transaction details into the context window. Instead, it should follow a “query plan → analysis service → evidence summary” orchestration pattern:

1. Parse user intent, e.g., “check balance,” “category breakdown,” “detect duplicate charges,” or “explain annual interest.”
2. Generate a permission-constrained query plan that only accesses connected accounts and the authorized time window.
3. Invoke categorization, aggregation, and anomaly detection services to produce structured results.
4. Generate a natural language explanation with traceable transaction records or time ranges.
5. Continue refining charts, filters, or statistical scope based on follow-up questions.

This approach reduces context length pressure and makes results easier to audit and reproduce.

Categorization, Bills, and Anomaly Detection

Spending categorization can combine rules, models, and user feedback: rules handle high-confidence cases, models handle long-tail merchant descriptions, and user feedback corrects errors. Bill tracking can surface recurring charges that are easy to overlook, such as membership renewals, subscriptions, and periodic payments.

Example anomaly detection rules:

Duplicate charges: same merchant, same amount, multiple times within a short window
Unexpected fees: fee-category amounts deviating significantly from historical distribution
Rising bills: charges from the same recurring merchant steadily increasing
Spending exceeds income: expenses consistently greater than income within the period
Interest calculation: estimate interest paid based on account APR and balance ranges

These thresholds are examples only and need calibration for your specific scenario. The system should avoid misclassifying normal installments, refunds, pre-authorizations, and internal transfers as anomalies, and should explain its reasoning in the answer.

Visualization and Explainability

Visualization should serve explanation, not decoration. Weekly spending charts can show category breakdowns and period-over-period changes; bill calendars can mark recurring charges and due dates; a personal finance dashboard can summarize balances, credit limits, monthly cash flow, and anomaly alerts. Every chart should be generated from structured configuration and support further filtering and adjustment.

Explainability requires that every conclusion carry an evidence chain wherever possible—transaction time, amount, normalized merchant name, and categorization rationale. For questions like “Am I spending more than I earn?” or “How much interest did I pay this year?”, the system should clearly state the statistical scope, time range, and assumptions.

Security, Privacy, and Compliance

Security design should include, at minimum: read-only authorization, encrypted token custody, field minimization, encryption in transit and at rest, access auditing, immediate halt on unlinking, no default use of conversation data for model training, and secondary confirmation for sensitive operations. The system must never request banking credentials and must not have transfer, investment, or fund management capabilities.

Additionally, establish data retention and deletion policies that specify how long authorization records, transaction caches, and analysis results are kept. For services operating across regions, applicable local financial data and privacy regulations must also be observed.

Accuracy Risks and Human Review

LLM-generated analysis may contain categorization errors, statistical scope inconsistencies, or inaccurate explanations. The product should prompt users to verify important figures, inspect the specific transactions supporting a conclusion when needed, and treat bank-provided information as authoritative. Engineering teams can continuously evaluate quality through offline labeled datasets, regression testing of rules, manual sampling, and anomaly rate monitoring.

Implementation Recommendations

Roll out in phases: start with read-only account linking, balance inquiries, and basic categorization; then add recurring bill detection, anomaly detection, and visualization; finally, explore compliant collaboration with licensed professionals and regulated financial institutions. At every stage, permission controls, audit logs, and explainable evidence chains should be mandatory requirements—not afterthoughts.

Ultimately, the key to combining LLMs with real financial data is not making the model “compute faster,” but using rigorous authorization, data minimization, rule-and-model collaboration, evidence chains, and human review to turn natural language interaction into a safe, controllable, and auditable personal finance analysis capability.