Pismo: Core Banking Cloud-Native e Processamento para Emissores

Modernizar a infraestrutura financeira raramente é uma questão de trocar um sistema por outro. Bancos e instituições financeiras costumam operar sobre décadas de tecnologia acumulada, incluindo plataformas de core banking, processadores de pagamento, sistemas antifraude, canais de atendimento ao cliente, plataformas de dados, aplicações regulatórias e integrações com terceiros. Por isso, uma mudança no core pode afetar praticamente todas as camadas ao seu redor.

A Pismo foi projetada para esse tipo de ambiente.

A Pismo é uma plataforma de tecnologia para serviços financeiros cloud-native, com foco em core banking, emissão de cartões, pagamentos e capacidades de processamento relacionadas. Sua arquitetura orientada por APIs permite que instituições financeiras conectem essas capacidades a aplicações para clientes, serviços de pagamento, plataformas de parceiros e outros componentes do seu stack tecnológico.

A arquitetura orientada por APIs da Pismo também pode sustentar um modelo de headless banking, no qual as capacidades bancárias e de pagamentos operam por trás de APIs, enquanto as experiências voltadas ao cliente são desenvolvidas separadamente.

Para bancos e fintechs, essa separação pode viabilizar diferentes canais, produtos, marcas e experiências de embedded finance (finanças embarcadas) a partir das mesmas capacidades de back-end. Ela também exige mais atenção à governança de APIs, segurança, propriedade dos dados, observabilidade, integração e resiliência operacional.

Este artigo analisa a Pismo sob essa perspectiva arquitetural. Ele explora onde a plataforma se encaixa em um stack bancário moderno, como core banking e processamento para emissores se relacionam, o que uma arquitetura orientada por APIs significa para a integração e como a Pismo pode fazer parte de uma estratégia mais ampla de modernização de sistemas legados.

A Pismo passou a fazer parte da Visa em janeiro de 2024. A Visa posicionou a aquisição com base nas capacidades cloud-native da Pismo em core banking e processamento para emissores, bem como em sua abordagem baseada em APIs para a infraestrutura financeira.

O Papel da Pismo na Infraestrutura Bancária Moderna

A Pismo atua em diversas áreas do stack tecnológico de serviços financeiros que, tradicionalmente, eram atendidas por sistemas separados ou por plataformas fortemente acopladas.

No nível do core banking, a plataforma oferece capacidades como contas, ledgers (razões contábeis), transações, depósitos, poupança, cheque especial e outros produtos financeiros. Já suas capacidades de processamento para emissores abrangem produtos de cartão e a infraestrutura de processamento relacionada.

Essa combinação é relevante porque produtos financeiros modernos raramente operam de forma isolada. Uma conta digital pode interagir, dentro de um mesmo fluxo transacional, com um programa de cartões, um motor antifraude, uma rede de pagamentos, um provedor de identidade, um aplicativo móvel, um sistema de relatórios e uma plataforma de dados.

Uma plataforma orientada por APIs oferece às equipes de arquitetura uma forma estruturada de conectar essas capacidades e definir onde cada responsabilidade deve ficar.

Um ambiente baseado na Pismo pode envolver:

• Infraestrutura cloud-native para serviços financeiros;
• Capacidades de core banking;
• Processamento para emissores;
• APIs e integrações orientadas a eventos;
• Serviços bancários modulares;
• Produtos digitais e canais de atendimento ao cliente;
• Serviços externos de pagamento e financeiros;
• Plataformas de fraude e risco;
• Serviços de identidade e autenticação;
• Plataformas de dados e monitoramento.

A arquitetura resultante depende de como esses componentes são implementados e governados. O design das integrações, a migração de dados, a prontidão operacional e a definição de responsáveis influenciam a confiabilidade e os custos operacionais de longo prazo.

Os Desafios Bancários que a Pismo Foi Projetada para Resolver

Muitas iniciativas de modernização do core começam com restrições acumuladas ao longo do tempo.

Um core legado pode exigir uma ampla coordenação para lançar um novo produto. Processos baseados em lote (batch) podem limitar a velocidade com que as informações chegam aos sistemas dependentes. Aplicações voltadas ao cliente podem depender de detalhes de implementação do back-end, o que torna mais difícil liberar mudanças nas experiências digitais.

A complexidade de integração é outro problema comum. À medida que os bancos adicionam canais, produtos, parceiros e serviços especializados, as conexões ponto a ponto podem se tornar difíceis de manter e monitorar.

Os desafios mais comuns incluem:

• Lançamentos de produtos lentos, causados por dependências dentro do core;
• Plataformas legadas rígidas e com pouca flexibilidade;
• Sistemas de front-end e back-end fortemente acoplados;
• Integrações complexas entre aplicações bancárias e de pagamentos;
• Dependência de processamento em lote para processos dos quais se espera, cada vez mais, operação em tempo real;
• Dificuldade em expor funcionalidades do core por meio de APIs modernas;
• Altos custos associados a mudanças nas funcionalidades do core;
• Complexidade crescente ao adicionar produtos, marcas ou canais.

O posicionamento da Pismo endereça várias dessas restrições arquiteturais por meio de infraestrutura cloud-native, APIs, capacidades modulares e suporte ao processamento em tempo real.

Para uma instituição que está avaliando a plataforma, o passo-chave é mapear essas capacidades em relação ao seu próprio ambiente tecnológico. As dependências existentes, as estruturas de dados, os padrões de integração e os requisitos operacionais vão determinar onde a Pismo pode gerar valor e onde será necessário um trabalho adicional de arquitetura.

Arquitetura Headless no Contexto da Pismo

A arquitetura headless separa os sistemas responsáveis pelas capacidades centrais das interfaces por meio das quais os usuários acessam essas capacidades.

No setor bancário, isso pode significar expor gestão de contas, transações, serviços de cartões e outras capacidades financeiras por meio de APIs, enquanto aplicações web, aplicativos móveis, canais de parceiros, experiências de embedded finance e ferramentas internas consomem esses serviços de forma independente.

O modelo orientado por APIs da Pismo oferece um contexto útil para essa abordagem. Sua documentação para desenvolvedores disponibiliza APIs para capacidades bancárias, de cartões e de pagamentos, permitindo que as aplicações interajam com os serviços de back-end por meio de interfaces bem definidas.

Para uma explicação mais ampla do princípio arquitetural, veja Arquitetura Headless.

Um modelo simplificado seria assim:

Canais de atendimento ao cliente → camada de APIs → orquestração e serviços de negócio → Pismo → redes de pagamento e serviços financeiros externos

Plataformas de fraude, identidade, dados, monitoramento e outras plataformas especializadas podem operar em torno desse fluxo, de acordo com os requisitos de cada instituição.

Essa arquitetura cria limites claros entre as camadas, mas esses limites precisam de governança. As equipes devem definir a propriedade dos serviços, a gestão do ciclo de vida das APIs, os controles de segurança, o tratamento de falhas e o monitoramento entre os sistemas dependentes.

Separação entre Capacidades Centrais e Experiência do Cliente

A Pismo fornece a infraestrutura bancária e de pagamentos, enquanto as experiências voltadas ao cliente podem permanecer separadas desses serviços centrais.

Assim, um banco ou fintech pode construir diferentes experiências sobre capacidades compartilhadas. Um aplicativo de mobile banking, uma interface para parceiros, um produto de embedded finance e uma ferramenta de operações internas podem consumir os mesmos serviços subjacentes, mantendo modelos de interação e design systems diferentes.

Esse modelo pode viabilizar:

• Mais liberdade no design de produtos digitais;
• Múltiplas experiências do cliente sobre capacidades bancárias compartilhadas;
• Evolução independente dos canais digitais;
• Menor dependência entre as entregas de front-end e a lógica do core;
• Reutilização de capacidades bancárias entre aplicações.

Essa flexibilidade traz responsabilidades adicionais de integração. Os contratos de API precisam se manter confiáveis, a autenticação e a autorização devem ser consistentes, e as equipes precisam de processos definidos para versionamento, monitoramento, resposta a incidentes e propriedade dos serviços.

Para organizações com vários canais de atendimento ou produtos voltados a parceiros, essas responsabilidades passam a fazer parte do modelo operacional.

Valor de Negócio de uma Arquitetura Bancária Desacoplada

As implicações de negócio do desacoplamento ficam mais claras quando observadas sob a ótica do ciclo de vida do produto.

