Soporte 442 138 8102 Contratar internet
Fisher Comply · PLD y KYC

Sepa con quién opera: listas, riesgo e identidad en su propio ERP.

Dos módulos de Fisher Suite que se contratan juntos o por separado. Screening PLD criba a sus clientes, proveedores y personal contra las listas oficiales y le dice por qué hay una coincidencia. IdVerify verifica la identidad con INE o pasaporte, con una persona que decide. Los datos se quedan en su instancia.

Agendar una demostración Qué hace y qué no
  • Coincidencias explicadas campo por campo
  • Cuatro ojos y bitácora que detecta alteraciones
  • Ninguna verificación se aprueba sola
Cumplimiento · octubreVista ilustrativa
Juan Pérez EjemploLa CURP coincide con la lista · aprobada por una segunda persona
Confirmada
Importadora Ejemplo del CentroNombre idéntico, sin RFC en la lista · se pidió la constancia
En revisión
Marta López MuestraDocumento leído, datos coherentes · espera su revisión visual
Identidad
Una lista cambia → se vuelve a cribar sólo a quien se parece
Lo que suele pasar

Seis maneras de no saber con quién se opera

Conocer a la contraparte es una obligación para muchos y una buena práctica para todos. Hacerlo a mano no escala.

Buscar en un sitio, a mano

Alguien teclea el nombre en el buscador de una lista, cuando se acuerda, y no queda constancia de qué versión de la lista se consultó.

Listas que cambian y nadie revisa

Se criba al dar de alta. Seis meses después, la lista cambió y el cliente sigue ahí sin que nadie lo vuelva a mirar.

Alertas sin explicación

«Coincide al 87 %», ¿con qué? Sin saber por qué suena, el analista descarta todo o no descarta nada.

Decisiones sin segundo par de ojos

Una sola persona confirma o descarta, y mañana nadie sabe quién, cuándo ni con qué argumento.

Identificaciones por WhatsApp

Una foto movida de la credencial, sin consentimiento, sin revisión y guardada en el teléfono de alguien.

Cada área con su hoja

Ventas, compras y finanzas no ven lo que cumplimiento ya sabe, y se factura o se paga a quien no debía.

Cómo encaja todo

Del alta de la ficha a la decisión, sin salir del ERP

Cada pieza sirve por sí sola, pero juntas cierran el ciclo de conocer a su contraparte.

1

Identificar

La persona sube su documento por una liga, su portal o en mostrador, con su consentimiento.

2

Cribar

Su nombre, RFC y CURP se comparan con las listas oficiales. Al alta, al editar y cuando una lista cambia.

3

Revisar

Los casos se explican y los decide una persona; los confirmados, con una segunda.

4

Evaluar el riesgo

Matriz con sus pesos y sus niveles. Define cada cuánto se vuelve a revisar.

5

Actuar

La puerta advierte o bloquea la factura o el pago, y todo queda en una bitácora.

Dentro de la ficha

El cumplimiento vive donde ya trabaja su equipo

No es otro sistema al que hay que ir: es una pestaña de la ficha del cliente, del proveedor, del empleado y del lead.

admin/clients/client/79
Ficha de un cliente ficticio. Estado PLD y de identidad a la vista, las listas consultadas con su versión y el porqué del riesgo.
  • Qué listas y de qué fechaCada cribado guarda las fuentes y versiones que usó, para poder demostrarlo después.
  • Beneficiarios y representantesSe agregan a la ficha y se criban también.
  • Cribar ahoraUn botón para volver a mirar sin esperar a la cola.
  • En cuatro tipos de fichaClientes, proveedores, personal y leads; también contactos y candidatos.
Screening PLD · listas

Las listas oficiales, descargadas de su fuente y versionadas

  • Sanciones: OFAC (SDN y Consolidated), Reino Unido, Unión Europea, ONU, Consolidated Screening List de EE. UU., Canadá (SEMA) y Suiza (SECO).
  • México: SAT 69-B y 69-B Bis. Las del art. 69 del CFF (créditos firmes, no localizados…) están en el catálogo, apagadas de serie, y cuentan como riesgo fiscal, no como alerta.
  • La suya: una lista interna de la casa y una carga manual, para lo que no se puede descargar, como la Lista de Personas Bloqueadas de la UIF, que se entrega a los sujetos obligados por sus canales.
  • Salud de cada fuente: última carga, versión y cambios (qué entró, qué cambió y qué salió). Una carga que daría de baja más del 20 % de una lista se detiene y avisa.
admin/screening
Tablero. Casos por estado, cartera y la salud de cada lista con su última carga.
Coincidencias explicables

