Read-Only Personal Finance AI Assistants: Permission Boundaries, Data Governance, and Numerical Reliability

1. Where This Comes From: From Generic Chat to a Personal Finance Copilot

Personal finance has a long-standing structural problem: the data is scattered across bank accounts, credit cards, and multiple subscription services. Users have to log into each source, export by hand, and stitch spreadsheets together just to answer a basic question like “where did my money go this month.” Harder questions — “which of my bills quietly went up,” “am I being charged twice” — are effectively out of reach for most people.

Large language models change the interaction model: users no longer need to learn the definitions behind a statement or report. They just ask in natural language. But wiring a model into financial data also raises the stakes from “it said something wrong” to “it moved money incorrectly.” The engineering focus here is therefore not on how smart the model is, but on three things: permission boundaries, data governance, and numerical reliability.

2. First Principle: Read-Only Is a Non-Negotiable Architectural Constraint

The most common misreading when designing this kind of feature is “ship first, add safeguards later.” In a financial context the order should be reversed: start with minimum capability by default, and let the architecture enforce read-only behavior — not a prompt asking the model to behave.

Read-only has to hold at three levels at the same time.

1. API level. Request no permission that can move money. The authorization scope covers only balance queries, transaction history reads, and account metadata; nothing for payments, direct debit mandates, card changes, transfers, or investment order placement.
2. Credential level. Hold only short-lived access tokens paired with revocable refresh tokens; the token-to-user binding can be severed at any time and invalidated immediately. Credentials that any write operation would require simply do not exist in the system, which removes the possibility of privilege escalation physically rather than procedurally.
3. Product level. Issue no credit products, offer no proprietary deposit accounts, and sell no financial products. This looks like a commercial decision, but it is really a precondition for trust: only when the service provider earns no sales revenue from the user can its verdict on “where you overspent” be read as a neutral conclusion.

Alongside the “no ads, no sponsored recommendations” stance comes one hard engineering rule: the recommendation surface must be completely isolated from the financial computation path. No commercial ranking factor may exist anywhere in the chain that produces financial conclusions — otherwise a single recommendation that “happens to rank first” is enough to destroy the credibility of the entire feature.

# Read-only authorization scope declaration (illustrative)
FINANCE_READ_SCOPES = [
    "accounts.balance:read",       # account balance
    "transactions.history:read",   # transaction history; default window of 24 months
    "accounts.meta:read",          # account type, currency, institution name
]
# Capabilities explicitly not requested; recorded in the permission
# matrix and enforced as a CI check
FORBIDDEN_SCOPES = {
    "payments:write", "transfers:write", "mandates:write",
    "cards:write", "investments:write",
}
assert not (set(FINANCE_READ_SCOPES) & FORBIDDEN_SCOPES)

Putting that assertion in the pipeline is far more reliable than putting it in a design document.

3. Reference Architecture: Five Layers

A deployable implementation usually splits into five layers, each with a single responsibility and a clear boundary.

Layer	Responsibility	Key design points
Authorization and linking	Link user accounts, issue and revoke tokens	Least privilege, short-lived tokens, revocable
Account aggregation	Pull data through open banking / statement aggregation APIs	Idempotent pulls, incremental sync, retry on failure
Data governance	Normalize, mask, categorize, compute metrics	Deterministic computation; the model does no arithmetic
Inference orchestration	Intent detection, tool invocation, result explanation	Tool return values are the source of truth
Audit and presentation	Citation and provenance, logging, export and deletion	Fully traceable end to end; authorization can be revoked

The important consequence of this split is that each layer’s input and output becomes independently testable. Categorization accuracy, anomaly recall, and numeric error rate can each be measured on their own, instead of being folded into a vague judgment of whether “the answers are good.”

4. Data Minimization and Masking: Show the Model Only What It Needs

Dumping raw transaction records wholesale into the context is the most common anti-pattern here. It amplifies three risks at once: the privacy exposure surface, the prompt injection surface, and context cost.

The recommended approach is to mask inside the data governance layer and hand the model a structured view only:

import hashlib, hmac, os
def to_model_view(tx, salt: bytes):
    return {
        "ref": hmac.new(salt, tx.id.encode(), hashlib.sha256).hexdigest()[:12],
        "date": tx.posted_at.date().isoformat(),
        "amount": f"{tx.amount:.2f}",
        "currency": tx.currency,
        "merchant": generalize(tx.merchant_raw),  # keep only the granularity categorization needs
        "category": tx.category,
        "status": tx.status,                      # posted / pending
    }
