Pismo: Core Banking Cloud-Native y Procesamiento para Emisores

Modernizar la infraestructura financiera rara vez consiste en reemplazar un sistema por otro. Los bancos y las instituciones financieras suelen operar sobre décadas de tecnología acumulada, que incluye plataformas de core banking, procesadores de pagos, sistemas antifraude, canales de atención al cliente, plataformas de datos, aplicaciones regulatorias e integraciones con terceros. Por eso, un cambio en el core puede afectar a casi todas las capas que lo rodean.

Pismo fue diseñada para este tipo de entorno.

Pismo es una plataforma tecnológica de servicios financieros cloud-native, enfocada en core banking, emisión de tarjetas, pagos y capacidades de procesamiento relacionadas. Su arquitectura orientada a APIs permite a las instituciones financieras conectar estas capacidades con aplicaciones para clientes, servicios de pago, plataformas de socios y otros componentes de su stack tecnológico.

La arquitectura orientada a APIs de Pismo también puede respaldar un modelo de headless banking, en el que las capacidades bancarias y de pagos operan detrás de APIs, mientras que las experiencias orientadas al cliente se desarrollan por separado.

Para bancos y fintechs, esta separación puede habilitar distintos canales, productos, marcas y experiencias de embedded finance (finanzas embebidas) a partir de las mismas capacidades de back-end. También exige prestar mayor atención a la gobernanza de APIs, la seguridad, la propiedad de los datos, la observabilidad, la integración y la resiliencia operativa.

Este artículo analiza Pismo desde esa perspectiva arquitectónica. Explora dónde encaja la plataforma dentro de un stack bancario moderno, cómo se relacionan el core banking y el procesamiento para emisores, qué implica una arquitectura orientada a APIs para la integración y cómo Pismo puede formar parte de una estrategia más amplia de modernización de sistemas heredados.

Pismo pasó a formar parte de Visa en enero de 2024. Visa posicionó la adquisición en torno a las capacidades cloud-native de Pismo en core banking y procesamiento para emisores, así como a su enfoque basado en APIs para la infraestructura financiera.

El Rol de Pismo en la Infraestructura Bancaria Moderna

Pismo abarca varias áreas del stack tecnológico de servicios financieros que, tradicionalmente, se gestionaban mediante sistemas separados o plataformas fuertemente acopladas.

En el nivel del core banking, la plataforma ofrece capacidades como cuentas, ledgers (libros mayores), transacciones, depósitos, ahorros, sobregiros y otros productos financieros. Sus capacidades de procesamiento para emisores abarcan productos de tarjetas y la infraestructura de procesamiento relacionada.

Esta combinación es relevante porque los productos financieros modernos rara vez operan de forma aislada. Una cuenta digital puede interactuar, dentro de un mismo flujo transaccional, con un programa de tarjetas, un motor antifraude, una red de pagos, un proveedor de identidad, una aplicación móvil, un sistema de reportes y una plataforma de datos.

Una plataforma orientada a APIs ofrece a los equipos de arquitectura una forma estructurada de conectar estas capacidades y definir dónde debe ubicarse cada responsabilidad.

Un entorno basado en Pismo puede incluir:

• Infraestructura cloud-native para servicios financieros;
• Capacidades de core banking;
• Procesamiento para emisores;
• APIs e integraciones orientadas a eventos;
• Servicios bancarios modulares;
• Productos digitales y canales de atención al cliente;
• Servicios externos de pagos y financieros;
• Plataformas de fraude y riesgo;
• Servicios de identidad y autenticación;
• Plataformas de datos y monitoreo.

La arquitectura resultante depende de cómo se implementen y gobiernen estos componentes. El diseño de las integraciones, la migración de datos, la preparación operativa y la definición de responsables influyen en la confiabilidad y en los costos operativos a largo plazo.

Los Desafíos Bancarios que Pismo Busca Resolver

Muchas iniciativas de modernización del core comienzan con restricciones que se han acumulado con el tiempo.

Un core heredado puede requerir una amplia coordinación para lanzar un nuevo producto. Los procesos basados en lotes (batch) pueden limitar la rapidez con la que la información llega a los sistemas dependientes. Las aplicaciones para clientes pueden depender de detalles de implementación del back-end, lo que dificulta liberar cambios en las experiencias digitales.

