Metode: Sådan fungerer vores data og værktøjer

Kortnummerering: ISO/IEC 7812

Betalingskortnumre følger standarden ISO/IEC 7812. Det første ciffer er Major Industry Identifier, de forreste cifre udgør Issuer Identification Number (IIN, almindeligvis kaldet BIN), de følgende cifre identificerer den enkelte konto, og det sidste ciffer er et kontrolciffer.

Kortnetværk genkendes på deres præfikser og længder; f.eks. starter Visa-numre med 4, og flere netværk bruger bestemte intervaller i 2- og 5-serien. Vores værktøjer bruger disse offentliggjorte mønstre til at identificere et nummers mærke.

6-cifrede og 8-cifrede BIN'er

IIN var historisk seks cifre. Standarden blev opdateret til at understøtte ottecifrede IIN'er, og de store netværk har bevæget sig over til ottecifrede intervaller. Ét sekscifret præfiks kan derfor dække flere udstedere eller produkter.

Når du indtaster otte eller flere cifre, leder vi først efter det mest præcise matchende interval og falder tilbage til det sekscifrede interval, når der ikke findes en ottecifret post.

Luhn-kontrolsummen

Luhn-algoritmen (mod 10) opdager de fleste tastefejl i enkeltcifre og mange ombytninger. Den fungerer sådan:

1. Start fra cifferet længst til højre og bevæg dig mod venstre, og fordobl hvert andet ciffer.
2. Hvis fordoblingen giver et tal over 9, så træk 9 fra.
3. Læg alle cifrene sammen.
4. Hvis summen er et multiplum af 10, består nummeret kontrollen.

At bestå Luhn-kontrollen betyder kun, at et nummer er korrekt opbygget. Det betyder ikke, at kortet findes, er aktivt eller har dækning.

Sådan sammensættes BIN-databasen

Vores BIN-database kombinerer offentligt tilgængelige intervaloplysninger, branchereferencer og rettelser indberettet af brugere. Posterne normaliseres, så mærke, type, niveau, bank og land bruger ensartede navne og koder, og modstridende poster gennemgås, før de flettes.

Kortnetværk offentliggør ikke en komplet liste over alle intervaller, så ingen tredjeparts-BIN-database kan være perfekt. Vi er åbne om disse begrænsninger:

• Udstedere kan til enhver tid omfordele, sammenlægge eller nedlægge intervaller, og posterne kan halte bagefter.
• Banknavne kan afspejle et ældre navn efter en fusion eller et navneskifte.
• Kortniveau og -type er de felter, der oftest mangler eller er forældede.
• Private label-, flåde- og visse forudbetalte intervaller er muligvis ikke opført.

IP-geolokalisering

IP-opslag bruger DB-IP Lite-databasen sammen med data om netværksejerskab (ASN). Resultater på landeniveau er generelt nøjagtige, fordi IP-blokke tildeles netværk i bestemte lande.

By, region og koordinater er omtrentlige. Mobiloperatører, virksomhedsnetværk, VPN'er og satellitforbindelser kan placere en bruger langt fra den angivne placering, så bydata bør aldrig bruges som bevis for, hvor nogen befinder sig.

Registrering af VPN og proxy sammenligner det netværk, der ejer en IP, med kendte hosting-, VPN- og Tor-netværk. Det giver et risikosignal, ikke en sikkerhed.

Validering af SWIFT/BIC og IBAN

En SWIFT/BIC-kode har 8 eller 11 tegn: en bankkode, en ISO-landekode, en lokationskode og en valgfri filialkode. Vi tjekker formatet og landekoden og matcher koderne med vores referencekatalog.

IBAN'er valideres med ISO 13616 MOD-97-kontrollen: de første fire tegn flyttes til slutningen, bogstaver omdannes til tal, og resultatet skal give en rest på 1 ved division med 97. Vi tjekker også den forventede længde for hvert land.

Syntetiske testdata

Kortnumre og IBAN'er fra vores generatorer er syntetiske. De opbygges ud fra et valgt præfiks eller landeformat med tilfældige cifre og et korrekt kontrolciffer, så de består formatvalidering i software under test.

De er ikke knyttet til nogen rigtig konto, og udløbsdatoer og sikkerhedskoder er tilfældige. Testdata er kun til udvikling, QA og undervisning.

Opdateringer og rettelser

Referencedata gennemgås og opdateres løbende, og indberettede fejl tjekkes og rettes, efterhånden som de kommer ind. Datoen på hver side viser, hvornår sidens indhold sidst blev gennemgået.