An LLM-Powered Personal Finance Assistant: Read-Only Access, Anomaly Detection, and Privacy Practices

1. Problem Background and Product Positioning

Personal finance management has long been caught in a contradiction: transaction data is highly fragmented, yet the way people ask about it is casual and vague. What users really want to know often involves a judgment call, such as “where did my money go this month” or “how much will I have left before payday.” The underlying data, by contrast, is stored discretely as individual transactions, balance snapshots, and recurring bills. Traditional report-style products leave the filtering, aggregation, and interpretation to the user, which makes them hard to learn. A financial analysis assistant built around natural language tries instead to hand that “translation and computation” work over to the model.

It is worth being explicit about where this kind of product belongs. At its core it is a read-only financial information query and analysis tool, not an entry point for moving money. The assistant must not initiate transfers, manage assets, or carry out any investment action on the user’s behalf. This is more than a product choice: it directly shapes the system’s permission model, security boundaries, and compliance requirements. Every design decision that follows rests on three principles: read-only, explainable, and revocable.

2. Layered Architecture

A dependable financial analysis assistant can usually be split into the following layers, each with a clear responsibility and boundary:

• Interaction layer: receives the user’s natural language questions and maintains context across multiple turns.
• Intent understanding and query generation layer: maps natural language to structured query intent, essentially an NL2Query (natural language to structured query) step.
• Data access layer: reads authorized account and transaction data through standardized interfaces.
• Analysis and computation layer: performs aggregation, statistics, and anomaly detection.
• Response generation layer: turns structured results into natural language answers, with the necessary caveats attached.
• Security and audit layer: spans the entire flow and handles authorization checks, redaction, logging, and revocation controls.

The value of this layering is that the model only “understands and expresses” and never touches raw data reads or writes directly. Actual data retrieval goes through a controlled data access layer, which rules out at the root the risk of the model operating a database directly or issuing write operations.

3. Read-Only Authorization Model and Secure Access

The first principle for connecting financial data is minimal authorization and credential isolation.

Users should never hand their bank passwords to a third-party system. The approach common in the industry is to use a financial data aggregation provider: the user logs in and completes authentication directly on the bank side, and the third party receives only a restricted, revocable access token and cannot see the user’s bank credentials. Throughout the process, what the AI service receives is an authorization credential scoped to read-only access.

# Illustrative read-only authorization and access model (pseudocode)
authorization = request_user_authorization(scope=["read_only"])
if not authorization.is_valid() or authorization.can_write():
    raise PermissionError("Only read-only access is allowed")
accounts = data_provider.list_accounts(token=authorization.token)
for acc in accounts:
    # Reads only; any write operation is explicitly rejected at this layer
    transactions = data_provider.read_transactions(
        token=authorization.token, account=acc.id, limit=730  # e.g., at most the last two years
    )

The key point is to explicitly reject write permission at the architectural level. Even if an upstream model produces faulty output or falls victim to a prompt injection attack, the data access layer still cannot carry out destructive actions such as transfers or modifications. This is a defense-in-depth approach: security rests on structure rather than merely on the model’s “good behavior.”

4. Turning Natural Language Into Executable Queries

Turning “where did all my money go this month” into an executable query takes several steps:

1. Intent recognition: determine whether the user wants a spending summary by category, a balance lookup, or a bill forecast.
2. Time normalization: map vague expressions such as “this month” or “last quarter” to concrete date ranges.
3. Query construction: produce structured query conditions (category, time range, aggregation method).
4. Computation: the aggregation is performed in the data access layer, rather than letting the model “do the math in its head.”

# Illustrative pipeline: natural language -> structured query intent
query = {
    "intent": "expense_summary",
    "time_range": {"start": "2026-09-01", "end": "2026-09-30"},
    "group_by": "merchant_category",
    "aggregation": "sum"
}
result = analytics_engine.run(query)