La complejidad de integración es otro problema frecuente. A medida que los bancos incorporan canales, productos, socios y servicios especializados, las conexiones punto a punto pueden volverse difíciles de mantener y monitorear.

Entre los desafíos más comunes se encuentran:

• Lanzamientos de productos lentos, causados por dependencias dentro del core;
• Plataformas heredadas rígidas y con poca flexibilidad;
• Sistemas de front-end y back-end fuertemente acoplados;
• Integraciones complejas entre aplicaciones bancarias y de pagos;
• Dependencia del procesamiento por lotes en procesos de los que se espera, cada vez más, una operación en tiempo real;
• Dificultad para exponer funcionalidades del core mediante APIs modernas;
• Altos costos asociados a los cambios en las funcionalidades del core;
• Complejidad creciente al incorporar productos, marcas o canales.

El posicionamiento de Pismo aborda varias de estas restricciones arquitectónicas mediante infraestructura cloud-native, APIs, capacidades modulares y soporte para el procesamiento en tiempo real.

Para una institución que evalúa la plataforma, el paso clave es contrastar esas capacidades con su propio entorno tecnológico. Las dependencias existentes, las estructuras de datos, los patrones de integración y los requisitos operativos determinarán dónde Pismo puede generar valor y dónde será necesario un trabajo adicional de arquitectura.

Arquitectura Headless en el Contexto de Pismo

La arquitectura headless separa los sistemas responsables de las capacidades centrales de las interfaces a través de las cuales los usuarios acceden a ellas.

En banca, esto puede significar exponer la gestión de cuentas, las transacciones, los servicios de tarjetas y otras capacidades financieras mediante APIs, mientras que las aplicaciones web, las aplicaciones móviles, los canales de socios, las experiencias de embedded finance y las herramientas internas consumen esos servicios de forma independiente.

El modelo orientado a APIs de Pismo ofrece un contexto útil para este enfoque. Su documentación para desarrolladores expone APIs para capacidades bancarias, de tarjetas y de pagos, lo que permite que las aplicaciones interactúen con los servicios de back-end mediante interfaces bien definidas.

Para una explicación más amplia de este principio arquitectónico, consulte Arquitectura Headless.

Un modelo simplificado se vería así:

Canales de atención al cliente → capa de APIs → orquestación y servicios de negocio → Pismo → redes de pago y servicios financieros externos

Las plataformas de fraude, identidad, datos, monitoreo y otras plataformas especializadas pueden operar alrededor de este flujo, según los requisitos de cada institución.

Esta arquitectura crea límites claros entre las capas, pero esos límites necesitan gobernanza. Los equipos deben definir la propiedad de los servicios, la gestión del ciclo de vida de las APIs, los controles de seguridad, el manejo de fallas y el monitoreo entre los sistemas dependientes.

Separación entre las Capacidades Centrales y la Experiencia del Cliente

Pismo proporciona la infraestructura bancaria y de pagos, mientras que las experiencias orientadas al cliente pueden mantenerse separadas de esos servicios centrales.

De este modo, un banco o una fintech puede construir distintas experiencias sobre capacidades compartidas. Una aplicación de banca móvil, una interfaz para socios, un producto de embedded finance y una herramienta de operaciones internas pueden consumir los mismos servicios subyacentes, manteniendo modelos de interacción y design systems diferentes.

Este modelo puede habilitar:

• Mayor libertad en el diseño de productos digitales;
• Múltiples experiencias del cliente sobre capacidades bancarias compartidas;
• Evolución independiente de los canales digitales;
• Menor dependencia entre las entregas de front-end y la lógica del core;
• Reutilización de capacidades bancarias entre aplicaciones.

Esta flexibilidad implica responsabilidades adicionales de integración. Los contratos de API deben mantenerse confiables, la autenticación y la autorización deben ser consistentes, y los equipos necesitan procesos definidos para el versionado, el monitoreo, la respuesta a incidentes y la propiedad de los servicios.

Para las organizaciones con varios canales de atención o productos orientados a socios, estas responsabilidades pasan a formar parte del modelo operativo.

Valor de Negocio de una Arquitectura Bancaria Desacoplada

Las implicaciones de negocio del desacoplamiento se vuelven más claras cuando se analizan desde la perspectiva del ciclo de vida del producto.

Cuando un canal de atención depende directamente de una implementación específica del core, un cambio en la experiencia puede requerir coordinación entre varios equipos y sistemas. Las interfaces de servicio bien definidas pueden reducir parte de esas dependencias y dar a los equipos límites más claros.

