Migração de Core Banking: Como Migrar Milhões de Contas sem parar o Banco

Uma migração de core banking transfere saldos, contratos, parcelas, limites e histórico de uma plataforma para outra enquanto a instituição continua operando. Os programas mais seguros dividem a base em ondas, usam o mesmo motor de migração em todas elas e conciliam cada conta antes de começar a próxima onda.

Na prática, uma migração é julgada por um único momento: a manhã seguinte à virada, quando os clientes abrem o aplicativo e veem o saldo certo, ou não. A maior parte do que decide esse momento acontece meses antes, em escolhas que raramente aparecem na conversa sobre a lista de fornecedores: como a base de clientes é dividida, o que migra primeiro e como a equipe comprova que cada conta chegou com o valor correto.

Essas escolhas estão recebendo mais atenção porque mais instituições estão diante delas. Na pesquisa Core Platforms Survey da American Bankers Association, 19% dos bancos disseram que provavelmente vão trocar de fornecedor de core na próxima renovação do contrato (ABA). Fintechs e emissores de cartões também estão se movendo, muitas vezes de processadores de primeira geração para plataformas cloud-native como a Pismo, que hoje faz parte da Visa (Visa).

Segundo a The Financial Brand, alguns contratos de core chegam a durar 15 anos. Isso significa que, quando a próxima conversão começa, as pessoas que conduziram a anterior muitas vezes já saíram da instituição.

O histórico explica a cautela. Em uma análise da McKinsey sobre conversões de core ligadas a fusões bancárias, os esforços de integração e modernização ultrapassaram as estimativas iniciais de custo em 50% a 100% (McKinsey). Se você ainda está avaliando as escolhas de arquitetura por trás de um novo core, o nosso guia sobre modernização do core banking trata delas em profundidade. Este artigo trata do lado da execução, com base nos programas de migração que a NTConsult conduziu para bancos e emissores de cartões, incluindo migrações para a Pismo.

O Que uma Migração de Core Banking Realmente Movimenta?

O core é o sistema de registro, por isso a migração leva muito mais do que as contas dos clientes:

• Contas e saldos, incluindo retenções, bloqueios e a situação de cada conta.
• Contratos e seus cronogramas: parcelas, taxas, situação de inadimplência e saldos para quitação.
• Configuração de produtos: tarifas, limites, ciclos de faturamento e regras de juros, que muitas vezes precisam ser reconstruídos no destino, em vez de copiados.
• Histórico necessário para extratos, contestações e relatórios regulatórios.
• Conexões com os sistemas satélites, como cobrança, pagamentos, processamento de cartões, crédito, contabilidade e relatórios regulatórios.

É nos sistemas satélites que o escopo costuma crescer. Um motor de cobrança ou um sistema de limites que lê diretamente do core legado precisa ser reapontado, testado de novo e, às vezes, substituído. Uma forma de reduzir o problema, sugerida pela The Financial Brand, é migrar alguns produtos de terceiros, como pagamento de contas (bill pay) ou emissão de cartões, antes da própria conversão do core, para que menos coisas mudem na mesma janela.

Quais São as Principais Estratégias de Migração de Core Banking?

Há quatro formas comuns de transferir uma base de clientes de um core para outro. A escolha certa depende do tamanho da base, do número de produtos e de quantos sistemas ao redor não podem ser desligados ao mesmo tempo.

Segundo a 10x Banking, a migração em fases é hoje a escolha mais comum entre instituições grandes e complexas. A Oliver Wyman chega à mesma conclusão: a coexistência “agora é a abordagem preferida, devido às inúmeras falhas de grande repercussão da estratégia convencional de ‘big bang’” (Oliver Wyman). Os fornecedores de plataforma seguiram o mesmo caminho. Leonardo Collado, que lidera a Pismo na Visa, disse à PYMNTS que a Pismo prefere modernizar serviço a serviço, em vez de fazer substituições big bang, por causa do risco operacional que elas trazem (PYMNTS).

A equipe da Pismo na Visa divide a migração em fases em três variantes (Visa Issuing Solutions). Em uma implementação greenfield, os novos produtos são lançados em um stack moderno e o negócio existente migra depois. Um side core funciona ao lado do sistema legado, para que novos produtos possam ser lançados enquanto o core antigo continua operando. Um thin ledger é um ledger leve, colocado ao lado do core legado, que assume as contas aos poucos. Esses padrões definem onde os novos negócios vão ficar. O plano de ondas define como as contas existentes chegam lá, e a maioria dos programas precisa das duas decisões. Cada variante também aceita um período de coexistência em troca de um risco menor na virada, então as regras de coexistência descritas mais adiante valem para todas elas.