Cada alerta dice por qué suena

  • Qué casó con qué: las palabras del nombre, la cobertura, y si la fecha de nacimiento y el país coinciden, contra la versión de la lista que se usó.
  • RFC y CURP como identificadores exactos. Una CURP o un RFC iguales a los de una lista suenan siempre. De una CURP se deduce, además, la fecha de nacimiento y el sexo.
  • Pensado para nombres hispanos: orden invertido, sin acentos, sin segundo apellido, partículas («de», «del»), errores de una letra y apodos como «Chuy» por Jesús.
  • Un homónimo no estorba: con otra fecha de nacimiento, la alerta no se levanta.
  • Umbrales por fuente y por tipo de sujeto, editables, y un conjunto de casos etiquetados con el que se calibra el motor antes de cambiarlo.
admin/screening/cases/2
Un caso en revisión. Sujeto y lista lado a lado, la explicación de la alerta y la decisión con su motivo. Entradas de la lista interna, ficticias.
Casos con cuatro ojos

Una decisión de cumplimiento la firma una persona, y otra la aprueba

  • Las alertas se agrupan en un caso por persona. Cada alerta se decide: falso positivo (con su motivo), coincidencia confirmada o no concluyente.
  • Cuatro ojos configurable: nadie, sólo las confirmadas (de serie) o todas. Quien propuso no puede aprobar, y eso se comprueba en el servidor, no en la pantalla.
  • Un falso positivo no vuelve a sonar mientras no cambien los datos de la persona ni los de la lista.
  • Bitácora encadenada por huellas: si alguien la altera a mano, la ficha del caso dice en qué evento.
  • Constancia en PDF con las listas y sus versiones, la explicación de cada coincidencia, quién decidió y quién aprobó.
admin/screening/cases/1
Caso cerrado. Propuesto por un analista y aprobado por otra persona; la bitácora se verifica y dice «íntegra».
Riesgo y monitoreo

Un nivel de riesgo que usted define y que se mantiene al día

  • Enfoque basado en riesgo: resultado del cribado, país (con las listas del GAFI, editables), persona políticamente expuesta, riesgo fiscal, actividad, producto, canal, beneficiario controlador, antigüedad, volumen facturado y verificación de identidad.
  • Pesos, puntos, niveles y reglas de mínimo en pantalla. Cada cambio es una versión nueva: lo ya evaluado conserva la suya.
  • Revisión periódica por nivel (de serie 36, 12 y 6 meses): una tarea nocturna vuelve a cribar a quien la tiene vencida.
  • Puerta en facturación y compras: emitir una factura, pagar a un proveedor o dar de alta un pedido preguntan antes. De serie advierte; usted decide qué bloquea. Autorizar a operar a pesar de un bloqueo pide motivo y a una segunda persona.
admin/screening/risk
Matriz de riesgo. Pesos, puntos y niveles editables, con versión.
Todo es ajuste: cuatro ojos, tolerancias y puerta.

PEP, como complemento

Cargos públicos de Wikidata (dominio público) y el padrón de presidentes municipales del INAFED, con familiares y plazo configurable. No es un producto curado: vea «Qué hace y qué no».

IdVerify · verificación de identidad

Que la persona se identifique, y que alguien lo revise

Un flujo guiado, un aviso de privacidad con consentimiento y una pantalla de revisión donde cada comprobación dice lo que pasó y lo que no se pudo comprobar.

1

Consentimiento

Aviso completo; identificación y biometría en casillas separadas, con nombre tecleado.

2

Documento

Anverso y reverso con guía de encuadre y avisos de nitidez, luz y reflejos.

3

Selfie y retos

Si autorizó la biometría: una selfie y movimientos que pide el servidor.

4

Comprobaciones

Lectura de la zona mecánica, CURP, vigencia, edad, datos contra la ficha y cribado.

5

Revisión

Una persona aprueba o rechaza, con motivo. Opcionalmente, una segunda.

Revisión

Cada comprobación, con su resultado, y lo que no se pudo comprobar, dicho

  • Lectura en su servidor de la zona de lectura mecánica de la credencial y de los pasaportes, con sus dígitos de control; las confusiones del OCR se corrigen sólo cuando el dígito lo confirma.
  • CURP: dígito verificador y coherencia con la fecha, el sexo y el apellido leídos. También vigencia, edad mínima, QR, comparación con la ficha y aviso si el mismo documento ya se verificó para otra persona.
  • «No disponible» no cuenta como correcto. Lo que no se pudo comprobar manda la verificación a revisión, con su motivo.
  • Lo automático es sólo el rechazo de un documento caducado o de un menor de edad. Aprobar siempre lo hace una persona.