Entre los posibles resultados se encuentran:

• Evolución más rápida de los canales digitales;
• Mayor facilidad para experimentar con nuevas experiencias del cliente;
• Menor dependencia del front-end respecto de los detalles de implementación del core;
• APIs reutilizables entre productos y canales;
• Soporte para múltiples marcas y productos financieros;
• Integración con experiencias de socios y de embedded finance;
• Límites más claros entre la experiencia del cliente y el procesamiento de transacciones.

Para sostener estos beneficios, la arquitectura necesita una gobernanza de APIs consistente. Las interfaces mal gestionadas pueden convertirse en una fuente de deuda técnica cuando varias aplicaciones dependen de contratos inestables o de servicios sin responsables claramente definidos.

Por lo tanto, un entorno bancario desacoplado requiere gestión del ciclo de vida de las APIs, observabilidad, propiedad de los servicios, pruebas de integración, controles de seguridad y procesos de gobernanza bien definidos.

Pismo en un Stack Bancario Moderno

Pismo puede operar como parte de una arquitectura bancaria más amplia, en la que el core banking y el procesamiento para emisores se conectan con los canales de atención, la orquestación, la seguridad, los pagos, las plataformas de datos y los servicios financieros especializados.

El diseño exacto depende de los productos y de la infraestructura existente de cada institución. Un banco que moderniza un core con décadas de antigüedad puede necesitar varios adaptadores y capas de coexistencia. En cambio, una institución nativa digital puede tener menos dependencias heredadas, pero una mayor cantidad de servicios distribuidos y APIs externas.

Esto convierte la ubicación de las capacidades en una decisión arquitectónica importante: ¿qué funciones deben pertenecer al core y cuáles deben mantenerse como servicios a su alrededor?

Capacidades que Deben Permanecer Fuera del Core

Las plataformas de core banking son responsables de las capacidades financieras fundamentales. Otras funciones a menudo pueden gestionarse de forma más eficaz mediante sistemas especializados, con ciclos de entrega y modelos de responsabilidad diferentes.

Algunos ejemplos:

• Experiencia del cliente;
• Analytics;
• CRM;
• Decisiones antifraude;
• Gestión de identidades y accesos;
• Orquestación;
• Marketing;
• Servicios especializados de terceros.

Mantener estas capacidades fuera del core puede evitar que la plataforma bancaria acumule responsabilidades que se gestionarían mejor en otro lugar.

Las decisiones antifraude, por ejemplo, pueden depender de modelos especializados y de inteligencia externa. Las plataformas de CRM tienen sus propias estructuras de datos de clientes y sus propios flujos de trabajo. Los sistemas de marketing requieren capacidades de gestión de campañas y audiencias que tienen poca relación con el procesamiento de transacciones.

Cada separación crea un punto de integración. Por eso, los contratos de datos, los controles de seguridad, las expectativas de latencia, el manejo de fallas y las responsabilidades deben definirse para toda la arquitectura circundante.

APIs y Componibilidad en la Arquitectura Bancaria

Las APIs son centrales en la arquitectura de Pismo. El Pismo Developers Portal ofrece APIs REST en áreas como cuentas, tarjetas, transacciones, pagos, controles y estados de cuenta.

Para las instituciones financieras, el valor arquitectónico está en la forma en que estas interfaces permiten combinar capacidades bancarias entre distintas aplicaciones y servicios.

Un diseño orientado a APIs establece límites entre los servicios y las aplicaciones que los consumen. Una aplicación móvil, una plataforma de socios o un sistema interno puede solicitar una capacidad bancaria específica sin reproducir la lógica de procesamiento subyacente.

Esto favorece la componibilidad en:

• Límites entre servicios;
• Capacidades bancarias reutilizables;
• Canales externos de atención al cliente;
• Integraciones con socios;
• Experiencias de embedded finance;
• Servicios de pago;
• Aplicaciones internas.

A escala empresarial, la componibilidad requiere estándares técnicos consistentes. Entre los aspectos importantes se encuentran:

• Versionado de APIs;
• Autenticación y autorización;
• Estabilidad de los contratos;
• Gobernanza de APIs;
• Observabilidad;
• Control de tasa de solicitudes (rate limiting);
• Manejo de errores;
• Gestión del ciclo de vida y de la deprecación de APIs.