Escolher o caminho é a primeira decisão do programa, e ela deve sair de um exercício de mapeamento. Repetir por padrão o que foi feito no último projeto é a forma como as instituições acabam operando dois cores por mais tempo do que tinham orçado.

O Que Deve Ser Decidido Antes de Construir Qualquer Coisa?

Uma avaliação de prontidão responde a três perguntas: o que migra, em que ordem e com qual risco. Costumamos dimensioná-la em 8 a 12 semanas, com uma equipe pequena (um gerente de projeto, um arquiteto de dados, um especialista na plataforma de destino e um analista de negócios). Ela entrega:

• Uma análise aprofundada do negócio com os responsáveis pelos processos: produtos, regras de faturamento, limites e ciclos.
• Uma análise técnica aprofundada da plataforma de origem: integrações com os sistemas bancários ao redor, sistemas satélites e bases de dados históricas. Nosso guia completo sobre integração de sistemas bancários mostra como mapeá-los em detalhe.
• O mapeamento dos dados, campo a campo, da origem para as entidades que a plataforma de destino espera.
• Uma análise de gaps que separa o que é nativo no destino do que precisa ser construído ou adaptado.
• Uma estratégia de ondas, um roadmap e uma estimativa de esforço e investimento.

A análise de gaps importa mais do que parece. A McKinsey constatou que as migrações bem-sucedidas adotaram pelo menos 80% das funcionalidades nativas do novo core. Cada gap resolvido com customização vira algo para construir, testar e conciliar em todas as ondas.

Dois itens do checklist de prontidão para migração da Visa também fazem parte dessa fase. O primeiro é uma auditoria dos dados, com limpeza automatizada e testes de regressão, para que os registros incorretos sejam corrigidos na origem em vez de migrados. O segundo é confirmar que o destino atende aos padrões de segurança e compliance aos quais a instituição está sujeita, como PCI DSS e ISO 27001.

É também nessa fase que surgem os riscos menos óbvios. Em uma migração que apoiamos em um banco digital brasileiro, 1,6 milhão de contas e 1,6 milhão de contratos de crédito pessoal e consignado foram transferidos para um novo core em cerca de 12 meses. As arquiteturas antiga e nova funcionaram em paralelo até que a plataforma legada deixasse de criar contas e contratos. Os problemas mais difíceis tinham pouco a ver com o novo core:

• Clientes híbridos. Durante um período, alguns clientes tinham a conta em uma plataforma e o empréstimo na outra, e os sistemas dependentes não estavam preparados para isso. Os estados híbridos precisam ser mapeados nas regras de coexistência antes da primeira onda.
• Sistemas satélites que não estavam prontos. Cobrança, recuperação de crédito e alguns produtos ainda não estavam preparados para a nova plataforma. Uma verificação de prontidão para cada sistema satélite, vinculada à onda que depende dele, evita que uma onda leve clientes para uma plataforma que o atendimento deles não consegue alcançar.
• Uma origem que continuava crescendo. As novas contas e os novos contratos precisaram ser direcionados para o destino durante a migração. Caso contrário, a base legada continua crescendo atrás das ondas.

Nenhum desses problemas aparece em uma demonstração da plataforma, e qualquer um deles pode parar uma onda.

Como Planejar Ondas que a Operação Consiga Absorver?

Uma sequência típica começa com um ensaio completo em um ambiente fora de produção, passa por um piloto com uma base controlada em produção, segue para a primeira onda, depois para as ondas dois a N, para a base residual e, por fim, para o desligamento da plataforma de origem.

As ondas costumam ser formadas por bandeira de cartão, BIN ou produto; por produto e modalidade; ou por segmento de clientes e perfil de risco. O volume que cada janela consegue processar, as dependências de integração e os calendários de faturamento ou das bandeiras definem os limites. Cada janela tem um limite de volume, um critério de entrada e um critério de saída, e nada avança até que a onda anterior esteja conciliada. Essa regra deixa o calendário um pouco mais lento, mas elimina a falha mais cara: descobrir um erro de mapeamento depois que ele já foi copiado para três ondas.

