Construir, comprar o asociarse. La decisión de infraestructura para fintechs con licencia.

Cuando una fintech con licencia necesita construir su producto sobre infraestructura bancaria, los fundadores se enfrentan a una decisión que normalmente se toma por sesgo de ingeniería y no por lógica comercial. El movimiento por defecto de los fundadores técnicamente fuertes es construir. El de los fundadores con el capital justo es comprar. El de los fundadores que ya han pasado por esto es asociarse.

La decisión tiene más matices de lo que sugieren esos automatismos. Puntos de partida distintos producen respuestas correctas distintas, y el coste de equivocarse se mide en años de lanzamiento retrasado y capital quemado.

He visto los tres caminos ejecutarse bien y he visto fracasar a los tres. El patrón del fracaso no es aleatorio: se correlaciona con una lógica de decisión que no encaja con el punto de partida del fundador.

La opción de construir

Qué significa: la fintech emplea a su propio equipo de ingeniería para desarrollar el stack principal (procesamiento de transacciones, ledger, orquestación de KYC, integración con procesamiento de tarjetas, gestión de tesorería, reporting) desde cero o a partir de componentes open source.

Cuándo gana.

Cuando el producto necesita de verdad una arquitectura a medida que ninguna plataforma disponible soporta. Esto es más raro de lo que creen los fundadores. La mayoría de los productos fintech son variaciones de patrones que ya se han construido antes, y la diferenciación real está en la capa de experiencia de cliente - no en la capa de infraestructura.

Cuándo pierde.

Cuando la decisión de construir se justifica con un «queremos controlar nuestro destino» o un «no queremos depender de un proveedor». Son justificaciones emocionales, no comerciales. Un desarrollo que tarda 18 meses en alcanzar la paridad de producción con la oferta de un proveedor ha consumido 18 meses de capital, 18 meses de atención directiva y 18 meses de coste de oportunidad. La mayoría de las fintechs que construyen mueren porque no tienen 18 meses.

Cómo comprobarlo.

Escriba qué va a poder hacer seis meses después del lanzamiento que no podría hacer si hubiera comprado. Si la respuesta es «habremos construido nuestro propio ledger», eso no es un diferenciador de cara al cliente. Si la respuesta es «habremos lanzado una categoría de producto que ninguna plataforma soporta», sí lo es.

La opción de comprar

Qué significa: la fintech licencia una plataforma (orquestación BaaS, SaaS vertical para entidades reguladas, finanzas embebidas) que proporciona el stack principal como servicio configurado. La fintech concentra su equipo de ingeniería en la capa de producto que va por encima.

Cuándo gana.

Cuando la fintech puede lanzar un producto competitivo con la configuración de la plataforma, sin necesidad de desarrollo a medida. Es el caso más habitual en la mayoría de los productos fintech: pagos, neobanca, finanzas embebidas, tarjetas de marca blanca.

Cuándo pierde.

Cuando la fintech elige una plataforma que no puede entregar de verdad lo que prometía el copy de marketing. La licencia está firmada, el presupuesto de servicios profesionales agotado y el producto sigue a seis meses del lanzamiento. Es el modo de fallo más común de la vía de comprar, y se previene con la disciplina de evaluación de proveedores que la mayoría de compradores se salta.

Cómo comprobarlo.

¿Puede el proveedor enseñarle, en un sandbox funcionando, los flujos de usuario concretos que su producto necesita, con datos y latencias realistas? Si es así, la plataforma probablemente cumplirá. Si la demo exige lenguaje condicional («esto se lo podemos configurar» o «esto entra en la próxima release»), la plataforma vende promesas - no capacidad.

La opción de asociarse

Qué significa: la fintech cierra una relación comercial directa con un partner bancario (banco patrocinador, banco emisor, partner EMI) y construye su propia capa de conectividad sobre esa relación, sin plataforma intermediaria.

Cuándo gana.

Cuando la fintech tiene acceso a una relación que produce condiciones comerciales (intercambio, margen de FX, reparto de ingresos por depósitos) claramente mejores que las que una plataforma puede trasladar. Normalmente exige una relación previa de la carrera anterior de algún fundador, o una palanca comercial concreta que el partner valore.

Cuándo pierde.

Cuando la asociación se da por supuesta en lugar de contratarse, o cuando la capacidad operativa del partner no encaja con el calendario de lanzamiento de la fintech. El fracaso más caro aquí es la asociación que existe como apretón de manos a nivel directivo pero no puede ejecutarse a nivel operativo. La fintech pasa meses intentando integrarse con un partner cuya API no está lista para producción, o cuyo proceso interno de compliance introduce retrasos que el fundador no había previsto.

Cómo comprobarlo.

¿Tiene un term sheet firmado, un responsable de integración con nombre y capacidad asignada en el partner, y una fecha de lanzamiento que el equipo de operaciones del partner haya confirmado por escrito? Si falta cualquiera de las tres, lo que tiene es un concepto de asociación - no una asociación.

La secuencia de decisión

La decisión rara vez es binaria. La mayoría de fintechs con licencia que triunfan combinan: se asocian para una relación crítica (el patrocinador bancario, la membresía en el esquema de tarjetas), compran la capa de orquestación y construyen solo el producto de cara al cliente.

Yo ejecutaría la secuencia en este orden:

1. Identifique qué debe construir porque nadie más puede construirlo por usted. Eso es su diferenciación.

2. Identifique para qué debe asociarse porque el valor comercial justifica la complejidad operativa. Suele ser una o dos relaciones clave.

3. Compre todo lo demás.

Los fundadores que invierten esta secuencia (construirlo todo, no asociarse para nada, tratar la plataforma como el diferenciador) son los que queman capital más rápido. La secuencia honesta obliga a un desarrollo pequeño, a una conversación de partnership enfocada y a una decisión de compra rápida. La secuencia inversa produce un desarrollo indefinido, una conversación de partnership aplazada y una decisión de compra que nunca llega a tomarse porque el desarrollo siempre parece estar al 60%.

Modos de fallo habituales

Construir porque el CTO quiere.

El entusiasmo del CTO no sustituye a la prueba comercial. Construya si construir diferencia el producto. No construya porque construir le parezca más creíble que comprar. Es el modo de fallo más común en equipos de fundadores técnicos en su primera fintech.

Comprar porque el pitch del proveedor era bueno.

El pitch es la parte fácil. La difícil es la ejecución en el mes 12, cuando la integración está a medias y el presupuesto de servicios profesionales se ha agotado. La disciplina de evaluación de proveedores - hacer las preguntas que la mayoría de compradores se salta - es lo que protege de esto. El artículo anterior sobre evaluación de proveedores cubre las preguntas concretas que importan.

Asociarse porque un banquero sénior dijo que sí en una cena.

Los banqueros sénior dicen que sí a menudo. Los equipos de operaciones ejecutan despacio. En la distancia entre la conversación directiva y la realidad operativa es donde mueren las asociaciones. El term sheet firmado, el responsable de integración con nombre y la fecha de lanzamiento por escrito no son formalismos. Son la prueba de si la asociación es real.

La respuesta correcta para la mayoría de fintechs con licencia en 2026 es una mezcla: construir el producto, comprar la orquestación, asociarse para la parte bancaria. Las fintechs que intentan hacer las tres cosas a la vez acaban con lo peor de cada una: un stack a medio construir, una plataforma sobrepersonalizada y una asociación que no termina de funcionar. La disciplina está en elegir qué capa es cuál y ser honesto con la respuesta.