Is there any benefit to hashing sortcodes + account numbers?

We have a database of sort codes (6 digit numbers) and account numbers (8 digit numbers) that we use to reconcile monthly accounts with the table of supporters.

There is nothing in the data received from the bank that uniquely identifies the supporter, other than the sort code and account number. ... I know, it's annoying.

While this data is not as sensitive as card data (and not subject to PCI-DSS), it's still pretty sensitive and I'd like to find another way to do the reconciliation to reduce the liability of having all this data.

Combining sort code and account number gives up to 10^16 possibilities.

Is there a way (using a reliable and established PHP function) to hash the data and only store the hash, that would allow me to take a monthly file of -say- 1000 records and match them up to the hashed data? Or is there really no point and instead focus on hardening security around this db?

The security advantage I'm seeking is that the database does not have a ready-to-use list of people's bank details. The transactional monthly bank statement data can be considered to be of short lifespan (it is received encrypted, decrypted, processed, deleted).

I've read a helpful detailed comparison of hashing functions but obviously here we're not talking about password, and in effect we need to be able to crack them every month! Hmmm.