Technical Architecture and Engineering Practices for LLM-Powered Personal Finance Assistants

1. From Manual Bookkeeping to Conversational Financial Analysis

Personal finance management is a frequent need, but many existing tools still only partially address it. Traditional bookkeeping applications usually require users to manually enter transactions, import statements, define classification rules, and then review charts or reports. This approach has several clear limitations.

First, financial data is often scattered across banks, credit cards, and electronic payment channels, forcing users to switch between multiple applications. Second, statement formats are inconsistent, merchant names are often non-standard, and automatic categorization may have limited accuracy. Third, when users want to answer a specific question, they often need to navigate several screens and combine filters, creating a fragmented experience. Fourth, unusual charges, duplicate subscriptions, and hidden fees are difficult to detect in a timely manner.

After large language models were introduced, the interaction model for personal finance management changed. Users no longer only “view reports.” They can ask questions in natural language, such as:

• “How much did I spend on dining this month?”
• “Have there been any duplicate charges recently?”
• “Are my subscription fees higher than last month?”

The model can integrate data from authorized accounts and perform aggregation, categorization, comparison, explanation, and visualization.

However, the core difficulty of this type of application is not “being able to chat.” It is how to place natural language interaction inside an engineering system that is secure, controllable, and auditable. Personal financial data is highly sensitive and involves privacy, authorization, permission boundaries, data minimization, model hallucination, and compliance considerations. Therefore, the technical design must be built around read-only access, least privilege, explainable output, traceable logs, and human review.

2. High-Level Architecture: From Data Access to Conversational Output

A relatively complete LLM-powered personal finance assistant can usually be divided into the following layers.

1. Account connection layer
   This layer handles user identity verification, financial data authorization, account binding, token management, and permission revocation. It does not directly perform business analysis. Instead, it ensures that data access is lawful, compliant, and controllable.

2. Data standardization layer
   Different financial institutions may return transaction records in different formats. This layer unifies field definitions, such as transaction time, amount, currency, merchant name, merchant category, payment method, account type, and transaction status.

3. Business analysis layer
   Based on standardized data, this layer performs spending categorization, monthly aggregation, trend comparison, subscription detection, unusual charge detection, interest calculation, and budget analysis.

4. Model understanding layer
   This layer identifies user intent and extracts parameters such as time range, account scope, spending category, and amount threshold. It converts natural language into a structured query request.

5. Result generation layer
   This layer converts query results into natural language answers, charts, billing calendars, financial dashboards, or other output formats, with the necessary supporting data.

6. Governance and audit layer
   This layer includes access control, logging, sensitive information masking, model output risk warnings, data deletion, permission revocation, and anomaly alerts.

The key value of this layered structure is that the model is only responsible for understanding and expressing information. It does not directly own permissions to move funds. Business queries must pass through controlled interfaces. Sensitive data must enter a least-privilege and auditable processing chain.

3. Account Connection: Read-Only Access and Least Authorization

The most common entry point for a personal finance assistant is connecting to bank accounts, credit cards, or other payment accounts. From a security perspective, account connection must follow the principle of read-only authorization.

1. Read-only access rather than fund operations

The system should request only the ability to read account information. It should not have capabilities such as transfers, payments, repayments, investments, or changes to account settings.

Even if future product experiences may extend to scenarios such as repayment reminders or bill planning, the underlying system should separate the permission boundary between “reading data” and “executing operations.”

Read-only access typically includes:

• Reading account balances;
• Reading account types;
• Reading account names;
• Reading only the last four digits of account numbers or masked identifiers;
• Reading transaction records;
• Reading billing cycles;
• Reading credit limits or credit information where applicable.

The system should not ask users to provide full card numbers, passwords, payment PINs, or other sensitive credentials beyond what is required for compliant verification. Account connection should use a compliant financial data connection service to complete identity verification and authorization.

2. Minimal authorization scope

When users authorize access, the system should clearly show the read scope. For example:

