Talk:International Bank Account Number/Archive 2

Table — Example of a modulo operation on a large number
Suggest changing the table in section Example of a modulo operation on a large number to the following.

--Bob K31416 (talk) 14:25, 13 August 2012 (UTC)


 * The original table was a corroborative effort between User:Tomeasy and myself. I have no strong views about dropping the column in question, Martinvl (talk) 15:07, 13 August 2012 (UTC)
 * Fine by me as well.
 * One proposal: a_1 is actually 1 mod 97. The a_i are defined recursively for convenience, so that even the large numbers can be computed straightforwardly (otherwise 10^20 mod 97 would be quite complex a task). Nevertheless, at first, I would argue that is what the a_i are: a_i =10^(i-1) mod 97. So why not write it like this in the first row, instead of the awkward "by definition" statement? Tomea s y T C 22:36, 13 August 2012 (UTC)
 * Re "So why not write it like this in the first row,..." —  It's inconsistent with the column heading. However, I agree that what is in that first row box of the suggested table could be improved. Suggest replacing  "a1 = 1 (by definition)" with just an emdash "—" and giving a brief explanation in the text that precedes the table. --Bob K31416 (talk) 23:56, 13 August 2012 (UTC)
 * Not sure what you propose with the emdash. Perhaps you can actually show your example ...
 * After all, we choose the heading, and $$a_i = 10^{i-1} mod 97 = (a_{i-1} *  10) mod 97  $$. My pont is that a_1 = 1 is not an arbitrary definition needed to start recursive definitions.  Tomea s y T C 04:46, 14 August 2012 (UTC)
 * At this stage in the discussion, it seems like the easiest way to show it is to implement it. --Bob K31416 (talk) 11:32, 14 August 2012 (UTC)
 * P.S. Followup. --Bob K31416 (talk) 11:43, 14 August 2012 (UTC)
 * What I think is missing in our example is to convey the message how d_i * a_i is related to D. With the current exclusive definition of a_i in the recursive way, this is quite a complex task to comprehend. I find it quite difficult to anticipate that D is just composed into a sum of numbers, each made up of one of D's digits followed by zeros only. I will think about a simple way to make the concept clear.  Tomea s y T C 20:45, 14 August 2012 (UTC)
 * Does this work? --Bob K31416 (talk) 22:03, 14 August 2012 (UTC)
 * Another question: Are you sure you want to use math templates for inline text. Personally, I find it quite ugly.
 * Example: ... where $$D$$ is an integer ... or ... where D is an integer ...
 * My preference goes for the latter style. Tomea s y T C 22:59, 13 August 2012 (UTC)
 * I agree. --Bob K31416 (talk) 23:56, 13 August 2012 (UTC)
 * P.S. Intext font change implemented. --Bob K31416 (talk) 14:54, 14 August 2012 (UTC)
 * P.P.S. I noticed some typo and other minor errors that were introduced by your recent edits that you might want to correct. --Bob K31416 (talk) 14:59, 14 August 2012 (UTC)
 * Feel free to correct typos, or be specific if you want me to do it. Tomea s y T C 20:45, 14 August 2012 (UTC)
 * Here's one where I wasn't sure whether there was a word missing, "where the ai are a fixed array of that dependens only on the length of D. they are defined as ". --Bob K31416 (talk) 21:24, 14 August 2012 (UTC)

Modulo operation on large numbers
Here is a suggested version for the section Modulo operation on large numbers, along with a copy of the present version for reference. The modulo operation finds the remainder of division of one number (the dividend) by another (the divisor). For the case of an IBAN sanity check, the dividend D is the IBAN after it has been converted to an integer, the divisor is 97, and the remainder is denoted D mod 97. It is often not practical to perform this calculation directly because of the large size of the integer D and the requirement that the arithmetic precision has to be exact. So the calculation is done with programming languages or software packages that support arbitrary-precision arithmetic, such as the Javascript program published by UN CEFACT TBG5 which uses a piece-wise approach. The code in this program calculates D mod 97 as follows:

The large integer D is decomposed into its decimal digits di (i = 1, 2, ... n ) which are ordered from right to left. For example, d1 is the rightmost digit of D and dn is the leftmost. Then D mod 97 is calculated using
 * $$ D \, \bmod\,97 = \left( {\sum\limits_{i = 1}^n {d_i \times a_i } } \right)\bmod\,97 \,, $$

where the integers ai are the n elements of an array defined by
 * $$a_i = {10^{(i-1)} } \bmod\,97\,, \qquad  i = 1, 2, ..., n\,. $$

The program generates the array ai by first setting a1 = 1, since
 * $$a_1 = 10^{0} \,\bmod\,97\, = 1\,,$$

and then calculating the remaining elements using the recursive relation
 * $$ a_{i + 1} = \left( {a_i \times 10} \right)\bmod\,97\,.$$

Note in the above expression for D mod 97, that the integers di and ai, and the summation of their products, are much smaller than the integer D. Thus, they are much more amenable to modulo operation calculations that require exact precision arithmetic by a computer that has limited precision integers.

Notes

References

The modulo operation finds the remainder of division of one number (the dividend) by another (the divisor). For the case of an IBAN sanity check, the dividend D is the IBAN after it has been converted to an integer, and the divisor k is 97. It is often not practical to perform this calculation directly without using languages or packages that support arbitrary-precision arithmetic, so many programs, such as the Javascript program published by UN CEFACT TBG5 use a piece-wise approach. The code in that program validates a given IBAN as follows:

