First of all, this depends on the country you are in and its laws. The best practice is to encrypt all your user data since you are handling financial data.
Just to avoid confusion about data encryption, there are generally two things to deal with, as described below. The reason I bring this up is that in my experience people tell me as a security consultant that "the database is encrypted".
However, by asking a few more questions, it turns out that the data in the database itself is not encrypted but the disks the database is running on.
1. Disk Encryption
This type of encryption protects your data from being stolen if one of more physical machines are in rest (turned off and stolen perhaps)
2. Database Encryption
This type of encryption protects your data in the database itself. For example, if an attacker is able to (partially) dump your database, the records are encrypted and is basically useless to the attacker.
The only challenge here is, where do you store the encryption key. This key should never be on the same disk (e.g. in a configuration file) of either the application server and database server.
In order to read the encryption key, a 'vault' mechanism is recommended. Google "encryption key vault" should lead to several solutions that you could implement.
How much should I encrypt?
In my opinion, financial data itself should definitely be encryption but this also depends on regulations and company policy. I have been in companies that use the following policy:
"Every record that can be used to identify a person is considered sensitive data"
Examples are: Social Security Numbers, bank account numbers etc.
What's the best way to encrypt it?
In my experience, most of the time, symmetric key encryption is used.
What's the best storage medium?
Most open source databases support column encryption, so does Postgres.
