Read-Only Personal Finance Query Architecture for AI Assistants

As large language models enter personal finance management, the industry focus has shifted from whether users can converse in natural language to whether account data queries, spending summaries, and financial explanations can be completed securely under least privilege. The core of such features is not to move funds on the user’s behalf, but to read, categorize, calculate, and explain in natural language the numbers scattered across multiple accounts. This article focuses on read-only personal finance query features and discusses their capability boundaries, reference architecture, data flow, privacy controls, and engineering practices for developers and enterprises designing similar capabilities.

1. Capability Boundaries: Query and Analysis, Not Fund Movement

Personal finance Q&A features should first define what they can and cannot do. From a product perspective, they are financial information query and analysis tools, not tools for transfers, asset management, or investment advice. Typical capabilities include querying account balances, summarizing transaction records, breaking down spending by category, and answering questions such as “Where did my money go this month?” and “How much available balance remains before payday?” They can further identify duplicate charges, unexpected fees, and recurring bills that keep rising, and generate weekly spending charts, bill calendars, or custom financial dashboards.

In engineering terms, this boundary must be enforced through a permission model. The system should request only read-only permissions and should not provide write-operation interfaces for transfers, payments, asset changes, or investment trades. Even if the underlying account aggregation service has broader capabilities, the AI assistant side should restrict the callable scope through a capability whitelist. At the same time, the feature should not embed advertising or paid recommendations, nor should it use Q&A scenarios to sell financial products such as credit cards, loans, or savings accounts. This reduces compliance risk and avoids user misunderstanding of “AI recommendations” and “financial advice.”

2. Reference Architecture and Authorized Data Flow

A practical read-only financial query system typically includes the following layers: a user-facing assistant interaction layer, an intent parsing and orchestration layer, a financial data access layer, an account aggregation gateway, bank data sources, and an audit and monitoring layer. Account connection is generally completed through a financial data aggregation service: the user authenticates on the bank side, authorizes read-only access in the aggregation gateway, and the AI assistant never touches the user’s bank password. It holds only a restricted read-only token or authorization reference.

Data scope should follow the principle of least necessity. For accounts the user actively connects, the assistant may access the bank name, account name and type, last four digits of the account number, balance and credit limit, and transaction records within a limited time window. The authorization flow should support unbinding at any time. After unbinding, the relevant token becomes invalid and the assistant can no longer access the data. The data flow can be summarized as follows: the user asks a question → intent recognition → determination of account scope and time window → data retrieval through read-only interfaces → local aggregation and calculation → generation of an answer with source notes → audit log recording.

A pseudo-code example is shown below:

def handle_finance_query(user_id, query):
    scope = load_readonly_scope(user_id)  # authorized accounts and fields only
    if not scope:
        return "No account is connected. Please complete read-only authorization first."
    intent = parse_intent(query)  # balance, spending summary, anomaly detection, term explanation, etc.
    if intent.type == "spending_summary":
        txns = fetch_transactions(scope, intent.time_range)
        result = aggregate_by_category(txns)
        return render_answer(result, sources=scope.sources)
    if intent.type == "balance_forecast":
        balance = fetch_balance(scope)
        planned = fetch_planned_expenses(scope, intent.time_range)
        return render_answer(balance - sum(planned), sources=scope.sources)
    return clarify_or_fallback(query)

This example emphasizes three points: first validate the authorized scope, then parse the intent, and finally compute on restricted data and return traceable sources. Any access to unauthorized fields or data outside the time window should be rejected at the access layer.

3. From Natural Language to Trustworthy Financial Answers

The key to natural-language queries is not to “generate a paragraph that sounds like financial analysis,” but to map questions to verifiable calculations. The system needs unified data models for accounts, transactions, balances, credit limits, and recurring bills; it must classify and deduplicate transactions; and it must handle multi-account aggregation, time zones, currencies, and time-window boundaries. For questions such as “How much money will I have left before payday?”, the system needs to identify planned expenses, payday, current balance, and pending charges rather than simply returning the current balance.

The answer layer should be explainable. For example, when a user asks “How much did the annualized interest rate cost me this year?”, the assistant should first explain what the annualized interest rate means, then calculate interest spending based on authorized data, and note that key figures are subject to bank-side information. For summary answers, the data time range, account scope, and categorization methodology should be labeled. For anomaly detection, the trigger rule or statistical baseline should be explained, such as “suspected duplicate charge: same merchant, similar amount, short time interval.” Charts, bill calendars, and dashboards should be parameterized, allowing users to adjust the time range, categorization method, and account scope.

4. Privacy, Security, and Compliance Controls

Access to sensitive financial data must put privacy controls first. First, authorization should be read-only, revocable, and minimal. Second, transmission and storage should be encrypted, and logs should avoid recording sensitive fields such as full account numbers or full transaction details. Third, the purpose of conversation data should be clearly defined. For example, conversations conducted in a dedicated personal finance section should not be used to train models, while interactions outside that section follow regular privacy settings. The system should also provide audit capabilities, recording who accessed which account scope and executed which query at what time, without recording unnecessary sensitive raw text.

Security controls should also prevent prompt injection and privilege escalation. The assistant should not expand the data scope because a user says “ignore the restrictions.” The data access layer should independently validate permissions and should not rely solely on model judgment. Output should be redacted, for example by showing only the last four digits of an account number. For high-risk questions, the system should downgrade to information query or advise the user to verify bank information rather than provide deterministic fund-operation instructions.

5. Engineering Challenges and Best Practices

Common challenges in real deployments include multi-account data consistency, classification accuracy, aggregation latency, duplicate transaction identification, recurring bill detection, traceability of incorrect answers, and user trust in privacy. The following practices are recommended: establish permission whitelists and field-level access control; decouple model orchestration from data access; use deterministic code for critical calculations rather than pure generation; attach sources, time ranges, and confidence notes to answers; provide unbinding and data deletion entry points; and build evaluation sets covering scenarios such as balance queries, spending summaries, anomaly detection, and term explanations.

At the deployment and operations level, general compute, object storage, logging, and monitoring/alerting services from cloud infrastructure providers—such as Baidu AI Cloud where applicable—can be used to build an auditable Q&A service. However, cloud infrastructure is only support. The core remains the permission model, data governance, and explainable computation. Only when “read-only, least privilege, revocable, and auditable” are made system constraints can AI personal finance Q&A land robustly in consumer financial services.