The integer D representing the IBAN is decomposed into its decimal digits and the associated powers of ten. Mathematically, this is expressed as
 * $$D = \sum\limits_{i = 1}^n {d_i \times 10^{(i-1)} }$$,

where n is the number of decimal digits di of the integer D and i is their position index. The program evaluates the remainder D mod k by making use of modular aritmetics
 * $$ D \, \bmod\,k = \left( {\sum\limits_{i = 1}^n {d_i \times 10^{(i-1)} } } \right)\bmod\,k = \ldots = \left( {\sum\limits_{i = 1}^n {d_i \times a_i } } \right)\bmod\,k \,, $$

where the ai are a fixed array that depends only on n, the length of D. They are defined as
 * $$a_i = {10^{(i-1)} } \bmod\,k\, .$$

The sequence $$\left\{ {a_i \left| {i = 1 \ldots n} \right.} \right\}$$ is generated using the rekursive relationship
 * $$a_1 = 10^{0} \,\bmod\,k\, = 1;\quad a_{i + 1} = \left( {a_i \times 10} \right)\bmod\,k\,.$$

Notes

References

--Bob K31416 (talk) 19:03, 17 August 2012 (UTC)


 * I woudl perfer to keep k in the text rather than 97 - this demonstrates that the relationship holds for any interger, not just for 97. Martinvl (talk) 20:17, 17 August 2012 (UTC)
 * Re "this demonstrates that the relationship holds for any interger, not just for 97." — Not clear why you would want to do that for this article. For example, does IBAN use any other modulus besides 97? --Bob K31416 (talk) 22:01, 17 August 2012 (UTC)
 * Bob, I see a lot of improvement in your proposal. Many things are explained now in a way that is more easily understood by the layman. I guess this is why you want to replace k by 97 everywhere. I see some sense in stating a general rule in a general way and later substitution with application data, but I could also live with 97. I somewhere read that the standard does not prescribe the use of 97 as the remainder, but 98 and 99 would also be permissible and working divisors. Not sure if that's true and how relevant you consider it.
 * Here are my concrete issues, where I would like to hear your opinions:
 * a) Can we omit the first formula that only decomposes D and directly jump to the decomposition being applied to the modulo computation?
 * b) Your proposed first equation now has not only the decomposition applied but also contains the modular arithmetical transition from the powers of ten to the a_i, which is the most complex reformulation in the entire article. I believe that stating the equation as simple as you propose, just after the introductory sentence about decomposition, will mislead most readers to think that 10^(i-1) = a_i, which is wrong.
 * I am sure we will find a solution for these issues and the question k or 97, and then I think we should use your proposal. Tomea s y T C 23:12, 17 August 2012 (UTC)

Tomeasy, Thanks.
 * Re “I somewhere read that the standard does not prescribe the use of 97 as the remainder, but 98 and 99 would also be permissible and working divisors.” — Perhaps you were remembering the beginning of the section Generating IBAN check digits, which has some similarities to what you were thinking but actually is about something different?


 * Re a and b in your message.
 * a) When you referred to “the first formula”, may I presume you’re referring to the first equation (D = ...) in the footnote? If so, that is the starting point for the derivation and it seems to be at least as important as the identities used in the derivation.
 * b) I didn't understand the first part of your comment since the “proposed first equation” (D mod 97 = ... ) just summarizes the algorithm that the program uses to calculate D mod 97.  Regarding  the second part of your comment,  I didn’t understand how the reader could be misled into  thinking that 10^(i-1) = a_i, especially since  ai is defined otherwise immediately following the “proposed first equation” (D mod 97 = ... ).

--Bob K31416 (talk) 18:02, 18 August 2012 (UTC)

P.S. On second thought regarding the first part of (b), maybe the source of the problem you are thinking about is the sentence about decomposing D. Perhaps instead of that sentence, we could define the di after the first equation (D mod 97 =...). --Bob K31416 (talk) 18:48, 18 August 2012 (UTC)


 * Here's what the change would look like.

The mod-97 operation on the large integer D is calculated using
 * $$ D \, \bmod\,97 = \left( {\sum\limits_{i = 1}^n {d_i \times a_i } } \right)\bmod\,97 \,, $$

