What it takes to localize IBANs
At Qonto, we want you to have a great banking experience in your country.
To us, being a European bank does not mean offering the lowest common denominator. It means being the best Italian bank, the best French bank, the best Spanish bank, the best German bank, and so forth.
That requires going the extra mile in each territory: exploring what pains are met by freelancers and entrepreneurs where they live, and tackling them one by one.
One salient issue that appeared in practice is IBAN discrimination. An IBAN is a (supposedly) international identifier for your bank account. Qonto generates it when you register. However, some institutions cannot handle IBANs from a foreign country. The French IBAN we used to produce could prevent you from paying for services that you needed. Besides, giving a national IBAN to your partners and customers gives them a more native, trustworthy experience: Qonto really becomes a local bank.
We worked hard to provide national IBANs for everyone. A big part of that involved cooperating with a number of banking authorities, filing detailed requests for registration and activation of codes and routing information. But here, we will talk about the tech. Surprisingly, it involves some light finite field arithmetic.
IBANs, how do they work?
Functionally, IBANs must fulfill a few requirements:
- Detect typographical errors,
- Allow routing to the right bank,
- Be unique, which as you will see is performed hierarchically.
Let’s first look at error detection.
When the International Standards Organization worked on ISO 13616 (the IBAN specification), they opted to solve typos by using an earlier standard, MOD 97–10 from ISO/IEC 7064. Let’s quote it:
This International Standard specifies a set of check character systems capable of protecting strings against errors which occur when people copy or type data.
A check digit (or checksum) is an algorithm producing a distinct output for inputs that are one error apart. You append it to the text: now, if someone copies it wrong, a machine can tell them! All it needs is to recompute it and compare it with the stored checksum.
Here is how an IBAN is structured, with the checksum chucked near the start:
Before digging deeper into the checksum, let’s have a quick word on the other components. The country lets you know where the bank resides. The BBAN, which we will dig into later, contains the identifier of the bank and of the account number, and its format is country-specific.
As for the checksum, how does its algorithm work? How do you even build something that is good at catching human errors? Interestingly, there are properties of finite fields that you can take advantage of to prove that you detect whole classes of mistakes. For IBANs, they picked arithmetic modulo 97, which is the largest prime below a hundred. That gives the best bang for the buck (“buck” here means “wasting two characters”. But don’t worry, you will see that we are ready to waste much more).
The spirit of the l̶a̶w̶ checksum in one sentence: the number representation of the IBAN must be congruent to 1 modulo 97.
Now, we know how typos are caught. Next, how do banks know where to send money from the IBAN alone? The secret sauce is in the BBAN.
BBANs, how do they work?
When designing IBANs, ISO chose to externalize much of the complexity surrounding routing of funds, to a private society which made it their core business: SWIFT.
SWIFT lets governments and banking authorities register a BBAN format for their country.
Each country has a registry of bank codes that they deliver to each bank residing in that country. That bank code is required to be a subcomponent of the BBAN. But the government only guarantees that this code is unique nationally. SWIFT then maps the bank code to an internationally unique code that they assign to each bank: the BIC (Business Identifier Code). BICs are then used to route funds through the payment networks.
It turns out that many countries already had preexisting formats, often with their own checksum systems. Thus, a number of them simply plugged their old standard in the BBAN and called it a day. I am looking at you, France, and your RIB format:
That actually helps explain an oddity: why do French IBANs always start with FR76? Isn’t the 76 part meant to detect typos? Does it mean French accounts are not protected against them⁈
Actually, as luck would have it, the French authorities picked a checksum format which is very closely related to the one ISO chose. Instead of converting the account to a number that must be one modulo 97, it must be zero modulo 97. And therefore, the RIB checksum cancels out the whole BBAN in the IBAN checksum equation:
Now, you have an idea of the kind of things we must implement: when generating accounts, we must ensure that the computed checksums validate, for each country’s checksum algorithm.
Thankfully, not all countries have a complex system.
Behold the German BBAN, a paragon of deutsche Effizienz:
Ah! Only what is essential! All you truly need in a BBAN is the bank code and an account number. No need for a national checksum when the IBAN already has one!
By the way, we talked about where bank codes come from — but what about account numbers? How are they built, to make sure that they are uniquely identifiable?
A very good account number
Each bank can choose whichever account number they want, provided it follows the BBAN’s mandatory format. They don’t need to register it to anyone, since it only needs to be unique inside their own database. But in our opinion, some banks put more love into picking the right account number than others.
A good account number generation needs to:
- be easy to copy. Some IBANs contain letters that are difficult to distinguish visually from certain numbers, such as zero / capital O. We chose to restrict ourselves to digits for that purpose.
- have a healthy amount of entropy (in the Shannon sense). In other words, it needs to be random enough. That protects customers from fraudsters that obtain similar-looking IBANs, and ensures that someone’s IBAN cannot be guessed.
For the latter, we rely on cryptographic sources: /dev/urandom, which nowadays on Linux uses the fantastic ChaCha20 primitive.
We even take care to avoid modulo bias. In other words, to get a base-10 number, we cannot just take the modulo base 10 of a random base-2⁸ number: indeed, some base-10 numbers would then be more likely to be picked.
To circumvent that annoyance, we use rejection sampling: loop through random outputs until you get one under 10. Since each value under 10 is uniformly distributed, the result will be too.
Parce que vous le valez bien
There are quite a few details to get right in order to offer the best account numbers, but you are all worth it. Our dream is to help foster a fantastic ecosystem of individual, small, medium, and large businesses, that no longer get wrinkles out of receiving customer complaints that the payment did not go through because “the IBAN got rejected”.
About Qonto
Qonto is a neobank for SMEs and freelancers founded in 2016 by Steve Anavi and Alexandre Prot. Since the launch in July 2017, Qonto has made business banking easy for more than 120,000 companies. Thanks to Qonto, business owners save time (streamlined account opening before a day-to-day user experience with unlimited history, accounting exports, expense management feature), have more control while giving their teams autonomy (real-time notifications, user right management system) and have improved visibility on cash-flows (smart dashboards, transactions auto-tagging, and cash-flow monitoring). They also enjoy stellar customer support, at a fair and transparent price.
Interested in joining a challenging and game changer company? Consult our job offers!
