Los IBAN no son contraseñas, pero siguen siendo datos de pago sensibles. Un IBAN real puede identificar una cuenta bancaria, vincularla con una persona o empresa y aparecer en pagos, facturas, mandatos de adeudo directo, tickets de soporte, exportaciones y registros de auditoría.
Almacenar IBAN de forma segura es un problema de diseño de ingeniería. El objetivo es recopilar el valor solo cuando el producto lo necesita, normalizarlo una vez, validarlo en el servidor, guardar la representación mínima útil y mantener el valor original fuera de los registros, las analíticas y los entornos inferiores.
Trata los IBAN como datos financieros sensibles
En la mayoría de los productos de pago, un IBAN debe tratarse como dato financiero personal cuando pertenece a un particular y como dato bancario empresarial confidencial cuando pertenece a una empresa.
Por sí solo, un IBAN normalmente no autoriza un pago. No demuestra la titularidad de la cuenta ni sustituye un mandato, un flujo de verificación, una comprobación del proveedor de pagos o una revisión antifraude. Aun así, puede revelar relaciones bancarias y crear un riesgo operativo si se filtra.
Una regla interna práctica es:
- Mostrar el IBAN completo solo cuando el usuario lo introduce, confirma o corrige.
- Mostrar un IBAN enmascarado en cualquier otro lugar.
- Guardar el IBAN completo solo si se necesita para ejecutar pagos en el futuro.
- No usar nunca IBAN reales en desarrollo, demos, capturas de pantalla ni eventos de analítica.
Empieza por minimizar los datos
Antes de diseñar el almacenamiento, decide si necesitas guardar el IBAN.
Puede que no necesites conservarlo si solo se usa para una validación puntual, un presupuesto o un paso temporal de configuración. En ese caso, valida la entrada, pásala al proveedor de pagos si hace falta y descártala cuando termine el flujo.
Probablemente sí necesitas almacenarlo si el producto admite pagos periódicos, cobros por adeudo directo, cuentas de vendedores de un marketplace, nóminas, pagos a proveedores, facturación de suscripciones o flujos de soporte que deben identificar una cuenta guardada.
Cuando sea necesario conservarlo, separa los campos por finalidad:
| Campo | Finalidad |
|---|---|
iban_ciphertext |
IBAN completo cifrado para ejecutar pagos |
iban_country |
Enrutamiento, filtrado y comprobaciones de cumplimiento |
iban_last4 |
Visualización segura y búsquedas del soporte |
iban_fingerprint |
Detección de duplicados sin exponer el IBAN |
verification_status |
Estado de las comprobaciones de titularidad o del proveedor |
created_at y updated_at |
Controles de auditoría y conservación |
Evita guardar como valor principal cadenas formateadas para mostrar. Guarda una versión canónica y dale formato solo al renderizarla.
Normaliza antes de guardar
Los IBAN suelen introducirse con espacios, letras minúsculas o agrupaciones incoherentes copiadas de aplicaciones bancarias. El sistema debe normalizar el valor antes de validarlo y almacenarlo.
Un flujo práctico de normalización es:
- Recortar los espacios al principio y al final.
- Eliminar los espacios internos.
- Convertir las letras a mayúsculas.
- Rechazar caracteres no compatibles.
- Validar el código de país, la longitud y la suma de comprobación.
- Guardar el valor canónico solo después de validarlo en el servidor.
Por ejemplo, de89 3704 0044 0532 0130 00 debe convertirse en DE89370400440532013000.
Mantén separado el formato de presentación. La interfaz puede mostrar grupos legibles, pero los proveedores posteriores suelen esperar el formato canónico compacto.
Cifra el IBAN completo
Si guardas IBAN completos, usa cifrado a nivel de campo en lugar de depender solo del cifrado del disco de la base de datos. El cifrado del disco ayuda en algunos escenarios de infraestructura, pero no protege frente a muchas rutas de acceso de la aplicación, copias de seguridad, analíticas o bases de datos.
Un diseño más seguro cifra el IBAN antes de escribirlo en la base de datos y lo descifra solo dentro del flujo de ejecución del pago o de un procedimiento operativo estrictamente controlado.
Puntos clave de implementación:
- Usa un servicio de gestión de claves cuando esté disponible.
- Rota las claves mediante un proceso de migración planificado.
- Limita los permisos de descifrado a los servicios que realmente los necesitan.
- Mantén el descifrado fuera de los paneles de administración generales.
- Registra cada consulta o exportación privilegiada de datos bancarios completos.
Si ingenieros, analistas y soporte pueden consultar IBAN completos sin control, el cifrado no es suficiente.
Usa huellas digitales para las búsquedas
Muchos sistemas deben detectar si ya se ha añadido el mismo IBAN. No lo soluciones guardando un hash simple del IBAN.
Los IBAN siguen formatos nacionales conocidos y parte de su valor tiene estructura. Un HMAC con clave es más adecuado para detectar duplicados, porque evita búsquedas precomputadas sencillas si se expone la base de datos.
Guarda una huella como:
HMAC-SHA256(secret_key, canonical_iban)
Usa la huella para comprobar igualdad, evitar duplicados y hacer correspondencias internas. Mantén la clave HMAC separada de la base de datos y rótala con cuidado, porque cambiarla cambiará todas las huellas.
Enmascara los IBAN de forma coherente
El enmascarado debe ser una utilidad compartida, no una lógica de cadenas aislada y repetida por el código.
Un patrón de visualización habitual muestra el código de país y los cuatro últimos caracteres:
DE89 **** **** **** **3000
Otro patrón más restrictivo es:
DE****************3000
Elige un patrón y úsalo en todas partes: paneles de clientes, facturas, vistas de administración, registros, plantillas de correo, exportaciones y herramientas de soporte.
No reveles dígitos intermedios adicionales porque parezcan inofensivos. Las revelaciones parciales se acumulan cuando la misma cuenta aparece en varios sistemas.
Mantén los IBAN fuera de registros y analíticas
Las filtraciones en registros son una de las formas más comunes de que los datos de pago salgan de su límite previsto. Los IBAN pueden aparecer en cuerpos de peticiones, errores de validación, cargas del proveedor, trazas de webhooks, argumentos de trabajos en segundo plano, índices de búsqueda y propiedades de analítica.
Integra la redacción en la capa de plataforma:
- Redacta los campos llamados
iban,account_number,bank_accounty sus equivalentes específicos del proveedor. - Redacta antes de que los registros salgan del proceso de la aplicación.
- Redacta con el mismo cuidado los datos de validaciones fallidas y correctas.
- Desactiva el registro completo de peticiones en las rutas de pago.
- Revisa si las herramientas de monitorización de errores capturan variables locales y breadcrumbs.
Una prueba útil es enviar un IBAN falso conocido a staging y buscar el valor completo en registros, trazas, eventos de analítica y herramientas de soporte. El IBAN completo no debería aparecer fuera del almacenamiento cifrado y de la petición necesaria al proveedor.
Separa la validación de la titularidad
Un IBAN válido no equivale a una cuenta bancaria perteneciente al usuario.
La validación del IBAN confirma que el formato y la suma de comprobación son plausibles. No confirma que la cuenta exista, acepte el tipo de pago, pertenezca al usuario o sea segura para recibir pagos.
Según el nivel de riesgo del producto, la titularidad puede requerir uno o varios controles:
- Verificación de cuenta del proveedor de pagos.
- Verificación mediante open banking.
- Confirmación mediante microdepósitos.
- Confirmación del mandato de adeudo directo.
- Coincidencia del nombre cuando esté disponible.
- Revisión financiera manual para pagos de importe elevado.
Guarda esto como un estado separado. No uses iban_valid para significar a la vez cuenta verificada, apta para pagos y aprobada.
Diseña flujos seguros para soporte
Los equipos de soporte suelen necesitar identificar una cuenta bancaria sin ver el IBAN completo. Dales herramientas que funcionen con datos enmascarados.
Un buen flujo permite buscar por cliente, referencia de pago, país, últimos cuatro caracteres y estado de verificación. Mostrar el IBAN completo debe ser excepcional, estar sujeto a permisos, limitarse en el tiempo y quedar auditado.
Un flujo práctico de revelación incluye:
- Un motivo de acceso identificado.
- Permiso para casos sensibles.
- Enmascarado automático tras un tiempo breve.
- Registros de quién vio el valor y cuándo.
- Alertas por accesos masivos o patrones de consulta inusuales.
Así el soporte sigue siendo eficaz sin convertir cada pantalla administrativa en un riesgo de exposición.
Usa IBAN generados en desarrollo y QA
Los entornos de desarrollo y staging no deben contener IBAN de clientes reales. Las copias de bases de datos de producción son arriesgadas porque los datos de pago suelen propagarse a copias de seguridad, herramientas de búsqueda, equipos locales, capturas y sesiones de depuración.
Usa IBAN de prueba generados. Un IBAN de prueba con formato válido basta para la validación de formularios, pruebas de interfaz, tests unitarios, exportaciones CSV, simulaciones de webhooks y la mayoría de flujos sandbox de proveedores.
Random IBAN puede generar IBAN específicos por país que superan la validación de suma de comprobación estándar, por lo que resulta útil para:
- Probar formularios de pago.
- Cuentas de demostración.
- Scripts de QA.
- Datos iniciales.
- Capturas para documentación.
- Pruebas de regresión de enmascarado y redacción.
Haz que los datos de prueba sean evidentes. Usa nombres de cliente ficticios, cuentas de proveedores sandbox y metadatos no productivos para que nadie confunda un IBAN generado con una cuenta real.
Define reglas de conservación
Los equipos de pagos suelen conservar los datos bancarios más tiempo del necesario porque nadie se encarga de borrarlos. Define las reglas de conservación al construir la funcionalidad.
Considera eliminar o archivar el IBAN completo cuando:
- El usuario elimina la cuenta bancaria.
- Se cierra la cuenta de un vendedor, proveedor o empleado.
- Expira un mandato.
- La empresa ya no necesita realizar pagos.
- Ha pasado el periodo legal de conservación.
- El usuario solicita la supresión y no existe una obligación superior que lo impida.
La conservación es más sencilla cuando los campos de presentación, las huellas, los registros de auditoría y los valores sin procesar cifrados están separados. Puedes conservar un historial de pagos enmascarado y eliminar el IBAN completo necesario para futuras operaciones.
Lista de comprobación de ingeniería
Antes de publicar una función que recopile o almacene IBAN, confirma que:
- El producto tiene un motivo claro para guardar el IBAN completo.
- La entrada se normaliza antes de validarla.
- La validación se ejecuta en el servidor, no solo en el navegador.
- El IBAN canónico se cifra a nivel de campo.
- La presentación enmascarada usa una utilidad compartida.
- Registros, trazas, analíticas e informes de errores redactan los campos IBAN.
- La detección de duplicados usa una huella con clave.
- El acceso al IBAN completo tiene permisos y auditoría.
- Desarrollo y staging usan IBAN de prueba generados.
- Las reglas de conservación y borrado están documentadas.
Para conocer la validación, consulta Cómo validar un número IBAN. Para datos de QA seguros, consulta Datos IBAN sintéticos para QA fintech.
Un sistema IBAN bien diseñado no se limita a aceptar el formato correcto. También limita quién puede ver los datos bancarios, mantiene las cuentas reales fuera de los entornos no productivos y ofrece a operaciones la información necesaria sin exponer más de lo imprescindible.