Read-Only AI Assistant Architecture for Personal Financial Data

1. Background: From Generic Advice to Account-Level Facts

Early financial Q&A use cases were rarely actionable. The limitation was not the model’s language ability, but the granularity of information: the model could only provide generic advice based on user self-reports. It could not see real balances or verify transaction details.

What users actually need is not inspirational advice such as “how to save money,” but factual answers such as “how much higher was my dining spending this month than last month” or “was this subscription charged twice.”

Making this work is fundamentally a data-access and permission-constraint problem, not a prompt-engineering problem. The following sections describe the architecture by responsibility.

2. Define Capability Boundaries First: What Is Allowed and What Must Never Happen

For any assistant that touches financial data, the first design task is to turn capability boundaries into hard constraints rather than relying on model self-discipline:

• Allowed: account and balance lookup, transaction search and aggregation, spending-category statistics, anomalous-charge flagging, financial-concept explanation, and data-based calculations.
• Forbidden: transfers, payments, repayments, password changes, placing orders, or modifying any account state; selling proprietary credit or savings products; providing personalized investment advice.
• Forbidden on the data side: accessing users’ raw banking credentials, exporting full raw statement files, or building cross-user aggregated profiles.

Once the boundaries are defined, the rest of the architecture is about ensuring they cannot be breached.

3. Overall Architecture: Five Layers with Separated Responsibilities

1. Account aggregation layer. Connect to multiple banks and card issuers through industry-standard account aggregation protocols. The aggregator hosts user credentials and the authorization flow; the assistant side never holds any bank account passwords.
2. Normalized data layer. Unify heterogeneous fields returned by different institutions into three entity types: institution, account, and transaction. Attach a unified category system and metadata for currency and time zone.
3. Tool-calling layer. Package read-only capabilities as structured tools that the model can select, parameterize, and parse results from.
4. Reasoning and conversation layer. Handle intent recognition, multi-turn clarification orchestration, result explanation, and natural-language organization.
5. Security and audit layer. Perform permission validation, field-level masking, full call logging, and anomaly alerts.

Tool declaration is a key implementation point. Example:

{
  "name": "list_transactions",
  "description": "Search transactions by time range, account, merchant, or amount range. This tool only supports querying and does not involve any fund operations.",
  "parameters": {
    "type": "object",
    "properties": {
      "account_ids": { "type": "array", "items": { "type": "string" } },
      "date_from": { "type": "string", "format": "date" },
      "date_to": { "type": "string", "format": "date" },
      "category": { "type": "string" },
      "limit": { "type": "integer", "maximum": 500 }
    },
    "required": ["date_from", "date_to"],
    "additionalProperties": false
  }
}

Two details are easy to overlook:

• additionalProperties: false prevents the model from injecting undefined fields to bypass validation.
• The limit maximum prevents a single request from pulling an entire statement history and expanding the data-exposure surface.

It must also be clear that the schema is only the first line of defense. The server side still needs independent validation, because model output should never be treated as trusted input.

4. Engineering Implementation of Read-Only Access

“Read-only” is not just a declaration. It must be enforced at four levels:

• Field allowlist. The assistant’s visible scope should be strictly limited to institution name, account name and type, last four digits of the account number, current balance, credit limit, and transaction records within a specified time window. Raw account numbers, ID numbers, CVV, and login credentials must never be visible.
• Zero credential retention. Authorization should redirect to the aggregator-hosted page. The assistant side should only receive a short-lived access token with a fixed read-only scope, a short validity period, and a refresh limit.
• Physical isolation at the API layer. Fund-operation APIs should not be connected to the assistant gateway. Even if the model is induced to generate a transfer intent, there should be no callable channel. This is the most reliable layer of protection and takes precedence over prompt hardening.
• Policy-engine review. Tool calls generated by the model should first pass server-side policy checks for account ownership, time range, field set, and call frequency before execution.

Exposing only the last four digits of an account number is an intentional design trade-off. It satisfies the user’s need to confirm “you are looking at my card,” while minimizing identifiable information.

5. Data Normalization: The Real Threshold for Analysis Quality

Many bill-analysis products perform poorly not because of the model, but because of dirty data. At least five types of problems must be handled:

