Blog de Internet Security Auditors: Ampliación del IIN (BIN) de 6 a 8 dígitos: ¿Qué implicaciones conlleva?

Escrito por Internet Security Auditors | Mar 12, 2021 5:00:00 AM

NOTA ACLARATORIA - SEPTIEMBRE 2021

El PCI SSC ha actualizado la FAQ#1091 relativa a los formatos de truncamiento aceptados por las marcas de pago. Este cambio incluye nuevos criterios por parte de VISA y Mastercard para todos aquellos PAN con un BIN de 8 cifras.

De este modo, se permite almacenar los 8 primeros dígitos (BIN) y otros 4 cualesquiera. Esto hace que únicamente deba eliminarse de forma permanente un segmento de 4 cifras, y no de 6 cifras.

Para los PAN con un BIN de 6 dígitos no hay cambios, por lo que en este caso se sigue exigiendo que únicamente sean legibles los primeros 6 y otros 4 cualesquiera, exigiendo que se elimine permanentemente un segmento de un mínimo de 6 dígitos.

Este artículo trata sobre la ampliación del valor del IIN, y las implicaciones que esto conlleva para el cumplimiento con el estándar PCI DSS. Antes de entrar en el tema de fondo, es necesario hacer una pequeña introducción con el fin de explicar las partes que conforman el Primary Account Number (PAN), o Número de Cuenta Primario.

Dicho número, se encuentra presente en la cara principal de todas las tarjetas de pago, y de acuerdo con lo establecido por la norma ISO/IEC 7812:2017 publicada por la Organización Internacional de Normalización ISO/IEC (2017), se compone de los siguientes valores:

Número de identificación del emisor (IIN): Este número identifica a la institución que emitió la tarjeta de pago al titular. Cabe destacar, además, que el primer dígito del IIN se denomina identificador principal de la industria (MII) y que identifica a la categoría de entidad que emitió la tarjeta de pago.

Anteriormente, el IIN se denominaba BIN, y sus siglas significaban número de identificación de banco. Las marcas de pago VISA y Mastercard siguen utilizando esta denominación.
Número de identificación de cuenta individual: Identificador de cuenta individual. Se trata de un campo de longitud variable.
Número de control: Dígito de control que se calcula haciendo uso del algoritmo de Luhn. El algoritmo de Luhn se utiliza para generar este número, y para comprobar a posteriori si un PAN de tarjeta es válido o no.

Imagen sacada de: www.freepik.es

Norma ISO/IEC 7812:2017

El formato del número de identificación del emisor (IIN), y el del número de cuenta primario (PAN), se regula por la norma internacional ISO/IEC 7812:2017. La primera publicación de esta norma se remonta a 1985, y desde entonces, se han producido varias actualizaciones. Actualmente, se compone de dos partes:

ISO/IEC 7812-1:2017: Sistema de enumeración.
ISO/IEC 7812-2:2017: Procedimientos de solicitud y registro.

Hoy en día, los números IIN tienen una longitud de 6 dígitos. Pero, con el fin de garantizar la disponibilidad de números en el futuro, en la última versión de la ISO/IEC 7812-1 se indica que el valor del IIN debe pasar a ser de 8 dígitos. Asimismo, en la misma ISO/IEC 7812-1 también se indica que el valor mínimo del PAN debe pasar a ser de 10 dígitos, en lugar de los 8 contemplados hasta la fecha, por lo tanto, el PAN tendrá una longitud variable de 10 a 19 dígitos.

Finalmente, cabe destacar que de acuerdo con el briefing publicado por Mastercard (2018), la marca de pago aplicará el cambio de longitud del IIN en abril de 2022. Pero no es la única, en un documento publicado por VISA (2020b) se indica que el mes de abril de 2022 es la fecha límite establecida por VISA con el fin de que los adquirientes y los procesadores se encuentren preparados para trabajar con IINs de 8 dígitos. Además, en una nota de prensa posterior publicada por la misma VISA (2020a), se establece que la fecha de abril de 2022 sigue siendo completamente vigente, indicando que no se ve alterada por la situación de emergencia sanitaria causada por el virus SARS-CoV-2.

Uso del IIN

El aumento de la longitud del IIN es un cambio que puede parecer menor, pero que no lo es. No solamente tiene implicaciones a nivel de cumplimiento normativo, también conlleva cambios funcionales en los sistemas utilizados por los procesadores de pago, las entidades financieras, los comercios etc.

