-
Notifications
You must be signed in to change notification settings - Fork 80
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SI IBAN prefix #5
Comments
As far as I read the documentation from the link you provided the checksum digits are still calculated conforming to the IBAN specification. My assumption is that the BBAN specific checksum is computed in a way, so that the IBAN check digits are always 56. Is that correct? |
Ping @Prome88 |
Hi, Yes you are correct, maybe it would be clearer with the example from wikipedia: SIkk bbss sccc cccc cxx k = IBAN check digits (always = "56") Few countries do not utilize the IBAN in full and have some fixed numbers / characters, usually as IBAN check digits. The question is if IBAN.generate() supports / will support this deviation(s)/addendum(s) from IBAN standard? |
Also I cannot get BIC from a valid SI IBAN. |
Getting BICs from the bank code of an IBAN is not done via some algorithm. It is a fixed list, where you have to lookup the bank code (that is part of the IBAN). We implemented that for Germany, since there is an official source that is more or less machine readable. You can have a look how that is done in this repository here. If there is such a list to get a mapping bank code to BIC for all slowenian banks, let us know or create a pull requests. We looked into this a while back, but there where no good sources for this kind of information. |
Also, back to topic on @Prome88 issue - let me try to understand your problem: Slowenian IBANs consist of And you want to generate a IBAN by just having National bank code ( Is that correct? Is there a source on the algorithm, that is behind that checksum? |
Central bank of Slovenia has this list available from: And the offical explanation on the algorithm: |
The list of BICs is appreciated, thanks! It is not as machine readable as it could be (.csv, .json or .xml), but at least - a list! Regarding generation of the BBAN checksums, I did not find any algorithm on the website you linked, also not on linked webpages (in slowenian) like this one , but the php lib for handling IBANs has the same issue here (open for over 2 years). It contains some resources - and as far as I could see also the wanted algorithm for Slowenia. I draw two conclusions here:
@Prome88 Did i understand your problem correctly (two comments up)? |
Hi, let me post a follow-up on this matter. The algorithm is specified (albeit in Slovene language), if you follow some of the links above to an official law amendment. To spare you the inconvenience, let me briefly sketch the algorithm: First of all you should know that each slovene BBAN is suffixed with two control digits so that modulo 97 you will always get 1. So BBAN % 97 = 1 always. IBAN validation:
Hence, in order to get a valid IBAN, you should always use 56 as control digits in the "SEPA header" (right after the country code) for every slovene IBAN. Of course, in order to facilitate a full-fledged BBAN validation, a special functional block should be added to Schwifty to manipulate IBANs by their corresponding BBAN validation algorithm, which is frankly speaking a lot of work. However, as a slightly better approximation of a full Slovene IBAN validation, a simple modification of SEPA specification »SI2!n5!n8!n2!n« can be made by using the right control digits 56 instead of 2!n. So, put at least »SI565!n8!n2!n« and you'll be slightly better off with Slovene IBAN validation. In fact, I have created a pull request #12 with this modification and some other improvements of the Schwifty internal IBAN spec JSON DB. Please review ... |
Fixed by #12 |
The specifications for SI IBAN are technically correct, but in reality the central bank of Slovenia uses only 56 as the "2!n" part after SI. Consiquently all IBANs start with SI56 - see the link for more info.
The text was updated successfully, but these errors were encountered: