Read-Only Authorization for AI Personal Finance Assistants: Technical Design and Boundaries

4 hr ago0 views

Connecting bank and credit card accounts to a general-purpose AI assistant raises a core engineering question: how to gather enough data for meaningful analysis without ever taking control of funds. This article argues that read-only access is an architectural decision, not a feature restriction. It lays out a threat model for personal finance, an account-linking chain that keeps credentials out of the model side, a whitelist-based capability model, four deterministic analytical features (spending categorization, anomaly detection, subscription recognition, and multi-view output), language-layer design for explaining terminology and uncertainty, privacy engineering for conversation data and memory, a pre-launch checklist with quality metrics, and the common anti-patterns that cause these products to fail.

1. The Core Problem: Define the Threat Model Before the Features

When a general-purpose AI assistant links in bank and credit card accounts for analysis, the real engineering challenge is not “can it generate a spending report.” It is how to obtain enough data for analysis without ever touching control over funds. These two concerns must be examined separately.

The loss structure in personal finance is highly asymmetric:

Operation type	Cost of error	Reversibility	Default policy
Read balance and transaction history, compute statistics	Low (information misread)	Fully reversible	Allowed, with explanations and confidence
Mis-categorization, false anomaly alerts	Medium (loss of trust)	User can correct	Allowed, requires justification
Initiate transfers, pay bills	Extremely high (fund loss)	Essentially irreversible	Does not exist at the capability layer
Authorize third-party debits, place investment orders	Extremely high (long-term liability)	Hard to revoke	Does not exist at the capability layer

The conclusion is that read-only is not feature trimming; it is an architectural decision. It means the model’s output space is constrained to “statements and suggestions,” while the execution channel for fund operations has no exit in the system design at all. Any roadmap of “start read-only, then open up write access later” buries a dormant write path in the permission model that can be activated at any time. The correct approach is to make write capability inexpressible in code and gateway configuration.

2. The Account-Linking Chain: Credentials Never Enter the Model Side

Mainstream industry practice does not use a “user hands their online-banking password to the AI platform” model. Instead, it introduces an account-aggregation authorization agent: the user completes bank-side authentication on the agent’s authorization page, and the platform receives only a token and structured data. The key design of this chain spans four layers.

2.1 Authorization and Credential Isolation

User ──(password/OTP)──> Bank-side authentication domain
                              │
                              └──> Aggregation authorization service (holds tokens)
                                         │ issues only restricted tokens + normalized data
                                         v
                                  AI application backend (read-only)
                                         │
                                         └──> Model inference (sees only redacted, structured summaries)

The backend and inference layers never obtain bank passwords, OTPs, CVVs, or similar credentials. Token storage must go through an independent key-management component (a KMS/HSM-class service), separated from the business database, so that “the application being compromised does not mean the account is compromised.”

2.2 Describe Capabilities with a Whitelist, Not a Blacklist

The first principle of the permission model is default-deny. The capability list should be explicitly enumerated, and the gateway should directly reject any unregistered action rather than maintaining a list of “forbidden actions”:

from enum import Enum
class Scope(Enum):
    ACCOUNT_META_READ  = "account.meta.read"    # bank name, account name, account type
    BALANCE_READ       = "account.balance.read"  # balance, credit limit
    TXN_HISTORY_READ   = "txn.history.read"      # transactions; suggested cap of 24 months
# The following capabilities do not exist in the type system:
# INITIATE_TRANSFER / SCHEDULE_PAYMENT / GRANT_MANDATE / PLACE_ORDER
ALLOWED = {
    "summarize_spending": {Scope.TXN_HISTORY_READ},
    "list_upcoming_bills": {Scope.TXN_HISTORY_READ},
    "flag_outlier": {Scope.TXN_HISTORY_READ, Scope.ACCOUNT_META_READ},
    "report_utilization": {Scope.BALANCE_READ},
}
def guard(action: str, granted: set[Scope]) -> None:
    if action not in ALLOWED:            # reject any unknown action
        raise PermissionDenied(action)
    if not granted.issuperset(ALLOWED[action]):
        raise PermissionDenied(action)

The key point is that the AI side exposes only a small set of semantic “query actions,” rather than exposing the generic create/read/update/delete interfaces of raw account objects to the model. The model always sees action names, never an SDK.

2.3 Minimal Field Set

Within the authorized scope, request only the fields required for analysis. Any field fetched “just to have it along the way” is a compliance liability:

