Operações11 min de leitura

Núcleos Auxiliares e Padrão Strangler Fig: A Arquitetura Real da Modernização Bancária Progressiva

O padrão de núcleo auxiliar não elimina o risco de migração. Substitui um único corte abrupto por um requisito de reconciliação contínua que persiste durante toda a duração da execução em paralelo, que na maioria dos programas de modernização bancária dura entre dois e cinco anos. Os bancos que tratam o núcleo auxiliar como um piloto controlado e adicionam a reconciliação em uma fase posterior descobrem consistentemente o problema na ordem errada: as lacunas de reconciliação aparecem depois que os dados já estiveram viajando entre dois sistemas por meses.

40% dos bancos seguem estratégias de núcleo auxiliar em meados de 2026, com uma projeção de 70-80% para 2028. 85% das instituições financeiras relatam planos para investimentos de transformação de núcleo de grande envergadura (KPMG European Banking Outlook 2026). A indústria aceitou que o reemplacemento Big Bang é demasiado arriscado. Se um núcleo auxiliar deve ser operado já não é uma decisão aberta. O que importa é se a arquitetura do núcleo auxiliar inclui a infraestrutura de reconciliação necessária para operar dois núcleos financeiros em paralelo sem acumular estado irreconciliável.

Por Que o Reemplacemento Big Bang Falhou

A migração da TSB em 2018 é a referência canônica. A TSB tentou migrar 5,2 milhões de clientes da plataforma do Lloyds Banking Group para seu novo núcleo Proteo4UK em um único fim de semana. A migração produziu uma interrupção de 18 dias que afetou 1,9 milhões de clientes, bloqueou clientes de suas próprias contas, expôs a alguns clientes os dados de transação de outros clientes e custou à TSB mais de GBP 330 milhões em remediação, compensação e sanções regulatórias. A FCA e PRA do Reino Unido impuseram sanções adicionais de GBP 48,65 milhões em 2023.

A causa estrutural não foi um único bug. Foi a impossibilidade de validar a equivalência de comportamento completa de dois sistemas em um ambiente de teste contra cinco anos de dados de produção, estados de clientes e histórico de transações de casos de limite. A TSB testou a migração extensivamente. O ambiente de produção revelou interações que nenhuma matriz de teste havia previsto.

Cada reemplacemento de core banking em grande escala que tentou um único corte de fim de semana viu o mesmo tipo de problema. O comportamento do sistema legado não está completamente documentado. O comportamento do novo sistema sob carga de produção difere de seu comportamento sob carga de teste. O estado do cliente no momento do corte contém casos de limite que os testes pré-migração não cobriram.

A arquitetura de núcleo auxiliar evita o corte de fim de semana único. Introduz uma classe diferente de problema.

O Problema do Cérebro Dividido

Quando dois núcleos operam simultaneamente contra dados de clientes sobrepostos, tornam-se possíveis fontes de verdade contraditórias. A cliente Alice tem uma conta no núcleo legado (onde residem seus mandatos de débito direto, débitos diretos e histórico de transações) e no núcleo auxiliar moderno (onde residem suas novas contas e novos produtos). Quando o salário de Alice é depositado, vai para a conta legada. Quando ela paga uma assinatura com o novo produto, vai para a conta auxiliar. Seu saldo total disponível é a soma de ambos, mas nenhum dos núcleos conhece a visão completa.

O problema do cérebro dividido tem três dimensões.

Visibilidade de saldo. A cliente vê um saldo que depende de qual conta do sistema ela consulta. Os agentes de atendimento ao cliente devem consultar ambos os sistemas para responder "qual é meu saldo total?" Cada consulta de saldo orientada ao cliente que toca ambos os sistemas requer uma operação de junção sobre dois núcleos que podem não ter seu estado sincronizado no momento da consulta.

Histórico de transações. Uma cliente que contesta um débito deve ser capaz de reconstruir seu histórico completo de transações independentemente de qual núcleo as processou. Uma trilha de auditoria que diz "suas transações antes de [data] estão no sistema legado; suas transações após [data] estão no novo sistema" não é um histórico completo. É um particionamento de dois registros incompletos.

Estado de compliance. Os registros CDD, indicadores AML, designações PEP e resultados de triagem de sanções devem ser consistentes em ambos os núcleos. Se uma cliente está marcada no sistema legado mas o auxiliar não recebeu esse indicador, o auxiliar pode processar transações que o sistema legado teria bloqueado. O Artigo 14 da AMLD5 requer que os resultados CDD sejam aplicados consistentemente em todas as linhas de produto, um requisito que é violado estruturalmente quando os dois núcleos não compartilham seu estado de compliance em tempo real.

Reconciliação como Componente Arquitetônico de Primeira Classe

A abordagem correta é tratar a reconciliação como um componente estrutural da arquitetura do núcleo auxiliar, não como um processo operacional adicionado após o deploy.

