IBAN and the SEPA account identifier

The International Bank Account Number, or IBAN, is the account identifier that makes SEPA possible, and every analyst who works on European payments must understand its structure. An IBAN is made of a two letter country code, two check digits, and a Basic Bank Account Number, known as the BBAN, which identifies the bank and the account within that country. The total length varies by country. A German IBAN has twenty two characters, a French IBAN has twenty seven, and a Maltese IBAN has thirty one. The check digits are calculated with a standard algorithm called MOD 97, which catches most typing errors before the payment is even sent, because a mistyped IBAN will usually fail the check digit validation. The MOD 97 check is worth understanding in detail, because it is the first line of defence against a wrong payment. To validate an IBAN, move the first four characters to the end, replace each letter with two digits, A is 10, B is 11, and so on through Z is 35, and then divide the resulting number by 97. If the remainder is 1, the IBAN is valid. Take a German IBAN, DE89 3704 0044 0532 0130 00. Move DE89 to the end, convert the letters, and the division leaves a remainder of 1, so the IBAN passes. Change one digit and the remainder changes, so the check fails. The analyst must design IBAN validation into every payment screen: check the country code, check the length for that country, run the MOD 97 check, and show a clear error if the IBAN is invalid, before the payment is submitted. Catching a bad IBAN at entry is far cheaper than handling a returned payment days later. The length table is the reference an analyst keeps at hand. Germany 22 characters, France 27, Spain 24, Italy 27, Netherlands 18, Belgium 16, Austria 20, Ireland 22, Malta 31, Luxembourg 20. The BBAN inside the IBAN has a different structure in each country: in Germany it is an 8 digit bank code followed by a 10 digit account number, in France it is a 5 digit bank code, a 5 digit branch code, an 11 digit account number and 2 check digits, in the Netherlands it is a 4 letter bank code followed by a 10 digit account number. The analyst does not need to memorise every structure, but must know that the IBAN is not a single global format with a fixed length, and that the validation must look up the length and the structure for the country code before it accepts the IBAN. The IBAN replaced the need to know a separate bank code and account number, which is how many countries addressed payments before SEPA. A German payment used to need a Bankleitzahl and a Kontonummer; a French payment used to need a code banque, a code guichet and a numero de compte. The IBAN combines all of that into a single string that is the same across the whole area, and it is printed on bank statements, invoices and salary slips across Europe. A business analyst must design IBAN validation into every payment screen, check the country code, check the length for that country, run the MOD 97 check, and show a clear error if the IBAN is invalid, before the payment is submitted. Catching a bad IBAN at entry is far cheaper than handling a returned payment days later. The Business Identifier Code, or BIC, is the second identifier that appears in European payments, and it identifies the bank rather than the account. A BIC is eight or eleven characters long and is also known as a SWIFT code. The first four characters identify the bank, the next two identify the country, the next two identify the location, and the optional last three identify the branch. In the early days of SEPA, customers had to provide both the IBAN and the BIC, but the BIC is no longer required for SEPA payments inside the area, because the IBAN alone is enough for the receiving bank to be identified through central directories. This is the IBAN only rule, in force since 2016. The BIC still matters for payments outside SEPA and for some internal routing, so the analyst should keep it in the data model even when the customer does not have to type it. What happens when an IBAN is wrong is the test of the design. If the IBAN fails the MOD 97 check, the payment screen must reject it immediately with a clear message, and the payment must never be submitted. If the IBAN passes the check but belongs to a closed account, the payee bank rejects the payment with reason code AC04, and the payer bank reports the rejection in a pain.002. If the IBAN passes the check but the account number inside it does not exist, the code is AC01 for an incorrect account number. If the IBAN belongs to a different person than the name the payer typed, the verification of payee check warns the payer before the payment is sent. Each of these is a different failure with a different message and a different fix, and the analyst must map each one to a screen, a message and an operations action. The IBAN also appears in the ISO 20022 messages, and the analyst must know where. In a pain.001 customer credit transfer initiation, the creditor IBAN sits in the creditor account block. In a pacs.008 interbank credit transfer, the creditor IBAN sits in the creditor account block and the debtor IBAN sits in the debtor account block. In a pain.008 direct debit initiation, the debtor IBAN sits in the debtor account block. The IBAN is the key that links the customer instruction to the interbank message to the statement, and a payment that carries a different IBAN in the pain.001 and the pacs.008 is a defect that reconciliation must catch. The analyst should specify that the IBAN is carried unchanged from initiation to settlement to statement, and that any transformation is a defect. A final point on IBAN discipline. The IBAN is case insensitive and is usually printed in groups of four characters with spaces, but the system must store it without spaces and in upper case, and must strip spaces and convert to upper case on entry. A payment screen that rejects an IBAN because the customer typed it in lower case, or with spaces, is a defect. A payment screen that accepts an IBAN with spaces and then sends it with spaces in the pacs.008 is also a defect, because the receiving bank may reject it. Normalise on entry, validate the normalised form, store the normalised form, and display it in groups of four for readability. That is the complete IBAN rule, and it fits in one paragraph of requirements.