php-iban

Memories. ~10 years ago I looked in to this stuff as part of adding national checksum support to an IBAN library. It was quite a mission to discover the number of systems out there, most of which were insufficiently documented or undocumented. Wound up reverse engineering quite a few of them (period braindump available[3]). In the end I wrote a function[1] which reverses an input known to fail a checksum to determine probable transcription errors based upon a manually compiled, exhaustive list of probable mistranscriptions[2]. I was quite impressed at how fast and accurate it was. From a systems architecture standpoint, I learned that there is really no excuse today for creating a system in which human transcription may occur without a checksum mechanism. Largely, however, QR codes and the trusted optical exchange of identifiers in physic

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 ig

You can also use a checksum like in IBAN, I have implemented some auto-detection of mistranscribed input based upon that over here: https://github.com/globalcitizen/php-iban

No. As I said, in these cases you use a CI tool to test on a broad range of environments. For example, here is a library I maintain with 12,000+ installs per month that is tested on 7 different environments every commit using Travis: https://github.com/globalcitizen/php-iban

Still better is grouped alphanumeric without potentially ambiguous characters (ie. generate number-1's but not letter-I's, generate number-0's but not letter-O's). I wrote a disambiguation library based upon the checksums present in IBAN @ https://github.com/globalcitizen/php-iban .. it's surprising how accurate the mistranscription suggestions are. In general, pure-number systems are better if possible, but where you have issues squashing in enough data in suitably compact form, transitioning to alphanumeric is better. You can also consider the use prefix-based systems, either utilizing temporal epochs or node-specific prefixes, both of which can utilize readable aliases. Finally, for anything expecting human transcription, checksum systems are awesome!

The correct solution to a transcription error is a checksum algorithm. See for example the implementation I made for reverse-searching incorrect IBAN from a liberal list of probable transcription errors @ https://github.com/globalcitizen/php-iban/ .. it's very fast, cheap and accurate.

Just yesterday I found myself reverse engineering checksum algorithms in various domestic bank account systems about the world. https://github.com/globalcitizen/php-iban/issues/39 I went for an explanation of some of the newer ones I hadn't heard of before (Damm) and it was painful. (The code was only a few lines, though!) While some algorithms had a pre-existing implementation, wiser than rewriting I simply nabbed them and evaluated. Most of the implementations were unreadable/undocumented and of dubious origin, many of the implementations claiming to provide the same algorithm delivered different results. Some of these work for some countries, some for others. No idea where the differences lie and not enough interest to bother finding out. Then of course there's the origin of these 'standards', ISO, who insist on charging 88CHF for a 5

Many of us from the pre-stripe era have implemented Luhn once or twice I'd say, very often in Javascript and web scripting languages! However, you really should avoid re-implementing this sort of thing, and particularly additional credit card checks as it's easy to make spurious assumptions (eg. credit card prefix should equal country of address of credit card, or of mailing address) which are in fact invalid. This stuff prevents actual sales and frustrates your users. For a slightly out there and arguably more interesting financial checksum algorithm, and one that is actually amazingly effective, do some statistics on mod97's performance. Realizing how good it was, a few years back for a cool hack in my IBAN library I wrote a mistranscription error suggestion system, which plays off the strengths of mod97. See https://github.com/globalci