Institution identifier: bank / card-issuer name
Account identifier: account name, account type (checking / savings / credit)
Limit view: current balance, credit limit, and used credit (to compute utilization)
Transaction details: time, amount, direction, raw merchant description, normalized merchant-cluster ID, currency
Time window: default to the most recent 24 months; anything beyond requires explicit second consent

Explicitly not collected: full account numbers of counterparties, ID document numbers, original bill PDFs, and the list of other linked financial accounts.

Consent must be tiered (item-by-item opt-in rather than a single blanket grant), and the revocation path must be as short as the authorization path. In engineering terms, maintain three state maps: token validity, consent-scope version, and data-retention period. After revocation, cached raw transactions should be deleted within an agreed period, retaining only non-reversible aggregate statistics.

3. Delivering Analysis: Turn “Browsing Bills” into a Conversation

Read-only authorization yields the complete transaction history. On top of it, you can build four deterministic capabilities. They suit financial scenarios better than open-ended Q&A because their results can be verified and rechecked.

3.1 Spending Categorization

Categorization uses a two-layer structure of “rules first, model as fallback”: rules built on merchant clusters and keywords cover high-frequency cases first, and the model handles the long tail. The key is to return a confidence score alongside the label. Low-confidence items should prompt the user to confirm rather than being silently dumped into “Other.”

RULES = [
    ("Dining",        {"restaurant", "cafe", "takeaway", "food_delivery"}),
    ("Transport",     {"ride_hailing", "metro", "fuel", "parking"}),
    ("Subscriptions", {"saas", "streaming", "membership"}),
    ("Housing fixed costs", {"rent", "mortgage", "property_fee", "utility"}),
]
def categorize(tx) -> tuple[str, float]:
    for label, keys in RULES:
        hit = keys & tx.merchant_tags
        if hit:
            return label, 0.95            # rule hit, high confidence
    return MODEL_PREDICT(tx), 0.6         # fallback, needs user review

3.2 Anomaly and Unusual-Spending Detection

Relying only on absolute-amount thresholds produces a flood of false positives. The safer approach is to detect relative deviation within the same category and merchant cluster, and to preserve the evidence chain (amount, time, merchant, and the multiple relative to the historical mean):

def flag_outlier(tx, history, min_peers=6, z=2.5):
    peers = [t for t in history
             if t.category == tx.category and t.merchant_cluster == tx.merchant_cluster]
    if len(peers) < min_peers:
        return None                      # insufficient sample, no judgment
    mean = statistics.fmean(p.amount for p in peers)
    sd = statistics.pstdev([p.amount for p in peers])
    if sd == 0:
        return None
    score = (tx.amount - mean) / sd
    return {"txn_id": tx.id, "z": round(score, 2)} if score >= z else None

You also need a false-positive suppression mechanism: merchants or scenarios the user marks as “normal” should enter a personal whitelist so the same expense is not flagged repeatedly. Alert fatigue is the leading cause of failure for products of this kind.

3.3 Subscription Detection and Bill Price Increases

Detecting recurring charges is essentially a three-way constraint match on “merchant cluster + interval regularity + amount stability”:

def detect_recurring(txs, tol_days=3, min_occurrences=3):
    buckets = {}
    for t in sorted(txs, key=lambda x: x.date):
        buckets.setdefault((t.merchant_cluster, round(t.amount, 2)), []).append(t)
    result = []
    for (merchant, amount), items in buckets.items():
        if len(items) < min_occurrences:
            continue
        gaps = [(b.date - a.date).days for a, b in zip(items, items[1:])]
        if max(gaps) - min(gaps) <= tol_days:          # stable interval → suspected subscription
            result.append({"merchant": merchant, "amount": amount,
                           "cycle_days": round(statistics.fmean(gaps))})
    return result

On top of this, run a price-change comparison: when a new amount tier appears for the same merchant cluster across different cycles, surface “this subscription’s price changed from A to B over the past N months.” That is far more actionable than “you have a subscription.”

3.4 Output Forms

The same analysis result should support multiple view renderings: category summaries as charts, bill due dates on a calendar, and credit utilization and cash flow on a dashboard. Technically this is “one query, many projections” rather than letting the model recompute, which avoids figures with inconsistent definitions across views.

4. Language-Layer Design: Explain Terms and Explain Uncertainty

