Conversational Personal Finance Assistants: Technical Architecture and Engineering Practices

As large language models and structured data analysis continue to converge, personal finance management is shifting from manual bookkeeping, spreadsheet exports, and transaction-by-transaction reconciliation to simply connecting accounts and asking questions in natural language.

The core of such a system is not allowing a model to “do the math” on behalf of the user. Instead, it is building an auditable engineering pipeline that connects account authorization, transaction aggregation, standardized categorization, deterministic calculations, anomaly detection, and explainable presentation. This article uses the conversational personal finance assistant as a general example to examine its architecture, key capabilities, and practical implementation considerations.

1. Capabilities and System Boundaries

A conversational personal finance assistant typically provides the following capabilities:

• Summarizing balances and transactions across connected accounts
• Aggregating spending by category
• Comparing income and expenses across multiple months
• Identifying recurring subscriptions, duplicate charges, unusual fees, and rising bills
• Answering questions such as “Am I spending more than I earn this month?” or “How much interest did I pay over the past year?”
• Generating weekly spending charts, bill calendars, or personal finance dashboards based on user requests

The system boundary must be explicit. The assistant should primarily support read-only analysis. It should not directly initiate payments or transfers, or modify account data.

Financial calculations should be implemented through deterministic rules and structured queries. The model’s main responsibilities should be intent understanding, query orchestration, and result explanation. Every conclusion should be traceable to its data sources, time range, and calculation method.

For concepts such as interest rates and fees, the model can provide plain-language explanations. However, any specific monetary amount must be produced by logic that can be independently recomputed.

2. A Layered Architecture: From Account Connections to Conversation

A five-layer architecture is a practical starting point:

1. Connection layer: Handles account authorization, token management, synchronization jobs, and authorization revocation.
2. Aggregation layer: Retrieves account and transaction data, then performs cleaning, deduplication, merchant normalization, and category mapping.
3. Analysis layer: Provides deterministic services for balance analysis, income and expense calculations, category analysis, recurring transaction detection, interest estimation, and anomaly detection.
4. Conversation layer: Interprets natural-language intent, generates query plans, calls analysis services, and organizes explanations.
5. Presentation layer: Produces text, tables, chart specifications, and dashboard configurations, while supporting iterative adjustments.

The key architectural principle is to decouple model generation from data computation. The model should not directly access raw account credentials, nor should it invent monetary values. The analysis layer should expose capabilities through controlled functions or query services, while the conversation layer selects and composes those capabilities.

3. Account Connections and Data Synchronization

Account connections should use standard authorization protocols and follow the principle of least privilege. The system should request only the permissions required for read-only access to balances and transactions.

Tokens must be encrypted at rest, isolated by tenant, and revocable by the user at any time. Synchronization jobs should support:

• Incremental data retrieval
• Failure retries
• Idempotent writes
• Out-of-order event handling

The same transaction may appear multiple times during repeated synchronization, so the system must use a stable business key for deduplication.

A transaction data model might look like this:

Transaction {
  id
  account_id
  posted_at
  amount
  currency
  merchant_raw
  merchant_normalized
  category_l1
  category_l2
  is_recurring
  source_hash
}

Here, source_hash supports idempotent deduplication, while merchant_normalized enables merchant-level aggregation. Category fields should retain both the rule version and the model version so that classification changes can be traced later.

The synchronization pipeline should also record data freshness. Otherwise, a user asking for the “current balance” could receive an answer based on stale information.

4. Transaction Normalization and Categorization

Raw transaction descriptions often contain merchant identifiers, channel information, and abbreviations. They should be cleaned before classification.

A practical engineering approach combines rules, models, and user feedback:

• Use rules for frequent merchants and clear keywords.
• Use text classification for long-tail merchants.
• Feed user corrections back into the system as labeled feedback data.

The category hierarchy should not be unnecessarily granular. First-level categories should remain stable, while second-level categories can be extended over time. The system should also preserve special types such as Uncategorized, Transfer, and Income. Otherwise, transfers between a user’s own accounts may be incorrectly counted as spending.

Classification results should be explainable. Users should be able to see why a transaction was assigned to a category and manually correct the result.

For income and expense analysis, the system must distinguish among spending, refunds, transfers, repayments, and interest charges. Failing to do so can introduce systematic errors into balance calculations.

5. From Natural-Language Questions to Structured Analysis

A natural-language query should pass through intent recognition, entity extraction, query planning, data retrieval, calculation, and explanation generation.

