Building a Read-Only AI Financial Assistant for Account Connection and Spending Analysis

Combining conversational AI with personal financial data is becoming an important direction for intelligent assistants. The core value is not to provide generic financial advice, but to let users ask natural-language questions such as “Where did my money go?”, “Did I overspend this month?”, or “Was I charged twice?” and receive explainable answers based on authorized account data.

For developers, this requires an end-to-end engineering workflow that includes account connection, permission control, data normalization, spending analysis, conversation orchestration, privacy auditing, and staged deployment. This article discusses how to build a read-only, minimal-access, auditable personal finance analysis assistant from a general technical perspective.

1. Requirements and Product Scope

Traditional financial Q&A often relies on users manually entering transactions or uploading statements. The information is incomplete and quickly becomes outdated. An account-level analysis assistant uses a standard authorization process to connect bank or credit card accounts, normalize transaction records, and provide them to an analysis service. The conversational layer then turns the results into understandable answers.

The product should be positioned as an assistant for understanding financial activity, not as an entry point for moving money. The system should therefore follow a strict read-only principle. It may read account names, account types, balances, credit limits, and transaction records, but it must not transfer money, manage funds, or execute investment operations.

Typical capabilities include:

1. Spending summaries: Aggregate expenses into categories such as rent and utilities, dining, and shopping.
2. Trend comparisons: Answer whether spending is higher than usual.
3. Anomaly alerts: Identify possible duplicate charges, unexpected fees, or steadily increasing bills.
4. Concept explanations and calculations: Explain concepts such as annual percentage rates and show the total interest paid over the previous year.

The conversational experience and financial calculations should be governed separately. The conversation layer is responsible for presenting results, while the analysis layer handles reproducible calculations and business rules.

2. System Architecture and Data Flow

A layered architecture is recommended:

• Integration layer: Handles user authorization and account aggregation.
• Permission layer: Enforces read-only access and field allowlists.
• Normalization layer: Converts transactions from different accounts into a common structure.
• Analysis layer: Performs categorization, aggregation, and anomaly detection.
• Conversation orchestration layer: Converts natural-language questions into controlled queries.
• Audit layer: Records access events and the boundaries of data usage.

The following pseudocode illustrates permission declarations and a data structure. It is not a specific API implementation:

type AccountScope = {
  bankName: string;
  accountType: "checking" | "credit";
  last4: string;
  balance: number;
  creditLimit?: number;
  transactions: Transaction[]; // Limit to the necessary time window when possible
}
const capabilities = {
  readAccounts: true,
  readTransactions: true,
  transfer: false,
  invest: false,
  manageFunds: false
};

The data flow should follow this sequence:

Authorization → Retrieval → Normalization → Analysis → Response → Audit

Every response should be traceable to the accounts used, the time window queried, and the aggregation rules applied. For a question such as “Where did I spend my money this month?”, the model should not generate figures freely. The analysis service should first calculate category totals and then pass structured results to the conversational layer for verbalization. This reduces the risk of hallucinated financial data.

3. Read-Only Connections and Least-Privilege Boundaries

Account connection is the highest-risk part of the workflow. The implementation should ensure that:

• Authorization tokens provide read-only access.
• The permission layer explicitly denies transfers, payments, investments, and other financial operations.
• The accessible fields are limited to the minimum necessary information.

Recommended fields include the bank name, account name and type, the last four digits of the account number, balance, credit limit, and transaction records within a necessary time window. For developers, an explicit field allowlist is more reliable than a denylist. Any new field should undergo a privacy review before it becomes available.

Users should also be able to revoke authorization at any time. The product should show connection status, the most recent synchronization time, and the scope of accessible data.

Read-only access does not eliminate risk. Transaction records remain sensitive financial information and require encryption in transit, access isolation, managed keys, and audit logging. On Baidu AI Cloud, general cloud capabilities such as key management, logging, object storage, and monitoring alerts can be combined to support key protection, access auditing, storage of redacted audit packages, and observation of abnormal calls. Together, these capabilities can form an operational security baseline.

4. Spending Categorization, Anomaly Detection, and Explainable Responses

The spending analysis layer should provide a stable category system and configurable rules. Categorization can combine rules and models: merchant type, keywords in transaction descriptions, and the user’s historical behavior can jointly determine a category. Model outputs should retain both confidence information and an explanation of the factors used.

Anomaly detection may cover duplicate charges, unusually large amounts, increased subscription renewals, and imbalances between income and expenses. Example rules include:

for tx in transactions:
  if duplicate(tx, window=3d):
    flag("Possible duplicate charge", tx)
  if amount(tx) > baseline(category) * threshold:
    flag("Unusual amount", tx)
  if subscriptionIncreased(tx):
    flag("Bill increase", tx)

Thresholds should be configured by the business and calibrated through evaluation. Performance figures should not be invented.

Responses should distinguish between facts and alerts:

• Facts come from aggregation results.
• Alerts come from matched rules.

For concepts such as annual percentage rates, the assistant should provide the definition, calculation formula, and the result based on the user’s data. It should also clearly state that the information does not constitute investment advice.

Neutrality is equally important. The assistant should not embed advertisements, sponsored recommendations, or proprietary credit, loan, or savings products. This prevents commercial interests from influencing financial answers.

5. Privacy Compliance, Model Training Boundaries, and Staged Rollout

Financial conversations should not be used to train models. This boundary should be enforced in both product policy and technical systems:

• The training data pipeline should not collect these conversations.
• Logs should retain only the minimum information required for auditing.
• Sensitive fields should be redacted before data enters analysis and evaluation environments.

External release should use a staged rollout. The product can first be tested with a limited group of paying users, allowing the team to collect information about question patterns, false-positive rates, and user feedback before expanding availability.

During the rollout, teams should pay particular attention to:

• Authorization failures
• Data synchronization delays
• Categorization bias
• False-positive anomaly alerts

Experience with assistants for vertical domains such as legal and financial services also demonstrates that specialized capabilities must be built around clear boundaries. The assistant should explain, summarize, and alert—but it should not perform unauthorized operations.

A practical development checklist includes:

• A clear read-only capability declaration
• Field allowlists
• Authorization revocation
• Defined data time windows
• Evaluated categorization rules
• Explainable anomaly alerts
• A policy preventing conversations from being used for training
• Audit logs
• Neutral recommendation policies
• Appropriate risk disclosures

Only by implementing these engineering constraints can an AI financial assistant improve users’ understanding of their finances while remaining secure, compliant, and trustworthy.