Figuring out transaction data

In the course of building Backbone, I got to test out many Fintech products in order to figure out how their data could be used for credit risk assessment.

I wasn’t surprised to see how many of these companies make an effort to make sense of the user’s bank transactions. I was, however, surprised to see how many of them are getting it wrong in a significant way.

Why is it important to get it right?

I have noticed two main use cases for using bank transaction data and these are to help customers create savings pots and assess whether the customer can afford a credit product.

In order to help customers start a savings pot, it’s important to understand what is the net spendable income of the customer and how much of it could be set aside to a savings pot. In the case of credit products, it’s important to understand how much of their available income could be used to repay their loans.

In both scenarios, getting the net spendable income is a crucial factor for the services to be efficient and right for the customers. When the calculated net spendable income is lower than what it really is the customer will either not save as much as she can, or in the case of credit products, not be approved for the credit product. When the calculated net spendable income is higher than what it really is the customer might go into overdraft because too much money was diverted to savings, and in the case of credit they might not be able to repay their loans.

So, in order to have an efficient product, that serves the customers without jeopardising their financials while still allowing them to benefit the product to its full extent, companies must get this right.

What are they getting wrong?

The three major things that I have seen gone wrong are:

1. Not getting the full picture

2. Not accounting for inter-account transfer

3. Misidentifying transactions

Not getting the full picture

When on-boarding to the services I tried out, I was usually asked which bank account I wish them to connect to. The process usually assumed I use just one.

Once my transactions were fetched, the services didn’t bother figuring out whether the transactions they are getting are telling the whole financial story. Obviously, getting only a portion of a person’s financials can be very misleading when trying to assess savings ability or credit affordability.

The thing is that any human looking at the transactions could see right away that something is amiss, so why couldn’t an algorithm figure it out?

This is specifically risky when trying to assess the affordability of a credit product, as this could be easily used to game the lender’s algorithm to show high spendable income while the customer has other accounts that are in a bad shape.

Not accounting for inter-account transfer

I’m sure I’m not the only one who has savings account and current accounts both held by the same bank. And when one has these accounts, there might be some transfers from the current account to the savings account and vice versa. Some of the services I tried out were clever enough to pull the transactions from all of my accounts that are held by my main banking provider. However, they all failed to identify the inter-account transfers. This means that money that I transferred to my savings account was counted as expense and money that I withdrew from my savings account was counted as income. This is obviously the wrong way to account for these transactions and might lead to wrong conclusions by the service providers.

The strange part is that it’s really easy to figure this part out. These transfers are usually marked with a very close timestamp and have the exact same amount. How hard is it to figure out that they cancel each other?

Knowing that the customer has a savings account and knowing the patterns of the inter-account transfers is a significant piece of data when trying to assess a customer’s ability to save money or afford a credit product, but it seems that it’s not properly used.

Misidentifying transactions

This is the headline for many small mistakes that these providers make when categorising the transactions.

Correctly identifying transactions and their purpose is super important. The importance lies with the intention of most credit and savings providers to distinguish between fixed monthly expenses and the flexible expenses. Tagging too many of the transactions as fixed expenses might mean that the customer will be offered less savings than they could save or be offered less credit than they can really serve. On the other hand, tagging too many transactions as flexible might mean that too much money will be directed to savings, not leaving enough money to pay for bills and such, or in the case of credit, the customer might be offered a credit product that that they can’t repay.

Few examples for getting the transactions wrong:

Marking credit card payments as one big purchase — This means that the transaction will be tagged as a fixed expense, since it happens every month, but it actually hides a larger picture of multiple fixed and flexible expenses. This goes back to the first point of having the full picture.

Misidentifying ATM withdrawals — Since many ATM withdrawals are made not in bank ATMs but other ATMs, they are tagged wrongly in many cases. For example, if you withdraw money from an ATM at a Sainsbury’s, the transactions are usually tagged as grocery shopping and usually tagged as a fixed expense, while it doesn’t have to be.

In conclusion

Open banking gives Fintech companies a lot of data they can use to make their products great. Getting banking transaction right should be the corner stone of any financial service provider in order to make an efficient product that provide great value to their customers without putting them in harm way.

The first two issues I mentioned are relatively simple to figure out and fix. The 3rd one is a bit trickier, but with the combination of human and AI, this can be solved. In that respect the work the Monzo did early on, when they asked users to tag, or edit tags of transactions is a brilliant way to create a database of transaction tagging that I’m sure will help them a lot going forward.