El valor IIN es comúnmente utilizado para realizar comprobaciones tales como identificar:

-   La marca de la tarjeta de pago. Por ejemplo: VISA, Mastercard.
-   El tipo de tarjeta de pago. Por ejemplo: Crédito, Débito, Prepago.
-   El banco emisor de la tarjeta de pago. Por ejemplo: Banco ficticio A.
-   El país en el que se emitió la tarjeta de pago. Por ejemplo: USA.

Estas comprobaciones se acostumbran a realizar por varios motivos. Algunos de los más comunes son los operacionales, funcionales, y de control y prevención del fraude.

Hay multitud de páginas web y de APIs disponibles para extraer la correlación de datos relacionados con un número IIN. Por ejemplo, dado un IIN de 8 dígitos, en la página web Binlist, se obtiene la siguiente información:

Implicaciones relacionadas con el cumplimiento PCI DSS

Antes de entrar en materia, y empezar a desgranar los requerimientos afectados de PCI DSS v3.2.1, es necesario hacer una aclaración previa, ya que los conceptos de ‘enmascaramiento’ y ‘truncamiento’ deben quedar claros desde un principio.

¿Enmascaramiento y truncamiento son lo mismo?

En este caso, tiene que quedar claro que enmascaramiento y truncamiento son dos cosas muy distintas. Dado que se trata de una duda generalizada en comercios, y otras partes interesadas que deben cumplir con el estándar, el PCI SSC publicó la FAQ#1146 para aclararlo. De acuerdo con el PCI SSC (2014) las principales diferencias que hay entre ambos son las siguientes:

- “El enmascarado es un método para ocultar un segmento del PAN cuando este se muestra o se imprime, por ejemplo, en un recibo. […]” (PCI SSC, 2014)

Por lo tanto, aplica únicamente a la visualización del PAN, y se trata de un método para ocultar valores de este de forma temporal, ya que, bajo una necesidad de negocio debidamente justificada, un empleado podría desenmascarar los otros valores.

- El truncamiento, en cambio, “es un método utilizado para que un segmento del PAN sea ilegible de forma permanente, y aplica cuando el PAN se almacena electrónicamente. […]” (PCI SSC, 2014)
Así pues, todos los valores del PAN truncados son irrecuperables, y no hay forma posible de recuperar el valor del PAN original.

Los requerimientos afectados de PCI DSS v3.2.1 son el 3.3 y el 3.4. En los siguientes apartados se analizan ambos requerimientos.

Requerimiento 3.3 del estándar PCI DSS v3.2.1

A continuación, se recoge el posicionamiento de las marcas de pago Mastercard y VISA, y el del PCI SSC, para el requerimiento 3.3 de PCI DSS v3.2.1.

“ 3.3. Enmascare el PAN (número de cuenta principal) cuando aparezca (los primeros seis o los últimos cuatro dígitos es la cantidad máxima de dígitos que aparecerá), de modo que solo el personal con una necesidad comercial legítima pueda ver más que los primeros seis o los últimos cuatro dígitos del PAN.” (PCI SSC, 2018a)

De acuerdo con el briefing publicado por Mastercard (2018), la marca indica que el aumento de la longitud del IIN de 6 a 8 dígitos no provoca modificación alguna sobre este requisito. En el mismo documento se indica, además, que, si se requiere la visualización de cualquier otro dígito, esta únicamente puede realizarse bajo una justificación de negocio debidamente fundamentada y documentada.

El texto concreto presente en el briefing de Mastercard es el siguiente:

“ […] For Requirement 3.3, the masking approach should always ensure that only the minimum number of digits is displayed as necessary to perform a specific business function. For example, if only the last four digits are needed to perform a business function, mask the PAN so that individuals performing that function can view only the last four digits. While the intent of Requirement 3.3 is to display no more than the “first six and last four digits” of a PAN, an entity will be permitted to display more digits if needed but only with a documented business justification. […]” (Mastercard, 2018)

En un documento publicado por la marca de pago VISA (2020b), se hace hincapié en que PCI DSS permite la visualización de todos o parte de los dígitos del PAN ante una necesidad de negocio debidamente justificada y legítima. Asimismo, también aprovechan para indicar que la longitud total del PAN seguirá siendo de 16 dígitos, salvo el caso de V PAY (disponible en Europa), que hace uso de números PAN con una longitud de 19 dígitos en algunas implementaciones específicas.

