IFPE, API, POS, tarjetas, promotores, datos, marca y fraude

Promotor de una IFPE: límites de representación

Punto de decisión

El promotor sólo realiza los actos expresamente permitidos y no recibe fondos, acepta clientes ni obliga a la IFPE sin facultad. Guiones, botones, dominios y capacitación deben respetar la frontera contractual. La entidad revisa muestras de comunicación y corrige cualquier apariencia de representación.

Checklist

1. Definir verbos permitidos y prohibidos.
2. Aprobar guiones, interfaces y capacitación.
3. Auditar comunicaciones y leads.

Patrón observado

En una negociación anonimizada, el contrato negaba representación pero el material comercial decía ‘abre tu cuenta con nosotros’; la inconsistencia se corrigió antes del lanzamiento.

Cómo llevarlo a operación

Prepare una lista de frases permitidas y prohibidas para promotores. Revise páginas, mensajes, eventos y capacitación. El lead debe llegar a la IFPE para evaluación sin que el promotor acepte o maneje fondos. Registre aprobación de materiales y muestreo posterior. Las quejas ayudan a detectar representación aparente. Si el aliado usa marca, la leyenda de rol debe acompañarla. El límite se sostiene cuando contrato y experiencia producen la misma impresión al usuario.

Prueba de estrés

Entregue al promotor un caso que exige modificar comisión o prometer aprobación. El guion y los permisos deben impedir ambas conductas y dirigir al canal autorizado. Revise materiales, correos y grabaciones de muestra para detectar representación aparente. La remuneración tampoco debe premiar altas sin calidad. Incidentes y correcciones permiten demostrar supervisión más allá de una cláusula contractual.

Base legal

• Ley para Regular las Instituciones de Tecnología Financiera (texto vigente) — artículos 11 a 13 sobre autorización y artículos 22 y siguientes sobre instituciones de fondos de pago electrónico.
• Ley General de Organizaciones y Actividades Auxiliares del Crédito (texto vigente) — artículos 81-A Bis, 81-B, 81-D, 86 Bis y 95 Bis, según el tema.

Finder fee en alianzas IFPE: cómo evitar incentivos tóxicos

Punto de decisión

Referral y servicio se separan por entregable y momento de causación. El referido termina en una introducción verificable; onboarding, asesoría o soporte requieren otro alcance. El fee excluye altas rechazadas, fraude y reversos, e incorpora clawback cuando la calidad del lead no cumple.

Checklist

1. Definir hito objetivo y auditable.
2. Excluir fraude, reversos y altas inválidas.
3. Incluir clawback y revisión de calidad.

Patrón observado

En un esquema anonimizado, el fee nacía al fondear, incentivando presión comercial sobre clientes aún no validados; se movió al hito autorizado y estable.

Cómo llevarlo a operación

Defina el hito que genera comisión y la evidencia que lo acredita. Una introducción no equivale a asesoría ni alta. Excluya operaciones revertidas, fraudulentas o rechazadas. Establezca ventana de atribución y reglas para leads duplicados. El clawback requiere cálculo y plazo claros. Revise incentivos periódicamente. El acuerdo debe pagar por valor legítimo sin empujar al referido a fondear antes de completar evaluación o inducir al promotor a representar facultades inexistentes.

Prueba de estrés

Modele la comisión sobre alta, primera operación y permanencia a noventa días. Compare qué comportamiento incentiva cada evento y establezca reversas por fraude, duplicidad o expediente incompleto. El aliado no debe poder alterar elegibilidad ni ocultar información para cobrar. La conciliación enlaza usuario, evento, monto y aprobación, y permite investigar concentraciones anómalas por promotor.

Base legal

• Ley para Regular las Instituciones de Tecnología Financiera (texto vigente) — artículos 11 a 13 sobre autorización y artículos 22 y siguientes sobre instituciones de fondos de pago electrónico.
• Disposiciones legales aplicables a transmisores de dinero — DCG derivadas del artículo 95 Bis y sus modificaciones.

SLA de fraude entre un transmisor y su aliado de pagos

Punto de decisión

