In Germany, the norms for EBICS/SWIFT processing are de facto defined by the Deutsche Kreditwirtschaft.
In its specification of the SWIFT number, the DK takes a slightly more restrictive approach to a valid SWIFT number: it specifies it with the regular expression [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}. (In other words, there must not be a 0 or 1 in the 7th place and no O in the 8th place.) Source for this specification is Appendix 3 Data Formats 3.6.pdf, section 2.3.1
Faker does not currently honor this restriction. This clashes with the verification against an xsd schema file provided by the DK, which third-party libraries perform. Thus, Faker is not able to provide data which is consistently accepted by those libraries.
Steps to reproduce
from faker import Faker
import re
Faker.seed(0)
fake = Faker(locale='de_DE')
if __name__ == '__main__':
for i in range(100):
swift = fake.swift()
if not re.match(r"[A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}", swift):
print(f"{i}:{swift}")
In Germany, the norms for EBICS/SWIFT processing are de facto defined by the Deutsche Kreditwirtschaft.
In its specification of the SWIFT number, the DK takes a slightly more restrictive approach to a valid SWIFT number: it specifies it with the regular expression
[A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}
. (In other words, there must not be a 0 or 1 in the 7th place and no O in the 8th place.) Source for this specification is Appendix 3 Data Formats 3.6.pdf, section 2.3.1Faker does not currently honor this restriction. This clashes with the verification against an xsd schema file provided by the DK, which third-party libraries perform. Thus, Faker is not able to provide data which is consistently accepted by those libraries.
Steps to reproduce
Expected behavior
The output should be empty.
Actual behavior
The output is