El texto concreto del documento de VISA es el siguiente:

[…] Data Presented on Screens and Reports: Provisions already within the PCI DSS allow users with a legitimate business need to see any or all of the PAN digits [...] (VISA, 2020b)

En el mismo sentido se expresa la FAQ#1492, publicada recientemente por el PCI SSC (2021), indicando que el requerimiento 3.3 requiere que como máximo solamente se pueden mostrar los primeros 6 y los últimos 4 dígitos salvo que exista una justificación de negocio documentada y legítima, la cual debe ser aprobada por la dirección/gerencia, y generar evidencias que deben almacenarse y ponerse a disposición de los auditores para su revisión durante la auditoría PCI DSS.

Requerimiento 3.4 del estándar PCI DSS v.3.2.1

El otro requerimiento afectado en la versión 3.2.1 de PCI DSS es el 3.4. A continuación, se realiza una breve explicación del requerimiento, y se recoge el posicionamiento de las marcas de pago Mastercard y VISA, y el del PCI SSC.

“ 3.4. Convierta el PAN (número de cuenta principal) en ilegible en cualquier lugar donde se almacene (incluidos los datos que se almacenen en medios digitales portátiles, en medios de copia de seguridad y en registros) utilizando cualquiera de los siguientes métodos:

• Valores hash de una vía basados en criptografía sólida (el hash debe ser del PAN completo)
• Truncamiento (los valores hash no se pueden usar para reemplazar el segmento truncado del PAN)
• Tokens y ensambladores de índices (los ensambladores se deben almacenar de manera segura).
• Criptografía sólida con procesos y procedimientos asociados para la administración de claves.” (PCI SSC, 2018a)

Según recoge la versión 3.2.1 del estándar PCI DSS publicado por el PCI SSC (2018a), si se quiere utilizar la opción del truncamiento para cumplir con el requerimiento 3.4, debe eliminarse de forma permanente un segmento de los datos del PAN, con el fin de que solamente se almacene una parte de este. Y, además, se indica que generalmente pueden almacenarse los primeros seis y los últimos cuatro dígitos.

De acuerdo con el briefing publicado por Mastercard (2018), la marca de pago tampoco introduce ningún cambio que permita adaptar el requerimiento 3.4 a la nueva realidad que aplicará el próximo mes de abril de 2022. Así pues, indica de forma clara y tajante que los formatos de truncamiento aceptados por Mastercard no se han visto alterados como resultado de la ampliación de la longitud del IIN de 6 a 8 dígitos, y que, si se requiere almacenar más de los 6 primeros y otros 4 dígitos cualesquiera, entonces el truncamiento no es una opción válida para cumplir con el requerimiento 3.4 de PCI DSS v3.2.1.

El texto concreto que contiene el briefing de Mastercard es el siguiente:

“ For Requirements 3.4, the maximum digits of a PAN that can be stored using truncation are “first six and any other four.” Mastercard’s acceptable truncation format has not changed as a result of the 8-digit BIN expansion mandate. If an entity needs to store more than “first six and any other four,” then truncation cannot be used to meet Requirement 3.4 and one of the other three approaches would need to be applied to render the PAN unreadable anywhere it is stored.” (Mastercard, 2018)

Un lector familiarizado con PCI DSS seguramente piense que en los dos párrafos anteriores hay un error. Pero no es así. Se ha indicado ‘otros 4 dígitos cualesquiera’ intencionadamente. En el siguiente apartado, denominado “Entonces, ¿cómo queda la situación?”, se entenderá el motivo.

En el documento publicado por la marca de pago VISA (2020b), se indica de forma clara que PCI DSS exige que, al menos, 6 dígitos se trunquen o cifren para proteger los datos en reposo. E indica que, todos aquellos clientes que tengan una necesidad de exponer el BIN de 8 dígitos completo, tendrán que utilizar otros métodos tales como el cifrado, el hasheo o la tokenización.

El texto concreto que contiene el documento de VISA es el siguiente:

“ [..] After evaluating the expansion to eight-digit BINs, PCI advises that a minimum of six digits must be truncated or encrypted to protect data at rest. Clients that use truncation as their only method of complying with the PCI requirement for protecting data at rest, and who would like to expose the full eight-digit BIN as well as the last four digits, will need to add one or more of the other acceptable methods for data protection, such as encryption, hashing or tokenization [...]” (VISA, 2020b)

