Actor

TPP

Third Party Provider (proveedor tercero)

Término paraguas para todo proveedor tercero autorizado que se conecta a las API de los bancos. Tres papeles posibles: leer (AISP), pagar (PISP), verificar fondos (CBPII).

Definición

Un TPP (Third Party Provider) es un proveedor tercero autorizado que se conecta, vía API, a las cuentas bancarias de un PSU con su consentimiento.

Es un término paraguas: detrás de «TPP» se esconden en realidad tres papeles distintos definidos por la PSD2.

Los tres papeles

Un mismo actor puede acumular las autorizaciones, pero cada papel está separado a nivel regulatorio:

  • AISP (Account Information Service Provider) — lee las cuentas (saldos, transacciones): agregadores, herramientas de contabilidad.
  • PISP (Payment Initiation Service Provider) — desencadena una transferencia desde la cuenta: pago instantáneo en el checkout.
  • CBPII (Card Based Payment Instrument Issuer) — verifica la disponibilidad de fondos antes de un pago con tarjeta vinculada a una cuenta de un tercero.

Lo que un TPP puede hacer

  • Conectarse a cualquier banco europeo cubierto por la PSD2.
  • Operar en todo el EEE mediante el pasaporte europeo, una vez autorizado.
  • Acumular varios papeles (a menudo AISP + PISP) para un servicio completo.

Lo que un TPP no puede hacer

  • Operar sin autorización de una autoridad competente (ACPR, BaFin, FCA).
  • Acceder a una cuenta sin el consentimiento explícito del PSU.
  • Salirse del alcance de su autorización (un AISP por sí solo no puede iniciar un pago).
  • Prescindir de los certificados eIDAS (QWAC para el transporte, QSealC para la firma).

En el ecosistema PSD2

El TPP es el intermediario entre el PSU y su ASPSP: no posee ni las cuentas ni el dinero, sino que aporta un servicio por encima.

Ejemplos concretos

  • TPP de «infraestructura»: Bridge, Tink (Visa), TrueLayer, Yapily y GoCardless ofrecen API multibancarias consumidas por otras apps, casi siempre actuando como AISP y PISP a la vez.
  • TPP de «producto»: Bankin', Linxo, Lydia y Revolut exponen un producto terminado al PSU.
  • TPP «vertical»: Pennylane e Indy (contabilidad), Algoan (scoring), Trustly y Fintecture (pago por transferencia) — cada uno elige la autorización útil para su negocio.
  • Combinación AISP + PISP: la más frecuente, para ofrecer «ver mis cuentas» y «pagar desde mis cuentas» en una sola experiencia.

Ver también: Manual STET

Fuentes

Profundizar

En el blog

Lecturas más completas para ir más allá de la definición.

24 de agosto de 2026
seguridad

QWAC vs QSealC: quién hace qué, y por qué se equivoca de capa — Leer el artículo

El QWAC lo lee la capa TLS, una vez, en el handshake. El QSealC lo lee la capa aplicativa, en cada petición. Dónde vive cada clave privada, qué exige STET y cómo leer un «error de certificado».

7 de abril de 2026
técnico

Arquitectura técnica de una API DSP2: lo que hay que saber antes de escribir la primera línea de código — Leer el artículo

Panorama técnico de la DSP2 para CTO, desarrolladores y PM técnicos: estándares de API, seguridad (mTLS, certificados eIDAS), OAuth2, flujos SCA, gestión del consentimiento, trampas de implementación.

6 de abril de 2026
regulación

Entender la PSD2: lo que cambia para sus clientes y su negocio — Leer el artículo

Todo lo que un directivo, un product manager o un equipo de negocio debe entender de la PSD2 (DSP2). Actores, consentimiento, oportunidades, sin jerga técnica.