AI for Bank Statement Analysis: A Technical Implementation Path for Personal Finance Insights

1. Requirements Background: Why Personal Finance Analysis Fits Large Models Well

Traditional bookkeeping products have long suffered from two pain points.

First, data entry costs are high. Users need to record transactions manually or use fixed templates. Once records are missed, all downstream analysis becomes distorted.

Second, analysis dimensions are pre-defined by the product. Reports can answer questions such as “How much did I spend on dining?”, but they cannot answer open-ended questions that require comparison baselines and time semantics, such as “Am I spending more than usual this month?”

Bank statement data helps address the first problem. It is naturally structured and includes transaction time, amount, merchant name, remarks, and debit/credit direction.

Large models help address the second problem. They can translate natural language questions into executable queries, semantically categorize transactions, and turn statistical results into natural-language explanations.

However, it is important to recognize that a large model is not the ledger itself. It is not good at precise summation, it does not naturally remember historical data from two years ago, and it does not hold the user’s account permissions.

Therefore, the engineering essence of this type of application is this: use engineering controls to constrain a large model so that it performs summarization and explanation on a read-only, controllable, and auditable copy of data, rather than dumping raw statements into a model and letting it freely interpret them.

2. Start by Defining Boundaries: Capability Scope Determines the Architecture

Before writing any code, it is important to define boundaries clearly, because they directly determine authorization scope, data retention strategy, prompt design, and evaluation standards.

Boundary 1: Read-only access. No fund movement.

Analytical applications should request read-only data scope. They should not request authorization for transfers, payments, or automatic debits.

Fund-moving capabilities belong to the payment risk-control domain. They require separate limits, multi-factor identity verification, dispute handling, and responsibility assignment. Mixing fund-moving permissions with analysis permissions means that a single prompt injection or a single misjudgment could directly become a financial loss.

Boundary 2: Explain income and expenses. Do not provide investment advice.

The application output should focus on questions such as “Where did my money go during this period?”, “Which expenses are rising abnormally?”, and “Which bills are due soon?”

It should not output advice such as “What you should buy.” The latter involves suitability management and liability boundaries, which belong to another compliance system.

Boundary 3: Data may be delayed, and the interface must indicate this.

Bank-side data synchronization already has delays. A common situation is that data is updated incrementally from the same day to the next day. Differences between account balance timing and credit card posting time can also be significant.

The product should clearly show the “data as of” time and should avoid using delayed data for highly time-sensitive judgments such as payment failure or overdraft warnings.

Boundary 4: Data should not enter model training by default.

This is not just a disclaimer. It is an engineering constraint. Tenant-level and session-level isolation and switches should be configured, and traceable audit records should be kept on the management side.

3. Reference Architecture: Six Layers

1) Account Authorization and Connection Layer

This layer is responsible for initiating authorization, obtaining access tokens, and maintaining account mapping relationships.

A key design point is that credentials such as passwords and SMS verification codes entered by users on the bank side should not pass through the application’s servers. The authorization process should be completed through a licensed or compliant aggregation channel. The application should only receive a token representing the authorization.

The application side should support unbinding at any time. After unbinding, downstream data cleanup tasks should be triggered.

2) Data Ingestion and Normalization Layer

This layer is an invisible but critical factor determining final analysis quality. It needs to handle:

• Merchant name normalization: The same convenience store may appear in several or many different forms in transaction records. Standardized mapping should be performed first, followed by entity merging.
• Transaction direction semantics: Credit card purchases, repayments, refunds, and fees need to be distinguished by debit/credit direction. Refunds should not be treated as new purchases.
• Amount and time zone unification: For cross-border transactions, currency, exchange rate date, posting date, and transaction date should be stored separately.
• Deduplication: The same transaction may appear twice across different channels. Idempotent merging should be performed based on time window, amount, and merchant fingerprint.

3) Storage and Index Layer

Detailed transaction data should be stored in low-cost storage that supports batch scanning. Pre-aggregated metrics designed for question answering should be stored in separate tables or views.

Semantic indexes should also be prepared for the chain of “natural language question → query.”

It is important to note that two years of transaction details may far exceed the context window. Therefore, the system should follow the pattern of first aggregate, then retrieve, and finally drill down. Detailed transactions should not be fed directly into the context as a whole.

4) Analysis and Orchestration Layer

The rule engine, statistical calculation, and model calls should have clear responsibilities:

• Rules handle deterministic judgments.
• Statistics handle baseline calculations.
• The model handles semantic understanding and narrative generation.

5) Interaction and Presentation Layer

This layer includes natural language question answering, spending charts, bill calendars, and financial dashboards.

Charts and numbers must come from validated backend calculation results, not from free model generation.

