Guía de compra de plataformas de neobanco whitelabel

Una plataforma de neobanco whitelabel es software al que se le pone la marca propia para lanzar una app de estilo bancario (cuentas, tarjetas, transferencias y, a veces, cripto) sin construir el core desde cero. Comprar una es, en realidad, comprar dos cosas fáciles de confundir: el core que mueve el dinero y la capa de app que ven tus clientes. Esta guía sirve para distinguirlas antes de firmar, porque casi todas las preguntas difíciles sobre una plataforma whitelabel acaban siendo preguntas sobre dónde están sus costuras, y el trabajo del proveedor es difuminar esa línea mientras que el del comprador es encontrarla.

Hay cinco cortes que conviene hacer antes de comprometerse: core frente a capa de app, dónde reside la licencia, hasta dónde llega el sistema de diseño, entrega independiente o embebida, y la decisión de construir o comprar que subyace a todo lo demás. Vamos por orden.

Primer corte: el core frente a la capa de app

La línea más útil es la que separa la parte que debe ser correcta de la parte que debe ser tuya. El core es caro de equivocar: un libro mayor de partida doble, cuentas y saldos, KYC y onboarding, emisión y procesamiento de tarjetas, rails de cripto y stablecoins, y la consola de operación que lo gobierna todo. La capa de app es lo que toca el cliente: la marca, las pantallas, la arquitectura de la información, el subconjunto de funciones activadas. Una plataforma que merece la pena comparte un único core entre todas las marcas y configura la app por tenant. Evalúa ambas con criterios distintos: juzga el core por su corrección (si el libro mayor es de verdadera partida doble, si la conciliación cuadra, si los operadores pueden operarlo de verdad) y la capa de app por su flexibilidad (hasta dónde puede divergir una marca antes de que alguien tenga que hacer un fork).

Dónde reside la licencia y si es separable

El permiso para custodiar o mover dinero está regulado, y no es la misma compra que el software. Pregunta sin rodeos si la plataforma incluye una autorización regulada o espera que aportes la tuya; y, si la incluye, de quién es la licencia, en qué países y si eres su cliente directo o su agente. Lo que importa al comprador es la separación: una plataforma que suelda su software a una única licencia que no puedes sustituir ha elegido en silencio tu jurisdicción y tu socio por ti, mientras que una que trata la licencia como un rail que tú aportas te deja elegir la autorización de forma independiente y cambiarla después. Ninguna es incorrecta, pero debes saber cuál estás comprando. Protocore Pay (/products/pay) es la capa de software por sí sola: funciona sobre los rails regulados que tú aportes, y ningún software es una licencia. Los conceptos que saldrán en esa conversación (EMI, entidad de pago, agente, banco patrocinador) se explican en el /glossary.

Hasta dónde llega el sistema de diseño

Toda la promesa del whitelabel es que la app parezca tuya y no un simple cambio de aspecto de la demo del proveedor, y esa promesa solo llega tan lejos como el sistema de diseño que la sustenta. Uno superficial permite cambiar un logotipo y un color de acento. Uno profundo expone el vocabulario real (color, tipografía, radio de esquina, espaciado, densidad, movimiento) como tokens que lee cada pantalla, de modo que una marca es un conjunto de sobrescrituras y no un fork. Pregunta cuántos tokens hay y qué cubren, si los mismos tokens se emiten para web, nativo y escritorio para que un color sea el mismo color en todas partes, y si un diseñador puede alejar a un tenant mucho de la build de referencia sin tocar código. El sistema de diseño de Protocore (/products/pds) es una respuesta ya en producción (144 tokens y 889 clases de utilidad, dark-first, radio cero por defecto, emitido para web, .NET y nativo), pero la pregunta del comprador es general: ¿la capa de diseño es un auténtico sistema de tokens o una mano de pintura sobre una app fija?

App independiente o capa embebida

