Results 1 to 14 of 14

Thread: IBAN controle

  1. #1
    John Kuiper
    Join Date
    Apr 2007
    Location
    Almere
    Posts
    8,662

    IBAN controle

    Ik ben heel blij met het stukje code van Goleztrol om te controleren of een IBAN nummer wel de elf proef doorstaat.
    Maar wat is een fout rekeningnummer? Als ik mijn eigen oude rekeningnummer intyp voor zowel de ABNAMRO als ING, krijg ik een mooi IBANnummer terug, die ook nog door de ELF proef komt. Ook als ik 9999999 gebruik.
    Maar kan dat wel? Wat is eigenlijk een foutief rekeningnummer?

    Ik heb hier een demootje geplaatst om te laten zien.
    Attached Files Attached Files
    Delphi is great. Lazarus is more powerfull

  2. #2
    Correctie. Die code van mij controleert niet de elfproef op het (oude) bankrekeningnummer. En volgens mij heb ik dat ook nergens beweerd. Dat is een andere check die in principe los staat van IBAN.

    Deze code controleert alleen een aantal basisregels voor IBAN, namelijk de indeling en de geldigheid van het controlegetal (met een soort 97-proef). Een IBAN bestaat namelijk uit een tweeletterige landcode, een controlegetal, en een landspecifieke rekeningnummerindicatie. Die indicatie bestaat voor Nederland uit 14 tekens, namelijk een vierletterige bankcode en een tiencijferig rekeningnummer (waar weer een elfproef op van toepassing is), maar die landspecifieke controle zit er al niet in. Zelfs de lengte-controle is niet landspecifiek. Nederlandse nummers moeten altijd 18 tekens zijn, maar mijn code controleert alleen de algemeen geldende regels die zeggen dat de lengte tussen de 5 en 34 tekens moet zijn.

    Ik kan dus alleen maar benadrukken dat deze code echt heel minimalistisch is, en dus een hoop kan goedkeuren wat eigenlijk fout is.

    Als je specifiekere checks nodig hebt, dan kun je de landregels ook implementeren. Als je die voor Nederland implementeert, dan kun je kijken naar de beschikbare bankcodes voor Nederland, en naar de Elfproef voor het achterliggende oude nummer.

    Voor een implementatie van de Elfproef kun je verder het archief in duiken naar deze code van PsychoMark.
    1+1=b

  3. #3
    Quote Originally Posted by GolezTrol View Post
    Als je die voor Nederland implementeert, dan kun je kijken naar de beschikbare bankcodes voor Nederland, en naar de Elfproef voor het achterliggende oude nummer.
    En hoelang blijft de elfproef gelden voor die laatste nummers in de IBAN?
    Hoewel het huidige nationaal gebruikte 9- of 10-cijferige bankrekeningnummer onderdeel uitmaakt van de IBAN standaard, is het niet gegarandeerd dat de elfproef behouden blijft nadat Nederland over is op IBAN, waarvoor de wettelijke deadline 1 februari 2014 is.
    (http://nl.wikipedia.org/wiki/Elfproef)

  4. #4
    Zie je wel. Ik wist dat er een reden was dat ik dat niet geïmplementeerd had.
    1+1=b

  5. #5
    John Kuiper
    Join Date
    Apr 2007
    Location
    Almere
    Posts
    8,662
    Sorry, Goleztrol. Ik heb verkeerd gelezen (maar verder werkt het wel goed ).
    Delphi is great. Lazarus is more powerfull

  6. #6
    John Kuiper
    Join Date
    Apr 2007
    Location
    Almere
    Posts
    8,662
    Ik heb de code van Psychomark en die werkt goed met een ECHT bankrekeningnummer. Maar ING heeft de postbank overgenomen waarbij minstens 40% van de bevolking een bankrekeningnummer heeft die koter zijn dan 9 (7 of minder). Daarvan werkt die code niet. Op Wiki staat ook:
    Oud-Postbanknummers

    De ING is ontstaan uit een samenvoeging van Postbank en ING Bank. De Postbank hanteerde girorekeningnummers die geen controlecijfers bevatten. Alle getallen tussen 1 en 99999999 (acht negens) representeren in principe acceptabele gironummers. De ING heeft deze nummers niet uitgebreid met een controlecijfer, ook niet toen de merknaam Postbank in januari 2009 gestopt werd. De afwezigheid van een controlecijfer maakt oud-Postbankrekeningnummers onveilig voor overschrijvingen. Op 27 oktober 2009 diende een kort geding in Almelo van een gedupeerde die door twee cijfers te verwisselen in het oud-Postbankrekeningnummer van de begunstigde 43 duizend euro op een verkeerde rekening stortte.

    Om toch de veiligheid te garanderen van optisch gelezen acceptgiro's, waar oud-Postbanknummers bij betrokken zijn, gebruikt de ING een truc. Op de acceptgiro wordt een onveilig oud-Postbanknummer omgezet in een langer, veilig nummer. Dit gebeurt met de acceptgiro-elfproef. Het recept is als volgt. Tel het aantal cijfers van het oud-Postbanknummer. Indien dit aantal minder is dan 7 wordt het nummer links aangevuld met nullen zodanig het geheel 7 cijfers bevat. Het oud-Postbanknummer van de Nederlandse Staat is 1, dat wordt dus aangevuld tot 0000001. Aan dit zevencijferige nummer wordt een controlecijfer toegevoegd volgens de acceptgiro-elfproef. Als laatste actie moeten er dan nog twee nullen voor om het totaal aantal cijfers op 10 te brengen. Met andere woorden het onveilige oud-Postbanknummer van de Nederlandse Staat is 1 en het veilige nummer van de Nederlandse Staat is 0090000001. Deze verlengde nummers worden gebruikt op de strook van de acceptgiro die door de machine wordt gelezen. De ING staat niet toe dat de consument dit verlengde nummer gebruikt bij gewone overschrijvingen.
    Er kan dus geen controle worden uitgevoerd met 'gironummers' (getest met het voorbeeld hierboven).

    Klopt dat of kunnen andere dat weerleggen met een andere controle?
    Delphi is great. Lazarus is more powerfull

  7. #7

  8. #8
    Jan
    Join Date
    Oct 2007
    Location
    Mijdrecht
    Posts
    906
    Postbank nrs. voldoen inderdaad aan geen enkele controle. Bankrekeningnummers nog wel aan de 11-proef. Maar gezien het feit dat het aantal nummers beperkt is zou het me niks verbazen als Equens die 11-proef gaat weghalen in de toekomst.

  9. #9
    Voorlopig zijn er nog wel nummers beschikbaar. De elfproef zou ook moeten werken als het nummer langer wordt. En ook in IBAN rekeningnummers kun je dus een controle uitvoeren. Is het bankrekeningnummer, na het verwijderen van de voorloopnullen, korter dan 8 tekens, dan gaat het om een voormalig gironummer.

    V.z.i.w. is het 8e controlegetal, dat ING toevoegde om toch een elfproef te kunnen doen, niet overgenomen in IBAN. Dat zou ook niet nodig zijn, want IBAN bevat dus al een controlegetal, dus het is onwaarschijnlijk dat je onopgemerkte fouten maakt in het "postbank-deel" van een IBAN.

    Dat is waarschijnlijk tevens de reden dat er in de toekomst voor gekozen kan worden om nummers zonder elfproef te gaan gebruiken, dus als ze zeggen dat je de elfproef niet meer moet gebruiken, dan zou ik dat ook niet doen. Anders heb je straks een applicatie die geldige nummers weigert.
    1+1=b

  10. #10
    John Kuiper
    Join Date
    Apr 2007
    Location
    Almere
    Posts
    8,662
    Ik wilde het wiel opnieuw uitvinden door zelf een procedure te maken.
    Dit had het moeten worden:
    Code:
    function IBANElfProef(const aIBAN : string) : boolean;
    var RevIBAN      : string;
        ConvIBAN     : string;
        index        : integer;
        controlleNr  : int64;
        Karakter     : char;
    begin
      //verplaats de eerste 4 karakters naar het einde
      RevIBAN := uppercase(copy(aIBAN,5,length(aIBAN) - 4) + copy(aIBAN,1,4));
      //vervang elke letter door 2 cijfers, waarbij A = 10, B = 11, ..., Z = 35
      ConvIBAN := '';
      for index := 1 to length(RevIBAN) do
      begin
        Karakter := RevIBAN[index];
        if Karakter in ['A'..'Z'] then
          ConvIBAN := ConvIBAN + IntToStr(ord(Karakter) - 55)
        else
          ConvIBAN := ConvIBAN + IntToStr(ord(Karakter) - ord('0'));
      end;
      //bereken dan het getal modulo 97
      controllenr := StrToInt64(ConvIBAN);
      result := (controllenr mod 97) = 1;
    end;
    maar het getal is groter dan een int64 en hangt daarop. Nog even gekeken naar een bigint library, maar wilde niet werken met FPC.

    blijkt dat op deze code kant en klaar staat.
    Het controleert het echte IBAN-nummer (inclusief de oude postbanknummers)
    Delphi is great. Lazarus is more powerfull

  11. #11
    blijkt dat op deze code kant en klaar staat.
    Ha heerlijk! Een echte staartdeling uit de oude doos.
    Niks problemen met beperktheid in bytegrootte, gewoon het getal van links naar rechts te lijf gaan !

  12. #12
    @Jkuiper, die code van Torry doet volgens mij ook geen elfproef hoor. Waar baseer je dat op? En je eigen code ook niet. Je berekent zo te zien alleen het modulo 97 controlegetal voor IBAN, maar dat deed mijn code, waarmee je deze thread begon ook al.
    1+1=b

  13. #13
    John Kuiper
    Join Date
    Apr 2007
    Location
    Almere
    Posts
    8,662
    Nu ben ik verward.
    Ik ben vanuit gegaan wat bij http://nl.wikipedia.org/wiki/Interna...Account_Number wordt verteld onder het stukje valideren. Dat geeft toch aan dat je werkt met een correct IBAN nummer. Ik heb ook andere IBAN nummers geprobeerd met foute nummers en die worden inderdaad als negatief gezien.

    Als jouw code dat ook al deed, heb ik dan allang een controle van het IBAN nummer in 'mijn bezit'.
    Een test gedaan en inderdaad komen beide met hetzelfde resultaat.
    Dan vraag ik mij af wat IBAN calculator nog extra doet.
    NL20INGB0001234567 wordt wel geaccepteerd en NL50ABNA0001234567 niet.
    Doen zij nog op basis van de geselecteerde bank nog een ELF proef?
    Delphi is great. Lazarus is more powerfull

  14. #14
    Member
    Join Date
    Mar 2012
    Location
    Nederland
    Posts
    58
    Die IBAN calculator probeert waarschijnlijk de elfproef uit te voeren als je ABN AMRO als bank opgeeft. ING had geen rekeningnummers die a.d.h.v een elfproef gecontroleerd konden worden. De site geeft dat ook aan.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •