I built a subscription finder that never uploads your bank statement

pedro acosta — Wed, 28 Oct 2026 17:25:25 +0000

I'm a software engineer, and I built a budgeting app because I was tired of guessing where my money went. One piece of it has its own free page: a Subscription Finder where you drop in a CSV from your bank and it lists every recurring charge. The rule that shaped the whole thing was simple. The file must never leave the browser. This post is about how that works and the parts that turned out harder than I expected.

No upload endpoint, so nothing to leak

The page is a client component. The file is read with file.text() and parsed in the browser. There is no API route that accepts it, so there is nothing on my server that could store or leak a statement. That is a stronger promise than a privacy policy, because it holds even if I make a mistake later.

One honest detail: when the tool runs it logs a single analytics event with counts only, how many recurring charges it found, how many possible ones, and how many months the statement covers. No file, no merchant names, no amounts.

Reuse the real detector, not a toy one

The free tool calls the same recurring detector the app uses, so the two never disagree:

const charges = txns.filter((t) => !NOT_A_CHARGE.test(t.name));
const recurring = extractSubscriptions(detectRecurring(charges, null));

Here is what detectRecurring does. It groups charges by normalized merchant name, direction, and account. A group needs at least three charges spread over at least two weeks. It takes the median gap between the dates and snaps it to a frequency such as weekly, biweekly, or monthly. Then it averages the amount after dropping anything more than 20 percent from the median, so a late fee on a phone bill does not drag the number around.

The null argument matters. The app normally looks at a rolling window of the last few months, but an uploaded statement can end months ago, so the finder asks it to use every transaction.

One statement has no other accounts

Inside the app, transfers between your own accounts are removed by matching them across accounts. A single CSV has nothing to match against, so the finder filters by name instead:

const NOT_A_CHARGE =
  /TRANSFER|\bXFER\b|PAYMENT THANK YOU|AUTOPAY PAYMENT|ONLINE PAYMENT|\bZELLE\b|\bATM\b|DEPOSIT|INTEREST (CHARGE|PAID)/i;

It is a heuristic and it will sometimes be wrong. I would rather show a slightly noisy list than hide real subscriptions.

Short statements need honest handling

Three charges are the minimum, so a one month statement cannot show recurrence at all. I handle that two ways. A list of well known subscription merchants flags a charge seen only once as a possible subscription. And if the tool finds nothing and the statement covers less than three months, it says that is probably why, instead of implying you have no subscriptions.

Real bank files are messy too. Some banks put a few account summary lines above the header, so the parser looks through the first 15 rows for the real header with date, description, and amount columns. Billing phone numbers get stripped from merchant names, so "HULU 877-8244858" and "HULU" are not listed twice.

What I would tell another developer

If a privacy promise can be structural, make it structural. No upload endpoint beats a paragraph in a policy.
Reuse the product's real logic for a free tool, so the free version and the product agree.
When the input is too small to answer the question, say so. Tell the person what you cannot see.

If you want to try it, it is free and needs no account: https://finsight.it.com/free-subscription-finder. It is part of FinSight, a budgeting app with an AI assistant that explains your money.

How I built an AI that explains your money, with no way to touch it

pedro acosta — Mon, 26 Oct 2026 18:49:58 +0000

I'm a software engineer, and I built a budgeting app because I was tired of guessing where my money went. The part people ask about most is the AI assistant, so this post is about the one design choice that shaped all of it: the AI can read a snapshot of your finances, and it has no way to do anything else.

The stack is Next.js, Prisma, Clerk for auth, Plaid for bank connections, and Claude for the assistant, streamed through the Vercel AI SDK. Here is how the read-only part works.

Layer one: the bank connection only reads

When someone connects a bank, the Plaid Link token asks for exactly one product, Transactions. There is no payment initiation product in the request, so even a bug on my side cannot create a transfer. It is a boundary the bank enforces, not a promise in my code.

Layer two: the model gets a snapshot, not a database

The assistant does not run queries and it has no tools. Before each chat turn, the server builds a text summary of the user's finances (account balances, three months of cash flow, spending by category, budgets, goals, and upcoming recurring charges) and passes it as the system message:

const systemContext = await buildAiContext();

const result = streamText({
  model: anthropic("claude-sonnet-4-6"),
  system: systemContext,
  messages: messagesForModel,
  maxOutputTokens: 1024,
});

The model can only talk about what is in that snapshot. It cannot fetch more, write anything back, or call out to anything. If the model misbehaves completely, the worst outcome is a bad answer on screen.

I considered giving it tools, so it could look up arbitrary date ranges. I decided against it. Every tool is a new way for a prompt to cause a side effect, and for a money app the extra flexibility is not worth the new attack surface. A bigger or better organized snapshot solves most of what tools would have solved.

Layer three: cache the snapshot, retrieve the rest

The snapshot is the expensive part of each request, and it barely changes between messages in one conversation. So it sits in the system message with Anthropic's prompt caching turned on:

providerOptions: {
  anthropic: { cacheControl: { type: "ephemeral" } },
},

Follow up questions in the same session reuse the cached prefix instead of paying for it again.

For general money questions that are not about the user's own data, like "what is an avalanche payoff", I retrieve a few articles from a small knowledge base and put them in the last user message. They go there on purpose. Retrieval results differ on every turn, so putting them in the cached system message would break the cache every time. A failed lookup falls back to the plain messages, so retrieval can never take the chat down.

Layer four: boring guardrails

Monthly message quotas are enforced per plan and counted in the database, and a Redis rate limit sits in front of everything as an abuse guard. The request body is validated with Zod, and the message list only allows user and assistant roles. A client cannot smuggle in a fake system message, because the Messages API has no system role inside the list at all, and I restrict the schema to match.

What I would tell another developer

Decide what the model must never be able to do, then make that impossible at the boundary, not in the prompt.
Prefer a good snapshot over tools until you can name a specific question the snapshot cannot answer.
Put stable context in the cached prefix and volatile context in the user turn.

If you want to see the result, the app is FinSight at https://finsight.it.com, and there is a free tool that finds recurring charges in a bank statement CSV without an account: https://finsight.it.com/free-subscription-finder. I'm happy to answer questions about any of this in the comments.

DEV Community: pedro acosta

I built a subscription finder that never uploads your bank statement

No upload endpoint, so nothing to leak

Reuse the real detector, not a toy one

One statement has no other accounts

Short statements need honest handling

What I would tell another developer

How I built an AI that explains your money, with no way to touch it

Layer one: the bank connection only reads

Layer two: the model gets a snapshot, not a database

Layer three: cache the snapshot, retrieve the rest

Layer four: boring guardrails

What I would tell another developer