Spots 
Three of these you can catch before the payment leaves. The fourth you cannot, and pretending otherwise is how you end up trusting a validator that quietly lets money go to nowhere.
Every account identifier below is invented. The check digits are real, so the valid ones genuinely validate, you can run them yourself. 1. The IBAN checksum, which almost nobody actually checks
An IBAN carries its own error detection. Two digits at position three and four are check digits under ISO 13616, and they catch the overwhelming majority of typing mistakes including transpositions, which is what people actually do when copying a number off a PDF.
The algorithm is four lines. Move the first four characters to the end, turn letters into numbers where A is 10, and the whole thing mod 97 must equal 1. Here is a valid one, and the same one with two digits swapped:
Length matters too, and it is per country — 22 characters for Germany and the UK, 27 for France and Italy, 28 for Poland. Checking the checksum without checking the length lets through a value that is the right shape but truncated. 2. The sort code that lost its leading zero A UK sort code is six digits. It is not a number, and the moment anything treats it as one you lose leading zeros:
That happens in spreadsheets, in JSON that went through a loose parser, and in any code that calls int() on the way past. You will see it as a five-digit sort code, which is a tell, not a mystery:
Return the specific reason, not just False. "Five digits, probably a lost leading zero" tells an operations person what to do. "Invalid sort code" sends them back to the supplier for a value that was correct when it was sent. Seven digits is the opposite failure: the account number has bled into the field. 3. The BIC that belongs to a different country
A SWIFT/BIC is 8 or 11 characters: four for the bank, two for the country, two for the location, and an optional three for the branch. The eight-character form means head office; XXX in the branch position means the same thing spelled out. The shape check is a regex, and it is worth exactly as much as the cross-field check that follows it:
That last line catches a real and common case: a payee who banks in Ireland pasting the BIC of the same bank's UK entity. Both are well-formed. Together they are wrong, and neither field alone can tell you.
This is the general lesson of field validation most of what you can catch, you catch by comparing two fields to each other, not by inspecting either one. 4. The one that passes everything Now the reason this post exists.
Three of these you can catch before the payment leaves.