Mint already uses Plaid, but I the transaction information it gets is too low in information to categorize anything reasonably. For example my Amazon Grocery transaction happen on my amazon Chase Credit card(gives me 5% discount).

But connecting to Chase.com using plaid pulls in transaction statement is still information poor. The obvious consequence of this is that budget information is not correctly reflected in Mint(that info is actually in my Amazon.com silo). The only way to fix this rn is sadly manually.

As a tangent, I do feel though that LLM agents that can one day act on individuals behalf, reading info and making this manual job far more easier in absence of any govt regulations.

Mint does not use Plaid. Intuit has their own service for integrating with bank APIs and/or screen-scraping that they use across all their products.

They used plaid as a fallback for some banks

Copilot Money achieve Amazon SKU description automatically by AuthN into your Amazon account and transaction matching.

They do this lack of info lift and then recommend category splits.

Fighting with Mint and categorizing Amazon purchases was what initially pushed me down the path into plain text accounting (PTA).

I ended up long down the rabbit hole with auto-downloading Amazon orders (originally with https://github.com/jbms/finance-dl, but then my own custom scraping) and importing and matching them up with credit card transactions using beancount-import (https://github.com/jbms/beancount-import).

This ultimately resulted in me spending a lot less on Amazon - to the point that now doing it manually wouldn't be too bad...

I can try to improve import functionality, but Plaid etc is quite hard. I can't even figure out their pricing model from their page. So, as a free app I don't think it can support Plaid.

[I work at Plaid] The pricing model is here: https://plaid.com/docs/account/billing/ but @jpeeler is right that for a free app like this aimed at an audience of engineers you could also set it up for your users to BYO Plaid API keys.

This is the precise option I was thinking might be possible. Is it even reasonable for an individual developer to use their own API keys for something like this? I assume because you suggested it, it is. Any limitations that are impractical for personal use?

I'm in the middle of going down this path right now. It kind of works, except for certain banking institutions require more rigor than just getting accepted into the developer platform.

The steps, as far as I can tell, look something like this:

1) Sign up for Plaid developer account

2) Request developer access (without it you can only play with sandbox data)

3) Request production access

4) Submit application information including a name, website URL, and logo

5) Add a legal company entity name and address to my plaid account

6) Sign an MSA contract (no idea what its about)

7) Fill out a security questionnaire.

I'm at step 3 currently but I'm not sure how much further I'm realistically going to get. I'm not sure I could reasonably fill the rest without stretching the truth quite a bit and it seems to get deep into legal territory that I'm not sure I'm comfortable with.

There's also apparently different API behaviors depending on the bank: https://plaid.com/docs/link/oauth/#institution-specific-beha...

I don't have a lot of hope that this is going to pan out. I'm considering just scraping Chase with a headless puppeteer script instead.

It's possible that this may be simpler for other banks though, I've only tried Chase since that's my primary bank.

[I work at Plaid]

I will say that while annoying (especially for Chase, which has the most paperwork-type requirements for developers) this process should be totally doable for solo developers. You can put your own name as the legal entity name if you don't have a company. The Master Services Agreement (MSA) sounds scary but is just the contract between you and Plaid -- the legalese laying out what you're paying for, what Plaid is providing, and the rights and obligations of both parties. And when it comes to the security questionnaire, fill it out as accurately as you can, but you don't need to stress over it -- Plaid doesn't expect a solo hobbyist to have the same security measures as, like, a publicly traded company.

Thanks for the info -- this is really good to know. I'll keep pressing on as far as I can!

Can confirm: I did this as a solo user of a personal API integration with Chase via Plaid. I answered honestly given the scope of what I was doing: for example, IIRC there was a question about whether all employees are background checked, and another about how we deal with terminated employee access. As the only user/employee/human, I could confidently say I background check all my employees and that if they’re terminated, their access will be promptly revoked :D

Thank you! I wish Plaid would document this on the website. I've always been hesitant to convert from my dev account to a production account because everything gives the impression you're looking for a Serious Business.

I'd much rather just pay the money and have the standard API, and my workflows are all built around Plaid anyway.

I guess I'll give it a go now.

How much would it generally cost for a user? I couldn't figure it out from the pricing page.

You just need to have each person create their own Plaid account (which is probably the way you want it anyway). The free tier supports 100 institutions.

Last time I looked at this, I thought it was stated that the free/sandbox tier is not guaranteed to have the same SLA as the production environment. But I can't find this in the documentation anywhere.

[I work at Plaid] I don't know if we explicitly write down in the docs that the free Development tier isn't guaranteed to have the same SLA as the production environment, but if you're not paying Plaid there is no SLA (I mean, the usual recourse for an SLA breach is a rebate, but you can't give a rebate to someone who isn't paying you in the first place). That said, in practice the differences between the free and paid tiers for a personal finance app are not really such that someone doing a hobbyist app for personal use would notice them.

Correct me if I'm wrong but some of the banks don't work in developer mode at all (at least, it doesn't seem to work with Chase).

All banks work in the free Development environment, but for banks on OAuth, including Chase, you need to go through the Production approval vetting as a pre-requisite. Once you've been approved for Production (and if applicable for the given bank, gotten your security questionnaire approved as well -- I think Chase requires this) you can then access those banks in Development for free.

I would use this if there was an easy way to integrate it with plaid. (login once and keep data synced). This would be comparable to personal capital at that level.

I know this is only vaguely related, but as a European that's been looking for an open source budgeting solution, how does PSD2 help?

My understanding of PSD2 is that it requires banking transactions to be "machine-readable" whatever that means. So there's an actual legal requirement for making data accessible outside of the browser.

The problem I faced when I looked at data export was that none of the banks had any apis. You always had to go through 3rd party commercial apis. Maybe there are ways bur I didnt find them

If you're talking about European banks they all have APIs. But only licensed companies can use them directly. Those companies are called AISPs within the PSD2 framework, sometimes referred to as aggregators. Some of them have ways for individuals to access their own accounts at banks via the AISP APIs. But there are limitations, one major one being that PSD2 doesn't cover credit card data or anything other than deposit accounts. [I'm a product manager at a bank]

you should check out Actual budget as well - works perfectly for me in the same situation.

What is PSD2 and why is it important? Is it the basis for something like UPI in India?

Payment Services Directive 2 and it’s basically legal stuff we gotta comply with to do payments. Can’t speak for India but it’s v much something in the UK

It basically means OpenBank API mandatory just to financial companies, not to consumer, potentially any enterprise can ask to have OpenBank API access if it meet certain criteria and then it can get and commit any transaction from all EU banks. So potentially offer to their customers full API access to their EU banks, for anything, disposing transactions as well locally instead of via some crappy website. This also means having legally valid local transactions (XML/XADES or JSON/JADES signed by the bank).

One option I'd recommend for anyone working towards this is to use the SimpleFIN Bridge [0], which is basically an API wrapper around MX (a Plaid competitor) designed for personal use by the same people that make Budgeting with Buckets. Data security is definitely an issue, but I value having my transactions automatically imported more than I'm concerned about the risk of SimpleFIN being breached.

I've personally used SimpleFIN to provide automatic imports in my own personal, kind-of selfhostable personal finance tool [1].

[0] https://beta-bridge.simplefin.org/

[1] https://github.com/avirut/bursar

Wow, very cool thank you for sharing!

Reason are not obvious to me. Could you elaborate?