Personal Finance Assistant with Large Language Models: Architecture and Security Practices

From Conversation to Financial Analysis: A High-Value LLM Scenario

Large language models are moving from being simple question-and-answer tools toward becoming systems that can understand data and support decision-making. Personal financial management is one of the high-value scenarios in this shift.

In traditional workflows, users often need to switch between multiple banking and credit card applications, manually aggregate statements, reconcile transactions, and calculate disposable balances. This process can be tedious and error-prone.

When an LLM is introduced into this scenario, users can ask questions in everyday language, such as:

• “Where did my money go this month?”
• “How much can I still spend before payday?”
• “How much interest have I paid this year?”

The model is responsible for pulling data across accounts, breaking it down by category, calculating key metrics, and explaining the results in natural language. The core value is to transform fragmented, heterogeneous, and jargon-heavy financial data into answers that ordinary users can directly understand.

However, financial data is highly sensitive. Poor design can lead to privacy leaks, and model hallucinations can mislead users into making important financial decisions. Therefore, the technical challenge of this type of system is not whether it can answer questions, but how to answer safely, compliantly, and controllably.

Core Positioning: Understand Numbers, Do Not Move Money

A mature personal finance assistant must first establish a clear boundary at both the product and technical levels: it should only read and analyze data, not touch funds.

Specifically, the capabilities and prohibited behaviors of the system can be defined as follows:

• Allowed: read balances, transaction records, and credit limits; aggregate data across accounts; break down spending by category; identify anomalies; generate charts and dashboards; explain financial terms.
• Prohibited: initiate transfers, execute payments, buy or sell assets, modify any account settings, or perform any fund operations on behalf of the user.

This boundary is not only a product positioning statement. It must also be implemented in the technical design. During the permission request stage, the system should request only read-only scopes, eliminating write capability at the API level.

An illustrative permission design is as follows:

{
  "consent": {
    "scopes": [
      "accounts:read",
      "balances:read",
      "transactions:read",
      "identity:read"
    ],
    "mode": "read_only",
    "expires_in_days": 90,
    "revocable": true
  }
}

Notice that this example does not include any write scopes such as *:write, payment:initiate, or transfer:create. When write capability does not exist at the source, even if the model makes a judgment error or is manipulated, it cannot cause actual fund-level operations. This is one of the most reliable parts of a defense-in-depth strategy.

Account Connection: Authorization Instead of Password Custody

A personal finance assistant needs access to banking data, but it should never ask users for their bank login passwords.

The common industry approach is to introduce a financial data aggregation service, aligned with the Open Banking paradigm. The user completes identity verification directly with the aggregation service, and the service then grants limited access to the assistant through tokens.

A typical authorization flow is as follows:

1. The user initiates “Connect Account” in the assistant. The system generates an authorization request and redirects the user to the aggregation service.
2. The user enters bank credentials on a hosted page provided by the aggregation service and completes multi-factor authentication. The credentials do not pass through the assistant, so the model provider cannot obtain the password.
3. The aggregation service returns a limited access token and a refresh token. The scope is strictly limited to read-only permissions.
4. The assistant uses the token to retrieve account and transaction data through standard interfaces. The token expires when it reaches its expiration time or when the user unlinks the account.

The significance of this design is that it moves the “trust boundary” from the assistant system itself to a regulated aggregation service. Credential custody, identity verification, token issuance, and revocation are handled by a specialized institution, while the assistant system acts only as a data consumer.

An illustrative implementation of token exchange and account disconnection is shown below:

def connect_account(user_id, public_token):
    # Exchange a one-time public token for a restricted access token through the aggregation service
    # Key point: request read-only scopes and do not request any write scopes
    access = aggregator.exchange_token(
        public_token=public_token,
        scopes=["accounts:read", "balances:read", "transactions:read"]
    )
    store_token_encrypted(user_id, access)  # Tokens must be stored encrypted
    return fetch_accounts(access)
def disconnect_account(user_id, access_token):
    # Revoke the token immediately after disconnection
    # After revocation, the model side immediately loses access to data
    aggregator.revoke(access_token)
    purge_local_data(user_id)               # Also clear locally cached data

Data Scope and the Minimization Principle

After authorization, the data that the system can access should follow the data minimization principle: only obtain the fields necessary to complete the user’s request.

A reasonable field list may include:

• Account metadata: institution name, account name, account type, and the last four digits of the account number.
• Balance information: current balance, available balance, and credit limit.
• Transaction details: time, amount, merchant, and category. Transaction history is typically retained for up to about two years.

Two points require special attention.

First, only the last four digits of the account number should be retained. Full card numbers, passwords, CVV codes, and similar sensitive information should not be retrieved or stored.

Second, historical data retention should have a clear upper limit, such as two years. Data beyond the retention period should be automatically archived or deleted. This helps avoid the compliance and security risks that come from long-term storage of sensitive information.

At the storage level, the system should meet the following requirements:

• Encryption at rest: tokens and transaction data should be encrypted when persisted.
• Encryption in transit: the full data path should use TLS.
• Access isolation: tenant-level isolation should be applied on a per-user basis.
• Masking: sensitive fields should be displayed in masked form.

Natural-Language Analysis and Anomaly Detection Pipeline

