Waarom gebruikt de controlefunctie van de bankkaartnummers het getal 97 (het hoogste priemgetal van twee cijfers) en niet 99?

Antwoord

Beste Fons,

Een goede vraag! De studie van controlegetallen is al best oud en er bestaan vele verschillende manieren om controlegetallen te berekenen. Het doel van deze controlegetallen was in eerste instantie schrijffouten en/of typfouten te kunnen detecteren. Later ook om fouten te kunnen corrigeren. Ik zal me in mijn antwoord op jouw vraag beperken tot detecteren van fouten. 

Het korte antwoord

Het korte antwoord op je vraag is dat 97 een priemgetal is (zoals je zelf al aangaf) en dat door deze keuze een controlegetal wordt berekend met sterkere eigenschappen in termen van foutdetectie. Door het feit dat 97 twee cijfers heeft, hoeven we ook maar twee extra cijfers toe te voegen en blijft de redundantie beperkt. Hieronder geef ik wat meer details over waarom priemgetallen tot deze eigenschap leiden.

Een controleschema

Stel, ik heb een reeks cijfers (bvb. de cijfers van een bankkaart) en ik wil er extra cijfers aan toevoegen zodat deze, samen met de oorspronkelijke  cijfers, iemand anders toelaten om aan foutcontrole te doen. Een manier om deze extra cijfers te berekenen noemen we een controleschema. Er bestaan verschillende manieren om deze berekeningen te doen. Deze verschillen zijn voor een deel gedreven door het feit dat er ook verschillende types van fouten bestaan.

Fouten in getallen

De meest voorkomende fout is de "1-cijfer"-fout, waarbij één cijfer uit de gegeven reeks wordt vervangen door een ander. Bijvoorbeeld: als ik het getal 548953 wou doorgeven en ik typ per ongeluk 548923, dan heb ik een "1-cijfer-fout" gemaakt. Een andere veel voorkomende fout is de "burenwissel" waarbij twee naburige cijfers per ongeluk worden omgewisseld (bvb.:  548953 ->  548593). Uit studies is gebleken dat, hoewel er nog veel andere types fouten bestaan, deze twee fouten (de "1-cijfer-fout" en de "burenwissel") veruit de meest voorkomende zijn. We willen dus graag dat een controleschema op zijn minst in staat is deze twee foutsoorten in alle situaties te detecteren. Als andere types fouten ook worden gedetecteerd, dan is dat uiteraard een mooie bonus! 

Een gewogen modulo-schema

De bankkaarten in Europa hebben allemaal een IBAN nummer.  Deze gebruiken een controleschema met twee extra cijfers en is gebaseerd op gewogen modulo-K rekenen. Bij een gewoon modulo-K-schema berekenen we het controlegetal door alle cijfers op te tellen en daarna de rest bij deling door K te berekenen. K is hier een natuurlijk getal groter 0 dat we op voorhand afspreken. Als we dit eens toepassen op ons eerder getal 548953 en we nemen K=10 dan krijgen we

 5+4+8+9+5+3 mod 10 = 34 mod 10 = 4

Ik vind dus dat mijn controlegetal gelijk is aan 4 en ik voeg dit toe zodat mijn getal  5489534 wordt. Als ik dit getal aan jou geef, en je weet dat K=10, dan kan je de berekening herhalen en kijken of jouw uitkomst overeenkomt met het laatste cijfer. Stel ik dat per ongeluk een typfout maak en ik geef je het nummer  5489234, waarbij ik nu een 1-cijfer fout heb gemaakt. Als jij wil controleren of mijn nummer klopt dan herhaal je de berekening van het controlegetal met de eerste zes cijfers en je vindt:

 5+4+8+9+2+3 mod 10 = 31 mod 10 = 1

Dit cijfer is anders dan het controlegetal (4) en je weet dus dat het gegeven nummer een fout bevat. Je weet niet waar deze fout zit, je weet niet wat voor soort fout het is, je weet alleen dat er een fout aanwezig is.

Is dit nu een goed schema? Niet echt, want geen enkele burenwissel in de eerste zes cijfers kan worden gedetecteerd. Als ik jou bijvoorbeeld het getal 5485934 geef, zal je als controle getal nog steeds 4 krijgen en denken dat het nummer juist is. Erger, ik kan de zes cijfers in elke willekeurige volgorde plaatsen en je zal aan de hand van dit ene controlegetal niet kunnen detecteren dat er iets fout is.

Om dit probleem op te lossen, kan je een gewogen modulo-K systeem gebruiken waarbij je elk cijfer eerst vermenigvuldigt met een gewicht alvorens de som modulo-K te berekenen. Bij het IBAN nummer zijn deze gewichten allemaal machten van 10. Ik zal hier een eenvoudiger reeks van gewichten gebruiken. Ik ga namelijk elk cijfer op een oneven positie met gewicht 1 vermenigvuldigen en elk cijfer op een even positie met gewicht 3. Als we dit doen met ons oorspronkelijk getal (548953) dan krijgen we:

1*5 + 3*4 + 1*8 + 3*9 + 1*5 + 3*3 mod 10 = 5 + 12 + 8 + 27 + 5 + 9 mod 10 = 66 mod 10 = 6

Met dit nieuwe (gewogen) schema krijg je dus 6 als controlegetal en mijn nummer wordt  5489536. Opnieuw stellen we ons de vraag: "Hoe goed is dit schema nu?" Het antwoord op deze vraag is dat alle 1-cijfer fouten gedetecteerd worden en bijna alle burenwissels. De burenwissel die we eerder deden kunnen we opsporen, want als ik jou 5485936 doorstuur, dan kan jij vinden dat:

1*5 + 3*4 + 1*8 + 3*5 + 1*9 + 3*3 mod 10 = 5 + 12 + 8 + 15+ 9 + 9 mod 10 = 48 mod 10 = 8

en dit is niet gelijk aan het controlegetal 6.

Nu komen we stilaan bij het antwoord op jouw eigenlijke vraag. Het is namelijk zo dat de burenwissels die we niet kunnen opsporen precies diegene zijn waarbij het verschil tussen de buren gelijk is aan vijf. De reden dat dit zo is, is omdat het verschil tussen twee naburige gewichten (1 en 3) gelijk is aan 2 en 2*5 mod 10 = 0. Hierdoor zal er in het berekende controlegetal geen verschil optreden. Het probleem dat zich hier stelt, is dat het verschil in gewichten maal het verschil in buren een veelvoud is van K=10. Met andere woorden, we detecteren bepaalde burenwissels niet omdat 10 als delers 5 en 2 heeft.  Als we als K een priemgetal nemen, is dit niet zo en kunnen we meer burenwissels detecteren. 

Het IBAN-nummer gebruikt in principe een gewogen modulo-K-schema waarbij K=97 en waarbij de gewichten allemaal verschillende machten van 10 zijn. Het detecteert alle 1-cijfer-fouten, alle burenwissels en nog veel meer. Als we K=99 zouden nemen, dan introduceren we een minder sterk controlegetal omdat 99 delers heeft.