CID - 1 Dic 2021

CONTRATO DE
INTERCAMBIO DOMÉSTICO
Capítulo I
Contrato de Intercambio Domestico
CID Versión 6.2 – diciembre 01, 2021
INDICE
MANUAL OPERATIVO
I. REGLAS OPERATIVAS
II. RESOLUCIÓN DE CONTROVERSIAS
III. VALIDACIONES
IV. COSTO DE SERVICIOS
V. PENAS CONVENCIONALES POR INCUMPLIMIENTO
VI. POLÍTICAS Y PROCEDIMIENTOS DE SEGURIDAD CON LOS RECEPTORES
DE PAGOS
VII. FIRMA EN ARCHIVO
VIII. PAGO DE TARJETAS EN EL INTERCAMBIO
IX. PEAJE
X. SERVICIO DE PAGO RAPIDO (QPS)
XI. COMERCIO ELECTRÓNICO
XII. CONTROL Y ADMINISTRACIÓN DE AFILIACIONES
XIII. VALIDACIÓN DE RECLAMACIÓN DE UN TARJETAHABIENTE
XIV. CONTINGENCIAS
XV. CHIP EMV
XVI. PROMOCIONES
XVII. PCI DSS
XVIII. LACPI
XIX. CARGOS PERIODICOS
XX. CAT (TRANSACCIONES ACTIVADAS POR EL TARJETAHABIENTE)
XXI. TAG (INTERCAMBIO DE TRANSACCIONES CON TAG)
XXII. MOVILIDAD TARJETAS DE CRÉDITO
XXIII. OPERATIVA CHECK IN – CHECK OUT
XXIV. VALIDACIÓN DE INDICADORES
XXV. DIGITALIZACIÓN DE IMÁGENES
XXVI. OPERATIVA MO/TO
XXVII. CONTACTLESS
XXVIII. CASH BACK

ANEXOS
GLOSARIO
Capítulo I
C
CAPÍTULO I
MANUAL OPERATIVO
Capítulo I
1.- ADMINISTRACIÓN DE INSTITUCIONES Y BINES.
1.1 Las Instituciones Emisoras y/o Adquirentes que requieran participar en el

Intercambio Doméstico deben solicitar su registro a través de la Cámara de
Compensación con que opere, en los términos de las reglas publicadas por
Banco de México y la Comisión Nacional Bancaria y de Valores.
Las Cámaras de Compensación deben registrar a las Instituciones que operen

con ellos en el Anexo 29 (Instituciones Participantes en el Intercambio), el
registro de una Institución se debe realizar por alguno de los responsables
designados en el Anexo 3 (Responsables para la Actualización de Instituciones
/ BINES), mediante correo electrónico al Árbitro Operativo, y se verá reflejado
en el Anexo 29, al día hábil siguiente a su solicitud.
Estructura del catálogo de Instituciones:
La estructura del número de una entidad estará compuesta por 06 dígitos
• En la primera posición con un dígito se ubica la Cámara (1,2 ó 3)

• En la segunda posición con un dígito se ubica si es Adquirente y/o
Emisor (1 ó 2)
• De la tercer a sexta posición se ubica el Número asignado a la entidad.
CÁMARA PREFIJO EMISOR Ó ADQUIRENTE CONSECUTIVO

1 POSICIÓN 4 POSICIONES
NUMÉRICO 1 POSICIÓN NUMÉRICO (NUMÉRICO)
X X XXXX
CÁMARA PREFIJO DE CÁMARA

PROSA 1
E-GLOBAL 2
MASTERCARD 3
PREFIJO EMISOR Ó PREFIJO DE EMISOR Ó

ADQUIRENTE ADQUIRENTE
EMISOR 1
ADQUIRENTE 2
Para las nuevas entidades, el Árbitro Operativo asignará un “6” en la tercera

posición, de la posición 4 a la 6 serán números consecutivos, continuando la
numeración existente en el catálogo.
Capítulo I
El número consecutivo de 4 posiciones asignado debe ser el mismo sin importar si
opera con más de una Cámara de Compensación o si opera como Emisor o
Adquirente.
1.2 En el Anexo 1 (Relación de BINES sujetos al Intercambio Doméstico), se

detallan los BINES de las Tarjetas que fueron previamente otorgados por un
Titular de Marca o la Secretaria de Economía y que serán considerados en el
intercambio, así mismo se establece que la longitud de los BINES sólo puede
ser de 6 u 8 dígitos, no se admiten longitudes diferentes y deben iniciar con un
valor igual a 2, 3, 4, 5, 6 u 8 de acuerdo al ISO/IEC 7812.
1.2.1 La solicitud para dar de alta, baja o modificar cualquier BIN se debe efectuar
en la aplicación denominada BIN Manager, que es una herramienta de
administración, control de operativas y riesgos de los BINES previamente
autorizados que participan en el Intercambio Doméstico.
En caso de contingencia en el proceso de alta, baja, y/o modificación de

BINES de cualquiera de las Instituciones o del Árbitro Operativo, la
información se debe enviar vía correo electrónico a los funcionarios
registrados en el Anexo 3 (Responsables para la Actualización de
Instituciones y BINES).
Las solicitudes se envían de forma electrónica a los responsables

designados para esta actividad según Anexo 3, con la información señalada
en el Anexo 2 (Información Requerida para Alta, Baja o modificación de
BINES), de este Manual Operativo.
Adicionalmente a las notificaciones señaladas en el párrafo anterior, los

Adquirentes cuentan con 3 vías de comunicación para obtener esta
información:
1. Notificación por correo electrónico a los responsables detallados en el
Anexo 3A (Contactos para actualización de plataformas Adquirente)
2. Descarga manual de los movimientos en tránsito y bines vigentes.
3. Conexión vía API a BIN Manager que permite actualizar de forma
automática los sistemas de las Instituciones participantes en el
intercambio doméstico.
No se puede dar de alta ningún BIN en el intercambio, si la institución a la

que pertenece no se encuentra registrada en el Anexo 29 (Instituciones
Participantes en el Intercambio)
Los participantes pueden solicitar la presentación ante el Árbitro Operativo
de los certificados de los Titulares de Marca o Secretaría de Economía en
caso de requerir alguna aclaración derivada del alta, modificación y/o
aceptación de un BIN en el Intercambio Doméstico, para que éste valide que
el BIN está amparado por un certificado emitido por las entidades
anteriormente señaladas, sin que este sea un requisito para el trámite de alta.
1.2.2 La solicitud electrónica de alta, baja o modificación de un BIN sólo puede ser
enviada a las camaras de compensación por alguno de los responsables
Capítulo I
detallados en el Anexo 3 (Responsables para la Actualización de
Instituciones y BINES).
1.2.3 La solicitud (alta, baja o modificación) del Emisor y respuesta del Adquirente
serán registradas a través de la aplicación BIN Manager y se envía correo
electrónico a los funcionarios registrados en el Anexo 3 (Responsables para
la Actualización de Instituciones y BINES).
1.2.4 Se reciben solicitudes de Alta, Baja o Modificación de BINES durante los días
hábiles del año en un horario de 9:00 a 17:00 horas y las instituciones
Adquirentes tienen un plazo máximo de 30 días naturales contados a partir
del día siguiente hábil de la fecha de registro en la aplicación BIN Manager
para actualizar los BINES en todas sus plataformas.
1.2.5 Las solicitudes de alta, baja o modificación de BINES recibidas entre el 15

de noviembre al 15 de enero de cada año, pueden ser atendidas de buena
fe por los Adquirentes en el tiempo establecido en el párrafo anterior, de no
ser así el periodo de atención inicia el día 16 de Enero de cada año.
1.2.6 Cada Cámara de Compensación receptora de una solicitud de Alta, Baja o

modificación de BINES, debe confirmar mediante la aplicación BIN Manager
su actualización.
1.2.7 La Baja de un BIN se registra en la aplicación BIN Manager a solicitud del

Emisor o cuando las autoridades (Banco de México, Comisión Nacional
Bancaria y de Valores o Secretaría de Hacienda y Crédito Público) notifiquen
la suspensión de una institución registrada en el Anexo 29 (Instituciones
participantes en el Intercambio).
Cuando la baja se derive de una suspensión determinada por la autoridad, la

Cámara de Compensación, debe registrar el movimiento de baja en BIN
Manager, de los bines asociados a dicha Institución, en un plazo no mayor a
48 horas a partir de haber recibido la notificación por parte de las autoridades.
La cámara de compensación emisora debe darlo de baja en sus procesos en

línea (autorizaciones). Se mantiene activo durante un periodo de 6 meses
para el proceso Batch, donde sólo se deben intercambiar y/o compensar
transacciones de Aclaraciones o Pagos de Tarjetas en el Intercambio, al
término de este plazo, se marca como inactivo en la Aplicación BIN Manager.
La solicitud de baja de una Institución registrada en el Anexo 29 (Instituciones

Participantes en el Intercambio), se aplica 6 meses después de confirmada
la baja del proceso Batch de su último BIN activo.
1.2.8 Cuando se solicite un movimiento de Modificación, de cambio de Tipo de

Producto (naturaleza contable) de un BIN, este debe cumplir el siguiente
ciclo:
1. Solicitar modificación mediante la aplicación BIN Manager.
2. El Emisor debe mantener inactivo el BIN durante un plazo de 90 días,

a partir de la fecha de solicitud del movimiento de modificación.
Capítulo I
Las aclaraciones que presenten los tarjetahabientes por transacciones
de Bines en proceso de modificación de Tipo de Producto, efectuadas
antes del periodo de inactividad (90 días), serán tratadas bajo las
características del producto registrado antes de la solicitud de cambio.
3. El emisor debe entregar el documento proporcionado por las marcas

donde se autoriza la naturaleza contable del BIN.
Cuando se solicite Venta de Cartera (Cesión de Derechos), se hará el cambio

de razón social al de la nueva institución que está adquiriendo la
responsabilidad del BIN y se debe especificar la fecha en la que el cambio
será efectivo, por lo que a partir de la fecha antes mencionada, la nueva
institución será responsable de las aclaraciones sin importar que las
transacciones hayan sido realizadas con anterioridad a la solicitud de cesión
de derechos.
Cuando se solicite Migración de Cámara de Compensación debe existir plan

de trabajo por lo menos 90 días naturales previos a la fecha en que se hará
efectiva la migración .
1.2.9 Será responsabilidad de cada Adquirente actualizar los BINES de los

Emisores en sus plataformas de acuerdo a las características determinadas
por el Emisor en el Anexo 1 y coordinar con sus Agregadores / Receptores
de Pagos afiliados incluyendo sus Interredes, la actualización de éstos.
Registrar en el Anexo 9 (Relación de BINES Adquirentes) a través de su

Cámara de Compensación, el detalle de sus BINES de adquirencia que
deben considerarse en el Intercambio Local, para que pueda operar en el
intercambio.
1.2.10 Los emisores deben registrar e identificar los Bines que operen con las
características de Tarjeta Virtual, wallet o digital, en la herramienta BIN
Manager.
El emisor está obligado a obtener la certificación LACPI de los Bines que

opere con las características de Tarjeta Virtual, wallet o digital, antes de su
salida a producción.
1.2.11 En caso de una incidencia en la aceptación de un BIN, esta debe ser

notificada a través de la herramienta de incidencias del Árbitro Operativo, por
alguno de los funcionarios registrados en el Anexo 3 y/o las Instituciones que
previamente hayan obtenido su usuario y contraseña a través de su Cámara
de Compensación y/o Empresa Especializada.
El Emisor antes de ingresar una incidencia debe realizar las siguientes

validaciones:
• El BIN fue dado de alta para la aceptación de la transacción, motivo de la

incidencia en BIN Manager.
• El template del BIN se encuentra verificado por un LACPI y ha entregado

insumos e iniciado el proceso de verificación con el resto de laboratorios
Capítulo I
existentes de acuerdo con lo establecido en el capítulo XVIII (LACPI), solo
aplica para incidencias en TPV y mPOS.
• La tarjeta correspondiente a la incidencia se encuentre vigente, activa y

con fondos suficientes.
• El Emisor debe realizar un monitoreo de transacciones del BIN de la

incidencia en la afiliación involucrada, para confirmar que no esta
transaccionando.
El Adquirente antes de ingresar una incidencia debe realizar las siguientes

validaciones:
• El BIN fue dado de alta para la aceptación de la transacción, motivo de la

incidencia en BIN Manager.
• La aplicación se encuentra verificada por un LACPI de acuerdo con lo

establecido en el capítulo XVIII (LACPI).
• El Adquirente debe realizar un monitoreo de transacciones del BIN de la

incidencia en la afiliación involucrada, para confirmar que no esta
transaccionando.
En caso de que se detecte que algún Emisor/Adquirente no realizó estas

validaciones en tres ocasiones en un plazo de 60 días se aplica el inciso “b”
de la penalización 32 del Capítulo V (Penas Convencionales por
Incumplimiento), en caso de un nuevo incumplimiento en un plazo de 60 días
siguientes, se aplicará el siguiente inciso de la penalizacion 32.
Una vez completada la lista de validación procede al envío de la incidencia

con información de acuerdo con el canal que presenta la incidencia:
1. Incidencia en TPV / mPOS

a. Cuenta
b. Descripción de la Incidencia
c. Afiliación del Receptor de Pagos involucrado
d. Adquirente
e. Fecha de Incidencia
f. Importe
g. Registro de verificación en LACPI
2. Incidencia en Interred
a. Cuenta
c. Afiliación del Receptor de Pagos involucrado
d. Adquirente
f. Importe
3. Pago de tarjeta de crédito en sucursal

a. Cuenta
c. Institución
Capítulo I
d. Sucursal
f. Importe
4. Incidencia en Portal Web

a. Cuenta
b. ¿Participa en 3D Secure?
c. URL del sitio
d. Descripción de la Incidencia
e. Adquirente
f. Fecha de Incidencia
g. Importe
h. Captura de pantalla del error presentado
5. Incidencia en App Móvil

a. Cuenta
b. ¿Participa en 3D Secure?
c. Nombre de Aplicación
d. Descripción de la Incidencia
e. Adquirente
f. Fecha de Incidencia
g. Importe
h. Captura de pantalla del error presentado
El registro debe ser menor o igual a 15 días hábiles de ocurrida la incidencia.
1.2.12 La herramienta de incidencias notifica al responsable para su atención,

seguimiento y respuesta, la Institución Adquirente debe corregir el problema
o demostrar que es causado por el Emisor, en un plazo máximo de 10 días
hábiles, contados a partir de la notificación de la incidencia, en caso contrario
se hace acreedor al inciso b) de la penalización 32 y debe notificar su plan
de trabajo, para lo cual, cuenta con los plazos que se detallan en la siguiente
tabla para resolver la incidencia.
Plataforma Plazo de Corrección

Punto de Venta (TPV’s, mPOS, 30 días naturales
Etc.)
Banca Móvil / Portal Institución 45 días naturales
Agregadores e Integradores 45 días naturales
App Móvil o Portal del Receptor de 60 días naturales
Pagos
Sucursal (Pago de Tarjetas) 60 días naturales
Interredes, ECR, Otros productos 60 días naturales
especializados.
El Adquirente debe seleccionar la plataforma correspondiente a la afiliación

reportada.
Todos los plazos se consideran a partir de la fecha de registro de la

incidencia.
Capítulo I
En caso de requerir más tiempo del establecido para la corrección de la
Incidencia, la Institución debe solicitar la ampliación del plazo por medio del
Comité de Tarjetas o con autorización de parte de la institución afectada.
Esta solicitud se debe realizar antes del vencimiento del plazo original
presentando el plan de trabajo correspondiente.
Los planes de trabajo, evidencias y/o acuerdos, deben quedar registrados en

la aplicación de incidencias o en la minuta del Comité de Tarjetas, ningún
otro medio escrito o electrónico será considerado como evidencia para
comprobar las gestiones realizadas en la incidencia registrada.
Las respuestas de incidencia atendida, deben aportar evidencias, enviar un

listado de transacciones aceptadas con fecha posterior al reporte de la
incidencia, documento que ampare la corrección realizada o acordar con la
parte afectada lugar, fecha y hora para realizar una prueba que valide la
corrección del problema reportado.
La Institución que registró la incidencia cuenta con un plazo de 10 días

hábiles a partir de la fecha de notificación de incidencia atendida o
improcedente para cerrar la incidencia o cambiar el estatus de la misma,
dando comentarios al respecto en el plazo señalado, en caso contrario la
incidencia se considerará como resuelta y se cierra una vez vencido el plazo.
Cuando se reciba respuesta de incidencia improcedente o resuelta y la

contraparte reporte que continua el problema, se debe citar a un grupo de
análisis, incluyendo a las partes involucradas y en caso de aplicar también a
LACPI, para determinar la causa del problema y poder establecer
compromisos que contribuyan a la solución de la incidencia.
El grupo de análisis debe integrarse como mínimo por personal involucrado

en la incidencia:
• Cámaras de Compensación
• Emisor
• Adquirente
• Coordinador de Operaciones
• Coordinador de Nuevas Tecnologías
• Árbitro Operativo
Si la incidencia se reactiva, los plazos para proporcionar un diagnóstico o

realizar la corrección continuan y en caso de que estos se hayan vencido, se
aplicará la amonestación o penalización correspondiente.
1.2.13 INCUMPLIMIENTOS
INCUMPLIMIENTO AL PLAZO INICIAL
2 días hábiles después de concluir el plazo de 10 días hábiles y no presentar

alguno de los siguientes documentos:
• Plan de Corrección
• Soporte de No Procedencia
• Respuesta de Incidencia Resuelta
Capítulo I
El Adquirente se hace acreedor a lo señalado en el inciso c) de la
penalización 32, del Capítulo V (Penas Convencionales por Incumplimiento)
y cuenta con 10 días hábiles adicionales para entregar el documento
correspondiente.
En caso de nuevos incumplimientos el Adquirente se hace acreedor a lo

establecido en el siguiente nivel de la penalización 32 y cuenta con 10 días
hábiles adicionales para entregar el documento correspondiente.
En caso de aplicar el inciso “f” de la penalización 32, se notifica al Comité de

Tarjetas para determinar las acciones a seguir.
INCUMPLIMIENTO AL PLAZO DE CORRECCIÓN

2 días hábiles después de concluir el plazo de corrección y no solucionar la
incidencia, el Adquirente se hace acreedor a lo señalado en el inciso c) de la
penalización 32 del Capítulo V (Penas Convencionales por Incumplimiento)
y cuenta con 10 días hábiles adicionales para solucionar la incidencia.
En caso de nuevos incumplimientos el Adquirente se hace acreedor a lo

establecido en el siguiente nivel de la penalización 32 y cuenta con 10 días
hábiles adicionales para solucionar la incidencia.

INCUMPLIMIENTO AL PLAZO DE CORRECCIÓN AMPLIADO

Un Adquirente solicita ampliación del plazo establecido para la corrección de
una incidencia y 2 días hábiles después de concluir el plazo solicitado no ha
solucionado la incidencia, el Adquirente se hace acreedor a la penalización
señalada en el inciso d) de la penalización 32 del Capítulo V (Penas
Convencionales por Incumplimiento), y cuenta con 10 días hábiles
adicionales para solucionar la incidencia.
En caso de un nuevo incumplimiento, el Adquirente se hace acreedor a lo

establecido el siguiente nivel de la penalización 32 y cuenta con 10 días
hábiles adicionales para corregir la incidencia.

1.2.14 En caso de altas, bajas o modificaciones de un BIN Adquirente, el plazo será

de 30 días naturales y los responsables serán los establecidos para la
actualización de BINES de Emisor, mediante la aplicación BIN Manager.
Cuando se presente este tipo de movimiento se notifica vía correo electrónico

al Despacho Administrador de la BDU, para sus controles internos y se
integra en el Anexo 9 (Relación de BINES Adquirentes).
Capítulo I
2.- LIMITE DE TIEMPO PARA PRESENTACION DE TRANSACCIONES A
INTERCAMBIO.
2.1 Se establecen los siguientes tiempos (días naturales):
CRÉDITO
Facturación Facturación Facturación
De 1 a 30 Extemporánea Extemporánea Extemporánea
días (de 121 a 320 (de 321 días en
(de 31 a 120 días) adelante)
días)
Forma de Proceso Proceso Normal Aplica de Buena Fe No se Acepta

Presentación Normal o Anexo 12 con costo de servicio
ambos con costo de Anexo 12
servicio
2.1.1 Recibir en el intercambio, los importes de los Comprobantes de venta,

generados por el uso de Tarjetas de Crédito, con una antigüedad no mayor
a 30 días naturales, después de la fecha de suscripción del documento.
Para el proceso de devoluciones aplica lo señalado en el Anexo 21 de este

contrato.
2.1.1.1 Aquéllas transacciones que se encuentren en el periodo de 31 a 120 días

pueden presentarse para su recuperación por medio del proceso normal
de intercambio, así como por lo establecido en el Anexo 12 (Presentación
de Facturación Extemporánea Crédito), con el costo de servicio
establecido en el punto “H” del capítulo IV (Costos de Servicio), no aplica
para el rubro de Devoluciones.
2.1.1.2 Cuando un Emisor reciba reclamación del Tarjetahabiente, derivado de

una transacción que se encuentre en el periodo de 31 a 120 días y que
el Adquirente presentó a través del proceso normal de Intercambio de
Facturación, así como por lo establecido en el Anexo 12 (Presentación de
Facturación Extemporánea Crédito), puede contracargar por código de
razón 74 opción “D”.
2.1.1.3 Aquéllas transacciones que se encuentren en el periodo de 121 a 320

días naturales pueden presentarse para su recuperación de Buena Fe,
de acuerdo a lo establecido en el Anexo 12 (Presentación de Facturación
Capítulo I
Extemporánea Crédito), con el costo de servicio establecido en el punto
“H” del capítulo IV (Costos de Servicio), no aplica para el rubro de
Devoluciones.

el Adquirente presentó a través del proceso establecido en el Anexo 12
(Presentación de Facturación Extemporánea Crédito), puede
contracargar por código de razón 74 opción “D”.
DÉBITO EN LÍNEA
Facturación Facturación
De 1 a 8 días De 9 a 30 días Extemporánea Extemporánea
(de 31 a 120 (de 121 días en
días) adelante)
Proceso Normal Aplica de Buena Fe
Forma de Proceso Normal o Anexo 13 con costo de servicio No se Acepta
Presentación ambos con costo Anexo 13
de servicio
2.1.2 Las Instituciones acuerdan recibir en el intercambio, los importes de los

Comprobantes de venta, generados por el uso de Tarjetas de Débito en
Línea, con una antigüedad no mayor a 8 días naturales, después de la fecha
de suscripción del documento.
Para el proceso de devoluciones aplica lo señalado en el Anexo 21 de este

contrato.
2.1.2.1 Aquéllas transacciones que se encuentren en el periodo de 9 a 30 días

naturalespueden presentarse para su recuperación por medio del
proceso normal de intercambio, así como por lo establecido en el Anexo
13 (Presentación de Facturación Extemporánea Débito), con el costo
de servicio establecido en el punto “H” del capítulo IV (Costos de
Servicio), no aplica para el rubro de Devoluciones.
2.1.2.2 Tratándose de transacciones de Débito en Línea presentadas en el

periodo de 9 a 30 días y en caso de que la cuenta se encuentre
cancelada, bloqueada o embargada por orden judicial, el Emisor puede
contracargar por Código de Razón 74 opción “B”, sin que el Adquirente
tenga derecho a representar a excepción de que exista devolución al
Tarjetahabiente.

una transacción que se encuentre en el periodo de 9 a 30 días y que el
Adquirente presentó a través del proceso normal de Intercambio de
Facturación, así como por lo establecido en el Anexo 13 (Presentación de
Capítulo I
Facturación Extemporánea Débito), puede contracargar por código de
razón 74 opción “D”.
2.1.2.4 Aquéllas transacciones que se encuentren en el periodo de 31 a 120

días naturales pueden presentarse para su recuperación de Buena Fe,
de acuerdo a lo establecido en el Anexo 13 (Presentación de
Facturación Extemporánea Débito), con el costo de servicio establecido
en el punto “H” del capítulo IV (Costos de Servicio), no aplica para el
rubro de Devoluciones.

el Adquirente presentó a través del proceso establecido en el Anexo 13
(Presentación de Facturación Extemporánea Débito), puede contracargar
por código de razón 74 opción “D”.
3.- SOLICITUD DE COMPROBANTES.
3.1 El Emisor puede solicitar al Adquirente a través del intercambio originales o

copias de Comprobantes y Devoluciones, mediante la referencia de 23
posiciones, cuenta e importe.
Cuando se trate de operativas que utilicen cuentas tokenizadas (MST / NFC,

etc.) el Emisor debe utilizar Invariablemente el número de cuenta tokenizado
en la solicitud de comprobantes, o al iniciar una aclaración.
Los Adquirentes se comprometen a entregar al Emisor que lo solicite

(utilizando para tal fin los archivos de intercambio) comprobantes originales
(cuando sean solicitados con el código de transacción 51. Solicitud de
Comprobante Original) o copias (cuando sean solicitados con el código de
transacción 52. Solicitud de Comprobante Copia) de Comprobantes y
Devoluciones.
El Adquirente está obligado a sellar las copias que entrega al Emisor excepto
cuando entregue la documentación a través del Intercambio de Imágenes, en
cuyo caso debe enviar en el intercambio, el resumen Hash de los documentos
enviados.
Una vez que el Adquirente procede a la entrega de un Comprobante o

Devolución solicitada por el Emisor, debe informar de dicha entrega a éste
último utilizando el código de transacción 53 (Confirmación de Atención de
Comprobante) en el archivo de intercambio.
3.2 El Emisor no está obligado a recibir el Comprobante si carece del sello original
del Adquirente o si el valor Hash del documento no coincide con el del registro
en el archivo de intercambio según corresponda, y sigue transcurriendo el
plazo de atención, para lo cual la confirmación electrónica no tiene validez,
siempre y cuando el rechazo se haga en el mismo día de la recepción, de no
Capítulo I
ser así se considera como atendido el documento y no procede contracargo
por no atención.
3.3 El Adquirente no está obligado a entregar documentación original cuando se

trate de Comprobantes por ventas telefónicas, ventas por correo, terminales
auto-atendidas (CAT), comercio electrónico seguro, Internet, cargos periódicos
(card on file) y chip más nip que se detallan para estas transacciones en el
anexo 15 (Datos Legibles y Mandatorios).
3.4 Las copias de los Comprobantes, (únicamente planchados), que los

Adquirentes envíen como respuesta a los Emisores, no deben ser inferiores al
70% de su tamaño original, por lo que en caso de no cubrir el tamaño, pueden
ser contracargados por código de razón 60, del capítulo II (Resolución de
Controversias).
3.5 Las Devoluciones aplicadas por los Adquirentes, se regulan de acuerdo a lo

que se establece en el anexo 21 (Devoluciones).
3.6 Los Adquirentes no pueden presentar como facturación nueva o

extemporánea transacciones que ya estuvieron involucradas en un proceso de
controversias y en caso de que los Emisores detecten esta anomalía pueden
someter al Árbitro Operativo dichas transacciones, independientemente del
importe, hasta en un plazo de 180 días naturales a partir de la fecha de
recepción de los Comprobantes y puede aplicar la penalización 15, de acuerdo
al capítulo V (Penas Convencionales por Incumplimiento).
La documentación probatoria para este punto es cualquiera que esté

involucrada en el proceso de controversias y que se encuentre debidamente
certificada en el presente contrato.
3.7 El Adquirente puede imprimir el nombre del Emisor de la Tarjeta en los
comprobantes POS.
3.8 Para el proceso de resolución de Controversias en el Intercambio, únicamente

se solicitan y entregan originales o copias de Comprobantes y Devoluciones,
cuya antigüedad sea menor o igual a 180 días naturales, contados a partir de
la fecha de intercambio de la transacción, y cuyo monto sea mayor a lo
establecido en el punto “A” del Capítulo IV (Costo de Servicios), de no ser así,
el Adquirente puede aplicar el cobro de la penalización 3 y/o 4 establecidas en
el capítulo V (Penas Convencionales por Incumplimiento)
Cuando el Adquirente ejerce su derecho de cobro de las penalizaciones

establecidas en el punto 3 y/o 4 del capítulo V (Penas Convencionales por
Incumplimiento) y atiende el documento, no puede cobrar el importe
correspondiente por la atención del mismo.
3.8.1 El día del intercambio de transacciones, se considera dentro del plazo

como el día (uno) para efectos de solicitud de documentos.
Capítulo I
3.8.2 El Adquirente está facultado para realizar cobro de servicios por
oportunidad en la entrega de documentos, de acuerdo a lo establecido en
el punto “B” del capítulo IV (Costo de Servicios).
3.9 Para solicitud de originales o copia de Comprobantes, el plazo de atención para

el Adquirente es hasta 30 días naturales.
3.9.1 La entrega de originales o copias de Comprobantes y Devoluciones se

puede efectuar el último día del vencimiento en horas hábiles de oficina
a más tardar a las 14:00 horas para entrega en papel o en la última
ventana establecida entre Cámaras de Compensación para el
intercambio de imágenes, previamente confirmados en el medio
magnético vigente.
Para la atención de originales o copias de Comprobantes, que su plazo

de vencimiento sea en un día inhábil y/o festivo se puede entregar al día
hábil siguiente.
3.9.2 El Emisor no está obligado a recibir comprobantes que no tengan sello o

si el valor Hash del documento no coincide con el del registro en el archivo
de intercambio según corresponda y la confirmación electrónica de
recepción no tendrá validez, continuando el tiempo de atención y en caso
de no ser atendido dentro del plazo puede ser contracargado por código
de razón 79, (copia u original del pagaré solicitado, no recibido).
Si el rechazo por falta de sello o si el valor Hash del documento no

coincide con el del registro en el archivo de intercambio según
corresponda, no se realiza el mismo día de la entrega, este no es válido
y se considera como documento entregado.
El Adquirente está obligado a dar respuesta a las solicitudes de

Comprobantes del Emisor según sea el caso con: Comprobantes,
notificación de rechazos (transacción 54) o informando las devoluciones
realizadas mediante el Anexo 19 (Listado Verificador Certificado), de
conformidad a los registros solicitados y dentro del plazo señalado en el
punto 3.9 de atención de documentos. Para éste caso el Emisor esta
obligado a recibirlo.
Cuando un Adquirente atienda (transacción 53), una solicitud de

Comprobante (transacción 51 o 52) con Log de Autorizaciones (Anexo
18), en lugar de proporcionar el Comprobante emitido por la Terminal
Punto de Venta o el Contrato de Prestación de Servicios de acuerdo a lo
señalado en el Anexo 15, el Emisor puede realizar contracargo por
Código de Razón 60 opción C y el Adquirente solo puede representar en
caso de haber procesado un abono o devolución. Lo anterior no aplica
para transacciones en las cuales se especifique que pueden ser
atendidas mediante el Log de Autorizaciones de acuerdo a lo establecido
en el Anexo 15.
Cuando el Emisor detecte ilegibilidad en el número de cuenta y/o importe

y/o número de autorización y/o firma, puede ejercer emplazamiento
arbitral sin necesidad de generar un primer contracargo, dentro de los
Capítulo I
siguientes 6 días naturales contados a partir de la fecha de recepción del
Comprobante.
El emplazamiento debe completarse con la siguiente documentación:
a) Carta del Emisor certificando haber recibido reclamación del

Tarjetahabiente o Carta reclamación del Tarjetahabiente o medio
de registro certificado.
b) Copia del comprobante con el sello original del Adquirente o
archivo intercambiado mediante le proceso de digitalización de
imágenes.
3.9.3 En caso de representación de un contracargo por código de razón 79,

enviando evidencia de un crédito con Listado Verificador Certificado
(Anexo 19); el Adquirente se hace acreedor a la penalización señalada
en el punto 9, del capítulo V (Penas Convencionales por Incumplimiento),
el cobro se efectua vía misceláneo transacción 10 código de razón 106,
(Anexo 5) incluyendo copia de la representación.
3.10 Los documentos originales o copias de Comprobantes, no entregados dentro

del plazo estipulado en el punto 3.9 del presente Capítulo, son sujetos a
contracargo por el total del importe del Comprobante.
3.10.1. Cuando el Emisor solicite comprobante original y el Adquirente

atienda copia (y no se trate de documento sustituto), el importe del
documento se puede contracargar por código de razón 79, siempre y
cuando el Emisor demuestre que fue requerido por un organismo Jurídico
vigente y/o por orden o mandato Judicial.
3.10.2. Si el Emisor solicita original del Comprobante por primera vez, no tiene
derecho a solicitar posteriormente copia del mismo documento, si el
Emisor solicita copia del Comprobante y fue atendida, puede realizar una
segunda solicitud por el original, y ésta es sujeta de contracargo conforme
al código de razón 79.
3.11 Unicamente se puede solicitar copia u original del documento una sola vez. El
Adquirente puede cobrar a la contraparte lo señalado en el punto 2 del capítulo
V, (Penas Convencionales por Incumplimiento), por solicitud de documento
duplicada, dos transacciones (51 y/o 52), proporcionando a la otra la fecha de
la primera petición.
3.12 Cuando un Emisor haya contracargado por código de razón 79, (Copia y/u
original del pagaré solicitado no recibido), no tiene derecho a un contracargo
posterior por ningún código de razón, con excepción de que el Adquirente
hubiese representado la transacción.
Si el Emisor realiza contracargo por código de razón 79, (Copia y/u original del
pagaré solicitado no recibido) sin haber efectuado solicitud de documento
Capítulo I
(transacción 51 o 52), el Adquirente tiene derecho a representar por
contracargo improcedente, el Emisor se hace acreedor a la penalización 22
del Capítulo V (Penas Convencionales por Incumplimiento), puede solicitar el
documento por buena fé y/o efectuar un segundo contracargo por cualquier
código de razón, siempre y cuando esté dentro del plazo del nuevo código con
excepción del código de razón 79.
3.13 Cuando el Emisor solicite original o copias de Comprobantes mayores a 180

días naturales y/o menores al importe señalado en el capítulo IV (Costo de
Servicios), el Adquirente no esta obligado a atender estas solicitudes y
además puede penalizar de acuerdo a lo señalado en los puntos 3 y/o 4, del
capítulo V (Penas Convencionales por Incumplimiento), por transacción fuera
de normas.
3.14 Cuando el Adquirente rechace una solicitud de documento (transacción 54)

por datos erróneos (No. de cuenta, referencia, importe) se obliga a demostrar
al Emisor con la copia del listado verificador certificado (Anexo 19), así como
por petición duplicada o extemporánea, importes menores a lo señalado en el
capítulo IV (Costo de Servicios), puede penalizar de acuerdo a lo señalado en
los puntos 1, 2, 3 y/o 4, del capítulo V, (Penas Convencionales por
Incumplimiento), por transacción, dentro de los 6 días hábiles siguientes a la
fecha de solicitud.
El plazo máximo del Adquirente para rechazar (transacción 54) por datos
erróneos, es de 5 días naturales contados a partir de la fecha de solicitud, por
lo que en caso de contracargo por código de razón 79, tiene derecho a
representar la transacción adjuntando el acuse de recibo del rechazo o el
detalle de la transacción 54.
3.15 El Emisor debe demostrar que su petición es correcta dentro de los siguientes
5 días naturales contados a partir de la fecha de la recepción del rechazo
(transacción 54), para lo cual puede efectuar el contracargo por código de
razón 79, (Copia y/o original del pagaré solicitado no recibido), dentro del plazo
original de la solicitud del comprobante, por el total del importe del
comprobante y rechazar la penalización señalada en los puntos 1, 2, 3 y/o 4,
del capítulo V (Penas Convencionales por Incumplimiento), cobrada por el
Adquirente.
Así mismo el Emisor tiene derecho a cobrar una nueva penalización de

acuerdo a lo señalado en el punto 17, del capítulo V (Penas Convencionales
por Incumplimiento), por rechazo improcedente.
3.16 Las Instituciones acuerdan que la transacción 53 Confirmación de Entrega de

documentos es obligatoria en el medio magnético vigente y debe corresponder
al número de Comprobantes, que entregue el Adquirente, si éste último
entrega documentación de más, no es válida por ningún concepto.
3.17 Cuando el comprobante proporcionado por el Adquirente en atención a una

solicitud de un documento, no reúne las características obligatorias suscritas
en el anexo 15 (Datos Legibles y Mandatorios), el documento puede ser
contracargado por el Emisor de acuerdo al código de razón 60.
Capítulo I
3.18 Cuando la copia del Comprobante que entregue el Adquirente, presenta un
planchado en otro documento, este debe contener las características de
legibilidad del pagaré manual establecidas en el anexo 15 (Datos Legibles y
Mandatorios), si esta regla no se cumple pueden ser contracargados por
código de razón 60.
3.19 Los comprobantes de venta (impresos en una TPV y/o cualquier dispositivo
punto de venta electrónico) no deben ser requisitados ni sobre-escritos,
alterando la información impresa en los campos mandatorios que se
establecen en el anexo 15 (Datos Legibles y Mandatorios), por lo que en caso
de presentarse esta anomalía pueden ser contracargados por código de razón
60.
3.20 Los comprobantes de venta impresos en TPV y/o cualquier dispositivo punto
de venta electrónico que contengan planchado de tarjeta y el número de
cuenta del comprobante de venta electrónico no corresponda al mismo de la
impresión de la tarjeta, pueden ser contracargados al Adquirente por código
de razón 80, no importando que la tarjeta planchada sea del mismo cliente.
3.21 Para las transacciones de cargos periódicos (Token Q2 subcampo 1, valor 02)
que el Emisor solicite Comprobante, el Adquirente debe enviar copia del
contrato del cargo periódico firmado por el tarjetahabiente.
3.22 Para las peticiones de Documento donde el Adquirente identifique la

transacción con Firma Digitalizada, debe atender con la impresión del
documento que invariablemente contenga en el panel de firma, firma del
tarjetahabiente incluyendo con marca de agua en el panel de firma fecha de
transacción, hora de transacción y número de autorización, establecidos en el
Anexo 15 (Datos Legibles y Mandatorios que deben Contener los Documentos
de Tarjetas).
• Los Adquirentes deben solicitar una Firma Digitalizada en cada

transacción.
3.23 En transacciones con lectura de chip EMV (PEM 05), con importe igual o
menor a lo señalado en el punto “A” del Capítulo IV (Costo de Servicios) o
Contactless EMV (PEM 07), con importe igual o menor al CVM Limit descrito
en el punto 4 y detallado en la tabla del punto 5 del Capítulo XXVIIaplica lo
siguiente:
• No es obligatoria la impresión del comprobante por parte del Receptor
de Pagos.
• En caso de imprimir el comprobante, no es obligatorio recabar la firma
del tarjetahabiente.
• En los procesos de resolución de controversias donde el Adquirente
requiera proporcionar el comprobante de la transacción, puede
documentarlo con el Log de Autorizaciones Certificado (Anexo 18).
Lo anterior, no aplica para los Receptores de Pagos de los siguientes giros:

• 5542 Gasolineras
• 5965 Venta por Catalogo
Capítulo I
• 5969 Venta Directa
• 6012 Servicios Financieros
• 7995 Apuestas Casinos Lotería
• 9401 Gobierno
Por lo que, en transacciones realizadas en estos giros si se debe imprimir el

comprobante y recabar la firma respectiva (Autógrafa o electrónica).
3.24 En transacciones con lectura de chip EMV (PEM 05) + NIP, las solicitudes de
comprobante se atienden con el log de autorizaciones certificado (Anexo 18).
4.- CONTRACARGOS Y REPRESENTACIONES
I) El Emisor.
El Emisor debe postear las transacciones, si por alguna causa requiere

generar un primer contracargo debe cumplir con la documentación y tiempos
que se requieren de acuerdo al código de razón utilizado, por lo que el Emisor:
a) Debe evitar acreditar dos veces a la tarjeta el importe de una misma

transacción.
b) En caso de que una transacción se aplique a la tarjeta y el Emisor genera

un primer contracargo debe acreditar el importe de la controversia a la
tarjeta a más tardar al término del ciclo de controversias.
II) El Adquirente:
Debe evitar enviar transacciones 96 o 21 (devoluciones) a Tarjetas cuyos

montos ya fueron contracargados por el Emisor duplicando de esta manera la
corrección a la tarjeta.
Debe enviar correctamente los indicadores señalados en el Anexo 4I, para
cada una de sus transacciones.
4.1 Para el trámite de resolución de controversias, los plazos son considerados a

partir de la fecha del intercambio.
4.1.1 Los Emisores tienen el derecho a contracargar transacciones del

intercambio Nacional por alguna de las siguientes causas:
a) Reclamación de sus tarjetahabientes.
b) Registros rechazados por computador.
c) Problemas de fraude.
En el caso del inciso a) y c), los Emisores no pueden ejercer su derecho

de contracargo sin contar con la carta reclamación de su tarjetahabiente o
medio de registro certificado Anexo 30, aún cuando el código de razón de
Capítulo I
contracargo no requiera que se envíe, de acuerdo al Capítulo II
(Resolución de Controversias).
El Emisor es la única entidad autorizada a recibir y gestionar las

aclaraciones de sus Tarjetahabientes. (Reglas Operativas)
4.1.2 Para los contracargos y representaciones que su plazo de vencimiento

sea en un día inhábil y/o festivo, se puede intercambiar al día hábil
siguiente, con la documentación de apoyo correspondiente.
4.1.3 El Emisor asume la responsabilidad en caso de falsificación, alteración,

modificación; derivada del mal uso que pudiera hacerse de sus Tarjetas,
siempre y cuando los Receptores de Pagos se apeguen a las normas
establecidas en el Capítulo VI (Políticas y Mecanismos de Seguridad con
los Receptores de Pagos Afiliados).
4.2 Los contracargos y representaciones deben presentarse en el intercambio a

través del medio electrónico vigente según lo especificado en el Convenio
Operativo para el Intercambio entre Cámaras para Pagos con Tarjetas.
4.3 El Emisor y el Adquirente, deben enviar por cada contracargo y/o

representación, el formulario anexo 8 (Exhibit) por cada transacción
acompañado de la documentación de apoyo correspondiente, especificando
un sólo código de razón y opción, por lo cual el código y opción del exhibit,
deben coincidir con la información electrónica o el procedimiento de
Digitalización de Imágenes.
Los casos deben tener código de razón y opción en el anexo 8 (Exhibit), ya

sea para el primer o segundo contracargo por parte del Emisor y para la
representación por parte del Adquirente, si esta regla no se cumple, se puede
enviar a arbitraje operativo, aun cuando no haya cumplido el ciclo de
contracargos descrito en el punto 8.2.1.
En caso de no coincidir la información electrónica con la información en papel,

se tomará como valida esta última.
4.3.1 Para los contracargos y/o representaciones generados por los códigos de
razón 72, 77, 82 y 93 por rechazo de computador, 57, 63 y 79 por
reclamación del tarjetahabiente, señalados en el capítulo ll (Resolución
de Controversias), solo si los contracargos se operan fuera del proceso
de Digitalización de Imágenes, se pueden enviar las transacciones en un
sólo formulario anexo 8 (exhibit) global, anexando el detalle de cada
registro (No. de cuenta, referencia de 23 posiciones e importe).
4.3.2 Cuando se vaya a llevar a cabo una representación y/o un segundo

contracargo por código de razón 72, 77, 82 y 93 por rechazo de
computador, 57, 63 y 79 por reclamación del tarjetahabiente, se debe
respetar el exhibit global original, sin incorporar partidas de otro exhibit
global, ajeno al de origen, de lo contrario será motivo de rechazo, y
seguirá corriendo el plazo establecido del contracargo o representación
inicial.
Capítulo I
Para los contracargos efectuados por Código de Razón 57 y 63, en Anexo 8
(exhibit) global, son aceptados siempre y cuando se trate del mismo número
de cuenta.
4.4 Cuando el Emisor contracargue una transacción y ésta no pueda ser localizada
por causas imputables al mismo, se le sanciona de acuerdo al punto 13 del
capítulo V (Penas Convencionales por Incumplimiento), proporcionando
listado verificador certificado, conforme al anexo 19.
Cuando el Adquirente represente una transacción y esta no pueda ser

localizada por causas imputables al mismo, se sanciona de acuerdo al punto
14, del capítulo V (Penas Convencionales por Incumplimiento),
proporcionando listado verificador certificado, conforme al anexo 19.
4.5 El Emisor tiene derecho a ejercer dos contracargos, el Adquirente tiene derecho
a una representación y cuaquiera de estos puede solicitar un arbitraje
operativo cumpliendo con lo estipulado en el punto 8.2 del presente Capítulo.
4.6 Para efectos de un segundo contracargo, con diferente código de razón del
primer contracargo, son válidos siempre y cuando estén dentro del plazo, del
nuevo código de razón, a excepción de lo detallado en condiciones del código
de razón (60), (68), (71 opción “A”), (79) en condiciones del código de razón
punto 3, (80) y (82 opción “G”) en condiciones del código de razón punto 1.
4.7 El día del intercambio se considera dentro del plazo, como el día uno para todos
los procesos y productos del intercambio.
4.8 Para realizar un proceso de resolucion de controversias, los participantes no

deben solicitar copia de anverso y reverso de la tarjeta.
4.9 El plazo máximo para la presentación de los segundos contracargos es de 30

días naturales, contados a partir de la fecha de intercambio de la
representación, a excepción de lo establecido en el punto 4.6 y lo detallado en
condiciones del código de razón (60), (68), (71 opción “A”), (79) en condiciones
del código de razón punto 3, (80) y (82 opción “G”) en condiciones del código
de razón punto 1.
4.10 En los casos que el Emisor efectúe contracargos y de acuerdo al código de

razón utilizado se requiera de la copia del Comprobante enviado por el
Adquirente, el Emisor, invariablemente debe anexar el comprobante sellado
que entregó el Adquirente.
4.11 Cuando el Adquirente realice una representación por documentación de

apoyo faltante, esta obligado a detallar la misma en el anexo 8 (Exhibit).
4.12 Los contracargos que en su documentación de apoyo soliciten copia de estado

de cuenta, se puede anexar estado de cuenta electrónico certificado de
acuerdo al anexo 20.
4.13 Para efectos del primer y segundo contracargo por parte del Emisor y
representación por parte del Adquirente que su documentación de apoyo o
evidencia de listados verificadores anexo 19 y log de autorización anexo 18,
sean documentos mandatorios, deben ser los certificados ante el Árbitro
Operativo.
Capítulo I
4.14 Para los contracargos en que se requiera como documentación de apoyo la
carta reclamación del Tarjetahabiente, el Emisor puede enviar una carta
certificando la reclamación del Tarjetahabiente siempre y cuando en la
documentación de apoyo del código de razón y opción así lo establezca, la
cual debe contener:
• Leyenda: “Emisor”, con esta carta certifica haber recibido solicitud de

aclaración.
• Folio de Aclaración
• Nombre del Tarjetahabiente
• Número de Tarjeta
• Fecha Reclamación del Tarjetahabiente
• Fecha de Transacción
• Importe de la Transacción
• Descripción de la reclamación de la transacción
• Sello del Emisor
• Referencia de 23 posiciones
En los casos que se envíe la carta de reclamación del Tarjetahabiente, ésta

debe contener fecha de la reclamación, número de cuenta, motivo de la
reclamación, descripción de transacciones (fecha, Receptor de Pagos e
importe), nombre y firma del mismo.
El emisor no puede complementar, agregar y/o modificar el contenido de la

carta reclamación del tarjetahabiente, si esta situación es detectada, la carta
reclamación no tiene validéz en el proceso para el cual sea utilizada.
Así mismo, se establece que cuando un Adquirente considere que durante un

proceso de controversia un Emisor no recibió reclamación del Tarjetahabiente, el
Adquirente puede solicitar un proceso de validación de carta reclamación ante el
Árbitro Operativo de acuerdo a lo señalado en el Capítulo XIII (Validación de
Reclamación de un Tarjetahabiente).
En caso de que el resultado de la revisión realizada por el Arbitro Operativo

determine que es Satisfactoria, el Adquirente cubrirá el costo de los honorarios
vigentes con el Arbitro Operativo.
En caso de que el resultado de la revisión realizada por el Arbitro Operativo

determine que es No Satisfactoria, el Emisor se hace acreedor a lo señalado en
punto 4 del Capitulo XIII (Validación de Reclamación de un Tarjetahabiente), más
los honorarios vigentes con el Arbitro Operativo.
4.15 Un Emisor puede iniciar un ciclo de controversia por transacciones recibidas,

por importes menores a lo establecido en el punto “A” del Capítulo IV (Costo
de Servicios), siempre que exista reclamación del Tarjetahabiente.
No es necesario anexar copia de los Comprobantes en poder del Adquirente.
En caso de representación el Adquirente debe anexar copia del comprobante

de venta en transacciones con PEM 01 y 90 y Log de Autorizaciones
Capítulo I
Certificado (Anexo 18) en transacciones con PEM 05 y 07 y le cobra al Emisor
como documento atendido.
En caso de que el comprobante presentado por el Adquirente en la

representación sea ilegible o con datos incompletos, el Emisor puede generar
un segundo Contracargo por código de razón 60 (Opción A o B), en un plazo
no mayor a treinta días naturales de haber recibido la representación por parte
del Adquirente.
El cobro de la atención de documentos enviados en la representación será a

través de misceláneo transacción 10 código de razón 112, conforme a la fecha
de representación y en base a lo establecido en el punto B del Capítulo IV
(Costos de Servicios).
4.16 El único documento válido para demostrar la aplicación de una devolución o

el procesamiento de un abono a una tarjeta es el Listado Verificador Certificado
del intercambio entre Emisores/Adquirentes de acuerdo al anexo 19.
4.17 En caso de que el Emisor o el Adquirente violen alguna de las reglas del
presente contrato y no exista código de Razón para poder contracargar o
representar, cualquiera de las Instituciones puede iniciar un proceso de
precumplimiento, el cual debe ser resuelto en un plazo máximo de 10 días
naturales después que la parte afectada informe a su contraparte de la
afectación obteniendo acuse de recibo, en caso contrario podrá someter a un
emplazamiento arbitral.
4.18 Cuando un Emisor contracargue y realice petición de documento de una

misma transacción, o realice petición de documento y contracargue, dentro del
plazo de atención de cualquiera de estas, invariablemente el Adquirente puede
rechazar la solicitud de documento y penalizar de acuerdo al punto 22, del
capítulo V (Penas Convencionales por Incumplimiento).
4.19 Cuando se inicie un Ciclo de Controversias (Primer Contracargo) sin la

documentación soporte mandatoria, incorrecta o incompleta para cada opción,
así como fuera de los plazos establecidos en el Capítulo II (Resolución de
Controversias), el Emisor no tiene derecho a realizar un Segundo contracargo,
cuando el Adquirente represente por Contracargo extemporáneo o por
documentación de apoyo faltante, incorrecta o incompleta.
4.20 Sólo en los casos de controversia que para su resolución requieran de

validación del modo de entrada (PEM) y exista diferencia entre los log´s de las
Instituciones, el log de autorización que tiene validez, es el del Emisor, siempre
y cuando la autorización no se haya otorgado por Stand In.
4.21 Las transacciones realizadas por Internet que no cuenten con valor “ECI” 5 ó
6, son responsabilidad del Adquirente de acuerdo a lo señalado en el punto 4
del capítulo XI (Comercio Electrónico).
Capítulo I
4.22 En las transacciones realizadas mediante dispositivos móviles, el emisor solo
puede iniciar un ciclo de controversias por transacciones duplicadas, múltiples,
comprobantes no atendidos y devoluciones no aplicadas.
4.23 Con objeto de reforzar la adopción en el mercado local de transacciones

contactless (NFC) o inducción de banda magnética (MST), en un proceso de
aclaracion el emisor debe cumplir lo siguiente:
1. Cuando el Emisor utilice tokenización en sus transacciones,

invariablemente debe utilizar el número de cuenta tokenizado (LOG de
autorizaciones, exhibit, etc).
2. La documentación técnica debe cumplir los siguientes valores:
PEM C4 s12 Q2 Responsabilidad

MST Tarjeta 90 0, 1, 5 03, 04, 17 Emisor
NFC Presente 07 0, 5, 6, 7 03, 04, 17, 19 Emisor
Cuando un tercero realiza el proceso de tokenización a nombre del emisor, este

debe indicarle el resultado de la validación del criptograma ARQC en el valor:
DE 63 Token B4 subcampo 8
Cuando se trate de transacciones de tarjeta no presente tokenizadas por una

solución Adquirente, invariablemente se deben intercambiar con el número de
cuenta real.
1. La documentación técnica debe cumplir los siguientes valores:
PEM Q2 Responsabilidad
Comercio Electrónico 01 09 De acuerdo a valores ECI
Mo To 01 08 De acuerdo a valores ECI

Tarjeta
no
Presente De acuerdo con el Capítulo II, Código de Razón
Cargo Periódico 01 02
41.
De acuerdo con el medio de acceso:

Card on File 10 09, 02 Q2 = 09 - Valores ECI
Q2 = 02 - Código de Razón 41
4.24 En transacciones con medio de acceso Q2 Valor 00, 01 o 18 se les dará el

tratamiento de transacciones de comercio electrónico (Q2 valor 09).
Capítulo I
5.- AUTORIZACIONES
5.1 Es responsabilidad del Emisor el otorgar o no la autorización,

independientemente del medio de acceso que la solicite.
Las transacciones de Pago de Tarjetas en el Intercambio y Devoluciones, no

requieren autorización del Emisor.
5.1.1 Cuando un Tarjetahabiente realice una transacción y el Receptor de Pagos

solicite una autorización y no presenta la facturación dentro de los días
naturales que establece el presente contrato (punto 2.1), no debe solicitar
otra autorización para la misma transacción con el único fin de evitar la
recuperación a través del archivo especial de facturación extemporánea
(en caso de que se detecte esta practica se considera como un
incumplimiento y se puede presentar un arbitraje directo).
5.2 El Emisor asume la responsabilidad de las autorizaciones otorgadas con

código Modo de entrada (02) sin derecho a contracargo excepto que los
Receptores de Pagos Afiliados no se apeguen a las normas establecidas en
el Contrato de afiliación y en lo respectivo al capítulo VI (Políticas y
Mecanismos de Seguridad con los Receptores de Pagos Afiliados), en cuyo
caso se aplicarán cualquiera de los códigos de razón establecidos en el
capítulo II (Resolución de Controversias).
5.3 Se puede efectuar el cobro al Emisor de la solicitudes de Autorización de

transacciones de débito en Interredes, sin importar si éstas son exitosas o no,
por cada día natural, de acuerdo al punto “C” del capítulo IV (Costo de
Servicios).
5.3.1 El cobro de autorización se debe efectuar mediante misceláneo 103,

dentro de los 10 días hábiles siguientes a la fecha de su otorgamiento, de
no ser así se pierde este derecho.
5.3.2 El cobro de las autorizaciones se debe efectuar por BIN Emisor según
anexo 1 (Relación de BINES Sujetos al Intercambio Doméstico).
5.3.3 En caso de aclaraciones por diferencias en cobros de Autorizaciones el

Emisor puede solicitar al Adquirente el detalle por BIN Emisor de las
autorizaciones, mismo que debe ser entregado dentro de los 2 días
hábiles siguientes de la fecha de petición.
Capítulo I
5.3.4 La liquidación del cobro de servicios se debe incluir en el intercambio
diario.
5.3.5 Se emitirán facturas por parte del Adquirente de acuerdo a las

disposiciones fiscales vigentes.
5.3.6 El Emisor puede presentar inconformidad sobre el importe cobrado en un

plazo máximo de 5 días hábiles contados a partir de la fecha en que se
reciba la información, en caso contrario se pierde ese derecho.
5.3.7 El Adquirente tiene 5 días hábiles como máximo contados a partir de la

inconformidad por parte del Emisor para objetar la controversia.
5.3.8 El Emisor cuenta con la facultad de cargar el importe reclamado en caso

de no haber recibido comentario alguno.
5.3.9 Cuando la TPV y/o cualquier dispositivo punto de venta electrónico de un

Receptor de Pagos se encuentre desconfigurado en la fecha y la hora con
respecto a los datos registrados en el log de autorizaciones de los
sistemas y esta situación sea determinante para deslindar la
responsabilidad financiera, el Emisor puede recuperar el importe de la
transacción a través del proceso de controversias, siempre y cuando
haya rebasado 5 horas entre la autorización y la emisión del
Comprobante.
Es importante mencionar que el Emisor únicamente puede hacer uso de

esta regla siempre y cuando demuestre la pérdida financiera derivada de
no poder demostrar a su cliente que la transacción fue hecha antes del
reporte de robo y/o extravío.
Cuando por la desprogramación del dispositivo se genere un cobro de

servicios con relación a la presentación de la facturación, el Adquirente
puede recuperar el cobro mediante misceláneo 102, enviando como
documento soporte el log de autorizaciones durante los 5 días hábiles
después del cobro del Emisor.
5.3.10 Los Adquirentes no deben presentar en el intercambio las transacciones

que inicialmente solicitaron la autorización en línea y de las cuales
procesa un reverso de autorización el mismo día, si la transacción se
hubiera completado con el cliente, el Receptor de Pagos tiene la
obligación de procesar una devolución de mercancía.
5.4 Los participantes pueden determinar Límites de Piso para las autorizaciones,
los cuales se rigen de acuerdo al anexo 16, (Límites de Piso de
Autorizaciones), así mismo la entidad que lo determine, es la responsable de
la transacción.
6.- VALIDACIONES
6.1 Las Instituciones a través de sus Cámaras de Compensación deben validar la

información recibida vía transferencia electrónica previo al intercambio de la
transacción.
Capítulo I
Las transacciones que no cumplan con los formatos y/o lay outs establecidos,
se deben rechazar a la Institución que las genera por parte su Cámara de
Compensación de acuerdo a lo señalado en el Capítulo III (Validaciones) y a
lo establecido en el Documento de Condiciones para el Intercambio entre
Cámaras de Compensación para Pagos con Tarjeta.
7.- PENAS CONVENCIONALES POR INCUMPLIMIENTO
7.1 Los Participantes pueden efectuar el cobro de penalizaciones conforme a lo

señalado en el Capítulo V (Penas Convencionales por Incumplimiento), las
cuales invariablemente deben ser enviadas diariamente en el intercambio
Nacional a través del medio magnético vigente, vía misceláneo, transacción
10 código de razón 106 de acuerdo al Anexo 5 (Detalle de Misceláneos).
El plazo máximo para poder ejercer el derecho de cobrar una penalización es

de 6 días hábiles a partir del día siguiente hábil del evento que le de origen,
cualquier penalización que rebase el plazo puede ser devuelta por la parte
afectada en un plazo no mayor de 6 días hábiles.
7.2 Cualquier penalización debe estar documentada, en caso contrario la parte

afectada con el cargo puede solicitar dentro de los primeros 6 días hábiles de
haber recibido el misceláneo, los antecedentes.
La contraparte cuenta con un plazo de 6 días hábiles para documentar el caso,

de lo contrario este cobro no tiene validez y puede ser regresado anexando
copia del requerimiento de documentación sin que exista posibilidad de
recuperación.
7.3 Las Instituciones acuerdan que para el cobro de penalizaciones, que su plazo
de vencimiento sea en un día inhábil y/o festivo se puede efectuar el cobro al
día hábil siguiente.
7.4 Las Instituciones acuerdan que todos los cobros de penalizaciones estipulados
en este manual operativo, deben ser intercambiados con su respectivo
Impuesto al Valor Agregado (I.V.A) y/o cualquier otro que lo sustituya o
complemente. a través del misceláneo correspondiente a cada caso.
8.- ARBITRAJE OPERATIVO
8.1 REGLAS
8.1.1 Se puede someter al arbitraje aquéllos casos que no se hayan resuelto

satisfactoriamente, una vez agotadas las reglas y políticas enmarcadas
en este Manual Operativo.
8.1.2 El Dictamen emitido por el Árbitro Operativo a favor o en contra es apelable

una sola ocasión, no importando el monto de la transacción.
La apelación debe presentarse al Árbitro Operativo, mediante un escrito

libre firmado por el funcionario correspondiente, facultado en el anexo 11
(Funcionarios Facultados Para Sometimiento Arbitral), conteniendo como
mínimo: folio de emplazamiento asignado por el árbitro operativo, fecha
de dictamen del emplazamiento, descripción y causa de la apelación, así
Capítulo I
mismo debe anexar únicamente la documentación original utilizada para
el análisis y definición del caso.
8.1.3 El plazo máximo para la apelación es de 5 días hábiles, a partir del día
hábil siguiente de haber recibido el Dictamen.
8.1.4 El resultado de la apelación por parte del Árbitro Operativo es notificado

por escrito dentro de los 5 días hábiles, a partir del día hábil siguiente de
la fecha de recepción de la apelación.
8.1.5 La apelación que proceda, queda exenta para los involucrados, del cobro
de los honorarios vigentes por concepto de arbitraje.
8.1.6 Para someter un caso a arbitraje deben cumplir alguna de las premisas
mencionadas en el punto 8.2 del presente Capítulo.
8.1.7 Cualquier caso emplazado puede ser retirado previa autorización por
escrito para el Árbitro Operativo, firmado por la Institución que solicita el
retiro o utilizando la opción de retiro desde la plataforma de arbitraje sin
papel, en un plazo no mayor a los 2 días hábiles siguientes a la fecha en
que el emplazamiento fue notificado por el Árbitro Operativo dentro del
horario de 9:00 a 17:00 hrs.
8.1.8 Las Instituciones acuerdan someter a arbitraje aquellos casos donde

existan cobros o pagos por misceláneos improcedentes.
8.1.9 El Árbitro Operativo está obligado a dar su dictamen a partir del tercer
día hábil siguiente de la notificación del emplazamiento.
8.2 PROCEDIMIENTOS PARA RESOLUCIÓN DE CONTROVERSIAS
8.2.1 Los casos que sean sometidos a arbitraje deben cumplir invariablemente
el ciclo de: Primer contracargo y segundo contracargo por parte del
Emisor, ambos contracargos debieron haberse efectuado al mismo
Adquirente, primera y única representación por parte del Adquirente, a
excepción del contracargo por código 60, y lo detallado en el párrafo
tercero del punto 8.2.3, párrafo cuarto del punto 3.9.2, párrafo segundo
del punto 4.3.
8.2.2 En los casos que el Emisor reciba una segunda representación por parte
del Adquirente, tiene el derecho de someter el arbitraje.
8.2.3 El Adquirente tiene el derecho de sometimiento arbitral por haber recibido

un segundo contracargo fuera de normas: datos erróneos,
documentación de apoyo no recibida o incompleta, primero o segundo
contracargo extemporáneo, contracargos duplicados o aquéllos
estipulados en cualquier apartado y/o capítulo detallado en este Manual
Operativo.
Los contracargos y representaciones duplicadas que presente cualquier

Participante en redes de Medios de Disposición, son sujetos a
emplazamiento arbitral, aun cuando éstos no hayan cubierto el ciclo de
contracargos descrito en el punto 8.2.1, así mismo el sistema que lo
realice se hará acreedor a la penalización señalada en el punto 5, del
Capítulo I
capítulo V (Penas Convencionales por Incumplimiento); el contracargo
duplicado debe contener las siguientes características: misma cuenta,
misma referencia de 23 posiciones, mismo importe y que en el anexo 8
(Exhibit), indique el mismo concepto (código de uso) primer o segundo
contracargo, o representación, en ausencia de lo anterior se debe
presentar al Árbitro Operativo el registro electrónico que muestre la
duplicidad, aun cuando no exista documentación de apoyo de alguno de
los registros, siempre y cuando el Adquirente o Emisor se vean afectados
por los costos financieros.
8.2.4 El plazo máximo para sometimiento arbitral es de 30 días naturales,

contados a partir de la fecha de presentación del contracargo,
representación y/o misceláneo que de origen al mismo, dentro del horario
de 9:00 a 17:00 hrs.
El período del 22 de diciembre al 3 de enero se considera inhábil para

cualquier proceso relacionado con el arbitraje (recepción, aceptación,
declinación, dictamen, etc), por lo que estos días no se consideran para
el conteo de los plazos.
8.2.5 Se considera un misceláneo improcedente aquél que:

• No cuente con carta de aceptación de la institución que está
recibiendo el cargo.
• No cuente con los antecedentes necesarios para su validación.
• No se haya recibido la información electrónica en el intercambio.
• No corresponda a la institución que esta recibiendo el cargo.
Por lo que cualquier sistema puede realizar la recuperación de un misceláneo

improcedente de acuerdo a lo siguiente:
• La parte afectada debe enviar un escrito de pre-arbitraje como intento

de recuperación del importe en disputa dentro de un plazo no mayor
a 10 días naturales contados a partir de la fecha del intercambio del
misceláneo en disputa.
• La parte que reciba el pre-arbitraje queda obligada a dar respuesta en

un plazo no mayor a 10 días naturales contados a partir del acuse de
recibo del pre-arbitraje.
• En caso de no recibir respuesta en este plazo, o que persista la

controversia el caso puede ser emplazado al Árbitro Operativo.
• El plazo máximo para poder ejercer el derecho de emplazar un caso

al Árbitro Operativo es de 30 días naturales contados a partir de la
fecha de intercambio del misceláneo en disputa presentando la
documentación o reportes de apoyo que apliquen.
8.2.6 En caso de que el Emisor reciba representación con Comprobante(s) o

devoluciones, con sello de una entidad no autorizada, podrá ejercer el
Capítulo I
derecho de enviar a arbitraje sin que tenga que cumplir el ciclo de
contracargos mencionado en el punto 8.2.1 de este capítulo.
8.3 DOCUMENTACIÓN REQUERIDA PARA SOMETIMIENTO
8.3.1 Los Participantes deben presentar el sometimiento en el formato contenido

en el anexo 10 Emplazamiento Arbitral, el cual invariablemente debe ir
debidamente requisitado y firmado por cualquiera de los funcionarios
facultados ante el Árbitro Operativo, detallados en el anexo 11 o ingresar
su solicitud de arbitraje con la documentación intercambiada a través del
proceso de intercambio de imágenes mediante la plataforma de arbitraje
sin papel proporcionada por el Árbitro Operativo.
Las Empresas Especializadas / Cámaras de Compensación deben dar

acceso al árbitro operativo, para que pueda consultar la totalidad de
transacciones que estén involucradas en un proceso de arbitraje.
Cuando el árbitro operativo no cuente con acceso a la información

relacionada con un caso de arbitraje, su dictamen estará basado en la
información disponible y no se admite apelación.
8.3.2 La carta de sometimiento invariablemente debe ir acompañada de la

documentación original Intercambiada o de los archivos intercambiados
mediante el proceso de intercambio de imágenes, en el proceso de
controversias: de los anexos 8 (Exhibit´s) correspondientes a los
contracargos y representaciones, antecedentes de la solicitud de
Comprobantes en el caso de aplicar, y listado verificador certificado
según anexo 19 cuando el motivo del emplazamiento sea por
presentación extemporánea, así como la documentación de apoyo que
permita al Adquirente objetar un segundo contracargo, únicamente
cuando exista cambio de código de razón, a excepción de los códigos de
razón (60), (68), (71 opción “A”), (79) en condiciones del código de razón
punto 3, (80) y (82 opción “G”) en condiciones del código de razón punto
1 y cuando haya existido gestión de recuperación por escrito entre las
Instituciones, para este último caso exclusivamente el Árbitro Operativo
debe notificar a la contraparte, quien tiene máximo 2 días hábiles para
remitir la información con que cuente y notificación con acuse de recibo.
8.3.3 La Institución que someta un caso por cobro o pago de misceláneo

improcedente debe cumplir con lo señalado en la cláusula 8.2.5 presentar
la documentación y requisitar los formatos de sometimiento arbitral
establecidos en este Manual Operativo.
8.4 RESPONSABILIDADES DEL ÁRBITRO OPERATIVO
8.4.1 El Árbitro Operativo está obligado a dar una respuesta de aceptación o

declinación de los casos en 2 días hábiles, a partir de su presentación y
dentro del horario de 9:00 a 17:00 hrs., excepto para los casos
relacionados en el punto 8.3.2, cuando se emplacen más de cincuenta
Capítulo I
casos por una o más instituciones en un solo día o cuando se presente
una contingencia (Terremotos, Incendios Inundaciones, manifestaciones,
etc.), para los cuales cuenta con 5 días hábiles para su aceptación o
declinación.
8.4.2 El Árbitro Operativo se obliga a declinar las solicitudes de sometimiento

por los siguientes motivos:
• Documentación ilegible o faltante (siempre y cuando la causa de

sometimiento no sea el motivo que dio origen a la transacción en
disputa).
• Los eventos descritos en la carta de emplazamiento no coinciden con

la documentación de apoyo.
• El Anexo 10 (Emplazamiento Arbitral), fue presentado sin cumplir con

lo estipulado en alguno de los puntos 8.2.4, 8.3.1 y/o 8.3.2 del
presente Manual Operativo.
• El resúmen hash del archivo enviado en la plataforma de arbitraje sin

papel, no coincide con los registros de intercambio en las cámaras de
compensación.
• No adjuntar el Anexo 18 (Log de Autorizaciones Certificado) cuando

se trate de emplazamiento por Código de Razón 68.
• La transacción ya fue emplazada anteriormente, duplicando el

proceso de arbitraje.
• El costo por declinación se establece en el punto O del Capítulo IV

(Costos de Servicios).
8.4.3 El Participante que reciba la declinación del sometimiento, tiene el

derecho de someter nuevamente el caso con la información faltante;
siempre y cuando no exceda los 30 días naturales, enunciados en el
punto 8.2.4.
8.4.4 En caso de que el Árbitro Operativo no acepte un caso que conforme a

este reglamento si proceda y derivado de esto el plazo de presentación
se hubiere vencido, sólo en éstos casos se puede emplazar dentro de los
3 días hábiles siguientes a la fecha de su vencimiento, quedando exento
para ambas Instituciones del cobro de los honorarios vigentes por
concepto de arbitraje.
8.4.5 En los casos de solicitudes de sometimiento arbitral aceptadas, el Árbitro

Operativo tiene como máximo 5 días hábiles a partir del día siguiente hábil
de su aceptación, para emitir su Dictamen, excepto cuando se emplacen
más de cincuenta casos por una o más instituciones en un solo día o
cuando se presente una contingencia (Terremotos, Incendios
Inundaciones, manifestaciones, etc.), para los cuales contará con 3 días
hábiles más, o cuando se trate de arbitraje por diferencia de valores de
autenticación, para lo cual el Arbitro Operativo cuenta con 5 días hábiles
Capítulo I
a partir de la recepción del Anexo 32 (Reporte de Valores de
Autenticación) por parte del Adquirente.
8.4.6 Cuando el Árbitro Operativo reciba una solicitud de arbitraje por

documentación de apoyo no recibida o incompleta, el Adquirente, debe
anexar la notificación por escrito enviada al Emisor con acuse de recibo
de acuerdo al punto 8.2.3 párrafo segundo del presente Manual
Operativo.
8.4.7 Al realizar un retiro de emplazamiento con la conformidad de los

Participantes, el Árbitro Operativo determina la responsabilidad financiera
conforme a lo detallado en el punto 8.5.6.
8.4.8 Cuando el Árbitro Operativo requiera información adicional que ayude a

determinar la responsabilidad de una transacción, puede solicitarla al
Adquirente, Emisor, Cámaras de Compensación y/o Empresa
Especializada, para lo cual debe notificar su requerimiento vía correo
electrónico y el responsable de entregar la información cuenta con 5 días
hábiles para entregar la información solicitada, de lo contrario se
procederá a emitir el dictamen con la información disponible.
La emisión del dictamen queda suspendida hasta recibir la información

solicitada o al vencimiento del plazo para su entrega, por lo que el
dictamen será emitido a más tardar 3 días hábiles después de haber
recibido la información o del vencimiento del plazo.
8.5 RESPONSABILIDAD FINANCIERA
8.5.1 Cuando un Participante reciba el Dictamen en contra y no tenga el cargo de

la partida en disputa, debe cubrir financieramente lo siguiente:
• El monto de la partida en disputa.

• Intereses moratorios de acuerdo al calculo siguiente:
días importe en
calendario x (T.I.I.E. x 2.5 ) x disputa
360
Los días calendarios son a partir del contracargo o representación del

importe en disputa.
• Penalización por emplazamiento, de acuerdo al punto 18, del capítulo V

(Penas Convencionales por Incumplimiento).
• Honorarios vigentes con el Árbitro Operativo, de acuerdo al punto M del

Capítulo IV (Costos de Servicios).
8.5.2 Cuando un Participante reciba el Dictamen en contra y tenga el cargo de la

partida en disputa, debe cubrir financieramente lo siguiente:
Capítulo I
• Penalización por emplazamiento, de acuerdo al punto 18, del capítulo V
(Penas Convencionales por Incumplimiento).
• Honorarios vigentes con el Árbitro Operativo, de acuerdo al punto M del

Capítulo IV (Costos de Servicios).
8.5.3 El Participante que reciba el Dictamen a favor tiene derecho a cobrar el

monto de la partida en disputa, los intereses moratorios respectivos a partir
de la presentación del segundo contracargo o segunda representación al
día del Dictamen y la penalización por emplazamiento, de acuerdo al punto
18, del capítulo V (Penas Convencionales por Incumplimiento).
8.5.4 El Participante que recibe el Dictamen a su favor y no tenga registrada la

partida en disputa recibe un abono por el monto de la penalización, por
emplazamiento, de acuerdo al punto 18, del capítulo V (Penas
Convencionales por Incumplimiento).
8.5.5 El cobro de los importes detallados en el punto 8.5 del presente Manual
Operativo, se efectuan vía transferencia electrónica (misceláneo
transacción 10 código de razón 110, de no ser así se rechaza y sigue
corriendo su plazo de presentación) en un plazo no mayor a 6 días hábiles
a partir de la fecha de recepción del Dictamen a favor, en caso de
incumplimiento pierde el derecho del cobro.
8.5.6 El Participante que solicite el retiro de emplazamiento debe pagar a la

contraparte el importe en disputa, la penalización por retiro de
Convencionales por Incumplimiento), más los honorarios correspondientes
por retiro vigentes con el Árbitro Operativo designado por las Instituciones,
de acuerdo al punto N del Capítulo IV (Costos de Servicios).
8.5.7 La responsabilidad financiera del Participante que resulte con el Dictamen

en contra por el cobro o pago de misceláneos improcedentes, es por el
importe del cargo de la partida en disputa, más la penalización por
Convencionales por Incumplimiento), intereses moratorios de acuerdo al
punto 8.5.1 de este capítulo, más los honorarios correspondientes vigentes
con el Árbitro Operativo designado por las Instituciones, de acuerdo al
punto M del Capítulo IV (Costos de Servicios).
9. GESTION DE RECUPERACIÓN DE BUENA FE
9.1 Si un Participante registra una pérdida financiera derivada de una

transacción en controversia, puede intentar gestionarla por la vía de
recuperación de Buena Fe.
El Participante que objeta la transacción en controversia, procede a enviar

a su contraparte la documentación que soporte su disputa, mediante el
anexo 23, mismo que debe ser dirigido y solicitado por alguno de los
Capítulo I
funcionarios facultados en el anexo 11A (Funcionarios Facultados para
Gestión de Recuperación de Buena Fe), del presente Manual Operativo.
9.2 En caso de aceptación de la contraparte, cuando se trate de afectaciones

financieras, el cargo debe ser presentado en el Intercambio Doméstico a
través de misceláneo, transacción 10 código de razón 112, dentro de los
siguientes 6 días hábiles, contados a partir de la fecha de aceptación del
caso, de lo contrario perderá la oportunidad de realizarlo.
9.3 La petición de gestión de recuperación de Buena Fé financiera o no

financiera, debe responderse favorable o no, en un período no mayor a 30
días naturales.
En caso de que un Participante no de respuesta a una solicitud de Buena Fe,

el Participante afectado genera un reporte a su Cámara de Compensación
para notificar en el Comité de la Red de Medios de Disposición.
9.4 El Participante que acepta la petición de Buena Fe, puede cobrar por
concepto de Costos Operativos, de acuerdo al tiempo de atención y
aceptación del caso, bajo el siguiente esquema:
• De 1 a 15 días Naturales, contados a partir de la fecha de petición de

Buena Fe, cobrará de acuerdo a lo establecido en el punto D del capítulo
IV (Costos de Servicios).
• De 16 a 30 días Naturales, contados a partir de la fecha de petición de

Buena Fe, cobrará de acuerdo a lo establecido en el punto E del capítulo
IV Costos de Servicios.
• Más de 30 días Naturales, contados a partir de la fecha de petición de

Buena Fe, cobrará de acuerdo a lo establecido en el punto F del capítulo
IV Costos de Servicios.
10. GUARDA Y CONSERVACIÓN DE DOCUMENTOS
10.1 Es responsabilidad de la Institución Adquirente la guarda y custodia de los

Comprobantes y Devoluciones originales generados por el uso de Tarjetas
con sus Receptores de Pagos.
Capítulo I
CAPÍTULO II
RESOLUCIÓN DE CONTROVERSIAS
Para este capítulo, la Documentación de Apoyo es obligatoria de acuerdo con todos

los puntos que contiene cada uno de los Códigos de Razón.
En Condiciones para la representación se debe elegir la opción por la cual se

representa.
Capítulo II 1

CÓDIGO DE RAZÓN 41.- CARGO PERIÓDICO CANCELADO O NO
SOLICITADO.
CONTRACARGO DIRECTO - TIEMPO: 100 DÍAS NATURALES
CONDICIONES:
A.- Un Receptor de Pagos procesó una transacción con medio de acceso Q2 Sub Campo 1 valor 02,
sin autorización del Tarjetahabiente o sin previo contrato de servicio.
Esta opción de contracargo solo aplica si el importe de la transacción es menor a lo señalado en

el punto A del Capítulo IV, Costo de Servicios.
Puede aplicar:
Cuando el Emisor inicie un nuevo ciclo de contracargos por este código (mismo número de cuenta,
Receptor de Pagos y de diferente periodo), derivado de un cargo periódico, y el Adquirente representa
sin anexar nuevamente el contrato, el Emisor puede enviar a arbitraje sin cumplir el ciclo establecido
en el punto 8.2.1 del capítulo I (Manual Operativo), de este contrato.
DOCUMENTACIÓN DE APOYO:
Exhibit (Anexo 8).
Carta del Emisor, certificando haber recibido reclamación del Tarjetahabiente o Carta reclamación del
Tarjetahabiente o Medio de Registro de Solicitud de Aclaraciones (Certificado).
Estado de Cuenta (Físico / Digital o estado de movimientos del Emisor), o listado verificador
certificado donde aparece el cargo.
CONDICIONES PARA LA REPRESENTACIÓN: 30 DÍAS NATURALES

a) El contracargo es improcedente, (especificar causas y enviar evidencia).
b) Se procesó abono al Tarjetahabiente (enviar copia de listado verificador certificado).
c) El Tarjetahabiente firmó Contrato, autorizando el cargo periódico, (enviar copia del Contrato)
Puede aplicar:
Cuando el Emisor inicie un nuevo ciclo de contracargo por este código (mismo número de cuenta,
Receptor de Pagos y de diferente periodo), derivado de un cargo periódico y el Adquirente haya
enviado el contrato firmado por el Tarjetahabiente en el primer ciclo, el Adquirente puede enviar a
arbitraje sin cumplir el ciclo establecido en el punto 8.2.1 del capítulo I (Manual Operativo) de este
contrato, siempre y cuando el contrato de servicios este vigente y/o no exista cancelación por parte del
Tarjetahabiente.
C.R. 41 1/9
Capítulo II 2

SOLICITADO.
CONDICIONES:
B.- Un Receptor de Pagos continúa cargando al Tarjetahabiente con medio de acceso Q2 Sub Campo
1 valor 02, de cargos periódicos a pesar de la notificación de cancelación, efectuada 15 días
naturales antes del cargo del Receptor de Pagos.
Exhibit (Anexo 8).
Copia de la cancelación del Tarjetahabiente, enviada o presentada al receptor de pagos.
En caso de No existir cancelación por escrito, el Tarjetahabiente debe proporcionar:
1.- Fecha de cancelación.

2.- Número de reporte.
3.- Nombre de quien recibió la cancelación (opcional).
Debiendo especificar lo anterior en el Exhibit (Anexo 8).
c) El Receptor de Pagos no recibió cancelación de la transacción, por parte del Tarjetahabiente.
d) La notificación de cancelación de la transacción no fue presentada antes de los 15 días naturales del
cargo presentado por el Receptor de Pagos.
C.R. 41 2/9
Capítulo II 3

SOLICITADO.
CONDICIONES:
C.- Un Receptor de Pagos procesó una transacción con medio de acceso Q2 Subcampo 1 valor 02 sin
previo contrato de servicio o derivados de una renovación no autorizada.
Exhibit (Anexo 8)
Especificando en la Carta o en el exhibit, desconocimiento de la transacción o derivado de una

renovación no autorizada.
c) El Tarjetahabiente firmó Contrato autorizando el cargo periódico, (enviar copia del Contrato)
d) El Adquirente presenta contrato firmado por el Tarjetahabiente donde especifica que la renovación
será en forma automática.
C.R. 41 3/9
Capítulo II 4

SOLICITADO.
CONDICIONES:
D.- Un tarjetahabiente solicitó a su Emisor la cancelación del servicio de cargo periódico, y el receptor
de pagos procesó la transacción con un indicador diferente al valor 2 del Token Q2 subcampo 1.
Exhibit (Anexo 8) indicando la fecha en que fue cancelado el Servicio.
Carta del Emisor certificando haber recibido reclamación del Tarjetahabiente o Carta reclamación del
Tarjetahabiente o Medio de Registro de Solicitud de Aclaración de un Tarjetahabiente.
Copia de Log de Autorizaciones demostrando que viajaron los valores diferentes de indicadores y que
por tal motivo fue autorizado.
CONDICIONES PARA LA REPRESENTACIÓN:

C.R. 41 4/9
Capítulo II 5

SOLICITADO / TAG.
CONDICIONES:
E.- Un tarjetahabiente con contrato de servicio para la operativa TAG token Q2 subcampo 1 valor
24, no reconoce la transacción.
Exhibit (Anexo 8)
a) El contracargo es improcedente, (especificar causas y anexar evidencia).
c) Detalle de transacciones (Anexo 27A) demostrando la presencia del dispositivo TAG en el lugar,
fecha y hora de las transacciones.
C.R. 41 5/9
Capítulo II 6

SOLICITADO / TAG.
CONDICIONES:
F.- Un receptor de pagos con la operativa TAG token Q2 subcampo 1 valor 24, procesó transacciones
sin contar con un Contrato firmado por el Tarjetahabiente.
Exhibit (Anexo 8)
c) Copia del Contrato de Servicio firmado por el Tarjetahabiente.
C.R. 41 6/9
Capítulo II 7

SOLICITADO.
CONTRACARGO TRADICIONAL - TIEMPO: 120 DÍAS NATURALES
CONDICIONES:
G.- Un Receptor de Pagos procesó una transacción con medio de acceso Q2 Subcampo 1 valor 02 sin
autorización del Tarjetahabiente o sin previo contrato de servicio.
Exhibit (Anexo 8).
Contrato proporcionado por el Adquirente donde el nombre no coincide con el del Tarjetahabiente.

c) El Tarjetahabiente firmó Contrato, autorizando el cargo periódico, (enviar copia del Contrato).
C.R. 41 7/
Capítulo II 8

SOLICITADO.
CONDICIONES:
H.- Un Receptor de Pagos continúa cargando al Tarjetahabiente transacciones con medio de acceso
Q2 Sub Campo 1 valor 02, de cargos periódicos a pesar de la notificación de cancelación,
efectuada 15 días naturales antes del cargo del Receptor de Pagos.
Exhibit (Anexo 8).
Copia de la cancelación del Tarjetahabiente, enviada o presentada al receptor de pagos.
Documento proporcionado por el Adquirente con sello original o resumen Hash en el Proceso de
En caso de No existir cancelación por escrito, el Tarjetahabiente deberá proporcionar:
1.- Fecha de cancelación.

2.- Número de reporte.
3.- Nombre de quien recibió la cancelación (opcional).
Debiendo especificar lo anterior en el Exhibit
c) El Receptor de Pagos no recibió cancelación de la transacción, por parte del Tarjetahabiente.
d) La notificación de cancelación de la transacción no fue presentada antes de los 15 días naturales del
cargo presentado por el Receptor de Pagos.
C.R. 41 8/9
Capítulo II 9

SOLICITADO.
CONDICIONES:
I.- Un Receptor de Pagos continúa cargando al Tarjetahabiente transacciones con medio de acceso
Q2 Sub Campo 1 valor 02 de cargos periódicos, derivadas de una renovación no autorizada.
Exhibit (Anexo 8)
Copia del contrato de servicios firmado por el Tarjetahabiente.
c) El Adquirente presenta contrato firmado por el cliente donde especifica que la renovación será en
forma automática.
C.R. 41 9/9
Capítulo II 10

CÓDIGO DE RAZÓN 57.- TRANSACCIÓN MÚLTIPLE NO AUTORIZADA POR
EL TARJETAHABIENTE.
CONDICIONES:
A.- Transacciones múltiples con una sola tarjeta ocurrieron en el mismo Receptor de Pagos, sin
autorización del Tarjetahabiente.
Las transacciones electrónicas en interred, terminal punto de venta y/o multicajas, con envío de PEM
(90), (05), (07), (80) ó (02), no deben exceder de 15 minutos entre una transacción y otra. No aplica
para los Giros Tiendas Departamentales (5311) cuando se trate de un número de caja distinto ni para
transacciones de CHIP + NIP.
El cliente acepta haber participado en por lo menos una transacción en el mismo Receptor de Pagos,
no aplica para transacciones de tarjeta no presente.
Exhibit (Anexo 8).
Carta del Emisor certificando haber recibido reclamación del Tarjetahabiente, Medio de Registro de
Solicitud de Aclaraciones (Certificado) o Carta reclamación del Tarjetahabiente.
Aceptando su participación en una transacción o varias, especificándolas en su carta, medio de registro
certificado o exhibit.
Estado de cuenta o listado de movimientos del Emisor que demuestre el proceso de dos o más
transacciones.

b) Se procesó abono o reverso al Tarjetahabiente (enviar copia de listado verificador certificado).
c) La transacción electrónica excede de 15 minutos de una transacción a otra. (anexar copia de log de
autorizaciones y Comprobantes)
d) La copia de los Comprobantes en disputa contiene la misma firma de la carta reclamación y/o los
Comprobantes que sí reconoce el Tarjetahabiente.
e) El cliente no reconoce cuando menos una transacción en el Receptor de Pagos.
f) La Carta Certificación del Emisor no cumple con lo señalado en el punto 4.14 del Capítulo I del
Manual Operativo.
g) La firma de la carta reclamación no es la misma con la del Comprobante que sí reconoce.
C.R. 57 1/5
Capítulo II 11

EL TARJETAHABIENTE.
CONDICIONES:
B.- Transacciones múltiples con una sola tarjeta ocurrieron en el mismo Receptor de Pagos, sin
El cliente acepta haber participado en por lo menos una transacción en el mismo Receptor de Pagos.
En el log de autorizaciones existen transacciones múltiples del mismo Receptor de Pagos, mismo día
o días distintos con PEM (01), no aplica para transacciones de comercio electrónico autenticado
con indicador ECI (5 ó 6)..
Exhibit (Anexo 8).
Aceptando su participación en una transacción o varias, especificándolas en su carta, medio de
registro certificado o exhibit.
transacciones.

c) La copia de los Comprobantes en disputa contiene la misma firma de la carta reclamación y/o los
d) El cliente no reconoce cuando menos una transacción en el Receptor de Pagos.
e) La Carta Certificación del Emisor no cumple con lo señalado en el punto 4.14 del Capítulo I del
Manual Operativo.
f) La firma de la carta reclamación no es la misma con la del Comprobante que sí reconoce.
g) El Indicador de Comercio Electrónico (ECI) es igual a “5” o “6” (enviar Anexo 18 Log de
Autorizaciones certificado y Anexo 32 reporte de valores de autenticación).
C.R. 57 2/5
Capítulo II 12

EL TARJETAHABIENTE.
CONDICIONES:
C.- Transacciones múltiples con una sola tarjeta ocurrieron en el mismo Receptor de Pagos, sin
(90), (05), (07), (80) ó (02), no deberán exceder de 15 minutos de una transacción a otra. No aplica
para los Giros Tiendas Departamentales (5311) cuando se trate de un número de caja distinto ni para
transacciones de CHIP + NIP.
El cliente acepta haber participado en por lo menos una transacción en el mismo Receptor de Pagos,
no aplica para transacciones de tarjeta no presente.
Exhibit (Anexo 8).
Carta reclamación del Tarjetahabiente o Medio de Registro de Solicitud de Aclaraciones (Certificado),
aceptando su participación en una transacción o varias especificándolas en su carta, medio de registro
transacciones.

c) La transacción electrónica excede de 15 minutos de una transacción a otra.
d) La copia de los Comprobantes en disputa contiene la misma firma de la carta reclamación y/o los
Manual Operativo.
g) La firma de la carta reclamación no es la misma con la del Comprobante que sí reconoce.
C.R. 57 3/5
Capítulo II 13

EL TARJETAHABIENTE.
CONDICIONES:
D.- Transacciones múltiples con una sola tarjeta ocurrieron en el mismo Receptor de Pagos, sin
Comprobantes planchados tradicionalmente con envío diferente a PEM (90), (05), (07), (80) ó (02),
del día o días distintos, la firma deberá ser diferente a la del Tarjetahabiente contra la del Comprobante
que sí reconoce y/o carta reclamación.
El cliente acepta haber participado en por lo menos una transacción de tarjeta presente en el mismo
Receptor de Pagos.
Exhibit (Anexo 8).
Aceptando su participación en una transacción o varias especificándolas en su carta, medio de registro
Documentos proporcionados por el Adquirente con sello original o resumen Hash en el Proceso de

c) La copia de los Comprobantes en disputa contiene la misma firma de la carta reclamación y/o los
d) El cliente no reconoce cuando menos una transacción en el Receptor de Pagos.
Manual Operativo.
f) La firma de la carta reclamación no es la misma con la del Comprobante que sí reconoce.
C.R. 57 4/5
Capítulo II 14

CÓDIGO DE RAZÓN 57.- TRANSACCIÓN MÚLTIPLE CON NIP NO
RECONOCIDA POR EL TARJETAHABIENTE.
CONDICIONES:
E.- Transacción única o múltiple con NIP digitado, mismo importe con una sola tarjeta ocurriendo en
el mismo Receptor de Pagos. Puede tratarse de la misma o diferente afiliación y/o Adquirente
El contracargo se debe de efectuar al Adquirente que recibió la o las primeras autorizaciones.
(05) o (07), no deben exceder de 10 minutos entre una transacción y otra.
El cliente acepta haber digitado su NIP en una o varias transacciones en el mismo Receptor de Pagos
indicando el comercio que no fue o fueron realizadas las transacciones, no aplica para transacciones
de tarjeta no presente.
Exhibit (Anexo 8).
Medio de Registro de Solicitud de Aclaraciones (Certificado) o Carta reclamación del Tarjetahabiente,
aceptando su participación en una transacción o varias, especificándolas en su carta, medio de registro
certificado o exhibit. (Cuando se trate de transacción única, no es necesario especificarla)
LOG de autorización (certificado) de acuerdo con el anexo 18 con valores de NIP.
Estado de cuenta o listado de movimientos del Emisor que demuestre el proceso de una o más
transacciones.

c) La transacción electrónica excede de 10 minutos de una transacción a otra. (anexar copia de log de
autorizaciones o Comprobantes)
d) En transacciones de CHIP + NIP, debe enviar copia del o los Comprobante(s) en disputa emitido(s)
por el punto de venta. (Pagaré con la leyenda “Autorizado con firma electrónica”).
C.R. 57 5/5
Capítulo II 15

CÓDIGO DE RAZÓN 60.- ORIGINAL O COPIA RECIBIDA ILEGIBLE, CON
DATOS INCOMPLETOS O NO CORRESPONDE
CONTRACARGO TRADICIONAL - TIEMPO 25 DÍAS NATURALES DESPUES DE LA FECHA
DE RECEPCIÓN DEL DOCUMENTO.
CONDICIONES:
A.- El Adquirente proporcionó ilegible el Comprobante original, copia o Comprobante sustituto.
Los datos mandatorios que debe contener el comprobante se señalan en el Anexo 15.
Puede aplicar:
En caso de recibir una representación por opción “c”, el Emisor puede efectuar un segundo contracargo
por otro código en un plazo no mayor a 30 días naturales contados a partir de la fecha de la
representación aun cuando haya vencido el plazo establecido para el nuevo código de razón. (No aplica
para solicitud de Comprobantes originales).
Si un adquirente representa contracargos con comprobantes con datos ilegibles de acuerdo con el
Anexo 15, el emisor puede generar un segundo contracargo por esta opción del código de razón en un
plazo no mayor a 30 días naturales contados a partir de la fecha de representación.
Exhibit (Anexo 8) indicando la información ilegible.
Devolución de la copia del Comprobante o copia del documento sustituto que contiene el sello original
del Adquirente o resumen Hash en el Proceso Digitalización de Imágenes o el documento original.
En caso de tratarse de Comprobante original el Emisor deberá recabar firma de acuse de recibo del
Adquirente por la devolución del Comprobante original, al momento de entregar en el intercambio la
documentación de apoyo del primer contracargo.

c) Anexando nueva copia del Comprobante y opcionalmente copia del Log de Autorizaciones
certificado como complemento para evitar segundo contracargo por código de razón 60 o 75
siempre y cuando el dato ilegible no sea alguno de los siguientes: número de cuenta, número de
autorización, importe o firma (Aplica únicamente para atender solicitud de copia).
Puede aplicar:
En caso de que el Adquirente considere que la copia u original entregado al Emisor, en atención a su
transacción 51 o 52 es legible, el Adquirente puede someter el caso a arbitraje desde la recepción del
primer contracargo.
C.R. 60 1/3
Capítulo II 16

DATOS INCOMPLETÓS O NO CORRESPONDE
CONDICIONES:
B.- El documento atendido por el Adquirente, no contiene alguno de los datos del Anexo 15.
Puede aplicar:
En caso de recibir una representación, el Emisor puede efectuar un segundo contracargo por otro
código en un plazo no mayor a 30 días naturales contados a partir de la fecha de la representación aun
cuando haya vencido el plazo establecido para el nuevo código de razón. (No aplica para solicitud de
Comprobantes originales).
Si un adquirente representa contracargos con comprobantes con datos incompletos de acuerdo con el
Anexo 15, el emisor puede generar un segundo contracargo por esta opción del código de razón en un
plazo no mayor a 30 días naturales contados a partir de la fecha de representación.
Exhibit (Anexo 8) indicando la información faltante.
Devolución de la copia del Comprobante o copia del documento sustituto que contiene el sello original
del Adquirente o resumen Hash en el Proceso Digitalización de Imágenes o el documento original.

c) Anexando copia del Comprobante o copia del documento sustituto que cumple con las
características del anexo 15 y opcionalmente copia del Log de Autorizaciones certificado como
complemento para evitar segundo contracargo por código de razón 60 o 75
Puede aplicar:
En caso de que el Adquirente considere que la copia u original entregado al Emisor, en atención a su
transacción 51 o 52 contiene los datos mandatorios del Anexo 15, el Adquirente puede someter el caso
a arbitraje desde la recepción del primer contracargo.
C.R. 60 2/3
Capítulo II 17

DATOS INCOMPLETÓS O NO CORRESPONDE.
CONDICIONES:
C.- Un Adquirente atendió (transacción 53), una solicitud de Comprobante (transacción 51 o 52) con
Log de Autorizaciones (Anexo 18), en lugar de proporcionar el Comprobante emitido por la
Terminal Punto de Venta o el Contrato de Prestación de Servicios de acuerdo con lo señalado en
el Anexo 15.
Lo anterior no aplica para transacciones en las cuales se especifique que pueden ser atendidas
mediante el Log de Autorizaciones de acuerdo con lo establecido en el Anexo 15.
Exhibit (Anexo 8) indicando que el Comprobante no corresponde a la operativa.
Comprobante recibido que contiene el sello original del Adquirente o resumen Hash en el Proceso de
a) El contracargo es improcedente (especificar causas y enviar evidencia)
Puede aplicar:
En caso de que el Adquirente considere que el documento entregado, en atención a su transacción 51

o 52 es válido, el Adquirente puede someter el caso a arbitraje desde la recepción del primer
contracargo.
C.R. 60 3/3
Capítulo II 18

CÓDIGO DE RAZÓN 63.- CHIP (EMV)
CONDICIONES:
A.- Transacción realizada con una Tarjeta Chip (EMV), flag service code A (2xx, 6xx), no reconocida por
el Tarjetahabiente. Un Adquirente transmitió PEM (90), Terminal Capability diferente a 5, 8 o 9 y flag
service code (A).
No aplica para ventas telefónicas, cargos periódicos, correo, Comercio Electrónico, firma en archivo y/o
reservaciones garantizadas (no show).
Medio de Registro de Solicitud de Aclaraciones (Certificado) o Carta Reclamación del Tarjetahabiente.
Exhibit Anexo 8 Indicando en el campo de observaciones la fecha de bloqueo o cancelación por skimming de
la Tarjeta, (Puede presentarse exhibit global Anexo 8 solo cuando se trate del mismo número de cuenta).
Documento proporcionado por el Adquirente con sello original o resumen Hash en el Proceso de Digitalización
de Imágenes.
Copia del log de Autorizaciones certificado donde se aprecia que recibió PEM (90), Terminal Capability
diferente a 5, 8 o 9 y flag service code (A).
Y alguna de las siguientes opciones:
a) Impresión de la pantalla del registro en el sistema de fraudes de las Marcas con la siguiente información:
• Fecha de registro del fraude en VISA (TC-40) o MasterCard (SAFE), la cual debe ser igual o anterior a la
fecha del contracargo.
• Clave de tipo de fraude, 04 MasterCard o 4 Visa
O
b) Carta del área de Prevención de Fraudes certificando skimming, individual o global cuando se trate del mismo
número de cuenta, de acuerdo con lo señalado en el punto 3.1 del capítulo XV Chip (EMV).

b) Se procesó abono al tarjetahabiente (enviar copia de listado verificador certificado).
c) El Log Adquirente presenta valores Chip (EMV) de acuerdo con la tabla del punto 1 inciso e) del capítulo
XV del presente Manual Operativo, enviar Log de Autorizaciones del Adquirente.
d) La fecha de bloqueo o cancelación por skimming de la Tarjeta es posterior a la fecha del contracargo.
e) La fecha de registro del fraude en VISA (TC-40) o Mastercard (SAFE), no existe o es posterior a la fecha del
primer contracargo.
f) El registro del fraude en VISA (TC-40) o Mastercard (SAFE), se modificó o se eliminó, posterior a la fecha
del primer contracargo.
C.R. 63 1/4
Capítulo II 19

CONDICIONES:
B.- Una transacción bajo el esquema de Chip (EMV), flag service code A (2xx, 6xx), presenta valores
distintos a los establecidos en la tabla del punto 1 inciso e) del capítulo XV Chip (EMV), en el log de
autorizaciones certificado.
No aplica para ventas telefónicas, cargos periódicos, correo, Comercio Electrónico, firma en archivo y/o
reservaciones garantizadas (no show).
Exhibit Anexo 8 Indicando en el campo de observaciones la fecha de bloqueo o cancelación por skimming
de la Tarjeta, (Puede presentarse exhibit global Anexo 8 solo cuando se trate del mismo número de cuenta).
Copia del log de Autorizaciones certificado donde se aprecia que recibió valores distintos a los establecidos
en la tabla del punto 1 inciso e) del capítulo XV Chip (EMV).
Y alguna de las siguientes opciones:
a) Impresión de la pantalla del registro en el sistema de fraudes de las Marcas con la siguiente información:
• Fecha de registro del fraude en VISA (TC-40) o MasterCard (SAFE), la cual debe ser igual o anterior
a la fecha del contracargo.
• Clave de tipo de fraude, 04 MasterCard ó 4 Visa
O
b) Carta del área de Prevención de Fraudes certificando skimming, individual o global cuando se trate del
mismo número de cuenta, de acuerdo con lo señalado en el punto 3.1 del capítulo XV Chip (EMV).

c) El Log Adquirente presenta valores Chip (EMV) de acuerdo con la tabla del punto 1 inciso e) del capítulo
XV del presente contrato, enviar Log de Autorizaciones del Adquirente.
d) La fecha de bloqueo o cancelación por skimming de la Tarjeta es posterior a la fecha del contracargo.
e) La fecha de registro del fraude en VISA (TC-40) o Mastercard (SAFE), no existe o es posterior a la fecha del
primer contracargo.
f) El registro del fraude en VISA (TC-40) o Mastercard (SAFE), se modificó o se eliminó, posterior a la fecha
del primer contracargo.
C.R. 63 2/4
Capítulo II 20

CONDICIONES:
C.- El Emisor recibe reclamación del tarjetahabiente informando que desconoce una transacción hecha
con su tarjeta Chip EMV y el Adquirente no envió el ARQC (No aplica para PEM 01, 02, 80 o 90)
No se puede utilizar esta opción, cuando el Emisor NO califique con 0, el token B4 subcampo 8
DOCUMENTACIÓN DE APOYO :
Exhibit (Anexo 8).

LOG de autorizaciones certificado con valores FULL EMV de acuerdo con lo señalado en el Capítulo XV de
este manual operativo.

c) Log de Autorizaciones Certificado (Anexo 18) demostrando que SI envió el ARQC en el Token B2,
subcampo 5.
C.R. 63 3/4
Capítulo II 21

CONDICIONES:
D.- El Emisor recibe reclamación del tarjetahabiente informando que desconoce una transacción hecha
con su tarjeta Chip EMV, y el Adquirente no solicitó la validación del NIP.
El emisor solo puede utilizar esta opción de contracargo si cumple con las siguientes condiciones:
-Adquirente envió ARQC y el Token B4 subcampo 8 es igual a 2 o 4.

-POS Entry Mode posición 1-2 es igual a 05
-POS Entry Mode posición 3 es distinto a 1.
Exhibit (Anexo 8).

LOG de autorizaciones certificado con valores EMV y NIP de acuerdo con lo señalado en el Capítulo XV de
este manual operativo.
Impresión de la pantalla del registro en el sistema de fraudes de las Marcas con la siguiente información:
• Fecha de registro del fraude en VISA (TC-40) o MasterCard (SAFE), la cual debe ser igual o anterior
a la fecha del contracargo con la clave de tipo de fraude, 00 Tarjeta Perdida, 01 Tarjeta Robada o 02
Tarjeta No Entregada.

c) El adquirente envió valores correctos (adjuntar LOG de autorizaciones certificado con valores de CHIP+NIP)
C.R. 63 4/4
Capítulo II 22

CÓDIGO DE RAZÓN 64.- TRANSACCIÓN MANUAL EN TERMINAL
ELECTRÓNICA.
CONDICIONES:
A.- Un Adquirente no transmitió PEM (90), (05), (07), (80) ni (02) y envío PEM (01)
El Receptor de Pagos digita el No. de cuenta en el punto de venta.
No aplica para ventas telefónicas / correo Q2=08, cargos periódicos Q2=02, Comercio Electrónico
Q2=09, reservaciones garantizadas (no show) y Firma en Archivo.
Exhibit (Anexo 8).
Copia del log de autorizaciones certificado.
c) La transacción corresponde a ventas telefónicas, cargos periódicos, correo, Comercio Electrónico,

reservaciones garantizadas (no show) y Firma en Archivo.
C.R. 64 1 / 2
Capítulo II 23

CÓDIGO DE RAZÓN 64.- TRANSACCIÓN MANUAL EN TERMINAL
ELECTRÓNICA.
CONDICIONES:
B.- Un Adquirente no transmitió PEM (90), (05), (07), (80) ni (02) y envío PEM (01)
El Receptor de Pagos, digita el No. de cuenta en el punto de venta.
No aplica para ventas telefónicas / correo Q2=08, cargos periódicos Q2=02, Comercio Electrónico
Q2=09, reservaciones garantizadas (no show) y Firma en Archivo.
Exhibit (Anexo 8).
c) La transacción corresponde a ventas telefónicas, cargos periódicos, correo, Comercio Electrónico,

reservaciones garantizadas (no show) o Firma en Archivo.
C.R. 64 2/2
Capítulo II 24

CÓDIGO DE RAZÓN 68.- TRANSACCIÓN DE ORDEN
TELEFONICO/CORREO/INTERNET FRAUDULENTA.
CONDICIONES:
A.- El Emisor recibe reclamación del Tarjetahabiente de una transacción con PEM 01 y medio de
acceso diferente a Q2-02 o Q2-09 con indicador ECI “5” o “6”, informando que él no participó
en la transacción.
El contracargo no procede si se trata de transacciones de:
-Tarjeta Presente indicando en el log de autorizaciones PEM 05, 07, 80 o 90
-Donde existan dos factores de autenticación por cualquier método.
Puede aplicar:
Si la documentación o información proporcionada por el Adquirente en la representación, da opción a
un nuevo código de razón el Emisor puede efectuar un segundo contracargo por otro código, en un
plazo no mayor a 30 días naturales contados a partir de la fecha de la representación aun cuando haya
vencido el plazo establecido para el nuevo código de razón.
Exhibit (Anexo 8).
Solicitud de Aclaraciones (Certificado) o Carta reclamación del Tarjetahabiente señalando que no
reconoce la transacción.
c) La compra fue transmitida en terminal punto de venta, cuenta con autorización electrónica “presencia del plástico en el
receptor de pagos”, PEM (Pos Entry Mode) igual a “05”, “07”, “80” o “90”. (enviar copia de log de autorizaciones
certificado.
d) Cuando la transacción cuenta con al menos dos factores de autenticación adjuntar log de autorizaciones certificado que
contenga los tokens PO y PY.
e) Mo/To Autenticado o Comercio Electrónico Autenticado. - Comprobante de Pago por Complemento de Servicio con
importe de $10.00 con Tarjeta CHIP (PEM 05,07) que autentica la tarjeta con la cual se realizó la Transacción Original,
acuse de recibo, logs de autorizaciones certificados de la Venta Original y de la Venta por complemento de Servicio.
f) La Carta Certificación del Emisor no cumple con lo señalado en el punto 4.14 del Capítulo I del Manual Operativo.
g) El ECI (Indicador de Comercio Electrónico) es igual a “5” o “6” (enviar Anexo 18 Log de Autorizaciones certificado
y Anexo 32 reporte de valores de autenticación).
h) La transacción corresponde a la operativa Check In / Check Out (enviar copia de los Logs de Autorizaciones
Certificados relacionados con la transacción).
i) Para reservaciones garantizadas en donde el nombre del tarjetahabiente coincida con el de la carta reclamación
presentada por el Emisor. Enviar carta del Receptor de Pagos con logotipo o membretada, que contenga datos generales
del Tarjetahabiente: teléfono, nombre del tarjetahabiente, número de tarjeta y fecha de vencimiento o cuando se trate
de servicios no prestados por contingencia conforme a lo señalado en el punto 8 del Capítulo XIV, presentando las
opciones ofrecidas al tarjetahabiente.
j) Si se trata de un cargo por No Show en donde el nombre del tarjetahabiente coincida con el de la carta reclamación
presentada por el Emisor. El cargo por no show será de acuerdo a las políticas de reservación y cancelación del
establecimiento, para lo cual el receptor de pagos deberá proporcionar carta membretada y firmada por un responsable o
por contingencia conforme a lo señalado en el punto 8 del capítulo XIV, presentando las opciones ofrecidas al
tarjetahabiente.
Cuando el Adquirente envíe a arbitraje transacciones contracargadas por este código de razón, debe adjuntar el Anexo 18
(Log de Autorizaciones Certificado).
C.R. 68 1/4
Capítulo II 25

TELEFONICO/CORREO/ INTERNET FRAUDULENTA.
CONDICIONES:
B.- Las transacciones de Bines Emisores que SI participan en 3D Secure con valor ECI “5” o “6”, se pueden
Contracargar si al revisar el Anexo 32 encuentra uno de los siguientes escenarios:
Para 3D Secure 1.0

- El campo de Estatus del VERes muestra el valor “U”
- El campo de Estatus del VERes muestra código de error
- El campo de Estatus del PARes muestra un valor distinto a “Y” o “A”
- El campo de Estatus del PARes muestra un valor igual a “Y” o “A” y no presenta CAVV/AAV
Para 3D Secure 2.0

- El campo de Estatus del AReq muestra el valor “U”
- El campo de Estatus del AReq muestra código de error
- El campo de Estatus del ARes muestra un valor distinto a “Y” o “A”
- El campo de Estatus del ARes muestra un valor igual a “Y” o “A” y no presenta CAVV/AAV
- El campo de Estatus del CRes muestra un valor distinto a “Y”
- El campo de Estatus del CRes muestra un valor igual a “Y” y no presenta CAVV/AAV
Las transacciones de Bines Emisores que NO participan en 3D Secure se pueden Contracargar si en el Log de
Autorizaciones cuentan con valor ECI “5”.
Exhibit (Anexo 8).
Tarjetahabiente o Medio de Registro Certificado Anexo 30.
Anexo 18 (Log de autorizaciones Certificado).
Anexo 32 (Reporte de Valores ECI). Si el BIN Emisor no participa en 3D Secure, no es necesario enviar este
documento.

c) El Adquirente demuestra mediante Anexo 32 que los valores 3D Secure de su MPI son correctos.
d) La Carta Certificación del Emisor no cumple con lo señalado en el punto 4.14 del Capítulo I del Manual
Operativo.
C.R. 68 2/4
Capítulo II 26

CONDICIONES:
C.- El Emisor recibe reclamación del Tarjetahabiente, de una transacción con PEM 01 y medio de
acceso diferente a Q2-02 o Q2-09 con indicador ECI “5” o “6”, informando que él no participó
en la transacción.
El contracargo no procede si se trata de transacciones de:
-Transacciones de Tarjeta Presente indicando en el log de autorizaciones PEM 05, 07, 80 o 90
-Cuando existan dos factores de autenticación por cualquier método.
Puede aplicar:
Si la documentación o información proporcionada por el Adquirente en la representación, da opción a
un nuevo código de razón el Emisor puede efectuar un segundo contracargo por otro código, en un
plazo no mayor a 30 días naturales contados a partir de la fecha de la representación aun cuando haya
vencido el plazo establecido para el nuevo código de razón.
Exhibit (Anexo 8).
Carta del Emisor certificando haber recibido reclamación del Tarjetahabiente, Medio de Registro de Solicitud de
Aclaraciones (Certificado) o Carta reclamación del Tarjetahabiente señalando que no reconoce la transacción.
Documentación enviada por el Adquirente con sello original o resumen Hash en el Proceso Digitalización de Imágenes.
c) La compra fue transmitida en terminal punto de venta, cuenta con autorización electrónica “presencia del plástico en el
receptor de pagos”, PEM (Pos Entry Mode) igual a “05”, “07”, “80” o “90”. (enviar copia de log de autorizaciones
certificado.
d) Cuando la transacción cuenta con al menos dos factores de autenticación adjuntar log de autorizaciones certificado que
contenga los tokens PO y PY.
e) Mo/To Autenticado o Comercio Electrónico Autenticado. - Comprobante de Pago por Complemento de Servicio con
importe de $10.00 con Tarjeta CHIP (PEM 05,07) que autentica la tarjeta con la cual se realizó la Transacción Original,
acuse de recibo, logs de autorizaciones certificados de la Venta Original y de la Venta por complemento de Servicio.
f) La Carta Certificación del Emisor no cumple con lo señalado en el punto 4.14 del Capítulo I del Manual Operativo.
g) El ECI (Indicador de Comercio Electrónico) es igual a “5” o “6” (enviar Anexo 18 Log de Autorizaciones certificado
y Anexo 32 reporte de valores de autenticación).
h) La transacción corresponde a la operativa Check In / Check Out (enviar copia de los Logs de Autorizaciones
Certificados relacionados con la transacción).
i) Para reservaciones garantizadas en donde el nombre del tarjetahabiente coincida con el de la carta reclamación
presentada por el Emisor. Enviar carta del Receptor de Pagos con logotipo o membretada, que contenga datos generales
del Tarjetahabiente: teléfono, nombre del tarjetahabiente, número de tarjeta y fecha de vencimiento o cuando se trate
de servicios no prestados por contingencia conforme a lo señalado en el punto 8 del Capítulo XIV, presentando las
opciones ofrecidas al tarjetahabiente.
j) Si se trata de un cargo por No Show en donde el nombre del tarjetahabiente coincida con el de la carta reclamación
presentada por el Emisor. El cargo por no show será de acuerdo a las políticas de reservación y cancelación del
establecimiento, para lo cual el receptor de pagos deberá proporcionar carta membretada y firmada por un responsable o
por contingencia conforme a lo señalado en el punto 8 del capítulo XIV, presentando las opciones ofrecidas al
tarjetahabiente.
Cuando el Adquirente envíe a arbitraje transacciones contracargadas por este código de razón, debe adjuntar el Anexo 18
(Log de Autorizaciones Certificado).
C.R. 68 3/4
Capítulo II 27

CONDICIONES:
D.- Las transacciones de Bines Emisores que, SI participan en 3D Secure con valor ECI “5” o “6”, se pueden
Contracargar si al revisar el Anexo 32 encuentra uno de los siguientes escenarios:
Para 3D Secure 1.0

- El campo de Estatus del VERes muestra el valor “U”
- El campo de Estatus del VERes muestra código de error
- El campo de Estatus del PARes muestra un valor distinto a “Y” o “A”
- El campo de Estatus del PARes muestra un valor igual a “Y” o “A” y no presenta CAVV/AVV
Para 3D Secure 2.0

- El campo de Estatus del AReq muestra el valor “U”
- El campo de Estatus del AReq muestra código de error
- El campo de Estatus del ARes muestra un valor distinto a “Y” o “A”
- El campo de Estatus del ARes muestra un valor igual a “Y” o “A” y no presenta CAVV/AAV
- El campo de Estatus del CRes muestra un valor distinto a “Y”
- El campo de Estatus del CRes muestra un valor igual a “Y” y no presenta CAVV/AAV
Las transacciones de Bines Emisores que NO participan en 3D Secure se pueden Contracargar si en el Log de
Autorizaciones cuentan con valor ECI “5”.
Exhibit (Anexo 8).
Tarjetahabiente o Medio de Registro Certificado Anexo 30.
Anexo 18 (Log de autorizaciones Certificado).
Documentos enviados por el Adquirente con sello original o resumen Hash en el Proceso de Digitalización de
Imágenes.
Anexo 32 (Reporte de Valores ECI). Si el BIN Emisor no participa en 3D Secure, no es necesario enviar este
documento.

c) El Adquirente demuestra mediante Anexo 32 que los valores 3D Secure de su MPI son correctos.
d) La Carta Certificación del Emisor no cumple con lo señalado en el punto 4.14 del Capítulo I del Manual
Operativo.
C.R. 68 4/4
Capítulo II 28

CÓDIGO DE RAZÓN 70.- TARJETA BOLETINADA.
CONDICIONES:
A.- Un Receptor de Pagos no validó el boletín para un importe que está debajo del límite de piso y la
cuenta estaba boletinada en la fecha de suscripción del Comprobante.
En los casos de cargos periódicos, la fecha de consumo se considera la fecha de la transacción recibida
en el intercambio.
Exhibit (Anexo 8) informando la fecha de suscripción del Boletín.
c) La cuenta no se encontraba incluida en el boletín papel correspondiente a la fecha de suscripción.
d) La transacción cuenta con autorización, enviar copia de log de autorizaciones certificado.
C.R. 70 1/2
Capítulo II 29

CÓDIGO DE RAZÓN 70.- TARJETA BOLETINADA.
CONDICIONES:
B.- Un Receptor de Pagos no validó el boletín para un importe que está debajo del límite de piso y la
cuenta estaba boletinada en la fecha de suscripción del Comprobante.
En los casos de cargos periódicos, la fecha de consumo se considera la fecha de la transacción recibida
en el intercambio.
Debe estar almacenado en el repositorio de Imágenes, la atención del comprobante por parte del
Adquirente.
Exhibit (Anexo 8) informando la fecha de suscripción del Boletín.
c) La cuenta no se encontraba incluida en el boletín papel correspondiente a la fecha de suscripción.
d) La transacción cuenta con autorización, enviar copia del log de autorizaciones certificado.
C.R. 70 2/2
Capítulo II 30

CÓDIGO DE RAZÓN 71.- AUTORIZACIÓN DECLINADA
CONDICIONES:
A.- Un Receptor de Pagos completó una transacción después de que la autorización solicitada fue
declinada.
Puede aplicar:
Si el Comprobante proporcionado por el Adquirente en la representación, da opción a un nuevo código
de razón el Emisor puede efectuar un segundo contracargo por otro código, en un plazo no mayor a 30
días naturales contados a partir de la fecha de la representación aun cuando haya vencido el plazo
establecido para el nuevo código de razón.
DOCUMENTACIÓN DE APOYO.
Exhibit (Anexo 8).
Copia de log de autorizaciones certificado, donde aparece declinada la transacción.

c) Copia del Comprobante.
d) La transacción fue autorizada, enviar copia del log de autorizaciones.
C.R. 71 1/2
Capítulo II 31

CÓDIGO DE RAZÓN 71.- AUTORIZACIÓN DECLINADA
CONDICIONES:
B.- Un Receptor de Pagos completó una transacción después de que la autorización solicitada fue
declinada.
DOCUMENTACIÓN DE APOYO.
Exhibit (Anexo 8).
Copia del log de autorizaciones certificado donde aparece declinada la transacción
c) La transacción fue autorizada, enviar copia del log de autorizaciones.
C.R. 71 2/2
Capítulo II 32

CÓDIGO DE RAZÓN 72.- TRANSACCIÓN QUE EXCEDE EL IMPORTE
AUTORIZADO O FALTA DE AUTORIZACIÓN.
CONTRACARGO DIRECTO - TIEMPO: 45 DÍAS NATURALES POR RECHAZO DE

COMPUTADOR, POR TRANSACCIÓN QUE EXCEDE EL IMPORTE AUTORIZADO.
CONDICIONES: No requiere contar con carta reclamación del tarjetahabiente.
A.- Un Receptor de Pagos procesó una transacción por un importe mayor a la autorización otorgada
por el Emisor.
Cuando el importe autorizado es menor al importe de la transacción, se contracarga solo el importe
que excede el importe autorizado.
Cuando el importe de la transacción es mayor al 20% del importe autorizado, para una transacción en
renta de autos, restaurantes y/o hoteles, sólo se contracarga el importe que excede el 20%.
Exhibit (Anexo 8)
b) Se procesó abono al Tarjetahabiente (enviar copia del listado verificador certificado).
c) El Receptor de Pagos obtuvo autorización (enviar copia del log de autorizaciones certificado)
C.R. 72 1/4
Capítulo II 33

CONTRACARGO DIRECTO - TIEMPO: 45 DÍAS NATURALES POR FALTA DE

AUTORIZACIÓN.
CONDICIONES:
B.- Un Receptor de Pagos no obtuvo autorización para una transacción.

El Comprobante no contiene autorización.
Exhibit (Anexo 8)
Copia del log de autorización certificado de 5 días naturales a partir de la fecha de suscripción.
En los casos de que el documento no contenga fecha de suscripción, se considerará la fecha enviada
en el anexo 4.
c) El Receptor de Pagos obtuvo autorización (enviar copia del log de autorizaciones certificado).
C.R. 72 2/4
Capítulo II 34

CONTRACARGO TRADICIONAL - TIEMPO 120 DÍAS NATURALES POR TRANSACCIÓN

QUE EXCEDE EL IMPORTE AUTORIZADO Y RECLAMACIÓN DEL TARJETAHABIENTE.
CONDICIONES:
C.- Un Receptor de Pagos procesó un Comprobante por un importe mayor a la autorización otorgada
por el Emisor estampada en dicho Comprobante.
Cuando el importe autorizado es menor al importe de la transacción, se contracarga solo el importe

que excede el importe autorizado.
Cuando el importe de la transacción es mayor al 20% del importe autorizado, para una transacción en
renta de autos, restaurantes y/o hoteles, sólo se contracarga el importe que excede el 20%.
Exhibit (Anexo 8)
c) El Receptor de Pagos obtuvo autorización, enviar copia del log de autorizaciones certificado.
C.R. 72 3/4
Capítulo II 35

CONTRACARGO TRADICIONAL - TIEMPO 120 DÍAS NATURALES POR FALTA DE

AUTORIZACIÓN Y RECLAMACIÓN DEL TARJETAHABIENTE.
CONDICIONES:
D.- Un Receptor de Pagos no obtuvo autorización para una transacción.

El Comprobante no contiene autorización.
Exhibit (Anexo 8)
Capia del log de autorización certificado de 5 días naturales a partir de la fecha de suscripción.
En los casos de que el documento no contenga fecha de suscripción, se considerará la fecha enviada
en el anexo 4.
c) El Receptor de Pagos obtuvo autorización (enviar copia del log de autorizaciones certificado).
d) La firma es la misma de la carta reclamación.
C.R. 72 4/4
Capítulo II 36

CÓDIGO DE RAZÓN 73.- TARJETA VENCIDA.
CONDICIONES:
A.- Un Receptor de Pagos completó una transacción con una tarjeta vencida y no obtuvo autorización.
DOCUMENTACION DE APOYO:
Exhibit (Anexo 8)
c) El Receptor de Pagos obtuvo autorización vía voz y/o electrónica, (enviar copia del log de
autorizaciones certificado).
d) La tarjeta no estaba vencida al momento de la transacción.
C.R. 73 1/2
Capítulo II 37

CÓDIGO DE RAZÓN 73.- TARJETA VENCIDA.
CONDICIONES:
B.- Un Receptor de Pagos completó una transacción con una tarjeta vencida y no obtuvo autorización.
Exhibit (Anexo 8)
c) El Receptor de Pagos obtuvo autorización vía voz y/o electrónica, (enviar copia del log de
autorizaciones certificado).
d) La tarjeta no estaba vencida al momento de la transacción.
C.R. 73 2/2
Capítulo II 38

CÓDIGO DE RAZÓN 74.- PRESENTACIÓN EXTEMPORÁNEA
CONTRACARGO DIRECTO POR COMPUTADOR - TIEMPO: 100 DÍAS NATURALES

A.- El Adquirente no procesó la transacción dentro del tiempo límite requerido.
El Adquirente presentó facturación alterando la fecha de Transacción, con la finalidad de:
• Evitar el pago del costo de servicio en el proceso normal.
• Incluir facturación extemporánea en el proceso normal.
• Evitar el rechazo de la transacción en el archivo de facturación extemporánea.
En el caso de transacciones en Hoteles, la fecha de transacción es la fecha de salida
En el caso de transacciones en Renta de Autos, la fecha de transacción es la fecha de entrega a la

arrendadora.
Puede aplicar:
La penalización de acuerdo con lo establecido en el punto 28 del capítulo V (Penas Convencionales
por Incumplimiento), de este Manual Operativo.
Exhibit (Anexo 8).
Copia de Log de Autorizaciones Certificado
c) El Adquirente procesó la transacción dentro de los tiempos límites requeridos, (enviar copia del
listado verificador certificado).
d) Las transacciones corresponden a la recuperación de facturación por medio magnético

independiente (Anexo 12 o Anexo 13).
C.R. 74 1/4
Capítulo II 39

B.- El Adquirente presentó transacciones de Débito en el período de 9 a 30 días y la cuenta se

encuentra cancelada, bloqueada o embargada por orden judicial.
Exhibit (Anexo 8).
Carta del Emisor en formato libre, certificando el status de la tarjeta, firmada por alguno de los
funcionarios facultados en el Anexo 11 (Funcionarios Facultados Para Sometimiento Arbitral),
especificando mínimo los siguientes datos:

• No. de Tarjeta.
• Estatus de la Tarjeta (cancelada, bloqueada o embargada por orden judicial)
• Fecha del último cambio de estatus de la Tarjeta.
• Fecha de Proceso
a) Sin derecho a Representación, excepto si procesó abono al Tarjetahabiente o

b) Por inconsistencias de acuerdo con el Anexo 13A (Proceso de Monitoreo de transacciones de
DÉBITO, en plazo de 9 a 30 días).
Puede aplicar:
En caso de que el Emisor no proporcione la documentación de apoyo correspondiente, el Adquirente
puede solicitar directamente el arbitraje, sin cumplir el ciclo establecido en el punto 8.2.1 del
capítulo I (Manual Operativo), de este Contrato.
C.R. 74 2/4
Capítulo II 40

CONDICIONES:
C.- El Adquirente no procesó la transacción dentro del tiempo límite requerido.

El Adquirente presentó facturación alterando la fecha de Transacción, con la finalidad de:
• Evitar el pago del costo de servicio en el proceso normal.
• Incluir facturación extemporánea en el proceso normal.
• Evitar el rechazo de la transacción en el archivo de facturación extemporánea.
En el caso de transacciones en Hoteles, es la fecha de salida
En el caso de transacciones en Renta de Autos, es la fecha de entrega a la arrendadora.
Puede aplicar:
La penalización de acuerdo con lo establecido en el punto 28 del Capítulo V (Penas Convencionales
por Incumplimiento), de este contrato.
Exhibit (Anexo 8).

c) El Adquirente procesó la transacción dentro de los tiempos límites requeridos, (enviar copia del
listado verificador certificado).
d) Las transacciones corresponden a la recuperación de facturación por medio magnético
independiente, (Anexo 12 o Anexo 13).
C.R. 74 3/4
Capítulo II 41

CONTRACARGO TRADICIONAL – TIEMPO 120 DÍAS NATURALES.
CONDICIONES:
D.- El Emisor recibe reclamación del Tarjetahabiente, derivado de una Transacción extemporánea
que el Adquirente presentó a través del proceso de Intercambio normal de Facturación, así como
por lo establecido en el Anexo 12 o Anexo 13 (Recuperación de Facturación Extemporánea).
Puede aplicar:
1.- En caso de cualquier representación por causa diferente a las enlistadas en Condiciones de
Representación de este Código, el Emisor puede enviar a arbitraje sin cumplir el ciclo establecido en
el punto 8.2.1 del capítulo I (Manual Operativo), de este contrato.
2.- La penalización de acuerdo con lo establecido en el punto 28 del capítulo V (Penas Convencionales
por Incumplimiento), de este contrato.
Exhibit (Anexo 8).

Sin derecho a representar, (excepto por las causas siguientes):
a) No corresponde al Adquirente
b) Fuera del plazo establecido del código
c) Sin documentación soporte (Carta de certificación o Carta Reclamación).
d) Error en el llenado del Exhibit (Referencia, cuenta e importe).
e) La Carta Certificación del Emisor no cumple con lo señalado en el punto 4.14 del Capítulo I de
este Manual Operativo.
C.R. 74 4/4
Capítulo II 42

CÓDIGO DE RAZÓN 75.- AUTORIZACIÓN FALSA
A.- El Adquirente intercambió transacciones donde el número de autorización es falso.
Exhibit (Anexo 8)
Listado Verificador Certificado (Anexo 19)
b) Se procesó abono al Tarjetahabiente, (enviar copia del listado verificador certificado).
c) La autorización es válida, (enviar copia del log de autorizaciones certificado).
C.R. 75 1/2
Capítulo II 43

CÓDIGO DE RAZÓN 75.- AUTORIZACIÓN FALSA
CONTRACARGO TRADICIONAL – TIEMPO 120 DÍAS NATURALES POR RECLAMACIÓN

DEL TARJETAHABIENTE.
CONDICIONES:
B.- El Adquirente intercambió transacciones donde el número de autorización es falso.
Exhibit (Anexo 8)
Listado Verificador Certificado (Anexo 19)
b) Se procesó abono al Tarjetahabiente, (enviar copia del listado verificador certificado).
c) La autorización es válida, (enviar copia del log de autorizaciones certificado).
C.R. 75 2/2
Capítulo II 44

CÓDIGO DE RAZÓN 76.- PEAJE EN CARRETERAS
CONDICIONES:
A.- El Tarjetahabiente no reconoce una o más transacciones de PEAJE, las cuales se realizaron con
una diferencia menor a 5 minutos a partir de la que sí reconoce.
Exhibit (Anexo 8), indicando la(s) transacción(es) que el Tarjetahabiente sí reconoce de PEAJE
Copia del log de autorizaciones certificado del Emisor.
a) El contracargo es improcedente, (Especificar Causas y enviar evidencia).
b) Se procesó abono al Tarjetahabiente, (Enviar Copia del Listado Verificador Certificado)
C.R. 76 1/4
Capítulo II 45

CONDICIONES:
B.- El Tarjetahabiente no reconoce una o más transacciones de PEAJE.
Exhibit (Anexo 8)
b) Se procesó abono al Tarjetahabiente, (Enviar Copia del Listado Verificador Certificado).
C.R. 76 2/4
Capítulo II 46

CONDICIONES:
C.- El Tarjetahabiente no reconoce una o más transacciones de PEAJE, las cuales se realizaron con
una diferencia menor a 5 minutos a partir de la que sí reconoce.
Exhibit (Anexo 8), indicando la(s) transacción(es) que el Tarjetahabiente sí reconoce de PEAJE
Copia del Comprobante de Peaje (Anexo 27).
b) Se procesó abono al Tarjetahabiente, (Enviar copia del Listado Verificador Certificado).
C.R. 76 3/4
Capítulo II 47

CONDICIONES:
D.- El Tarjetahabiente no reconoce una o más transacciones de PEAJE.
Exhibit (Anexo 8)
Copia del Log de autorizaciones certificado del Emisor.
Copia del Comprobante de Peaje (Anexo 27).
b) Se procesó abono al Tarjetahabiente, (enviar copia del Listado Verificador Certificado).
C.R. 76 4/4
Capítulo II 48

CÓDIGO DE RAZÓN 77.- NÚMERO DE CUENTA INVÁLIDO
A.- Un Receptor de Pagos o Adquirente procesó una transacción con un número de cuenta que no
coincide con ninguno en el archivo maestro del Emisor.
Exhibit (Anexo 8)
c) Se transmitió correctamente el número de cuenta (enviar evidencia):
• Para transacciones con PEM 90, (05), (07) u (80) (Copia del log de autorizaciones certificado y/o
copia de Comprobante)
• Para transacciones con PEM diferente a 90, (05), (07) u (80) (copia de Comprobante)
C.R. 77 1/1
Capítulo II 49

CÓDIGO DE RAZÓN 79.- (COPIA) DEL PAGARÉ SOLICITADO NO RECIBIDO.
CONDICIONES:
A.- Un Emisor no recibió copia del pagaré solicitado.
Cuando se esté dentro de lo señalado en el Capítulo I (Manual Operativo), punto 3.15
Puede aplicar:
En caso de recibir una representación por la opción “f” de este código, el Emisor puede efectuar un
segundo contracargo cuando:
1.- Un Adquirente no envíe la documentación soporte establecida en el Capítulo XIV
(Contingencias).
2.- El Emisor demuestre que recibió requerimiento por parte de la CONDUSEF.
3.- El Adquirente atendió con Comprobante, el Emisor puede contracargar por otro código en un plazo
no mayor a 30 días naturales contados a partir de la fecha de la representación; aun cuando haya
vencido el plazo establecido para el nuevo código de razón. (No aplica para solicitud de pagarés
originales).
Exhibit (Anexo 8)

c) El Emisor no espero el tiempo estipulado para efectuar el contracargo.
d) El pagaré sí fue atendido en el plazo establecido, enviar detalle de la confirmación de entrega
(transacción 53) o detalle del rechazo (transacción 54).
e) Cuando se esté dentro de lo señalado en el capítulo I (Manual Operativo), punto 3.14 de este
contrato.
f) Cuando se esté dentro de lo señalado en los puntos 7 u 8 del capítulo XIV (Contingencias), anexando
información del Receptor de Pagos (Domicilio completo, teléfono y responsable del Receptor de
pagos) y Log de Autorizaciones demostrando PEM (90), (05), (07), (80) o Comprobante.
C.R. 79 1/2
Capítulo II 50

CÓDIGO DE RAZÓN 79.- (ORIGINAL) DEL PAGARÉ SOLICITADO NO
RECIBIDO.
CONDICIONES:
B.- El contracargo es presentado por documento original no recibido.
Cuando se esté dentro de lo señalado en el capítulo I (Manual Operativo), punto 3.15
Puede aplicar:
En caso de recibir una representación por la opción “g” de este código, el Emisor puede efectuar un
segundo contracargo cuando:
1.- Un Adquirente no envíe la documentación soporte establecida en el Capítulo XIV
(Contingencias).
2.- El Emisor demuestre que recibió requerimiento por parte de la CONDUSEF.
3.- El Adquirente atendió con Comprobante, el Emisor puede contracargar por otro código en un plazo
no mayor a 30 días naturales contados a partir de la fecha de la representación; aun cuando haya
vencido el plazo establecido para el nuevo código de razón. (No aplica para solicitud de pagarés
originales).
Exhibit (Anexo 8).
El Emisor anexará copia de la solicitud de la autoridad (Legal o Penal).

c) El Emisor no espero el tiempo estipulado para efectuar el contracargo.
d) No enviaron la documentación requerida, copia de la autoridad (Legal o Penal) que la solicitó.
e) El pagaré sí fue atendido en el plazo establecido, enviar detalle de la confirmación de entrega
(transacción 53) o detalle del rechazo (transacción 54).
f) Cuando se esté dentro de lo señalado en el capítulo I (Manual Operativo), punto 3.14 de este contrato.
g) Cuando se este dentro de lo señalado en los puntos 7 u 8 del capítulo XIV (Contingencias), anexando
información del Receptor de Pagos (Domicilio completo, teléfono y responsable del Receptor de
pagos) y Log de Autorizaciones demostrando PEM (90), (05), (07), (80) o Comprobante.
C.R. 79 2/2
Capítulo II 51

CÓDIGO DE RAZÓN 80.- ERROR EN PROCESO
CONTRACARGO TRADICIONAL – TIEMPO 25 DÍAS NATURALES DESPÚES DE LA

RECEPCIÓN DEL DOCUMENTO.
CONDICIONES:
A.- Un Adquirente procesó una transacción de un número de cuenta y/o importe diferente a los datos
del Comprobante que fue solicitado.
El contracargo se efectuará por la diferencia, cuando se trata de disputa del importe.
Puede aplicar:
cuando haya vencido el plazo establecido para el nuevo código de razón.
Exhibit (Anexo 8).
Copia de los estados de cuenta y/o listados verificadores certificados, donde aparece el cargo y el
siguiente estado de cuenta y/o listado verificador certificado.
Copia del Comprobante mal capturado.
b) Se procesó abono al Tarjetahabiente (enviar copia del listado verificador certificado)
c) Se procesó una o dos notas de devolución, (enviar copia del listado verificador certificado).
d) El número de cuenta y el importe son correctos. (enviar evidencias).
e) El Adquirente proporciona copia del Comprobante correcto, siempre y cuando se trate del mismo
Receptor de Pagos.
C.R. 80 1/3
Capítulo II 52


CONDICIONES:
B.- Un Adquirente procesó una nota de crédito como venta.
El contracargo se efectuará por el doble de la transacción.
Puede aplicar:
Exhibit (Anexo 8).
Copia de los estados de cuenta y/o listados verificadores certificados, donde aparece el cargo y el
siguiente estado de cuenta y/o listado verificador certificado.
Copia de la nota de devoluciones procesada como venta.

c) La transacción está bien procesada, sí corresponde a una venta.
d) El Adquirente procesó la nota de crédito con fecha posterior, enviar copia del listado verificador
certificado.
e) La representación se efectuará por un solo importe.
f) El Adquirente procesó las dos notas de devolución con fecha posterior, enviar copia del listado
verificador certificado.
g) La representación se efectuará por el doble del importe.
C.R. 80 2/3
Capítulo II 53


CONDICIONES:
C.- Un Adquirente atendió una solicitud de original o copia de documento por un importe diferente
al solicitado o con un comprobante de un adquirente distinto, con el mismo número de cuenta.
Aplica sólo cuando existan las dos transacciones cargadas al Tarjetahabiente.
El contracargo se efectuará por el total del importe del Comprobante solicitado.
Puede aplicar:
Exhibit (Anexo 8).
Copia de estados de cuenta y/o listados verificadores certificados, donde aparezcan las dos
transacciones.
Original o copia del documento proporcionado por el Adquirente con sello original o resumen Hash
en el Proceso de Digitalización de Imágenes.
c) El Adquirente proporciona copia del Comprobante correcto, siempre y cuando se trate del mismo
Receptor de Pagos.
C.R. 80 3/3
Capítulo II 54

CÓDIGO DE RAZÓN 81.- FALTA DE IMPRESIÓN
CONDICIONES:
A.- Un Receptor de Pagos no imprimió la tarjeta en el Comprobante y lo procesó sin autorización del
cliente.
Este contracargo no puede ser usado para órdenes telefónicas/correo, Comercio Electrónico, cargos
periódicos, Firma en archivo, Peaje, si hubo PEM 90, (05), (07) u (80) o transacción no Show.
Exhibit (Anexo 8).
c) El Comprobante contiene impresión.
d) Se trata de una transacción: órdenes telefónicas/correo, Comercio Electrónico, cargos periódicos,

Firma en Archivo, Peaje, no show, depósito por anticipado.
e) Hubo PEM 90, (05), (07) u (80), enviar copia del log de autorizaciones certificado.
f) No aplica para transacciones de Débito no embozado.
C.R. 81 1/1
Capítulo II 55

CÓDIGO DE RAZÓN 82.- PROCESO DUPLICADO
CONTRACARGO DIRECTO – TIEMPO 100 DÍAS NATURALES
CONDICIONES:
A.- La misma transacción fue procesada más de una vez por el mismo Adquirente, mismo Receptor
de Pagos, mismo importe.
Exhibit (Anexo 8)
Listado Verificador Certificado (Anexo 19) de las transacciones.
b) Se procesó abono al Tarjetahabiente en fecha posterior, (enviar copia de listado verificador

certificado).
c) Se trata de consumos diferentes, enviar copia de Comprobantes.
C.R. 82 1/7
Capítulo II 56

CONTRACARGO DIRECTO – TIEMPO 100 DÍAS NATURALES
CONDICIONES:
B.- La misma transacción fue procesada más de una vez por diferentes Adquirentes, el contracargo
se efectúa al segundo Adquirente.
Puede aplicar:
El Emisor puede emplazar directamente al primer Adquirente, sin que tenga que cumplir el ciclo de
contracargos señalado en el punto 8.2.1 del Capítulo I (Manual Operativo), cuando demuestre que la
documentación que presente en su representación es la misma recibida del segundo Adquirente.
Exhibit (Anexo 8)
Copia de los estados de cuenta y/o listado verificador donde se reflejen los cargos, debiendo mostrar
las referencias de 23 posiciones de cada Adquirente.
Copia del Log de autorizaciones certificado del Emisor de las dos transacciones.
b) Se procesó abono al Tarjetahabiente en fecha posterior, (enviar copia del listado verificador
certificado).
c) Se trata de dos consumos diferentes, enviar copia de Comprobante.
d) El contracargo se realizó al Adquirente que procesó la primera transacción.
Puede aplicar:
Este punto será válido, siempre y cuando el Emisor anexe la documentación que muestre el ciclo de
contracargos del segundo Adquirente.
C.R. 82 2/7
Capítulo II 57

CONTRACARGO TRADICIONAL - TIEMPO 120 DÍAS NATURALES
CONDICIONES:
C.- La misma transacción fue procesada más de una vez por el mismo Adquirente, mismo Receptor
de Pagos, mismo importe.
Exhibit (Anexo 8)
Copia de los estados de cuenta o listados verificadores certificados donde se refleja el primer cargo
y/o los siguientes.
Copia de los dos documentos proporcionados por el Adquirente con sello original o resumen Hash en
el Proceso de Digitalización de Imágenes.
certificado).
c) Se trata de consumos diferentes, enviar copia de Comprobantes.
C.R. 82 3/7
Capítulo II 58

CONDICIONES:
D.- La misma transacción fue procesada más de una vez por diferentes Adquirentes, el contracargo
se efectuará al segundo Adquirente.
Exhibit (Anexo 8)
Copia de los estados de cuenta y/o listado verificador donde se reflejen los cargos, debiendo mostrar
las referencias de 23 posiciones de cada Adquirente.
Copia del documento proporcionado por el primer Adquirente con sello original o resumen Hash en
Copia del documento proporcionado por el segundo Adquirente con sello original o resumen Hash en
certificado).
c) Se trata de dos consumos diferentes, enviar copia de Comprobantes.
d) El contracargo se realizó al Adquirente que procesó la primera transacción.
C.R. 82 4/7
Capítulo II 59

CONDICIONES:
E.- La misma transacción fue procesada más de una vez por el mismo Adquirente, el mismo día y
mismo Receptor de Pagos.
Cuando los cargos fueron actualizados al Tarjetahabiente.
Exhibit (Anexo 8)
Copia de los estados de cuenta donde se reflejan los cargos.
Listado Verificador Certificado (Anexo 19) de las transacciones.
certificado).
c) Se trata de dos consumos diferentes, enviar copia de Comprobantes.
C.R. 82 5/7
Capítulo II 60

CONTRACARGO TRADICIONAL - TIEMPO 120 DÍAS NATURALES DUPLICADO MASIVO

(MÁS DE 20 TRANSACCIONES)
F.- La misma transacción fue procesada más de una vez por el mismo Adquirente, de un mismo
Receptor de Pagos.
Así mismo el Emisor puede cobrar las penalizaciones señaladas en el punto 6 incisos (a) y (b) del
capítulo V (Penas Convencionales por Incumplimiento).
Exhibit (Anexo 8).
b) Se procesó abono al Tarjetahabiente en fecha posterior, en un periodo no máximo de 5 días hábiles

a partir de la fecha de intercambio, el Adquirente está obligado a notificar al Emisor dicha
corrección.
C.R. 82 6/7
Capítulo II 61

CONDICIONES:
G.- Un Adquirente atendió con una misma copia dos o más solicitudes de copia de Comprobante.
El contracargo se efectuará en Exhibit y la transferencia se efectuará a detalle.
Puede aplicar:
1.- En caso de recibir una representación, el Emisor puede efectuar un segundo contracargo por otro
código en un plazo no mayor a 30 días naturales, contados a partir de la fecha de la representación,
aun cuando haya vencido el plazo establecido para el nuevo código de razón.
No aplica para solicitud de Comprobantes originales.
2.- Cuando un Adquirente proporcione un mismo documento, en atención a dos solicitudes de

Comprobante, petición 51, el Emisor puede emplazar a arbitraje sin que tenga que cumplir el ciclo
de contracargos señalado en el punto 8.2.1 del Capítulo I (Manual Operativo) y aplicar la multa de
acuerdo con el punto 23 del capítulo V (Penas Convencionales por Incumplimiento).
Exhibit (Anexo 8).

Copia de estado de cuenta y/o listado verificador certificado.

certificado).
c) El Adquirente proporciona copia de los Comprobantes correctos, siempre y cuando se trate del
mismo Receptor de Pagos, número de cuenta e importe.
C.R. 82 7/7
Capítulo II 62

CÓDIGO DE RAZÓN 84.- FALTA DE FIRMA Y/O FIRMA EN ARCHIVO.
CONTRACARGO DIRECTO - TIEMPO 100 DÍAS NATURALES
CONDICIONES:
A.- Una Agencia de Viajes con la Operativa de firma en archivo cuenta con el Formato o Contrato de
Servicios y cargó la transacción sin la autorización del Tarjetahabiente.
Exhibit (Anexo 8).
b) Se procesó abono al Tarjetahabiente (enviar copia del Listado Verificador Certificado)
c) Presenta Formato o Contrato de Servicios, comprobante con la leyenda “Firma en Archivo o

Signature on File” y acuse de recibo de la entrega del servicio.
d) La transacción fue realizada antes de la fecha de cancelación.
C.R. 84 1/6
Capítulo II 63

CONDICIONES:
B.- Un Receptor de Pagos no obtuvo firma del cliente en el Comprobante (Pagaré) y completó la
transacción.
El contracargo no procede si se trata de transacciones derivadas de: orden telefónica/correo, comercio

electrónico, cargos periódicos, firma en archivo, Autorizado con firma Electrónica (PEM 05 o 07 Chip
+ NIP), depósito por anticipado, transacciones de cargos periódicos, No Show, CAT, Peaje o Servicios
de Pago Rápido (QPS) en montos menores al señalado en el punto “K” del capítulo IV.
Exhibit (Anexo 8).
c) El Comprobante cuenta con firma.
C.R. 84 2/6
Capítulo II 64

CONDICIONES:
C.- Un Receptor de Pagos no obtuvo la firma del Tarjetahabiente en el Formato o Contrato de

Servicios para la Operativa de Firma en Archivo y completó la transacción.
Exhibit (Anexo 8).
c) El Receptor de Pagos cuenta con Registro de Firma en Archivo, (enviar copia del el Formato o
Contrato de Servicios.
C.R. 84 3/6
Capítulo II 65

CONDICIONES:
D.- Una Agencia de Viajes con la Operativa de firma en archivo cuenta con el Formato o Contrato de
Servicios y cargó la transacción sin la autorización del Tarjetahabiente.
Exhibit (Anexo 8).
C.R. 84 4/6
Capítulo II 66

CONDICIONES:
E.- El Adquirente no envió completa la documentación copia del Formato o Contrato de Servicios o
Copia del Comprobante con la leyenda Firma en Archivo y/o Signature on File y Copia del Acuse de
Recibo).
Exhibit (Anexo 8) especificando la documentación faltante.

certificado).
c) Anexar documentación faltante.
C.R. 84 5/6
Capítulo II 67

CONDICIONES:
F.- Un Receptor de Pagos con la Operativa de Servicio de Pago Rápido (QPS), presentó el
Comprobante sin la leyenda “Autorizado sin Firma”.
El contracargo no procede si se trata de transacciones con (PEM 05 o 07)
Exhibit (Anexo 8).
c) El Comprobante cuenta con firma.
d) El Comprobante si contiene la leyenda “Autorizado sin Firma” (Impresión en línea, manual y/o
sello).
C.R. 84 6/6
Capítulo II 68

CÓDIGO DE RAZÓN 85.- DEVOLUCIÓN NO PROCESADA/VENTA
FRUSTRADA
CONTRACARGO DIRECTO- TIEMPO 30 DÍAS NATURALES
CONDICIONES:
A.- Un Emisor recibe confirmación de Venta Frustrada y el Adquirente/Receptor de Pagos no procesó

la devolución dentro de los 10 días hábiles siguientes a partir de la confirmación.
El importe del contracargo puede ser igual o menor al importe de la transacción.
Exhibit (Anexo 8) debiendo especificar fecha de confirmación de Venta Frustrada y el Folio del
sistema SVL con la confirmación de la venta frustrada por parte del Adquirente o Receptor de Pagos.
Impresión de la venta frustrada en el Sistema de Validación en Línea (Opcional)
b) Existe devolución procesada (enviar copia del listado verificador certificado).
C.R. 85 1/2
Capítulo II 69

CÓDIGO DE RAZÓN 85.- DEVOLUCIÓN NO PROCESADA/VENTA
FRUSTRADA
CONDICIONES:
B.- Un Receptor de Pagos emitió una Devolución y no fue procesada por el Adquirente, dentro del
plazo establecido en el punto 1 del Anexo 21 (Devoluciones).
El plazo de los días naturales se considera a partir de la fecha de suscripción de la devolución. Por lo
que el Emisor no puede contracargar antes de que se cumpla este plazo.
El importe de la devolución puede ser igual o menor al importe de la transacción.
Puede ser mayor sólo en los casos que el Emisor demuestre que existen dos o más transacciones.
Exhibit (Anexo 8)
Copia de estados de cuenta y/o listados verificadores certificados desde la fecha de la venta hasta el
actual.
Copia legible de la devolución y/o carta de aceptación de la devolución de parte del Receptor de Pagos,
en poder del Tarjetahabiente. Cuando se trate de Comercio Electrónico Autenticado, puede anexar
copia del email o comprobante electrónico proporcionado por el Receptor de Pagos. El comprobante
debe contener al menos los siguientes datos:
Número de tarjeta con la que se realizó la venta
Fecha de devolución
Importe
Afiliación que corresponda al mismo adquirente que realizó la venta.
Especificar concepto de Devolución
Cuando la devolución ampare dos o más ventas, el Emisor anotará las otras referencias en los
comentarios del Exhibit (Anexo 8).
b) La devolución fue procesada (enviar copia del listado verificador certificado).
c) El Adquirente demuestra que una o varias de las transacciones fueron contracargadas por Código
de Razón 79 (copia u original del pagaré solicitado no recibido).
C.R. 85 2/2
Capítulo II 70

CÓDIGO DE RAZÓN 86.- ALTERACIÓN DE IMPORTE.
CONTRACARGO DIRECTO – TIEMPO 100 DÍAS NATURALES.
CONDICIONES:
A.- El importe del Comprobante original fue alterado por el receptor de pagos, sin autorización del
Tarjetahabiente.
Sólo se contracarga la diferencia que resulte del importe de la transacción procesada vs. el
importe de la copia del Tarjetahabiente.
Exhibit (Anexo 8) especificando el importe real de la transacción.
Log de Autorizaciones Certificado (Anexo 18)
Copia del Comprobante en poder del Tarjetahabiente donde se demuestre la diferencia entre los
importes.
c) El Comprobante original no fue alterado, (enviar copia del mismo).
d) El Tarjetahabiente estuvo de acuerdo por escrito, con el importe alterado, (enviar copia del escrito).
C.R. 86 1/2
Capítulo II 71

CÓDIGO DE RAZÓN 86.- ALTERACIÓN DE IMPORTE.
CONDICIONES:
B.- El importe del Comprobante original fue alterado por el receptor de pagos, sin autorización del
Tarjetahabiente.
Sólo se contracarga la diferencia que resulte del importe de la transacción procesada vs. el
importe de la copia del Tarjetahabiente.
Exhibit (Anexo 8) especificando el importe real de la transacción.
Log de Autorizaciones Certificado (Anexo 18)
Copia del Comprobante en poder del Tarjetahabiente donde se demuestre la diferencia en los importes.
c) El Comprobante original no fue alterado, (enviar copia del mismo).
d) El Tarjetahabiente estuvo de acuerdo por escrito, con el importe alterado, (enviar copia del escrito).
C.R. 86 2/2
Capítulo II 72

CÓDIGO DE RAZÓN 87.- PAGARÉ PREELABORADO
CONDICIONES:
A.- Un Receptor de Pagos deposita Comprobantes de un mismo número de cuenta, previamente

elaborados sin la autorización del Tarjetahabiente.
Exhibit (Anexo 8)
Demostrar folios dentro de un rango de numeración de 100 anterior o posterior de otro Receptor de
Pagos o del Receptor de Pagos correlacionado, dentro de un periodo de 90 días naturales anteriores
o posteriores a la fecha de la transacción.
c) Demostrar que el Comprobante le corresponde al Receptor de Pagos mediante presentación de acuse

de recibo de papelería o copias de Comprobantes del Receptor de Pagos (mínimo 5) dentro del
rango establecido.
d) No debe utilizarse Comprobantes previamente contracargados que se encuentren en disputa.
e) Tarjeta falsificada no es argumento válido, por sí solo como concepto de representación para este
código.
C.R. 87 1/1
Capítulo II 73

CÓDIGO DE RAZÓN 88.- VENTA FRACCIONADA.
CONDICIONES:
A.- Un Receptor de Pagos procesó dos o más transacciones, cada una debajo del límite de piso
establecido en el anexo 16, que en total excede el límite de piso, para evitar autorización para una
sola transacción.
Exhibit (Anexo 8).
Copia de los documentos en disputa proporcionados por el Adquirente con sello original o resumen
Hash en el Proceso de Digitalización de Imágenes.
c) Los Comprobantes fueron suscritos en departamentos diferentes y/o en cajas diferentes, solo cuando
se trate de tiendas departamentales y/o en tiendas de autoservicio.
d) Las transacciones fueron operadas en terminales punto de venta, y/o con interred, lectura de banda
magnética / chip y autorización electrónica o manual, excepto cuando haya solicitado autorización
y esta fue declinada.
C.R. 88 1/1
Capítulo II 74

CÓDIGO DE RAZÓN 89.- FIRMA NO AUTORIZADA
CONDICIONES:
A.- La firma del Comprobante, difiere de la firma del panel de la tarjeta y la transacción fue procesada
sin el permiso del Tarjetahabiente.
Exhibit (Anexo 8), debiendo especificar que la tarjeta no es falsificada, robada o extraviada por la
empresa de mensajería y la firma no corresponda a la del titular y/o a sus adicionales.
Carta reclamación del Tarjetahabiente (Para este código de razón NO se acepta Carta del Emisor
certificando haber recibido reclamación del Tarjetahabiente o Medio de Registro de Solicitud de
Aclaraciones Certificado)

c) La firma coincide o es similar.
Responsabilidad del Emisor:
d) La compra fue efectuada con una tarjeta falsificada, alterada, robada, extraviada, duplicada.
El Tarjetahabiente negó haber recibido la tarjeta inicial y/o reposición.
e) Presencia del plástico en el Receptor de pagos:

La compra fue transmitida en terminal punto de venta y/o receptor de pagos con interred, cuenta con
autorización electrónica con envío de PEM (05), (07), (80), (90) o (02) por la lectura de banda
magnética, (enviar copia del log de autorizaciones certificado).
C.R. 89 1/1
Capítulo II 75

CÓDIGO DE RAZÓN 92.- RECEPTOR DE PAGOS CON ACTIVIDAD
IRREGULAR
CONTRACARGO TRADICIONAL – TIEMPO 120 DÍAS NATURALES
CONDICIONES:
A.- Los Comprobantes fueron intercambiados por un Adquirente que no ejecutó las medidas
preventivas y correctivas, referidas en el capítulo VI, punto 4 de este manual operativo.
Exhibit (Anexo 8)
Copia de la notificación del Emisor de las situaciones irregulares, con acuse de recibo del Adquirente.
b) El Adquirente presenta evidencia de haber ejecutado las acciones.
c) Las transacciones son anteriores a la fecha de notificación al Adquirente.
C.R. 92 1/1
Capítulo II 76

CÓDIGO DE RAZÓN 93.- RECEPTOR DE PAGOS BLOQUEADO
CONTRACARGO DIRECTO – TIEMPO 15 DÍAS NATURALES POR COMPUTADOR.
A.- Los Comprobantes fueron depositados por un Receptor de Pagos que ya ha sido identificado
como indeseable y fueron rechazados por el computador: cargo automático al Adquirente.
Exhibit (Anexo 8)
b) La compra se efectúo con fecha anterior a la fecha del bloqueo del Receptor de Pagos.
c) Cuando el receptor de pagos fue reconsiderado por todas las Instituciones, se representarán al
Emisor.
C.R. 93 1/2
Capítulo II 77

CÓDIGO DE RAZÓN: 93 RECEPTOR DE PAGOS BLOQUEADO
CONTRACARGO TRADICIONAL – TIEMPO 120 DÍAS NATURALES
CONDICIONES:
B.- Los Comprobantes fueron depositados por un Receptor de Pagos bloqueado cuya fecha de
transacción es posterior a la fecha de efectividad del bloqueo.
Exhibit (Anexo 8) debiendo especificar la fecha del bloqueo.
Acuse de recibo de la notificación del bloqueo
c) Cuando el receptor de pagos fue reconsiderado por los tres sistemas, se representarán al Emisor.
d) La compra se efectuó con fecha anterior a la fecha de bloqueo del Receptor de Pagos.
C.R. 93 2/2
Capítulo II 78

CÓDIGO DE RAZÓN 94.- CANCELACIÓN DE RESERVACIÓN
GARANTIZADA, CARGOS DEMORADOS Y/O PAGO POR OTROS MEDIOS.
CONDICIONES:
A.- Un hotel o compañía de renta de autos cargó a la cuenta de un Tarjetahabiente, después de la

Cancelación de la Reservación Garantizada.
Exhibit (Anexo 8).
Solicitud de Aclaraciones (Certificado) o Carta reclamación del Tarjetahabiente, informando, fecha,
hora y número de reporte de confirmación de la cancelación y/o copia de la carta de cancelación que
presentó el Tarjetahabiente al receptor de pagos.
Proporcionar documentación que soporte la cancelación

c) El Tarjetahabiente nunca canceló por escrito o telefónicamente la reservación garantizada (enviar
evidencia).
d) Enviar listado de cancelaciones del receptor de pagos de la fecha que indica el Tarjetahabiente o
carta del Receptor de Pagos donde informe que el Tarjetahabiente nunca canceló, la carta deberá
contener membrete o logotipo, firma y nombre del responsable del Receptor de Pagos y número
de afiliación.
e) El cargo por no show es de acuerdo a las políticas de reservación y cancelación del establecimiento,
para lo cual el receptor de pagos debe proporcionar carta membretada y firmada por un responsable.
Manual Operativo.
C.R. 94 1/9
Capítulo II 79

CONDICIONES:
B.- El Tarjetahabiente no solicitó una reservación garantizada ni participó en la transacción.
Exhibit (Anexo 8).
Solicitud de Aclaraciones (Certificado) o Carta reclamación del Tarjetahabiente, manifestando que no
ha solicitado reservación al Receptor de Pagos.
c) Enviar carta del Receptor de Pagos con logotipo o membretada, que contenga datos generales del
Tarjetahabiente, teléfono, nombre del Tarjetahabiente, número de tarjeta y fecha de vencimiento o
cuando se trate de servicios no prestados por contingencia conforme a lo señalado en el punto 8
del Capítulo XIV, presentando las opciones ofrecidas al tarjetahabiente.
d) El cargo por no show será de acuerdo a las políticas de reservación y cancelación del
establecimiento, para lo cual el receptor de pagos deberá proporcionar carta membretada y firmada por
un responsable o por contingencia conforme a lo señalado en el punto 8 del capítulo XIV, presentando
las opciones ofrecidas al tarjetahabiente.
e) La Carta Certificación del Emisor no cumple con lo señalado en el punto 4.14 del capítulo I del
Manual Operativo.
C.R. 94 2/9
Capítulo II 80

CONDICIONES:
C.- El Tarjetahabiente sí se hospedo en la misma ciudad el mismo día, misma cadena y le están
cargando un no show.
El contracargo procede únicamente por el no show.
Exhibit (Anexo 8).
Solicitud de Aclaraciones (Certificado) o Carta reclamación del Tarjetahabiente describiendo haber
recibido dos cargos.
c) Proporcionar factura y/o Comprobante firmado por el Tarjetahabiente.
d) No procede como evidencia un Comprobante o factura de no show, (a excepción de dos

reservaciones en la misma cadena).
e) El cargo por no show será de acuerdo a las políticas de reservación y cancelación del
establecimiento, para lo cual el receptor de pagos deberá proporcionar carta membretada y firmada
por un responsable.
f) La Carta Certificación del Emisor no cumple con lo señalado en el punto 4.14 del capítulo I del
Manual Operativo.
C.R. 94 3/9
Capítulo II 81

CONDICIONES:
D.- El Tarjetahabiente sí consumió en el establecimiento, pero pagó la cuenta por otros medios,
(aplica para todos los Receptores de Pagos).
Exhibit (Anexo 8).
Solicitud de Aclaraciones (Certificado) o Carta reclamación del Tarjetahabiente describiendo la forma
de pago, (anexar comprobante de pago por otro medio).
Copia del estado de cuenta y/o listado verificador certificado, evidenciando los dos cargos.
c) Copia del Comprobante donde demuestre que el Tarjetahabiente pago con la tarjeta.
d) No procede como evidencia un Comprobante o factura de no show.
Manual Operativo.
C.R. 94 4/9
Capítulo II 82

CONDICIONES:
E.- Un hotel o compañía de renta de autos cargó a la cuenta de un Tarjetahabiente, después de la

Cancelación de la Reservación Garantizada.
Exhibit (Anexo 8).
Solicitud de Aclaraciones (Certificado) o Carta reclamación del Tarjetahabiente, informando, fecha,
hora y número de reporte de confirmación de la cancelación y/o copia de la carta de cancelación que
presentó el Tarjetahabiente al receptor de pagos.

c) El Tarjetahabiente nunca canceló por escrito o telefónicamente la reservación garantizada (enviar
evidencia).
d) Enviar listado de cancelaciones del receptor de pagos de la fecha que indica el Tarjetahabiente o
carta del Receptor de Pagos donde informe que el Tarjetahabiente nunca canceló, la carta deberá
contener membrete o logotipo, firma y nombre del responsable del Receptor de Pagos y número
de afiliación.
por un responsable.
Manual Operativo.
C.R. 94 5/9
Capítulo II 83

CONDICIONES:
F.- El Tarjetahabiente no solicitó una reservación garantizada ni participo en la transacción.
Exhibit (Anexo 8).
Solicitud de Aclaraciones (Certificado) o Carta reclamación del Tarjetahabiente, inconformando el
cargo.
c) Enviar carta del Receptor de Pagos con logotipo o membretada, que contenga datos generales del
Tarjetahabiente, teléfono, nombre del Tarjetahabiente, número de tarjeta y fecha de vencimiento o
cuando se trate de servicios no prestados por contingencia conforme a lo señalado en el punto 8
del Capítulo XIV, presentando las opciones ofrecidas al tarjetahabiente.
d) El cargo por no show será de acuerdo a las políticas de reservación y cancelación del
establecimiento, para lo cual el receptor de pagos deberá proporcionar carta membretada y firmada por
un responsable o por contingencia conforme a lo señalado en el punto 8 del capítulo XIV, presentando
las opciones ofrecidas al tarjetahabiente.
e) La Carta Certificación del Emisor no cumple con lo señalado en el punto 4.14 del Capítulo del
Manual Operativo.
C.R. 94 6/9
Capítulo II 84

CONDICIONES:
G.- El Tarjetahabiente sí se hospedó en la misma ciudad el mismo día, misma cadena y le están
cargando un no show.
El contracargo procede únicamente por el no show.
Exhibit (Anexo 8).
de pago, anexar comprobantes de pago por otro medio.
c) Proporcionar factura o nota que no liquidó el Tarjetahabiente, (el servicio no liquidado debió ocurrir
dentro del periodo de estancia en el hotel).
por un responsable.
Manual Operativo.
C.R. 94 7/9
Capítulo II 85

CONDICIONES:
H.- El Tarjetahabiente sí consumió en el establecimiento, pero pagó la cuenta por otros medios,
(aplica para todos los Receptores de Pagos).
Exhibit (Anexo 8).
de pago, (anexar comprobante de pago por otro medio).
Anexar copia del Comprobante en poder del Adquirente, con sello original o resumen Hash en el
Proceso de Digitalización de Imágenes.
Copia del estado de cuenta y/o listado verificador certificado que muestre el cargo.
c) Copia del Comprobante donde demuestre que el Tarjetahabiente pagó con la tarjeta.
Manual Operativo.
C.R. 94 8/9
Capítulo II 86

CONDICIONES:
I.- Un Tarjetahabiente reclama por haber recibido un cargo demorado.

La autorización del cargo demorado no fue solicitada por el Receptor de Pagos dentro de los 3 días
naturales siguientes a la fecha de pago del Tarjetahabiente.
Exhibit (Anexo 8).
Solicitud de Aclaraciones (Certificado) o Carta reclamación del Tarjetahabiente, donde especifique no
reconocer el cargo.
Estado(s) de cuenta y/o listado verificador donde se muestren los cargos.
CONDICIONES PARA LA REPRESENTACÓN: 30 DÍAS NATURALES
c) El cargo se presentó en tiempo, de parte del Receptor de Pagos.
d) Carta membretada del Receptor de Pagos, describiendo los cargos y firmada por el responsable en
turno.
e) Carta de aceptación de los cargos de parte del Tarjetahabiente.
f) Tratándose de cargos por firma de responsiva de algunos servicios, (enviar evidencia).
g) La Carta Certificación del Emisor no cumple con lo señalado en el punto 4.14 del Capítulo I del
Manual Operativo.
C.R. 94 9/9
Capítulo II 87

CÓDIGO DE RAZÓN 95.- DEPOSITO POR ADELANTADO
CONDICIONES:
A.- Un Receptor de Pagos cargó a la cuenta del Tarjetahabiente una transacción por depósito por
adelantado cuando:
El Tarjetahabiente canceló la reservación.
Exhibit (Anexo 8).
Carta del Emisor certificando haber recibido reclamación del Tarjetahabiente, Medio de Registro
de Solicitud de Aclaraciones (Certificado) o Carta del Tarjetahabiente indicando fecha, hora y
número de confirmación de cancelación.
Copia de estado de cuenta y/o listado verificador certificado.

b) El Receptor de Pagos emitió y procesó un crédito (enviar copia del listado verificador certificado).
c) El número de cancelación es inválido.
d) La Carta Certificación del Emisor no cumple con lo señalado en el punto 4.14 del Capítulo I del
Manual Operativo.
C.R. 95 1/4
Capítulo II 88

CONDICIONES:
B.- Un Receptor de Pagos cargó a la cuenta del Tarjetahabiente una transacción por depósito por
adelantado cuando:
El Receptor de Pagos proveyó hospedaje alterno, pero no emitió crédito.
Exhibit (Anexo 8).
de Solicitud de Aclaraciones (Certificado) o Carta reclamación del Tarjetahabiente indicando fecha
de arribo y lugar del hospedaje alterno.

c) La Carta Certificación del Emisor no cumple con lo señalado en el punto 4.14 del Capítulo I del
Manual Operativo.
C.R. 95 2/4
Capítulo II 89

CONDICIONES:
C.- Un Receptor de Pagos cargó a la cuenta del Tarjetahabiente una transacción por depósito por
adelantado cuando:
El Receptor de Pagos no informe al Tarjetahabiente de las políticas de cancelación.
Exhibit (Anexo 8).
de Solicitud de Aclaraciones (Certificado) o Carta reclamación del Tarjetahabiente indicando que
el Receptor de Pagos no informó al Tarjetahabiente de las políticas de cancelación.

c) La Carta Certificación del Emisor no cumple con lo señalado en el punto 4.14 del Capítulo I del
Manual Operativo.
C.R. 95 3/4
Capítulo II 90

CONDICIONES:
D.- Un Receptor de Pagos cargó a la cuenta del Tarjetahabiente sin su autorización una transacción
por depósito por adelantado.
Exhibit (Anexo 8).
de Solicitud de Aclaraciones (Certificado) o Carta del Tarjetahabiente informando no haber
autorizado la transacción.

c) El Receptor de Pagos presenta información firmada por el Tarjetahabiente

d) La Carta Certificación del Emisor no cumple con lo señalado en el punto 4.14 del Capítulo I del
Manual Operativo.
C.R. 95 4/4
Capítulo II 91

CÓDIGOS DE RAZÓN
PARA
REPRESENTACIONES
Capítulo II 92

CÓDIGO DE RAZÓN 97.- ENVÍO EQUIVOCADO.
TIPO DE CONTRACARGO: TRADICIONAL 30 DÍAS NATURALES A PARTIR DE LA FECHA

DE RECEPCIÓN DEL CONTRACARGO.
CONDICIONES:
A.- El Adquirente recibió un contracargo destinado a otro Adquirente.
Devolución de toda la documentación recibida y Exhibit (Anexo 8).
C.R. 97 1/1
Capítulo II 93

CÓDIGO DE RAZÓN 98.- NO RECEPCIÓN DE DOCUMENTACIÓN DE APOYO
Y/O DOCUMENTACIÓN DE APOYO INCOMPLETA.

CONDICIONES:
A.- El Adquirente no recibió la documentación de apoyo del contracargo, o la recibida es incompleta.
Indicación de la causa de la representación y Exhibit (Anexo 8).
C.R. 98 1/1
Capítulo II 94

CÓDIGO DE RAZÓN 99.- VARIOS

CONDICIONES:
De acuerdo con las condiciones de representación del Código de Razón y opción utilizado.
Exhibit (Anexo 8) y documentación de apoyo con información adicional en su caso.
El valor de la representación deberá ser el mismo del contracargo recibido o por el importe corregido,
si ello resuelve el caso.
Anexar evidencia.
C.R. 99 1/1
Capítulo II 95

CAPÍTULO II
RESOLUCIÓN DE CONTROVERSIAS
PAGO DE TARJETAS EN EL
INTERCAMBIO
Para este capítulo, la Documentación de Apoyo es obligatoria de acuerdo con todos

los puntos que contiene cada uno de los Códigos de Razón.
En Condiciones para la representación se debe elegir la opción por la cual se

representa.
Capítulo II 96

CÓDIGO DE RAZÓN: ( 30 ) .- PAGO NO APLICADO
TIEMPO: 5 DÍAS HÁBILES DESPUÉS DEL VENCIMIENTO DE SOLICITUD DE
ACLARACIÓN
CONDICIONES:
A.- No hubo respuesta a la solicitud de aclaración dentro del plazo establecido en la normativa o el
Adquirente acepta el cargo.
No se requiere documentación de apoyo, ya que esta viajó en la solicitud.
CONDICIONES PARA LA REPRESENTACION: 5 DÍAS NATURALES
a) El contracargo es improcedente (especificar causas y enviar evidencia).

b) Fuera del plazo establecido del código de razón del contracargo.
c) No se recibió solicitud de aclaración de pago no aplicado con documentación soporte.
d) El adquirente demuestra que el pago fue procesado al Emisor enviar listado de transacciones
aceptadas.
C.R. 30 1/1
Capítulo II 97

CÓDIGO DE RAZÓN: ( 31 ) .- PAGO APLICADO PARCIALMENTE
TIEMPO: 5 DÍAS HÁBILES DESPUÉS DEL VENCIMIENTO DE SOLICITUD DE
ACLARACIÓN
CONDICIONES:
A.- No hubo respuesta a la solicitud de aclaración dentro del plazo establecido en la normativa o el
Adquirente acepta el cargo.
El contracargo será únicamente por la diferencia reclamada por el Tarjetahabiente.
No se requiere documentación de apoyo, ya que esta viajó en la solicitud.
a) El contracargo es improcedente (Especificar causas y enviar evidencia)

b) Fuera del plazo establecido del código de razón del contracargo.
c) No se recibió solicitud de aclaración de pago no aplicado con documentación soporte.
d) El adquirente demuestra que el pago fue procesado al Emisor enviar listado de transacciones
aceptadas.
C.R. 31 1/1
Capítulo II 98

CÓDIGO DE RAZÓN: ( 32 ) .- RESPUESTA NO PROCEDENTE
TIEMPO: 30 DÍAS NATURALES DESPUES DE LA RESPUESTA DE LA
SOLICITUD DE ACLARACIÓN.
CONDICIONES:
La Institución Destino no está de acuerdo con la respuesta de la Institución Origen.
22 No Acepta Cargo, la Transacción si fue intercambiada (Fecha de intercambio, Listado de
transacciones aceptadas y total de transacciones e importe del día).
23 No Acepta Cargo. Documento Ilegible (Los datos mandatarios no son legibles).
24 No Acepta Cargo. Comprobante de Pago Alterado (Listado de transacciones aceptadas).
25 No Acepta Cargo. Institución Orígen no corresponde.
26 No acepta Cargo, Petición Inválida, Pago inexistente
27 No Acepta Cargo, Aclaración duplicada (Fecha y No. de aclaración).
28 No Acepta Cargo, Imagen no corresponde
Exhibit (Anexo 8P). (Pagos)
22 Listado de Rechazos de Sintaxis
23 Envía documentación Legible
24 Listado de transacciones aceptadas donde no aparece la transacción.
25 Enviar copia del Comprobante
27 Enviar copia de los dos Comprobantes

a) El contracargo es improcedente (Especificar causas y enviar evidencia)
b) Fuera del plazo establecido del Código de Razón del Contracargo.
c) No se recibió solicitud de aclaración de Pago no aplicado con documentación soporte.
d) 22.- Envío evidencia del pago por misceláneo.
e) 23.- Fecha de aplicación del pago.
f) 24 y 26.- Enviar Comprobante Original
g) 25.- La Institución Origen debe proporcionar evidencia de que el pago si fue procesado
correctamente.
h) 27.- Listado Verificador donde se reflejan los dos pagos o información del pago por misceláneo.
i) 28.- Enviar Listado Verificador donde se aplicó el pago.
C.R. 32 1/1
Capítulo II 99

CÓDIGO DE RAZÓN
PARA
REPRESENTACIONES
PAGO DE TARJETAS EN EL INTERCAMBIO
Capítulo II 100

CÓDIGO DE RAZÓN 96.- VARIOS

CONDICIONES:
De acuerdo con las condiciones de representación del Código de Razón 32 (Respuesta no Procedente)
y opción utilizada.
Documentación de apoyo de acuerdo con la opción utilizada.
C.R. 96 1/1
Capítulo II 101

CAPÍTULO III
VALIDACIONES
Las Instituciones participantes emisoras y adquirentes aplicaran las

validaciones contenidas en este Capítulo.
Los códigos de validación contenidos en este capítulo deben aplicarse a

las operaciones intercambiadas y se tendrá un plazo de hasta cinco días
naturales para su presentación, de lo contrario ya no puede utilizar los
códigos aquí descritos.
Capítulo III 1
Contrato de Intercambio Domestico CID Versión 6.2 – diciembre 01, 2021
OPERATIVA VENTAS
VALIDACIÓN: ( 01 ).- NÚMERO DE AFILIACIÓN
El adquirente presentó sus transacciones y no se intercambian por:
Las ocho posiciones son igual a “0” ceros.
Las ocho posiciones son igual a espacios en blanco.
No existe en la Base de Datos Única de Receptores de Pagos.
VALIDACIÓN: ( 02 ) .- NUMERO DE CUENTA
Las 16 posiciones son igual a “0”
Una o las 16 posiciones son igual a espacios en blanco
No es un prefijo sujeto a intercambio (BIN de marca propia)
El digito verificador es erróneo.
No es un prefijo registrado en la tabla de bines del Bin Manager para

intercambio
VALIDACIÓN ( 03 ).- NÚMERO DE TRANSACCIÓN INVÁLIDO
El adquirente o emisor presentó sus transacciones y no se intercambian

por:
Una o las 2 posiciones son igual a espacios en blanco.
Las 2 posiciones contienen un valor diferente a:
Venta (Código de transacción 05)

Devolución (Código de transacción 06)
Misceláneos (Código de transacción 10)
Misceláneos (Código de transacción 20)
Contracargo (Código de transacción 15)
Contracargo (Código de transacción 16)
Capítulo III 2
Petición Original (Código de transacción 51)
Petición Copia (Código de transacción 52)
Confirmación (Código de transacción 53)
Rechazo de petición (Código de transacción 54)
VALIDACIÓN ( 04 ).- FORMATO DE ARCHIVO
Debe contener un Header y un Trailer
La fecha de recepción del archivo debe ser igual a fecha de header del
archivo
La longitud del archivo debe ser de 350 posiciones
Validación del BIN en el header
Si las cifras de control en el Trailer no cuadran no es motivo de rechazo.
VALIDACIÓN ( 05 ).- ERROR EN IMPORTE

por:
Todos los campos deben ser numéricos
Las transacciones sean mayor $0.00
VALIDACIÓN ( 06 ).- NÚMERO DE AUTORIZACIÓN (Alfanumérico)
Una o las 6 posiciones son espacios en blanco.
Una o las 6 posiciones son caracteres especiales (#, $, %, &.)
Capítulo III 3
VALIDACIÓN ( 07 ).- FECHA DE TRANSACCIÓN

por:
El formato sea diferente a “MMDD” numérico.
Transacciones de venta que excedan los tiempos de proceso normal de

presentación tanto debito como crédito indicados capítulo I “Reglas
Operativas POS” numeral 2 “Límite de tiempo para presentación de
transacciones a intercambio” más 1 día natural.
VALIDACIÓN ( 08 ).- NÚMERO DE REFERENCIA

por:
Los prefijos son diferentes a los detallados en el (Anexo 9).
La fecha juliana sea diferente al formato “ADDD”.
La posición 12 a la 22, los campos sean igual a “0” o espacios en blanco.
Que el dígito verificador de la referencia sea erróneo.
La referencia inicie con un digito diferente a “7”
VALIDACIÓN ( 09 ).- NÚMERO DE CÓDIGO DE RAZÓN Y/O CÓDIGO DE

USO.

por:
El código de razón sea diferente a:
COD. DE USO
Transacción 05 Código de R. 00 y código de uso 1
Transacción 06 Código de R. 00 y código de uso 1
Transacción 05 Código de R. 97, 98, 99 y código de uso 2
Transacción 06 Código de R. 97, 98, 99 y código de uso 2
Transacción 10 Código de R. 100 al 112
Transacción 15 Código de R. 41 al 95 y código de uso 1 o 2
Capítulo III 4
Transacción 16 Código de R. 41 al 95 y código de uso 1 o 2
Código de uso 1 para transacción original (primeras presentaciones

y contracargos.
Código de uso 2 para representaciones y segundos contracargos
Transacción 51, 52, 53, 54 Código de R. 00

Transacción 05, 06, 15, 16, 51, 52, 53, 54 Código de R. 01 al 11
Transacción 54 Código de R. 33 al 40
LAS TRANSACCIONES 51, 52, 53, 54 SON NO MONETARIAS
VALIDACIÓN ( 10 ).- NOMBRE DEL RECEPTOR DE PAGOS
La primera o las 25 posiciones sean igual a espacios en blanco, o contenga

caracteres diferentes a lo establecido en el Capítulo XII (Control y
Administración de Afiliaciones).
VALIDACIÓN ( 11 ).- TRANSACCIONES DUPLICADAS
Se validan VENTAS, que previamente hayan sido aprabadas y liquidadas

en el intercambio, cuyos valores en los siguientes campos sea igual:
TIPO DE TRANSACCIÓN
FECHA DE TRANSACCIÓN
CUENTA
IMPORTE
AUTORIZACIÓN
AFILIACIÓN
VALIDACIÓN ( 23 ) .-CATEGORÍA DE RECEPTOR DE PAGOS
El adquirente presentó sus transacciones de ventas y/o devoluciones, y no

se intercambian por:
Las 2 posiciones tienen un valor diferente a los señalados en el Capítulo

XII “Control y Administración de Afiliaciones”.
Capítulo III 5
VALIDACIÓN ( 25 ) .- IMPORTE CUOTA / TASA INTERCAMBIO
El adquirente presentó sus transacciones de venta y devoluciones con

código de uso 1 y no se intercambian por:
Una o las 12 posiciones son igual a espacios en blanco
Una o las 12 posiciones no son numéricas
OPERATIVA PAGOS INTERBANCARIOS
VALIDACIÓN ( 12 ) .- NÚMERO DE CUENTA
La Institución presentó sus transacciones y no se intercambian por:
No es prefijo sujeto a intercambio
El dígito verificador de la Cuenta es erróneo.
VALIDACIÓN ( 13 ).- NÚMERO DE TRANSACCIÓN INVÁLIDO
Las 2 posiciones contienen un valor diferente a:
08, 18 (Solo Archivo de Aclaraciones).
VALIDACIÓN ( 15 ).- ERROR EN IMPORTE
Capítulo III 6
VALIDACIÓN ( 16 ).- FECHA DE TRANSACCIÓN
El formato sea diferente a “MMDD” numérico.
VALIDACIÓN ( 17 ).- NÚMERO DE REFERENCIA

por:
El dígito indicador de proceso es diferente a “7”
Los prefijos son diferentes a los detallados en el (Anexo 9P).
La fecha juliana sea diferente al formato “ADDD”.
La posición 12 a la 22, los campos sean igual a “0” o espacios en blanco.
Que el dígito verificador de la referencia sea erróneo.
VALIDACIÓN ( 18 ).- NÚMERO DE CÓDIGO DE RAZÓN
El código de razón sea diferente a:
Transacción 08 Código de R. 00 12 13 15 16 17
VALIDACIÓN: ( 19 ) .- BANDERA DE TIPO DE PAGO
La posición tiene un valor diferente a:
0 = Otro (Default)
1 = En efectivo
Capítulo III 7
OPERATIVA INTERCAMBIO DE IMÁGENES
VALIDACIÓN: (26).- VALOR HASH INVÁLIDO
La cámara emisora/adquirente presentó sus transacciones (Imágenes) y

alguna de las Imágenes fueron rechazadas por:
El Valor HASH del archivo de imagen recibido y almacenado NO es idéntico

al del Origen.
La cámara emisora/adquirente debe rechazar con el código de transacción

recibido.
VALIDACIÓN: (27).- ARCHIVO ELECTRÓNICO CONTIENE

TRANSACCIONES NO SOPORTADAS EN EL ARCHIVO DE IMÁGENES
(Sólo aplica para el proceso de atención de documentos, transacción 53)

El adquirente presentó sus transacciones (Datos) y fueron rechazadas por:
El Archivo Electrónico de datos recibido y almacenado contiene

información (Transacciones) NO identificadas o soportadas en el Archivo
Electrónico de Imágenes.
La cámara emisora / Adquirente debe rechazar con el código de

transacción recibido.
VALIDACIÓN: (29).- NUMERO DE FOLIO UNICO EMISOR.

La cámara emisora/adquirente presentó sus transacciones (Datos e
Imágenes) y se rechazan por:
Folio no cumple con la estructura definida para el intercambio de Imágenes.
La cámara debe rechazar con el número de folio único Emisor recibido.
Capítulo III 8
VALIDACIÓN: (31).- ARCHIVO ELECTRONICO DE IMAGEN REBASA EL
TAMAÑO ESPECIFICADO.
La cámara Adquirente presentó sus transacciones (Imágenes) y fueron

rechazadas por:
El Archivo de Imagen Electrónico recibido rebasa el tamaño especificado

(1Mb) por transacción.
VALIDACIÓN: (32).- ARCHIVO DE IMAGEN ELECTRONICO NO CONTIENE

EL FORMATO ESTABLECIDO.
La cámara Emisora / Adquirente presentó sus transacciones (Imágenes) y

fueron rechazadas por:
El Archivo de Imagen Electrónico no contiene el formato establecido (PDF).
Capítulo III 9
CAPÍTULO IV
COSTO DE SERVICIOS

COSTO DE SERVICIOS
1. La liquidación de los costos de servicio, invariablemente deben ser
enviadas en el Intercambio Doméstico vía misceláneo, transacción 10 con el
código que corresponda de acuerdo a lo detallado en el Anexo 5 “Detalle de
Miscelaneos” de este contrato, todos los cobros deben efectuarse a más tardar
a los 15 días naturales, contados a partir de la fecha del proceso que les dio
origen.
2. Al cobro de los siguientes conceptos se les debe adicionar su correspondiente

I.V.A. y/o cualquier otro que lo sustituya o complemente.
A) Importe para solicitud de Comprobantes, no impresión “Informativo”

del mismo o no solicitar firma: $ 250.00, de acuerdo a lo
señalado en los puntos 3.8 y 3.23 del Capítulo I (Reglas
Generales).
B) Copias y originales de Comprobante(s) de venta no

mayores a 180 días naturales, contados a partir de
(fecha de intercambio a fecha de solicitud).
Comprobante(s) de venta operados en terminales

punto de venta ( P.O.S. ) y Comprobante(s) de venta
transmitidos en interred:
Incentivos por oportunidad: Copia Original
De 01 a 10 días naturales $ 393.00 $ 796.00
Comprobante(s) de venta, planchados

tradicionalmente:
Incentivos por oportunidad: Copia Original
C) Cobro al Emisor por solicitud de autorización. $ 0.30

Únicamente aplica para transacciones de débito en
interredes.
D) Por atención oportuna de cualquier requerimiento

unitario de Buena Fe, de 1 a 15 días naturales. $ 280.00
(No aplica para facturación extemporánea ni para
atención de pagares mayores a 180 días).
E) Por atención oportuna de cualquier requerimiento unitario

de Buena Fe, de 16 a 30 días naturales. $ 186.00

F) Por atención de cualquier requerimiento unitario de $ 0.00

Buena Fe, mayor a 30 días naturales.
G) Costo por recuperación de Tarjetas $205.00
H) Crédito:
Por Gastos de Operación en Presentación de
Facturación de 31 a 120 y extemporáneas de 121
a 320 días (por transacción), incluye transacciones
rechazadas. 31 a 120 días $ 43.00
121 a 320 días $ 64.00
Débito en Línea:
Transacciones que se encuentren en el periodo de
9 a 30 y extemporáneas de 31 a 120 días naturales
después de la fecha de suscripción del documento,
incluye transacciones rechazadas.
Estos costos no aplican para transacciones por

concepto de Devolución. $ 67.00
Evento Masivo, mas de 20,000 transacciones Crédito o

Débito:
Procesamiento masivo de facturación extemporánea, aplica lo
siguiente:
• Máximo 3 eventos al año (Enero-Diciembre) por

Institución Adquirente.
1er. Evento $ 593,766.00
2do. Evento $1,187,533.00
3er. Evento $1,781,300.00
- Evento posterior a los tres establecidos aplica el
costo normal por transacción extemporánea.
I) Por atención de Copias y/o Originales de

Comprobante(s) de venta mayores a 180 días naturales,
contados a partir de (fecha de intercambio a fecha de
solicitud). $ 937.00
J ) Por respuesta favorable de reembolso de

una Institución receptora a un Pago
realizado por el Tarjetahabiente $ 64.00

K ) Monto máximo autorizado para operar
transacciones bajo la Operativa de Pagos “Informativo”
Rápidos (QPS) $ 250.00 por transacción y
hasta $ 2,000.00 por día.
L ) Cuota de Intercambio fija para todos los

comercios del esquema Débito-Cuota que $ 1.24
paga el Adquirente al Emisor.
Costo de Servicios no compensables.
M ) Por Arbitraje Dictaminado $ 2,671.00
N) Por Retiro de Arbitraje $ 1,336.00
O ) Por Declinación de Arbitraje $ 667.00
Para los incisos C y L, el incremento por inflación solo aplica previa autorización de Banco de México.

CAPÍTULO V
PENAS CONVENCIONALES
POR INCUMPLIMIENTO
Capítulo V
PENAS CONVENCIONALES POR INCUMPLIMIENTO
Las Cámaras de Compensación deben aplicar las penalizaciones determinadas, las
Instituciones no pueden rechazar ninguna multa aplicada, por lo que la anulación o
devolución de una penalización requiere autorización del Comité de Tarjetas.
El plazo máximo para poder ejercer el derecho de cobrar una penalización es de 6

días hábiles a partir del día siguiente hábil del evento que le de origen, cualquier
penalización que rebase el plazo puede ser devuelta por la parte afectada en un
plazo no mayor de 6 días hábiles.
Al cobro de los siguientes conceptos se les deberá adicionar su correspondiente

I.V.A. y/o cualquier otro que lo sustituya o complemente.
1. Solicitar Copia de Comprobantes con Datos Erróneos:

El Emisor solicita copia de Comprobante con datos
erróneos, (número de cuenta y/o importe y/o número de
referencia), el Adquirente penalizará un importe de:
(por solicitud errónea). $ 164.00
2. Solicitar Copia de Comprobantes por Duplicado:

El Emisor solicita copia de Comprobante por duplicado,
el Adquirente penalizará un importe de: $ 164.00
(por solicitud duplicada).
3. Solicitar Comprobantes con Antigüedad mayor a lo

establecido:
El Emisor solicita Comprobantes con antigüedad mayor
a lo establecido en el punto “B” del capitulo IV (Costos
de Servicios), el Adquirente penalizará un importe de:
(por solicitud). $ 164.00
4. Solicitar Comprobantes menores al Costo Establecido:
El Emisor solicita Comprobantes menores al importe
establecido en el punto “A” del capítulo IV (Costos de
Servicios), el Adquirente penalizará un importe de: $ 164.00
(por solicitud).
5. Duplicidad de Contracargos y Representaciones:
Una de las Partes duplica contracargos y/o
representaciones, la contraparte penalizará un importe
de: $ 164.00
(por transacción).
6. Duplicidad de Transacciones (Más de 20, no aplica para
rechazos o si se procesó abono dentro de los cinco días
hábiles siguientes.) :
a) Duplicados
El Adquirente duplica transacciones en el
intercambio (más de 20 transacciones), el Emisor
tiene derecho a cobrar:
Capítulo V
(por transacción) $ 164.00
b) Por Inmovilización.
Aplica al total de las transacciones duplicadas más
intereses anuales; calculados sobre el resultado del
archivo duplicado a razón de la T.I.I.E. multiplicado
por 2.5 veces, y utilizando el calculo de días naturales
transcurridos con divisor de 360.
No. días resultado de

calendario x (T.I.I.E. x 2.5) x archivo duplicado
360
Para el pago de intereses se considera la T.I.I.E. a

28 días, vigente al día en que no se liquido el
resultado de la compensación.
7. Incumplimiento del Adquirente por Actividad Punto

Común de Consumo:
En caso de incumplimiento del Adquirente a la respuesta
por concepto de actividad “punto común de consumo” en
el plazo de 30 días naturales de la recepción de la
notificación, el emisor que alerte, puede solicitar al
adquirente el bloqueo y tiene derecho a penalizar al
Adquirente con: $ 6,265.00
diarios.
8. Incumplimiento de Respuesta del Adquirente:

En caso de incumplimiento del adquirente a la
notificación de 12 días naturales, se hace acreedor a una
multa de : $ 1,251.00
diarios, a partir del día 13, por parte del emisor que
notifique, hasta que dé respuesta, con un tope máximo
de $33,000.00 (treinta y tres mil pesos m.n.)
9. Falta de notificación de un Reverso o Crédito:
Cuando el Adquirente no informe que realizó un reverso
o crédito dentro del plazo de atención del comprobante,
el Emisor tendrá derecho a cobrar: $ 267.00
10. Rechazo Improcedente:
Si una de las partes rechaza transacciones por
validación y su rechazo es improcedente, se hace
acreedor a una penalización de: $ 164.00
(por transacción)
11. DEROGADA
12. DEROGADA
Capítulo V
13. Contracargo no Localizado por Información Incorrecta:
Cuando el Emisor contracargue al Adquirente una
transacción y ésta, no pueda ser localizada porque la
información es incorrecta se sancionará al sistema
Emisor con una penalización de: $ 164.00
(por transacción) de acuerdo a lo estipulado en el
Capitulo I de (Reglas Generales) punto 4.4
14. Representación no localizada por Información

Incorrecta:
Cuando el Adquirente represente al Emisor una
transacción y ésta, no pueda ser localizada porque la
información es incorrecta, se sancionará al sistema
Adquirente con una penalización de: $ 164.00
(por transacción), de acuerdo a lo estipulado en el
Capítulo I (Reglas Generales), punto 4.4 segundo
párrafo.
No aplica para los casos en los que los datos incorrectos
de la representación, sean resultado del primer
contracargo por datos erróneos del Emisor.
15. Presentar como Facturación Nueva, Transacciones

Involucradas en un Proceso de Controversias:
Cuando un Adquirente presente como facturación nueva
o extemporánea transacciones que ya estuvieron
involucradas en un proceso de controversias, se hará
acreedor a una penalización de:
(por transacción), de acuerdo a lo estipulado en el $ 937.00
Capítulo I (Reglas Generales), punto 3.6
16. DEROGADA
17. Rechazo Improcedente de Solicitud de Comprobantes:

Cuando un Emisor demuestre un rechazo improcedente
de solicitud de Comprobante por datos erróneos, petición
duplicada, extemporáneas y/o importe menor a lo
señalado en el punto “A” del capítulo IV (Costos de
Servicios), el Adquirente se hará acreedor a una
penalización de: $ 164.00
(por transacción), de acuerdo a lo estipulado en el
Capítulo I (Reglas Generales), punto 3.15
18. Fallo en contra por un Proceso de Arbitraje:

Cuando un Emisor o Adquirente reciban un fallo en
contra, derivado de un proceso de arbitraje, se hará
(Por emplazamiento).
Capítulo V
19. Retiro de un Emplazamiento de Arbitraje:
Cuando un Emisor o Adquirente retire un
emplazamiento a Arbitraje, se hará acreedor a una
(Por emplazamiento).
20. No Presentar en Tiempo Factura por Servicios de un
mes:
a) Cuando un sistema no emita la factura por los
servicios prestados y pactados al amparo del
presente contrato, a más tardar el día 20 del mes
siguiente, se hará acreedor a una penalización de: $ 29,562.00
(Por evento).
b) En caso de un nuevo incumplimiento al plazo de 30
días naturales, la parte afectada podrá exigir el cobro
de 1.5 veces el importe señalado en el inciso a) de
esta penalización.
21. Aplicar una Devolución Fuera de Plazo:
a) Cuando un Adquirente aplique el importe de una
devolución, después de 15 días de la fecha de
suscripción de la misma o no la presente al
intercambio, se hará acreedor a una penalización
de: $ 562.00
(Por transacción).
b) Cuando un Emisor aplique el importe de una

devolución, después de 15 días de su fecha de
intercambio o no la aplique, se hará acreedor a una
(Por transacción).
22. Contracargo y Petición de Comprobante de una Misma

Transacción:
Cuando un Emisor contracargue y realice petición de
documento, o realice petición y contracargue dentro del
mismo plazo de atención de una misma transacción o
realice contracargo por código de razón 79 sin previa
solicitud de documento, se hará acreedor a una
(Por transacción), de acuerdo a lo señalado en los
puntos 3.12 y 4.18 del capitulo I de Reglas Generales.
23 Atender dos Solicitudes con un mismo Comprobante:

Cuando un Adquirente proporcione un documento en
atención a dos solicitudes, (petición 51 y/o 52), se hará
(Por transacción).
+
Capítulo V
24 Duplicar Transacciones en un Proceso de Facturación
Extemporánea:
Cuando un Adquirente presente transacciones más de
una vez en un proceso de facturación extemporánea
(anexo 12 y 13), se hará acreedor a una penalización de: $ 64.00
(Por transacción).
25. Falta de Respuesta a Solicitud de Reembolso de un

Pago de Tarjeta en el Intercambio:
Cuando un Emisor no de respuesta al Adquirente en un
plazo de 10 días naturales, a una solicitud de reembolso
de un Pago de Tarjeta en el Intercambio realizado por un
Tarjetahabiente, se hará acreedor a una penalización de: $ 00.00
26. Posteo de Transacciones Rechazadas en un proceso de

Facturación Extemporánea:
Cuando el Emisor cargue al tarjetahabiente
transacciones rechazadas al Adquirente, derivadas de
un proceso de recuperación de facturación
extemporánea, se hará acreedor a una penalización de: $ 937.00
(Por transacción).
27 DEROGADA
28. Presentar facturación alterando fecha de Transacción.

Cuando un Adquirente presente Facturación Alterando la
Fecha de Transacción, con la finalidad de:
• Evitar el pago del costo de servicio en el proceso
normal.
• Incluir facturación extemporánea en el proceso
normal.
• Evitar el rechazo de la transacción en el archivo
de facturación extemporánea.
se hará acreedor a una penalización de: $ 164.00
(Por transacción).
29. DEROGADA
30 DEROGADA
31 DEROGADA
Capítulo V
32 Incumplimiento al Contrato de Intercambio Doméstico:
Cuando un Emisor o Adquirente incumplan alguna de las
normas establecidas en el Contrato de Aceptación de
Tarjetas y sea referido a esta penalización, se hará
acreedor a lo siguiente:
a) Aplica: Amonestación
b) Aplica: $ 10,000.00 *
c) Aplica: $ 40,000.00 *
d) Aplica: $ 100,000.00 *
e) Aplica: $ 250,000.00 *
f) Aplica: $ 400,000.00 *
El Árbitro Operativo debe generar la notificación a la

Institución penalizada, así como dar instrucción a la
Cámara de Compensación contraria para que el cobro
sea aplicado.
Las Cámaras de Compensación administran los

importes de esta penalización de común acuerdo con las
Instituciones y serán utilizados según se determine en el
Comité General de Medios de Disposición.
33. Receptor de Pagos en Umbral de Riesgo:

Cuando un Receptor de Pagos sea ingresado en el
Programa de Cumplimiento y no disminuya su porcentaje
de contracargos por debajo del umbral de riesgo (2% o
10% según corresponda) durante el período de
corrección/aclaración se hace acreedor a las
penalizaciones descritas a continuación:
a) Aplica: Amonestación
b) Aplica: $ 250.00 *
c) Aplica: $ 500.00 *
d) Aplica: $ 1,000.00 *
Capítulo V
34. Emisor realiza contracargos improcedentes:
Cuando un Emisor realice contracargos improcedentes y
derivado de ello un Receptor de Pagos haya sido
ingresado en el Programa de Cumplimiento, el Emisor se
hace acreedor a devolver el importe el importe de la
penalización 33 recibido por este concepto y
adicionalmente
$ 250.00*
(Costo Operativo Adquirente) por cada contracargo que
el Adquirente demuestre como improcedente.
* Para esta penalización no aplica el incremento anual por inflación, salvo acuerdo en
contrario.
Capítulo V

CAPÍTULO VI
POLÍTICAS Y PROCEDIMIENTOS DE
SEGURIDAD CON LOS
RECEPTORES DE PAGOS
Capítulo VI 1

Objetivo
Establecer la obligatoriedad de los emisores, adquirentes y agregadores, a través de su
adquirente, en el cumplimiento de normas operativas destinadas a la mitigación de los
riesgos asociados en el uso, operación y administración de los medios de pago con
tarjeta.
1. Disposiciones Generales
Para promover el buen funcionamiento y desarrollo de la Red de Pagos con Tarjetas,

los Participantes en la Red de Pagos con Tarjeta deberán observar los respectivos
requerimientos que se señalan a continuación:
Las Instituciones participantes deben:
a) Contar con procesos, herramientas, infraestructura tecnológica y controles para

la vigilancia, detección y prevención de eventos que se aparten de los
parámetros de uso habitual de los tarjetahabientes y aceptación por parte de los
Receptores de pago, incluyendo fraudes, estableciendo requerimientos mínimos
respecto a la vigilancia, detección y prevención de eventos.
b) Dicho equipo dedicado a la prevención de fraudes de cada Institución, es
responsable de integrar sus procedimientos operativos y metodologías en la
administración de riesgo para el control de fraude, siempre y cuando incluya
como mínimo las reglas señaladas en este capítulo, así como los capítulos
relacionados al control y administración para prevención de riesgos.
2. Responsabilidad de la Unidad de Prevención de

Fraudes
• Implementar un proceso de monitoreo de transacciones.
• Contar con herramientas especializadas para la prevención y/o detección del
Fraude para una correcta administración y control del fraude.
• Contar con personal dedicado a la Prevención de Fraudes.
• Mantener un equilibrio entre las ventas y las declinaciones por medidas
preventivas.
• Participar, operar y administrar sistemas propuestos por el gremio para la
prevención del fraude tales como:
o Sistema Nacional de Alertas (SNA)
o Sistema de Validación en Línea (SVL).
Capítulo VI 2

o Sistema de Prevención Compartido (SPC)
• Compartir información de fraudes cometidos o eventos de fraude entre
emisores, adquirentes por medio de plataformas dedicadas para este fin tales
como: SNA, SVL y SPC.
• Enviar, notificar y atender solicitudes de validación, ventas frustradas a través
SVL.
3. Criterios mínimos de Monitoreo Emisor

Transacciones
Un Emisor debe identificar en la operación de sus tarjetahabientes,
transacciones fuera de parámetros habituales y realizar el análisis
correspondiente. Los siguientes ejemplos son de carácter informativo mas
no limitativo.
• Múltiples transacciones en periodos cortos de tiempo.

• Comercios distintos a los acostumbrados en la región y/o a su giro
• Fuera del horario habitual de transacción
• Importes fuera de las transacciones habituales
• Negocios en común antes y/o después de la irregularidad
detectada.
• Transacciones con decremento de importes, mismo receptor de
pagos.
Detectar Posible Punto Compromiso.
• El Emisor identifica más de una cuenta con fraude detectado y/o

patrón inusual, las cuales convergen en un mismo Receptor de
Pagos, debe generar la alerta en el SNA .
• Cuando un Emisor se adhiera a una alerta generada por otro

Emisor, no requiere un mínimo de cuentas, solo debe registrar la
información en el SNA.
• El Emisor que genera o se adhiere a una alerta, debe integrar al

reporte toda la información relacionada al fraude, que se detalla en
el punto 7 de este capítulo, para que el Adquiriente pueda analizar
y dictaminar si el Receptor de Pagos es un Punto Compromiso
Confirmado.
• El Adquirente está obligado a notificar al Emisor por el SNA el

resultado de la alerta generada incluyendo el periodo estimado de
compromiso de información, de acuerdo a lo señalado en el punto
7 de este capítulo.
Capítulo VI 3

4. Criterios mínimos de Monitoreo Adquirente

4.1 Transacciones on line y/o batch
El Adquirente debe identificar comportamientos inusuales con base al

histórico de transacciones de sus Receptores de Pagos. Para ello, se
enlistan algunos criterios mínimos, más no limitativos, que pueden variar
de acuerdo a la modalidad que se esté presentando:
• Alto número de operaciones declinadas

• Importes altos Negocios nuevos
• Mismos importes y/o similares (exceptuando cargos recurrentes).
• Frecuencia alta de transacciones fuera de horario, mismo emisor,
en cortos períodos de tiempo.
• Importes fuera del rango de facturación habitual.
• Transacciones con importes fraccionados consecutivos
• Transacciones con decremento de importes, misma tarjeta.
• Cuentas con múltiples transacciones con diferente PEM
4.2 Se recomienda, dentro de lo posible, considerar de acuerdo al giro,

zona y/o tamaño del comercio, los siguientes criterios adicionales:
• Uso repentino de cuentas extranjeras

• Giros y zonas de alto riesgo
• Transacciones PEM 80.
4.3 Monitoreo de solicitud de documentos
Incremento en el volumen de solicitud de comprobantes del Receptor de

Pagos.
4.4 Exceso de contracargos por transacciones dictaminadas como fraude
Para proteger el exceso de contracargos el adquirente debe de llevar un

control de monitoreo* a su comercio el cual se debe conformar por tres
componentes:
Capítulo VI 4

1. Periodo de notificación, el cual se debe realizar dentro de los
últimos 30 días.
2. Periodo de trabajo, el cual se lleva a cabo entre el Adquirente y sus
Receptores de pago, a fin de aplicar las medidas necesarias para
la reducción de contracargos.
3. Periodo de cumplimiento y penalización, en el cual se trasladará, a
los Receptores de Pagos, las multas correspondientes derivadas
de la falta de remediación, las cuales pueden incluir hasta la
desafiliación de Receptor de Pagos.
*Cabe mencionar que el periodo de monitoreo se apega a lo establecido

por las marcas
Niveles de % de Riesgo
Riesgo Contracargos vs Ventas
Bajo 0.75
Standard** 1
Alto 2
**Cuando el Receptor de Pagos exceda el 1% o más del monto de

contracargos contra la facturación o el 1% o más de contracargos contra
el total de transacciones, el adquirente deberá tomar acciones inmediatas
en su proceso de monitoreo de prevención de fraude y hacer la
notificación vía SNA para que el Emisor realice las acciones que
correspondan
4.5 Posible Punto Compromiso (PPC)
En caso de Alerta por Posible Punto Compromiso registrada en el SNA, el

Adquirente se obliga a realizar la investigación correspondiente sujeto a:
a) Análisis de transacciones reportadas en alerta generada por el

Emisor.
b) Visita al Receptor de Pagos y realiza revisión de instalación y
programación de la(s) terminal(es), así como el proceso de su
operación.
c) El adquirente debe dar respuesta a través del SNA en un plazo no
mayor a 10 días hábiles bancarios, de lo contrario, el Administrador
de la Base Única tiene la facultad de bloquear al Receptor de
Pagos por clave 30*.
4.6 Punto Compromiso Confirmado (PCC)

Capítulo VI 5

Una vez confirmado el Punto Compromiso, la Institución Adquirente debe tomar

acciones inmediatas para mitigar y prevenir el compromiso de datos, ejemplo
Bloqueo del Receptor de Pagos o del sub-afiliado.
Cuando el adquirente confirma y registra el punto compromiso debe bloquear el

receptor de pagos o sub-afiliado por clave 30 y debe entregar al administrador
de SNA un plan de trabajo ejecutado por un tercero especializado y autorizado
en un máximo 10 días naturales a partir de la notificación. Si el receptor de
pagos o subafiliado en la Base Única no está bloqueado por el adquiriente, este
plan de trabajo debe estar acompañado por la carta donde el adquirente se hace
responsable de las transacciones mientras se lleva a cabo la certificación de
PCI.
El administrador de SNA está facultado para bloquear al receptor de pagos o

subafiliado por clave 30, en caso de no recibir la carta en el tiempo establecido
anteriormente por parte del adquirente.
El Administrador de SNA debe ejecutar la notificación de acuerdo al Punto 7 de

este Capítulo.
Una vez que se confirme la ventana de exposición de riesgo, el administrador
notificara a los emisores que pueden iniciar el proceso de contracargo fulminante
92 (Receptor de pagos o subafiliado con actividad irregular) opción A.
Una vez que al receptor de pago se le realiza la revisión del análisis técnico de
acuerdo al incidente, debe ejecutar la revisión PCI el Agregador y/o el propio
subafiliado de acuerdo al flujo de operación estipulado en Capítulo XVII, de este
contrato.
En caso de no enviar su plan de trabajo, su carta responsiva y no estar
bloqueada la afiliación de acuerdo al Capítulo XII de este contrato el
administrador de la Base Única tiene la facultad de bloquear al Receptor de
Pagos por clave 38*
*Ver concepto de bloqueos en el Catálogo de claves de cancelación

Cap.XII
Con base al dictamen final, el adquirente tomará las siguientes acciones:
PPC Duda Razonable. - De acuerdo al análisis no se comprueba

colusión, sin embargo, existen elementos que apuntan a esta.
Acciones:
• Bloqueo preventivo (Clave 5).
• Plazo máximo para confirmar 10 días hábiles bancarios.
Capítulo VI 6

• En caso de no recibir respuesta en el tiempo estipulado, se
procederá al bloqueo con clave 30.
PCC Empleado del Receptor de Pagos Involucrado Confirmado. - de

acuerdo al análisis se determina que únicamente algún empleado es la
persona responsable.
Acciones:
• Posible denuncia de hechos por la parte afectada financieramente:
Emisor, Adquirente y/o el Receptor de Pagos.
• Ventana de contracargos al Receptor de Pagos.
PCC Dueño Involucrado. - de acuerdo al análisis se determina que el

dueño del Receptor de Pagos está coludido.
Acciones:
• Bloqueo del Receptor de Pagos, clave 30.
• Retiro de equipo de ventas señalamiento, papelería etc.
• Denuncia de hechos por parte del Emisor y/o el Adquirente.
El Receptor de Pagos está dentro de los parámetros de vigilancia y

se implementan las siguientes acciones correctivas y preventivas:
Acciones:
• Límite de piso cero.
• TPV, sin acceso manual.
• Capacitar al Receptor de Pagos.
El Receptor de Pagos ha sido cancelado y/o bloqueado a decisión y

riesgo del Adquirente e incluido en el proceso de bloqueo y
desbloqueo, señalado en el punto 8 de este capítulo.
En caso de incumplimiento del adquirente a la respuesta por concepto de

actividad “punto común de consumo” en el plazo de 30 días naturales de la
recepción de la notificación, el administrador de SNA debe notificar al Árbitro
operativo la aplicación del punto “a” de la penalización 32 y cuenta con 5 días
hábiles para dar respuesta, en caso contrario se aplicaría el punto subsecuente
la penalización 32 del capítulo V y así sucesivamente hasta aplicar el punto “f”, si
después de aplicar el punto “f” continua el incumplimiento, se expondrá el caso
en el Comité de Tarjetas para que se determinen las acciones a seguir.
a) El Adquirente puede solicitar por escrito a los Emisores, el apoyo

necesario para una investigación conjunta, manteniéndose en todo
Capítulo VI 7

momento como único responsable y coordinador de las actividades
necesarias.
b) El Área de Prevención de Fraudes Adquirente, analiza la solicitud de

reclamación contra la facturación del intercambio de las partes
involucradas en el alertamiento e informa al Emisor el resultado del
análisis de la información recibida y las acciones a ejecutar de acuerdo a
lo siguiente:
o La Unidad de Prevención de Fraudes debe recibir del

Administrador de SNA el alertamiento cuando al receptor de pagos
se le declara como PCC con una observación en caso de que
existan otros receptores de pagos asociados
4.7 Reincidencia de un Receptor de Pagos
Receptor de Pagos reincidente en actividad Posible Punto Compromiso.
Cuando el Adquirente recibe alertas o reincidentes como Posible Punto

Compromiso de un receptor de pagos, y no son atendidas en un periodo máximo
de 10 días naturales, el administrador del SNA debe bloquear la afiliación del
Receptor de Pagos con clave 38 y enviarlo al administrador de PCI.
4.8 Proceso de afiliación de un receptor de pagos
Es responsabilidad de los Adquirentes-Agregadores en su proceso de

originación o afiliación de receptores de pagos de acuerdo a los lineamientos
establecidos en el capítulo XII.
5. Seguridad de la Información
Es responsabilidad de las Instituciones cumplir con lo establecido en el
capítulo XVII PCI.
6. Análisis de la Información
La unidad de prevención de fraudes de cada Institución debe establecer y
desarrollar metodologías de análisis de información, con el objetivo de detectar
tendencias y áreas de oportunidad.
Capítulo VI 8

• Análisis e identificación de origen de fraude.

• Análisis inverso de transacciones fraudulentas.
• Identificación de punto común de compra y punto compromiso.
• Medidores de efectividad y productividad.
7. Sistema Nacional de Alertas (SNA)

Sistema mediante el cual las Instituciones notifican situaciones irregulares de acuerdo a
los parámetros establecidos en este capítulo, para implementar acciones preventivas
y/o correctivas.
El emisor notifica al adquirente, a través del Sistema Nacional de Alertas, las

situaciones irregulares para que tome acciones preventivas y/o correctivas señaladas
con anterioridad en este capítulo.
DATOS DEL ALERTAMIENTO
Afiliación: Número que identifica al Receptor de pagos.
Tipo de alerta: De acuerdo al siguiente catálogo y definiciones:
ID TIPO DE ALERTA
1 EXCESO DE CARGOS NO RECONOCIDOS CON TARJETA PRESENTE Y NO PRESENTE
2 EXCESO DE CONTRACARGOS
3 EXCESO DE FRAUDES
4 PAGARES PREELABORADOS ( Planchados)
5 POSIBLE PUNTO DE COMPROMISO.
6 ACTIVIDAD CUESTIONABLE DEL RECEPTOR DE PAGOS
7 REINCIDENCIA COMO NEGOCIO SOSPECHOSO POR ACTIVIDAD CUESTIONABLE
REINCIDENCIA EN NOTIFICACIÓN DE ALERTA COMO NEGOCIO SOSPECHOSO O EN
8
VIGILANCIA
9 TARJETAS NO RECIBIDAS OPERADAS EN UN PUNTO COMUN DE CONSUMO
10 TARJETAS CHIP OPERADAS CON BANDA
11 TARJETAS ROBADAS, EXTRAVIADAS, IDENTIDADES FICTICIAS O ROBO DE IDENTIDAD
12 “DOUBLE SWIPE”
13 EXCESO DE CARGOS PERIODICOS DIGITALES.
14 ATAQUE MASIVO DE TRANSACCIONES
ID 1. EXCESO DE CARGOS NO RECONOCIDOS CON TARJETA PRESENTE Y

NO PRESENTE
Que el Receptor de Pagos registre más del 2% de su facturación mensual de
reclamos por fraude en transacciones
ID 2. EXCESO DE CONTRACARGOS
Capítulo VI 9

Que el Receptor de Pagos rebase el 1% en montos de contracargos contra
la facturación de intercambio y cuya antigüedad no sea mayor a tres meses.
ID 3. EXCESO DE FRAUDES
Que los fraudes reportados y registrados por el emisor ante las marcas
SAFE (Master Card), TC40 (Visa), SRF (Carnet), con base a la facturación
mensual del receptor de pagos sean mayor al 3% y con antigüedad no
mayor a tres meses.
ID 4. PAGARES PREELABORADOS
Cuando el emisor detecta que una transacción es depositada por un
Receptor de Pagos por un monto diferente en la línea con un monto
diferente con el que se generó el criptograma.
ID 5. POSIBLE PUNTO DE COMPROMISO
Cuando el emisor identifique al menos dos transacciones reclamadas dentro
de los últimos 90 días en un mismo receptor de pagos.
Si algún otro emisor registra un alertamiento del mismo receptor de pagos,
el SNA envía la notificación a todos los emisores y al adquirente
correspondiente, quien deberá dar respuesta a la alerta en los plazos
establecidos en este Capítulo.
ID 6. ACTIVIDAD CUESTIONABLE DEL RECEPTOR DE PAGOS
Esta notificación se realiza conforme a actividades que el emisor identifique
como cuestionables en la operación de los Receptores de Pagos, tales
como:
• Exceso en respuestas de rechazo ( Pick up, Declinada, Referida).
• Posibles pruebas de tarjetas a través de la TPV, dispositivos móviles y
sitios de internet de venta en línea
• Posible colusión de empleados en transacciones fraudulentas.
• Engaño o estafa a tarjetahabientes, por servicios no existentes o no
prestados.
• Posible colusión del negocio en transacciones fraudulentas Incluye
Robo/Extravío.
ID 7. REINCIDENCIA COMO NEGOCIO SOSPECHOSO POR ACTIVIDAD

CUESTIONABLE
Cuando el emisor identifique transacciones legitimas reincidentes como
POSIBLE PUNTO COMPROMISO.
ID 8. REINCIDENCIA EN NOTIFICACIÓN DE ALERTA COMO NEGOCIO

SOSPECHOSOS O EN VIGILANCIA
Cuando dentro de un periodo de seis meses, el emisor reporta otro
alertamiento por operaciones de fraude o punto compromiso.
ID 9. TARJETAS INTERCEPTADAS O NO RECIBIDAS POR EL

TARJETAHABIENTE.
Capítulo VI 10

Cuando en el emisor detecta en un Receptor de Pagos, más de una tarjeta
identificadas como “No entregadas al Tarjetahabiente”.
ID 10. TARJETAS CHIP OPERADAS CON BANDA.

Cuando el emisor o adquirente detecte comercios que operan, con TPV,
transacciones de banda cuando se trata de tarjetas Chip; o bien
comercios que operen TPV sin capacidad de CHIP. Para alertar se
requiere más de una cuenta involucrada en un periodo de 30 días, se
puede reportar la alerta si las transacciones ocurrieron dentro de los
últimos 90 días.
ID 11 ROBO DE IDENTIDAD
Cuando el emisor detecta en un Receptor de Pagos más de una tarjeta
reportadas con Robo de Identidad o Identidad Ficticia.
ID 12. DOUBLE SWIPE”

Cuando una Institución detecta que un Receptor de Pagos está realizando
“Double Swipe”. El administrador debe pedir la validación por PCI al
Receptor de Pagos de acuerdo a lo señalado en el Capítulo XVII del CID.
ID 13 EXCESO DE CARGOS PERIODICOS DIGITALES
Cuando un receptor de pagos recibe por parte de uno o varios emisores,

reporte de que su comercio de servicios digitales ha sido detectado como
PCC, ya que ha generado diversos cargos periódicos a una cuenta, mismos
que no han sido reconocidos y dichos cargos coinciden con otros cargos de
algún o algunos otros comercios que también han sido reclamados por el
cliente,
El Adquirente deberá revisar con su Receptor de pagos, el motivo por el cual

se ha generado el exceso de cargos periódicos y deberá revisar si existe
alguna correlación con los comercios involucrados en el fraude.
Asimismo, deberá confirmar en el SNA el resultado de su dictamen de

investigación.
ID 14 ATAQUE MASIVO DE TRANSACCIONES
-Un Emisor recibe un ataque de múltiples transacciones con diferencia

mínima de tiempo.
-El adquirente debe realizar un bloqueo preventivo inmediato y realizar las
investigaciones correspondientes con el receptor de pagos
Capítulo VI 11

-El adquirente debe realizar un bloqueo preventivo inmediato y realizar las
investigaciones correspondientes con el receptor de pagos.
-El adquirente debe procesar de inmediato las devoluciones o aceptar un
exhibit por el total de las transacciones involucradas.
Evidencias: Es un archivo de texto separado por comas (CSV), que contiene

transacciones de evidencia relacionadas con la Alerta. La estructura del archivo es
la siguiente:
NOMBRE DEL CAMPO CONTENIDO FORMATO

Fecha Tran. Fecha de la transacción dd/mm/aaaa/
Hora Tran. Hora de la transacción hh.mm.ss
Tarjeta Número de la tarjeta Nnnnnnnnnnnnnnnn (16)
Tipo Tran. Clase numérica del tipo de Nn
transacción
Afiliación Número de afiliación Nnnnnnn(7)
Nombre Nombre comercial Aaaaaaaaaaaaaaaaaaaaaaa
Respuesta Aprobada/Declinada/…. Aaaaaaaaaaaaaaaaaaaaaaa
PEM PEM Nn
Card Capability Card Capability N
Importe Importe de la transacción Nnnnnnnnnnnnn nn
Código País Mx MX
Ciudad Cuidad o población Aaaaaaaaaaaaaaaaaaaaaa
MCC Giro Mnnn
Estatus 1= Reconocida por el TH, 0= N
Con fraude
CONECTIVIDAD
El Administrador y la Institución deben establecer un medio de conexión seguro, en

el cual la información viaje cifrada, generalmente VPN LAN to LAN IPSec o en su
defecto VPN SSL, pudiendo ser alguna otra que permita cifrar la información.
La Institución debe contar con los elementos de hardware, software e infraestructura

para establecer la comunicación con el Administrador.
La Institución puede conectarse directamente con el Administrador o mediante su

Cámara de Compensación.
ACCESO AL SNA.
La Institución, a través de su representante de Prevención de Fraudes, debe

solicitar al Administrador las claves de usuario para sus equipos de analistas,
indicando si el usuario tiene acceso de consulta y/o mantenimiento de Alertas POS,
así como consulta y/o mantenimiento del Directorio Operativo
Capítulo VI 12

El Administrador debe crear el usuario en el SNA y proporcionar directamente al
usuario las instrucciones de acceso, así como un usuario y contraseña temporal, a
más tardar un día hábil siguiente después de haber recibido la solicitud
En su primer acceso, el sistema debe solicitar al usuario cambiar su contraseña

inicial.
Cada funcionario es responsable del buen uso de su cuenta de usuario, en ningún

caso debe proporcionar su contraseña a otros funcionarios o personas.
El caso de usuarios nuevos, el Despacho entrega manual de usuario y proporciona

capacitación para el uso y manejo del SNA.
GENERACIÓN DE ALERTAS
Cuando la Institución, como resultado de su monitoreo de incidentes, detecte casos

que deban ser alertados a las otras Instituciones, debe capturar una Alerta en el
SNA.
Procedimiento de alertamiento:
a. El funcionario facultado emisor o adquirente captura el número de

afiliación del Receptor de Pagos del cual desea emitir la alerta.
b. El sistema despliega los datos generales del Receptor de Pagos de
manera informativa.
c. En caso de que la afiliación no exista el sistema despliega un mensaje
con el error correspondiente.
d. El sistema realiza una búsqueda de otras alertas con las que cuente el
Receptor de Pagos y las despliega.
e. Si el funcionario facultado emisor o adquirente detecta que su alerta está
relacionada por su tipo y periodo de riesgo con una alerta existente la
selecciona de la lista para sumarse a esta y puede editar:
• Periodo de riesgo.
• Medio de acceso.
• Observaciones.
• Anexar evidencias en un archivo de Excel.
f. Si no existe una alerta relacionada o el sistema no despliega ninguna,

continúa con la captura de los otros datos para la alerta. Debe capturar:
• Tipo de alerta.
• Periodo de riesgo.
• Medio de acceso.
• Observaciones.
Capítulo VI 13

• Anexar evidencias en un archivo de Excel.
MENSAJES DE ALERTA
Cada vez que algún funcionario emisor o adquirente genera una alerta, el SNA
envía un correo electrónico que contiene la leyenda “SNA POS se ha generado una
alerta”, el email contiene la siguiente información que permite identificar las
diferentes alertas:
• Id
• Institución que emite
• Tipo de alerta
• Medio de acceso
• Institución alertada
El mensaje del punto anterior es enviado a todas las direcciones de correo

electrónico del Directorio Operativo.
Las Instituciones, al recibir el mensaje de alerta, deben acceder al SNA a fin de

consultar la alerta y tomar las acciones de mitigación correspondientes.
REVISIÓN DE ALERTAS
Los funcionarios con privilegios de consulta de alertas de Receptores de Pagos

pueden acceder al sistema para revisar las alertas recibidas.
Cada Institución es responsable de consultar las alertas y principalmente de tomar

las acciones de prevención y mitigación del fraude en su Institución.
Para tener control de los casos que ya se han atendido o revisado, el sistema
despliega una opción para las alertas “nuevas” y las “revisadas”.
Al entrar a la opción de alertas nuevas o revisadas el sistema despliega un listado

con las alertas ordenadas por fecha de alertamiento descendente.
Del listado los funcionarios pueden seleccionar las alertas que deseen consultar
para ver su detalle.
Los funcionarios tienen la posibilidad de marcar cada alerta nueva como revisada y
viceversa, cuando una alerta se marca por un funcionario esto aplica para todos los
funcionarios de la misma institución.
Capítulo VI 14

CIERRE DE ALERTAS
El adquirente del Receptor de Pagos alertado debe atender la situación de su

Receptor de Pagos y cerrar la alerta recibida.
El cierre debe ser procesado conforme a las siguientes descripciones:
ID CIERRE DESCRIPCIÓN
1 ATENDIDO CON SU DESCRIPCION DE

LAS MEDIDAS TOMADAS Y EL
CODIGO DE ID DEL CATALOGO
ANTERIOR.
2 EMPLEADO INVOLUCRADO
3 DUEÑO INVOLUCRADO
4 CAPACITACION AL RECEPTOR DE
PAGOS
La institución adquirente cuenta con un plazo máximo de 10 días hábiles a partir de

la fecha de alertamiento para cerrar una alerta que le corresponda.
En caso de que la alerta se encuentre en estatus abierta y ya haya vencido el

tiempo, el Administrador de SNA enviará una notificación vía correo electrónico al
adquirente, con copia al emisor o emisores que generaron la alerta, incluyendo al
árbitro operativo para informar que comienza la aplicación de la penalización 32,
señalando el inciso al que se hace acreedora la Institución en incumplimiento, con
base en la siguiente tabla:
Días hábiles Penalización 32

transcurridos Capítulo V
del 1 al 10 N/A
del 11 al 20 Punto B
Capítulo VI 15

del 21 al 25 Punto C
del 26 al 30 Punto D
del 31 al 35 Punto E
a partir del dia 36 Punto F
Una vez rebasado el punto f, se presentará el caso en el Comité de Tarjeta para

revisión de impactos posibles.
Es responsabilidad del Administrador generar las notificaciones a los adquirentes,

emisores y árbitro operativo de las acciones a seguir de cada escenario por
incumplimiento.
Para tener control de los casos que ya se han cerrado, el sistema despliega una
opción para las alertas “abiertas” y las “cerradas”.
Al entrar a la opción de alertas abiertas o cerradas el sistema despliega un listado

con las alertas ordenadas por fecha de alertamiento descendente.
Del listado los usuarios pueden seleccionar las alertas que deseen consultar para
ver su detalle y en su caso cerrar la alerta.
Cuando exista más de una alerta relacionada con el mismo caso, al cerrar el
adquirente la alerta principal, el sistema debe cerrar también las alertas
relacionadas.
Cuando el emisor envíe una alerta al adquirente y el adquirente no cierra la alerta,

se responsabilizará del quebranto generado por las alertas.
REPORTES
El Sistema Nacional de Alertas POS permite generar los siguientes reportes:
• Institución que levanta la alerta

• Institución adquirente
Capítulo VI 16

• Tipo de alerta, del catálogo de tipos de alertas
• Medio de acceso
• Abiertas / Cerradas
• Fecha inicial /Fecha final de alertamiento
El resultado de los reportes puede ser exportado a Excel desde el sistema.
Concentrado
El Sistema Nacional de Alertas también permite emitir un reporte concentrado, con

las sumatorias de alertas que cumplan con los filtros configurados por el usuario:
• Institución que levanta la alerta

• Institución adquirente
• Tipo de alerta, del catálogo de tipos de alertas
• Medio de acceso
• Abiertas / Cerradas
• Fecha inicial /Fecha final de alertamiento.
DIRECTORIO
El Sistema Nacional de Alertas, cuenta con dos directorios para facilitar a los
usuarios contactar a sus contrapartes de otras Instituciones cuando lo requieran.
Directorio de funcionarios: Contiene los datos de contacto de los representantes de

Prevención de Fraudes de nivel control o decisión de Cada Institución, le pueden
dar mantenimiento y consulta los usuarios de las Instituciones con perfil
Administrador.
Directorio Operativo: Contiene los datos de contacto de las áreas operativas de

Prevención de Fraudes de cada Institución, le pueden dar mantenimiento los
usuarios de las Instituciones con perfil Administrador y puede ser consultado por
todos los usuarios. Se recomienda ampliamente que las direcciones de correo
electrónico sean buzones genéricos, no las direcciones e-mail personales de los
funcionarios.
8. Bloqueo y Desbloqueo de Receptores de Pagos
Se deben tomar las claves de bloqueo a utilizar descritas en el capítulo XII
Opciones para la generación del movimiento de bloqueo y desbloqueo:
Capítulo VI 17

§ Las instituciones capturan sus movimientos en sus sistemas internos y se
aplica de manera inmediata y en paralelo deben enviarlo al sistema de
base única de la empresa especializada para su aplicación.
Validación del movimiento.
§ En la Base Única de Receptores de Pagos el movimiento se verifica

automáticamente, aplicando las validaciones descritas en el capítulo XII
Base Única de Receptores de Pagos, dentro del apartado Validación de
Movimientos, en particular lo relativo a los movimientos:
• Bloqueo (BL)
• Reactivación (RA)
Actualización del bloqueo/desbloqueo.
Las áreas de prevención de fraudes pueden realizar una actualización del estado del
status de la afiliación:
§ Los bloqueos/desbloqueos por las áreas de Prevención de Fraudes son el

único movimiento que puede ser actualizado en el sistema de la
Institución o de la base única antes de intercambiarla.
§ Los bloqueos/desbloqueos con clave de Prevención de Fraudes deben

ser actualizados por el Despacho en la Base Única en cuanto son
aceptadas. Para las Instituciones la actualización en sus sistemas internos
debe ser:
• El mismo día si son recibidas por la Institución en días hábiles

hasta las 5:00 p.m.
• A más tardar al siguiente día hábil si son recibidas por la Institución

después de las 5:00 p.m. en días hábiles o cualquier horario en
días inhábiles
Validez de los datos de bloqueo
§ En caso de controversia entre los datos de bloqueo/desbloqueo entre

Instituciones, se toma como referencia válida los datos de la Base Única
de Receptores de Pagos.
§ Los movimientos de bloqueo/desbloqueo intercambiados y el control de

bloqueos de la Base Única tienen validez para contracargos y solución de
controversias.
Capítulo VI 18

Receptores de Pago multiadquiridos con misma afiliación
En caso de Receptores de Pago multiadquiridos con misma afiliación, el sistema

que reciba notificación de bloqueo puede requerir de forma inmediata a quien lo
inicia, documentación de apoyo que respalde la acción (el Receptor de Pagos
debe ser bloqueado).
Quien inicia el bloqueo y es requerido con documentación de apoyo, queda

obligado a responder el requerimiento en 24 horas, en caso de incumplimiento,
el segundo adquirente puede nulificar la solicitud a través del desbloqueo.
El adquirente afectado por un Receptor de Pagos, antes de iniciar el bloqueo

debe notificar por escrito al otro adquirente de la problemática a fin de que se
llegue a un arreglo durante los siguientes 30 días naturales a dicha notificación.
Para transacciones fraudulentas, el Receptor de Pagos debe ser bloqueado.
Si estos no llegan a un acuerdo para el bloqueo de un Receptor de Pagos se

escala el asunto al grupo de prevención de fraudes, permaneciendo el Receptor
de Pagos bloqueado para realizar el siguiente procedimiento:
Mostrar y evaluar, el total de ventas y fraude registrados del Receptor de Pagos.

Analizar y determinar el porcentaje global de fraude, posterior al evento, si algún
adquirente decide mantener al Receptor de Pagos que exceda los parámetros
establecidos, asume la responsabilidad de las transacciones fraudulentas
documentadas, incluyendo falsificaciones con transacciones manuales o
electrónicas que no envíen código 90, 05 u 80, en los seis meses siguientes.
Las transacciones en tránsito suscritas antes de la fecha y hora del bloqueo

deben ser aceptadas por el emisor.
La institución que inicie el bloqueo debe conservar la información soporte

durante dos años, de lo contrario pierde el derecho de bloqueo.
Es responsabilidad del Adquirente recuperar el equipo y papelería proporcionada

al Receptor de Pagos.
Las áreas de Prevención de fraudes adquirentes podrán definir un bloqueo

transaccional temporal desde sus sistemas internos por medidas precautorias a
la TPV derivado de un problema de fraude cometido y que este no afecte a las
otras TPV’s direccionadas a la misma afiliación del receptor de pagos.
9. Ventas Frustradas
Capítulo VI 19

Son transacciones autorizadas por el Emisor, dictaminadas como fraude, donde el
receptor de pagos evita la entrega del bien o servicio adquirido relacionadas por ventas
físicas o digitales.
Por lo anterior, se establece un procedimiento para realizar las devoluciones a las

tarjetas de los Emisores involucrados.
El adquirente debe promover con sus receptores de pago, se realice la devolución o

cancelación de las transacciones confirmadas como venta frustrada, evitando generar
contracargos y los trámites administrativos relacionados.
9.1 Fraude Confirmado por el Emisor
9.1.1 Si un Emisor detecta a través de sus esquemas de monitoreo una transacción como
fraude, confirmará al Adquirente o Receptor de Pagos mediante el Sistema de
Validación en Línea (SVL).
Si un Adquirente o Receptor de Pagos detecta una transacción sospechosa de

fraude puede solicitar al Emisor una validación en forma inmediata a través de la
aplicación SVL y si el Emisor confirma fraude, debe alertar al Adquirente o
Receptor de Pago a través de la misma aplicación.
9.1.2 Una vez recibida la notificación de fraude, el Receptor de Pago debe realizar las
acciones correspondientes, para intentar frustrar la venta, reteniendo las mercancías
o evitando que se proporcione el servicio vendido.
En algunos giros como los de aerolíneas, el importe de la cancelación y/o devolución

puede ser por un monto parcial o total del boleto de avión, si es que el pasajero ya
utilizó una parte del vuelo.
9.1.3 Una vez que el Receptor de Pagos ha logrado la retención de las mercancías o haber
evitado la prestación de los servicios vendidos, procede a confirmar al Emisor, a
través de la aplicación SVL, el resultado de la confirmación de venta frustrada
conforme a los siguiente:
• El Receptor de Pago/Adquirente debe procesar una devolución por los

importes correspondientes en un término no mayor a 15 días naturales.
• En caso de vencerse el plazo de los 15 días naturales para la devolución de

la transacción, el Emisor puede generar un contracargo por código de razón
85 opción “A”.
9.1.4 Una venta frustrada, no debe ser reportada como fraude a las marcas siempre y
cuando se haga la compensación (devolución) correspondiente.
En caso de que una transacción de venta frustrada sea reportada a las marcas, debe
ser eliminada a la brevedad por el Emisor y se hace acreedor a lo señalado en el
Capítulo VI 20

punto A de la penalización 32 del Capítulo V (Penas Convencionales por
Incumplimiento).
Si el Emisor reporta nuevamente un comercio a las marcas y no han transcurrido

más de 180 días naturales desde su último incumplimiento, se aplicarán los puntos
subsecuentes de la Penalización 32.
Para la aplicación de la penalización 32, es responsabilidad del Adquirente enviar al

Árbitro Operativo el reporte de fraude ante las marcas y la evidencia de la devolución
procesada o del contracargo recibido.
10. Cartas de Inconformidad

Cuando el adquirente requiera de la carta reclamación del tarjetahabiente, para
soportar alguno de los trámites descritos a continuación, debe solicitarla por
escrito al emisor y éste tiene la obligación de atenderlas en un plazo no mayor a
10 días hábiles después de recibir la petición.
• Cargo a cuenta de cheques con la posibilidad de recuperación al emisor

(debe acordar con el emisor, la forma del reembolso).
• Demostrar al Receptor de Pagos la razón del bloqueo de la afiliación.
• Atención a demanda entablada por el Receptor de Pagos en contra del

Adquirente.
El emisor puede atender la solicitud con el Medio de Registro de Solicitud de

Aclaración certificado detallado en el Anexo 30.
En caso de que el emisor no de respuesta al Adquirente en el plazo establecido

para la atención de la carta reclamación, pierde el derecho de alerta al
adquirente sobre actividad sospechosa del Receptor de Pagos en las
transacciones involucradas, para lo cual, el adquirente debe comprobar con el
acuse de recibo de notificación al emisor de la pérdida del derecho de alerta.
11. Intercambio de Información de Fraude

11.1 Durante los primeros 10 días de cada mes, los emisores de tarjetas deben
enviar información del fraude por medio de la plataforma SPC respecto al top 10
de los comercios con mayor monto y número de transacciones de fraude
separado por tarjeta presente y no presente del mes previo anterior. Para mayor
detalle referirse al manual de SPC.
Capítulo VI 21

11.2 El resultado del TOP podrá ser consultado por los participantes del gremio.
11.3 El emisor tiene la obligación de reportarlo durante los primeros 10 días del
mes.
11.4 En caso de incumplimiento de un emisor que no haya compartido la

información, no se permitirá la consulta a la información hasta que no haya
realizado el reporte.
11.5 La información del top de fraude es de uso interno de las instituciones para la
toma de acciones estrategias que permitan controlar el fraude. Por lo tanto, queda
prohibido el compartir o revelar dicha información por cualquier medio.
12. Intercambio de Documentos

En caso de que exista un detenido o una investigación en proceso por algún
delito, las áreas de seguridad o prevención de fraudes se deben coordinar para
atender las solicitudes de comprobantes originales o copia que se requieran para
tal efecto.
La petición de comprobante originales o copia que se efectúe bajo este

procedimiento no exime de la solicitud tradicional, por lo cual el adquirente debe
apoyar a las áreas de seguridad para recabar y proporcionar los comprobantes
solicitados por este conducto, en el menor tiempo posible.
Todos comprobantes originales o copia que se soliciten, se deben procesar

conforme a los tiempos, costos y penalizaciones establecidos en el Capítulo I
Manual Operativo.
13. Validaciones Emergentes

13.1 El Sistema de Validación en Línea (SVL)
Es una herramienta estándar de comunicación bidireccional, que permite realizar

validaciones emergentes de transacciones entre Emisores, Adquirentes y/o
Receptores de Pagos, priorizando y respondiendo cada solicitud de una forma
ágil, eficiente y segura.
Capítulo VI 22

Solo se atienden solicitudes de validación emergente que sean recibidas a
través de la aplicación SVL.
13.2 Incorporación
13.2.1 Instituciones. - Deben solicitar el acceso a SVL a través de su Cámara de

Compensación, mediante el Anexo 49 (Formato de Inscripción Instituciones
SVL).
La Cámara de Compensación previa validación de las personas responsables de

cada Institución, debe enviar el Anexo 49 a la dirección electrónica
info@cmerlos.com.mx, solicitando el alta de la Institución que desea participar
en SVL.
El Administrador General de SVL verifica que el Anexo 49 cumpla con la

información requerida y al día siguiente hábil proporciona a la Institución
solicitante la información de la aplicación, guía de uso y acceso a un ambiente
de pruebas para que el responsable y los analistas se familiaricen con SVL.
Una vez que la institución está lista para operar SVL, el Administrador General
proporciona la ruta de acceso, el nombre de usuario y la contraseña de acceso
al Administrador SVL de la Institución detallado en el Anexo 49, quién tiene la
facultad y responsabilidad para generar altas, bajas o cambios de usuarios
administradores y analistas para su Institución en la perspectiva Emisor y/o
Adquirente. La perspectiva Adquirente solo se habilita a las Instituciones que
estén registradas en el Anexo 9 (Relación de Bines de Referencia).
Por último, el Administrador General notifica la incorporación de la nueva

Institución a los participantes de SVL y realiza la liberación a producción dentro
de los 2 días hábiles posteriores a la solicitud de incorporación a producción.
13.2.2 Receptores de Pagos / Agregadores. - Deben solicitar el acceso a SVL a

través de su Adquirente, mediante el Anexo 50 (Formato de Inscripción
Receptores de Pagos SVL) y el Adquirente debe enviar la solicitud a través de
su Cámara de Compensación.
La Cámara de Compensación, previa validación de las personas responsables

de la Institución, debe enviar el Anexo 50 a la dirección electrónica
info@cmerlos.com.mx, solicitando el alta del Receptor de Pagos que desea
participar en SVL.
El Administrador General de SVL verifica que el Anexo 50 cumpla con la

información requerida y al día siguiente hábil proporciona al Receptor de Pagos
Capítulo VI 23

solicitante la información de la aplicación, guía de uso y acceso a un ambiente
de pruebas para que el responsable y los analistas se familiaricen con SVL.
Una vez que el Receptor de Pagos esté listo para operar SVL, el Administrador
General proporciona la ruta de acceso, el nombre de usuario y la contraseña de
acceso al Administrador SVL de la Institución detallado en el Anexo 50, quién
tiene la facultad y responsabilidad para generar altas, bajas o cambios de
usuarios administradores y analistas para el Receptor de Pagos.
Por último, el Administrador General notifica la incorporación del Receptor de

Pagos a los participantes de SVL y realiza la liberación a producción dentro de
los 2 días hábiles posteriores a la solicitud de incorporación a producción.
13.3 Participantes
Los participantes en SVL son:
• Adquirente
• Emisor
• Receptores de Pagos / Agregadores con acceso a la aplicación SVL
• Receptores de Pagos / Agregadores sin acceso a la aplicación SVL
(Operan a través del Adquirente)
• Administrador General SVL
13.3.1 Adquirente
Puede enviar validaciones emergentes a través del Sistema de Validación en

Línea, de cualquier Receptor de Pagos / Agregador que requiera el servicio y
que no tenga acceso directo a SVL, posteriormente debe notificar el resultado de
la validación a su Receptor de Pagos / Agregador.
De igual forma notifica y da seguimiento a los reportes de fraude que los

Emisores le envían a través del Sistema de Validación en Línea, de aquellos
Receptores de Pagos / Agregadores que no tienen acceso directo a SVL.
La comunicación entre el Adquirente y sus Receptores de Pagos / Agregadores,

se realiza mediante los canales de comunicación que tengan establecidos.
13.3.2 Emisor
Debe atender las validaciones emergentes recibidas a través del Sistema de

Validación en Línea, estas pueden ser enviadas por los Adquirentes o
directamente por algunos Receptores de Pagos / Agregadores con acceso a la
aplicación.
Capítulo VI 24

El Emisor debe contar con niveles de servicio, como mínimo para atender 100
solicitudes de validación por día.
Puede enviar notificaciones de transacciones confirmadas como fraude,

derivadas de su esquema de monitoreo a los Adquirentes y/o Receptores de
Pagos / Agregadores con acceso al Sistema de Validación en Línea.
Es decisión del Emisor, el atender o no, las validaciones emergentes que reciba
por otros canales (Teléfono, Correo Electrónico, etc.).
13.3.3 Receptores de Pagos / Agregadores con acceso a la aplicación SVL
Pueden participar Receptores de Pagos / Agregadores que cuenten con una

herramienta de monitoreo de fraudes y que se encuentren dentro de los
siguientes segmentos:
• Receptores de Pagos / Agregadores Tier I o Tier II

• Grandes Facturadores con Host propio.
• Comercio Electrónico / MoTo
Cualquier otro Receptor de Pagos / Agregador debe contar con la aprobación del
Grupo de Prevención de Fraudes.
El Receptor de Pagos / Agregador con acceso a la aplicación debe realizar su

monitoreo transaccional y enviar al Emisor a través de la aplicación SVL
(Sistema de Validación en Línea), las solicitudes de validación de las
transacciones que su sistema alertó de acuerdo a sus estrategias de monitoreo.
De igual forma el Receptor de Pagos / Agregador debe atender las notificaciones

de Fraude Confirmado enviadas por el Emisor mediante la aplicación SVL.
13.3.4 Receptores de Pagos / Agregadores SIN acceso a la aplicación SVL
El Receptor de Pagos / Agregador sin acceso a la aplicación realiza su

monitoreo transaccional (cuando aplique) y envía a su Adquirente las solicitudes
de validación de las transacciones que califique con sospecha de fraude a través
de los canales de comunicación que actualmente tenga con su Adquirente.
Así mismo atiende las notificaciones de Fraude Confirmado enviadas por el

Emisor, a través de los canales y herramientas de comunicación vigentes con su
Adquirente.
Capítulo VI 25

13.3.5 Administrador General de SVL
Es el responsable del mantenimiento y operación del sistema, así como del alta,
baja o modificación de Instituciones y/o usuarios administradores de las
Instituciones y Receptores de Pagos / Agregadores que participan en SVL.
13.4. Operación
El Adquirente es responsable de dar a conocer a sus Receptores de Pagos /

Agregadores, los términos y condiciones del presente capítulo.
El volumen de transacciones máximo a validar por día se establece en el punto

13.3.2 de este capítulo, en caso de un ataque masivo de fraude, el Adquirente,
Agregador o Receptor de Pagos, puede establecer con el Emisor afectado las
acciones necesarias para atender el volumen que se presente.
El Adquirente, Agregador o Receptor de Pagos, debe notificar las transacciones

que detecte como sospechosas, para que sean validadas por el Emisor con sus
tarjetahabientes, mismo que tiene la responsabilidad de contestar de acuerdo a
lo siguiente:
El Adquirente, Agregador o Receptor de Pagos, por ningún motivo puede

contactar directamente al tarjetahabiente, con excepción de aquellos casos en
los que se tenga autorización expresa o tácita por parte del Emisor.
El Adquirente, Agregador o Receptor de Pagos, puede enviar al Emisor las

transacciones, utilizando el Sistema de Validación en Línea, con la información
que para cada segmento corresponda.
Las validaciones deben enviarse y responderse diariamente con el fin de que no

se acumulen y se dé una respuesta ágil y oportuna.
Las transacciones que el Adquirente, Agregador o Receptor de Pagos, envíe a

validar deben contener las siguientes características:
• Antigüedad menor o igual a 5 días naturales a partir de la fecha

transacción.
Validación de cuenta
El Emisor se compromete, a realizar el bloqueo de la cuenta el mismo día, si se

confirma que la transacción es Fraude.
El Emisor está obligado a dar respuesta de acuerdo al tipo de operativa y los

niveles de servicio en SVL
Capítulo VI 26

En el caso de que el Emisor no de respuesta al Adquirente, Agregador o

Receptor de Pagos, en el plazo establecido para la validación de transacciones
pierde el derecho de alertar al Adquirente sobre actividad sospechosa del
Receptor de Pagos en las transacciones involucradas.
13.5 Respuestas del Emisor
Las respuestas que el emisor envíe serán en tres niveles, Fraude Confirmado,
Transacción OK y Sin Contacto
Fraude Confirmado: Transacciones que el emisor determina como fraude

mediante la validación con el tarjetahabiente o a falta de contacto, mediante
análisis de comportamiento histórico.
Transacción OK: se validó con el tarjetahabiente y confirmó compra o se

determinó con base en el análisis.
Sin Contacto: El emisor no logró contactar al tarjetahabiente y el análisis no es

suficiente para determinar si es fraude, por lo tanto, se requiere seguimiento por
parte del Adquirente, Agregador o Receptor de Pagos.
Cuando el Emisor responde Sin Contacto, debe confirmar cuatro variables con
una respuesta binaria (SI / NO), para que el Adquirente, Agregador o Receptor
de Pagos, tenga más elementos en la toma de decisiones.
¿Nombre Coincide?, se refiere a si el nombre del tarjetahabiente enviado

en la solicitud de validación, coincide con los registros del Emisor.
¿Domicilio Coincide?, se refiere a si el domicilio enviado en la solicitud de

validación, coincide con los registros del Emisor.
¿Teléfono Coincide?, se refiere a si el número de teléfono enviado en la

solicitud de validación, coincide con los registros del Emisor.
¿Patrón de Compra Coincide?, se refiere a si el patrón de compra

coincide con los hábitos de consumo del tarjetahabiente.
En las transacciones que el emisor responda como Fraude Confirmado, el

Adquirente, Agregador o Receptor de Pagos debe cancelar la entrega del bien o
servicio y tramitar la cancelación de la transacción en sistema o bien la
devolución a la Tarjeta, de acuerdo a lo señalado en el punto 9 del Capítulo VI
(Políticas y Procedimientos de Seguridad con los Receptores de Pagos).
Flujo Incorporación de una Institución en SVL

Capítulo VI 27

Flujo Incorporación de un Receptor / Agregador de Pagos en SVL
Capítulo VI 28

14. Sistema de Prevención Compartido

Capítulo VI 29

14.1 Participantes:
• Emisor
• Adquirente
• Receptor de Pagos
• Administrador General SPC
SPC es una herramienta colaborativa electrónica de comunicación bidireccional,

a través de internet, que permite intercambiar, almacenar y compartir
información no convencional de transacciones no reconocidas por los
tarjetahabientes.
Mediante los lineamientos descritos en los párrafos subsecuentes, dicho

intercambio de información se realiza entre Emisores y Receptores de Pagos,
otorgando a los Adquirentes pleno acceso a la información de la base
compartida.
El objetivo de la solución es el prevenir transacciones de fraude mediante el

resultado de compartir datos no convencionales de transacciones de fraude
confirmado por los emisores con sus tarjetahabientes a fin de que estén
disponibles para la consulta por los Receptores de pago quienes los podrán
utilizar directamente para la prevención de fraude y/o para incluirlos en sus
herramientas preventivas a fin de prevenir ventas fraudulentas. Las
informaciones de los resultados obtenidos no podrán ser usados para una
finalidad distinta a la prevención de fraude.
14.2 Alta de los participantes al servicio SPC
14.2.1 Emisor.- Debe solicitar el acceso al SPC al administrador del sistema

directamente o a través de su empresa especializada con la cual tiene los
servicios contratados.
La empresa especializada realiza previamente la validación de las personas

responsables de la Institución Emisora, debe enviar el Anexo 49 a la dirección
electrónica info@cmerlos.com.mx, solicitando el alta de la Institución que desea
participar en SPC.
Debe cargar en SPC las transacciones de fraude confirmado y las no

reconocidas por los tarjetahabientes con alta probabilidad de fraude, para que
los Receptores de Pagos participantes provean la información no convencional
con la que estas transacciones se llevaron a cabo.
Capítulo VI 30

De forma semanal como máximo el emisor deberá reportar eventos de
transacciones fraudulentas, en el caso de no presentarlos el sistema restringirá
su acceso a la base de información compartida.
La información que el Emisor debe enviar en su solicitud de datos no

convencionales es:
• Nombre del Receptor de Pagos

• Afiliación
• Hora de Transacción
• Importe
• Número de Autorización (Opcional)
• Referencia de 23 Posiciones (Opcional)
• MCC (Opcional)
• Modo de Entrada
• Medio de Acceso (Opcional)
• Identificador de la Terminal del Receptor de Pagos (Opcional)
14.2.2 Adquirente
Derivado de la relación que tiene con los Receptores de Pago, es el responsable

de solicitar la incorporación de estos en el Sistema de Prevención Compartido
mediante el llenado y envío del Anexo 50 al Administrador General de SPC.
Tiene pleno acceso a la base de información compartida para lo cual debe

solicitar sus usuarios mediante el Anexo 49.
Es de carácter obligatorio:
Capítulo VI 31

Incorporar aquellos receptores de pagos que se encuentren dentro del TOP 10

de fraude en el Intercambio Local, basado en la última actualización mensual
proporcionada por las áreas de prevención de fraudes.
De forma opcional un adquirente puede incorporar a otros receptores de pagos

que consideren importantes para la participación en SPC, siempre y cuando
haya forma de comprobar que el Receptor de Pagos cuenta con los requisitos
descritos en el punto 14.2.4
14.2.3 Receptor de Pagos –Aquellos Receptores de pago que cumplan con lo

establecido en el punto 14.3.3 de este documento y deseen participan
voluntariamente, deben solicitar la incorporación a SPC a través de su
Adquirente, mediante el Anexo 50 (Formato de Inscripción Receptores de
Pagos).
El Adquirente debe verificar con el representante legal del Receptor de Pagos, a

las personas facultadas que designa para que se les autorice el acceso a SPC.
El Adquirente, debe enviar el Anexo 50 a la dirección electrónica

info@cmerlos.com.mx, solicitando el alta del Receptor de Pagos que desea
participar en SPC.
El Administrador General de SPC verifica que el Anexo 50 cumpla con la

información requerida, con lo que en un máximo de 3 días siguiente hábiles
proporcionará al Receptor de Pagos solicitante la, guía de uso y accesos
correspondientes.
El Administrador General notifica la incorporación del Receptor de Pagos a los

participantes de SPC
14.2.4 Consideraciones de los Receptores de Pagos
Deben participar los Receptores de Pagos que se encuentren dentro del TOP 10
de fraude del intercambio doméstico.
Cualquier otro Receptor de Pagos debe contar con la aprobación de al menos

dos Instituciones Participantes, ya sea Emisores o Adquirentes, utilizar una
herramienta de monitoreo de riesgo y que se encuentren dentro de los siguientes
segmentos:
• Receptores de Pagos Tier I o Tier II

• Grandes Facturadores con Host propio.
• Comercio Electrónico / MoTo
Capítulo VI 32

El Receptor de Pagos se obliga a realizar un análisis inmediato de las
transacciones reportadas por el banco Emisor mediante el SPC, para determinar
cuáles operaciones pueden corresponder a una aclaración, una devolución, o un
caso de carácter fraudulento. Sobre este último, el Receptor de Pagos debe
identificar la información No Convencional para compartirla en SPC.
El Receptor de Pagos, a través de personal autorizado, se compromete a

proporcionar a través de la plataforma SPC, la información No Convencional con
la que se llevó a cabo la transacción determinada como fraude y que tenga en
sus registros, considerando para tales efectos los siguientes datos:
14.2.5 Información No Convencional

• Datos de Facturación (calle, número exterior, número interior, colonia,
código postal, ciudad y estado)
• Datos de Entrega (calle, número exterior, número interior, colonia, código
postal, ciudad y estado)
• Teléfono
• Email
• Dirección IP
• Finger Print Device
Adicionalmente debe informar si entregó o no, el bien o servicio y el estatus en

que se encuentra la devolución de esta transacción con base a las siguientes
opciones:
• Pendiente
• En Proceso
• Realizada
• Sin Datos
• No Aplica
• En Espera de Contracargo
Por último y a través de su Adquirente debe proporcionar los números de tarjetas que
se intentaron utilizar en las transacciones de fraude prevenidas. Esto a fin de dar
oportunidad al emisor de prevenir transacciones adicionales que se intenten en los
Receptores de Pago fuera del alcance de la SPC.
14.2.6 Administrador General de SPC
Es el responsable del, mantenimiento y operación del sistema, así como del alta,
baja o modificación de Instituciones y/o usuarios administradores de las
Instituciones y Receptores de Pagos que participan en SPC.
Debe verificar que el alta de los accesos al personal de los bancos y receptores
de pagos, sea conforme al protocolo establecido en el numeral 14.2
Capítulo VI 33

14.3. Operación
El Adquirente es responsable de dar a conocer a sus Receptores de Pagos los

términos y condiciones de la presente normativa.
El Receptor de Pagos, debe proporcionar la información no convencional de la

transacción con la que cuente, dicha información será almacenada en una base
de datos compartida con el resto de los participantes de la plataforma de tal
modo que el gremio y no solo los involucrados en la transacción, para que los
Participantes puedan protegerse de futuros intentos de fraude con la misma
información.
La información de la base compartida está disponible para su consulta en tres

métodos:
1. Consulta directa mediante la interfaz web.

2. Descarga en archivo de la información.
3. Consulta en tiempo real mediante una API.
Los participantes que deseen hacer una conexión vía API, deben ponerse en
contacto con el Administrador General de SPC para que este les proporcione los
requisitos de conexión.
14.4 Alertas
Capítulo VI 34

En el sistema se pueden registrar dos tipos de alertas (manual y automática),
una alerta manual a su vez se divide en individual o general, puede ser iniciada
por cualquiera de los participantes de la herramienta, mediante este proceso el
participante puede notificar de algún tipo de fraude detectado, ataque masivo y/o
cualquier eventualidad cuya información pueda ser compartida y coadyuve a
mitigar el fraude, la notificación se puede realizar a una institución en particular o
se puede compartir de forma general con todos los participantes de la
herramienta.
Una alerta automática es generada por el propio sistema en cuanto detecta 3 o

más coincidencias de un dato en la base, por ejemplo, una dirección de email
que ha sido usada en 3 o más ocasiones, será notificada para que los
participantes pongan especial atención en transacciones donde se haya utilizado
el dato, para que procedan a validar la transacción y/o iniciar el procedimiento
para frustrar la venta.
La declaración de una transacción como no reconocida o fraudulenta es

responsabilidad de quien emite y clasifica dicha transacción, por lo cual esto no
recaerá en las otras Instituciones que hagan uso de dicha información.
14.5 Seguridad
En caso de que, se observe o exista alguna recomendación en la que los

participantes deban implementar algún desarrollo tecnológico adicional, esto
debe ser revisado y acordado por el grupo de Prevención de Fraudes de la ABM.
Los Participantes que extraigan información del SPC están obligados a

transmitirla o resguardarla con las medidas de seguridad señaladas en el anexo
49 y anexo 50.
14.6 Uso y restricciones
El objetivo del SPC es que, a través de la comunicación de información

oportuna, los Participantes tengan conocimiento de las transacciones no
reconocidas para poder llevar a cabo acciones de seguridad que prevengan
fraudes u otras conductas delictivas en la industria.
El uso de la herramienta de cualquier manera que no sea ética, legal o que no

corresponda con el objetivo de la misma podrá ser sujeto a las acciones civiles,
administrativas y penales mencionadas en el Anexo 49 o Anexo 50 según
corresponda.
Capítulo VI 35

La declaración de una transacción como no reconocida o fraudulenta es
responsabilidad de quien emite y clasifica dicha transacción, por lo cual esto no
recaerá en las otras Instituciones que hagan uso de dicha información.
15 Acciones para recuperación de importes por

ataques de fuerza
Se refiere a eventos de fraude relacionados con peticiones de autorización de forma

continua basado por velocidad y frecuencia. Esta operativa inusual debe ser detectada
por los sistemas especializados de monitoreo ya sea por el adquirente o el mismo
emisor. El receptor de pagos procesa peticiones de autorización con tarjetas existentes,
cerradas y vigentes, a través de generadores de números de tarjetas aleatoriamente
mediante un algoritmo especial con softwares, aplicaciones o páginas públicas de
internet. También existen receptores de pagos que se afilian como receptores de pago
de tipo fachada para ofrecer servicios de asistencia y después procesar cientos de
transacciones de tipo cargo recurrente.
En su mayoría se refiere a transacciones con tarjeta no presente y el procedimiento

administrativo es el siguiente:
15.1 Emisor
• Recibe o detecta un ataque de múltiples transacciones con diferencia

mínima de tiempo, por velocidad y frecuencia.
• Genera la alerta en el SNA por tipo 14 ATAQUE MASIVO
TRANSACCIONES DE TARJETA NO PRESENTE
• El adquirente recibe la notificación en el SNA, analiza la operativa y de
ser posible procede al bloqueo preventivo (Clave 5) de la afiliación del
receptor de pagos así como la retención de fondos que corresponda.
• El adquirente tiene 5 días naturales para responder la alerta y confirmar
si se trata de un evento de fraude con participación del receptor de
pagos.
• El adquirente debe cancelar la afiliación con clave 30 en la Base Única.
• El adquirente debe procesar de inmediato las devoluciones o aceptar un
• Cuando el emisor recuperé dichas transacciones, no debe reportar el
fraude a las marcas.
15.2 Adquirente
Capítulo VI 36

• Detecta un ataque o evento inusual de múltiples transacciones por

velocidad y frecuencia.
• Genera la alerta en el SNA por tipo 14 ATAQUE MASIVO
TRANSACCIONES DE TARJETA NO PRESENTE
• En base a su dictamen y tipo de operativa el adquirente procede al
bloqueo preventivo (Clave 5) de la afiliación del receptor de pagos o en
su caso con clave 30 de fraude confirmado, así como la retención de
fondos que corresponda.
• El adquirente envía la relación de las transacciones y sus tarjetas a los
emisores afectados para su revisión.
• EL emisor tiene 2 días naturales para responder al adquirente y
confirmar si se trata de un evento de fraude.
• El adquirente debe procesar de inmediato las devoluciones o aceptar un
Capítulo VI 37

CAPÍTULO VII
OPERATIVA FIRMA EN ARCHIVO
AGENCIAS DE VIAJE
Capítulo VII 1

Objetivo
Establecer reglas operativas para las agencias de viajes que se incorporen al programa
de Registro de Firma en Archivo y regular la resolución de controversias derivadas del
intercambio con otras Instituciones.
Definición del Servicio
Las Agencias de Viajes pueden realizar la venta de sus servicios y de boletos de avión,
sin necesidad de que los Tarjetahabientes tengan que firmar un Documento cada vez que
soliciten una transacción a la Agencia de Viajes, con las Tarjetas emitidas por las
Instituciones registradas en el Anexo 29.
Reglas Operativas
§ Estas reglas solo aplican para transacciones efectuadas en Agencias de Viajes

autorizadas por los Adquirentes.
§ La autorización del servicio de Firma en Archivo se debe realizar llenando del formato
o Contrato de Servicio, determinado por el Receptor de Pagos con el Tarjetahabiente.
§ Esta operativa aplica para todas las Tarjetas que el Emisor autorice.
§ El Receptor de Pagos está obligado a emitir un Comprobante Electrónico para las

transacciones derivadas de esta operativa e invariablemente debe contener la leyenda
Firma en Archivo y/o Signature on File (Impresión en línea, manual y/o sello).
§ Cuando exista una petición de Comprobante y el Adquirente identifique la transacción

dentro de esta operativa, está obligado a enviar copia del formato o Contrato de
Servicios entre el Tarjetahabiente y el Receptor de Pagos copia del comprobante con
la leyenda Firma en Archivo y/o Signature on File que permita al emisor comprobar el
servicio y acuse de recibo
§ En caso de enviar la documentación incompleta, el Emisor puede contracargar por

código de razón 84 Falta de Firma y/o Firma en Archivo (opción E).
§ El Adquirente es el responsable de validar que el Receptor de Pagos se apegue a las

políticas de afiliación.
§ El Adquirente no está obligado a presentar documentación original, de la descrita en el

Anexo 15 (Datos Legibles y Mandatorios que deben contener los Documentos de
Tarjetas).
Capítulo VII 2

CAPÍTULO VIII
PAGOS INTERBANCARIOS DE
TARJETA DE CRÉDITO
Capítulo VIII 1

Capítulo VIII 2

1.- REGLAS GENERALES DE PAGOS
1.1 Este documento únicamente regula los pagos de tarjetas en el intercambio

para Tarjetas de Crédito en Moneda Nacional.
1.2 Las Instituciones acuerdan recibir en el intercambio, los importes de los

pagos, generados a Tarjetas de Crédito, recibidos por una Institución
diferente al Emisor de la tarjeta a través de los siguientes medios:
a) Pagos a tarjetas de crédito recibidos en las sucursales bancarias.

b) Pagos a tarjetas de crédito recibidos a través de los medios electrónicos
que cada Institución tenga establecidos (Internet, Vía Telefónica, Cajeros
Automáticos, etc.)
1.3 La antigüedad de los mismos no debe ser mayor a 2 días hábiles, después
de la fecha valor.
1.4 El Emisor de la tarjeta debe aplicar el pago con fecha valor

independientemente a la fecha de proceso con la leyenda que el Emisor
establezca para identificar la transacción en el estado de cuenta del
Tarjetahabiente.
1.5 El Lay out está definido en el Anexo 4P (Pago de Tarjetas en el Intercambio y

Aclaraciones).
1.6 Se establecen validaciones para la Operativa de Pago de Tarjetas en

el Intercambio, descritas en el Capitulo III (Validaciones)
1.7 Cuando una de las Instituciones no pueda procesar la información, está

obligada a notificar a la contraparte, obteniendo acuse de recibo de
cualquiera de los funcionarios señalados en el anexo 11“B” del Contrato de
Aceptación de Tarjetas para que sustituya el archivo, a más tardar al día
hábil siguiente.
1.8 La Compensación de la Operación de Pago de Tarjetas en el Intercambio de

Tarjeta de Crédito se efectúa de acuerdo a lo señalado en las Condiciones
para el Intercambio entre Cámaras de Compensación.
1.9 Es responsabilidad de la Institución receptora, intercambiar la información

con estricto apego a las presentes reglas.
1.10 Las cuentas de American Express, deben justificarse a la derecha (campo

numérico), dado que son de 15 posiciones conteniendo un ‘0’ en la primera
posición.
Capítulo VIII 3

1.11 Es responsabilidad del Emisor una vez intercambiada la información, la
oportuna y correcta aplicación de los pagos a sus Tarjetahabientes.
1.12 El Emisor es el responsable de recibir y gestionar las aclaraciones de sus

Tarjetahabientes, derivadas de esta operativa.
1.13 Los Emisores son responsables de registrar las Altas, Bajas y

Modificaciones de los BINES que aceptan Pagos para Tarjetas de Crédito de
acuerdo a lo señalado en la regla 1.2 del Manual Operativo.
1.14 En el momento en que una Institución receptora detecte que un BIN no es

de naturaleza Crédito, puede darlo de baja de su plataforma de recepción de
pagos, sin previo aviso al Emisor.
1.15 Las Instituciones receptoras son responsables de dar de Alta en sus

plataformas los BINES que acepten pagos en el intercambio, registrados en
el Anexo 1 (Relación de BINES sujetos al Intercambio Local) y a su vez
deben validar el BIN y dígito verificador de la cuenta en el momento de la
recepción del Pago.
1.16 El plazo para que la Institución receptora actualice dicha información es de

30 días naturales contados a partir de la fecha de registro del movimiento de
Alta, Baja o Modificación en el BIN Manager.
1.17 La multa que a consecuencia del incumplimiento de alguna Institución sea

impuesta por las autoridades a otra Institución, la Institución penalizada por
la autoridad tiene el derecho de trasladarle a la Institución responsable el
monto total de la multa.
El trámite de recuperación debe ser realizado a través del árbitro operativo

con la documentación correspondiente, bajo las siguientes premisas:
§ Cuando la Institución receptora no acepta un Pago de Tarjeta de Crédito

por no tener registrado el BIN y la Institución Emisora si dio de Alta su
BIN, la multa la debe pagar la Institución receptora.
§ Cuando la Institución receptora no acepta un pago de Tarjeta de Crédito

y el Emisor no dio de alta su BIN, la multa la debe pagar la Institución
Emisora.
§ Cuando un pago a Tarjeta de Crédito no fue procesado por la Institución

receptora en los tiempos establecidos en el punto 1.3 de esta Normativa,
la multa la debe pagar la Institución receptora.
§ En caso de Pago de Tarjetas en el Intercambio por medios electrónicos,

la Institución receptora no puede realizar un reverso a la cuenta origen
sin haber notificado al Tarjetahabiente.
Capítulo VIII 4

§ Cuando una Institución reciba un pago de un BIN no autorizado en el
Anexo 1 (Relación de Prefijos Sujetos al Intercambio Local) y un Emisor
recibe una Aclaración de Pago no Aplicado, este debe realizar una
solicitud por escrito a la Institución receptora, la cual se obliga a enviar al
Emisor por medio de misceláneo 112 transacción 20 el importe del pago.
2.- CICLO DE CONTROVERSIAS DE PAGOS
2.1 El Emisor tiene 130 días naturales a partir de la fecha de pago para poder
ejercer una solicitud de aclaración.
Tipos de Aclaraciones:
a) Pago no aplicado en forma total
b) Pago aplicado en forma parcial (referencia 23 posiciones)
2.2 La Institución receptora cuenta con 5 días hábiles para dar respuesta a una
solicitud de aclaración.
El catálogo de transacciones para el ciclo de controversias es el siguiente:
Códigos de Transacción
52 Solicitud Aclaración
53 Confirmación Aclaración
18 Contracargo
08 Representación
Código de Transacción 52 Emisor.
20 Abono total no Aplicado

21 Abono parcialmente Aplicado
Código de Transacción 53 Institución receptora.
20 Acepta Cargo Total, del Pago no Aplicado

21 Acepta Cargo Parcial, del Pago no Aplicado
22 No Acepta Cargo, la Transacción si fue intercambiada (Fecha de
intercambio, Listado de transacciones aceptadas y total de transacciones
e importe del día).
23 No Acepta Cargo. Documento Ilegible (Los datos mandatarios no son
legibles).
24 No Acepta Cargo. Comprobante de Pago Alterado (Listado de
transacciones aceptadas).
Capítulo VIII 5

25 No Acepta Cargo. Identificador de Institución no corresponde (Anexar la
información recibida).
26 No acepta Cargo, Petición Inválida, Pago inexistente (Listado de
transacciones aceptadas), el pago por Internet no fue cargado a la
cuenta origen.
27 No Acepta Cargo, Aclaración duplicada (Fecha y No. de aclaración).
28 No Acepta Cargo, Imagen no corresponde o no se recibió imagen
Código de Transacción 18 Emisor.
Código de razón 30 Pago no Aplicado

Código de razón 31 Pago Aplicado Parcialmente
Código de razón 32 Respuesta No Procedente
Código de Transacción 08 Adquirente.
Código de razón 96 Representación
2.3 En caso de que el Emisor no esté de acuerdo con las respuestas señaladas
en el punto 2.2 código de transacción 53 (22 al 28), puede contracargar por
el código de razón 32.
2.4 El horario de intercambio de las aclaraciones para ser consideradas como

atendidas en el mismo día es el señalado en las Condiciones para el
Intercambio entre Cámaras de Compensación.
2.5 La Institución receptora tiene 12 días hábiles a partir de la recepción del

Contracargo, para poder ejercer una representación a un Emisor por un
Contracargo Improcedente.
2.6 Se debe utilizar el Anexo 8P (exhibit) “Documentación Transmitida para

Contracargos y/o Representaciones Pago de Tarjetas en el Intercambio”
(Aplica únicamente para el código de razón 32)
3.- DOCUMENTACIÓN DE APOYO PARA LA SOLICITUD DE ACLARACIÓN

POR PAGO NO APLICADO
3.1 Pago en Ventanilla
• Copia de comprobante legible con el sello y certificación de la caja del

recibo de pago.
• Estado de Cuenta donde debió quedar aplicado el Pago.
Capítulo VIII 6

3.2 Pago por Medio Electrónico (Internet, Vía Telefónica, Cajeros Automáticos,
etc.)
• Comprobante especificando folio, clave, autorización, o cualquier referencia

que identifique la transacción electrónica y/o comprobante electrónico.
• Estado de Cuenta donde debió quedar aplicado el pago.
4.- PROCEDIMIENTO PARA LA SOLICITUD DE ACLARACIÓN DE UNA

INSTITUCIÓN RECEPTORA.
4.1 La Institución receptora debe notificar a través de su Cámara de

Compensación al Emisor(es), para que realice la gestión de recuperación
proporcionando los números de cuenta, importes, fechas de los pagos,
fechas de proceso del intercambio y total del archivo que incluya número de
pagos e importe cuando detecte que se presentó algún error de proceso en
el envío de la información cuando existan las siguientes condiciones:
a) Pagos duplicados.
b) Importes multiplicados / Importes erróneos.
c) Procesos duplicados.
Cuando Emisor informe que no es posible recuperar algún importe este lo

realizara de buena fe
4.2 La afectación monetaria de esta recuperación la realiza el Emisor y se efectúa a

solicitud de la Institución receptora a través de misceláneo 112) conforme se
gestione la recuperación.
4.3 El plazo que tiene la Institución receptora para la notificación es de 5 días

hábiles contados a partir de la fecha de proceso. El Emisor tiene 5 días
hábiles a partir de la notificación de la Institución receptora para su
aceptación y solo puede rechazar en los casos que demuestre que la cuenta
se encuentra cancelada.
4.4 Recuperación de pagos de la Institución receptora:
4.4.1 Para los casos de pagos compensados por errores en proceso de la

Institución receptora, se gestionan mediante un procedimiento manual con
las siguientes premisas:
Capítulo VIII 7

a) La Institución receptora tiene hasta 90 días naturales a partir de la fecha de
la transacción realizada por el Tarjetahabiente, para presentar su solicitud
de reembolso vía e-mail al Emisor con un costo de servicio por
requerimiento, de acuerdo al punto “J” del capítulo IV (Costos de Servicios),
cuando exista respuesta favorable para los siguientes casos:
Concepto Documentación soporte de Recuperación Emisor

la Institución Receptora documentación soporte
Carta del Emisor
Pago Duplicado Listado de Intercambio certificando haber recibido
reclamación del TH o
Carta reclamación del TH,
Comprobante de pago
Interbancario.
Importe diferente al Copia comprobante de Carta del Emisor

pago recibido. pago y/o carta responsiva certificando haber recibido
de la Institución receptora. reclamación del TH o
Carta reclamación TH
Carta del Emisor
Importe aplicado en Listado de Intercambio y/o certificando haber recibido
cuenta errónea. carta de la Institución reclamación del TH o
receptora. Carta reclamación TH,
Comprobante de pago.
b) El Emisor debe revisar si existe la aplicación del pago a su tarjetahabiente

por el monto reclamado por la Institución receptora y resolver la petición en
un máximo de 10 días naturales, si no hay respuesta en el plazo definido, la
Institución receptora puede penalizar al Emisor de acuerdo a lo señalado en
el punto 25 del capítulo V (Penas Convencionales por Incumplimiento).
c) El Emisor tiene hasta 130 días naturales a partir de la aceptación de la

Buena Fe, para ejercer una acción de recuperación con la Institución
receptora, cuando el cliente presente carta reclamación y recibo de pago
interbancario, realizando cargo directo mediante misceláneo.
Capítulo VIII 8

5.- PENALIZACIONES
5.1 Se puede efectuar el cobro de penalizaciones conforme a lo señalado en el

Capítulo V (Penas Convencionales por Incumplimiento), las cuales
invariablemente deben ser enviadas diariamente en el intercambio Nacional
a través del medio magnético vigente, vía misceláneo, transacción 10 código
de razón 106.
El plazo máximo para poder ejercer el derecho de cobrar una penalización es

de 6 días naturales, cualquier penalización que rebase el plazo puede ser
devuelta por la Institución afectada en un plazo no mayor de 6 días naturales.
5.2 Cualquier penalización debe estar documentada, (Anexo 12P Listado de

Transacciones de Pagos de Tarjetas en el Intercambio Extemporáneos), en
caso contrario la Institución afectada con el cargo puede solicitar dentro de
los primeros 6 días hábiles de haber recibido el misceláneo, los
antecedentes.
La contraparte cuenta con un plazo de 6 días hábiles para documentar el

caso, de lo contrario este cobro no tiene validez y puede ser regresado
anexando copia del requerimiento de documentación sin que exista
posibilidad de recuperación.
5.3 Las Instituciones acuerdan que para el cobro de penalizaciones, que su

plazo de vencimiento sea en un día inhábil y/o festivo se puede efectuar el
cobro al día hábil siguiente.
5.4 Las Instituciones acuerdan que todos los cobros de penalizaciones

estipulados en este contrato, serán intercambiados con su respectivo
Impuesto al Valor Agregado (I.V.A) y/o cualquier otro que lo sustituya o
complemente, a través del misceláneo correspondiente a cada caso.
6.- REGLAS DE PRESENTACIÓN DE IMÁGENES
6.1 Las imágenes deben ser escaneadas bajo el formato jpg / tif comprimido y
presentadas de manera conjunta con el Archivo de Intercambio.
6.2 La resolución de las imágenes no puede ser menor a 100 DPI y el tamaño de
las mismas no exceder de 100 Kb.
6.3 En caso de no cumplir con las especificaciones, la imagen no se considera válida y

el registro debe ser rechazado. (Solicitar aclaración al Procesador)
Capítulo VIII 9

6.4 Pueden integrarse fichas de depósito, comprobantes de pago en internet y
documentación soporte de Contracargos y representaciones, para lo cual
existe un límite máximo de 5 imágenes por solicitud y 5 por respuesta.
6.5 Es responsabilidad de los Bancos enviar la información correcta y

debidamente asociada a la aclaración mediante el folio que le asigne el
Emisor, el cual está considerado en el lay out de intercambio, ya que no se
realiza ninguna validación de la documentación presentada como soporte o
respuesta a una aclaración.
6.6 El acuse de recibo del envío de la documentación es el que proporcionen los

Sistemas, en donde se registra el horario de recepción del archivo de
Aclaraciones de Pagos, de acuerdo con la validación del Header y Trailer,
como actualmente se está realizando en el proceso de intercambio así como
el número de registros recibidos en la carátula de pagos interbancarios con el
tipo de transacción 52.
6.7 Es importante que consideren que el acuse electrónico es el que genera la

aplicación para el envío y/o recepción de los archivos. Este acuse no
contiene detalles, sólo refleja el horario de recepción y las cifras control de los
archivos.
6.8 La respuesta de petición de aclaraciones de Pagos Interbancarios están

consideradas en la carátula de Pagos Interbancarios Anexo 6P (Carátula de
Intercambio de Pagos Interbancarios), con la transacción 53.
7 LEGIBILIDAD DE IMÁGENES
7.1 La imagen se considera legible cuando contiene los datos mandatorios

establecidos en el Anexo 15P (Datos Legibles y Mandatarios que deben
contener los Documentos de Pagos Interbancarios), del Contrato de
Aceptación de Tarjetas Bancarias vigente.
7.2 Es requisito indispensable que el tamaño de la imagen permita visualizar

todos los datos mencionados en el anexo 15P (Datos Legibles y Mandatarios
que deben contener los Documentos de Pagos Interbancarios) vigente, así
como la información contenida en la documentación soporte de contracargos
y representaciones.
7.3 Las imágenes deben ser conservadas en el formato original, de manera que
en caso de Controversia entre las Instituciones, se cuente con la evidencia
necesaria para determinar su legibilidad a través del Árbitro Operativo.
Capítulo VIII 10

7.4 Cualquier documento e información soporte que se presente, y que no
corresponda a la aclaración sobre la cual se inició el proceso de controversia,
se considera inválida.
8.- ARBITRAJE PAGO DE TARJETAS EN EL INTERCAMBIO
8.1 REGLAS GENERALES
8.1.1 Se puede someter al arbitraje aquéllos casos que no puedan resolverse

satisfactoriamente, una vez agotadas las reglas y procedimientos señalados
en este Capítulo.
8.1.2 El dictamen emitido por el Árbitro Operativo es apelable una sola ocasión,
no importando el monto de la transacción.
La apelación debe presentarse al Árbitro Operativo, mediante un escrito

libre firmado por el funcionario correspondiente, facultado en el anexo 11
(Funcionarios Facultados Para Sometimiento Arbitral) del Manual Operativo,
conteniendo como mínimo: folio de emplazamiento asignado por el árbitro
operativo y fecha de dictamen del emplazamiento, descripción y causa de la
apelación, así mismo debe anexar únicamente la documentación original
previamente intercambiada, para el análisis y definición del caso.
8.1.3 El plazo máximo para la apelación es de 5 días hábiles, a partir del día hábil
siguiente de haber recibido el dictamen.
8.1.4 El resultado de la apelación por parte del Árbitro Operativo, lo notifica por
escrito dentro de los 5 días hábiles, a partir del día hábil siguiente de la
fecha de recepción de la apelación.
8.1.5 La apelación que proceda, queda exenta para ambas Instituciones del
cobro de los honorarios vigentes por concepto de arbitraje.
8.1.6 Para someter un caso a arbitraje deben cumplir alguna de las premisas
mencionadas en el punto 8.2 del presente Capítulo.
8.1.7 Cualquier caso emplazado puede ser retirado previo acuerdo por escrito,
firmado por las Instituciones involucradas y entregado al Árbitro Operativo,
en un plazo no mayor a los 3 días hábiles siguientes a la fecha en que el
emplazamiento fue recibido por el Árbitro Operativo dentro del horario de
9:00 a 17:00 hrs.
8.1.8 Se pueden someter a arbitraje aquéllos casos donde existan cobros o

pagos por misceláneos improcedentes.
Capítulo VIII 11

8.2 PROCEDIMIENTOS PARA RESOLUCIÓN DE CONTROVERSIAS
8.2.1 Los casos que sean sometidos a arbitraje deberán haber cumplido
invariablemente el ciclo de: primer contracargo por parte del Emisor y
representación por parte del Adquirente.
8.2.2. En los casos que el Adquirente reciba un segundo contracargo por parte del
Emisor, tendrá el derecho de someter el caso a arbitraje.
8.2.3 El Emisor tendrá el derecho de sometimiento arbitral por haber recibido una
representación fuera de normas: datos erróneos, documentación de apoyo
no recibida o incompleta, representación extemporánea, representaciones
duplicadas o aquéllos estipulados en cualquier apartado de este capítulo.
Los contracargos y representaciones duplicadas que presente cualquier

sistema, serán sujetos a emplazamiento arbitral, aun cuando éstos no
hayan cubierto el ciclo de contracargos descrito en el punto 8.2.1, así
mismo el sistema que lo realice se hará acreedor a la penalización señalada
en el punto 5, del capítulo V (Penas Convencionales por Incumplimiento); el
contracargo duplicado deberá contener las siguientes características:
misma cuenta, misma referencia de 23 posiciones (cuando aplique), mismo
importe y que en el anexo 8P (Exhibit), indique el mismo concepto (código
de uso) primer contracargo, o representación, en ausencia de lo anterior se
deberá presentar al Árbitro Operativo el registro electrónico que muestre la
duplicidad, aun cuando no exista documentación de apoyo de alguno de los
registros, siempre y cuando el Adquirente o Emisor se vean afectados por
los costos financieros.
8.2.4 El plazo máximo para sometimiento arbitral será de 15 días naturales,

contados a partir de la fecha de presentación del contracargo,
representación y/o misceláneo que de origen al mismo, dentro del horario
de 9:00 a 17:00 hrs.
8.2.5 Se considera un misceláneo improcedente aquél que:
• No cuente con carta de aceptación de la institución que está recibiendo

el cargo.
• No cuente con los antecedentes necesarios para su validación.
• No se haya recibido la información electrónica en el intercambio.
• No corresponda a la institución que esta recibiendo el cargo.
Por lo que cualquier sistema puede realizar la recuperación de un

misceláneo improcedente de acuerdo a lo siguiente:
Capítulo VIII 12

• La Institución afectada deberá enviar un escrito de pre-arbitraje como
intento de recuperación del importe en disputa dentro de un plazo no
mayor a 10 días naturales contados a partir de la fecha del intercambio
del misceláneo en disputa.
• La Institución que reciba el pre-arbitraje quedará obligada a dar

respuesta en un plazo no mayor a 10 días naturales contados a partir del
acuse de recibo del pre-arbitraje.
• En caso de no recibir respuesta en este plazo, o que persista la

controversia el caso puede ser emplazado al Árbitro Operativo.
• El plazo máximo para poder ejercer el derecho de emplazar al Árbitro

Operativo es de 15 días naturales contados a partir de la fecha de
intercambio del misceláneo en disputa presentando la documentación o
reportes de apoyo que apliquen.
8.3 DOCUMENTACIÓN REQUERIDA PARA SOMETIMIENTO
8.3.1 Las Instituciones presentarán el sometimiento en el formato contenido en

el anexo 10P Emplazamiento Arbitral, el cual invariablemente deberá de ir
debidamente requisitado y firmado por cualquiera de los funcionarios
facultados ante el Árbitro Operativo, detallados en el anexo 11.
8.3.2 La carta de sometimiento invariablemente deberá de ir acompañada de la

documentación que se señala en el punto 3.1 y 3.2 de este capítulo
correspondiente al contracargo y representación, la documentación de
apoyo intercambiada y listado de transacciones aceptadas certificado según
anexo 19P
En los casos de ilegibilidad de la imagen, el Emisor invariablemente debe

proporcionar copia del Comprobante de Pago.
8.3.3 La Institución que someta un caso por cobro o pago de misceláneo

improcedente debe cumplir con lo señalado en la cláusula 8.2.5 presentar
la documentación y requisitar correctamente los formatos de sometimiento
arbitral establecidos en este Contrato.
8.4 RESPONSABILIDADES DEL ÁRBITRO OPERATIVO
8.4.1 El Árbitro Operativo está obligado a dar una respuesta de aceptación o

declinación de los casos en 2 días hábiles, a partir de su presentación y
dentro del horario de 9:00 a 17:00 hrs.
8.4.2 El Árbitro Operativo se obliga a declinar las solicitudes de sometimiento

por los siguientes motivos:
• Los eventos descritos en la carta de emplazamiento no coinciden con la

documentación de apoyo.
Capítulo VIII 13

• El anexo 10P (Emplazamiento Arbitral), fue presentado sin cumplir con lo
estipulado en alguno de los puntos 8.2.4, 8.3.1 y/o 8.3.2 del presente
Capítulo.
8.4.3 La Institución que recibió la declinación del sometimiento, tiene el derecho

de someter nuevamente el caso con la información faltante; siempre y
cuando no exceda los 15 días naturales, enunciados en el punto 8.2.4.
8.4.4 En caso de que el Árbitro Operativo no acepte un caso que conforme a

este reglamento si proceda y derivado de esto el plazo de presentación se
hubiere vencido, sólo en éstos casos se puede emplazar dentro de los 3
días hábiles siguientes a la fecha de su vencimiento, quedando exento
para ambas Instituciones del cobro de los honorarios vigentes por
concepto de arbitraje.
8.4.5 En los casos de solicitudes de sometimiento arbitral aceptadas, el Árbitro

Operativo tiene como máximo 5 días hábiles a partir del día siguiente hábil
de su aceptación y se obliga a emitir su dictamen a partir del cuarto día
hábil.
8.4.6 Cuando el Árbitro Operativo reciba una solicitud de arbitraje por
documentación de apoyo no recibida o incompleta, la Institución receptora,
debe anexar la notificación por escrito enviada al Emisor con acuse de
recibo de acuerdo al punto 8.2.3 párrafo segundo del presente Capítulo.
8.4.7 El Árbitro Operativo notifica retiro de emplazamientos recibidos con la

conformidad de las Instituciones involucradas y determina la
responsabilidad financiera, detallada en el punto 8.5.6.
8.5 RESPONSABILIDAD FINANCIERA
8.5.1 Cuando una de las Instituciones reciba dictamen en contra, y tenga el Pago
de la Tarjeta de Crédito de la partida en disputa, se ve afectado
financieramente por caso, con lo siguiente: penalización por
Convencionales por Incumplimiento), honorarios vigentes con el Árbitro
Operativo designado por las Instituciones, el monto de la partida en
disputa así como del cobro de los intereses moratorios respectivos; de
acuerdo al calculo siguiente:
días importe en
calendario x (T.I.I.E. x 2.5 ) x disputa
360
Los días calendarios son a partir del contracargo o representación del

importe en disputa.
Capítulo VIII 14

8.5.2 Cuando una de las Instituciones reciba dictamen en contra y no tenga el
Pago de la Tarjeta de Crédito en disputa, se ve afectado financieramente
por caso, con lo siguiente: penalización por emplazamiento, de acuerdo al
punto 18, del capítulo V (Penas Convencionales por Incumplimiento),
honorarios vigentes con el Árbitro Operativo designado por las
Instituciones.
8.5.3 La Institución que recibe el dictamen a favor y no tenga el Pago de la

Tarjeta de Crédito tiene derecho a cobrar el monto en disputa, los
intereses moratorios respectivos a partir de la presentación del
contracargo o representación al día del fallo y la penalización por
8.5.4 La Institución que recibe el dictamen a su favor y tenga el Pago de la

Tarjeta de Crédito, tiene derecho a cobrar el monto de la penalización por
8.5.5 El cobro de los importes detallados en el punto 8.5 del presente Capítulo,
se efectúan vía transferencia electrónica (misceláneo transacción 10
código de razón 110); de no ser así se rechaza y sigue su plazo de
presentación en un plazo no mayor a 5 días hábiles a partir de la fecha de
recepción del dictamen a favor, en caso de incumplimiento pierde el
derecho del cobro.
8.5.6 La Institución que solicite el retiro de emplazamiento debe pagar a la

contraparte el importe en disputa, la penalización por retiro de
Convencionales por Incumplimiento), más los honorarios
correspondientes por retiro vigentes con el Árbitro Operativo.
8.5.7 La responsabilidad financiera de la Institución que resulte con el dictamen

en contra por el cobro o pago de misceláneos improcedentes, es por el
importe del cargo de la partida en disputa, más la penalización por
Convencionales por Incumplimiento), intereses moratorios de acuerdo al
punto 8.5.1 de este capítulo, más los honorarios correspondientes
vigentes con el Árbitro Operativo.
EJEMPLO DE RESPONSABILIDADES FINANCIERAS
Costo
Acción Fallo Importe financiero Penalización Honorarios
A FAVOR Cobro Cobro Cobro N. A.

Emisor
EN
CONTRA N. A. N. A. Paga Paga
Capítulo VIII 15

A FAVOR N. A. N. A. Cobro N. A.
Adquirente
EN
CONTRA Paga Paga Paga Paga
Capítulo VIII 16

CAPÍTULO IX
INTERCAMBIO DE TRANSACCIONES
DE PEAJE EN CARRETERAS
Capítulo IX 1

INTERCAMBIO DE TRANSACCIONES ON LINE DE PEAJE EN
CARRETERAS
OBJETIVO Y ANTECEDENTES
Regular las Transacciones derivadas del pago de Cuotas de Peaje en la Red

Nacional de Carreteras, salvo las condiciones que se especifiquen en el contenido
del presente documento.
El objetivo principal es la modernización de los esquemas de pago en este nicho

de mercado y otorgar a los Tarjetahabientes la posibilidad de evitar el uso de
dinero en efectivo para el pago de Cuotas de Peaje en Carreteras, utilizando un
esquema ágil y eficiente tanto para el Tarjetahabiente como para la infraestructura
carretera.
Las PARTES acuerdan celebrar el presente Acuerdo Operativo, conforme a las

siguientes Reglas Generales:
1. REGLAS OPERATIVAS
1.1 Las transacciones derivadas del uso de la Red de Carreteras de cuota por
el pago del correspondiente Peaje, se intercambian de acuerdo a lo
establecido en las Reglas para la Organización, Funcionamiento y
Operación de Cámaras de Compensación para Pagos con Tarjetas.
1.2 Las transacciones se deben realizar con tarjeta presente, deslizada ó con
lectura de CHIP (En línea, PEM 90, 05, 07 u 80), el Punto de Venta
procesa la transacción mediante la lectura de la banda magnética de la
tarjeta ó del CHIP y genera una solicitud de autorización al Emisor, sin que
se emita Comprobante.
Ante la no emisión del Comprobante, el Receptor de Pagos continua siendo

el responsable por la cobertura del Seguro de Viaje, en caso de siniestro
ante los Tarjetahabientes.
Esta operativa aplica únicamente al giro 4784 Cuota - Puentes, (Cuotas y

Tarifas - Puentes y Carreteras).
Capítulo IX 2

2 SOLICITUD DE COMPROBANTES
2.1 La solicitud de Comprobantes dado que no existe un comprobante que la
terminal emita estas solicitudes se atienden mediante el Comprobante de
Peaje (Anexo 27), que proporcione el Receptor de Pagos por medio del
Adquirente, el costo por atención de Comprobantes es el que se indica en
el punto “B” del capítulo IV (Costos de Servicios) del Manual Operativo, en
caso de no atender la petición el Emisor puede contracargar por código de
Razón 79 (Copia u original del Documento no Atendido).
3 CONTRACARGOS
3.1 Las transacciones de peaje no reconocidas por los tarjetahabientes, pueden

ser contracargadas de acuerdo a las opciones del código de razón 76
(Peaje en Carreteras).
3.2 El Emisor puede utilizar cualquier otro código de razón de los señalados en
el Capítulo II (Resolución de Controversias) cuando aplique, apegándose
las condiciones del código que utilice.
Capítulo IX 3

CAPÍTULO X
SERVICIOS DE PAGO
RAPIDO (QPS)
Capítulo X 1
ANTECEDENTES
Las Partes acuerdan regular por medio del presente Capítulo, las transacciones
realizadas por medio de la Operativa de Servicio de Pagos Rápidos (QPS), en
Receptores de Pagos, así como la resolución de controversias derivadas del
Intercambio entre Adquirentes y Emisores.
REGLAS OPERATIVAS
1. El Servicio de Pagos Rápidos (QPS), aplica para todos los Giros, excepto para
los señalados en el Anexo 25 (Giros operativas especiales) y permite que en
transacciones con presencia física del plástico, Autorización en línea (On Line)
y por un importe igual o menor al establecido en el punto “K” del capítulo IV
(Costos de Servicios) del Manual Operativo, no es necesario recabar la firma
del Tarjetahabiente en el Comprobante.
2. La Autorización debe ser en línea (On line), debe de viajar en el campo 63
token C4, subcampo 12 valor 5 presencia física de la Tarjeta.
3. Esta operativa aplica a los Bines registrados en el anexo 1.
4. Los Comprobantes operados bajo está Operativa no contienen firma, cuando el
monto sea menor o igual al establecido en el punto “K” del Capítulo IV (Costos
de Servicios), del Manual Operativo, no obstante el Comprobante
invariablemente debe contener la leyenda “Autorizado Sin Firma” o "Autorizado
Sin PIN" (Impresión en línea, manual y/o sello).
5. Las transacciones por importes mayores a lo establecido en el punto “K” del

Capítulo IV (Costos de Servicios), son consideradas como transacciones
electrónicas y deben ser operadas bajo las normas actuales de aceptación
establecidas en el Manual operativo, para lo cual invariablemente deben
recabar la firma autógrafa/electrónica del Tarjetahabiente.
6. El Adquirente es responsable de establecer y validar que sus Receptores de
Pagos se apeguen a las normas de Aceptación de ésta Operativa
7. Lo no previsto en éste Capítulo será resuelto de acuerdo a las Reglas del

Manual Operativo.
Capítulo X 2
CAPÍTULO XI
COMERCIO ELECTRÓNICO
Capítulo XI 1

OBJETIVO
Regular las transacciones locales realizadas por comercio electrónico, basado en el manejo
de los indicadores así como las condiciones en el proceso de Resolución de Controversias.
Las operaciones de Comercio Electrónico, están reguladas por el presente documento en lo

particular y de manera general por el Manual Operativo.
Por Comercio Electrónico se consideran las transacciones que tienen medio de acceso Q2
valor 09, establecido en el documento de Especificación Técnica (Indicadores en Proceso
Línea Campo 63, Anexo 4I).
1.- Transacciones autenticadas mediante 3DSecure (3DS 1.0)
1.1.- Características de las transacciones 3DSecure
Las transacciones procesadas con valor ECI = “5” o “6” son responsabilidad del Emisor
(Cambio de responsabilidad “Liability Shift”), por lo que no pueden ser contracargadas,
siempre y cuando cumplan con las características señaladas en esta normativa.
Los valores ECI que responden las marcas Visa y MasterCard son distintos, por lo que, los
valores de MasterCard se mapean al 5 y 6, en el intercambio local, realizado por las Cámaras
de Compensación.
ECI VISA MASTERCARD RED MX
Autenticación Exitosa 5 02 5
Intento de Autenticación 6 01 6
Las PARTES acuerdan que el XID no es necesario para MasterCard y se debe de considerar
la integración del XID para Visa como “requerida” en transacciones 3DSecure, en el Token
C6, de acuerdo a lo establecido en el documento de Especificación Técnica (Indicadores en
Proceso Línea Campo 63, Anexo 4I).
En 3DSecure todos los emisores deben soportar los Token C6 y Token CE de la RED MX,
los cuales contienen el criptograma CAVV/AAV.
Las transacciones con indicador ECI 5 deben contar con el criptograma CAVV/AAV.
Las transacciones con indicador ECI 6 deben contar con el criptograma CAVV/AAV siempre
y cuando se trate de un Intento de Autenticación y esta no se lleva a cabo debido a que el
Capítulo XI 2

emisor permite al tarjetahabiente no enrolarse durante la compra.
Si el emisor recibe una transacción con indicador ECI 5, el criptograma CAVV/AAV debe ser
validado.
Si el emisor recibe una transacción con indicador ECI 6, el criptograma CAVV/AAV debe ser
validado cuando sea generado por el ACS.
El adquirente (receptor de pagos) no debe enviar un ECI 5 o 6 derivado de un valor “Y” o “A”
en el campo de estatus del PARes, sin el criptograma CAVV/AAV, en caso de hacerlo, la
transacción se considera no autenticada y se le da el tratamiento de un valor ECI 7 en el
proceso de aclaraciones.
Capítulo XI 3

Las transacciones de 3DSecure se determinan mediante las fases siguientes:
Fase 1 – Verificación de Enrolamiento (VERes)
Revisión en el Directory Server (DS) de las marcas para verificar la participación en el

programa 3DSecure. Las respuestas del DS y la responsabilidad de las Instituciones se
indican en el siguiente cuadro:
VERes
Status Field Valor ECI
(Verify
Descripción Comentarios Responsable
Enrollment
Response Visa MasterCard
Code)
El DS contesta al MPI Únicamente en
No aplica – El No aplica – El El MPI envía un
que la autenticación este caso, el
ECI es ECI es PAReq al ACS del
para ese BIN de proceso
Y determinado determinado emisor para llevar
tarjeta está disponible continua con el
por el resultado por el resultado a cabo el proceso
y le informa la URL paso 2;
del PARes del PARes de autenticación
del ACS PAReq al ACS
El MPI procede
con la transacción,
La tarjeta no ha sido la envía con valor
N inscrita en el 6 01 ECI 6 ó 01 y deja Emisor
programa el campo CAVV /
AAV en blanco o
ceros
No es posible
procesar esa tarjeta,
no es elegible o no
participa en el
U programa por
definición (por ejemplo
Tarjetas Corporativas,
Comerciales,
Prepagas) Si el Adquirente
decide enviar la
El VEReq no pudo 7 Nulo transacción, lo Adquirente
Fallo en procesar la petición debe hacer como
la debido a que el MPI “No autenticada”
validación no proporciono
de los credenciales validas al
campos DS. Campo con un
valor invalido
Error en Error en el mensaje

el de la transacción o en
mensaje el formato del mismo
Capítulo XI 4

Fase 2 – Respuesta de Autenticación (PARes)
Si la respuesta del DS es “Y”, se envía la petición al Access Control Server (ACS) del Emisor
para solicitar la autenticación del tarjetahabiente. La respuesta del ACS así como la
responsabilidad de la transacción se indican en el siguiente cuadro:
PARes Status Valor ECI

Field
Descripción Comentarios Responsable
(Authentication
Response Code) Visa MasterCard
Autenticación Exitosa: El El MPI envía el

tarjetahabiente ingreso mensaje al
correctamente su autorizador con
Y 5 02 Emisor
contraseña (o la forma de ECI 5 ó 02 y el
autenticación que haya CAVV / AAV
definido el emisor). correspondiente
Intento de Autenticación. La
El MPI envía el
autenticación no se lleva a
mensaje al
cabo debido a que el
autorizador con
A emisor permite al 6 01 Emisor
ECI 6 ó 01 y el
tarjetahabiente no
CAVV / AAV
enrolarse durante la
correspondiente
compra.
La Autenticación no puede
llevarse a cabo: Puede
existir alguna condición que Si el Adquirente
impida realizar la decide enviar la
U autenticación por ejemplo 7 Nulo transacción, la Adquirente
time out, error de sistema, debe hacer como
datos inconsistentes de la “No Autenticada”
transacción, transacción
mal canalizado, etc.
Autenticación Errónea: El
tarjetahabiente no ingreso
la contraseña previamente
N registrada para la tarjeta (o
falla en la forma de
autenticación que haya
definido el emisor)
El MPI no debe
enviar esta
Hay algún problema con la
Fallo en la solicitud de
validación de los campos y
validación de N/A N/A autorización por Adquirente
las llaves (no importa el
los campos tratarse de una
estatus del VERes)
transacción que no
es segura.
Error en el mensaje de la
Error en el
transacción o en el formato
mensaje
del mismo
Capítulo XI 5

Los Emisores pueden Contracargar por Código de Razón 68 Opciones B y D, las
Transacciones que reclamen sus Tarjetahabientes por transacción no reconocida, si al
revisar el Anexo 32 (Reportes de Valores ACS Certificado), se encuentra alguno de los
siguientes escenarios:
§ El campo de Estatus del VERes muestra el valor “U”

§ El campo de Estatus del VERes muestra código de error
§ El campo de Estatus del PARes muestra un valor distinto a “Y” o “A”
§ El campo de Estatus del PARes muestra un valor igual a “Y” o “A” y no presenta
CAVV/AAV
VALIDACIÓN DEL CAVV / AAV
Adquirente Emisor Responsabilidad
No envía CAVV/AAV No puede Validar Adquirente aún si existe ECI 5
Adquirente aún si existe ECI 6

No envía CAVV/AAV No puede Validar
(Solo para el caso del Attempt)
Valida o no el
Envía CAVV/AAV Emisor siempre que autorice
CAVV/AAV
1.2.- Proceso On Line
La información de comercio electrónico bajo el esquema 3DSecure en el mensaje de

autorización, esta normado en el Documento de Especificación Técnica (Indicadores en
Proceso Línea Campo 63, Anexo 4I) en el campo 63 de la mensajería, donde se incluyen los
siguientes tokens:
§ Token Q2 Subcampo 1: Indicador del medio de acceso que realiza la solicitud de

autorización valor 9 (Internet Comercio Electrónico).
§ Token C0 Subcampo 1: validar que este poblado con cuatro caracteres CVV2, CVC2 o
espacios en blanco.
§ Token C0 Subcampo 8: Indicador de presencia del CV2 valores válidos (0,1, 2, 9).
§ Token C0 Subcampo 10: Authentication collector indicator valores válidos (0, 1, 2).
§ Token C0 Subcampo 12: Resultado de la validación del CAVV/AAV por parte del
emisor, valores válidos (0,1, 2, 3, 4, 5, 6, 7).
§ Token C0 Subcampo 5: Indicador de Comercio Electrónico, valores válidos (5, 6, 7).
§ Token 04 Subcampo 3 Bandera de verificación de la tarjeta, valores válidos “ ”.
§ Token C4 Subcampo 1: Indicador si la terminal es atendida por el adquirente valor 1
(terminal no es atendida, ej. PC).
§ Token C4 Subcampo 3: Localización de la terminal valor 2 (la terminal está en la
Capítulo XI 6

ubicación del tarjetahabiente, ej. Comercio electrónico).
§ Token C4 Subcampo 4: Indicador de presencia o no del tarjetahabiente valor 5 (el
tarjetahabiente no está presente, orden electrónica desde una PC o Internet).
§ Token C4 Subcampo 5: Indicador de presencia o no de la tarjeta valor 1 (la tarjeta no
está presente).
§ Token C4 Subcampo 10: Indicador de activación de la terminal por el
tarjetahabiente valor 6 (comercio electrónico).
§ Token C6 Subcampo 1: XID.
§ Token C6 Subcampo 2: CAVV.
§ Token CE Subcampo 1: Indicador UCAF.
§ Token CE Subcampo 2: Datos de autenticación del tarjetahabiente en formato Ans-28
base 64 encoded.
Cabe aclarar que si se envía el Token CE no se envía el C6 y viceversa, ya que el Token

CE corresponde a tarjetas MasterCard y el C6 a tarjetas Visa.
1.3.- Proceso Batch
En el proceso de intercambio las transacciones realizadas a través de 3DSecure, deben

considerarse los siguientes campos, los cuales se envían en el archivo de intercambio
(Anexo 4):
§ Campo 34 - Indicador de Medio de Acceso valor 09.

§ Campo 21 - Indicador de Comercio Electrónico valor 5, 6, 7.
§ Campo 37 - Resultado de la autenticación valor CAVV (Método de Visa) y AAV
(Método de MasterCard).
1.4.- Solicitud de Documentos
1.4.1.- Para la atención de documentos de transacciones con ECI (Indicador de Comercio

Electrónico) valor 5 ó 6 el adquirente proporcionará el Anexo 18 (Log de Autorizaciones)
como Documento comprobatorio.
1.4.2.- Si un Adquirente atiende con Log de Autorizaciones transacciones de comercio

electrónico no Autenticadas con valor ECI diferentes a 5 ó 6 se pueden contracargar por
código de razón 60 opción C (Original o Copia recibida Ilegible, con Datos Incompletos
o No Corresponde) ó 68 (Transacción de Orden Telefónico/Correo/Internet fraudulenta).
Capítulo XI 7

1.4.3.- El reporte Access Control Server “ACS” de los Emisores y el reporte del Merchant
Plug In “MPI” de los Adquirentes, debe contener como mínimo los siguientes campos:
Fecha de la transacción
Número de Cuenta
Monto de la transacción
Número de Afiliación
Resultado de Autenticación
Indicador de Comercio Electrónico (ECI)*
Campo de estatus VERes
Campo de estatus PARes
Campo CAVV/AAV
Identificador de la transacción (XID)
* Los valores ECI que responden las marcas Visa y MasterCard son distintos, por lo que,
los valores de MasterCard se mapean al 5 y 6, sin embargo, en el Anexo 32 (Reportes de
Valores de Autenticación), se graban los valores originales de las marcas.
Capítulo XI 8

1.5.- Solución de Controversias
1.5.1.- Cuando un Adquirente represente transacciones argumentando que se trata de 3D

Secure 1.0, debe adjuntar copia del Anexo 32 certificado de su MPI para demostrar que la
transaccion fue autenticada o que hubo un intento de autenticación, En caso de no adjuntar
el documento antes mencionado, la representación se considera improcedente.
Capítulo XI 9

2.- Transacciones autenticadas mediante EMV 3DS (3DS 2.0)
2.1.- Características de las transacciones EMV 3DS
Las transacciones procesadas con valor ECI = “5” o “6” son responsabilidad del Emisor
(Cambio de responsabilidad “Liability Shift”), por lo que no pueden ser contracargadas,
siempre y cuando cumplan con las características señaladas en esta normativa.
Los valores ECI que responden las marcas Visa y MasterCard son distintos, por lo que, los
valores de MasterCard se mapean al 5 y 6, en el intercambio local, realizado por las Cámaras
de Compensación.
Autenticación Exitosa
N/A 06 5
(excepción del emisor)
N/A 07 5
(transacción recurrente)
El XID no se requiere para MasterCard ni para Visa en EMV 3DS.
En EMV 3DS todos los emisores deben soportar los Token C6 y Token CE de la RED MX,
los cuales contienen el criptograma CAVV/AAV.
Las transacciones con indicador ECI 5 deben contar con el criptograma CAVV/AAV.
Las transacciones con indicador ECI 6 deben contar con el criptograma CAVV/AAV siempre
y cuando se trate de un Intento de Autenticación y esta no se lleva a cabo debido a que el
emisor permite al tarjetahabiente no enrolarse durante la compra.
Capítulo XI 10

Si el emisor recibe una transacción con indicador ECI 5 y el criptograma CAVV/AAV, éste
debe ser validado.
Si el emisor recibe una transacción con indicador ECI 6, y el criptograma CAVV/AAV, éste
debe ser validado cuando el criptograma sea generado por el ACS del emisor.
El adquirente (receptor de pagos) no debe enviar un ECI 5 o 6 derivado de un valor “Y” o “A”
en el campo de estatus del ARes o de un valor “A” en el campo de estatus del CRes, sin el
criptograma CAVV/AAV, en caso de hacerlo, la transacción se considera no autenticada y se
le da el tratamiento de un valor ECI 7 en el proceso de aclaraciones. Para Visa es cuando el
campo del criptograma se encuentre vacío y en el caso de MasterCard es cuando el campo
del criptograma se encuentre vacío y el formato del AAV no sea el correcto.
En EMV 3DS se cuentan con las siguientes definiciones:
EMV 3DS Message Descripción
AReq / Ares Del 3DServer al DS y Regreso
RReq / Rres Del ACS al 3DServer y Regreso
CReq / Cres Del 3DServer al ACS y Regreso
PPeq / Ppes Del 3DServer al DS
Capítulo XI 11

2.2.- Descripción general EMV 3DS
Esta descripción general describe los componentes, los sistemas y las funciones necesarias
para implementar EMV 3DS. Las descripciones se dividen en los siguientes dominios:
§ Dominio del Adquirente: las transacciones EMV 3DS se inician desde el dominio del
adquirente.
§ Dominio de Interoperabilidad: las transacciones EMV 3DS se cambian entre el
dominio del adquirente y el dominio del emisor.
§ Dominio del Emisor: las transacciones EMV 3DS se autentican en el dominio del
emisor.
La Figura 1 muestra la interacción de los tres dominios y los componentes de cada uno.
Debido a que la implementación del entorno del “EMV 3DS Requestor” puede variar, el
diagrama propuesto no implica una implementación específica de estos componentes o
cómo interactúan. Por ejemplo, el “EMV 3DS Client” puede comunicarse directamente con el
“EMV 3DS Server”, o el “EMV 3DS Server” y el “EMV 3DS Requestor” pueden combinarse
funcionalmente.
Figura 1: Dominios y Componentes en EMV 3DS
Fuente: EMV 3-D Secure Protocol and Core Functions Specification v2.2.0
2.3.- Flujos de autenticación EMV 3DS
Capítulo XI 12

Existen 2 tipos de flujo de autenticación definidos en EMV 3DS:
§ Flujo sin fricción (Frictionless Flow)

§ Flujo con desafío (Challenge Flow)
2.3.1.- Flujo EMV 3DS sin fricción (Frictionless Flow)
§ EMV 3DS Requestor Environment: Todos los componentes en el dominio del

adquirente.
§ EMV 3DS Server: Anteriormente Merchant Plug In (MPI).
§ EMV 3DS Client: Componente dirigido al consumidor. Se puede implementar In-App
(SDK de EMV 3DS) y en compras en el navegador (método EMV 3DS).
§ Solicitud/Respuesta de autenticación (AReq/ARes).
Figura 2: Flujo EMV 3DS sin fricción
Capítulo XI 13

2.3.2.- Flujo EMV 3DS con desafío (Challenge Flow)
Ø EMV 3DS Requestor Environment: Todos los componentes en el dominio del

adquirente.
Ø EMV 3DS Server: Anteriormente Merchant Plug In (MPI).
Ø EMV 3DS Client: Componente dirigido al consumidor. Se puede implementar In-App
(SDK de EMV 3DS) y en compras en el navegador (método EMV 3DS).
Ø Solicitud/Respuesta de autenticación (AReq/ARes).
Ø Solicitud/Respuesta de desafío (CReq/Cres).
Ø Solicitud/Respuesta de resultados (RReq/Rres).
Figura 3: Flujo EMV 3DS con desafío
Capítulo XI 14

2.4.- Fases de la transacción EMV 3DS
Las transacciones de EMV 3DS se determinan mediante las fases siguientes:

Ø Fase 1 - Messages EMV 3DS (Authentication)
Ø Fase 2 - Secure Messages EMV 3DS (Results and Challenge)
Ø Fase 3 - Secure Messages EMV 3DS (Preparation)
2.4.1.- Messages EMV 3DS (Authentication)
Ø Mensaje de Solicitud de Autenticación (AReq)

Mensaje enviado por el EMV 3DS Server a través del Directory Server (DS) al Access Control
Server (ACS) para iniciar el proceso de autenticación.
Ø Mensaje de Respuesta de Autenticación (ARes)

Mensaje devuelto por el ACS a través del DS en respuesta a un mensaje AReq (el
tarjetahabiente está autenticado o se requiere una mayor interacción del tarjetahabiente).
Figura 4: Messages EMV 3DS (Authentication)
Capítulo XI 15

2.4.2.- Secure Messages EMV 3DS (Results and Challenge)
Ø Mensaje de Solicitud del Challenge (CReq)

Mensaje enviado por el EMV 3DS SDK o el 3DS Server donde se envía información adicional
del tarjetahabiente al ACS para respaldar el proceso de autenticación.
Ø Mensaje de Respuesta del Challenge (CRes)

Es la respuesta del ACS al mensaje CReq. Puede indicar el resultado de la autenticación del
tarjetahabiente o, en el caso de un modelo basado en App, también indicar que se requiere
mayor interacción con el tarjetahabiente para completar la autenticación.
Ø Mensaje de Solicitud de Resultados (RReq)

Mensaje enviado por ACS a través del DS para transmitir los resultados de la transacción
autenticada al EMV 3DS Server. Este mensaje solo está presente en una autenticación que
requiera un Challenge al tarjetahabiente.
Ø Mensaje de Respuesta de Resultados (RRes)

Mensaje enviado por el EMV 3DS Server a través del DS como acuse de recibo del mensaje
de solicitud de resultados. Este mensaje solo está presente en una autenticación que
requiera un Challenge al tarjetahabiente.
Figura 5: Secure Messages EMV 3DS (Results and Challenge)
Capítulo XI 16

2.4.3.- Secure Messages EMV 3DS (Preparation)
Ø Mensaje de Solicitud de Preparación (PReq)

Mensaje enviado desde el EMV 3DS Server al DS para solicitar las versiones del ACS que
corresponden a los rangos de tarjeta del DS, así como opcionalmente el EMV 3DS Method
URL para actualizar la información del almacenamiento interno del EMV 3DS Server.
Ø Mensaje de Respuesta de Preparación (PRes)

Respuesta al mensaje PReq que contiene los rangos de tarjeta del DS y el EMV 3DS Method
URL para que se pueda realizar la actualización de la información de almacenamiento interno
del EMV 3DS Server.
Figura 6: Secure Messages EMV 3DS (Preparation)
Capítulo XI 17

2.5.- Valores de estatus de la transacción en EMV 3DS
Valores de Descripción delos

CAVV /
Mensaje Estatus de la Valores de Estatus de la ECI
AAV
Transacción Transacción
Y Autenticación Exitosa 5
Intento de procesamiento SI
Solicitud de Autenticación / A 6
Respuesta realizado (Attempts)
Fallo Autenticación;
(AReq / ARes) N
No autenticado
El 3DS Server envía el AReq a través No se pudo realizar
del DS al ACS del Emisor o el U autenticación; Problema
Attempts al ACS técnico u otro 7 NO
Una vez recibido, el ACS del Emisor R Autenticación rechazada

o el Attempts del ACS realiza una
autenticación basada en riesgo y Challenge requerido,
proporciona los resultados de la comercio abandona flujo
autenticación al 3DS Server en el C de autenticación
ARes Challenge requerido,
Considerar
comercio continúa flujo de
resultado del CRes
autenticación
Valores de Descripción de los
CAVV /
Mensaje Estatus de la Valores de Estatus de la ECI
AAV
Transacción Transacción
Solicitud de Challenge / Respuesta
(CReq / CRes)
Y Autenticación Exitosa 5 SI
El EMV 3DS Server (o EMV 3DS
SDK) envía el CReq al ACS del
Emisor
Una vez recibido, el ACS del Emisor

realiza el Challenge al tarjetahabiente
a través de un método de N No autenticado 7 NO
autenticación como un OTP y
responde al EMV 3DS Server o al
EMV 3DS SDK con el CRes
Ø Los resultados del Challenge se envían en el mensaje de Solicitud de Resultados

(RReq) por el ACS al EMV 3DS Server.
Ø Y, N, U o A, el comercio puede proceder a solicitar la autorización utilizando valor ECI
correcto y CAVV/AAV (CAVV/AAV solo aplica para Y o A) proporcionando por el
ACS/Attempts Server del Emisor.
Ø R, no se recomienda proceder a la solicitud de autorización.
Ø C, el flujo EMV 3DS sin fricción (Frictionless Flow) hace la transición al flujo EMV 3DS
con desafío (Challenge Flow).
En caso de enviar una solicitud de autorización con ECI 7 será responsabilidad del
Capítulo XI 18

adquirente/comercio.
Excepciones
Ø ERROR RECEIVED – Si el EMV 3DS Server recibe un mensaje de error, el comercio

puede proceder con la solicitud de autorización utilizando un valor ECI 7 (transacción
de comercio electrónico no autenticada).
Capítulo XI 19

2.6.- Valores de estatus de la transacción en disputa
Restricción ECI Descripción
Los comercios no están protegidos cuando el ECI es

5 o 6 y no está presente el CAVV/AAV en la
CAVV/AAV no presente 5o6 autorización.
Reclasificar con ECI a 7.
Los comercios no están protegidos cuando el tipo de

tarjeta es una de prepago no recargable.
Prepago no recargable 6
Reclasificar con ECI a 7.
Si el adquirente (receptor de pagos) envía un ECI 5 o 6 sin el criptograma CAVV/AAV en la

transacción, la empresa especializada debe degradar la transacción con ECI 7 de acuerdo
al estándar; Para Visa es cuando el campo del criptograma se encuentre vacío y en el caso
de MasterCard es cuando el campo del criptograma se encuentre vacío y el formato del AAV
no sea el correcto.
Descripción ECI Aplicabilidad
CAVV/AAV no presente 5o6 Todas las transacciones
Prepago no recargable 6 Todas las transacciones
Los Emisores pueden Contracargar por Código de Razón 68 Opciones B y D, las

Transacciones que reclamen sus Tarjetahabientes por transacción no reconocida, si al
revisar el Anexo 32 (Reportes de Valores ACS Certificado), se encuentra alguno de los
siguientes escenarios:
Ø El campo de Estatus del ARes muestra el valor “U”, “R” o “N”

Ø El campo de Estatus del ARes muestra código de error
Ø El campo de Estatus del ARes muestra un valor distinto a “Y” o “A”
Ø El campo de Estatus del ARes muestra un valor igual a “Y” o “A” y no presenta
CAVV/AAV.
Ø El campo de Estatus del CRes muestra un valor distinto a “Y”
Ø El campo de Estatus del CRes muestra un valor igual a “Y” y no presenta CAVV/AAV.
VALIDACIÓN DEL CAVV / AAV

Adquirente Emisor Responsabilidad
No envía CAVV/AAV No puede Validar Adquirente aún si existe ECI 5
No envía CAVV/AAV No puede Validar Adquirente aún si existe ECI 6 (Solo para
Capítulo XI 20

el caso del Attempt)
Envía CAVV/AAV Valida o no el CAVV/AAV Emisor siempre que autorice
La información de comercio electrónico bajo el esquema EMV 3DS en el mensaje de

autorización, esta normado en el Documento de Especificación Técnica (Indicadores en
Proceso Línea Campo 63, Anexo 4I) en el campo 63 de la mensajería, donde se incluyen los
siguientes tokens:
Ø Token Q2 Subcampo 1: Indicador del medio de acceso que realiza la solicitud de

Ø Token C0 Subcampo 1: validar que este poblado con cuatro caracteres CVV2, CVC2
o espacios en blanco.
Ø Token C0 Subcampo 8: Indicador de presencia del CV2 valores válidos (0,1, 2, 9).
Ø Token C0 Subcampo 10: Authentication collector indicator valores válidos (0, 1, 2).
Ø Token C0 Subcampo 12: Resultado de la validación del CAVV/AAV por parte del
emisor, valores Válidos (0,1, 2, 3, 4, 5, 6, 7).
Ø Token C0 Subcampo 5: Indicador de Comercio Electrónico, valores válidos (5, 6, 7).
Ø Token 04 Subcampo 3 Bandera de verificación de la tarjeta, valores válidos “ ”.
Ø Token C4 Subcampo 1: Indicador si la terminal es atendida por el adquirente valor 1
Ø Token C4 Subcampo 3: Localización de la terminal valor 2 (la terminal está en la
Ø Token C4 Subcampo 4: Indicador de presencia o no del tarjetahabiente valor 5 (el
tarjetahabiente no está presente, orden electrónica desde una PC o Internet).
Ø Token C4 Subcampo 5: Indicador de presencia o no de la tarjeta valor 1 (la tarjeta no
está presente).
Ø Token C4 Subcampo 10: Indicador de activación de la terminal por el
Ø Token C6 Subcampo 2: CAVV.
Ø Token CE Subcampo 1: Indicador UCAF (AAV)
Ø Token CE Subcampo 2: Datos de autenticación del tarjetahabiente en formato Ans-
28 base 64 encoded.
Ø Token RJ Subcampo 1: Indicador de Protocolo 3DS
o [Program Protocol – MasterCard]
§ Valores válidos (0, 1, 2)
o [3DS Indicator - Visa]
§ Valores válidos (0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, D, E, F)
Ø Token RJ Subcampo 2: DS-TXN-ID.
Cabe aclarar que si se envía el Token CE (MasterCard-UCAF), no se debe enviar el Token

C6 (Visa-CAVV) y viceversa, ya que cada Token almacena el criptograma utilizado por
cada una de las marcas, es decir; son mutuamente excluyentes.
Capítulo XI 21

En transacciones EMV 3Dsecure 2.0 con tarjetas marca Visa, se debe de respetar la
estructura del token RJ en ambiente doméstico, es decir; el Adquirente deberá enviar el
Token sin información. Este se debe de mandar con espacios conservando la estructura
definida en el Anexo 4I - Especificación Técnica de Indicadores Campo 63.
2.8.- Proceso Batch
En el proceso de intercambio las transacciones realizadas a través de EMV 3DS, deben

considerarse los siguientes campos, los cuales se envían en el archivo de intercambio
(Anexo 4):
Ø Campo 34 Indicador de Medio de Acceso valor 09

Ø Campo 21 Indicador de Comercio Electrónico valor 5, 6, 7.
Ø Campo 37 Resultado de la autenticación valor CAVV (Método de Visa) y AAV
(Método de MasterCard)
2.9.1.- Para la atención de documentos de transacciones con ECI (Indicador de Comercio

Electrónico) valor 5 ó 6 el adquirente únicamente proporcionará el Log de Autorizaciones
como Documento comprobatorio, cuando el Log de Autorizaciones no contenga los
valores completos de la autenticación el Adquirente adicionalmente debe enviar el Anexo
32 (Reportes de Valores de Autenticación) certificado, para el valor 7 debe enviar la
documentación establecida para transacciones de comercio electrónico no autenticadas,
en ambos casos de acuerdo a lo señalado en el Anexo 15 (Datos Legibles y Mandatorios
que deben contener los Documentos de Tarjetas)

electrónico no Autenticadas con valor ECI diferentes a 5 ó 6 se pueden contracargar por
código de razón 60 (Original o Copia recibida Ilegible o con Datos Incompletos) ó 68
(Transacción de Orden Telefónico/Correo/Internet fraudulenta).
2.9.3.- El reporte Access Control Server “ACS” de los Emisores y el reporte del EMV 3DS
Server (anteriormente MPI) de los Adquirentes, debe contener como mínimo los
siguientes campos:
Fecha de la transacción
Número de Cuenta
Monto de la transacción
Número de Afiliación
Resultado de Autenticación
Indicador de Comercio Electrónico (ECI)*
Campo de estatus AReq
Campo de estatus Ares
Campo del estatus RReq
Capítulo XI 22

Campo del estatus RRes
Campo de estatus CReq
Campo de estatus CRes
Campo CAVV/AAV
Indicador de Protocolo 3DS [Program Protocol - 3DS Indicator]
* Los valores ECI que responden las marcas Visa y MasterCard son distintos, por lo que,
los valores de MasterCard se mapean al 5 y 6, sin embargo, en el Anexo 32 (Reportes de
Valores de Autenticación), se graban los valores originales de las marcas.
Autenticación Exitosa 5 02
5
N/A 06 5
(excepción del emisor)
N/A 07 5
Capítulo XI 23

3.- Validación de un Adquirente
3.1.- Cuando el Emisor reciba reclamación de un tarjetahabiente y detecte que un Adquirente

está presentando valores diferentes a los indicados para 3DSecure (tablas del punto 1.1 de
este Capítulo) o EMV 3DS (tabla del punto 2.5 de este Capítulo), entre el log de
Autorizaciones y los registros del Access Control Server “ACS”, el Emisor puede solicitar al
Árbitro Operativo un arbitraje de valores de acuerdo a lo siguiente:
El Emisor debe enviar su solicitud de arbitraje acompañando con el Anexo 18 (Log de

Autorizaciones del Adquirente) y el reporte del Access Control Server “ACS” establecido en
el Anexo 32 (Reportes de Valores de Autenticación) certificado, donde se demuestre las
diferencias en los valores de la autenticación.
El Adquirente a solicitud por escrito del Árbitro Operativo, debe presentar su Anexo 32
(Reportes de Valores de Autenticación) en un plazo máximo de 5 días hábiles para entregar
la documentación solicitada, a partir de la fecha de solicitud.
3.2.- El resultado de la revisión de Información es de acuerdo a lo siguiente:
a) El Dictamen realizado por el Arbitro Operativo determina que el Log del Adquirente
presenta Valores Correctos. El Emisor debe cubrir el costo de los honorarios vigentes con
el Arbitro Operativo.
b) El Dictamen realizado por el Arbitro Operativo determina que el Log del Adquirente
presenta Valores Incorrectos y se dictamina como primer evento para el proceso de
penalizaciones del Capítulo V punto 32 y cuenta con 10 días hábiles a partir de la notificación
del Dictamen, para presentar al Árbitro Operativo, el plan de corrección de las diferencias
presentadas en su Log, de continuar en incumplimiento al vencimiento del plazo, se procede
con la aplicación del siguiente inciso de la penalización 32 y cuenta con un nuevo plazo de
10 días hábiles para presentar su plan de corrección.
Si el plan de trabajo excede de 90 días naturales para realizar la corrección, este debe contar
con la aprobación de los participantes.
El Adquirente debe cubrir los importes de la transacción, penalización por emplazamiento,

intereses moratorios de acuerdo a lo establecido en el punto 8.5.1 del Capítulo I del Manual
Operativo, más el costo de los honorarios vigentes con el Arbitro Operativo.
Capítulo XI 24

Primer Evento Segundo Evento
El Adquirente se hará acreedor a lo El Adquirente se hará acreedor a lo

señalado en el punto “a” de la señalado en el punto “b” de la
penalización 32 del capítulo V (Penas penalización 32 del capítulo V (Penas
Convencionales por Incumplimiento) Convencionales por Incumplimiento)
Tercer Evento Cuarto Evento
El Adquirente se hará acreedor a lo

El Adquirente se hará acreedor a lo
señalado en el punto “d” de la
señalado en el punto “c” de la
penalización 32 del capítulo V (Penas
penalización 32 del capítulo V (Penas
Convencionales por Incumplimiento) y
Convencionales por Incumplimiento)
se notifica a los participantes para que
se tome una decisión colegiada.
Los eventos subsecuentes no proceden cuando el Dictamen del Árbitro Operativo con
resultado Valores Incorrectos, se emita dentro del plazo que el Adquirente tiene para
corregir las diferencias de su Log de autorizaciones.
Los casos de aclaraciones no contemplados en esta normativa deben ser gestionados bajo
el proceso de Buena Fe de acuerdo a lo señalado en el punto 9 del Capítulo I de las reglas
operativas.
Capítulo XI 25

4.- Comercio Electrónico Validado por un método diferente a 3DSecure o
EMV 3DS
Operativa que se compone de 2 transacciones, una transacción inicial que se lleva a cabo
mediante Tarjeta No Presente vía Internet y otra complementaria con Tarjeta Presente
que permite autenticar la tarjeta con la que se realizó la transacción inicial, aplica para las
transacciones por Internet sin 3DSecure o EMV 3DS.
4.1.- Indicadores
Las transacciones deben enviar los indicadores especificados en el Anexo 4I,
adicionalmente la transacción complementaria debe contener un PEM de tarjeta presente
(05 o 07).
4.2.- Aclaraciones
Cuando se trata de transacciones de Comercio Electrónico autenticadas por un método
Diferente a 3DSecure o EMV 3DS, el emisor puede contracargar al adquirente por código de
razón 68 y éste puede representar enviando al emisor la siguiente documentación
cumpliendo con los datos mandatorios para cada tipo de documento:
4.3.- Resolución de Controversias
Ø Acuse de recibo de bien o servicio comprado por Internet.

o Folio de Venta
o Fecha de compra original
o Datos del Tarjetahabiente
§ El nombre corto o largo del tarjetahabiente debe coincidir con el
registrado en la plataforma Emisor
o Firma del Tarjetahabiente donde acepta haber recibido el bien o servicio
o No. de Identificación Oficial
o Fecha de Entrega
Ø Log de Autorizaciones Certificado (Anexo 18).

o Log de Autorizaciones de la Venta Original
o Log de Autorizaciones de la Venta por complemento de Servicio (Transacción
importe $10.00)
Ø Comprobante de Pago por Complemento de Servicio con importe de $10.00 con

Tarjeta CHIP (PEM 05,07) que autentica la tarjeta con la cual se realizó la
Transacción Original.
o El Comprobante debe cumplir con los campos mandatorios establecidos en el
Anexo 15 del CID.
o El Receptor de Pagos debe anotar en la parte superior del comprobante, el
“Número de Folio de Venta” proporcionado al tarjetahabiente para recoger
producto o servicio. Evitando dañar, tachar o hacer ilegible la información
mandatoria establecida en el Anexo 15 del CID.
Capítulo XI 26

o El Adquirente debe notificar al Receptor de pagos lo señalado en el párrafo
anterior para que se incluya en sus políticas de entrega del bien o servicio.
Consideración: En caso de que el Receptor de pagos no puede aplicar el cargo por

“complemento de Servicio” con tarjeta presente, la transacción queda como Comercio
Electrónico sin autenticación y puede solicitar otra forma de pago para concretar la entrega
del bien/servició.
El adquirente no tiene derecho a representar cuando los indicadores de la transacción en

disputa no se encuentren alineados al estándar técnico establecido en el Anexo 4I.
El tarjetahabiente tendrá como “máximo” 30 días naturales, a partir de la fecha de la compra
para recoger el bien o servicio.
Flujo de la operación de Comercio Electrónico Validada por un método Diferente a

3DSecure o EMV 3DS
* En caso de que el Receptor de pagos no puede aplicar el cargo por “Complemento de

Servicio” con tarjeta presente, la transacción queda como Comercio electrónico sin 3DSecure
o EMV 3DS (01) y el receptor de pagos puede solicitar otra forma de pago al tarjetahabiente
para concretar la compra total y cobro del servicio, para la entrega del bien/servicio.
Capítulo XI 27

5.- Características de las transacciones de Comercio Electrónico sin
Autenticación
Las transacciones procesadas sin Autenticación son responsabilidad del Adquirente, por lo
que pueden ser contracargadas por el Emisor cuando exista reclamación del tarjetahabiente.
La información de comercio electrónico sin Autenticación en el mensaje de autorización, esta

normado en el Documento de Especificación Técnica (Indicadores en Proceso Línea Campo
63, Anexo 4I) de la mensajería, donde se incluyen los siguientes tokens:
Ø Token Q2 Subcampo 1: Indicador del medio de acceso que realiza la solicitud de

Ø Token C0 Subcampo 1: validar que este poblado con tres caracteres CVV2, CVC2 o
espacios en blanco.
Ø Token C0 Subcampo 5: Indicador de Comercio electrónico, valor válido 7.
Ø Token C0 Subcampo 8: Indicador de presencia del CV2 valores válidos (0,1, 2, 9).
Ø Token 04 Subcampo 3 Bandera de verificación de la tarjeta, valores válidos “ ”.
Ø Token C4 Subcampo 1: Indicador si la terminal es atendida por el adquirente valor 1
Ø Token C4 Subcampo 3: Localización de la terminal valor 2 (la terminal está en la
Ø Token C4 Subcampo 4: Indicador de presencia o no del tarjetahabiente valor 5 (el
tarjetahabiente no está presente, orden electrónica desde una PC o Internet)
Ø Token C4 Subcampo 5: Indicador de presencia o no de la tarjeta valor 1 (la tarjeta no
está presente).
Ø Token C4 Subcampo 10: Indicador de activación de la terminal por el
5.2.- Proceso Batch
En el proceso de intercambio las transacciones realizadas fuera de la plataforma 3DSecure

o EMV 3DS, deben considerarse los siguientes campos, los cuales se envían en el archivo
de intercambio (Anexo 4):
Ø Campo 34 Indicador de Medio de Acceso valor 09.

Ø Campo 21 Indicador de Comercio Electrónico valor 7.
Capítulo XI 28


electrónico no Autenticadas con valor 7 (código ECI) se pueden contracargar por código de
razón 60 (Original o Copia recibida Ilegible o con Datos Incompletos) ó 68 (Transacción de
Orden Telefónico/Correo/Internet fraudulenta).
6.- Incumplimiento en el envío de los Indicadores
Cuando una Cámara de Compensación Emisora o el Emisor detecte inconsistencia en los

valores de los indicadores de comercio electrónico o se detecte al Adquirente enviando
transacciones de comercio electrónico con un Token Q2 diferente a 9, debe enviar el reporte
con su soporte al árbitro operativo para generar lo siguiente:
Amonestación y cuenta con un plazo de 15 días hábiles a partir de la notificación de la

amonestación, para entregar su plan de corrección, dicha corrección no debe exceder 3
meses.
a) En caso de vencerse el plazo señalado en el plan de corrección, el Adquirente

se hace acreedor al punto c) de la penalización 32, y cuenta con un nuevo plazo
de 20 días hábiles para realizar la corrección.
b) En caso de no presentar su plan de trabajo señalado, se hace acreedor a lo

establecido en el punto c) de la penalización 32.
En caso de un nuevo incumplimiento en cualquiera de los dos casos, se notifica al Comité

de Tarjetas para solicitar el bloqueo de la afiliación.
Capítulo XI 29

CAPÍTULO XII
Control y Administración de Afiliaciones
Capítulo XII
Contrato de Intercambio Domestico 1

1.- Reglas para la operación de la Base Única
1.1 DEFINICIÓN
Sistema integral para la gestión del registro de información de Receptores de Pagos / Agregadores,
entre emisores y Adquirentes (llamada SIN-A). Tiene como objetivo principal administrar las
afiliaciones y comportamiento de los Receptores de Pagos y Agregadores. Cada Institución
participante cuenta con un perfil específico para poder tener acceso solo a la información que le
corresponde.
La Base Única es administrada por una empresa especializada (Administrador de la Base Única),
contratada a través de las Cámaras de Compensación en su papel de empresa especializada, las
cuales firman un contrato de prestación de servicios en representación de las Instituciones.
El Administrador de la Base Única entrega a los participantes a través de su empresa especializada

(Cámaras de Compensación) los rangos de afiliaciones y grupos, a su vez cada Cámara es
responsable de distribuirlos a sus Adquirentes.
1.2 OBLIGACIONES DE LAS INSTITUCIONES ADQUIRENTES AL

ADMINISTRADOR DE BASE UNICA.
• Enviar al Administrador de la Base Única los movimientos de altas, bajas y cambios de

Receptores de Pago y/o Agregadores.
• Los movimientos procesados y aprobados por el Administrador de la Base Única, deben ser
aplicados por las Instituciones y/o su empresa especializada (Cámara de Compensación) en
sus sistemas centrales.
• Presentar, cuando el Administrador de la Base Única requiera validar información de acuerdo

a lo establecido en el Anexo 52 (sección Soporte Documental).
• La información de los movimientos enviados al Administrador de la Base Única deben

cumplir con las reglas definidas en este Capítulo y estar soportadas con la documentación
correspondiente.
• Cumplir con el proceso de Confronta especificado en el numeral 9 (Confronta).
1.3 OBLIGACIONES DEL ADMINISTRADOR DE LA BASE ÚNICA
• Mantener una base central con la información de Receptores de Pagos, Agregadores y sus
Subafiliados, de acuerdo a las normas y políticas determinadas en este Capítulo.
• Implementar los controles necesarios a fin de garantizar la integridad y resguardo de la

información proporcionada de los Receptores de Pago para la integración de la Base Única.
Capítulo XII

• Vigilar que se cumplan las reglas y normas establecidas en éste Capítulo y reportar las
desviaciones a la Institución correspondiente.
• Elaborar y entregar reportes a sus Adquirentes mensualmente y reportes Globales de

Información referente a la información contenida en la Base Única para estadísticos y/o a
petición de alguna autoridad o instancia legal.
• Asignar la clave de intercambio de crédito y débito con base en las políticas establecidas en
la tabla autorizada por Banco de México publicada en el Anexo 51.
o Todos los movimientos enviados por las Instituciones deben responderse el mismo
día de su recepción, a excepción de los movimientos que generen errores en el
proceso de validación o requieran validación de soporte documental.
• Los movimientos que requieran alguna validación manual, enviados después de las 17:00
horas, serán atendidos al día hábil siguiente.
• Asegurar la correcta calificación a los Receptores de Pago en los procesos de asignación

de clave de intercambio crédito y débito con base en las reglas establecidas en el numeral
3 (Asignación de Claves de Intercambio) de este Capítulo.
• Solo en caso de presentarse casos que no cumplan los requisitos para su correcto registro
o calificación debe solicitar a las Instituciones participantes la documentación necesaria que
soporte o justifique el movimiento solicitado.
• Realizar las confrontas de información entre la Base Única y los sistemas centrales de las
Instituciones participantes, de acuerdo a los establecido en el numeral 9 (Confronta) de éste
Capítulo.
1.4 ACCESOS A BASE ÚNICA
• Los Adquirentes o las Cámaras de Compensación en su papel de empresa especializada en

representación de sus Adquirentes.
• Los Emisores pueden tener acceso de consulta para obtener los datos de los comercios para
atender sus aclaraciones y las áreas de Prevención de Fraudes podrán tener acceso de
consulta con un usuario solicitado a la Cámara de Compensación en su papel de empresa
especializada, solamente a datos especificados de acuerdo a su perfil autorizado por su
Institución.
1.5 CONDICIONES Y LIMITACIONES
• Para los plazos expresados en días naturales, se considera su vencimiento al siguiente día
hábil, en caso de que dicho vencimiento se presente en un día inhábil.
Capítulo XII

2.- Proceso operativo
El siguiente diagrama describe el proceso operativo y la interacción de los participantes con
la información de afiliaciones.
2.1 ENVÍO DE MOVIMIENTOS A LA BASE ÚNICA
Las Instituciones Adquirentes pueden enviar sus movimientos a la Base Única:
• Por captura directa. El usuario debe capturar en línea en la Base Única los
movimientos altas, bajas y cambios.
• Por archivo TXT, el cual no contiene encabezado ni cifras control y debe cumplir
con el numeral 4.2.1 (Descripción y validación de los campos) de éste Capítulo.
Capítulo XII

3.- Asignación de claves de intercambio
3.1 CLAVE DE INTERCAMBIO DE CRÉDITO Y DÉBITO POR TASA
3.1.1 FAMILIAS
• A cada Receptor de Pagos individual o agrupado, se le asigna la clave de intercambio de

crédito y débito que corresponda a su familia de acuerdo al Anexo 51. La familia se determina
con base en el giro comercial preponderante del Receptor de Pagos de acuerdo al Anexo
53. Aplican las excepciones consideradas en las reglas siguientes:
3.1.2 CENTROS DE CONSUMO
• Se consideran Centros de Consumo a los Receptores de Pagos que cumplen con las
siguientes condiciones:
o Ubicados en el mismo predio del Receptor de Pagos principal
o Mismo dueño, accionista o franquicia del Receptor de Pagos principal.
• Para centros de consumo de Hoteles, Escuelas o Universidades, se asigna la clave de

intercambio correspondiente al giro comercial del Receptor de Pagos principal.
• Los centros de consumo deben cumplir con el criterio de agrupamiento definido en el

numeral 5 (Agrupamiento de Receptores de Pago) de éste Capítulo.
3.1.3 HOSPITALES Y CLINICAS DE GOBIERNO
• Aplica para los Receptores de Pagos con giro de clínicas y hospitales (8062), que
pertenezcan a gobierno, es decir públicos y se les otorga la clave de intercambio 41,
correspondiente a Gobierno. Para lo cual el Adquirente debe enviar copia del decreto de
creación vigente publicado en el Diario Oficial de la Federación o sus equivalentes para los
ámbitos estatal y municipal.
• La Institución debe enviar al Administrador de la Base Única la solicitud de inclusión de un

nuevo hospital o clínica de gobierno, por correo electrónico un día hábil antes de enviar sus
movimientos.
• El Administrador de la Base Única puede solicitar al Adquirente como documento soporte,

para comprobar que se trata de una clínica u hospital de gobierno, la copia del decreto de
creación vigente publicado en el Diario Oficial de la Federación o sus equivalentes para los
ámbitos estatal y municipal.
• El Administrador de la Base Única debe controlar en la Base Única las razones sociales
permitidas como hospitales de gobierno y actualizar este control de acuerdo a las nuevas
solicitudes
Capítulo XII

• Los hospitales del sector privado o aquellos que no hayan sido aceptados como sector
Gobierno continúan utilizando el giro 8062, con la clave de intercambio 72 que corresponde
a su familia.
• Cuando una Institución solicite que un hospital de gobierno se desclasifique como tal para
obtener clave de hospital privado, se puede aceptar, siempre y cuando sea el único
Adquirente del Receptor de Pagos. Para Receptores de Pagos compartidos el Administrador
de la Base Única notificará a los otros Adquirentes la solicitud, los cuales contarán con 5
días hábiles para enviar su Vo.Bo. El Administrador de la Base Única debe hacer un
recordatorio vía e-mail y vía telefónica a las Instituciones involucradas. En caso de no
recibirse una respuesta a la solicitud, la Institución que envío el documento puede solicitar
una solución de controversia con los otros Adquirentes involucrados.
3.1.4 TIENDAS DE CONVENIENCIA
Aplica para los Receptores de Pagos con giro 5499
DESCRIPCIÓN
MCC DESCRIPCIÓN LARGA
CORTA
5499 TIENDAS DE Unidades comerciales a detalle, tipo minisúper dedicadas

CONVENIENCIA, a la venta de productos para consumo inmediato, venden
MINISUPER principalmente alimentos y bebidas; el surtido y diversidad
de la mercancía es limitada. Pueden estar abiertas las 24
horas, por ejemplo: oxxo. 7 eleven, kiosco, extra, etc.
• Solo se puede asignar el giro 5499 a los Receptores de Pagos que por sus características
sean considerados tiendas de conveniencia bajo la definición anterior y debe enviar el acta
constitutiva comprobando la actividad del Receptor de Pagos.
3.1.5 BENEFICENCIAS
1. Solo se consideran dentro de la familia de beneficencias los Receptores de

Pagos que se ubiquen en alguno de los siguientes supuestos:
a. Personas morales con fines no lucrativos que (i) se ubiquen en el supuesto

a que se refiere la fracción VI del artículo 79 de la Ley del Impuesto sobre la
Renta; (ii) hayan obtenido del SAT autorización para recibir donativos
deducibles a través del oficio-constancia correspondiente; y (iii) su
denominación o razón social esté incluida en el apartado A “Organizaciones
Civiles y Fideicomisos Asistenciales” del Directorio de Donatarias
Autorizadas publicado en el Diario Oficial de la Federación y en el portal de
Internet del SAT.
b. Las personas morales a que se refiere el inciso anterior, aun cuando su

denominación o razón social no haya sido incluida en el apartado A
“Organizaciones Civiles y Fideicomisos Asistenciales” del Directorio de
Capítulo XII

Donatarias Autorizadas publicado en el Diario Oficial de la Federación y en
el portal de Internet del SAT, siempre y cuando:
o Se ubiquen en el supuesto a que se refiere la fracción VI del

artículo 79 de la Ley del Impuesto sobre la Renta
o Hayan obtenido del SAT autorización para recibir donativos

deducibles a través del oficio-constancia correspondiente,
mismo que debe enviarse al Administrador de la Base Única,
siempre y cuando su objeto social y/o fin o actividad
preponderante es de beneficencia.
c. Aquellas entidades gubernamentales dedicadas a actividades de

beneficencia o asistencia social no remuneradas, que emitan comprobantes
deducibles de impuestos y que como tales no se encuentren en el Directorio
de Donatarias Autorizadas publicado en el Diario Oficial de la Federación y
en el portal de Internet del SAT. Debe enviarse al Administrador de la Base
Única el alta ante hacienda, decreto de creación y/o documento oficial que
acredite el tipo de actividad y la dependencia de gobierno de que se trate.
d. Otras personas morales con fines no lucrativos que hayan obtenido del SAT
autorización para recibir donativos deducibles a través del oficio-constancia
correspondiente y cuya denominación o razón social esté incluida en el
Directorio de Donatarias Autorizadas publicado en el Diario Oficial de la
Federación y en el portal de Internet del SAT, en apartados diversos al
señalado en el inciso a. anterior, siempre y cuando comprueben que su
objeto social y/o fin o actividad preponderante es de beneficencia. Debe
enviarse al Administrador de la Base Única:
o Documento de alta ante hacienda.
o Acta constitutiva o documento oficial que compruebe el tipo de

actividad.
o El oficio-constancia emitido por el SAT, mediante el cual

autoriza a la persona moral de que se trate para recibir
donativos deducibles.
2. Cualquier evento de beneficencia realizado por un Receptor de Pagos no

incluido en inciso anterior, debe contar con un oficio constancia emitido por
SHCP.
3. Los Receptores de Pagos a que se refiere el numeral 1 anterior, que estén

afiliados como Beneficencias y que además de recibir donativos, requieran
aceptar Tarjetas para el cobro de productos y/o servicios, como una actividad
lucrativa, deben tramitar otra afiliación con el giro correspondiente a su
actividad. El Administrador de la Base Única debe asignar la Clave de
intercambio que le corresponda a dicho giro. Es responsabilidad de cada
Institución informar al Receptor de Pagos que no puede utilizar la afiliación de
Beneficencia para el cobro de productos y/o servicios que no sean donativos.
Capítulo XII

El Administrador de la Base Única debe de validar de forma mensual que las
afiliaciones de los Receptores de Pago registradas como 8398 (Beneficencias)
se encuentren vigentes de acuerdo a lo publicado en el portal del SAT de los
siguientes directorios:
o Donatarias Autorizadas.
o Donatarias Revocadas.
o Donatarias No Renovadas; que son publicados en el Diario

Oficial de la Federación y en el portal de Internet del SAT, a fin
de constatar que los Receptores de Pagos afiliados como
Beneficencias a que se refieren los incisos a., b. y d. del numeral
1, siguen cumpliendo con los requisitos y obligaciones para ser
considerados como tales y por lo tanto han sido o continúan
registrados en dicho directorio o bien que la correspondiente
autorización está pendiente de ratificación o ha sido revocada,
según sea el caso. El Administrador de la Base Única debe
informar a cada Institución el resultado de la revisión mensual
prevista en este numeral, mediante reporte que incluya las
afiliaciones que ya no cumplan con los requisitos previstos en el
presente apartado como resultado de cada revisión.
4. Una vez que las Instituciones reciban el reporte a que se refiere el numeral inmediato anterior,
deben solicitar a los Receptores de Pagos cuya autorización haya sido revocada o esté pendiente
de ratificación, tramiten nuevamente ante el SAT la autorización para recibir donativos y exhiban el
oficio constancia correspondiente que debe enviarse al Administrador de la Base Única dentro de
un plazo no mayor a 60 días naturales, de lo contrario, deben reclasificar su giro de 8398
(Beneficencias) a 8641 (Asociaciones Civiles), con su consecuente cambio de clave de
intercambio.
3.1.6 PERSONAS FÍSICAS
Los Receptores de Pagos que no demuestren su actividad económica preponderante se afiliarán

con la tasa de intercambio más alta de acuerdo al Anexo 51.
Capítulo XII

4.- Validación de Movimientos
4.1 VALIDACIÓN DE MOVIMIENTOS DE RECEPTORES DE PAGOS
Validaciones que realiza el Administrador de la Base Única de los movimientos enviados por las
Instituciones.
4.2 REGLAS DE CONTENIDO
Son las características que debe tener la información del lay out establecido.
Caracteres permitidos:
• A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, 1, 2, 3,
4, 5, 6, 7, 8, 9, 0, & y el espacio en blanco
• En el caso del alfabeto deben ser únicamente mayúsculas.
• No se permiten acentos
• Sólo se permite un espacio entre palabras.
• Sin espacios al inicio
• No es aceptada la Ñ
• Las abreviaturas no llevan punto
• Se acepta “*”(asterisco) solo para Sub-afiliados
• Se acepta “.” Solo en domicilio.
4.2.1 DESCRIPCIÓN Y VALIDACIONES DE LOS CAMPOS
Datos a intercambiar por tipo

de movimiento
Envía
A A B C M R R
Secuencia Nombre del Campo Tipo y Longitud Adquiren Descripción
C L A A O A E
te
• Información de control que genera el
1 FolioAdministrador entero(10) NO D D D D D D D
Administrador.
• Identificador informativo del movimiento como
2 FolioInstitucion entero(10) *SI O O O O O O O
control entre la Institución y el Administrador.
3 LoteEnvio alfanumérico(16) NO D D D D D D D
Administrador.
4 Usuario alfanumérico(3) NO D D D D D D D
Administrador.
• Debe corresponder a la fecha en que la
Institución envía el movimiento al Administrador.
• Formato de la fecha aaaa-mm-dd.
5 FechaEnvio fecha(10) *SI I I I I I I I
• El Administrador, para un mayor control, debe
guardar la hora en el registro de la solicitud con el
formato hh: mm: ss.
Capítulo XII

• Debe corresponder a la fecha en la que el
Administrador regresa el movimiento de la
6 FechaValidacion fecha(10) NO D D D D D D D
solicitud a la Institución.
• Formato de la fecha aaaa-mm-dd.
• Debe corresponder a la Institución que envía el
7 Institucion alfanumérico(3) *SI movimiento y debe apegarse al catálogo de I I I I I I I
Instituciones.
8 Movimiento alfanumérico(2) *SI • Claves permitidas: AC, AL, BA, CA, MO RA, RE I I I I I I I
• Número entero que asigna el sistema

9 Afiliacion entero(7) *SI I I I I I I I
automáticamente.
• Sólo se utiliza para el movimiento de
recontratación y debe hacer referencia al
10 AfiliacionAnterior entero(7) *SI I
Receptor de Pagos que se cancela para aceptar la
nueva afiliación
• Nombre comercial conocido, debe ser claro,
con la finalidad de que puedan ser identificados
fácilmente por los Tarjetahabientes en sus
estados de cuenta y así, evitar aclaraciones por
esta causa.
• Tratándose de nombres de personas físicas:
o Se debe anteponer un indicativo que permita
identificar el giro del Receptor de Pagos, ejemplo:
11 NombreComercial alfanumérico(22) *SI I I I I I I I
Giro 8011 siempre se debe anteponer al nombre
de la persona física.
o No se permite "CONSULTORIO MEDICO" para
el giro 8011.
• Cuando se usen abreviaturas debe utilizarse el
catálogo de abreviaturas indicado en el Anexo 52,
si la palabra existe en dicho catálogo
• Se acepta “*”(asterisco) solo para Subafiliados
• Valores permitidos se encuentran indicados en
el catálogo de Giros.
12 Giro entero(4) *SI O I O O I I I
• Apegado a la actividad preponderante del
Receptor de Pagos de acuerdo al Anexo 52.
• Parte inicial del RFC del Receptor de Pagos.
• El valor para personas físicas es de 4 posiciones.
13 RfcInicial alfanumérico(4) *SI • El valor para las personas morales también es O I O O I I I
de 4 posiciones, solo que la cuarta posición es un
espacio en blanco.
14 RfcFecha alfanumérico(6) *SI • Formato de la fecha aammdd O I O O I I I
15 RfcHomoclave alfanumérico(3) *SI • El valor enviado debe ser diferente de espacios. O I O O I I I
• Personas físicas: Apellido paterno, materno y
nombre(s).
• Personas morales con denominación social
válida de acuerdo al Código Mercantil, ejemplos:
SA, SACV, SA CV, SCV, CASA DE BOLSA, SRL MI,
SRL ART, SPR, AR, SRI, SRL, CV, SCA, SC, AC, SCS,
16 RazonSocial alfanumérico(30) *SI SCSA, SNC, IAP, SCP. O I O O I I I
• Para los fideicomisos del sector gobierno que
así lo requieran, se permite que la razón social
sea un descriptivo del fideicomiso y que el RFC
corresponda a la entidad gubernamental que lo
sustenta, aunque no corresponda el RFC con la
razón social
• Criterio 17, envío de documentación soporte
17 Accionistas alfanumérico(255) SI solicitado por el despacho. O I O O I I I
• Solo aplica para personas morales.
• Debe corresponder a la ubicación física del
Receptor de Pagos
• Debe contener la calle, número, interior y/o
similares
• En caso de no contar con número se incluyen
los caracteres "SN" Ej. : AV CAMARON SABALO
SN
18 DomicilioCompleto alfanumérico(30) *SI • Entre el nombre de la calle y el número deben O I O O I I I
incluirse las siglas "NO" Ej. : AV REVOLUCION NO
100
• En el caso de carreteras se pueden utilizar el
punto para denotar el KM ejemplo: KM 18.5
• Se aplican las abreviaturas de acuerdo al
catálogo de abreviaturas para domicilio solo
cuando sea necesario.
Capítulo XII

• Debe corresponde a la calle de la ubicación
19 Calle alfanumérico(30) *SI O I O O I I I
física del Receptor de Pagos.
• Debe corresponde al número exterior de la calle
20 NumeroExterior alfanumérico(15) *SI O I O O I I I
de la ubicación física del Receptor de Pagos.
• Debe corresponde al número interior, cuando
21 NumeroInterior alfanumérico(15) *SI aplique, del número exterior de la calle de la O I O O I I I
ubicación física del Receptor de Pagos.
• Apegado al comprobante de domicilio indicado
en éste Capítulo XII del CID.
22 Colonia alfanumérico(30) *SI • No se incluye el prefijo COL. O I O O I I I
• Se abrevia según el catálogo de abreviaturas
para domicilio del Anexo 52.
• Se conforma por el nombre de la ciudad o
municipio y la abreviatura del estado.
• De acuerdo al catálogo de poblaciones indicado
en el Anexo 52.
23 Poblacion alfanumérico(30) *SI • Contiene la ciudad o municipio y la abreviatura O I O O I I I
del estado.
• El Administrador de la Base Única debe sustituir
la población cuando esta corresponde al catálogo
de poblaciones, pero no es idéntica.
• Debe corresponder a la población del Receptor
de Pagos
• Debe apegarse a documento de validación
como soporte indicado en éste Capítulo XII del
CID.
24 CodigoPostal entero(5) *SI O I O O I I I
• Si el código postal no existe en el catálogo de
SEPOMEX, pero el Receptor de Pagos lo soporta
con alguno de los documentos indicados en éste
Capítulo XII del CID, puede aceptarse el
movimiento.
25 CodigoPostalAnterior entero(5) NO D D D D D D D
Administrador.
• 10 dígitos para el teléfono incluyendo clave lada
regional
• Preferentemente línea fija del lugar donde
26 Telefono alfanumérico(15) *SI opera el Receptor de Pagos. O I O O I I I
• Si el receptor no cuenta con teléfono de línea
fija, se permite número celular de su
representante.
27 TelefonoSecundario alfanumérico(15) Opcional • Dato Opcional. O O O O O O O
28 CorreoElectronico alfanumérico(255) Opcional • Dato Opcional. O O O O O O O
• El valor corresponde a una persona física con el
29 RepresentanteLegal alfanumérico(30) *SI siguiente orden Nombre(s), Apellido Paterno y O I O O I I I
Apellido Materno.
• El Administrador actualiza de acuerdo a los
30 CategoriaCredito entero(2) NO D D D D D D D
criterios establecidos en éste Capítulo.
AsignacionCategoriaC • El Administrador actualiza de acuerdo a los
31 alfanumérico(2) NO D D D D D D D
redito criterios establecidos en éste Capítulo.
32 CategoriaDebito entero(2) NO D D D D D D D
AsignacionCategoriaD • El Administrador actualiza de acuerdo a los
33 alfanumérico(2) NO D D D D D D D
ebito criterios establecidos en éste Capítulo.
34 Grupo entero(6) SI O I O O I I I
35 Cadena entero(4) SI O I O O I I I
36 CriterioAgrupamiento entero(1) SI O I O O I I I
• De acuerdo al criterio establecido en el
37 ClaveRecontratacion entero(1) *SI apartado de descripción movimiento de I
recontratación de éste Capítulo XII del CID.
• De acuerdo al criterio establecido en el
apartado de descripción movimiento de bloqueo
38 ClaveBloqueo entero(2) *SI I
por cancelación administrativa y de fraudes de
éste Capítulo XII del CID.
• El Administrador actualiza la operativa tomando
39 Operativa alfanumérico(6) Opcional en cuenta la información que envía las Cámaras O O O O O O O
de Compensación para la aplicación PCI.
ObservacionesInstituc
40 alfanumérico(150) Opcional O O O O O O O
ion • Dato Opcional.
ObservacionesAdmini
41 strador de la Base alfanumérico(150) NO • El Administrador actualiza de acuerdo a los D D D D D D D
Única criterios establecidos en éste Capítulo.
Capítulo XII

42 Procede entero(1) NO D D D D D D D
• Claves permitidas se encuentran indicadas en
43 Adquirente entero(3) SI I I I I I I I
los catálogos de Adquirentes del Anexo 52.
• Debe corresponde a la ubicación física del
44 Latitud alfanumérico(15) *SI O O O O O O O
Receptor de Pagos.
• Debe corresponde a la ubicación física del
45 Longitud alfanumérico(15) *SI O O O O O O O
Receptor de Pagos.
• De acuerdo a las disposiciones del RENAPO.
• Solo para personas físicas.
46 curp Alfanumérico ( 18) Opcional O O O O O O O
• Se puede validar mediante los WebService que
proporciona el RENAPO.
Dónde:
I Debe ser enviado por la Instituciones
D Debe ser enviado por el Administrador de la Base Única
O Opcional para la Institución
No debe ser enviado
4.3 ACTUALIZACIÓN DE OPERATIVAS
En caso de que el Adquirente no envíe en sus movimientos la operativa del medio de

acceso, el Administrador actualizará el dato de acuerdo al archivo de transacciones que
recibe la empresa especializada mensualmente.
Capítulo XII

4.4 DESCRIPCIÓN DE LAS CLAVES POR TIPO DE MOVIMIENTO
Los tipos de movimientos son:
Clave Nombre Descripción
AC Actualización de información por el Movimiento solo para administrador para

administrador. avisos, actualización de claves de
intercambio, encadenamientos.
AL Alta Receptor de Pagos nuevo.
BA Baja Eliminación del registro, se utiliza

principalmente en la depuración.
CA Cancelación por bloqueo Cambio de estatus a bloqueado por

clave administrativa o de Prevención de
Fraudes.
MO Modificación Actualización de datos por el Adquirente.
RA Reactivación Cambio estado de cancelado/ bloqueado

a activo.
RE Recontratación Bloqueo de una afiliación y asignación de

un nuevo número de afiliación cuando el
Receptor de Pagos cambia de razón
social.
Capítulo XII

4.5 DESCRIPCIÓN DE LOS TIPOS DE MOVIMIENTOS
4.5.1 (AC) ACTUALIZACIÓN DE INFORMACIÓN POR EL ADMINISTRADOR
Actualización solamente de los campos grupo, cadena y claves de intercambio, permite al

Administrador de la Base Única y a los Adquirentes realizar ajustes en los agrupamientos.
1. Que el número de afiliación exista y corresponda al Receptor de Pagos.
2. Sólo se permite modificar los campos grupo, cadena y/o clave de intercambio.
3. No implica cambio de Adquirente.
4. Si el Administrador de la Base Única identifica a un Receptor de Pagos (llave,

RFC) la cual no se encuentra agrupada, debe agruparla.
5. No implica reactivación del Receptor de Pagos.
6. El cambio de agrupamiento debe apegarse a lo establecido en el numeral 5.2

(Integración a un agrupamiento existente) de éste Capítulo.
7. Si implica un desagrupamiento, la Institución debe mencionar en sus

observaciones la leyenda “SE DESAGRUPA”.
8. Cuando se requieran agrupar los Receptores de Pagos que se encuentren en

proceso PCI, el Administrador enviará un aviso al Adquirente, si este no lo
atiende en 5 días hábiles el Administrador de la Base Única podrá aplicar los
agrupamientos, generando por cada agrupamiento un movimiento AC para que
quede en el histórico de la Base Única.
4.5.2 (AL) ALTA
Para la Integración o incorporación de nuevos Receptores de Pagos a la Base Única se debe

validar que:
1. Que el número de afiliación no exista en Base Única en Receptores de Pago

cualquiera que sea su estado.
2. Que el Receptor de Pagos no tenga un número de afiliación previamente en la

Base Única, salvo las excepciones descritas en el numeral 4.9 Receptores de
Pagos con más de una afiliación.
3. La integración de un Receptor de Pagos a un agrupamiento debe apegarse a

los criterios y normas de agrupamiento descritas en el numeral 5.3.
4. Los números de afiliación dados de baja o depurados se pueden reutilizar,

siempre y cuando los datos correspondan al mismo Receptor de Pagos que se
dio de baja.
Capítulo XII

5. Que el Receptor de Pagos no tenga relación o tenga antecedentes de fraude,
para ello el Administrador de la Base Única deberá comparar los datos generales
del Receptor de Pagos en la combinación de algunos datos (Nombre comercial,
RFC, razón social, representante Legal, ubicación y/o teléfono) contra los datos
de Receptores de Pagos bloqueados. La Institución puede mencionar en sus
observaciones lo conducente. El Administrador de la Base Única puede aceptar
o en su caso rechazar el movimiento como medida de protección, indicando esta
causa en sus observaciones. En caso de rechazo por esta causa, el área de
Prevención de Fraudes de la Institución, quién tendrá toda la responsabilidad,
debe evaluar y en su caso dar su visto bueno mediante correo electrónico por
el personal facultado previsto en el directorio señalado en el numeral 7 del
Capítulo VI (Políticas y procedimientos de seguridad con los Receptores de
Pagos) dirigido al Administrador de la Base Única para la aceptación del
movimiento.
4.5.3 (BA) BAJA.
Eliminación del registro de un Receptor de Pagos en la Base Única e inclusión en un histórico de

bajas. Se realiza principalmente en el proceso de depuración descrito en el numeral 8 (Cancelación
de inactivos y Depuración de cancelados) de éste Capítulo, pero también puede enviarlo alguna
Institución cuando se haya enviado un movimiento de manera incorrecta y requiere eliminarlo para
no afectar su operación.
1. No pueden darse de baja los Receptores de Pagos bloqueados por clave de

Fraude de acuerdo al Anexo 52.
2. Pueden darse de baja Receptores de Pagos que se hayan dado de alta de

manera incorrecta y cuando el proceso de depuración se ejecuta, se envía en la
base de históricos.
3. La baja de un Receptor de Pagos debe ser enviada por el Adquirente único del
Receptor de Pagos (no aplica para Receptores de Pagos multiadquiridos).
4. Los números de afiliación dados de baja o depurados se pueden reutilizar,

siempre y cuando los datos correspondan al mismo Receptor de Pagos que se
dio de baja.
4.5.4 (CA) BLOQUEO POR CANCELACIÓN
Cambio del estado de un Receptor de Pagos a bloqueado con clave administrativa o con clave de
Prevención de Fraudes
Bloqueo por Cancelación de Prevención de Fraudes:
1. Se debe utilizar una clave de bloqueo de acuerdo al catálogo de claves de

bloqueo, Anexo 52, rango de Prevención de Fraudes.
Capítulo XII

2. Que el número de afiliación exista en Base Única.
3. Las Instituciones pueden enviar todos los datos del Receptor de Pagos o
solamente la afiliación y la clave de bloqueo, en cualquiera de los casos el
Administrador de la Base Única debe actualizar en el movimiento los datos
generales del Receptor de Pagos que se tengan en la Base Única, respetando
la afiliación y clave de bloqueo enviadas por la Institución. Lo anterior para evitar
que en el movimiento de bloqueo se utilicen datos diferentes a los existentes en
la Base Única.
4. Cada Institución debe enviar los bloqueos de sus Receptores de Pago a través
de su área de Prevención de Fraudes. Los datos deben corresponder al
Receptor de Pagos que se va a bloquear.
5. Los bloqueos por las áreas de Prevención de Fraudes son el único movimiento
que puede ser actualizado en el sistema de la Institución antes de ser enviado a
la Base Única.
6. Solo la Institución Adquirente puede enviar el bloqueo de un Receptor de Pagos

con clave de Prevención de Fraudes, de acuerdo al catálogo de claves de
bloqueo por cancelación, excepto la clave 38 (No cumple la normativa PCI) la
cual puede ser enviada solo por el Administrador de la Base Única.
El Administrador de PCI tiene la facultad de instruir al Administrador de la Base

Única el bloqueo de un Receptor de Pagos con la clave 38 por el incumplimiento
de certificación de PCI.
7. La clave de bloqueo debe corresponder con la situación real del Receptor de

Pagos, si se presenta una causa que no cuente con una clave específica, se
debe utilizar la clave 5 “Receptor de Pagos en investigación”, de acuerdo al
catálogo de claves de bloqueo descrito en el Anexo 52.
Los bloqueos con clave 5 (Receptor de Pagos en investigación) tienen una

vigencia de 10 días naturales, en caso de que el Adquirente no realice el cambio
de clave, el Administrador de la Base Única debe enviar el cambio de clave
mediante un movimiento de Bloqueo Administrativo, con la clave 55 a nombre
del Adquirente que había bloqueado con clave 5. Adicionalmente el
Administrador de la Base Única debe insertar como aviso un movimiento AC,
con la observación “VENCIÓ PLAZO PARA CAMBIAR CLAVE DE BLOQUEO
5,”.
8. El Adquirente puede modificar el motivo del bloqueo de un Receptor de Pagos

que ya se encuentre suspendido o bloqueado cuando cambie:
• Las claves de Prevención de Fraudes entre sí, solo si se trata del mismo
Adquirente que bloqueó al Receptor de Pagos
• Las claves administrativas entre sí
• De una clave administrativa a una de Prevención de Fraudes
9. Para los casos de No Devolución de TPV
Capítulo XII

• Cuando Adquirente manda un bloqueo con clave 60 (No devolución de
TPV) hasta los 75 días el Adquirente puede realizar el cambio a la clave
39 (No devolución de TPV confirmada).
• En caso de que no se confirme el bloqueo, se elimina el monitoreo y el

Receptor de Pagos permanece en bloqueo administrativo con clave 60,
con lo cual puede ser reactivado por cualquier Adquirente.
• Los Adquirentes pueden enviar como documentos soporte al

Administrador de la Base Única:
o El acta administrativa por No Recuperación de TPV. Donde

indique fecha, número de afiliación, nombre comercial, domicilio,
teléfono, descripción y resultado de la gestión.
o El soporte administrativo de retiro de TPV. Donde indique fecha,

número de afiliación, nombre comercial, domicilio, teléfono,
marca, modelo y número de serie de la TPV.
o Otros documentos que comprueben gestiones de recuperación

de la TPV.
Los movimientos de bloqueo intercambiados (los Adquirentes notifican al

Administrador de la base única los Receptores de Pago que fueron bloqueados por
Prevención de Fraudes) y el control de bloqueos de la Base Única tienen validez
para contracargos y solución de controversias.
En caso de robo o extravío de equipo, no es necesario bloquear la afiliación, lo cual

se realizaba con la clave 7, en su lugar, el Adquirente es responsable de bloquear
su propio equipo o TPV.
Para receptores de pago multiadquiridos, se tendrá el siguiente tratamiento:
1.
Si la clave es 30, el movimiento deberá ser aceptado por el
administrador de la base única y de manera inmediata, se comunicará
vía telefónica con los adquirentes participantes para informarles del
bloqueo del receptor de pagos.
• Si los adquirentes participantes le solicitan al adquirente que solicitó el bloqueo
del receptor de pagos documentación soporte, éste último debe de dar
respuesta en un plazo no mayor a 24 horas, en caso de no atender, los
adquirentes participantes pueden solicitar el desbloqueo.
2. Para cualquier otra clave de bloqueo, el administrador de la base única, rechazará el
movimiento y le solicitará a los adquirentes participantes su confirmación de bloqueo en
un plazo no mayor de 48 horas.
• Si no se confirma en el plazo indicado, el receptor de pagos se bloquea.
• Si un adquirente participante confirma que no procede el bloqueo, el adquirente
que envió el movimiento decidirá si envía un movimiento de solo cancelación
administrativa.
Capítulo XII

3. El administrador de la base única entregará los movimientos de bloqueos de receptores
de pagos multiadquiridos del día.
Bloqueo por cancelación administrativa:
1. Se debe utilizar la clave de bloqueo de acuerdo al catálogo de claves de bloqueo

por cancelación, rango administrativas.
2. Que el número de afiliación exista en la Base Única.
3. Las Instituciones pueden enviar todos los datos del Receptor de Pagos o
solamente la afiliación y la clave de cancelación, en cualquiera de los casos el
Administrador de la Base Única debe actualizar en el movimiento los datos
generales del Receptor de Pagos que se tengan en la Base Única, respetando
la afiliación y clave de cancelación enviadas por la Institución. Lo anterior para
evitar que en el movimiento de cancelación se utilicen datos diferentes a los
existentes en la Base Única.
4. Que los datos correspondan al Receptor de Pagos que se va a bloquear.
5. Si una Institución envía bloqueo por clave administrativa (50 a la 60) y el

Receptor de Pagos es multiadquirido, el Administrador de la Base Única debe
regresar el movimiento con clave 58, sin modificar el status del Receptor de
Pagos, sólo se desliga al Adquirente que realizó la solicitud. El Administrador de
la Base Única debe indicar en las observaciones del movimiento con cuál(es)
Adquirentes quedan operando con el Receptor de Pagos.
6. Si una Institución envía un bloqueo por clave administrativa (50 a la 60) y no es

multiadquirido, el Administrador de la Base Única hace efectiva la cancelación
de esa afiliación. Si es multiadquirido, el Administrador solo desliga al Adquirente
que la solicitó
7. Para los bloqueos con clave 60 (No devolvió TPV al Adquirente)
• El Adquirente cuenta con un plazo de 60 días para cambiar de la clave

60 a la clave 39 donde confirma que la terminal no fue devuelta.
Si no es enviada la clave 39 por el Adquirente, la afiliación conserva la clave 60, con lo cual
puede ser reactivado por cualquier Adquirente y, además, es considerada para el proceso
de depuración. Si existe otro Adquirente:
• En el reporte semanal del monitoreo activo que el Administrador de la

Base Única entrega, debe aparecer el aviso del punto anterior durante
los 60 días de plazo, para que otros Adquirentes del Receptor de Pagos
puedan gestionar la devolución o acuerdo con el Adquirente que reclama
la devolución de la TPV.
• Solo si persiste la no devolución de la TPV o la gestión no es exitosa,

después de los 60 días, mencionados en el punto anterior, el Adquirente
afectado cuenta con 15 días naturales adicionales, para confirmar el
Capítulo XII

bloqueo con clave 39 (No devolución de TPV confirmada) y solo el
Adquirente que bloquea podrá reactivarla.
• En caso de que no se confirme el bloqueo clave 39 al término de los 15

días naturales del punto anterior, se elimina el monitoreo y el Receptor
de Pagos permanece bloqueado con clave 60, con lo cual puede ser
reactivado por cualquier Adquirente.
8. Una Institución puede enviar un movimiento de bloqueo por clave 51, cuando
encuentre a un Receptor de Pagos con los mismos datos que otro(s) Receptor
de Pagos(s) activo(s) en la base, mandando una modificación del Receptor de
Pagos que se queda como activo, indicando en el campo de afiliación anterior
el número con el cual estaba duplicado.
9. El Adquirente puede enviar el bloqueo por cancelación administrativa de un

Receptor de Pagos previamente bloqueado por cancelación administrativa, se
permite cambiar solamente a otra clave administrativa.
10. Con excepción de las cancelaciones por clave 58 y 59 cualquier bloqueo debe
surtir efecto en la Base Única inmediatamente.
4.5.5 (MO) MODIFICACIÓN
Actualización de los datos de un Receptor de Pagos activo, este movimiento es enviado por la
Institución Adquirente o alguno de los Adquirentes en el caso de Receptores de Pagos
Multiadquiridos.
1. Que el número de afiliación exista, se encuentre activo y corresponda al

Receptor de Pagos.
2. La institución que envía el movimiento es Adquirente del Receptor de Pagos.
3. Se pueden realizar modificaciones a los datos generales del Receptor de Pagos:

nombre comercial, giro, grupo, cadena, domicilio, colonia, población, teléfono,
representante legal.
4. En caso de que la afiliación se encuentre suspendida o bloqueada, la Institución

debe enviar previamente el movimiento de reactivación (RA) según corresponda
al estado del Receptor de Pagos.
5. El Adquirente puede realizar correcciones parciales, por errores de captura a la

denominación social, al RFC y Razón Social, siempre y cuando no implique un
cambio de contribuyente fiscal.
6. Cambio de razón social con la misma afiliación:
• Se permite conservar su mismo número de afiliación si el Receptor de

Pagos lo requiere.
Capítulo XII

• El cambio no afecte el giro del Receptor de Pagos.
• Cuando existe un cambio de razón social, el Adquirente puede mandar

movimiento por movimiento incorporando sus modificaciones para que
quede en el registro histórico.
• Puede generar archivo con la siguiente información, para que el

Administrador lo aplique por proceso. La institución solicitante debe
enviar al Administrador de la Base Única un e-mail explicando su
solicitud e incluyendo la siguiente información:
o RFC y razón social actual
o RFC y razón social nueva
o Números de afiliación afectados

los criterios y normas de agrupamiento, establecidos en el punto 5.
Agrupamiento de Receptores de Pago de éste Capítulo.
8. Todos los cambios de las afiliaciones se deben de registrar en el histórico de

movimientos.
9. Cuando implique un desagrupamiento, la Institución debe mencionar en sus

10. Cuando el Receptor de Pagos tenga otros Adquirentes, el Administrador de la

Base Única debe enviar un aviso de modificación al resto de los Adquirentes
11. En caso de solo modificar el giro pero no la razón social y el Receptor de Pagos
es multiadquirido , se debe cumplir con lo siguiente:
• La Institución debe enviar al Administrador de la Base Única documento

soporte que respalde el giro asignado.
• El Administrador de la Base Única debe verificar que el giro asignado

corresponda con los datos del Receptor de Pagos y el documento
soporte.
• Si procede el cambio de giro el Administrador de la Base Única acepta

el movimiento y genera enseguida un movimiento adicional de aviso AC
con las observaciones “AVISO INICIAL, CAMBIO DE GIRO RECEPTOR
DE PAGOS COMPARTIDO” con una vigencia de 30 días naturales.
• Si el cambio de giro modifica la tasa de intercambio hacia el alta, el

Administrador rechazará el movimiento.
Solo como informativo, se enviará un correo electrónico a los Adquirentes

participantes del movimiento que se rechazó.
Capítulo XII

• El aviso de cambio de giro debe aparecer en el reporte semanal de
avisos mientras se encuentre vigente.
• Al vencer la vigencia del aviso el Administrador de la Base Única debe

generar un movimiento AC con las observaciones “AVISO FINAL,
CAMBIO DE GIRO RECEPTOR DE PAGOS COMPARTIDO”.
4.5.6 (RA) REACTIVACION
Cambio de estado de un Receptor de Pagos bloqueado de inactivo a activo, cuando el Receptor

de Pagos se encuentra en bloqueo administrativo o de Prevención de Fraudes.
1. Que el número de afiliación exista en Base Única.
2. Que la afiliación corresponda al Receptor de Pagos que se quiere reactivar.
3. Que el Receptor de Pagos se encuentre bloqueado en la Base Única con clave

administrativa o de Prevención de Fraudes.

los criterios y normas de agrupamiento, establecidos en el apartado de Criterios
de Agrupamiento de éste Capítulo.
5. Cuando implica un desagrupamiento, la Institución debe mencionar en sus

6. Cuando el Receptor de Pagos se encuentre bloqueado por clave administrativa:
• El Receptor de Pagos puede ser reactivado por cualquier Institución, no

necesariamente la Institución que envió el bloqueo administrativo.
• En caso de que un Adquirente reactive a un Receptor de Pagos

cancelado por otro Adquirente con clave 60 (No devolvió TPV al
Adquirente), el Administrador de la Base Única genera un aviso de
solicitud de reactivación para eliminar la clave 60, para lo cual se debe
generar en el reporte semanal de monitoreo, el aviso de la reactivación
del Receptor de Pagos durante los 60 días de plazo, para que los otros
Adquirentes multiadquiridos realicen la gestión para el proceso de
recuperación de la TPV.
• Que el Receptor de Pagos no tenga relación o tenga antecedentes de

fraude, para ello el Administrador de la Base Única deberá comparar los
datos generales del Receptor de Pagos (Nombre comercial, RFC, razón
social, representante Legal, ubicación y/o teléfono) contra los datos de
Receptores de Pagos bloqueados. La Institución podrá mencionar en
sus observaciones lo conducente. Dependiendo la solicitud del
Adquirente de la Institución el Administrador de la Base Única podrá
aceptar o en su caso rechazar el movimiento como medida de
protección, indicando esta causa en sus observaciones. En caso de
Capítulo XII

rechazo por esta causa, el área de Prevención de Fraudes de la
Institución debe evaluar el caso y en su caso dar su visto bueno al
Administrador de la Base Única para la aceptación del movimiento. La
búsqueda descrita en este punto es una herramienta adicional que
proporciona el Administrador de la Base Única a las Instituciones, sin
que ello le represente responsabilidad sobre la afiliación de Receptores
de Pagos con antecedentes de Fraudes.
7. Cuando el Receptor de Pagos se encuentre bloqueado por clave de Prevención

de Fraudes:
• Las áreas operativas de afiliaciones de las Instituciones no deben

originar el desbloqueo, este debe contar con la autorización por su área
de Prevención de Fraudes.
• El desbloqueo de un Receptor de Pagos solo puede ser enviado por el

Adquirente que lo bloqueó.
• Las afiliaciones bloqueadas con clave 5, cuyo plazo de 10 días naturales

para cambiar de clave de bloqueo haya vencido sin que el Adquirente
no realice el cambio de clave, el Administrador de la Base Única debe
enviar el cambio de clave mediante un movimiento de Bloqueo
Administrativo (CA), con la clave de bloqueo 55 No conviene al
Adquirente a nombre del Adquirente que había bloqueado con clave 5.
Una vez que se encuentren suspendida con clave 55, podrán ser
reactivadas por cualquiera de las Instituciones, sin que le implique
responsabilidad sobre adeudos con la Institución que bloqueó
originalmente.
• La Institución debe incluir en sus observaciones “REACTIVACION CON

AUTORIZACION DE PREVENCION DE FRAUDES”. El Administrador
de la Base Única debe incluir en sus observaciones “DESBLOQUEO PF”
y actualizar en el movimiento la clave de cancelación que tenía el
Receptor de Pagos antes de la reactivación.
• Para el desbloqueo de un Receptor de Pagos compartido, si no existe

otra causa de rechazo, el Administrador de la Base Única debe aceptar
la reactivación sin que sea necesario informar a otros Adquirentes. Solo
aplica cuando el Adquirente que desbloquea es el mismo que bloqueó
el Receptor de Pagos. El desbloqueo no implica responsabilidad de la
Institución que reactiva sobre adeudos del Receptor de Pagos con otras
Instituciones, las cuales podrán bloquearlo nuevamente si así lo
consideran necesario.
8. Las reactivaciones o desbloqueos así como el control de afiliaciones bloqueadas

de la Base Única tienen validez para contracargos y solución de controversias.
Capítulo XII

4.5.7 (RE) RECONTRATACION.
Asignación de un nuevo número de afiliación a un Receptor de Pagos existente y bloqueo del

número de afiliación anterior, se utiliza cuando el Receptor de Pagos cambia de RFC o Razón
Social.
1. Que el número de afiliación anterior exista en Base Única y que no haya sido
recontratado durante los últimos 6 meses.
2. En caso de que, además del RFC y razón social, cambie la ubicación y/o el
nombre comercial, se consideran diferentes Receptores de Pagos, por lo que
no procede la recontratación. En dicho caso el Adquirente puede enviar el
bloqueo del Receptor de Pagos anterior y alta del nuevo.
3. Que el Receptor de Pagos no tenga un número de afiliación previamente en la

Base Única, salvo las excepciones descritas en el numeral 4.9 (Receptores de
Pagos con más de una afiliación).
4. La integración del Receptor de Pagos nuevo a un agrupamiento debe apegarse

a los criterios y normas de agrupamiento, establecidos en el apartado de
Criterios de Agrupamiento de éste Capítulo.
La integración del Receptor de Pagos nuevo a un agrupamiento debe apegarse a los criterios y
normas de agrupamiento.
1. El cambio de razón social debe representar un cambio de contribuyente fiscal.

Los Receptores de Pagos que cambien de razón social y por ende de R.F.C.
deben ser recontratados, con excepción de lo dispuesto en el numeral 6 del
movimiento modificación “Cambio de razón social con la misma afiliación”.
2. El Administrador de la Base Única debe agregar el movimiento de bloqueo de

la afiliación anterior, con clave 51 Opera con otro número de afiliación.
3. Que el Receptor de Pagos no tenga relación o tenga antecedentes de fraude,

para ello el Administrador de la Base Única deberá comparar los datos
generales del Receptor de Pagos (Nombre comercial, RFC, razón social,
representante Legal, ubicación y/o teléfono) contra los datos de Receptores de
Pagos bloqueados. La Institución podrá mencionar en sus observaciones lo
conducente. Dependiendo de los comentarios de la Institución, el Administrador
de la Base Única podrá aceptar o en su caso rechazar el movimiento como
medida de protección, indicando esta causa en sus observaciones. En caso de
rechazo por esta causa, el área de Prevención de Fraudes de la Institución debe
evaluar el caso y en su caso dar su visto bueno al Administrador de la Base
Capítulo XII

Única para la aceptación del movimiento. La búsqueda descrita en este punto
es una herramienta adicional que proporciona el Administrador de la Base Única
a las Instituciones, sin que ello le represente responsabilidad sobre la afiliación
de Receptores de Pagos con antecedentes de Fraudes.
4.6 DUPLICIDADES DE RECEPTORES DE PAGOS:
Se considera que un Receptor de Pagos está duplicado cuando se encuentra en alguno de

los siguientes casos:
1. Cuando un mismo Receptor de Pagos tiene dos o más números de afiliación,

que no se traten de afiliaciones adicionales, ejemplo una sucursal, centro de
consumo u operativas diferentes; para lo cual, la Institución deberá indicar en el
campo de observaciones que se trata de una afiliación adicional.
4.7 RECHAZO POR DATOS DUPLICADOS:
Si en el envío de la petición de afiliación la Institución no indica que se trata de una afiliación

adicional de acuerdo en el numeral 4.1, entonces será rechazada automáticamente por
duplicidad.
4.8 VALIDACIÓN DEL GIRO:
El Administrador de la Base Única debe validar que el giro corresponda a los Receptores de
Pagos, basado en los siguientes criterios:
1. El giro debe existir en el catálogo de giros Anexo 53 y en caso de requerir un soporte

documental, éste debe coincidir con el giro solicitado, tales como acta constitutiva o
los indicados en el punto 4.10
2. En caso de que el Receptor de Pagos tome el giro de un agrupamiento

(agrupamiento automático).
4.9 RECEPTORES DE PAGOS CON MÁS DE UNA AFILIACIÓN:
A cada Receptor de Pagos se le otorgan afiliaciones por cada tipo de operativa, tales como, MO/TO,
Cargos Recurrentes, Tarjeta Presente, etc.
4.10 DOCUMENTACIÓN SOPORTE:
Cuando el Administrador de la Base Única solicite soporte documental, los participantes deben
enviarlo de acuerdo a lo establecido en el Anexo 52 (sección Documentación Soporte).
Capítulo XII

5.- Agrupamiento de Receptores de Pagos.
Se puede relacionar Receptores de Pagos de acuerdo a los criterios de agrupamiento, para tener un
mejor control de los mismos. El agrupamiento no aplica para efectos de mejorar la clave de
intercambio, solo para procesos internos de las Instituciones y controles operativos.
El agrupamiento se realiza mediante los campos grupo, cadena y criterio de agrupamiento de los
movimientos de Receptores de Pagos.
5.1 FORMACIÓN DE AGRUPAMIENTO.
1. Si se trata de un grupo existente, se asigna la cadena consecutiva a las que ya existan.
2. Si se trata de un grupo nuevo se asigna el número de grupo consecutivo en el rango de la

Institución y la cadena 1. Para nuevos Participantes el Administrador de la Base Única les
debe asignar el siguiente grupo cadena.
2.1 Para el caso de esquemas de agregador 1, 2, 3 las cadenas inician con 1001 y 2001,
respectivamente.
3. Debe existir una afiliación principal activa para poder generar el grupo cadena.
4. Cada Receptor de Pagos debe cumplir al menos uno de los criterios de agrupamiento, de
acuerdo a las reglas que se mencionan en el apartado de criterios de agrupamiento
5. El giro del agrupamiento se obtiene del conjunto de Receptores de Pagos que la integran y
que tienen criterios del 1, 2,3...
6. No debe generar un agrupamiento duplicado, es decir, si ya existe un agrupamiento con

Receptores de Pagos de la misma marca comercial o razón social deben integrarse al
existente.
7. Los centros de consumo pueden integrarse al agrupamiento del Receptor de Pagos principal,
siempre y cuando no pertenezcan a otro agrupamiento.
5.2 INTEGRACIÓN A UN AGRUPAMIENTO EXISTENTE.
1. Los Receptores de Pagos que se integren a un agrupamiento deben ser

enviados con el número de grupo, cadena y criterio de agrupamiento
correspondiente
2. Si un Receptor de Pagos se integra a un agrupamiento, no es necesario que el

número de grupo corresponda al rango de la Institución, es decir, los
agrupamientos no se realizan por Adquirente, sino por cadena comercial.
3. Cada Receptor de Pagos debe cumplir al menos uno de los criterios de

agrupamiento, mencionados en el apartado de criterios de agrupamiento.
4. Los Receptores de Pagos que vean afectada su clave de intercambio y no hayan

sido enviados por la Institución, deben ser enviados por el Administrador de la
Base Única como Actualización de Clave de Intercambio (AC).
Capítulo XII

5. En caso de desagrupamiento, solo puede realizarse si la Institución que envía
es Adquirente único del Receptor de Pagos o Adquirente principal, el
Administrador de la Base Única deberá de informar a los otros Adquirentes que
se desagrupó.
5.3 CRITERIOS DE AGRUPAMIENTO.
CRITERIO NOMBRE/DESCRIPCIÓN
1 Mismo Giro y RFC
Receptores de Pagos con la misma actividad y que pertenecen a la misma

persona física o moral
2 Mismo Giro y Grupo de Accionistas
Receptores de Pagos con la misma actividad cuyos propietarios estén

asociados legalmente (persona física o moral).
3 Mismo Giro y Franquicia u Operadora
Receptores de Pagos con la misma actividad (giro), que sean franquiciatarios

de la misma empresa franquiciante, controlados por la misma empresa
operadora o distribuidores exclusivos de la misma marca comercial.
4 Centros de Consumo
Un Receptor de Pagos se considera centro de consumo del Receptor de

Pagos controlador, cuando sean de distinto giro, se encuentre en el mismo
domicilio (predio). La asignación de claves de familia correspondiente al giro
del agrupamiento solo aplica cuando el giro principal es de Hoteles, Escuelas
o Universidades.
5 Operativas Especiales (NO APLICA PARA NUEVAS AFILIACIONES YA

QUE DEBEN SER REGISTRADOS CON SU GIRO NATURAL)
Receptor de Pagos cuyo giro está en el rango del 5960 al 5969 a excepción
del 5968, el cual debe estar asociado a un Receptor de Pagos controlador.
Los Receptores de Pagos de operativas especiales deben tener el mismo
nombre comercial, domicilio o RFC del Receptor de Pagos controlador y sus
propietarios deben estar relacionados legalmente como socios (persona física
o moral).
Capítulo XII

Subafiliado
6 Receptores de Pagos que operan mediante un Agregador, de acuerdo al
numeral 6 Agregadores
Agregador
7 Es el Receptor de Pago que afilia subcomercios y los agrupa de acuerdo a su
operativa
8 Afiliación por adquirente
5.4 SOPORTES DOCUMENTALES PARA EL AGRUPAMIENTO.
Los soportes documentales solo se solicitan para confirmar la actividad comercial del
Receptor de Pagos y se envían cuando se incurre en uno de los siguientes casos.
Caso Descripción
Cualquier giro Se integra un Receptor de Pagos como centro

de consumo (criterio 4 de agrupamiento).
Giro no corresponde Cuando el Administrador de la Base Única

detecta que el giro asignado por la Institución
no corresponde a la actividad comercial.
Tiendas de autoservicio, Se integra un Receptor de Pagos con giro

departamentales o clubes 5311, 5411, 5300, 5814
de descuento calificadas
1. Los documentos válidos como soporte son:
a. Actas constitutivas, Alta de Hacienda, Constancia de situación fiscal,

Cédula Fiscal o Licencia de Funcionamiento, solo hojas en las que
aparezcan el objeto social, los accionistas, el nombre y tipo de
sociedad.
2. En los documentos soporte debe constar que las razones sociales involucradas
tienen al menos un accionista en común, personas físicas y/o morales.
Capítulo XII

5.5 AGRUPAMIENTO AUTOMÁTICO.
1. El Administrador de la Base Única podrá agrupar automáticamente la

afiliación, es decir, actualizar los campos grupo, cadena y criterio de
agrupamiento, cuando detecte movimientos de Receptores de Pagos que
sean enviados como individuales por la Institución.
a. Se encuentre un grupo cadena que contenga afiliaciones que

coincidan con alguno de los siguientes criterios, sin importar que
dentro de la cadena existan Receptores de Pagos con otros
criterios:
• Criterio 1 (Mismo giro y mismo RFC) Todas las afiliaciones

dentro del grupo-cadena cumplen este criterio.
• Criterio 2 (Mismo giro y grupo de accionistas) Existen

afiliaciones con el mismo giro y RFC dentro del grupo-cadena,
aunque existan otras afiliaciones con diferentes RFC’s.
2. Casos donde no aplica el agrupamiento automático
a. Criterios 3 (Mismo giro y franquicia u operadora)
b. Criterio 4 (Centros de consumo)
c. Criterio 6 (Subafiliados)
d. Cuando se encuentre más de un grupo-cadena donde el Receptor

de Pagos cumpla algún criterio de agrupamiento válido, incluso si
se trata de diferentes cadenas dentro del mismo grupo.
3. El agrupamiento automático solo se aplica si el movimiento es aprobado, es

decir, que no tiene alguna otra causa de rechazo.
4. En las observaciones del Administrador de la Base Única se agrega la

leyenda “Agrupamiento automático”.
5. Es responsabilidad de la Institución Adquirente actualizar el agrupamiento

automático en sus sistemas, lo mismo que el resto de las Instituciones
6. Semanalmente el Administrador de la Base Única entregará a cada

institución un reporte de los agrupamientos automáticos de la semana
inmediata anterior.
Capítulo XII

6.- Agregadores, Integradores y Motores de Pago.
Participante en la Red de Pagos con Tarjetas que, al amparo de un contrato de prestación de
servicios celebrado con un Adquirente, ofrece a Receptores de Pagos el servicio de aceptación de
Pagos con Tarjetas y, en su caso, provee la infraestructura de TPVs conectadas a dichas redes.
Estas entidades también son conocidas con los siguientes nombres:
• PSP (“Payment Service Provider” – Proveedores de Servicios de Pagos).

• PF (“Payment Facilitator” – Facilitador de Pagos).
6.1 ALTA DE AFILIACIONES:
El Adquirente debe registrar a su Agregador/Integrador/Motor de Pago en cualquiera de los cuatro

esquemas de acuerdo al detalle de este mismo punto.
Cuando un Receptor de Pagos/Subafiliado es dado de alta, no se le solicita documentación soporte,

dicha documentación solamente es requerida cuando hay una validación por parte del Administrador
de Base Única.
Para los esquemas 1000 y 2000, el Adquirente debe de entregarle a su

Agregador/Integrador/Motor de Pago por lo menos una afiliación principal por esquema para la
administración de los subcomercios. Las afiliaciones principales no deben de transaccionar. Si
existe más de una afiliación principal por esquema, en cada una se deben de encadenar a los
subcomercios sin importar su giro comercial.
Para los esquemas 3000 y 4000 solo se deben de entregar una afiliación principal por esquema, en
donde la afiliación principal del esquema 3000 no deben transaccionar y para el esquema 4000 si
puede transaccionar.
En cada una debe encadenar a los subcomercios de acuerdo a su forma de operar.
6.2 GRUPO CADENA DE AGREGADORES/INTEGRADORES/MOTORES DE

PAGO CON SUS RECEPTORES DE PAGO/SUB-AFILIADOS
Para el control de éstas afiliaciones deben utilizarse el agrupamiento que se describe en el Anexo
54 y deben de contener un grupo y una cadena.
Para poder encadenar un Agregador y sus subafiliados se requiere:

Tener Grupo o solicitar al Administrador un número de Grupo
GRUPO: Identificador del conjunto de cadenas que pertenecen a un mismo

Agregador/Integrador/Motor de Pagos.
Capítulo XII

Se tiene que utilizar el criterio de agrupamiento para lo cual el Agregador/Integrador/Motor de Pagos
debe de tener un número de afiliación principal y cada Sub-afiliado debe contar con un identificador
independiente.
No hay limitante por afiliación principal
Siempre debe existir afiliación principal para poder ingresar subafiliados.
Para poder encadenar un Agregadores y sus subafiliados se requiere:
Tener Grupo o solicitar al Administrador un número de Grupo.
CADENA: Se llama cadena al número consecutivo por tipo de esquema.
Definición de Estructura de Layout
Campo Tipo Descripción
Grupo Numérico • Número entero, hasta 6 posiciones.
• Para nuevos participantes el Administrador de la

Base Única debe asignar un rango de números de
grupo
• Se deben asignar los números de grupo
Cadena Numérico • Número entero, hasta 4 posiciones
• Consecutivo dentro del grupo validar las posiciones
La estructura de la cadena es CNNN, donde

C=Número de esquema
NNN=Pertenece a la cadena del esquema.
En el campo cadena no existirán consecutivos, la

numeración es fija con la finalidad de no tener limite
en los subafiliados de cada afiliación.
Capítulo XII

CRITERIO DE AGRUPAMIENTO
Criterio de Numérico • 4 posiciones

agrupamiento
• Exista en el catálogo de criterios de agrupamiento
• Debe ser obligatorio cuando el Receptor de Pagos

esté agrupado validar posiciones
Ejemplo: Grupo 2040
A ese Grupo se le asigna una cadena, ejemplo: 1001
Y se toma el agrupamiento en este caso el 7 corresponde al Agregador/Integrador/Motor

de Pagos y el número 6 al subafiliado, quedando de la siguiente manera.
EJEMPLO DE AGRUPAMIENTO:
TASA NATURAL
ESQUEMA 1 AFILIACION PRINCIPAL 1
Criterio de
Grupo Cadena Afiliación Nombre Giro Transacciona
agrupamiento
P 2040 1001 7 1234567 AGTEC*NATURAL 5399 No

1 2040 1001 6 3456782 AGTEC*MISC LUPITA 5422 Sí
2 2040 1001 6 3456476 AGTEC*MISC PATITO 5422 Si
3… 2040 1001 6 2345653 AGTEC*FERRETERIA 5251 Si
Criterio de
agrupamiento
1 2040 1002 6 9876559 AGTEC*ZAP LA LUNA 5661 Sí

2 2040 1002 6 3456476 AGTEC*MISC LUZ 5422 Si
3… 2040 1002 6 2345653 AGTEC*TLAPALERIA 5251 Si
Capítulo XII

ESQUEMA 1 AFILIACIÓN PRINCIPAL 3
Criterio de
agrupamiento

1 2040 1003 6 7253689 AGTEC*ZAP LA LUNA 5661 Sí
2 2040 1003 6 7425896 AGTEC*MISC LUZ 5422 Si
TASA NATURAL POR EXCEPCIÓN
Grupo cadena con modelo de operación Tasa Natural por Excepción
Criterio de
agrupamiento
AGTEC*POR
P 2040 2001 7 1234567 EXCEPCION 5399 No
1 2040 2001 6 5682659 AGTEC*MISC LUPITA 5422 Sí
2 2040 2001 6 5236458 AGTEC*CREMERIA 5451 Si
3… 2040 2001 6 8542568 AGTEC*CALZADO 5931 Si
Criterio de
agrupamiento
AGTEC*POR
P 2040 2002 7 5235689 EXCEPCION 5399 No
1 2040 2002 6 7425842 AGTEC*MISC SOL 5422 Sí
2 2040 2002 6 72123658 AGTEC*LACTEOS 5451 Si
AGTEC*TDA EL
3… 2040 2002 6 6258745 AMIGO 5947 Si
Capítulo XII

TASA AGREGADOR
Grupo cadena con modelo de operación Tasa Agregador o Persona Física sin comprobación de
actividad económica

Criterio de
agrupamiento
AGTEC*GIRO
P 2040 3001 7 7268978 AGREGADOR 5399 No
1 2040 3001 6 7412369 AGTEC*ABARROTES 5399 Sí
2 2040 3001 6 7896541 AGTEC*ARTESANIAS 5399 Si
3… 2040 3001 6 7531598 AGTEC*REGALOS 5399 Si
Criterio de
agrupamiento
AGTEC*GIRO
P 2040 3002 7 5235689 AGREGADOR 5399 No
1 2040 3002 6 7425842 AGTEC*ZAPATERIA 5399 Sí
2 2040 3002 6 72123658 AGTEC*DULCERIA SOL 5399 Si
Nota: En la columna de cadena se identifica de color rojo ya que es siempre fija.
AGREGADOR SIN SUBAFILIADOS
Grupo cadena con modelo de operación Agregador sin registrar Sub-Afiliados
Criterio de
agrupamiento
P 2040 4001 7 3458900 AGTEC*AGREGADOR 5399 Si
1 2040 4001 7 7896785 AGTEC*AGREGADOR 5399 Sí
2 2040 4001 7 7865654 AGTEC*AGREGADOR 5399 Si
3… 2040 4001 7 7687867 AGTEC*AGREGADOR 5399 Si
Capítulo XII

ESQUEMAS DE AFILIACIÓN:
6.2.1 TASA NATURAL:
El Sub-afiliado cuenta con su propio RFC y su giro natural.
Ejemplo: Grupo 0001 cadena 1001 criterio de agrupamiento 7 Nombre del Nombre del
Agregador*NATURAL
Cuando el Receptor de Pagos Sub-afiliado cuenta con un número de afiliación de tasa natural,
se le asigna la tasa de intercambio correspondiente a su giro, el Agregador es responsable de
enviar los movimientos de sus Receptores de Pagos Sub-afiliados, a través de su Adquirente a
la Base Única.
1. Es obligación del Adquirente enviar al Administrador de la Base Única los movimientos
de sus Receptores de Pagos Sub-afiliados.
2. Los Receptores de Pagos Sub-afiliados se actualizan en Base Única y se identifican por
pertenecer a un grupo con giro principal 5399.
3. El grupo-cadena debe corresponder al Agregador.
4. El giro debe corresponder a la actividad principal del Receptor de Pagos Sub-afiliado.
5. El nombre comercial debe estar compuesto del nombre de la afiliación principal del
Agregador, un separador (*) y el nombre del Receptor de Pagos Sub-afiliado sin rebasar
las 22 posiciones del campo.
6. Los Sub-afiliados se agrupan utilizando el criterio de agrupamiento: “6 –Sub-afiliados” el
cual permite integrar en un grupo, con giro principal de Agregador (5399) cualquier
afiliación válida, sin importar su giro y sin requerir ninguna relación accionaria ni de
franquicia con la afiliación principal del Agregador.
7. Si se encuentra que un Receptor de Pagos Sub-afiliado tiene relación con un Receptor
de Pagos bloqueado por clave de Prevención de Fraudes, se rechaza el movimiento y
se reporta el caso al Adquirente para su revisión.
8. Los Sub-afiliados pueden tener otras afiliaciones cuando operen con distintos
Agregadores u otro Adquirente, sin que esto se considere una duplicidad.
9. Para Agregadores y Sub-afiliados que tenga una afiliación diferente a la del Agregador,
aplica la misma regla cuando exista una cancelación y bloqueo que al resto de los
Receptores de Pagos.
• En caso de cancelación o bloqueo de la afiliación principal del Agregador, el
Adquirente decide si mantiene activos a los Sub-afiliados, en tanto aclara la
situación del Agregador.
• En caso de cancelación o bloqueo de afiliación del Receptor de Pagos Sub-
afiliado, sólo se afecta dicha afiliación.
10. El Administrador de la Base Única puede solicitar al Adquirente el envío de
documentación soporte de Receptores de Pagos o a Sub-afiliados en modelo Tasa
Natural o por excepción, de la validación de movimientos.
Capítulo XII

6.2.2 TASA NATURAL POR EXCEPCIÓN:
Ejemplo: Grupo 0001 cadena 2001 criterio de agrupamiento 7 Nombre del Agregador*por
Excepción
1. Si el Receptor de Pagos subafiliado no cuenta con un RFC propio, se debe integrar el RFC
del Agregadores en el campo de RFC, para cumplir con el campo
2. Se da de alta de la misma manera y campos que el modelo de tasa Natural.
3. La afiliación se entrega de forma inmediata después de la validación de datos por el
Adquirente y podrá transaccionar al día hábil siguiente ya que se tienen que compensar,
excepto que el Receptor de Pagos subafiliado tenga temas de riesgo.
El Administrador procede a dar de alta la afiliación y debe solicitar un soporte válido que compruebe
el giro al Adquirente/Agregadores, y éste debe entregarlo máximo en 5 días hábiles posteriores a la
afiliación. De no entregarlo el Administrador, al siguiente día hábil mandará esa afiliación al esquema
3 con tasa de intercambio de Agregadores y debe generar la comunicación del movimiento a la
institución.
Cuando el Adquirente/Agregadores exceda el 1% de incumplimientos sobre el total de

requerimientos relacionados con la entrega de sus comprobantes o por entregar comprobantes no
válidos, se marcará en la base y no podrá usar el esquema de tasa por excepción.
Y tendrá que enviar todos los documentos de sus Receptores de Pago/Subafiliados.
6.2.3 TASA AGREGADOR (GIRO 5399).
El Adquirente o el Agregador deben tener su documentación digitalizada para poder enviarla cuando
le sea solicitada por el Administrador de la Base única, posterior al alta del Receptor de Pago quiere
comprobar su giro o realizar compulsa como a cualquier Receptor de Pagos. El Agregadores u
Adquirente deberá entregar su documentación y si esta no es entregada en un máximo de 24 Hrs el
Administrador ejecutará su movimiento inmediato al esquema 3000 de Agregadores con tasa de
Agregadores.
Ejemplo: Grupo 0001 cadena 3001 criterio de agrupamiento 7 Nombre del Agregador*GIRO
AGREGADOR
1. Si el Receptor de Pagos subafiliado no cuenta con un RFC propio, se debe ingresar el RFC
del Agregador.
2. Los datos de la afiliación son los mismos que el Agregador, excepto el nombre comercial,
domicilio, teléfono, y representante legal, que deben corresponder al Receptor de Pagos
Sub-afiliado.
3. El Agregador es responsable de enviar los movimientos de sus Receptores de Pagos Sub-
afiliados, a través de su Adquirente.
4. Es obligación del Adquirente enviar al Administrador de la Base Única los movimientos de
sus Receptores de Pagos Sub-afiliados.
5. Los Sub-afiliados se actualizan en Base Única y se identifican por pertenecer a un grupo con
giro principal 5399.
6. El grupo-cadena debe corresponder al Agregador.
7. El giro debe corresponder al 5399
Capítulo XII

8. El RFC y la razón corresponden al Agregador, en virtud de que este tipo de Subafiliados no
cuentan con un RFC propio.
9. El nombre comercial debe estar compuesto del nombre de la afiliación principal del
Agregador, un separador (*) y el nombre del Receptor de Pagos Sub-afiliado sin rebasar las
22 posiciones del campo (AGREGADOR* SUBAFILIADO).
10. Los Receptores de Pagos Sub-afiliados se agrupan utilizando el criterio de agrupamiento: “6
– Sub-afiliados” el cual permite integrar en un grupo, con giro principal de Agregador (5399)
cualquier afiliación válida, sin importar su giro y sin requerir ninguna relación accionaria ni
de franquicia con la afiliación principal del Agregador.
11. En caso de bloqueo solo se afecta al Receptor de Pagos Sub-afiliado.
12. Los Receptores de Pago Sub-afiliados pueden tener otras afiliaciones, sin que esto se
considere una duplicidad.
ESTOS GIROS SOLO PUEDEN TENER AFILIACIONES CON TASA NATURAL.
GIRO DESCRIPCIÓN ESTOS GIROS SOLO PUEDEN

OPERAR CON TASA NATURAL
5300 CLUBES DE MAYORISTAS Clubes de compradores/clubes de
membresía
7321 BUROS DE CREDITO, (BURO DE CREDITO AL Protección de crédito/protección contra
CONSUMIDOR), robos de identidad
MERCADEO DIRECTO - COMERCIANTES QUE PRESTAN
Receptores de Pagos de mercadeo
5967 SERVICIOS POR TELEFONO Y QUE RECIBEN LLAMADAS
directo - suscripción
DE LOS TARJETAHABIENTES
5969 MERCADEO DIRECTO - NO CLASIFICADO Receptores de Pagos de infomerciales
Venta de medicamentos controlados o de

prescripción médica vía Internet. No
5912 DROGUERIAS, (FARMACIAS) podrá entregar medicamentos
controlados sin receta médica, debe pedir
la receta y custodiarla
RECEPTORES DE PAGOS ELECTRONICOS (VENTAS A
TRAVES DE INTERNET), (SERVICIOS - RED DE
4816 Sitios de remisión a farmacias de Internet
COMPUTADORAS), (SERVICIOS DE INFORMACION POR
COMPUTADORA)
Receptores de Pagos de mercadeo a
5963 VENTAS DE PUERTA - EN – PUERTA múltiples niveles, cuando no hay
presencia de tarjeta
MERCADEO DIRECTO - COMERCIANTES DE
5966 TELEMERCADEO QUE HACEN LLAMADAS A LOS Tele mercadeo de salida
TARJETAHABIENTES
Receptores de Pagos de Venta Dirigida,
5964 MERCADO DIRECTO - VENTAS POR CATALOGO
cuando no hay presencia de tarjeta
4814 SERVICIOS DE TELECOMUNICACION INCLUYENDO,
LLAMADAS TELEFONICAS LOCALES Y LARGA DISTANCIA,
Telecom
LLAMADAS CON TARJETAS DE CREDITO, TELEFONO CON
LECTOR DE BAN
Receptor de Pagos electrónico
RECEPTORES DE PAGOS ELECTRONICOS (VENTAS A
4816 (Contenido para Adultos). Se prohíbe la
TRAVES DE INTERNET), (SERVICIOS - RED DE
pornografía infantil, brutalidad, zoofilia o
Capítulo XII

COMPUTADORAS), (SERVICIOS DE INFORMACION POR cualquier actividad prohibida por las leyes
COMPUTADORA) nacionales.
7995 CASINOS, CASAS DE JUEGO, (APUESTAS, INCLUYE
Negocios de apuestas (Sin presencia de
BILLETES DE LOTERIA),(LOTERIAS, JUEGOS DE
Tarjeta)
AZAR),(APUESTAS - CARRERAS DE CABALLOS)
5993 TABAQUERIAS Producción de tabaco (Sin presencia de
Tarjeta)
6.2.4 AFILIACIÓN ÚNICA POR AGREGADOR
Esta afiliación principal si transacciona y no se conocen los ID de los sub-afiliados
• Responsabilidad directa del Agregador

• El grupo-cadena debe corresponder al Agregador.
• El RFC y la razón corresponden al Agregador, en virtud de que los afiliados no están
registrados en la Base Única
• En caso de bloqueo afecta a todos los Receptores de Pagos ya que todos transaccionan
con la misma afiliación
6.2.5 TASA CERO
Criterios de Validación para comercios que pueden obtener el incentivo de Tasa Cero por un año
para fomentar el uso de los medios de pago con transacciones de débito de estas 6 familias.
1.- Aplicará solo para comercios nuevos y Reactivaciones.
1.1.-Para personas físicas:
• Acta de Hacienda, solo aplica cuando la razón social y nombre comercial no corresponda al
giro solicitado.
1.2.-Para personas morales:
• Acta de Hacienda, solo aplica cuando la razón social y nombre comercial no corresponda al
giro solicitado.
2.-Para cambios de giro, el solicitante deberá de comprobar:
• Presentar evidencia fotográfica de acuerdo al giro solicitado(Es necesario presentar

fotografías de fachada de comercio e interior, se deberán de enviar en formato PDF de hasta 3 Mb).
• Acta de Hacienda
En caso de no recibir la documentación soporte la solicitud se rechaza.
Capítulo XII

Familias Tasa Cero:
Giro al
Familia Giro Descripción Condiciones
por mayor
Escuelas y colegios, niveles
preescolar o kínder, primaria y
8211 secundaria, cuando no cuenten con
grado de preparatoria o universidad.
Solo escuelas pequeñas kínder, primaria y
Educación Academias y escuelas de cursos por
8241 secundaria, siempre y cuando no tenga 8220
Básica correspondencia
preparatoria y universidad)
Academias y escuelas sin grado
académico, instrucción o cursos de
8299 música, arte, cocina, modelaje, karate,
manejo u otros.
742 Servicios Veterinarios 5995
Médicos y cirujanos generales o de

especialidades, dermatología,
psiquiatría, radiología, ortopedia,
8011 pediatría, neurología, ginecología, 8099
obstetricia u otros. Consultorios
médicos que no sean clínicas ni
hospitales.
Odontólogos generales o de
especialidad, ortodoncia, endodoncia,
8021 periodoncia u otra. Dentistas,
7298
Servicios profesionales de médicos de cualquier
consultorios dentales.
Médicos y profesión de medicina y no tiendas, no
dentistas Médicos osteópatas. Consultorios
comercios, no talleres, no farmacias, no clínicas,
8031 médicos que no sean clínicas ni no hospitales
hospitales.
Quiroprácticos. Consultorios médicos

8041 que no sean clínicas ni hospitales.
8062
Oftalmólogos y optometristas,
8042 consultorios médicos que no sean
clínicas ni hospitales
Pedicuristas, quiropodistas.
8049 consultorios médicos que no sean
clínicas ni hospitales
Guarderías, puericultura, estancias

Guarderías 8351 infantiles
Específicamente guarderías 8999 / 7399
Distribuidores de artículos de
ferretería y herramienta al por menor
5072 manual o eléctrica. No
5039
departamentales,
Solamente a los comercios de venta al por
Distribuidores de artículos de plomería menor no talleres ni agencias automotrices ni
Refacciones y 5074 y calefacción.
5039 / 5085
venta de refacciones o ferretería al por mayor,
Ferreterías no departamentales. Si se encadenan se
Artículos de ferretería, plomería y/o deberá revisar de manera trimestral.
5251 herramientas.
5039
Autopartes y accesorios automotrices.

5533 No agencias automotrices.
5013
Incluye estética y peluquerías con venta mínima

Salones de Salones de belleza, peluquerías, de productos de belleza. No categorías Spa. No
7230 7298
Belleza estéticas, uñas, maquillaje. No spa. masajes y no clínicas de belleza. No venta al
por mayor de productos de belleza.
Capítulo XII

Abarrotes, misceláneas, tiendas Tiendas al por menor llamadas como tiendas de
naturistas, carnicerías, pescaderías,
Miscelánea 5422 verdulerías, tortillerías. No tiendas de
colonia que no sean de conveniencia. No aplica 5411 / 5199
conveniencia. venta al por mayor.
Nota: En caso de controversia entre dos adquirentes, se llevará al grupo de trabajo.

Se recomienda dar de alta una nueva afiliación en caso de contar con más una actividad en
el mismo domicilio.
6.3 OBLIGACIONES DEL ADQUIRENTE Y AGREGADOR EN LA BASE UNICA
1. Debe crear los grupos-cadena definidos en el Anexo 54 e integrar en él a cada uno de los
Receptores de Pagos sub-afiliados.
2. No debe permitir que el Agregador afilie Receptores de Pagos con actividades de
pornografía infantil, bestialidad, zoofilia o cualquier actividad prohibida por las leyes
nacionales.
3. Es responsable de atender las solicitudes de documentación que le requiera el
Administrador de la Base Única, conforme al apartado Documentos Soporte.
4. Requerir a los sub-afiliados la documentación Soporte del cuadro Modelos de sub-
afiliados, detallado en el Anexo 54.
5. Los Receptores de Pagos sub-afiliados con tasa natural, no pueden operar transacciones
de actividades comerciales que no correspondan a su giro.
6. Los Agregadores no deben sub-afiliar a otros Agregadores, es decir un Agregador no
puede operar a través de otro Agregador.
6.4 AFILIACIÓN PERSONAS FÍSICAS SIN COMPROBAR ACTIVIDAD.
Ofrecer un esquema de afiliación para Personas físicas que no pueden demostrar su actividad
comercial por la cual recibiría ingresos mediante la aceptación de Medios de Pago Electrónico.
ALCANCE: Puede ser cualquier operativa (Tarjeta Presente y no presente).
ALTA DE AFILIACIONES:
Se utilizara la familia (76), considerando que es el mismo intercambio.
Se utilizara el giro 5399 con criterio 8
GRUPO CADENA
Para el control de éstas afiliaciones deben utilizarse un número identificador por cada Adquirente
participante.
GRUPO El adquirente + CADENA (POR SERVICIOS)+ CRITERIO DE AGRUPAMIENTO 8 +

AFILIACIÓN (#) + NOMBRE (xxx) + GIRO (5399) + Todas transaccionan.
Capítulo XII

EJEMPLO DE AGRUPAMIENTO
Puede
Criterios de Razón
Grupo Cadena Afiliación Nombre RFC Giro Transa
Agrupamiento Social
ccionar
BMR - 69999
EVO –
399998 JUAN
XAXX0
PRO - JUAN PEREZ
3001 8 1234567 101010 5399 SI
999999 PEREZ GONZAL
00
EGL - EZ
299999
Campo Campo Campo Campo Campo Campo Campo Campo NA

numérico, se Numérico numérico, es un numérico alfanumérico alfabético alfanum numéric
asigna Lo Asigna identificador que se Asignado por , Nombre érico, o, Giro
número de el asignado a los asigna por el Adquirente completo Único asociad
grupo por Adquirente adquirentes para el oficial o a la
Institución afiliar sin Adquirente para Familia
para comprobar su person 76
identificarlo. actividad as
físicas
definido
por el
SAT.
GRUPO: Número fijo que identifique a cada adquirente.
Los números asignados por cada institución, son:
BMR - 69999
EVO – 399998
PRO - 999999
EGL - 299999
CADENA: Se llama cadena al número consecutivo por cada una de las clasificaciones que se
definan.
La cadena a utilizar es: 3001
CRITERIO DE AGRUPAMIENTO: Se utilizará el nuevo criterio de agrupamiento 8
(Familia 76).
REGLAS:
1. Siempre tienen que enviar el grupo XXXX (Número fijo asignado para cada institución)
2. Se utilizara el Rfc Genérico( XAXX010101000 )
3. De acuerdo a la clasificación determinada, se tiene que enviar el número de cadena definido
que le permite al Adquirente identificar la actividad de sus afiliados.
4. El criterio de agrupamiento deberá de ser siempre el número 8.
5. Para aquellos afiliados que soliciten cambiar a un giro de acuerdo a la familia de la actividad
que compruebe, este deberá de presentar la documentación soporte correspondiente.
6. Una vez que cambia de esquema no podrá regresar al esquema anterior.
7. El Adquirente debe entregar a su afiliado una sola afiliación.
Capítulo XII

8. No requiere el envío de documentación soporte.
DOCUMENTACION SOPORTE MINIMA REQUERIDA POR EL ADQUIRENTE:
1. Identificación Oficial
2. Comprobante de Domicilio
3. Clave de CURP.
6.5 AFILIACIÓN BAJO EL ESQUEMA DE TASA NATURAL.
Ofrecer un esquema de afiliación que permita al adquirente la inclusión de nuevos participantes de

una forma ágil garantizando la aceptación de Medios de Pago Electrónico.
ALCANCE: Puede ser cualquier operativa (Tarjeta Presente y no presente). Giros con Beneficio del
Intercambio Tasa Cero sin límites de facturación. Misceláneas, Tlapalerías, Escuelas de Educación
Básica y Médicos y Dentistas
Características:
Tiempos de Afiliación
De acuerdo a las condiciones descritas en este documento, el adquirente enviara en el proceso de

Alta la solicitud de afiliación dentro de las ventanas de tiempo ya establecidas, recibiendo respuesta
el mismo día.
Documentación Soporte
La documentación soporte debe ser integrada con cualquier comprobante que demuestre la actividad
comercial del giro solicitado, toda vez que el administrador solicite el sustento de la actividad por
encontrar diferencias entre el nombre comercial y el giro. En caso de no ser entregada se moverá al
giro 5399.
Nota:
El Acta Constitutiva, no es el único soporte documental, este puede ser sustituido por el Alta de
Hacienda o cualquier otro que compruebe la actividad comercial.
Ejemplos:
• Contratos de servicios.
• Contratos de arrendamiento.
• Facturas de proveedores.
Capítulo XII

EJEMPLO DE AGRUPAMIENTO
Criterios
Caden de Razón
Grupo Afiliación Nombre RFC Giro
a Agrupami Social
ento
BMR - 69999 XAXX010101000
EVO – 399998 ABARROTES
ABARROTE
PRO - 999999 3002 8 1234567 LUPITA SA O 5422
S LUPITA
EGL - 299999 DE CV
ABA 050719AX1
Campo Campo Campo Campo Campo Campo Campo Campo

numérico, se Numéric numérico, es numérico alfanumérico alfabético, alfanumérico, numéric
asigna número o Lo un que se Asignado Razón social Único oficial para o, Giro
de grupo por Asigna identificador asigna por el por el correspondient personas físicas asociad
Institución para el asignado a Adquirente Adquirente. e al receptor definido por el o a la
identificarlo. Adquire los Debe de pagos. SAT. Puede actividad
nte. adquirentes corresponde utilizar el RFC del del
para afiliar r a la comercio. receptor
sin actividad del de
comprobar receptor de pagos.
su actividad. pagos.
ALTA DE AFILIACIONES:
Se utilizara el giro natural.
Se utilizara criterio 8.
Capítulo XII

7.- Control de afiliaciones por Adquirente
El Administrador de la Base Única debe mantener registrado en la Base Única, por cada afiliación:
• Institución
• Adquirente(s)
• Último mes de actualización de cada Adquirente
• Último movimiento que afectó el Adquirente del Receptor de Pagos
7.1 REPORTE DE ACTUALIZACIÓN DEL ARCHIVO MENSUAL DE

ADQUIRIDOS
Proceso mediante el cual las Instituciones Adquirentes envían al Administrador de la Base

Única, información de los Receptores de Pagos que adquieren, para efectos de su validación
contra los movimientos de la Base Única, con el fin de encontrar afiliaciones adquiridas por
una Institución, sin que esto se haya registrado con el movimiento correspondiente.
1. Las Instituciones envían mensualmente, al Administrador de la Base Única un archivo,

que contenga las afiliaciones de sus Receptores de Pagos adquiridos, al cierre del mes
inmediato anterior.
2. El archivo debe ser enviado al Administrador de la Base Única, durante los primeros 14
días naturales de cada mes.
3. El formato del archivo es texto separado por tabuladores sin encabezados.
4. La nomenclatura del archivo es: ADQbbbmmaaaa.TXT. Donde
¨ bbb = Clave de la Institución
¨ mm = Mes al cual corresponden los datos
¨ aaaa = Año al cual corresponden los datos
5. La estructura del archivo es:
Campo Tipo Longitud
Afiliación Entero 7,0
Institución Carácter 3,0
Adquirente Entero 3,0
6. El contenido de Institución y Adquirente es obligatorio, de lo contrario el archivo debe ser

reenviado por la Institución:
Capítulo XII

7. El archivo no debe contener afiliaciones duplicadas ni nulas, de lo contrario debe ser
corregido y reenviado por la Institución.
8. El Administrador de la Base Única debe reportar vía e-mail a la Institución sus afiliaciones
adquiridas que no cuenten con el movimiento correspondiente en la Base Única.
9. La Institución contará con 10 días hábiles para enviar la modificación de las afiliaciones
reportadas por el Administrador de la Base Única en el punto anterior1.
10. En caso de que la Institución no realice las modificaciones solicitadas en el plazo de 10

días hábiles el Administrador de la Base Única deberá reportarlo al Grupo Base Única
para su revisión.
7.2 ACTUALIZACIÓN DE LA DEPURACIÓN
¨ Cuando exista una depuración de Receptores de Pagos, para aquellas afiliaciones que
sean depuradas, El Administrador de la Base Única deben eliminar los registros de
Adquirente de dichas afiliaciones, sin la necesidad de almacenar un histórico de estos
registros, ya que son regenerados en caso de que la afiliación se dé de alta de nuevo.
7.3 CONTROL DEL CAMBIO DE ADQUIRENTE PARA PCI 1 :
Para los Receptores de Pagos que se encuentren en proceso de verificación PCI de acuerdo
a la Normativa, capítulo XVII Reglas de Seguridad de la Información en PCI, el Administrador
de la Base Única deberá verificar los cambios de Adquirente.
1. Cuando el Administrador de la Base Única detecte a través de los movimientos del

intercambio de Receptores de Pagos que Receptores de Pagos PCI están cambiando
de Adquirente deberá verificar si se siguen cumpliendo los criterios establecidos en los
procedimientos de Segmentación del capítulo XVII ya que no pueden cambiar de
Adquirente si no cumple con la certificación de PCI
2. Si se presentan cambios de Adquirente que provoquen el cambio de Adquirente

mayoritario del Receptor de Pagos se considera un cambio de responsabilidad
• El Administrador de la Base Única debe notificar el cambio de

responsabilidad a los Adquirentes involucrados en un plazo no mayor a tres
días hábiles
• El Administrador de la Base Única debe y registrar el cambio de

responsabilidad en la Base PCI en un plazo no mayor a tres días hábiles
• El nuevo Adquirente mayoritario toma la responsabilidad sobre el

seguimiento y cumplimiento de la Verificación PCI a partir de la fecha de
notificación del Administrador de la Base Única
7.4 HISTÓRICO:
Capítulo XII

1. El Administrador de la Base Única conserva el dato del último movimiento del
intercambio de Receptores de Pagos que afectó el registro de Adquirentes de un
Receptor de Pagos.
2. Se considera necesario guardar un histórico de los cambios de Adquirente dentro de

la base de datos.
7.5 ALTAS, BAJAS Y CAMBIOS DE ENTIDADES ADQUIRENTE:
1. El Administrador de la Base Única debe aplicar los cambios que afecten el catálogo
de Adquirentes señalado en el Anexo 52 y en la Base Única, en un plazo no mayor
a 1 día hábil después de haber reenviado el mensaje a los participantes.
Capítulo XII

8.- Cancelación de inactivos y Depuración de
cancelados
Proceso anual, en el cual se determinan aquellas afiliaciones que no se encuentran en operación,
para borrarlas de la Base Única, conservando su historial.
8.1 REGLAS GENERALES:
El proceso de depuración se realiza de manera anual, en el mes de febrero de cada año.
8.1.1 CANCELACIÓN DE AFILIACIONES ACTIVAS QUE NO FACTURAN
• El Administrador de la Base Única solicita a las Instituciones el archivo de

Afiliaciones Activas, el cual debe contener todas las afiliaciones que se encuentran
activas en la Base Única, cuya fecha de alta sea más de tres meses anterior a la
fecha en que se genere el archivo
• Las Instituciones indican aquellas afiliaciones que no presenten facturación de

EMISOR en sus sistemas, considerando para ello la facturación de 4, 5 y 6 meses
anteriores al mes de envío de las Afiliaciones Activas o bien afiliaciones que por
alguna circunstancia no está de acuerdo en que sean depuradas. Deben
actualizar el campo “cancelar” con los siguientes valores:
o 0, cuando no acepta que se cancele
o 1, cuando sí acepta que se cancele
• Las Instituciones cuentan con 14 días naturales para devolver el archivo al

Administrador de la Base Única, en el mismo formato que les fue enviado, este es
el archivo de Facturan Por Emisor
• El Administrador de la Base Única integra los archivos de las Instituciones para

obtener aquellas afiliaciones que no presenten facturación con ningún emisor,
este es el archivo de Activas Sin Facturar
• El Administrador de la Base Única cuenta con 7 días naturales para entregar el

archivo de Activas Sin Facturar a las Instituciones
• Las Instituciones deben enviar los movimientos de cancelación de aquellas

afiliaciones Activas Sin Facturar que tenga adquiridas.
8.1.2 DEPURACIÓN DE AFILIACIONES CANCELADAS
El proceso de depuración se lleva a cabo en el mes de febrero, el Administrador

debe entregar dentro de los primeros 14 días hábiles del mes, un archivo a cada
institución con las afiliaciones susceptibles de depuración, este debe incluir las
afiliaciones propias de la institución y las afiliaciones multiadquiridas que cumplan
con las siguientes características:
Capítulo XII

o Su fecha de alta es previa al 1 de enero del año anterior
o Está cancelado y su fecha de cancelación tiene más de 13 meses de

antigüedad
o No se encuentra bloqueado en la Base Única (claves del rango de

Prevención de Fraudes)
• A partir de la fecha de entrega del archivo de Afiliaciones Susceptibles de

Depuración, cada Institución cuenta con un plazo de 14 días hábiles, para
responder al Administrador de la Base Única, entregando un Archivo de
Confirmación donde indique cuáles afiliaciones aceptan que sean depuradas y
cuáles no, deben actualizar el campo “depurar” con los siguientes valores:
o 0, cuando no acepta que se depure
o 1, cuando sí acepta que se depure
• El Administrador de la Base Única debe obtener, con base en los Archivos de

Confirmación, las afiliaciones de las cuales las Instituciones autorizan la
depuración. Estas son las Afiliaciones a Depurar.
• El Administrador de la Base Única debe verificar nuevamente el día que se hace

la depuración contra la base de datos, las afiliaciones a depurar siguen siendo
susceptibles de depuración. Aquellas afiliaciones que ya no lo sean, deben ser
excluidas de las afiliaciones a depurar.
• A partir de la fecha en que el Administrador de la Base Única haya recibido todos

los Archivos de Confirmación cuenta con 7 días hábiles para reportar a cada
institución el archivo final para su revisión y aprobación.
• Una vez que se reciba el Vo.Bo. de cada institución el Administrador cuenta con
7 días hábiles para la aplicación de las bajas correspondientes en la Base Única,
generando una ventana especial de movimientos misma que debe entregarse a
las instituciones.
• A partir de que cada Institución haya recibido los movimientos de Baja, cuenta
con 15 días hábiles para depurar las afiliaciones de sus sistemas.
• El administrador debe llevar un control de las afiliaciones que fueron depuradas

y se den de alta nuevamente durante los 15 días de actualización por parte de
las instituciones.
• Se deben reportar los avances en el grupo de trabajo de Base Única.
Capítulo XII

9.- Confronta
Proceso por el cual se el Administrador de la base única certifica que las Instituciones mantienen la
integridad de los datos de la Base Única en sus sistemas.
Reglas:
1. Durante el mes de enero de cada año, las Instituciones entregan al

Administrador de la Base Única, a través de su Empresa especializada su base
de datos de Receptores de Pagos/Agregadores de su sistema central, para
validar la consistencia de datos, con corte de información al cierre del año
inmediato anterior.
2. El Administrador de la Base Única realiza la confronta y le reporta resultados.
3. El archivo que envíe la Institución debe cumplir Administrador de la Base Única

las siguientes especificaciones:
LONGIT
CAMPO TIPO UD DESCRIPCIÓN
(máxima)
afiliacion Número 7 Afiliación
Nombre Texto 22 Nombre
rfc_ini Texto 4 Iniciales del RFC
rfc_fecha Texto 6 Fecha del RFC
rfc_homoclave Texto 3 Homoclave del RFC
razon_social Texto 30 Razón social
Domicilio Texto 30 Domicilio
Colonia Texto 30 Colonia
Población Texto 30 Población
Cp Número 5 Código Postal
Telefono Texto 10 Teléfono
Capítulo XII

rep_legal Texto 30 Representante legal
Giro Número 4 Giro
Grupo Número 6 Grupo
Cadena Número 4 Cadena
clave_cancelacion Número 2 Clave de cancelación
cat_credito Número 2 Clave de familia de crédito
asig_cat_credit Texto 2 Clave de asignación de crédito
cat_debito Número 2 Clave de familia de débito
asig_cat_debito Texto 2 Clave de asignación de débito
• La entrega es en un archivo de texto separado por tabuladores, con

encabezados y sin calificadores de texto
• Se deben incluir tanto afiliaciones activas como canceladas o

bloqueadas
• Se deben incluir afiliaciones propias y de otros Adquirentes
• No incluir afiliaciones de uso interno
• La información debe provenir de sistemas centrales, no de la réplica de

Base Única
• El corte de información es al cierre del año inmediato anterior
4. El Administrador de la Base Única valida con un muestreo que la información

sea realmente del sistema de cada Institución.
5. La confronta es de la Base Única contra el sistema de cada Institución.
6. El Administrador de la Base Única debe emitir los reportes de resultados de la

confronta, a cada una de las Instituciones, en un plazo no mayor a 7 días
naturales a partir de la recepción de su archivo.
7. A petición de alguna Institución, el Administrador de la Base Única puede realizar

confrontas parciales o totales, del sistema central de otra Institución contra la
Base Única. Sin que exceda de dos peticiones al año por Institución solicitante.
Capítulo XII

Las Instituciones tienen máximo 30 días naturales para inconformarse o aplicar todas
las correcciones de datos generales en sus sistemas, así como 7 días naturales para
las diferencias de clave de intercambio.
Los resultados deben ser presentados a los Adquirentes, por el Administrador de la

Base Única a más tardar 7 días naturales después de realizada la confronta, con el
siguiente formato:
Confronta de datos <institución> Vs. BU
Corte -------
Afiliaciones recibidas ----------
No existen en BU ( - ) ----------
Afiliaciones comparadas ----------
No existen en Institución (
+) ----------
En BU ----------
AFILIACIONES COMPARADAS: ----------
Campo Diferentes Iguales
Nombre - -
Rfc - -
razon_social - -
domicilio - -
colonia - -
Capítulo XII

población - -
Cp - -
teléfono - -
rep_legal - -
giro - -
grupo - -
cadena - -
clave_cancelacion - -
cat_credito - -
asig_cat_cred - -
cat_debito - -
asig_cat_deb - -
Capítulo XII

CAPÍTULO XIII
VALIDACIÓN DE
RECLAMACIÓN DE UN
TARJETAHABIENTE Y CÓDIGO DE
RAZÓN 63 CHIP (EMV)
Capítulo XIII 1
VALIDACIÓN DE RECLAMACIÓN DE UN TARJETAHABIENTE
Y CÓDIGO DE RAZÓN 63 CHIP (EMV)
Antecedentes:
Las Instituciones han establecido un proceso que les permita validar que los
participantes en el Intercambio Local, no realicen prácticas fuera de normas en
la presentación de Contracargos.
Definición:
Es el proceso mensual que realiza el Árbitro Operativo para verificar la

existencia de Carta Reclamación o inicio de una solicitud de aclaración por
parte de un Tarjetahabiente en un proceso de controversia, así como verificar
que el contracargo por código de razón 63 CHIP (EMV), cumpla con las
condiciones de Skimming, Chip + NIP y ARQC que establece el punto 4 del
capítulo XV Chip EMV del Manual Operativo.
Tipos de Validación:
Aplica a las Instituciones Emisoras detalladas en el Anexo 29 (Instituciones

Participantes en el Intercambio Local) de acuerdo a lo siguiente:
• Programada (Una vez al año)

• Por Monitoreo (Trimestral o Cuatrimestral)
• Por Solicitud (A solicitud de un Adquirente)
1. Validación Programada:
Es el proceso mediante el cual el Árbitro Operativo, realiza una revisión por

año calendario (Enero – Diciembre) a cada una de las instituciones
registradas en el Anexo 29 (Participantes en el Intercambio Local) de
acuerdo a lo siguiente:
Las Instituciones de nuevo ingreso se incorporan al sorteo cuatro meses

después de su integración al Anexo 29.
Esta revisión no procede cuando el Emisor se encuentre en un proceso de

validación por monitoreo Trimestral o Cuatrimestral.
Capítulo XIII 2
1.1 Procedimiento:
Las Cámaras de Compensación deben enviar al Árbitro Operativo dentro de
los primeros 5 días hábiles de cada mes, un archivo “Electrónico” a través
de un medio seguro con el total de los Primeros Contracargos recibidos
como Adquirente del mes inmediato anterior.
1.2. El archivo Electrónico de Contracargos debe contener la siguiente

información:
• Nombre del Adquirente

• Número de Cuenta (Formato 123456XXXXXX1234)
• Importe de Contracargo
• Código de razón
• Fecha de Contracargo
1.3. El Árbitro Operativo dentro de los primeros 5 días hábiles de cada mes y
ante un representante de las Instituciones determina las Instituciones a
revisar mediante un sorteo.
1.4 El Árbitro Operativo selecciona una muestra aleatoria de 60 transacciones

de Contracargos del archivo Electrónico recibido, de los cuales 30
contracargos para validar Carta Reclamación del Tarjetahabiente y 30
Contracargos del Código de Razón 63 Chip EMV para validar Skimming,
en caso de que la Institución a revisar no cuente mínimo con 30
Contracargos por proceso en el mes, el Árbitro Operativo puede integrar la
muestra con información de hasta tres meses anteriores.
1.5 El Árbitro Operativo notifica a los Emisores dentro de los 3 días hábiles
siguientes a la recepción del archivo Electrónico, y dentro de un horario de
9.00 a 17.00 horas, a los funcionarios responsables señalados en el
Anexo 11 (Funcionarios Facultados para Sometimiento Arbitral), la
relación de transacciones a revisar (debiendo contener los mismos datos
del Archivo Electrónico recibido).
1.6 El Emisor tiene 12 días hábiles para entregar en las instalaciones del
Árbitro Operativo, mediante escrito libre y dentro de un horario de 9.00 a
17.00 horas, copia legible de la Carta Reclamación del Tarjetahabiente o
requerimiento de Autoridad o área jurídica de la Institución o copia del
registro de entrada de la solicitud de Aclaración del Tarjetahabiente
señalados en el Anexo 30, autorizado y previamente Certificado ante el
Árbitro Operativo, de acuerdo al procedimiento señalado en el Anexo 28
(Procedimiento de Certificación de Información).
En caso de que la documentación entregada al Árbitro Operativo sea

ilegible o incompleta, esta se notifica por correo electrónico y se confirma
vía telefónica a los funcionarios responsables detallados en el Anexo 11
(Funcionarios Facultados para Sometimiento Arbitral), el Emisor
Capítulo XIII 3
responsable tiene 2 días hábiles a partir del día hábil siguiente a la
notificación del Árbitro Operativo, para entregar la documentación, de lo
contrario se determina resultado NO SATISFACTORIO.
Cuando se trate de rechazos de Computador no aplica el proceso de

validación de Carta Reclamación.
Para el código de razón 63 Chip (EMV), adicionalmente a la información

señalada anteriormente, debe enviar la documentación para cada opción
de cambio de responsabilidad, misma que se detalla en el punto 4 del
capítulo XV.
La entrega de información al Arbitro Operativo, también puede ser

mediante correo electrónico con un máximo de 10 megabytes por mensaje
y deben confirmar telefónicamente la recepción y legibilidad del mismo
con el Árbitro Operativo.
1.7 Una vez recibida la información en tiempo y forma, el Arbitro Operativo

verifica que correspondan al No. de Cuenta e importe de los Contracargos
solicitados.
El Árbitro Operativo cuenta con 8 días hábiles siguientes a la recepción de

la documentación, para emitir y notificar a la Institución en cuestión el
resultado de la revisión, determinando en su caso las sanciones
financieras señaladas en el punto 4 de este capítulo.
1.8 Cuando se solicite la baja de un prefijo, este permanecerá vigente para el

proceso de validación durante los 6 meses siguientes a la fecha en que se
solicitó la baja.
2. Revisión por Monitoreo o por Solicitud de un Adquirente.
Es el proceso mediante el cual un Emisor es revisado de forma periódica por el

Árbitro Operativo (Trimestral, Cuatrimestral o por solicitud de un Adquirente),
de acuerdo a lo establecido en el punto 1.4 de este capítulo, por alguna de las
siguientes causas:
• Presentar Contracargos sin contar con Reclamación del

Tarjetahabiente.
• Presentar Contracargos sin contar con copia del registro de entrada
de la solicitud de Aclaración del Tarjetahabiente.
• Presentar Contracargos sin contar con requerimiento de Autoridad:
o Comisión Nacional Bancaria y de Valores.
o Banco de México.
o CONDUSEF.
• Presentar Contracargos por código de razón 63 Chip (EMV), sin
que cuente con las condiciones de Skimming, CHIP + NIP o
ARQC, señaladas en el punto 4 del capítulo XV Chip EMV del
Manual Operativo
Capítulo XIII 4
2.1 Durante este proceso los Adquirentes mantienen vigente su derecho de
solicitar una revisión de acuerdo a lo establecido en el punto 4.14 del
capítulo I del Manual Operativo.
2.2 Los plazos de notificación y de entrega de información son los mismos que
se señalan para el proceso de Revisión Programada mencionados en el
punto 1 del presente capítulo.
2.3 La responsabilidad financiera es de acuerdo a lo señalado en el punto 4 de

este capítulo, más el costo de los honorarios vigentes con el Árbitro
Operativo para este proceso.
2.4 Cuando en un proceso de revisión (Programado, Trimestral, Cuatrimestral o

por solicitud de un Adquirente), se requiera de otros elementos que
permitan al Árbitro Operativo confirmar la autenticidad de la solicitud de
Aclaración por parte de un Tarjetahabiente, o las condiciones de
Skimming, el Arbitro Operativo puede solicitar al Emisor información
adicional que le permita ratificar la documentación presentada, para lo
cual el Emisor cuenta con 2 días hábiles a partir del día hábil siguiente de
la solicitud del Árbitro Operativo, para entregar la información.
Solo en el caso de que la información solicitada dependa de la respuesta

de las marcas, se establece un plazo de 20 días hábiles a partir del día
hábil siguiente de la solicitud del Árbitro Operativo, para la entrega de la
información, en caso de exceder el plazo se escala a los participantes.
2.5 Las revisiones por Monitoreo cuya fecha de aplicación sean en el mes de
Diciembre, se recorren al mes de Noviembre del año en curso.
3. Resultado de la Validación:
El resultado de la revisión de Información será de acuerdo a lo siguiente:
a) Satisfactorio, en el total de Contracargos de la muestra, existe

Reclamación o un proceso de Solicitud de Aclaración por parte de los
Tarjetahabientes o los contracargos por código de razón 63 Chip EMV
cumplen con las condiciones de Skimming, CHIP + NIP o ARQC,
señaladas en el punto 4 del capítulo XV Chip EMV. (No Aplica
Responsabilidad Financiera).
b) No satisfactorio, en uno o varios Contracargos de la muestra:
• No se documentó la Reclamación del Tarjetahabiente.

• El contenido de la carta Reclamación del Tarjetahabiente se
complementó, agregó y/o modificó.
• El medio de registro de Solicitud de Aclaración no está
certificado.
Capítulo XIII 5
• El medio de registro de Solicitud de Aclaración no contiene
alguno de los datos mandatorios señalados en el Anexo 28
(Procedimiento de Certificación de Documentos).
• No se entregó pantalla de registro de fraude de las Marcas de
acuerdo al Anexo 45 (Reporte de Fraude).
• Tratándose de cambio de cambio de responsabilidad por
Skimming, el registro de fraude en las Marcas no es por código
04 ó 4.
• Tratándose de cambio de cambio de responsabilidad por CHIP
+ NIP, el registro de fraude en las Marcas no es por código 00,
01 o 02 para Visa o 01, 02 o 03 para Mastercard.
• El registro de fraude en las Marcas se efectuó, modificó o
eliminó posterior a la fecha del primer contracargo.
En cualquiera de los casos señalados en el inciso b), aplica responsabilidad

financiera.
3.1 En caso que el Emisor NO proporcione la información solicitada por el

Arbitro Operativo o la proporcione incompleta / incorrecta, el resultado
es no satisfactorio.
3.2 Cuando en un mismo período de revisión (Programada, por Monitoreo o

por solicitud de un Adquirente), se detecten dos o más anomalías
éstas no son acumulativas y sólo se considera como un evento para la
aplicación de la penalización 32 del Capítulo V (Penas Convencionales
por Incumplimiento).
3.3 Una vez emitido un fallo en contra del Emisor, las incidencias anteriores
a esta fecha no son acumulativas para la aplicación de la
Responsabilidad Financiera, aun cuando se deriven de un arbitraje.
Las incidencias posteriores si son consideradas como reincidencia
para posteriores revisiones.
3.4 Al término de la revisión si el resultado de la validación es satisfactorio,

el Emisor cuenta con 5 días hábiles para notificar y programar la
recuperación de la información entregada al Árbitro Operativo, de lo
contrario al décimo día hábil esta es destruida.
Cuando el resultado de la validación es no satisfactorio, el Árbitro

Operativo conserva la información durante un cuatrimestre, al término
del plazo, el Emisor cuenta con 5 días hábiles para notificar y
programar la recuperación de la información entregada al Árbitro
Operativo, de lo contrario al décimo día hábil esta es destruida.
Capítulo XIII 6
4. Criterios de Aplicación de Responsabilidad Financiera:
4.1 Primer evento con resultado no satisfactorio:
Carta Reclamación TH Código de Razón 63

Se aplica al Emisor el importe Se aplica al Emisor el importe de
de la transacción más lo la transacción más lo establecido
establecido en el punto “a” de en el punto “c” de la
la penalización 32 del Capítulo penalización 32 del Capítulo V
V (Penas Convencionales por (Penas Convencionales por
Incumplimiento) del Manual Incumplimiento) del Manual
Operativo y se sujeta a un Operativo y se sujeta a un
proceso de monitoreo proceso de monitoreo
cuatrimestral durante 12 meses. cuatrimestral con una muestra de
50 transacciones durante 12
meses.
4.2 Segundo evento con resultado no satisfactorio:

Se aplica al Emisor el importe de la Se aplica al Emisor el importe de la
transacción más lo establecido en el transacción más lo establecido en
punto “b” de la penalización 32 del el punto “d” de la penalización 32
Capítulo V (Penas Convencionales del Capítulo V (Penas
por Incumplimiento) del Manual Convencionales por
Operativo y se sujeta a un proceso Incumplimiento) del Manual
de monitoreo trimestral Operativo y se sujeta a un proceso
de monitoreo trimestral con una
muestra de 50 transacciones
durante 12 meses.
4.3 Tercer evento con resultado no satisfactorio:

transacción más lo establecido en el transacción más lo establecido en
punto “d” de la penalización 32 del el punto “e” de la penalización 32
Capítulo V (Penas Convencionales del Capítulo V (Penas
por Incumplimiento) del Manual Convencionales por
Operativo y se sujeta a un proceso Incumplimiento) del Manual
de monitoreo trimestral durante 12 Operativo y se sujeta a un proceso
meses de monitoreo trimestral con una
muestra de 50 transacciones
durante 12 meses.
Capítulo XIII 7
4.4 Cuarto evento con resultado No Satisfactorio:

transacción más lo establecido en el transacción más lo establecido en el
punto “e” de la penalización 32 del punto “f” de la penalización 32 del
Capítulo V (Penas Convencionales Capítulo V (Penas Convencionales
por Incumplimiento) del Manual por Incumplimiento) del Manual
Operativo y se sujeta a un proceso Operativo y se sujeta a un proceso
de monitoreo trimestral durante 12 de monitoreo trimestral con una
meses muestra de 50 transacciones
durante 12 meses.
4.5 Quinto evento con resultado No Satisfactorio:

Se aplica al Emisor el importe de la
transacción más lo establecido en el
punto “f” de la penalización 32 del
Capítulo V (Penas Convencionales N/A
por Incumplimiento) del Manual
Operativo y se sujeta a un proceso
de monitoreo trimestral durante 12
meses
4.6 Cuando el incumplimiento continúe después de aplicar el punto “f” de

la penalización 32 se emite el resultado no satisfactorio, se notifica a
los participantes para que determine las acciones a seguir, una vez
que este las determine, el Árbitro Operativo hará la notificación
correspondiente.
4.7 El Emisor que cumpla satisfactoriamente su ciclo de monitoreo (12

meses) posteriores a un resultado no satisfactorio en el proceso de
Revisiones por Monitoreo o por Arbitraje a solicitud de un Adquirente,
automáticamente se considera con un historial sin antecedentes y se
incorporan al sorteo de validación cuatro meses después de haber
concluido el proceso de monitoreo, por lo que, en caso de un nuevo
incumplimiento se aplica el punto 4.1 de esta normativa.
4.8 El cobro de la penalización detallada en el presente Capítulo, se

efectuará a través del medio magnético vigente vía misceláneo
(transacción 10 código de razón 112), en un plazo no mayor a 6 días
hábiles a partir del día siguiente hábil de la fecha de recepción del
resultado de la revisión a favor, de no ser así, se rechaza y pierde el
derecho de cobro.
Capítulo XIII 8
La recuperación de las transacciones No satisfactorias detalladas en
el resultado de la revisión del Árbitro Operativo, se efectúa a través del
medio magnético vigente vía misceláneo (transacción 10 código de
razón 112 sin IVA) en un plazo no mayor a 10 días hábiles a partir del
día siguiente hábil de la fecha de recepción del resultado de la revisión
a favor. Para este misceláneo se debe adjuntar la documentación
soporte de los contracargos, de no ser así, se rechaza y pierde el
derecho de cobro.
5. Notificación de Resultados.
El Árbitro Operativo informa mensualmente a Emisores y Adquirentes a través

de su Cámara de Compensación, lo siguiente:
• Resultado de la Validación mensual por Institución, incluyendo

Programadas y cuando aplique, por Monitoreo o por solicitud de un
Adquirente.
Capítulo XIII 9
CAPITULO XIV
CONTINGENCIAS
Capítulo XIV
Contrato de Intercambio Doméstico
ESQUEMA OPERATIVO ESPECIAL EN APOYO A LAS AREAS AFECTADAS
POR DESASTRES NATURALES Y/O SITUACION DE CONTINGENCIA.
Definición:
Derivado de las afectaciones provocadas por los desastres naturales o alguna

contingencia que afecte la continuidad del negocio en Territorio Mexicano, se
establecen las siguientes medidas de contingencia.
Objetivo:
Apoyar al tarjetahabiente para que pueda disponer de recursos en el territorio

nacional; así como definir las acciones necesarias para la atención de
controversias en un evento de contingencia.
Estableciendo un esquema en el cual Emisores y Adquirentes puedan ofrecer apoyo

en casos de desastre natural (Huracanes, Terremotos, Temblores, inundaciones,
Incendios, etc.) y cuya ubicación geográfica haya sido considerada como zona de
desastre por la autoridad Gubernamental correspondiente.
Alcance:
1. Se crea el giro 6012 (Disposición de efectivo en ventanilla) categoría 20 para

esta operativa con una cuota de intercambio 0.
Queda a criterio de los Emisores parametrizar la aceptación y monto

permitido para ésta operativa.
Existen productos que por su naturaleza no permiten la disposición en

efectivo como son Valeras y Monederos Electrónicos que no participan en
ésta operativa.
2. Se establecen lineamientos para atención de documentación en el proceso

de controversias durante el periodo de contingencia
1. Características de ésta Operativa para Distribución de Efectivo
Éste plan se denomina oficialmente (Plan de Distribución de Efectivo en

Contingencia)
Capítulo XIV
Se activa el plan de contingencia de acuerdo a lo siguiente:
a) Una vez declarada la contingencia por parte de Protección Civil o la autoridad

competente, por ende, quede activado el Plan DN-III E, se activa el plan de
Distribución de efectivo de manera coordinada SHCP y Banco de México.
b) Las “TPVs para Contingencias” quedarán instaladas y puestas en operación

a través de la aplicación de Plan de Distribución de efectivo ABM-SHCP-
BANXICO-BANJERCITO en caso de desastres.
c) Restaurado el servicio eléctrico y comunicación en la(s) localidad(es)

afectada(s), se desactivará el servicio de Distribución de Efectivo.
2. Definición técnica que permite identificar una transacción con ésta

operativa:
• Afiliación: 7868059 (10 equipos / misma afiliación)

• Giro: 6012
• Id: 902
• TPV: Verifone wifi
• Aplicación: RETAIL
• Monto máximo x día (a criterio del Banco Emisor)
• Posteo al cliente: “Plan de Contingencia”
3. Aspectos de la transacción (Reglas de la operativa)
a) Este tipo de operativa se activa independientemente de la operación de

contingencia ante desastres naturales que operan las interredes.
b) En caso de que el emisor solicite una reclamación, este será atendido con el
Pagaré firmado por el Tarjetahabiente, si el Adquirente no está en
posibilidades de atender la aclaración con el pagare, ésta será atendida con
el LOG de Autorizaciones.
c) En caso de requerirse un límite de operación, este se fijará de acuerdo a lo

que solicite el adquirente en cada caso de contingencia, determinado por el
efectivo disponible y la población afectada.
Ejemplo:
a) Chip +NIP = $ 4,000 diarios

b) Chip-Banda y Banda = $ 2,000 diarios
Capítulo XIV
c) A petición del emisor, su Cámara podrá fijar un monto máximo por
tarjeta por día, no mayor a $ 7,000.00
Para estas transacciones el tarjetahabiente debe acreditarse con una

identificación para autenticar su personalidad.
Para la presentación, compensación y liquidación de estas transacciones, los

tiempos no cambian de acuerdo a lo establecido actualmente en el CID.
4. Cobertura Geográfica:
Las poblaciones, municipios o ciudades que se declaren como Zona de Desastre

por las Autoridades y cuyos Tarjetahabientes o Receptores de Pago se encuentren
imposibilitados debido a la situación de contingencia para atender en tiempo y forma
las obligaciones contractuales con su Institución.
5. Vigencia de la Contingencia:
Capítulo XIV
Se determina por los participantes, de acuerdo al tipo de contingencia.
6. Presentación de transacciones:
Presentación de facturación conforme a lo establecido en el Anexo 12

(Presentación de Facturación Extemporánea “Crédito”) y el Anexo 13
(Procedimiento para el Proceso de Transacciones de Débito en línea en
plazo de 9 a 30 días y Facturación Extemporánea).
7. Proceso de Controversias por declaración de zona de desastre.
a) El Emisor puede realizar de Buena Fé solicitudes de pagarés hasta 60 días

naturales adicionales al plazo establecido en el punto 3.8 del capítulo I de las
Reglas Operativas, para aclaraciones de Tarjetahabientes cuyo domicilio se
ubica dentro de la zona declarada en desastre, anexando copia del Estado
de Cuenta que lo demuestre.
b) El Adquirente puede representar de acuerdo a lo señalado en el Código de

Razón 79 (Copia u Original del pagare solicitado no recibido), opción “A”
condiciones para Representación “f” y opción “B” condiciones para la
Representación “g”.
c) En caso de que el Adquirente este imposibilitado para presentar copia del

pagaré requerido, puede presentar copia del Log de Autorizaciones
certificado y escrito libre que contenga la información del Receptor de Pagos
(Domicilio completo, teléfono y responsable del Receptor de Pagos) así como
la leyenda “Este receptor de pagos se encuentra localizado en Zona de
Desastre”.
d) Por acuerdo de las Instituciones, se establece que las transacciones que se

apeguen a este capítulo y realizadas a través de Lectura de Banda Magnética
PEM 90 u 80 o Lectura de chip PEM 05 o 07, son responsabilidad de los
Emisores.
e) En caso de que alguna de las transacciones del escenario anterior fuera

reclamada por el Tarjetahabiente ante la CONDUSEF (Comisión Nacional
para la Protección y Defensa de los Usuarios de Servicios Financieros), son
responsabilidad de los Adquirentes, por lo que el Emisor puede recuperar la
transacción mediante el envío de un misceláneo, transacción 10 código de
razón 112, para lo cual debe presentar el Oficio de la CONDUSEF.
f) Los Receptores de Pagos no pueden aplicar cargos por no show, en las

áreas declaradas como zona de desastre dentro del periodo de la
contingencia.
Capítulo XIV
8. Proceso de Controversias por acuerdo de Contingencia de los
Participantes.
a) El periodo de contingencias se define previo acuerdo de los participantes

y notificación al Comité de Tarjetas, el período de contingencia será el
establecido en la minuta y operativamente se ampliará hasta 30 días
naturales posteriores a la fecha en que se declare como concluida la
contingencia.
Este comunicado se debe hacer extensivo a los participantes del Contrato

de Intercambio Doméstico.
b) Únicamente para las solicitudes de documentos cuyo vencimiento se

ubique dentro del plazo de contingencia establecido, el Adquirente cuenta
con 30 días naturales adicionales mediante el uso del mecanismo de
representación del Código de Razón 79 (Copia u Original del pagare
solicitado no recibido), con el documento correspondiente a cada
operativa. Aclarando que este beneficio solo estará disponible durante el
período de contingencia.
c) Durante el período de contingencia, aplicarán condiciones especiales

para los códigos de razón 68 y 94, dichas condiciones sólo podrán ser
aplicables a las transacciones que se hayan realizado en fecha igual o
anterior al inicio del período de contingencia descrita en el inciso a) de
este numeral y cuyo uso del bien o servicio se encuentre dentro del
período de contingencia y hasta 30 días naturales posteriores al cierre de
esta.
Los Receptores de Pagos que durante el período de contingencia

apliquen cargos por no show, adicionalmente a lo ya establecido en el
inciso “i” (reservación garantizada) y “j” (cargo por no show) de las
condiciones de representación del código de razón 68, deberá cumplir
con lo siguiente:
• Acreditar que se envió una alternativa del receptor de pagos por

correo electrónico al tarjetahabiente incluyendo esta información:
• Alternativa(s) presentada(s) por el receptor de pagos

• Datos de la transacción (Fecha, Autorización, Importe)
Capítulo XIV
• Fecha propuesta por parte del receptor de pagos.
• Nombre del tarjetahabiente
• Número de tarjeta (Puede ser truncado)
• Dirección física o electrónica a la que se envió la información.
Código de razón 94 opción “b” (directo) y “f” (tradicional). Este caso solo
aplicará cuando el receptor de pagos cumpla con lo siguiente:
Acreditar que se envió una alternativa del receptor de pagos por correo
electrónico al tarjetahabiente incluyendo esta información:
• Alternativa(s) presentada(s) por el receptor de pagos

• Datos de la transacción (Fecha, Autorización, Importe)
• Nombre del tarjetahabiente
• Número de tarjeta (Puede ser truncado)
• Dirección física o electrónica a la que se envió la información.
9. Criterios por considerar de Receptores de Pago para la incapacidad de

prestar los servicios derivado de una contingencia.
Alcance:
Se consideran vulnerables ante una pandemia, los giros clasificados de

viajes y entretenimiento como son Hoteles, Agencias de viajes, Aerolíneas,
Renta de autos y Arrendadoras.
Con motivo de la suspensión de operaciones determinada por un Receptor

de Pagos que origine un riesgo operativo en la prestación de servicios o en
la atención de contracargos, el Adquirente debe notificar a los Emisores
sobre esta situación.
La obligación deja de ser del Adquirente cuando el Receptor de Pagos

compruebe que tuvo un acercamiento con el tarjetahabiente y acordó la
entrega de ofertas, ampliación de plazo o cualquier otro beneficio en favor
del tarjetahabiente. Estos deben de ser soportados para poder ser válidos.
Lo anterior, por ser una situación que excede la responsabilidad del

Adquirente. Cualquier aclaración que derive del punto anterior, el Emisor
deberá remitir al tarjetahabiente con el receptor de pagos para solventar
cualquier inconformidad al respecto, en caso de que el tarjetahabiente no
reciba respuesta, se le informa que podrá acudir ante la procuraduría federal
del Consumidor (PROFECO) para una solución.
Capítulo XIV
CAPITULO XV
OPERATIVA CHIP EMV FULL
Capítulo XV 1
Objetivo
Establecer las reglas operativas de Intercambio de transacciones EMV para la resolución

de controversias derivadas del intercambio.
Definiciones
Una transacción EMV es aquella donde se cumplen las siguientes características:
• Tarjeta emitida con EMV: es aquella cuyo Código de Servicio (Flag

Service Code) es igual a “A” 2xx (Internacionales) o 6xx (Nacionales).
• Punto de Venta con capacidad de lectura de EMV y mensaje con

Capacidad de la Terminal (Terminal Entry Capability) con valor 3, 5, 8
ó 9 de acuerdo a lo señalado en el Campo 63, Token C4 Sub-campo 11
(referente al campo 60 VISA o campo 61 Mastercard) y Sub-campo 12
del Documento de Especificación Técnica de Indicadores de este
manual.
• Mensaje de solicitud de autorización con Modo de Entrada (PEM -

POS Entry Mode) en el campo 22 valores 05 (Chip EMV), 07
(Contactless EMV) al Banco Emisor.
Enviar el Token B2, B3 y B4 en la solicitud de autorización de acuerdo al

documento de Especificación Técnica de Indicadores en línea campo 63 Anexo 4I.
Identificación de Fallback
• Mensaje de solicitud de autorización con POS Entry mode 80 al Banco

Emisor.
• Tarjeta emitida con CHIP, código de servicio “A” 2xx (Internacionales) o

6xx (Nacionales).
• Mensaje con terminal entry capability con valor 3, 5, 8 ó 9 (referente al

campo 60 VISA y campo 61 Mastercard).
Capítulo XV 2
Alcance:
Las transacciones realizadas bajo la Operativa de EMV, son reguladas por el presente
capítulo en lo particular, y de manera general en los demás capítulos de este Manual
Operativo.
Para las transacciones EMV es mandatorio para el Adquirente enviar el Token B2, B3 y B4
en la solicitud de autorización de acuerdo al documento de Especificación Técnica
Indicadores en línea campo 63.
El cambio de responsabilidad en la operativa de EMV solo aplica para operaciones

realizadas en el Intercambio Doméstico y Bines registrados por las Instituciones en el
Anexo 1 de este manual operativo.
El cambio de responsabilidad aplica cuando exista reclamación del tarjetahabiente y se

divide en tres esquemas:
Esquema 1. Para transacciones dictaminadas como fraude por skimming cuando el

adquirente no cuenta con la capacidad de lectura de Chip. Si el Emisor no cuenta
con Chip no puede aplicar el cambio de responsabilidad
Los campos PEM, Flag Service Code y Terminal Entry Capability son mandatorios en el Log
de Autorizaciones y Archivo de Intercambio.
Esquema 2. Cuando el adquirente:
o No envía en el mensaje de autorización (en línea) los Tokens B2, subcampos

3, 4, 6, 7, 8, 9, 10, 11, 12, 13, 14 y 16 correspondientes al ARQC y B4
subcampo 5 cuando aplique
Esquema 3. Cuando el adquirente no soporta NIP Offline:
o Para transacciones donde el terminal (TPV) no soporta NIP Offline

o Cuando un adquirente realice una operación de PIN Bypass y no envíe los
indicadores en la tabla de TVR (Tag 95)
o Cuando el emisor autorice una transacción la cual fue identificada por la
terminal como PIN Bypass
o Transacciones dictaminadas como fraude por robo/extravío/tarjeta no entregada
Capítulo XV 3
1. Condiciones para cambio de responsabilidad por skimming (esquema 1)
a) Valores del PEM (Pos Entry Mode):
Corresponde al campo P-22 ISO o en el Token B4 subcampo 1 del mensaje de

solicitud de una autorización a un Emisor
Valor 05 Solicitud de autorización con dispositivo con capacidad de lectura Chip y

tarjeta con Chip
Valor 80 Solicitud de autorización con dispositivo con capacidad de lectura Chip y

tarjeta Chip con error de lectura del Chip
b) Valores del Terminal Entry Capability:
Corresponde al Campo 63 Token C4 subcampo 11
Valor 3 Lector Contactless Chip

Valor 5 Lector de Banda y Lector de Chip
Valor 8 Lector de Banda, Entrada manual y Lector de Chip
Valor 9 Lector de Chip EMV
c) Valores del Flag Service Code:
El valor del Flag Service Code representa el primer digito del Código de servicio de
las tarjetas (2xx o 6xx), los valores asignados son:
Bandera valor A = Tarjeta de Chip EMV.
Capítulo XV 4
d) Fallback
Si se desliza la banda de una tarjeta EMV se indica en la pantalla del dispositivo

utilizar el Chip, en caso de que éste no pueda ser leído en dos intentos
consecutivos, entonces se permite enviar en una tercera transacción con lectura de
banda magnética (Fallback) al Emisor.
El Emisor detecta estas transacciones por el valor 80 en el PEM (Pos Entry Mode) y
decide si autoriza o rechaza la transacción.
El mensaje que despliega la Terminal cuando la transacción sea rechazada por el

Emisor, es el código ISO 12 con el mensaje "Transacción Inválida", si el rechazo es
por causa diferente se aplican los códigos vigentes certificados en los Log´s de
Autorizaciones.
Todas las transacciones electrónicas con lectura de banda magnética (Fallback) se

consideran como transacciones electrónicas y son responsabilidad del Emisor.
El Emisor es responsable de otorgar o rechazar la autorización de las transacciones

que reciba con PEM (Pos Entry Mode) 80 Fallback.
e) Combinación de Valores CHIP EMV
La siguiente tabla muestra la única combinación de valores de una transacción en

el esquema Chip, cualquier otra combinación de valores con una tarjeta Chip (Flag
Service Code “A ó 2xx, 6xx”) aplica para el cambio de responsabilidad por
skimming, solo en los casos donde el tarjetahabiente reclame no haber efectuado
la transacción y la institución Emisora lo dictamine como fraude y reporte como
skimming ante su titular de marca.
VALORES CHIP
PEM TERMINAL FLAG RESPONSABLE
ENTRY SERVICE CONCEPTO
CAPABILITY CODE
EMV EMISOR
05
3, 5, 8 o 9 A
FALLBACK EMISOR
80
3, 5, 8 o 9 A
07 3 A CONTACTLESS EMV EMISOR
Capítulo XV 5
Los Adquirentes deben enviar los tokens B2, B3 y B4 en todas las transacciones
Chip EMV de acuerdo a lo señalado en el Documento de Especificación Técnica de
Indicadores en Línea Campo 63, en caso de existir problemas de interoperabilidad
se sujetarán a lo establecido en Capítulo XVIII (Laboratorio de Pruebas de
Interoperabilidad).
2.- Condiciones para Cambio de Responsabilidad de ARQC (esquema 2)
De acuerdo a lo establecido en el Anexo 46“Cálculo y Validación de ARQC Transacciones

POS (TPV’s e Interredes)” del apartado IV del manual operativo del CID
Campo 63, Token B4 subcampo 8 (posición 19) - ARQC-VRFY: con uno de los siguientes
valores:
Descripción Valor (Token B4 Sc 8)

No se validó (0 / Nulo / “espacio”) 0
Falló la validación en el switch 1
Fue validado exitosamente en el switch 2
Falló la validación en el autorizador 3

Fue validado exitosamente en el
4
autorizador
2.1 Cambio de responsabilidad con CHIP y validación de ARQC
Adquirente Emisor Valores de

ARQC Emisor
envía Valida Respuesta en el Responsabilidad
Válido Autoriza
ARQC ARQC Token B4 SC8
No N/A N/A Si Valor 0 Adquirente
Envía
N/A N/A Si Valor 0 Adquirente
Ceros
Si No N/A Si Valor 0 Emisor
Si Si No Si Valor 1 o 3 Emisor
Si Si Si Si Valor 2 o 4 Emisor
Nulo, espacio o
No No N/A Si Emisor
cualquier valor
Capítulo XV 6
diferente a 0, 1 o 3
Los Emisores en su autorizador deben rechazar las transacciones que contengan ARQC y
hayan sido calificadas con valor 0, 1 o 3 en el token B4 sub-campo 8, ya que si autorizan
asumen la responsabilidad y no pueden utilizar ningún código de razón para contracargar.
Cuando se trate de transacciones donde el número de cuenta es tokenizado, el Token B2

subcampo 5 se debe validar en el LOG adquirente.
En caso de que el Adquirente envíe valores de ARQC incorrectos, el Emisor debe iniciar
una incidencia integrando la documentación soporte mediante la aplicación de
incidencias, el Adquirente tiene 10 días hábiles para corregir la incidencia o entregar un
plan de trabajo.
De no corregir o entregar su plan de trabajo en el plazo señalado entra el esquema de

penalización 32
No aplica cambio de responsabilidad cuando exista PEM 80, derivado de que las
transacciones de Fallback son responsabilidad del Emisor.
Cuando una transacción PEM=05 es enviada por un adquirente FULL EMV, el emisor debe
generar y responder ARPC.
3.- Cambio de Responsabilidad por CHIP+NIP (esquema 3)
Definiciones
El envío de una transacción con NIP debe cumplir con las características de una
transacción CHIP:
• Transacción:
o Mensaje de solicitud de autorización con Modo de Entrada
(PEM - POS Entry Mode) en el campo 22 valores 05 (Chip
EMV) o 07 (Contactless EMV) al Banco Emisor.
o Método de identificación del tarjetahabiente de acuerdo a
lo señalado en el Campo 63, Token C4 subcampo 12 con
valor 2 PIN del Documento de Especificación Técnica de
Indicadores. Cuando exista discrepancia entre la
información de este campo y la validación de NIP de los
tokens Bs, se considera como válida esta última.
o Enviar los Token B2, B3 y B4 en la solicitud de autorización
de acuerdo al documento de Especificación Técnica
Indicadores.
Capítulo XV 7
o En la respuesta de solicitud de autorización enviar el Token
B5 y cuando el emisor envíe scripts el Token B6
o Resultado del método de autenticación con valores 01, 02,

03, 04, 05, 41, 42, 43, 44, 45 en sus primeras 2 posiciones
(Byte 1), correspondientes al método de autenticación
realizado, de acuerdo a lo señalado en el Campo 63, Token
B3 subcampo 8 CVM Results, en donde:
§ 01 y 41 son PIN offline en claro.
§ 02 y 42 son PIN online cifrado.
§ 03 y 43 son PIN offline en claro y firma autógrafa.
§ 04 y 44 son PIN offline cifrado.
§ 05 y 45 son PIN offline cifrado y firma autógrafa.
Otros valores que pueden presentarse, pero que no
corresponden al manejo de PIN son:
§ 40 y 00 – Falló la validación del tarjetahabiente.
§ 1E y 5E – Firma autógrafa en papel (ticket)
§ 1F y 5F – No se requirió método de autenticación.
§ 06 a 1D y 46 a 5D – Reservados para uso futuro.
o Resultado del método de autenticación con valor 02
(exitoso) en sus últimas 2 posiciones (Byte3),
correspondientes al resultado de autenticación, de
acuerdo a lo señalado en el Campo 63, Token B3 subcampo
8 CVM Results. Este campo corresponde al tercer byte del
CVM Results
Otros valores que pueden presentarse son:
§ 00 – Desconocido (por ejemplo firma).
§ 01 – Fallido.
3.1 Alcance:
Para las transacciones EMV con NIP es mandatorio para el Adquirente enviar el Token B2,
B3 y B4 en la solicitud de autorización de acuerdo al documento de Especificación Técnica
Indicadores en línea campo 63
3.2 Condiciones para Cambio de Responsabilidad de NIP
Capítulo XV 8
El cambio de responsabilidad por No soportar el ingreso de NIP solo aplica cuando la
tarjeta fue reportada a las marcas como robo/extravío o tarjeta no entregada y se
cumplan las condiciones señaladas en la siguiente tabla:
POS
Entry
POS Entry Resultado del método
Mode
Mode de autenticación Emisor
(campo Token B4 subcampo 8 Responsabilidad
(Campo 22- (Token B3 subcampo 8 Autoriza
22-
posición 3) byte 1)
posición
1 y 2)
Valor Firma (Papel) o No se
05 / 07 Si Valor 2 o 4 Adquirente
distinto a 1 requirió CVM
En el caso de una operativa Contactless solo aplica el NIP Online
4.- Resolución de Controversias.
4.1 Cambio de Responsabilidad por Skimming
• La regla 4.1.3 del Capítulo I del Apartado IV Manual Operativo POS, no aplica para
las transacciones EMV cuando se cumplen las condiciones para el cambio de
responsabilidad.
• Es responsabilidad del Emisor que previo a la presentación del contracargo por

Código de Razón 63 opciones “A” y “B” debe cancelar y/o bloquear la tarjeta en su
sistema, así como registrar el Número de cuenta ante su Titular de Marca por
fraude dictaminado como Skimming.
El Emisor debe verificar que previo a la generación del contracargo por Código de Razón
63 opciones “A” y “B”, el registro de la transacción este confirmado por las marcas, ya que
posterior a la realización del Contracargo la Institución no debe modificar o eliminar el
registro ante la marca.
Si el Emisor elimina o modifica el registro de fraude por skimming ante la marca posterior
a la realización del Contracargo, debe regresar el monto de la transacción contracargada
al Adquirente.
En caso de no devolver el monto de la transacción previo a que sea detectado por el

Adquirente o a la solicitud de validación de transacciones realizada por el Árbitro
Operativo, el Emisor se hace acreedor a la penalización 32 del Capítulo V (Penas
Convencionales por Incumplimiento), de acuerdo a lo señalado en el punto 4 de este
capítulo.
Capítulo XV 9
Cuando se realice contracargo por código de razón 63 (Chip) Opción “A” y “B” , se debe
adjuntar al Exhibit Anexo 8, cualquiera de las opciones siguientes:
a) Impresión de la pantalla de registro del sistema de fraude de las Marcas de

acuerdo al Anexo 45 (Reporte de Fraude) con la siguiente información:
• Fecha de registro de fraude por skimming ante su titular de marca la cual

debe ser anterior o igual a la fecha del contracargo.
• Clave de tipo de fraude 04 o 4.
b) Carta del área de Prevención de Fraudes certificando skimming conteniendo la

siguiente información:
• Leyenda: “El Área de Fraudes de la Instirución Emisora”, dictamina que las

transacciones corresponden a fraude por skimming
• Importe
• Fecha de transacción
• Firma del responsable de acuerdo al Anexo “31 y 31A” (Funcionarios del
Área de Prevención de Fraudes facultados para dictaminar skimming), de
no contar con funcionarios registrados en el Anexo 31 y 31A, no puede
hacer uso de esta opción.
4.2 Resolución de Controversias por CHIP+NIP.
La atención de comprobantes con operativa CHIP+NIP puede atenderse con el LOG de

autorizaciones certificado.
• Es responsabilidad del Emisor que previo a la presentación del contracargo por

Código de Razón 63 opción “D” debe cancelar y/o bloquear la tarjeta en su
sistema, así como registrar el Número de cuenta ante su Titular de Marca por
fraude dictaminado como tarjeta robada, extraviada o No entregada.
El Emisor debe verificar que previo a la generación del contracargo por Código de Razón
63 opcion “D”, el registro de fraude de la transacción este confirmado por las marcas, ya
Capítulo XV 10
que posterior a la realización del Contracargo la Institución no debe modificar o eliminar el
registro ante la marca (Safe, TC40 o SRF).
Si el Emisor elimina o modifica el registro de fraude por robo, extravío o tarjeta No

entregada ante la marca posterior a la realización del Contracargo, debe regresar el monto
de la transacción contracargada al Adquirente.
En caso de no devolver el monto de la transacción previo a que sea detectado por el

Adquirente o a la solicitud de validación de transacciones realizada por el Árbitro
Operativo, el Emisor se hace acreedor a la penalización 32 del Capítulo V (Penas
Convencionales por Incumplimiento), de acuerdo a lo señalado en el punto 7 de este
capítulo.
Cuando se realice contracargo por código de razón 63 (Chip) Opción “D” , se debe adjuntar
al Exhibit Anexo 8:
Impresión de la pantalla de registro del sistema de fraude de las Marcas de acuerdo al

Anexo 45 (Reporte de Fraude) con la siguiente información:
• Fecha de registro de fraude por robo, extravío o tarjeta No entregada ante

su titular de marca la cual debe ser anterior o igual a la fecha del
contracargo.
• Clave de tipo de fraude de acuerdo a marcas:
Para Visa / MasterCard / Carnet
00 tarjeta perdida
01 tarjeta robada
02 tarjeta no recibida
4.2.1 Transacciones reclamadas con presencia de CHIP+NIP
Cuando el tarjetahabiente reclame y acepte haber participado en una o más transacciones

con tarjetas CHIP+NIP, y se aplique el cargo de la transacción o transacciones en su
estado de cuenta, el emisor puede contracargar por código de razón 57 (Chip) Opción “E”
El adquirente debe proporcionar en la representación el LOG de autorizaciones certificado

(anexo 18) de la transacción donde fue aplicado el reverso.
Capítulo XV 11
4.3 Cambio de Responsabilidad por ARQC
Se puede utilizar la opción C del Código de Razón 63 cuando se cumplan las siguientes
condiciones:
o Un Adquirente envía ceros, nulo o espacios en el Token B2, subcampo 5 (ARQC)
o El log de autorizaciones certificado del Emisor debe contener valor 0, en el token

B4 subcampo 8 (ARQC VRFY), confirmando que el Emisor está validando el Token
B2, subcampo 5 (ARQC).
4.3.1 Representación
El Adquirente puede representar un código de razón 63 opción “C” cuando:
a) Presente Log de Autorizaciones Certificado (Anexo 18) demostrando que SI envió el ARQC
en el Token B2, subcampo 5.
5.- Campos mandatorios de la operativa CHIP + NIP en el Log de Autorizaciones

Certificado (Anexo 18)
Campo Valores posibles

- Falló CVM
- Verificación del PIN en texto plano realizada
por el
chip de la tarjeta
- Verificación en línea del PIN cifrado
- Verificación del PIN en texto plano realizada
por el
chip de la tarjeta y firma (papel)
CVMR - Método Utilizado (B3 sub8 - Byte 1) - Verificación del PIN cifrado realizada por el
chip de
la tarjeta
- Verificación del PIN cifrado realizada por el
chip de
la tarjeta y firma (papel)
- Firma (papel)
- No se requirió CV
CVMR - Resultado (B3 sub8 - Byte 3) Desconocido / Fallido / Exitoso

TVR - Verificación del tarjetahabiente (B2 sub4 - Byte 3) Exitoso / Fallido
CVR - Verificación del PIN Offline (B2 sub16 - Byte 2) Si / No
CVR - Resultado de la Verificación del PIN Offline (B2 sub16 -
Exitoso / Fallido
Byte 2)
El mapeo de los valores contenidos en el LOG de autorización se hace referencia al Anexo

24 “Documento Técnico para la Construcción y Validación de PIN Offline”.
Capítulo XV 12
6. Arbitraje
Cuándo el Emisor o el Adquirente no estén de acuerdo con los valores del ARQC
presentados por su contraparte, pueden enviar esta transacción directamente a arbitraje
sin concluir el ciclo de aclaraciones y debe adjuntar la documentación intercambiada.
7. Penalizaciones
Primer Evento Segundo Evento

transacción más lo señalado en el transacción más lo señalado en el
punto “c” de la penalización 32 del punto “d” de la penalización 32 del
capítulo V (Penas Convencionales por capítulo V (Penas Convencionales por
Incumplimiento) y se sujeta a un Incumplimiento)
proceso de monitoreo cuatrimestral y se sujeta a un proceso de monitoreo
con una muestra de 50 transacciones trimestral con una muestra de 50
durante 12 meses. transacciones durante 12 meses.
Tercer Evento Cuarto Evento

transacción más lo señalado en el transacción más lo señalado en el
punto “e” de la penalización 32 del punto “f” de la penalización 32 del
capítulo V (Penas Convencionales por capítulo V (Penas Convencionales por
Incumplimiento) y se sujeta a un Incumplimiento) y se sujeta a un
proceso de monitoreo trimestral con proceso de monitoreo trimestral con
una muestra de 50 transacciones una muestra de 50 transacciones
durante 12 meses. durante 12 meses.
Cuando el incumplimiento continue despues de aplicar el punto “f” (Cuarto evento) de

la penalización 32, se notifica a Emisores y Adquirentes para que determinen las
acciones a seguir, una vez que estos las determinen, el Arbitro Operativo efectúa la
notificación a la Institución correspondiente.
Capítulo XV 13
CAPÍTULO XVI
PROMOCIONES
Capítulo XVI 1

PROMOCIONES
(PAGOS DIFERIDOS)
OBJETIVO
Contar con un esquema de operación que permita a las Instituciones ofrecer a sus
Receptores de Pagos, operar promociones mediante Pagos Diferidos en diferentes
modalidades y plazos con Tarjeta de Crédito.
Optimizar el uso de números de afiliación primarias, con la utilización del token Q6,
establecido en el Anexo 4I Especificación Técnica, Indicadores en Proceso en Línea
Campo 63.
ALCANCE
Las transacciones de este capítulo, son reguladas por el presente instrumento en lo
particular y de manera general por el Manual Operativo.
Los Receptores de Pagos que hayan realizado contrato con los Emisores avalando la
promoción mediante Pagos Diferidos a sus Tarjetas de Crédito.
CONDICIONES
Generales:
Ø El Receptor de Pagos debe contar con Software actualizado proporcionado por
la Institución Adquirente, que permite enviar en sus operaciones electrónicas
los valores acordados del campo 63 token Q6 para el envío de la mensajería al
Emisor.
Ø El Emisor debe contar con capacidad de recibir la solicitud de autorización con
el token Q6 e interpretarlo para su autorización o rechazo.
Ø Los Adquirentes deben estar preparados para el envío de la información con
las características de los Pagos Diferidos de acuerdo a la promoción en el
archivo de intercambio.
Ø El adquirente debe enviar los valores transmitidos en línea en el archivo de
intercambio en los campos 39, 40 y 41.
Ø El Emisor debe aplicar el cargo a su tarjetahabiente, en el plazo señalado en
los campos mencionados en el punto anterior.
Afiliación de Receptores de Pagos para operar promociones

Cada Emisor debe contar con un contrato para el manejo de promociones mediante
Pagos Diferidos entre el Receptor de Pagos y el Emisor de la Tarjeta de Crédito, que
contenga los siguientes puntos:
Ø Utilizar la afiliación principal del Receptor de Pagos para sus promociones.
Ø En los casos en que el Receptor de Pagos genere una devolución, ni el Emisor
ni el Adquirente están obligados a enviar ó recibir el indicador de promociones
en el proceso batch.
El esquema de Pagos Diferidos no aplica para transacciones con pagaré planchado (no
Electrónica).
Capítulo XVI 2

1.- RESPONSABILIDADES
Responsabilidades del Emisor:
El Emisor controla la vigencia de las promociones por Receptores de Pagos, condiciones

y los BINES que participan.
Recibir el token Q6 interpretarlo y autorizar o rechazar la transacción.
Dar respuesta a la solicitud de autorización de transacciones procesadas
electrónicamente para Pagos Diferidos en la modalidad y plazos que solicita el Receptor
de Pagos, los cuales deben corresponder a los valores acordados por las Instituciones.
Utilizar el código de respuesta 57 ISO 8583 “Pago Diferido no permitido” y código de

respuesta 89 ISO 8583 “Pago diferido Parámetro inválido” para la respuesta de rechazo
de la autorización de Pagos Diferidos, cuando la transacción no sea aceptada, por:
Ø Fuera de vigencia de la promoción contratada.

Ø BIN no está autorizado para participar en Pagos Diferidos.
Ø Plazo de la promoción excede al convenido con el Receptor de Pagos.
Ø No existe convenio con el Receptor de Pagos.
Atender las aclaraciones que presenten los Tarjetahabientes.

El Emisor es el responsable de realizar con sus propios medios, el cobro de gastos y
aclaraciones asociadas al proceso de Pagos Diferidos contratado con el Receptor de
Pagos.
Responsabilidades del Adquirente:

Ningún adquirente puede negociar la Operativa de Pagos Diferidos en representación de
otros Emisores sin previo acuerdo con estos.
Desarrollar el software en sus TPV / ECR’s e Interredes para que permita enviar en la
solicitud de autorización, los valores del token Q6 con los 3 sub-campos que contiene.
Enviar en el archivo de intercambio los valores con los que autorizó el Emisor la operación
y que estos correspondan a los valores acordados en el documento de Especificación
Técnica, Indicadores en Proceso en Línea Campo 63. Si existe discrepancia aplica el
rechazo de sintaxis correspondiente.
Los Adquirentes deben capacitar a los Receptores de Pagos para que no envíen
transacciones diferidas sin un contrato previo con el Emisor.
Capítulo XVI 3

2.- PROCESO ON LINE
Las promociones de pagos Diferidos a través de los Receptores de Pagos deben cumplir
las especificaciones del token Q6 incluyendo los sub-campos siguientes:
Token Q6
Sub campo Nombre Ini Fin Valores válidos
1 Diferimiento 11 12 Número de Meses en el que el pago no será
de Cargos exigible (compre hoy y pague después),
justificado con ceros a la izquierda
2 Número de 13 14 Número de meses en que se va a dividir los
pagos pagos (con o sin intereses) justificado con
ceros a la izquierda
3 Tipo de plan 15 16 Tipo de plan a utilizarse
de promoción 00.- Sin promoción
03.- Sin intereses al tarjetahabiente
05.- Con Intereses para el tarjetahabiente
07.- Compre hoy y Pague después (Skip a
Payment Puro).
3.- INTERCAMBIO
En el archivo de Intercambio, las transacciones de promociones con Pagos

Diferidos deben contener los valores con que se dio la autorización.
El layout del archivo de intercambio contiene los siguientes datos:
a) Campo 39 posición 176 – 177 “Diferimiento de Promociones”

Ø Número de meses en el que el pago no será exigido
b) Campo 40 posición 178 – 179 “Número de pagos Promociones”

Ø Número de meses
c) Campo 41 posición 180 – 181 “Tipo de plan Promociones”

Ø Los valores 00, 03, 05, 07.
4.- ACLARACIONES
Las aclaraciones generadas por el uso de la Operativa de Pagos Diferidos son atendidas
directamente por el Emisor con el Receptor de Pagos considerando la siguiente regla:
En las transacciones que en el pagaré presenten una promoción de Pagos Diferidos y el

cargo al Tarjetahabiente se registre como revolvente o con tipo de promoción diferente, el
Emisor debe honrar la transacción autorizada siempre y cuando haya recibido en línea los
Capítulo XVI 4

valores de Q6 y que el Receptor de Pagos tenga contrato vigente al momento de la
transacción, con el Emisor.
Capítulo XVI 5

CAPÍTULO XVII
Administración de PCI DSS
Capítulo XVII
1. ANTECEDENTES.
En apego a los estándares internacionales, las Instituciones de medios de pago en México comparten
con los Titulares de Marca el interés por reforzar los mecanismos que reduzcan los potenciales escenarios
de fraude, protegiendo los datos sensibles de las transacciones.
Por lo anterior, en el 2011 fueron creadas las Reglas de Seguridad de la Información para México “RSIM”.
A partir de 2017 se incorporaron los controles de verificación de las versiones PCI-DSS, PA-DSS vigentes.
2. OBJETIVO
Establecer los procesos y procedimientos para la administración y seguimiento al cumplimiento por parte
de los participantes en la red de medios de pago, para la ejecución de la verificación de los estándares
en materia de seguridad de la información, tales como certificaciones de normas de seguridad de la
industria de tarjetas, incluyendo entre otras, la norma de seguridad de datos (PCI-DSS), la norma de
seguridad de datos para las aplicaciones de pago (PA-DSS) y los requisitos de seguridad. En lo sucesivo
denominado PCI-DSS o PCI.
Lo cual coadyuva en la protección de la información de tarjetahabientes, tarjetas y sus transacciones

contenidas en medios electrónicos para mitigar el riesgo.
Referir al cumplimiento de la Circular Única de Bancos para la entrega del Plan Director de Seguridad
(artículo 316 Bis 8).
3. ALCANCE.
Asegurar que todos los participantes en la red de medios de pago que procesen, transmiten o almacenen
una transacción, de acuerdo a la segmentación anual, cuenten con la revisión y en su caso certificación
PCI-DSS o PA-DSS vigente para operar los pagos con tarjeta en México.
Si un receptor de pagos, agregador, integrador, motor de pago, sub-afiliado o cualquier otro participante
de la Red de Medios de pago no cumple con la línea de tiempo para realizar su verificación, podrá ser
sujeto a sanciones establecidas en este capítulo, aplicadas por el adquirente o el propio administrador de
la base única.
La certificación PCI-DSS o PA-DSS, no exime a los participantes en la red de medios de pago del proceso
de controversias, conforme al Acuerdo Interinstitucional establecido en el Capítulo II de este Manual
Operativo.
4. LINEAMIENTOS DE LA CERTIFICACIÓN.
En la Red de pagos con tarjeta se consideran como datos sensibles:
Tarjeta:
• PIN (Personal Identification Number) o NIP
• Contenido completo de la banda magnética (Track 1 y 2).
• CVV2, CVC2 o CID y 4DBC.
• Fecha de vencimiento.
Tarjetahabiente:
Cuando está en conjunto el número de cuenta o números de tarjeta, con:
• El nombre
• Direcciones de correo electrónico
• Límites de crédito
• Saldos
• Identificaciones de usuarios
Capítulo XVII
• Información de autenticación.
•
4.1) Entidades participantes en el proceso de certificación PCI.
1
Entidad Acrónimo
Institución Adquirente IA
Entidad Certificadora EC
Cámara de Compensación CC
Entidad Administradora EA
Árbitro Operativo AO
Receptor de Pagos RP
Sub-afiliado (RP de un SA
Agregador)
Agregador/Integrador o Motor de AG
pago
4.2) Proceso general de certificación:
En caso de que sea aplicable, la certificación de los comercios debe ser considerada dentro del Plan
Director que el participante presente a la autoridad.
1
En adelante, se puede mencionar a las diferentes entidades participantes por su nombre o por su acrónimo
Capítulo XVII
5. SEGMENTACIÓN.
5.1 Segmentación Receptores de Pago Afiliados
Las empresas especializadas, con el consentimiento de los adquirentes entregan dentro de los primeros
10 días naturales de cada mes a la Entidad Administradora el total de transacciones del período del mes
anterior correspondiente, (identificando el archivo por cada adquirente del cual se entregue la información
transaccional). En caso de que el adquirente no otorgue el consentimiento, éste deberá entregar la
información directamente a la Entidad Administradora, en el plazo establecido.
La Entidad Administradora deberá enviar un reporte de forma mensual al Adquirente respecto de los
cambios de responsable de PCI DSS de sus receptores de pagos.
A continuación, se describen las características del archivo de transacciones que deberá de generar la
Cámara de Compensación:
BASE DE TRANSACCIONES
Adquirente Número entero Número de Adquirente, de
acuerdo al catálogo de
Instituciones del capítulo XII del
CID
Afiliación Número entero, Afiliación a la cual corresponden
máximo 7 las transacciones
posiciones
Operativa Número entero, Valor del token Q2 (indicador del
máximo 2 tipo de operativa), de acuerdo al
posiciones anexo 4I Documento Técnico de
Indicadores del CID. No pueden
existir afiliaciones con más de
una operativa.
Transacciones Número entero Total de transacciones, una sola
cifra por cada operativa que
resulte de sumar las
transacciones aprobadas:
Nacionales e internacionales con
tarjeta de débito y crédito,
incluyendo tarjetas privadas,
transacciones propias y de otros
emisores, adquiridas por sus
Instituciones, que correspondan
al indicador del punto anterior con
la entrega mensual.
La Entidad Administradora debe consolidar la información de transacciones para ejecutar la segmentación

considerando las transacciones del año inmediato anterior a la fecha de ejecución, a fin de determinar los
Receptores de Pagos que califican para los segmentos que se describen a continuación:
Capítulo XVII
Self-Assessment
PCI con Report
Questionnaire ( en
Of Compliance Gap Análisis
lo sucesivo PCI L4
(“ROC”) y Nivel I de PCI
“SAQ”) en Nivel II
reportes
PCI
Certificación
Certificación
Tier IV
Certificación Certificación Tier Tier IV
Certificación TARJETA
Tier I II TARJETA NO
PRESENTE
PRESENTE
20,000 o más
Trxs
1,000,000 a
6,000,000 2,000,000 E-commerce /
1,999,999
a a MoTo/ Cargo
Tarjeta
14,999,999 5,999,999 Periódico
15,000,000 o más presente
Trxs anuales
independientemen
Transacciones
te del titular de Trxs anuales
marca, producto y independiente Trxs anuales
Trxs anuales Trxs anuales
adquirente mente del titular independiente
independienteme independientement
de marca, mente del titular
nte del titular de e del titular de
producto y de marca,
marca, producto y marca, producto y
adquirente. producto y
adquirente adquirente
adquirente
En sitio Sí Sí Remoto Remoto Remoto

4 escaneos
trimestrales de
Sí Sí Sí Sí Sí
vulnerabilidad
externos
Al menos dos pruebas
de penetración
Sí Sí No No No
anuales, una interna y
otra externa
Consideraciones especiales de la segmentación:
• La afiliación debe ser la de uso nacional, no utilizar el ID internacional
• Un proceso unitario de certificación puede abarcar una o más afiliaciones, de acuerdo a

su segmento; las cuales generalmente corresponden a un conjunto denominado Grupo-
Cadena en la Base Única de Receptores de Pagos.
• Los Agregadores deben registrarse en la Base Única y certificarse en PCI DSS como
Service Provider.
• Un Receptor de Pagos que es verificado satisfactoriamente de acuerdo a su volumen

transaccional o cambio de operativa no califica, en la siguiente segmentación y no se le
solicita la certificación.
• Para Receptores de Pagos compartidos el responsable es la Institución Adquirente que

tenga el mayor número de transacciones de acuerdo al segmento y operativa por la que
fue calificado el Receptor de Pagos.
• Cuando la Institución Adquirente mayoritaria en el total de transacciones sea diferente de

la Institución Adquirente responsable por la operativa del Receptor de Pagos, la Institución
Adquirente mayoritaria debe acompañar a la Institución Adquirente responsable en las
gestiones con el Receptor de Pagos, cuando así se requiera.
Capítulo XVII
Para Receptores de Pagos que se encuentren en Remediación y ya no cumplan con ninguno de los
criterios de Segmentación, el Receptor de Pagos debe concluir su remediación hasta obtener una
certificación satisfactoria.
5.2 Segmentación para Receptores de pago sub-afiliados
Cada adquirente deberá entregar dentro de los primeros 10 días naturales de cada mes a la Entidad
Administradora el total de transacciones con tarjeta presente y no presente, por sub-afiliado sin giro
natural con su identificador propio de cada sub-afiliado, realizadas el mes anterior correspondiente. Los
sub-afiliados con giro natural no deberán ser incluidos en este reporte ya que estos últimos si se
encuentran integrados en la base de segmentación que entregan las cámaras a la entidad administradora
como parte de la segmentación anual.
A continuación, se describen las características del archivo de transacciones que deberá de generar la
Cámara de Compensación:
BASE DE SUB-AFILIADOS CON TASA AGREGADOR

Adquirente Número entero Número de Adquirente, de
acuerdo al catálogo de
Instituciones del capítulo XII del
CID
Agregador Número entero - De acuerdo al catálogo de
valor 7 Instituciones del capítulo XII del
CID
Identificador del sub- Número entero, Identificador a la cual
afiliado máximo 7 corresponden las transacciones
posiciones
Operativa Tarjeta presente / no Identificar transacciones con
presente tarjeta presente y con no
presente.
Transacciones Número entero Total de transacciones, una sola
cifra por cada operativa que
la entrega mensual.
Monto Anual Número Monto total de transacciones, una
Transacciones Fraccionado sola cifra por cada operativa que
la entrega mensual.
Capítulo XVII
La Entidad Administradora debe consolidar la información de transacciones para ejecutar la segmentación
considerando las transacciones del año inmediato anterior a la fecha de ejecución, a fin de determinar los
Receptores de Pago sub-afiliados que califican para el segmento L4:
PCI L4
Certificación Tier IV Certificación Tier IV
Sub-afiliados con Tasa Agregador Sub-afiliados con Tasa Agregador
TARJETA PRESENTE TARJETA NO PRESENTE
1,000,000 o más Trxs 20,000 o más Trxs
Trxs anuales independientemente del Trxs anuales independientemente del

titular de marca, producto, adquirente y titular de marca, producto, adquirente y
Agregador. Agregador.
En caso que el Sub-afiliado con

Transacciones operativa tarjeta presente, realice al
menos el 75% de sus transacciones en
dispositivos certificados por EMVco,
más NIP no se requiere de manera
obligatoria acción alguna de
cumplimiento.
En sitio Remoto Remoto

4 escaneos trimestrales de Si Si
vulnerabilidad externos
Al menos dos pruebas de penetración No No
anuales, una interna y otra externa
En el caso de los sub-afiliados que lleven a cabo transacciones con tarjeta no presente, su segmentación
será realizada contabilizando el total de las transacciones de tarjeta no presente que lleve a cabo con
cualquier Agregador.
Si el total de transacciones con tarjeta no presente de un sub-afiliado sobrepasa las 20,000 transacciones
anuales, independientemente de con cuantos Agregadores llevaron a cabo las mismas, deberán cumplir
con la certificación correspondiente y el escaneo de vulnerabilidad de cada uno de los Agregadores con
los que llevan a cabo estas transacciones con tarjeta no presente de acuerdo al siguiente detalle:
Modelo Nivel
Transaccional
e-commerce PSP / PF /
Modelo SAQ / AOC ASV
(Todas las Agregador
marcas
actualizado)
a. Solución de
comercio electrónico
No es
totalmente operada
necesario,
por un tercero. El del
Menor a únicamente
b. Re direccionamiento Proveedor de
20,000 relación
de pagos de URL (Link Servicios de
Adquirente – Certificación
de pagos) Pago (PSP /
Marcas Nivel 1
c. IFrame (Inline Facilitador de
Frame) Pago o
a. Solución de Agregador)
comercio electrónico De 20,000 a 1
A
totalmente operado por millón
un tercero.
Capítulo XVII
b. Re direccionamiento
de URL (link de pagos)
c. IFrame (Inline Frame
d. Direct Post o Java
Nivel 2, 3, 4 A-EP
Script
e. API Cualquier El del Receptor
D
Nivel de Pagos
*SAQ A: Comerciantes dedicados al comercio electrónico totalmente tercerizados que emplean un sitio
web externo para el procesamiento de pagos
*SAQ A-EP: Comerciantes dedicados al comercio electrónico parcialmente tercerizados que emplean un
sitio web externo para el procesamiento de pagos
*SAQ D: Comerciantes con elegibilidad SAQ que no cumplan los criterios para ningún otro tipo de SAQ
Consideraciones especiales de la segmentación:
• La afiliación debe ser la de uso nacional, no utilizar el ID de las marcas.
• Un Receptor de Pagos que es verificado satisfactoriamente de acuerdo a su volumen

transaccional o modificó su operativa no califica, en la siguiente segmentación y no se le
solicita la certificación.
• Los sub-afiliados (receptores de pago de agregadores) que cuenten con giro natural, serán
considerados dentro de la segmentación elaborada por la Entidad Administradora.
• Aquellos sub-afiliados (receptores de pago de agregadores) que no cuenten con giro

natural, deberán ser identificados mediante la asignación de un número de afiliación, se
integrarán a la Base Única y deben contemplarse en la elaboración de la segmentación
mediante el uso del reporte que el Adquirente emita mensualmente a la Entidad
Administradora.
• Tomando en cuenta el resultado que arroje el censo de receptores sub-afiliados con Tasa
Agregador, estos podrán aprovechar el esquema de Tasa Natural siempre y cuando
presente los requisitos requeridos por el Contrato de Intercambio Doméstico y deberá
tener el monto máximo permitido
Para Receptores de Pagos que se encuentren en Remediación y ya no cumplan con ninguno de los
criterios de Segmentación, el Receptor de Pagos debe concluir su remediación hasta obtener una
certificación satisfactoria.
Capítulo XVII
5.3 Procedimiento operativo de la segmentación PCI DSS
5.4 Segmentos de la Certificación:
• PCI con ROC y reportes: Receptores de pagos con más de 15,000,000 de transacciones
anuales sin importar el titular de marca, producto o adquirente, por adquirente o que hayan
sido reportados como Punto Compromiso por el Grupo de Prevención de Fraudes. Les
aplica la certificación presencial por parte de la Entidad Certificadora (que conforme a las
Reglas de PCI Security Standards Council para llevar a cabo las certificaciones PCI. Por
ejemplo, un QSA (significa por sus siglas en inglés el Qualified Security Assesor) con
generación de ROC y reportes, escaneos de vulnerabilidad interno y externo, y pruebas
de penetración interna y externa.
• Gap Análisis PCI Tier I: Receptores de pagos con más de más de 6,000,000 y menor a
15,000,000 de transacciones anuales sin importar el titular de marca, producto o
adquirente. Les aplica la certificación presencial por parte de la Entidad Certificadora
escaneos de vulnerabilidad interno y externo, y pruebas de penetración interna y externa.
Con el fin de estandarizar el tipo de reporte y contenido de un informe GAP Análisis este debe
contener la información que el PCI DSS vigente solicite, a continuación, se enuncian más no se
limitan las secciones a considerar en el GAP Análisis Tier I de PCI:
o Portada
o Tabla de contenido
o Información de contacto y fecha del reporte
Capítulo XVII
§ Datos de contacto del Receptor de Pagos
§ Datos de contacto de la Entidad Certificadora
§ Fecha de ejecución del GAP
§ Versión de PCI DSS utilizada
o Resumen del reporte. Debe contener, a manera de resumen, el resultado general de la
certificación por requerimiento.
o Descripción de la actividad que el Receptor de Pagos realiza en la que se involucra el
procesamiento, transmisión y/o almacenamiento de datos del tarjetahabiente y/o datos
sensibles de tarjeta.
o Descripción del alcance de la certificación y las actividades realizadas por el Receptor de
Pago para, si es el caso, reducir el alcance de la certificación.
o Listado de las entidades externas con las que comparte datos del tarjetahabiente y/o
datos sensibles de tarjeta.
o Descripción de todos los flujos de transacciones con tarjeta incluidos en la certificación
(por ejemplo: autorizaciones, devoluciones, contracargos, cargos periódicos, e-
commerce, conciliación, liquidación, etc.)
o Listado de los proveedores de servicio del Receptor de Pagos que por la naturaleza del
servicio se incluyen en el proceso de certificación.
o Listado de los resultados de los escaneos de vulnerabilidades externos que se incluyen
en la certificación (fecha del escaneo, nombre del ASV que lo realiza, resultado, fecha
del re-escaneo [cuando aplica]).
o Listado de todos los requerimientos que incluye el estándar PCI DSS marcando cada uno
de ellos el estado en el que se encontró: Cumplimiento, , No Aplica, No Probado, No
Cumplimiento.
o La documentación de todos los controles compensatorios evaluados de acuerdo a lo
establecido en el estándar PCI DSS (Apéndice C)
La Entidad Certificadora debe obtener evidencia suficiente y completa para evaluar el

cumplimiento con cada uno de los requerimientos de PCI DSS que se incluyen en el reporte GAP
Análisis Tier I
• SAQ Tier II de PCI: Receptores de pagos con más de más de 2,000,000 y menos de
6,000,000 de transacciones anuales sin importar el titular de marca, producto o adquirente.
Les aplica la certificación remota y debe ser firmada por parte de la Entidad Certificadora
(QSA o ISA Information Security Assesor), escaneos de vulnerabilidades y pruebas de
penetración que se determinen en el tipo de SAQ (Self-assessment Questionnaire) que
les aplique de acuerdo a su operativa y en conjunto con las reglas definidas por el PCI
DSS.
• PCI L4:
o Receptores de pagos con operativas E-commerce, Cargo Periódico o MoTo a partir de
20,000 transacciones anuales. En el caso de E-commerce debe presentar su esquema
de conectividad y el certificado de motor de pagos de PCI DSS para confirmar que la
infraestructura cumple con PCI DSS.
o Receptores de pago con más de 1,000,000 y menos de 2,000,000 de transacciones
anuales de tarjeta presente, en todos los casos sin importar el titular de marca o
adquirente. Les aplica la certificación remota por parte de la Entidad Certificadora, y
escaneos de vulnerabilidades y pruebas de penetración que se determinen por su
operativa y en conjunto con las reglas definidas por el PCI DSS para receptores de pago
que operen Con Tarjeta Presente y cumplan con encripción punta a punta, lectura y envío
de EMV al emisor responsable, envío de los indicadores correctos con su operativa.
o Receptores de pago sub-afiliados con más de 1,000,000 transacciones con Tarjeta
Presente, en todos los casos sin importar el titular de marca o adquirente. Les aplica la
certificación remota por parte de la Entidad Certificadora, y escaneos de vulnerabilidades
y pruebas de penetración que se determinen por su operativa.
Capítulo XVII
o Receptores de pago sub-afiliados con más de 20,000 transacciones con Tarjeta No
Presente, en todos los casos sin importar el titular de marca o adquirente. Les aplica la
certificación remota por parte de la Entidad Certificadora, y escaneos de vulnerabilidades
y pruebas de penetración que se determinen por su operativa.
5.5 Reportes de Adquirente.
Informe de resultados a los Adquirentes
• Una vez obtenidos los resultados de la segmentación, la Entidad Administradora debe

entregar por medio de la herramienta de administración proporcionada y de forma electrónica
cuando la Institución Adquirente lo solicite un reporte de Segmentación con la siguiente
estructura:
Campo Descripción
Grupo Número de grupo cuando se trate de una cadena, número de afiliación
cuando se trate de un Receptor de Pagos Individual
Cadena Número de cadena cuando se trate de una cadena, cero cuando se
trate de un Receptor de Pagos Individual
Afiliación de Número de identificación de un Receptor de Pagos representativo del
referencia Grupo/Cadena.
Nombre Nombre comercial del Receptor de Pagos
Segmento Clave del segmento, de acuerdo al cuadro de segmentos. Es el
segmento que se obtuvo al aplicar los criterios de segmentación
Segmento anterior Clave del segmento, de acuerdo al cuadro de segmentos. Es el
segmento que tenía el Receptor de Pagos en la segmentación anterior
Adquirente Clave del adquirente responsable, tres letras de acuerdo al catálogo de
responsable Adquirentes. Es aquel que tiene más transacciones del segmento
obtenido
Responsable anterior Clave del adquirente responsable anterior, tres letras de acuerdo al
catálogo de Adquirentes. Es aquel que era responsable del Receptor
de Pagos en la segmentación anterior
Adquirentes Clave del adquirente compartido, tres letras de acuerdo al catálogo de
compartidos Adquirentes, si son varios adquirentes se separan con comas y se
ordenan del mayor al menor, de acuerdo al número de transacciones
del segmento obtenido
Adquirente Clave del adquirente mayoritario, tres letras de acuerdo al catálogo de
mayoritario Adquirentes. Es aquel que tiene más transacciones, considerando el
gran total de transacciones del Receptor de pagos, no solo del
segmento obtenido
Resultado Descripción del resultado obtenido, pudiendo ser uno o varios de los
siguientes casos:
• Nuevo
• Permanece
• Cambia de adquirente responsable
• Cambia de segmento
• Ya no resulta segmentados
• Cada Adquirente debe recibir un reporte, conteniendo solo los casos donde aparece como
adquirente responsable, estos serán sus Receptores de Pagos a certificar. Adicionalmente
el reporte debe contener otros casos donde el Adquirente aparece como responsable
anterior, responsable compartido o Adquirente mayoritario, para enterarle de cambios
donde tiene relación, aunque no sea el responsable.
Capítulo XVII
• La Entidad Administradora puede requerir a la Institución Adquirente, reordenar Grupos-
Cadena en la Base Única de acuerdo al resultado de la segmentación, para tener un ID-
Receptor de Pagos por cada certificación. La Institución Adquirente debe atender la
solicitud en un plazo no mayor a 10 (diez) días naturales.
• Es responsabilidad de la Entidad Administradora constatar que los Receptores de Pago

segmentados NO se encuentran en proceso de verificación y/o considerados en una
segmentación anterior; dado que el receptor de pagos deberá terminar su proceso de
certificación anterior para ser considerado nuevamente en una segmentación.
Revisión de resultados por parte de los Adquirentes.
A partir de la entrega de resultados del ejercicio de segmentación, las Instituciones Adquirentes cuentan
con 30 (treinta) días naturales para revisar y en su caso aprobar los resultados de la segmentación.
• En caso de presentar alguna inconformidad con el ejercicio de segmentación, debe reportarlo

a la Entidad Administradora, para que tome las acciones que correspondan.
• En caso de detectar Receptores de Pagos de los que ya no sea Adquirente, podrá iniciar
el procedimiento de cambio de responsabilidad descrito en la sección “CAMBIO DE
RESPONSABLE DE RECEPTORES DE PAGOS EN PROCESO DE CERTIFICACIÓN”.
• Para los Receptores de Pagos solicitados por la Institución Adquirente, la Entidad

Administradora debe determinar el segmento en el cual se pueden clasificar y agregarlos a
la lista de Receptores de Pagos a certificar. En caso de existir asignación previa de un
Receptor de Pagos a una Entidad Certificadora, la Institución Adquirente debe informar a la
Entidad Administradora, para dar el seguimiento correspondiente. Tratándose de un Receptor
de Pagos multiadquirido, la Institución Adquirente que solicita la certificación es responsable
de darle seguimiento y la Entidad Administradora debe notificar a las otras Instituciones
Adquirentes que se va a llevar a cabo certificación.
Actualización de la segmentación en la Base PCI.
Una vez concluidas las revisiones con los Adquirentes, la Entidad Administradora cuenta con 3 (tres) días
naturales para actualizar en la Base PCI los resultados de la segmentación.
6. PROCEDIMIENTO DE CERTIFICACIÓN PCI.
6.1) 2Líneas de tiempo. Conforme al contenido del presente Capítulo se podrá consultar la línea de
tiempo para el proceso PCI DSS en el Anexo 56.
*La línea de tiempo podrá ser modificada en casos de contingencia, previa revisión del
Comité de Tarjetas.
2
Las Instituciones Adquirentes podrán actualizar los planes de trabajo presentados a la Entidad
Administradora, siempre y cuando se encuentren vigentes a la fecha de solicitud. La Entidad
Administradora debe actualizar el plan de trabajo en la Base PCI y en la herramienta de reportes
proporcionada a los Adquirentes.
Capítulo XVII
7. PLANEACIÓN DE LA CERTIFICACIÓN.
Una vez que la Institución Adquirente cuenta con los Receptores de Pagos3 segmentados debe elaborar
un plan de ejecución de la certificación; siendo el responsable de asignar en conjunto con sus Receptores
de Pagos los tiempos y prioridades para la ejecución de las certificaciones, cumpliendo con los plazos
especificados en el presente Capítulo. Las Instituciones Adquirentes podrán actualizar las fechas y
alcance de los planes de trabajo presentados a la Entidad Administradora, siempre y cuando se encuentre
vigentes a la fecha de actualización.
El plan de trabajo debe contener al menos, la siguiente información:
• Opcional la fecha en la que la Institución Adquirente presentó el programa PCI DSS, si no se

ha presentado debe proporcionarse la fecha estimada de presentación.
• Si ya se presentó el programa debe proporcionarse la fecha de ejecución de la verificación

que le corresponda al Receptor de Pago de acuerdo a su segmentación, en caso de no
haberse ejecutado debe proporcionarse la fecha estimada de ejecución.
• Si el Receptor de Pagos ya cuenta con una certificación PCI DSS debe indicar la fecha del
certificado y que cubre su operación en México (información descrita en Certificado emitido
y/o proporcionar el extracto de **** del ROC). Si está en proceso de certificación, debe
proporcionar las fechas de implementación de acuerdo a su plan de trabajo vigente.
• El Adquirente debe indicar en su plan de trabajo la Entidad Certificadora que llevará a cabo
el proceso de certificación de los Receptores de Pago.
• Los Adquirentes cuentan con 50 (cincuenta) días naturales para entregar vía e-mail a la
Entidad Administradora su plan de trabajo de los Receptores de Pagos de los que es
responsable, para los Receptores de Pago segmentados en PCI L4 los Adquirentes a través
de su personal responsable registrado ante la Entidad Administradora podrá proporcionar por
medio electrónico: (i)plan de trabajo general que aplique para todos los Receptores de Pago,
siempre y cuando los certifique la misma Entidad Certificadora y se establezca el contacto de
cada Receptor de pagos; o (ii) entregar un Plan de Trabajo por cada Receptor de pagos
segmentado.
• El Adquirente puede actualizar el plan de trabajo a la Entidad Administradora, siempre y

cuando la actualización suceda antes de la fecha que se encuentre establecida anteriormente
para la ejecución PCI DSS y que se encuentre dentro de la línea de tiempo (Anexo 56), La
Entidad Administradora debe actualizar el plan de trabajo en la Base PCI y en la herramienta
de reportes proporcionada a los Adquirentes.
• El incumplimiento por parte de la Institución Adquirente y/o Receptor de Pagos a la

presentación o ejecución del plan de trabajo, se hacen acreedores a la responsabilidad
señalada en el punto 17 Penalizaciones de este capítulo.
3
Un cambio de razón social y afiliación de un Receptor de Pagos segmentado, no afectará la
certificación en curso.
Capítulo XVII
8. PROCEDIMIENTO GENERAL PARA LA CERTIFICACIÓN
8.1 DE LOS RECEPTORES DE PAGO
Fase 1: Análisis (al presente se enuncian más no se limitan las actividades que la entidad
Certificadora debe cumplir conforme los estándares vigentes de PCI DSS)
• La Entidad Certificadora debe proporcionar acceso al Receptor de Pagos a su Portal web,

para la gestión de la certificación.
• Revisión de los Escaneos de Vulnerabilidad.
• Recolección de evidencias, documentos y configuraciones de sistemas.
• Generación y envío del reporte de Análisis detallado al Receptor de Pagos.
• Envío de reporte al Adquirente de estatus de cumplimiento del Receptor de Pagos y

adquirente.
Fase 2: Gestión de Remediación
• Plan de trabajo con el Receptor de Pagos y la Entidad Certificadora.
• Seguimiento del avance de remediación.
Fase 3: Validación de la remediación
• Resultado de la verificación de todos los controles de seguridad, configuraciones, políticas,

procedimientos, y realizar entrevistas de acuerdo a los estándares de PCI DSS vigentes.
• Entrega de informe final de cumplimiento al Receptor de Pagos y a la Institución Adquirente.
La Entidad Certificadora debe mantener disponible para el Receptor de Pagos y/o su Institución
Adquirente, el certificado PCI DSS y los resultados de los escaneos de vulnerabilidad de cada
Receptor de Pagos, durante 5 años después de la conclusión de la verificación.
8.2 DE LOS AGREGADORES (PAYMENT FACILITATORS AND SERVICE PROVIDERS)
Un Service Provider es una organización involucrada en el procesamiento, almacenamiento y

transmisión de datos de tarjetahabientes, así como la protección y la seguridad de esta
información. Dentro de esta categoría, también se considera a los proveedores de hosting y otros
proveedores de servicios para Receptores de Pagos.
Los Agregadores pueden requerir para su operación de los servicios de uno o varios Service
Provider. Por lo que, además de cumplir con los requerimientos específicos en su función como
Agregador (y Service Provider), requieren solicitar el cumplimiento que corresponde a cada uno
de sus Service Provider.
Capítulo XVII
8.2.1 Niveles de certificación
Nivel 1 (L1) Service Providers
Service Volumen de PCI SSC- Quarterly

Provider Transacciones Approved network
QSA scans
PCI SSC
ASV
Agregadores Almacena, Aplica Aplica
transmite o
procesa mas de
300 mil txns
anuales
Nivel 2 (L2) Service Providers
Service Volumen de Annual Self Quarterly

Provider Transacciones Assessment network
SAQ scans
PCI SSC
ASV
Agregadores Almacena, Aplica Aplica
transmite o
procesa menos
de 300 mil txns
anuales
9. ROLES Y RESPONSABILIDADES
9.1) Institución Adquirente (IA):
• Entregar a la Entidad Administradora y al Árbitro Operativo los primeros 20 (veinte) días del
año en enero la matriz de escalamiento actualizada indicando a los representantes para
enviar y recibir notificaciones del estatus de sus Receptores de Pago, conforme a lo indicado
en el presente Capítulo. La institución Adquirente es responsable de mantener actualizados
los contactos, en caso contrario, se tomarán como vigente la información proporcionada y las
notificaciones surtirán todos sus efectos, conforme se establece en el presente Capítulo.
• Revisar y autorizar los resultados de la segmentación realizada por la Entidad Administradora.
• Entregar a la Entidad Administradora el plan de trabajo de los Receptores de Pagos de
acuerdo con lo establecido en el punto 7 del presente documento, con fechas programadas
sin enviar todos los Receptores de Pagos a una misma fecha y menos aún a la fecha límite.
• Programar en conjunto con la Entidad Certificadora las fechas de revisión a los Receptores
de Pagos asignados.
• Entregar al Receptor de Pagos la carta de presentación de PCI DSS
• Dar seguimiento para que el Receptor de Pagos cumpla con la verificación en tiempo y forma,
conforme al segmento designado y plan de trabajo presentado.
• Entrega al Receptor de Pagos la documentación requerida.
• Recabar Carta de Conocimiento para su certificación PCI DSS (Anexo 38), mediante el cual
el Receptor de Pagos está de acuerdo y se compromete a asegurar la información sensible
de los tarjetahabientes a través de la certificación PCI DSS, en el documento se debe
proporcionar el nombre del contacto responsable del seguimiento de la certificación.
Adicionalmente, para los Receptores de Pago segmentados en PCI L4, el Adquirente puede
entregar el Anexo 38 de forma genérica, identificando a todos los Receptores de pago que
se certificaran con la misma Entidad Certificadora, si el Adquirente opta por la entrega del
Anexo 38 genérico para Receptores de Pago PCI L4, el Anexo 38 deberá de ser firmado por
Capítulo XVII
el Representante Legal del Adquirente como responsable de los Receptores de Pago que se
identifican en dicho documento.
• Entregar digitalizado vía E-mail a la Entidad Administradora la carta conocimiento Anexo 38
antes de la conclusión de la certificación de los Receptores de Pago. En su caso esta carta
puede ser sustituida por una carta con el mismo contenido que el Anexo 38, emitida y firmada
por el adquirente responsable.
• Autorizar a la Entidad Administradora el acceso a la información que genere la Entidad
Certificadora para mantener actualizada la base de datos de PCI para el control y seguimiento
del avance de la certificación de cada uno de los Receptores de Pagos.
Cuando se trate de un Receptor de Pagos multiadquirido:
• El Adquirente mayoritario en transacciones es el responsable de dar seguimiento al proceso

de certificación de acuerdo a su segmento u operativa. Dado que el objetivo es proteger los
datos de la tarjeta y que deben realizarse las mismas actividades sin importar si tienen
conexiones con una o más entidades para su operación, se conserva el principio de que debe
realizarse una sola certificación.
§ Para los Receptores de pagos de los segmentos Tier I y Tier II se considera el
total de transacciones, sin importar su operativa.
§ Para los Receptores de Pagos del segmento L4 se considera su operativa, de
acuerdo a lo establecido en el cuadro de Segmentos del punto 5.
• En caso de que un Receptor de Pagos cuente con 2 o más host involucrados en el flujo de la
transacción, cada host tiene debe de considerarse en la verificación.
• En caso de que el resultado de la ejecución de la verificación sea no satisfactoria, al concluir

su remediación, tendrá que solicitar una nueva verificación.
• Una vez que se tenga una certificación exitosa, se notifica al Receptor de Pagos que la
certificación es vigente por un año y deberá renovarla, siempre y cuando califique en la última
segmentación.
• Notificar a la Entidad Administradora, cuando detecte cambio de adquirencia de Receptores
de Pagos de los cuales es responsable. Al momento de la segmentación, la Entidad
Administradora deberá notificar a todos los adquirentes involucrados de aquellos Receptores
de Pagos que sean multiadquiridos.
•
9.2) Responsabilidades de la Entidad Certificadora (EC):
• La Entidad Certificadora debe contar con personal QSA (Quality Security Assessor)
certificado con experiencia en la norma PCI DSS.
• Realizar certificaciones de PCI DSS cuando el Receptor de Pagos resulte segmentado, ser
determinado como Punto Compromiso o a solicitud de la Institución Adquirente.
• Realizar escaneos de vulnerabilidad ASV (Approved Scanning Vendors) y pruebas de
penetración cuando así se requiera de acuerdo a la norma PCI DSS.
• Firmar un Convenio de Confidencialidad NDA (Non Disclosure Agreement) con los
Receptores de Pagos y/o las Instituciones Adquirentes.
• Realizar certificaciones de acuerdo a lo descrito en este Capítulo.
o Análisis del cuestionario de auto-evaluación para determinar estatus actual de
cumplimiento con los estándares de PCI DSS.
o Revisión en sitio o remota, para evaluar los procesos y controles operativos de

infraestructura, redes y prácticas actuales de seguridad de la información.
o Revisión de configuraciones de sistemas y dispositivos involucrados en el procesamiento

de las transacciones.
Capítulo XVII
o Revisión de escaneos de vulnerabilidad externo para que tengan resultados en estatus
de cumplimiento de acuerdo a los estándares PCI DSS.
o Revisión de políticas y procedimientos para validar que los Receptores de Pagos están
en cumplimiento.
o Entrega de recomendaciones y priorización de las acciones para alcanzar el estatus de

cumplimiento.
o Entregar los siguientes documentos, conservando acuse de entrega físico o electrónico:
§ Reporte detallado al Receptor de Pagos y al Adquirente del resultado de la

certificación por un medio seguro o cifrado. La Entidad Certificadora debe
conservar registro de la entrega del reporte al Receptor de Pagos.
§ Reporte de Seguimiento y las ejecuciones de verificación realizadas a la

Entidad Administradora.
§ Certificado de cumplimiento de PCI DSS o reporte de GAP Analysis o SAQ,

cuando sea satisfactorio y según corresponda.
• La Entidad Certificadora no puede compartir y dar información de los Receptores de Pagos

en proceso a Adquirentes que no sean el Adquirente responsable o los adquirentes
compartidos del Receptor de Pagos.
9.3) Entidad Administradora (EA):
• Desarrollar y actualizar la base de datos PCI para el control del avance de la certificación.
• Administrar el proceso de certificación de los Receptores de Pagos de acuerdo a lo señalado

en el presente Capítulo.
• Contar con el control y seguimiento del proceso PCI DSS ya sea a través de correos
electrónicos o medios automatizados.
• Realizar la segmentación de los Receptores de Pagos, de acuerdo a lo señalado en el punto

5 de este capítulo.
• Entregar a cada Institución Adquirente el resultado de la segmentación para su revisión y

aprobación.
• Solo puede compartir a la Institución Adquirente el total de transacciones que tiene

registradas como adquirente.
• Deberá generar un reporte mensual para los Titulares de Marca indicando: nombre del
receptor de pagos, nivel de certificación, adquirente responsable y estatus general. El reporte
se generará al personal responsable reportado por cada Titular de Marca a la Entidad
Administradora.
• Ratificar con la Institución Adquirente la relación de Receptores de Pagos a certificar y

registrarlo en la base de datos de PCI
Capítulo XVII
• Recibir y Actualizar el(los) plan(es) de trabajo proporcionado(s) por el Adquirente para la
verificación de los Receptores de pago asignados.
• Actualizar la asignación de Receptores de Pagos a las Entidades Certificadoras.
• Notificar al Árbitro Operativo las actualizaciones de la matriz de escalamiento a través de

correo electrónico.
• Notificar al Árbitro Operativo, los Incumplimientos a esta normativa.
• Cumplir con los roles descritos en el Control del proceso de certificación.
• Cumplir con los niveles de servicio acordados con las Instituciones Adquirentes.
• En caso de proporcionar medios automatizados, deberá proporcionar el acceso a las

personas que las Instituciones Adquirentes, Titulares de Marca y QSAs designen; así como
administrar los usuarios y responsabilidades de cada una de ellas.
9.4) Cámara De Compensación (CC):
• Entregar a la Entidad Administradora mensualmente el total de transacciones del mes

inmediato anterior, durante los primeros 10 (diez) días naturales de cada mes, de acuerdo al
layout establecido en el punto 5.
9.5) Árbitro Operativo (AO):
• Recibir las notificaciones que la Entidad Administradora genere.
• Notificar a las Instituciones los Incumplimientos determinados por la Entidad Administradora,

conforme a lo establecido por el presente Capítulo.
• Notificar las penalizaciones determinadas por la Entidad Administradora a las que una
Institución Adquirente se hace acreedora, por el incumplimiento al presente Capítulo.
Presentar reporte mensual al Subcomité de Operaciones de los incumplimientos y penalizaciones que se

generen en el presente capítulo
10. CONTROL DEL PROCESO DE CERTIFICACIÓN
La Entidad Administradora da mantenimiento y actualiza la Base PCI DSS, con base en los reportes de
status y la información en general que reciba de los Adquirentes, Entidad Certificadora y Árbitro Operativo,
las cuales colaboran con el administrador para mantener actualizada la información de PCI DSS.
10.1) Requisitos previos
• La Entidad Administradora debe proporcionar acceso a la Base PCI DSS a los usuarios que
los Adquirentes responsables designen, Entidad Certificadora y Árbitro Operativo.
o El Acceso de los usuarios a la Base PCI DSS debe ser por un canal cifrado.
o Los usuarios deben autenticarse a través de un nombre de usuario y contraseña.
Capítulo XVII
o Los usuarios de la Entidades Certificadoras pueden consultar e informar a la Entidad
Administradora de las actualizaciones de los datos solamente de los Receptores de
Pagos que les hayan sido asignados.
o Los usuarios de la Instituciones Adquirentes solo pueden consultar e informar al

Administrador de las actualizaciones de la información de Receptores de Pagos de los
cuales son responsables.
10.2) Catálogo de Status
El Administrador, debe actualizar en la Base PCI DSS y generar la actualización del envío en la
Base Única, de acuerdo al siguiente catálogo:
Secuencia Clave Status Descripción Responsable

1 AS Asignado El Administrador asigna a EA
una Entidad Certificadora
2 PP Presentación del La Institución Adquirente EA
programa PCI presenta el programa al
Receptor de Pagos
3 AC Receptor de La Institución Adquirente IA
Pagos aceptó obtiene el Anexo 38 Carta de
certificación. Conocimiento de PCI
4 EJ Ejecución La Entidad Certificadora EV
Assessment ejecuta la certificación
5 EI Entrega de La Entidad Certificadora EV
Informes entrega los informes de
resultados al Receptor de
Pagos
6 IM Implementación El Receptor de Pagos trabaja EV
de Medidas de en su remediación
Mitigación
7 SA Satisfactoria Cumple satisfactoriamente EV
con la certificación
Excepción RE Reevaluación Un Receptor de Pagos EV
certificado presenta Punto
Compromiso y requiere
nueva certificación.
Excepción PC Cuenta con El Receptor de Pagos cuenta EA

certificación PCI con una certificación PCI
DSS DSS aprobada en los últimos
12 meses
Excepción NA No acepta La Institución Adquirente EA
certificación solicita la certificación, pero
el Receptor de Pagos no la
acepta
Excepción NC No cumplimiento No aprueba EV
satisfactoriamente la
certificación y presenta
compromiso de información
Capítulo XVII
10.3) Actualización de status
La Entidad Administradora es responsable de dar seguimiento desde la ejecución de la segmentación,

ejecución de la verificación, plan de remediación hasta la conclusión de la certificación, actualizando en
la base PCI DSS los cambios de estatus en cada etapa, hasta que el Receptor de Pagos obtenga el
certificado PCI DSS, Resultado del GAP o SAQ, según corresponda. Como resultado de los avances en
el proceso de la verificación, la Entidad Certificadora y las Instituciones Adquirentes deben informar a la
Entidad Administradora cada cambio de status, de acuerdo a la secuencia marcada en la tabla de status
anterior de conformidad al plan de trabajo presentado y línea de tiempo (Anexo 56).
• Cada cambio de estatus en la Base PCI DSS debe contar con la fecha de actualización.
• La captura debe realizarse en la Base PCI DSS a más tardar 3 (tres) días naturales
después de que la actividad de referencia haya sido notificada por la Entidad responsable
de la actividad.
• En caso de que las actualizaciones se realicen después de 3 (tres) días naturales esto
debe ser reportado por la Entidad Administradora a los participantes.
• Los siguientes datos sólo pueden ser actualizados por la Entidad Administradora en la
Base PCI DSS:
o ID del Receptor de Pagos (grupo/afiliación)

o Nombre comercial
o Segmento
• Los datos que deben ser actualizados por la Entidad Certificadora o Institución adquirente
en la Base PCI DSS, son:
o Folio de la Entidad Certificadora: Es un campo opcional, la Entidad Certificadora puede

indicar su propio folio en caso de contar con un control interno de sus actualizaciones.
o Status ejecutado: Es un dato obligatorio, debe corresponder a la actividad que ya fue

ejecutada en el Receptor de Pagos, de acuerdo al catálogo de status del presente
capítulo.
o Fecha de ejecución: Es un dato obligatorio, es la fecha en que se concluyó la actividad

del punto anterior.
o Status programado: Debe corresponder a la siguiente actividad a realizar en el Receptor

de Pagos.
o Fecha programada: Es la fecha en que se estima ejecutar el status programado, solo

puede capturarse la fecha programada si se ha capturado un status programado.
o Observaciones: Este campo es opcional, la Entidad Certificadora puede capturar

información complementaria del status que está actualizando.
• En la Base PCI DSS se debe validar la congruencia de los datos capturados por la Entidad
Certificadora, los status deben seguir la secuencia marcada en el cuadro de status, salvo
cuando se trate de un status de excepción.
• Si la información de status capturada por la Entidad Certificadora es correcta esta se

actualiza en la Base PCI DSS, quedando disponible para su consulta tanto de las
Entidades Certificadoras como de las Instituciones Adquirentes responsable y la propia
Entidad Administradora.
Capítulo XVII
• Si la información de status capturada por la Entidad Certificadora tiene errores estos se
deben presentar al usuario, no se deben actualizar en la Base PCI DSS hasta su
corrección.
• Cuando la Institución Adquirente no da cumplimiento a los plazos establecidos en el Plan

de trabajo (presentado conforme), la Entidad Administradora debe enviar un reporte a la
Institución Adquirente indicando los Receptores de Pagos que se encuentran en dicha
situación de conformidad a lo establecido en la línea de tiempo (Anexo 56).
10.4) Reporte de Avance de Certificaciones
La Entidad Administradora debe proporcionar a las Instituciones Adquirentes reportes mensuales

de avance de acuerdo a las siguientes reglas.
• Estatus de los Receptores de Pagos de los cuales es responsable, indicando Grupo-Cadena

o afiliación cuando aplique, nombre comercial, segmento, Entidad Certificadora, estatus y
fechas.
• Estatus global del proceso de certificación, indicando el número de Receptores de Pagos por
cada estatus y los porcentajes de cumplimiento a los participantes.
10.5) Consulta estatus PCI DSS.
Como un complemento a la actualización de status, la Entidad Certificadora puede consultar los datos,
sólo de los Receptores de Pagos que le han sido asignados, se proporcionan las siguientes consultas:
• Consulta por Receptor de Pagos. Presenta los siguientes datos:
o Id del Receptor de Pagos (grupo/afiliación)

o Nombre comercial
o Segmento
o Status actual
o Fecha en la que se ejecutó el status actual
o Status programado
o Fecha estimada de ejecución del status programado
o Histórico de actualización de status, listado de las actualizaciones de status que haya
tenido el Receptor de Pagos anteriormente
• Consulta general. Presenta un listado de todos los Receptores de Pagos asignados a la

Entidad Certificadora, con los siguientes campos:
o Id del Receptor de Pagos (grupo/afiliación)

o Nombre comercial
o Segmento
o Status actual
o Fecha en la que se ejecutó el status actual
o Status programado
o Fecha estimada de ejecución del status programado
o Histórico
Capítulo XVII
A continuación, se detalla el proceso operativo de actualización de Base PCI DSS:
10.6) Notificaciones de certificación PCI DSS

5 (cinco) días naturales antes del vencimiento de cualquiera de los plazos establecidos en el Plan
de trabajo presentado por la Institución adquirente y/o de los tiempos establecidos en la línea de
tiempo de conformidad a lo establecido en el presente Capítulo, la Entidad Administradora debe
enviar un aviso a las Instituciones Adquirentes que no han cumplido, de acuerdo a la matriz de
escalamiento establecida por las Instituciones Adquirentes.
La Institución Adquirente debe presentar al Receptor de Pagos el programa de certificación dentro

del período indicado en la línea de tiempo correspondiente, así como solicitar las personas de
contacto que darán seguimiento a la certificación y actualizar el estatus de presentación de
programa a la Entidad Administradora en la base de PCI DSS.
La Entidad Administradora debe notificar a la Institución Adquirente con 5 (cinco) días naturales de
anticipación que su plazo de presentación se encuentra próximo a vencer, en caso de
incumplimiento la Entidad Administradora debe notificar al Árbitro Operativo para ejecutar el punto
17 Penalizaciones de este capítulo.
La Entidad Certificadora y/o la Institución Adquirente deben coordinar con el Receptor de Pagos
en un plazo no mayor a 30 (treinta) días naturales posteriores a la notificación del programa, la
fecha estimada de inicio cumpliendo lo siguiente:
• Notificar los objetivos de la certificación

• Notificar el tipo de certificación a realizar
• Enviar al Receptor de Pagos los requisitos previos a la verificación
• Entregar al Receptor de Pagos la documentación soporte para la verificación, así como el
Cuestionario de Autoevaluación.
• Determinar una fecha compromiso con el Receptor de Pagos para la entrega de la
información requerida.
Capítulo XVII
• Coordinar con el Receptor de Pagos las fechas para gestión con su área legal (Aplica para
Receptor de Pagos que firman acuerdo de confidencialidad con la Entidad Certificadora).
• Indicar al Receptor de Pagos datos de contacto de la Entidad Certificadora.
Para Receptores de Pagos que tuvieron certificación satisfactoria y está por vencer su año de
vigencia, la Entidad Administradora debe notificar al adquirente en los siguientes plazos:
• 60 (sesenta) días naturales antes del vencimiento
• 30 (treinta) días naturales antes del vencimiento
• 5 (cinco) días naturales antes del vencimiento
El Receptor de Pagos debe proporcionar una fecha programada de ejecución de la verificación, la cual
no debe exceder de 18 meses posteriores a la fecha de presentación del programa.
La Entidad Administradora debe notificar a la Institución Adquirente que su plazo de ejecución

vence en 30 (treinta) o 5 (cinco)días naturales, en caso de incumplimiento la Entidad
Administradora debe notificar al Árbitro Operativo para ejecutar lo señalado en el punto 15:
Sanciones, del presente capítulo.
11. CAMBIO DE RESPONSABLE DE RECEPTORES DE PAGOS EN PROCESO DE

CERTIFICACIÓN
Cuando el Administrador de Base Única reciba una modificación de un Receptor de Pagos, o cuando el
Adquirente reporte que un receptor de Pagos deja de operar con él, deberá validar:
• Si el Receptor de Pagos se encuentra en proceso de certificación se debe marcar en la Base PCI

DSS, para que el nuevo Adquirente tome la responsabilidad y los tiempos para completar su
certificación.
• Si el Receptor de Pagos se encuentra bloqueado con CLAVE 38 “NO CUMPLE CON LA

NORMATIVA PCI”, la Entidad Administradora notificará que la modificación no aplica, hasta que
el Receptor de Pagos concluya su certificación o presente su Plan de trabajo en conjunto con la
Entidad Certificadora.
• El Administrador de PCI debe notificar vía correo electrónico a los Adquirentes involucrados sobre
el seguimiento, fechas de vencimiento y cumplimiento de la certificación.
Los adquirentes cuentan con 10 (diez) días naturales para revisar el cambio y en su caso inconformarse,
en caso de confirmación o falta de respuesta por parte de los adquirentes, el Administrador de PCI DSS
debe actualizar el cambio de responsabilidad en la Base PCI.
El nuevo adquirente responsable, debe dar continuidad a la certificación a partir del status en el que se
encuentre el Receptor de Pagos y cuenta con 30 (treinta) días naturales para enviar un plan de trabajo a
fin de cumplir con la certificación, sin exceder el plazo indicando en la Línea de tiempo (Anexo 56) para
ejecutar su verificación.
12. CONSIDERACIONES ESPECIALES PARA CERTIFICACIÓN PCI.

12.1) Certificación PCI L4:
• Es decisión del Adquirente exigir la certificación L4 a los receptores de pagos

segmentados que operen únicamente con Tarjeta Presente, siempre y cuando, envíen los
indicadores correctos, cuenten con encripción punta a punta, lectura de EMV con NIP.
• Cuando el Cuestionario de autoevaluación (SAQ) no resulte satisfactorio o se detecte
alguna vulnerabilidad alta, será requerida la visita en sitio.
• Cuando se detecte una vulnerabilidad media, la visita en sitio queda sujeta a evaluación
con el adquirente, entregando un plan de mitigación, en un plazo no mayor a 14 (catorce)
Capítulo XVII
días naturales, con una fecha compromiso no mayor a 6 meses y carta responsiva del
adquirente.
• Cuando se detecte una vulnerabilidad baja, el receptor de pagos la debe remediar antes
de su siguiente escaneo trimestral.
• Cuando exista entregables por parte de los Receptor de pagos segmentados (conforme
lo establece el presente capítulo y línea de tiempo) en las dos últimas semanas de
diciembre, se brindará una prórroga por la época navideña para que la entrega se realice
la segunda semana de enero.
• En el caso de E-commerce debe presentar su esquema de conectividad y el certificado de
motor de pagos de PCI DSS para confirmar que la infraestructura cumple con PCI DSS
12.2) PCI-DSS Previo
Cuando el Receptor de Pagos cuenta con una certificación PCI DSS, no registrada en la base PCI
se le asigna el estatus “PC” con la fecha de expedición del certificado, transcurridos 12 (doce)
meses debe entregar un nuevo certificado PCI. Es válido enviar la liga de la página de los titulares
de Marca o el PCI Council donde aparece que el Receptor de Pagos cumple con el programa PCI
DSS. En estos casos se recomienda recurrir a los titulares de Marca para obtener copia del
certificado o al menos la fecha de emisión.
12.3) Ejecución a solicitud de Prevención de Fraudes:
•
El Grupo de Prevención de Fraudes, a través de su coordinador, puede solicitar a la Entidad
Administradora, de acuerdo a lo descrito en el punto 14 del presente capítulo.
• Para Receptores de Pago segmentados en L4 con la plataforma Ecommerce y que
proporcionen evidencia de una infraestructura segura, se les podrá pedir la certificación
mínima en el nivel que tiene en su segmentación cuando el número de contracargos sea
equivalente al 1% de su facturación.
12.4) Ejecución voluntaria:
• Los Adquirentes pueden solicitar a la Entidad Administradora, la certificación de Receptores

de Pagos que no hayan resultado segmentados, cuando el propio Receptor de Pagos o el
Adquirente quiera ejecutar de manera voluntaria.
• La entidad Administradora debe integrar el Receptor de pagos con ejecución voluntaria en la
Base PCI DSS, con el segmento y operativa que le corresponda.
13. EVALUACIÓN POR CERTIFICADOR
La Entidad Certificadora debe llevar un control confidencial y detallado, de la certificación del Receptor
de Pagos.
El Receptor de Pagos debe proporcionar a la Entidad Certificadora la información solicitada de acuerdo

a su certificación.
Para la evaluación en sitio o remota, la Entidad Certificadora debe realizar las siguientes actividades en
conjunto con el Receptor de Pagos:
•
El receptor de pagos cumplió con los requerimientos mínimos, de acuerdo a los estándares
PCI DSS vigentes.
• Confirmar la fecha compromiso para la certificación en sitio o remota.
Una vez confirmada la fecha, la Entidad Certificadora debe reportar el cambio de estatus a la Entidad
Administradora y se debe actualizar las fechas de certificación en la base PCI.
13.1) Certificación en sitio

Durante la certificación en sitio, la Entidad Certificadora analiza las configuraciones de sistemas
del Receptor de Pagos, documentación que soporte los controles de seguridad y el resguardo de
la información de datos de las tarjetas y tarjetahabientes (según sea el caso),
Capítulo XVII
La Entidad Certificadora no puede solicitar mayor información que no sea la necesaria para
corroborar el cumplimiento.
Posterior al análisis de la información recibida, se genera el reporte de resultados de la certificación.
13.2) Certificación Remota

Durante la certificación Remota, la Entidad Certificadora revisa la documentación enviada por el
Receptor de Pagos.
La Entidad Certificadora analiza las configuraciones de sistemas del Receptor de Pagos,
documentación que soporte los controles de seguridad y el resguardo de la información de datos
de las tarjetas y tarjetahabientes.
La Entidad Certificadora no puede solicitar mayor información que no sea la necesaria para
corroborar el cumplimiento.
Posterior al análisis de la información recibida se genera el reporte de resultados de la certificación.
14. REQUISITOS DE CUMPLIMIENTO
Los Receptores de pagos, deben cumplir con los controles de los estándares PCI DSS vigente, de
acuerdo al segmento determinado por la Entidad Administradora en el proceso de Segmentación, descrito
en el punto 7 del presente capítulo. Los estándares PCI DSS pueden consultarse en el sitio
https://www.pcisecuritystandards.org/
Con el fin de estandarizar el tipo de reporte y contenido de un informe GAP Análisis para PCI, este debe
contener al menos las siguientes secciones:
o Portada
o Tabla de contenido
o Información de contacto y fecha del reporte
§ Datos de contacto del Receptor de Pagos
§ Datos de contacto de la Entidad Certificadora
§ Fecha de ejecución del GAP Análisis.
§ Versión de PCI DSS utilizada
o Resumen del reporte. Debe contener, a manera de resumen, el resultado general de la
certificación por requerimiento.
o Descripción de la actividad que el Receptor de Pagos realiza en la que se involucra el
procesamiento, transmisión y/o almacenamiento de datos del tarjetahabiente y/o datos
sensibles de tarjeta.
o Descripción del alcance de la certificación y las actividades realizadas por el Receptor de
Pago para, si es el caso, reducir el alcance de la certificación.
o Listado de las entidades externas con las que comparte datos del tarjetahabiente y/o
datos sensibles de tarjeta.
o Descripción de todos los flujos de transacciones con tarjeta incluidos en la certificación
(por ejemplo: autorizaciones, devoluciones, contracargos, cargos periódicos, e-
commerce, conciliación, liquidación, etc.)
o Listado de los proveedores de servicio del Receptor de Pagos que por la naturaleza del
servicio se incluyen en el proceso de certificación.
o Listado de los resultados de los escaneos de vulnerabilidades externos que se incluyen
en la certificación (fecha del escaneo, nombre del ASV que lo realiza, resultado, fecha
del re-escaneo [cuando aplica]).
o Listado de todos los requerimientos que incluye el estándar PCI DSS marcando cada uno
de ellos el estado en el que se encontró: Cumplimiento, No Aplica, No Probado, No
Cumplimiento.
o La documentación de todos los controles compensatorios evaluados de acuerdo a lo
establecido en el estándar PCI DSS (Apéndice C).
Capítulo XVII
La Entidad Certificadora debe obtener evidencia suficiente y completa para evaluar el
cumplimiento con cada uno de los requerimientos de PCI DSS que se incluyen en el reporte GAP
Análisis.
14.1) Si un Receptor de Pagos opera a través de un tercero, el cual cuenta con una certificación
PCI DSS, esto debe ser considerado por la Entidad Certificadora en el alcance de la Certificación
en México, así como validar en un diagrama de operación que el receptor de pagos no almacena,
procesa y/o trasmite información transaccional, si el Receptor de Pagos almacena, procesa y/o
transmite información transaccional adicional a corroborar que su infraestructura es segura y
cumple con los estándares PCI DSS deberá cumplir con un PCI L4 sin importar en el segmento
que se le asigno para su certificación
14.2) Escaneos de Vulnerabilidad
Es obligatorio que, a los Receptores de Pagos, se les apliquen cuatro escaneos de vulnerabilidad interno
y externo, uno cada tres meses en el periodo de un año. Solo aquellos Receptores de Pagos que se
ejecuten por primera vez la certificación pueden presentar solo el primer escaneo y un plan de trabajo
para los escaneos del siguiente año.
Si como resultado de los escaneos de vulnerabilidad el Receptor de Pagos no cumple con los puntos
críticos del dictamen de escaneo, se revoca el estatus de cumplimiento
Si un Receptor de Pagos obtuvo el estatus de cumplimiento y en escaneos de vulnerabilidad posteriores

el Receptor de Pagos no cumple satisfactoriamente con los puntos críticos del dictamen de escaneo, se
cambia el estatus a RS (Re escaneo) hasta que el Receptor de Pagos corrija los puntos críticos del
dictamen de escaneo.
Cuando la Entidad Certificadora reporte inconsistencias que deben ser atendidas para cumplir con la
certificación, el Receptor de Pagos cuenta con 30 (treinta) días naturales para presentarle un plan de
trabajo que contemple las actividades a realizar y al concluirlas debe iniciar un nuevo proceso de
certificación para obtener reporte GAP Análisis o certificado PCI, en el caso de que la certificación del
Receptor de Pago sea PCI L4 en PCI y esta no sea satisfactoria, la Entidad Certificadora debe notificar a
La Entidad Administradora para que esta informe a la Institución Adquirente que el Receptor de pago
debe de tener una visita presencial con un costo adicional.
El Receptor de Pagos cuenta con 18 meses para que se ejecute la verificación y en caso de recibir
observación por la Entidad Certificadora deberá presentar su plan de remediación. Los receptores de
pago deberán entregar su plan de remediación el cual deberá especificar la fecha de cumplimiento para
tener su certificado.
14.3) Reporte de certificación
Posterior a la certificación la Entidad Certificadora debe generar los siguientes reportes:

• Reporte detallado al Receptor de Pagos y a la Institución Adquirente.
• Reporte al Adquirente de estatus de cumplimiento del Receptor de Pagos.
• Reporte GAP Análisis o certificado PCI al Receptor de Pagos.
14.4) Cambio de estatus
La Entidad Certificadora debe reportar los cambios de estatus a la Entidad Administradora en la base
PCI DSS.
Capítulo XVII
15. INCUMPLIMIENTO
Los Receptores de Pagos con reporte de No Aceptación, conforme a lo establecido en la línea de tiempo:
Deben ser reportados por la Entidad Administradora a la Institución Adquirente, quien cuenta con 15
(quince) días naturales para tomar alguna de las siguientes acciones:
• El Adquirente demuestra que el Receptor de Pagos ya está en cumplimiento.
• Bloquear el Receptor de Pagos en la BU con clave administrativa
En caso de que la Institución Adquirente no realice ninguna de las acciones mencionadas en el punto
anterior, dentro del plazo establecido, la Entidad Administradora debe notificar al Árbitro Operativo, a más
tardar dos días naturales después del vencimiento del plazo, el bloqueo del Receptor de Pagos en la
Base Única, con clave 38 (No cumple con la normativa PCI).
En caso de que otra Institución Adquirente decida atraer al Receptor de Pagos, esta debe realizar la
solicitud de desbloqueo a la Entidad Administradora enviando una carta compromiso de ejecución de la
certificación, firmada por el Receptor de Pagos. La entidad Administradora solicita el desbloqueo del
Receptor de Pagos a Base Única y cambia el Adquirente responsable en la Base PCI DSS.
15.1) Cuando exista incumplimiento en el programa de trabajo de la certificación, la Entidad

Administradora debe notificar al Árbitro Operativo vía correo electrónico máximo en dos días
naturales posteriores al incumplimiento, describiendo la(s) causa(s) y el número de Receptores
de Pagos en esta situación en un horario de 09:00 a 18:00 horas.
El Árbitro Operativo notifica a los responsables de las Instituciones Adquirentes de los Receptores de
Pagos el incumplimiento señalado en la matriz de escalamiento, en un plazo máximo de 2 (dos) días
naturales posteriores a la notificación de la Entidad Administradora y aplica lo establecido en el punto 15
Sanciones, de esta normativa.
Para la matriz de escalamiento se consideran los siguientes niveles:
• Contacto 1: Operaciones
• Contacto 2: Control
• Contacto 3: Decisión
Cuando se notifique una amonestación, el Árbitro Operativo debe notificar a los contactos 1 y 2.
Cuando se notifique una penalización, el Árbitro Operativo debe notificar a los contactos 1, 2 y 3.
15.2) En caso de un Punto Compromiso Confirmado, el área de Prevención de Fraudes debe
notificar a la Entidad Administradora, al día hábil siguiente a la determinación del Punto
Compromiso, para que dé inicio el proceso establecido en el punto 14 de este Capítulo.
16. PROCEDIMIENTO EN CASO DE PUNTO COMPROMISO
De acuerdo a la normativa Capítulo VI Políticas y Procedimientos de Seguridad con los receptores de

Pago: Cuando un Receptor de Pagos es calificado por el Sistema Nacional de Alertas como Punto
Compromiso, el Administrador del Sistema Nacional, a más tardar al siguiente día hábil, debe notificar al
Administrador de PCI (Entidad Administradora), el nombre comercial y número de afiliación del Receptor
de Pagos que ha sido calificado como Punto Compromiso.
La Entidad Administradora debe informar el inicio de este procedimiento a la Institución Adquirente, al día
hábil siguiente en que recibe la notificación del Administrador del Sistema Nacional de Alertas, para que
dé cumplimiento a los siguientes puntos:
Capítulo XVII
a) El Adquirente debe solicitar a su Receptor de Pagos que realice un análisis forense con un
QSA Certificado, así como entregar plan de trabajo en un plazo no mayor a 30 (treinta) días
hábiles.
b) Derivado del resultado de este análisis forense, el Receptor de Pagos debe entregar un plan
de trabajo para remediar los hallazgos encontrados en la revisión y cuenta con 30 (treinta)
días hábiles para entregar dicho plan.
c) Una vez concluida la remediación la Entidad Certificadora debe determinar cuál certificación
corresponde al Receptor de Pagos:
§ Certificación PCI con ROC y reportes

§ Certificación PCI con GAP Análisis
§ Certificación PCI L4
d) Como alternativa al análisis forense y certificaciones, el Receptor de Pagos puede cambiar

su plataforma al esquema de TPV´s con EMV y cifrado, no debe deslizar la tarjeta (double
swipe) ni almacenar información de los tarjetahabientes en sus sistemas propios. Ni
almacene copia de identificación ni tarjeta.
e) El Adquirente debe entregar un nuevo plan de trabajo en un plazo no mayor a 10 (diez) días
hábiles, señalando la fecha en que dará cumplimiento a la certificación o implementación del
cambio de plataforma.
f) Una vez concluida la remediación del Receptor de Pagos, el QSA debe corroborar los
resultados y notificarlo a la Entidad Administradora, hasta que la remediación resulte
satisfactoria.
g) En caso de que el QSA determine que el riesgo de robo de información aún existe, debe
notificar el hecho a la Entidad Administradora, esta a su vez lo notifica a los participantes de
Prevención de Fraudes. La Entidad Administradora solicita el bloqueo del Receptor de Pagos
con clave 38 (No cumple la Normativa PCI) a Base Única. Los participantes de Prevención
de Fraudes pueden instruir a la Entidad Administradora para desbloquear al Receptor de
Pagos.
h) Los Receptores de Pagos determinados como Punto Compromiso, no pueden realizar

movimientos de cambio de Adquirente o integración de nuevos Adquirentes en tanto el
Receptor de Pagos se encuentre en proceso de análisis forense o certificación PCI
incluyendo los cuatro escaneos trimestrales.
i) En caso de incumplimiento de cualquiera de los puntos anteriores, se aplica lo señalado en

el punto 13 Incumplimiento, del presente capítulo.
17. PENALIZACIONES.
17.1 Causas por las cuales se inicia el proceso de penalización por incumplimiento de una
Institución Adquirente (las penalizaciones aplican por cada Receptor de pagos en donde se
determine el incumplimiento) en el proceso PCI:
a) Si una Institución Adquirente incumple con los plazos para la presentación al Receptor de Pagos
del programa de certificación.
b) Un Receptor de Pagos incumple dos veces con la cita agendada con la Entidad Certificadora,
para la ejecución de la certificación.
c) Un Receptor de Pagos incumple con los plazos para la ejecución de la certificación.
Capítulo XVII
d) Un Receptor de Pagos no concluye satisfactoriamente la implementación de las medidas de
mitigación recomendadas dentro del plazo establecido o autorizado por la Entidad
Certificadora.
e) Incumplimiento de los plazos establecidos en el punto 14 “Procedimiento en caso de Punto
Compromiso”.
17.2. Penalizaciones por incumplimiento.

Penalización aplicable por el incumplimiento a los incisos indicados en el numeral 17.1 de esta
norma.
1. Si la Institución Adquirente incumple lo establecido en el numeral 17.1, dicha Institución se hace

acreedora a la penalización 32 del Capítulo V (Penas Convencionales por Incumplimiento) y
cuenta con 20 días naturales posteriores a la notificación de cada incumplimiento para su
atención.
Si la Institución Adquirente no brinda respuesta dentro de los 2 (dos) días naturales posteriores al inciso
f) de la notificación de incumplimiento por parte del Árbitro Operativo, la Entidad Administradora debe
efectuar el bloqueo en la Base Única con la clave 384 NO CUMPLE CON LA NORMATIVA PCI.
17.3. Consideraciones
1. En caso de que una Institución Adquirente realice el bloqueo con clave 38 antes de que los plazos
de penalización se hayan vencido, el proceso de Penalizaciones se suspenderá.
2. El bloqueo con clave 38 se realiza en todas las afiliaciones con el mismo RFC siempre y cuando
sean con operativa con tarjeta no presente (Ecommerce, MoTo, Cargo recurrente).
o No aplica para operativa con tarjeta presente.
3. En caso que un Receptor de Pagos se encuentre bloqueado con clave 38 y solicite ser reactivado,
este deberá cumplir con su certificación PCI previo a su reactivación.
4. Aquellos Receptores de Pago que hayan tenido seguimiento por parte de la Institución Adquirente
para el cumplimiento de certificación y decidan cancelar su operativa con esa Institución
Adquirente posterior al plazo establecido en el Anexo 56 inciso 10 serán bloqueados con clave
38.
5. Cuando alguna Institución Adquirente se le notifique el incumplimiento del inciso c), el
Administrador PCI deberá presentar dicho Incumplimiento ante el Comité de Tarjetas inmediato
posterior para su conocimiento e implementación de medidas correctivas por parte de la
Institución Adquirente.
4
Si el Receptor de Pagos no puede concluir con su certificación derivado de procesos internos o temas tecnológicos,
el Receptor de Pagos deberá presentar un Plan de trabajo a la Entidad Administradora de común acuerdo con la
Entidad Certificadora.
Capítulo XVII
CAPÍTULO XVIII
LABORATORIO CERTIFICADOR
PARA PRUEBAS DE
INTEROPERABILIDAD EN
PUNTOS DE VENTA
Capítulo XVIII 1
1. Objetivo
1.1. Establecer los lineamientos operativos para garantizar la interoperabilidad de

tarjeta presente con contacto y contactless en producción entre dispositivos punto
de venta, medios de acceso, el estándar EMV Full, sus factores de autenticación
y la interacción con los demás capítulos de este manual operativo.
1.2. Establecer los lineamientos operativos para garantizar la interoperabilidad de

operativas con tarjeta no presente, sus factores de autenticación y la interacción
con los demás capítulos de este manual operativo.
2. Alcance
2.1 Estos laboratorios que en lo sucesivo se denominarán LACPI (Laboratorio

Certificador para Pruebas de Interoperabilidad), cuentan con autonomía y
autoridad para determinar si la Interoperabilidad y mensajería cumplen con esta
normativa y estándares.
2.2 Validar todos y cada uno de los procesos operativos correspondientes al correcto
funcionamiento de los medios de acceso con tecnología EMV FULL y tarjetas en
la transaccionalidad nacional para asegurar un nivel de servicio a los clientes y
cumplir con los estándares y requerimientos de las autoridades.
2.3 Validar todos y cada uno de los procesos operativos correspondientes al correcto
funcionamiento de los medios de acceso con tecnología EMV contactless y
tarjetas en la transaccionalidad nacional para asegurar un nivel de servicio a los
clientes y cumplir con los estándares y requerimientos de las autoridades.
Verificar la totalidad de dispositivos, versiones, marcas, modelos, operativas y

aplicativos de entrada por ejemplo: medios de acceso, cajas registradoras (ECR y
PinPad), puntos de venta móviles (MPos), cajeros por incidencia (ATM’s) o
cualquier otra aplicación que acepte y procese las tecnologías de pago EMV Full
así como EMV contactless. Incluyendo la fecha de actualización en el cambio de
llaves del Emisor que se integren al intercambio de RED MX, la cual se ejecuta
con dos tipos de validaciones según corresponda:
- La interoperabilidad de acuerdo al Anexo 33 (matriz de pruebas para

operativas con tarjeta presente).
- Anexo 33B (matriz de pruebas para operativas de tarjeta no presente).
- Validación del contenido correcto e íntegro de acuerdo a lo definido en el

punto 6 de este capítulo.
Capítulo XVIII 2
2.4 Se deben compartir y comparar los resultados en los logs de autorizaciones
certificados entre los LACPIs, para garantizar que la información reflejada en los
logs sea congruente entre las Cámaras cuando la transacción sea de intercambio.
2.4.1 En caso de existir diferencia, se compartirán los logs de las transacciones

con diferencias para su análisis.
2.5 Verificar que las instituciones Emisoras y Adquirentes registrados en el Anexo 29

(Instituciones Participantes en el Intercambio Nacional) cumplan con los
lineamientos y procedimientos de este manual operativo.
3. Responsabilidades
3.1 Es responsabilidad de las instituciones que sus medios de acceso, dispositivos y

tarjetas se sujeten a las pruebas o certificaciones realizadas por los Titulares de
Marca. Las pruebas de Interoperabilidad en el laboratorio “NO SUSTITUYEN”
la certificación de las marcas, por lo que se podrá dar inicio a la certificación en
LACPI sin contar con los certificados de las marcas.
Es responsabilidad de las instituciones entregar los certificados de las marcas,

durante o posterior a la certificación en LACPI.
3.2 Responsabilidad LACPI
§ Revisar y asegurar que los Emisores y Adquirentes cumplan con lo

establecido en el Anexo 34 PDP (Paquete de Dispositivos de Prueba) y
Anexo 35 PTP (Paquete de Tarjetas Productivas) de este Manual Operativo.
§ Contar con un inventario de entradas y salidas de los mismos, los cuales

tienen que ser registrados en cada uno de los LACPIs o concentrados en el
Control de Insumos.
§ Los LACPIs son responsables de recibir y enviar a sus contrapartes los

insumos que lleguen de sus Emisores, llevando el control de entrada y salida
así como su recolección cuando estos tengan que ser remplazados.
§ Realizar pruebas con la totalidad de dispositivos, versiones, marcas,

modelos, operativas y aplicativos de entrada en todos los medios de acceso
de acuerdo a su tipo de operativa y que cumplan con su totalidad del Anexo
33.
§ Para el caso de medios de pago distintos a tarjetas físicas se debe validar

las diferentes capacidades de modo de entrada (ejemplo: Wallet, stickers,
etc.).
§ Para las pruebas de nuevos dispositivos, versiones, plataformas, o

aplicaciones que acepten la tecnología EMV FULL y sus actualizaciones, se
realizan en las instalaciones del LACPI. Para el caso de ECR e Interredes,
Capítulo XVIII 3
las pruebas pueden realizarse en el laboratorio o en el sitio del receptor de
pago.
§ Para las pruebas de un nuevo BIN / template, cambio de llaves o diferentes

personalizadores en los medios de acceso, con aplicaciones que acepten
la tecnología EMV FULL se realizan en las instalaciones del LACPI.
§ Realizar un diagnóstico del resultado de las pruebas incluyendo

herramientas de diagnóstico (SmartSpy), log de autorizaciones y el Anexo
4I de este manual operativo y cuando se detecten problemas de
interoperabilidad, se debe emitir un reporte al solicitante el cual contenga el
detalle del hallazgo.
§ Entregar un plan de trabajo a cada institución y laboratorio con las fechas de

ejecución para cada BIN y dispositivo a validar.
§ Registrar BIN y dispositivo verificado y autorizado por cada LACPI a través

de la aplicación CIAT (Control de Inventarios de Aplicaciones y Templates),
esta información contempla la relación BIN / template o dispositivo /
aplicación / versión.
§ El LACPI Adquirente debe validar que el PDP cumpla con las características
descritas anteriormente e ingresarlas a su inventario para uso exclusivo del
LACPI, en caso contrario debe notificar las inconsistencias y devolverlos al
Adquirente en un plazo no mayor de 3 días hábiles.
§ El LACPI debe enviar un reporte cuando aplique a su Cámara de

Compensación de las transacciones procesadas para generar las
devoluciones, máximo al segundo día hábil de acuerdo a la fecha de su
intercambio, de no ser así este absorberá los costos financieros y moratorios
que se genere en cada cuenta.
§ El LACPI debe enviar un reporte a su contraparte, cuando sea solicitado por

el Emisor del medio de acceso que incluya las transacciones y devoluciones
realizadas en dicho periodo.
§ El LACPI Emisor debe validar que el PTP cumpla con las características
descritas en el punto 3.4 Responsabilidades del Emisor e ingresarlas a su
inventario, en caso de que no cumpla con las características físicas debe
notificar y devolverlo al Emisor en un plazo no mayor de 3 días hábiles.
§ Los LACPIs deben registrar en el CIAT el Anexo 35 y los PTP

correspondientes a cada uno de ellos, acordando la fecha de revisión en un
plazo máximo de 3 días hábiles por parte los responsables LACPI.
§ Los LACPIs deben notificar al Árbitro Operativo cuando en los tiempos de

remediación no se cumpla el plan de trabajo de acuerdo con la Penalización
32.
§ Cuando exista una incidencia que requiera la intervención de los LACPIs,

los laboratorios deben revisar el problema utilizando las herramientas de
diagnóstico con las que cuentan.
Capítulo XVIII 4
§ Los LACPIs deben entregar un reporte mensual del estatus de los BINes de
su contraparte que incluya: estatus de la certificación, estatus de
funcionalidad y otras observaciones que se consideren pertinentes.
§ Si aplica, se debe generar un reporte de problemas de interoperabilidad.
3.2.1 Insumos de LACPI

§ Área asignada y exclusiva con acceso restringido solo para personal
LACPI ya que esta área es independiente de las Cámaras de
Compensación, además de contar con área de operación para la
ejecución de pruebas de los medios de acceso y espacio suficiente
para que los Bancos Adquirentes o Emisores puedan realizar
validaciones especiales dentro del Laboratorio con personal de LACPI.
§ Políticas de seguridad físicas y lógicas.
§ Caja de seguridad para el resguardo de tarjetas y medio de acceso

dentro de Laboratorio.
§ Módulo de resguardo de herramientas de validación.
§ Los LACPIs no pueden prestar las tarjetas o dispositivos para una

prueba diferente a las funciones de este capítulo, a menos que cuente
con autorización escrita del Emisor o del dueño del dispositivo y se
debe monitorear la actividad de las tarjetas que salen del LACPI y
asegurarse de que sean devueltas en un tiempo específico. Asimismo,
debe tener un control de préstamo de estas situaciones.
§ Mantener el inventario actualizado de aplicaciones ingresadas para su

certificación.
§ Capacidad de conectar dispositivos locales y remotos (Dial Up,

Internet, GPRS, TCP/IP, etc.)
§ Implementar mejores prácticas o herramientas conforme la evolución

del mercado lo requiera.
§ La estructura de LACPI es un ambiente productivo para garantizar el

correcto funcionamiento en línea y batch.
§ Debe contar con afiliación(es) productiva(s) que soporten todas las

operativas tales como hotel, retail, restaurante, arrendadora, etc.
§ El LACPI debe contar con dispositivos espía (ejemplo: SmartSpy,

Collis) útiles y actualizados para su uso en las tareas que el LACPI
realiza.
§ Es responsabilidad de los participantes en la RED MX proporcionar a

LACPI estos dispositivos.
Capítulo XVIII 5
§ Es responsabilidad de LACPI mantener en perfectas condiciones
dichos dispositivos.
§ El LACPI debe contar con acceso a plataformas para transacciones de

e-Commerce.
§ El LACPI debe realizar la validación de los Tokens PO (a solicitud del

participante) y PY cuando estén poblados.
3.3 Responsabilidad Adquirente
§ Entregar de acuerdo al Anexo 34 de este Manual Operativo a su LACPI los

dispositivos en buenas condiciones, completos y las relaciones de sus
terminales, aplicativos y versiones. Esta información es considerada
confidencial y exclusivamente será conocida por el Adquirente, su LACPI y
el Árbitro Operativo de acuerdo a su documento de confidencialidad.
§ Verificar los dispositivos, aplicaciones y versiones que utilicen la tecnología

de contacto y sin contacto en los LACPIs.
§ Los Adquirentes deben mantener actualizadas las versiones de sus

dispositivos en los LACPIs, con un máximo de cuatro incluyendo la última
productiva.
§ Entregar afiliaciones exclusivas para el LACPI con una cuota de intercambio

cero.
o Verificar con su LACPI que éste cuente con los dispositivos, versiones
y aplicaciones actualizadas que operan en el mercado.
o Entregar para su verificación las nuevas aplicaciones, dispositivos y

equipos ya productivos antes de la instalación en los Receptores de
Pagos.
§ Verificar que su LACPI realice un plan de trabajo así como validar los
resultados y reportes de las pruebas con sus dispositivos / aplicaciones /
versiones y su publicación en la aplicación CIAT.
§ Durante el proceso de Certificación LACPI, cuando existan problemas de

interoperabilidad y/o en la calidad de datos, el Adquirente debe recibir un
reporte con dichos problemas.
§ El Adquirente debe hacer la recolección de sus dispositivos cuando el LACPI

notifique que estos ya no son funcionales, en un lapso no mayor a 30 días,
dicha notificación se enviara nuevamente al día 15, en caso contrario se
procede a la destrucción del equipo al vencimiento del plazo.
§ El Adquirente debe informar altas, bajas o cambios de sus dispositivos en

cuanto a marcas, modelos, llaves y versiones activas, etc. de manera
continua a los LACPIs, con una compulsa cada 6 meses entre los LACPIs
para la actualización o validación en el CIAT.
Capítulo XVIII 6
§ Para poder certificar una plataforma e-Commerce se debe dar acceso a la
misma.
3.4 Responsabilidad Emisor
§ Verificar que su LACPI cuente con las tarjetas \ BINes templates

actualizadas que operan en el mercado. Así como sus medios de pago,
actualizados a su última versión.
§ Entregar a su LACPI las tarjetas:
o BINes existentes con un nuevo template.
o BINes nuevos con un template nuevo.
o Cuando es el mismo template pero cambia de proveedor.
§ Entregar a su LACPI los medios de pago:
o Por cada sistema operativo soportado.
o Por cada producto que tengan disponible. Por ejemplo (stickers,

móviles, pulsera, etc.)
§ Debe generar y entregar un PTP por cada LACPI Adquirente, mismo que
debe ser entregado a su LACPI mediante el Anexo 35, cuando un BIN opere
con diferentes productos y estos tengan diferentes templates deben
desglosarlo e identificarlo en el Anexo 35.
§ Verificar que su laboratorio realice un plan de trabajo así como validar los
resultados de las pruebas con sus BINes / templates.
§ Verificar que el LACPI a través de su Cámara de compensación aplique las

devoluciones a sus tarjetas de las pruebas realizadas en un plazo no mayor
a 4 días hábiles posteriores al posteo de las mismas, para lo cual el Emisor
cuenta con 20 días naturales para realizar su reclamación mediante correo
electrónico a través de su LACPI, de lo contrario asume los costos derivados
del proceso.
§ Los insumos deben ser entregados con las siguientes características:
o Como mínimo una tarjeta para cada LACPI de cada BIN, template,
proveedor que opere en la RED MX o cuando exista un cambio en el
template, lote (solo si cambió el proveedor del chip o tarjeta) o todo lo
que implique un cambio en la aplicación del chip, así como para un
nuevo BIN dual EMV interface (con contacto y sin contacto) y banda
magnética o solo banda magnética, esto incluye los wallets e
incluyendo los BINes virtuales.
§ Para la verificación de un BIN, debe encontrarse vigente en la aplicación de

BIN Manager.
Capítulo XVIII 7
§ Las tarjetas para las pruebas deben generarse bajo las siguientes
características:
o La Institución debe generar en el nombre del Tarjetahabiente alguna

referencia para dirigirse al LACPI, como una nomenclatura o en su
caso colocar una etiqueta adherible de acuerdo a los ejemplos
detallados a continuación:
Nombre en Tarjeta
Versión Sistema
Producto Plataforma Proveedor
Template (Solo en Chip)
Operativo
(Solo en Chip) (Solo en Chip)
v 9.9 TDC VSDC Java GD = G&D
v 1.6 TDD VSDC Applet Advantis GE = Gemalto
v 1.0 TDM Local Advantis Duo OB =Oberthur
v 1.0 TDR CPA Multos AX = Axalto
Mchip Chrysalis FO = Forzaform
Mchip Lite Gemshare IN = Intelcav
Mchip Select StarDC MY = Mycard
Convengo
Mchip 4 Lite ST = ST Microelectronics
Element 6.4
Banda
TG = TGS Card Solutions
magnética
G4 = G4 Solutions
HG = Hogier Gartner & CIA
SA
Ejemplos de etiquetado de plásticos:
v9.9 TDC VSDC Java GD

v1.6 TDD M/C Advan Inf GE
v1.0 TDR Loc Advan ST OB
v1.0 TDM CPA Multos
Banda Magnética
§ Las tarjetas entregadas al responsable del Laboratorio, deben ser

productivas, siempre estar activas, tener una vigencia de acuerdo a las
políticas de cada Emisor y no contar con algún bloqueo interno de fraudes,
sin límite de transacciones diarias.
§ El monto disponible de cada tarjeta debe ser de $500.00 (quinientos pesos

00/100 m.n.) para la realización de pruebas adjuntando un comprobante de
saldo. Cualquier excedente al monto señalado en el párrafo anterior es
responsabilidad del Emisor.
§ Para el caso de tarjetas de chip deben tener cargadas llaves de EMV

productivas.
Capítulo XVIII 8
§ De acuerdo a los periodos de corte y de pago de las tarjetas y a los abonos
en los tiempos establecidos a las cuentas no deben generar intereses o
generación de anualidad.
§ El Emisor debe notificar si hay cambios en el proceso de autorización.
§ Si el medio de acceso presenta rechazos por parte del Emisor éste debe dar
solución en un periodo no mayor a 3 días hábiles desde su notificación.
o En caso de que la tarjeta esté en proceso de certificación y no se dé

solución a los rechazos, esta certificación será cancelada.
o En caso de que la tarjeta sea utilizada para las pruebas de certificación

de un Adquirente y no se dé solución a los rechazos, el BIN no será
considerado para dicha certificación.
§ Las tarjetas que se entregan al laboratorio deben ser generadas para el uso
exclusivo para las pruebas de Interoperabilidad, no deben ser:
o Tarjetas adicionales.
o Utilizadas previamente para alguna otra prueba.
§ Las tarjetas pueden ser blancas y/o con la leyenda de prueba.
§ Deben estar resguardadas por el LACPI por el tiempo de vigencia de la

tarjeta.
§ Las tarjetas deben ser enviadas directamente al responsable del laboratorio.
§ Las instituciones que incumplan con alguna de las características antes

mencionadas serán notificados por el responsable del laboratorio en un
plazo máximo de 3 días hábiles posteriores a la recepción y las tarjetas serán
devueltas para su reemplazo. En caso contrario, cualquier certificación
relacionada a esas tarjetas será cancelada.
§ El Emisor debe sustituir o reponer al LACPI toda tarjeta:
o Vencida o expirada.
o Dañada.
o Con llaves EMV vencidas.
o Rechazadas y que no se puedan reactivar.
o O cualquier otro motivo que no permita su uso en los LACPIs.
§ El Emisor debe hacer la recolección de sus insumos (tarjetas, wallets,

etc.) cuando el LACPI notifique que éstos ya no son funcionales, en un
lapso no mayor a 30 días y debe realizar el remplazo de los insumos
en un plazo máximo de 30 días.
Capítulo XVIII 9
§ El Emisor debe informar altas, bajas o cambios de sus plásticos, BINes
y templates en cuanto a marcas, llaves, proveedor, cambio de chip,
etc. de manera continua a los LACPIs, con una compulsa cada 6
meses entre los LACPIs para la actualización o validación en el CIAT.
A continuación se muestra un ejemplo de la entrega física hacia LACPI de las

tarjetas:
§ Cuando existan problemas de interoperabilidad y/o en la calidad de datos,

el Emisor debe recibir un reporte con dichos problemas.
4. Procedimiento operativo para verificar un BIN/Template de cualquier medio de

pago
4.1.- Verificación de tarjetas o cualquier medio de pago
La verificación de tarjetas o cualquier medio de pago se deben llevar a cabo de la

siguiente manera:
4.1.1.- Primera Etapa Anexo 33 Matriz de Pruebas LACPI del Manual

Operativo del CID para Medios de pago y BINES o Templates
Cada LACPI es responsable de capturar la información de verificación para

tarjetas y medios de pago de las instituciones, en la aplicación CIAT.
Capítulo XVIII 10
Tratándose de la verificación de un BIN/Template o un medio de pago, los
LACPIs deben ejecutar lo establecido en el Anexo 33.
Cuando los resultados de la matriz de pruebas son NO SATISFACTORIOS,

se continúa su ejecución y una vez finalizada, se inicia el proceso de pruebas
con herramientas de diagnóstico de acuerdo a lo establecido en el punto
4.1.3 Problema de interoperabilidad en el proceso de certificación para
medios de pago, BINes o Template.
4.1.2.- Segunda etapa de validación (Log´s) para medios de pago y BINes o

Templates
Se realiza validación de acuerdo a lo señalado en el punto 6 del presente

capítulo.
En caso de que uno o más valores no cumplan con las especificaciones

descritas en el punto 6 de este capítulo, se considera como prueba no
exitosa, en el caso de ser necesario inicia el proceso de pruebas con
herramientas de diagnóstico, en el caso existir afectaciones se da de alta la
inconsistencia de acuerdo a lo establecido en el punto 4.1.3 Problemas de
interoperabilidad para medios de pago y BINes o Templates.
4.1.3.- Problema de interoperabilidad en el proceso de certificación para

medios de pago, BINes o Templates.
Si el resultado de la validación con herramientas de diagnóstico indica que

la falla es responsabilidad probable de la tarjeta o medio de pago en proceso
de verificación, el LACPI que detecta la falla debe entregar el soporte de las
evidencias a fin de que la institución propietaria del BIN/Template o medio
de pago en un plazo no mayor a 5 días hábiles a partir de haber recibido las
evidencias de la falla, verifique la causa raíz y corrija el problema para poder
iniciar nuevamente el proceso de verificación, en caso contrario; se inicia
incidencia en la aplicación CIAT administrada por el Árbitro Operativo, con
el propósito de corregir la falla detectada en la tarjeta, de acuerdo a lo
señalado en el punto 5.2.
4.2.- Verificación de medios de pago, Tarjetas y Templates certificados en

Receptores de pago con Caja Registradora (ECR) o Interredes
4.2.1.- Primera Etapa Anexo 33 Matriz de Pruebas de este Manual Operativo.
Los LACPIs a través de sus Adquirentes deben establecer un plan de trabajo

con las fechas para la certificación en producción de los medios de acceso
ECR, versión, marca, modelo y aplicativo (o aplicativos).
Una vez que el Adquirente confirma el calendario, el LACPI tiene que dar de
alta en la aplicación CIAT, el medio de acceso que se va a validar y al
finalizar su verificación se indicará su resultado.
Cuando el LACPI cuenta en sus instalaciones con el medio de acceso ECR

realiza las pruebas en su laboratorio, en caso contrario asistirá a las
instalaciones del receptor de pago en la fecha de acuerdo en el plan de
Capítulo XVIII 11
trabajo establecido con el Adquirente. El Adquirente debe definir la afiliación
con la que se realiza la verificación y notificar a su LACPI al entregar el
calendario de pruebas.

se continúa su ejecución y una vez finalizada, se inicia el proceso de pruebas
con herramientas de diagnóstico de acuerdo a lo establecido en el punto
4.2.3 Problemas de interoperabilidad en medios de acceso, TPV’s y Tarjetas
en Receptores de pago con Caja Registradora (ECR) o Interredes.
4.2.2.- Segunda Etapa de Validación de log´s para medios de acceso, TPV’s

y Tarjetas en Receptores de pago con Caja Registradora (ECR),
Interredes.
El LACPI realiza validación de acuerdo a lo señalado en el punto 6 del

presente capítulo.
En caso de que uno o más valores no cumplan con las especificaciones

descritas en el punto 6 de este capítulo, se considera como prueba no
satisfactoria, en el caso de ser necesario inicia el proceso de pruebas con
herramientas de diagnóstico, en el caso existir afectaciones se da de alta la
inconsistencia de acuerdo a lo establecido en el punto 4.1.3 Problemas de
interoperabilidad en medios de acceso, TPV’s y Tarjetas en Receptores de
pago con Caja Registradora (ECR) o Interredes.
4.2.3.- Problemas de interoperabilidad con Tarjetas en Receptores de pago

con Caja Registradora (ECR) o Interredes.
Si el resultado de la validación con herramientas de diagnóstico indica que

la falla es responsabilidad probable del medio de acceso en proceso de
verificación, el LACPI que detecta la falla debe entregar el soporte de las
evidencias a fin de que la institución propietaria dispositivo, en un plazo no
mayor a 5 días hábiles a partir de haber recibido las evidencias de la falla,
verifique la causa raíz y corrija el problema para poder iniciar nuevamente el
proceso de verificación, en caso contrario se inicia incidencia en la aplicación
CIAT administrada por el Árbitro Operativo, con el propósito de corregir la
falla detectada el dispositivo, de acuerdo a lo señalado en el punto 5.2.
4.3.- Verificación de medios de acceso y Tarjetas certificadas en Receptores de

pago con e-Commerce
4.3.1.- Primera Etapa Anexo 33B Matriz de Pruebas de este Manual Operativo.
Los LACPIs a través de sus Adquirentes deben establecer un plan de

trabajo, el cual será proporcionado hasta que todos los insumos sean
recibidos con las fechas para la certificación en producción de los medios de
acceso en e-Commerce, versión de la aplicación, titulares de marcas
soportadas, dirección de la página del comercio o tienda en línea, usuario y
password asignados para pruebas LACPI, registro de productos “dummy”
para que sean seleccionado como productos para compra (no mayor a un
peso), afiliación.
Capítulo XVIII 12
El LACPI tiene que dar de alta en la aplicación CIAT, la plataforma e-
Commerce que se va a validar.
Las pruebas deben realizarse dentro de las instalaciones del LACPI.

se continúa su ejecución y una vez finalizada, se enviaran las observaciones
encontradas para su atención.
4.3.2.- Segunda Etapa de Validación de log´s para plataformas e-Commerce.
El LACPI realiza validación de acuerdo a lo señalado en el punto 6 del

presente capítulo.
En caso de que algún valor no cumpla con las especificaciones descritas en

el punto 6 de este capítulo, se considerará como prueba NO
SATISFACTORIA, en este caso se da de alta una incidencia de acuerdo a
lo establecido en el punto 4.3.3 Problemas de interoperabilidad en
plataformas e-Commerce.
4.3.3.- Problemas de interoperabilidad en plataformas e-Commerce.
VERIFICACIÓN DE TARJETAS Y MEDIOS DE ACCESO.

Si el resultado del análisis determina que la falla es responsabilidad de la
tarjeta o medio de pago en proceso de Verificación, el LACPI que detecta la
falla entrega las evidencias a fin de que la institución propietaria de la tarjeta
o medio de acceso pueda determinar la falla en un plazo no mayor a 5 días
hábiles especificando la falla a corregir para poder iniciar nuevamente el
proceso de Verificación.
VERIFICACIÓN DE LA PLATAFORMA E-COMMERCE.

Si el resultado del análisis determina que la falla es responsabilidad de la
plataforma, el LACPI Adquirente entrega evidencias a la institución
propietaria de la plataforma a fin de que ésta pueda determinar la desviación
en un plazo no mayor a 5 días hábiles especificando la falla a corregir para
poder iniciar nuevamente el proceso de Verificación
5. Registro de Problemas de Interoperabilidad
Cuando se detecte algún problema de interoperabilidad entre los medios de acceso,

BINes, Templates, aplicaciones o cualquier otro factor, se da inicio al proceso de
registro del evento mediante la aplicación CIAT para el conocimiento de los
participantes, de acuerdo a lo siguiente:
Capítulo XVIII 13
5.1 LACPI Emisor
5.1.1 Debe ingresar al módulo de incidencias de la aplicación CIAT, debiendo

cumplir con lo siguiente:
§ Que la tarjeta este vigente, activa y con fondos suficientes el día de la

transacción que presentó el problema de interoperabilidad.
§ Adicionalmente si se cuenta con un registro de la transacción en el log

Emisor, asegurarse que existe un problema de interoperabilidad y que
no se trata de casos aislados.
Si el BIN y Template de la tarjeta no cuenta con registro de previo de

Verificación ante LACPI, la aplicación no debe permitir iniciar el registro
problema de interoperabilidad, por lo cual el Emisor debe contactar a su
LACPI para que se le indique las acciones a seguir.
Cuando la solicitud de problema de interoperabilidad queda registrada, el

LACPI Emisor es responsable de validar las siguientes operativas:
EMV Full
§ Que las llaves de EMV configuradas en la tarjeta estén vigentes.
§ Que corresponda a una falla de interoperabilidad
§ Que la tarjeta sea capaz de autenticar a su Tarjetahabiente como le

fue programado en CVM List
§ Que el Emisor sea capaz de enviar scripts a su tarjeta y éstos sean

procesados en la tarjeta misma
Contactless
§ El Emisor a través de su tarjeta o medio de pago debe informar al

Adquirente el Tag 9F6E para que este sea utilizado para la generación
del Token CZ. En caso de ausencia del Tag, debe ser informado el
valor default de acuerdo a la Normativa contactless
§ El medio de pago debe ser capaz de autenticar a su Tarjetahabiente

como le fue programado
§ Que corresponda a una falla de interoperabilidad.
Doble Factor de Autenticación
§ Que los factores de autenticación fueron validados e intercambiados

en la mensajería a través de los Tokens PY definidos en el campo 63.
Capítulo XVIII 14
§ En caso que el Emisor requiera la validación del Tarjetahabiente con
el uso del Token PO debe notificarlo previo al inicio de las pruebas.
5.1.2 Una vez completada la lista de validación procede a la captura en la

aplicación CIAT administrada por el Árbitro Operativo, con la siguiente
información:
§ Descripción de la incidencia.
§ Institución que reporta.
§ Personal autorizado de la institución
§ Personal facultado de LACPI.
§ BIN de la tarjeta.
§ Selección de Template asociado.
§ Fecha de incidencia.
§ Número de afiliación.
§ [Folio automático generado por el módulo de la herramienta del árbitro

operativo]
5.1.3 La aplicación CIAT administrada por el Árbitro Operativo notifica la apertura

del problema de interoperabilidad a los responsables señalados en el Anexo
36 del manual operativo del CID (Responsables del Proceso LACPI), el
responsable de atender el problema de interoperabilidad es el LACPI que
valida la aplicación Adquirente de la afiliación
5.1.4 El LACPI Emisor valida que el medio de acceso esté verificado por LACPI o
se encuentre en proceso de verificación por el mismo LACPI,
5.1.5 Cuando el medio de acceso cuente con verificación de interoperabilidad o

se trate de un medio de acceso en campo en proceso de verificación, el
LACPI Adquirente utilizará las herramientas de diagnóstico para operativas
de tarjeta presente contacto y contactless generando información que apoye
al Adquirente a determinar el origen del problema de interoperabilidad. Para
operativas con tarjeta no presente LACPI Adquirente debe revisar los Logs
Transaccionales para apoyar al Adquirente a determinar el origen del
problema de interoperabilidad.
Si el resultado de la validación con herramientas de diagnóstico determina que la

falla está vinculada al Emisor durante el proceso de verificación, el LACPI Emisor
debe entregar las evidencias a la institución propietaria del medio de acceso en
un plazo no mayor a 5 días hábiles para que el Emisor corrija y pueda iniciar
nuevamente el proceso de Verificación, en caso contrario se inicia incidencia en
la aplicación CIAT administrada por el Árbitro Operativo, con el propósito de
corregir la falla detectada en la tarjeta, de acuerdo a lo señalado en el punto 5.2 y
continua el proceso de Verificación del medio de pago.
Capítulo XVIII 15
5.2 LACPI Adquirente
5.2.1 El LACPI Adquirente debe ingresar al módulo de problemas de

interoperabilidad de la aplicación CIAT, confirmando la siguiente lista de
validación:
§ Que el medio de acceso, aplicación y versión estén verificados por

LACPI.
§ Que las llaves de EMV configuradas en la TPV estén vigentes.
§ En el caso de e-Commerce que la página se encuentre verificada por

el LACPI
Adicionalmente cuando cuente con registro de la transacción en el log

Adquirente, asegurarse que existe un problema de interoperabilidad.
5.2.2 Una vez completada la lista de validación procede a la captura del problema
de interoperabilidad en la aplicación CIAT con la siguiente información:
§ Descripción de la incidencia.
§ Institución que reporta.
§ Personal autorizado de la institución
§ Personal facultado de LACPI.
§ BIN de la tarjeta.
§ Marca y modelo de medio de acceso, versión y aplicación o página de

comercio
§ Fecha de incidencia.
§ Número de afiliación.
§ [Folio Automático generado por el módulo de la herramienta del árbitro

operativo]
5.2.3 La aplicación CIAT notifica la apertura del problema de interoperabilidad a

los responsables señalados en el Anexo 36 de este contrato, el responsable
de atender el problema de interoperabilidad es el LACPI Adquirente de la
afiliación.
5.2.4 El LACPI Adquirente valida que el BIN este verificado por LACPI, en caso
contrario se rechaza el problema de interoperabilidad del Emisor.
5.2.5 Medios de acceso

Capítulo XVIII 16
Cuando el BIN/Template cuente con verificación de interoperabilidad, el
LACPI Adquirente debe utilizar las herramientas de diagnóstico para emitir
un reporte detallado de la causa del problema de interoperabilidad en un
plazo no mayor a 5 días hábiles y registrar en la aplicación CIAT el resultado
de su diagnóstico.
El LACPI de acuerdo al resultado de las herramientas de diagnóstico,

notifica al responsable (Emisor o Adquirente) por los medios que tengan
establecidos, en el caso de que la responsabilidad sea del Adquirente debe
presentar en un plazo máximo de 10 días hábiles un plan de trabajo que
corrija el problema y el LACPI debe registrar el plan de trabajo en la
aplicación CIAT máximo un día hábil posterior a la recepción del mismo.
La información que debe registrarse en el plan de trabajo es la siguiente:
§ Fecha de solución.
§ Número de medios de acceso afectados o porcentaje del total.
§ Fechas de Implementación inicio y término (roll out).
§ Descripción de la falla encontrada.
§ Descripción de la solución.
Cuando al 8º día hábil del plazo para la presentación del plan de trabajo no
exista registro del mismo, la aplicación envía una alerta a los LACPIs e
Institución responsable de acuerdo al Anexo 36, para notificar que el plazo
está por vencer.
El árbitro operativo es quien da el seguimiento al plan de trabajo entregado

por la institución, hasta que el plan de trabajo se concluya.
5.2.6 ECR/INTERREDES
Cuando el BIN/Template cuente con verificación de interoperabilidad, el

LACPI Adquirente debe utilizar las herramientas de diagnóstico para emitir
un reporte detallado de la causa del problema de interoperabilidad en un
plazo no mayor a 5 días hábiles y registrar en la aplicación CIAT el resultado
de su diagnóstico o en su caso recibir del Adquirente o del Comercio
proporcione un reporte detallado de la causa raíz del problema de
interoperabilidad que debe entregar en un lapso de 10 días a su LACPI
Adquirente para que LACPI registre en la aplicación CIAT el resultado del
diagnóstico.
El LACPI de acuerdo al resultado de las herramientas de diagnóstico,

notifica al responsable (Emisor o Adquirente) por los medios que tengan
establecidos, en el caso de que la responsabilidad sea del Adquirente debe
presentar en un plazo máximo de 10 días hábiles un plan de trabajo que
corrija el problema y el participantes debe publicar el plan de trabajo en la
aplicación CIAT.
Capítulo XVIII 17
§ Número de medios de acceso afectados o porcentaje del total.
Institución responsable de acuerdo al Anexo 36 del manual operativo), para
notificar que el plazo está por vencer.

§ Acciones a tomar una vez concluido el plazo establecido en el plan de

trabajo
o Solucionó el problema de interoperabilidad
De común acuerdo las partes deben llevar a cabo un proceso de

validación para certificar que el problema de interoperabilidad ha
sido corregido.
Roll Out
Los plazos para implementar la solución deben quedar
establecidos en el plan de trabajo y en caso de que la
Institución afectada no esté de acuerdo con las fechas
propuestas, debe presentar su inconformidad ante el
Árbitro Operativo.
Si un Adquirente requiere ampliación del plazo establecido en el

plan de trabajo, debe obtener autorización del Comité de
Tarjetas previo al vencimiento del plazo.
o Continúa el mismo problema de interoperabilidad posterior al

vencimiento del plan de trabajo
Debe iniciar nuevamente el proceso de Validación LACPI del

problema de interoperabilidad y el Árbitro Operativo decide la
sanción que esto le conlleva.
Capítulo XVIII 18
5.2.7 e-Commerce
Cuando el BIN/Template cuente con verificación de interoperabilidad o se

encuentre en campo en proceso de verificación, el LACPI Adquirente debe
utilizar las herramientas de diagnóstico y los Logs Transaccionales de
intercambio generando información que apoye al cliente a determinar el
origen del problema del problema de interoperabilidad y el cliente debe
registrar en la aplicación CIAT el resultado de su diagnóstico.
El LACPI de acuerdo al resultado del análisis de los log's certificados de

intercambio, notifica al responsable (Emisor o Adquirente) por los medios
que tengan establecidos, en el caso de que la responsabilidad sea del
Adquirente debe presentar en un plazo máximo de 10 días hábiles un plan
de trabajo que corrija el problema de interoperabilidad.
§ Dirección electrónica del comercio.
Institución responsable de acuerdo al Anexo 36, para notificar que el plazo
está por vencer.

5.3 Notificación por Penalización
El LACPI registra a través de la aplicación CIAT los dictámenes de los

problemas de interoperabilidad para que el Árbitro Operativo notifique a las
Instituciones involucradas con copia a los LACPIs la penalización
correspondiente a lo establecido en la penalización 32 del manual operativo.
Capítulo XVIII 19
6. Etapa de validación de log’s
6.1 Se realiza la validación de las pruebas de acuerdo a la matriz, la evidencia se

exporta y se mantiene en formato electrónico durante 1 año.
Los Adquirentes y Emisores pueden realizar la solicitud mediante petición

vía mail generada por funcionarios facultados (Anexo 36). Los valores y
elementos a verificar en el registro en línea o en el log de autorizaciones son
los siguientes:
§ Pos Entry Mode con valores “05x”, “07x”
§ Pos Entry Mode con valores banda “90x” y “80x”
§ Pos Entry Mode con valor digitado “01x”
§ Terminal Capability con valores “3”, “5” o “8”
§ Flag Service Code con valor “A”, “B” o “C”
§ Presencia e integridad de los siguientes elementos:
Nombre del elemento de dato Nombre del Tag Token Subcampo

CRYPTO-INFO-DATA 9F27 B2 2
TVR Resultado de la
95 B2 4
Verificación del Terminal (TVR)
ARQC 9F26 B2 5
AMT-AUTH Cantidad
9F02 B2 6
Autorizada
AMT-OTHER Otra Cantidad 9F03 B2 7
AIP Perfil de Intercambio de la
82 B2 8
Aplicación (AIP)
ATC Contador de
Transacciones de la Aplicación 9F36 B2 9
(ATC)
TERM-CNTRY-CDE Código de
9F1A B2 10
País del Terminal
TRAN-CRNCY-CDE Código de
5F2A B2 11
Moneda de la Transacción
TRAN-DAT Fecha de la
9A B2 12
Transacción
TRAN-TYPE Tipo de
9C B2 13
Transacción
UNPREDICT-NUM Número
9F37 B2 14
Aleatorio
ISS-APPL-DATA 9F10 B2 16
PAN SEQ NUMBER
5F34 B4 5
(Condicional)
Capítulo XVIII 20
CVM RESULTS Resultado de
9F34 B3 8
la validación del TH
ISS-SCRIPTDATA Template de
71 y/o 72 B6 2
script de Emisor
ARPC Authorization Response
91 B5 4
Cryptogram
§ Elemento de datos ARQC_VRFY (Token B4 Subcampo 8) con valores

“0”, “2” y “4”, para el caso de valores “1”, “3” se debe verificar con el
Adquirente está enviando estructura correcta o indicar al Emisor si
está ejecutando su validación adecuadamente.
6.2 Se realiza la validación de la matriz de pruebas inicial y general contra el

archivo de intercambio (Anexo 4), en un máximo de 72 horas posteriores a
la ejecución de las pruebas, la evidencia se mantiene en formato electrónico
durante 1 año. Los Adquirentes y Emisores pueden realizar la solicitud de
las evidencias, mediante petición vía mail generada por los funcionarios
facultados. Los valores y elementos a verificar para el archivo de intercambio
son los siguientes:
§ Pos Entry Mode con valores “05x”, “07x”
§ Pos Entry Mode con valores banda “90x” y “80x”
§ Terminal Capability con valores “3”, “5” o “8”
§ Flag Service Code con valor “A”, “B” o “C”
Nombre del elemento de dato Nombre del Tag Token Subcampo

CRYPTO-INFO-DATA 9F27 B2 2
TVR Resultado de la
95 B2 4
Verificación del Terminal (TVR)
ARQC 9F26 B2 5
AMT-AUTH Cantidad
9F02 B2 6
Autorizada
AMT-OTHER Otra Cantidad 9F03 B2 7
AIP Perfil de Intercambio de la
82 B2 8
Aplicación (AIP)
ATC Contador de
Transacciones de la Aplicación 9F36 B2 9
(ATC)
TERM-CNTRY-CDE Código de
9F1A B2 10
País del Terminal
TRAN-CRNCY-CDE Código de
5F2A B2 11
Moneda de la Transacción
Capítulo XVIII 21
TRAN-DAT Fecha de la
9A B2 12
Transacción
TRAN-TYPE Tipo de
9C B2 13
Transacción
UNPREDICT-NUM Número
9F37 B2 14
Aleatorio
ISS-APPL-DATA 9F10 B2 16
PAN SEQ NUMBER
5F34 B4 5
(Condicional)
CVM RESULTS Resultado de
9F34 B3 8
la validación del TH
ISS-SCRIPTDATA Template de
71 y/o 72 B6 2
script de Emisor
ARPC Authorization Response
91 B5 4
Cryptogram
§ Elemento de datos ARQC_VRFY (Token B4 Subcampo 8) con valores

“0”, “2” y “4”, para el caso de valores “1”, “3” se debe verificar con el
Adquirente está enviando estructura correcta o indicar al Emisor si
está ejecutando su validación adecuadamente.
§ Se verifica que en el token C4 en el sub-campo 12 viajen los valores

0,1, 2 o 5 cuando aplique.
Cuando se trate de una aplicación nueva, el Laboratorio debe revisar que el

ARQC que se imprime en el voucher sea el mismo que viaje en el Log de
Autorización.
6.3 Se realiza la validación de e-Commerce de la matriz de pruebas inicial y

general contra el archivo de intercambio (Anexo 4), en un máximo de 72
horas posteriores a la ejecución de las pruebas, la evidencia se mantiene en
formato electrónico durante 1 año. Los Adquirentes y Emisores pueden
realizar la solicitud de las evidencias, mediante petición vía mail generada
por los funcionarios facultados. Los valores y elementos a verificar para el
archivo de intercambio son los siguientes
§ Terminal Capability con valores “6”
Nombre del elemento de dato Token Valor permitido

Valor del token C4 C4 102510023660
Valor del token Q2 Q2 09
Presencia del CVV2 C0 – SC 8 1
Presencia de token PO en el mensaje de solicitud PO
Presencia de token PY en el mensaje de respuesta PY
§ Se verifica que en el token C4 en el sub-campo 12 viaje el valor 0.

Capítulo XVIII 22
6.4 En caso de que los valores cumplan con las especificaciones anteriormente
descritas se considerará la prueba como exitosa y se publica el resultado en
la aplicación CIAT de acuerdo a los puntos 6.1, 6.2 y 6.3.
7. Fases de la Verificación
Cuando se trate de la verificación de un BIN/Template, la validación se efectúa en dos

fases:
Proceso de validación de tarjeta en TPV, ECR e Interredes
Se ejecuta la matriz de pruebas del Anexo 33 en cada una de las TPV´s

instaladas en todos los LACPIs, al concluir satisfactoriamente esta fase el
BIN/Template se considera verificado, se registra en la aplicación CIAT.
Proceso de validación tarjeta en e-Commerce
Se ejecuta la matriz de pruebas del Anexo 33B en cada una de las

plataformas certificadas en todos los LACPIs, al concluir satisfactoriamente
esta fase el BIN/Template se considera verificado, se registra en la
aplicación CIAT
Cuando se trate de la verificación de una TPV, la validación se efectúa de acuerdo a lo

siguiente:
Proceso de validación de Dispositivo
Se ejecuta la matriz de pruebas del Anexo 33 con cada una de las tarjetas
con que cuenta el LACPI, al concluir satisfactoriamente esta fase la TPV se
considera verificada por LACPI, se registra en la aplicación CIAT y puede
ser liberado a producción.
Si en el proceso de autorización del Emisor la tarjeta solicita el NIP al

dispositivo, el LACPI debe verificar que los valores sean correctos.
8. Penas convencionales por incumplimiento
8.1 Incumplimiento de Presentación de Plan de Trabajo.
Adquirente:
Si un dispositivo o versión de aplicación vigente en el mercado presentó

problemas de interoperabilidad o no entrego aplicación para su certificación,
se venció el plazo de 10 días hábiles establecido en este capítulo y el
Adquirente no presentó alguno de los siguientes documentos:
Capítulo XVIII 23
§ Plan de Trabajo para la Corrección (incluyendo el número de TPV’s
que cuentan con esa versión/aplicación, marca y modelo), solo a su
LACPI Adquirente.
§ Respuesta de problema de interoperabilidad Resuelto.
§ Plan de trabajo de entrega de aplicaciones, donde la entrega no debe

ser mayor a 30 días hábiles.
Se hace acreedor a lo señalado en el punto b) de la penalización 32 del

capítulo V (Penas Convencionales por Incumplimiento) y cuenta con 10 días
hábiles adicionales para entregar el documento correspondiente a su plan
de trabajo, en caso de vencerse nuevamente la fecha compromiso, se
notifica al Árbitro Operativo para evaluar la aplicación del siguiente nivel (c,
d, e o f) de la penalización 32 del capítulo V).
8.2 Incumplimiento al Plazo de Corrección
Adquirente:
Se hace acreedor a lo señalado en el punto b) de la penalización 32 del

capítulo V y cuenta con 10 días hábiles adicionales para notificar la fecha de
corrección del problema de interoperabilidad, si el nuevo plazo excede de
60 días naturales, debe contar con la aprobación del Árbitro Operativo.
En caso de vencerse nuevamente la fecha compromiso, se notifica al Árbitro

Operativo para evaluar la aplicación del siguiente nivel (c, d, e o f) de la
penalización 32 del capítulo V.
8.3 Incumplimiento a la Verificación
Adquirente:
Si un dispositivo o versión de aplicación, fueron liberadas al mercado sin

cumplir con la Verificación LACPI.
El Adquirente se hace acreedor a lo señalado en el punto c) de la

penalización 32 del capítulo V y cuenta con 10 días hábiles para presentar
su corrección a verificación con su LACPI, en caso de vencerse nuevamente
la fecha compromiso, se notifica al Árbitro Operativo para evaluar la
aplicación del siguiente nivel (d, e o f) de la penalización 32 del capítulo V.
9. Proceso de validación de LACPI para una transacción de ARQC inválida
Cuando exista una transacción con valores de calificación en el ARQC “1” o “3” (Valores
del ARQC inválidos) de acuerdo a lo señalado en el punto 2 del capítulo XV de este
manual operativo y esta requiera ser presentada al proceso de controversias los
Emisores o Adquirentes deben enviar el log certificado y solicitar al LACPI el análisis de
Capítulo XVIII 24
la transacción para que este determine la integridad de los valores y tener evidencia o
no de poder presentar el contracargo al Adquirente.
El laboratorio cuenta con máximo 5 días hábiles con un tope de 50 casos para realizar
el análisis, dentro de su proceso el laboratorio integrará lo siguiente:
§ Confirmación de validación LACPI del dispositivo y BIN involucrados.
§ Análisis con el detalle de campos de acuerdo al documento de indicadores

aprobados entre los participantes de medios de disposición.
§ Resumen del evento presentado.
Para los casos en que los elementos disponibles no se puedan determinar de

quien es la responsabilidad, el laboratorio solicitará evidencia en sitio entre el
dispositivo y BIN involucrados.
Una vez emitido el análisis sobre la integridad de los datos es responsabilidad de la

institución el determinar la generación del contracargo o representación con los
procesos normales adjuntando la documentación determinada por LACPI.
Capítulo XVIII 25
10. Emisión de Resultados
Cuando el LACPI concluye su proceso de certificación sin encontrar problemas de

interoperabilidad ni en la calidad de los datos intercambiados, debe indicar en el portal
CIAT, la conclusión del proceso de certificación.
Adquirente:
• El LACPI con el que inicio su proceso de certificación debe “Verificar” la

información registrada del Anexo 34 entregada por el Adquirente y solicitar
al Árbitro Operativo, a través del portal CIAT, generar la “Constancia de
Verificación”.
• La revisión realizada por el LACPI es suficiente para determinar que el

Adquirente, su dispositivo y software (registrados en el Anexo 34) se
encuentran certificados ante el LACPI.
• El adquirente está obligado a realizar la certificación con un solo LACPI,

mientras que su dispositivo y su software no sufran cambios y estos ya se
encuentran certificados.
Si el LACPI detecta problemas de interoperabilidad y/o en la calidad de datos

intercambiados, debe notificar al participante para que corrija los problemas. Bajo las
políticas de cada LACPI, el LACPI puede rechazar el proceso de certificación; por lo que
será necesario que el participante inicie un nuevo proceso de certificación.
Emisor:
• El LACPI Inicial (con el que inició su proceso de certificación el Emisor) debe

“Verificar”, a través del portal CIAT, la información registrada del Anexo 35
entregada por Emisor.
• La revisión exitosa realizada por el LACPI Inicial es suficiente para

determinar que el Emisor y su combinación de BIN/Template tienen
permitido iniciar cualquier proceso de Incidencia de Aceptación como está
declarado en el Capítulo I del CID.
o Esto no excluye al Emisor a realizar el proceso de certificación del resto

de los LACPIs de la red.
o Los otros LACPIs deben confirmar al Árbitro Operativo, a través del portal
CIAT, el resultado del LACPI Inicial.
Capítulo XVIII 26
o Si un LACPI, distinto al LACPI Inicial, detecta un problema en la
interoperabilidad y/o en la calidad de datos intercambiados con el Emisor
y su combinación de BIN/Template debe:
§ Notificar al LACPI Inicial y analizar en conjunto los problemas de

interoperabilidad y/o de calidad de datos detectados.
§ Si los problemas de interoperabilidad y/o de calidad de datos son

causados por el Emisor y/o por su combinación de BIN/Template,
se revoca el privilegió del Emisor a levantar cualquier proceso de
Incidencia de Aceptación relacionadas al BIN/Template en
cuestión.
• Se podrá entregar al Emisor su “Constancia de Verificación”, generada por

el Árbitro Operativo hasta que todos los LACPIs de la red hayan verificado
de manera exitosa el BIN/Template.
Si el LACPI detecta problemas de interoperabilidad y/o en la calidad de datos

intercambiados, debe notificar al participante para que corrija los problemas. Bajo las
políticas de cada LACPI, el LACPI puede rechazar el proceso de certificación; por lo que
será necesario que el participante inicie un nuevo proceso de certificación.
Capítulo XVIII 27
CAPITULO XIX
CARGOS PERIODICOS
Capítulo XIX 1

Cargo Periódico
Es una transacción con cargo a la cuenta del tarjetahabiente con indicador de medio de acceso
Q2 valor 02, que se realiza en intervalos de tiempo acordados con el receptor de pagos, al amparo
de un contrato por concepto de servicios y/o productos.
Objetivo
Regular la operación de las transacciones locales de Cargos Periódicos en línea y Batch de Tarjetas,
así como la cancelación del cargo periódico a solicitud del tarjetahabiente.
Lineamientos:
Aplicar los filtros en el proceso de autorización de acuerdo con esta Normativa para Hard Decline y
Soft Decline.
En el filtro se debe Integrar la validación de la Afiliación-Tarjeta y la agrupación de afiliaciones

relacionadas con el mismo Receptor de Pagos (Grupo Cadena), para que el tarjetahabiente pueda
solicitar a su Emisor la cancelación del cobro de servicio de un número de contrato especifico con el
código de respuesta 83 “Tarjetahabiente no acepta el cargo periódico del contrato indicado”.
Para dar cumplimiento a los lineamientos se debe considerar lo siguiente:
a. El Adquirente debe solicitar al receptor de pagos integrar el número de contrato de hasta 20

posiciones alfanumérico justificado a la izquierda con espacios a la derecha, en caso de no
contener todas las posiciones.
b. El Adquirente debe incluir el campo contrato para ser enviado en el token R4 del mensaje de
autorización del campo 63, como se detalla en el documento de especificación técnica de
indicadores en línea.
c. Las Cámaras de Compensación deben integrar el campo (contrato) en el mensaje de la
autorización.
d. El Emisor debe manejar un Script en su Centro Telefónico para diferenciar en la llamada si
la cancelación de cargos recurrentes es por tarjeta, afiliación “código de respuesta 84” o es
por un contrato especifico número de tarjeta, afiliación, contrato “código de respuesta 83”.
e. Para que el Emisor pueda bloquear por código de respuesta 83 se requiere que el número
de contrato viaje en la mensajería.
f. En la mensajería de autorización en el campo 63 se debe integrar el número de contrato y
registrarlo en el log de autorizaciones.
g. El Emisor debe estar preparado para poder rechazar con el código de respuesta
correspondiente cuando el Cliente solicite una cancelación.
h. Las Cámaras de Compensación deben desarrollar los filtros Adquirentes solicitados, si algún
Emisor requiere algún filtro lo debe solicitar directamente con su Cámara de Compensación.
Premisas
Dando cumplimiento a la Ley Federal de Protección de datos personales, las Instituciones no deben
solicitar al Receptor de Pagos bajo ninguna circunstancia, documentación personal de su cliente,
para cualquier proceso operativo tales como copias de tarjetas, credencial de elector, pasaporte,
cartilla, tarjetas, etc., y cumplir con las reglas de RSIM o PCI.
El Emisor es responsable de dar de alta los Bines (Anexo 1 Relación de Bines Sujetos al Intercambio
local de acuerdo a lo establecido en el Capítulo I, punto 1.2 del Manual Operativo del CID) que
participan para ésta operativa.
Capítulo XIX 2

Los Adquirentes a través de su Cámara de Compensación son responsables del
control y manejo de los filtros mencionados en Reglas Operativas puntos 1, 2, 3 y 4
de este Capítulo, en caso de Incumplimiento, en el número de intentos, intervalos
establecidos o Bines participantes.
Los Adquirentes deben dar de alta sus Receptores de Pagos con operativa de cargos periódicos en
el giro que les corresponde de acuerdo a su actividad según el Capítulo XII del CID.
Reglas Operativas
Las Instituciones se obligan a respetar las siguientes reglas que deben estar parametrizadas en los
Adquirentes:
1. Bines Autorizados: Los Adquirentes solo pueden enviar solicitud de autorización de Cargos
Periódicos al Emisor, de transacciones cuyo BIN este dado de alta para esta operativa de
acuerdo a lo establecido en el Capítulo I de Reglas Generales del manual operativo, punto 1.2
del presente contrato y Anexo 1 (Relación de Prefijos sujetos al Intercambio Local) del CID.
El BIN de la tarjeta debe ser validado por los Adquirentes para verificar que está inscrito en el
Anexo 1 Relación de Prefijos sujetos al Intercambio Local del CID para funcionar en esta
operativa.
2. Bloqueo Hard Decline: El Adquirente no debe volver a enviar una solicitud de autorización al
Emisor de un número de tarjeta ya identificada con un bloqueo de este tipo, para estas
tarjetas, el Adquirente se obliga a mantener los números de tarjeta registrados en un archivo
en su Cámara de Compensación durante 180 días naturales, a partir del primer rechazo de
autorización del Emisor / Cámara de Compensación Emisora.
a. La Cámara de Compensación Adquirente genera un proceso de depuración en el

archivo de Hard Decline al día hábil siguiente a los 180 días naturales después de
su fecha de ingreso, tiempo máximo para que el Adquirente solicite al receptor de
pagos elimine el registro de su base de cobro; de lo contrario el Adquirente se hace
acreedor a la penalización 32 del Cápitulo V (Penas Convencionales por
Incumplimiento) de acuerdo al número de incumplimiento:
• Primer y Segundo incumplimiento, se aplica el punto “A”.
• Tercer incumplimiento, se aplica el punto “B”.
• Cuarto incumplimiento, se aplica el punto “C” y se bloquea al receptor de
pagos.
b. El emisor es responsable de rechazar una transacción cuando el Cliente haya
solicitado el bloqueo del cargo periódico (83 o 84).
Para el código de respuesta 83 (número de contrato y número de tarjeta), en una

transacción con indicador Q2 valor 02, la Cámara de compensación Adquirente
debe revisar:
o El BIN participa en Cargos Periódicos

o El número de tarjeta, afiliación, contrato no se encuentran en el filtro
de Hard Decline.
Capítulo XIX 3

o Que la tarjeta, afiliación, contrato con la que se presenta la
transacción no forma parte del mismo grupo cadena del cual el
tarjetahabiente solicito el bloqueo.
Para el código de respuesta 84 (número de tarjeta, afiliación y validación por grupo

cadena), en una transacción con indicador Q2 valor 02, la Cámara de
compensación Adquirente debe revisar:
o El BIN participa en Cargos Periódicos

o El número de tarjeta, afiliación no se encuentran en el filtro de Hard
Decline.
o Que la tarjeta, afiliación con la que se presenta la transacción no
forma parte del mismo grupo/cadena del cual el tarjetahabiente solicito
el bloqueo.
El Emisor es responsable de cualquier cambio de estatus en la tarjeta o el envío de un código de

respuesta.
El Adquirente debe capacitar a su Receptor de Pagos para que no envíe solicitudes de autorización
de Cargos Periódicos incluidas en el proceso de Hard Decline.
Las Cámaras de Compensación Adquirentes deben almacenar en forma diaria y generar el reporte
mensual a sus Instituciones de las transacciones de Hard Decline, mismo que debe contener No. de
Afiliación, Nombre del Comercio, No. de Tarjeta, No. de Contrato (Cuando aplique) de acuerdo al
Código de Respuesta, Fecha de la Transacción e Importe para que el Adquirente tenga un soporte
para revisarlo con su Receptor de pagos. (Flujo 1)
Cuadro 1
Hard Decline Códigos de Respuesta,
Transacción rechazada por el Emisor con los códigos:
Códigos ISO Códigos Base-24
04 Pick up (Recoger tarjetas)
909 Capture
07 Pick up card (Recoger tarjetas) 909 Capture
14 Invalid card Number (Número de tarjeta no valido)
058 Invalid Status
34 Suspected fraud (Sospecha de fraude)
909 Capture
35 Card acceptor contact acquirer, pick–up 909 Capture
36 Restricted card
902 NEG Capture Card
37 Card acceptor call acquirer security
909 Capture
41 Lost card 057 Lost or Stolen Card
43 Stolen card, pick-up 903 Stolen Card
56 No card record
206 CAF No Found
Q5 Delinquent 906 Delinquent
Capítulo XIX 4

N7 (84) Tarjetahabiente no acepta ningún cargo 84 Tarjetahabiente no acepta ningún cargo periódico
periódico de este comercio. de este comercio.
83 Tarjetahabiente no acepta el cargo periódico del 60 Tarjetahabiente no acepta el cargo periódico del
contrato indicado. contrato indicado.
3. Bloqueo Soft Decline (A): La Cámara de compensación Adquirente no debe volver a enviar una
solicitud de autorización al Emisor de un número de tarjeta / afiliación ya identificada con un bloqueo
de este tipo durante 30 días naturales. (Cuadro 2 Soft Decline (A) Códigos de Respuesta)
Cuando el estatus de la tarjeta o tarjetas tiene un bloqueo de Soft Decline (A), el Adquirente se
obliga a mantenerla en un archivo en su Cámara de Compensación durante 30 días naturales, a
partir del primer rechazo del Emisor con el fin de no volver a solicitar autorización para este número
de tarjeta y este se depura automáticamente a los 30 días de su fecha de ingreso. (Flujo 4)
Cuadro 2
Soft Decline (A) Códigos de Respuesta,
15 No such issuer 070 No IDF
45 Reserved for ISO use N/D
80 Approved national negative file hit OK 008 Approved National Negative
82 Private - reversal and adjustment (no security 054 No Security Module
module accounts)
87 Statement information not available 064 Bad Track Data
94 Duplicate transmisión 078 Duplicate Transaction
N0 Reserved for private use 074 Unable to Authorize
R1 Approved administrative request-out of window 953 Approved Administrative request out of window
T5 CAF STATUS=0 OR 9 089 CAF Status = 0 or 9
4. Bloqueo Soft Decline (B): Cuando la Cámara de Compensación Adquirente reciba un rechazo
a su solicitud de Autorización con estos códigos de respuesta, debe cumplir las siguientes reglas
para los subsecuentes intentos de autorización con la misma afiliación y tarjeta (Cuadro 3 Soft
Decline (B) Códigos de respuesta):
• En el día: El Receptor de pagos a través de su Adquirente no debe enviar la solicitud de

Autorización más de una vez.
• En el mes: El Recpetor de pagos a través de su Adquirente no debe enviar la solicitud de

autorización más de 8 veces (Incluyendo el primer rechazo), en intervalos no menores a 48 horas.
(Flujo 5)
Capítulo XIX 5

Cuadro 3
Soft Decline (B) Códigos de Respuesta,
Extracto del Documento Técnico de Indicadores
01 Refer to card issuer 088 Pleace Call
51 Not sufficient funds 076 Low Founds
02 Refer to card issuer’s 101 Issue Call
03 Invalid merchant 150 Merchant No File
13 Invalid amount 205 Invalid amount
78 Contact card issuer 005 Approved Blind
61 Exceeds withdrawal amount limit 095 Amount over maximun
65 Exceeds withdrawal frequency limit 082 Number of times used
06 Error 100 Unable to Process
30 Format error 069 Bad Message Edit
12 Invalid transaction 055 Invalid transaction
N8 Over floor limit 086 Over Floor Limit
P1 Over daily limit 107 Over Daily Limit
T4 Amount over máximum 106 Amount Over Maximum
57 Transaction not permitted 056 No support
05 Do not honor 050 Decline
52 No checking account N/D
O8 Bad PBF 099 Bad PBF
5. Cancelación del Servicio de Cargos Periódicos
• Cuando en el proceso de solicitud de autorización un Emisor responde con el código de

respuesta “N7” (Base 24) ó 84 (ISO)), el Adquirente se obliga con su Receptor de pagos a
ya no enviar cargos periódicos posteriores, ya que el Tarjetahabiente solicitó a su Emisor la
cancelación de todo cargo periódico con ese Receptor de pagos a su número de tarjeta
(Flujo 6 Cancelación de Cargos Periódicos).
• Cuando en el proceso de solicitud de autorización un Emisor responde con el código de

respuesta “N6 (83)” (Base 24) ó “60 (83)” (ISO), el tarjetahabiente solicitó a su Emisor
cancelar sólo un número de contrato a su número de tarjeta, por lo cual, el Adquirente se
obliga con su Receptor de Pagos a ya no enviar cargos periódicos posteriores, a ese
número de contrato. (Flujo 6 Cancelación por Número de Contrato de Cargos
Periódicos).
6. Reactivación de Cargos Periódicos o Cambio de código de respuesta 83 al 84 o

viceversa o en algún otro a petición del emisor.
Código 83
Capítulo XIX 6

a. Cuando el tarjetahabiente solicite la reactivación de su cargo periódico debe de
seguir los siguientes pasos.
• Notifica a su Institución Emisora, que desea reanudar el servicio de cargos
periódicos con el Comercio con el número de contrato que desea reactivar
b. El Emisor debe desbloquear el servicio o solicitar a través del medio establecido a
su Cámara de Compensación emisora que lo realice.
c. La Cámara de Compensación emisora debe solicitar a la Cámara de Compensación
adquirente su desbloqueo, en un periodo no mayor a 8 días hábiles. (Flujo 8)
d. La Cámara de Compensación adquirente debe notificar a su adquirente para que
este le indique a su comercio que puede enviar nuevamente cargos periódicos a ese
contrato.
Código 84
a. Cuando el tarjetahabiente solicite la reactivación de su cargo periódico debe seguir

los siguientes pasos.
• Notifica a su Institución Emisora, que desea reanudar el servicio de cargos
periódicos con el Comercio
• Esperar 10 días hábiles para ir con el Comercio y firmar un nuevo contrato
de Cargos periódicos.
b. El Emisor debe desbloquear el servicio en su autorizador o solicitar a través del
medio establecido con su Cámara de Compensación contratada que lo efectué, y
que ésta solicite el desbloqueo con el procedimiento que establezcan de la cuenta a
la Cámara de Compensación adquirente que administra la base con los rechazos del
emisor, para está operativa.
c. La Cámara de Compensación adquirente debe desbloquearla en la base construida
para está operativa, en un periodo no mayor a 8 días hábiles. (Flujo 7)
Petición del emisor
a. Cuando el emisor solicite la reactivación de un cargo periódico debe de seguir los

siguientes pasos.
• El Emisor debe desbloquear el servicio en su autorizador o solicitar a través

del medio establecido con su Cámara de Compensación contratada que lo
efectué, y que ésta solicite el desbloqueo con el procedimiento que
establezcan de la cuenta a la Cámara de Compensación adquirente que
administra la base con los rechazos del emisor, para está operativa.
• La Cámara de Compensación adquirente debe desbloquearla en la base
construida para está operativa, en un periodo no mayor a 8 días hábiles.
(Flujo 5)
• La Cámara de Compensación adquirente debe notificar a su adquirente para
que este le indique a su comercio que puede enviar nuevamente cargos
periódicos a ese contrato.
7.- Incumplimiento por exceso de envío de transacciones
Las Cámara de Compensación deben generarle a sus Instituciones un reporte mensual de las
transacciones de Hard Decline y Soft Decline que exceden los parámetros permitidos que
contenga No. de Afiliación, Nombre del Comercio, No. de tarjeta, No. de Contrato de acuerdo al
código, Código de Respuesta, Fecha de la Transacción y Monto.
Capítulo XIX 7

El detalle de la información y cobro de las autorizaciones excedidas de acuerdo al capítulo IV Costo
de servicio inciso C) por solicitud de autorización debe ser entregada a la contraparte, y en su caso
para reclamo de aquellas operaciones que no esté de acuerdo (entregando su detalle del por que no
esta de acuerdo). El medio de cobro debe ser por cobro misceláneo, con el código “104- Rechazo de
Autorizaciones por Cargos periódicos”, solicitadas fuera de rango de todos los comercios afiliados a
dicho Adquirente.
El detalle de la información y solicitud de cobro de las autorizaciones excedidas del mes inmediato
anterior debe solicitarse máximo al 10º día hábil del siguiente mes, cuando aplique.
Una vez que se genere el primer rechazo por Soft Decline A, iniciara un contador de 30 días
naturales para ese Número de Tarjeta-Afiliación, y en caso de que el comercio envíe una transacción
fuera de los rangos de tiempo estipulados, el Adquirente devolverá el costo de servicio al Emisor.
El Costo de Servicio establecido en el Punto “C” del Capítulo IV Costos de Servicios se debe de
regresar cuando el Adquirente exceda los parámetros establecido en esta normativa.
En el caso de que se exceda las solicitudes de autorización de acuerdo a esta normativa, el Emisor
cuando aplique, puede ejercer el cobro de las solicitudes de autorización ya pagadas fuera de
parámetros de forma manual o automática dentro de los 5 primeros días hábiles de cada mes, vía
misceláneo “104 Rechazo de Autorizaciones por Cargos Periódicos”.
Si el Comercio envía un cargo periódico con un medio de acceso diferente y se comprueba que es
cargo periódico se envía un Contracargo 41 opción I de acuerdo al (Flujo 10).
8.- Extracto del Documento Técnico de Indicadores
Si el Emisor autoriza, asume la responsabilidad de la transacción siempre y cuando el Adquirente

envíe de manera correcta los indicadores en línea.
En las transacciones de Cargo periódico, el Emisor no debe validar la fecha de vencimiento de la

tarjeta, ni el CVV2/CVC2, al momento de autorizar una transacción.
Para las transacciones de cargo periódico No aplica el Stand in.
En el proceso Batch todas las transacciones de Cargos periódicos deben identificarse con en el
Anexo 4 “Archivo de Intercambio” Lay Out de 350 posiciones con el medio de acceso valor 02 en el
campo 34, posiciones 169 – 170 del archivo de intercambio.
Estos son los valores que el Adquirente debe enviar como obligatorios para esta operativa.
Token Descripción Valores

Adquirente graba, Emisor lee
Token Q2 Indicador del medio de acceso que realiza la
[Subcampo 1] solicitud de autorización 02 = Sistema de Cargos Periódicos
Capítulo XIX 8

Token C4 Datos de la Terminal
4 Indicador de 14 14 1 9(01) Indicador de la presencia del tarjeta

presencia del habiente en la TPV:
tarjetahabiente 4 = El tarjetahabiente no está presente
5 Indicador de 15 15 1 9(01) Indicador de presencia de la tarjeta en la

presencia de tarjeta TPV:
1 = La tarjeta no está presente.
Token R4 indica el número de contrato
Columnas Titulo Tipo de Detalle Ejemplo de dato

dato
H-1 EYE-CATCHER X(01) Header de Token: Identificador de inicio de !
Token.
! = valor fijo (Admiración Cerrada)
H-2 USER-FLD1 X(01) Header de Token: Primer Separador.
“ “ = valor fijo (Espacio en blanco)
H-3 Identificador del X(02) Header de Token: Identificación del Token R4
Token que se está enviando.
30 = valor fijo
H-4 Longitud de datos 9(05) Header de Token: Longitud de la sección de 00020
datos del Token.
00066 = valor fijo
H-5 USER-FLD2 X(01) Header de Token: Segundo separador.
“ “ = valor fijo (Espacio en blanco)
1 Número de PIC X(20) Número de contrato sobre el que se realice ABC123456789········
contrato el cargo recurrente.
El campo debe estar justificado a la

izquierda, rellenando con espacios las
posiciones que no sean ocupadas.
El token no pueden contener sólo espacios,

vacío o ceros.
Extracto Descripción del Archivo de Intercambio

Lay Out de 350 posiciones
Campo Descripción Posiciones Contenido

Identificación del medio de acceso
que realiza la solicitud del autorizador
34 Indicador del Medio de Acceso 169-170
02 = Sistema de Cargos Periódicos
Incumplimiento en el envio de los Indicadores
Capítulo XIX 9

Cuando una Camara de Compensacion Emisora o el Emisor detecte inconsistencia en los valores de
los indicadores de cargos períodicos o se detecte al Adquirente enviando transacciones de cargos
períodicos con un Token Q2 diferente a 02, a excepción del token R4, debe enviar el reporte con su
soporte al árbitro operativo para generar lo siguiente:
Amonestación y cuenta con un plazo de 15 días hábiles a partir de la notificación de la

amonestación, para entregar su plan de corrección, dicha corrección no debe exceder 3 meses.
a) En caso de vencerse el plazo señalado en el plan de corrección, el Adquirente se hace

acreedor al punto c) de la penalización 32, y cuenta con un nuevo plazo de 20 días hábiles
para realizar la corrección.
b) En caso de no presentar su plan de trabajo señalado, se hace acreedor a lo establecido en

el punto c) de la penalización 32.
En caso de un nuevo incumplimiento en cualquiera de los dos casos, se notifica al Comité de

Tarjetas para solicitar el bloqueo de la afiliación.
Flujo de Operación Diaria (1)
(i)
Capítulo XIX 10

Flujo de Comercio (2)
Flujo de Hard Decline (3)
Capítulo XIX 11

Flujo de Soft Decline A (4)
Capítulo XIX 12

Flujo Soft Decline B (5)
Capítulo XIX 13

Flujo de Cancelación (6)
Capítulo XIX 14

Flujo de Reactivación por el Emisor (7)
Capítulo XIX 15

Reactivación por Afiliación / Contrato (83) (8)
Capítulo XIX 16

Reactivación por Afiliación (84) (9)
Capítulo XIX 17

Flujo de Incumplimiento (Flujo 10)
Capítulo XIX 18

CAPÍTULO XX
TRANSACCIONES
ACTIVADAS POR EL
TARJETAHABIENTE (CAT)
Capítulo XX 1

ANTECEDENTES
Los participantes acuerdan regular por medio del presente Capítulo, transacciones con
Tarjetas en Terminales Desatendidas en Receptores de Pagos, así como la resolución de
controversias derivadas del intercambio de esta operativa.
Las Transacciones realizadas por el Tarjetahabiente se generan a través de dispositivos

electrónicos que no requieren expresamente ser atendidos por un dependiente y que se
denominan Terminales de Aceptación Desatendidas (CAT = Cardholder Activated
Transaction).
1. REGLAS GENERALES
Los participantes acuerdan que los giros que cumplan con lo señalado en esta normativa,
están autorizados para operar CAT y que existen 3 niveles de Transacciones, cada una
se sujeta a Reglas específicas de aceptación y autorización por los Emisores.
Los diferentes niveles de CAT se establecen en función del nivel de la transacción y no

del equipo o terminal.
Los participantes acuerdan que ésta Operativa aplica para productos de Crédito y Débito.
Los participantes acuerdan que las transacciones con importes mayores a los
establecidos para cada uno de los tres niveles, son responsabilidad del Emisor si las
autoriza.
El Adquirente es responsable de establecer y validar que sus Receptores de Pagos se

apeguen a las normas de Aceptación para ésta Operativa.
El Adquirente es responsable de enviar los Tokens de CAT de acuerdo a los indicadores

señalados en el Anexo 4I. Q2 valor 19, C4 subcampo 1 valor (1), subcampo 4 valor (0),
subcampo 5 valor (0), subcampo 10 valor (1, 2, o 3) y subcampo 12 valor (3).
Las cámaras de compensación deben estar preparados para transmitir los valores de esta
operativa.
2. CAT SIN PIN (Nivel 2 o 3)
Las Instituciones acuerdan las siguientes condiciones de aceptación para las

transacciones “CAT sin PIN”:
• El Adquirente debe enviar los indicadores determinando que es una

transacción CAT para que lo valide el Emisor, Q2 valor 19, C4 subcampo 1
valor (1), subcampo 4 valor (0), subcampo 5 valor (0), C4 subcampo 10
valor (2) para nivel 2 o valor (3) para nivel 3 y subcampo 12 valor 3.
Capítulo XX 2

• El dispositivo debe aceptar o rechazar la transacción de acuerdo al código
de respuesta del Emisor.
• Es el Emisor quien debe efectuar las validaciones, el Adquirente solo envía
la solicitud de autorización.
Transacción Nivel 3
NIVEL 3
Monto máximo $250.00 M/N por transacción hasta
Monto de las
$2,000.00 por día a decisión del Emisor.
transacciones
Uno de los siguientes:
Método de autorización En línea (con lectura de datos del chip de EMV sin PIN)
En línea (mediante lectura de datos de la banda magnética)
NIVEL 2
Monto de las Monto mayor a $ 250.00 por transacción, hasta un monto
transacciones máximo a decisión del Emisor.
Método de autorización En línea (con lectura de datos del chip de EMV sin PIN)
En línea (mediante lectura de datos de la banda magnética)
3. CAT CON PIN (Nivel 1)
Las Instituciones acuerdan las siguientes condiciones de aceptación para las

transacciones CAT con PIN:
• Aceptar PIN de acuerdo a lo establecido en el punto 3 del capítulo XV

(CHIP EMV).
• El Adquirente debe enviar los indicadores determinando que es una
transacción CAT para que lo valide el Emisor, Q2 valor 19, C4 subcampo 1
valor (1), subcampo 4 valor (0), subcampo 5 valor (0), subcampo 10 valor
(1) y subcampo 12 (valor 3) El dispositivo debe aceptar o rechazar la
transacción de acuerdo al código de respuesta del Emisor.
• Es el Emisor quien debe efectuar las validaciones, el Adquirente solo envía
la solicitud de autorización
Capítulo XX 3

NIVEL 1
Monto de las transacciones Sin límite establecido, a decisión del Emisor.
En línea (con lectura de datos del CHIP + PIN off line de

Método de autorización
EMV).

Método de verificación del Verificación del CHIP + PIN off line
tarjetahabiente Verificación del PIN (con tarjetas de CHIP que cumpla
con los requisitos EMV).
Las Instituciones acuerdan que si la transacción es rechazada a decisión del Emisor por
superar el límite, estos deben responder con un código de respuesta ISO (05) y Base 24
(050) para que el dispositivo despliegue el mensaje “Transacción Invalida”.
Las Instituciones acuerdan que para ésta Operativa los montos máximos de aceptación
para cada uno de los Tipos de Transacciones Activadas por los Tarjetahabientes son los
establecidos en los tres niveles señalados en este capítulo, estos montos se pueden
modificar por acuerdo de las Instituciones.
4. CARACTERÍSTICAS DE LA OPERACIÓN CAT

• Lectura de CHIP con EMV o Banda.
• El Emisor es responsable de otorgar o rechazar la autorización de transacciones
que reciba de Fallback PEM (Pos Entry Mode) 80.
• El dispositivo CAT debe ser EMV y encriptar la transacción o enviarla por un canal
seguro de acuerdo a capitulo X publicado por la CNBV.
• Se limita a transacciones de compra y pago de productos o servicios.
• El número de tarjeta debe estar enmascarado en el recibo de acuerdo al Anexo 15
del Contrato de Aceptación de Tarjetas.
• Es decisión del Emisor autorizar las transacciones dependiendo del nivel de CAT.
• No aplica para retiro de dinero y solicitud de saldo.
• El CAT debe manejar el nivel 1, 2 ó 3, de acuerdo al tipo de operación.
5. CARACTERÍSTICAS DEL COMPROBANTE

La impresión del comprobante de compra es opcional cuando el cliente lo solicite.
En caso de que se imprima el comprobante se sugiere contenga los siguientes
datos:
• Fecha y hora de la operación

• Afiliación.
• Número de tarjeta presentando solo los últimos 4 dígitos.
• Tipo de tarjeta.(TDC ó TDD)
Capítulo XX 4

• No. Autorización
• Monto de la transacción
6. REQUISITOS QUE DEBE DE CUBRIR EL ADQUIRENTE

• Mandar los indicadores de acuerdo al documento técnico (Anexo 4I)
• Envía y graba en el log los valores Q2 valor 19 y el Token C4 subelemento 10 y 12
de acuerdo al documento de indicadores.
• No hay autorizaciones de stand-in para CAT.
• Asegurar que la terminal:
§ No dispense efectivo.
§ El dispositivo debe contar con señalización y tener el número
telefónico de servicio a clientes.
§ Proporcionar un comprobante de la transacción cuando el cliente lo
solicite.
7. REQUISITOS PARA EMISOR

• Validar los diferentes niveles de CAT antes de autorizar la transacción.
• Recibe y valida en línea los valores Q2 valor 19, C4 subcampo 1 valor (1),
subcampo 4 valor (0), subcampo 5 valor (0), subcampo 10 valor (1, 2, ó 3) y
subcampo 12 (valor 3).
• Los Códigos de Respuesta a una solicitud de Autorización que debe enviar son los
correspondientes a: “Aprobada”, “Fondos Insuficientes” y “declinada” /
“Transacción Invalida”.
8. SOLICITUD DE COMPROBANTES:
Cuando un Emisor solicite un comprobante, el Adquirente únicamente
proporcionará como documento comprobatorio el Anexo 18 (Log de Autorizaciones
Certificado), cuando este no contenga los datos mandatorios de acuerdo al Anexo
15 (Datos legibles y mandatorios que deben contener los documentos de tarjetas),
se pueden contracargar por código de razón 60 (Original o Copia recibida Ilegible
o con Datos Incompletos).
9. RESPONSABILIDADES
Para el caso de un cargo no reconocido por el Tarjetahabiente en los 3 niveles de
esta operativa, las transacciones son responsabilidad del Emisor, siempre y
cuando el Adquirente inicie la transacción e intercambie los Indicadores de CAT.
Cuando el Adquirente intercambie transacciones de terminales no atendidas y no

envíe los indicadores señalados en el punto 1 de esta normativa, es responsable
de las transacciones donde exista una reclamación del Tarjetahabiente, por lo que
el Emisor puede utilizar el código de razón 60 (Original o Copia recibida Ilegible o
con Datos Incompletos).
Capítulo XX 5

CAPÍTULO XXI
INTERCAMBIO DE TRANSACCIONES
CON TAG
Capítulo XXI 1
TRANSACCIONES TAG
OBJETIVO
Regular en el Contrato de Intercambio Doméstico las transacciones On Line o a
través de un archivo, derivadas del pago de un servicio ende un dispositivo
(Tag), ligado a un número de tarjeta, para realizar el pago de servicios.
TAG
Receptor/generador de ondas de radio, ligado a un número de tarjeta al cual se
carga la transacción y es utilizado para el cobro electrónico de servicios.
1.- REGLAS GENERALES:
1. Los giros autorizados para ésta operativa son los que se indican en el
Anexo 25 (Giros operativas especiales) del Manual Operativo del Contrato
de Aceptación de Tarjetas.
2. Cuando una transacción se realice a través de un dispositivo TAG, el

Adquirente debe enviar los indicadores en línea con el Token Q2 Valor 24 y
C4 Sub campo 5 valor 1 (La tarjeta no está presente) por lo que no envía el
CVV2/CVC2, fecha de vencimiento y no se emite un comprobante en línea.
3. El Emisor debe recibir y validar en línea los valores indicados en el punto

anterior de los indicadores para tomar la decisión de aprobar o rechazar la
transacción.
4. Ante la no emisión de un Comprobante por el servicio otorgado, el

comercio es responsable de proporcionarlo posteriormente, a petición de
sus clientes, sin injerencia en el proceso de las aclaraciones.
5. Para incluir un nuevo Giro a esta operativa, la solicitud debe ser presentada
para su aprobación y vigencia ante los participantes, una vez aprobada, se
actualiza el Anexo 25 (Giros operativas especiales).
6. Los Emisores que por cualquier situación mapean el indicador de TAG al

indicador Q2 con valor 2, no podrá generar contracargos de esta
transacción.
Capítulo XXI 2
FLUJO DE LA TRANSACCIÓN
2 SOLICITUD DE COMPROBANTES
2.1 La solicitud de Comprobantes deben ser atendidas mediante el
Comprobante de TAG Anexo 27A (Comprobante de TAG), que proporcione el
Receptor de Pagos por medio del Adquirente, el costo por atención de
Comprobantes es el que se indica en el punto “B” del capítulo IV (Costos de
Servicios) del Manual Operativo del Contrato de Intercambio Doméstico, de lo
contrario serán contracargados por código de Razón 79 (Copia u original del
Documento no Atendido).
Los datos mínimos mandatorios del comprobante TAG Anexo 27A

(Comprobante de TAG), se establecen en el Anexo 15 (Datos legibles y
Mandatorios que deben contener los Documentos de Tarjetas) del Manual
Operativo del Contrato de Intercambio Doméstico y son los siguientes:
1. Afiliación
2. Número de Dispositivo TAG
3. Número de Tarjeta
4. Fecha de Transacción
5. Hora de Transacción
6. Número de Caseta (cuando aplique)
7. Número de Carril (cuando aplique)
8. Identificador de Servicio
9. Importe
10. Autorización
Capítulo XXI 3
3 CONTRACARGOS
3.1 Los casos de contracargos por reclamación, donde especifica el

tarjetahabiente no haber contratado el servicio o no haber utilizado su
dispositivo en la fecha y hora señalados en el detalle de la transacción, se
pueden Contracargar por código de razón 41 opciones “E” o “F” del Capítulo II
(Resolución de Controversias) del Manual Operativo del Contrato de
Intercambio Doméstico.
Capítulo XXI 4
CAPÍTULO XXII
MOVILIDAD TARJETAS DE CRÉDITO
Capítulo XXII 1

OBJETIVO
Que las Instituciones Financieras permitan a los usuarios de Tarjeta de Crédito dar por terminado el
contrato de adhesión por conducto de otra Institución Financiera, transfiriendo el saldo total.
ALCANCE
Dar cumplimiento a las disposiciones en materia de transparencia aplicables a las instituciones de

crédito y sociedades financieras. Publicadas por la Comisión Nacional para la Protección y Defensa
de los Usuarios de Servicios Financieros el pasado 30 de Octubre 2014, en sus Artículos 23,25 y 26.
Facilitando entre las Instituciones Receptoras y Transferentes el proceso de Movilidad de Saldo, así
como los trámites de liquidación y cancelación de cuenta por parte de las Instituciones.
DEFINICION DE MOVILIDAD DE TARJETAS DE CRÉDITO
Es el servicio que ofrece una Institución Receptora a los tarjetahabientes que sean o no sus clientes,
a través de este servicio, la Institución Receptora ofrece la posibilidad de traer el saldo de la
Institución Transferente dando por cancelado el contrato de adhesión de Tarjeta de Crédito del
usuario solicitante.
PARTICIPANTES EN EL SERVICIO
1. CONDICIONES OPERATIVAS
Capítulo XXII 2

Para que el proceso de Movilidad de Saldo se realice de manera correcta, las Instituciones
Financieras participantes, deberán de cumplir:
Institución Receptora:
• Recibe por escrito en sucursal o cualquier medio que disponga la Institución, las solicitudes
de terminación de operaciones activas (Movilidad de Saldo).
• Cuenta con manuales que garanticen la seguridad, responsabilidad y eficiencia en el proceso
de la terminación de operaciones.
• Tramita Tarjeta de Crédito a nombre del Usuario, en caso de no contar con un crédito
existente.
• Lleva a cabo los trámites respectivos, bajo su responsabilidad y sin cobro de comisión
alguna.
• Genera Solicitud de Movilidad con la información necesaria y firma del solicitante en el
Formato de Movilidad impreso según corresponda.
• Comunica a la Institución Transferente su compromiso sobre la veracidad y legitimidad de
la instrucción de terminación por parte del Usuario.
• Conserva en su expediente como evidencia los documentos originales en los que conste la
manifestación de la voluntad del Usuario para dar por terminada la relación, y la
autenticación del cliente.
• En los expedientes debe señalarse el nombre y firma del Ejecutivo de Cuenta responsable.
• Cuenta con la aprobación del crédito correspondiente, cuyo importe debe ser suficiente
para liquidar el saldo deudor y se considerará dispuesto el crédito en el momento en que se
realice el pago a la Institución Transferente.
• No ofrecerá contraprestación a las empresas, sindicatos, etc. que puedan ejercer influencia
sobre otros usuarios, con el propósito de promover la terminación de operaciones de
manera colectiva.
• La Movilidad de Saldo no aplica cuando el saldo que solicita es cero.
• Liquidar el adeudo del Usuario.
• La operación de cargo y abono entre instituciones debe ser acreditada en un plazo no mayor
a 48 horas hábiles (dos días).
• Confirma al cliente el pago y cancelación de las operaciones con la Institución Transferente.
• Entrega al Usuario (tarjetahabiente) el Contrato de Adhesión, carátula y estado de cuenta.
• En caso de no cumplir con las políticas, estándares y procedimientos de acuerdo a ésta
normativa y/o ser autenticado al Cliente, cubrirá el pago de daños y perjuicios ocasionados
al usuario, así como las sanciones que resulten aplicables, en caso de que no pueda
comprobar la autorización respectiva del cliente. De acuerdo a punto I Artículo 26 de la ley
de transparencia)
• Acuse de cancelación (confirmación previa de la Institución Transferente), de acuerdo a lo
establecido por cada institución según corresponda.
• La transferencia de saldos se debe realizar a más tardar al tercer día hábil siguiente de que
la Institución Transferente proporcione la confirmación del saldo.
Capítulo XXII 3

Institución Transferente:
• Dar a conocer a la Institución Receptora, la información respecto al saldo y la establecida

para la terminación de la operación solicitada por el usuario.
• Requerir al usuario confirmación de haber solicitado a la Institución Receptora el servicio de
cancelación y transferencia de recursos.
• Una vez realizado el pago del saldo deudor deberá renunciar a sus derechos de cobro
residuales, que pudieran subsistir después del momento de la cancelación.
• La operación de cargo y abono entre instituciones debe ser acreditada en un plazo no mayor
a 48 horas hábiles (dos días).
• A partir de la transferencia de los recursos, se extinguen los derechos y obligaciones de los
contratos que hayan sido vinculados a dicha cuenta.
• La transferencia de saldos se debe realizar a más tardar al tercer día hábil siguiente a aquel
en que se reciba la solicitud autorizada.
• En caso de no cumplir con las políticas, estándares y procedimientos de acuerdo a ésta
normativa y/o ser autenticado al Cliente, cubrirá el pago de daños y perjuicios ocasionados
al usuario, así como las sanciones que resulten aplicables, en caso de que no pueda
comprobar la autorización respectiva del cliente. (De acuerdo a punto I Artículo 26 de la
ley de transparencia).
• Acuse de cancelación (confirmación previa de la Institución Transferente), de acuerdo a lo
establecido por cada institución según corresponda.
2. CONDICIONES PARA EL PROCESO DE MOVILIDAD DE SALDO
El Usuario participante (Tarjetahabiente), como las Instituciones Receptoras y Transferentes

deben de dar cumplimiento a lo establecido por Comisión Nacional para la Protección y Defensa
de los Usuarios de Servicios Financieros (CONDUSEF) publicado el 24 Octubre 2014.
• Recibir por escrito en su sucursal o cualquier canal que disponga las Instituciones
Receptoras las solicitudes de terminación de operaciones activas (Movilidad de Saldo).
• Contar con un Folio de Movilidad vigente, generado por la Institución Transferente, el cual
debe generarse en el Módulo de Movilidad.
• Folio de Movilidad de acuerdo a los criterios y controles de cada Institución.
• La Institución Transferente podrá dar el saldo y estatus de la cuenta a la Institución
Receptora, previa confirmación con el cliente de la instrucción de movilidad
• La Institución Receptora deberá de enviar a la Institución Transferente la notificación de
pago en un plazo no mayor a 3 días hábiles después de enviada la confirmación de que
procede su solicitud, mediante el Módulo de Movilidad.
• La Institución Receptora deberá de notificar al cliente en caso de la cancelación del trámite
de movilidad. Para continuar con el proceso, se reinicia con un nuevo folio de Movilidad de
Saldo.
Capítulo XXII 4

• Si el Cliente cuenta con una Aclaración en tránsito, la Institución Receptora debe de
informar al cliente que el trámite de movilidad, se podrá llevar a cabo una vez concluidos
los procesos antes mencionados.
• El pago del saldo se realizará a través de pago interbancario o cualquier otro medio.
Integrando el concepto de pago que tiene definido cada institución ejemplo, (PAGO
MOVILIDAD) con la finalidad de identificar el pago.
• El trámite de solicitud de saldo deberá iniciar en la herramienta un día (hábil) posterior
al corte y hasta ocho días (hábiles) antes de la fecha límite de pago.
• Para realizar la movilidad, el tarjetahabiente deberá de tener una antigüedad mínima de un
año en la Institución Transferente.
3. PROCESO DE MOVILIDAD
Descripción del proceso:
1. El tarjetahabiente acude a la sucursal o cualquier canal que disponga la institución

Receptora para solicitar la Movilidad de Saldo.
a. Acude con el Ejecutivo de Cuenta responsable para solicitar la Movilidad de Saldo.
b. Si no tiene una Tarjeta de Crédito, debe realizar el proceso para solicitarla. De
acuerdo a las políticas y procesos establecidos de cada institución.
c. Si ya cuenta con una línea de Crédito, el Ejecutivo de Cuenta debe de validar si
requiere un aumento de línea de crédito para poder realizar la Movilidad.
d. El Ejecutivo de Cuenta debe de capturar en la herramienta la información requerida,
toda vez que el cliente ya cuenta con una línea de crédito aprobada y con límite
suficiente, solicitando al cliente los documentos que la institución requiera para la
integración de su expediente.
e. El sistema valida que no haya una movilidad en los últimos doce meses, de existir,
debe ser rechazada.
2. De acuerdo a las políticas y tiempos de cada institución para la autorización de la solicitud
del crédito y/o incremento de línea de crédito, así como la verificación las condiciones del
punto 1-e. El sistema genera un número de control interno, el cual se le informa al cliente.
3. Si NO procede la validación, la Institución Receptora declina la solicitud notificando al
cliente causa de rechazo:
a. No calificó para una línea de crédito
b. No calificó para un incremento por el saldo de Movilidad
c. Cuenta con Aclaraciones en tránsito
4. El Ejecutivo de Cuenta le informa al cliente que iniciará la solicitud de Movilidad con la

Institución Transferente e imprime el formato para la firma del cliente autorizando el
trámite de Movilidad.
5. El cliente será contactado por el Banco Transferente para confirmar la solicitud de
Movilidad de saldo:
Capítulo XXII 5

a. Sí en la validación, se confirma que el cliente no solicitó este trámite, se cancela la
solicitud de Movilidad de Saldo.
b. Si el cliente es autenticado, el ejecutivo de la Institución Transferente debe revisar
que no cuente con aclaraciones pendientes, en caso de no tenerlas se debe
bloquear la cuenta de manera temporal.
c. Si en el proceso de autenticación el cliente confirma la solicitud de Movilidad de
Saldo se proporciona folio de Movilidad.
d. Si se autentica al cliente y decide no continuar con la solicitud de Movilidad, no se
genera el folio y se cancela solicitud.
6. La Institución Transferente genera folio de Movilidad y notifica por la herramienta a la
Institución Receptora. (Esta solicitud cuenta con una vigencia de tres días hábiles, en caso
de no ser confirmada, se cancela la solicitud iniciando nuevamente el trámite de
Movilidad).
7. Una vez que se integra el Folio de Movilidad, la Institución Receptora a través de la
herramienta envía la petición de movilidad de saldo incluyendo el folio de la Institución
Transferente con la notificación recibida, realizando la siguiente validación:
a. Se confirma la solicitud del cliente, realizando el siguiente proceso a criterio de cada
Institución:
i. El cliente cuenta con Cargos Periódicos y está de acuerdo en notificar a los
comercios el cambio del número de tarjeta.
ii. El cliente cuenta con aclaraciones en tránsito y está de acuerdo en la
cancelación del proceso de aclaración.
8. Si procede la solicitud, la Institución Receptora recibe el monto a transferir contando con
un periodo de 3 días (hábiles) para realizar el traspaso de saldo de Movilidad.
a. La Institución receptora genera el movimiento a través de pago interbancario o
cualquier otro medio, notificando a través del Módulo de Movilidad a la Institución
Transferente.
9. La Institución Transferente debe postear su pago en un máximo no mayor a 48 horas
hábiles, cambiar el estatus de bloqueo de la cuenta a cancelado y enviar a través de la
herramienta la confirmación de haber recibido el depósito notificando que la cuenta fue
cancelada.
10. Si al quinto día hábil de haber confirmado el saldo de la Institución Transferente a la

Institución Receptora y no ha recibido el depósito a la cuenta, la Institución Transferente
(la herramienta de Movilidad) debe cancelar el folio de Movilidad y en su caso quitar el
bloqueo temporal y notificar al cliente; en caso de que la Institución Transferente así lo
considere,
11. La Institución Receptora genera documentación soporte e integrar expediente.
12. Fin del proceso.
Capítulo XXII 6

Por motivos de seguridad de la información, solo se reciben solicitudes de Movilidad
que sean enviadas a través del sistema autorizado que se establecen en este proceso.
4. INTEROPERABILIDAD ENTRE LOS SISTEMAS
La comunicación de la herramienta de Movilidad entre los dos sistemas que la operan, están
desarrolladas bajo los mismos estándares, criterios, procesos y tiempos definidos en esta
normativa.
5. PENALIZACIONES:
En caso de incumplimiento por cualquiera de las instituciones participantes, se aplicara el

inciso (d) de la penalización 32 del Capítulo V (penas convencionales por incumplimiento),
del CID. Y cuenta con un plazo de 30 días naturales para incorporarse al proceso de
Movilidad establecido en éste documento.
En caso de vencimiento del plazo establecido, se aplicarán el nivel (e o f) de la penalización

32. En caso de llegar al punto f de ésta penalización se notificará al Comité de Medios de
Pago. Para evaluar las medidas correspondientes.
Línea de tiempo en el proceso de Movilidad de Saldo, a partir de la línea de

crédito que fue Autorizada
En caso de que el titular de la operación no reconozca dicha terminación o la transferencia de
recursos efectuada, la Institución Financiera Receptora debe entregar los recursos con sus
respectivos accesorios a la Institución Financiera Transferente, dentro de un plazo máximo de tres
días hábiles.
Capítulo XXII 7

ANEXO 55 CAMPOS REQUERIDOS PARA LA MOVILIDAD DE SALDO
INSTITUCIÓN RECEPTORA
1. Folio Movilidad
2. Nombre Cliente
3. Número de Cuenta Origen
4. Nombre Institución Origen
5. Nombre Institución Receptora
6. Límite de crédito asignado por Institución Receptora
Capítulo XXII 8

7. Copia de IFE / Edo cuenta
8. Fecha límite de pago
9. Fecha de corte
10. Antigüedad con la tarjeta.
11.Datos de la sucursal (Promotor y firma)
12.Formato de Autorización firmada
13.Fecha de petición
14.Estatus solicitud
a. Aprobada
b. Declinada
INSTITUCIÓN TRANSFERENTE
15.Estatus Cuenta
a. Activa
b. Bloqueada
16.Saldo de la tarjeta
17.Aclaraciones en tránsito
18.Cuenta con Cargos Periódicos (control interno)
19.Fecha Bloqueo
20.Fecha Pago
21.Monto aplicado por la movilidad
22.Fecha Cancelación del crédito
23.Motivo de cancelación (Cancelado por movilidad)
CAPITULO XXII
Enteradas las partes del contenido del presente instrumento lo firman en la
Ciudad de México, D.F., el 1 de marzo de 2016
NOMBRE INSTITUCION FIRMA RUBRICA
Capítulo XXII 9

Capítulo XXII 10

Capítulo XXII 11

Capítulo XXII 12

Capítulo XXII 13

Capítulo XXIII
Operativa
Check In y Check Out
Capítulo XXIII 1
Objetivo
Normar la operativa en Receptores de Pago con operación de Check In y Check
Out para tarjetas.
Alcance
Eliminar la práctica de la firma en un pagaré sin monto, aplicable para las operativas
que tengan Check In, utilizando en el intercambio la mensajería ISO 8583 en los
mensajes financieros, en el proceso on line, compensación y aclaraciones.
Definición.
Check In:
Proceso en el que se adquiere un servicio con una tarjeta en un receptor de pagos,
se firma un pagaré, por un monto estimado del total del servicio a brindar
Check Out:
Proceso de cierre de una transacción de check in, de un receptor de pagos; para
presentarse al intercambio (posteo y liquidación de la transacción), debiendo tener
una pre-autorización de cargo a la cuenta del tarjetahabiente.
Premisas.
Las transacciones de cierre Check Out se generan offline, se envían a la cámara de

compensación adquirente al cierre del día o en la siguiente transacción que realice
la terminal y debido a que en ese momento el tarjetahabiente ya no se encuentra
presente, no se realizan validaciones para generar un posible rechazo de forma
automática.
Las transacciones realizadas en hoteles y renta de autos cuyo origen sea una
transacción telefónica o internet no se consideran dentro de esta normativa, sino
como una reservación garantizada conservando su medio de acceso original,
A partir de las condiciones actuales de la operativa de este tipo de transacciones,

las cámaras de compensación han desarrollado servicios que permiten detectar y
filtrar transacciones que califiquen como sospechosas de fraude. Estos servicios
pueden ser aprovechados por las instituciones (con enfoque adquirente), o si así lo
deciden, implementar filtros propios a nivel adquirente.
Operativa Hotel y Renta de Autos
Capítulo XXIII 2
Check In:
Una transacción de Check In se debe realizar Online / (Tarjeta presente), la cual no

se compensan. En donde el tipo de mensaje de la solicitud puede ser (100/200),
recibiendo una respuesta (110/210), de acuerdo al tipo de mensaje que se estén
enviando.
Reautorizaciones:
Estas transacciones se generan sin tarjeta presente con PEM 01, la solicitud de la
reautorización es por un monto complementario al monto original solicitado en el
check in. En donde el tipo de mensaje de la solicitud puede ser (100/200), recibiendo
una respuesta (110/210).
Check Out:
El monto puede ser menor o igual al monto del Check In o en su caso de un importe
mayor, con los importes de las reautorizaciones aprobadas.
El receptor de pagos en las transacciones de cierre, puede operarlas de la siguiente

manera:
a) Transacciones Sin tarjeta presente, no pueden exceder del 20% de la suma del
importe solicitado en el Check In más los importes de las reautorizaciones,
generando el Check Out con la fecha del cierre de la transacción.
b) Las transacciones con tarjeta presente, el receptor de pagos debe anular la
transacción del Check In y sus reautorizaciones, para generar una nueva
transacción por el monto total, a menos que el comercio se asegure tomar el número
de autorización del Check In para realizar el cierre.
Ajustes de Check Out:

Cuando las transacciones viajan en línea con un mensaje 0100 al cerrar con el
check out, se realiza la validación o la suma del check in más las reautorizaciones,
el monto del Check Out puede ser menor al monto original + reautorizaciones pero
nunca mayor al 20% de esta suma ya que si excede a éste porcentaje, la
responsabilidad será del Adquirente. Las transacciones viajan con ajustes en línea
antes del cierre de lote del día en la terminal.
Capítulo XXIII 3
ESQUEMA OPERATIVO
Operativa Hotel y Renta de Auto. Ejemplo ciclo de la transacción
Operación No. de No. de Tipo de Draft PE Monto
Comentarios
Tarjeta Aut. mensaje Capt M Ejemplo
Check In
*****9999 0200 / 0100 90
Solicitud
05 Online– Tarjeta presente /
0 $2,000
Check In 80 No se compensa
*****9999 975310 0210 / 0110
Respuesta 07
Reautorización
*****9999 0200 Online - Sin tarjeta presente.
Solicitud
Se plasman el valor de tarjeta No

Presente
01
0 $10,000
Reautorización
*****9999 246810 0210 La solicitud es por un monto
Respuesta
complementario al monto original.
No se compensa
Check Out Offline - Tarjeta no presente.

Cierre
*****9999 975310 0220
Solicitud El monto puede ser menor, o igual a
la suma de los montos original y de
reautorización. (Validación por TPV).
SI se compensa
90
05 Se plasman los valores PEM de la
Check Out 1 <= $12,000 autorización del Check In donde hubo
07
Cierre tarjeta presenta
80
Respuesta *****9999 975310 0230 o
Envía el número de autorización de
la transacción donde existió
presencia de plástico; El monto no
debe exceder al 20% adicional a la
suma de las transacciones
autorizadas.
Puede viajar con Ajustes en línea antes del cierre de Lote

Off line – Tarjeta no presente. El
Ajuste de Check
*****9999 975310 0220 1 01 $0.00 monto puede ser menor o mayor al del
Out
Check Out
Ajuste Check Out
*****9999 975310 0230 1 01 $0.00
Respuesta
El Draft Capture es el indicador si la transacción se compensa o no
0= No se compensa 1=Se compensa
Liberación del disponible
El tiempo de liberación de retención del disponible por parte de los emisores para
un Check Out o una cancelación del Check In, no debe ser mayor a 10 días
naturales posterior al cierre de la transacción, en caso de que el Emisor no lo libere
en el plazo señalado, se deberá de llevar al Comité de Medios de Disposición
(Comité de Tarjetas) para evaluar su sanción.
Capítulo XXIII 4
Operativa para Restaurante Producto Crédito y Débito
En la Operativa de Restaurante hay dos tipos de funcionalidad, Pos Propina y Pre

propina, de las cuales se describen a continuación.
Pos Propina
Para esta funcionalidad de acuerdo al esquema (2), en la Solicitud de Autorización,
la transacción es Online – (Tarjeta presente) esta No se compensa, Viaja un
mensaje (200) con un PEM (90-05-07-80). Al recibir la respuesta con el número de
autorización tiene un tipo de mensaje (210).
El cierre de la Operación, es Offline – (Tarjeta no presente) en la cual No hay
restricción en el importe excedente, viajando en la solicitud del cierre el mensaje
(220) con el PEM (01) y SI se compensa.
De acuerdo al tipo de terminal, al cierre de la operación puede viajar con ajustes en
línea antes del cierre de lote.
Operativa Restaurante (POS PROPINA) Esquema operativo (2)

Operación No. de No. de Tipo de Draft PEM Monto
Comentarios
Tarjeta Aut. mensaje Capt Ejemplo
Consumo 90
*****9999 0200
Solicitud 05 Online – Tarjeta presente
0 $2,000
Consumo 07 No se compensa
*****9999 674983 0210
Respuesta 80
Consumo
Offline - Tarjeta no
Cierre *****9999 674983 0220
presente.
Solicitud 01
1 $X No hay restricción en el
Consumo
importe.
Cierre *****9999 674983 0230
SI se compensa
Respuesta
Puede viajar con Ajustes en línea antes del cierre de Lote.
Consumo Online– Tarjeta presente
0200 /
On Line *****9999 220
Si se compensa
90
Solicitud Banamex genera un
05
1 $2,000 mensaje de aviso 220 y al
Consumo 80
cierre de lote envía un
On line *****9999 975310 0210 / 230 07
mensaje 200 por el monto
Respuesta
del cierre de la transacción.
El Draft Capture es el indicador si la transacción se compensa o no
0= No se compensa 1=Se compensa
Capítulo XXIII 5
Pre Propina
En la solicitud, viaja con un mensaje (200) y PEM (90-05-07-80), la transacción es

Online (Tarjeta Presente), regresa la autorización viajando con mensaje (210). En
la impresión y firma del pagaré el importe de la venta incluyendo la propina.
Mediante esta operativa como se muestra en el esquema (3), la propina se

determina antes de realizar la transacción, por lo que viaja el importe final sin
necesidad de una transacción de cierre.
Operativa Restaurante (PRE PROPINA) Esquema operativo (3)

No. de No. de Tipo de Draft Monto
Operación PEM Comentarios
Tarjeta Aut. mensaje Capt Ejemplo
Consumo Online – Tarjeta Presente +
*****9999 0200
Solicitud Propina.
Si se compensa
90
$2,000
05
1 $200.00 Si el pagare es mayor de
Consumo 07
*****9999 0200 $2,200.00 $250.00 debe de ser firmado.
Propina 80
Autógrafa o
electrónicamente.
90
Consumo 05 Regresa la autorización con
*****9999 975310 0210 1 $2,200
Respuesta 07 Tarjeta presente.
80
Operativa de Pre-Autorización y Cierre de Autorización en Gasolineras:
Descripción:
En el dispositivo (POS) se realiza una Pre Autorización para permitir la activación
del despachador de gasolina y en cuanto concluye el servicio, realiza el Cierre de
Pre Autorización por un importe menor o igual al inicial.
Capítulo XXIII 6
Estableciendo las siguientes consideraciones:
1. Para efectos de concluir la transacción se establece como máximo que el

Cierre de Pre Autorización se realizará al día siguiente de haber realizado la
Pre Autorización.
2. Para este tipo de operaciones se establece que todas las transacciones

siempre serán con tarjeta presente
3. Queda establecido por parte de los Adquirentes que el receptor de pago No

podrá manejar transacciones de re-autorización ni ajustes.
4. Solo aplica para los giros correspondientes a Gasolineras.
5. Sobre los comprobantes de estas transacciones, aplicarán de acuerdo al

indicador del tipo de operativa que intercambie el Adquirente.
Resolución de controversias
Los casos de controversia por reclamación, donde especifica el tarjetahabiente no

reconocer la transacción que excede el importe autorizado o falta de autorización,
se pueden Contracargar por código de razón 72 del Capítulo II (Resolución de
Controversias) del Manual Operativo del Convenio de Intercambio Domestico.
Presentando los Log´s de Autorización del Check In y Check Out.
PENALIZACIONES:
En caso de no liberar los fondos para un Check Out o una cancelación del Check In
en el plazo estipulado de 10 días, se aplicara el inciso (b) de la penalización 32 del
Capítulo V (penas convencionales por incumplimiento), del CATB. Y cuenta con un
plazo de 30 días naturales para incorporarse al proceso automatizado de esta
normativa. En caso de vencerse nuevamente el plazo establecido anteriormente se
aplicarán el nivel (c, d, e o f) de la penalización 32. En caso de llegar al punto f de
ésta penalización se notificará al Comité de Medios de Pago. Para evaluar las
medidas correspondientes.
Capítulo XXIII 7
Esta aplica cuando un Adquirente presenta los elementos de reclamación del
receptor de pagos, al árbitro operativo quien a su vez, deberá solicitar al Emisor la
evidencia de la liberación de fondos. La cual deberá de atender el Emisor en un
plazo no mayor a cinco días hábiles. Dando atención a estos casos, mediante un
proceso de arbitraje.
Los giros que aplican para estas operativas son:
Giro comercial (Familia)

Renta de Autos
Agencias De Viajes
Hoteles
Entretenimiento
Hospitales
Restaurantes
DIAGRAMAS DE FLUJO Operativa Tarjeta de Crédito

Esquema 1
Capítulo XXIII 8
*Saldo Retenido: (Sin Compensación)
Esquema 2 Tarjeta Presente
Capítulo XXIII 9
Capítulo XXIII 10
DIAGRAMAS DE FLUJO Operativa Tarjeta de Débito
Capítulo XXIII 11
DIAGRAMAS DE FLUJO Pos-propina – Restaurante
Esquema 3
Capítulo XXIII 12
DIAGRAMAS DE FLUJO Pre-propina – Restaurante
Esquema 4
Capítulo XXIII 13
CAPITULO XXIV
VALIDACIÓN DE INDICADORES
Esquema de aplicación de penalización a los Adquirentes y Emisores por el

incumplimiento en el envío obligatorio y correcto de los indicadores.
Capítulo XXIV 1 Contrato de Intercambio Domestico
CID Versión 5.0 – mayo 15, 2020 CID Versión 6.2 – diciembre 01, 2021
Alcance
Aplica para las Instituciones Adquirentes y Emisores en las transacciones del Intercambio
Doméstico, de acuerdo con las operativas detalladas en este documento.
Responsabilidades:
Adquirente: Inicia las transacciones con los indicadores establecidos en el anexo 4I

(Documento de Especificación Técnica de Indicadores), de acuerdo al tipo de operativa.
Adicionalmente debe establecer un monitoreo de los indicadores para vigilar que sus
transacciones no generen algún Incumplimiento.
Emisor: Recibir y validar los indicadores recibidos en la solicitud de autorización y con base
en ello dar respuesta, incluyendo los indicadores que le corresponden de acuerdo al Anexo 4I
(Documento de Especificación Técnica de Indicadores).
Adicionalmente debe establecer un monitoreo de los indicadores para vigilar que sus
transacciones no generen algún incumplimiento.
Cámara de Compensación: Rutear, compensar y liquidar las transacciones enviadas por el

adquirente hacia el emisor y la respuesta del emisor al adquirente, así mismo debe grabar la
información en log de autorizaciones.
1.- Proceso de Monitoreo de Cumplimiento
1.1 Objetivo.
Mantener y mejorar la integridad y calidad de la información de los indicadores en el mensaje

de autorización, a través del monitoreo de las transacciones para los Emisores y Adquirentes.
Alertar a las instituciones que incumplan con las reglas establecidas en el Documento de
Especificación Técnica de Indicadores para que presenten un plan de corrección.
1.2 Esquema de Monitoreo.
Se utilizan las definiciones establecidas en el Anexo 4I (Documento de Especificación Técnica

de Indicadores) del CID para monitorear el correcto envió de los indicadores en las
transacciones.
En caso de algún cambio en las definiciones, previa autorización de los participantes, estas
serán comunicadas a los Adquirentes en la nueva propuesta del documento normativo.
El monitoreo se realiza con la con el total de transacciones registradas en un mes completo por
cada una de las Cámaras.
Las Cámaras de Compensación deben reportar mensualmente, y dentro de los primeros 10 días
naturales de cada mes al Árbitro Operativo y a sus instituciones, (en caso del vencimiento sea
un día inhábil se presentara al día siguiente hábil), las afiliaciones en incumplimiento que
operan en la(s) Cámara(s) opuesta(s), con el detalle de todas las transacciones y afiliaciones
con las Operativas descritas en el Alcance de este documento.
La información que generan las Cámaras se debe intercambiar entre ellas dentro de los primeros
cinco días naturales del mes, (en caso de que el vencimiento sea un día inhábil se presentara
al día siguiente hábil), y de acuerdo con el formato acordado, antes del reporte al Árbitro
Operativo e Instituciones.
El Adquirente cuenta con un plazo de 90 días naturales a partir de la notificación del Árbitro
operativo, para realizar la corrección de la inconsistencia reportada.
En caso de requerir un plazo mayor para la solución o determine que la inconsistencia no es

originada en sus afiliaciones, el Adquirente tiene hasta el día 45 para:
• Presentar ante el comité de tarjetas el plan de trabajo con posible fecha de solución y
argumentos para solicitar la autorización correspondiente antes del vencimiento del
plazo inicial y presentarlo al Árbitro operativo.
• Presentar la evidencia. (Trama completa de al menos tres transacciones) al Árbitro

operativo, que demuestre que la inconsistencia no es originada por el adquirente.
En caso de que el Adquirente presente evidencia que involucre a uno o más Emisores, se
suspende el conteo del plazo otorgado al adquirente para la corrección y el Arbitro Operativo
debe notificar dentro de los siguientes 5 días hábiles al grupo de trabajo de indicadores para el
análisis correspondiente.
El análisis del grupo de trabajo debe determinar la causa y el responsable de la inconsistencia

en el envío de los indicadores en un plazo no mayor a 5 días hábiles.
Si se determina que la inconsistencia reportada es responsabilidad del adquirente, se reanuda

el conteo de días del plazo inicial establecido en esta normativa para la corrección de la
inconsistencia.
En caso que la afiliación cambie de adquirente, se debe reportar al Árbitro Operativo y el nuevo
Adquirente asume la responsabilidad, por lo que continúan los plazos del incumplimiento
reportado.
Si se determina que la incidencia reportada es responsabilidad del Emisor, cuenta con un plazo
de 90 días naturales a partir de la notificación del Árbitro operativo, para realizar la corrección
de la inconsistencia reportada.
En caso de requerir un plazo mayor para la solución o determine que la inconsistencia no es

originada en el Emisor tiene hasta el día 45 para:
• Presentar ante el comité de tarjetas el plan de trabajo con posible fecha de solución y
argumentos para solicitar la autorización correspondiente antes del vencimiento del
plazo inicial y presentarlo al Árbitro operativo.
• Presente la evidencia. (Trama completa de al menos tres transacciones) al Árbitro

operativo, que demuestre que la inconsistencia no es originada por el emisor.
En caso de que el Emisor presente evidencia que involucre a uno o más Adquirentes, se
suspende el conteo del plazo otorgado al Emisor para la corrección y el Arbitro Operativo debe
notificar dentro de los siguientes 5 días hábiles al grupo de trabajo de indicadores para el análisis
correspondiente.
El análisis del grupo de trabajo debe determinar la causa y el responsable de la inconsistencia

en el envío de los indicadores en un plazo no mayor a 5 días hábiles.
Si se determina que la inconsistencia reportada es responsabilidad del Emisor, se reanuda el

conteo de días del plazo inicial establecido en de esta normativa para la corrección de la
inconsistencia.
El Árbitro Operativo debe administrar el seguimiento para verificar que se resuelvan las
inconsistencias y en caso contrario aplicar las sanciones correspondientes.
El o los emisores que sean identificados como responsables de afectar los indicadores a un
Adquirente, deben apegarse al esquema de penalización, detallado en el presente documento.
La información que las Cámaras de Compensación envían al Árbitro Operativo, debe ser de
acuerdo al siguiente layout:
Adq AFILIACIÓN Q2 (Operativa) DETALLE

2 Cargos Periódicos
8 Mo/To
ABCDE 1234567 DESCRIPCIÓN DE LA FALLA
9 E-Commerce
24 TAG
1.3 Penalizaciones
Cuando un Emisor o un Adquirente reciba de su Cámara de compensación la notificación de

incumplimiento por no enviar los indicadores de acuerdo a las operativas descritas en el Alcance
de este documento o los envíe de forma incorrecta, el Emisor o el Adquirente se hacen
acreedores a la amonestación señalada en el punto a) de la penalización 32 y cuentan con 90
días naturales a partir de la notificación de la amonestación por parte del Árbitro Operativo, para
corregir o aclarar las inconsistencias reportadas.
En caso de que el Emisor o el Adquirente una vez vencido el plazo continuen sin corregir , se
aplica el siguiente inciso de la penalización 32, y así sucesivamente hasta que el Emisor o el
Adquirente aplique la corrección del incumplimiento hasta que se le notifique el punto f) de la
penalización 32.
Si un Emisor o un Adquirente reciben notificación de incumplimiento con el punto f) de la

penalización 32 y sigue sin corregir el envío de los indicadores, se notifica al Comité de Tarjetas
para decidir la sanción que se debe aplicar.
Cuando la Institución penalizada haya corregido la afiliación reportada y posterior a la corrección

presente una inconsistencia diferente al objeto de la penalización en períodos anteriores, se
tomará como un nuevo error y el proceso de penalización iniciaría nuevamente con una
amonestación.
CAPÍTULO XXV
DIGITALIZACION DE
IMAGENES
Capítulo XXV 1
Objetivo
Establecer los procesos y procedimientos del intercambio de imágenes

derivado del proceso de solicitud de documentos, controversias o misceláneos
de las Instituciones emisoras y adquirentes.
Características del archivo
• Un archivo en formato PDF que contenga los documentos de cada

transacción de acuerdo al registro intercambiado.
• Tamaño del archivo hasta 1Mb.
• Contar con su valor Hash obtenido del archivo PDF, en el campo que
corresponda del archivo de intercambio de acuerdo al tipo de registro.
1.- Valor Hash
Los archivos PDF que contienen las imágenes, deben contar con su
correspondiente resumen Hash mediante el algoritmo MD5. La codificación del
MD5 de 128 bits es representada como un número de 32 caracteres
hexadecimal, ejemplo: d41d8cd98f00b204e9800998ecf8427e
Dicho valor se debe incluir en el campo correspondiente del archivo de

intercambio de transacciones de acuerdo al tipo de registro, para proporcionar
la seguridad de que un archivo no tuvo modificaciones, el sistema debe hacer
una comparación de la suma del algoritmo MD5 enviada en el archivo de
intercambio con la suma de comprobación del archivo recibido, con lo que las
Instituciones tienen la seguridad que el archivo intercambiado es igual al
generado por la contraparte.
2.- Solicitud de Documentos
El Emisor a través el archivo de intercambio puede solicitar documentos

mediante las transacciones 51 y 52 al Adquirente de acuerdo a la regla
operativa del punto 3.1 del Capítulo I de Reglas Generales.
El Adquirente debe contestar junto con los documentos atendidos con la

transacción 53, si alguna petición no puede ser atendida por datos erróneos de
acuerdo a las condiciones ya establecidas en la regla 3.14 del Capítulo I, debe
ser rechazada con el código de transacción 54 y su clave de rechazo.
Capítulo XXV 2
CLAVE DESCRIPCIÓN
1 Duplicidad Histórico (Petición de documento en diferentes fechas
2 Duplicidad en el Incoming (Petición de documento en el mismo día)
3 Error en Importe (diferente a la transacción original)
4 Error en Referencia (diferente a la transacción original)
5 Error en Número de Cuenta (diferente a la transacción original)
6 Solicitud con Importe Menor al Autorizado
7 Solicitud mayor a 180 días
8 Solicitud y Contracargo dentro del Periodo de Atención del Documento de
acuerdo a la regla 4.18 del CID
O mediante un escrito libre que contenga la siguiente información:
• Fecha de Rechazo
• Institución
• Número de Cuenta
• Referencia
• Importe
• Clave de Rechazo
3.- Intercambio de imágenes del archivo de aclaraciones:
Envío y recepción diario del archivo que contiene las imágenes con la
documentación soporte de las controversias y atención de solicitudes de
documentos, mismo que es adicional e independiente al Archivo de Intercambio
de Transacciones.
• El archivo de imágenes debe contener el mismo nombre del

archivo de transacciones intercambiado, identificando el de
imágenes con la extensión zip.
• Los archivos de imágenes deben ser transmitidos de manera

inmediata a la conclusión del envío del archivo de facturación de
cada ventana.
• Las controversias que no contengan un archivo de imagen, deben

ser rechazadas en el archivo de intercambio.
• En caso de que no se pueda transmitir el archivo de imágenes por

alguna contingencia, la cámara generadora del archivo debe
informar a la cámara receptora que la entrega será el mismo día
en un medio de almacenamiento cifrado antes de las 13:00.
Capítulo XXV 3
• En caso de no transmitirse el archivo de intercambio, no debe
enviarse el archivo de imágenes.
4.- Detalle de transacciones de solicitud de documento en el

intercambio
En el extracto del Archivo de Intercambio de Transacciones (Anexo 4 del

Apartado IV POS), se cuenta con los campos 50, 51 y 52 del layout, que nos
permite relacionar el registro de datos con el registro de imágenes.
A continuación se muestra un extracto del Archivo de Intercambio de

Transacciones con el detalle de los campos, que permite relacionar el registro
de datos con el registro de imágenes.
Formato de intercambio del registro de transacciones (Contracargo/

Representaciones) DETALLE (DE)
SEC. CÓDIGO NOMBRE DEL CAMPO POSICIÓN TAMAÑO CONTENIDO DEL CAMPO
A)INSTITUCIÓN = 3 POSICIONES + 1
POSICIÓN (A=ADQUIRENTE; E=
EMISOR)
FOLIO UNICO EMISOR FECHA JULIANA
50 DT[50]13AN(C) 255 - 267 13
DIGITALIZACION B)AÑO = 1 POSICIÓN
C)DÍA = 3 POSICIONES (NÚMERO
CONSECUTIVO 001 - 365)
D)CONSECUTIVO = 5 POSICIONES
EMISOR)
FECHA JULIANA
B)AÑO = 1 POSICIÓN
NOMBRE DEL ARCHIVO PDF
51 DT[51]16AN(C) 268 - 283 16 C)DÍA = 3 POSICIONES (NÚMERO
DIGITALIZACION
E)CÓDIGO DE TRANSACCIÓN 2
POSICIONES
F)CÓDIGO DE USO 1 POSICIÓN
HASH DEL ARCHIVO PDF VALOR HASH OBTENIDO DEL ARCHIVO
52 DT[52]32N(C) 284 - 315 32
DIGITALIZACION PDF ENVIADO
Formato de intercambio del registro de transacciones (Solicitud de

Documentos) DETALLE (DE)
EMISOR)
FECHA JULIANA
25 SD[25]13AN(C) FOLIO ÚNICO EMISOR 169 – 181 13
EMISOR)
FECHA JULIANA
B)AÑO = 1 POSICIÓNB)AÑO = 1
POSICIÓN
26 SD[26]16AN(C) NOMBRE DEL ARCHIVO PDF 182 - 197 16
POSICIONES
VALOR HASH OBTENIDO DE LA
27 SD[27]32AN(C) HASH DEL ARCHIVO PDF 198 - 229 32
IMAGEN ENVIADA
Capítulo XXV 4
Formato de intercambio del registro de transacciones MISCELÁNEOS
(MI) DETALLE (DE)
EMISOR)
FOLIO ÚNICO FECHA JULIANA
21 DM[21]13AN(C) 175 - 187 13
EMISOR/ADQUIRENTE B)AÑO = 1 POSICIÓN
EMISOR)
FECHA JULIANA
22 DM[22]16AN(C) NOMBRE DEL ARCHIVO PDF 188 - 203 16 C)DÍA = 3 POSICIONES (NÚMERO
POSICIONES
VALOR HASH OBTENIDO DE LA
23 DM[23]32AN(C) HASH DEL ARCHIVO PDF 204 - 235 32
IMAGEN ENVIADA
5.- Folio único:
Corresponde al número de folio asignado al registro intercambiado.
Este folio debe mantenerse en cada uno de los ciclos cuando se trate de
controversias para su identificación y control.
El Emisor / Adquirente debe utilizar la siguiente nomenclatura:
IIIIadddXXXXX donde:
Ejemplo de folio único: 026E629400001
• IIII: Número alfanumérico que identifica si se trata de un

movimiento Adquirente (A) o Emisor (E).
• addd (Fecha Juliana): fecha de proceso del registro

intercambiado, es un campo de 4 posiciones (considera fecha
juliana compuesta del ultimo digito del año del proceso, año
juliano (1 posición), y día juliano de envío (número consecutivo
001-365 de 3 posiciones).
• XXXXX: es un número consecutivo del registro intercambiado de

5 posiciones.
6.- Folio del archivo de imagen:
Corresponde al número de folio asignado a la imagen en el registro del archivo

batch entre Cámaras de Compensación.
El Emisor / Adquirente deben utilizar la siguiente nomenclatura:
IIIIadddXXXXXTTC.ext donde:
Capítulo XXV 5
Ejemplo de nombre de imagen de contracargo: 026E426900001151.pdf
• IIII identificador asignado por la Cámara de Compensación, más

una posición que identifica si se trata de un movimiento
Adquirente (A) o Emisor (E).
• Addd (Fecha Juliana): fecha de proceso del registro

intercambiado, es un campo de 4 posiciones (considera fecha
juliana compuesta del ultimo digito del año del proceso, año
juliano (1 posición), y día juliano de envío (número consecutivo
001-365 de 3 posiciones).
• XXXXX: es un número consecutivo del registro intercambiado de

5 posiciones.
• TT Código de Transacción
05= Representación
10=Misceláneo de Abono
15= Contracargo
20=Misceláneo de Cargo
51= Solicitud de Comprobante Original
52= Solicitud de Comprobante Copia
53= Atención de Solicitud
54=Rechazo
• C: Código de uso de una posición

1 = Contracargo
2 = Representación o Segundo Contracargo
• .ext: es la extensión del archivo de imagen, la cual debe ser .pdf
Los Emisores / Adquirentes deben realizar las validaciones de éste archivo de

acuerdo a lo establecido en el Capítulo III Validaciones, de éste contrato.
La validación de la legibilidad de las imágenes, es responsabilidad de la

entidad receptora de la controversia.
El Anexo 8 exhibit, se considera mandatorio en el envío de la documentación

soporte de la controversia.
Capítulo XXV 6
7.- REGLAS OPERATIVAS
Es responsabilidad de las Instituciones enviar la información debidamente

asociada a una solicitud de documento, controversia o misceláneo, mediante el
folio que le asigne el Emisor / Adquirente de acuerdo a lo establecido en el
Anexo 4 (Descripción del Archivo de Intercambio).
La imagen se considera correcta siempre y cuando cumplan con los datos

mandatorios establecidos en el Anexo 15 (Datos Legibles y Mandatarios que
deben contener los Documentos de Ventas y Devoluciones). En caso de no
cumplir con las especificaciones el Emisor y/o Adquirente pueden iniciar un
proceso de documentación ilegible.
El Emisor no está obligado a recibir copia del Comprobante en imagen, si

carece del Folio único de intercambio o Algoritmo de Verificación (resumen
Hash), por lo que aplica la validación correspondiente de acuerdo a lo señalado
en el capítulo III (Validaciones) y continua transcurriendo el plazo para la
atención, por lo anterior la confirmación electrónica del código de transacción
53 (Confirmación de Atención de Documento) no se registra en el intercambio.
Los contracargos y representaciones masivos no se pueden llevar a cabo a

través de este proceso, tendrá que hacerse uno a uno.
Capítulo XXV 7
CAPÍTULO XXVI
OPERATIVA MO/TO
Capítulo XXVI 1

1.- Mo / To TRADICIONAL
Las Transacciones MO/TO, son aquellas que se realizan a través de una tarjeta no
presente para la adquisición de un bien o servicio por medio de una orden telefónica o
comercio electrónico sin 3D Secure.
Objetivo:
Establecer reglas de la Operativa MO/TO (Mail Order/Telephone Order) para la venta de un

bien o servicio facilitando su uso como Medio de Pago por parte del Receptor de Pagos.
Alcance:
Para la Operativa MO/TO se consideran las siguientes transacciones:
a) Venta por Correo / Venta telefónica

b) Venta por Comercio electrónico sin 3D Secure
1.1.- Envío de Indicadores
a) Venta por Correo / Venta Telefónica:
Estas transacciones deben cumplir con los siguientes indicadores:
Token Q2 (indicador del medio de acceso)
- Subcampo 1 (indicador del medio de acceso que realiza la solicitud de

autorización)
o -Valor 8 (comercios MO/TO)
Así como los indicadores descritos en el punto 1.2.3 del Anexo 4I (Transacciones
MO/TO)
b) Venta por Comercio Electrónico sin 3D Secure
Para que estos comercios puedan obtener la operativa MO/TO Autenticado deben
contar con certificación PCI Vigente de acuerdo al criterio de su segmentación.
Estas transacciones deben cumplir con los siguientes indicadores:
Capítulo XXVI 2

Token Q2 (indicador del medio de acceso)
- Subcampo 1 (indicador del medio de acceso que realiza la solicitud de

autorización)
o -Valor 9 (internet -comercio electrónico)
Así como los indicadores descritos en el Capítulo XI (Comercio Electrónico) punto 5

“Características de las Transacciones de Comercio Electrónico sin autenticación”.
Si el Adquirente no envía los indicadores establecidos en los puntos anteriores, no puede

ejercer el proceso de representación en un ciclo de controversias.
Estos indicadores se deben reflejar en el log autorizaciones y en el archivo de intercambio,

si estos indicadores no son enviados por el adquirente, se sujetan a lo establecido en
Capítulo XXIV– (Validación de Indicadores).
Las transacciones MO/TO son responsabilidad del Adquirente, por lo que en caso de
reclamación del tarjetahabiente, el Emisor puede contracargar por Código de Razón 68
(Transacción de orden telefónico/correo/internet fraudulenta) de acuerdo al Capítulo II del
CID.
2.- Mo / To Autenticado:
Operativa que se compone de 2 transacciones, una transacción inicial que se lleva a cabo
mediante Tarjeta No Presente y otra complementaria con Tarjeta Presente que permite
autenticar la tarjeta con la que se realizó la transacción inicial.
Alcance
Para la Operativa MO/TO Autenticado se consideran las siguientes transacciones:
a) Venta por Correo / Venta telefónica

b) Venta por Comercio electrónico sin 3D Secure
2.1.- Indicadores:
Las transacciones deben enviar los indicadores especificados en el Anexo 4I y/o Capítulo
XI (Comercio Electrónico), adicionalmente la transacción de Tarjeta Presente debe
contener un PEM (05 o 07).
Capítulo XXVI 3

Cuando se trata de MOTO Autenticado el Emisor puede contracargar al Adquirente por
código de razón 68 y el Adquirente puede representar enviando al emisor la siguiente
documentación cumpliendo con los datos mandatorios para cada tipo de documento:
• Acuse de recibo de bien o servició comprados por Teléfono o Internet.

o Folio de Venta.
o Fecha de compra original
o Datos del Tarjetahabiente
§ El nombre corto o largo del tarjetahabiente debe coincidir con el
registrado en la plataforma Emisor.
o Firma del Tarjetahabiente donde acepta haber recibido el bien o servicio
o No. de Identificación Oficial
o Fecha de Entrega
• Log de Autorizaciones Certificado (Anexo 18).

o Log de Autorizaciones de la Venta Original
o Log de Autorizaciones de la Venta por complemento de Servicio (Transacción
importe $10.00).
• Comprobante de Pago por Complemento de Servició con importe de $10.00

con Tarjeta CHIP (PEM 05,07) que autentica la tarjeta con la cual se realizó la
Transacción Original.
o El Comprobante debe cumplir con los campos mandatorios establecidos en el
Anexo 15 del CID.
o El Receptor de Pagos debe anotar en la parte superior del comprobante, el
“Número de Folio de Venta” proporcionado al tarjetahabiente para recoger
producto o servicio. Evitando dañar, tachar o hacer ilegible la información
mandatoria establecida en el Anexo 15 del CID.
Consideración: En caso de que el Receptor de pagos no puede aplicar el cargo por

“complemento de Servicio” con tarjeta presente, la transacción queda como MoTo
tradicional (01) y puede solicitar otra forma de pago para concretar la entrega del
bien/servició.
El adquirente no tiene derecho a representar cuando los indicadores de la transacción en

disputa no se encuentren alineados al estándar técnico establecido en el Anexo 4I.
El tarjetahabiente tendrá como “máximo” 30 días naturales, a partir de la fecha de la

compra para recoger el bien o servicio.
Capítulo XXVI 4

2.3.- Flujo de la Operación MO/TO Autenticado
* En caso de que el Receptor de pagos no puede aplicar el cargo por “Complemento de Servicio” con tarjeta
presente, la transacción queda como Mo/To tradicional (01) y puede solicitar otra forma de pago para
concretar la entrega del bien/servicio.
Capítulo XXVI 5

CAPITULO XXVII
CONTACTLESS - NFC
Capítulo XXVII 1

Objetivo
Normar la operativa de este modo de acceso en el intercambio doméstico.
Alcance
Emisores y adquirentes en la operativa doméstica en todos los modos de acceso

compatibles con esta tecnología de manera enunciativa más no limitativa como son:
• Card (tarjeta)
• Mobile Phone or Smartphone
• Key Fob (Llavero)
• Watch (Reloj)
• Mobile Tag (Calcomanias)
• Wristband (Brazalete)
• Mobile Phone Case or Sleeve (carcasa)
1.- Indicadores en la operativa Contactless
Valores del PEM (Pos Entry Mode):
Corresponde al campo P-22 del mensaje de solicitud de una autorización a un Emisor
Valor 07 Solicitud de autorización con dispositivo con capacidad de lectura

Contactless y tarjeta con Contactless
Valores del Terminal Entry Capability:
Valor 3 Lector Contactless Chip
Valores del Flag Service Code:
El valor del Flag Service Code representa el primer digito del Código de servicio de
las tarjetas (2xx o 6xx), los valores asignados son:
Bandera valor A = Tarjeta de Chip EMV
Capítulo XXVII 2

VALORES CONTACTLESS EMV
PEM TERMINAL FLAG

SERVICE
ENTRY CODE CONCEPTO
CAPABILITY
07 3 A CONTACTLESS
El Emisor puede responder a una solicitud de autorización con el código de respuesta 65

(MasterCard) o 1A (Visa) para indicar al receptor de pagos que se deberá realizar una
transacción autenticada con lectura CHIP de contacto.
Los Adquirentes deben de soportar los códigos de respuesta 65 (MasterCard) o 1A (Visa)

para que la terminal solicite insertar la tarjeta y dar inicio a una transacción de tarjeta
presente.
2.- Token CZ - Indicador de Tipo de Dispositivo Contactless
De acuerdo con lo establecido en el Anexo 4I
3.- Resolución de Controversias
Las transacciones Contactless autorizadas, son responsabilidad del Emisor.
La solicitud de comprobantes de transacciones Contactless-NFC (PEM=07) serán

atendidas mediante el LOG de autorización certificado.
Cuando sea una transacción Contactless-NFC tokenizada se debe apegar a la regla 4.23
del capítulo I “Reglas Generales”.
Las transacciones duplicadas o múltiples deben aclararse conforme a lo establecido en el

capítulo II
(Resolución de Controversias) del CID.
Capítulo XXVII 3

4.- CVM Limit en transacciones Contactless
Límite de Piso en Terminales Contactless (Terminal Contactless Floor Limit)
El límite de piso en México es considerado Cero, por lo cual todas las transacciones deben
ser enviadas siempre en línea, es decir, no hay procesamiento de transacciones con
autorización Offline.
Límite Máximo del monto de una Transacción Contactless sin requerir autenticación
del tarjetahabiente (Terminal CVM Required Limit o CVM Limit)
Es el límite establecido en México para transacciones Contactless-NFC sin autenticación

del tarjetahabiente, el cual se determina a MX$400.00.
Límite Máximo del monto de una Transacción Contactless
Es responsabilidad del emisor establecer este límite a sus tarjetas y es su decisión autorizar
o no las transacciones que superen el límite. (CVM Limit).
5.- Penalizaciones
Si el adquirente no envía los indicadores será sujeto a la penalización 32 descrita en el

Capítulo XXIV Validación de Indicadores
Capítulo XXVII 4

CAPÍTULO XXVIII
CASH BACK EN EL
INTERCAMBIO DOMÉSTICO
Capítulo XXVIII 1
ANTECEDENTES
En este capítulo se regulan las operaciones de retiro de efectivo en comercios (cash back)
con Tarjetas de débito, así como la resolución de controversias derivadas del mismo.
DEFINICIONES
Para los efectos de este documento cash back es una transacción de tarjeta presente en la
cual se permite a un Tarjetahabiente utilizar su tarjeta de Débito para realizar el pago de
una compra y en la misma operación obtener dinero en efectivo.
ALCANCE
Regula las transacciones de Cash Back realizadas en la REDMX (intercambio doméstico)

con tarjeta de débito presente.
1.- CARACTERÍSTICAS DEL SERVICIO

• La operación se debe realizar con tarjeta de débito presente para transacciones en el
intercambio local, sujetándose a esta normativa.
• La operación queda disponible a todo comercio con Terminal Punto de Venta (TPV), por
lo que será decisión del Emisor su autorización.
• Será responsabilidad del Emisor el registro en el Bin Manager de los bines que
participan en esta operativa.
• Esta operativa no aplica para tarjeta no presente, así como para transacciones de check
in check out.
• El comercio podrá determinar el monto a ofrecer por Cash Back sin exceder la mediana
cuantía de acuerdo con las definiciones de la CUB, y el emisor podrá rechazar de
acuerdo con sus políticas de riesgo.
• La decisión de ofrecer el servicio de cash back al comercio es del Adquirente y la
facultad para autorizar la transacción corresponde al Emisor.
• No aplica para transacciones con operativa QPS.
• Solo aplica para transacciones con CHIP + PIN
• El Emisor es responsable de lo siguiente:
o Determinar los productos participantes (excluyendo vales que por regulación
estos productos no pueden recibir efectivo).
o Determinar el monto a retirar por operación de acuerdo con la evaluación de
riesgo por comercio y respetando el monto máximo diario.
o Controlar el importe diario autorizado para disponer de efectivo.
o De autorizar y honrar las transacciones que el receptor de pagos envía, de
acuerdo a los parámetros de riesgo del emisor.
o El emisor es responsable de asegurarse de autorizar transacciones solo
de tarjeta de débito.
Capítulo XXVIII 2
2.- CARACTERÍSTICAS DE LA OPERACIÓN:
• Todas las transacciones solo operan en línea con sus indicadores respectivos de
acuerdo con la operativa
o No aplica para transacciones manuales, autorizaciones voz, ni fuera de línea.
• La operación se autoriza por el importe total (compra + disposición en efectivo).
o No se permiten autorizaciones parciales, declinaciones parciales o referidas.
• La operación se considera como una sola que incluye el monto de la compra más el
monto de la disposición.
• La mensajería que manda el adquirente para que su cámara de compensación
intercambie, debe viajar de manera conjunta, es decir, la suma de la compra y el monto
de disposición en efectivo, (monto del cash back), por lo que el importe del cash back
tiene que desglosarse en otro campo que se incluye en el mismo mensaje de solicitud
de autorización de acuerdo al lay out descrito en este documento.
• Dentro del mensaje de autorización debe viajar la respuesta del emisor considerando la
suma de los dos importes:
• El importe total corresponde a la suma del valor de la venta y el importe del cash
back (compra más cash back).
• El importe del reverso deberá corresponder al monto de la transacción original (Compra
y efectivo) para lo cual se debe utilizar en el campo DE3 el código de transacción con
un processing code “09=CASH BACK” para el reverso de total de la transacción.
• Cuando aplique una devolución solo será por el importe de la compra.
• El ARQC se debe de calcular de acuerdo con el anexo 46 de este manual.
• Contactless se integrará en la segunda etapa.
3.- PROCESO ON LINE
El mensaje de autorización con formato ISO8583 generado por el comercio debe ser el
siguiente:
a) En la aplicación que desarrolle el adquirente debe enviar el DE 3 (código de

proceso). El valor a utilizar en el subcampo para identificar el tipo de transacción
CASH BACK será “09”. El resto de los subcampos permanecen sin modificación.
Para lo cual, el emisor debe estar preparado para recibir este tipo de transacción.
b) En el DE 4 (Monto de la Transacción) con el importe de la transacción se debe
considerar el importe total de la operación esto es el importe de la compra más el
importe por compra en efectivo.
c) En la mensajería que envía el adquirente debe contener en el DE 54 (Monto
Adicional) el importe de CASH BACK (este importe solo es informativo), con un
formato alfanumérico de 15 posiciones:
1-3 Longitud (012 fijo).
4-15 Importe dispuesto en efectivo, sin punto decimal como actualmente se maneja
el ISO 8583.
Capítulo XXVIII 3
El Emisor debe recibir el mensaje de autorización con las adecuaciones mencionadas
anteriormente, teniendo en cuenta las siguientes consideraciones:
a) Solo se utilizan los mensajes 0200 “autorización” y “0420” reverso” con

transacciones de cash back.
b) La Institución Emisora debe utilizar los códigos de rechazo 62 “tarjeta restringida”
cuando el BIN de la tarjeta no es válido para este tipo de transacción.
c) Las transacciones no deben ser autorizadas en stand-in por el Adquirente en caso
de que el Emisor no esté disponible. Por lo tanto, no deben generar transacciones
forzadas (0220/0221)
4.- PROCESO BATCH
Se identifica la transacción de cash back en el archivo de Intercambio con código de

transacción 05 (campo 1) indicando con una bandera que la transacción incluye cash back.
El layout del archivo modificado a 350 posiciones para contemplar los siguientes datos
adicionales:
IMPORTE DEL MONTO

*42 182 - 193 12 9(10) V9(02) Importe del cash back siempre será numérico.
CASH BACK
IMPORTE DE LA TASA Importe de la tasa cash back siempre será
43 194 - 205 12 9(10) V9(02)
CASH BACK, numérico y siempre viajará en ceros
*44 BANDERA DE CASH BACK 206 - 206 1 X(1) 0= no cash back y 1= cash back
Dentro del alcance de este documento se define el Campo 43 (Importe de la tasa cash
back) se mantiene en el lay-out para uso futuro.
5.- COMPENSACIÓN E INTERCAMBIO
• Se debe calcular la tasa de intercambio, de transacciones procesadas con cash

back, con tasa/cuota con base solo al importe de la compra.
• El campo importe en las carátulas de compensación no se modifica (compra cash

back).
• En las Carátulas de Intercambio entre Cámaras de Compensación debe reflejar el

monto de cash back, así como el monto de la compra.
Capítulo XXVIII 4
6.- ACLARACIONES
Las aclaraciones deben ser atendidas de acuerdo a lo establecido en el Capítulo II

Resolución de Controversias de este Manual Operativo, considerando las siguientes
premisas:
1. El Emisor no debe generar contracargos por esta operativa de cash back ya que
las transacciones se realizan mediante chip + pin
2. Para este tipo de transacciones el Emisor no debe generar solicitudes de

comprobantes (transacción 51 o 52), por lo tanto, no puede utilizar el código de
razón de Contracargo 79
3. En caso de aclaraciones de cash back por concepto de duplicadas o múltiples,

estas serán contracargadas por el importe total de la compra + cash back
Todas las transacciones deben de ser Chip + Pin las cuales serán aclaradas con el log de
autorizaciones del Emisor.
Capítulo XXVIII 5
CAPITULO “XXIX”
DOCUMENTO ESTÁNDAR PARA
OPERATIVAS CON TOKENIZACIÓN
Capítulo XXIX 1

Índice
1. Introducción
1.1 Objetivo
1.2 Referencias
1.3 Premisas y Alcance
2. Ecosistema de Tokenización
2.1 Conceptos principales
2.2 Participantes
2.2.1 Tarjetahabiente
2.2.2 Emisor
2.2.3 Receptor de Pagos / Comercio
2.2.4 Adquirente / Agregador
2.2.5 Token Service Provider (TSP) – Proveedor de Token
2.2.5.1 Bóveda de Tokenización
2.2.6 Token Requestor (TR) – Solicitante de Token
2.2.7 Usuario del Token
2.2.8 Control de BIN Tokenizado
2.3 Diagramas Generales
2.3.1 Descripción general de la solicitud de token
2.3.2 Descripción general de la solicitud de transacción con token
3. Programa de Tokenización
3.1 Enrolamiento
3.2 Aprovisionamiento
3.3 Tokenización del PAN
4. Mensajería para transacciones Tokenizadas

4.1 Descriptivo General (Token TM y Token TV)
4.1.1 Tarjeta presente
4.1.1.1 Transacción tokenizada – NFC
4.1.1.2 MST
4.1.2 Tarjeta no presente
4.1.2.1 Transacción tokenizada - eCommerce
4.1.2.1 CoF
5. Reglas Operativas y Controversias
Capítulo XXIX 2

1. Introducción
1.1 Objetivo
Establecer las características para el estándar en el intercambio de transacciones

de tokenización en la rede de medios de pagos.
1.2 Referencias
“Las siguientes reglas contienen disposiciones a las que se hace referencia en este
marco técnico. Se aplicará la última versión, incluidas todas las enmiendas
publicadas, a menos que se indique explícitamente una fecha de publicación.”
Texto tomado directamente del documento “EMVCo Payment Tokenisation

Specification”.
Normative References
The following standards contain provisions that are referenced in this technical
framework. The latest version including all published amendments shall apply
unless a publication date is explicitly stated.
Table 1.1: Normative References Publication Name

Reference
ISO/IEC 7812 Identification cards — Identification of
issuers
ISO 8583 Financial transaction card originated
messages — Interchange message
specifications (1987, 1993, 2003 and
other variants where appropriate)
ISO 9564-1 Financial services -- Personal
Identification Number (PIN)
management and security -- Part 1:
Basic principles and requirements for
PINs in card-based systems
ISO 13491 Banking — Secure cryptographic
devices, all parts
PCI DSS Payment Card Industry Data Security
Standard, including Token Service
Provider PCI appendix
Capítulo XXIX 3

1.3 Premisas y Alcance
1.3.1 Premisas
Los distintos esquemas de tokenización hacen uso de medios de acceso ya

regulados tales como (mas no de forma limitativa): Terminales punto de venta,
comercio electrónico, entre otros.
1.3.2 Alcance
1. Establecer los criterios técnicos de la mensajería en la red de medios de

pagos (ISO8583) para la inclusión de información tokenizada.
2. Describir los mecanismos mínimos de seguridad que establece el estándar
internacional y deben ser cumplidos de forma previa al envío de
transacciones.
3. Cualquier solución de “tokenización” que no se encuentre dentro de los
parámetros de este documento deben ser evaluadas de forma individual
para determinar su riesgo, interoperabilidad, escalabilidad en la red,
adaptación y posible inclusión en el presente documento.
Capítulo XXIX 4

2. Ecosistema de Tokenización
2.1 Conceptos principales
Token
Elemento de información cuyo objetivo es sustituir un elemento de datos sensibles

con un equivalente no sensible, mediante mecanismos de seguridad.
Token de Pago
Elemento que sustituye al PAN en la transacción financiera y que se crea bajo un

sistema de cifrado algorítmico que emite un código numérico distinto.
Uso de Token
Un Token de pago puede ser utilizado en:
• Tarjeta Presente en TPV teniendo como opciones;
• NFC
• MST
• QR Codes
• Tarjeta no Presente como opciones;
• Comercio Electrónico
• Botones de pago
• Card on File (CoF) / (Credencial en Archivo)
Tokenización de Cuenta
Reemplazó del número de cuenta de 16 dígitos, “Número de Cuenta Principal”
(PAN) con un identificador digital único llamado Token (Token de Pago).
DesTokenización de Cuenta (De-Tokenisation)

Convertir un “Token de Pago” con fecha de vencimiento de Token a un PAN
subyacente una fecha de vencimiento de PAN.
¿Quién pueden usar un Token de pago?
• Los usuarios o tarjetahabientes autorizados por su Emisor.

• Solicitantes de Tokens (Token Requestors)
Capítulo XXIX 5

¿Quién participan en la Tokenización?
ü Tarjetahabiente
ü Emisor
ü Receptor de Pagos / Comercio
ü Adquirente/Agregador
ü Token Service Provider (TSP)
ü Token Requestor (TR)
ü Usuario del Token
ü Control de BIN Tokenizado
2.2 Participantes
La Tokenización como medio de pago involucra diferentes roles. Algunos son roles
existentes dentro del ecosistema de pago tradicional y otros son roles específicos
de la Tokenización. Estos últimos pueden ser cumplidos por entidades existentes o
por entidades de reciente aparición.
A continuación, se describen cada uno de los roles dentro del ecosistema de

Tokenización como medio de pago.
2.2.1 Tarjetahabiente
El tarjetahabiente mantiene el rol actual. La relación entre el titular de la tarjeta y el

emisor de la misma no se verá afectada. En la mayoría de los casos, se espera que
el tarjetahabiente no sepa cuando haya sido emitido un Token de Pago (Payment
Token) para representar el PAN de su cuenta, sin embargo, el solicitante del Token
o el emisor de la tarjeta puede o no informar al tarjetahabiente.
Los tarjetahabientes podrán ser requeridos a participar en el proceso de

Identificación y Verificación (ID&V) definido por el adquirente o emisor. Cuando es
definido por el adquirente, el tarjetahabiente no participa en el ID&V.
2.2.2 Emisor
El emisor de la tarjeta continuará con el mismo rol, además de encargarse de su

autorización y administración continua de riesgos en el ecosistema de pago por
Tokenización.
El emisor debe coordinarse con los participantes apegados al estándar de EMVco.

para comprender la aplicabilidad y el manejo de los campos de acuerdo con la red
de pagos.
Capítulo XXIX 6

2.2.3 Receptor de Pagos / Comercio
El receptor de pagos / comercio continuará con sus funciones procesando

transacciones además de incluir las Tokenizadas. El receptor de pagos / comercio
necesitará implementar todos los requerimientos definidos en el estándar a través
de su Adquirente incluyendo el soporte a los campos específicos e interfaces de la
Tokenización.
Los receptores de pagos / comercios pueden recibir el Token, los datos

relacionados como la fecha de expiración del Token y el criptograma cuando este
aplique, en los siguientes escenarios.
- Desde el tarjetahabiente durante la Tokenización. A través de la solución con

la que se lleve a cabo la compra en el comercio.
- Como solicitante de Token, ya sea directamente o por una vía intermedia.
- Como una vía de las interfaces del solicitante de Token y el usuario del
Token.
2.2.4 Adquirente / Agregador

El adquirente / agregador continuará con su rol actual procesando todas las
transacciones incluidas las Tokenizadas. Deberán soportar los campos
especificados en el estándar para cada una de las interfaces definidas en la red de
pagos o adquirentes.
Es responsabilidad del adquirente / agregador el observar que los receptores de

pagos / comercios cumplan con los requerimientos definidos en el estándar.
2.2.5 Token Service Provider (TSP) – Proveedor de Token

El proveedor de servicio del Token es un rol específico de la Tokenización. Este es
el responsable de una serie de funciones que pueden incluir pero no limitarse a:
- Mantenimiento y operación de la bóveda de Tokens.

- Generación de Token.
- Aplicación de seguridad y controles.
- Emisión de Token y aprovisionamiento de los mismos.
- Funciones de registro para las solicitudes de Token.
- Tokenización y Destokenización.
- Aplicación de controles de restricción del dominio de Token.
- Entrega y revisión de criptogramas (cuando este aplique) en cada
transacción.
Los proveedores de servicio pueden participar en los diferentes tipos de solicitudes

de Token como parte de su participación dentro del programa de Token. Estas
especificaciones serán fundamentales para poder establecer procesos de
Capítulo XXIX 7

tokenización, para procesos fuera de EMVco. Manteniendo con esto la
interoperabilidad, escalabilidad del proceso.
2.2.5.1 Bóveda de Tokenización

Los sistemas de medios de pago continuarán con su rol y pueden optar por apoyar
a la Tokenización de acuerdo con el marco técnico. Los participantes que soportan
la Tokenización considerando el estándar de EMVco. son los responsables de
definir las políticas, procesos y programas de registro que conforman su programa
de Token.
Los participantes deberán considerar las implicaciones de negocio, técnicas y de

proceso, además de comunicar los requerimientos a las partes interesadas.
Los participantes como controladores de registro de BINes definen los campos

dentro de la red de pago.
2.2.6 Token Requestor (TR) – Solicitante de Token

El Solicitante de Token (Token Requestor) es un rol específico de la Tokenización.
El Token Requestor se registra con uno o más proveedores de servicios de Token
(Token Service Providers). Su registro se gestiona de acuerdo a las políticas de
cada Token Programme (Es el tipo de Token que proporciona el TSP).
Los solicitantes de Token son categorizados en tipos de solicitantes de Token

(Token Requestor Type) que pueden ser usados en conjunto con una
especificación de escenarios de la Tokenización para identificar los requerimientos
de seguridad y servicio.
Una vez registrado se le asignará uno o varios IDs, con el fin de soportar cada uno
de los diferentes escenarios. Los solicitantes de Token son los responsables del
manejo apropiado de los ID del solicitante (Token Requestor ID) cuando estos
soliciten un Token de Pago.
2.2.7 Usuario del Token

El usuario de Token tendrá una relación comercial con uno o varios solicitantes de
Tokens. Los solicitantes de Tokens pueden definir los requerimientos para el uso
de Tokens de pago compartidos.
El usuario de Token es un rol específico de la Tokenización. Los usuarios de Token

solicitan un Token de pago (Token Payment Requests) con Tokens de pago
compartido (Shared Payment Tokens) recibido desde los solicitantes de Token
(Token Requestors).
Capítulo XXIX 8

2.2.8 Control de BIN Tokenizado
Dentro del ecosistema doméstico, no se llevará el control de BINs Tokenizados y
únicamente se llevará el registro que se tiene en el BIN Manager.
2.3.1. Descripción general de la solicitud de token.
La figura 1.1 muestra un ejemplo de cómo funciona el proceso de solicitud de token.
Figura 1.1
La figura 1.2 es un ejemplo de cómo funciona el proceso de solicitud de token por

el tarjetahabiente.
Figura 1.2
Capítulo XXIX 9

2.3.2. Descripción general de la solicitud de transacción con token.
La figura 2.1 es un ejemplo de cómo podría ocurrir una transacción utilizando un

Token de pago. Todos los roles de procesamiento de transacciones existentes
continúan normalmente.
Figura 2.1
Capítulo XXIX 10

3. Programa de Tokenización
Un programa de token está compuesto por políticas, procesos y programas de

registro que facilitan la generación y emisión de tokens de pago por parte de los
proveedores de servicios de token para solicitantes de tokens registrados que usen
Token BIN o Rangos de BIN de token. Adicionalmente, un Programa Token
comprende las políticas y los procesos para la De-Tokenización, y la aplicación de
controles de restricción de dominio de token durante el procesamiento de token.
Aquellas entidades que introducen la tokenización de pago a un ecosistema de

pago existente son responsables de definir las políticas, procesos y programas de
registro que comprenden su programa de fichas.
Los proveedores de servicios de token y los solicitantes de token deberán cumplir

con las políticas relevantes, procesos y programas de registro cuando se opera
dentro de cualquier Token particular.
Programa.
Se deben considerar las siguientes políticas mínimas para establecer y mantener
un Programa de tokens:
Ø Asignación de Tokens de pago / Fechas de vencimiento del token a PAN
subyacentes / Expiración de PAN
Ø Fechas para su uso en el procesamiento de fichas
Ø Registro y aprobación de solicitantes de token y proveedores de servicios de
token
Ø Determinación de métodos de garantía de token para indicar el ID&V
realizado
Ø Establecimiento de requisitos de seguridad y controles relacionados con la
bóveda de token, token
Ø Aprovisionamiento y procesamiento de tokens
Ø Establecimiento de controles de restricción de dominio de tokens permitidos
Ø Establecimiento de requisitos para Token de pago y gestión del ciclo de vida
de PAN
Se deben considerar los siguientes procesos mínimos para procesar el pago

Tokenizado como Adquirente:
Ø Tokenización dentro de un Programa Token:

Ø Gestión numérica de PANs y Tokens de Pago.
Ø Emisión de tokens de pago, incluidos Token Assurance, Token Generation,
Token
Ø Emisión, ubicación de token y aprovisionamiento de token
Ø Operación y mantenimiento en curso de una bóveda de fichas
Ø Aplicación de seguridad y controles relacionados.
Ø Funciones de registro de Token Requestor, incluidas las ID de Token
Requestor y Token
Capítulo XXIX 11

Ø Tipos de Solicitantes.
Ø Aplicación de Controles de Restricción de Dominio Token
Ø Procesamiento de token, incluida la aplicación de controles de restricción de
dominio de token
Ø Token de pago y requisitos de gestión del ciclo de vida de PAN
Ø Soporte de interfaces del programa Token.
Ø Requisitos de informes del programa de token
Ø Requisitos para entidades autorizadas.
Las políticas y procesos previamente descritos se pueden aplicar a los diferentes

participantes que realizan soluciones de Token de Pago, los cuales podrían estar
fuera de las consideraciones de EMVCo. para un programa de tokenización (Token
Program).
Existen programas de tokenización (Token Program) que integran el uso de

criptogramas específicos para tokenización, los cuales son distintos a los que hoy
en día se utilizan en soluciones de comercio electrónico seguro. Sí el programa de
tokenización incluye el envío de criptogramas; estos deberán de ser incorporados
de acuerdo a las políticas y procesos del programa de tokenización (por ejemplo:
siempre se deberá de enviar el criptograma en la primera transacción financiera).
En el caso de VISA requiere del envío del criptograma TAVV, el cual deberá ser
enviado dentro del Token C6 sub 1 y el TSP lo recibe en el Field 126 SF 8.
En el caso de MasterCard requiere el envío del criptograma de DSRP, el cual

deberá ser enviado dentro del Token SX sub 5 y el TSP lo recibe en el DE 104.
En la definición de un programa de tokenización (Token Program), se debe de

considerar y comprender cualquier impacto potencial que afecte a uno o varios de
los participantes.
El estándar EMVCo. no define, acredita, aprueba, respalda ni evalúa programas de

token específicos.
3.1 Enrolamiento
El proceso de enrolamiento del tarjetahabiente es responsabilidad del Emisor y

debe apegarse a lineamientos de capitulo X de la CNBV y del TSP, donde durante
el enrolamiento participa la institución emisora para identificar, validar, autorizar o
tener conocimiento del usuario y la tarjeta que ha sido elegida para el proceso de
Tokenización y en su caso digitalización.
Tratándose del receptor de pagos, este debe apegarse a los lineamientos del TSP.
Capítulo XXIX 12

3.2 Aprovisionamiento
Una vez que el enrolamiento fue realizado de manera exitosa, el TSP genera de
manera remota el Token entre el dispositivo y el servidor de autenticación
transaccional (Transaction Manager).
Dependiendo del modelo implementado por el Emisor, Empresas Especializadas o

Servicio de Billetera Digital, el Token residirá en la Nube (Cloud) bajo el modelo
HCE o en un Elemento Seguro (SE) dentro del dispositivo del Tarjetahabiente
El aprovisionamiento de token ocurre después de la emisión del token. Es el

proceso mediante el cual se entregan un token de pago y los datos relacionados a
la ubicación del token.
Las consideraciones para el aprovisionamiento de tokens incluyen:
Ø Definición de los requisitos mínimos de la política de aprovisionamiento de
token, incluido el token de pago, cualquier información relacionada enviada
al solicitante de token y seguridad física y lógica.
Ø Definición de los requisitos mínimos del proceso de aprovisionamiento de
token, incluidas las acciones de confirmación del solicitante de token.
Ø Definición de los requisitos de interfaz de usuario. incluyendo las interfaces
aceptables para la transmisión del token de pago y datos relacionados
Ø Determinar si PAR está disponible para el aprovisionamiento e identificar los
medios para obtener los datos de los controladores BIN registrados
relevantes
Ø Facilitar el aprovisionamiento de token utilizando tecnología creada o
autorizada por el TSP que interactúa con los terminales, entornos de
billetera u otras tecnologías de pago.
3.3 Tokenización del PAN
Es la implementación de un método seguro de realizar pagos, involucrando una

plataforma de Tokenización, dispositivo móvil u operativas con cuentas
Tokenizadas.
Al contar con un PAN Tokenizado se identifican los siguientes tipos de

transacciones que se pueden efectuar:
ü Transacciones en comercios con pago por NFC.

ü Transacciones en comercio electrónico incluyendo indicadores EMV.
ü Transacciones en comercios con pago por inducción de banda
magnética (MST).
ü Token por dispositivos compartidos.
ü Card on File.
ü QR Code.
Capítulo XXIX 13

4. Mensajería para transacciones Tokenizadas
4.1 Descriptivo General (Token TM y Token TV)
De acuerdo a las especificaciones del Anexo 4I, referentes al Token TM y Token

TV dependiendo de las características solicitadas por el TSP.
4.1.1 Tarjeta presente

4.1.1.1 Transacción tokenizada – NFC / Inducción de banda magnética (MST)
Los siguientes diagramas muestran el flujo de una transacción Tokenizada con el

uso de un dispositivo NFC / Inducción de banda magnética (MST)
Figura 3.1
Capítulo XXIX 14

Figura 3.2
Capítulo XXIX 15

Transacción tokenizada – NFC
Para las transacciones de Tokenización, en donde fue sustituido el numero PAN

por un número dPAN, se identifican los siguientes elementos principales en la
mensajería ISO8583.
Tipo de 0200, 0210

Mensaje:
DE 22
PEM Campo Contenido Observaciones
07= Transacción Campo en las
POS Entry contactless EMV marcas:
Data Element:
Mode,
Campo [MC] DE22-SE1
ISO 22 [Visa] DE22-
SE1
DE 35
Track Campo Contenido Observaciones
II Mensaje 0200 y Cuando la
Track II, 0210 en el Cámara Emisor
Campo intercambio y destokeniza, el
ISO 35 con el contenido de
adquirente: este campo se
Contiene la altera para
información del informar al
PAN tokenizado emisor los datos
y la fecha de destokenizados.
expiración
asociada al En el resto del
PAN tokenizado flujo
transaccional se
*Mensaje 0200 respeta el
entregado al contenido
emisor: original.
Contiene la
información de
tokenizada del
PAN y fecha de
expiración
asociada. Este
track se arma
de manera
parcial al no
tener todos los
Capítulo XXIX 16

elementos del
track original.
*Aplica
únicamente
cuando la
Cámara emisor
destokeniza
DE 63 Campo Contenido Observaciones

Token Terminal 3 = Contactless Se considera el
C4 Capabilities, EMV uso de
Campo ISO dispositivos y
63, token terminales
C4sub11: contactless

Token Indicador Tipo de dispositivo Valor
CZ de Tipo de NFC con correspondiente
Dispositivo, tokenización. al dispositivo de
Campo pago utilizado
ISO 63,
token
CZsub2
DE63 Campo Contenido Observaciones

Token Token PAN Mensaje 0200 Permite que el
BL Campo ISO entregado al emisor conozca
63, token BL emisor: tanto la
Sub1: Token información de
(OPCIONAL) PAN tokenizada
Sub2: Fecha de (DE35) y el
expiración token asociado
correspondiente (token BL)
al PAN
tokenizado Aplica
únicamente
cuando la
Cámara Emisor
destokeniza
Capítulo XXIX 17

Afectación Online
• Se consideran los siguientes criterios y afectaciones:

o La información generada por el comercio en una transacción con
Tokenización, presenta la misma estructura que una transacción de
tarjeta presente.
o La combinación de valores en los campos PEM y BIN en el track II,
determinan la operativa de Tokenización. A partir de estos datos, el
responsable del proceso de destokenización (Emisor o Cámara
emisora), envía los datos correspondientes al TSP para obtener la
información de Tokenizada.
o Cuando el proceso de destokenización es realizado por la Cámara
emisora:
§ En el DE35 (track II), se entrega al emisor la información des-
Tokenizada.
§ De manera opcional y complementaria se le puede entregar el
token BL, con la finalidad de que el emisor conozca los datos
originales tokenizados.
§ El token BL se considera únicamente como informativo entre
la Cámara Emisora y Emisor, no se considera al intercambio
entre Cámaras.
o La información generada en la respuesta presenta la misma
estructura que una transacción de tarjeta presente.
Capítulo XXIX 18

Inducción de banda magnética (MST)
Para las transacciones de tokenización MST, en donde fue sustituido el numero

PAN por un número dPAN, se identifican los siguientes elementos principales en la
Tipo de 0200, 0210

Mensaje:
DE 22
90= Transacción Campo en las
POS Entry banda magnética marcas:
Data Element:
Mode,
Campo [MC] DE22-SE1
ISO 22 [Visa] DE22-
SE1
DE 35
expiración
transaccional se
emisor: original.
Contiene la
información de
tokenizada del
PAN y fecha de
expiración
asociada. Este
track se arma
de manera
parcial al no
tener todos los
Capítulo XXIX 19

elementos del
track original.
*Aplica
únicamente
cuando la
Cámara
emisor
destokeniza

Token Terminal 2 = Lector de Se considera el
C4 Capabilities, banda uso de
Campo ISO 63, magnética dispositivos y
token C4sub11 3 = Lector de terminales con
banda, capacidad de
entrada lectura de
manual, banda
lector de magnética
chip EMV y
Contactless
EMV
5 = Lector de
banda y
lector de
chip EMV-
compatible
7 = Lector de
banda y
entrada
manual
8 = Lector de
banda,
entrada
manual y
lector de
chip EMV-
Compatible
Método de 2= PIN. Este campo es
Identificación calificado por el
del responsable del
Tarjetahabiente, proceso de
Campo ISO 63, tokenización
token C4sub12 (Cámara
Emisor o
Emisor)
Capítulo XXIX 20

Token Bandera C = Se realizó la Mapeo de los
04 de verificación de la campos 44.5
verificación tarjeta y el VISA y
de la Código de DE48SE71SF2
tarjeta, validación fue MasterCard
Campo inválido.
ISO 63, Y = Se realizó la Es colocado por
token verificación de la el responsable
04sub3 tarjeta y el del proceso de
Código de de-tokenización
validación fue (Cámara
correcto Emisor o
Emisor)

Token Indicador Dispositivo móvil Valor
CZ de Tipo de correspondiente
Dispositivo, al dispositivo de
ISO 63,
token Este campo es
CZsub2 colocado por el
responsable del
proceso de
destokenización
en el mensaje
de respuesta
(Cámara
Emisor o
Emisor)

63, token BL
emisor: tanto la
al PAN
tokenizado Aplica
únicamente
cuando la
Capítulo XXIX 21

Cámara Emisor
destokeniza
Capítulo XXIX 22

Afectación Online

o Una transacción de inducción de banda magnética, NO requiere que
el dispositivo de pago ni la terminal tengan capacidades Contactless.
§ Por parte del dispositivo de pago, debe contar con capacidades
lógicas y físicas para realizar la inducción de banda magnética.
§ Por parte de la terminal, debe contar con capacidad de lectura
de banda magnética.
o La información generada por el comercio en una transacción por
inducción de banda magnética, presenta la misma estructura que una
transacción de tarjeta presente.
determinan la operativa de Tokenización. A partir de estos datos, el
responsable del proceso de destokenización (Emisor o Cámara
emisora), envía los datos correspondientes al TSP para obtener la
información de tokenizada.
emisora:
§ En el DE35 (track II), se entrega al emisor la información de
tokenizada.
entre Cámaras.
estructura que una transacción banda de tarjeta presente.
Capítulo XXIX 23

4.1.1.2 Transacción tokenizada – QR code
Los siguientes diagramas muestran el flujo de una transacción con QR code.
Figura 4.1
Capítulo XXIX 24

Figura 4.2
Capítulo XXIX 25

Para las transacciones de QR code, en donde fue sustituido el numero PAN por
un número dPAN, se identifican los siguientes elementos principales en la
Tipo de 0200, 0210

Mensaje:
DE 22
[Visa] 03 = Bar Campo en las
POS Entry code read / Código marcas:
Data Element: QR
Mode,
Campo [MC] 81 = [MC] DE22-SE1
ISO 22 eComm [Visa] DE22-
SE1
DE 35
expiración
transaccional se
emisor: original.
Contiene la
información de
tokenizada del
PAN y fecha de
expiración
asociada. Este
track se arma
de manera
parcial al no
tener todos los
elementos del
track original.
Capítulo XXIX 26

*Aplica
únicamente
cuando la
Cámara
emisor
destokeniza

Token Indicador Tipo de Valor
CZ de Tipo de dispositivo movil correspondiente
Dispositivo, con tokenización. al dispositivo de
ISO 63,
token Este campo es
responsable del
proceso de
destokenización
(Cámara
Emisor o
Emisor)

Token Indicador de 5 = Comercio En caso de
C0 comercio seguro, titular presentar
electrónico, autenticado (3D indicadores de
Campo ISO Secure) Comercio
63, token C0 6 = Comercio Electrónicos, la
sub5 seguro, titular información del
no autenticado criptograma
(3D Secure) puede copiarse
7 = a los tokens CE
Autenticación o C6
3D Secure no
realizada

Token Indicador de 09 = Comercio Valor
Q2 medio de electrónico correspondiente
acceso a transacciones
Campo ISO de comercio
63, token Q2 electrónico
Capítulo XXIX 27

63, token BL
emisor: tanto la
al PAN
tokenizado Aplica
únicamente
cuando la
Cámara Emisor
destokeniza
Capítulo XXIX 28

Afectación Online

comercio electrónico.
determinan la operativa de tokenización en comercio electrónico. A
partir de estos datos, el responsable del proceso de destokenización
(Emisor o Cámara emisora), envía los datos correspondientes al TSP
para obtener la información destokenizada.
emisora:
tokenizada.
entre Cámaras.
Capítulo XXIX 29

4.1.2 Tarjeta no presente
4.1.2.1 Transacción tokenizada – eCommerce
Los siguientes diagramas muestran el flujo de una transacción de comercio

electrónico tokenizada
Figura 5.1
Capítulo XXIX 30

Figura 5.2
Capítulo XXIX 31

Para las transacciones de comercio electrónico con tokenización, en donde fue
sustituido el numero PAN por un número dPAN, se identifican los siguientes
elementos principales en la mensajería ISO8583.
Tipo de 0200, 0210

Mensaje:
DE 22
01 = Valor actual Campo en las
POS Entry eComm marcas:
Data Element:
Mode, 09 = Mobile
Campo eComm [MC] DE22-SE1
ISO 22 81 = eComm [Visa] DE22-
10 = COF SE1
DE 35
expiración
transaccional se
emisor: original.
Contiene la
información de
tokenizada del
PAN y fecha de
expiración
asociada. Este
track se arma
de manera
parcial al no
tener todos los
elementos del
track original.
Capítulo XXIX 32

*Aplica
únicamente
cuando la
Cámara
emisor
destokeniza

Token Indicador Tipo de Valor
CZ de Tipo de dispositivo movil correspondiente
Dispositivo, con tokenización. al dispositivo de
ISO 63,
token Este campo es
responsable del
proceso de
destokenización
(Cámara
Emisor o
Emisor)

Token Indicador de 5 = Comercio En caso de
C0 comercio seguro, titular presentar
electrónico, autenticado (3D indicadores de
Campo ISO Secure) Comercio
63, token C0 6 = Comercio Electrónicos, la
sub5 seguro, titular información del
no autenticado criptograma
(3D Secure 2.0) puede copiarse
7 = a los tokens CE
Autenticación o C6
3D Secure no
realizada

Token Indicador de 09 = Comercio Valor
Q2 medio de electrónico correspondiente
acceso a transacciones
Campo ISO de comercio
63, token Q2 electrónico
Capítulo XXIX 33

63, token BL
emisor: tanto la
al PAN
tokenizado Aplica
únicamente
cuando la
Cámara Emisor
destokeniza
Capítulo XXIX 34

Afectación Online

comercio electrónico.
determinan la operativa de tokenización en comercio electrónico. A
partir de estos datos, el responsable del proceso de destokenización
(Emisor o Cámara emisora), envía los datos correspondientes al TSP
para obtener la información destokenizada.
emisora:
tokenizada.
entre Cámaras.
Capítulo XXIX 35

5. Reglas Operativas y Controversias
El proceso de Tokenización no implica cambio de responsabilidad, estas

transacciones se aclaran conforme a lo señalado en el capítulo I, “Reglas
Generales”, punto 4.23 y lo establecido en el capítulo II “Resolución de
Controversias” del Contrato de Intercambio Doméstico (CID).
Si la Tokenización es por parte del Adquirente, en el proceso de aclaración el

Emisor inicia dicha aclaración con el número de cuenta original (LOG de
autorizaciones, exhibit, etc.).
Capítulo XXIX 36

CAPÍTULO XXX
MONITOREO DE
AFILIACIONES POR EXCESO
DE CONTRACARGOS
Capítulo XXX
Monitoreo de Afiliaciones por Exceso de Contracargos.
Antecedentes:
La Industria ha puesto en marcha el Programa de Impulso a los Medios de Pago

Electrónicos, cuyo objetivo es incrementar y eficientar el uso de las operaciones
de tarjetas.
En el marco de este Programa, los participantes de la red de pagos con tarjeta

identificaron que los Emisores reciben un gran volumen de reclamaciones de sus
tarjetahabientes en transacciones de tarjeta no presente y su alto costo impacta
esta operativa.
En este sentido el Programa de Impulso a los Medios de Pago Electrónicos

estableció contar con un proceso de “Monitoreo de Transaccionalidad” para
evitar el exceso de contracargos por reclamaciones en la operativa de tarjeta
no presente, con el objeto de atender la causa origen del problema, así como
lograr la reducción del exceso de reclamaciones, o en su caso, la recuperación
de los costos operativos de las instituciones participantes en el intercambio.
Definición:
Los participantes han establecido un proceso que les permita validar que las
instituciones en el Intercambio no realicen prácticas fuera de normas en la
presentación de Contracargos.
1 Procedimiento para consolidar la información
Las Instituciones Emisoras a través de sus Empresas Especializadas deben

enviar al Árbitro Operativo, los archivos Electrónicos con los primeros
contracargos que hayan procesado sus instituciones, de transacciones
nacionales (on-us / of-us) dentro de los primeros 10 días hábiles de cada mes.
Si las transacciones no son ruteadas a través de la cámara de compensación, el

emisor dentro de los primeros 5 días hábiles de cada mes, debe generar un
archivo hacia su Empresa Especializada de acuerdo al layout definido y
debidamente llenado para que esta, concentre la información previo a su entrega
al Árbitro Operativo.
Los archivos electrónicos se deben entregar a través del medio seguro que la
Empresa Especializada determine con el total de contracargos de tarjeta no
presente.
Capítulo XXX
Archivos de Contracargos
Archivo 1. Vista Emisor, primeros contracargos de transacciones nacionales del

mes inmediato anterior, (on-us/off us, intercambio e intracámaras).
Archivos Transaccionales
Archivo 2. Mensual del total de transacciones de venta autorizadas y

compensadas por afiliación/grupo cadena (nacional)
El Árbitro Operativo debe consolidar la información proporcionada por las

Empresas Especializadas para integrarla a una base de contracargos y poder
determinar las afiliaciones/grupos cadena que rebasen el porcentaje del umbral
establecido para este proceso.
El Árbitro Operativo debe integrar las transacciones de tarjeta no presente para

este monitoreo con base en lo siguiente:
Los archivos de contracargos nacionales deben enviarse por las Empresas

Especializadas dentro de los primeros 10 días hábiles de cada mes, de acuerdo
con el siguiente layout:
• Nombre del Adquirente

• Número de Cuenta (Formato 123456XXXXXX1234)
• Importe de Contracargo
• Identificador de medio de acceso Q2
• Código de razón
• Opción del Código de Razón
• Fecha de Contracargo
• Afiliación del Receptor de Pagos
• Nombre del receptor de Pagos
Los archivos de transacciones deben enviarse por las Empresas Especializadas

dentro de los primeros 10 días hábiles de cada mes, de acuerdo con el siguiente
layout:
• Nombre del receptor de Pagos

• Afiliación del Receptor de Pagos
• Total de Transacciones autorizadas e intercambiadas por
afiliación
• Identificador de medio de acceso Q2
• Grupo
• Cadena
Capítulo XXX
2 Proceso General del Programa de Cumplimiento por Exceso de
Contracargos en transacciones de Tarjeta no Presente.
El Árbitro Operativo dentro de los 5 días hábiles posteriores a la recepción de la

información por parte de las Empresas Especializadas, consolida la información
recibida y realiza el proceso de monitoreo para detectar si existen Receptores de
Pagos que superen el umbral de riesgo, al aplicar el cálculo en las transacciones
de los últimos 3 meses, de acuerdo con lo siguiente:
¡ Dividir el total de contracargos entre el total de transacciones para obtener

el porcentaje de riesgo de cada afiliación o grupo/cadena
Total de Contracargos
= Porcentaje de Riesgo
Total de transacciones
¡ Se considerarán los últimos tres meses de contracargos y transacciones

para hacer el cálculo de los porcentajes del punto anterior, tomando en
cuenta 2 esquemas:
1. Los Receptores de Pagos que cuenten con 100 o más

contracargos y que alcancen el umbral de riesgo establecido en
2%.
2. Los Receptores de Pagos que tengan menos de 100 contracargos

y que alcancen el umbral de riesgo establecido en 8%, este
segundo reporte en ningún momento formará parte del proceso de
penalizaciones mientras el receptor de pagos se mantenga por
debajo de 100 contracargos.
¡ Los Receptores de Pagos que alcancen alguno de los umbrales de riesgo

de contracargos establecidos, se consideran en incumplimiento hasta que
en al menos 1 trimestre se mantengan fuera del umbral de riesgo.
¡ Una vez ejecutado el procedimiento para determinar a los Receptores de

Pagos que alcanzan el umbral, se notifica a través del buzón electrónico
del Árbitro Operativo, a la Institución / Empresa Especializada lo
siguiente:
¡ Receptores de Pago en incumplimiento con más de 100
contracargos.
¡ Receptores de Pago en incumplimiento con menos de 100
contracargos.
¡ Receptores de Pago con más de 100 contracargos,
próximos a rebasar el umbral de riesgo.
Capítulo XXX
¡ Transacciones susceptibles de cobro por exceso de
contracargos (cuando aplique).
¡ Receptores de pago que salen del programa de
cumplimiento.
Proceso Operativo
Monitoreo preventivo
Si un receptor de pagos con más de 100 contracargos supera el 1.75% del
umbral de riesgo, el árbitro operativo notificará a los Adquirentes
correspondientes, informando que su receptor de pagos está próximo a llegar al
umbral de riesgo del esquema de monitoreo, esto con el objeto de que el
adquirente inicie un proceso de análisis para evitar que el receptor de pagos
rebase el umbral de alertamiento establecido y entre al programa de
cumplimiento.
Incorporación al Programa de Cumplimiento

Si un Receptor de Pagos alcanza el umbral de riesgo del 2%, contra el total de
transacciones, el Árbitro Operativo notifica a los Adquirentes correspondientes el
inciso a) de la penalización 33 y la incorporación del Receptor de Pagos al
Programa de Cumplimiento.
Período de Corrección
Cuando un Receptor de Pagos es incorporado al Programa de Cumplimiento, el
Adquirente, en conjunto con su Receptor de Pagos, se obliga a identificar la
causa raíz e implementar medidas en conjunto para reducir el porcentaje de
contracargos por debajo del umbral de riesgo, para ello contará con un período
de corrección equivalente a los siguientes 3 meses a partir de la notificación del
incumplimiento.
En caso de que el Adquirente requiera de un plazo mayor, debe presentar su

plan de trabajo con fechas compromiso de corrección ante el Comité de Tarjetas,
quienes tomarán la decisión de autorizar la ampliación del plazo. La solicitud de
ampliación de plazo, se debe realizar dentro de los 45 días posteriores a la
notificación del incumplimiento, en caso de no realizarlo en tiempo no habrá
ampliación de plazo.
3 Sanciones por incumplimiento

Cuando se notifique incumplimiento de un Receptor de Pagos se aplica el inciso
a) de la penalización 33 (Amonestación) y el Adquirente cuenta con tres meses
para disminuir el umbral de riesgo de los Receptores de Pagos por debajo del
2%, en caso de no hacerlo, el Árbitro Operativo notifica el incumplimiento y el
Adquirente se hace acreedor a la penalización 33, conforme a lo siguiente:
Capítulo XXX
Cuando se determine la penalización 33, los Emisores NO podrán ejercer
el cobro de los contracargos que no hayan sido entregados, mediante los
archivos descritos en esta normativa.
Mes Descripción
Adquirente es notificado de la incorporación al Programa
de Cumplimiento de sus Receptores de Pagos.
A partir de la notificación, el Adquirente en conjunto con su

Receptor de Pagos, se hace acreedor al inciso a) de la
1
penalización 33 y debe corregir las causas que dieron
orígen a su incorporación al Programa de Incumplimiento
o demostrar que su incorporación fue a consecuencia de
recibir contracargos improcedentes
Si el Receptor de Pagos se mantiene por encima del

umbral de riesgo en los meses 5, 6 y 7, el Adquirente se
5, 6 y 7
hace acreedor al inciso b) de la penalización 33 por cada
contracargo que un Emisor haya realizado al Receptor de
Pagos en incumplimiento.

umbral de riesgo en los meses 8, 9 y 10, el Adquirente se
hace acreedor al inciso c) de la penalización 33 por cada
8, 9 y 10
contracargo que el Emisor haya realizado al Receptor de

umbral de riesgo del mes 11 en adelante, el Adquirente se
hace acreedor al inciso d) de la penalización 33 por cada
11 y posteriores contracargo que el Emisor haya realizado al Receptor de
A partir de la notificación de una sanción, el Adquirente puede demostrar que el

incumplimiento del Receptor de Pagos fue a consecuencia de recibir
contracargos improcedentes, para lo cual cuenta con 20 días naturales, período
durante el cual no se podrá ejercer el cobro de las sanciones que le hayan sido
determinadas.
Capítulo XXX
Un Receptor de Pagos solo puede ser liberado del Programa de Cumplimiento
si durante 2 trimestres continuos se mantiene por debajo del porcentaje del
umbral de riesgo o demuestra que se encontraría por debajo de dicho umbral,
tomando en cuenta únicamente los contracargos procedentes.
Si un Receptor de Pagos rebasa el umbral de riesgo como consecuencia de

haber recibido contracargos improcedentes, el Adquirente puede cobrar al
Emisor, lo señalado en la penalización 34 por cada contracargo improcedente
que haya recibido.
Flujo del Proceso
Capítulo XXX
CAPÍTULO XXXI
Operativa Domestica de Credencial en
archivo (CoF)
Capítulo XXX

1.- OBJETIVO
Regular las transacciones locales realizadas con el indicador de “Card on File” – “Datos
Almacenados en Archivo” (CoF), basado en transacciones “Iniciadas por el Tarjetahabiente”
(“Cardholder Initiated Transactions” - CIT) y transacciones “Iniciadas por el Comercio”
(“Merchant Initiated Transactions” - MIT).
Las operaciones de “Card on File” (CoF), están reguladas por el presente documento.
Por CoF se consideran las transacciones que utilizan el P-22 “Point of Service Entry Mode” -
“Modo de Entrada” (PEM) = 10, sin restricción de la naturaleza contable (crédito o débito).
Las transacciones CoF deben utilizar diferentes tokens del P-63 “Additional Data”;
Token PJ “POS Environment”, Token 17 “Visa Payment Service 2000” (VISA) y Token 20
“Interchange Compliance” (MasterCard).
1.1 Introducción
La evolución en el comercio digital junto con el desarrollo de nuevos modelos de negocios
ha dado como resultado un aumento en el número de transacciones en las que los receptores
de pagos (comercios, billeteras digitales, botón de pago, etc.) usan el CoF (incluyendo entre
otras cosas, “número de cuenta” o “token de pago”), con la finalidad de facilitar pagos
posteriores en sus plataformas.
Las transacciones CoF son aquellas en las cuales el tarjetahabiente ingresa sus datos en la
aplicación o portal del comercio / receptor de pagos y autoriza el resguardo de su
información, para generar transacciones posteriores.
Para mantener orden en el manejo de transacciones CoF, es necesario contar con los
lineamientos generales. Los cuales consideran los mandates de las marcas y las mejores
prácticas recomendadas.
A.- Registro de la cuenta por primera vez;

A.1.- Cuando el tarjetahabiente proporciona su información al receptor de pagos y da
autorización para que se resguarde su información para futuras transacciones.
B.- “Primera transacción” o “Verificación de cuenta”

B.1.- Si existe un monto para solicitud de autorización, se deberá mandar el mensaje
financiero indicando que se solicita el alta de una cuenta para CoF (Card on File).
B.2.- Si no hay monto a pagar, se deberá de presentar una solicitud de “verificación de
cuenta” indicando que se solicita el alta de una cuenta para CoF (Card on File).
Si se declina la “Primera transacción” o la “Verificación de cuenta”, la cuenta no se puede

considerar CoF (Card on File) y el receptor de pago no debe usarla para futuras
Capítulo XXX

transacciones.
C.- Resguardo de la información para cobros (datos de la tarjeta);

C.1.- Si la transacción de “Verificación de cuenta” se realizó de manera exitosa, el receptor
de pagos puede guardar los datos de la tarjeta en sus sistemas para ser utilizada en futuras
transacciones. Las cuales deberán de seguir las reglas de operación e indicadores que se
establecen en este documento.
D.- Transacción CoF (Card on File)

D.1.- En transacciones posteriores, el receptor de pagos puede hacer uso de los indicadores
correspondientes a CoF (Card on File), para que el emisor pueda identificar que dicha
transacción, tiene como antecedente una primera transacción exitosa.
E- Verificación de cuenta con PEM 10

E.1- Cuando el comercio / receptor de pagos ya tiene una cuenta previamente verificada, y
busca una nueva verificación de cuenta.
Para soluciones que operen con cuentas tokenizadas, se deberá de realizar el envío de los
criptogramas de acuerdo al tipo de servicio que tengan los participantes.
2.- Ecosistema de “Card on File” (CoF)
Capítulo XXX

Entidades Involucradas:
Comercios / “Receptores de pago” y Adquirentes

Cámara.
Emisores.
Clientes.
A continuación, se especifican algunas de las operativas comunes que pudieran operar como
transacciones CoF, Estas operativas no representan solo las transacciones que deben de
usar el indicador de CoF. Puede haber otros escenarios en los que se debe utilizar el
indicador de CoF.
2.1.- e-Comm
Esta operativa deberá apegarse a los valores y campos indicados en el capítulo XI del CID
“Comercio Electrónico”.
Cualquier transacción de e-Commerce realizada desde un sitio web, aplicación móvil (app)
de un comercio donde el tarjetahabiente haya guardado sus credenciales en CoF para pagos
previamente autorizados y/o compras posteriores que el mismo cliente solicite.
Con el crecimiento de “pedidos en línea (order online)” y “recoger en tienda (pick-up)”, el

indicador de CoF debe usarse si el tarjetahabiente paga en línea (online) con sus
credenciales CoF. El nuevo indicador no debe utilizarse cuando se realiza un pago en el
comercio / receptor de pagos y el comercio no guarda las credenciales de pago.
Para transacciones de e-Commerce que operen con cuentas tokenizadas, se deberá de

realizar el envío de los criptogramas de acuerdo al tipo de servicio que tengan los
participantes y en cumplimiento al capítulo XXIX del CID “Tokenización”.
2.2.- MOTO (transacción inicial)
Esta operativa deberá apegarse a los valores y campos indicados en el capítulo XXVI
“Operativa MOTO”.
Cualquier transacción MO/TO que se genere cuando el tarjetahabiente haya autorizado el

resguardo de sus credenciales en CoF. Con lo anterior el comercio / receptor de pagos puede
utilizar el indicador de CoF.
Para transacciones MO/TO que operen con cuentas tokenizadas, se deberá de realizar el
envío de los criptogramas de acuerdo con el tipo de servicio que tengan los participantes y
en cumplimiento al capítulo XXIX del CID “Tokenización”.
Capítulo XXX

2.3.- Cargos Periódicos.
Las características de transacciones que utilicen este medio de acceso (Token Q2 = “02”) se
establecen de acuerdo con los valores y campos indicados en el capítulo XIX “Cargos
Periódicos”.
Puede aplicar para transacción con medio de acceso de Cargos Periódicos en donde el
tarjetahabiente haya guardado sus credenciales para pagos previamente autorizados en el
comercio / receptor de pagos.
Para transacciones con medio de acceso de Cargos Periódicos que operen con cuentas
tokenizadas, se deberá de realizar el envío de los criptogramas de acuerdo con el tipo de
servicio que tengan los participantes y en cumplimiento al capítulo XXIX del CID
“Tokenización”.
2.4.- Promociones (Pagos Diferidos)
Las características de transacciones que utilicen este esquema de operación se establecen

de acuerdo con los valores y campos indicados en el capítulo XVI “Promociones (Pagos
Diferidos”.
El comercio puede generar cobros con promociones (pagos diferidos) y los indicadores de
CoF cuando el tarjetahabiente haya autorizado el resguardo de sus credenciales. Con lo
anterior el comercio / receptor de pagos puede utilizar el indicador de CoF.
Para transacciones con promociones (pagos diferidos) que operen con cuentas
tokenizadas, se deberá de realizar el envío de los criptogramas de acuerdo con el tipo de
servicio que tengan los participantes y en cumplimiento al capítulo XXIX del CID
“Tokenización”.
3.- Descripción general de CoF.
3.1.-Descripción General
Capítulo XXX

3.1.1.- “Primera transacción” o “Verificación de cuenta” (Enrolamiento del Cliente)
Toda transacción de “CoF” lleva una primera transacción, que genera el Comercio y que le
permitirá identificar si la cuenta es una cuenta válida, obtener un Transaction ID emitido por
el [Emisor/Empresa Especializada], como respuesta de una transacción exitosa y finalmente,
registrarla en su sistema de pagos para operaciones posteriores.
El Comercio deberá de contar con la aprobación del Cliente para que se puedan realizar el
registro de los datos de su tarjeta en el sistema y para los cargos posteriores.
Se recomienda que la primera transacción sea un Account Verification. Sin embargo, también
puede realizar la solicitud del Transaction ID en una transacción con solicitud de autorización
financiera. En ambos casos se debe de indicar que se solicita el alta de una cuenta para CoF
(Card on File).
3.1.2.- CASO SOLICITUD INICIADA POR EL COMERCIO
El emisor deberá generar y responder el valor del Transaction ID para todas las
transacciones autorizadas y el comercio deberá conservar el valor del campo Transaction ID
y enviar el original o el previo en las transacciones subsecuentes.
Transacción “Verificación de cuenta” (Account Verification):

P- 03 Processing Code con valor ‘81’ – Card Verification.
P- 04 Transaction Amount (monto $0.00).
P- 22 PEM en transacciones iniciales el PEM no puede ser igual a ‘10’.
Transacción Financiera:
P- 03 Processing Code con valor ‘00’ – Normal
P- 04 Transaction Amount.
Ver punto 6.- Administración ciclo de vida, para hacer el uso correcto del Token PJ.
3.1.3.-CASO SOLICITUD INICIADA POR EL TARJETAHABIENTE
El emisor deberá generar y responder el valor del Transaction ID en todas las transacciones
de enrolamiento y el comercio deberá conservar el valor del campo Transaction ID y enviarlo
en todas las solicitudes subsecuentes de COF.
Transacción “Verificación de cuenta” (Account Verification):

P- 03 Processing Code con valor ‘81’ – Card Verification.
P- 04 Transaction Amount (monto $0.00).
Transacción Financiera:
Capítulo XXX

P- 03 Processing Code con valor ‘00’ – Normal
P- 04 Transaction Amount.
Ver punto 6.- Administración ciclo de vida, para hacer el uso correcto del Token PJ.
3.2.- Diagrama General para la solicitud de autorización, utilizando CoF.
4.- INDICADORES CoF
Capítulo XXX

Capítulo XXX

Capítulo XXX

Capítulo XXX

4.1.- Cargos / Transacciones Subsecuentes.
Los Emisores y Adquirentes deberán validar y resguardar el identificador de

transacción (Transaction Identifier VISA /Trace Id MasterCard).
El identificador de transacción es responsabilidad del emisor y este podrá gestionarlo

de dos formas:
a.- En transacciones que sean originadas por plataformas de las marcas (botón de
pago, wallets, click to pay) o en transacciones internacionales, la información del
identificador de transacciones es proporcionada al comercio / receptor de pagos para
su integración en la solicitud de la autorización. De igual manera; si se requiere del
uso de criptogramas estos deberán ser enviados desde el inicio. (validar Capitulo XXIX
Tokenización, punto 3).
b.- En transacciones domesticas; en donde el comercio / receptor de pagos realice las

solicitudes del identificador de transacción (TRX ID) directamente. El emisor podrá o
no generar el identificador de transacción, y en caso de si hacerlo deberán de
resguardarlo tanto el emisor como el comercio para futuras transacciones. Si se
requiere el uso de criptogramas en transacciones subsecuentes deberán de ser
enviados.
En el caso de las marcas, el identificador de transacción lo manejan con las siguientes

características:
Descripción del Field /

Marca Campo Data Element Formato Campo
Token
VISA Transaction Identifier Field 62.2 15 N 17
Token
MC Trace ID DE 48.63 Ans - 15 20
Capítulo XXX

5.- Transacciones CoF
5.1.- Características de las transacciones CoF
Flujo operativo:
1) CoF – Relación Usuario / Comercio: Proceso que realiza el tarjetahabiente para establecer
la relación con el comercio / receptor de pagos. En el cual se pueden solicitar datos y la
autorización para el resguardo de credenciales de pago para futuras transacciones.
2) CoF – Enrolamiento / Verificación de Cuenta / Primer Transacción: El comercio / receptor
de pagos realiza la primera transacción en la cual solicita un identificador de transacción
utilizando los datos proporcionados por el tarjetahabiente (cliente). Esta acción se puede
realizar sin una compra y generando una verificación de cuenta.
3) CoF – Resguardo PAN en el comercio: Si la transacción inicial o verificación de cuenta
son exitosas, el comercio podrá resguardar las credenciales de pago para futuras
transacciones. Por lo que es importante que resguarde el identificador de la transacción.
4) CoF – Transacción CoF: El comercio / receptor de pagos puede utilizar el P-22 = “10”
indicando que es una transacción CoF además de agregar el identificador de transacción
(VISA – TranId / MasterCard - TraceId) y el token PJ.
Capítulo XXX

5.2.- Escenarios, casos de uso
5.2.1.- Transacción recurrente iniciada por el comercio en intervalos regulares fijos sin identificador de
transacción (Domestica sin tokenización):
Cuando el comercio con previa autorización del tarjetahabiente pueda resguardar el medio de pago y con
este, generar los pagos programados en un tiempo definido. La primera transacción puede ser para
verificación de datos o parte de un cobro inicial con el objetivo de verificar la cuenta. En transacciones
subsecuentes posteriores ya se podrá hacer uso del indicador PEM10.
En este escenario, el emisor no genera identificador de transacción, por lo que aplican las reglas actuales de
controversias para este caso de uso.
5.2.2.- Transacción recurrente iniciada por el comercio en intervalos regulares fijos con identificador de
transacción (Con cuenta tokenizada):
subsecuentes posteriores se podrá hacer uso del indicador PEM10. En caso de contar con el identificador de
transacción (VISA – TranId / MasterCard - TraceId) deberá ser enviado de acuerdo con el Token Program.
En este escenario el emisor no genera el identificador de transacción, ya que el proceso natural de la marca
lo genera como parte del proceso de tokenización.
En estas transacciones, el emisor no tiene derecho a ejercer un contracargo por desconocimiento de la

transacción.
Capítulo XXX

5.2.3.- Transacción recurrente iniciada por el comercio en intervalos regulares fijos con identificador de
transacción (Domestica sin tokenización):
subsecuentes posteriores ya se podrá hacer uso del indicador PEM10 y; en caso de contar con el
identificador de transacción (VISA – TranId / MasterCard - TraceId) deberá ser enviado.
En este escenario el emisor genera el identificador de transacción.
En estas transacciones, el emisor no tiene derecho a ejercer un contracargo por desconocimiento de la

transacción.
5.2.4- Transacción iniciada por el tarjetahabiente:
Cuando el tarjetahabiente realiza el alta de sus credenciales de pago en algún comercio o plataforma en el
cual otorga autorización para que pueda resguardar sus credenciales y con estas generar pagos a solicitud del
tarjetahabiente. La primera transacción puede ser para verificación de datos o parte de un cobro inicial con
Capítulo XXX

el objetivo de verificar la cuenta. En transacciones subsecuentes posteriores ya se podrá hacer uso del
indicador PEM10.
Tomar en cuenta proceso validación cuenta, se define basada en monto cero o con algún importe
En este escenario, el emisor no genera identificador de transacción.
Para transacciones con PEM10, Token PJ y Token Q2 subcampo 1 con valor diferente a 02, el emisor no tiene
derecho a ejercer un contracargo por desconocimiento de la transacción.
5.2.5- Transacción iniciada por el comercio por montos fijos y / o variables sin fecha programada.
Cuando el comercio con previa autorización resguarda las credenciales del tarjetahabiente y con este puede
generar pagos posteriores y / o adicionales sin estar sujetos a un importe fijo o fecha específica. La primera
transacción puede ser para verificación de datos o parte de un cobro inicial con el objetivo de verificar la
cuenta. En transacciones subsecuentes posteriores ya se podrá hacer uso del indicador PEM10 y; en caso de
contar con el identificador de transacción (VISA – Transaction identifier / MasterCard - TraceId) deberá ser
enviado.
5.2.6.- Transacción iniciada por el tarjetahabiente en billeteras y/o botón de pago:

Capítulo XXX

Cuando el tarjetahabiente tiene una billetera de pagos en la cual ya existan registradas sus credenciales; la
billetera es la responsable de resguardarlas y con estas generar pagos a solicitud del tarjetahabiente. Desde
la primera transacción se podrá hacer uso del indicador PEM10.
5.2.7.- Transacción sin CoF que cuenta con identificador de transacción
Cuando el comercio no resguarda las credenciales del Tarjetahabiente, pero realiza transacciones
subsecuentes tomando como referencia una autorización anterior (pre-autorización, check in) y/o cuenta
con una verificación previa; deberá de manifestarlo utilizando el identificador de transacción VISA –
Transaction Identifier / MasterCard - TraceId.
Las transacciones que operen con procesos de pre-autorización y/o Check In deberán apegarse a los valores y
campos indicados en el capítulo XXIII del CID “Operativa Check In y Check Out”.
Capítulo XXX

6.- Administración de estatus de transacción Card on File (CoF)
El token PJ permite identificar en qué momento de la transacción se encuentra establecido en el documento

de Especificación Técnica (Indicadores en Proceso Línea Campo 63, Anexo 4I) por lo que es importante
considerar las diferentes opciones que se tienen para los casos de uso indicados en el punto 5:
6.1.- Escenario 1.- Transacción recurrente iniciada por el comercio en intervalos regulares fijos.
6.1.1.-Transacción inicial, compra financiera más enrolamiento para cargos posteriores.

(MOTO, e-Commerce, Cargo Periódico, Tarjeta Presente)
El comercio / Receptor de pagos genera el token PJ

Token PJ sub 1 = 'E'; establecimiento de relación (transacción inicial de una cadena
CoF subsecuentes)
Token PJ sub 2 = 'R'; transacción de cargo recurrente
6.1.2.- Transacción recurrente posterior

Token PJ sub 1 = 'M'; Transacción CoF subsecuente iniciada por el comercio
Token PJ sub 2 = 'R'; transacción de cargo recurrente
6.2.-Escenario 2.- “Transacción iniciada por el tarjetahabiente” / “Transacción iniciada por el

tarjetahabiente en billetera y/o botón de pago”
6.2.1.- Transacción en que el tarjetahabiente utiliza sus credenciales de pago almacenadas.

(MOTO, e-Commer, Cargo Periódico, Tarjeta Presente)

Token PJ sub 1 = 'E’; establecimiento de relación (transacción inicial de una cadena
CoF subsecuentes)
Token PJ sub 2 = 'C'; transacción CoF
6.2.2.- “Transacción recurrente posterior” / “Transacción iniciada por el tarjetahabiente en

billetera y/o botón de pago”

Token PJ sub 1 = 'C'; Transacción CoF subsecuente iniciada por el tarjetahabiente
Token PJ sub 2 = ' '; [CIT] COF, 3rd Party Digital Wallet, Sin CoF / Default
6.3.- Escenario 3.- Transacción iniciada por el comercio por montos fijos y / o variables sin fecha
programada
6.3.1.- Transacción por monto fijo o variable que no ocurre en una fecha programada o
regular.
(MOTO, e-Commerce, Cargo Periódico, Tarjeta Presente)
Capítulo XXX

Token PJ sub 1 = 'E'; establecimiento de relación (transacción inicial de una cadena
CoF subsecuentes)
Token PJ sub 2 = 'C'; transacción CoF
6.3.2.- Transacción recurrente posterior

Token PJ sub 1 = 'M'; Transacción CoF subsecuente iniciada por el tarjetahabiente
Token PJ sub 2 = 'C'; Transacción [MIT] COF no Programada (UCOF).
7.- Proceso On Line
La información de CoF en el mensaje de autorización, esta normado en el Documento de

Especificación Técnica (Indicadores en Proceso Línea Campo 63, Anexo 4I) en el campo 63
de la mensajería, donde se incluyen los siguientes tokens:
Enrolamiento / Verificación de Cuenta / Primera Transacción
Ø Token PJ Subcampo 1: Indica si se trata de la transacción inicial de una cadena de

transacciones COF subsecuentes. Valores validos (E, “ “).
Ø Token PJ Subcampo 2: En la transacción inicial de una cadena de subsecuentes
indica el ambiente sobre el que operarán las transacciones CoF subsecuentes.
Valores validos (R, C, “ “).
Capítulo XXX

Si el comercio / receptor de pagos recibe el identificador de la transacción, debe de
resguardarlo para utilizarlo en transacciones posteriores.
Transacción CoF
Ø Token 17 / Token 20: Es el identificador de la transacción, el cual permite dar

seguimiento a la transacción original. Es un campo que recibe y administra el
comercio / receptor de pagos para mandarlo en transacciones posteriores.
Ø Token PJ Subcampo 1: Indica en transacciones CoF subsecuentes indica quién está
iniciando la transacción: Valores validos (M, C, “ “).
Ø Token PJ Subcampo 2: En transacciones CoF subsecuentes indica el ambiente en
que se están realizando las transacciones: Valores validos (R, C, “ “).
Cabe aclarar que si se envía el Token 17 no se envía el 20 y viceversa, ya que el Token 20

corresponde a tarjetas MasterCard y el 17 a tarjetas Visa.
Flujo para transacciones que se originan en plataformas de las marcas y/o

internacionales
8.- Proceso de controversias
Capítulo XXX

El uso del PEM10, identificador de transacción (TRX ID) y Token PJ son indicadores que permiten saber que la
transacción es subsecuente. Estos elementos son propios de la administración del método de pago y al no
interactuar con el tarjetahabiente en cada solicitud de autorización no se considera como factores de
autenticación (FDA).
Con lo anterior no existe proceso de cambio de responsabilidad asociado al manejo del indicador (PEM10)
para transacciones que implementen el resguardo de las credenciales en archivo (CoF). Todas las
transacciones se mantendrán con las reglas de operación, controversias y aclaración que las rige
actualmente.
A continuación, se presenta una tabla donde se identifican los diferentes escenarios de uso del indicador
PEM10:
TIPO DE ESCENARIO OPERATIVA REGLAS
Transacciones que implementan PEM10 y

usan el Token Q2 Subcampo 1 con valor Cargo periódico Cap. XIX
02. No utilizan TRX ID.
Transacciones que implementan PEM10,
TRX ID y usan Token Q2 subcampo 1 con Cargo periódico Cap. XIX
valor 02. Utilizando plataformas de la
marca para generar el TRX ID.
Transacciones que implementan PEM10,
TRX ID y usan Token Q2 subcampo 1 con Cargo periódico Cap. XIX
valor 02. Utilizando infraestructura del
propio emisor para generar el TRX ID
Para transacciones que implementan PEM
10 y usan Token Q2 subcampo 1 con valor Comercio Electrónico Cap. XI
09.
Para transacciones que implementan PEM
10 y usan Token Q2 subcampo 1 con valor Operativa MoTo Cap. XI
08.
Los Emisores y Adquirentes podrán desarrollar el TRX ID y Token PJ, de acuerdo con sus necesidades para la
integración de la operativa de Card on File (CoF).
Capítulo XXX

CID - 1 Dic 2021

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

CID - 1 Dic 2021

Cargado por

Copyright:

Formatos disponibles

CONTRATO DE

XXVIII. CASH BACK

1.1 Las Instituciones Emisoras y/o Adquirentes que requieran participar en el

Las Cámaras de Compensación deben registrar a las Instituciones que operen

Estructura del catálogo de Instituciones:

La estructura del número de una entidad estará compuesta por 06 dígitos

• En la primera posición con un dígito se ubica la Cámara (1,2 ó 3)

CÁMARA PREFIJO EMISOR Ó ADQUIRENTE CONSECUTIVO

CÁMARA PREFIJO DE CÁMARA

PREFIJO EMISOR Ó PREFIJO DE EMISOR Ó

Para las nuevas entidades, el Árbitro Operativo asignará un “6” en la tercera

1.2 En el Anexo 1 (Relación de BINES sujetos al Intercambio Doméstico), se

En caso de contingencia en el proceso de alta, baja, y/o modificación de

Las solicitudes se envían de forma electrónica a los responsables

Adicionalmente a las notificaciones señaladas en el párrafo anterior, los

No se puede dar de alta ningún BIN en el intercambio, si la institución a la

1.2.5 Las solicitudes de alta, baja o modificación de BINES recibidas entre el 15

1.2.6 Cada Cámara de Compensación receptora de una solicitud de Alta, Baja o

1.2.7 La Baja de un BIN se registra en la aplicación BIN Manager a solicitud del

Cuando la baja se derive de una suspensión determinada por la autoridad, la

La cámara de compensación emisora debe darlo de baja en sus procesos en

La solicitud de baja de una Institución registrada en el Anexo 29 (Instituciones

1.2.8 Cuando se solicite un movimiento de Modificación, de cambio de Tipo de

1. Solicitar modificación mediante la aplicación BIN Manager.

2. El Emisor debe mantener inactivo el BIN durante un plazo de 90 días,

3. El emisor debe entregar el documento proporcionado por las marcas

Cuando se solicite Venta de Cartera (Cesión de Derechos), se hará el cambio

Cuando se solicite Migración de Cámara de Compensación debe existir plan

1.2.9 Será responsabilidad de cada Adquirente actualizar los BINES de los

Registrar en el Anexo 9 (Relación de BINES Adquirentes) a través de su

El emisor está obligado a obtener la certificación LACPI de los Bines que

1.2.11 En caso de una incidencia en la aceptación de un BIN, esta debe ser

El Emisor antes de ingresar una incidencia debe realizar las siguientes

• El BIN fue dado de alta para la aceptación de la transacción, motivo de la

• El template del BIN se encuentra verificado por un LACPI y ha entregado

• La tarjeta correspondiente a la incidencia se encuentre vigente, activa y

• El Emisor debe realizar un monitoreo de transacciones del BIN de la

El Adquirente antes de ingresar una incidencia debe realizar las siguientes

• El BIN fue dado de alta para la aceptación de la transacción, motivo de la

• La aplicación se encuentra verificada por un LACPI de acuerdo con lo

• El Adquirente debe realizar un monitoreo de transacciones del BIN de la

En caso de que se detecte que algún Emisor/Adquirente no realizó estas

Una vez completada la lista de validación procede al envío de la incidencia

1. Incidencia en TPV / mPOS

3. Pago de tarjeta de crédito en sucursal

4. Incidencia en Portal Web

5. Incidencia en App Móvil

El registro debe ser menor o igual a 15 días hábiles de ocurrida la incidencia.

1.2.12 La herramienta de incidencias notifica al responsable para su atención,

Plataforma Plazo de Corrección

El Adquirente debe seleccionar la plataforma correspondiente a la afiliación

Todos los plazos se consideran a partir de la fecha de registro de la

Los planes de trabajo, evidencias y/o acuerdos, deben quedar registrados en

Las respuestas de incidencia atendida, deben aportar evidencias, enviar un

La Institución que registró la incidencia cuenta con un plazo de 10 días

Cuando se reciba respuesta de incidencia improcedente o resuelta y la

El grupo de análisis debe integrarse como mínimo por personal involucrado

Si la incidencia se reactiva, los plazos para proporcionar un diagnóstico o

INCUMPLIMIENTO AL PLAZO INICIAL

2 días hábiles después de concluir el plazo de 10 días hábiles y no presentar

En caso de nuevos incumplimientos el Adquirente se hace acreedor a lo

En caso de aplicar el inciso “f” de la penalización 32, se notifica al Comité de

INCUMPLIMIENTO AL PLAZO DE CORRECCIÓN

En caso de nuevos incumplimientos el Adquirente se hace acreedor a lo