Diskussion:Internationale Bankkontonummer/Archiv/1

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:Internationale Bankkontonummer/Archiv/1#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:Internationale_Bankkontonummer/Archiv/1#Thema_1

Warum Modulo 97

Wer hat ne Antwort auf das Warum zur MOD 97 Frage - scheint eigentlich bestenfalls Einzelziffernfehler und vielleicht manchmal(!) noch Zahlendreher zu erkennen - gibts da nicht besseres und was zeichnet die 97 aus ? Eine Diskussion der Fehlererkennbarkeit am Spezialfall und/oder Verweis wär vielleicht ganz erhellend. (nicht signierter Beitrag von 82.83.48.146 (Diskussion) )

97 ist die größte zweistellige Primzahl. Die Modulo-Chiffre/Umkehrbarkeit funktioniert nur mit Primzahlen. Hat Simon Singh gesagt.

Nein, man kann modulo jeder Zahl rechnen/"chiffrieren" (z.B. auch 100 -einfach die letzten 2 Stellen) und umkehrbar ist das nie, da es mehr als 97 mögliche Kontonummern gibt. Damit die Prüfziffer zweistellig wird, muss der Modulus jedenfalls kleinergleich 100 sein. 100 merkt keine Fehler vor den letzten beiden Stellen, 99 merkt keinen Zahlendreher um 2 Stellen. 98=2*49 wirkt im Prinzip wie 49, außer dass die letzte Stelle "doppelt" kontrolliert wird. Also ist 97 wohl die größte vernünftige Zahl, die man nehmen kann. --Roentgenium111 20:35, 14. Feb. 2012 (CET)

PS: Die 97 kann sämtliche Einzelzifferfehler erkennen (da keine 10erpotenz durch 97 teilbar ist). Bzgl. Zahlendrehern müsste man prüfen, ob eine der Zahlen 9...999 (mit 2 bis 34 Neunen) durch 97 teilbar ist, das weiß ich nicht. Jedenfalls sind Zahlendreher um 1-4 Stellen erkennbar, da 9, 99, 999, 9999 nicht durch 97 teilbar sind. --Roentgenium111 20:40, 14. Feb. 2012 (CET)

PPS: 1/97 hat laut en:Recurring_decimal#Cyclic_numbers eine 96-stellige Periode, ist also durch keine der Zahlen 99..999 mit weniger als 96 Stellen teilbar. Die Prüfnummer sollte also alle Zahlendreher (von 2 Zahlen) erkennen können. Den Unterschied zwischen "9700" und "0097" sieht man so aber natürlich nicht ;-) --Roentgenium111 20:53, 14. Feb. 2012 (CET)

IBAN mehrdeutig?

Gibt es mehrfach vergebene IBAN? Wozu braucht man den BIC/SWIFT, wenn man eine IBAN angibt? Das habe ich bisher nicht verstanden und wird irgendwie aus dem Artikel auch nicht klar.--Juliabackhausen 17:09, 31. Jan. 2008 (CET)

Die Frage, wozu man den BIC braucht, kann ich auch nicht mit Sicherheit beantworten. Aber durch meinen beruflichen Kontakt mit dem Thema habe ich einen Verdacht: dir BIC identifiziert die Filiale/Zweigstelle, bei der das Konto verwaltet wird. Es scheint so zu sein, dass nicht alle Banken in allen Ländern in der Lage oder gewillt sind, das mit der IBAN eindeutig identifizierte Konto der Filiale/Zweigstelle zuzuordnen, bei der es verwaltet wird. Dafür scheint der BIC notwendig zu sein: um die Überweisung an die Kontoführende stelle weiterzuleiten.

IBAN ohne BIC

Siehe SWIFT.com BICplusIBAN: "Financial institutions and corporates use the BICPlusIBAN Directory to: [...] Look-up the BIC corresponding to an IBAN via the included bank/branch code"'. Ergo, falls die ehemalige Kontverbindung eine Bankleitzahl (bank code) oder Filialkennziffer (sort code) enthielt, und so in die IBAN eingeflossen ist, so kann man aus der IBAN den BIC herausbekommen. Ob Banken eine SEPA-Überweisung auch ohne BIC-Angabe überhaupt annehmen, ist damit aber nicht sicher. GuidoD 16:44, 29. Jul. 2010 (CEST)

„By use of an interbank agreement the Austrian banks intend to allow SEPA payments without BIC (IBAN only) if both ordering and receiving banks are within Austria.“

– APC December 2006: Status of preparation and plans as per December 2006: (Austria_SEPA_migration_plan_en.pdf)

„According to Gerard Hartsink, EPC chairman, "The EPC has, in general, no position on pricing [of extra services] by banks to their customers. The Regulation 2560/2001 requires that banks do not make a distinction in their pricing, provided that a correct IBAN and BIC is given by the customer in the payment order. If customers for whatever reason do not give the IBAN and BIC in a payment order, their bank has to deliver extra services and is fully entitled to charge the customer for the service." [...] Repair fees are not capped and this is a concern for corporates. Currently, repair fees are around €10 per payment across the whole of Europe. The ICP has not fixed or put an upper limit on these charges, which means that they are not subject to regulation. Admittedly, regulating repair fees is difficult as pricing is generally fraught with anti-competition issues. [...] To avoid the repair charges, corporates must make sure they comply with the ICP's IBAN/BIC requirements“

– HSBC, 12 Mar 2007: Corporate Update on BIC/IBAN Repair Charges, Michael Grainger, HSBC Global Transaction Banking http://www.gtnews.com/article/6669.cfm

„Mr Ruttenberg (ECB) appreciated this initiative. He recalled the Eurosystem stance outlined in the 6th SEPA Progress Report, namely that to stimulate the use of SCT by smaller users, it would be helpful if banks would require them only to use the IBAN; the BIC would be added by the bank of the ordering customer by retrieving it from databases available on the market. Furthermore, it was clarified that the aim is to make the SEPA products more comfortable and attractive for the end-users and to use these features as a stimulus to migrate to SEPA. // In the subsequent discussion, Mr de Sèze (Banque de France) indicated that the IBAN only is not sufficient in France for initiating payments. Mr Schrade (Deutsche Bundesbank) indicated that in Germany, the end-users have started to complain since Germany has one of the longest IBANs (22 digits) and therefore he supported the idea that it should be considered how to help the customers while stressing that an immediate remedy may not be available in the short term. Mr Ernst, assured that in Luxemburg most banks used the old account number and built it in the IBAN. He also indicated that the migration towards the use of IBAN went smoothly in Luxemburg Mr Santamaria suggested that the consumer complaints may be a result of insufficient communication and that more could be done in the domain; this view was also supported by the Co-Chair, Mr Hartsink. // The Chair concluded that the possibility of payment initiation via IBAN only still remains an open issue and the Eurosystem is awaiting the proposal of the EPC.“

– COGEPS, 15. März 2010: Thema "The future of payment initiation via IBAN without BIC" http://www.ecb.int/paym/grou.pdf

Hinweis: der Stuzza Vorschlag in Österreich für das IBAN-ohne-BIC Verfahren sieht vor, dass bei fehlendem BIC (vom Kunden) automatisch der Wert "NOTAVAIL" (vom Sendesystem) in das BIC-Feld der Bank-Nachricht eingetragen wird, sodass formal die Format-Anforderungen des EPC (für das Clearing) erfüllt sind. GuidoD 10:56, 31. Jul. 2010 (CEST)

Prüfziffern

Hallo, ich hätte hier die IBAN DE 02 600501017495530102 vorliegen. wenn ich die Prüfung auf richtigkeit mache stimmt die soweit. Wenn ich jedoch davon ausgehen würde, dass ich die Iban nicht habe, kommt bei der Ermittlung der Prüfziffer die Modulo 97 Summe 98 raus. das würde ja bedeuten, dass die Prufziffern 00 wären. Ist es dann etwa so, dass alle Prüfziffern, die unter 02 liegen auf min. 02 erhöht werden oder habe ich etwas übersehen? Also die IBAN muss jedenfalls so existieren, es ist das Konto des Landes BW mit Täglich über 100 Mio umsätzen;-) lg 193.197.148.126 10:36, 8. Jul. 2011 (CEST)

Wer die Erläuterung des Prüfziffernverfahren unter IBAN#Validierung_der_Pr.C3.BCfsumme nachvollziehen will, stößt auf widersprüchliche Darstellungen. Im Text (im Teil 1.) ist von Zahlen und + die Rede, im Beispiel werden die Teile dagegen als Zeichenketten hintereinandergestellt (2 + 1 ist bei mir 3 und nicht 21). Was stimmt jetzt? --91.8.152.229 18:33, 12. Jan. 2014 (CET)

Seit Januar 2009 sind die Banken verpflichtet, SEPA-Überweisungen anzubieten

Hierzu hätte ich gerne eine Quelle, da ich erst heute in einer Präsentation der Deutschen Bundesbank (von 2011) wieder gelesen habe, dass es im Gegensatz zu den SEPA-Lastschriften gerade für die SEPA-Überweisungen noch keine Verpflichtung gibt. (nicht signierter Beitrag von 217.110.62.222 (Diskussion) 16:50, 9. Feb. 2012 (CET))

BLZ Berechnungsmethode

Ich hab mir mal die Bankleitzahlendatei heruntergeladen, aber das angegebene Feld gibt es dort nicht. Das Feld "Prüfziffer-berechnungs-methode" hat erstmal nichts damit zu tun, dieses Feld ist zweistellig alphanumerisch und kennt 113 Varianten (00 bis D9), wobei das zugehörige beschreibende Dokument mit 82 Seiten verdeutlicht, dass nicht die IBAN gemeint ist, sondern dass die Kreditinstitute in ihre Kontonummern (ohne Bankleitzahl) eine Prüfziffer eingebaut hatten. Die "neue Bankleitzahlendatei" ist noch nicht frei verfügbar - laut Abschnitt Bankleitzahlendatei "erfolgt die Bereitstellung der Bankleitzahlendatei ab dem 3. Juni 2013 in zwei Versionen: einer unveränderten Version und einer um das neue Kennzeichen erweiterten Version. Die erweiterte Version wird ausschließlich im ExtraNet veröffentlicht." und im folgenden Abschnitt zum ExtraNet wird klar, dass man dafür eine Registrierung braucht. Eine technische Nachprüfung der Angaben kann wohl erst zu einem späteren Zeitpunkt erfolgen, vermutlich ab September mit dem nächsten Update der Bankleitzahlendatei im freie Download mitsamt der IBAN-Kennziffer. GuidoD 14:22, 11. Jun. 2013 (CEST)

Eine Veröffentlichung der IBAN-Regeln ist nicht geplant. Dieses Dokument und die zugehörige erweiterte BLZ-Datei steht nur registrierten Benutzern zur Verfügung. Ich habe Zugriff auf diese Dokumente und wollte nur deutlich machen, dass man die IBAN in vielen Fällen eben nicht einfach aus BLZ und Kontonummer ermitteln kann. Viele Softwareprodukte und Dienste errechnen die IBAN lediglich nach der Standard-Regel ("000000"). Ein Teil der so errechneten IBANs ist schlichtweg falsch. --Loonie (Diskussion) 00:02, 15. Jun. 2013 (CEST)