admin/idverify/sessions/1
Revisión. La comparación facial sale «No disponible» porque no hay motor facial: la compara una persona.
Imágenes con resguardo

Las imágenes no son de todos, y cada vista queda registrada

  • Cifradas (AES-256-GCM) en un destino de almacenamiento propio. Sin un destino cifrado, no se abre ninguna verificación.
  • Se ven sólo en la pantalla de revisión, con dos permisos (revisar y ver biometría), con marca de agua con el nombre de quien mira y registro de accesos.
  • Retención configurable: de serie, 10 años en flujos PLD, 90 días la selfie fuera de PLD y 30 días los fotogramas. No se guardan plantillas biométricas.
  • El titular sólo ve «en revisión», «verificada» o «no se pudo completar»: nunca el resultado de un cribado.
Imágenes de muestra. La credencial es ficticia y lleva el rótulo «MUESTRA»; el rostro es una ilustración.
Rechazo automático: documento vencido.
Sesiones y su estado.
Flujos y proveedores

Usted decide qué se pide, y quién hace cada parte

  • Flujos configurables: pasos, documentos aceptados (credencial para votar, pasaporte, tarjeta de residente…), prueba de vida, umbrales, si es de PLD y si criba al aprobar.
  • Cuatro canales: liga por correo, portal del cliente, mostrador y traspaso al móvil con un código QR.
  • Proveedores como piezas: el módulo trae la interfaz, los ajustes cifrados y el receptor de avisos firmados, pero ninguno viene conectado. Si contrata uno, un proveedor nunca aprueba ni rechaza solo: sus negativas van a revisión.
  • Motor facial opcional: un servicio de visión propio (Python, en un VPS) para comparar y puntuar. Sin él, lo compara una persona viendo las imágenes.
admin/idverify/flows/1
Editor de flujos. Lista Nominal y RENAPO aparecen como «No se comprueba» mientras no haya convenio.
Ajustes, con el aviso de sus límites a la vista.
Sin letra pequeña

Qué hace y qué no hace

Preferimos que lo sepa hoy y no en una auditoría. Esto es lo que está implementado y lo que no.

Lo que sí hace

Hoy, en producción
  • Descarga y versiona listas oficiales desde su fuente, y las vuelve a cribar cuando cambian.
  • Compara por nombre, RFC y CURP, y explica cada coincidencia.
  • Casos con cuatro ojos, bitácora encadenada y constancia en PDF.
  • Riesgo configurable y puerta en facturación y compras.
  • Lee la credencial y el pasaporte, comprueba dígitos de control, CURP, vigencia y edad.
  • Consentimiento, imágenes cifradas, marca de agua y registro de accesos.
  • Datos en su instancia: nada de su cartera sale a un tercero, salvo que usted elija un proveedor.

Lo que no hace

Dicho con claridad
  • No valida contra el INE ni contra RENAPO por defecto. Eso exige un convenio (o un proveedor que lo tenga). El módulo trae el espacio para el convenio propio, sin adaptador hasta tener el anexo técnico.
  • La prueba de vida propia no está certificada (iBeta, ISO 30107-3) ni detecta ataques de inyección, falsificaciones de calidad ni el chip NFC.
  • Sin servicio de visión, no compara rostros: lo hace una persona viendo las imágenes.
  • No hay medios adversos propios. Sólo vía un proveedor, que no está incluido.
  • Los PEP son un complemento, de fuentes abiertas, no un producto curado de datos de pago.
  • La Lista de Personas Bloqueadas es de carga manual: no se puede descargar públicamente.
  • No «cumple la ley por usted». Es una herramienta para su oficial de cumplimiento; la decisión y la responsabilidad son suyas.

Más datos, si los necesita. Quien requiera PEP mundiales curados puede conectar OpenSanctions como consulta de pago con una cuenta propia (viene apagada y cada consulta se cobra); quien requiera validación contra el INE o RENAPO, un convenio propio o un proveedor; y quien requiera una prueba de vida certificada, encargar esa parte a un proveedor. Cada pieza se enciende sin cambiar lo demás.

Parte de Fisher Suite

Lo que significa estar dentro del ERP

Facturación y compras

La factura o el pago preguntan antes de salir. Sin Screening activo, todo funciona como antes.

Antilavado

Las personas y representantes de Antilavado se criban y tienen su pantalla, sin modificar el módulo ni sus avisos a la UIF.

Expedientes

Un requisito «Verificación de identidad» que se pide desde su tarjeta y se cumple solo al aprobarse, con la constancia adjunta.

