I maintain an IBAN library.[0] There is actually a lot that is interesting about account numbers. Really well designed account number systems do not include sim

I maintain an IBAN library.[0] There is actually a lot that is interesting about account numbers. Really well designed account number systems do not include similar glyphs, for example both '1' and 'L' or both '0' and 'O' should not both be present. I have compiled a retroactive list of probable transposition errors in my library, which can recommend checksum-correct potential input intent through brute force search.[1] While many countries and specific banks had or have alternate checksum systems that pre-date IBAN, not all of them actually cover the whole account number (eg. may only cover the account number itself, not the sort code / branch code / bank code / whatever else). These are also falling out of use at an unreported rate so it is often difficult to determine whether or not they are now significant. Often a bank just starts ignoring its previous rules without telling anyone, leading to popular confusion. IBAN is a pretty well designed system, possibly excepting the mistranscription issues which it probably considered out of scope but could have seriously helped to avoid with recommendations / best practices. The point of all this is that you shouldn't reinvent the wheel... and that goes for digital banking and digital currency systems as well as any other system with identifiers that may need to be manually analyzed, compared, reported or transcribed. [0] https://github.com/globalcitizen/php-iban https://github.com/globalcitizen/php-iban [1] https://raw.githubusercontent.com/globalcitizen/php-iban/master/mistranscriptions.txt https://raw.githubusercontent.com/globalcitizen/php-iban/mas...