Conversational AI for Personal Finance: Account Data Access, Technical Design, and Security Boundaries

A model provider recently shipped personal-finance capabilities for its conversational assistant, opening them in beta to higher-tier paid users in select regions. After authorizing connections to their bank and credit card accounts, users can check balances, review spending breakdowns, and track bills in natural language — and have the system detect duplicate charges, unexpected fees, and subscriptions whose prices have “quietly” gone up.

Setting the specific product aside, the part that matters to developers is not the conclusion that “AI can do bookkeeping now.” It is the set of engineering constraints behind it: how to connect highly sensitive, heavily regulated financial account data to an LLM inference pipeline securely, and how to make every number in the output traceable. This article abstracts that class of capability into a general technical problem — a conversational personal-finance analysis system — and lays out a layered design plus a checklist of boundaries.

1. Define the capability boundary first: what it replaces, what it doesn’t

The core workflow of traditional bookkeeping tools is “move data + classify manually”: the user exports statements, filters out noise by hand, and defines their own classification rules. The pain points cluster in three places: exports are tedious and every institution formats them differently; classification criteria vary by person, making months incomparable; and finding an issue means building your own pivot table.

Conversational analysis adds value in three specific ways:

• Natural language becomes the query interface. Users no longer need to know terms like “classification dimension,” “time window,” or “aggregation method.”
• On-demand aggregation and cross-comparison. The same normalized dataset can support month-over-month comparison, category drill-down, and single-transaction tracing.
• Explainable and follow-up-able. When a user asks why a given transaction counts as a subscription, the system goes back to the original transactions and shows the evidence.

What it explicitly does not do matters just as much: it performs no fund operations, makes no investment decisions, and does not replace licensed institutions or qualified professionals. Draw the capability boundary first — everything downstream in security and compliance design needs something to anchor to.

2. Reference architecture: five layers plus one cross-cutting track

┌──────────────────────────────────────────────┐
│  Presentation: charts / bill calendar /      │
│  dashboard / drill-down detail               │
├──────────────────────────────────────────────┤
│  Orchestration: intent recognition → metric  │
│  compilation → tool invocation → explanation │
├──────────────────────────────────────────────┤
│  Analytics: rules engine (subscriptions,     │
│  duplicate charges, anomalies) + statistics  │
├──────────────────────────────────────────────┤
│  Semantics: metric definitions, taxonomy,    │
│  time / currency / account dimensions        │
├──────────────────────────────────────────────┤
│  Access: open-banking aggregation, read-only │
│  authorization + incremental sync            │
└──────────────────────────────────────────────┘
   Cross-cutting: identity & authorization, encryption & key management,
   audit logging, masking & retention policy

In practice these systems are built on cloud infrastructure and reuse generic capabilities such as object storage, message queues, audit logging, and monitoring/alerting; vendors such as Baidu AI Cloud offer general-purpose data and AI capabilities that can serve as infrastructure options here. The point worth stressing: the access layer should be the only component that touches external account credentials. Every other layer consumes only an internal data model that has already been masked and normalized.

3. Read-only access: what least privilege looks like in code

The authorization model rests on one principle — the platform never holds the credential, and the permission cannot be exceeded:

1. The user signs in on the authentication page owned by their own institution; the platform never sees the account password.
2. A standard authorization-code flow exchanges that for a read-only access token, scoped to a specific list of accounts.
3. The platform incrementally syncs only what the granted scope allows and stores no institution-side login credentials.
4. The user can revoke the connection at any time; on revocation the token is invalidated immediately and local caches are cleaned up in cascade.

Readable fields should be narrowed to the minimum required for analysis: institution name, account name and type, last four digits of the account number, balance and credit limit, and up to roughly two years of transaction history. Any capability to transfer money, make payments, place orders, modify a payee, or change credentials must not appear in the tool list at all — this is not a prompt-level constraint, it is a code-level whitelist.

# Illustrative code: tool whitelist + enforced account scoping
READ_ONLY_TOOLS = {
    "list_accounts", "get_balances", "query_transactions",
    "aggregate_by_category", "list_recurring_bills", "render_chart",
}
DENIED_ACTIONS = {
    "transfer", "pay_bill", "place_order",
    "modify_payee", "change_credentials",
}
def dispatch(tool_name: str, args: dict, ctx: SessionContext):
    if tool_name in DENIED_ACTIONS or tool_name not in READ_ONLY_TOOLS:
        raise PermissionError(f"tool not permitted: {tool_name}")
    # Key point: account scope comes from the session context,
    # not from parameters the model filled in
    scope = set(ctx.authorized_account_ids)
    requested = set(args.get("account_ids", scope))
    args["account_ids"] = sorted(requested & scope)
    if not args["account_ids"]:
        raise PermissionError("no authorized account in scope")
    args["as_of"] = ctx.data_freshness_ts   # inject data freshness for the explanation layer
    return TOOL_REGISTRY[tool_name](**args)

Two details are easy to miss: tokens need rotation and revocation auditing; and account scope must be injected server-side rather than derived from model-generated parameters, otherwise a single misjudgment can widen the data surface.

4. Data normalization: turning transactions into a computable semantic structure

Statements from different institutions differ enormously in sign conventions, time granularity, and merchant naming. A stable normalization layer has to exist first, or every metric above it is untrustworthy.