Quando um canal de atendimento depende diretamente de uma implementação específica do core, uma mudança na experiência pode exigir coordenação entre várias equipes e sistemas. Interfaces de serviço bem definidas podem reduzir parte dessas dependências e dar às equipes limites mais claros.

Os resultados possíveis incluem:

• Evolução mais rápida dos canais digitais;
• Mais facilidade para experimentar novas experiências do cliente;
• Menor dependência do front-end em relação aos detalhes de implementação do core;
• APIs reutilizáveis entre produtos e canais;
• Suporte a múltiplas marcas e produtos financeiros;
• Integração com experiências de parceiros e de embedded finance;
• Limites mais claros entre a experiência do cliente e o processamento de transações.

Para sustentar esses benefícios, a arquitetura precisa de uma governança de APIs consistente. Interfaces mal gerenciadas podem se tornar fonte de dívida técnica quando várias aplicações dependem de contratos instáveis ou de serviços sem responsáveis claramente definidos.

Por isso, um ambiente bancário desacoplado exige gestão do ciclo de vida das APIs, observabilidade, propriedade dos serviços, testes de integração, controles de segurança e processos de governança bem definidos.

A Pismo em um Stack Bancário Moderno

A Pismo pode operar como parte de uma arquitetura bancária mais ampla, na qual core banking e processamento para emissores se conectam a canais de atendimento, orquestração, segurança, pagamentos, plataformas de dados e serviços financeiros especializados.

O desenho exato depende dos produtos e da infraestrutura existente de cada instituição. Um banco que está modernizando um core com décadas de uso pode precisar de vários adaptadores e camadas de coexistência. Já uma instituição nativa digital pode ter menos dependências legadas, mas um número maior de serviços distribuídos e APIs externas.

Isso torna o posicionamento das capacidades uma decisão arquitetural importante: quais funções devem pertencer ao core e quais devem permanecer como serviços ao seu redor?

Capacidades que Devem Permanecer Fora do Core

As plataformas de core banking são responsáveis pelas capacidades financeiras fundamentais. Outras funções muitas vezes podem ser tratadas de forma mais eficaz por sistemas especializados, com ciclos de entrega e modelos de responsabilidade diferentes.

Alguns exemplos:

• Experiência do cliente;
• Analytics;
• CRM;
• Decisão antifraude;
• Gestão de identidade e acesso;
• Orquestração;
• Marketing;
• Serviços especializados de terceiros.

Manter essas capacidades fora do core pode evitar que a plataforma bancária acumule responsabilidades que seriam mais bem gerenciadas em outro lugar.

A decisão antifraude, por exemplo, pode depender de modelos especializados e de inteligência externa. As plataformas de CRM têm suas próprias estruturas de dados de clientes e seus próprios fluxos de trabalho. Os sistemas de marketing exigem capacidades de gestão de campanhas e de audiências que têm pouca relação com o processamento de transações.

Cada separação cria um ponto de integração. Por isso, contratos de dados, controles de segurança, expectativas de latência, tratamento de falhas e responsabilidades precisam ser definidos para toda a arquitetura ao redor.

APIs e Composabilidade na Arquitetura Bancária

As APIs são centrais na arquitetura da Pismo. O Pismo Developers Portal oferece APIs REST em áreas como contas, cartões, transações, pagamentos, controles e extratos.

Para as instituições financeiras, o valor arquitetural está na forma como essas interfaces permitem combinar capacidades bancárias entre diferentes aplicações e serviços.

Um design orientado por APIs estabelece limites entre os serviços e as aplicações que os consomem. Um aplicativo móvel, uma plataforma de parceiros ou um sistema interno pode solicitar uma capacidade bancária específica sem reproduzir a lógica de processamento subjacente.

Isso favorece a composabilidade em:

• Limites entre serviços;
• Capacidades bancárias reutilizáveis;
• Canais externos de atendimento ao cliente;
• Integrações com parceiros;
• Experiências de embedded finance;
• Serviços de pagamento;
• Aplicações internas.

Em escala corporativa, a composabilidade exige padrões técnicos consistentes. Entre os pontos de atenção estão:

• Versionamento de APIs;
• Autenticação e autorização;
• Estabilidade dos contratos;
• Governança de APIs;
• Observabilidade;
• Controle de taxa de requisições (rate limiting);
• Tratamento de erros;
• Gestão do ciclo de vida e da descontinuação de APIs.

O design das APIs também precisa considerar como as transações financeiras se comportam em caso de falha. Um serviço que retorna um erro não significa, necessariamente, que a transação não aconteceu. Essa distinção torna a idempotência, a conciliação, o tratamento de eventos e o monitoramento operacional especialmente importantes em ambientes bancários.

Responsabilidades de Integração em um Ambiente API-First

Uma plataforma API-first continua exigindo uma engenharia de integração disciplinada.

Um banco que adota a Pismo pode precisar mapear dados de clientes, contas, produtos, transações e dados de referência para novas estruturas. Também pode precisar orquestrar fluxos de trabalho entre a Pismo e os sistemas responsáveis por identidade, fraude, pagamentos, relatórios, compliance ou comunicação com clientes.

As principais responsabilidades incluem:

• Mapeamento de dados;
• Orquestração de fluxos de trabalho e processos;
• Tratamento de erros;
• Segurança;
• Estratégias de retentativa (retry);
• Conciliação;
• Sequenciamento de eventos;
• Adaptadores para sistemas legados;
• Monitoramento;
• Definição de responsáveis pelas integrações.

Considere uma transação que passa por vários sistemas. O core pode processar a transação enquanto um serviço antifraude avalia o risco, uma rede de pagamentos cuida da autorização, os sistemas dependentes atualizam seus registros e as plataformas de relatórios consomem os dados resultantes.

Uma falha em qualquer ponto dessa cadeia pode gerar consequências operacionais.

É por isso que a arquitetura de integração precisa ser desenhada em conjunto com a arquitetura-alvo do core. As APIs fornecem as interfaces, enquanto o desenho ao redor determina como a instituição gerencia consistência de dados, retentativas, conciliação, falhas e responsabilidades.

Modernização do Core Banking e Caminhos de Migração

A modernização do core banking é uma iniciativa arquitetural de grande porte, porque o core sustenta uma enorme quantidade de produtos e processos.

Uma migração para a Pismo não precisa, necessariamente, acontecer em uma única virada (cutover). Dependendo do ambiente, a instituição pode migrar capacidades, produtos ou segmentos de clientes selecionados, mantendo uma coexistência controlada com os sistemas legados.

Os materiais da Pismo descrevem suporte à migração e uma abordagem híbrida para instituições em transição a partir de ambientes legados.

Uma estratégia de migração deve considerar:

• Substituição de capacidades selecionadas do core;
• Coexistência com sistemas legados;
• Migração produto a produto;
• Migração por segmento de clientes;
• Modernização em fases;
• Migração de dados;
• Conciliação;
• Camadas de abstração;
• Planejamento de rollback e de contingência;
• Dependências de aplicações do entorno.

A separação arquitetural também pode ajudar durante a transição. O artigo Arquitetura Headless traz mais contexto sobre como separar as interfaces dos serviços subjacentes pode reduzir dependências durante a modernização.

Substituição do Core versus Modernização Progressiva

Há diferentes formas de conduzir a modernização do core.

Uma substituição completa pode ser adequada quando as limitações técnicas da plataforma atual, os custos operacionais, as restrições do fornecedor ou o roadmap de produtos tornam necessária uma transformação mais ampla.

A modernização progressiva pode ser útil quando a instituição precisa controlar o número de mudanças simultâneas ou manter os produtos existentes durante a transição.

Um programa em fases pode envolver:

• Migrar primeiro produtos selecionados;
• Migrar segmentos específicos de clientes;
• Introduzir novas capacidades em paralelo às existentes;
• Criar camadas de abstração entre as aplicações e os sistemas core;
• Redirecionar gradualmente as cargas de trabalho;
• Desativar componentes legados depois que suas cargas de trabalho forem migradas.

A abordagem adequada depende do ambiente. Dependências de dados, requisitos regulatórios, volumes de transações, complexidade dos produtos e a quantidade de sistemas conectados influenciam o escopo.

A arquitetura de transição também precisa de um plano explícito de desativação. Interfaces temporárias, mecanismos de sincronização e adaptadores para sistemas legados podem permanecer em produção por muito mais tempo do que o previsto quando sua remoção não está incluída no roadmap de migração.

A Coexistência com Sistemas Legados como Desafio de Integração

Os bancos raramente têm a opção de substituir todos os sistemas dependentes ao mesmo tempo.

Um novo core pode precisar coexistir com:

• Aplicações do entorno;
• Data warehouses;
• Processadores de pagamento;
• Plataformas antifraude;
• Sistemas de relatórios;
• Sistemas regulatórios;
• Canais de atendimento ao cliente.

Durante a coexistência, dois sistemas podem conter temporariamente informações relacionadas ou participar do mesmo processo de negócio. Isso levanta, de imediato, questões sobre qual sistema é a fonte da verdade, sincronização, conciliação, sequenciamento de eventos e recuperação de falhas.

Por exemplo, se uma alteração em uma conta ocorre em um sistema enquanto uma aplicação dependente ainda utiliza a fonte legada, a arquitetura de migração precisa determinar como essa alteração chega ao ambiente dependente e qual sistema continua sendo a referência oficial.

Executar determinados processos em paralelo nos dois sistemas pode oferecer uma validação adicional, mas também aumenta a carga operacional. As equipes precisam de regras claras para comparar resultados, investigar divergências, tratar exceções e definir quando as funcionalidades legadas podem ser desativadas.

Por isso, uma arquitetura de coexistência controlada pode se tornar um dos componentes mais importantes de uma migração de core.

Processamento para Emissores na Plataforma Pismo

O processamento para emissores é uma capacidade distinta, que complementa o core banking.

A Pismo oferece capacidades de emissão e processamento de cartões para produtos como cartões de crédito, débito, pré-pagos e private label, incluindo experiências com cartões físicos e virtuais.

Para instituições que estão lançando ou modernizando produtos de cartão, o processamento para emissores abrange a infraestrutura necessária para configurar e operar programas de cartões e processar as transações associadas. Ele também pode interagir com serviços de fraude, risco, redes de pagamento e outros serviços especializados.

A conexão com o core banking ganha importância quando as transações com cartão afetam contas, saldos, limites, extratos ou outros registros financeiros subjacentes.

Core Banking e Processamento para Emissores Cumprem Papéis Diferentes

O core banking fornece a infraestrutura fundamental para contas e produtos financeiros.

Core banking:

• Gerencia contas e saldos;
• Administra ledgers e registros financeiros;
• Processa transações no nível da conta;
• Suporta produtos como depósitos, poupança, empréstimos e cheque especial;
• Fornece as capacidades bancárias fundamentais.

Processamento para emissores:

• Viabiliza a emissão de cartões de pagamento;
• Gerencia programas e configurações de cartões;
• Processa as transações relacionadas a cartões;
• Suporta produtos de cartões digitais e físicos;
• Conecta os programas de cartões às redes de pagamento e aos serviços relacionados.

Essas capacidades se cruzam porque uma transação com cartão pode afetar uma conta ou um produto financeiro subjacente. Manter as responsabilidades bem separadas ajuda as equipes de arquitetura a determinar qual sistema deve ser dono de cada processo e quais dados precisam trafegar entre eles.

Fundamentos Cloud-Native para Escala e Resiliência

A arquitetura cloud-native da Pismo influencia a forma como suas capacidades bancárias e de processamento podem ser implantadas, escaladas, integradas e operadas.

Para as instituições financeiras, as características relevantes incluem:

• Escalabilidade elástica;
• Serviços distribuídos;
• Independência de implantação;
• Disponibilidade das APIs;
• Expansão geográfica;
• Iteração mais rápida de produtos;
• Abstração da infraestrutura;
• Resiliência operacional.

Essas características podem apoiar instituições que atuam com múltiplos produtos e mercados, principalmente quando os volumes de transações, os canais digitais e os requisitos de integração mudam ao longo do tempo.

A arquitetura cloud-native também pode impactar a gestão de releases. Um número maior de serviços implantáveis de forma independente permite que as equipes evoluam capacidades específicas sem precisar coordenar cada mudança por meio de uma única aplicação de grande porte.