One easily overlooked but critical engineering principle applies here: numeric calculations must be delegated to deterministic code, not generated by the model. Large language models excel at understanding meaning and organizing structure, but they are poor at precise arithmetic and risk producing “hallucinated numbers.” A sensible division of labor is for the model to “translate the question clearly,” the computation engine to “calculate the numbers accurately,” and the model again to “explain the results clearly.”

Multi-turn conversations also need context. For example, if a user first asks about total spending and then follows up with “how much of that was dining out,” the system must correctly inherit the time range and filters from the previous turn so the user does not have to spell them out again every time.

5. Billing Anomaly Detection

Beyond spending summaries, one of the more valuable analytical capabilities of this kind of assistant is identifying potential anomalies, typically including:

• Duplicate charges: the same merchant and the same amount appearing several times within a short period, suggesting a double billing.
• Unexpected fees: a merchant or fee type the user has never paid before.
• Rising recurring bills: subscription or fixed bills whose amounts keep climbing from one billing cycle to the next.

# Illustrative duplicate-charge detection logic
def detect_duplicate_charges(txns, window_hours=48, amount_tol=0.01):
    flagged = []
    for i, a in enumerate(txns):
        for b in txns[i+1:]:
            same_merchant = a.merchant_id == b.merchant_id
            close_amount = abs(a.amount - b.amount) <= amount_tol
            close_time = abs((a.time - b.time).total_seconds()) <= window_hours * 3600
            if same_merchant and close_amount and close_time:
                flagged.append((a, b))
    return flagged

Detecting rising recurring bills, by contrast, means tracking a time series for each “merchant + billing cycle” dimension and issuing an alert when the amount rises monotonically across several consecutive cycles and deviates from the historical baseline. The point of this kind of analysis is not to replace the user’s judgment, but to surface suspicious signals scattered across large volumes of transactions and lower the cost of self-checking.

6. Minimizing Data Access Scope

Following the least-privilege principle, for a connected account the assistant should read only the fields required for the analysis, such as:

• Institution name, account name, and account type;
• The last few digits of the account number (for the user to recognize the account, rather than the full number);
• Balance and credit limit snapshots;
• Transaction details within a given time window (for example, at most the last two years).

Full account numbers, full passwords, CVV codes, and other sensitive credentials should not, and do not need to, enter the system. Minimizing fields not only shrinks the blast radius of a leak but also makes security audits and compliance assessments easier to pass.

7. Privacy Protection and Compliance Practices

Privacy is the lifeline of this kind of product, and a few key practices are worth highlighting:

• Isolated data zones: you can create a dedicated finance zone in which conversations are not used for model training by default. Interactions in general-purpose zones, meanwhile, continue to follow the user’s existing privacy settings. This scenario-based boundary on data use gives users a stronger sense of control over sensitive data.
• Revocation at any time: users should be able to disconnect an account with one action, after which the system immediately loses data access. Authorization must be designed to be reversible, and revocation must take effect immediately in the data access layer rather than merely hiding the entry point in the frontend.
• Accuracy caveats: because of data delays, misclassification, or misreading of a statement, the assistant’s output may be inaccurate. The product should make it clear that, for decisions involving important amounts, the authoritative data on the bank side takes precedence. This is both responsible toward users and a necessary design choice for keeping liability boundaries clear.

8. Engineering Recommendations for Real-World Deployment

When bringing these capabilities to production, mature general-purpose cloud services can help lower the build cost. For example, you can use object storage to archive transaction snapshots, a message queue to smooth peaks and process asynchronous analysis tasks, monitoring and alerting to track the false-positive rate of anomaly detection, and a logging service to retain complete authorization and access audit records. As an example, Baidu AI Cloud offers general-purpose capabilities such as object storage, message queues, logging, and monitoring and alerting, which can help keep a system like this running stably and traceable. Availability and specific features vary by region, so refer to the official documentation for details.

Finally, three bottom lines are non-negotiable: read-only, explainable, and revocable. Read-only keeps funds safe, explainable keeps user trust (every number can be traced back to specific transactions), and revocable keeps users in control at all times. Within these three constraints, large language models can truly become a capable assistant for personal finance management rather than a new source of risk.