{
  "txn_id": "t_01HZX...",
  "account_id": "acc_1",
  "authorized_at": "2026-09-29T23:40:00Z",
  "posted_at": "2026-09-30T08:12:00Z",
  "status": "posted",
  "amount_minor": -1299,
  "currency": "CNY",
  "direction": "debit",
  "merchant_raw": "SVCS *MONTHLY PLAN 8842",
  "merchant_norm": "Streaming video membership",
  "mcc": "4899",
  "category_l1": "Subscriptions",
  "balance_after_minor": 152340
}

Four conventions are non-negotiable:

• Amounts are stored as integers in the smallest currency unit, eliminating the reconciliation drift that floating point introduces.
• Direction and sign are stored separately. “Debit/credit” is an explicit field, avoiding the cross-institution inconsistency of assuming a negative number means an expense.
• Authorization time and posting time are distinguished, and the pending/posted status is preserved — otherwise statistics shift depending on when the sync happened.
• Merchant name normalization and merchant category code (MCC) mapping are applied as two separate layers. The raw string is kept for traceability; the normalized result is what aggregation uses.

5. Layered analysis capability: from descriptive to diagnostic

Splitting capability into three tiers by complexity makes both gradual rollout and acceptance testing manageable:

Descriptive statistics: aggregation by category, month-over-month comparison, balance calculation, bill calendar. Deterministic code handles all of it; no model is needed for the arithmetic.

Recurring-item detection: the same normalized merchant appearing at least three times in the window, with intervals stable at 27–35 days and very small amount variation, is treated as a subscription candidate, and the next charge date is predicted.

Diagnostic detection:

# Duplicate charge (illustrative rule)
if merchant_norm identical and amount identical and 1 day <= interval <= 5 days
   and both transactions are posted:
    -> flag as suspected duplicate charge, attach both txn_ids for user drill-down
# Abnormal fee
if fee category in {fees, interest, penalties} and amount > historical mean
   for that category on this account + 3σ:
    -> flag as abnormal fee, show the historical baseline range
# Slowly rising bill
Fit a linear regression on the monthly amount of a given subscription:
  slope significantly positive and cumulative increase > threshold
    -> flag as "gradually increasing", show first-vs-latest period amounts
# Interest cost
interest ≈ average daily interest-bearing balance × daily rate × days
The daily rate is derived from the annual percentage rate (APR);
interest calculation methods differ by institution, so the result is labeled an estimate

Questions like “am I spending more than I earn” should be answered through general financial metrics instead: cash flow coverage over the last N months, debt-to-income ratio, savings rate — each reported together with the months and source accounts used in the calculation.

6. Where the LLM sits: orchestration and explanation, not arithmetic

This is where the design is most often gotten wrong. Letting the model generate SQL directly, or “mentally compute” an amount, hands accuracy over to a probability distribution.

The correct division of labor: the model handles intent recognition, parameter extraction, tool selection, and result explanation. All numeric computation lives in deterministic code.

// Illustrative: natural language compiles into a constrained metric query, not arbitrary SQL
{
  "metric": "spend_by_category",
  "filters": {
    "account_ids": ["acc_1", "acc_2"],
    "date_range": {"from": "2026-08-01", "to": "2026-09-30"},
    "status": "posted"
  },
  "group_by": ["category_l1"],
  "compare": {"type": "mom", "baseline_months": 3},
  "limit_rows": 200
}

Three validation constraints accompany this:

• Citation constraint: every amount that appears in an answer must carry a txn_id or an aggregation-definition note, so the user can drill down in one click.
• Data freshness labeling: the response explicitly states “data as of” a given moment, and pending transactions are called out separately.
• Untrusted-input isolation: merchant names, transfer memos, and similar fields come from external institutions and are untrusted text. They may only be used as data values in computation and display — never executed as instructions. This is the key layer of prompt-injection defense.

7. Privacy, security, and accuracy governance

Data surface: encryption in transit and at rest, with keys held in a dedicated key management service; field-level minimization, with full account numbers masked by default in the display layer; logs masked before storage, with an explicit retention period and expiry deletion mechanism.

Model training isolation: conversation content inside the finance-specific entry point is excluded from training corpora by default, and that policy should be stated plainly to users rather than buried in documentation.

Accuracy governance checklist:

• Make clear that coverage is limited to connected accounts and does not represent the user’s complete financial situation.
• Institution-side sync has latency; balances and bills are authoritative on the institution’s side.
• Establish a sampling reconciliation mechanism that periodically compares internal statistics against official statements, with alerts when the gap exceeds a threshold.
• Attach a disclaimer to the output: results are informational analysis and do not constitute investment, tax, or legal advice.

8. Rollout cadence and common failure modes

A three-stage progression works well: read-only analysis → insight alerts → collaboration with licensed professional institutions, with each stage gated by geography, account type, or user segment behind a feature flag, and a pre-built rollback switch (one-click stop of syncing, existing imported data kept read-only).

The high-frequency failure modes are worth guarding against in advance: a taxonomy so fine-grained that months become incomparable; ignoring time zones and misattributing transactions across the day boundary; counting pending transactions in the balance and generating user complaints; a model “filling in” a plausible-looking number when no data exists; and the most serious of all — permission checks placed in the prompt instead of on the server.

Conclusion: the technical difficulty of conversational personal-finance analysis lies not in model capability but in least-privilege access design, the rigor of the normalized data model, and a clean split between “numbers come from deterministic computation, language comes from the model.” Hold those three lines and the rest is a matter of experience optimization.