Comercio exterior

El 69-B del expediente aduanal se actualiza solo desde la descarga automática del SAT.

Bastino

Bastino busca en las listas, dice el estado de una ficha y propone cribar o asignar un caso. Decidir un caso o aprobar una verificación, nunca: lo firma una persona.

API, avisos y webhooks

Cribado por API con cupo por clave, avisos en la aplicación y eventos de plataforma (alerta, caso decidido, verificación concluida) para sus webhooks.

Siguiente paso

Cómo empezamos

Los dos módulos se contratan juntos o por separado, y se cotizan por instancia.

1

Demostración

Un cliente ficticio de punta a punta: alta, cribado, caso, riesgo y verificación.

2

Su política

Nos cuenta qué listas, qué umbrales, qué se bloquea y quién aprueba. Eso es configuración.

3

Puesta en marcha

Primera carga de listas, roles de cumplimiento, aviso de privacidad aprobado por su área legal y destino cifrado.

4

Operación

Se criba la cartera existente y su equipo atiende los primeros casos, acompañado por el nuestro.

Preguntas frecuentes

Lo que nos suelen preguntar

¿Valida mi INE o mi CURP contra el INE o RENAPO?

No de serie. Esas consultas exigen un convenio con la DERFE del INE o con RENAPO, o un proveedor que ya lo tenga. Hay un lugar para configurar un convenio propio, pero ningún proveedor viene conectado. Lo que sí hace es leer el documento, comprobar sus dígitos de control, la coherencia de la CURP, la vigencia y la edad, y ponerlo todo ante una persona que decide.

¿La prueba de vida está certificada?

No. La propia no cuenta con certificación independiente ni detecta ataques de inyección (cámaras virtuales, deepfakes en tiempo real). Sin el servicio de visión opcional, la comparación facial la hace una persona. Si necesita esa certificación, puede encargar esa capacidad a un proveedor y dejar el resto con el motor propio.

¿Qué listas se consultan y cada cuánto se actualizan?

OFAC (SDN y Consolidated), Reino Unido, Unión Europea, ONU, Consolidated Screening List de EE. UU., Canadá (SEMA), Suiza (SECO) y SAT 69-B y 69-B Bis, descargadas de su fuente oficial a la frecuencia que cada fuente permite; cada una tiene su propia salud en pantalla. Se suman la lista interna, la carga manual y los PEP de fuentes abiertas.

¿Y la Lista de Personas Bloqueadas de la UIF?

No es descargable públicamente: se entrega a los sujetos obligados por sus canales. Por eso se carga a mano desde el fichero que usted reciba, con un mapeo de columnas que se guarda, y sólo se ve dentro del panel.

¿Entrega PEP mundiales y medios adversos?

No como producto propio. Los PEP incluidos (Wikidata e INAFED) son un complemento. Quien necesite una cobertura mundial curada puede conectar OpenSanctions con una cuenta propia (consulta de pago, apagada de serie) o un proveedor. Los medios adversos no existen en el módulo y sólo se obtendrían por un proveedor.

¿Dónde quedan los datos y las imágenes?

En la base y el almacenamiento de su instancia. Las imágenes de identidad se guardan cifradas, con retención configurable, y nada sale del servidor salvo al proveedor que usted elija en un flujo. La inteligencia artificial, si la activa, sólo trabaja sobre texto y nunca sobre las imágenes.

¿Cuánto cuesta?

Las listas oficiales no tienen costo de licencia. El precio se cotiza por instancia, con Screening PLD e IdVerify juntos o por separado. Cotice con nosotros según su volumen y sus necesidades.

Agende una demostración

Veremos su política de cumplimiento y lo que hoy hace a mano, y se lo mostramos funcionando con datos ficticios.

Fisher Networks ventas@fishernetworks.net 442 138 8102
Escribir un correo
Sobre las capturas y los datos

Las capturas son de un entorno de demostración. Todas las personas, empresas, RFC y CURP que aparecen son ficticios (por ejemplo «Juan Pérez Ejemplo»), las entradas que producen coincidencias están en la lista interna de la demostración, y las credenciales son imágenes de muestra generadas para la ocasión, con el rótulo «MUESTRA»; los rostros son ilustraciones. Los nombres de las listas oficiales y sus fechas de carga son reales; ninguna captura muestra a una persona incluida en ellas. Las referencias a la LFPIORPI, al SAT o a las listas oficiales son informativas y no constituyen asesoría legal. «Fisher Comply» es el nombre comercial con el que se presentan los módulos Screening PLD e IdVerify de Fisher Suite.

Ver planes