def generalize(raw: str) -> str:
    # Keep only the entity name needed to classify the merchant;
    # drop card numbers, store IDs, and order IDs
    return normalize_merchant(raw)

Supporting requirements:

• Encryption in transit and at rest. Encrypt the whole path, encrypt fields at the storage level, and keep keys in a dedicated key management service with rotation support.
• Explicit retention. Keep transaction detail for a fixed period and purge it automatically on expiry; aggregated metrics may be retained indefinitely because they cannot be reversed back into individual transactions.
• User control. Provide “export my data” and “delete and unlink now” entry points, where unlinking invalidates tokens immediately and aborts any running pull jobs.

5. Transaction Categorization: Deterministic Rules as a Floor, Semantic Recall for Coverage

Pure model-based categorization is unstable: the same merchant lands in different categories across turns, and users lose trust immediately. Pure rules are low coverage: new merchants, small merchants, and foreign merchants appear constantly.

The more robust engineering answer is a three-stage funnel.

def categorize(tx, rules, embed_index, llm):
    # Layer 1: deterministic rules; a hit returns immediately and is reproducible
    hit = rules.match(tx.mcc, tx.merchant_raw, tx.amount)
    if hit and hit.confidence >= 0.90:
        return hit.category, "rule"
    # Layer 2: vector recall; find nearest neighbors among historical labeled samples
    neighbors = embed_index.search(embed(tx.merchant_raw, tx.mcc), top_k=5)
    if neighbors and neighbors[0].score >= 0.82:
        return neighbors[0].category, "embedding"
    # Layer 3: model fallback; force a closed-set enum and discard illegal values
    guess = llm.classify_closed_set(tx, categories=CATEGORY_SET)
    if guess in CATEGORY_SET:
        return guess, "llm"
    return "uncategorized", "fallback"   # better to leave a gap than to invent

Two details that are easy to overlook:

• Corrections must flow back. When a user clicks “this isn’t dining,” that signal should be written back to the rules or the labeled set, so the same merchant is matched directly next time.
• Categorization must be versioned. When the taxonomy changes, historical reports still need to be reproducible under the taxonomy in force at the time; otherwise month-over-month comparisons show jumps nobody can explain.

6. Anomaly Detection: Turning “Things People Miss” into a Computable Problem

The real value of this kind of feature sits in low-frequency, high-impact anomalies. The four categories below can all be implemented with deterministic logic, without asking the model to guess.

from collections import defaultdict
from decimal import Decimal
def duplicate_charges(txs, window_days=7, tol=Decimal("0.01")):
    """Same merchant, same amount, charged multiple times within a short window"""
    groups = defaultdict(list)
    for t in txs:
        if t.status != "posted" or t.amount >= 0:
            continue
        key = (t.merchant_key, abs(t.amount))
        groups[key].append(t)
    out = []
    for (m, amt), items in groups.items():
        items.sort(key=lambda x: x.posted_at)
        for prev, cur in zip(items, items[1:]):
            gap = (cur.posted_at - prev.posted_at).days
            if 0 <= gap <= window_days and abs(abs(cur.amount) - amt) <= tol:
                out.append({"merchant": m, "amount": amt, "gap_days": gap})
    return out
def price_creep(txs, merchant_key, months=12, min_ratio=Decimal("1.10")):
    """A recurring bill that quietly increases within a year"""
    series = [t for t in txs
              if t.merchant_key == merchant_key and t.amount < 0
              and t.is_recurring]
    series.sort(key=lambda x: x.posted_at)
    if len(series) < 2:
        return None
    first, last = abs(series[0].amount), abs(series[-1].amount)
    if first > 0 and last / first >= min_ratio:
        return {"merchant": merchant_key,
                "from": str(first), "to": str(last),
                "ratio": float(last / first),
                "span_months": months}
    return None
def mystery_fees(txs, keywords=("service fee", "processing fee",
                                "account maintenance fee", "annual fee")):
    return [t for t in txs if any(k in t.merchant_raw.lower() for k in keywords)]

Three definition questions that must be settled during implementation, not after:

• Separate pending from posted. pending transactions must not count toward monthly totals; otherwise period attribution shifts across month boundaries and duplicate charges get flagged incorrectly.
• Time zone and statement period. Attribute by posting time, normalized to a single user time zone. A credit card billing cycle and a calendar month are not the same thing and need to be distinguished explicitly.
• Refunds, partial refunds, and reversals must be netted as pairs. They cannot each be counted once.