El diseño de las APIs también debe considerar cómo se comportan las transacciones financieras ante una falla. Que un servicio devuelva un error no significa necesariamente que la transacción no se haya realizado. Esa distinción hace que la idempotencia, la conciliación, el manejo de eventos y el monitoreo operativo sean especialmente importantes en entornos bancarios.

Responsabilidades de Integración en un Entorno API-First

Una plataforma API-first sigue requiriendo una ingeniería de integración disciplinada.

Un banco que incorpora Pismo puede necesitar mapear datos de clientes, cuentas, productos, transacciones y datos de referencia hacia nuevas estructuras. También puede necesitar orquestar flujos de trabajo entre Pismo y los sistemas responsables de identidad, fraude, pagos, reportes, cumplimiento normativo o comunicaciones con clientes.

Las principales responsabilidades incluyen:

• Mapeo de datos;
• Orquestación de flujos de trabajo y procesos;
• Manejo de errores;
• Seguridad;
• Estrategias de reintento (retry);
• Conciliación;
• Secuenciación de eventos;
• Adaptadores para sistemas heredados;
• Monitoreo;
• Definición de responsables de las integraciones.

Considere una transacción que pasa por varios sistemas. El core puede procesar la transacción mientras un servicio antifraude evalúa el riesgo, una red de pagos gestiona la autorización, los sistemas dependientes actualizan sus registros y las plataformas de reportes consumen los datos resultantes.

Una falla en cualquier punto de esa cadena puede generar consecuencias operativas.

Por eso, la arquitectura de integración debe diseñarse junto con la arquitectura objetivo del core. Las APIs proporcionan las interfaces, mientras que el diseño circundante determina cómo la institución gestiona la consistencia de los datos, los reintentos, la conciliación, las fallas y las responsabilidades.

Modernización del Core Banking y Caminos de Migración

La modernización del core banking es una iniciativa arquitectónica de gran envergadura, porque el core sostiene una gran cantidad de productos y procesos.

Una migración a Pismo no tiene por qué realizarse necesariamente en un único corte (cutover). Según el entorno, una institución puede migrar capacidades, productos o segmentos de clientes seleccionados, manteniendo una coexistencia controlada con los sistemas heredados.

Los materiales de Pismo describen soporte para la migración y un enfoque híbrido para las instituciones en transición desde entornos heredados.

Una estrategia de migración debe considerar:

• Reemplazo de capacidades seleccionadas del core;
• Coexistencia con sistemas heredados;
• Migración producto por producto;
• Migración por segmento de clientes;
• Modernización por fases;
• Migración de datos;
• Conciliación;
• Capas de abstracción;
• Planificación de rollback y contingencia;
• Dependencias de las aplicaciones circundantes.

La separación arquitectónica también puede ayudar durante la transición. El artículo Arquitectura Headless ofrece más contexto sobre cómo separar las interfaces de los servicios subyacentes puede reducir dependencias durante la modernización.

Reemplazo del Core versus Modernización Progresiva

Existen distintas formas de abordar la modernización del core.

Un reemplazo completo puede ser adecuado cuando las limitaciones técnicas de la plataforma actual, los costos operativos, las restricciones del proveedor o el roadmap de productos hacen necesaria una transformación más amplia.

La modernización progresiva puede ser útil cuando una institución necesita controlar la cantidad de cambios simultáneos o mantener los productos existentes durante la transición.

Un programa por fases puede incluir:

• Migrar primero productos seleccionados;
• Migrar segmentos específicos de clientes;
• Incorporar nuevas capacidades en paralelo a las existentes;
• Crear capas de abstracción entre las aplicaciones y los sistemas core;
• Redirigir gradualmente las cargas de trabajo;
• Retirar los componentes heredados una vez que sus cargas de trabajo hayan sido migradas.

El enfoque adecuado depende del entorno. Las dependencias de datos, los requisitos regulatorios, los volúmenes de transacciones, la complejidad de los productos y la cantidad de sistemas conectados influyen en el alcance.

La arquitectura de transición también necesita un plan explícito de retiro. Las interfaces temporales, los mecanismos de sincronización y los adaptadores para sistemas heredados pueden permanecer en producción mucho más tiempo de lo previsto cuando su eliminación no está incluida en el roadmap de migración.

La Coexistencia con Sistemas Heredados como Desafío de Integración