• Which account types will be read: savings accounts, credit cards, or payment accounts;
• How much historical data will be read: the last three months, the last year, or a longer period;
• Which fields will be read: balances, transaction details, or billing cycles;
• Whether the data will be used for analysis;
• Whether the data will be used for model inference;
• Whether the data will be used for model training.

In data model design, it is recommended to store only the minimum fields required to complete the business task. For example, full merchant names can be masked or hashed, account numbers can retain only the last four digits, and transaction descriptions can be standardized to avoid storing excessive raw sensitive information.

3. Token and access credential management

After authorization is completed, the system usually obtains an access credential or token. Engineering implementation should pay attention to the following points:

• Tokens should have an expiration time;
• Token refresh should have security boundaries;
• Access should stop immediately after the user revokes authorization;
• Related access credentials should be deleted or disabled after account unbinding;
• Logs must not record plaintext sensitive tokens;
• Data between different users must be strictly isolated.

An example authorization state model is shown below:

{
  "user_id": "u_10001",
  "connection_id": "conn_88231",
  "institution_type": "bank",
  "read_only": true,
  "granted_at": "2026-04-01T08:00:00Z",
  "expires_at": "2026-05-01T08:00:00Z",
  "scopes": [
    "account_balance",
    "transactions",
    "billing_cycle"
  ],
  "revoked": false
}

The fields above are illustrative. In a real system, a more fine-grained permission model may be needed according to compliance requirements.

4. Engineering Natural Language Queries

User questions are often vague. Examples include:

• “How much did I spend last month?”
• “Have there been any duplicate charges recently?”
• “Did I spend more this month than last month?”

The system needs to convert these questions into executable data queries.

1. Intent recognition

Common intents include:

• Balance queries;
• Spending summaries;
• Category statistics;
• Time-based trend comparisons;
• Billing calendar queries;
• Unusual charge detection;
• Subscription fee detection;
• Interest or fee calculation;
• Explanation of financial concepts;
• Chart generation.

The model needs to determine whether the user is asking for a factual query, statistical analysis, risk warning, or concept explanation. Different intents correspond to different data processing methods.

For example:

• “How much did I spend this month?” is an amount aggregation request.
• “Why did my food delivery spending increase compared with last month?” is a category comparison analysis request.
• “Are there any duplicate charges?” is an anomaly detection request.
• “What does annual interest rate mean?” is a concept explanation request and should not trigger a transaction query.

2. Slot extraction

After the intent is clear, the system needs to extract key parameters, including:

• Time range: this week, this month, last month, the last three months, or a specified date;
• Account scope: all accounts, a specific account, credit card, or savings account;
• Spending category: dining, transportation, shopping, subscriptions, healthcare, or financial fees;
• Amount threshold: greater than or less than a specified amount;
• Merchant keyword: a specific merchant or merchant type;
• Aggregation method: total amount, average, maximum, share, month-over-month change, or year-over-year change;
• Output format: text, table, chart, or calendar.

An example of structured parameters is shown below:

{
  "intent": "category_spending_summary",
  "entities": {
    "period": "2026-04",
    "account_scope": "all",
    "category": "dining",
    "comparison": "month_over_month",
    "output_format": "chart_and_text"
  }
}

The advantage of this approach is that the model is responsible for interpreting user language, while the business system executes controlled queries. This prevents the model from directly accessing sensitive databases.

3. Query execution and result validation

The system can convert structured parameters into controlled queries. For example, to calculate category spending for a user in a given month:

SELECT category, SUM(amount) AS total_amount
FROM authorized_transactions
WHERE user_id = :user_id
  AND transaction_date >= :start_date
  AND transaction_date <= :end_date
  AND status = 'completed'
GROUP BY category;

The following points require special attention:

• Queries must be bound to the user identity to prevent unauthorized access;
• Only authorized accounts can be read;
• Time boundaries must be clear to avoid cross-month errors;
• Currency must be unified to avoid mixed calculations;
• Transaction statuses such as refunds, cancellations, and reversals need special handling;
• Large aggregate results should undergo sanity checks;
• If data is missing, the system should explicitly state this rather than guess.

4. Model output explanation

After obtaining query results, the model should not rush to give a conclusion. It should first confirm the facts and then generate an explanation. For example:

“Based on the data from your connected accounts, dining spending in April 2026 was 1,280, compared with 980 in March, an increase of about 30.6%. Food delivery orders accounted for about 62%, mainly from multiple small purchases between April 8 and April 20. If needed, I can further break this down by week or by merchant.”

This type of answer includes the time range, data source, amount result, comparison change, possible cause, and follow-up suggestion. It meets the explainability requirements of personal finance analysis.

5. Spending Categorization and Income/Expense Analysis

Spending categorization is one of the most basic and complex modules in a personal finance assistant. Transaction data often comes from different institutions. Merchant names may be abbreviations, codes, payment channel names, or third-party platform names. Direct categorization is therefore prone to error.

1. Designing a categorization system

A relatively general personal spending categorization system may include:

• Dining: dine-in, delivery, coffee, snacks;
• Transportation: public transit, ride-hailing, fuel, parking;
• Shopping: daily necessities, clothing, electronics, e-commerce;
• Housing: rent, utilities, property fees, gas;
• Entertainment: movies, games, memberships, performances;
• Healthcare: medicine, medical examinations, consultations;
• Education: courses, books, training;
• Financial fees: interest, service charges, annual fees, account fees;
• Subscriptions: video, music, cloud services, software memberships;
• Transfers and repayments: repayments, transfers, top-ups;
• Other: transactions that cannot be classified.

The categorization system should be extensible because merchant characteristics vary significantly across regions and payment channels.

2. Combining rule-based and model-assisted categorization

A common practice is “rules first, model assistance second.”

Rule-based categorization can rely on:

• Merchant keywords;
• Merchant category;
• Payment method;
• Amount range;
• Transaction time;
• Historical user correction records.

Model assistance is used for ambiguous cases, such as truncated merchant names, transactions displayed as platform names, or users without historical labels. However, model-generated categories should retain confidence scores and supporting evidence so users can correct them easily.

For example, if a transaction is displayed as “Technology Services – Quick Pay” with an amount of 38.00 and occurs on a weekday around noon, the system could say:

“This transaction may belong to dining or retail. Please confirm. If you often purchase coffee from this merchant, I can classify it as dining.”

3. Monthly income, expense, and balance analysis

Income and expense analysis usually includes:

• Total income;
• Total expenses;
• Category expenses;
• Fixed expenses;
• Variable expenses;
• Monthly balance;
• Month-over-month changes;
• Year-over-year changes;
• Savings rate;
• Share of large expenses.

For credit card accounts, the system also needs to distinguish between spending, repayments, refunds, installments, and fees. Otherwise, repayments may be incorrectly counted as spending, distorting the statistics.

A simplified monthly analysis workflow is as follows:

1. Pull transaction records from authorized accounts;
2. Filter out refunds, cancellations, internal transfers, and other transactions that affect statistical accuracy;
3. Aggregate by spending category;
4. Calculate fixed expenses and flexible expenses;
5. Compare with historical months;
6. Output charts and text conclusions;
7. Provide warnings for unusual fluctuations.

6. Unusual Charge and Risk Detection

An important value of a personal finance assistant is helping users discover issues that are easily overlooked.

1. Duplicate charge detection

Duplicate charges usually appear as follows:

• Same merchant;
• Same or similar amount;
• Close transaction times;
• Same payment channel;
• Same subscription service;
• Two or more identical charges within a short period.

A detection rule can be expressed as follows:

If multiple transactions with the same or similar amount occur within a short time window,
and the transaction channel, item description, or billing cycle is similar,
the system may flag them as "suspected duplicate charges."