A user’s natural-language question is processed through a complete pipeline. The pipeline can be abstracted into the following stages:

1. Intent recognition and entity extraction: convert a request such as “How much do I have left before payday?” into “Calculate the disposable balance before a specific date.”
2. Data retrieval: based on the parsed time range and account scope, retrieve the relevant transactions and balances.
3. Calculation and analysis: aggregate data by category, subtract planned expenses, and calculate metrics such as interest or proportions.
4. Result organization and explanation: present the conclusion in natural language, and explain professional terms before using them in calculations.

For example, if a user asks, “Where did my money go this month?”, the pipeline can aggregate transactions across accounts for the current month, break them down by categories such as rent, utilities, and dining, and provide the total amount and structural proportions.

For questions involving technical terms, such as “How much have I spent on my annual interest rate this year?”, the model should first explain what APR, or Annual Percentage Rate, means, and then calculate the interest expense based on actual balances and rates. This helps prevent users from misinterpreting results because they do not understand the terminology.

Anomaly detection is another high-value capability. It can cover cases such as:

• Duplicate charges: multiple charges from the same merchant with similar amounts within a short period.
• Unexpected fees: newly added subscription fees or service charges with abnormal amounts.
• Increasing bills: recurring bills that continue to rise month over month.

An illustrative implementation combining rule-based checks and statistical analysis is shown below:

def detect_anomalies(transactions):
    anomalies = []
    # 1. Duplicate charges: same merchant + same amount + multiple times within 24 hours
    grouped = group_by(transactions, key=lambda t: (t.merchant, t.amount))
    for _, group in grouped.items():
        if len(group) >= 2 and within_hours(group, 24):
            anomalies.append({"type": "duplicate_charge", "items": group})
    # 2. Recurring bill increase: compare month over month and flag increases above a threshold
    for bill in identify_recurring(transactions):
        if mom_increase(bill) > 0.15:  # Month-over-month increase above 15%
            anomalies.append({"type": "bill_increase", "bill": bill})
    return anomalies

It is important to emphasize that all conclusions involving monetary amounts should include a disclaimer: “For reference only. Please refer to official bank data.” Model outputs may contain calculation errors or delayed data. The interface must remind users to verify authoritative sources. This is a basic requirement for preventing misleading conclusions.

Privacy and Model Training Isolation

Financial data must never be used to train general-purpose models. This is a non-negotiable red line for this type of system.

A reasonable design should implement spatial isolation: conversations and data generated inside a dedicated “financial zone” must be clearly excluded from the model training corpus. General conversations outside that zone should follow the user’s existing privacy settings.

Supporting privacy controls include:

• Training isolation: data in the financial zone is labeled as “not to be used for training” and is strictly filtered out in the data pipeline.
• Instant disconnection: users can unlink their accounts at any time. After disconnection, the token is immediately revoked, cached data is cleared, and the model side can no longer access the data.
• Minimal retention: conversations and data should have defined retention periods and be automatically cleaned up when they expire.
• Auditability: all access to sensitive data should leave audit logs, making compliance audits and abnormal behavior tracing easier.

At the implementation level, general cloud capabilities can be used to build an observable and governable data pipeline:

• Use object storage to store encrypted historical data and configure lifecycle policies for automatic cleanup.
• Use logging services to record access behavior.
• Use monitoring and alerting to provide real-time warnings for abnormal access patterns.

These are common categories of capabilities and can be selected based on the actual environment. The key point is that access should be recordable, data should be cleanable, and behavior should be monitorable.

Boundaries and Compliance: AI Is Not a Licensed Advisor

Finally, the product boundary must be clear: a personal finance assistant is an information query and analysis tool, not a licensed financial advisor.

It can help users understand their current financial situation, discover anomalies, and understand concepts. However, when major financial decisions are involved, such as whether to borrow money, how to allocate assets, or whether to invest in a particular product, the assistant should clearly remind users to consult licensed professionals and regulated financial institutions.

From a compliance perspective, the assistant should also observe the following principles:

• Do not embed advertising.
• Do not provide paid recommendations.
• Do not sell credit cards, loans, or financial products to users.

This stance is a fundamental difference between a trustworthy assistant and marketing-driven fintech products. It is also a prerequisite for maintaining user trust. Once the model starts “recommending” financial products, its neutral analytical positioning can be compromised by commercial interests.

Conclusion: Security Is the First Principle

Bringing large language models into personal finance is no longer only about whether a system can hold a conversation. The more important question is whether it can do so safely.

Several principles run through the entire design:

• Read-only first: write permissions do not exist from the source, providing the strongest protection against accidental operations.
• Authorization instead of passwords: identity verification is completed through an aggregation service, so credentials never fall into the assistant side.
• Data minimization: only retrieve the fields that are necessary, retain only the last four digits of account numbers, and clean up historical data within a defined period.
• Training isolation: sensitive financial data must never enter model training.
• Authoritative fallback: all model conclusions should remind users to refer to official data, and major decisions should be returned to licensed professionals.

When this design is implemented systematically, a large language model can become a genuinely trustworthy financial assistant: one that helps users understand complex numbers while remaining restrained about their funds and privacy. This is both a technical requirement and the foundation for long-term user trust in this type of product.