7. Numerical Correctness: Never Let the Model Do Arithmetic

This is the single most important engineering discipline in the whole system. A model’s strengths are explanation, summarization, and follow-up questions; its weaknesses are exactly precise computation and stable counting. Every number must come from a tool. The model only narrates.

def month_spend(transactions, year, month, tz="Asia/Shanghai"):
    start, end = month_bounds(year, month, tz)
    posted = [t for t in transactions
              if t.status == "posted" and start <= t.posted_at < end]
    by_cat = defaultdict(Decimal)
    total = Decimal("0")
    for t in posted:
        if t.amount >= 0:
            continue
        by_cat[t.category or "uncategorized"] += -t.amount
        total += -t.amount
    return {
        "total": str(total.quantize(Decimal("0.01"))),
        "by_category": {k: str(v.quantize(Decimal("0.01")))
                        for k, v in sorted(by_cat.items(), key=lambda kv: -kv[1])},
        "tx_count": len(posted),
        "window": [start.isoformat(), end.isoformat()],
    }

Two more checks belong on the output side:

1. Numeric allowlist validation. Every amount and count that appears in an answer must have a matching value in the structured result returned by the tools for that turn. If it does not, refuse the output and fall back to “please re-run the query.”
2. Citation and provenance. Attach the ref (masked transaction reference) and the statistical window to every conclusion so the user can open it and verify. Verifiability is the dividing line between a financial conclusion and ordinary chit-chat.

Explaining concepts like interest rates or annualized returns follows the same discipline: definitions may be given, but the actual amounts must come from tool computation, never from the model deriving interest on its own.

8. Compliance and Content Governance: Encode the Red Lines in the System

These constraints need to hold at both the product and the code level:

• No investment advice. Provide factual analysis such as spending structure or fee composition; do not issue directive “buy/sell this instrument” guidance.
• No handling of funds. No write-capable interfaces exist, and the service never custodies user money.
• No commercial ranking. The financial path and the advertising path are physically isolated.
• End-to-end audit. Record every data pull, every tool invocation, and the data version each answer relied on, so incidents can be reconstructed and users can self-check.
• Incident response for anomalies. Credential leaks and data source failures need a degradation strategy — if the data cannot be retrieved, say so plainly; never pass off cached history as live data. This is especially dangerous for balances and pending amounts.

9. Gradual Rollout and Launch Checklist

Feature availability should follow staged rollout, with observable metrics deciding whether to widen the exposure.

Metric	What it means	Response strategy
Data pull success rate	Health of the aggregation path	Stop expanding below the threshold
Categorization coverage	Effectiveness of rules plus recall	Add rules before scaling if the uncategorized share is high
Numeric validation failure rate	Accuracy floor for answers	Target near zero; any non-zero result blocks expansion
Authorization revocation rate	Reverse signal of trust	A spike requires reviewing whether the privacy notice is clear
Sensitive data leakage alerts	Effectiveness of masking	Roll back on any single hit

User-side communication matters just as much: on first linking, explain on a single page what can be read, for how long, and how to revoke it — rather than burying the permission details deep inside a settings page. The lower the cost of understanding a permission, the lower the revocation rate.

10. Common Anti-Patterns

• Handing raw transaction records to the model, which leaks privacy and raises prompt injection risk;
• Using a prompt to “tell” the model not to transfer money instead of simply never granting write scopes in the permission matrix;
• Letting the model sum values on its own, producing amounts and category counts that contradict each other;
• Ignoring pending status, refund netting, and time zone attribution, so monthly totals do not reconcile;
• Falling back to cached data when retrieval fails and presenting a stale balance as a live one;
• Mixing commercial recommendations into the financial conclusion path, losing neutrality in one stroke.

Conclusion

The hard part of connecting a large language model to personal finance is not whether it can hold a conversation — it is whether it can be trusted. A read-only permission matrix, data minimization, deterministic computation, numeric allowlist validation, and auditable traceability form a complete loop: the model handles understanding and explanation, while the system owns facts and boundaries. None of the implementation is mysterious. The difficulty is restraint — requesting one fewer permission, caching one fewer dataset, and letting the model compute one fewer number are all preconditions for this kind of feature surviving in the long run.