We provide a mechanism for answering this question.
You can use this for things such as:
This constitutes noticeable progress compared to the current situation, where a SEPA transfer (or direct debit) can lead to three different scenarios. You find out which of the three scenarios actually applies only a day or two after initiating the transfer:
Our mechanism eliminates the not-so-desirable second and third scenarios for those IBANs for which we have a hash value in our database.
Our web service allows users to share the information whether IBANs exist and belong to a given account holder without sharing the IBANs or account holder names. Other users can then use this stored information to find out that a given IBAN really belongs to a given acount holder.
What might sound a bit like magic is made possible by cryptographic hash functions. We do not store IBANs or account holders but only hashes of IBANs which have been salted with data derived from the account holder names. These hashes allow us to answer the question "does IBAN X belong to account holder Y", but they do not allow us to figure out the values of X or Y ourselves.
As a result, our users can (for those IBANs for which we have hashes) find out that a given IBAN really belongs to a given account holder. This information is included in the return values of the function validate_iban.
There are two ways for our users to share the information that a certain IBAN belongs to a certain account holder. Either way, we store only salted hashes (where the salt is generally different for every IBAN); we do not store any IBANs or account holder names.
No matter which of the two ways a user chooses, there is a reward for submitting IBANs:
The easiest submission possibility is to use the function submit_iban, which excpects the IBAN and the account holder as parameters. We will (after validating the IBAN) first derive some salts from the account holder name, then hash the IBAN with each salt, and finally store those hashes but neither the IBAN nor the account holder name. The downside of this simple method is that the submitter has to trust that we do not store IBANs or account holder names, but on the other hand, it's convenient. Also, since we perform the hashing ourselves, there is no danger of incurring the penalty for submitting bogus hashes which is mentioned above.
A slightly less simple method which has the advantage that the submitter knows that no IBAN can be stored by us because none is ever submitted is the following: First, call the function get_salts, which expects an account holder name as parameter. Then, hash this account holder's IBAN with each of the salts returned by the get_salts function, and finally, submit the resulting hashes using the function submit_hashes.
In case a hacker manages to capture our database with its list of hashes, it is important to ensure that no IBANs and/or account holder names can be reconstructed from these data.
This is actually the case, for the following reasons: