Última actualización: 13 de octubre de 2026.

Para manejar la revocación de consentimiento de usuario PSD2, registra la solicitud, identifica el permiso afectado y bloquea las nuevas consultas asociadas. Después, comprueba que el cambio se propaga a los sistemas y tareas programadas, y documenta por separado qué tratamiento darás a los datos ya obtenidos.

Si trabajas en producto, riesgos o ingeniería, detener el acceso futuro no resuelve por sí solo qué hacer con la información almacenada. El flujo debe diferenciar ambas decisiones y dejar una trazabilidad que permita reconstruir quién recibió la revocación, cuándo y qué acciones ejecutó.

Esta guía describe una secuencia técnica y operativa para coordinar la interfaz, las solicitudes de acceso bancario y los sistemas que reciben datos. Una API de agregación, como la de Wealthreader, puede formar parte de esa arquitectura; el proceso debe coordinarse con los sistemas de tu empresa y con las responsabilidades definidas para cada participante.

¿Cómo manejar la revocación de consentimiento de usuario PSD2?

Trátala como un cambio de estado que debe llegar a todos los componentes capaces de consultar o procesar datos. Registra la señal, identifica el permiso exacto, bloquea nuevas solicitudes y verifica el resultado en el backend, en las tareas asíncronas y en la interfaz.

Antes de implementar el flujo, decide qué identificadores vinculan la solicitud con el usuario, la conexión y el permiso. Define también cómo se gestionan las consultas que ya estaban en curso y quién debe revisar el tratamiento de los datos almacenados. Estas decisiones permiten convertir una acción de interfaz en un proceso verificable, sin confundir revocar el acceso con borrar información.

¿Qué significa gestionar la revocación de consentimiento PSD2?

Gestionar una revocación de consentimiento PSD2 significa actualizar el estado del permiso afectado y coordinar la respuesta entre la aplicación, los servicios internos y el acceso bancario. El objetivo operativo es impedir nuevas consultas asociadas a ese permiso, conservar un registro verificable de la decisión y evaluar por separado qué hacer con los datos ya recibidos.

A fecha de octubre de 2026, el artículo 67.2.a de la Directiva (UE) 2015/2366 establece que el proveedor de servicios de información sobre cuentas debe prestar el servicio con el consentimiento explícito del usuario del servicio de pago. La Directiva PSD2 publicada en el Diario Oficial de la Unión Europea el 23 de diciembre de 2015 establece el marco para ese acceso. La autorización de acceso bancario, el consentimiento asociado y el tratamiento posterior de los datos son aspectos relacionados, pero no equivalentes.

¿Qué elementos del flujo pueden revocarse?

Distingue el permiso de acceso bancario de los permisos internos de la aplicación, como habilitar una función o compartir información entre equipos. Revocar uno no implica que los demás hayan cambiado. Identifica qué autorización está afectada y qué procesos dependen de ella.

El estado de acceso puede depender del flujo bancario y del proveedor que participa en la conexión. Por eso, refleja por separado el estado que conoce la aplicación y el que informa la entidad o el proveedor. Para manejar la revocación de consentimiento de usuario PSD2, documenta también el papel de cada parte, las condiciones aplicables y las señales que recibe tu sistema.

¿Revocar el acceso obliga a borrar los datos ya obtenidos?

No hay una respuesta universal para todos los tratamientos. Detener nuevas consultas y decidir si se conservan, eliminan o restringen los datos ya obtenidos son decisiones distintas. La segunda depende de la base jurídica aplicable, la finalidad, la política de conservación de la empresa y el contexto contractual. Requiere revisión legal; la revocación del acceso no resuelve por sí sola esas cuestiones.

Registra qué conjuntos de datos existen, de qué conexión proceden y qué decisión se ha tomado sobre su tratamiento posterior. Así, el equipo puede aplicar la política correspondiente sin reactivar consultas ni confundir conservación con permiso de acceso.

Regla operativa: al revocar un permiso, detén las nuevas consultas asociadas y registra la solicitud, el estado del acceso y la decisión independiente sobre los datos ya obtenidos.

¿Qué pasos debe seguir tu equipo cuando recibe una revocación?

Cuando tu sistema recibe una revocación, debe vincularla al permiso correcto, actualizar su estado y comunicar el cambio a los componentes que podrían iniciar consultas. Un flujo definido evita que la interfaz indique una cosa mientras los procesos internos siguen usando un acceso que el usuario ha retirado.