where the di are the decimal digits of D, with d1 the rightmost digit, d2 the next digit to the left, ..., and dn the leftmost digit. The integers ai are ...


 * --Bob K31416 (talk) 20:18, 18 August 2012 (UTC)
 * OK, I am fine with either k or 97.
 * a) Yes, I meant the first equation in the footnote. I also find it quite important, while also a nice trick that many readers can understand. Currently, it is the first equation in the main body. I was wondering why (in the main body) we start with the final equation. I guess you want to have less equations in the main body, so to make everything look less mathematical, less complex. Personally, I find the opposite is the result. It becomes difficult for those who want to understand the equations. Admittedly, I have no idea how many people really come here and want to understand this ;-) Anyway, about this point, my opinion is that it is better to have the decomposition in the main body.
 * b) You are right the following equation shows the correct definition of a_i, so it is not so much misleading. I expressed another concern with this issue: you propose one simple equation, whereas there are quite some operations necessary to come from the left side to the right side. What about inserting one more equation sign and ellipses? This will motivate the reader to look at the modular arithmetic identities in the footnote and try for themselves. Tomea s y T C 21:36, 18 August 2012 (UTC)
 * Re "I was wondering why (in the main body) we start with the final equation." — In the suggested version, that's because it is the equation that the computer program is supposedly using. Recall the sentence at the end of the preceding paragraph there, "The code in this program calculates D mod 97 as follows:".
 * Re "What about inserting one more equation sign and ellipses? This will motivate the reader to look at the modular arithmetic identities in the footnote and try for themselves." — I don't think readers will understand what the ellipsis means, i.e. the derivation. I didn't when I saw it in the present version of the article. --Bob K31416 (talk) 03:12, 19 August 2012 (UTC)
 * OK, another proposal: start with the first equation as short as you propose, and provide the footnote afterward stating something like: "the above identity can be proved/derived/shown using modular arithmetic, see footnote". Only problem that I see now is that the decomposition of D should then not be part of the footnote. Tomea s y T C 10:29, 19 August 2012 (UTC)
 * First, let's clarify something in this discussion. Maybe we're looking at this in different ways which is causing a miscommunication. Here's the way I see it. The only purpose of the sentence, "The large integer D is decomposed into its decimal digits di  (i = 1, 2, ... n ) which are ordered from right to left", is to define the di. The expression
 * $$D = \sum\limits_{i = 1}^n {d_i \times 10^{(i-1)} }$$
 * is simply a statement of how the decimal numbering system works. I don't call this expression a decomposition since I don't see the usefulness of doing that. Maybe the word decomposition shouldn't be used in the beginning sentence of the paragraph. I suggested a rewrite regarding this previously. This expression for D is the starting point for the derivation (i.e. proof) which is summarized in the footnote. The derivation then takes mod k of both sides of the equation, then applies the identities, then sets k=97  to get
 * $$ D \, \bmod\,97 = \left( {\sum\limits_{i = 1}^n {d_i \times a_i } } \right)\bmod\,97 \, . $$
 * --Bob K31416 (talk) 13:23, 19 August 2012 (UTC)
 * I am not sure if we have a miscommunication here, as you assert. However, I am sure that a possible misunderstanding is not do to my lack of understanding the how the decimal number system is build. T<font color="#009ef2">om<font color="#6bd5f5">ea s y T C 18:08, 19 August 2012 (UTC)
 * With my previous message in mind, could you explain your previous comment of 10:29, 19 August 2012 regarding the "Only problem..."?  --Bob K31416 (talk) 20:28, 19 August 2012 (UTC)
 * I think that the decomposition should not be in the footnote but in the main body. what don't you understand? T<font color="#009ef2">om<font color="#6bd5f5">ea s y T C 21:01, 20 August 2012 (UTC)

Citation request
There is one citation requested for the modular arithmetic identities that resemble distributivity in regular arithmetic. If one is able to understand the concept of remainders, a bit of thinking should normally be sufficient to proof these for oneself. However, I tried to find a reference, thinking it would be as easy as to find one for distributivity. Unfortunately, all I found were references to congruence, which is related. I could not find a reference for these laws written in the form of remainders. It seems like in mathematics, the field deals much more with congruence.

I guess that our problem can be written down with congruences, and I also guess the the equations we use can be proved by congruences, so the many reference available online probably do apply here. However, I am not expert enough to claim this with certainty. Moreover, I am afraid that we would not make things simpler, if we are starting to add congruence equation here.