Los bancos rara vez tienen la opción de reemplazar todos los sistemas dependientes al mismo tiempo.

Un nuevo core puede necesitar coexistir con:

• Aplicaciones circundantes;
• Data warehouses;
• Procesadores de pagos;
• Plataformas antifraude;
• Sistemas de reportes;
• Sistemas regulatorios;
• Canales de atención al cliente.

Durante la coexistencia, dos sistemas pueden contener temporalmente información relacionada o participar en el mismo proceso de negocio. Esto plantea de inmediato preguntas sobre cuál es la fuente de verdad, la sincronización, la conciliación, la secuenciación de eventos y la recuperación ante fallas.

Por ejemplo, si un cambio en una cuenta ocurre en un sistema mientras una aplicación dependiente todavía utiliza la fuente heredada, la arquitectura de migración debe determinar cómo llega ese cambio al entorno dependiente y qué sistema sigue siendo la referencia oficial.

Ejecutar determinados procesos en paralelo en ambos sistemas puede aportar una validación adicional, pero también aumenta la carga operativa. Los equipos necesitan reglas claras para comparar resultados, investigar discrepancias, gestionar excepciones y definir cuándo se pueden retirar las funcionalidades heredadas.

Por lo tanto, una arquitectura de coexistencia controlada puede convertirse en uno de los componentes más importantes de una migración de core.

Procesamiento para Emisores en la Plataforma Pismo

El procesamiento para emisores es una capacidad distinta que complementa al core banking.

Pismo ofrece capacidades de emisión y procesamiento de tarjetas para productos como tarjetas de crédito, débito, prepago y private label, incluidas experiencias con tarjetas físicas y virtuales.

Para las instituciones que lanzan o modernizan productos de tarjetas, el procesamiento para emisores abarca la infraestructura necesaria para configurar y operar programas de tarjetas y procesar las transacciones asociadas. También puede interactuar con servicios de fraude, riesgo, redes de pago y otros servicios especializados.

La conexión con el core banking cobra importancia cuando las transacciones con tarjeta afectan cuentas, saldos, límites, estados de cuenta u otros registros financieros subyacentes.

Core Banking y Procesamiento para Emisores Cumplen Roles Diferentes

El core banking proporciona la infraestructura fundamental para las cuentas y los productos financieros.

Core banking:

• Gestiona cuentas y saldos;
• Administra ledgers y registros financieros;
• Procesa transacciones a nivel de cuenta;
• Soporta productos como depósitos, ahorros, préstamos y sobregiros;
• Proporciona las capacidades bancarias fundamentales.

Procesamiento para emisores:

• Habilita la emisión de tarjetas de pago;
• Gestiona programas y configuraciones de tarjetas;
• Procesa las transacciones relacionadas con tarjetas;
• Soporta productos de tarjetas digitales y físicas;
• Conecta los programas de tarjetas con las redes de pago y los servicios relacionados.

Estas capacidades se cruzan porque una transacción con tarjeta puede afectar una cuenta o un producto financiero subyacente. Mantener las responsabilidades bien diferenciadas ayuda a los equipos de arquitectura a determinar qué sistema debe ser responsable de cada proceso y qué datos deben circular entre ellos.

Fundamentos Cloud-Native para Escala y Resiliencia

La arquitectura cloud-native de Pismo influye en la forma en que sus capacidades bancarias y de procesamiento pueden implementarse, escalarse, integrarse y operarse.

Para las instituciones financieras, las características relevantes incluyen:

• Escalabilidad elástica;
• Servicios distribuidos;
• Independencia de despliegue;
• Disponibilidad de las APIs;
• Expansión geográfica;
• Iteración más rápida de productos;
• Abstracción de la infraestructura;
• Resiliencia operativa.

Estas características pueden apoyar a instituciones que operan con múltiples productos y mercados, sobre todo cuando los volúmenes de transacciones, los canales digitales y los requisitos de integración cambian con el tiempo.

La arquitectura cloud-native también puede incidir en la gestión de releases. Contar con más servicios desplegables de forma independiente permite a los equipos evolucionar capacidades específicas sin tener que coordinar cada cambio a través de una única aplicación de gran tamaño.

Aun así, la infraestructura financiera requiere prácticas rigurosas de confiabilidad. Las fallas de red, las caídas de dependencias, los incidentes de seguridad, las inconsistencias de datos y la disponibilidad de los sistemas dependientes deben abordarse mediante la arquitectura y los procesos operativos.

