La respuesta corta

La primera pregunta no es técnica: es de licencia. Para acceder a las cuentas bancarias de tus usuarios como tercero hace falta estar autorizado o registrado como proveedor de servicios de información sobre cuentas —AISP— ante la autoridad competente nacional. Sin eso, no hay conversación técnica que valga.

De ahí salen las tres opciones reales, y la decisión de construir o comprar se toma dentro de una de ellas, no antes:

  1. Ser AISP tú. Control total, y un proceso regulatorio con sus tiempos, su capital y su función de cumplimiento.
  2. Usar un agregador ya licenciado. Es lo que hace la mayoría: el proveedor pone la licencia y la conectividad, tú pones el producto.
  3. Operar bajo la licencia de un tercero como agente, cuando la figura encaja en tu caso.

Y en las tres, algo no cambia: el usuario tiene que dar su consentimiento explícito, y los bancos están obligados a dar acceso a través de sus interfaces dedicadas cuando ese consentimiento existe.

Lo que de verdad cuesta construirlo

Si te planteas la conexión directa a los bancos, esto es lo que estás comprando con tu presupuesto de ingeniería:

Heterogeneidad. La obligación de exponer interfaces es común, pero cada banco tiene su versión: su forma de gestionar el consentimiento, sus tiempos de respuesta, sus campos y sus rarezas. La capa de integración se convierte en el componente más complejo del producto, y no es un esfuerzo que termina: cada banco evoluciona su interfaz por su cuenta.

Consentimiento y su renovación. Este es el coste que casi nadie modela y el que más duele en el segundo año. El consentimiento no es eterno: caduca, y hay que hacer que el usuario lo renueve. Eso significa un ciclo de vida completo —recordatorios, reautenticación, estado degradado mientras tanto— y una caída de datos cada vez que alguien no renueva. Si tu producto depende de tener el saldo actualizado, esa caída es una incidencia de negocio recurrente.

Disponibilidad ajena. Cuando el banco cae, tu app parece rota. Necesitas estado por entidad, mensajes honestos y una forma de distinguir «no hay datos» de «no hemos podido consultar».

Soporte. Cada entidad nueva es un ciclo de pruebas, y cada fallo llega a tu servicio de atención al cliente aunque la causa esté al otro lado.

Lo que compras con un agregador

  • Cobertura ya construida y mantenida.
  • Normalización: un solo modelo de datos en vez de veinte.
  • Mantenimiento continuo cuando las entidades cambian.
  • La licencia, si operas bajo la suya.

Y lo que pagas por ello:

  • Coste por usuario conectado o por consulta, que escala con el éxito. Un producto que crece mucho puede acabar con una factura que no cabía en el modelo inicial.
  • Dependencia: si el proveedor sube precios, cambia condiciones o desaparece, tu producto principal está encima de él.
  • Calidad de datos que no controlas: la categorización automática de movimientos, por ejemplo, suele ser mejorable, y a veces es exactamente lo que tu producto necesita afinar.
  • Latencia y frescura que dependen de sus decisiones, no de las tuyas.

El criterio de decisión

Construir la conexión directa tiene sentido cuando se cumplen varias de estas:

  • La agregación es el producto, no un accesorio.
  • Operas en pocos mercados y con un número acotado de entidades relevantes.
  • Ya tienes —o vas a tener igualmente— función de cumplimiento y licencia.
  • El volumen hace que el coste por usuario del agregador supere claramente al de mantener la integración.

Usar un agregador tiene sentido cuando:

  • La agregación habilita tu producto pero no es tu diferencial.
  • Necesitas cobertura amplia desde el primer día.
  • Quieres validar el negocio antes de asumir un proceso regulatorio.
  • Tu equipo es pequeño y no puede dedicar gente a mantener conectores.

Y hay una vía intermedia que funciona mejor de lo que parece: empezar con agregador y diseñar tu capa de datos como si no lo tuvieras. Es decir, no dejar que el modelo de datos del proveedor se filtre a todo tu producto. Si mañana cambias, cambias un adaptador y no la aplicación entera.

Lo que hay que diseñar sí o sí, elijas lo que elijas

  • Consentimiento como estado de primera clase: activo, por caducar, caducado, revocado. Con su comportamiento de producto en cada uno.
  • Estado por entidad, visible para el usuario.
  • Reconciliación: qué haces cuando el banco devuelve movimientos que ya tenías, con importes o fechas distintas.
  • Modo degradado: la app tiene que ser útil cuando la conexión bancaria no está.
  • Borrado: cuando el usuario revoca, qué se borra y en cuánto tiempo.

Ese último punto es a la vez requisito de protección de datos y decisión de producto, y conviene tenerlo escrito antes de la primera línea de código.

Antes de estimar

  1. ¿Bajo qué licencia vais a operar, y quién la tiene?
  2. ¿Qué mercados y qué entidades, en orden de importancia?
  3. ¿Cuánta frescura necesita el producto: tiempo real, diaria, semanal?
  4. ¿Quién es dueño de la categorización de movimientos, vosotros o el proveedor?
  5. ¿Qué pasa con el usuario cuando caduca el consentimiento?

La quinta define media docena de pantallas y un ciclo de notificaciones. Es la que más se olvida y la que más se nota en la retención.

Es una de las decisiones que ordenamos al principio de un proyecto de apps fintech, junto con la autenticación reforzada — que tiene su propia conversación en SCA y biometría en una app bancaria.

Marco normativo: Directiva (UE) 2015/2366 (PSD2) y su Reglamento Delegado (UE) 2018/389 sobre autenticación reforzada y comunicación segura. Consultado el 14 de agosto de 2026.