For me I simply had a spreadsheet with rows for each month and columns for each account: chequing, mortgage, RRSP, RESP, etc. I’d spend 10 mins a month logging in and typing out each balance. I’d chart the over-time trend and that’s all I needed to detect any changes in habit or ugly trajectories. 90% of what signal I needed with 10% of the effort.
If you don’t need to micromanage all your flavours of spending or other details, consider keeping it dead simple.
I find that once I normalize against the price movements of my goals, the significantly positive trend becomes much less significant. Since I am relatively young with likely a couple decades or more work left in me, I like to benchmark against a low cost broad market equity index ETF.
I ported it to Qt for Linux last year and still use it, but to be honest, I don't really know why I track my finances that religously - although it has helped me a few times with accounting / tax purposes given I'm a contractor now.
I suspect one of the reasons there are so many different solutions is everyone wants to do things differently, and integration with the banks for automated transaction import/download is quite complicated.
All of my financial history is contained in a text file processed by beancount and long may it continue!
One thing I do wonder though is how well it scales, I'm a single man so tracking everything isn't too much effort but if I had a partner it suddenly becomes at least 50% more things to track
I love these command line self hosted accounting software packages. But double entry bookkeeping was invented using ledgerbooks with ruled tables. I feel the plain text dataformats are a regression compared to a sql database. A general ledger just works so well with columns that you can sum.
It also saves you from needing a custom tool like bean-query to replicate sqlite-ish queries because it could have been in a database from the start
And on a somewhat unrelated note: his book on building data-intensive applications is another goldmine (on a different topic).
I use the envelope style. Every dollar is assigned a bucket when it comes in. All spending is done from a bucket and balances always persist. I don't like monthly budget targets. I prefer to put money in a bucket when the money comes in.
I might move back to plain text accounting as it is so flexible. I will miss the amazing interface to Lunch Money. I also like supporting a small business like Lunch Money.
> Recall that the flow of money in double-entry accounting is represented using transactions involving at least two accounts. When you download CSVs from your bank, each line in that CSV represents money that's either incoming or outgoing. That's only one leg of a transaction (credit or debit). It's up to us to provide the other leg.
> This act is called "balancing".
Balance (accounting) https://en.wikipedia.org/wiki/Balance_(accounting)
Are unique record IDs necessary for this [financial] application? FWICS, https://plaintextaccounting.org/ just throws away the (probably per-institution) transaction IDs; like a non-reflexive logic that eschews Law of identity? Just grep and wc?
> What does the ledger look like?
> I wrote earlier that one of the main things that Beancount provides is a language specification for defining financial transactions in a plain-text format.
> What does this format look like? Here's a quick example:
option "title" "Alice"
option "operating_currency" "EUR"
; Accounts
2021-01-01 open Assets:MyBank:Checking
2021-01-01 open Expenses:Rent
2021-01-01 * "Landlord" "Thanks for the rent"
Assets:MyBank:Checking -1000.00 EUR
Expenses:Rent 1000.00 EUR
People use other flags to indicate, for instance, whether a transaction has been reconciled, or cleared their bank, or whatnot.
https://github.com/csingley/ofxtools
</shameless plug>
I just added a link to it on https://awesome-beancount.com/#tools.
For budgeting, I import csv from my bank/credit cards into google sheets and tag transactions with ~20 different categories - I do this every month or two and it doesn't take that long. It gives me a backwards view of my spending that I can use to influence future spending. I don't run a hard budget really.
We have this feature at Nordigen (I'm the cofounder), where we allow developers to download their bank statements in JSON format from 1,000+ European banks (free): https://nordigen.com/en/blog/download-your-bank-statement-js...
"in order to derive statistical models for future data enrichment purposes", "to improve the performance and accuracy of the Services", "to improve Your experience while using the Services" and "to send Users and website visitors relevant informational content regarding Services and personalized offers they subscribed to".
"Nordigen may also provide personal data to companies that process personal data on behalf of Nordigen such as marketing service providers." - wonderful, thank you for doing that. not.
GDPR requires you to be more specific in terms of "purpose", to actually list your data processing partners, what purpose the data sharing with that particular partner serves, and which data exactly is shared with which partner.
At the end of every month, banks send out statements so importing all transactions aren't necessary to keep track of one's overall financial standing.
Banks do make mistakes but extremely rarely that it's not worth wanting to import all transactions in the off chance that you'll catch a mistake. Retailers can make mistakes like double charge you but again those are rare and you can take a quick look at your statements to find them usually.
Keeping track of individual transactions are important to be able to figure out where the money is going in general but this doesn't require keeping track of 'every' transaction. Just the ones that make up the biggest percentage of the total money spent. They are usually easy to spot on the bank/creditcard statements.
One doesn't even have to be perfectly accurate to gain from inspecting statements either. You spent $834.56 for new tires? You can enter that as $850 and it's fine.
Sure, there might be cases where the total is split more or less evenly across several small transactions and that can be handled similarly to the above.
Knowing where the money is going isn't terribly useful actually unless there are a lot of frivolous spendings. It usually comes down to "you are not making enough money" or "the lifestyle you desire is too expensive for your current income". No app can fix either of these, other than point out the obvious problem. Most personal finance blogs end up leaning towards "how to earn more" because that's more important than keeping track of your transactions or budgeting.
I personally find the topic difficult and comes with a lot of nonsensical jargons.
It’s not targeting technical users but it would be cool to add a SQL integration like Stripe Sigma, etc at some point.
> No, your personal data is not sold or rented or given away or bartered to parties that are not Plaid, your bank, or the connected app. We talk about all of this in our privacy policy, including ways that data could be used — for example, with data processors/service providers (like AWS which hosts our services) for the purposes of running Plaid’s services or for a user’s connected app to provide their services.
>> I saw that. Thank you for your patience and persistence in responding to so many pointed questions.
>> For any interested, here is a link to relevant section of the referenced privacy policy: https://plaid.com/legal/#consumers
>> I am also impressed by the Legal Changelog on the same page that clearly lays out a log of changes made to privacy & other published legal documents.
Many thanks to Simon Michael for not only that wonderful program but also being so responsive.
I also had a good collection of scripts to manage my finances. I ran it all on a VPS so I could access anywhere. I had an ssh client on my phone to make changes on the go. Not as ergonomic as an app but it worked.
Agreed Simon is an amazing project owner. He and his documentation are the reasons I like HLedger over the alternatives.
I'll admit that GoDBLedger is also tempting.
I have a report that does how much money I spent per period that is unaccounted for, that's money that got spend on "miscellaneous". As long as that number is beneath some threshold that I consider acceptable I let it be. If it's high, I might look back and try to determine where my money went and make adjustments.
The guiding principle behind this approach is resilience to laziness. It's not an all or nothing system, instead it gives me whatever I give it. If I am busy and don't enter as many transactions, no worries - I'll just have more in the miscellaneous category. If I don't track my balances every month, the period will be longer. But the system always "balances".
The system also serves as a log for bigger purchases. When did I buy that fridge? How much did I pay? What is the exact model number of that piece of equipment in case I need to buy it again? I can search my transaction log.
You only need to write Python code if you're using the Beancount importers framework and intend to use bean-identify and/or bean-extract.
Anyway, while it's FOSS it's not really packaged for easy reuse. You'd need to set up a server and configure it. It might be good as inspiration or as a starting point for your own project though, so you're still interested I can log in to LinkedIn later and message you there.
Banks should implement read-only OAuth APIs, so that users are not required to store their u/p/sqa answers.
From "Canada calls screen scraping ‘unsecure,’ sets Open Banking target for 2023" https://news.ycombinator.com/item?id=28229957 :
> AFAIU, there are still zero (0) consumer banking APIs with Read-Only e.g. OAuth APIs in the US as well?
Looks like there may be less than 3 so far.
> Banks could save themselves CPU, RAM, bandwidth, and liability by implementing read-only API tokens and methods that need only return JSON - instead of HTML or worse, monthly PDF tables for a fee - possibly similar to the Plaid API: https://plaid.com/docs/api/
> There is competition in consumer/retail banking, but still the only way to do e.g. budget and fraud analysis with third party apps is to give away all authentication factors: u/p/sqa; and TBH that's unacceptable.
> Traditional and distributed ledger service providers might also consider W3C ILP: Interledger Protocol (in starting their move to quantum-resistant ledgers by 2022 in order to have a 5 year refresh cycle before QC is a real risk by 2027, optimistically, for science) when reviewing the entropy of username+password_hash+security_question_answer strings in comparison to the entropy of cryptoasset account public key hash strings: https://interledger.org/developer-tools/get-started/overview...
No. Plaid did agree to pay the $58 million, and the lawsuit was for alleged data sharing with third parties without user consent. I don't care if they admit guilt or not. They agreed to pay $58 million to end the lawsuit, and that does not engender trust. Shifting the blame to banks doesn't make Plaid any more reputable.
Providing usernames and passwords of sensitive accounts to a third party is a privacy and security risk, and Plaid has not earned enough trust from me to justify the risk I would need to assume to use their services.
From https://my.plaid.com/help/360043065354-does-plaid-have-acces... :
> Does Plaid have access to my credentials?
> The type of connection Plaid has to your financial institution determines whether or not we have access to the login credentials for your financial account: your username and password.
> In many cases, when you link a financial institution to an app via Plaid, you provide your login credentials to us and we securely store them. We use those credentials to access and obtain information from your financial institution in order to provide that information, at your direction, to the apps and services you want to use. For more information on how we use your data, please refer to our End User Privacy Policy.
> In other cases, after you request that we link your financial institution to an app or service you want to use, you will be prompted to provide your login credentials directly to your financial institution––not to Plaid––and, upon successful authentication, your financial institution will then return your data to Plaid. In these cases, Plaid does not access or store your account credentials. Instead, your financial institution provides Plaid with a type of security identifier, which permits Plaid to securely reconnect to your financial institution at regularly scheduled intervals to keep your apps and services up-to-date.
> Regardless of which type of connection is made, we do not share your credentials with the apps or services you’ve linked to your financial institution via Plaid. You can read more about how Plaid handles data here.
What do you think this should say instead?
Do you think they use the same key to securely store all accounts, like ACH? Or no key, like the bank ledger that you're downloading a window of as CSV through hopefully a read-only SQL account, hopefully with data encrypted at rest and in motion.
When you download a CSV or a OFX to a local file, is the data then still encrypted at rest?
Again, US Banks can eliminate the need for {Plaid, Mint, } as the account data access middlemen by providing a read-only OAuth API. Because banks do not have a way to allow users to grant read-only access to their account ledgers, the only solution is to securely store the u/p/sqa. If you write a script to fetch your data and call it from cron, how can you decrypt the account credentials after an unattended reboot? When must a human enter key material to decrypt the stored u/p/sqa?
Here, we realize that banks should really have people that do infosec - that comprehend symmetric and assymetric cryptography - audits to point out these sorts of vulnerabilities and risks. And if they had kept current with the times, we would have a very different banking and finance information system architecture with fewer single points of failure.
And Plaid's terms of service (https://plaid.com/legal/#how-we-use-your-information) contains vague catch-alls such as:
> We share your End User Information for a number of business purposes:
> With our data processors and other service providers, partners, or contractors in connection with the services they perform for us or developers
Sure, it would be great if banks offered different authentication systems, but that has nothing to do with my lack of trust for Plaid. A different authentication system wouldn't eliminate the data sharing concerns I have with Plaid.