Responsabilidades Operativas en un Entorno Cloud-Native

Llevar la infraestructura bancaria a la nube cambia la forma en que los equipos operan la plataforma.

Las instituciones siguen necesitando controles sólidos en:

• Observabilidad;
• Seguridad;
• Monitoreo de las integraciones;
• Gestión de incidentes;
• Gobernanza de datos;
• Gestión de dependencias;
• Planificación de recuperación ante desastres.

La observabilidad cobra especial importancia en las arquitecturas distribuidas. Una transacción puede atravesar varios servicios antes de completarse; por eso, los equipos de operaciones necesitan telemetría suficiente para identificar dónde ocurrió un problema y comprender sus efectos en los sistemas dependientes.

La gobernanza de datos sigue siendo igual de importante. La infraestructura en la nube no define quién es el responsable de un dato, qué sistema puede modificarlo, durante cuánto tiempo debe conservarse ni cómo deben conciliarse los cambios.

Por lo tanto, para los líderes de tecnología, evaluar una plataforma cloud-native implica analizar tanto el modelo operativo como la propia infraestructura.

La Expansión de Pismo en el Ecosistema de Visa

La adquisición de Pismo por parte de Visa estableció una relación tecnológica más amplia entre ambas compañías. Visa completó la adquisición en enero de 2024 y posicionó a Pismo como una plataforma cloud-native de procesamiento para emisores y core banking.

En 2026, Visa informó que Pismo había ingresado a 19 nuevos mercados desde la adquisición. Visa también destacó la demanda de procesamiento para emisores y core banking, y subrayó el papel de Pismo en ayudar a las instituciones financieras a migrar sus plataformas de core banking a la nube.

La cifra de 19 mercados es una métrica de expansión reportada por Visa. Por lo tanto, debe entenderse como información reportada por la propia compañía y no como una medida independiente de la penetración de mercado de Pismo.

Desde una perspectiva arquitectónica, la expansión geográfica introduce requisitos adicionales relacionados con esquemas de pago, monedas, marcos regulatorios, configuraciones de productos y modelos operativos locales.

Visa también destacó el soporte de Pismo para múltiples rieles de pago y tipos de producto, incluido Pix en Brasil.

Para un contexto más amplio, conozca el ecosistema tecnológico de Visa.

Las relaciones corporativas pueden aportar un contexto útil al evaluar una plataforma, pero los anuncios públicos rara vez ofrecen información suficiente para determinar el alcance de la migración, los plazos de implementación, las mejoras de rendimiento, el ROI o los detalles de la arquitectura interna.

Esos factores deben evaluarse en función de los requisitos técnicos y de negocio específicos de cada institución.

Marco de Evaluación para Entornos Bancarios Heredados

Los líderes de tecnología que evalúan Pismo deben comenzar por la arquitectura actual de la institución y por el modelo operativo objetivo.

La evaluación debe abarcar:

• Restricciones actuales del core;
• Arquitectura de integración;
• Complejidad de la migración de datos;
• Madurez en APIs;
• Necesidades de procesamiento para emisores;
• Roadmap de productos;
• Requisitos de cumplimiento normativo;
• Requisitos geográficos;
• Expectativas de disponibilidad;
• Preparación organizacional;
• Cambios en el modelo operativo.

La adecuación técnica y la viabilidad de la migración también deben evaluarse por separado. Una plataforma puede cumplir con los requisitos funcionales y, aun así, el entorno existente puede presentar una complejidad de migración significativa.

Una evaluación estructurada ayuda a identificar esas dependencias antes de iniciar la implementación.

Preguntas de Arquitectura que Responder Antes de la Migración

Antes de definir un camino de migración, los equipos de arquitectura y de negocio deben tener respuestas claras a preguntas como:

• ¿Qué sistema seguirá siendo la fuente de verdad durante la transición?
• ¿Qué productos o segmentos de clientes deben migrarse primero?
• ¿Cómo se migrarán los datos de clientes y de cuentas?
• ¿Cómo funcionará la ejecución en paralelo (dual-run) o la coexistencia?
• ¿Qué integraciones heredadas deben permanecer activas?
• ¿Cómo se gestionará la conciliación?
• ¿Cuál es la estrategia de rollback?
• ¿Cómo se gobernarán las APIs?
• ¿Cómo detectarán y gestionarán los cambios los sistemas dependientes?