Gerade für Firmen als Kunden der Banken ist doch aber die IBAN-Berechnung wichtig, sodass sie nicht jeden einzelnen ihrer eigenen Kunden anschreiben müssen und sie nach der IBAN fraaaagen müssen. Tatsächlich zeigt ja eine der Referenzen auf genau so einen Dienstleister, die eben die IBAN nicht nur nach Standard-Regel erstellen, sondern sich auf die Sammlung der Bundesbank stützen. Der große Umfang der Nicht-Standard-Regeln sollte eigentlich für Firmen schon hinreichend sein, es gar nicht selbst zu versuchen, sondern über einen solchen Service zu gehen.

Den Download zu absichtlich zu verstecken, wäre damit allerdings eine ziemlich sinnlose Aktion, und könnte vermutlich auch angefochten werden. Dass man erstmal eine Umstellungsphase der BLZ-Datei einplant, ist mir dagegen einleuchtend. Eine Anfrage zum freien Zugang hätte ich also frühestens im September rausgeschickt - wenn du sicher bist, dass das nicht geplant ist, könnte man das natürlich auch jetzt schon machen? GuidoD 08:30, 15. Jun. 2013 (CEST)

Stimmen die Ländercodes u.a. der französichen Überseegebiete in der Liste?

Denn laut dem Artikel über die ISO 9362(BIC) hält sich die IBAN eben nicht 100% an die ISO 3166-1. Dort heisst es, dass alle französischen Überseegebiete in der IBAN mit FR beginnen. In der englischen Wikipedia-Liste habe ich diese z.B. auch nicht gefunden. (nicht signierter Beitrag von 62.159.240.138 (Diskussion) 09:24, 24. Okt. 2013 (CEST))

seit wann?

Schade, dass kein konkreter Zeitpunkt genannt wird, seit wann es die IBAN gibt. Auf Kontoauszügen vom Mai 2003 fand ich sie das erste Mal. --Andreas Schwarzkopf (Diskussion) 09:48, 9. Jan. 2014 (CET)

Naja, IBANs gibt es meistens schon länger, als sie gebraucht wurden - man könnte das Datum nehmen, an dem die deutsche IBAN das erste mal in ihrem Format registriert wurde. Könnte man theoretisch sogar herausbekommen, allerdings ist das ja auch nicht generell "IBAN existiert" sondern die deutsche IBAN. Wirklich gebraucht wurde aber auch diese erst mit der EU-Überweisung, daher kommt 2003 als Zeitpunkt sehr gut hin, an dem sie dir zugeteilt wurde. Vor diesem Zeitpunkt war sie irrelevant, und grenzübergreifende Überweisungen wurden mit SWIFT und den nationalen Kontonummern gemacht. GuidoD 14:16, 9. Jan. 2014 (CET)

Hier steht übrigens, Deutschland hat die IBAN per 1.2.1998 übernommen. [1] ... GuidoD 14:23, 9. Jan. 2014 (CET)

Online-Validierung / Unterkonten / Lesbarkeit / Einheitliche Länge

• Betreffend Online-Validierung und Unterkonten habe ich mal BLZ 20041133 gegoogelt, das ist wohl Comdirect. Unterkonto leitet weiter, dort sind aber keine 2-, sondern 1- oder 4-stellige Unterteilungen aufgeführt. Wie wurde denn bei einer herkömmlichen Überweisung das Unterkonto abgebildet? Es gibt ja nur BLZ und Kontonummer.
• Und die BLZ konnte beim Online-Banking nach der Eingabe einfach validiert werden, weil im nächsten Schritt dann immer der Name/Ort aufgelöst wurde (zumindest bei VR/Spk).
• Bei den deutschen IBAN mit 22 Zeichen widerspricht die Vierergruppierung mit übriggebliebenen 2 Stellen zumindest meinen Gewohnheiten: Eine Kontonummer (oder auch Telefonnummer) gruppiere ich gedanklich 12 3456 und nicht 1234 56. Also hätte ich bei den Instituten, die keine Unterkonten verwenden, einfach immer 00 angehängt.
• Es wäre m.E. wesentlich einfacher gewesen, bei sämtlichen Ländern mit Nullen auf 36 Zeichen aufzufüllen, dann wäre das auch mit den Vierergruppen stets aufgegangen.

-- Heribert3 (Diskussion) 14:45, 12. Jan. 2014 (CET)

