La idea tras éste artículo surge por mi completo desconocimiento sobre el servicio de Bizum Pay. El buen funcionamiento del Bizum actual y su idea de constituirse como alternativa a Google Pay, han bastado para tratar de averiguar en qué consiste su propuesta, cómo queda frente a las actuales de Google y Apple y qué puede aportar en cuanto a experiencia y privacidad de usuario.
Escenario actual
Cuando realizamos un pago mediante Apple Pay, ni el comercio ni Apple saben el número de tarjeta. El terminal recibe un token de un solo uso generado en el propio teléfono móvil y ahí termina todo. Cuando pagamos con Bizum Pay, el dinero sale directamente de la cuenta bancaria y llega a la del comercio en cuestión de segundos; sin tokens ni una red de tarjetas de crédito intermedia. Son dos formas radicalmente distintas de hacer exactamente lo mismo, y con implicaciones también muy diferentes en cuanto a privacidad.
Bizum Pay está funcionando desde el 18 de mayo de 2026, cuando CaixaBank, BBVA, Sabadell y Bankinter activaron el servicio para sus clientes. El despliegue masivo llegará en otoño, cuando el resto de entidades (Santander, ING, Unicaja, Kutxabank y otras) completen la integración. Para entonces se espera una aplicación propia en Android e iOS, aunque la experiencia ya es funcional desde las aplicaciones bancarias que ya participan de las primeras pruebas.
Será el momento en que Bizum entre en competencia directa con Visa, Mastercard, Apple Pay y Google Pay. Y lo hará en un ecosistema donde todas éstas empresas llevan décadas dominando: el pago entre particulares y todo tipo de comercios. Además, con una arquitectura completamente diferente, con sus propias ventajas e inconvenientes en lo relativo a la privacidad.
Redsys como infraestructura central
En éstos momentos, Bizum es una plataforma construida sobre Redsys, el procesador de pagos que ya gestiona la mayoría de los TPV virtuales y físicos en España. Una tecnología muy contrastada y madura que se adaptará mediante Bizum Pay al datáfono de los comercios que se sumen a la iniciativa.
En el comercio electrónico, la integración de Bizum ya existe hace años a través del parámetro DS_MERCHANT_PAYMETHODS=z en el TPV Virtual de Redsys. El salto al pago presencial no requerirá de nuevo hardware, ya que los datáfonos actuales llevan años soportando NFC para tarjetas contactless y para Apple Pay o Google Pay. Tan sólo será necesaria una actualización software del terminal para que, cuando detecte una transacción Bizum, la procese como una transferencia SCT Inst (SEPA Credit Transfer Instant, la infraestructura europea de transferencias bancarias instantáneas) en lugar de como una transacción ISO 8583 de red de tarjetas.
El canal NFC es el mismo; lo que cambia completamente es el protocolo y los pasos posteriores.
- La firma de transacciones utiliza HMAC-SHA512 (versión 2 del protocolo Redsys).
- El comercio firma los parámetros de la operación.
- Redsys los valida en su infraestructura.
Como se ha citado anteriormente, es un modelo probado en producción desde hace muchos años.
Lo que sí cambia de forma fundamental respecto al pago con tarjeta es la liquidación. Con Visa o Mastercard, el dinero llega al comercio en 24-48 horas. Con Bizum Pay, la liquidación es instantánea vía SCT Inst (SEPA Credit Transfer Instant). Para un pequeño negocio con márgenes ajustados, la diferencia entre cobrar hoy o mañana no es algo baladí.
Qué visibilidad tiene Redsys de cada transacción:
- Tiene acceso al importe
- Al identificador del comercio
- Al timestamp (fecha y hora exacta de la operación)
- Al banco emisor.
No al IBAN del usuario (está en el directorio de Bizum S.L.), pero sí al identificador Bizum que mapea a ese IBAN. Es el nodo central de información de todo el sistema, con visibilidad de todas y cada una de las operaciones que pasan a través de él.
Bizum Pay frente a Apple Pay y Google Pay
Tres modelos distintos de gestionar el pago mediante NFC.
Apple Pay
Apple Pay tokeniza la tarjeta bancaria generando un Device Account Number (DAN) que queda almacenado en el Secure Element del dispositivo, un chip de hardware físicamente aislado que ni el propio iOS puede leer. Cuando efectuamos un pago, el terminal recibe un token de un solo uso vinculado a esa transacción concreta. El número de tarjeta real (PAN) nunca sale del dispositivo ni llega al comercio.
La autenticación biométrica (Face ID, Touch ID) se procesa localmente en el Secure Enclave, sin que los datos biométricos salgan del dispositivo. Apple, como empresa, no almacena el número de tarjeta real ni tiene acceso al historial de compras de sus usuarios. Es lo que se conoce como privacidad por diseño (arquitectura).
El punto débil en Apple Pay está en la jurisdicción: Apple Inc. es una empresa estadounidense. Aunque cumple el RGPD como entidad que opera en la UE, las transferencias de datos que se producen: gestión de cuenta, actualizaciones, resolución de problemas, etcétera; implican salidas fuera del espacio de la UE.
Google Pay
Google Pay también tokeniza la tarjeta, pero con una diferencia importante en el diseño: en lugar de almacenar el token en el hardware del dispositivo, usa Host Card Emulation (HCE), lo que significa que el Device Primary Account Number (DPAN) se gestiona desde servidores en la nube de Google.
Google actúa como intermediario en la generación y gestión del token.
La consecuencia práctica es que Google tiene acceso a metadatos de todas las transacciones. La empresa es explícita en su política de privacidad sobre el uso de esta información para mejorar sus servicios (detección de fraude mediante ML, entre otras finalidades), pero eso incluye también valor para el ecosistema publicitario de Google.
Desde una perspectiva de privacidad, Google Pay es muy inferior a Apple Pay por su propio diseño: la arquitectura HCE implica necesariamente que Google conozca el patrón de compras de los usuarios.
Bizum Pay
Bizum Pay no usa tokenización de tarjeta en ningún momento del proceso. El pago es una transferencia directa entre cuentas bancarias: el dinero sale de tu cuenta y llega a la del comercio mediante SCT Inst.
El número de teléfono actúa como identificador del usuario, vinculado a su IBAN en el directorio centralizado gestionado por Bizum S.L. En el pago presencial, la autenticación se delega a la aplicación del banco (biometría, PIN) o a la propia de Bizum Pay (cuando esté disponible), según el banco.
La visibilidad de los datos queda de la siguiente manera:
- El banco emisor del usuario tiene acceso a todos los datos: Importe, comercio, timestamp, IBAN de destino y patrones de uso.
- Redsys: al importe, comercio, identificador Bizum del usuario y al banco emisor.
- El banco receptor (del comercio): al importe e identificador Bizum del pagador.
- El comercio: a la confirmación de pago con importe. Sin datos bancarios del usuario.
- Bizum S.L.: opera el directorio teléfono <-> IBAN. En «teoría» a las estadísticas agregadas, no a las transacciones individuales.
El comercio nunca va a recibir datos sensibles del pagador; ventaja muy importante respecto a pagar con tarjetas en terminales; por contra, el banco del usuario tiene completa visibilidad de las transacciones que no ocurría en el modelo de tarjeta tradicional, donde el flujo de datos pasaba distribuido entre banco emisor, red de tarjetas y banco receptor.
← Desliza para ver las tres columnas →
El móvil toca el datáfono
La operación ha concluido
Qué es Bizum y qué datos gestiona
Antes de hablar de la privacidad que aporta el sistema, vamos a recapitular sobre la propiedad y gestión tras el servicio. Bizum S.L. (CIF B87599478, antes denominada Sociedad de Procedimientos de Pago S.L.) fue constituida el 27 de junio de 2016. Es propiedad de 24 entidades bancarias que operan en el mercado español. Con una plantilla de apenas 8 empleados registrados, su objeto social inscrito en el Registro Mercantil lo define como: «la creación y explotación de un directorio común en el que se vinculan números IBAN de cuentas de pago a un identificador». Ésto es Bizum en esencia: un directorio centralizado teléfono↔IBAN gestionado por una sociedad participada por los bancos.
La cadena de custodia de datos en cada transacción queda así:
| Actor | Datos que gestiona | Base legal (RGPD) |
|---|---|---|
| Bizum S.L. | Directorio teléfono↔IBAN, metadatos del servicio | Contrato de servicio (art. 6.1.b) |
| Banco emisor del usuario | Importe, comercio, timestamp, IBAN destino, patrón de uso | Contrato bancario |
| Banco receptor (del comercio) | Importe, identificador Bizum del pagador | Contrato bancario |
| Redsys | Parámetros de transacción, identificadores de comercio y banco | Procesador de pagos |
| AEAT (desde enero 2026) | Todos los cobros de autónomos y profesionales, sin umbral mínimo | RD 253/2025 (obligación legal) |
Un detalle en la política de privacidad de Bizum S.L.: para gestionar comunicaciones de newsletter, los datos pueden cederse a Mailchimp (The Rocket Science Group LLC), con sede en EE.UU. No afecta a los datos de las transacciones, pero ilustra que la promesa de «datos en Europa» tiene sus matices cuando se mira al detalle.
Seguridad y superficie de ataque
Bizum Pay presenta buenas credenciales en cuanto a seguridad:
- El doble factor es obligatorio en prácticamente todas las operaciones (PSD2/SCA).
- El comercio nunca recibe datos sensibles del pagador.
- Al no existir PAN de tarjeta, no hay exposición del número de la misma en el punto de venta (uno de los vectores de fraude más habituales en terminales físicos).
Sus riesgos más relevantes (superficie de ataque) serían los siguientes:
El directorio central es el activo de mayor riesgo. Bizum S.L. gestiona el mapeo de más de 31 millones de números de teléfono con sus respectivos IBANs; la gestión técnica de dicho directorio recae en Redsys. El problema es la propia arquitectura: concentrar ese volumen de datos en un único nodo lo convierte automáticamente en objetivo de enorme valor. Caso de quedar comprometido, tendría implicaciones de una escala muy diferente al robo de tokens individuales (que es, por diseño, lo que no existe en Bizum).
El SIM swapping. Si un atacante se hiciera con el control del número de teléfono, puede intentar asociarlo a un nuevo dispositivo Bizum. La dependencia del número de teléfono como identificador principal es estructuralmente más frágil que una credencial hardware como el Secure Element de Apple Pay. Los bancos tienen controles contra este vector, pero el diseño del sistema lo hace más vulnerable que las alternativas mediante tokenización en un chip dedicado..
La aplicación bancaria como vector de ataque. Si nuestra aplicación bancaria quedara comprometida (malware, keylogger, etcétera) el atacante puede manipular o capturar la transacción antes de que el usuario la confirme. Esto no es ningún riesgo exclusivo de Bizum, pero éste, tampoco ofrece contramedida alguna.
Disputas y reversiones. Bizum tiene una política clara sobre las disputas, pero el mecanismo de reversión es considerablemente menos automatizado que el chargeback (revertir el cargo) de una tarjeta. Una vez que el dinero ha viajado entre cuentas, recuperarlo ante un error o un fraude requiere intervención de los bancos implicados, no es un proceso estándar ni automatizado como en las redes de tarjetas.
Privacidad
Nuevo escenario regulatorio: Bizum y Hacienda
El Real Decreto 253/2025 (BOE del 2 de abril de 2025) modificó las obligaciones informativas de entidades financieras frente a la AEAT. Desde el 1 de enero de 2026, los bancos reportan mensualmente a la Agencia Tributaria todos los cobros recibidos vía Bizum por autónomos y profesionales (sin umbral mínimo de importe), identificando al receptor, número de comercio, importe mensual acumulado y cuentas asociadas. La información se reporta agregada mensualmente por profesional, no por transacción individual.
Esto no afecta a las transferencias entre particulares (C2C). Pero revela algo técnicamente importante: si esa información puede reportarse a Hacienda con ese nivel de detalle, es porque ya existe en los sistemas de los bancos.
Nos enfrentamos por tanto, ante una trazabilidad absoluta.
La paradoja de la soberanía de los datos
El argumento de que Bizum Pay es «más privado» porque los datos no van a Google ni a Apple, es cierto pero sólo parcialmente.
Si bien es correcto hablar de que los datos permanecen bajo jurisdicción española y bajo supervisión del Banco de España y la AEPD. También lo es el hecho de que lo están dentro de un modelo de centralización absoluta.
Con Apple Pay, ni siquiera la propia Apple sabe qué compras hace el usuario. Con una tarjeta convencional, la información de la transacción se distribuye entre banco emisor, red de tarjetas (Visa/Mastercard) y banco receptor. Con Bizum Pay, el banco del usuario tiene visibilidad completa de cada operación: qué compró, dónde, cuándo y por cuánto. En ese aspecto, se unifica toda una cadena de información que antes estaba más repartida.
A nivel de privacidad, la pregunta no es tanto «bajo qué jurisdicción quedan mis datos» como «qué nivel de concentración de mis hábitos de consumo quiero que tenga una entidad financiera». Entidad, que a futuro bien los podría utilizar para calificación crediticia, personalización de productos o como palancas para ventas cruzadas.
El antecedente de la AEPD: la multa de 80.000 euros
En septiembre de 2022, un atacante aprovechó que el sistema permitía verificar si un número de teléfono estaba registrado en Bizum, mostrando el nombre o iniciales del titular antes de completar la operación. Mediante un script automatizado ejecutado desde la web de una entidad bancaria asociada, extrajo datos de más de 20.000 usuarios en menos de dos horas. El límite de 30 peticiones canceladas antes del bloqueo fue evadido utilizando la plataforma web de un banco adherido.
Bizum no confirmó la escala del incidente hasta meses después, cuando los datos ya circulaban en la dark web. Tampoco notificó a los usuarios afectados, argumentando que el riesgo era «bajo» y usando una metodología de evaluación propuesta por la Agencia Europea de Seguridad de las Redes y la Información (ENISA).
La AEPD no aceptó ese criterio. En su resolución EXP202318538 (agosto de 2025), sancionó a Bizum con 100.000 euros (luego reducidos a 80.000 por pago voluntario) por tres infracciones del RGPD: medidas técnicas insuficientes para el riesgo real del tratamiento (artículo 32), detección tardía de la brecha, y no notificación a los usuarios afectados.
El razonamiento de la agencia fue claro: si los datos circulaban en la dark web, el riesgo para los afectados no podía calificarse de bajo.
La filtración no fue de datos financieros sino de datos de directorio: número de teléfono, iniciales y apellidos. Pero es que es precisamente eso, el principal activo del sistema. Además no se trató de una vulneración muy sofisticada:
«Bizum muestra el nombre e iniciales del destinatario antes de confirmar cualquier transferencia, como medida de verificación para el usuario. Un atacante automatizó consultas secuenciales de números de teléfono desde la web de una entidad adherida (sin llegar a completar ninguna transferencia) para construir un listado de titulares. El límite de 30 operaciones canceladas antes del bloqueo, que Bizum había presentado como medida de protección ante una denuncia previa de 2020 sobre exactamente este vector, fue evadido sin dificultad: en dos horas y antes de que la entidad bloqueara al atacante, ya habían salido los datos de 20.070 usuarios. La vulnerabilidad había sido reportada a la AEPD dos años antes. La agencia archivó aquella denuncia tras escuchar las medidas que Bizum decía tener implementadas.»
Buscando ser más que un sistema de pago nacional
Hay muchos sistemas similares a Bizum en otros países: MB Way (Portugal), Bancomat Pay (Italia), Wero (Francia, Alemania, Bélgica) y Vipps MobilePay (países nórdicos); todos ellos ya forman parte de la alianza EuroPA (European Payments Alliance). En febrero de 2026, todos ellos firmaron un memorando de entendimiento para construir una infraestructura de pagos transfronterizos paneuropea, con el objetivo de cubrir pagos P2P en 2026 y comercio electrónico y presencial en 2027.
La interoperabilidad entre Bizum, Bancomat y MB Way ya está activa desde marzo de 2025, y durante 2025 se transfirieron 6 millones de euros de forma transfronteriza sin prácticamente ninguna campaña de promoción. La iniciativa final aspira a cubrir 13 países europeos (aproximadamente el 72% de la población de la UE y Noruega) a través de un hub técnico central basado en estándares europeos.
La dimensión geopolítica es muy importante: se trata de construir una alternativa a la dependencia de infraestructura de pagos estadounidense (Visa, Mastercard, Apple Pay, Google Pay) en el punto de venta físico, igual que estos sistemas nacionales ya dominan los pagos P2P en sus mercados domésticos.
Las implicaciones de privacidad dentro de toda esa interoperabilidad son ciertamente compleja: el directorio que hoy mapea teléfonos con IBANs en España, tendrá que coordinarse con sistemas equivalentes en otros países. El nivel de alineamiento entre supervisores europeos sobre el tratamiento de esos datos en un contexto internacional, está todavía por definir…
Código abierto: la alternativa de GNU Taler
Tanto en Bizum, como en Apple Pay o Google Pay, todas las promesas de privacidad son declarativas. Hemos de confiar en las política publicadas y en el marco regulatorio; no hay ninguna.posibilidad técnica de verificación objetiva.
Y aquí es donde aparece GNU Taler (Taxable Anonymous Libre Electronic Reserve). Un ejemplo de que las cosas podrían hacerse de manera diferente. Se trata de un sistema de pago electrónico completamente libre (licencia GNU) desarrollado con financiación de la propia Comisión Europea a través del programa Horizon Europe.
Su arquitectura es conceptualmente distinta:
- Los tokens de pago residen exclusivamente en el dispositivo del usuario. No hay cuenta en la nube, ni directorio central de usuarios.
- El pagador es anónimo para el receptor y para el operador del sistema. El receptor (el comercio) es identificable y sus ingresos son auditables (de ahí la «T» de «taxable»). Privacidad para el comprador a la vez que transparencia para las haciendas.
- Es compatible con cualquier moneda, incluido el euro. Técnicamente podría ser la infraestructura del euro digital si el BCE lo adoptara.
GNU Taler publicó su versión 1.3 en Noviembre de 2025 y entró en producción en Suiza a través de Taler Operations AG. La diferencia con Bizum en términos de privacidad es fundamental:
- No existe un directorio central susceptible de vulnerar.
- No hay número de teléfono que nos identifique unívocamente y de forma constante.
- Cualquier «declaración de privacidad» puede ser fiscalizada de forma objetiva.
Sus limitaciones todavía son muy importantes:
- Adopción prácticamente nula fuera de Suiza.
- Carece de soporte NFC para pago presencial (en desarrollo).
- Y quizás la más importante de todos; incentivos para que las grandes entidades bancarias accedieran a su implementación. Algo que no ocurrirá sin presión regulatoria de por medio.
En el caso de España (extrapolable al resto); la banca tiene todos los incentivos para que Bizum funcione y ninguno para adoptar una alternativa que elimine su posición central en el acceso al flujo de datos.
Cómo queda el usuario final
Bizum Pay es un sistema técnicamente sólido, construido sobre una infraestructura probada, con autenticación alineada a PSD2 y con la ventaja de que el comercio no recibe datos bancarios del consumidor. Desde el punto de vista de seguridad, es mejor que pagar con tarjeta física en un terminal que podría llegar a estar comprometido.
También es un sistema que ofrece menor privacidad que Apple Pay por su propia arquitectura. Pero a su vez mayor privacidad que Google Pay en cuanto a datos que acabarán en afiliados y en subastas.
Personalmente y tras toda la información recopilada, he quedado bastante decepcionado, tanto por la seguridad (centralización masiva) como por la privacidad (todo el control a las entidades bancarias). Y si bien es cierto que éstas últimas ya disponen de la práctica totalidad de nuestra información sensible; no sé hasta que punto se puede considerar una mejora darles también nuestros hábitos e historial de compras.
Al final y aún con los matices ya expuestos, todo lleva a plantearnos la siguiente pregunta : ¿Quién prefiero que posea y gestione el perfil detallado de todos mis hábitos de compra?
Esperando por GNU Taler…
Referencias y recursos
- Registro Mercantil de Madrid — Bizum S.L. (CIF B87599478) — Objeto social y estructura societaria
- Resolución AEPD EXP202318538 (agosto 2025) — Sanción a Bizum por brecha de datos de 2022
- Real Decreto 253/2025 (BOE 2 de abril de 2025) — Nuevas obligaciones informativas a la AEAT sobre medios de pago electrónicos
- GNU Taler — Lanzamiento v1.0 (mayo 2025) — Documentación técnica y anuncio de operación en Suiza
- Nota de prensa EuroPA + EPI — MoU (febrero 2026) — Acuerdo de interoperabilidad paneuropea
- Política de privacidad de Bizum S.L. — Texto completo
- Redsys — Guía de integración TPV Virtual (SIS v1.3), parámetro
DS_MERCHANT_PAYMETHODS— Documentación técnica para desarrolladores - Especificaciones PSD2/SCA (Strong Customer Authentication) — European Banking Authority
+ GNU Taler
- GNU Taler — Web oficial — Proyecto, filosofía y estado del sistema
- GNU Taler — Documentación técnica — Manuales para exchange, wallet, merchant backend y API
- GNU Taler — Anuncio v1.0 (mayo 2025) — Entrada en operación en Suiza
- GNU Taler — Anuncio v1.3 (noviembre 2025) — Última versión publicada; integración con banco Magnet
- GNU Taler — Código fuente — Repositorio oficial
- NLnet — Financiación del proyecto — Contexto de financiación europea (NGI / Horizon)