¿Necesitas una licencia bancaria para lanzar una app fintech?
«¿Necesitas una licencia bancaria para lanzar una app fintech?» son en realidad tres preguntas con un mismo abrigo. ¿Custodias dinero de clientes? ¿Lo mueves? ¿Y el permiso regulatorio de quién cubre ese movimiento: el tuyo o el de otro? Responde a eso y la cuestión de la licencia casi se resuelve sola. La versión corta, que sorprende a la mayoría de los equipos: la mayoría de las apps fintech nunca tienen licencia bancaria, porque la mayoría nunca hace lo único para lo que sirve una licencia bancaria. Lo que sigue es un mapa del espectro, no asesoramiento legal: el objetivo es saber qué preguntas hacer antes de que nadie te dé un plazo o un precio.
Para qué sirve realmente una licencia bancaria
Una licencia bancaria completa (en términos de la UE, la autorización como entidad de crédito) permite una actividad concreta y muy vigilada: captar depósitos del público y prestar ese dinero. Ese desfase de vencimientos, financiar préstamos largos con saldos que los clientes pueden retirar a la vista, es la razón por la que los bancos soportan exigentes requisitos de capital, obligaciones de garantía de depósitos y un supervisor que lee su balance línea a línea. Si tu app no capta depósitos ni presta con ellos, casi seguro que no estás ante una licencia bancaria. Estás ante algo más ligero, más abajo en el espectro, y el espectro es toda la historia.
El espectro de permisos, del más pesado al más ligero
Los permisos financieros se organizan por niveles. En la cima está la entidad de crédito —el banco—, que puede captar depósitos y conceder préstamos. Por debajo, una entidad de dinero electrónico (EMI) puede emitir dinero electrónico: puede custodiar el valor de sus clientes y ponerlo en tarjetas o en wallets, pero los fondos que mantiene deben estar salvaguardados —separados e intocables, nunca prestados—. Más abajo, una entidad de pago (PI) puede ejecutar pagos —iniciar transferencias, cobrar, remesar, adquirir transacciones con tarjeta—, pero no está pensada para almacenar valor en el tiempo: el dinero pasa, no se queda. Y en el último escalón, un agente o distribuidor no tiene licencia propia, sino que opera bajo la autorización de una entidad con licencia que lo ha registrado.
El patrón es que cada peldaño que se baja elimina una capacidad y, con ella, una parte del capital y de las obligaciones. Captar depósitos es lo más pesado que se puede estar autorizado a hacer; ser agente de quien puede hacerlo es lo más ligero. La mayoría de las apps fintech de consumo —wallets, tarjetas, transferencias, enlaces de pago— se sitúan en el rango de las EMI y las entidades de pago, o sobre un partner que cuenta con uno de esos permisos. Muy pocas necesitan ser un banco, y saberlo desde el principio ahorra muchos esfuerzos mal encaminados.
Una forma rápida de ubicarse: si tus clientes van a mantener un saldo en la app —una wallet que recargan, una tarjeta que precargan—, estás en territorio de dinero electrónico, porque almacenar valor es el permiso que define a una EMI. Si el dinero solo transita —inicias una transferencia, cobras un recibo, trasladas un pago directamente—, el encaje natural es un permiso de entidad de pago, ya sea propio o de un partner. Si nunca tocas los fondos y solo presentas información de cuentas que se tienen en otro lugar, incluso eso tiene su propio registro, más ligero. Cuanto más pesado es tu nivel, más capital y supervisión conlleva; el objetivo de diseño es no situarse más arriba de lo que el producto realmente requiere.
Alquilar el permiso: modelos con partner
No hace falta tener el permiso para construir sobre él. La vía habitual es alquilarlo. Con un acuerdo de banco patrocinador o de Banking-as-a-Service, un banco o una EMI con licencia mantiene las cuentas, emite los IBAN y las tarjetas y salvaguarda los fondos; tú desarrollas la app sobre su API y lanzas la experiencia. Con un modelo de agente, te registras como agente de una entidad de pago —o como distribuidor de un emisor de dinero electrónico— y su licencia cubre tu actividad, con el regulador al tanto de tu existencia a través de ellos. Contratos distintos, el mismo hecho de fondo: en algún punto de la cadena, alguien tiene el permiso. La única cuestión es si ese alguien eres tú o un partner.
Quién asume cada responsabilidad
Alquilar una licencia no traslada la responsabilidad. La entidad con licencia es la que responde ante el regulador: de la salvaguarda de los fondos de los clientes, de la supervisión contra el blanqueo de capitales, de la conducta de todo el programa. Pero esas obligaciones se trasladan hacia abajo por contrato. Si operas bajo la licencia de un partner, seguirás ejecutando el KYC y el onboarding, vigilando las transacciones por AML y respetando los límites y los informes a los que el partner está sujeto. La responsabilidad no se externaliza tanto como se reparte: el partner responde ante el regulador y te exige a ti, por contrato, buena parte del trabajo diario. Lee ese contrato con el mismo cuidado con el que leerías la licencia que decidiste no obtener.
Una licencia es el permiso para custodiar o mover el dinero de otras personas. El software es cómo se da la instrucción, se concilia y se muestra ese dinero al cliente. Puedes comprarlos a un proveedor o a dos, pero siempre estás comprando ambos.
El software y la licencia se compran por separado
Esta es la idea que reordena todo el proyecto. Para el cliente, una app de pagos parece una sola cosa, pero son dos fusionadas: el permiso regulado para custodiar o mover dinero, y el software que ordena el movimiento, lleva el libro mayor, concilia los abonos y muestra un saldo en pantalla. Ambos se obtienen por separado. Puedes tener licencia propia y comprar el software; tener licencia y desarrollar el software internamente; alquilar el permiso a través de un partner y comprar el software encima; o contratar ambos a un único proveedor que los ofrece empaquetados. Los cuatro casos son normales. Lo que no es normal —y lo que cuesta meses a los proyectos sin que se note— es confundir ambos: buscar una «licencia bancaria» cuando lo que necesitabas era un partner de BaaS más una app, o buscar una app dando por hecho que el permiso viene soldado a ella.
Ver ambas compras como separadas aclara las cosas porque permite valorarlas y planificarlas de forma independiente. El software se puede juzgar por sus méritos —si el flujo de onboarding funciona, si el libro mayor es correcto, si los operadores pueden realmente manejarlo—, mientras que el permiso se evalúa por jurisdicción, salvaguarda y condiciones. Protocore Pay (/products/pay) es un ejemplo de la capa de software por sí sola: una plataforma de apps whitelabel con consola de operador que funciona sobre los raíles regulados que aportes. No es una licencia, y ningún software lo es; por eso mismo la licencia sigue siendo una partida aparte en el plan.
Preguntas para cualquier proveedor de plataformas
Quienquiera que te ofrezca una plataforma para «lanzar tu fintech», la misma lista corta despeja casi toda la ambigüedad. ¿Tu producto incluye un permiso regulado o debo aportar el mío? Si lo incluye, ¿de quién es la licencia, en qué países, y soy cliente directo de esa entidad o de su agente? ¿Quién salvaguarda los fondos de los clientes y dónde se mantienen? ¿Quién figura ante el regulador en materia de prevención del blanqueo: tú, el partner o yo? ¿Qué obligaciones recaen sobre mí por contrato aunque la licencia no sea mía? Y si termina la relación con el partner, ¿qué pasa con el dinero de mis clientes y con sus datos? Las respuestas clasifican rápido a los proveedores entre los que venden software, los que revenden el permiso de un partner y los que de verdad han empaquetado ambos, y te dicen con cuál de los tres estás hablando.
Lo tranquilizador de todo esto: la mayoría de las apps se lanzan con software más el permiso de un partner, y pasan a tener licencia propia solo cuando el volumen, el margen o la estrategia hacen que compense el capital y el equipo de cumplimiento. Saber qué peldaño necesitas de verdad —y que el software y el permiso se compran en partidas separadas— es la mayor parte de la batalla. El resto es hacer las preguntas anteriores y leer las respuestas con atención. Nada de esto es asesoramiento jurídico, y los umbrales y los nombres de las categorías varían según la jurisdicción; tómalo como el mapa que llevas a la conversación con un regulador o un asesor, no como un sustituto de ellos.
¿Tienes un sistema que construir?
Cuéntanos el problema. Volveremos con una arquitectura y un plan.