Ainda assim, a infraestrutura financeira exige práticas rigorosas de confiabilidade. Falhas de rede, indisponibilidade de dependências, incidentes de segurança, inconsistências de dados e a disponibilidade dos sistemas dependentes precisam ser tratados por meio da arquitetura e dos processos operacionais.

Responsabilidades Operacionais em um Ambiente Cloud-Native

Levar a infraestrutura bancária para a nuvem muda a forma como as equipes operam a plataforma.

As instituições continuam precisando de controles sólidos em:

• Observabilidade;
• Segurança;
• Monitoramento das integrações;
• Gestão de incidentes;
• Governança de dados;
• Gestão de dependências;
• Planejamento de recuperação de desastres.

A observabilidade se torna especialmente importante em arquiteturas distribuídas. Uma transação pode passar por vários serviços até ser concluída; por isso, as equipes de operação precisam de telemetria suficiente para identificar onde ocorreu um problema e entender seus efeitos nos sistemas dependentes.

A governança de dados continua igualmente importante. A infraestrutura em nuvem não define quem é o dono de um dado, qual sistema pode alterá-lo, por quanto tempo ele deve ser retido ou como as alterações devem ser conciliadas.

Para líderes de tecnologia, avaliar uma plataforma cloud-native exige, portanto, olhar para o modelo operacional tanto quanto para a infraestrutura em si.

A Expansão da Pismo no Ecossistema Visa

A aquisição da Pismo pela Visa estabeleceu uma relação tecnológica mais ampla entre as duas empresas. A Visa concluiu a aquisição em janeiro de 2024 e posicionou a Pismo como uma plataforma cloud-native de processamento para emissores e core banking.

Em 2026, a Visa informou que a Pismo havia entrado em 19 novos mercados desde a aquisição. A Visa também destacou a demanda por processamento para emissores e core banking e ressaltou o papel da Pismo em ajudar instituições financeiras a migrar suas plataformas de core banking para a nuvem.

O número de 19 mercados é uma métrica de expansão divulgada pela Visa. Portanto, deve ser entendido como uma informação reportada pela própria empresa, e não como uma medida independente da penetração de mercado da Pismo.

Do ponto de vista arquitetural, a expansão geográfica traz requisitos adicionais relacionados a arranjos de pagamento, moedas, marcos regulatórios, configurações de produtos e modelos operacionais locais.

A Visa também destacou o suporte da Pismo a múltiplos trilhos de pagamento e tipos de produto, incluindo o Pix, no Brasil.

Para um contexto mais amplo, conheça o ecossistema de tecnologia da Visa.

Relações corporativas podem oferecer um contexto útil na avaliação de uma plataforma, mas anúncios públicos raramente trazem informações suficientes para determinar o escopo da migração, os prazos de implementação, os ganhos de desempenho, o ROI ou os detalhes da arquitetura interna.

Esses fatores precisam ser avaliados com base nos requisitos técnicos e de negócio específicos de cada instituição.

Framework de Avaliação para Ambientes Bancários Legados

Os líderes de tecnologia que estão avaliando a Pismo devem começar pela arquitetura atual da instituição e pelo modelo operacional desejado.

A avaliação deve abranger:

• Restrições atuais do core;
• Arquitetura de integração;
• Complexidade da migração de dados;
• Maturidade em APIs;
• Necessidades de processamento para emissores;
• Roadmap de produtos;
• Requisitos de compliance;
• Requisitos geográficos;
• Expectativas de disponibilidade;
• Prontidão organizacional;
• Mudanças no modelo operacional.

A aderência técnica e a viabilidade da migração também devem ser avaliadas separadamente. Uma plataforma pode atender aos requisitos funcionais enquanto o ambiente existente ainda apresenta uma complexidade de migração significativa.

Uma avaliação estruturada ajuda a revelar essas dependências antes do início da implementação.

Perguntas de Arquitetura a Responder Antes da Migração

Antes de definir um caminho de migração, as equipes de arquitetura e de negócio devem ter respostas claras para perguntas como:

• Qual sistema continuará sendo a fonte da verdade durante a transição?
• Quais produtos ou segmentos de clientes devem ser migrados primeiro?
• Como os dados de clientes e de contas serão migrados?
• Como funcionará a execução em paralelo (dual-run) ou a coexistência?
• Quais integrações legadas precisam permanecer ativas?
• Como a conciliação será conduzida?
• Qual é a estratégia de rollback?
• Como as APIs serão governadas?
• Como os sistemas dependentes vão detectar e tratar as mudanças?

