AI Personal Finance Assistant: Read-Only Queries and Privacy Boundaries

An AI assistant for personal finance should not be designed to replace users in managing their money. Its core role is to help users understand where their money is going. When large language models enter consumer financial services, the most important thing for technical teams to redefine is not the feature list, but the boundaries around permissions, data, and responsibility.

The original requirements can be abstracted into the following capabilities: users can ask natural language questions about account balances, transaction records, spending structure, recurring bills, disposable balance, and possible abnormal charges. The system itself does not transfer funds, operate accounts, provide investment advice, or sell financial products. This design means the system must be built around four principles: read-only, explainable, revocable, and auditable.

1. Capability Positioning: From Information Aggregation to Trustworthy Insights

The first capability is account connection and balance query. After user authorization, the assistant can aggregate balances from multiple bank accounts and answer conversational questions such as “How much available money do I have right now?” or “How much credit limit is left on my credit card this billing cycle?”

Because different accounts may have different data structures, the system needs to abstract bank accounts, credit card accounts, savings accounts, and other account types into a unified data model before generating user-readable answers.

The second capability is spending summary and category analysis. Users often ask questions such as “Where did my money go this month?”, “Which spending category increased the fastest?”, or “How much did I spend on rent, dining, and transportation?” These questions require the system not only to read transaction records, but also to divide time windows, identify merchants, map spending categories, and aggregate amounts.

For example, monthly spending can be divided into fixed expenses, flexible expenses, subscription expenses, and temporary expenses. Fixed expenses can be further divided into rent, utilities, property fees, telecommunications, insurance, and similar items. Flexible expenses can be divided into dining, shopping, transportation, entertainment, and similar items.

The third capability is budget awareness and available balance estimation. Users may ask, “How much can I still spend before payday?” or “After accounting for planned bills, how much available money is left in my account?” Answering these questions requires combining account balances, incurred spending, pending deductions, recurring bills, and salary dates. This is not simple balance display; it is a rolling calculation based on multiple account data sources.

The fourth capability is anomaly identification and bill explanation. The system can identify cases such as duplicate charges, unexpected fees, unusual increases in recurring bills, and repeated subscription renewals, then explain them to the user in natural language.

For example, when a recurring bill is higher than last month, the assistant can point out the increase, the historical average, the most recent charge time, and suggest that the user verify the original bill through the bank channel.

The fifth capability is financial terminology explanation. Users may not fully understand concepts such as annual interest rate, billing cycle, minimum payment, credit limit, interest-free period, or late fees. The assistant can explain terminology first and then provide the numerical answer, helping users avoid misinterpretation.

2. System Architecture: From Authorization and Data to Dialogue Output

A compliant personal finance assistant system can usually be divided into six layers: account access layer, authorization control layer, data governance layer, analysis and calculation layer, dialogue interaction layer, and security audit layer.

The account access layer is responsible for connecting to bank accounts or aggregated data services and obtaining data such as balances, transaction records, and basic account information.

The authorization control layer confirms that the user has actively authorized access and limits the permission scope.

The data governance layer handles field standardization, transaction cleaning, duplicate data identification, and time-window normalization.

The analysis and calculation layer generates spending summaries, budget estimates, anomaly detection results, and metric explanations.

The dialogue interaction layer understands user natural language questions and converts analysis results into explainable answers.

The security audit layer records access behavior, permission changes, data exports, and abnormal calls, ensuring that every data read can be traced.

A simplified permission model can be represented as follows:

{
  "account_scope": [
    "balance",
    "account_type",
    "last_four_digits",
    "transaction_history"
  ],
  "operation_scope": [
    "query"
  ],
  "forbidden_actions": [
    "transfer",
    "payment",
    "investment",
    "account_creation"
  ],
  "history_window": "not exceeding the authorization period",
  "revocation": "user can revoke at any time"
}

The most important field here is forbidden_actions. A personal finance assistant must explicitly exclude fund operation capabilities. Even if the product form expands in the future, the system should ensure through permission checks, service isolation, and audit mechanisms that the read-only principle is not broken.

3. Account Connection and Data Scope Design

Account connection usually relies on the user actively logging in to a bank page or authorization page to complete identity verification. The authorization service then returns a controlled access credential. The assistant should not access sensitive credentials such as the user’s bank card password, online banking password, or SMS verification code.

The system should request read-only query permissions, and the field scope should be minimized as much as possible.

Suitable data fields for access may include bank name, account name, account type, last four digits of the account number, current balance, credit limit, available credit, transaction time, transaction amount, merchant name, transaction summary, billing cycle, repayment status, and similar information.

For fields with higher privacy risk, such as full card number, ID number, contact information, and address information, the system should not read, store, or display them by default unless there is a clear business necessity.

Historical data scope should also be limited. A common design is to query only the most recent one or two years of transaction records, and to stop access immediately after the user revokes authorization.

Unlinking is not merely a front-end toggle. It should be a combination of backend credential invalidation, cache invalidation, index deletion, and audit record archiving.

From an engineering perspective, the authorization lifecycle can be abstracted as follows:

Connection request initiated -> User authentication -> Permission confirmation
        |                         |
        v                         v
Authorization active          User cancels
        |
        v
Data queryable
        |
        v
User revokes authorization -> Permission invalidated -> Data not queryable

Every query request should carry authorization context, and the server should verify that the current authorization is still valid. Even if the front-end interface shows that the account is connected, the backend must check the credential status in real time to prevent expired authorization from continuing to be used.

4. Spending Analysis: From Transaction Records to User-Readable Conclusions

The first step in spending analysis is transaction cleaning. Transaction records returned by banks may contain duplicates, reversals, cancellations, inconsistent currencies, non-standard merchant names, and other issues. The system needs to establish a unified transaction data model and convert raw records into standardized objects.

An illustrative transaction object may contain the following fields:

{
  "transaction_id": "internal unique identifier",
  "account_id": "internal account identifier",
  "occurred_at": "transaction occurrence time",
  "posted_at": "posting time",
  "amount": 100.00,
  "currency": "normalized currency",
  "direction": "expense or income",
  "merchant": "normalized merchant name",
  "category": "spending category",
  "status": "success, pending, cancelled, or reversal"
}

For classification, a strategy of “rules first, model supplement” can be used. Fixed expenses, utility payments, rent, telecommunications fees, and similar items can be identified through merchant keywords or bill type rules. Dining, retail, transportation, and similar categories can be mapped through merchant category codes.

For transactions that cannot be clearly classified, the system can place them under “Other spending” and prompt the user to refine them later.

Spending summaries should answer not only “how much was spent”, but also “where the money went”. For example, a user may ask:

What were my main expenses this month?

The system can answer with three layers:

Total spending this month was CNY 4,309.37.
Fixed expenses such as rent and utilities accounted for more than 50%.
Dining expenses were CNY 1,024.51, higher than last month.

If the user continues to ask:

How much can I still spend before payday?

The system needs to estimate available balance. A simplified logic is as follows:

Available balance = current account balance - identified pending deductions
                    - planned future expenses - minimum safety buffer

Illustrative code:

def estimate_available_balance(account, pending_items, buffer_amount):
    current_balance = account.balance
    reserved = sum(item.amount for item in pending_items if item.status == "pending")
    planned = sum(item.amount for item in pending_items if item.status == "planned")
    available = current_balance - reserved - planned - buffer_amount
    return round(max(available, 0), 2)

A special point should be noted here: available balance estimation is not financial forecasting. It is an estimate based on existing data. The system should clearly state in its answer that the value depends on currently read account data and may change with new transactions or changes in pending deduction status.

5. Natural Language Question Answering: Intent Recognition and Answer Orchestration

Users do not ask questions in structured fields, so the dialogue system needs to convert natural language into query intent. Common intents include balance query, spending summary, category query, time range query, bill explanation, anomaly identification, terminology explanation, and budget estimation.

For example:

Where did my money go this month?

The system needs to recognize:

intent = spend_analysis
time_range = current_month
output_type = category_summary

Another example:

How much can I still spend on my credit card this month?

The system needs to recognize:

intent = credit_limit_check
account_type = credit_card
output_type = available_credit

For questions whose intent cannot be confirmed, the system should proactively clarify rather than force a conclusion. For example, if the user says:

How was I doing last month?

The system can ask back:

Do you want to check last month’s total spending, category spending, account balance changes, or the bill for a specific card?

Answer generation should follow the structure of “conclusion first, data support second, boundary reminder third”. A recommended format is:

Conclusion: This month’s spending is mainly concentrated in rent and dining.
Data: Rent and utilities together account for more than half of spending, and dining expenses are CNY 1,024.51.
Reminder: This conclusion is based on connected account data. Please refer to bank information for the final statement.

This answer format improves user experience while reducing the risk of misunderstanding.

6. Anomaly Bill Identification: Combining Rules and Statistical Models

Anomaly identification is an important value point for a personal finance assistant, but it is also the area most prone to false positives. Careful design is therefore required.

Common anomaly types include:

1. Duplicate charges: multiple charges from the same merchant for the same amount within a short period.
2. Unexpected fees: high-frequency fees appearing for the first time, or spending at unfamiliar merchants.
3. Recurring bill increases: noticeable amount growth within the same service billing cycle.
4. Continuous subscription charges: multiple small subscription charges occurring repeatedly within a short period.
5. Large abnormal expenses: single transactions that are significantly higher than the user’s historical spending habits.

A rule engine can cover clear patterns. For example, if the same merchant charges the same amount twice within 24 hours and the user has no clear operation record, the system can prompt “suspected duplicate charge”.

Statistical models can identify relative anomalies. For example, a certain spending category may be significantly higher than the average of the past three months.

Anomaly prompts should avoid making direct conclusions and should instead use expressions such as “suspected”, “recommended for verification”, or “can be checked further”. An example answer is:

The system found that a subscription service charged about 35% more this billing cycle than the average amount over the past three months.
This may be caused by a plan change, added services, or bill adjustment.
It is recommended to further confirm through the bank transaction record or merchant bill.

This approach provides insight while avoiding unverified assertions.

7. Privacy and Security: Read-Only Mode Must Be Implemented in System Details

The sensitivity of personal financial data means privacy protection cannot remain only in product copy. The system needs to implement security controls at multiple levels.

First is data minimization. Only account and transaction fields necessary to answer questions should be read. Irrelevant information should not be read by default.

Second is session isolation. Conversation content generated within a dedicated financial Q&A area should be isolated from general conversation data by default, and policies can exclude it from general model training. After the user revokes authorization, related data access should become invalid immediately.

Third is encryption and masking. Data transmission should use secure channels, and sensitive fields should be encrypted on the storage side. The display layer should preferably show only the last four digits of the account number, merchant summary, amount, and time. It should not display full card numbers, full ID numbers, or sensitive verification information.

Logs and auditing are also critical. The system should record information such as:

Who initiated the query and when?
Which accounts were queried?
Which fields were accessed?
Was data export triggered?
Were there high-frequency or abnormal calls?

If a prototype system is built using a general-purpose cloud platform such as Baidu AI Cloud, common capabilities such as log auditing, key management, monitoring alerts, and object storage can be incorporated into the overall solution. However, the financial business itself still needs independently designed authorization flows, data permission models, and compliance assessment mechanisms. Security boundaries should not be simply outsourced to infrastructure.

8. Compliance Boundaries: No Fund Operations, No Misleading Decisions

The compliance boundaries of a personal finance assistant should be written into product principles and technical constraints. These should include at least the following:

1. Do not provide entry points for fund operations such as transfers, payments, repayments, or investments.
2. Do not sell credit cards, loans, deposits, or other financial products based on conversation content.
3. Do not embed paid recommendations or commercial ranking in answers.
4. Do not treat AI answers as equivalent to bank statements, official transaction records, or audit conclusions.
5. For key numerical values, remind users to refer to the bank’s original information.
6. Keep terminology explanations neutral and avoid inducing users to make financial decisions.

When users ask “Should I repay this loan?” or “Is this money suitable for investment?”, the system should clearly state that it can only provide bill query and information explanation, and cannot provide personalized financial advice. The answer can be changed to:

I can help you check the current bill, interest rate, repayment plan, and cash flow changes.
However, whether to repay early or how to allocate funds depends on your personal risk tolerance and the bank contract.

This kind of boundary expression protects both users and the platform.

9. Evaluation and Quality Assurance

A personal finance assistant cannot be launched based only on functional demonstrations. An evaluation system is also needed.

Evaluation dimensions can include:

• Intent recognition accuracy: whether the system correctly understands user questions.
• Data consistency: whether the same question returns consistent results based on the same authorized data at different times.
• Numerical calculation accuracy: whether amount summaries, percentages, available balance estimates, and other calculations are correct.
• Refusal and clarification rate: whether the system proactively clarifies when it cannot answer.
• Anomaly identification false positive rate: whether the system interrupts users too frequently.
• User correction rate: whether users need to repeatedly ask questions to understand results.
• Security and compliance checks: whether unauthorized reading, unauthorized display, or fund operation entry points exist.

Test data should cover multiple accounts, multiple currencies, duplicate transactions, reversal transactions, pending deductions, long-term inactive accounts, zero-balance accounts, frequently cancelled subscriptions, and other scenarios. For anomaly identification, historical real cases and manually labeled samples should also be introduced to avoid rules that are too broad or too narrow.

10. Implementation Advice: Read-Only First, Then Explanation, Then Insight

From a product evolution perspective, a personal finance assistant can be built in phases.

The first phase should focus only on read-only account connection and balance query, ensuring that the authorization chain is stable.

The second phase can add spending classification, bill summaries, and visual explanations.

The third phase can introduce anomaly identification, budget estimation, and trend analysis.

Each phase should focus on three goals: users can understand, the system can explain, and responsibility can be defined.

For engineering implementation, it is recommended to first establish a unified account model, a unified transaction model, and a unified permission model. Complex financial logic should not be scattered across dialogue code from the beginning, because this will make future maintenance difficult.

The dialogue layer should only handle intent understanding, parameter completion, and answer orchestration. Core calculations should be completed by an independent analysis service.

Ultimately, the value of an AI personal finance assistant is not to make decisions for users. It is to transform financial information scattered across multiple accounts into structured insights that users can understand, ask about clearly, and verify with evidence.

As long as the system maintains read-only permissions, minimal data usage, transparent explanations, and clear boundaries, this type of application can become an effective assistant for personal financial management under safe and controllable conditions.