Sincronização baseada em eventos. Cada mudança de estado em qualquer um dos núcleos é publicada como um evento em um log de eventos compartilhado. O log de eventos é o registro autoritativo do que aconteceu, em que ordem. Tanto o núcleo legado quanto o auxiliar moderno consomem este log de eventos. Seus estados são derivados da mesma sequência de eventos. A reconciliação não é uma comparação de dois estados independentes. É a verificação de que ambos os núcleos aplicaram corretamente a mesma sequência de eventos.

Isso requer que ambos os núcleos suportem a derivação de estado baseada em eventos, o que os núcleos legados geralmente não fazem. A abordagem prática para sistemas legados é capturar mudanças através de captura de dados de mudanças (CDC): monitorar o log de transações do banco de dados do núcleo legado e converter mudanças de estado em eventos. O CDC introduz latência (segundos a minutos) e requer manejo cuidadoso das peculiaridades do modelo de dados legado: campos não documentados, máquinas de estado implícitas codificadas em colunas de status, e regras de negócio que residem em procedimentos armazenados em vez de em código de aplicação.

Trilha de auditoria imutável através de ambos os núcleos. Cada transação processada por qualquer um dos núcleos deve ser registrada em um log de auditoria imutável compartilhado com um esquema de ID de correlação comum. Quando uma cliente pergunta "o que aconteceu com o pagamento X?", a resposta deve ser recuperável desde o log compartilhado independentemente de qual núcleo a processou. O log compartilhado não é um banco de dados de relatórios que ambos os núcleos agregam periodicamente. É um journal de write-ahead no qual ambos os núcleos escrevem antes de executar mudanças de estado.

Capacidade de rollback à granularidade de segmento de produto. O padrão Strangler Fig migra clientes ou segmentos de produto incrementalmente do núcleo legado para o auxiliar moderno. Se a migração de um segmento de produto revela uma diferença de comportamento onde o núcleo moderno manipula um caso de limite específico de maneira diferente do núcleo legado, a arquitetura deve suportar reverter esse segmento ao núcleo legado sem perda de dados.

O rollback requer que o estado do núcleo moderno seja um superconjunto do que o núcleo legado teria tido para as mesmas transações. Se o núcleo moderno processou transações que o núcleo legado não pode representar (porque o modelo de dados legado não suporta o novo tipo de conta, ou o motor de workflow legado não pode reproduzir a sequência de eventos), o rollback não é possível. Isso deve ser verificado antes da migração de cada segmento, não descoberto durante a tentativa de rollback.

O Strangler Fig a Granularidade de Produto

O padrão Strangler Fig, nomeado após a figueira que cresce ao redor de uma árvore hospedeira e a substitui gradualmente, migra funcionalidade incrementalmente. Em core banking, a granularidade mais efetiva para o Strangler Fig é o segmento de produto: migrar um tipo de produto de cada vez, começando com a aquisição de novos clientes (novos clientes recebem o núcleo moderno; clientes existentes permanecem no núcleo legado até serem explicitamente migrados).

A migração de segmento de produto com aquisição de novos clientes tem uma vantagem específica: os novos clientes não têm estado histórico no núcleo legado. Não há dados de clientes para migrar, nem histórico de transações para reconciliar, nem mandatos de débito direto para transferir. A carga de reconciliação para segmentos de novos clientes limita-se a verificar que o núcleo auxiliar processa corretamente produtos que o núcleo legado nunca processou.

A carga de reconciliação aumenta quando segmentos de clientes existentes são migrados. Cada cliente existente traz estado histórico: histórico de transações, configurações de produto, mandatos de débito direto, débitos diretos, registros CDD, indicadores AML e processos em andamento (pagos pendentes, disputas abertas, transferências programadas). A migração de clientes existentes requer:

Extração do estado atual completo de cada cliente do núcleo legado.
Verificação de que o modelo de dados do núcleo moderno pode representar cada elemento desse estado sem perda.
Transformação do estado legado para o formato do núcleo moderno.
Carga do estado transformado no núcleo moderno.
Operação paralela de ambos os núcleos durante um período de verificação, comparando as saídas para as mesmas entradas.
Corte do tráfego orientado ao cliente para o núcleo moderno.
Retenção do núcleo legado em modo somente leitura durante um período definido para lidar com disputas que fazem referência a dados históricos.

O passo 5 é onde a maioria dos programas subestima o esforço. O período de verificação requer gerar entradas de transações idênticas contra ambos os núcleos e comparar as saídas com cobertura suficiente para ter confiança de que a equivalência de comportamento se mantém em casos de limite, não apenas para o caminho feliz, mas para condições de erro, transações R, atualizações concorrentes e eventos ativados regulatoriamente. Isso não pode ser alcançado executando um conjunto de testes. Requer a reprodução simultânea de padrões de tráfego de produção contra ambos os sistemas.

