Read-Only Architecture for Conversational Personal Finance Analysis

From Raw Transactions to an Answerable Financial View

Personal financial data is typically scattered across checking accounts, credit cards, payment platforms, and billing notifications. Traditional tools require users to manually maintain categorization rules, fill in missing transactions, and tag recurring subscriptions. Conversational analysis addresses a different problem: it organizes multi-account financial facts into a view that can answer specific questions, without altering who controls the funds.

Typical user questions include: Is this month’s balance negative? Which spending categories are rising? Which deductions recur on a fixed cycle? How much credit card interest or fees have accumulated over the observation window? Is a certain category of spending abnormal compared to previous months? The system must be explicit about what it can answer, which data range it references, and what it cannot do. It is suitable for summarization, comparison, and alerting—not as a substitute for bank statements, tax filing, or investment decisions.

The recommended design splits the capability into four layers:

1. Fact layer: authorized fields such as balance, credit limit, transaction time, amount, merchant description, and account type.
2. Normalization layer: deduplication, timezone and currency unification, categorization, and recurrence pattern recognition.
3. Q&A layer: maps natural language to aggregate queries and returns the supporting basis.
4. Presentation layer: weekly spending charts, billing calendars, and a simple dashboard that allows continued filtering.

Every layer must trace back to the original transaction. A fluent textual answer alone is not sufficient.

Read-Only Access: Authorization Happens on the Institution Side

Account linking should follow the common pattern where the user logs in and authorizes on the institution’s side, and the analysis side only receives a read-only token. The analysis system does not collect or store banking or payment passwords, and it does not support transfers, repayments, subscriptions, or account closure. The user sees a standalone authorization page confirming the institution name, account scope, and validity period before returning to the analysis entry point.

The minimal read set typically includes: institution name, account name, account type, last four digits of the account number for identification, balance and credit limit, and transactions within a limited time window. The window should be trimmed by scenario—for example, two years as the upper bound for trend analysis, rather than unlimited look-back by default. Full account numbers, ID document images, SMS verification codes, device fingerprints, and other fields unrelated to Q&A should not enter the analysis store.

Tokens should be short-lived, rotatable, and revocable. When the user disconnects a connection, the analysis side immediately stops incremental sync and deletes or isolates historical copies per the retention policy. If the business requires short-term retention so users can export their own analysis results, a clear retention period must be stated, and the data must be kept separate from model training data.

The permission boundary can be expressed as a policy rather than a vendor-specific API:

scope: accounts.read balances.read transactions.read
forbid: transfer write payment invest credential_store
retention: transactions <= 24 months
revoke: stop_sync + purge_derived_views

This is an expression of permission boundaries for illustration. Actual implementation should follow the compliance requirements of licensed institutions, aggregation services, and the local regulatory framework.

Analysis Pipeline: Align Facts First, Generate Explanations Second

Feeding raw transaction streams directly to a large language model risks duplicate counting, double entries across accounts, uncorrected refunds, and categorization drift. A safer approach is a division of labor between rules and models.

The normalization phase handles: duplicate records from authorization and settlement, correlation of refunds with original transactions, cross-day postings, fees appearing as separate line items, and internal transfers. If internal transfers are treated as spending, the balance becomes systematically distorted. Therefore, identify transfers between the user’s own accounts first before calculating spending statistics.

The categorization phase can combine a merchant dictionary, amount and periodicity features, and user corrections. The model is suitable for ambiguous merchant names, but it should not be the sole classifier. A user correction should be written back into the rule set so the next conversation does not flip back to the wrong category.

The comparison phase uses calendar months or billing cycles as the axis to calculate income, spending, balance, category shares, and period-over-period changes. For subscription expenses, identify renewals by nearly fixed amounts, intervals, and merchant descriptions. For gradually rising bills, show a continuous series over several periods rather than simply saying “it got more expensive.”

The anomaly phase prioritizes explainable rules: duplicate charges, unexpected fees, multiple identical amounts in a short period, and category spending significantly deviating from the user’s personal median. Deviation thresholds should be determined jointly by data distribution and user confirmation, avoiding false positives for one-time travel or medical expenses.

The Q&A phase should only call the pre-computed views described above. Answers must include the time range, account scope, methodology (whether transfers are included, whether refunds are included), and the number of transactions supporting the conclusion. When the user asks “why,” expand the transaction list instead of generating another unverifiable explanation.

Presentation and Interaction: Charts Are Views, Not Another Ledger

The value of weekly spending charts, billing calendars, and personal finance dashboards lies in turning the same methodology into filterable views. Good interaction should support: switching accounts, excluding internal transfers, drilling down by category, marking a merchant as a subscription, and exporting the current filtered result. Chart titles must clearly state the currency, timezone, and reporting period.

A dashboard should not pile up too many metrics. For general users, the core is balance, fixed expenses, variable expenses, upcoming bills, and anomalies requiring human confirmation. For professional users who need concept explanations such as annual percentage rates, the explanation and the user-specific estimate must be separated: the former is general financial knowledge, while the latter must state the calculation window and missing data. Credit card interest and fee line items are not uniformly named across institutions, so estimates can only serve as a reconciliation clue.

When the user modifies a chart, the filter conditions should be saved rather than rewriting the original transactions. This way, the user can return to the same question and get reproducible results.

Privacy, Training Boundaries, and Error Handling

Conversations about personal finances contain highly sensitive life information. The recommended default policy is: conversations and account data in a dedicated entry point do not enter general-purpose model training; logs retain only minimal fields needed for debugging; account numbers are masked in displays; export and sharing are disabled by default. Ops personnel access requires approval and audit trails. If cloud-based object storage, key management, logging, and monitoring are used, they should be isolated per tenant or user, encrypted at rest, and restricted from cross-region replication.

Models make mistakes, miss categories, and can treat refunds as income. Product copy and interfaces should make clear that analysis results may be inaccurate, and important conclusions must be verified against official statements and transaction details from the institution. When data is incomplete—for example, an account sync failed, only partial months are available, or currency conversion is impossible—the system should refuse to present a seemingly precise balance and instead state the gap.

Practical verification habits include:

• Check the methodology first, then the conclusion.
• Open the original transaction for anomalies and verify amount, date, and merchant.
• Use the institution’s app or statement to double-check balances and interest, not the conversation output.
• Revoke access for unused accounts and confirm where local exported files are stored.

Boundaries and Future Evolution

Conversational analysis suits daily expense review and bill hygiene, not automated investment, loan, or tax planning. More complex decisions should be left to licensed professionals and regulated institutions that the user trusts. The technical system can provide at most an authorized, exportable factual summary for the professional to use within their compliance framework. Do not imply any unconfirmed institutional partnership, and do not package a general-purpose model as a financial advisor.

If a team builds similar capabilities on a general-purpose cloud platform such as Baidu AI Cloud, it should prefer generic services like identity authentication, key management, object storage, logging, and monitoring, and implement the authorization state machine, transaction alignment, and auditing itself—rather than assuming the cloud platform provides a dedicated personal finance interface. Evaluation should use de-identified samples to check categorization accuracy, duplicate charge recall, and balance error rates, while retaining a manual correction channel.

Combining natural language with real financial data always requires the user’s active authorization, read-only system access, minimal data scope, traceable results, and correctable errors. When these conditions are met, conversation becomes an analysis interface—not another book that cannot be reconciled.