El SLA de fraude se construye por escenario: credencial comprometida, cuenta destino alterada, suplantación, contracargo o falla compartida. Para cada uno asigna detección, bloqueo, evidencia, comunicación, reembolso y pérdida. Los relojes comienzan en eventos observables y no en avisos ambiguos.

Checklist

1. Crear matriz por vector y punto de control.
2. Fijar relojes de notificación y preservación.
3. Acordar regla de pérdida y cooperación.

Patrón observado

En una matriz anonimizada, doce escenarios de fraude tenían dueños distintos; el contrato original sólo regulaba uno.

Riesgo frecuente

Una cláusula que carga todo a quien cause el fraude no resuelve incidentes donde fallaron controles de ambas partes.

Cómo llevarlo a operación

Catalogue escenarios de fraude y asigne dueño por fase. Establezca reloj desde una señal observable y preserve logs antes de investigar. La comunicación al usuario debe coordinarse para evitar versiones distintas. Defina reembolso provisional y asignación final de pérdida. Pruebe un incidente compartido donde fallan dos controles. El contrato necesita una regla para evidencia incompleta. Un SLA útil acelera contención y decisión sin esperar a resolver primero quién tuvo la culpa.

Prueba de estrés

Simule una toma de cuenta detectada por el aliado antes que por el transmisor. El SLA debe definir canal, contenido mínimo, severidad, reloj y decisión sobre fondos. Después concilie alertas, tickets y comunicación al usuario. La responsabilidad por reembolso puede resolverse aparte; preservar evidencia y detener daño necesita una ruta inmediata que no espere la discusión comercial.

Base legal

• Ley para Regular las Instituciones de Tecnología Financiera (texto vigente) — artículos 11 a 13 sobre autorización y artículos 22 y siguientes sobre instituciones de fondos de pago electrónico.
• Circular 14/2017: disposiciones del SPEI, texto compilado — Circular 14/2017, texto compilado con modificaciones, incluida Circular 9/2026.

API de pagos: roles sobre instrucciones y datos

Punto de decisión

La API autentica aplicación y actor, limita alcance y conserva consentimiento e idempotencia. Cada payload se relaciona con usuario, propósito, respuesta y cambios de estado. El contrato distingue datos de cliente, telemetría, secretos y logs regulatorios, incluyendo retención y entrega.

Checklist

1. Usar autorización granular e idempotencia.
2. Registrar actor, propósito, payload y respuesta.
3. Definir propiedad, retención y entrega de logs.

Patrón observado

En una integración anonimizada, una credencial de servidor permitía operar para varios clientes sin un identificador del usuario que autorizó cada instrucción.

Riesgo frecuente

Una credencial de servidor común puede ejecutar instrucciones sin identificar a la persona que realmente autorizó el pago.

Cómo llevarlo a operación

Modele actor, cliente, aplicación y permiso en cada llamada. Use alcance mínimo, expiración e idempotencia. Conserve payload relevante sin exponer secretos. Pruebe repetición, cambio de dispositivo y revocación de consentimiento. Los logs deben ser exportables y estar sincronizados. El contrato asigna retención y cooperación. Una instrucción sólo es atribuible cuando puede conocerse quién la autorizó, con qué credencial, bajo qué versión y qué respuesta produjo el sistema.

Prueba de estrés

Siga una instrucción que la API acepta dos veces por pérdida de respuesta. Idempotencia, consulta de estado y llave compartida deben impedir doble ejecución. Registre qué entidad valida parámetros, conserva consentimiento y comunica el resultado. El contrato técnico y los logs deben usar la misma semántica; llamar 'confirmada' a una orden sólo recibida produce conciliaciones y mensajes incorrectos.

Base legal

• Ley para Regular las Instituciones de Tecnología Financiera (texto vigente) — artículos 11 a 13 sobre autorización y artículos 22 y siguientes sobre instituciones de fondos de pago electrónico.
• Ley Federal de Protección de Datos Personales en Posesión de los Particulares (texto vigente) — principios, aviso de privacidad, transferencias y medidas de seguridad.

POS, mandato y adquirencia: no son la misma actividad

Punto de decisión

POS, adquirencia, agregación y mandato describen funciones distintas que deben verse en el flujo contractual y bancario. Se identifica quién contrata al comercio, quién recibe, quién liquida y quién cobra cada comisión. El mandato no cambia los hechos si la plataforma dispone materialmente de recursos.

Checklist

1. Dibujar flujo contractual y bancario.
2. Alinear rol frente a comercio y pagador.
3. Separar comisiones por servicio y movimiento de fondos.

Patrón observado

En un contrato anonimizado, el diagrama comercial y la cláusula de liquidación atribuían la recepción a entidades diferentes.

Riesgo frecuente

Poner al agregador en una cláusula y a otro receptor en el diagrama de liquidación deja indeterminado el rol regulatorio.

Cómo llevarlo a operación

Dibuje flujos de contrato y dinero en carriles separados. Identifique quién celebra con comercio, quién recibe, quién procesa y quién liquida. Asigne cada comisión a un servicio concreto. Pruebe contracargo y devolución, pues revelan quién soporta la relación. El mandato debe coincidir con cuentas y facultades. Si la plataforma retiene o dispone, analice ese hecho expresamente. La conclusión regulatoria depende de la ejecución real y no del nombre elegido para la cláusula.

Prueba de estrés

Dibuje tres flujos separados: terminal que captura, mandato para instruir y adquirencia que liquida comercios. Para cada uno identifique contrato, fondos, comisión, contracargo y mensaje. La presencia de un POS no determina por sí sola la actividad jurídica. Si el producto combina funciones, la matriz explica qué entidad presta cada tramo y evita extender una figura contractual a todo el servicio.

Base legal

• Ley General de Organizaciones y Actividades Auxiliares del Crédito (texto vigente) — artículos 81-A Bis, 81-B, 81-D, 86 Bis y 95 Bis, según el tema.
• Ley para Regular las Instituciones de Tecnología Financiera (texto vigente) — artículos 11 a 13 sobre autorización y artículos 22 y siguientes sobre instituciones de fondos de pago electrónico.

Tarjetas, BIN y plataforma: matriz contractual mínima

Punto de decisión

El programa de tarjetas se mapea por emisor, titular de BIN, procesador, red, administrador y distribuidor. Contratos y anexos deben usar definiciones compatibles para autorización, saldo, liquidación, contracargo, fraude, marca y terminación. Una matriz señala qué documento prevalece en cada evento.

Checklist

1. Construir mapa de participantes y contratos.
2. Conciliar SLA y definiciones entre documentos.
3. Prever portabilidad de saldos, datos y tarjetas.

Patrón observado

En un comparativo anonimizado, dos contratos asignaban al mismo aliado la investigación de contracargos, pero con plazos incompatibles.

Riesgo frecuente

Plazos distintos para el mismo contracargo pueden hacer imposible que un aliado cumpla frente al siguiente.

Cómo llevarlo a operación

Cree una matriz de participantes y documento aplicable por evento. Alinee definiciones de autorización, saldo y liquidación. Compare plazos de contracargo entre red, procesador y distribuidor. Asigne fraude y atención al cliente sin vacíos. Pruebe terminación y portabilidad de datos. La licencia de marca debe sobrevivir sólo mientras corresponda. El programa es operable cuando ninguna obligación queda atrapada entre contratos incompatibles o proveedores que creen que otro responderá.

Prueba de estrés

Use una transacción con tarjeta emitida por un tercero, procesada bajo un BIN ajeno y mostrada en la plataforma del transmisor. Asigne autorización, tokenización, liquidación, contracargo, fraude y atención a partes concretas. Una marca visible no prueba emisión ni custodia. El usuario y los equipos internos deben recibir descripciones compatibles con la distribución contractual y técnica.

Base legal

• Ley para Regular las Instituciones de Tecnología Financiera (texto vigente) — artículos 11 a 13 sobre autorización y artículos 22 y siguientes sobre instituciones de fondos de pago electrónico.
• Ley Federal de Protección de Datos Personales en Posesión de los Particulares (texto vigente) — principios, aviso de privacidad, transferencias y medidas de seguridad.

Marca fintech: búsqueda, registro y licencia

Punto de decisión

La búsqueda marcaria revisa similitud fonética, figurativa, clases y servicios cercanos antes de invertir en campaña o dominio. Después se define titular y licencia con calidad, defensa, modificaciones, sublicencia y terminación. El análisis separa disponibilidad registral de riesgo comercial.

Checklist

1. Hacer búsqueda fonética y figurativa.
2. Definir titular y estrategia de clases.
3. Firmar licencia antes de campañas y dominios.

Patrón observado

En un memo anonimizado, el riesgo provenía de una marca similar en servicios cercanos y del uso público previo a cerrar la licencia.

Riesgo frecuente

Empezar uso público antes de asegurar la licencia puede convertir la marca en dependencia costosa de negociar.

Cómo llevarlo a operación

Busque variantes fonéticas, gráficas y conceptuales en clases relevantes. Analice coexistencia, notoriedad y servicios cercanos, no sólo coincidencia exacta. Defina estrategia de solicitud y titular antes del lanzamiento. La licencia regula calidad, defensa y terminación. Registre dominios y redes de forma coordinada. Si aparece oposición, evalúe alternativa antes de aumentar inversión. La marca elegida debe ser protegible y utilizable sin depender de una negociación incierta con tercero.

Prueba de estrés

Busque la denominación en clases relevantes y también variantes fonéticas, dominios y uso no registrado. Si una sociedad del grupo será titular y otra operará la marca, documente licencia, territorio, calidad y terminación. Antes de lanzar, revise que el signo no sugiera respaldo o licencia regulatoria inexistente. El expediente conserva búsqueda, decisión y versiones aprobadas de identidad.

Base legal

• Ley Federal de Protección a la Propiedad Industrial (texto vigente) — artículos 170 a 173 sobre registrabilidad y 239 a 244 sobre licencias de marcas.
• Ley para Regular las Instituciones de Tecnología Financiera (texto vigente) — artículos 11 a 13 sobre autorización y artículos 22 y siguientes sobre instituciones de fondos de pago electrónico.

Publicidad y estatus regulatorio en alianzas de pagos

Punto de decisión

La publicidad debe mostrar qué entidad presta cada servicio y qué papel tiene el aliado. Se revisan términos reservados, leyendas, orden de logos, CTA y afirmaciones sobre autorización o protección de recursos. Los materiales del promotor pasan por aprobación y monitoreo, no sólo el contrato principal.

Checklist

1. Incluir leyenda de rol junto al CTA.
2. Prohibir términos reservados o engañosos.
3. Someter campañas a revisión legal previa.

Patrón observado

En material anonimizado, el orden de logotipos y una frase de ‘cuenta’ hacían parecer que el promotor prestaba el servicio regulado.

Riesgo frecuente

Una frase de cuenta o entidad regulada junto al logo equivocado puede atribuir al promotor un estatus que no tiene.

Cómo llevarlo a operación

Prepare una matriz de afirmaciones por canal y entidad. Revise palabras reservadas, garantías, protección de recursos y supervisión. La leyenda de rol debe estar cerca del llamado a acción. Apruebe materiales antes de publicar y archive versión. Monitoree campañas de promotores y corrija desviaciones. Pruebe la impresión con una persona ajena al proyecto. Si no puede identificar quién presta el servicio regulado, la pieza necesita rediseño aunque cada frase aislada parezca correcta.

Prueba de estrés

Evalúe una pieza donde ambas marcas aparecen y el botón principal no identifica al prestador. Lea encabezado, llamada a acción, letras pequeñas y recorrido posterior como un solo mensaje. La corrección debe acercar el rol regulado al punto de decisión, no esconderlo en términos. Archive versión, aprobación y fecha de retiro para responder por campañas difundidas por aliados.

Base legal

• Ley General de Organizaciones y Actividades Auxiliares del Crédito (texto vigente) — artículos 81-A Bis, 81-B, 81-D, 86 Bis y 95 Bis, según el tema.
• Ley para Regular las Instituciones de Tecnología Financiera (texto vigente) — artículos 11 a 13 sobre autorización y artículos 22 y siguientes sobre instituciones de fondos de pago electrónico.

Aviso de privacidad en productos de pagos conectados