Essas perguntas costumam revelar dependências que passam despercebidas em um diagrama de arquitetura de alto nível.

Uma aplicação voltada ao cliente pode parecer independente do core, por exemplo, mas ainda depender de estruturas de banco de dados legadas. Um sistema de relatórios também pode ter dependências ocultas de determinados eventos de transação ou de formatos de dados históricos.

Por isso, o planejamento da migração precisa contemplar, em conjunto, as dependências de aplicações, dados, integrações e operações.

Riscos de Migração e Implementação

Os riscos da modernização do core costumam surgir nos limites entre os sistemas.

As áreas mais comuns incluem:

• Mapeamento incompleto de dependências;
• Falhas na migração de dados;
• Transações duplicadas;
• Falhas de conciliação;
• Incompatibilidade com sistemas dependentes;
• Mudanças nos contratos de API;
• Prontidão operacional;
• Observabilidade insuficiente;
• Configuração de segurança;
• Limitações de rollback.

Alguns controles podem ajudar a reduzir esses riscos:

• Manter um inventário completo de dependências;
• Adotar a migração em fases quando for apropriado;
• Realizar validação em paralelo quando a arquitetura permitir;
• Implementar testes de contrato;
• Estabelecer controles de conciliação;
• Realizar testes de desempenho em ambiente semelhante ao de produção;
• Definir procedimentos de rollback antes da virada;
• Implementar a observabilidade antes da migração para produção;
• Atribuir responsáveis claros para cada dependência crítica.

Esses controles se tornam especialmente importantes quando o novo core faz parte de um ambiente distribuído. Uma migração pode funcionar corretamente no nível do core e, ainda assim, causar falhas nos sistemas dependentes se o fluxo de ponta a ponta não tiver sido testado.

Métricas de Sucesso da Modernização

Programas de modernização precisam de linhas de base (baselines) mensuráveis.

Entre as métricas úteis estão:

• Lead time para lançamento de produtos;
• Frequência de releases;
• Disponibilidade das APIs;
• Taxa de incidentes de integração;
• Latência de processamento;
• Exceções de conciliação;
• Esforço de suporte operacional;
• Tempo necessário para integrar um novo canal;
• Custo da mudança;
• Taxa de defeitos na migração.

Sempre que possível, as linhas de base devem ser registradas antes da migração. Sem elas, fica difícil comprovar se a nova arquitetura melhorou o desempenho operacional.

As métricas também devem refletir os objetivos específicos do programa. Um banco focado em velocidade de produto pode priorizar o lead time de lançamento e a frequência de releases. Já uma migração centrada em estabilidade operacional pode dar mais peso a incidentes, exceções de conciliação, disponibilidade e esforço de suporte.

Não se deve presumir benchmarks específicos da Pismo sem evidências publicadas. A comparação mais confiável é entre a linha de base da própria instituição e os resultados medidos após a implementação.

Perguntas Frequentes

Avaliando o Papel da Pismo na Infraestrutura Bancária Moderna

A Pismo reúne capacidades de core banking e de processamento para emissores em uma arquitetura cloud-native e orientada por APIs, que pode se conectar a diferentes canais de atendimento, serviços de pagamento, plataformas de parceiros e sistemas financeiros especializados.

Para instituições que estão modernizando ambientes legados, a questão prática é como essas capacidades se encaixam na arquitetura existente e no modelo operacional desejado. Migração de dados, coexistência com sistemas legados, design das integrações, conciliação, observabilidade, segurança e responsabilidade operacional podem influenciar o caminho de implementação.

A posição da Pismo dentro da Visa acrescenta outra dimensão a essa avaliação, à medida que a Visa expande suas capacidades tecnológicas para além do modelo tradicional de bandeira de cartões.

Para os líderes de tecnologia, avaliar a Pismo exige, portanto, conectar as capacidades da plataforma ao ambiente atual da instituição, aos seus objetivos de modernização, ao roadmap de migração e aos requisitos operacionais.

Para entender como a Pismo se encaixa na estratégia mais ampla de infraestrutura financeira da Visa, conheça o ecossistema de tecnologia da Visa.