Hace unos meses, cuando quise que Cuéntamo leyera los movimientos del banco en vez de obligarme a subir un Excel cada mes, hice lo que haría cualquiera: pedir precios.
La respuesta me dejó bastante claro por qué el mercado de las aplicaciones de finanzas personales es como es.
El peaje
600 € al mes de mínimo. Y eso era el barato.
Por ese precio no tienes barra libre: viene con un tope bajo de conexiones bancarias. Si quieres además movimientos de tarjetas, sube. Si quieres operaciones de inversión, sube otra vez.
Hagamos la cuenta despacio, porque es donde está lo interesante. Seiscientos euros al mes son 7.200 € al año de coste fijo. Fijo significa que llega el día 1 tengas los clientes que tengas.
Si tu aplicación cuesta 5 € al mes, necesitas unos 120 suscriptores de pago solo para cubrir esa factura. No para ganar dinero: para no perderlo. Ciento veinte personas pagando antes de descontar el IVA, la comisión de la pasarela de pago, el servidor, y por supuesto antes de pagarte a ti un solo euro por las horas.
Y ahora la parte que de verdad me hizo cerrar la pestaña.
La pinza
Ese coste fijo te exige volumen. Necesitas cientos de usuarios de pago para amortizarlo.
Pero el tramo barato tiene un tope bajo de conexiones. Así que cuando por fin consigues esos cientos de usuarios, ya no te caben en el plan y saltas al siguiente tramo, que cuesta más. Y vuelta a empezar.
No es que la agregación bancaria sea cara. Es que está diseñada para que no puedas empezar pequeño. No hay una rampa. Hay un escalón, y o lo subes de una zancada o te quedas fuera.
En mi caso concreto había además una guinda: Cuéntamo gestiona inversiones (operaciones de bróker, posiciones, renta fija). O sea que la parte cara del catálogo, el sobrecoste por movimientos de inversión, era justo la que necesitaba. La vía no es que fuera cara para mí: estaba cerrada.
Lo que esto le hace al mercado
Cuando cuentas esto, se entiende de golpe algo que como usuario resulta desconcertante.
En los últimos meses han aparecido un montón de aplicaciones de finanzas personales. Si las miras con atención, verás que se dividen en dos grupos muy limpios: las que conectan con tu banco y las que te hacen subir un Excel. Casi no hay término medio.
No es que las segundas sean vagas o peores. Es que la conexión bancaria, hoy, solo se la puede permitir quien llega con una inversión seria detrás, o quien pertenece a un grupo que ya paga esa infraestructura por otro motivo.
Y aquí quiero ser justo, porque es fácil contar esto como si hubiera un villano y no lo hay.
La PSD2 (la normativa europea que abrió los datos bancarios a terceros) hizo lo que prometía: rompió el monopolio de los bancos sobre tus movimientos. Y los agregadores que operan sobre esa vía hacen un trabajo real y nada trivial: licencias, seguridad, y mantener vivas decenas de integraciones que se rompen solas. Si puedes pagarlo y te resuelve lo que necesitas, probablemente sea la herramienta correcta. No estoy diciendo que sobren.
Lo que digo es otra cosa: ese coste de entrada no tiene rampa. El cumplimiento (licencias, auditorías, certificaciones, infraestructura) es tan caro que solo se sostiene repartiéndolo entre muchos clientes, y eso convierte la puerta abierta en una puerta con portero. Los datos son tuyos, la ley dice que puedes llevártelos, y aun así leerlos programáticamente empieza en 7.200 € al año.
Hay además un segundo detalle que tardé en ver, y que me parece más importante que el precio: la PSD2 solo cubre cuentas de pago. No llega a las tarjetas de tienda, ni a los extractos de inversión, ni a los planes de pensiones, ni a las facturas, ni a los tickets de la compra. Justo la cola larga de documentos que un usuario necesita para tener sus cuentas completas. Así que ni pagando el peaje tenía el problema resuelto entero: habría pagado 7.200 € al año por una parte.
Y para ser justos del todo: si eres un particular y solo quieres tus cuentas corrientes, hay incluso una vía gratuita. Servicios como Enable Banking permiten, al amparo de la PSD2, acceder a los movimientos de tus propias cuentas de pago sin coste. Está muy bien y conviene saberlo. Pero choca con el mismo muro: cuentas de pago y nada más. Ni tarjetas, ni inversiones —que era justo lo que yo necesitaba.
La vuelta que le di
En algún momento caí en la cuenta de algo que ahora me parece obvio: cuando entro en la web de mi banco, los datos ya están en mi navegador. Los estoy viendo. Son míos. Llegan a mi ordenador sin que ningún intermediario tenga que autorizarlo.
El intermediario no hace falta para obtener los datos. Hace falta para obtenerlos desde un servidor, sin que yo esté delante. Y esa es una necesidad del modelo de negocio, no del problema.
Así que construí Habeas: una extensión de navegador que lee tus propios datos desde tu propia sesión, en tu equipo, y los deja donde tú digas (una carpeta, tu Drive, o la aplicación que uses). Sin servidores en medio, sin guardar tus credenciales, sin que nadie más los vea. Ya conté con más detalle por qué la hice, así que no me repito.
Conviene decir qué es y qué no es. Habeas no es un agregador alternativo ni compite con la PSD2 en su terreno. Es un mecanismo distinto: portabilidad de datos personales (el artículo 20 del RGPD) ejecutada por el propio usuario, en su navegador. No inicia pagos, no agrega nada en un servidor y no está sujeto a esa regulación porque no hace lo que esa regulación regula. Para una entidad que necesite acceso continuo y desatendido a cuentas de pago, la vía regulada sigue siendo la correcta. Pero llega a la cola larga que la otra no cubre, y no te pide 600 € para empezar.
Lo que no conté en aquel artículo, y es el motivo de este, es que no tiene por qué ser solo para mí.
Si construyes una app de finanzas, esto también es tuyo
Habeas es software libre (AGPL-3.0) y está diseñado desde el principio para que cualquier aplicación pueda usarlo. No hay lista blanca ni acuerdos: cualquier web puede pedirle datos al Habeas de su usuario, y solo puede recibirlos en su propio dominio (esa regla está en el código, no en un contrato).
En la práctica significa que:
- Integrarlo es cosa de una tarde. Tu aplicación pide permiso, el usuario aprueba en una pantalla de Habeas, y a partir de ahí recibes los movimientos en un endpoint tuyo, ya normalizados. Lo tienes explicado, con los dos modelos de integración y el código para copiar, en habeas.dev/developers.
- Añadir un banco es escribir un fichero de definición, no mantener un scraper frágil. Son datos, no código ejecutable, y viven en un catálogo comunitario.
- Y es un argumento de venta para tus usuarios, no solo un ahorro para ti: sus credenciales no salen de su navegador y no hay un tercero acumulando el historial financiero de nadie.
Y sumar un servicio que aún no esté en el catálogo tampoco exige programar: con un sistema de grabación y detección de sesiones, el propio usuario puede generar la fuente a partir de cómo usa el servicio; o enviar su sesión anonimizada al equipo de Habeas para que preparemos el adaptador de un servicio todavía no soportado. El catálogo crece con el uso, no solo con quien escribe código.
Aquí viene la petición, y la hago sin rodeos: si mantienes una aplicación de finanzas personales y te topaste con el mismo muro de precios, hablemos. Cuantos más seamos, más bancos cubre el catálogo, y un adaptador que escribes tú nos sirve a todos los demás. Es de los pocos casos donde colaborar con la competencia sale a cuenta: los adaptadores son fontanería compartida, y donde de verdad competimos es en el producto.
Lo que no te voy a vender
No sería honesto terminar sin los límites, que los tiene:
- El usuario tiene que iniciar sesión él. Habeas no guarda contraseñas ni entra por su cuenta; si no hay sesión activa, abre la pestaña del banco y espera. Eso es una decisión de diseño, no una carencia, pero implica que no hay sincronización silenciosa a las tres de la mañana.
- Si el banco cambia su web, hay que actualizar el adaptador. La diferencia con un agregador es que aquí puedes arreglarlo tú mismo en vez de esperar a que le toque en su hoja de ruta.
- Cada servicio tiene sus condiciones de uso, y cumplirlas es responsabilidad de quien lo usa. Habeas opera sobre tus propios datos y en tu propia sesión, que es justo lo que el derecho de portabilidad del RGPD contempla, pero no es una barra libre.
Con todo, prefiero estas limitaciones a la alternativa, que era no poder ofrecer la funcionalidad en absoluto.
Si construyes algo y quieres integrarlo, empieza por habeas.dev/developers. El código está en github.com/habeas-dev/habeas, bajo AGPL-3.0. Y si te ha resonado el número del principio porque tú también lo has visto en un presupuesto, escríbeme.
Deja una respuesta