Core banking vs BaaS: qué compras en realidad

El core banking es el sistema de registro del dinero: el libro mayor que contiene cada cuenta, cada saldo y cada asiento, además de las reglas que mueven el valor entre ellos correctamente. Banking-as-a-Service (BaaS) consiste en alquilar el core de otro —y el permiso regulado que lo respalda— mediante una API, en lugar de operar el tuyo. Entre tener un core propio y operar bajo un registro de agente hay un espectro, y el punto en que te sitúes decide qué construyes, qué alquilas y de qué eres responsable. «Core banking vs BaaS» no es realmente una comparación de productos; es una pregunta sobre cuánto de la pila quieres controlar.

Conviene aclararlo porque ambos se buscan como si estuvieran en el mismo pasillo. No lo están. Uno es software que tiene que ser correcto; el otro es un acuerdo comercial que te da corrección como servicio y te la factura. Saber cuál estás comprando —y cuál necesitas en realidad— es la mayor parte de la decisión.

Qué es realmente el «core banking»

Un sistema de core banking es el libro mayor de referencia y la maquinaria que lo rodea. Contiene el plan de cuentas, mantiene los saldos, registra cada asiento por partida doble para que débitos y créditos siempre cuadren, aplica y libera retenciones, devenga intereses y comisiones, y genera los extractos de los que depende todo lo demás. Es la parte de un banco que tiene que estar bien, porque si el libro mayor falla, nada de lo que se construya encima es fiable. Todo lo demás —la app, el diseño de la tarjeta, las notificaciones— es presentación. El core es la verdad.

Esa es la primera distinción que conviene retener: el core no es la app. El cliente ve una app; detrás, algún libro mayor lleva la cuenta. Puedes ser dueño de ese libro mayor, alquilarlo u operar sobre alguien que lo tiene. Esas tres opciones son el espectro.

El espectro: core propio, BaaS, agente

En el extremo pesado, el core es tuyo por completo: tu libro mayor, tu permiso para custodiar o mover dinero, tus conexiones directas con los raíles de pago. En el medio está el BaaS: un proveedor con licencia posee el core y el permiso, y tú construyes sobre su API —sus cuentas, sus IBAN, sus tarjetas, con tu marca—. En el extremo ligero está el modelo de agente: no tienes core ni licencia propios, sino que operas bajo una entidad con licencia que te ha registrado. Cada escalón que se baja elimina capacidad y, con ella, una parte del coste y de las obligaciones.

Core propio: control, y su factura

Tener el core propio da control. Tú defines la hoja de ruta del producto en lugar de esperar a la de un proveedor. Mantienes las cuentas directamente, te conectas directamente a los raíles, y tu economía unitaria deja de ser el margen de otro: a escala, el alquiler por cuenta y por transacción que habrías pagado a un proveedor de BaaS se convierte en margen para ti. Nada se interpone entre tus decisiones y el libro mayor donde se reflejan.

La factura es grande y en su mayor parte no es de software. Necesitas el permiso regulado (una compra aparte del software y, a menudo, la más difícil; el vocabulario de salvaguarda, interchange y liquidación está en /glossary), el capital que ese permiso exige, el equipo de cumplimiento y operaciones para sostenerlo, y las integraciones directas con cada raíl y cada esquema que utilices. Y la corrección pasa a ser tuya: cuando el libro mayor falla a las 2 de la madrugada, no hay proveedor al que llamar. Eres dueño de la verdad, y por tanto también de los fallos.

BaaS: alquilar el core y el permiso

El BaaS convierte esa factura en una relación mensual. Un partner con licencia mantiene las cuentas, emite los IBAN y las tarjetas, salvaguarda los fondos y responde ante el regulador; tú desarrollas la app sobre su API y lanzas. Lo que compras es velocidad: un core operativo y autorizado desde el primer día, en lugar de una solicitud de licencia y un proyecto de libro mayor. Para la mayoría de los equipos que lanzan su primer producto, ese intercambio es el acertado.

Lo que cedes es la propiedad. La economía del proveedor se convierte en tu coste mínimo: pagas por cuenta y por transacción, y esas tarifas no bajan al crecer como lo haría una infraestructura propia. Los límites del proveedor pasan a ser los tuyos, su hoja de ruta condiciona la tuya, y no eres dueño del libro mayor, lo que encarece la salida y convierte la migración en un proyecto en sí mismo. El BaaS es alquilar la parte correcta de un banco. El alquiler es barato al empezar y no termina nunca.

Un core propio es un proyecto de capital que se amortiza a escala. Un core alquilado es un coste operativo que nunca baja. La cuestión no es cuál es mejor, sino cuál se han ganado ya tu volumen y tu margen.

El modelo de agente: el más ligero

Más ligero todavía, el modelo de agente te pide construir casi nada del lado del dinero. Te registras como agente de una entidad de pago o como distribuidor de un emisor de dinero electrónico; su licencia cubre tu actividad, su core lleva el libro mayor y el regulador te conoce a través de ellos. Es la forma más rápida de poner un producto financiero con tu marca ante los clientes y la que menos control te deja: eres una cara sobre raíles ajenos, y sus condiciones son tu techo.

Dónde encaja una plataforma whitelabel sobre tu propio core

Hay una cuarta posición que el espectro oculta: tener tu propio core sin construir desde cero la capa de aplicación. El permiso regulado y el software que lo ejecuta son compras distintas: puedes tener tu propia licencia y aun así comprar la app de cliente, la consola de operador y la personalización visual como una plataforma encima. Ahí es donde encaja una plataforma whitelabel. Protocore Pay (/products/pay) es la capa de software por sí sola: una plataforma de apps con marca propia y consola de operador que funciona sobre el core y los raíles que aportes —propios o de un partner—, sin atar una licencia a la venta. La consola que la acompaña, donde cada acción privilegiada exige un motivo y queda registrada en un log de auditoría, es Protocore Center (/products/center).

Planteado así, queda más claro, porque permite valorar las dos líneas por separado. La licencia se juzga por jurisdicción, salvaguarda de fondos y condiciones; el software, por si el onboarding funciona, la integración con el ledger es limpia y los operadores pueden manejarlo de verdad. Comprar software no te compromete con una licencia, y comprar una licencia no te entrega una app: una confusión que, sin hacer ruido, cuesta meses a los proyectos.

Elegir tu peldaño

La heurística honesta se basa en volumen, margen y control. Si estás lanzando, no tienes clara la demanda y necesitas moverte rápido, BaaS o el registro como agente te pone en producción sin una ronda de capital, y aceptas el alquiler por transacción como precio de la velocidad. Si creces, con un volumen en el que el alquiler ya supera lo que costarían tu propio cumplimiento normativo y tu infraestructura, y con una hoja de ruta que un proveedor te bloquea una y otra vez, es entonces cuando tener el core propio empieza a compensar. La mayoría de los productos empiezan en alquiler y pasan a propiedad una sola vez: cuando los números dicen que el capital y el equipo salen más baratos que el alquiler.

Nada de esto es asesoramiento legal, y los nombres de las categorías cambian según la jurisdicción; tómalo como el mapa que llevas a una conversación con un regulador o un asesor, no como sustituto de ellos. Pero la estructura se mantiene en todas partes: el core bancario es el ledger que debe ser correcto, BaaS es alquilar esa corrección por meses, y una plataforma whitelabel es el software que pones encima de la opción que elijas. Compra el peldaño que tu volumen se ha ganado, y compra el software y la licencia como las dos cosas distintas que siempre fueron.