Additional country-specific validations

[globalcitizen]

Addition of special case national-level validations, eg. Estonia's record states that the first digit of the bank code cannot be 0, and Slovenia's five digit bank ID always begins with 91. At least one version of the German BLZ (bank IDs) database is available over here: https://github.com/Bigfoot0485/IBAN

[globalcitizen]

More generally, we could consider building a library of national-level bank or payment institution identifier codes. This would be rather large and an optional extension and would be in competition with SWIFTRef... see https://swiftrefdata.com/ and https://www.swift.com/our-solutions/interfaces-and-integration/swift-apis/swiftref-api and http://www.slideshare.net/SWIFTcommunity/bbf2015swift-refwork-sessionfinal2jul2015

[globalcitizen]

http://www.betaalvereniging.nl/en/european-transactions/sepa-documentation-for-the-netherlands-2/bic-from-iban/ is an apparently always up to date list of all Dutch bank IDs, for example NL91ABNA0417164300 would be ABNA which is ABN AMRO BANK.

[globalcitizen]

http://www.pangaliit.ee/Estonian_Payment_Service_Provider_codes_and_BICs.xlsx is an apparently always up to date list of all Estonian bank IDs, for example EE382200221020145685 would be 22 which is Swedbank AS.

[globalcitizen]

I've started this rather maintenance-headache-inducing project in an exploratory fashion. Currently thinking the fields would be:

• IBAN country: The country in which the bank's identifier belongs.
• Bank identifier: What is present in the appropriate portion of the BBAN for the country in question.
• Bank title: In officious English, eg. 'Hong Kong Shanghai Banking Corporation Netherlands Limited'
• Bank SWIFT BIC: Where known.
• Bank short title: Something like 'HSBC' rather than 'Hong Kong Shanghai Banking Corporation Netherlands Limited'
• Bank URL: With prefixed http:// or https:// removed. In most cases the domain name will suffice.

Currently entries only exist for countries:

• EE: Estonia
• NL: Netherlands
• TL: Timor-Lest (East Timor)

It is probably an option to write a scraper to initially populate the other countries, but then we would be as hearsay and out of date as the rest of them (999 websites with IBAN format and BIC descriptions, some of which extract data from this library). Thus, adding the info manually is probably a reasonable idea, but it will be a longer term job... and the fruit should be shared with those in non-PHP languages, so perhaps I will break this off to a separate project and generate language-specific frontends for the database, similar to how geoip implementations operate. In fact, php-iban could probably be rewritten in such a way with some utility.

I've noticed that in the case of acquisitions, sometimes old SWIFT BICs exist but are not really in use anymore. Since the ultimate arbiter of currency in that arena is SWIFT itself, we should probably not attempt to determine what is 'current', but simply publish everything for which an IBAN institution identifier code is known, SWIFT be damned.

[globalcitizen]

List of banks of Andorra.

[globalcitizen]

List of banks and SWIFT codes in Slovenia and another one.

[globalcitizen]

Albania: 1, 2, 3. 4.

[globalcitizen]

https://snel.it/svn/misc/trunk/au3/BICs-2014-03-07.php seems to be a conversion table from IBAN bankid to SWIFT BIC... rather short though.

[AlexKratky]

@globalcitizen

IBAN validation for the Czech Republic is not 100% correct, there is a rule "a second part containing at least 2 and at most 10 digits, at least two of which may not be zero, with the initial zeros having no significance.". The second part is the account part, so for example CZ0401000000000000000000 should be an invalid IBAN. I have tried to create a regex that will fulfill this rule, but I am not able to create a negative lookahead that will match one non-zero digit at any position. The non-all zeros regex is simple (?![0]{10})(\d{10}), but for one non-zero character not, the only solution that I figured out is to write all scenarios (where the one digit could be) for example (?![0]{10})(?![0]{1}[1-9]{1}[0]{8})...(?![0]{8}[1-9]{1}[0]{1})(\d{10}) which is terrible regex.

Specification: https://www.cnb.cz/export/sites/cnb/en/legislation/.galleries/decrees/decree_169_2011.pdf

[Triplkrypl]

at least two of which may not be zero, with the initial zeros having no significance.

Yes our CZ bank account number is pain. I also tried create fix, but with one regex, i was out of idea.

[globalcitizen]

Aha! Thanks for the spec @AlexKratky. I will take a look at fixing it.

From my perspective, one major problem in validating the country-specific code is collecting real test IBANs. Another is finding the official specs. I really don't have time to work on open source recently.

That said, would you and @Triplkrypl be so kind as to create a pull request adding some additional real-world CZ IBANs to assist with testing a new implementation with the new information? I can then allocate some time to work through solving it.

Here is the file to be expanded: https://github.com/globalcitizen/php-iban/blob/master/utils/example-ibans/cz-ibans

Thanks.

[Triplkrypl]

Here are some new examples: #121 with some differences from previous ones.

[globalcitizen]

Re. CZ, thanks for the addition @Triplkrypl. I merged and published a new release as v4.2.1 for now, until time is available for further work. A clear demo script showing failures (expected vs received output) would assist with getting a fix through quickly. Please post as a new CZ-specific issue. Thanks.