1. Recibe la señal. Identifica si procede de la aplicación, del banco o de otro componente del flujo. Conserva el origen y el contexto recibido.
2. Identifica el permiso afectado. Relaciona la solicitud con el usuario y la conexión correspondiente. Evita actuar sobre otros permisos del mismo usuario.
3. Registra la solicitud. Guarda la fecha y hora, el identificador del usuario, el alcance afectado, el origen y el resultado. Añade qué componente procesó el cambio.
4. Propaga el nuevo estado. Informa a los servicios internos que generan o consumen consultas y bloquea nuevas solicitudes vinculadas al permiso revocado.
5. Comprueba el resultado. Verifica que la aplicación y los componentes de acceso reflejen estados coherentes. No des por hecho que el estado de conexión y el acceso a datos cambian a la vez.

¿Cómo debe reflejarse la revocación en producto y sistemas?

Usa estados internos inequívocos, como «activo», «revocación en curso» y «revocado», siempre que encajen con tu arquitectura. Define qué acción corresponde a cada estado y qué componentes deben consultarlo antes de solicitar datos. Explica al usuario qué acceso se ha detenido y si queda alguna gestión pendiente; no afirmes que se han eliminado datos cuando esa decisión aún no se ha tomado.

Asegúrate de que producto, ingeniería y operaciones usen los estados con el mismo significado. Una etiqueta visible no basta si los procesos de backend aplican otra lógica. Documenta también quién puede cambiar el estado y cómo se registra cada transición.

¿Qué controles debe revisar desarrollo?

Comprueba que los trabajos en cola y las tareas programadas verifiquen el estado vigente antes de consultar datos. Simula reintentos, fallos de sincronización y señales duplicadas: una repetición no debería reactivar el permiso ni generar acciones contradictorias. Registra el resultado de cada paso para poder reconstruir qué componente actuó y cuándo.

Un registro útil permite reconstruir quién recibió la revocación, qué permiso afectó, qué sistemas actuaron y cuándo se completó cada cambio.

Si tu arquitectura incorpora agregación bancaria, conoce la API de acceso a bancos de Wealthreader y evalúa cómo coordinar el acceso a datos con los sistemas de tu empresa.

¿Qué errores prácticos complican la revocación del consentimiento PSD2?

Un fallo habitual es cambiar la interfaz sin detener los procesos asíncronos que siguen solicitando datos. Compara el estado que ve el usuario con el del backend y el acceso bancario, y mide cómo se propaga la revocación en tu propia arquitectura. No supongas que existe un plazo estándar válido para todos los flujos.

¿Qué ocurre si la revocación llega mientras hay una consulta en curso?

Define qué debe hacer cada componente según el punto del flujo. Una consulta que aún no se ha enviado debe bloquearse; una solicitud ya enviada debe registrarse como tal y gestionarse según la respuesta disponible. No presupongas que la revocación cancela retroactivamente una petición en curso. Prueba ambos casos de extremo a extremo y deja claro qué estado verá el equipo y qué se comunicará al usuario.

¿Cómo evitar confundir revocación con borrado de información?

Mantén decisiones diferenciadas para detener futuras consultas, conservar datos y eliminarlos. La revocación del acceso no determina por sí sola qué hacer con la información almacenada. Las excepciones y los plazos de conservación dependen del contexto jurídico y de la política aplicable; contrástalos con fuentes oficiales y asesoramiento legal antes de automatizar el borrado.

Para localizar incoherencias, compara los eventos de revocación con el estado guardado por el backend y el registro de solicitudes salientes. Por ejemplo, la interfaz puede mostrar «revocado» mientras una tarea programada conserva una consulta pendiente. Revisa también los eventos duplicados y los fallos de sincronización. Registra cuánto tarda cada transición en tu sistema y documenta los resultados observados, sin presentar esa medición como un plazo universal.

Incluye pruebas periódicas desde la señal inicial hasta el bloqueo de nuevas consultas. Revisa una muestra del registro de eventos para confirmar que permite reconstruir la secuencia y detectar estados atascados. Así, la pregunta de cómo manejar la revocación de consentimiento de usuario PSD2 se traduce en controles verificables, no solo en un cambio visual.

Si estás evaluando el acceso a datos bancarios dentro de esa arquitectura, solicita una demo de la API de Wealthreader para valorar cómo integrarla con los sistemas que reciben y procesan datos.

¿Cómo encaja una API bancaria en un flujo de revocación controlado?

Una API bancaria forma parte de la infraestructura de acceso a datos, mientras que tu empresa debe coordinar los controles de revocación que corresponden a sus sistemas. Al diseñar cómo manejar la revocación de consentimiento de usuario PSD2, asigna cada acción según el papel de tu organización, las condiciones aplicables y la arquitectura implementada.

