I remember when Microsoft Money was Sun downed, I thought Quicken had beaten them. But it seems Inuit still has financial problems and sold Quicken.
https://www.microsoft.com/en-us/search/result.aspx?q=Money+p...
Most banks had to provide an API for MS-Money to download data from them, and not all banks support that API anymore.
You might find that some banks still provide MS-Money format files for download that you can import.
Here is how you used to do it for an unsupported bank: https://support.microsoft.com/en-us/kb/836196
Some banks still support MS-Money others do not.
MS-Money will take QIF or QFX files and import them I think.
Even if your bank does not support MS-Money file formats you can find a converter here: http://ms-money-file-converter.en.informer.com/
I think Quicken is more advanced than MS-Money. It has been updated to modern technologies while MS-Money is frozen in time and a legacy app.
You find that database armatures usually store everything in one table. The professionals break things up into different tables using normalization.
For example you usually have a table with names in it and an ID, and then you have a transaction table that has the ID in it plus the transaction with a foreign key going back to the table with names in it. Could be names of each account or checking or savings account with an ID assigned to them.
Thing is you could be downloading more than one account and you don't want them mixed up into one CSV file. You want them separate in normalized tables. Now you could just have a CSV file with Account ID in it and then have a separate CSV file with the name of the account with the ID in it. But that just gets confusing.
What if you are a business and have several accounts you want to download and process? You don't want them all mixed up together. Yeah there could be sub-accounts as well that have an ID as a foreign key and then another Foreign key to the main account or sub-sub account etc. When you get into accounting and you have sub accounts and sub-sub accounts to track spending you have to have a way to figure out how they work.
Here is an example of tables with sub accounts: http://www.utteraccess.com/forum/lofiversion/index.php/t1855...
I would import them into Oracle, SQL Server, MS-Access, Clipper, etc and sometimes had to write a custom program to import the files.
I would work in a Unix environment as well and had to run AWK and SED to remove blank spaces and other problems that would cause invalid use of null errors in a database that the column couldn't be null. Sometimes the CSV file didn't follow the database validation rules, like using text in a number field, etc.
We also had fixed width files. Stuff from an IBM Mainframe that was in EPISODIC that had to be converted to ASCII. Then when it converted some of the characters in the file had to be edited because they were illegal control characters that had something to do with DASD JCL/JECL control codes.
But a CSV file is basically one database table with a bunch of columns in it that you import, separate the data with commas.