November 9, 2026 · Trust
“Read-only” is doing a lot of work in that sentence
Claude can now read two years of your bank transactions. The permission is narrow and the promise is reasonable. The questions worth asking are the ones that never make the blog post.
Anthropic's new Personal Finance tool connects Claude to bank and credit card accounts through Plaid, then answers questions about where the money went. It is read-only, which the company is careful to explain means it cannot move, manage or invest your money.
That is true, and it is also the least interesting part of the design. The interesting part is the scope: the bank's name, the account name and type, the last four digits, balances, credit limits, and up to two years of transaction history.
Two years is not a small grant. It is a detailed map of where you live, what you drive, who you support and what you are being treated for, inferred from merchants and amounts. Read-only access to that is still access.
What read-only protects, and what it does not
Read-only protects the balance. It does not protect the pattern. The risk of a financial assistant is not that it empties the account; it is that the record of your life now sits in one more place, governed by one more retention policy, owned by one more company.
Anthropic says conversations inside the finance hub are not used to train models. That is the right promise, and it is also a promise you cannot audit from the outside. So the practical questions are about copies: what is logged, for how long, and what happens to the summaries when you disconnect.
Five questions for any tool that wants account access
Scope. Which fields, exactly. "Transaction data" can mean merchant and amount, or merchant, amount, location, timestamp and memo. The second list is a different product.
Retention. How long is the copy kept after I revoke access? Revoking a connection and deleting a copy are two different operations, and only one of them is usually in the settings menu.
Derivation. Are categories, summaries and embeddings stored separately? Those survive the deletion of the underlying rows, which is precisely why they matter.
Sub-processors. Who else touches it — the aggregator, the model provider, the analytics vendor. Each one is another policy you have agreed to without reading.
Export and exit. Can I get my data out in a usable form, and can I prove it is gone? If the answer to either is a support ticket, the answer is no.
Why this matters beyond personal finance
The same shape is arriving at work. Expense reports, supplier invoices, reconciliation, procurement approvals — all of them are transaction feeds that an assistant could read, and the pitch will be identical: read-only, no training, revocable.
The difference is that a company's transaction history is not one person's privacy problem. It is a commercial secret with a legal retention obligation attached to it. If a tool ingests three years of supplier invoices, you have created a copy of your cost structure inside a system you do not control, and you will be asked about it in an audit long after the trial ends.
What to put in the contract instead
Three clauses do most of the work, and none of them is exotic.
A deletion certificate. Not "we will delete on request", but a written confirmation within a stated period, covering derived data and backups, issued on request without a support escalation.
A sub-processor list with notice. You want to know when a new model provider or analytics vendor is added, before it is added, and you want the right to object. Most standard terms give you neither.
A defined scope of ingestion. Named systems, named fields, named history window. "Whatever the connector can reach" is how a pilot quietly becomes a full copy of the finance system.
If a vendor will not sign those three, the product may still be good. It is just not ready for your data.
The design choice that would settle it
The strong version of this feature lets you grant access per account and per period — last ninety days, one card, one category — and shows you, inside the product, exactly what was read and when. Not a policy page. A log.
That is not what shipped, and it is not a scandal. It is early. The first generation of any access feature is coarse; the second generation is where the audit trail appears, usually after somebody has been embarrassed in public.
Read-only is a good default and a weak guarantee. The question worth asking is not whether it can move your money. It is what it will know about you in a year, and who else is allowed to read that.
We publish the pricing model, minimum commitment and export-readiness notes for every tool in the library, and we flag it when a vendor changes one without changing the headline price.