Parte	Responsabilidad que debe definirse
Tu empresa	Actualizar los estados internos, detener las consultas que controla y comunicar al usuario qué acceso se ha revocado.
Proveedor de acceso	Definir en la documentación y las condiciones del servicio qué información de estado ofrece, cómo se gestionan los errores y qué acciones corresponden a su servicio.
Banco	Determinar cómo se gestiona el acceso en sus canales y qué señales proporciona dentro del flujo bancario aplicable.

La tabla es un punto de partida, no una atribución legal universal. El reparto efectivo depende del servicio contratado, del flujo implementado y de las condiciones de cada entidad.

¿Qué debe quedar definido al integrar un proveedor de agregación?

Antes de integrar, define los límites de responsabilidad, los eventos disponibles y el tratamiento de errores a partir de la documentación y las condiciones del servicio. Comprueba cómo trasladar esos estados a tus sistemas y cómo registrar una incidencia si falla la sincronización. Para situar la integración en su contexto, consulta la guía sobre Open Banking en España, que explica el intercambio de datos entre entidades mediante API.

Wealthreader ofrece acceso a datos financieros mediante una API con cobertura directa de más de 250 bancos y gestoras en 61 países. Al integrar ese acceso, define cómo se coordina con los sistemas de tu empresa y cómo se registran los cambios de estado, las consultas y los errores del flujo.

¿Cómo presentar el proceso al usuario sin generar confusión?

Indica qué acceso deja de estar disponible, qué cambios se aplican y cuál es el resultado registrado. No equipares la interrupción de nuevas consultas con la eliminación de información obtenida anteriormente; comunica esas decisiones por separado y con términos comprensibles.

Si estás evaluando cómo integrar el acceso bancario y coordinarlo con tu arquitectura, solicita una demo para valorar tu integración.

Convierte la revocación en un control operativo

Revisa el flujo con los equipos de producto, ingeniería y cumplimiento. Comprueba que cada permiso tenga un estado claro, que las consultas respeten ese estado y que la decisión sobre los datos conservados siga un proceso separado. Así, cómo manejar la revocación de consentimiento de usuario PSD2 deja de ser una cuestión teórica y se convierte en un control que puedes probar y mantener.

Si estás diseñando esa arquitectura, evalúa cómo encaja el acceso a datos bancarios en tus sistemas y qué responsabilidades corresponden a cada componente. Una revisión técnica conjunta ayuda a identificar dependencias antes de llevar el flujo a producción.

Solicita una demo para analizar cómo integrar el acceso bancario en tu arquitectura y valorar los siguientes pasos con tu equipo. Un flujo bien definido facilita una gestión más trazable y comprensible.

Preguntas frecuentes

¿Qué garantías de seguridad y cumplimiento ofrece Wealthreader?

Wealthreader cuenta con ISO 27001 certification by AENOR, external audits and authorization from the Bank of Spain. Su infraestructura está alojada en la Unión Europea y utiliza cifrado de extremo a extremo. Estas medidas describen aspectos de seguridad y supervisión; revisa por separado cómo funciona el proceso de revocación integrado en tus sistemas.

¿Con qué frecuencia se puede actualizar la información?

Cada producto puede actualizarse más de 120 veces al mes sin coste adicional. La información intradía está disponible cuando la entidad de origen la publica. La frecuencia de actualización no cambia el estado de un permiso: las consultas deben respetar el estado de acceso registrado.

¿Qué es un producto?

Un producto es cada cuenta, tarjeta, préstamo, depósito o posición de inversión consultada durante el mes. Una sola conexión bancaria puede incluir varios productos. Al evaluar el alcance de una revocación, identifica los productos y accesos vinculados al permiso afectado, en lugar de tratar cada conexión como un único producto.

¿Puedo cambiar de plan en cualquier momento?

Sí. Puedes cambiar de plan en cualquier momento; la modificación se aplica en el siguiente ciclo de facturación y no tiene penalizaciones. El plan contratado y el procedimiento técnico para detener consultas son aspectos distintos, por lo que conviene documentarlos por separado.

¿Puedo probar Wealthreader antes de contratar?

Wealthreader no ofrece una demostración limitada. El plan Launch proporciona acceso real a la API desde el primer día y no tiene permanencia. Puedes usar ese acceso para evaluar cómo encaja la conexión con los sistemas de tu empresa y probar tus propios controles de permisos.