Estas preguntas suelen revelar dependencias que pasan desapercibidas en un diagrama de arquitectura de alto nivel.

Una aplicación para clientes puede parecer independiente del core, por ejemplo, y aun así depender de estructuras de bases de datos heredadas. Un sistema de reportes también puede tener dependencias ocultas de determinados eventos de transacción o de formatos de datos históricos.

Por eso, la planificación de la migración debe abarcar, en conjunto, las dependencias de aplicaciones, datos, integraciones y operaciones.

Riesgos de Migración e Implementación

Los riesgos de la modernización del core suelen surgir en los límites entre sistemas.

Las áreas más comunes incluyen:

• Mapeo incompleto de dependencias;
• Fallas en la migración de datos;
• Transacciones duplicadas;
• Fallas de conciliación;
• Incompatibilidad con sistemas dependientes;
• Cambios en los contratos de API;
• Preparación operativa;
• Observabilidad insuficiente;
• Configuración de seguridad;
• Limitaciones de rollback.

Algunos controles pueden ayudar a reducir estos riesgos:

• Mantener un inventario completo de dependencias;
• Adoptar una migración por fases cuando sea apropiado;
• Realizar validaciones en paralelo cuando la arquitectura lo permita;
• Implementar pruebas de contrato;
• Establecer controles de conciliación;
• Realizar pruebas de rendimiento en un entorno similar al de producción;
• Definir procedimientos de rollback antes del corte;
• Implementar la observabilidad antes de la migración a producción;
• Asignar responsables claros para cada dependencia crítica.

Estos controles cobran especial importancia cuando el nuevo core forma parte de un entorno distribuido. Una migración puede funcionar correctamente en el nivel del core y, aun así, provocar fallas en los sistemas dependientes si el flujo de extremo a extremo no ha sido probado.

Métricas de Éxito de la Modernización

Los programas de modernización necesitan líneas base (baselines) medibles.

Entre las métricas útiles se encuentran:

• Lead time de lanzamiento de productos;
• Frecuencia de releases;
• Disponibilidad de las APIs;
• Tasa de incidentes de integración;
• Latencia de procesamiento;
• Excepciones de conciliación;
• Esfuerzo de soporte operativo;
• Tiempo necesario para integrar un nuevo canal;
• Costo del cambio;
• Tasa de defectos en la migración.

Siempre que sea posible, las líneas base deben registrarse antes de la migración. Sin ellas, resulta difícil demostrar si la nueva arquitectura mejoró el desempeño operativo.

Las métricas también deben reflejar los objetivos específicos del programa. Un banco enfocado en la velocidad de producto puede priorizar el lead time de lanzamiento y la frecuencia de releases. En cambio, una migración centrada en la estabilidad operativa puede dar más peso a los incidentes, las excepciones de conciliación, la disponibilidad y el esfuerzo de soporte.

No deben asumirse benchmarks específicos de Pismo sin evidencia publicada. La comparación más confiable es entre la línea base de la propia institución y los resultados medidos después de la implementación.

Preguntas Frecuentes

Evaluando el Rol de Pismo en la Infraestructura Bancaria Moderna

Pismo reúne capacidades de core banking y de procesamiento para emisores en una arquitectura cloud-native y orientada a APIs, que puede conectarse con distintos canales de atención, servicios de pago, plataformas de socios y sistemas financieros especializados.

Para las instituciones que modernizan entornos heredados, la pregunta práctica es cómo encajan esas capacidades en la arquitectura existente y en el modelo operativo objetivo. La migración de datos, la coexistencia con sistemas heredados, el diseño de las integraciones, la conciliación, la observabilidad, la seguridad y la responsabilidad operativa pueden influir en el camino de implementación.

La posición de Pismo dentro de Visa añade otra dimensión a esta evaluación, a medida que Visa amplía sus capacidades tecnológicas más allá del modelo tradicional de red de tarjetas.

Por lo tanto, para los líderes de tecnología, evaluar Pismo implica conectar las capacidades de la plataforma con el entorno actual de la institución, sus objetivos de modernización, su roadmap de migración y sus requisitos operativos.

Para entender cómo encaja Pismo en la estrategia más amplia de infraestructura financiera de Visa, conozca el ecosistema tecnológico de Visa.