6) Security, Privacy, and Audit Layer

This layer cuts across all other layers and is responsible for data masking, key custody, access tracing, and abnormal access alerts.

4. Core Engineering Challenges and Solutions

Challenge 1: Transaction Classification

It is recommended to use a two-level category system. The first level may include categories such as “Housing,” “Dining,” “Transportation,” “Shopping,” and “Healthcare.” The second level may include categories such as “Rent,” “Utilities,” and “Food delivery.”

During cold start, merchant-name keyword rules can cover top merchants. Usually, a small number of rules can cover a large share of transaction volume. Long-tail merchants can be handled by the model for semantic classification. Classification results can then be written back as reusable mappings, forming a complementary loop between rules and the model.

Example code:

def classify_txn(txn, rules, model_client, cache):
    merchant = normalize_merchant(txn.merchant_raw)   # Normalize before matching
    key = hash(merchant) + "|" + txn.direction
    if key in cache:                                  # Prefer confirmed mappings
        return cache[key]
    hit = rules.match(merchant)                       # Keyword or regex rules
    if hit and hit.confidence >= 0.9:
        return hit.category
    if is_structured_merchant(txn):                   # Structured merchants such as platforms or chains
        return hit.category if hit else UNCATEGORIZED
    result = model_client.classify(                   # Call the model only for long-tail cases
        allowed_categories=CATEGORY_TREE,
        merchant=merchant,
        memo=txn.memo,
    )
    cache.store(key, result, needs_review=result.confidence < 0.6)
    return result.category

Challenge 2: Duplicate Charge and Subscription Detection

The essence is to identify periodicity at the merchant level.

An engineering approach is as follows: aggregate by normalized merchant, cluster using amount similarity and interval regularity, allow small amount fluctuations because many services have variable plan fees, use the median and standard deviation of adjacent intervals to determine periodicity, and then extrapolate the next charge date.

-- Example: Identify recurring charges under the same merchant
WITH base AS (
    SELECT merchant_id,
           CAST(txn_date AS DATE) AS d,
           ABS(amount) AS amt
    FROM   txn_detail
    WHERE  direction = 'DEBIT'
),
gapped AS (
    SELECT merchant_id, d, amt,
           DATEDIFF('day',
                    LAG(d) OVER (PARTITION BY merchant_id ORDER BY d), d) AS gap_days
    FROM   base
)
SELECT merchant_id,
       COUNT(*)                AS occurrence,
       MEDIAN(amt)             AS typical_amount,
       MEDIAN(gap_days)        AS typical_gap_days,
       STDDEV(gap_days)        AS gap_stddev
FROM   gapped
GROUP  BY merchant_id
HAVING COUNT(*) >= 3
   AND gap_stddev <= 3         -- Stable intervals indicate subscription-like behavior
   AND MAX(amt) / MIN(amt) <= 1.1
ORDER  BY typical_amount * 12 DESC;   -- Sort by annualized amount to expose large subscriptions first

Challenge 3: Baseline Selection for Anomaly Detection

A common pitfall is using the average of the most recent N transactions as the baseline.

Personal income and expenses have clear payday effects, seasonality such as holidays and school terms, and one-time large expenses. A mean baseline can be seriously skewed.

A more robust approach is to use the median of similar transaction types as the center value, use the interquartile range as the dispersion measure, and separately mark one-time large monthly expenses as “one-time” rather than “abnormal increase.”

When answering whether this month is higher than usual, the system should provide three comparisons at the same time: compared with last month, compared with the same period last year, and compared with the average of similar months over the last six months. The comparison baseline should be explicitly stated, rather than presenting a single isolated percentage.

Challenge 4: Numerical Correctness

Large models are unreliable when performing summation.

The correct approach is to converge all calculations involving amounts, counts, and date arithmetic into tool calls. The model should only organize the final language.

Example tool contract:

{
  "name": "query_spending_summary",
  "description": "Aggregate expenses by time range and category. Read-only interface.",
  "input_schema": {
    "type": "object",
    "properties": {
      "from_date":   {"type": "string", "format": "date"},
      "to_date":     {"type": "string", "format": "date"},
      "group_by":    {"type": "string", "enum": ["category", "merchant", "account", "month"]},
      "compare_with":{"type": "string", "enum": ["prev_month", "prev_year", "trailing_6m"]}
    },
    "required": ["from_date", "to_date", "group_by"]
  }
}

The model returns parameters, the backend executes the query, and the result set is fed back to the model for narration.

A hard output validation rule should be established: every number that appears in the final answer must be traceable to a tool result.

Challenge 5: Context Budget

Two years of statements may contain thousands or even tens of thousands of transactions.

