PCI MPoC (Mobile Payments on COTS) es el estándar de seguridad del PCI SSC que permite aceptar pagos con tarjeta — por aproximación y con ingreso de PIN — directamente en un smartphone o tablet común, sin hardware dedicado. Define objetivos de seguridad para el software, además de la atestación y el monitoreo continuo que hacen seguro ese modelo.
En la práctica, MPoC es lo que sustenta las soluciones de "Tap to Pay" y SoftPOS: una aplicación instalada en un dispositivo de consumo (COTS, commercial off-the-shelf) pasa a leer tarjetas por la antena NFC y a capturar el PIN en la propia pantalla. Como ese dispositivo no fue diseñado para ser un terminal seguro, el estándar desplaza la protección del hardware hacia una combinación de software resistente a ataques, cifrado de los datos de la cuenta y una infraestructura de atestación y monitoreo que verifica, transacción a transacción, si el entorno es confiable.
¿Qué significa la sigla MPoC?
MPoC significa Mobile Payments on COTS — pagos móviles en dispositivos de consumo. "COTS" es cualquier equipo de consumo sin modificar: un celular Android, un iPhone, una tablet. Ese es el punto central del estándar: aceptar datos de tarjeta en un equipo que no pasó por una evaluación física de seguridad, sin lector externo y, cuando es necesario, capturando el PIN en la pantalla táctil.
Publicado por el PCI Security Standards Council en 2022, MPoC es un estándar basado en objetivos de seguridad, y no en una lista cerrada de controles obligatorios. En vez de mandar "haga exactamente X", define el resultado que debe alcanzarse y deja al proveedor demostrar, con evidencia, que la implementación cumple ese objetivo. Esto da flexibilidad para distintas arquitecturas — pero exige evaluación técnica competente para probar equivalencia.
¿Cuál es la diferencia entre MPoC, SPoC y CPoC?
MPoC unifica y amplía dos estándares anteriores: SPoC, centrado en el ingreso de PIN, y CPoC, centrado en la lectura por aproximación. Antes de MPoC, un proveedor que quisiera aceptar contactless y PIN en el mismo celular debía conciliar dos estándares separados. MPoC junta ambos escenarios en un único marco modular y además permite transacciones de mayor valor con verificación de PIN en pantalla.
| Aspecto | SPoC | CPoC | MPoC |
|---|---|---|---|
| Sigla | Software-based PIN Entry on COTS | Contactless Payments on COTS | Mobile Payments on COTS |
| Ingreso de PIN en el celular | Sí, en pantalla | No | Sí, en pantalla (opcional por módulo) |
| Lectura por aproximación (NFC) | No (exige lector SCRP externo) | Sí, en la antena del COTS | Sí, en la antena del COTS |
| Lector de tarjeta externo | Obligatorio (SCRP) | No | No |
| Verificación del portador (CVM) | PIN | Sin CVM / limitada | PIN en la pantalla del COTS (módulo PIN Entry on COTS); demás CVM según la tarjeta/marca |
| Estructura | Controles prescriptivos | Controles prescriptivos | Objetivos de seguridad, modular |
| Situación | Estándar anterior, aún vigente | Estándar anterior, aún vigente | Estándar actual y unificado |
La lectura de la tabla es directa: SPoC resolvía el PIN pero dependía de un lector de tarjeta seguro acoplado; CPoC resolvía la aproximación pero sin PIN, lo que limitaba el valor de las transacciones; MPoC entrega ambos en la misma aplicación y sustituye la lógica de "control prescriptivo" por una de objetivos, permitiendo arquitecturas más variadas siempre que la seguridad quede comprobada.
¿Cómo protege MPoC los datos sin hardware seguro?
El estándar protege la transacción distribuyendo la seguridad en tres frentes que trabajan juntos, ya que ninguno de ellos es confiable de forma aislada en un dispositivo de consumo. La confianza no viene del equipo: viene de la capacidad del software de protegerse, cifrar los datos y ser verificado en forma remota en cada uso.
Los tres frentes son:
- Software resistente a ataques. El SDK y la aplicación de pago se construyen con protecciones contra ingeniería inversa, adulteración, hooking y depuración. El estándar trata el propio entorno de ejecución como hostil.
- Protección de los datos de la cuenta. El número de tarjeta y el PIN se cifran lo más cerca posible del punto de captura y nunca quedan expuestos en claro en la memoria del dispositivo ni en tránsito.
- Atestación y monitoreo continuos. Un backend verifica, transacción a transacción, la integridad de la aplicación y del dispositivo — si hay señales de root, emulación, adulteración o entorno comprometido — y puede bloquear o reaccionar en tiempo real.
MPoC organiza estos requisitos en módulos. Hay módulos para el núcleo de la solución (CORE), para la protección del SDK, para la atestación y el monitoreo, para el ingreso y el procesamiento seguros de los datos de la cuenta, para el ingreso de PIN en el COTS, para transacciones offline y para la gestión e integración del software. Esa modularidad es lo que permite evaluar solo las partes relevantes para cada tipo de producto.
¿Cómo funciona la evaluación de conformidad?
La conformidad con MPoC la atestigua un laboratorio reconocido por el PCI SSC, y no una autoevaluación. El proveedor no "se declara" conforme: somete la solución o el componente a un evaluador acreditado, que lo prueba contra los objetivos de seguridad y emite un informe aceptado por el Council.
El flujo típico involucra estas etapas:
- Alcance y clasificación. Se define qué se está evaluando — una solución MPoC completa o un componente/SDK — y qué módulos aplican a esa arquitectura.
- Preparación y evidencias. El proveedor reúne la documentación de diseño, el análisis de amenazas, las decisiones de arquitectura y las evidencias de que cada objetivo de seguridad se cumple.
- Evaluación de laboratorio. El laboratorio reconocido ejecuta el análisis de seguridad: revisión de diseño, pruebas del software (incluida la resistencia a ataques), validación del cifrado y de la lógica de atestación y monitoreo.
- Listado. La solución o el componente aprobado pasa a constar en la lista pública de productos validados del PCI SSC, lo que da visibilidad a adquirentes y marcas.
- Mantenimiento continuo. A diferencia de una auditoría puntual, MPoC presupone atestación y monitoreo en operación y revalidación periódica; cambios relevantes en el software exigen reevaluación.
Un punto importante: como el estándar está basado en objetivos, buena parte del esfuerzo está en demostrar equivalencia — probar, con evidencia técnica, que una elección de arquitectura cumple el objetivo de seguridad previsto. Aquí es donde la calidad del trabajo de seguridad antes de la presentación determina el tiempo y el costo de la evaluación.
¿Quién necesita PCI MPoC en Brasil?
Necesita MPoC quien desarrolla o provee software que convierte un dispositivo de consumo en instrumento de aceptación de tarjeta. En el ecosistema brasileño de pagos, esto alcanza a un grupo creciente de empresas a medida que el "Tap to Pay" se populariza:
- Adquirentes y subadquirentes que ofrecen aceptación por aproximación en el propio celular del comercio, sin terminal físico.
- Fintechs y facilitadores de pago que embarcan la función de cobro dentro de su propia aplicación.
- ISV y desarrolladores de SoftPOS que construyen el SDK o la app de pago vendida a terceros.
- Marketplaces y plataformas que quieren que el vendedor cobre presencialmente usando solo el smartphone.
En Brasil, la exigencia de MPoC llega por dos vías que se suman. La primera es contractual y de marca: Visa, Mastercard y demás marcas exigen validación PCI para habilitar soluciones de aceptación en el celular, y esa exigencia baja por la cadena hasta el desarrollador. La segunda es regulatoria: las instituciones de pago y los arreglos de pago operan bajo la supervisión del Banco Central, y las resoluciones del BACEN/CMN sobre seguridad cibernética — incluida la 4.893 — imponen requisitos de gestión de riesgo y de seguridad que hacen de la adopción de estándares reconocidos como MPoC una parte natural de la gobernanza. Quien procesa datos de portador también debe observar la LGPD en el tratamiento de esa información.
Vale la distinción: MPoC trata de la solución de aceptación en el COTS. No sustituye la conformidad con el PCI DSS del entorno que procesa, almacena o transmite los datos de tarjeta en el backend — ambos conviven. Una operación madura combina la solución MPoC validada en el borde con un entorno PCI DSS conforme en la retaguardia.
Cómo lo ejecuta Berghem
Berghem apoya a proveedores de SoftPOS e instituciones de pago en todas las fases que anteceden y sustentan la validación MPoC: modelado de amenazas de la aplicación y del SDK, análisis de resistencia a ataques (ingeniería inversa, adulteración, hooking y root/jailbreak detection), revisión del cifrado de datos de cuenta y PIN, y evaluación de la lógica de atestación y monitoreo. El objetivo es llegar a la evaluación de laboratorio con las evidencias listas y las brechas ya corregidas, acortando el ciclo.
Ese trabajo se conecta con el resto del programa de seguridad de pagos: pentest mobile de la aplicación, pentest de API de las integraciones con el backend y seguridad en pagos de la cadena en su conjunto. Para quien también necesita organizar el entorno de retaguardia, la adecuación al PCI DSS corre en paralelo. Conozca el enfoque completo en preparación para PCI MPoC y SoftPOS.
Preguntas frecuentes
¿MPoC sustituye al PCI DSS?
No. MPoC trata de la solución que acepta el pago en el dispositivo de consumo; el PCI DSS trata del entorno que procesa, almacena o transmite los datos de tarjeta en el backend. Son estándares complementarios. Una operación de SoftPOS madura mantiene la solución MPoC validada en el borde y el entorno de retaguardia conforme al PCI DSS.
¿Necesito MPoC si solo uso pago por aproximación, sin PIN?
Depende del producto, pero MPoC es el camino actual. Fue creado para unificar los escenarios que antes cubrían SPoC (PIN) y CPoC (aproximación) en un único estándar modular. MPoC es el estándar más reciente y abarcador; SPoC y CPoC siguen publicados, pero las nuevas soluciones que combinan aproximación y PIN tienden a evaluarse bajo MPoC, activando solo los módulos aplicables.
¿Quién emite la validación PCI MPoC?
La validación la realiza un laboratorio reconocido por el PCI SSC, no una autoevaluación. El evaluador prueba la solución o el componente contra los objetivos de seguridad del estándar y, una vez aprobado, el producto pasa a constar en la lista pública de productos validados del PCI SSC, con atestación y monitoreo continuos en operación.