El que sigue es un ejemplo muy sencillo de cómo utilizar un algoritmo que permite descubrir si uno cometió un error. Usted se preguntará (y con razón ¿qué error? ¿todo tipo de error?). No, seguro que no, pero permite detectar si uno se equivocó (de buena fe) al querer transmitir un grupo de números. El error más frecuente es una transposición (permutar dos números consecutivos) ¿Cómo hacer? ¿Cómo hacer para que entre los propios números que usted está dictando, aparezca la forma de detectar esa transposición? ¿Y dónde se usa?

Suponga que usted necesita hacer una compra y va a utilizar su cuenta bancaria pero no está físicamente en el lugar como para escribir un cheque. Los va a dictar por teléfono para que hagan un débito automático. Para hacer las cuentas más sencillas, supongamos que son diez dígitos. Usted los recita telefónicamente y la persona que escucha le pide que aguarde y después de un ratito le dice: “No, esa cuenta no existe”. Usted sabe que debería funcionar y que tiene el dinero suficiente ¿Cómo encontrar una manera de asegurarse que usted leyó los números correctamente o que no es la vendedora la que anotó o escuchó mal?

Por supuesto, hay muchos métodos para comprobar esto, pero me voy a referir acá a uno muy específico y muy fácil de entender. Es un algoritmo que inventó el matemático alemán Hans Peter Luhn en el año 1954 y fue patentado seis años más tarde. La idea fue muy creativa, y ha sido incorporado por muchas compañías que ofrecen tarjetas de crédito (o de débito) en distintas partes del mundo. En algunos países se usa para verificar los números en los seguros sociales, cuentas bancarias, pólizas de seguro o los datos que aparecen en las tarjetas SIM de los teléfonos celulares, por poner algunos ejemplos.

Haga de cuenta que usted tiene que dictarle a alguien esos 10 dígitos. En realidad, hay uno más (undécimo) que se usa como auto-verificación para asegurarse que los diez que usted envió están bien. Téngame un poquito de paciencia y verá a qué me refiero. Funciona así.

Supongamos que los primeros diez números son: 7, 1, 9, 8, 7, 3, 9, 2, 7 y 9. El undécimo lo voy a dejar vacante, y lo voy a llamar ‘x’ ¿Qué valor tiene que tener ‘x’ para validar todo lo anterior?

Vuelva a mirar los diez números. Hay cinco que están en posiciones impares: 7, 9, 7, 9 y 7, es decir el primer, tercer, quinto, séptimo y noveno dígito. Por otro lado, hay cinco que están en posiciones pares: 1, 8, 3, 2 y 9 (el segundo, cuarto, sexto, octavo y décimo dígito) ¿Cómo hacer ahora para determinar ‘x’? Haga lo siguiente. Primero, escriba una fila con los diez números y deje la ‘x’ para el final. Después, escriba otra fila, en donde usted repite los números que están ubicados en una posición impar (7,9,7,9 y 7) y duplica, los que están en posición par. Es decir, en lugar de escribir 1,8,3,2 y 9, escriba 2, 16, 6, 4 y 18. Debería obtener esta configuración:

7 1 9 8 7 3 9 2 7 9 x

7 2 9 16 7 6 9 4 7 18 x

Como usted ve, en la segunda fila aparecen algunos números con dos dígitos. En ese caso, súmelos. Es decir, en lugar de 16, escriba 7 (porque 1+6 = 7) y en lugar de 18, escriba 9 (ya que 1+8 = 9). Ahora las dos filas quedan así:

7 1 9 8 7 3 9 2 7 9 x

7 2 9 7 7 6 9 4 7 9 x

Para terminar, sume todos los dígitos que figuran en esta fila:

(7+2+9+7+7+6+9+4+7+9+x) = 67+x