A layered strategy is recommended:

1. First query the pre-aggregated metrics table, which may contain only a few hundred rows.
2. Drill down into detailed transactions for a single category only when necessary, usually tens of rows.
3. Pull detailed transactions only when the user explicitly requests transaction-by-transaction verification.

Session memory should also have limits and expiration policies to prevent historical conversations from growing indefinitely.

Challenge 6: Treat Statement Data as Untrusted Data

Transaction remarks, merchant names, and transfer notes are fields that may be written by users or external institutions. In theory, they may contain text designed to manipulate model behavior.

To address this, all external fields should be explicitly wrapped and escaped before entering the context. The system prompt should declare their data nature.

On the output side, tool calls should be restricted by a whitelist and read-only validation. The model should not be allowed to generate any write-operation request.

5. Privacy and Compliance Design Points

• Least-privilege authorization: Only request fields necessary for analysis, such as balance, transactions, and bills. Do not request account information unrelated to the feature.
• No credential storage: User bank passwords should not pass through the system. The application should only store authorization tokens. Tokens should be encrypted, managed by a dedicated key management service, and rotated periodically.
• Masked display: Account numbers should only display the last four digits in the interface and logs. Amounts and account names should be masked according to the scenario. Log collection should apply masking rules to avoid storing full statement data.
• Retention and deletion: Clearly define the retention period for detailed data. Support user-initiated unbinding and cascade deletion. Support data export.
• Training isolation: Ensure through both data-plane and configuration-plane controls that conversation content does not enter the training set. Retain switch status and change audit records.
• Compliance assessment: Before launch, evaluate purpose limitation, least privilege, separate consent, and revocability requirements for personal information protection. If data processing involves cross-border or cross-region transfer, confirm the compliance path in advance.

6. Quality Metrics and Rollout Strategy

Offline evaluation sets are a prerequisite for scaling this type of application. Recommended sets include:

• Transaction classification annotation sets
• Question-answering pairs, including questions that require baseline comparisons
• Anomaly and subscription case sets, including known false-positive traps
• Prompt injection attack samples

Key metrics include:

• Macro-averaged F1 for classification, rather than overall accuracy, to avoid head categories masking long-tail performance
• Question-answering factual consistency, measured as the proportion of numbers in answers that match tool results
• Subscription recognition recall and false-positive rate
• Mean absolute error of bill prediction
• Prompt injection blocking rate

Runtime monitoring should track:

• Tool call failure rate and timeout rate
• Context truncation ratio
• Output validation blocking rate
• End-to-end latency distribution

Logging services and monitoring alerts can be used to build a closed-loop process. Graded alerts should be configured for metric anomalies.

Gradual rollout strategy:

1. Start with a whitelist beta.
2. Expand to a small percentage of users by group.
3. Gradually roll out to all users.

Each stage should be observed for at least one week. Special attention should be paid to false-positive complaints. A single incorrect message such as “You were charged twice” can damage trust far more than a missed detection.

7. Mapping Cloud Capabilities for Implementation

Supporting this type of system usually does not require a complex architecture. General cloud capabilities are sufficient:

• Object storage can hold historical statements and archived data.
• A data warehouse or lakehouse can hold pre-aggregated metrics.
• A message queue can handle asynchronous synchronization tasks and bill reminders.
• A container platform can support elastic inference and batch classification jobs.
• A key management service can store tokens and encryption keys.
• Logging services and monitoring alerts can provide observability.

These capability categories are available in cloud product systems such as Baidu AI Cloud. Actual selection should be evaluated based on data scale, latency requirements, and compliance requirements, rather than defaulting to the largest configuration.

8. Common Pitfalls

1. Putting all statement data into the context, which is costly and may cause the model to miss information.
2. Allowing the model to calculate totals directly, which can lead to numerical hallucination.
3. Using a mean value as the anomaly baseline, which can be skewed by one-time large expenses.
4. Requesting the largest possible authorization scope for convenience, turning a read-only requirement into fund-moving permission.
5. Only providing an “unbind” button without implementing data cleanup after unbinding.
6. Using delayed data for highly time-sensitive reminders, causing a large number of invalid alerts.

9. Summary

Using AI to analyze bank statements is not technically mysterious. The difficult part is not calling the model, but doing five engineering tasks well:

• Account authorization
• Data normalization
• Statistical baselines
• Numerical validation
• Privacy isolation

A read-only boundary prevents financial risk. Tool-based calculation ensures numerical trustworthiness. Layered aggregation keeps costs under control. Least-privilege authorization and training isolation are prerequisites for long-term user trust.

Only when these layers are implemented correctly does the value of large models in this scenario become truly reliable.