However, the model should not directly conclude that a charge is incorrect based only on similarity. Instead, it should prompt the user to verify. For example:

“Two charges of 29.9 from the same merchant were detected on April 12, with a time interval of three minutes. This may be a duplicate charge, a trial-to-paid conversion, or two separate orders. Please check the transaction details before confirming.”

2. Hidden fee detection

Common hidden fees include:

• Automatic membership renewals;
• Subscription price increases;
• Platform service fees;
• Payment processing fees;
• Credit card annual fees;
• Interest charges;
• Late fees;
• Account management fees.

The system can identify subscription behavior through recurring transactions. For example, charges with the same time, same amount, and same or similar merchant every month may indicate a subscription service.

After detection, the system can generate a subscription list. For example:

• Video membership: 25 per month;
• Music membership: 15 per month;
• Cloud storage membership: 128 per year;
• Software subscription: 38 per month;
• Fitness membership: 99 per month.

The system can further calculate the annual subscription cost to help users decide whether to continue paying.

3. Fee increase detection

For recurring bill-type fees, the system can compare historical periods:

• Higher this month than last month;
• Higher this quarter than last quarter;
• Continuous increases for the same merchant;
• Changes in the same plan or package;
• Unusual increases in similar spending categories.

This type of analysis should avoid simple attribution. The model should provide factual evidence. For example:

“Your broadband fee over the last three months was 99, 109, and 129, showing an upward trend. This may be due to a plan adjustment or additional fees. Please check the bill details.”

7. Privacy Protection and Compliance Boundaries

Personal financial data is highly sensitive. The system must consider privacy and compliance from the beginning of the design process.

1. Data isolation

Data for different users must be strictly isolated. Isolation dimensions include:

• User identity;
• Account connections;
• Query requests;
• Cached results;
• Log records;
• Model inference context;
• Chart generation files;
• Exported reports.

Any shared cache, public index, or cross-user analysis must be strictly authorized and masked. Personal financial data must not be directly exposed.

2. Training data boundaries

If the platform provides general large model capabilities, it needs to clearly distinguish between “user financial analysis conversations” and “model training data.”

For sensitive financial conversations, the default recommendation is not to use them for model training unless the user provides separate, explicit, and revocable authorization.

In addition, policy controls need to be implemented across the data pipeline. For example:

• Sensitive fields should not enter training datasets;
• Inference logs should be separated from training data;
• Data should be masked before human annotation;
• Deletion mechanisms should cover storage, cache, logs, and backups;
• Access should stop after account unbinding.

3. Output risk warnings

The model may generate incorrect conclusions, especially for factual content involving amounts, interest, fees, or billing dates. Therefore, the system should remind users to verify the original data.

For example:

“This analysis is based on transaction records from your connected accounts. If there are unsynced, refunded, reversed, or delayed transactions, the results may differ slightly. For important financial decisions, please refer to the official statements provided by your bank or payment institution.”

4. Financial advice boundaries

A personal finance assistant can provide statistics, explanations, risk warnings, and general concept descriptions. However, it should not impersonate a licensed professional advisor to provide personalized investment advice, tax advice, or loan decision conclusions.

If a complex financial decision is involved, the system should guide the user to consult a qualified professional or a regulated financial institution.

The system is more suitable for roles such as:

• Data organization;
• Spending analysis;
• Risk reminders;
• Concept explanation;
• Report generation;
• Decision support.

8. Reliability, Evaluation, and Operations

1. Accuracy evaluation

A financial assistant should not only pursue answers that “sound human.” It must also ensure that answers are accurate. Recommended evaluation metrics include:

• Intent recognition accuracy;
• Parameter extraction accuracy;
• Amount aggregation error rate;
• Categorization accuracy;
• Duplicate charge recall rate;
• Duplicate charge false positive rate;
• Time boundary correctness;
• Correct handling of refunds and reversals;
• Consistency between charts and text conclusions;
• Completeness of cited transaction evidence.

