It's focussed on read tools at the moment, but we have write tools coming (money transfers, debt paydown, etc)
Check it out and let me know if you'd like to see any particular features landing - just email alex at the above domain name.
For background context I'm Alex the CEO, I'm ~new to HN but was the former head of web presence at stripe.com and was at Square / CashApp before that. Hi!
From there, Supabase MCP or psql gives Claude/Codex access to the transactions/balances for english queries. Really impressed with their ability to find subscription patterns, abnormal patterns, etc. Also to predict cashflow which no online tool so far is good at i.e. "tell me how much cash I can move to savings based on my monthly spend patterns and available cash".
For autocategorization, I learned Claude is really good at custom DSLs. Had it create a markdown table based ruleset to normalize payee/categories. I also run the autocat rules as part of the GitHub actions.
I'm doing something similar with Tiller (which I've been using since Mint was acquired by Intuit).
It's neat to see how OP did this using a Claude Routine though. My version locally uses a local qwen model + an API key (annoyingly created using OAuth) with sheets access. A Claude Routine would've been significantly easier
Here's the initial spec it created. I started off writing to a local sqlite db instead of Supabase: https://gist.github.com/cowlby/0dbeb52403c3f3c0f1d8122505203...
Edit: Here's also the DSL categorization spec. First one was string based, found it cumbersome, so second one was the Markdown table refactor: https://gist.github.com/cowlby/30d6b5cf132fc1424ab146f0eaf4a...
https://gist.github.com/cowlby/d569c8e05b5b6eecfd4d237372c06...
(edit: put in Gist instead of inline here)
They have an api and I got llm to write a CLI for it.
That way agent can pretty much pull the data it needs or wants.
One thing I also had it do is build up a series of rules for tagging which then I run a cron for once a day.
Every once in a while I just ask it to look over the rules and make new ones for uncategorized transactions.
(As a side note I think having LLM “memoize” a task through a rule engine or code is really nice pattern)
But once you have the cli with query you can pretty much ask the agent to do anything.
I think my only request is to expose the rules engine as a declarative api in v2.
I ended up locally caching the transactions data, using cel/aip-160 as a rules engine then having the script apply the results on the data.
The other use case funnily enough was to ask how much I’m spending on hobby dev.
Make sure I’m not getting carried away across llm subscriptions, as well as cloud costs.
I think the nice part is once you have the cli you just use the agent in your ide as your chat interface.
- Backend & CLI are both strictly linted Rust. The webapp runs on Axum (Rust web framework), and connects to Postgres via sqlx.
- Financial read-only. There's no transfer, pay, or send tool in the product. Nothing in the AI surface can move money.
- We request transactions, investments, and liabilities from Plaid. We don't request auth, transfer, or payment_initiation, so we never receive full account numbers or routing numbers — just the last-4 mask Plaid returns by default.
- Bank usernames and passwords go to Plaid Link, not us. We only hold a per-institution access token.
- Plaid access tokens live in a separate database behind a single custody Cloud Run service, encrypted at rest by Cloud KMS. The broker calls KMS's encrypt/decrypt endpoints — the root key material never leaves Google's HSM boundary and the broker's service account is the only one with encrypt/decrypt permissions. The web app doesn't have permission to read that database.
- Every encryption and decryption call passes the Plaid item ID as AAD (additional authenticated data). A ciphertext from one item cannot be swapped in and decrypted as another item's token.
- Each Cloud Run service (including our web app) runs under its own cloud identity and with its own DB role.
- Internal calls between services are authenticated: the caller presents a short-lived identity token from the cloud provider, and the receiver verifies it.
- The prod databases have no public IP. Secrets live in managed secret storage, not in source or container images.
- The AI connector is OAuth 2.1 + PKCE, scoped per user, revocable from the UI. Every tool call records the tool name, sanitized args, calling client, and the reason the agent supplied, so you can see what your LLM asked on your behalf.
- There are no fetch-URL, shell, or general I/O tools in the AI surface. Tools return structured financial data and nothing else.
- Networking, IAM, and DB grants are all in Terraform. All infra changes go through that path.
- Infra access is gated by 2fa and security keys.
or worse, a Show HN?,
at least indicate why.
It feels like all I’ve done today is Vouch comments that have no indicated reason for being Dead.
I don't quite understand the desire to have these verbose summaries that you have to read from LLMs. You'll notice anomalies if you just categorize each of your expenses every so often (easy with Tiller).
I actually built it for myself initially, and my wife. So I just built what we needed/wanted.
There will be a huge variety of products in this space and ours is just one take on the problem. I love seeing anything that's taking a shot at it.
It's the ease by which LLMs can ingest and combine various data sources.
I recently needed to set up some calendar events on certain dividend days, but of course, didn't know what those dividend dates actually were. So we used the MCP connector to retrieve our current Vanguard holdings, had GPT-Pro do web research to pull all the dates, and then created calendar events from that. Worked well.
I don’t understand how anyone is OK with this. It goes against every security principle and it’s against the terms and conditions of every bank.
I realize that almost no bank provides a secure and proper API to get info and/or to transfer funds, but Plaid’s solution is a disaster waiting to happen.
The problem is that there sort of isn't a better way right now in the US, and for now, Plaid or a Plaid-like competitor is the safest way. Eventually, it would be awesome if there were clean, open APIs, and standards around this, but for now, it's the best we have.
The alternative of course for the DIY-er is some sort of browser automation, which honestly, is what I tried first. I really wanted it to work, but it didn't - which led us to Plaid.
So then the correct thing to do is to not automate this, until there is a better way. Why would you willingly give your bank credentials to a third party just so you can get some summary emails?? It doesn’t make any sense.
When we built our Plaid integration it used OAuth and a redirect. Plaid just got an access token, you enter your user/pass at bank side.
Edit: Seems like smaller/local banks are probably the ones that won't support OAuth. We didn't support those.
When I'm dealing with my finances the 95% time Claude is correct and doesn't hallucinate is not enough as I have to be vigilant and review its work all the time. So it kinda makes it worthless in this case for me
For the non-Plaid assets eg., home, car, etc., we just added custom asset MCP tools so you can manually add those and they're included in your computed net worth.
Now for the criticism: back in the day mint.com was mind-blowing. It's what you always thought you'd wanted. The graphs were interactive and pretty and you really loved seeing them go up. Not so much down. I was so attached to the gamified aspects, much like step counters. They reinforce habits.
My mint journey ended with roughly 5 years or so of data, once they sold to Intuit, didn't like the ads and willingly syncing all my data to mega-corp. Much like Duolingo, it felt good at the time, but I don't know that it did anything for me at all.
Tracking is a double-edged sword: it really does build better habits. It's better to track weight every day for example so you better understand that fluctuations are mostly noise. The daily tracking stuff is entirely useful to get the need to track daily out of your system.
TLDR: checking my net-worth daily sounds like something I should coach myself out from. Ironically that probably takes tools, but the end goal is to not need them.
- We have a built-in CSV export tool in beta right now for cash transactions, and plan to add this for other datasets as well. You should be able to download your data when you want it. It's yours.
- Yes, tracking is great, but it also has a dark side. My sort of vision, at least for what I want, is less of a gamified finance tracker and more of an ambient, always-on agent that's watching for me. It knows my preferences, it knows what I care about, and it tells me when it finds something.
- Before we get there though, for now, it's really interesting to sort of tinker and build your own custom finance automations. As a programmer, it just feels liberating to get the data out of some closed banking app and into a space I'm comfortable in.
- Especially from an investing standpoint, it's been neat to pair our MCP with a much smarter model like 5.4 Pro and have it do long-horizon research tasks that require a lot of web research and correlation.
Quote of the week for me. well said.
~15 years ago I fumbled around with web programming basically because I never learned how to use excel in school. Nerded out with css, html, forms, then php and mysql to script together an unbelievably worse version of what a spreadsheet could do, but it was incredible that I could build something entirely made for my idea. And with the power to improve it.
Thank you for writing and sharing your story, it's motivating and comforting even. Good luck!
Just this morning, we stood up a demo email agent (basically, email back and forth with Claude with our MCP server connected, providing the data) and it's strangely comforting to chat with it. There's something about the medium of email and how it just works because that's where you're already used to talking with your financial advisor.
There's a lot of nuance in how it's built though, and everyone has different preferences, so to start with the focus is really on building an agent-friendly MCP.
Actually, as part of publicizing our new hobbyist-friendly onboarding, we're looking to work with hobbyists who have created Plaid-powered apps and would be interested in making a short video about their app and their Plaid experience to potentially be featured on the Plaid blog -- if you're interested, shoot me an email at ahoffer@plaid.com and I can send you the details.
In fact, we actually just this week launched a new sign-up flow to make it waaaay easier for non-businesses to use Plaid, so try checking it out -- after you go to dashboard.plaid.com and create an account, you should see a "Free trial" button show up on the homepage with a link to use the hobbyist onboarding flow.
Dear company who has extensive military contracts and is founded in stealing data from people here is every single financial transaction I have ever made! Please don't use it for surveillance pricing tee hee.
At least apple credit cards give you money for that rather then the other way around.
And I totally hear you -- we had this happen in our family as well, and it was really sad. Security is a massive priority for us, but it's always going to be a cost-benefit analysis for each person.
Happy to share more about our infra in a follow-up post.
A company working with Plaid has to request separate product "scopes" through Plaid in order to be able to move money.
I seriously hope this doesn't happen by the way but yea. This is not for me.
If I were interested in this though, yea, a local LLM would be the only way.
That’s where the fear is coming from - not robots.