An illustrative pseudocode flow is shown below:

plan = parse_intent(query)
plan.accounts = resolve_accounts(plan.entities)
plan.time_range = resolve_time_range(plan.entities)
if plan.intent == "category_spend":
    data = analyze_category_spend(plan.accounts, plan.time_range)
elif plan.intent == "monthly_balance":
    data = analyze_balance(plan.accounts, plan.time_range)
elif plan.intent == "recurring_detection":
    data = detect_recurring(plan.accounts, plan.time_range)
else:
    data = ask_clarification(plan)
answer = render_explanation(plan, data, sources=data.sources)

This workflow emphasizes three principles:

1. Clarify ambiguity: Expressions such as “the past three months” should be resolved into explicit start and end dates.
2. Delegate calculations to analysis services: Monetary calculations should not depend on mental arithmetic performed by the model.
3. Expose context in the response: Answers should include the time range, account scope, and data freshness timestamp.

For a question such as “Am I spending more than I earn?”, the system should define whether the calculation means income minus essential expenses or income minus all expenses. The selected definition must be displayed clearly to avoid misleading the user.

6. Detecting Duplicate Charges, Rising Fees, and Subscriptions

Duplicate-charge detection can combine several signals:

• Normalized merchant
• Exact or similar transaction amounts
• Time window
• Transaction type
• Historical periodicity

If two transactions involve the same merchant and the same amount within a short time window, and they do not match a known recurring bill, the system can mark them as possible duplicates. It should present the supporting evidence and allow the user to dismiss the alert.

Rising-fee detection can model recurring transactions as time series and compare the latest amount with the historical median or the previous billing cycle. If the difference exceeds a configured threshold, the system can issue an alert.

Subscription detection can combine fixed billing intervals, consistent merchants, and relatively stable amounts. The resulting subscription list may include the next expected charge date and an annual spending estimate.

The main challenge in anomaly detection is controlling false positives. Alerts should be classified into levels such as:

• Confirmed anomaly
• Possible anomaly
• For reference only

Users should have a way to provide feedback. The model can explain why an anomaly was flagged, but the detection itself should be implemented through configurable rules and statistical methods.

7. Visualization and Dashboards

The model should not generate arbitrary executable code directly for charts. Instead, it should produce a controlled chart specification containing elements such as:

• Chart type
• Dimensions
• Metrics
• Time range
• Filter conditions

The frontend can then render the specification through predefined templates. This approach supports weekly spending charts, bill calendars, and personal finance dashboards while improving security and consistency.

Dashboards should support follow-up adjustments, including switching accounts, changing time granularity, and drilling into categories. Each adjustment should preserve the corresponding query plan so that the result can be reproduced.

8. Security, Compliance, and Privacy

Personal financial data is highly sensitive. The system should provide:

• Encryption in transit and at rest
• Tenant isolation
• Least-privilege access
• Access auditing
• Data-retention policies
• Data deletion mechanisms

Users should be able to review connected accounts, revoke authorization, export their data, and delete it.

The conversation layer must also defend against prompt injection through untrusted text, such as transaction descriptions or merchant notes. Transaction data should be treated as data, not as instructions.

When presenting information externally, the system should avoid exposing full account numbers. Only necessary account suffixes and aggregated results should be displayed.

For cloud deployments, general-purpose capabilities such as object storage, message queues, logging, monitoring, and alerting can be provided by platforms including Baidu AI Cloud. Specific services should be selected according to compliance requirements, cost, and operational constraints.

9. Engineering Rollout and Evaluation

A practical rollout can proceed in stages:

1. Start with read-only aggregation and three high-frequency queries: balances, spending by category, and monthly net balance.
2. Add subscription detection and anomaly alerts.
3. Introduce visualization and dashboard capabilities.

Evaluation should cover:

• Intent recognition accuracy
• Query-plan correctness
• Consistency of monetary recomputation
• False-positive rates for anomaly detection
• Response latency
• Data freshness

A regression test set should include ambiguous questions, month-boundary cases, refunds, transfers, multiple currencies, and revoked authorizations.

Large-model output should be constrained with structured formats and supported by human fallback procedures. Every monetary conclusion must remain reproducible, explainable, and auditable.

Overall, the value of a conversational personal finance assistant is to lower the barrier to financial analysis, not to replace financial facts. A trustworthy system needs secure account connections as its entry point, standardized data as its foundation, deterministic calculations at its core, and explainable conversation as its interface.