Does this IBAN really exist and belong to this account holder?

We provide a mechanism for answering this question.

You can use this for things such as:

• Having more peace of mind when initiating a direct debit or entering a SEPA transfer order.
• Allowing your clients the same peace of mind.
• Monetizing any lists of known IBAN/account holder combinations you may have - or at least saving money when using our service - by submitting IBAN hashes (not necessarily the IBANs themselves) and receiving credits on your account in return.

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:

• You send money to a correct IBAN which really belongs to the account holder you think it belongs to: Great. Everything works, and after about 1-2 days, you can feel relieved.
• You transfer money to an IBAN which does not actually exist even though it might pass many tests such as checksum, existence of embedded bank code etc.: The money will bounce back, and you might be charged a fee. Not great but also not a catastrophe.
• You send money to an IBAN which actually does exist, but which does not belong to who you think it belongs to. The money is gone, and you have to rely on the mercy of the actual account holder for ever seeing your money again.

Our mechanism eliminates the not-so-desirable second and third scenarios for those IBANs for which we have a hash value in our database.

Letting other people know if an IBAN exists without divulging the IBAN

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.

Earning credits by sharing hashes for IBAN/account holder combinations

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:

• A user receives 10 points on his user account (to be used for IBAN validations or other SOAP transactions) if he submits the information that an IBAN belongs to a certain account holder, and this information is new to us.
• There is a penalty for submitting bogus hashes which have nothing to do with any IBAN just for the purpose of receiving free points: all points ever earned for submitting hashes/IBANs are subtracted from the account balance, and the user account is suspended if we detect this and have reasons to believe that the bogus hashes were sent intentionally.

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.

Why is this safe?

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:

• We rely on well-established cryptographic methods rather than inventing our own: SHA-2 is well-known and relied upon in some widely used security applications and protocols, including TLS and SSL, PGP, SSH, S/MIME, and IPsec.
• We generally use different salts for hashing different IBANs. (The salts are derived from account holder names, which tend to be different for different IBANs). If (almost) every hash has been produced using a different salt, a brute-force attack (going through every possible value of an IBAN, hashing it, and checking if the result happens to match a given hash value) becomes infeasible.
• Only IBAN hashes are stored for an indefinite time, but not the salts derived from account holder names. Therefore, neither the IBANs nor the names of account holders can be inferred from the contents of the database.