La entrega adopta dos formas. Una app independiente es una app bancaria completa a la que pones tu marca y que lanzas con tu propio nombre: tus clientes descargan tu banco. Una capa embebida es un conjunto de componentes y flujos que integras en un producto que ya tienes: pagos y saldos dentro de tu app actual. La elección no tiene que ver con la calidad, sino con dónde debe vivir la experiencia del dinero. Si la banca es tu producto, quieres la versión independiente. Si la banca es una función de un producto mayor (un marketplace que paga a sus vendedores, una plataforma que da una wallet a sus usuarios), quieres la vía embebida, para que el dinero esté donde tus clientes ya están. Una plataforma que merece la pena puede hacer ambas desde un mismo core, porque al core le da igual que su front end sea una app independiente o un panel dentro de la de otro.

Construir o comprar: el equilibrio, sin rodeos

Construir el core por tu cuenta compra control y cuesta años. Un libro mayor correcto, el procesamiento de tarjetas, el KYC, la conciliación y una consola de operación son proyectos en sí mismos, y todos son requisitos mínimos que hay que superar antes de haber lanzado una sola función que el cliente note. Comprar el core te devuelve esos años y te cuesta algo de soberanía: heredas el modelo ajeno de lo que es una cuenta, un límite, una liquidación. La forma honesta de decidir es preguntarse qué partes son tu producto y cuáles son fontanería. La fontanería (liquidación, conciliación, herramientas de cumplimiento) es muy parecida para todos y rara vez es donde se gana: cómprala. Las partes por las que tus clientes te eligen de verdad (los flujos, la marca, lo único que haces mejor que el operador tradicional) son donde deben dedicar su vida tus propios ingenieros. Comprar una plataforma es apostar a que el core es fontanería y tu diferenciación vive por encima.

Nunca compras un neobanco. Compras un core que esperas que sea fontanería y una capa de app que piensas hacer tuya, y toda la evaluación consiste en decidir si el proveedor trazó esa línea donde la habrías trazado tú.

Cinco direcciones, no cinco productos

Si pides ejemplos a un proveedor, a menudo te enseñará un puñado de apps terminadas. Léelas bien: son direcciones que puede tomar un mismo core, no un menú del que eliges un plato. El core de referencia de una plataforma puede dar soporte a un exchange limpio (Halcyon: sobrio, con la operación en primer plano), una superapp basada en el chat (Lumen: el dinero se mueve dentro de la conversación), una app centrada en transferencias (Fern: pagos por lotes y conversión basada en reglas ante todo), una build de stablecoins en modo oscuro (Volt: un clasificador de nóminas y tarjetas de equipo) y una cuenta multidivisa (Meridian: un saldo en EUR junto a USDC, y una cuenta BTC donde llegan las recompensas de la tarjeta). Cinco marcas, cinco arquitecturas de la información, cinco combinaciones de funciones: un único libro mayor, un único KYC y un único procesador de tarjetas bajo todas ellas. La cifra que importa no es cinco, sino cuantos tenants sea capaz de soportar el core. Un proveedor que te dice que el producto son cinco apps no ha entendido su propio producto; uno que te enseña cinco para demostrar que la sexta es trivial, sí.

Las preguntas que filtran a los proveedores

Una lista corta desmonta la mayoría de los discursos comerciales. ¿El core es un sistema compartido o una bifurcación por cliente? Y cuando se corrige un error, ¿la corrección llega a todos los tenants a la vez? ¿La capa de diseño expone tokens reales o solo un hueco para el logotipo? ¿La plataforma incluye un permiso regulado o debo aportar el mío, y puedo sustituirlo más adelante? ¿Puede el mismo core entregar tanto una app independiente como una capa embebida? ¿Qué partes consideráis infraestructura básica y cuáles esperáis que construya yo mismo? Las respuestas sitúan a un proveedor en el mapa que ha ido trazando esta guía: core compartido o granja de forks, sistema de tokens o simple pintura, software más mi licencia o paquete soldado, una forma de entrega o dos. El análisis completo de uno de estos cores —las cinco direcciones, la app de referencia y la consola de operador que hay detrás— está en /products/pay, el sistema de diseño que lo sustenta está en /products/pds y los términos, en el /glossary.