AI Bank Statement Analysis: Building a Secure Personal Finance Intelligence System

1. Background and Problem Definition

In recent years, introducing large language model capabilities into personal finance management has become a compelling application direction. A typical requirement is to aggregate income and expense information scattered across banks, credit cards, loans, and investment accounts into a unified view, and let AI help ordinary users answer high-frequency questions such as: “Are this month’s expenses higher than usual?”, “What bills still need to be paid before payday?”, and “Are there idle subscriptions that are still charging?”

From a technical perspective, this type of application is essentially a natural language analysis system for personal financial data. It needs to address four layers:

• How data can be securely accessed
• How transactions can be structured and categorized
• How anomalies can be automatically identified
• How conclusions can be presented in a trustworthy way

This article discusses a general and implementable technical approach across these four layers.

It is important to emphasize that the core positioning of such a system is to help users understand income and expenses, not to provide investment or wealth-management advice. Technically, four principles should always be maintained: least privilege, read-only access, explainability, and compliance.

2. Overall Technical Architecture

A complete personal finance intelligent analysis system can usually be divided into four layers:

• Data access layer: Connect to users’ various accounts in a tokenized manner through standardized financial data aggregation services, and obtain account metadata and transaction statements.
• Data processing layer: Clean, normalize, categorize, and tag raw transaction data to form a structured dataset.
• Analysis and reasoning layer: Perform analysis tasks such as expense aggregation, trend comparison, and anomaly detection on top of structured data, and hand the results to a large language model for natural language explanation.
• Presentation and interaction layer: Generate visualizations such as expense charts, bill calendars, and financial dashboards, and support multi-turn conversational queries.

The benefit of decoupling these four layers is that data access and business analysis are independent of each other. Security policies can be concentrated at the access layer, while analysis logic can be iterated repeatedly without touching raw sensitive credentials.

3. Data Access Layer: Security Comes First

Personal financial data is highly sensitive. The primary goal of the access layer is not merely to “connect,” but to connect safely. Common industry practices include:

1. Tokenized credential custody: Account connection and authentication are handled by third-party financial data aggregation platforms. The application itself never touches users’ bank passwords. Instead of account credentials, the platform issues time-limited and revocable access tokens to the application.
2. Read-only permission constraints: The authorization scope requested by the application should be strictly limited to reading account balances, transaction records, credit limits, and similar data. It should not have write capabilities such as transfers, payments, or portfolio rebalancing. This removes the risk of funds being mistakenly operated or abused at the architectural level.
3. Data minimization: Only fields necessary for completing tasks should be read, such as bank name, account type, last four digits of the account number, balance, credit limit, and historical transactions. Sensitive fields such as full account numbers should be masked or truncated.
4. Revocable at any time: Users should be able to unlink accounts and revoke tokens with one action. After revocation, data access should immediately become invalid.

The design should also clearly communicate data boundaries to users: the maximum number of accounts that can be connected, the longest historical period that can be read, and possible delays in balance data (for example, a settlement delay of one to two days). These limitations are not defects, but necessary constraints for protecting personal data security.

4. Transaction Categorization: From Raw Statements to Structured Tags

Raw transaction statements are usually semi-structured text containing merchant name, amount, time, and memo. They must be categorized before they can support higher-level analysis. A hybrid approach of rule matching plus model fallback is recommended:

• Rule layer: Quickly categorize transactions based on keywords and a merchant dictionary, covering common categories such as housing, utilities, dining, shopping, and transportation. This approach is low-cost, explainable, and stable.
• Model layer: For items that rules cannot cover, use a large language model to classify them semantically. Newly identified merchants can then be added back to the rule library, creating a positive feedback loop.

# Transaction categorization: rules first, model fallback
CATEGORY_RULES = {
    "housing":   ["rent", "mortgage", "property"],
    "utilities": ["electricity", "water", "gas", "internet"],
    "dining":    ["restaurant", "cafe", "food"],
    "shopping":  ["market", "store", "online"],
}
def categorize(transaction, model_classifier=None):
    memo = transaction["memo"].lower()
    for category, keywords in CATEGORY_RULES.items():
        if any(k in memo for k in keywords):
            return {"category": category, "source": "rule"}
    # If rules do not match, classify with the model
    if model_classifier:
        return {"category": model_classifier(transaction), "source": "model"}
    return {"category": "uncategorized", "source": "none"}

The accuracy of categorization directly affects the trustworthiness of downstream analysis. Therefore, it is recommended to retain a source field to indicate how the category was determined, making auditing and manual correction easier.

5. Anomaly Detection: Letting the System Find Problems

The real value of personal finance analysis often lies in automatically identifying problems that users may not easily notice. There are three common types:

1. Duplicate Charge Detection

Multiple charges from the same merchant for the same amount within a short period often indicate a system error or duplicate billing:

from collections import defaultdict
from datetime import date
def detect_duplicate_charges(transactions, window_days=7):
    seen = defaultdict(list)
    for t in transactions:
        key = (t["merchant"], round(t["amount"], 2))
        seen[key].append(t)
    duplicates = []
    for key, txns in seen.items():
        if len(txns) > 1:
            dates = sorted(t["date"] for t in txns)
            for i in range(1, len(dates)):
                if (dates[i] - dates[i - 1]).days <= window_days:
                    duplicates.append(txns)
                    break
    return duplicates

2. Subscription and Recurring Charge Detection

By analyzing the periodicity and amount stability of charges, the system can identify subscription services that users may have forgotten:

def detect_subscriptions(transactions):
    grouped = defaultdict(list)
    for t in transactions:
        grouped[(t["merchant"], round(t["amount"], 2))].append(t["date"])
    subscriptions = []
    for (merchant, amount), dates in grouped.items():
        dates = sorted(dates)
        if len(dates) >= 3:
            intervals = [(dates[i] - dates[i - 1]).days for i in range(1, len(dates))]
            avg = sum(intervals) / len(intervals)
            # Monthly subscription cycles are usually between 25 and 35 days
            if 25 <= avg <= 35:
                subscriptions.append({
                    "merchant": merchant,
                    "amount": amount,
                    "cycle_days": round(avg),
                })
    return subscriptions

3. Bill Increases and Abnormal Charges

For bills within the same category, month-over-month analysis can identify “continuously rising bills.” Single expenses that clearly deviate from the historical distribution can be marked as “abnormal charges.” Such analysis can combine statistical methods, such as mean and standard deviation, to establish a baseline. Items exceeding thresholds can prompt users to review them.

6. Analysis and Reasoning Layer: Structured Data plus Natural Language

A key design principle for the analysis layer is: let deterministic computation handle the math, and let the large language model handle the explanation.

Tasks such as amount aggregation, trend comparison, and anomaly detection should be completed by deterministic code logic to ensure accurate and reproducible results. The large language model should translate structured conclusions into natural language and support conversational follow-up questions. For example:

def compare_monthly_spending(transactions):
    monthly = defaultdict(float)
    for t in transactions:
        monthly[(t["year"], t["month"])] += t["amount"]
    values = list(monthly.values())
    avg = sum(values) / len(values) if values else 0
    result = {}
    for (y, m), amount in monthly.items():
        deviation = (amount - avg) / avg if avg else 0
        result[(y, m)] = {"amount": amount, "deviation": round(deviation, 3)}
    return result

After receiving months with a positive and relatively large deviation, the model can generate an explainable conclusion such as “This month’s spending is approximately X% higher than the historical average.” This division of labor both avoids the risk of the model making calculation errors and preserves the flexibility of natural language interaction. It is key to the trustworthiness of such systems.

7. Privacy and Compliance Design

Compliance design for personal finance systems should not be an afterthought. It should be built into the architecture from day one:

• Conversation data isolation: Conversation and query data used for financial analysis should not enter model training pipelines by default. Product and engineering teams should clearly define data usage boundaries and disclose them transparently to users.
• Encryption in transit and at rest: Sensitive data should be encrypted during transmission and static storage. Tokens and transaction data should be stored separately.
• Access auditing: All data read operations should be logged to support post-hoc audits and alerts for abnormal access.
• Deployment flexibility: In scenarios requiring stronger data control, generic cloud capabilities, such as object storage, message queues, logging services, and monitoring and alerting, can be used to build a compliant data processing pipeline. For example, general-purpose cloud products from providers such as Baidu AI Cloud can help implement encrypted storage, asynchronous processing, and end-to-end monitoring without requiring teams to build underlying infrastructure themselves.

It should be stated again: the system’s positioning is to help users understand personal income and expenses. No analysis conclusion should constitute investment or wealth-management advice. Product copy and interaction should include a clear disclaimer.

8. Engineering Implementation and Best Practices

Overall, implementing a personal finance intelligent analysis system should follow these practices:

1. Prioritize least privilege: The access layer should only request read-only authorization, eliminating write-operation risks at the architectural level.
2. Do not store sensitive data in plaintext: Fields such as account numbers should be masked, and tokens should be isolated from business data.
3. Separate computation from explanation: Amounts, trends, and anomalies should be calculated by deterministic code, while the model should only handle explanation and interaction.
4. Make data delays transparent: Clearly inform users that balances and transactions may have settlement delays to avoid misleading decisions.
5. Ensure explainability and correctability: Every analytical conclusion should be traceable to specific transaction records, and users should be able to manually correct categorization.
6. Do not use financial conversation data for training by default: Financial conversation data should be isolated by default, and this policy should be stated in privacy documentation.

9. Conclusion

“Letting AI read bank statements” may sound like a feature highlight for a single product. From an engineering perspective, however, it is a complete system design that covers secure data access, data structuring, anomaly detection, explainable analysis, and privacy compliance. The real challenge is not making the model “understand” data, but converting sensitive personal financial data into trustworthy and usable insights under constraints such as read-only access, least privilege, and auditability. Understanding this technical foundation is more valuable in the long run than memorizing any specific product feature.