O Contexto do CAGR de 14%

O deploy em nuvem no setor bancário europeu cresce com um CAGR de 14% (KPMG 2026). Os modelos SaaS e de core banking hospedado alcançaram uma quota de mercado de 67,5%. O mercado está se deslocando de sistemas de terceira geração com vendor lock-in para núcleos componíveis de quarta geração com APIs abertas e modelos de deploy em nuvem.

Esse deslocamento significa que a maioria dos bancos que atualmente operam programas de núcleo auxiliar estão avaliando núcleos modernos construídos especificamente para deploy em nuvem, com arquiteturas baseadas em eventos, modelos de dados nativos ISO 20022 e contratos de API padrão. O desafio de reconciliação é menor quando ambos os núcleos falam a mesma linguagem de dados: quando as transações do núcleo legado podem ser classificadas com códigos BankTransactionCode de ISO 20022 e o núcleo moderno usa a mesma classificação nativamente, o match de reconciliação é estrutural em vez de heurístico.

A lacuna de reconciliação é mais ampla quando o núcleo legado usa códigos de transação proprietários, identificadores de conta proprietários e contratos de API proprietários, e o núcleo moderno usa padrões ISO de maneira completa. Cada match de reconciliação entre esses dois sistemas requer uma camada de tradução, e cada camada de tradução é uma carga de manutenção e uma fonte potencial de discrepância.

Compromissos

A modernização progressiva através de núcleo auxiliar introduz custos que o reemplacemento Big Bang evita, e evita custos que o reemplacemento Big Bang cria.

Sobrecarga operacional contínua. Operar dois núcleos em produção dobra a superfície operacional: monitoramento, resposta a incidentes, planejamento de capacidade e patches de segurança devem cobrir ambos os sistemas. Para instituições que já operam com pessoal reduzido em operações de core banking, dobrar a superfície operacional sem aumentar a equipe cria risco.

Janela de consistência. A sincronização baseada em eventos introduz uma janela de latência entre uma mudança de estado em um núcleo e sua propagação para o outro. Durante essa janela, os dois núcleos podem reportar estados diferentes para o mesmo cliente. Para fins de compliance, a janela deve estar limitada e documentada: os reguladores esperam que as instituições conheçam o atraso máximo em sua arquitetura de núcleo duplo e tenham avaliado seu impacto nas obrigações de compliance.

Incompatibilidades de modelo de dados. Os núcleos legados foram construídos com modelos de dados que precederam a ISO 20022, PSD2 e GDPR. A migração de dados de clientes de um modelo legado para um moderno requer lidar com campos faltantes (registros de consentimento GDPR que o núcleo legado não rastreia), discrepâncias estruturais (enumerações de códigos de transação proprietárias que não mapeiam limpamente para códigos ISO 20022) e ambiguidades semânticas (colunas de status que codificam regras de negócio que já não estão documentadas em nenhum lugar).

Fernel Context

A arquitetura da Fernel é projetada desde sua decomposição inicial de camadas para o deploy de núcleo auxiliar. As três camadas estritamente isoladas (o motor de ledger, o motor de orquestração e a camada de domínio) operam independentemente. Um banco que opera um núcleo auxiliar pode fazer o deploy do motor de ledger da Fernel para segmentos de produto novos, enquanto retém o núcleo legado para clientes existentes, e conectar os dois através de uma camada de sincronização baseada em eventos que escreve tanto no log de transações legado quanto no journal de append-only da Fernel. A infraestrutura de reconciliação é o log de eventos, não um trabalho de lote periódico: cada mudança de estado em qualquer um dos sistemas é uma entrada de journal com uma ID de correlação, consultável a qualquer momento.

Fontes:

KPMG, European Banking Outlook 2026: 40% adoção de núcleo auxiliar em meados de 2026, 70-80% projetado para 2028; 85% planejam transformação de grande envergadura; CAGR de 14% de deploy em nuvem; 67,5% quota de mercado SaaS/hospedado
Falha de migração da TSB, abril de 2018: GBP 330 milhões em custos totais, 1,9 milhões de clientes afetados, interrupção de 18 dias. Ação de enforcement da FCA/PRA do Reino Unido e multa de GBP 48,65 milhões (2023)
ThoughtWorks, "Kill your core: The banking revolution you didn't see coming": princípios de arquitetura de coreless banking
AMLD5, Diretiva 2018/843, Art. 14 (Escopo e momento da verificação CDD, requisito de consistência)
Padrão Strangler Fig: Martin Fowler, "StranglerFigApplication" (2004), migração incremental por operação de sistemas paralelos
ISO 20022 BankTransactionCode External Code Sets: a ponte de linguagem de dados para a reconciliação de núcleo duplo