The readership on financial topics spans a very wide range, so the language layer carries two responsibilities.

Terminology translation: When a technical term first appears in the output, attach a one-sentence explanation, for example, “utilization = used credit ÷ total credit, generally considered a comfortable range at 30% or below.” These explanations should come from a controlled phrase library rather than the model improvising, to keep definitions consistent and auditable.

Expressing uncertainty: Distinguish three kinds of statements, using fixed sentence patterns to separate them — verified transaction facts, rule-based inferences, and information that requires user confirmation. For example: “This expense’s amount and merchant match the historical record (fact); it is judged to be rent (inference); if you have recently moved, please confirm the category (to confirm).”

Guardrails: Explicitly do not output buy/sell or recommendation advice on individual stocks, funds, or loan products; when tax, debt, or legal judgments are involved, provide a referral prompt. This boundary should be enforced at both the system-prompt layer and the output-validation layer, not left to the prompt alone.

5. Privacy Engineering: Dual Isolation of Conversation Data and Memory

The sensitivity of personal-finance conversations is close to that of medical records, so privacy design must be grounded in the data flow:

No entry into training: Financial conversations must be tagged with an independent label and filtered out at the data-pipeline layer, with a verifiable sampling audit (for example, spot-check the training set by session ID to confirm zero hits).
No coupling with long-term memory: Do not write balances, transaction summaries, or merchant names into cross-session memory. If you genuinely need to remember user preferences, store only abstracted preference items (such as “tracks subscription spending” or “prefers monthly summaries”), and do not associate them with an account ID.
Redact before inference: Text entering the model context must pass through a cleaning step that intercepts long digit strings, credential-type keywords, and account-number fragments in free text.

SENSITIVE = [
    r"\b(?:\d[ -]?){13,19}\b",              # card number / long account number
    r"(?i)(passcode|password|otp|cvv)\s*[:=]\s*\S+",
    r"\b[A-Z]{2}\d{2}[A-Z0-9]{10,}\b",      # IBAN-like pattern
]
def redact(text: str) -> str:
    for p in SENSITIVE:
        text = re.sub(p, "[REDACTED]", p)
    return text

Transmission and storage: Encrypt across the full chain; encrypt data at rest with keys held separately from the data; log only the action name, latency, result status, and a request-summary hash — never raw amounts or merchant names.
Auditability: Write all data access to an audit log that records the caller, consent version, and field scope, and support exporting a per-user list of “who read my data and when.”

6. Pre-Launch Checklist and Evaluation Metrics

Items that must be confirmed before launch

The permission model is whitelist-based, and write actions are inexpressible in the type system
Bank credentials do not pass through the application or inference layers; tokens are held by an independent key component
The field list is minimal, the time window has an upper limit, and second consent is supported
After authorization is revoked, raw-data deletion follows a verifiable process
Financial conversations are excluded from the training set in the data pipeline, with a sampling audit
Long-term memory stores no account values or merchant details
The output layer blocks personalized investment advice
Audit logs can be exported per user

Suggested quality metrics

Categorization accuracy and the “Other” ratio (a ratio persistently above 15% indicates insufficient rule coverage)
Anomaly-alert precision and user-dismissal rate (a rising dismissal rate signals that thresholds need retuning)
Subscription-detection recall (missing one high-value subscription costs more than over-reporting one)
Terminology-explanation reach and user follow-up-question rate
Number of privacy incidents and number of blocked unauthorized attempts (the latter should be positive, indicating the guardrails are working)

7. Common Anti-Patterns

Treating read-only as “read-only for now”: Reserving write-interface fields in the data model just defers the risk.
Letting the model call the aggregation SDK directly: The model should face only semantic actions; once raw interfaces are exposed, prompt injection can reach more capabilities.
Blanket consent: A single checkbox granting all fields makes precise revocation impossible.
Relying on prompts alone for compliance: Compliance boundaries must be enforced by code and the gateway; the prompt is an experience layer, not a control layer.
Ignoring alert fatigue: Anomaly detection without a personal whitelist and frequency control will eventually be switched off wholesale by users.

In summary, the technical focus of this kind of product is trading the strongest boundary for the narrowest data entry point: keep control over funds in the user’s hands, extract maximum value from read-only data, and provide engineering-grade safeguards for privacy and explainability. Hold this line, and an AI assistant can move from “glancing at a balance” to a genuinely sustainable everyday tool in personal finance.