Punto de decisión

El aviso se construye desde el inventario real de datos e integraciones. Distingue KYC, monitoreo, fraude, ejecución de pagos, soporte, autoridad, marketing y cookies, además de encargados y transferencias. Cada nueva API dispara revisión antes de ampliar finalidades o destinatarios.

Checklist

1. Actualizar inventario de datos por integración.
2. Distinguir finalidades necesarias y secundarias.
3. Controlar transferencias, encargados y cambios de aviso.

Patrón observado

En un mapa anonimizado, la interfaz enviaba datos a más actores que los descritos en el aviso porque nuevas APIs se habían agregado después de su aprobación.

Riesgo frecuente

Mantener un listado genérico de proveedores puede ocultar que un aliado usa datos para una finalidad propia.

Cómo llevarlo a operación

Levante inventario desde APIs y bases, no desde el aviso anterior. Asigne finalidad, base, destinatario, retención y medida de seguridad por dato. Distingua encargado de tercero con propósito propio. Revise transferencias y cambios de proveedor. La interfaz debe presentar versión vigente y conservar aceptación cuando aplique. Pruebe derechos y revocación de finalidades secundarias. El aviso resulta fiel cuando puede recorrerse desde cada párrafo hasta un flujo técnico real.

Prueba de estrés

Traza un dato de geolocalización desde la captura hasta analítica, proveedor antifraude y eliminación. En cada salto identifique finalidad, rol, región y plazo, y compárelo con el aviso mostrado. Pruebe revocación de una finalidad secundaria sin bloquear la función esencial. El inventario técnico debe poder demostrar que una promesa de minimización o supresión se ejecuta en sistemas y copias.

Base legal

• Ley Federal de Protección de Datos Personales en Posesión de los Particulares (texto vigente) — principios, aviso de privacidad, transferencias y medidas de seguridad.
• Ley para Regular las Instituciones de Tecnología Financiera (texto vigente) — artículos 11 a 13 sobre autorización y artículos 22 y siguientes sobre instituciones de fondos de pago electrónico.

Expediente de incidente y fraude en pagos

Punto de decisión

El expediente de fraude consolida autenticación, dispositivo, instrucciones, alertas, mensajes, logs, cambios de estado y movimientos. Todos los eventos se normalizan a una zona horaria y conservan fuente. La cadena de custodia permite decidir bloqueo, reclamación, recuperación y reporte sin alterar evidencia.

Checklist

1. Normalizar reloj, zona y fuente.
2. Preservar evidencia antes de rotar logs.
3. Asignar decisión, comunicación y recuperación por evento.

Patrón observado

En un incidente anonimizado, cada proveedor usaba una zona horaria distinta; normalizar tiempos cambió la secuencia aparente de autorización y bloqueo.

Riesgo frecuente

Comparar logs con relojes distintos puede invertir la secuencia y atribuir erróneamente autorización o demora.

Cómo llevarlo a operación

Preserve evidencia antes de bloquear credenciales o rotar logs. Normalice reloj, zona y fuente de cada evento. Construya cronología con autenticación, instrucción, alerta, comunicación y movimiento. Identifique huecos y solicite datos al proveedor con plazo. Separe investigación, reclamación y reporte regulatorio. Documente recuperación y aprendizaje. El expediente debe permitir que otra persona reproduzca la secuencia y distinga fraude confirmado, intento, error técnico o disputa sin alterar los registros originales.

Prueba de estrés

Preserve un caso en el que el atacante cambia credenciales, instruye un pago y borra una notificación. Congelar logs antes de remediar permite reconstruir autenticación, dispositivo, decisión antifraude, movimiento y comunicación. Normalice zonas horarias y documente cada hueco. Investigación, reclamación, recuperación y reporte pueden compartir evidencia, pero requieren decisiones y responsables claramente separados.

Base legal

• Circular 14/2017: disposiciones del SPEI, texto compilado — Circular 14/2017, texto compilado con modificaciones, incluida Circular 9/2026.
• Ley Federal de Protección de Datos Personales en Posesión de los Particulares (texto vigente) — principios, aviso de privacidad, transferencias y medidas de seguridad.