¿Sabe lo que ideó Luhn? Para validar que los diez primeros números sean los correctos, le adjudicó a la ‘x’ el menor dígito que le falta al número total (67 en este caso) para que sea un múltiplo de 10 ¿Qué valor tiene que tener ‘x’ entonces? (¿Quiere pensar usted?). El undécimo dígito, la ‘x’ tiene que ser un número 3, y de esa forma ahora la suma es 70, que -efectivamente- es un múltiplo de 10: termina en cero.

Este dígito ‘x’ funciona como auto-corrector. Hay muchísimas variantes de dígitos que se agregan para verificar que los anteriores son correctos. De hecho, en algunos ejemplos se duplican los números que están en las posiciones pares –como hice más arriba- y en otros casos, los que figuran en las posiciones impares. Por supuesto, hace falta que el protocolo lo especifique dependiendo del contexto en el que se va a utilizar.

Por ejemplo, el número de dígitos que aparecen en una tarjeta no es un número fijo, el caso más usual es cuando hay 16 dígitos [1]. Para avanzar en un caso concreto, yo voy a inventar un número de 16 dígitos, como si correspondiera a los que podrían figurar en una tarjeta de crédito en donde el último tendría que ser el dígito auto-verificador. Acompáñeme para ver si el número puede o no ser un caso posible. Le sugiero que usted haga lo mismo, generándose una tira de 15 dígitos primero, después agregue el último para verificar y vamos haciendo en paralelo las cuentas.

Yo propongo:

5 7 5 2 4 3 8 8 3 4 2 8 0 4 6 1

En ese caso, voy a poner ahora las tres filas: la primera es la original, la segunda contiene los números que se obtienen duplicando los dígitos que aparecen en las posiciones pares y la tercera, está formada sumando los dígitos de los números que son mayores o iguales que diez. Resulta así:

5 7 5 2 4 3 8 8 3 4 2 8 0 4 6 1

5 14 5 4 4 6 8 16 3 8 2 16 0 8 6 2

5 5 5 4 4 6 8 7 3 8 2 7 0 8 6 2

Y llegamos al último paso. Ahora sume los primeros 15 dígitos que figuran en esta última fila ¿Qué obtiene? Verifique que suman 78. Entonces, el dígito que hace falta es un 2 que es justamente el que figura como último en la tercera fila. O sea, está todo bien ¿Por qué? Porque al agregar el 2, ahora la suma de los 16 números resulta ser 80.

(5+5+5+4+4+6+8+7+3+8+2+7+0+8+6+2).

Moraleja: como escribí más arriba, esto ¡no garantiza que la tarjeta sea válida ni que la cuenta de quien la presenta tenga fondos ni dice nada sobre la historia crediticia del dueño! Solo dice que lo más probable es que no se haya producido ningún tipo de error en la transmisión de los datos. Y esto es todo lo que uno quería conseguir.

Lo que me interesa enfatizar es que el último dígito, el número dos del final, es el que confirma que los primeros 15 están bien: no se pretende ninguna otra cosa, y eso, con el uso de este algoritmo, está garantizado. Para operaciones que involucran los dígitos de una tarjeta de crédito o de débito, y uno no está en condiciones de alcanzarle físicamente el plástico al vendedor, entonces, el uso del algoritmo de Luhn garantiza que no hubo errores de buena fe [2][3]

[1] En realidad, aunque uno no lo sepa, la fecha de vencimiento así como los dígitos de seguridad también podrían estar incluidos entre los que verifica el algoritmo, y por eso se los piden como parte de los datos.

[2] El algoritmo sirve –por ejemplo- para detectar el más común de todos los errores de tipeo: las transposiciones de números consecutivos. Pero es muy importante que sean consecutivos porque si uno transpusiera los dígitos que ocupan dos lugares pares o impares, el algoritmo no los detectaría porque el resultado le daría lo mismo.

 

[3] La versión original del algoritmo que inventó Luhn empieza “al revés”, en donde los dígitos se leen de derecha a izquierda, pero yo utilicé esta variante para hacer las cuentas más sencillas. Conceptualmente, son equivalentes.