Hallo Heribert, zu Deinem ersten Punkt: Der Link Unterkonto bezieht sich auf den Kontenrahmen der kaufmännischen Buchhaltung, er hat mit den Bankkonten nichts zu tun. Unterkonten werden bei vielen Banken verwendet, um weitere Konten für einen Kunden unter einer gemeinsamen Kundennummer (das ist normalerweise die Kontonummer des Girokontos) zu führen. Bei vielen Banken wird die Unterkontonummer vorangestellt, bei anderen wird sie hinten angehängt. Die Unsitte ist, daß einige Banken (Deutsche Bank, Dresdner Bank, Comdirect...) eine Unterkontonummer 00 am Ende oft einfach weglassen (auch auf der Kundenkarte). Bei der Prüfung müssen sie dann u.U. wieder eingefügt werden, wie z.B. bei der obigen BLZ (s. unter http://www.am.hs-mannheim.de/konto_check/konto_test.php?methode_txt=on&blz=20041133&kto=1234400&kto_test=Kto.+pr%FCfen&ausgabe=2&sub=2 (Test mit Unterkonto) bzw. http://www.am.hs-mannheim.de/konto_check/konto_test.php?methode_txt=on&blz=20041133&kto=12344&kto_test=Kto.+pr%FCfen&ausgabe=2&sub=2 (Test ohne Unterkonto). (nicht signierter Beitrag von Michel plugge (Diskussion | Beiträge) 10:37, 28. Jan. 2014 (CET))

"Auf Forderung der USA wurde die IBAN-Pflicht in der Türkei schon zu Beginn 2010 eingeführt." ?

Diese Behauptung ist unbelegt. Weder finde ich dazu auf die Schnelle etwas, noch ist erscheint mir der Zusammenhang irgendwie plausibel - schliesslich haben die USA selbst ja nicht einmal IBAN definiert. (nicht signierter Beitrag von 87.245.84.31 (Diskussion) 17:11, 14. Feb. 2014 (CET))

IBAN outre-mer

Die französischen Überseegebiete sind in der en-wikipedia nicht gelistet, bei SWIFT gibt es nur einen Eintrag für Frankreich mit folgendem Kommentar

FR. Note that French Republic regional country codes used for companies identification (BIC) do not contradict the generic FR country code at IBAN level. Regional and administrative French Republic subdivision country codes : French Guyana (GF), Guadeloupe (GP), Martinique (MQ), Reunion (RE), French Polynesia (PF)*, French Southern Territories (TF)*, Mayotte (YT), New Caledonia (NC)*, Saint Barthelemy (BL), Saint Martin (French part) (MF), Saint Pierre et Miquelon (PM), and Wallis and Futuna Islands (WF)*.

bezügliche SEPA-Überweisung steht der Kommentar

"Yes, included GP, RE, MQ, GF, PM and YT"

Die hier angegebenen IBAN-Formate für diese Länder mit nicht-FR IBAN-Codes sind vermutlich reine Erfindung. GuidoD 12:22, 29. Apr. 2014 (CEST)

Übrigens, die deutsche Wikipedia listet Isle of Man, Guernsey und Jersey gar nicht (die britischen "Crown Dependencies") - sie sind über "GB"-IBAN-Codes jedoch erreichbar, siehe [2] GuidoD 12:22, 29. Apr. 2014 (CEST)

IBAN Länder lt. SWIFT

Auf der SWIFT hompage gibt es ein Dokument das von sich behauptet, dass es alle IBAN formate enthält (This registry provides detailed information about all ISO 13616-compliant national IBAN formats.) IBAN_Registry

Es fehlen in der SWIFT Liste 3 länder, die es in der Wikipedia Liste gibt: FO Faröer LG Grönland MA Marokko

Hat jemand eine Erklärung dafür?--(nicht signierter Beitrag von Bmandl (Diskussion | Beiträge) 19:51, 23. Jan. 2009 (CET))

Färöer und Grönland stehen in der SWIFT-Registry unter Dänemark. Sie gehören zum Königreich Dänemark, verwenden aber ihre eigenen Ländercodes.

Über Marokko finde ich auch nichts offizielles in der SWIFT-Registry. In der englischen Wikipedia ist Marokko auch nicht aufgeführt. Solange keine offizielle Quelle angegeben ist, sollten wir Marokko wieder entfernen.--Tom 03:07, 2. Mai 2010 (CEST)

(Diskusion sinnerhaltend gekürzt. Erledigtes entfernt. Link aktualisiert.) Auch in der IBAN Registry Release 47 vom Januar 2014 ist Marokko nicht enthalten. Der Ländercode MA ist laut ISO-3166-1-Kodierliste#M richtig, doch bei in den ca. 80 Treffern einer Websuche nach "iban marocco accept" ist keine IBAN Kennung mit MA... zu finden. Gegenprobe mit germany, tunisia und 5 weiteren ergibt je ca. 30k bis 60k Treffer. Es ist unwahrscheinlich, daß es keine marokkanischen Online-Händler gibt, welche IBAN Überweisungen akzeptieren würden, so es IBAN in Marokko gäbe. Ich nehme Marokko raus, würde mich jedoch über Korrektur mit verlässlicher Quellenangabe freuen. --Double7 (Diskussion) 17:27, 27. Mai 2014 (CEST)

Formatierung?

Gibt es irgendwas Verbindliches hinsichtlich der Formatierung von IBANs? --Hagman 16:29, 13. Mai 2009 (CEST)

Das Format zur elektronischen Verarbeitung enthält keine Leerzeichen. Aber für die Schriftform ist festgelegt, dass nach jeweils 4 Zeichen ein Leerzeichen einzufügen ist.--Tom 02:05, 2. Mai 2010 (CEST)

In der IBAN_Registry finden sich IBAN "electronic format example" und "print format example", welche diese Aussage stützen. IBAN#Schreibweise widerspricht leider. Bedauerlicherweise besteht eine Zugriff-Hürde von ca. 150 Euro für das ISO Dokument 13616-1:2007, es wäre nett wenn jemand mit Zugriff auf das Dokument recherchieren könnte ob die 4er Gruppen in "Druck"-Form nun Pflicht sind oder nicht.--Double7 (Diskussion) 17:27, 27. Mai 2014 (CEST)

Ausspähen von Kontodaten / Online-Validierung

Der Ebene 3 Abschnitt "Weblinks" unter "Einzelnachweise" ist mir ein rechter Dorn im Auge. Wieso hat der Artikel 2 Abschnitte "Weblinks", von denen einer auch noch auf zig Sites verweist, auf denen nichtsahnende Benutzer ihre Kontodaten angeben. Teilweise nicht mal in DE gehostet... Kann ja sein, dass die Anbieter alle hehre Absichten haben, aber ich wäre für eine vollständige Entfernung des Abschnitts, oder zumindest eine deutliche Warnung. -- 188.97.65.16 09:33, 29. Jul. 2010 (CEST)

Danke für den Hinweis, hab die Abschnitte zusammengefasst und bin mal die Weblinks durchgegangen. GuidoD 10:36, 29. Jul. 2010 (CEST)

Es fehlt immer noch die deutliche Warnung. Der Absatz "Online-Validierung" widerspricht an mehreren Stellen dem Artikel, in denen gem. ISO nur Banken für die Erzeugung der IBAN zuständig sind. Inzwischen ist SEPA/IBAN eingeführt und man darf davon aus gehen, dass alle Kunden von ihren Banken ihre persönlichen IBANs erhalten haben. Für diesen Zweck gibt es gar keinen Grund mehr eine Online-Validierung vorzunehmen. Bleibt die Prüfung von fremden Kontodaten. Laut meiner Bank wird die Prüfsumme der IBAN bei Bearbeitung der Bank-Formulare geprüft, das Online Portal der Bank nimmt erst keine IBAN mit falscher Prüfsumme an. Die Prüfung erfolgt also immer wenn ich eine legitime Überweisung auslöse. Daher gibt es keinen Grund für mich fremde Kontodaten auf einer fremden Webseite einzugeben. Die Daten-Skandale und Daten-Diebstähle 2013/2014 sollten eigentlich auch die letzten sensibilisiert haben. Wollen Sie das jemand Ihre Kontodaten in irgend einer Webseite eingibt? Gibt es für Wikipedia einen Grund ein solches Verhalten zu begünstigen? Gibt es weitere Argumente die bei Änderung des Absatzes berücksichtig werden sollten? --Double7 (Diskussion) 22:53, 27. Mai 2014 (CEST)

Maximale Länge

Die maximale Länge ist mit 34 Zeichen definiert. Bei uns in der EDV wird derzeit eine Erweiterung auf 40 Zeichen diskutiert. Sind mehr als 34 Zeichen irgendwo geplant? Weiss jemand darüber Bescheid? (nicht signierter Beitrag von 162.25.24.148 (Diskussion) 13:08, 16. Jan. 2013 (CET))

Die maximale Länge von 34 ist, was die IBAN Registry erlaubt. Und die hat keinen Grund, mehr als das durchzulassen - Pläne für einen Versuch geibt es aber auch keine. GuidoD 20:38, 17. Jan. 2013 (CET)

Eine Erweiterung auf 40 Zeichen macht keinen Sinn. Sinnvoll ist eine Erweiterung auf 42 Zeichen in Eingabemasken, damit die maximal erlaubte IBAN Länge mit Leerzeichen für 4er Gruppentrennung eingegeben werden kann. Es wäre dann Aufgabe der EDV die Leerzeichen zu entfernen und so die elektronische IBAN zu weiteren Verarbeitung zu erzeugen.
Hintergrund: In meinem Umfeld empfinden viele, sowohl jüngere als auch ältere, die IBAN als unübersichtlich lang. Die Handhabung mit Computer ist zwar akzeptiert, copy&paste sorgt für fehlerfreie Übertragung von/in ein Online-Formular. Doch bei Einmalrechnungen in Papier wird die IBAN heute überwiegend (sogar von Banken) ebenfalls am Stück ohne 4er Gruppen geschrieben und ich ertappe mich selbst, wie ich mühsam mit dem Finger die Leseposition wie ein Grundschüler mitschiebe. An 4er Gruppen kann sich mein Auge erheblich besser orientieren und ich kann die IBAN sowohl flüssig als auch korrekt abschreiben. Wie gesagt, es geht vielen in meinem Umfeld so, die schon Mal mehrere IBANs abtippen mussten.
Wollte man eine Rechnung schreiben die beide Gruppen zufrieden stellt, müsste man beide Formate angeben. Dabei wäre es doch ein leichtes nur das 4er Gruppen Format für alle Informationsflüsse zu nutzen, in denen ein Mensch beteiligt wäre und dem Computer die Aufgabe zu überlassen die überschüssigen Leerzeichen zu entfernen. Eine Umwandlung zwischen den beiden Formaten sollte für Computer und Programmierer eigentlich trivial sein.--Double7 (Diskussion) 22:53, 27. Mai 2014 (CEST)

Fehlende Quellen für IBAN-Struktur

Ich habe ein Script geschrieben, mit dem die IBAN-Stuktur mit den Quellen geprüft werden kann. Als bekannte Referenzen entsprechend der englischen Wikipedia gelten dabei SWIFT und Nordea

• http://www.swift.com/dsp/resources/documents/IBAN_Registry.txt
• http://www.nordea.com/Our+services/International+products+and+services/Cash+Management/IBAN+countries/908462.html

Folgende Probleme treten dabei zutage:

• HK=Hongkong existiert weder bei SWIFT noch Nordea
• MA=Marokko existiert weder bei SWIFT noch Nordea
• ST=São Tomé und Príncipe - existiert nicht bei SWIFT, wird bei Nordea mit "PT"=Portugal gelistet
• CF=Zentralafrikanische Republik - existiert nicht bei SWIFT, wird bei Nordea mit "FR"=Frankreich gelistet

die englische Wikipedia beschränkt sich auf bequellte Einträge, die vier hier genannten existieren dort nicht. Soweit keine Quellen bekannt werden, sollten diese Einträge in der deutschen Wikipedia ebenfalls gelöscht werden. GuidoD 22:29, 27. Apr. 2014 (CEST)

Hinweis: ich habe mal beispielgebend bei Hongkong den edit herausgesucht, der Kommentar enthält keine Quellenangabe. Bei den anderen habe ich es derzeit nicht geprüft, vermute jedoch ebenso, dass keine Quelle existiert. GuidoD 22:29, 27. Apr. 2014 (CEST)

Marokko bereits entfernt, suche nach Hongkong mit dem gleichen Muster brachte zwar auch um 50k Treffer, aber 20 Stichproben führten zu "ausgerechneten" IBAN oder Erklärungen wie man es ausrechnen kann. Suche nach Auktionsanbietern aus Hongkong brachte bei ca. 30 Stichproben ebenfalls keinen Anbieter mit IBAN zu Tage. Gleiches scheint auch die Suche nach China ergeben, auch wenn es noch nicht in der Liste steht ist die Möglichkeit groß auf ausgerechnete IBAN zu stoßen, die keine offiziellen sind. --Double7 (Diskussion) 22:53, 27. Mai 2014 (CEST)

Lösch/Archiv Antrag für Diskusionsbeiträge

Entschuldigung, ich habe beim letzten Edit entgegen den Regeln fremde Beiträge editiert. Ich hoffe ich habe meine Edits in der Beschreibung ausreichend genug dokumentiert. Mir sind bereits erledigte Sachen aufgefallen mit denen ich ein wenig Zeit verschwendet habe, und ich fand besser machen halt angebrachter als nur still ärgern. Es ist passiert und ich bin zu faul alles wieder rückgäng zu machen, meine Beiträge erneut einzuarbeiten und hoffe auf das nachträgliche stille Einvernehmen der Betroffenen. Als Entschuldigung gehe ich die Diskusion nochmal durch und verschiebe weitere erledigte/fragliche Beiträge nach hier unten. Mit Archivierung habe ich noch keine Erfahrung, traue es mir nicht zu und weiß auch nicht ob es für diese Diskusionsseite angebracht ist. --Double7 (Diskussion) 22:53, 27. Mai 2014 (CEST) PS: Aus der Entschuldigung wurde eine kleine Strafarbeit, hat vier Stunden gedauert, oben wurde kontocheck und entfärben thematisch passend verschoben. Unten findet sich veraltetes und erledigtes, jeweils mit kurzer Begründung.

SWIFT-Registry

Die Seite der ECBS mit der Liste der nationalen Formate ist nicht mehr erreichbar. Deshalb habe ich den Link durch einen auf die neue SWIFT-Seite ersetzt. Dort steht auch IL=Israel. Im Übrigen hat Tunesien immer die IBAN-Prüfziffer 59, weil die nationale Kontonummer schon 2 genauso berechnete Prüfziffern enthält. Gfis 23:17, 23. Nov. 2007 (CET)

Link wieder aktuell, IL ist gelistet, Prüfziffer kann ich nicht prüfen, wäre das wichtig? --Double7 (Diskussion) 22:53, 27. Mai 2014 (CEST)

gibt es IBAN mit Prüfziffer 97 oder 98 ?

Kann irgendjemand bestätigen, dass es tatsächlich eine von einer Bank vergebene IBAN mit Prüfziffer 97 oder 98 gibt? Egentlich sollte es diese nicht geben, weil laut ISO 7064 die Formel zur Berechnung der Prüfziffer lautet:

Control digit (2) = mod(98 - mod(data * 100, 97), 97)

(siehe http://www.europebanks.info/ibanguide.htm)

Ich habe noch keine gesehen, aber fast alle Prüfziffernberechnungen (sowohl Implementerungen als auch Beschreibungen) die ich gefunden habe sind falsch, weil sie

98 - mod(data * 100, 97)

anstelle von

mod(98 - mod(data * 100, 97), 97)

verwenden.

Das im zitierten Link enthaltene zweite "mod97" ist falsch, siehe die ursprüngliche Beschreibung EBS204.pdf oder eben die ISO-Norm 13616. Das Ergebnis von mod97 wird von 98 abgezogen und ggf. mit "0" auf 2 Stellen erweitert. Deshalb gibt es sehr wohl IBANs, die mit DE98 oder DE97 beginnen, aber keine (korrekten) mit DE99, DE00 oder DE01. --Gfis 23:13, 30. Nov. 2008 (CET)

Die Behauptung, dass es keine korrekten IBANs mit Prüfziffer 00 oder 01 gibt ist definitiv falsch! Ich habe die Frage hier gestellt weil mir aufgefallen ist, dass es diese gibt. Konkret handelt es sich dabei um italienische IBANs (IT00.... IT01....) die 100%ig echt und korrekt sind.

Hat jemand WIRKLICH schon einen echten (also von einer Bank vergebenen) IBAN mit Prüfziffer 97 oder 98 gesehen?

Die IBAN meines eigenen Kontos beginnt mit DE98. Und die kommt von der Bank. Also definitiv: ja! --89.0.155.66 11:59, 2. Dez. 2009 (CET)

Die Links sind tot und die Webseiten sehen eher nach blog als nach offizieller Seite aus. Glaubt man dem letzten Beitrag, lautet die einfache Antwort auf die Frage nur "ja". --Double7 (Diskussion) 22:53, 27. Mai 2014 (CEST)

Quelle fehlt

FÜr die Aussage"Die IBAN kann in Deutschland derzeit lediglich für grenzüberschreitende Zahlungsanweisungen (in das Ausland oder aus dem Ausland) verwendet werden. " fehlt die Quelle..

Inzwischen obsolet, da IBAN auch für innerdeutsche Überweisungen genutzt werden kann. --Double7 (Diskussion) 22:53, 27. Mai 2014 (CEST)

Weblinks nicht "vom Feinsten"

Es gibt viel zu viele Links auf Softwarepakete zur Berechnung. So schwierig ist die Berechnung nun auch nicht (siehe meinen vorvorigen Diskussionsbeitrag). Selbst berechnen soll man die IBAN sowieso nicht. Falls niemand etwas dagegen hat, werde ich die Links auf Software auf 1-3 reduzieren. --Gfis 23:13, 30. Nov. 2008 (CET)

Inzwischen können die Banken selbst das bieten. Zustimmung das es niemand selbst tun sollte, darauf weist auch der Artikel hin. Erledigt? --Double7 (Diskussion) 22:53, 27. Mai 2014 (CEST)

ECBS

Ich habe die Links auf die Homepage ecbs.org entfernt, da das alte ECBS im EPC aufgegangen ist und der neue Betreiber der Webseite in keinem Zusammenhang zum alten ECBS steht, vgl. http://de.wikipedia.org/wiki/European_Committee_for_Banking_Standards und http://de.wikipedia.org/wiki/Diskussion:European_Committee_for_Banking_Standards. Entscheidend sind heute nicht mehr die alten EBCS-Dokumente, sonder der ISO-Standard für den inzwischen SWIFT zuständig ist (und der hier ja auch schon verlinkt ist). --130.75.186.13 14:17, 3. Dez. 2008 (CET)

Die wenigen verbleibenden ECBS verweise im Artikel sind noch brauchbar. Erledigt. --Double7 (Diskussion) 22:53, 27. Mai 2014 (CEST)

IBAN-Pflicht

Deutschland ist laut Presseberichten das einzige Land, dass sich gegen die IBAN-Pflicht gestemmt hat. Mit der Beschlussvorlage der Kommission, die jetzt veröffentlicht wurde, ist man damit aber durch - die Abschaffung der nationalen Bankleitzahlsysteme kommt. Ab hier bin ich gespannt, ob nun zügig wie in Österreich wenigstens für Inlandsüberweisungen auf die BIC verzichtet werden kann. Denn dass man dafür kein Verfahren definiert hat, kann ja auch politische Gründe haben, um mit Hinweis auf "Extrem-Kontonummering" gegen die IBAN-Pflicht agitieren zu können. GuidoD 05:50, 17. Dez. 2010 (CET)

NTV meldet übrigens [3] "Bei dem Code zur Identifizierung der Bank (BIC), der elf Buchstaben hat, sollen die Banken nach dem Willen der EU-Kommission den Kunden helfen. So fügen in Belgien und Österreich Institute bei Überweisungen den BIC-Code automatisch ein. Denkbar sei auch, dass die Kunden ihre vertrauten Zahlen verwenden und die Banken diese in IBAN und BIC umrechnen. In Luxemburg, Italien, Griechenland und Slowenien ist die Umstellung laut EU-Kommission schon reibungslos vollzogen worden." / -> / bei Schweiz/Luxemburg war mir die IBAN-Umstellung bekannt, bei den anderen bräuchte es vielleicht ein paar Referenzen. GuidoD 17:12, 17. Dez. 2010 (CET)

Inzwischen erledigt? --Double7 (Diskussion) 22:53, 27. Mai 2014 (CEST)

Beerdigungsrituale

Mit Beschluss vom 14. Februar 2012 ist die Nutzung der BIC bei Überweisungen mit IBAN beerdigt - allerdings nur für den SEPA-Raum.

Wenn die Inlandsüberweisungen ab 1. Februar 2014 zwingend mit IBAN umgestellt werden ("IBAN-Pflicht"), so erfolgt dieses ohne die Angabe der BIC. Zieht man die damit die geschichtlich gewordenen Argumentationen heran, letztlich die einzige Möglichkeit, überhaupt die IBAN im täglichen Zahlungsverkehr einzuführen, ohne dass sich europäische Institutionen ziemlich unbeliebt gemacht hätten. Ein Zeitplan vom ZKA, wie das technisch und organisatorisch empfohlen umzusetzen ist, steht allerdings noch auch - zulange hat man sich wohl gesträubt. Das man technisch schon längst soweit ist, konnte ich anhand öffentlich verfügbarer Informationen leider nicht feststellen.

Für SEPA-Überweisungen entfällt die BIC dann ab 1. Februar 2016. Da ab 2012 für SEPA-Überweisungen die gleichen Anforderungen wie an Inlandsüberweisungen gelten (Bankarbeitstage, etc), sollte man erwarten, dass die technischen Infrastruktur angeglichen ist. Auch dies lässt sich anhand öffentlicher Quellen nicht aufzeigen - Informationen für Firmenkunden der großen Bankinstitute verweisen darauf, dass Inlandsüberweisungen per SEPA zwar akzeptiert werden, die Formulierungen verweisen aber darauf, dass man es nicht als Allgemeinstandard empfiehlt, aber man zum Testbetrieb mit diesem Verfahren einlädt.

Gern hätte ich die im Artikel enthaltenen Warnungen vor dem Inlandseinsatz von IBAN bzw SEPA-Überweiser in Deutschland in den Plusquamperfekt gesetzt, aber da scheinen wir noch ein bischen warten zu müssen. GuidoD 11:26, 3. Mär. 2012 (CET)

---

Fand den Beitrag gut, nur was heißt bei dir "IBAN-Pflicht"??? Soetwas gibt es ab dem 01.02.14 nur für Firmenkunden, wobei Altlastschriften und Altüberweisungen nicht mehr entgegengenommen werden dürfen. Oder man löst die Konvertierungsleistung von der Zahlungsdienstleistung ab, in dem man vorab konvertier (Zeitverlust). Bei Verbrauchern wird weiterhin mit Kto-Nr. und BLZ entgegengenommen werden, und zwar weitere 2 Jahre (bis 1.2.16). Die aktuelle EU Verordnung sieht eine Konvertierungsleistung seitens der KI's explizit vor! Weiterhin ist das Routing nur mit der IBAN zwar Pflicht, aber was ist, wenn der Kunde die BIC freiwillig angibt und dieser falsch ist? Löschen und überschreiben (da IBAN-only), zurückgeben oder ähnlich wie in Ö. ohne BIC weiterleiten??? (nicht signierter Beitrag von 87.79.96.173 (Diskussion) 00:26, 20. Mär. 2012 (CET))

Inzwischen erledigt? --Double7 (Diskussion) 22:53, 27. Mai 2014 (CEST)

Zwingend?

Was aus dem ganzen Artikel nicht hervorgeht: Ist die IBAN jetzt nun zwingend notwendig bei deutschlandweiten/europaweiten/weltweiten Überweisungen oder nicht? 77.11.139.36 17:04, 7. Dez. 2010 (CET)

In Deutschland wird IBAN 2014 Pflicht. Bisher war das recht unklar, erst vor kurzem kam es nach Einwänden (bzgl. Lastschrift-Problem) und Kompromissen zu einer Entscheidung. Siehe auch: International_Bank_Account_Number#IBAN-Pflicht --Wikinger77 (Diskussion) 21:06, 26. Mär. 2012 (CEST)

Inzwischen erledigt? --Double7 (Diskussion) 22:53, 27. Mai 2014 (CEST)

Weblinks

Der Lnk auf folgende Seite: http://www.blzdir.de/iban-rechner sollte entfernt werden, da der IBAN Rechner flasch ist. Dies ergibt sich aus schlampiger programmierung des Rechners. Er funktioniert nur mit Kontonummern, welche kleiner als der maximale wert einer Integer Zahl sind (2147483647). Eine Berechnung mit einer Kontonummer wie z.B.6778341449 führt daher zu einem falschen Ergebnis (DE46720200702147483647). (nicht signierter Beitrag von 188.111.42.70 (Diskussion) 09:14, 8. Mai 2013 (CEST))

Dann bitte auch einfach die Zusammenfassungzeile nutzen. Das hätte uns allen Arbeit erspart. Ich lösche den Link. --Dipl-Ingo (Diskussion) 10:09, 8. Mai 2013 (CEST)

Es gibt kein "offizielles" IBAN Umrechnungs-Portal für Deutschland, das ist nur ein weiteres Angebot / ein kommerzieller Dienst des Banken-Verlags. (Verbund dt. Banken) Text entfernt. (nicht signierter Beitrag von 91.65.88.92 (Diskussion) 01:06, 28. Jun. 2013 (CEST))

erledigt. Inhalt wird durch Aussage "nur die Banken selbst korrekte IBANs herausgeben" im Artikel abgedeckt. --Double7 (Diskussion) 22:53, 27. Mai 2014 (CEST)

Kroatien

Laut SEPA nimmt Kroatien seit 1. Juli 2013 an SEPA teil, weshalb die Grafik dahingehend aktualisiert werden müsste. --Huskytreiber (Diskussion) 20:37, 14. Apr. 2014 (CEST)

Inzwischen erledigt. Ich war's nicht! --Double7 (Diskussion) 17:27, 27. Mai 2014 (CEST)

Kontocheck sourceforge

• http://www.am.hs-mannheim.de/konto_check/?ausgabe=2&sub=2

Der kürzlich eingefügte Link scheint tatsächlich eine validierte IBAN-Generierung zu beinhalten, gehostet am Lehrstuhl für Angewandte Mathematik der Hochschule Mannheim, identisch mit http://kontocheck.sourceforge.net - im Code sieht man eine Referenz auf eine "/etc/blz.lut", und als Erklärung "Zur Bestimmung der IBAN werden die von der Deutschen Bundesbank veröffentlichten IBAN-Regeln benutzt."

Hat jemand eine BLZ/Kontonummer parat, die nicht nach IBAN-Regel 01 kodiert, damit man das mal testen kann? GuidoD 11:32, 12. Nov. 2013 (CET)

Das Programm berücksichtigt die IBAN-Regeln; außerdem wird bei der Validierung deutscher IBANs noch überprüft, ob eine Regel nicht beachtet wurde (auf Anregung eines Nutzers). Unter http://www.ckonto.de/download/IBAN_Fallen_Tabelle_V2.pdf gibt es eine (unabhängige) Liste einiger Testfälle mit den richtigen und falschen IBANs. Vor einigen Tagen habe ich die Kontenliste unseres Vereins umgesetzt; dabei waren von 135 Bankverbindungen 13 solche, bei denen IBAN-Regeln angewendet wurden. (Michael Plugge, Autor von konto_check) (nicht signierter Beitrag von 141.19.146.166 (Diskussion) 13:46, 21. Nov. 2013 (CET))

Hallo, ich habe den Link zu konto_check in den letzten Abschnitt (Online-Validierung) wieder eingefügt. Das konto_check enthält eine komplette Implementierung der deutschen IBAN-Regeln und wurde sehr intensiv getestet. Es ist Open Source und bietet Schnittstellen für diverse Programmiersprachen, sowie eine Online-Validierungsmöglichkeit. Die oben erwähnte Datei /etc/blz.lut ist die Datendatei mit den Daten der Bundesbank-Dateien für die Gültigkeitszeiträume 9.9.2013 bis 8.12.13 sowie 9.12.2013 bis 2.3.2014 (Michael Plugge) (nicht signierter Beitrag von 87.165.181.63 (Diskussion) 22:46, 25. Nov. 2013 (CET))

Hat da mal jemand einen audit gemacht? Ich denke, der sensible Umgang mit Zahlungsdaten würde das erfordern. Die Bilbiothek steht zwar unter einer freien Lizenz, soweit mir erkennbar, gibt es jedoch kein Community-Input und auch keine Reviewer. Mir erscheint die Quelle schwer erschließbar. Nicht aufgrund der Algorithmik zu den einzelnen Implementierungen irgendwelcher Regeln und Prüffziffern, sondern vielmehr aufgrund der Softwarearchitektur und der Form der Dokumentation. Im Moment würde ich behaupten, dass es daher keine valide Quelle ist, da hier ja auch der Author sich selbst referenziert und der einzige zu sein scheint, der in Kenntnis der Behauptungen in diesem Artikel ist. Es wäre schön, wenn die Quellen insoweit nachvollziehbar wären, dass sie den Artikel wenigstens für erfahrene Entwickler untermauern. Bis dahin würde ich vorschlagen, den Link zu entfernen. (nicht signierter Beitrag von 217.247.94.100 (Diskussion) 10:23, 18. Jul 2014 (CEST))

FUD, ich hab einige Standardbeispiele geprüft, die erkannt wurden. Die Ableitung aus der Beschreibung der Generierung ist erkennbar. Natürlich haftet bei dieser Software niemand, aber gerade kleine Vereine können sich die Kosten eines professionellen Umstelldienstes nicht leisten. Dass sich die Bundesbank weigert, ein validiertes Konvertierungswerkzeug kostenlos zur Verfügung zu stellen, ist der eigentliche Skandal. Der volkswirtschaftliche Schaden ist enorm. Aber diese Meinung kann man leider in einer ach-so neutralen Wikipedia nicht unterbringen. Aber man kann in Wikipedia informieren, dass es auch ohne Bundesbank-Hilfe hinreichend gut geht. GuidoD 17:34, 19. Jul. 2014 (CEST)

Schwer verstaendlich (Wann ist IBAN moeglich/verpflichtend, wann ist BIC noetig)

Ich finde es schwer verstaendlich, wann die IBAN verwendet werden kann oder muss und wann der BIC hinzugenommen werden muss. Zusaetzlich verwirrend erscheint mir, dass offenbar fuer Banken und deren Kunden unterschiedliche Fristen gelten. Kann man das in einen eigenen Abschnitt ausgliedern, der die Sache mit einfacheren Saetzen beleuchtet? -- iGEL·대화·Bew 14:15, 2. Apr. 2013 (CEST)

Nunja, Wikipedia ist keine Sammlung von Anleitungen und Ratgebern, insofern ein "kann oder muss und wann" nicht als eigener Abschnitt zur Handlungsanteilung niedergeschrieben wird. Verwirren sollte der Artikel natürlich auch nicht, der Abschnitt IBAN-Pflichet sollte es aber schon ausdrücken: Inlandsüberweisungen verwenden bis Januar 2014 die nationalen Überweiser, zum 1. Februar 2014 wird auf "IBAN ohne BIC" ungestellt. Die "IBAN mit BIC" alias SEPA-Überweisung ist heute schon für innereuropäische Transfers zu verwenden, das ändert sich erst 2016 wenn Inlandsüberweisung und SEPA-Überweisung zusammenfallen - bis dahin sind es getrennte Systeme. Wenn das nicht offensichtlich ist, wo willst du es einbauen? GuidoD 14:58, 2. Apr. 2013 (CEST)

Also nehmt es mir nicht Übel, aber Ihr habt gerade gesagt, was [Benutzer:iGEL|iGEL] suggeriert hat. ==> Man muß jetzt unbedingt eine IBAN aus Kontonummer Bankleitzahl und Landeskennung erstellen. Und dann muß man eine BIG bei Überweisungen suchen, die die Bank identifiziert. Was ist das denn für ein Quatsch?

Also ich möchte gerne wissen ob das wirklich so stimmt. Carsten --Ersteinmal (Diskussion) 10:53, 3. Aug. 2014 (CEST)

derzeit gilt:

* Inland: IBAN ohne BIC

* Ausland: IBAN mit BIC

Und ja, man muss eine IBAN nehmen, BLZ+Konto ist Geschichte. GuidoD 14:04, 3. Aug. 2014 (CEST)

IBAN-Regeln

Der Artikel verweist auf Sonderregelungen für die Generierung von IBANs im deutschsprachigen Raum. Gibt es derartige Regeln auch in anderen Ländern oder ist Deutschland hier eine Ausnahme? (nicht signierter Beitrag von 217.247.94.100 (Diskussion) 10:23, 18. Jul 2014 (CEST))

Siehe dass die Warnung vor der Generierung auf die ECBS als Quelle verweist, das gilt also auf europäischer Ebene. Wenn man nach Sonderregeln schaut, sollte man vor allem auf die großen Länder schauen, da kleinere Länder gemeinhin dazu neigen, die Regeln in der Bankwirtschaft zügiger und strikter abzustimmen. In Deutschland kann man nur aufräumen, was passiert ist, bevor man daran gedacht hat, Regeln aufzustellen. GuidoD 17:40, 19. Jul. 2014 (CEST)

Widerspruch im Artikel bei den Abschnitten "Schreibweise" und "Kritik"

Im Abschnitt "Schreibweise" steht, dass die Aufteilung in Viererblöcke für die Mensch-Maschine Kommunikation von der ISO-Norm beabsichtigt ist und weiter unten im Abschnitt "Kritik" steht dann, dass dies von der ISO-Norm nicht gefordert wäre? Ja was denn nun? Wenn es nicht beabsichtigt ist, dann sollte man im Abschnitt "Schreibweise" vielleicht das Wort empfohlen verwenden. Wenn es aber beabsichtigt ist, dann ist die Kritik fehlerhaft. --37.209.89.166 08:29, 25. Sep. 2014 (CEST)

In der Technikersprache gibt es Soll- und Muss-Regeln, dies findet man in zahlreichen Standards. Kurz gesagt, eine gruppierte Ausgabe muss nicht unterstützt werden, aber wenn sie unterstützt wird, dann soll sie die Form von Viererblöcken haben. Wie unter "Schreibweise" schon gesagt wird diese Form im Standarddokument noch nicht mal explizit gefordert, aber sie erscheint dort nur so in den Beispielen, nach denen sich ein Techniker richten wird, der den Standard umsetzt (ISO 13616-1:2007 - Abschnitt 8 "Formats and Samples"). Alternative Schreibungen mit anderen Leerzeichen sind durchaus möglich, ich selbst schreibe die deutsche IBAN in einer Gruppierung ähnlich der alten BLZ, was die Wiedererkennung stark vereinfacht. Da wir hier aber bei Wikipedia sind, wird diese persönliche Empfehlung nicht in den Haupttext aufgenommen. GuidoD 11:27, 25. Sep. 2014 (CEST)

Ich habe mir mal erlaubt, eine neue Formulierung vorzuschlagen … LG, ℳ웃79 ^✍ 12:36, 25. Sep. 2014 (CEST)

Ich sehe mit deiner Formulierung ein großes Problem. Wenn du dich irren solltest und viele, die irgendeine Software umsetzen sollen und dann den Wikipedia Artikel als Ratschlag verwenden, dann setzen sie das mit der vierer Einteilung nicht um, weil sie gemäß der neuen WP Formulierung meinen nicht zu müssen. Der Schaden liegt dann beim Kunden, also uns allen, die sich dann ständig darüber ärgern, dass die IBAN so unfreundlich und unübersichtlich eingegeben und gelesen werden muss. Die ursprüngliche Formulierung mit "sind aber so beabsichtigt" war besser. Es wäre daher sinnvoller, wenn man den Abschnitt unter "Kritik" ändert und da reinschreibt, dass viele die beabsichtigte Viererschreibweise nicht umsetzen. Die WP trägt hier also eine große politische Verantwortung und auch wenn sich die Entwickler eigentlich an die technischen Dokumente halten sollten, wissen wir doch alle genau, dass, wenn es mal schnell gehen soll, der kürzere WP Artikel zur Rate gezogen wird und da steht es dann vielleicht falsch drin. Ich weiß ja, dass die WP politisch neutral sein möchte, aber wollen wir uns in Zukunft mit unfreundlichen IBAN Formularfeldern herumärgern nur weil die WP diese praktisch dem Entwickler nahgelegt hat? Und ja, aus Entwicklersicht ist ein Formular, bei dem man keine Vierergruppeneinteilung beachten muss, wesentlich schneller programmiert. --37.209.89.166 21:33, 27. Sep. 2014 (CEST)

Könnte es sein, dass du irrst? Auch die alte BLZ hatte eine Gruppenteilung, die im Druck auch erschien - und wo so etwas existierte, wird es für die IBAN sicher etwas ähnliches geben und die Druckform in Vierergruppen erscheinen.

Bei der Eingabe in ein Formularfeld ist eine Unterteilung dagegen schwierig, da die IBAN ja nicht nur für DE-Konten gilt, es kann also ganz verschiedene Längen geben. Was mich eher ärgert, dass man keine Hilfszeichen festgelegt hat, also etwa zusätzliche "/" oder "-" regelmäßig nicht ignoriert werden, sondern eben zu Fehlern führt. Bei der Schreibweise von Rufnummern ist man da schon lange flexibler und Programmierer haben sich darauf eingestellt. Eine Schreibung als DE20/100-100-10/0000-3521-08 ist mE viel lesbarer. GuidoD 00:09, 28. Sep. 2014 (CEST)

Bei der ISO wurde absichtlich nicht vorgegeben, wie das umzusetzen ist, vermutlich damit sich das „menschenfreundlichste“ durchsetzt. Eine Schreibweise/Darstellung wie „DE20/100-100-10/0000-3521-08“ ist also möglich und bei der Formular-Eingabe muss lediglich ab dem dritten Zeichen jede Nicht-Ziffer entfernt werden. LG, ℳ웃79 ^✍ 19:15, 28. Sep. 2014 (CEST)

Jetzt mal unabhängig vom Artikel erwähnt, wenn es nach mir gegangen wäre, dann hätte man für die IBAN das Hexadezimalsystem eingeführt. Dann wäre die IBAN nämlich bei einer deutschen IBAN um 4 Zeichen kürzer. Also nur 18 Zeichen anstatt 22 und Computer könnten diese Hexadezimaldarstellung auch wesentlich schneller verarbeiten, aber mich fragt ja keiner und Oma und Opa hätte wahrscheinlich Panik gekriegt, wenn in der Kontonummer plötzlich die Buchstaben A-F aufgetaucht wären. --37.209.89.166 10:57, 29. Sep. 2014 (CEST)

Es sind auch durchaus andere menschenfreundliche Schreibweisen als die Vierergruppen in Verwendung. Meine Bank, die HypoVereinsbank, gliedert auf den Kontoauszügen meine IBAN nach den Bestandteilen. Also so: "DE87 12345678 1234567890" --62.156.183.195 15:30, 7. Nov. 2014 (CET)

In en-wiki gibt es ein Kontra, die Blockschreibweise sei so definiert. GuidoD 14:28, 29. Sep. 2014 (CEST)

IBAN Buntheit

Ich würde die Farbverwendung in der IBAN-Feldstruktur entfernen, ich sehe keinen Mehrwert zur Buchstabenkodierung und finde es eher irritierend. Ganz abgesehen davon, dass Editieren nicht besser wird. GuidoD 13:26, 7. Jul. 2013 (CEST)

und von dem grün kriegt man Augenkrebs --Carl B aus W (Diskussion) 15:21, 4. Aug. 2013 (CEST)

Eigentlich braucht man das wirklich nicht farbig. Ich hab mal zumindest blau (wg. Verwechslung mit Links) und grün (wg. Augenkrebs) geändert. Außerdem waren im Quellcode sinnlose, leere und verschachtelte <span>s.
Jjeka (Diskussion) 17:38, 5. Sep. 2013 (CEST)

entfärben

Ich sehe keinen Mehrwert in der bunten Nummerndarstellung, die Schema-Kodierung (b,s,k,K) ist hinreichend, die teils hellen Farben erschweren eher die Lesbarkeit, die Editierbarkeit ist grandios schlecht. Die color-Codes würde ich gern demnächst entfernen, gibt es da Gegenstimmen, die die bunten IBANs behalten wollen? GuidoD 13:10, 6. Apr. 2014 (CEST)

check, wenn keine Gegenstimmen, dann alle color-codes raus.  Pro GuidoD 08:02, 25. Apr. 2014 (CEST)

Wie oft musst Du die Tabelle benutzen, dass Du Dir die Arbeit machen willst? Den Farbcode könnte man mit suchen/ersetzen schnell ändern. Was die Pflege neuer Einträge angeht, wir haben etwa Halbzeit, <100 Länder sind bereits in der Liste, weitere ca. 100 könnten noch beitreten. Der Wunsch nach guter Editierbarkeit ist daher nachvollziehbar, von mir keine Gegenstimme. --Double7 (Diskussion) 22:53, 27. Mai 2014 (CEST)

Der Unterschied zwischen "k" (Stelle der Kontonummer) und "K" (Kontrollziffer) wäre bei einfarbiger Darstellung schwerer erkennbar. Für Kontrollziffern könnte man dann besser "z" statt "K" verwenden. --Bergfink (Diskussion) 22:41, 12. Dez. 2014 (CET)

Gruppierung in "Zusammensetzung"

Warum sind die Stellen im Schema "Allgemeiner Aufbau der IBAN" anders durch stärkere Trennlinien gruppiert als in den drei Darstellungen für Deutschland, Österreich und Schweiz? Warum folgt sie nicht in allen vier Schemata den sonst verwendeten Viererblocks? --Bergfink (Diskussion) 22:45, 12. Dez. 2014 (CET)

OMA Tauglich

Die Oma muss diesen Code auch verwenden, aber in Wikipedia braucht zu schauen was das ist. Der Artikel ist derartig geschwollen geschrieben, dass man da nichts suchen braucht. --K@rl 14:46, 19. Jan. 2016 (CET)

@Karl Gruber: Ja, sehe ich auch so: Der praktische Bezug für den Alltag sollte sowohl bei der Einleitung als auch beim aktuell von der Hauptseite aus verlinkten Abschnitt (Abschnittslink: IBAN#IBAN-Pflicht) klarer herauskommen. Gerade deswegen ist es so wichtig, wenn ganz normale Leserinnen und Leser hier mitschreiben (auch Oma und Opa und auch Leute mit Schwierigkeiten, mit solch langen IBAN-Nummern klarzukommen, egal ob wegen zunehmender Demenz, hoffentlich vorübergehenden Bewusstseinstrübungen oder einfach nur unterschiedlichem Bildungsgrad und Kenntnis in deutscher Sprache): Mitmachen bitte! Und Kritik (und Lob) bitte hier vortragen. Einige sehr einfach gehaltene Abschnitte wünsche ich mir. Die fachbegrifflichen Details sollten weiter unten stehen und verlinkt sein. --LudwigSebastianMicheler (Diskussion) 16:02, 1. Feb. 2016 (CET)

Gebe ich dir vollkommen recht - lachen muss ich schon über deine Kenntnis der deutschen Sprache - denn das merkt man oft, in Wikipedia, dass eben deutsch nicht deutsch ist - es ist eben eine Variantensprache. Du schreibst auch von der IBAN pflicht, das ist bei uns schon wieder Schnee von gestern, denn bei uns ist schon eine Weile Pflicht. Ich bin zwar nicht OMA sondern OPA und gewöhnlicher Bankkunde der ein Konto und eine Bankomatkarte hat und der Bank ein bissl ein zinsenloses ;-) Darlehen gibt :-) --lg K@rl 18:07, 1. Feb. 2016 (CET)

Demenz ist aber kein Problem bei den bisherigen BLZ und Kontonummern? Erstaunlich was 4 Stellen mehr für Auswirkungen haben.... (nicht signierter Beitrag von 178.4.248.121 (Diskussion) 22:41, 2. Feb. 2016 (CET))

IBAN-Änderungen zum 1. Februar 2016 mit Verlinkung von der Hauptseite

Auch wenn mir eigentlich die Zeit wegen meiner Probleme im Real Life fehlt: Es betrifft heute viele WP-Leserinnen, die vorhin noch gar nichts verstanden, wenn sie diesen Artikel von der Hauptseite aus angeklickt hatten: Zu lesen war "2014", die Änderung in "2016" erscheint mir inhaltlich freilich nicht ganz ausreichend und an dieser Stelle sogar falsch: Das Problem liegt an der unzulänglichen und unpassenden Verlinkung von der Hauptseite. Im Abschnitt IBAN#IBAN-Pflicht steht jedenfalls zuwenig zur aktuellen Änderung, entweder wir setzen oben einen Anker hin für die Hauptseite, oder der Text wird unten (inhaltlich vorübergehend gedoppelt?) für die HauptseitenleserInnen formuliert. Ich bin gebildeter Laie hier, also: Expert*in­nen bitte mitschreiben!

Eine weitere Schwierigkeit wegen unserer Wikipedia-Software und Server ist die alsbaldige Anzeige von (gesichteten) Änderungen (Cacheproblem): Zunächst @Schotterebene: Danke für Deine vielen Sichtungen! Wir bräuchten mehr aktive Sichterinnen und Sichter. Auch wenn manchmal kleine Fehler passieren, an die mann dann noch länger denkt, weil sie inhaltlich doch gravierend sind und auch mir erschreckend ziemlich peinlich waren (gerade wenn eine langsame "Dorfleitung" samt Uraltrechner eine schnelle Änderung erschwerte). Später kann man mit Humor zurückschauen. Unsere arbeitsteilige Autorengemeinschaft (so ähnlich wurde es mal von einem EU-Webseiten-Admin bezeichnet) ist zwar etwas kompliziert zu verstehen, doch irgendwie bekommen wir es insgesamt ja hin. Wir Autoren tragen täglich zur globalen Wissenserweiterung bei und bekommen auch im wirklichen Leben bisweilen eine positive Rückmeldung über den Nutzen unserer Wikipedia! Es könnte vielleicht mehr Dank an die ehrenamtlichen AutorInnen sein (eine Art nicht anrechenbares Bedingungsloses Grundeinkommen mit sehr kleinem Betrag wünsche ich mir sowieso für ALLE als Einstiegshilfe für freiwillige gesellschaftliche Dienste), zumal unsere Beiträge manchmal mit einem hohen Preis erkauft werden müssen: Ich werde natürlich nachdenklich, wenn ich in einer öffentlichen Bibliothek 5 Eurocent pro Minute bezahlen muss! Neben dem Verantwortungsbewusstsein für die Kontinuität bereits laufender Artikel oder Projekte steckt sicherlich auch ein wenig Sucht und zwanghaftes Verhalten dahinter, wenn ich Fahrten mit Bahn oder Fahrrad zum Internetcafe machte, weil mein Rechner zu einem völlig unpassenden Zeitpunkt kaputtging (abgesehen von der Frage, ob mit E-Mail-Anhang, länger zurückliegenden merkwürdigen Aktionen von "Freunden" an meinem Rechner hierbei nachgeholfen wurde, er kann ja auch einfach nur alt gewesen sein ...). Wie wird die jetzt noch junge Generation damit klarkommen, wenn die Bürokratie mit immer mehr Formularen, intensiveren Nachweisen für die (finanziell-wirtschaftliche) Existenzberechtigung, längeren IBAN-Nummern, Codes und Zugangsbeschränkungen noch zunimmt? Arbeiten wir zumindest hier im Artikel an einer Vereinfachung mit: Der sehr praktische Hinweis für Überweisungen, dass die eigene IBAN sowohl auf der Debit-Bankkarte als auch auf dem Kontoauszug steht, fehlt mir (Verlinkung mit passendem Anker dort wäre hilfreich). Zum dazu lernen für unseren fleissigen Sichter: Ich hätte das Leeren des auf dem Server gespeicherten Artikels auch übersehen, dies wäre ja eigentlich des sichtenden Hauptseiten-Admins Aufgabe gewesen. Hab' vorhin mal das mit dem Anhängen von "?action=purge" an die URL ausprobiert (Hilfe:Cache#Serverseitigen Cache leeren): Ging nahezu sofort! Erst nach dem Ausloggen sehen wir angemeldete Benutzer*in­nen ja den "Normalzustand", so wie ihn unsere vielen LeserInnen sehen (was manch Admin vergisst, sich hier nach einer Änderung probeweise abzumelden und die neuen Links mal anzutesten). Wobei wir anscheinend neuerdings auch ein besseres Vorschlagrecht für Texte auf der Hauptseite haben (dazugelernt). --LudwigSebastianMicheler (Diskussion) 16:12, 1. Feb. 2016 (CET)

IBAN-Länge in Weißrussland?

Angegeben im Feld Länge ist "24", aber das Muster hat 28 Zeichen (springt beim Sortieren nach Länge ins Auge). Welche Spalte hat Recht? (Im Übrigen: Die Maximallänge laut Artikel ist 34 Zeichen - ist es einfach nur Zufall, dass kein Land diesen Wert ausnutzt?)--Hagman (Diskussion) 14:06, 29. Nov. 2017 (CET)

Validierung der Prüfsumme

Der Artikel geht auf die Validierung ein und erklärt diese, hört aber beim letzten Schritt mit einer unmöglichen Modulo-Rechnung auf. Unmöglich weil kein normaler Rechner eine 24-stellige Zahl frisst! Wenn man sich schon die Mühe macht, die Berechnung zu erklären, dann sollte man auch 3 weitere Zeilen in die Modulo Rechnung investieren, z.B.:

Da die Zahl 210501700012345678131468 für die meisten Rechner zu gross sein dürfte, lässt sich die Berechnung z.B. so aufteilen:

2105017000123 mod 97 = 81
8145678131468 mod 97 = 1

-- 2018-01-31T16:30:49‎ 77.58.133.111

WP:WWNI, Wikipedia möchte ja gern eine Enzyklopädie sein, kein Kochbuch oder Sammlung von Anleitungen. Da fallen solche technischen Details dann eben schnell mal runter. GuidoD 10:18, 1. Feb. 2018 (CET)

Auch so große Zahlen kann man mit wolframalpha.com rechnen lassen. --Obb2011 (Diskussion) 07:29, 4. Jul. 2018 (CEST)

Online-Validierung

Im Abschnitt heißt es: Ein Nachteil dieses Dienstes ist, dass auch die IBAN DE23 2004 1133 0008 3033 07 fälschlicherweise als korrekt erkannt wird. Das Konto 8303307 bei der Bank mit der BLZ 20041133 hat in Wirklichkeit noch eine zweistellige Unterkontonummer, die nur in der IBAN sichtbar wird.

Das ist nicht ganz sauber.

Zunächst ist festzustellen, dass der zitierte Validierungsmechanismus offenbar nur die Syntax der IBAN prüft. So gesehen ist die IBAN auch tatsächlich korrekt. Nimmt man z.B. https://www.iban-rechner.de/iban_validieren.html als einen der vielen anderen Rechner, dann bemerkt dieser, dass die Prüfziffer der (alten) Kontonummer nicht stimmt. Die IBAN ist zwar syntaktisch korrekt, sofern man nur die Prüfsumme anschaut, aber sie ist inkorrekt, wenn man das komplette Verfahren wie von der Bundesbank publiziert anschaut (vgl. https://www.bundesbank.de/Navigation/DE/Aufgaben/Unbarer_Zahlungsverkehr/Serviceangebot/Pruefzifferberechnung/pruefzifferberechnung.html und dann unten downloads, wo auch die Methode 13 erklärt wird, die hier für die Fehlererkennung zieht).

Inkorrekt ist insbesondere, dass 8303307 "das Konto" bei der Bank ist. Die fragliche Bank ist die Comdirect. Die Comdirect hat keine 7-stelligen Kontonummern. Das ist die Depot-Nummer. In der Frühzeit (als die Comdirect noch klein war), war das auch die Zugangsnummer. Die Zugangsnummer ist heute 8-stellig. Die Kontonummer des Verrechnungskontos hat stets eine 00 angehängt und lautet hier auch 8303307. Andere Konten (z.B. Währungskonto, Tagesgeldkonto...) haben hinten zwei andere Ziffern. - Die Kundennummer ist übrigens die Depotnummer mit 3 voran gestellten Ziffern, aber das ist wieder eine andere Baustelle.

Vielleicht schaut sich das mal jemand genauer an. --1.64.174.182 13:53, 21. Jun. 2018 (CEST)

Abschnitt überarbeitet. Ich war selber "Opfer" der comdirect, meine Hausbank hat damals bei der Umrechnung von der Kontonummer und BLZ in meiner Empfängerliste eine falsche IBAN erzeugt. --Obb2011 (Diskussion) 15:11, 23. Jun. 2018 (CEST)

Kommerzieller Kreditvermittler als Quelle für IBAN-Einführung?

Diese Änderung ist m.E. Linkspam in den Einzelnachweisen. Es gibt es sicher seröse Quellen, mit denen die Einführungsdaten in einzelnen Staaten belegt werden können. Ich habe die Änderung rückgängig gemacht. Willi P • Disk • 15:05, 21. Jun. 2018 (CEST)

Link-Referenz 24 endet in einem 404

Ich habe mich mal durch die Seite der Bundesbank durchgeklickt: Mir scheint als wäre das die fehlende Seite: http://www.bundesbank.de/Navigation/DE/Aufgaben/Unbarer_Zahlungsverkehr/Serviceangebot/IBAN_Regeln/iban_regeln.html?[/bundesbank/Navigation/DE/Aufgaben/Unbarer_Zahlungsverkehr/Serviceangebot/IBAN_Regeln/iban_regeln]=

(nicht signierter Beitrag von 195.202.49.250 (Diskussion) 09:42, 15. Aug. 2017 (CEST))

Sicherheit des Prüfsummenverfahrens

Wie man an meinen vielen Änderungen sieht, habe ich hier mehrfach daneben gegriffen und zunächst Fehler produziert, die mir beim Nachrechnen und Nachprüfen aufgefallen sind. Es wäre gut, wenn hier jemand mit Mathehirn nochmals drüber schaut. Zwar bin ich gut im Prüfsummen-berechnen, nicht aber in Statistik. --Obb2011 (Diskussion) 23:30, 12. Jul. 2018 (CEST)

Obb2011, vielen Dank für die ausführliche Analyse, die ich durchaus für sinnvoll und wichtig für den Artikel halte. Trotzdem scheint es sich bei dem gesamten Abschnitt "Sicherheit des Prüfsummenverfahrens" durch nicht mit Sekundärliteratur belegte Theoriefindung zu handeln. Es ist keine einzige Quellenangabe enthalten; das alles lässt sich möglicherweise als "eigene Interpretationen veröffentlichter Daten und Analysen" zusammenfassen. Ich tendiere dazu, den gesamten Abschnitt zu löschen, falls keine Belege nachgetragen werden. ~ ToBeFree (Diskussion) 01:15, 24. Mai 2019 (CEST)

Tatsächlich habe ich, vom wo anders im Artikel bereits zitierten ISO-Standard abgesehen, dazu selber nichts gefunden. Von Theoriefindung zu sprechen halte ich in Anbetracht dessen, dass es sich um Grundschul- bzw. Mittelstufen-Mathematik handelt, für über das Ziel hinaus geschossen. Die Ergebnisse sind ja keine persönliche Meinung oder nicht beweisbare Fantasieprodukte, insofern auch keine Interpretation veröffentlichter Daten o.ä., sondern für jedermann nachvollziehbar und lediglich eine Erklärung, weshalb die Forderungen des Verfahrens erfüllt werden. Insb. die Aussage, dass Zahlendreher ausgeschlossen sind (ISO-Forderung) erschien mir für ein enzyklopädisches Werk adäquat. Anstatt selber zu rechnen und herzuleiten kann man dann halt nachschlagen. Aus Sicht von Mathematikern ist das so einfach, dass man darüber nicht diskutieren muss, aber nicht jeder ist ein Mathematiker, der sich für das Thema interessiert. Solange der Artikel durch eine Löschung besser wird, habe ich nichts dagegen. --Obb2011 (Diskussion) 05:16, 24. Mai 2019 (CEST)

ToBeFree Nach nochmaliger Durchsicht des Abschnitts und der Hinweise zur Theoriefindung sehe ich nicht, dass hier Theoriefindung betrieben wurde. Zitat: "Als Theoriefindung (originäre Forschung) gelten Aussagen in Artikeln der Wikipedia, die nicht in anerkannter Fachliteratur veröffentlicht sind. Das betrifft insbesondere unveröffentlichte Theorien, Daten, Aussagen, Konzepte, Methoden oder Argumente, aber auch eigene Interpretationen veröffentlichter Daten und Analysen (Stichwort Privattheorie). Ebenso unerwünscht sind eigene Begriffsbildungen und Wortschöpfungen." Ich denke, die Community ist sich einig: Originäre Forschung kann man das für den Laien Nachvollziehbar-machen des Prüfsummenverfahrens bzw. seiner Sicherheit in Bezug auf Vertipper, also das, was im Artikel steht, nicht nennen, und mehr findet dort nicht statt. Weder werden Theorien noch Daten, Aussagen, Konzepte oder Argumente im Artikel eingebracht, veröffentlicht oder "erfunden". Auch gibt es keine Interpretation von Daten oder Analysen. Tatsächlich wären die Ausführungen allerdings meiner Meinung in einem eigenen Artikel zu ISO 7064 (https://www.iso.org/obp/ui/#iso:std:iso-iec:7064:ed-1:v1:en) als konkretes Fallbeispiel vermutlich besser aufgehoben; meine persönliche Meinung ist aber ohne Belang. Ich hätte das alles übrigens gerne etwas kürzer; das ginge auch, indem man (wiki-korrekt) nur die ISO-Norm zitiert, selbige aber nicht (wie derzeit) weiter ausführt und damit für den nicht-versierten Leser verständlicher macht. Irgendwelche willkürlich gewählten Rechenbeispiele mussten ja zur besseren Erklärung gewählt werden, und dazu wurden die schon vorher im Artikel verwendeten IBANs gewählt. Damit sei zur Diskussion gestellt, ob der Artikel mit oder ohne die Ausführungen zur Sicherheit des Prüfsummenverfahrens besser ist. Weniger ist ja manchmal mehr, in Anbetracht der im Netz auffindbaren unsinnigen Behauptungen, dass es "Zahlendreher" in IBANs geben könnte, die zu Fehlüberweisungen führen könnten, erscheint ein enzyklopädischer Hinweis mit kurzem an die Mathematik angelehntem Beweis (der von jedem mit mathematischer Grundausbildung verstanden werden kann), dass dem nicht so ist, angebracht. Anders formuliert: Wollen wir gar nichts, ein "das ist so" oder ein "das ist so, weil...". Das ISO-Verfahren selber wurde, ebenso wie andere Bundesbank-Dokumente, im Artikel anderweitig bereits zitiert, wenn auch nicht erneut referenziert. Das kann ich aber nachholen, nur wird es dann redundant, was eigentlich nicht wiki-üblich ist. Community, gebt mal einen Kommentar ab und helft mit, den Artikel zu verbessern! -- Obb2011 (Diskussion) 11:32, 24. Mai 2019 (CEST)

Obb2011, vielen Dank für Diff 188896749. Mir war nicht bewusst, dass beispielsweise im Vorwort des ISO-Standards viele deiner Erklärungen tatsächlich so bestätigt werden. Ich hätte jetzt als Beispiel für persönliche Interpretation und Wertung die "hohe" Erkennungswahrscheinlichkeit genannt, diese Wertung wird jedoch im Standard selbst vorgenommen und ist entgegen meiner Erwartungen keine persönliche Interpretation eines Wikipedia-Autors. Auch, dass das Dokument so frei zugänglich ist, war mir bis gerade nicht bewusst. Häufig muss man ja für den Zugang zu solchen Dokumenten einen kostenpflichtigen Account haben oder zumindest seinen Studentenstatus nachweisen. Beim IEEE-Ethernet-Standard ist das beispielsweise der Fall.

Idealerweise sollte Wikipedia vermutlich eine Tertiärquelle sein und auf zuverlässiger Sekundärliteratur aufbauen. Das direkte Zitieren aus Primärquellen ist mit Fallstricken verbunden; so könnte ein eigentlich gescheiterter Standard beispielsweise in seiner eigenen Einleitung lobend irgendwelche längst überholten "Vorteile" anführen. In WP:Belege ("#Was sind zuverlässige Informationsquellen?") wird das Fehlen wissenschaftlicher Sekundärliteratur als ein mögliches Zeichen für fehlende enzyklopädische Relevanz genannt. Ich stimme allerdings auch zu, dass eine mathematisch objektive Darstellung in bestimmten Fällen sogar ganz ohne Belege verifizierbar sein kann.

Einen Gegensatz zu "im Netz auffindbaren unsinnigen Behauptungen" bilden zu wollen, ist einerseits ambitioniert und im Sinne einer qualitativ hochwertigen Enzyklopädie, kann aber andererseits auch zu erheblichen Konflikten führen. Es ist eigentlich nicht die Aufgabe der Wikipedia-Autoren, durch persönliche Untersuchungen die Korrektheit von Aussagen zuverlässiger Medien in Frage zu stellen. Im Gegenteil fallen diejenigen, die meinen, besser Bescheid zu wissen als seriöse Journalisten, manchmal mit Theoriefindung und Verschwörungstheorien gehörig auf die Nase. Daher ist Vorsicht angebracht, um nicht ähnliche Fehler zu machen. Ich glaube, WP:TF existiert, um zu ebendieser Vorsicht zu mahnen.

Es gibt vielleicht doch noch einige Aussagen im angesprochenen Abschnitt, die zumindest einmal zu hinterfragen sind:

• "Die so möglichen und zu einer korrekten Prüfsumme führenden „Vertipper“ sind auf Tastaturen weder bei Zahlenblöcken noch in der Ziffernreihe der Tastatur durch einfaches daneben tippen erzeugbar."
• "[…]in allen Fällen sind die Ziffern so auf der Tastatur angeordnet, dass man bei beiden Stellen nicht einfach daneben greifen kann, insb. nicht, wenn man z. B. um eine Stelle versetzt in die Tastatur greift."
• "Eine pauschale statistische Aussage zur Möglichkeit falscher Überweisungen durch Tippfehler lässt sich nicht treffen."
• "Normales menschliches (Ver-) Tippverhalten schließt solche Tippfehler so gut wie aus."
• "Die Wahrscheinlichkeit einer Fehlüberweisung ist also extrem klein."

Ich glaube, das waren die Stellen, die mich stutzig gemacht haben. Das klingt doch sehr nach persönlicher Interpretation und Wertung; was in bestimmten Szenarien als "extrem klein" betrachtet wird, entscheidet ja nicht objektiv die Mathematik. Möglicherweise entstehen global betrachtet Millionenschäden durch "extrem unwahrscheinliche" Fehler.

Abgesehen davon habe ich aber an den mathematischen Rechnungen, bei nochmaligem Durchsehen, nichts auszusetzen. Insbesondere habe ich mich geirrt, als ich mangels Belegen über eine Löschung des Abschnitts nachgedacht habe. Ich glaube, wenn wir die Wertungen belegen oder entfernen, hat sich das Problem erledigt. ~ ToBeFree (Diskussion) 20:07, 24. Mai 2019 (CEST)

ToBeFree Beim von Dir zitierten WP:TF heißt es: "Grundsätzlich beruhen Artikel in der Wikipedia auf überprüfbaren Aussagen." Mathematik, sofern man nicht gerade für etwas den Nobelpreis kriegt, ist für (fast) jeden überprüfbar. Da haben wir Konsens. Folgende Punkte stehen zur Debatte und tatsächlich habe ich sie im Raum stehen lassen.

• "Die so möglichen und zu einer korrekten Prüfsumme führenden „Vertipper“ sind auf Tastaturen weder bei Zahlenblöcken noch in der Ziffernreihe der Tastatur durch einfaches daneben tippen erzeugbar."

Das wird im folgenden Punkt geklärt:

• "[…]in allen Fällen sind die Ziffern so auf der Tastatur angeordnet, dass man bei beiden Stellen nicht einfach daneben greifen kann, insb. nicht, wenn man z. B. um eine Stelle versetzt in die Tastatur greift."

Mathematisch ist ein Tippfehler lediglich die Addition einer Zahl auf den aus der IBAN im Rahmen des Prüfverfahrens erzeugten Wert (siehe Artikel). Damit die Prüfsumme stimmt, muss das mod 97 aufgehen (s. auch Artikel). Soweit ist das trivial, wenngleich man vermutlich Probleme hätte, dies einem Juristen zu erklären. Greift man in der Ziffernreihe 1234567890 daneben, dann wäre so ein Additiv z.B. 1111, d.h. man würde z.B. 4 Ziffern um eine Stelle versetzt (circular shifted) eintippen (z.B.5462 nach 6573), oder 222 wenn man 3 Stellen um 2 verschiebt. Keines dieser Additive (alles Schnapszahlen) ist mod 97 = 0, d.h. es gibt immer einen erkennbaren Fehler. Dies entspricht auch der ISO-Forderung in der zitierten Quelle bei 1.3 c (https://www.iso.org/obp/ui/#iso:std:iso-iec:7064:ed-1:v1:en). Dazu gab es auch mal einen Hinweis von der Bundesbank, nur finde ich den leider nicht mehr. Im Ziffernblock gilt das sinngemäß. Den mathematischen Nachweis komplett darzustellen ist m.E. nicht Wikipedia-geeignet und auch nicht notwendig, jeder kann das ja nachrechnen; vor Gericht würde man einen Sachverständigen konsultieren.

• "Eine pauschale statistische Aussage zur Möglichkeit falscher Überweisungen durch Tippfehler lässt sich nicht treffen."

Gegenfrage: Wie soll man die treffen können? Das Problem ist hier nicht die Mathematik sondern das menschliche Tippverhalten. Tippfehler laufen nicht nach dem Monte-Carlo-Prinzip. Es kommt schon sehr auf die IBAN und den ersten Tippfehler an, ob bzw. wie man einen weiteren Tippfehler machen muss. Eine mathematisch korrekte Aussage lässt sich nur für die einzelne IBAN treffen. Es kommt auch auf das Kreditinstitut an. Wenn man bedenkt, dass wir nur ca. 3600 BLZ haben und in der Kontonummer institutseigene Prüfverfahren ziehen, dann kann schon gar nicht mehr pauschaliert werden.

Für IBANs habe ich keine Untersuchungen gefunden. Untersuchungen zu Tippfehlern in domains zeigten, dass sich Anwender bei facebook bei der Eingabe in der Browser-Zeile in einem von 7930 Fällen vertippt (https://www.chrisfinke.com/2011/07/25/what-do-people-type-in-the-address-bar/) Es gibt Untersuchungen zu Tippfehlern bei Patientennummern (https://www.ncbi.nlm.nih.gov/pmc/articles/PMC419425/), die die typische Systematik von menschlichen Tippfehlern belegen. Bei Durchsicht dieser Quelle(n) und Abgleich gegen die ISO-Norm wird offensichtlich, dass die Norm genau diese Fälle beachtet.

Soll man nun so etwas als Beleg zitieren, dass menschliches Tippverhalten bzw. Vertipper nicht dem Monte-Carlo-Prinzip unterliegt? Wenn es einen Artikel über Tippfehler und menschliche Fehlleistungen gäbe, dann wäre diese Quelle sicher dort gut aufgehoben, aber hier beim IBAN-Artikel? Ich habe darüber nachgedacht und selbiges verneint, aber wenn es gut für den Artikel ist, kann das nachgeholt werden. Wie sieht die Community das?

• "Normales menschliches (Ver-) Tippverhalten schließt solche Tippfehler so gut wie aus."

Siehe oben. Das schlägt auch in die Kerbe der ISO-Forderung (1.3 generell, hier meine ich d und vor allem e), dass absichtliche Verfälschungen nicht durch das Verfahren abgedeckt werden müssen bzw. sollen. Das Verfahren zielt auf unabsichtliche Fehler ab, die auf normalen Tastaturen "erzeugt" werden können. D.h. daneben greifen, ganze Zahlenblöcke um eine Stelle versetzt abtippen, zufällige einzelne Tapser auf der Tastatur.

• "Die Wahrscheinlichkeit einer Fehlüberweisung ist also extrem klein."

Das ist, zugegeben, mein persönlicher Schluss, der allerdings bei einer persönlichen Nachfrage bei der Bundesbank bestätigt wurde. Auch hier die Gegenfrage: Wer kennt wirklich jemanden persönlich, der nachweislich eine Fehlüberweisung wegen eines Vertippers getätigt hat? Ich bin da leidenschaftslos, das kann man streichen. Belegen kann ich das nicht, aber ich würde bei normalem Tippverhalten auf 1:1 Mio oder weniger tippen; nur wäre das nun tatsächlich Theoriefindung und solche nicht fundierbaren Zahlen sollten wir nicht verbreiten.

Bzgl. Deiner Aussage: "Einen Gegensatz zu "im Netz auffindbaren unsinnigen Behauptungen" bilden zu wollen, ist einerseits ambitioniert und im Sinne einer qualitativ hochwertigen Enzyklopädie, kann aber andererseits auch zu erheblichen Konflikten führen." - Das kann ich nur bejahen. In dem Fall gilt aber: Mathematik lügt nicht, da gibt es keine "alternativen Fakten".

Ich rege an, dass die Community / Du den Abschnitt so überarbeitest, wie Du ihn für richtig hältst. Das geht schneller als darüber zu diskutieren. Dass eine Löschung nicht mehr von Dir angeregt wird, lese ich zwischen den Zeilen. Wenn er kürzer wird, begrüße ich das sehr, nur soll er verständlich und nachvollziehbar bleiben.

-- Obb2011 (Diskussion) 07:31, 25. Mai 2019 (CEST)

Ich habe jetzt den Abschnitt unterteilt und auch eine Quelle für menschliche Vertipper bei numerischen Eingaben ergänzt. Der zweite Abschnitt ist nur Mathe-basiert und für jedermann nachrechenbar, er erläutert (für Nicht-Mathematiker geeignet), warum das Verfahren funktioniert. Der letzte Satz "Die Wahrscheinichkeit einer Fehlüberweisung ist also extrem klein" wurde gestrichen, die "Kleinheit" ist ja auch schon eine Forderung der ISO-Norm. Wenn es keinen weiteren Protest gibt, dann werde ich die Streich-Anregung in ein paar Tagen entfernen. Verbesserungen (und vor allem Kürzungen!) sind willkommen. --Obb2011 (Diskussion) 06:47, 26. Mai 2019 (CEST)

Textbaustein bzgl. fehlender Belege entfernt, da hier niemand mehr protestiert hat. --Obb2011 (Diskussion) 12:50, 9. Jun. 2019 (CEST)

Abschnitt Kritik

Die geforderten Belege (Quellen) für die Ablenhnng von IBAN sind m.E. sehr ausführlich im verlinkten IBAN-Diskriminierung dargestellt. Den entsprechenden Baustein (montiert am 25.4.2019) entferne ich in einigen Tagen, wenn es keine Proteste gibt. --Obb2011 (Diskussion) 12:48, 27. Mai 2019 (CEST)

Textbaustein bzgl. fehlender Belege entfernt, da hier niemand mehr protestiert hat. --Obb2011 (Diskussion) 12:50, 9. Jun. 2019 (CEST)

Groß-/Kleinbuchstaben in IBAN erlaubt?

Im Abschnitt "Zusammensetzung" wird darauf verwiesen, dass Ländercode und Kontoidentifikations Großbuchstaben enthalten müssen.

Lt. ISO 13616:2007 können aber auch Kleinbuchstaben verwendet werden. Der ISO-Standard selbst ist zwar kostenpflichtig, der relevante Satz dazu ist aber auch im freien Intro des Standards (https://www.iso.org/obp/ui/#iso:std:iso:13616:-1:ed-1:v1:en) nachzulesen (Abschnitt 0.2 "Background to this revision of ISO 13616" , letzter Satz):

"In addition, given the possibility that domestic accounts may use lower case alpha characters, ISO 13616 remains unchanged on this point, i.e. lower case characters continue to be allowed, although the check digit algorithm will continue to be case independent." (nicht signierter Beitrag von 62.47.255.66 (Diskussion) 10:13, 20. Apr. 2020 (CEST))

Der ISO13616-Hinweis ist ja ziemlich eindeutig. Dann passe das doch im Text an. Er lässt sich aber nur über den "domestic account" aus, dazu gehört nicht der Ländercode. Der ist auch eine klar definierte und begrenzte Wertemenge von Tupeln aus je 2 Großbuchstaben. Insofern ist in der Zusammensetzung richtig, dass der Ländercode Großbuchstaben enthalten muss, aber falsch, dass das für die Kontoinformation ebenso gilt. In Deutschland bestehen die Kontoinformationen aus der BLZ und der Kontonummer und sind daher immer numerisch; das ist allerdings keine ISO 13616-Anforderung. Mal in die community gefragt: Kennt denn irgendjemand tatsächlich einen existierenden Fall, in dem Kleinbuchstaben verwendet werden? -- Obb2011 (Diskussion) 12:44, 20. Apr. 2020 (CEST)

2021 > 2014

„Nach einer Übergangsfrist bis 1. Februar 2014 sollen die alten nationalen Kontoverbindungen abgeschaltet werden.“ Und wurden sie (es an diesem Tag)? -- Peter Gröbner 08:12, 1. Apr. 2021 (CEST)

IBAN Nicaragua

Das Länderkennzeichen in der Liste der IBAN-Schemata ist mit NO (Norwegen) vermutlich falsch (NI wäre da wohl richtig)! Die Liste sollte nochmal insgesamt geprüft werden, hab selber nur keine Zeit dafür... --213.95.191.68 09:58, 22. Jun. 2023 (CEST)

Hatte vergessen zu sagen das es sich um den Eintrag für Nicaragua handelt, sorry! --213.95.191.68 09:59, 22. Jun. 2023 (CEST)

Die Liste gibt es hier und im Artikel. NI und NO sind mit NIcaragua und NOrway richtig. --Netpilots ✉ 13:26, 22. Jun. 2023 (CEST)