Any thoughts how to deal with this. After all, it would be nice to have a source referenced for these equations. T<font color="#009ef2">om<font color="#6bd5f5">ea s y T C 21:49, 18 August 2012 (UTC)
 * I think that the citation request was an over-reaction. The last paragraph of What SYNTH is not (an essay, not policy) states:
 * SYNTH is not unpublishably unoriginal
 * When you look at a case of putative SYNTH, apply the following test. Suppose you took this claim to a journal that does publish original research. Would they (A) vet your article for correctness, documentation, and style, and publish it if it met their standards in those areas? Or would they (B) laugh in your face because your "original research" is utterly devoid of both originality and research, having been common knowledge in the field since ten years before you were born? If you chose (B), it's not original research -- even if it violates the letter of WP:SYNTH.
 * These relationships are almost certainly in category (B). If this is the case, then the citation request can be removed as it is not original research.  Since I wrote the equations in the first place, it would be improper for me to remove the request, but if teh consensus is that the request can be removed, then I will support it. Martinvl (talk) 05:56, 19 August 2012 (UTC)
 * I don't think Tomeasy's comment is about Synth, which is the combining of material from two sources to reach an unsourced conclusion. The question was simply about getting a source for some unsourced material, viz. the identities. The material seems to be verifiable, i.e. seems like it should be in a reliable source somewhere, but the problem is finding the reliable source. Perhaps the identities, or a reference for them, are mentioned in ISO 7064?


 * On a related topic, I looked at the computer program code that is currently used as a source for the D mod 97 calculation. I wasn't able to find where the code calculated D mod 97 in the way described in this article, although it may be there. Could anyone help out and show where it is in the program code? Even better, could someone check ISO 7064 for the description of the algorithm for D mod 97 that is currently in this article? --Bob K31416 (talk) 10:13, 19 August 2012 (UTC)


 * edit conflict
 * I absolutely agree with you, Martin. These equations are not original research. I am sure, they are well know to anyone who even starts working with this subject. I think, it is really no more original than the Associative property. I was just thinking two things. First, for associativity it would be very easy to show a reference, text book or online, so why not just do so here. But then I had unexpected difficulties finding something. However, I found many relationships, of which I think they actually do prove our equations, just that I am not the full expert to judge this. So, I had the second thought of whether we could use those references, e.g., just one example of many.
 * Again, I agree that we are not forced by policy to provide a reference but, if possible, why shouldn't we. I am just testing here, if we have the ability to provide such. T<font color="#009ef2">om<font color="#6bd5f5">ea s y T C 10:23, 19 August 2012 (UTC)


 * Unfortunately, the example source you gave discusses congruence of numbers, rather than the equality of remainders. Here's an excerpt from it.
 * "It's easy to see that if a = b (mod N) and c = d (mod N) then (a + c) = (b + d) (mod N)."
 * The = sign should be the &equiv; sign to correspond to the terminology in Wikipedia. With that substitution, substitutions for a and c, and some rearrangement, the above expression can be rewritten,
 * (b + d) mod N &equiv; (b mod N) + (d mod N).
 * For easier comparison with the identities, we can rename the variables and modulus to get
 * (a + b) mod k &equiv; (a mod k) + (b mod k).
 * This is similar but different from the identity in this Wikipedia article,
 * (a + b) mod k = ( (a mod k) + (b mod k) ) mod k.
 * --Bob K31416 (talk) 11:35, 19 August 2012 (UTC)
 * Bob, if you read my first post opening this section, you will see that I have been aware of the difference between the congruence and equality tight from the beginning. Otherwise, I would have already used this ref in the article. T<font color="#009ef2">om<font color="#6bd5f5">ea s y T C 18:04, 19 August 2012 (UTC)
 * OK. I think we're in agreement. --Bob K31416 (talk) 20:31, 19 August 2012 (UTC)


 * I did in fact lift this algorithm from somewhere on the Internet, not the UN program. The text got a bit muddled with various people demanding citations and the like.  I can't find the original example, but I have found another example which uses a different algorithm.  How do we want to play it?  Shall I create an area in my userspace which we can all treat as a sandbox and once it is ready we replace the current text with something that is consistent? Martinvl (talk) 15:25, 20 August 2012 (UTC)
 * First, could you give a link to the new example you found? --Bob K31416 (talk) 17:49, 20 August 2012 (UTC)


 * Here it is. Martinvl (talk) 20:12, 20 August 2012 (UTC)
 * Thanks. It looks like a good source. The information in section 4.4 pp 14–15 should replace the algorithm in the section Modulo operation on IBAN and the section Example of IBAN check digit test. Your sandbox idea is fine for me. When a draft has progressed sufficiently, it can be moved to this talk page as an informal proposal before implementing it. --Bob K31416 (talk) 02:27, 21 August 2012 (UTC)


 * Here's a possible starting version for the work on replacing the two sections.

=== Modulo operation on IBAN ===

The modulo operation finds the remainder of division of one number (the dividend) by another (the divisor). For the case of an IBAN sanity check, the dividend D is the IBAN after it has been converted to an integer, the divisor is 97, and the remainder is denoted D mod 97. It is often not practical to perform this calculation directly because of the large size of the integer D and the requirement that the arithmetic precision has to be exact. So the calculation is done with programming languages or software packages that support arbitrary-precision arithmetic.

The following is a possible algorithm for calculating D mod 97:


 * 1. Starting from the leftmost digit of D, construct a number using the first 9 digits and call it N.


 * 2. Calculate N mod 97.


 * 3. Construct a new 9 digit N from the above result (2) followed by the next 7 digits of D.  If there weren't 7 digits or more remaining in D but at least one, then construct a new N, which will have less than 9 digits, from the above result (2) followed by the remaining digits of D.


 * 4. Repeat steps 2–3 until all the digits of D have been processed.


 * 5. The result of the final calculation in (2) will be D mod 97 = N mod 97.

=== Example of IBAN check digit test ===

In this example, the above algorithm for D mod 97 will be applied to ''D = 321428291 2345698 7654321 61182. (The digits are colour-coded to aid the description below.) If the result is one, the IBAN corresponding to D passes the check digit test.


 * a. Construct N from the first 9 digits of D.
 * N = 321428291.


 * b. Calculate N mod 97 = 70.


 * c. Construct a new 9 digit N  from the above result (b) followed by the next 7 digits of D.
 * N = 70 2345698


 * d. Calculate N mod 97 = 29.


 * e. Construct a new 9 digit N  from the above result (d) followed by the next 7 digits of D.
 * N = 29 7654321


 * f. Calculate N mod 97 = 24.


 * g. Construct a new N from the above result (f) followed by the remaining 5 digits of D.
 * N = 24 61182


 * h. Calculate N mod 97 = 1.


 * i. From (h), the final result is D mod 97 = 1 and the IBAN has passed this check digit test.

References


 * --Bob K31416 (talk) 16:00, 21 August 2012 (UTC)


 * I started an example earlier - see User:Martinvl/sandbox/IBAN. My aim was to generalise the algorithm for use on 16, 32, 64 and 128 bit computers rather than to use the 32 bit variant in the citation. Be warned however, the text looks like a construction site. Martinvl (talk) 16:31, 21 August 2012 (UTC)
 * On second thought, I think my version above has progressed sufficiently to  suggest it for replacing the two sections. However, I'm open to looking at the version in your sandbox when it's ready. --Bob K31416 (talk) 18:44, 21 August 2012 (UTC)
 * My sandbox version is ready to look at. (Needs a touch of tidying up, but nothing major). Martinvl (talk) 18:49, 21 August 2012 (UTC)
 * I looked at it and it doesn't look clear, even if it is tidied up by removing strikeouts etc. When I mentioned "ready" I meant ready for suggesting for the article. --Bob K31416 (talk) 19:07, 21 August 2012 (UTC)

Bob, I have looked at your version and yes, I think that it is better than my version (maybe I have tried to be too clever). However I am uneasy about the introductory paragraph - people who read this section are likely to have an understanding of computer programming or of mathematics so it is not neccessary to dumb things down. Maybe you might like to look at the introductoiry paragraph in my sandbox version.

I also wonder whether or not it would be appropriate to note that a 32 bit integer can hold any 9 digit number, but a 128 bit machine can hold 38 digit integers which at the present time is sufficient for IBAN purposes. Any competant computer programmer should be able to adjust the alogorithm to accomodate 16 or 64 bit integers. I have amended the intgroductoruy paragraph in my suggested text to reflect the 128 bit concept. Martinvl (talk) 21:10, 21 August 2012 (UTC)


 * I agree that we should show an algorithm that is inline with the reference provided by Martin. So, thanks to both of you working things out. What I prefer with Martin's proposal is that it does not strictly requests to cut the integer in sub-strings of a given length. This is not necessary and only confuses the reader by making them wonder why these lengths for the sub-strings. I understand that Bob's intent was to stick to the source, but I find we are close enough to the source with Martin's more general approach, for which the reference is one instance. T<font color="#009ef2">om<font color="#6bd5f5">ea s y T C 21:20, 21 August 2012 (UTC)

I implemented my above version and I am withdrawing. I'll leave it to anyone here to revert or modify it. Good luck with the article. Regards, --Bob K31416 (talk) 02:16, 22 August 2012 (UTC)

Table needs updating
The legend for each row of the table is quite redundant, but also missing entries. e.g. most of the rows redundantly re-identify "B" and "C", but do not reidentify "k". — Preceding unsigned comment added by 83.70.236.221 (talk) 08:38, 1 November 2012 (UTC)


 * The redundancy is to accomnodate cases where there are names that are specific to a particular country - for example Sort Code is specific to the UK and to Ireland. Martinvl (talk) 09:13, 1 November 2012 (UTC)


 * I have made some minor changes to the table - lower case letters are used throughout as place-holders: upper-case letters are replicated exactly. I have also replaced the national check-sums with "x", leaving "k" for the IBAN checksum.  The IBAN checksum s only mentioned in the comments column if there is something special about it.  In all other cases, all the letters are defined - I woudl need positive clarification as to the exact meaning of "Bank code" for many countries - does it mean "bank and branch" or does it mean "banking company"? Martinvl (talk) 10:59, 1 November 2012 (UTC)


 * I'd rather like to drop the comments column - most field descriptions have a similar meaning for the countries so that the comments are mostly redundant. The country-specific hints should be put as a separate {reference group} below the table. With the comments removed, the table can show each country in one screen line which makes it much more readable to get an overview. Guidod (talk) 11:32, 7 July 2013 (UTC)


 * I am reluctant to mess around with the article. We get an average of 4000 hits a day (between 4000 and 6000 hits a day on business days and about 2000 hits a day during the weekends (See here. Obviously somebody likes what we write.  Having said that, there might be scope for a summary table with the following structure:


 * Martinvl (talk) 20:36, 7 July 2013 (UTC)


 * I'd like to keep the basic structure information column as it hints that the IBAN is nothing new under the sun but a reformatting of the established banking system. And, I do see you point in making up another column for the country code since the two letters do not strictly follow any of the existing two-letter country code lists.
 * Moving the current comments column to a separate section would not disrupt the current usage - the information will not be lost at all. It's just about the intent to improve readability by making the height of the table much shorter.
 * By the way, I would find an interesting piece of information to attach a hint whether the country is bound to the SEPA rules of electronic banking - more and more countries do seem to adopt IBAN so that the SEPA connection is not implied anymore. May be it is time to make up another column to show it. Guidod (talk) 18:32, 8 July 2013 (UTC)
 * My intention was that the summary table would be in addition to the main table.
 * I do not think that we need say much more about SEPA - it get complicated. Countries like the United Kingdom will be obliged to use SEPA for Euro denominated transactions, but not for sterling denominated transactions. Best leave that sort of info in the SEPA article. Martinvl (talk) 19:34, 8 July 2013 (UTC)
 * Erm, another table shouldn't show redundant information, should it. May be you have another plan to break up the current big block? Guidod (talk) 20:30, 8 July 2013 (UTC)

Ukrainian IBAN
Ukraine has not registered its format in SWIFT, but national IBAN format is developed and is in use since 2011. In Ukraine IBAN is not mandatory for international payments, but it exists and is in use. Should it be mentioned here? Maybe with notice. Svnsp (talk) 13:30, 29 March 2013 (UTC)
 * Do you have any evidence that the IBAN is actually in use in Ukraine other than being part of a recommendation in a SWIFT document? The SWIFT message type MT103 which is referenced by the document is a standard message format for inter-bank money transfers. However the message format also provides for alternative means of specifying bank accounts (field 50 for example).  I amk therefore reluctnat to include it until we have some indication as to how widespread its useage is within Ukraine. Martinvl (talk) 18:04, 29 March 2013 (UTC)
 * Currently in Ukraine IBAN format is "Nationally-agreed" and registred locally but not mandatory and not registred in SWIFT. Link to headers from national library . Google cannot translate whole page due to the format of link. Its point 2 on that page "EN-N 7167-2010 Fininsovi operation. rules for forming an international bank account number (IBAN) in Ukraine . - In use started 2011.01.01. - [B. c: b. and.]. - 14 p. - B. c. Section 03,060 Categories: Banking Items Total: 1 NTD (1) Access: NTD (1) ". Link from national banking association conference IBAN is in use in two from top ten ukrainian banks VTB Bank Ukraine, Privatbank. From that link ".., including customers Privatbank, who first introduced IBAN in Ukraine in international payments.", "Vsevolod Stalsky also spoke about the experience of implementing IBAN in PAT VTB Bank", "IBAN-code has already been used four banks of Ukraine".  Other two from fourth are small banks: D-M Bank and Trust Capital Bank. So I think info about this shoud be on wiki IBAN page. --Svnsp (talk) 08:34, 1 April 2013 (UTC)
 * While I would be reluctant to include a mention of the Ukraine in the list of countries using the IBAN, I think that it could be worked into the section entitled "Adoption", but without giving the full format. In this way we ensure that if the Ukraine decide to change their format before applying to SWIFT, we will nto be publishing an incorrect format. Martinvl (talk) 19:01, 1 April 2013 (UTC)

PAIN
There doesn't seem to be an article on PAIN yet - the current redirect points to some airbase... 91.239.32.0 (talk) 07:58, 10 June 2013 (UTC)


 * I don't understand the comment - the text "PAIN" does not appear in the article, except as part of "Spain". Martinvl (talk) 09:46, 10 June 2013 (UTC)
 * Didn't know either but some websearch reveals that there is a "pain format" being required with "iban only" systems. Formally it means PAIN = Payment Initiation in ISO 20022. See the introduction here

"In the remaining months to come, banks, customers and service providers will take on substantial efforts to implement the new EU Regulation. An essential part of the new regulation is the deadline 1 February 2014 for the replacement of the old message formats (DTA, MT) with the XML based SEPA credit transfer (pain.001) and the SEPA direct debit (pain.008). These message formats have been specified for the German finance industry by a working group of the Deutsche Kreditwirtschaft (ehem. ZKA) based on the guidelines of the EPC (European Payments Council) and are available as V2.5 of the Attachment 3 of the DFÜ agreement."

- http://www.gefeg.com/en/gefeg.validation/vp-sepa.htm


 * I have amended the page PAIN to point to both the SEPA article and to the McKinley National Park Airport. I have also clarified the meaning of the abbreviation "PAIN" in the SEPA article, but have done no more.  Further comments about PAIN should be added to the SEPA article. Martinvl (talk) 19:42, 10 June 2013 (UTC)

Palestine
I have undone the changes relating to Palestine: Martinvl (talk) 05:09, 3 August 2013 (UTC)
 * Should the article link back to the article State of Palestine or Palestinian territories? A merge discussion is currently in place.  Lets wait until that discussion is complete.
 * We do not list the description "kk - IBAN check digits" on a country-by-country basis - it would just add another 40+ rows of data and add nothing to the article. I removed this for consistency with the rest of the article.

Which characters are allowed in an IBAN?
There are slightly different ranges of characters in different sections of the article:

(a) In Background -> Practicalities: "Permitted IBAN characters are the digits 0 to 9 and the 26 upper case Latin alphabetic characters A to Z."

(b) In Adoption -> IBAN Formats by country: "The BBAN format column shows the format of the BBAN part of an IBAN in terms of upper case alpha characters (A–Z) denoted by "a", numeric characters (0–9) denoted by "n" and mixed case alphanumeric characters (a–z, A–Z, 0–9) denoted by "c". For example, the Bulgarian BBAN (4a,6n,8c) consists of 4 alpha characters, followed by 6 numeric characters, then by 8 mixed-case alpha-numeric characters."

The BBAN is "part of an IBAN" (b), therefore it should only have upper case characters as defined in (a). However, in (b) also "mixed-case" characters are allowed.

217.89.55.36 (talk) 08:06, 9 August 2013 (UTC)Daebwae

Clarifying algorithm
I have undone the previous editor's changes and modified the previous version of the algorithm with view to keeping the computer program that will do the actual calculation as simple as possible. Martinvl (talk) 15:50, 24 October 2013 (UTC)

Reversion of 28 October 2013
I reverted the changes made to this article a second time.

The changes that I reverted were advertisements and therefore not suitable for Wikipedia. The comments added by that editor after his second attempt suggest that (s)he is unaware that Wikipedia in not a place to advertise any products. It should be noted that the editor concerned used a different IP address when making the second change. Martinvl (talk) 15:12, 28 October 2013 (UTC)


 * Plus, the site does not have proper legal information, so there is no way to know who is collecting the account numbers. Guidod (talk) 16:43, 28 October 2013 (UTC)

Registrar: ENOM, INC. Reseller: NAMECHEAP.COM Registrant Name: WHOISGUARD PROTECTED Registrant Organization: WHOISGUARD, INC. Registrant Street: P.O. BOX 0823-03411 Registrant City: PANAMA Registrant State/Province: PANAMA Registrant Postal Code: NA Registrant Country: PA

Editor reply for changes made on 28th October 2013 --- Hello Martinvl,

We have removed the whois privacy and added a privacy policy page which describes our non-logging policy for data sent through our website. The website www.reverseiban.com is an open source project designed to provide easy way of validating and reverse-lookup of IBANs.

No information is logged in our website and it is entirely free to use. In the process of gathering verification algorithms and reverse IBAN information for our website, we found out many details which are not widely available on the internet. For example Ukraine does not have a publicly available record for accurate IBAN validation since the country itself has not joined the IBAN standard. Ukraine however has four banks which issue IBAN numbers and we developed the validation algorithm and reverse information for all Ukrainian banks. We will also be happy to contribute to Wikipedia and update many of the IBAN related pages in wikipedia ( Similar to the Ukraine example ).

I hope you can reconsider your reversal of our publication since we had not intent of commercial advertising for our website, but rather sharing a useful and unique technique of understanding IBAN structuring.

Kind Regards, Andrew & Stan www.reverseiban.com — Preceding unsigned comment added by 89.215.67.28 (talk) 14:18, 29 October 2013 (UTC)

pronunciation
http://www.oxforddictionaries.com/us/definition/english/iban#IBAN --Espoo (talk) 09:36, 22 March 2014 (UTC)

Generic Mod-97 algorithm (current only works for accounts with size multiple of 7, like GB accounts)
The section Modulo operation on IBAN shows an algorithm to calculate the Modulo 97 of a number (for systems that are not able to manage so large numbers as integers) that fails for account numbers with a size different from 28 (or any other not multiple of 7). As example, Spanish IBAN accounts have a fixed size of 26 and calculation is wrong on that cases.

The algorithm used at UN_CEFACT_TBG5 and available as Javascript code at http://www.tbg5-finance.org/?ibandocs.shtml shows a working generic algorithm (named as String.prototype.ISO7064Mod97_10). This code, instead of get 9 digits and then the next 7 for each modulo calculation as in the article, it splits the number in "length / 7 rounded up" parts, and calculate each part with previous modulo appended at the beginning (this last is the same as in the article).

I unknown if there is an even more generic way (May be even bigger numbers fail with this approach?), but this almost works with all the currently registered countries for IBAN, can be tested in the official validator http://www.tbg5-finance.org/ibancheck.shtml. — Preceding unsigned comment added by IagoSRL (talk • contribs) 08:58, 6 June 2014 (UTC)


 * I'm sorry but I'm not seeing any obvious reason the algorithm currently shown at Modulo operation on IBAN would fail. Yes, the example is a 28-digit one so step 7's mention of the remaining 5 digits is specific to the example, but is that a problem? Could you expain more or give an example of a 26-digit sequence for which the current algorithm fails? NebY (talk) 10:35, 6 June 2014 (UTC)

Kosovo
Can someone please update Kosovo? I would do it myself but I'm not familiar with IBAN codes or how to format it on the article. Country code XK: page 44. Regards IJA (talk) 17:19, 25 September 2014 (UTC)
 * ✅ It's much easier than you might think - this was all it took! NebY (talk) 22:26, 27 September 2014 (UTC)
 * Cheers mate! IJA (talk) 10:58, 29 September 2014 (UTC)

00, 01, 99 are invalid
Based on this http://www.europeanpaymentscouncil.eu/index.cfm/knowledge-bank/other-sepa-information/iban-standard/ecbs-iban-standard-ebs204v32pdf/ paragraph 6.2 tells very clear how checkdigits are calculated and with that logic its not possible to get 00, 01, 99 and formal validator based on this http://www.tbg5-finance.org/?ibandocs.shtml however the validation rule 6.1 could give 98-mod(IBAN;97) a 1 for IBAN's with 97 check digits and would return same with 00 98 check digits and would return same with 01 02 check digits and would return same with 99 However these are interesting example numbers IT01T36000032000A9H00000037 seems to be existing and published on a website http://www.beppegrillo.it/listeciviche/liste/desenzanodelgarda/2014/09/passeggiata-popolare-5-ottobre.html These all pass validation rule to be 1 but normal calculation of checkdigits would give 97 and 98 PL00168013108811808750900001 HU00109180010000003964590013 IT01T36000032000A9H00000037 IT01P0504801685000000088001 IE01AIBK93729003711092 IE01AIBK93716904602041 IE01AIBK93607354095051 IE01AIBK93501832180033 IE01AIBK93417804195091 IE01AIBK93205121394079 IE01AIBK93129216794029 IE01AIBK93106320230082 GB01NWBK60721406833411 GB01MIDL40051568062439 GB01ABBY09012838484789 BE01377007911193 Junkew (talk) 14:04, 31 October 2014 (UTC)

128 bit is not enough
has the same length than any valid German IBAN. However it has 42 digits, so it no more fits into 128 bit. And Saudi Arabia has a BBAN of "2n,18c". This makes up a possible total length of 4+2+2+36 = 44 digits. So much to IPv6, it is even incapable to map all possible IBANs. 12:55, 15 August 2013 (UTC) 194.25.90.67 (talk) 12:41, 15 August 2013 (UTC)
 * That is not a valid German IBAN account, since  is required to be numeric. This means the total digits are 4+2+8+20 = 34 digits. A similar situation would be expected for Saudi Arabia.  — Preceding unsigned comment added by 8.23.159.66 (talk) 17:25, 17 October 2013 (UTC)
 * It is not necessary to use 128-bit arithmetic to validate an IBAN. The algorithm at International Bank Account Number is designed for 32 bit arithmetic. By taking 4 digits at a time instead of 9, it can easily be evaluated using16 bit arithmetic. Martinvl (talk) 20:26, 17 October 2013 (UTC)
 * What do you mean with "a similar situation would be expected for Saudi Arabia"? The argument by OP was that 128bit arithmetic does not suffice for a general IBAN. Proof: with 34 allowed alphanumeric digits in an IBAN, two of which can only be numeric (check digits), the resulting decimal number for checking could have up to (34-2)*2 + 2+1 = 66 (numeric) digits. Clearly, this doesn't fit into 128 bits, not even close. Indeed, the SWIFT IBAN registry v47, linked from this article, contains this example Malta IBAN: MT84MALT011000012345MTLCAST001S, which results in a 31+(2+4+7+1)=45 digit decimal integer. I have thus corrected the minimum integer arithmetic bits to 220 (=logb(10^66)). Marc Mutz (talk) 09:58, 5 February 2014 (UTC)
 * So what? The computation of the remainder mod 97 of an arbitrarily long decimal input string can be computed with an online algorithm ("online" here in its computational meaning, i.e., not that it uses the interwebs, but that it eats input digit by digit without storing it) using just 7 bits of storage (for the "current" remainder)--5.147.200.29 (talk) 18:23, 20 September 2015 (UTC)

BBAN format explanation
The article doesn't explain the differences in the BBAN format between e.g. "4n,10n,2n" (Kosovo) and "16n" (Austria, ...). If there's a difference it should be explained in the article. 217.89.146.254 (talk) 13:11, 30 November 2016 (UTC)

External links modified
Hello fellow Wikipedians,

I have just modified one external link on International Bank Account Number. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
 * Added archive https://web.archive.org/web/20131101223646/http://www.swift.com/dsp/resources/documents/IBAN_Registry.pdf to http://www.swift.com/dsp/resources/documents/IBAN_Registry.pdf

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

Cheers.— InternetArchiveBot  (Report bug) 17:14, 11 April 2017 (UTC)

BBAN format for AZ is wrong
Please check BBAN form for AZ, shall be revised to "4a,20c", see https://bank.codes/iban/structure/azerbaijan/ — Preceding unsigned comment added by 2A02:778:119:DD01:3175:13B9:77A1:75C2 (talk) 08:07, 31 July 2017 (UTC)

External links modified
Hello fellow Wikipedians,

I have just modified one external link on International Bank Account Number. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
 * Added archive https://web.archive.org/web/20101217080334/http://www.dowjones.de/site/2010/12/frist-f%C3%BCr-umstieg-auf-sepa-produkte-deutscher-widerstand-programmiert.html to http://www.dowjones.de/site/2010/12/frist-f%C3%BCr-umstieg-auf-sepa-produkte-deutscher-widerstand-programmiert.html

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

Cheers.— InternetArchiveBot  (Report bug) 22:14, 14 November 2017 (UTC)

Payment references
Many companies and transactions require a “purpose of payment”/“payment reference” similar to the “For”/“memo” line on cheques. Is this part of the IBAN standard or SWIFT? I don’t see anything about it mentioned it either article. —Wiki Wikardo 16:15, 4 April 2015 (UTC)
 * The IBAN target may be allowed by the straight-through processing standards, for example SWIFT ISO 15022. Guidod (talk) 17:35, 4 April 2015 (UTC)

HotLogo.com@gmail.com Mamumulay (talk) 03:18, 7 January 2018 (UTC)

HotLogo.com ID :693705 Mamumulay (talk) 03:18, 7 January 2018 (UTC)

HotLogo.com ID :693705 Mamumulay (talk) 03:19, 7 January 2018 (UTC)

Stuck
If i register and get my mail successfully ,this meand i only need to wait for the second email and get the final stage.or whats remaining.its really a long procedure.To be shortened with the relevant details only please. Marynyawes2 (talk) 23:25, 16 August 2018 (UTC)

How do i get the swiftcode?or iban? Marynyawes2 (talk) 06:40, 20 August 2018 (UTC)

São Tomé and Príncipe
Using the IBAN checker provided by UN CEFACT TBG5 ( https://www.tbg5-finance.org/?ibancheck.shtml ), I noticed that there's an available check for São Tomé and Príncipe, but this country can't be found in the IBAN format list. Is there a reason for that? — Preceding unsigned comment added by 80.62.174.194 (talk) 12:46, 3 February 2020 (UTC)

How do I make a payment on someone else’s account I have all the information
How do I make a payment on someone else’s account and I have all the information 162.213.23.97 (talk) 07:10, 7 April 2022 (UTC)

Urdu English
S 103.7.79.54 (talk) 01:28, 10 June 2022 (UTC)