Sistemas de core bancario en 2026: la guía completa
Una inmersión profunda en 2026 en el core bancario: qué es, cores cloud-native frente a heredados, el panorama de proveedores (Mambu, Temenos, Thought Machine, Finxact, Tuum, Pismo, 10x, Minsait), comprar o construir, TCO y rutas de modernización.
¿Qué es un sistema de core bancario?
Un sistema de core bancario es el software que lleva los libros del banco. Mantiene el saldo de cada cuenta, registra cada adeudo y abono, aplica intereses, contabiliza comisiones y responde a la pregunta sencilla: "¿cuál es el saldo ahora mismo y esta transacción está permitida?". Todo lo demás que hace un banco - app móvil, programas de tarjetas, concesión de préstamos, KYC, analítica - se apoya sobre ese libro mayor y confía en que sea correcto.
Durante cuarenta años, core banking significó un monolito escrito en COBOL o PL/SQL, ejecutándose en un mainframe dentro del centro de datos del propio banco, parcheado cada noche en una ventana batch de dos horas. En 2026, un core nuevo es casi siempre cloud-native, API-first, orientado a eventos y desplegado de forma continua. El cambio es tan grande como el paso del correo on-premise a Gmail y sucede a una velocidad parecida.
Libro mayor
Cada cuenta, cada asiento, cada devengo de intereses. La única fuente de verdad que le importa al Banco de España.
Motor transaccional
Cobros, pagos, retenciones, reversos, ficheros de liquidación. En tiempo real, 24/7, conciliados al céntimo.
Fábrica de productos
Cuentas corrientes, ahorro, préstamos, tarjetas, depósitos a plazo. Modelados como parámetros, no como código.
Cuando un banco dice "vamos a sustituir el core", se refiere al trasplante de corazón. Es el proyecto más grande, más arriesgado y más caro que ejecuta una entidad. También es el proyecto que, bien hecho, reduce el coste operativo entre un 30% y un 50% y permite lanzar productos nuevos en semanas en lugar de trimestres.
Hablemos de tu proyecto y veamos cómo podemos lanzar tu Producto bancario digital Juntos
Solicita una demoCloud-native frente a cores heredados
Las dos generaciones conviven en 2026 y la mayoría de bancos operan ambas a la vez. Entender la diferencia es la primera pregunta que tiene que resolver cualquier conversación de modernización.
| Dimensión | Core heredado | Core cloud-native |
|---|---|---|
| Arquitectura | Monolito, módulos fuertemente acoplados, base de datos compartida | Microservicios, orientado a eventos, APIs de dominio |
| Procesamiento | Batch nocturno, ventanas de mantenimiento de dos horas | Tiempo real, 24/7, sin corte de día |
| Despliegue | Mainframe on-premise, entregas trimestrales | Nube pública (AWS, GCP, Azure), despliegue continuo |
| Configuración de producto | Cambios de código, ciclos de 6 a 12 meses | Definiciones de producto como datos, producto nuevo en días |
| Coste típico por cuenta | 40-80 USD al año | 4-15 USD al año |
| Modelo de escalado | Vertical, comprar un mainframe más grande | Horizontal, añadir contenedores bajo demanda |
Dicho en directo: los cores heredados se construyeron cuando la banca era una actividad de nueve a cinco en la sucursal. Los cores cloud-native se construyeron para un mundo en el que una cliente paga a un técnico en Manila desde una playa de Portugal a las tres de la mañana. El modelo operativo del banco tiene que encajar con la arquitectura de su core; si no, pierde dinero por cada costura.
El panorama de proveedores de core bancario en 2026
Alrededor de una docena de proveedores cuentan en 2026. Se agrupan en tres bloques: los retadores cloud-native nacidos después de 2010, los incumbentes que se han renovado y los especialistas regionales. En España, además, el ecosistema de integradores y proveedores locales como Indra/Minsait tiene un peso notable, y Tuum y Mambu han ganado tracción en banca digital y fintechs ibéricas.
Retadores cloud-native
- Mambu (Berlín): core SaaS, fuerte en crédito minorista y pyme, con clientes como N26 y ABN AMRO.
- Thought Machine (Londres): Vault Core y Vault Payments, smart contracts para la lógica de producto, utilizado por Lloyds y Standard Chartered.
- Finxact (hoy Fiserv): core en tiempo real centrado en EE.UU., adoptado por Mercantile Bank y Live Oak.
- Tuum (Tallin): core modular por API para bancos y fintechs en toda Europa, con proyectos recientes en España.
- 10x Banking (Londres): SuperCore, diseñado para bancos de primer nivel, operando en Chase UK y Westpac.
- Pismo (adquirido por Visa): core cloud latinoamericano, tarjetas y cuentas, muy implantado en Brasil.
Incumbentes modernizados
- Temenos: Transact sigue siendo el core más desplegado a nivel mundial; Temenos SaaS ofrece la vía cloud.
- SAP Fioneer: spin-off de SAP, se integra estrechamente con SAP ERP y tesorería.
- Oracle Flexcube y FSS: amplia funcionalidad, fuertes en MEA y APAC.
- Infosys Finacle: dominante en India y Sudeste Asiático, con ediciones cloud desde 2023.
- FIS IBS y TCS BaNCS: gran base instalada en Norteamérica y Reino Unido respectivamente.
- Minsait (Indra): integrador clave en España y Latinoamérica, con el core propio Altamira en bancos de la región.
Los datos de IBS Intelligence y Celent para 2025-2026 apuntan a la misma tendencia: los proveedores cloud-native se llevan la mayoría de las adjudicaciones greenfield y los lanzamientos de bancos digitales, mientras los incumbentes retienen el ciclo de reemplazo en los mayores bancos de primer nivel. La zona intermedia (bancos de segundo y tercer nivel, cooperativas de crédito, fintechs) es donde la batalla es más intensa.
El mercado de core bancario en 2026, en cifras
Dos hechos marcan cada conversación de comité en 2026. Primero, los bancos dedican alrededor del 70% de su presupuesto de TI solo a mantener luz encendida, y la mayor parte va al core heredado. Segundo, la migración media de core bancario dura entre tres y siete años y cuesta entre 100 M$ y 2.000 M$. Esa brecha entre lo que los bancos necesitan y lo que pueden permitirse es justo el hueco que están llenando los proveedores cloud-native y las plataformas de orquestación.
Arquitectura de microservicios por dentro
La diferencia entre un core moderno y uno heredado no es marketing. Es el diagrama eléctrico. Un core moderno es un conjunto de servicios desplegables de forma independiente que se comunican a través de un bus de eventos.
Libro mayor
Partida doble, inmutable, event-sourced. Fuente de verdad de saldos y asientos.
Motor de producto
Define qué es cada producto (cuenta corriente, préstamo, tarjeta) como dato, no como código.
Hub de pagos
SEPA, SEPA Instant, SWIFT, FedNow, Bizum, redes de tarjetas, todo tras una única abstracción.
Party y rol
Clientes, entidades, firmantes autorizados, titulares reales. Compartido entre productos.
Alrededor de esos cuatro pilares está el resto: KYC y onboarding, fraude y monitorización transaccional, límites, pricing, comisiones, extractos, reporting regulatorio, analítica. Cada uno es un servicio propio, cada uno publica eventos, cada uno puede cambiarse o actualizarse sin tumbar el banco. Por eso un core cloud-native puede subir a producción varias veces por semana, mientras un core heredado lo hace cuatro veces al año en fin de semana.
Comprar, construir o alquilar: las tres rutas honestas
No hay respuesta universalmente correcta. Solo hay una respuesta adecuada para su licencia, su capital, su equipo y sus plazos.
| Ruta | Tiempo | Capital | Encaje ideal |
|---|---|---|---|
| Construir internamente | 3-5 años | 50 M$+ más un equipo de 50 ingenieros o más | Bancos de primer nivel con necesidades de producto poco habituales y bolsillos profundos (JPMorgan, Goldman Marcus). |
| Comprar e integrar un core de proveedor | 18-36 meses | 5-100 M$ según el tamaño | Bancos de segundo y tercer nivel que sustituyen el legacy, o neobancos bien financiados que quieren control total. |
| Alquilar una plataforma de orquestación (p. ej. Crassula) | 4-12 semanas hasta MVP | Rango de seis cifras bajo, suscripción SaaS | Fintechs, EDE, entidades de pago y distribuidores que quieren un producto con marca propia sin integrar un core completo. |
La mayoría de los equipos fuera del primer nivel eligen la segunda o la tercera ruta. Ahí es donde se sitúa Crassula: libro mayor, motor de producto, enrutado de pagos, programa de tarjetas, orquestación de KYC, consola de administración y front-ends web y móvil, todo listo para marcar. Conecte su propia entidad licenciada (banco, EDE, entidad de pago) o elija un partner de BaaS y lance.
Coste total de propiedad: dónde va realmente el dinero
El precio de catálogo de un core es un mal indicador del coste total. La factura real está en la integración, la migración de datos, la formación, los programas de change-the-bank y los cinco años de operación tras el go-live.
Regla realista para un banco mediano: por cada 1 $ gastado en software de proveedor, cuente con 2-3 $ en implementación y otro 1 $ al año en operación. Las plataformas cloud-native y orquestadas comprimen la ratio; los reemplazos de legacy la disparan.
Rutas de modernización: big bang, convivencia y progresiva
Tres patrones dominan los programas reales en 2026.
- Big bang. Sustituir el core heredado en un fin de semana de cutover. Ya casi nadie. Riesgo de ejecución alto, y el supervisor (Banco de España, BCE para las grandes) exige planes de contingencia que pocos se pueden permitir. Solo algunos bancos de tercer nivel y de mercados emergentes lo intentan.
- Convivencia. El core nuevo corre junto al viejo, clientes y productos nuevos entran en el nuevo, las carteras existentes se quedan en legacy y migran por oleadas a lo largo de tres a cinco años. Es lo que hacen Lloyds, ING y la mayoría de programas tier-1.
- Progresiva (strangler fig). Extraer una capacidad cada vez (primero el hub de pagos, luego tarjetas, luego ahorro) hacia servicios modernos y dejar que el monolito legacy vaya encogiendo. Popular en banca regional y cooperativas.
Hay una cuarta ruta infravalorada: lanzar una marca nueva sobre un core moderno mientras el legacy sigue funcionando. Chase UK sobre 10x, Marcus sobre Mambu, Bo (RBS) y Mettle (NatWest) arrancaron así. Menor riesgo de ejecución, modelo de datos limpio y, con el tiempo, la marca nueva puede absorber el libro de la matriz.
Dónde se sitúa Crassula en el stack de core bancario en 2026
Crassula no es un motor de libro mayor para un banco de primer nivel. Es la capa de orquestación y de producto que se monta sobre una licencia y un conjunto de raíles, y que pone en marcha un producto bancario con marca propia en semanas. En concreto, Crassula aporta:
Cuentas y libro mayor
Cuentas multidivisa, IBAN virtuales, asientos en tiempo real, conciliaciones y extractos de serie.
Programa de tarjetas
Tarjetas físicas y virtuales con marca propia, tokenización para Apple Pay y Google Pay, partners patrocinadores de BIN.
Enrutado de pagos
SEPA, SEPA Instant, SWIFT, raíles locales y red corresponsal, todo tras una única API.
KYC y cumplimiento
Onboarding, screening AML y monitorización transaccional orquestados sobre los proveedores en los que ya confía.
Front-ends
Banca web, iOS y Android en white-label, listas para marcar y publicar con su nombre.
Back-office de administración
Consola operativa para ops, riesgos y soporte, con accesos por rol y traza de auditoría completa.
Si tiene licencia bancaria, de EDE o de entidad de pago, Crassula envuelve a su entidad licenciada. Si no, le conectamos con uno de nuestros partners BaaS. En cualquiera de los dos casos, lanza un producto bancario real sin pasar tres años integrando Temenos. Hable con nuestro equipo para dimensionar su lanzamiento.
Funciones y módulos de un sistema de core bancario
Un sistema de core bancario es mucho más que un libro mayor. Está formado por módulos funcionales que cubren el ciclo de vida completo de un producto bancario, desde la apertura de una cuenta hasta la liquidación de un crédito. La tabla siguiente recoge las capacidades que un core moderno debe tener, incluyendo los requisitos específicos del Banco de España para entidades reguladas.
| Módulo | Función | Requisitos en 2026 |
|---|---|---|
| Libro mayor | Contabilidad por partida doble, saldos en tiempo real, historial de asientos inmutable | Event-sourced, consultable hasta el asiento individual, multidivisa |
| Motor de producto | Define cuentas, préstamos, depósitos y tarjetas como plantillas configurables | Configuración sin código, reglas paramétricas de interés y comisiones |
| Hub de pagos | Enrutado de pagos entrantes y salientes por SEPA, SWIFT y raíles locales | Tiempo real (SEPA Instant, TIPS, Bizum), nativo ISO 20022 |
| Clientes y terceros | Perfiles de cliente, estado KYC, titulares reales, mandatos | Vista única de cliente entre productos, enlazado al screening AML |
| CRM y gestión de relaciones | Seguimiento de interacciones, segmentos de cliente, límites por relación | Accesible por API, alimenta capas de analítica y personalización |
| Reporting regulatorio | COREP, FINREP, EBA, reportes al Banco de España y Banco Central Europeo | Automatizado, con trazabilidad desde cada cifra hasta la transacción de origen |
El cambio desde 2020 es que estos módulos ya no tienen que venir del mismo proveedor. Los cores abiertos exponen cada función como API, lo que permite combinar lo mejor de cada mundo: un motor antifraude de terceros conectado al libro mayor, un procesador de tarjetas especializado junto al motor de producto. El coste de integración es real, pero la ganancia en flexibilidad es igualmente real.
Tipos de sistemas de core bancario
No todos los sistemas de core bancario son iguales. La elección correcta depende de la base de clientes, la licencia regulatoria y la escala. En España y Latinoamérica conviene considerar además el papel de actores regionales como Minsait (Indra) y cores especializados en mercados emergentes como Pismo.
Core de banca minorista
Alto volumen transaccional, producto simple (cuenta corriente, ahorro, crédito al consumo, tarjeta débito/crédito). Optimizado para bajo coste por cuenta y alta automatización. Usado por bancos al por menor, neobancos (Bnext, imaginBank), EDE y fintechs.
Core corporativo
Estructuras de crédito complejas, cash pooling multiempresa, financiación de comercio, financiación de cadena de suministro. Menor volumen pero mayor valor por operación. Típico de bancos corporativos y plataformas de tesorería.
Core universal
Cubre banca minorista y corporativa en una sola plataforma. Habitual en grandes bancos universales como Santander o BBVA. Temenos Transact y Oracle Flexcube encajan aquí. Mayor complejidad, justificada cuando ambos segmentos son relevantes. Minsait/Altamira opera en este espacio en España y LATAM.
| Modelo de despliegue | Descripción | Encaje típico |
|---|---|---|
| On-premises | El banco gestiona su propia infraestructura; el proveedor entrega el software | Bancos de primer nivel con requisitos estrictos de soberanía del dato o grandes parques legacy |
| Hosted / nube privada | El proveedor gestiona infraestructura dedicada; el banco tiene su propio entorno | Bancos de segundo nivel que quieren operaciones gestionadas sin multitenencia |
| SaaS / multitenencia | Plataforma completamente compartida; el banco configura pero no despliega | Fintechs, EDE, neobancos; lanzamiento más rápido, menor capex |
Integración del core bancario
Un sistema de core bancario solo es tan útil como el ecosistema que le rodea. En la práctica, el core debe conectarse con una docena o más de sistemas externos: proveedores KYC, procesadores de tarjetas, esquemas de pago, motores antifraude, plataformas de BI, portales regulatorios del Banco de España y el BCE. La capa de integración es donde los plazos de los programas suelen desviarse.
Patrones de integración
- API / REST: síncrono, request-response. Ideal para onboarding, consultas de saldo, iniciación de pagos. Estándar para cores modernos y proveedores terceros.
- Eventos / bus de mensajes: asíncrono, publicar-suscribir. Ideal para notificaciones de transacciones, señales antifraude, eventos de auditoría. Kafka, Pulsar y buses de eventos nativos en cloud son habituales.
- Ficheros / batch: intercambio programado de flat files o XML ISO 20022. Todavía se usa para liquidación de redes de tarjetas, reporting regulatorio legacy y ficheros de banca corresponsal.
Puntos de integración clave
- KYC e identidad: Sumsub, Onfido, Veridas (España) y similares se conectan en el onboarding y el screening continuo.
- Redes de tarjetas: ficheros de liquidación de Visa y Mastercard, flujos de autorización a través de patrocinadores de BIN o licencia directa.
- Raíles de pago: SEPA (SCT/SDD), SEPA Instant, SWIFT, Bizum (España), raíles locales LATAM (SPEI en México, PIX en Brasil).
- BI y analítica: eventos del core en streaming hacia un data warehouse para reporting, dashboards y modelos de ML.
- iPaaS y middleware: MuleSoft, Boomi, Azure Integration Services orquestan flujos entre el core y terceros.
Los mejores cores modernos publican un catálogo de API documentado y un catálogo de webhooks/eventos. Antes de elegir proveedor, mapee sus diez puntos de integración principales y verifique que cada uno dispone de un conector documentado y probado, no solo de un "puede hacerse". Esa comprobación elimina la mayor parte de las sorpresas en el programa.
Cómo es un programa de transformación del core bancario
Una transformación del core bancario no es un proyecto de TI. Es un programa de cambio de negocio que resulta involucrar software. La tecnología suele ser la parte más fácil. La gobernanza, la gestión del cambio y el control de riesgos son donde los programas se atascan - el Banco de España y el BCE exigen planes de contingencia y retroceso testados antes de cualquier migración de importancia sistémica.
Errores frecuentes: subestimar los problemas de calidad de datos en el sistema legacy; tratar el programa como un proyecto de TI en lugar de un proyecto de negocio; saltarse el ensayo general; recortar el período de hypercare para ahorrar presupuesto. Los bancos que lo han hecho con éxito señalan el fuerte patrocinio ejecutivo y un equipo de negocio dedicado a tiempo completo como los dos factores de éxito más importantes.
¿Cuánto cuesta un sistema de core bancario?
El precio varía enormemente según el nivel, el modelo de despliegue y el alcance. Las cifras siguientes son orientativas; cualquier programa serio requiere una conversación comercial específica con el proveedor. En mercados LATAM, los costes en moneda local reflejan tipos de cambio y estructuras de contrato distintos.
| Modelo de precio | Rango típico | Cuándo aplica |
|---|---|---|
| Por cuenta (SaaS) | 2-10 $ por cuenta al año | Cores SaaS cloud-native (Mambu, Tuum y similares). Escala directamente con la base de clientes. |
| Por transacción | 0,01-0,05 $ por transacción | Cargas de trabajo intensivas en pagos; a veces combinado con una tarifa base por cuenta. |
| Licencia perpetua + mantenimiento | 2-20 M$ licencia, 15-20% mantenimiento anual | Proveedores legacy e incumbentes modernizados (Temenos, Oracle Flexcube). Alto capex inicial. |
| Plataforma de orquestación | Bajo seis cifras en instalación + SaaS mensual | Crassula y similares: para EDE y fintechs que necesitan una capa de producto completa, no un core desnudo. |
La regla de TCO del bloque anterior aplica aquí también: para un programa con core de proveedor, multiplique el coste del software por dos o tres para llegar al gasto total del programa. Para plataformas de orquestación dirigidas a fintechs y EDE, la economía es diferente: la plataforma gestiona integración, herramientas de compliance y front-ends, colapsando las partidas que dominan los programas de core de proveedor.
Empresas de software de core bancario y partners de desarrollo
Elegir un proveedor de core es una decisión. Decidir quién lo implementa, integra y opera es otra. El mercado tiene dos categorías de partner bien diferenciadas: los fabricantes de software independientes (ISV) que venden la plataforma, y los integradores de sistemas (SI) y empresas de desarrollo que implementan y personalizan.
Proveedores de plataforma de core
Venden el software o la suscripción SaaS. Definen la hoja de ruta del producto. Sus equipos de servicios profesionales suelen hacer la configuración inicial, pero la personalización profunda y la integración de sistemas periféricos normalmente requieren un SI.
Ejemplos: Mambu, Thought Machine, Tuum, 10x Banking, Temenos, SAP Fioneer, Oracle Flexcube, Pismo (muy fuerte en LATAM tras su integración en Visa).
Integradores de sistemas
Grandes consultoras que dirigen el programa, entregan las integraciones, gestionan la migración de datos y ofrecen hypercare. Cobran por día de trabajo; los costes escalan con el tamaño y la complejidad del programa.
Ejemplos en España y LATAM: Minsait (Indra), Accenture, Capgemini, Deloitte, Everis (NTT Data), Sopra Steria. Muchos están especializados en el ecosistema de un proveedor concreto.
Empresas de desarrollo de software bancario
Empresas boutique o de tamaño medio que construyen extensiones, conectores o cores propietarios a medida. Más rápidas y baratas que los grandes SI para problemas acotados. Comunes en Europa del Este y Sudeste Asiático.
Úselas para: construir una capa iPaaS personalizada, desarrollar un producto propio sobre una API de core abierta, o extender una plataforma de proveedor con módulos específicos del mercado local (SPEI, PIX, reporte al Banco de España).
Plataformas de orquestación
Stacks preintegrados que condensan proveedor, SI y conectores en una única suscripción. Intercambian personalización por velocidad y menor coste total. Encaje ideal para EDE, fintechs y marcas de banca digital que no necesitan el conjunto completo de un core de primer nivel.
Ejemplo: Crassula - cuentas, tarjetas, pagos, KYC, front-ends y consola de administración, todo preconectado.
Cuándo contratar una empresa de desarrollo frente a licenciar un producto: si sus requisitos encajan en un 80% dentro de una plataforma existente y el 20% restante puede construirse como extensiones, licencie una plataforma. Si su producto tiene lógica genuinamente novedosa (un instrumento financiero nuevo, una estructura de libro mayor especial, un tipo de producto específico del mercado) que ningún core existente soporta, un desarrollo a medida puede ser la respuesta correcta. La señal de alarma: proveedores que afirman que su plataforma "puede personalizarse" para adaptarse a cualquier necesidad - ese lenguaje suele significar servicios profesionales costosos, no un encaje de producto real.
Preguntas frecuentes
Un sistema de core bancario es el software que lleva el libro mayor del banco, procesa cada transacción, aplica intereses y comisiones y define qué productos (cuentas, préstamos, tarjetas) ofrece la entidad. Todo lo demás - app móvil, web, programa de tarjetas, analítica - lee y escribe en el core. Cuando se habla de "cambiar el core", se habla del trasplante de corazón del banco.
Un core heredado es un monolito, normalmente en COBOL o PL/SQL, que corre procesos batch por la noche en un mainframe dentro del centro de datos del banco. Un core cloud-native es un conjunto de microservicios, orientado a eventos, desplegado en nube pública y procesando 24/7 en tiempo real. El coste operativo por cuenta suele bajar de 40-80 $ al año en legacy a 4-15 $ en cloud-native.
Líderes cloud-native: Mambu, Thought Machine, Finxact (Fiserv), Tuum, 10x Banking, Pismo. Incumbentes modernizados: Temenos, SAP Fioneer, Oracle Flexcube, Infosys Finacle, FIS IBS, TCS BaNCS. En España y Latinoamérica destaca además Minsait (Indra) como integrador y proveedor del core Altamira. La elección depende del tamaño, la región y la preferencia por SaaS o plataforma desplegada.
Salvo que sea un banco de primer nivel con requisitos poco habituales y un equipo de más de cincuenta ingenieros, comprar (o alquilar una plataforma de orquestación) gana siempre. Construir lleva entre tres y cinco años y más de 50 M$. Un core de proveedor moderno llega a producción en 18-36 meses. Una plataforma white-label como Crassula pone un producto con marca en el mercado en menos de tres meses sobre una licencia existente.
Para un banco de segundo o tercer nivel, lo habitual son 18-36 meses. Los programas de primer nivel se alargan de tres a siete años por el tamaño de cartera, la complejidad regulatoria y la cantidad de sistemas alrededor que hay que recablear. Los bancos digitales greenfield lanzan en 4-12 meses. La vía más rápida para una marca nueva es operar sobre un core moderno desde el día uno en lugar de migrar un libro existente.
Por cada 1 $ de software de proveedor, añada 2-3 $ de implementación e integración y 1 $ al año de operación. Para un banco mediano suele situarse entre 50 M$ y 200 M$ en una ventana de cinco años. Las plataformas cloud-native y orquestadas comprimen la ratio; los reemplazos de legacy la expanden.
Crassula es la capa de orquestación y de producto que se apoya sobre una licencia bancaria o de EDE y un conjunto de raíles de pago. Aportamos cuentas y libro mayor, programa de tarjetas, enrutado de pagos, orquestación de KYC, front-ends web y móvil en white-label y una consola de administración. Usted conecta su propia entidad licenciada o uno de nuestros partners de BaaS y sale a mercado con producto de marca en semanas. Somos complementarios a los grandes cores de proveedor, no un sustituto directo de Temenos o Thought Machine en un banco de primer nivel.
No. Un sistema de core bancario es el software que hace funcionar al banco. Banking-as-a-Service es un modelo comercial por el que un banco licenciado expone sus capacidades reguladas vía API para que entidades no bancarias las embeban. BaaS casi siempre se monta sobre un core moderno, pero son conceptos distintos. Vea nuestra guía de BaaS para el cuadro completo.
Un core completo cubre: libro mayor (partida doble, saldos en tiempo real), motor de producto (cuentas, préstamos, depósitos, tarjetas como plantillas configurables), hub de pagos (SEPA, SWIFT, raíles locales como Bizum o SPEI), gestión de clientes y terceros, motor de intereses y comisiones, límites y controles, hooks de AML/monitorización transaccional, reporting regulatorio (Banco de España, BCE) y capa de extractos y notificaciones. Los cores modernos exponen todo esto por API en lugar de empaquetarlo en un monolito cerrado.
Por segmento de clientes: cores minoristas (alto volumen transaccional, producto simple), cores corporativos (crédito complejo, cash pooling multiempresa) y cores universales (ambos, como los que usan Santander o BBVA). Por modelo de despliegue: on-premises (cliente gestiona infraestructura), hosted/nube privada (proveedor gestiona, entorno dedicado) y SaaS (completamente multitenencia, suscripción). Por arquitectura: legacy (monolito, procesamiento batch), incumbente modernizado (re-plataformado pero aún acoplado) y cloud-native (microservicios, orientado a eventos, tiempo real). En LATAM, Pismo es un ejemplo relevante de core cloud-native con fuerte implantación en Brasil.
Otras guías
Crea un banco digital en cuestión de días
Solicita una demo