Why There Is No Bank Integration in Debit & Credit (The Answer - it is not secure enough)
For many financial app developers providing direct bank integration seems to be a no-brainer. There are 3rd party bank aggregators that handle the hardest part, which is getting data from banks. Those aggregators don’t charge developers much (usually somewhere near $1 per month) and only a one time integration effort is needed to support them. If a developer can then sell this feature to his users for $5 per month, then why not to do that?
Well, there are a few reasons. Let’s start with the simple one.
Accuracy
Downloading transactions from your bank results in reports that are nowhere near as accurate as those that are created with manual transaction entry. Most of the time your bank has the following pieces of transaction data: amount, date and payee. Some people could argue that having payee name is enough to figure out what category of expense it belongs to. This is true most of the time, but what about general stores where you could purchase completely different items depending on the purpose of your visit. You could buy groceries on one day and household items on another at the same store. There is no way for your bank to know that.
The same applies to other cases, like having a few different categories in a single transaction (split categories) or recording pending transactions (not all banks provide information about pending transactions).
Despite that problem, I understand that some people are willing to give up accuracy just to do less manual work. It is perfectly fine.
Security
Let me start with a quick summary on how passwords are stored and used these days in the internet. When you go online and sign up for a new service, you are usually asked to create a password. The perception is that once this password is created, it is no longer stored “as it is” in a plain view by that service, it is hashed, meaning that it is encrypted in a non-reversible way.
Most of the time this is true because those hashes are be later used for authentication. When you want to sign in next time, the password that you enter is hashed and then its value is compared to the hash that was generated when you registered. This is how passwords usually work and there is nothing wrong with that.
Now let’s get back to bank aggregators. Whenever you start setting up bank integration in a finance app, you are asked to provide your internet banking credentials including your password. After that your credentials are sent to a bank aggregator.
You might think that your password is securely hashed just like with any other online service, but that is not the case. Bank aggregators store passwords in a reversible way, they don’t hash them. Yes, they still encrypt them, but they have means to decrypt them at any moment to download your data.
The reason why they can’t technically hash them is because they need to enter your password in a plain view every time they want to download data on your behalf. Many banks don’t provide APIs that could eliminate this need, so aggregators scrape information directly from internet banking portals.
Basically this means that if a bank aggregator gets hacked (which is always a possibility these days), all of its customer credentials could be in danger since they are stored in a reversible state.
Some people might argue that losing a password for internet banking is not such a big deal since usually there are security codes sent via SMS by banks to confirm operations. This is true, although only to some point. It really depends on your bank what operations to approve with SMS. Either way, the risk of losing your internet banking password is not something that could be ignored.
With some services, like PayPal (where text code verification is completely optional) it is even more risky.
At the end of the day, I don’t believe that giving up on security is worth saving a few minutes a day on recording transactions. I would like my customers to feel safe when using Debit & Credit.