O plano mestre precisa cobrir mais do que datas. Ele precisa de regras de coexistência (como o roteamento, o atendimento e a cobrança acompanham cada conta enquanto duas plataformas funcionam), dos caminhos críticos que podem parar uma onda, de observabilidade por onda e por registro e de um procedimento de rollback definido, com os critérios para usá-lo.

Os clientes devem saber da mudança antes que ela chegue até eles. Leonardo Collado, SVP e gerente-geral da Pismo, recomenda “comunicar as mudanças de forma clara e com antecedência e, ao mesmo tempo, oferecer um canal para que as pessoas deem feedback”. Em um plano de ondas, isso significa vincular os avisos aos clientes ao calendário de ondas, para que cada grupo receba a comunicação da instituição antes da sua própria janela, e garantir que o atendimento saiba em qual plataforma cada conta está naquele dia.

Por Que o Motor de Migração Precisa Ser Repetível?

Quando uma base migra em dez ou vinte ondas, a extração e a transformação deixam de ser um script pontual e passam a ser um processo de produção. O motor que construímos segue um caminho fixo: extração por lote e por onda, uma camada bruta (raw) que preserva os dados de origem sem alterações, um modelo canônico que dá a cada registro uma única representação (tratamos desse princípio em profundidade no nosso artigo sobre integração de dados financeiros), regras de transformação e validação e a entrega ao destino por arquivo ou API.

A camada bruta é fácil de pular e cara de não ter. Quando uma conciliação aponta uma diferença semanas depois, a equipe consegue voltar exatamente ao que a origem enviou, em vez de extrair de novo de um sistema que continuou mudando. O modelo canônico compensa quando há mais de uma origem: cada origem precisa de um único mapeamento para o modelo, e as regras seguintes continuam as mesmas.

Cada conta e cada contrato carregam sua identidade, versão, status e evidências em cada etapa. Esse rastro no nível do registro permite que a equipe identifique um problema em uma onda antes dos clientes e dá aos auditores algo concreto para revisar.

Em uma migração de processamento de cartões para um grande emissor do varejo brasileiro, mais de 5 milhões de contas estão migrando de dois processadores de origem para a Pismo, com cenários de migração separados por bandeira e produto. O motor recebe lotes de cada origem, valida o que chegou, aplica o mapeamento dos dados e envia o resultado para a Pismo, acompanhando cada retorno. Duas origens alimentando um único destino é justamente o caso em que uma abordagem improvisada não se sustenta.

Como Comprovar que a Migração Funcionou?

A conciliação é a etapa em que muitos programas investem pouco, e é sobre ela que os reguladores, as bandeiras de cartão e a própria área financeira da instituição vão perguntar. Fazemos três conciliações em cada onda:

• Origem vs. motor. Tudo o que saiu da origem foi lido, entendido e classificado? Contagens, chaves e integridade.
• Motor vs. destino. Tudo o que foi enviado foi aceito pelo destino no estado esperado? Retornos, eventos e rejeições.
• Origem vs. destino. Saldos, extratos, parcelas e dívida em aberto batem, conta a conta? Valores, datas e status.

A coexistência torna isso mais difícil: quando os produtos migram em momentos diferentes, os dados dos clientes podem precisar ficar em vários sistemas ao mesmo tempo, o que exige sincronização contínua, conciliação e um controle de mudanças rigoroso.

Para evitar que a conciliação vire um gargalo manual, a NTConsult construiu um motor de conciliação com apoio de IA. As equipes de negócio escrevem as regras de conciliação em linguagem natural, então não há código para manter. A IA aplica cada regra e registra a regra, a evidência e um índice de confiança para cada decisão. Os casos abaixo do limite de confiança vão para um analista, com o contexto já reunido. Os analistas deixam de conferir todos os registros e passam a dedicar seu tempo às exceções, que chegam com as evidências já levantadas.

O Que Muda Quando o Destino É a Pismo?

A Pismo é uma plataforma cloud-native de core banking e processamento para emissores de cartões, que abrange cartões, contas de depósito, crédito e serviços bancários corporativos. Para conhecer a sua arquitetura em detalhes, leia o nosso artigo completo, Pismo: Core Banking Cloud-Native e Processamento para Emissores. O desenho da plataforma favorece as migrações graduais. O kit de migração da Pismo se conecta ao core ou ao sistema de gestão de cartões existente por meio de APIs e também aceita o envio de arquivos para grandes volumes. Para cartões, um redirecionador de autorizações encaminha as transações para o sistema legado enquanto os cartões ainda estão lá e é desligado quando todos os cartões de um BIN já migraram. As instituições que recebem as autorizações diretamente das bandeiras podem migrar por BIN, em lotes, enquanto as fintechs que usam um patrocinador de BIN (BIN sponsor) costumam migrar todos os cartões de um BIN de uma só vez (Pismo).

Essas capacidades tornam as ondas possíveis do lado do destino. Elas não definem o que entra em cada onda, como os dados de origem são limpos e mapeados, como os sistemas satélites são preparados nem como cada onda é comprovada. A migração de cartões descrita acima nos ensinou três lições que valem para a maioria dos destinos cloud-native:

• Mapeie para as entidades do destino, e não para as tabelas da origem. Um core moderno espera o seu próprio modelo de dados, então o mapeamento é feito campo a campo para as entidades que a plataforma define.
• Duas origens exigem dois mapeamentos e um único modelo. É na consolidação de processadores que o modelo canônico se paga.
• A conciliação inclui a bandeira do cartão. Em carteiras de cartões, o processador de destino e a bandeira precisam estar de acordo com a origem.

A entrega por API torna práticas as ondas menores e mais frequentes. Ela não reduz o trabalho de conciliação, que cresce com o número de produtos e cenários.

Quanto Tempo Leva uma Migração de Core Banking?

A duração depende do tamanho da base, do número de produtos e de quantos sistemas satélites precisam mudar. Para uma instituição grande, com vários produtos, um plano típico fica assim:

O trabalho no motor e a conciliação se sobrepõem a partir da onda piloto, e bases menores, com conjuntos de produtos mais simples, avançam mais rápido. Para os bancos e as cooperativas de crédito dos EUA, o calendário costuma começar pelo contrato atual de core.

A The Financial Brand aconselha as instituições que enfrentam a descontinuação de um core a “negociar com sabedoria, planejar com cuidado e assumir o controle dos próprios prazos antes que alguém faça isso por elas”. Saber quando a plataforma atual será descontinuada também mostra quanto desses 18 a 24 meses está, de fato, disponível.

A plataforma será diferente em cada projeto. O que se repete é a ordem das decisões: decidir antes de construir e comprovar antes de desligar qualquer coisa.

Como a NTConsult Pode Ajudar

A NTConsult conduz migrações de core banking e de processadores de cartões para bancos e emissores, da primeira avaliação ao desligamento da plataforma de origem. Os casos deste artigo, uma conversão de core com 1,6 milhão de contas e 1,6 milhão de contratos de crédito e a migração de 5,4 milhões de contas de cartão para a Pismo, seguem o mesmo método, o NT MOVE. Cada uma das suas etapas (avaliação, planejamento das ondas, motor de migração e conciliação) pode ser contratada separadamente. Nossas equipes combinam especialistas na plataforma de origem com especialistas no destino, e a conciliação roda em um motor com apoio de IA que construímos e mantemos.

Se você está planejando a migração de um core ou de um processador, uma avaliação de prontidão entrega o mapa dos dados, a matriz de gaps, a estratégia de ondas e uma estimativa de custos em 8 a 12 semanas, antes que você se comprometa com um plano de virada. Fale com a nossa equipe de migração de plataformas.

Perguntas Frequentes

Fontes

Todas as fontes abaixo estão em inglês.

• American Bankers Association, Core Platforms Survey
• McKinsey & Company, Core banking migration during M&A: Seven keys to success
• Oliver Wyman, 5 key considerations to transform core banking systems
• The Financial Brand, Your Core Is Being Retired. Now What?
• Visa, Visa Completes Acquisition of Pismo
• Visa Issuing Solutions, Core Banking Modernization and Migration
• Visa, Transform with Visa and Pismo: Next-gen processing and core banking
• PYMNTS, Visa's Pismo Says AI Has Exposed Banking's Old Tech Problem
• 10x Banking, Core banking migration strategies
• Pismo, How Pismo helps banks migrate to cloud-based computer systems
• Pismo, Pismo continues migration success as more than 1.5 million accounts go live