En el mismo sentido se expresa la FAQ#1492 publicada recientemente por el PCI SSC (2021), indicando que cada marca de pago tiene diferentes longitudes de BIN y PAN, y diferentes criterios, por lo que las preguntas sobre los requisitos de truncamiento deben dirigirse directamente a las propias marcas de pago aplicables en cada caso. En el siguiente apartado se analizan los métodos de truncamiento permitidos por cada marca de pago.

Entonces, ¿cómo queda la situación?

Si bien, por norma general, todas las marcas de pago aceptan que los métodos de truncamiento permiten almacenar de forma libre y sin restricciones los 6 primeros, y los 4 últimos dígitos del PAN, aplican algunas posibles flexibilizaciones que deben tenerse en consideración, y que van en línea con la casuística analizada en el caso del requerimiento 3.4.

De acuerdo con la FAQ#1091 publicada por el PCI SSC (2018b), los métodos de truncamiento permitidos según cada marca de pago son los siguientes:

Longitud del PAN	Marca de pago
Longitud del PAN	American Express	Discover	Mastercard	JCB	Visa
PAN con una longitud superior a los 16 dígitos BIN de 6 dígitos	N/A	N/A	Al menos deben eliminarse 6 dígitos. Números máximos que pueden mantenerse: PAN de 17 dígitos: “Los primeros 6 dígitos, y otros 5 cualesquiera” PAN de 18 dígitos: “Los 6 primeros dígitos, y otros 6 cualesquiera” PAN de 19 dígitos: “Los primeros 6 dígitos, y otros 7 cualesquiera”	N/A	Al menos deben eliminarse 6 dígitos. Números máximos que pueden mantenerse: PAN de 17 dígitos: “Los primeros 6 dígitos, y otros 5 cualesquiera” PAN de 18 dígitos: “Los 6 primeros dígitos, y otros 6 cualesquiera” PAN de 19 dígitos: “Los primeros 6 dígitos, y otros 7 cualesquiera”
PAN con una longitud de 16 dígitos BIN de 8 dígitos	N/A	Al menos deben eliminarse 6 dígitos. Números máximos que pueden mantenerse: “Los primeros 6 dígitos, y otros 4 cualesquiera”	Al menos deben eliminarse 6 dígitos. Números máximos que pueden mantenerse: “Los primeros 6 dígitos, y otros 4 cualesquiera”	N/A	Al menos deben eliminarse 6 dígitos. Números máximos que pueden mantenerse: “Los primeros 6 dígitos, y otros 4 cualesquiera”
PAN con una longitud de 16 dígitos BIN de 6 dígitos	N/A	Al menos deben eliminarse 6 dígitos. Números máximos que pueden mantenerse: “Los primeros 6 dígitos, y otros 4 cualesquiera”
PAN con una longitud de 15 dígitos	Al menos deben eliminarse 5 dígitos. Números máximos que pueden mantenerse: “Los primeros 6 dígitos, y los últimos 4”	N/A	Al menos deben eliminarse 5 dígitos. Números máximos que pueden mantenerse: “Los primeros 6 dígitos, y otros 4 cualesquiera”	N/A	N/A
PAN con una longitud inferior a los 15 dígitos	N/A	Números máximos que pueden mantenerse: “Los primeros 6 dígitos, y otros 4 cualesquiera”		N/A	N/A

Así pues, queda claro que, si bien el posicionamiento oficial y ampliamente aceptado por todas las marcas de pago pasa por permitir que los primeros 6 dígitos, y los últimos 4 dígitos no se trunquen (si este es el método usado para cumplir con el requerimiento 3.4), hay algunas excepciones que pueden aplicar (o no) en función de la marca de pago de las tarjetas utilizadas en el entorno.

Conclusiones

Una vez analizados los posicionamientos del PCI SSC, y de las marcas de pago Mastercard y VISA, queda claro lo siguiente:

La norma general ampliamente aceptada por todas las marcas de pago sigue siendo que, en caso de aplicar truncamiento, únicamente se pueden almacenar, como máximo, los 6 primeros y los 4 últimos números del PAN de una tarjeta.
La norma general ampliamente aceptada por todas las marcas de pago sigue siendo que el PAN enmascarado únicamente puede mantener visibles los 6 primeros y los 4 últimos números. Si se requiere la visualización de algún otro número adicional, se tendrá que desenmascarar de forma expresa, y siempre, justificando dicha visualización con una necesidad de negocio legítima, y aplicando el resto de los controles del estándar PCI DSS que pudieren ser de aplicación.

Por todo ello, con la versión actual del estándar, y teniendo en cuenta los posicionamientos vigentes emitidos por las marcas de pago y la FAQ#1492 del PCI SSC (2021), las casuísticas de cumplimiento para el requerimiento 3.3 quedan de la siguiente forma:

Sin una necesidad legítima de negocio, únicamente se pueden visualizar los 6 primeros y los últimos 4 dígitos de un PAN, según recoge ya actualmente PCI DSS v3.2.1 (PCI SSC, 2018a). En caso de existir dicha necesidad, se podrán visualizar el resto de los valores que sean necesarios, siempre que dichas visualizaciones se hagan teniendo en cuenta todos los requerimientos aplicables.

Esto requerirá, pues, que en función del conjunto de números que se tengan que visualizar por necesidades legítimas y justificadas de negocio, se pueda (o no) cumplir con el requerimiento 3.4 haciendo uso del truncamiento, ya que este, es un método irreversible, de modo que un segmento truncado del PAN no puede ser recuperado.

Las casuísticas de cumplimiento para el requerimiento 3.4 quedan de la siguiente forma:

Necesidad de almacenar únicamente el BIN de 8 dígitos: Si únicamente se requiere mantener el BIN, y se truncan todos los otros valores del PAN, se está cumpliendo con lo estipulado en la FAQ#1091 publicada por el PCI SSC (2018b), siempre que las tarjetas de pago tratadas sean de Mastercard, VISA y/o Discover.
Necesidad de almacenar los últimos 4 números: Si únicamente se requiere mantener los últimos 4 números del PAN, y se truncan todos los otros dígitos, se está cumpliendo con lo estipulado en la FAQ#1091 publicada por el PCI SSC (2018b).
Necesidad de almacenar el BIN de 8 dígitos, y los últimos 4 dígitos del PAN: Bajo esta casuística, y de acuerdo con toda la información publicada hoy en día por las marcas de pago y el PCI SSC, no se puede almacenar un segmento de 11 dígitos del PAN en claro si se quiere cumplir con la FAQ#1091 publicada por el PCI SSC (2018b).

Los comercios, proveedores de servicio y terceras partes que se encuentren bajo esta casuística, tendrán que implantar alguna de las medidas adicionales previstas en el requerimiento 3.4 de PCI-DSS v3.2.1 publicado por el PCI SSC (2018a), tales como podrían ser:

a. La implementación de sistemas de cifrado y descifrado utilizando criptografía robusta
b. Valores hash de una vía basados en criptografía sólida (el hash debe ser del PAN entero)
c. Tokens y ensambladores de índices (los ensambladores se deben almacenar de forma segura)

Cabe mencionar que, además, tal y como nos recuerda la FAQ#1091 publicada por el PCI SSC (2018b), no se pueden utilizar múltiples métodos de truncamiento en un mismo entorno para una misma tarjeta de pago. Si por algún motivo justificado de negocio se requiere almacenar el mismo PAN, truncado de forma distinta en varios sistemas, se tendrán que aplicar controles de seguridad adicionales, con el fin de evitar que se puedan correlar las versiones truncadas.

Finalmente, aunque en un principio se esperaba la publicación de la nueva versión de PCI DSS a medianos de 2021 (Goodspeed, 2020), el PCI SSC ha ampliado el plazo de validación interna, por lo que, por ahora, no hay una fecha de publicación oficial. Se espera que esta se comunique a lo largo del presente año 2021 (Goodspeed, 2021).

Pero ¿qué podemos esperar de dicha versión? ¿Abordará de una forma distinta esta casuística? De momento no ha transcendido mucha información pública, pero hay un cambio destacable. La aparición del enfoque personalizado (Holloway, 2020).

De acuerdo con el artículo publicado por Holloway (2020) en el blog oficial del PCI SSC, la versión 4.0 de PCI DSS seguirá contemplando un conjunto de requerimientos, pero estos podrán ser “modificados” por las organizaciones con el fin de adaptarse a las necesidades de negocio, siempre que se cumpla con el objetivo del requerimiento original.

Es importante destacar que:

- La organización deberá justificar el requerimiento personalizado, y generar documentación para que el QSA la pueda validar.
- La justificación de personalizar uno más requerimientos se deberá apoyar en un proceso de análisis y gestión de riesgos de seguridad maduro por parte de la organización.
- En última instancia, será el QSA el responsable de determinar si el enfoque propuesto por la organización puede ser aceptado para sustituir al requerimiento original. Para ello, el QSA definirá las pruebas de auditoría específicas para cada uno de los requerimientos afectados.

Este punto conlleva un gran cambio, en mayúsculas. Hasta ahora, los requerimientos de PCI DSS se tenían que cumplir a ‘rajatabla’, y no daban lugar alguno a modificaciones de este tipo, salvo el uso de controles compensatorios, los cuales daban poca flexibilidad a las organizaciones. Siempre que se tenía una casuística de cumplimiento especial, se tenía que definir el control compensatorio y validar con el QSA, banco adquiriente y/o marcas de pago.

Por lo tanto, si todo prosigue según lo esperado, los requerimientos equivalentes en la versión v4.0 podrían ser modificados bajo el enfoque personalizado contemplado por PCI DSS v4.0.

Pero hasta que la versión 4.0 de PCI DSS no sea una realidad, bajo PCI DSS v3.2.1, si alguien se encuentra bajo la casuística expuesta en este artículo, lo primero que debe hacer es contactar con su QSA para confirmar la viabilidad de las flexibilizaciones indicadas en el apartado “Entonces, ¿cómo queda la situación?”, y si es necesario, contactar con las entidades adquirientes y marcas de pago según corresponda para validar las flexibilizaciones que se quiere implementar.

Referencias bibliográficas
1- Goodspeed, L. (2020). PCI DSS v4.0: Anticipated Timelines and Latest Updates. PCI SSC. https://blog.pcisecuritystandards.org/pci-dss-v4-0-anticipated-timelines-and-latest-updates
2- Goodspeed, L. (2021). PCI DSS v4.0 Timeline Updated to Support an Additional RFC. PCI SSC. https://blog.pcisecuritystandards.org/pci-dss-v4.0-timeline-updated-to-support-an-additional-rfc
3- ISO/IEC. (2017). ISO/IEC 7812-1:2017(en) Identification cards — Identification of issuers — Part 1: Numbering system. https://www.iso.org/obp/ui/#iso:std:iso-iec:7812:-1:ed-5:v1:en
4- Holloway, L. (2020). A View into Feedback from the PCI DSS v4.0 RFC. PCI SSC. https://blog.pcisecuritystandards.org/a-view-into-feedback-from-the-pci-dss-v4-0-rfc
5- Mastercard. (2018). 8-Digit BIN Expansion Mandate and PCI DSS Impact. https://www.mastercard.com/content/dam/public/mastercardcom/globalrisk/pdf/8-Digit-BIN-Expansion-Mandate-and-PCI-DSS-Impact.pdf
6- PCI SSC. (2014). What is the difference between masking and truncation? https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/What-is-the-difference-between-masking-and-truncation
7- PCI SSC. (2018a). Requirements and Security Assessment Procedures version 3.2.1. https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2-1.pdf
8- PCI SSC. (2018b). What are acceptable formats for truncation of primary account numbers?. https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/What-are-acceptable-formats-for-truncation-of-primary-account-numbers
9- PCI SSC (2021). How can an entity meet PCI DSS requirements for PAN masking and truncation if it has migrated to 8-digit BINs?. https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/How-can-an-entity-meet-PCI-DSS-requirements-for-PAN-masking-and-truncation-if-it-has-migrated-to-8-digit-BINs
10- VISA. (2020a). Numerics Initiative: Simplified Requirements for Eight-Digit Issuing BIN Adoption. https://usa.visa.com/dam/VCOM/global/support-legal/documents/numerics-initiative-simplified-requirements-for-eight-digit-issuing-bin-adoption.pdf
11- VISA. (2020b). Preparing for the Eight-Digit BIN. Frequently Asked Questions. https://usa.visa.com/dam/VCOM/global/partner-with-us/documents/visa.com-numerics-faq.pdf

Autor: Marc de Tébar - CISM, PCIP, MCAF, SFPC
Dpto. Consultoría

Ver post completo