• Merchant-name normalization. The same merchant may appear in different forms across channels. Alias mapping should be built before aggregation.
• Transaction deduplication. Pending and posted transactions often appear in pairs. Installment charges and full charges can also be double-counted.
• Unified billing-period definition. Credit-card data should be analyzed by statement cycle rather than calendar month. Otherwise, answers such as “how much did I spend this month” can be systematically biased.
• Category-system design. A two-level category system is recommended, such as housing, dining, transportation, subscriptions, and fees. Rule-based matching should be used first. The model should only assist with low-confidence items, and tagged results should be sampled for manual review.
• Handling missing and anomalous values. Refunds, adjustments, and cross-currency transactions should be separately flagged and not simply mixed into total spending.

6. Reproducibility Principle: Amounts Must Come from Code, Not the Model

This is one of the most important engineering disciplines for financial assistants: all numerical conclusions should be calculated by deterministic code, while the model is responsible only for explanation, categorization, and language organization. Allowing the model to perform arithmetic directly would produce unacceptable error rates.

def interest_paid(transactions, year: int) -> float:
    total = 0.0
    for t in transactions:
        if t.kind == "interest_charge" and t.posted_at.year == year:
            total += abs(t.amount)
    return round(total, 2)

Typical analysis capabilities and implementation approaches:

• Monthly spending summary and categorization: group by statement cycle and output category shares.
• Month-over-month and year-over-year comparison: compare with the previous cycle and the same period last year, showing absolute amount and percentage changes.
• Duplicate-charge identification: flag multiple matches with the same merchant, same amount, and close timing.
• Unexpected-charge identification: compare against historical patterns and alert when a new merchant type or new recurring fee appears.
• Persistent bill increases: notify when month-over-month spending rises above a threshold for multiple consecutive cycles.
• Concept explanation and calculation: after explaining terms such as annualized interest rate, calculate actual figures such as total interest paid and remaining periods using real data.

Answers should include both the conclusion and the calculation basis. Users can verify the result themselves, which creates much higher trust than presenting an isolated number.

7. Privacy, Compliance, and Trust Design

• Training-data exclusion. Financial conversations and derived data should be excluded from model training sets by default. This should be stated clearly at the product layer, not buried in terms and conditions.
• Retention and deletion. Session data and derived cached data should have a clear retention period. Users should have a one-click option to disconnect and clear historical data.
• Encryption and key management. Data should be encrypted in transit and at rest. Keys should be managed by an independent key-management service, with access subject to least-privilege approval.
• Neutrality statement. Do not run ads, accept sponsored recommendations, or sell proprietary financial products. This avoids the conflict of interest in which analysis conclusions serve sales targets.
• Disclaimer boundary. Explaining concepts and presenting facts is not the same as providing investment or credit advice. For major decisions, the assistant should clearly flag risks and guide users to licensed institutions or human advisors.

8. Canary Rollout and Observability

A tiered canary rollout is recommended. Start with a small amount of traffic for high-value paid users, validate authorization success rates and analysis accuracy, and then expand gradually.

Key metrics to monitor include:

• Account aggregation authorization failure rate
• Tool-call failure and timeout rate
• Number of unauthorized-field-access alerts
• Abnormal query count per session
• End-to-end latency distribution
• User follow-up rate and disconnect rate

The last metric is often a direct signal of privacy concerns.

9. Industry Trend Assessment

General-purpose assistants are increasingly moving into vertical scenarios, and finance is only one of them. A common characteristic of this path is that model capabilities gradually become commoditized, while real differentiation comes from trusted data access, strict permission design, and auditable execution chains.

As personal financial data access becomes more common, regulators are likely to continue tightening requirements around authorization granularity, retention periods, and marketing isolation. Treating “read-only, least necessary, reproducible, and auditable” as default design principles is much less costly than fixing problems after the fact.

10. Deployment Checklist

• Are fund-operation APIs physically isolated at the gateway layer?
• Does the field allowlist cover all institution, account, and transaction response fields?
• Are credentials zero-retention, and are tokens read-only and short-lived?
• Are all amounts calculated by deterministic code with a calculation-basis explanation?
• Are session data excluded from training sets, and is one-click clearing supported?
• Is the product clear about distinguishing factual explanation from professional advice?
• Are canary rollout, monitoring, alerting, and rollback plans complete?