2. Explainability evaluation

Model answers should be able to explain their basis. For example, when a user asks, “Why did my spending increase this month?” the system should provide:

• The comparison months;
• The increased amount;
• The main growth categories;
• Representative transactions;
• Unusual fluctuation warnings;
• The data time range.

If the model cannot provide a basis, it should lower the strength of the conclusion to avoid misleading the user.

3. Caching and asynchronous processing

For high-frequency queries, such as “total spending this month” or “category spending last month,” caching can improve response speed. However, caches must be isolated by user. Sensitive results cannot be reused across users.

For complex analysis, such as annual spending reports, multi-account aggregation, or long-term trend analysis, asynchronous tasks can be used:

1. The user initiates an analysis request;
2. The system checks permissions;
3. The task enters a message queue;
4. The analysis service reads authorized data;
5. The result is written to secure storage;
6. The result is delivered through notification or displayed on a page.

This architecture is suitable for handling large-volume analysis. It also makes failure retries and monitoring alerts easier.

4. Logging and audit

Logs need to record key behaviors but must not record sensitive plaintext. Recommended logs include:

• Who initiated the query and when;
• Which type of account was queried;
• Which authorization scope was used;
• The model intent and parameters;
• A summary of the query result;
• Whether a chart was generated;
• Whether the user made a correction;
• Whether a risk warning was triggered.

Logs should also support auditing and deletion mechanisms to meet privacy management requirements.

9. Typical Application Scenarios

1. Monthly spending summary

The system can generate a personal monthly financial summary, including total spending, category shares, fixed expenses, flexible expenses, month-over-month changes, and anomaly reminders.

2. Subscription management

The system can identify subscription services through recurring transactions and output the annual subscription cost, helping users decide whether to keep, pause, or cancel them.

3. Budget tracking

Users can set category budgets for dining, shopping, transportation, and other categories. The system can then predict the remaining available amount based on spending so far.

For example:

“Your dining budget for this month is 2,000. You have spent 1,280 so far. At the current pace, your dining spending this month may reach about 1,850.”

4. Interest and debt cost analysis

For credit card bills, users may ask about repayment methods, installment fees, or interest costs for a specific purchase. The system can perform calculations based on bill data, but it must remind users that the official statement from the financial institution remains authoritative.

5. Financial health report

The system can generate a personal financial health report across multiple dimensions:

• Savings rate;
• Share of fixed expenses;
• Share of subscription spending;
• Debt pressure;
• Spending volatility;
• Unusual charges;
• Budget execution status.

This type of report is best presented through a combination of charts, summaries, and actionable suggestions.

10. Conclusion: From Intelligent Q&A to a Trustworthy Financial Assistant

The entry of large language models into personal finance management is not simply about replacing bookkeeping functions with a chat window. It is about integrating natural language interaction, data analysis, risk warnings, and visualization into a unified entry point.

The real technical challenge is how to keep the model controllable in sensitive data scenarios. The system must understand user intent without exceeding permissions, provide insights while ensuring explainability, and improve user experience while meeting privacy and compliance requirements.

Therefore, a mature personal finance assistant should have the following characteristics:

• Read-only access, with no fund operation capabilities;
• Minimal authorization, reading only necessary data;
• Controlled queries, preventing the model from directly accessing sensitive data sources;
• Explainable output, with conclusions supported by evidence;
• Risk reminders, without replacing professional financial advice;
• Audit traceability, supporting permission revocation and data deletion;
• Evaluation-driven optimization, continuously improving accuracy and recall.

From an engineering perspective, the key to this type of system is not how “conversational” the model is. The key is whether the data pipeline is secure, whether the business logic is rigorous, and whether the output is trustworthy. Only by embedding model capabilities into a complete financial data governance framework can a personal finance assistant truly evolve from an “intelligent Q&A tool” into a “trusted personal financial analysis entry point.”