Resumo

  • Em 23 de setembro, a Murex anunciou que o MX.3 obteve certificação para execução na Google Cloud, somando um destino a uma trajetória que já incluía Azure e AWS. O comunicado fala em clientes explorando a possibilidade, sem identificar entrada em produção, prazo, preço, benchmark ou resultado de recuperação.
  • A certificação reduz o custo de considerar outra infraestrutura. Ela não transfere automaticamente posições validadas, garantias, corte de mercado, permissões, confirmações de interfaces e sequência de fechamento. O banco só possui uma saída utilizável quando consegue restaurar e reconciliar esse estado dentro da tolerância de serviço.

É possível acrescentar uma nuvem ao desenho de contingência antes do almoço. O livro de uma instituição exige outra espécie de trabalho. Na retomada, alguém precisa saber qual operação foi confirmada, se a movimentação de garantia já produziu efeito, qual fotografia de mercado alimentou a avaliação e que pagamentos ultrapassaram o ponto de retorno. Infraestrutura disponível não basta se o estado recuperado não pode ser aceito para abrir o mercado.

Esse é o limite relevante do anúncio da Murex em 23 de setembro. O MX.3 foi certificado na Google Cloud para operações de negociação, tesouraria, risco e pós-negociação, com referência a cálculos intensivos de risco de mercado, contraparte e análises intradiárias. A empresa afirma que vários clientes começaram a explorar a possibilidade.

Explorar não é ter concluído. O texto não nomeia cliente em produção, duração da migração, preço, objetivo de recuperação, combinação regional ou reconciliação. A certificação comprova um destino suportado; não prova que uma instituição específica consiga chegar lá com a continuidade de negócio preservada.

O terceiro destino cria valor de opção

A nuvem não é novidade na história do MX.3. A Murex anunciou a certificação no Azure em 2017. Sua página de nuvem descreve suporte a AWS e Microsoft Azure, diferentes modelos e uma adoção em etapas, do conceito aos ambientes de desenvolvimento, teste e produção. Em 2025, também anunciou um acordo plurianual com a AWS ligado à expansão de serviços gerenciados.

A Google Cloud adiciona uma opção. Uma implantação nova pode comparar mais fornecedores de infraestrutura, regiões, segurança e operação. Um cliente atual pode reconsiderar onde colocar desenvolvimento, recuperação ou uma grade elástica de risco. A Murex abre outro canal comercial e de suporte; o Google recebe acesso a cargas próximas do núcleo operacional financeiro.

Esse valor existe sem mudança integral de produção. A concorrência melhora termos comerciais, ambientes de teste podem ser descartáveis e cálculos podem crescer em outro lugar. Mas cada mobilidade tem alcance próprio. Expandir uma grade não torna fungível o registro ponta a ponta. Acionar um ambiente alternativo não demonstra que o livro esteja correto. Escolha de compra não equivale a direito de saída executável.

O modelo de serviço também precisa permanecer separado. O acordo com a AWS descreve o MXSaaS como serviço administrado pela Murex da infraestrutura às atualizações e apresenta XVA as a Service. O anúncio da Google Cloud fala na implantação do MX.3; não anuncia MXSaaS na Google Cloud. Certificação, IaaS gerenciada pelo cliente e serviço gerenciado industrializado distribuem trabalho e responsabilidade de maneiras diferentes.

MX.3 é uma sequência operacional, não uma caixa

A arquitetura do MX.3 reúne camadas de apresentação, negócio, orquestração e serviços técnicos. A última cuida de autenticação, autorização e registro de serviços. Diferentes tecnologias sustentam cálculos; produtos complexos podem usar grades de CPU ou GPU; Kubernetes e contêineres aparecem em risco de mercado e relatórios.

Contêineres em partes da carga não transformam toda a instalação em um pacote fechado. Uma operação antiga acumula configuração de produtos e livros, dados de referência e mercado, certificados, chaves, direitos, conexões, calendários de lote, limites de alerta, exceções e conhecimento dos operadores. Dependências podem morar no código, mas também em licenças, contratos de dados, janelas de liquidação e aprovações internas.

Há quatro níveis de portabilidade. Infraestrutura pergunta se computação, armazenamento e rede podem ser recriados. Aplicação pergunta se componentes e versões suportados funcionam. Dados exigem estado completo, ordenado e com significado preservado. Operação exige equipes capazes de proteger, executar, conciliar e recuperar o serviço sob a nova divisão de tarefas.

A certificação é uma evidência forte para os dois primeiros níveis. Os últimos dependem de cada cliente: serviços nativos adotados, desenho de interfaces, custódia de chaves e histórico de observação, propriedade dos manuais e existência de um ensaio de negócio no destino alternativo.

O último estado aceito vale mais que os arquivos

Reiniciar processos não encerra a recuperação de mercados. Uma operação importada duas vezes amplia a exposição. Uma garantia reconhecida por uma parte e ausente na outra gera disputa. Um corte de preços de horário diferente altera avaliação e limite. Uma ordem de pagamento liberada não pode voltar como pendente.

O pacote de saída deve incluir ponto de recuperação declarado, diários ordenados, origem, mensagens em trânsito, confirmações externas, dependências e regras de conciliação. Cada objeto precisa de uma fonte autoritativa e de uma pessoa com poder para resolver conflito. Versão, configuração, direitos e evidência de aprovação também compõem o estado de negócio.

Por isso, servidores equivalentes podem existir sem um serviço apto a operar. Banco de dados, identidade, filas, observabilidade, chaves e controles de rede específicos do fornecedor elevam a qualidade diária e aumentam a superfície de reconstrução. Evitar toda função nativa nem sempre é racional, pois pode reduzir confiabilidade e produtividade. A disciplina está em registrar, precificar, atribuir e testar a dependência.

Um ensaio crível pode começar pequeno. O banco escolhe um serviço importante e uma interrupção definida, restaura aplicação e dependências no destino alternativo, reconecta dados e interfaces controlados e confronta posições, caixa, garantias, sensibilidades, confirmações e contabilidade com uma referência aprovada. Tempo, ação manual, perda, exceções e aprovador ficam registrados. Esse recibo é superior a um diagrama com duas nuvens.

A regulação exige capacidade de sair

Para instituições financeiras europeias abrangidas, o artigo 28 do DORA exige estratégias quando serviços de TIC sustentam funções críticas ou importantes. A saída não deve interromper o negócio, limitar conformidade nem prejudicar clientes. Os planos precisam ser completos, documentados, suficientemente testados e revistos; devem identificar alternativas e permitir transferência segura e íntegra de serviços e dados ou sua reinternalização.

O DORA não certifica o MX.3 nem aprova uma arquitetura na Google Cloud. Tampouco determina que toda carga opere em várias nuvens. Ele mantém a responsabilidade na instituição financeira. O suporte do fornecedor de software a outro destino é um insumo, não a prova de saída do cliente.

O estudo do Banco da Inglaterra sobre resiliência operacional ajuda a explicar o interesse sistêmico: terceirização e dependência de poucos terceiros criam interconexões. Mais um fornecedor certificado reduz concentração na lista de compras. A concentração prática só diminui se o serviço importante puder ser movido ou restaurado no prazo tolerável.

Cada forma de operar muda a fronteira de responsabilidade

A Murex controla certificação do software, padrões suportados, versões e parte do método técnico. A Google Cloud controla regiões, capacidade, rede e produtos gerenciados. Um integrador pode construir a base, automatizar a implantação e operar partes. Em serviço gerenciado, o fornecedor assume mais tarefas rotineiras.

O banco continua dono da decisão de negócio. Classifica criticidade, define objetivos, aprova dados e identidade, mantém contratos de mercado, aceita conciliações e responde ao conselho e ao supervisor. Terceirizar a execução não terceiriza o significado de uma posição recuperada.

A matriz deve cobrir operação normal e saída. Quem mantém o código de infraestrutura? Quem exporta configuração, registros e provas? Quem assegura licença na transição? Quem abre a rede, gira chaves e valida fontes de preço? Quem autoriza voltar a negociar? Qual ajuda sobrevive ao encerramento do contrato? Um comunicado geral não responde a essas perguntas de cliente.

A escolha pode aprofundar o aprisionamento primeiro

Uma nova certificação cria paradoxo. Recursos nativos aceleram a entrega e motivam a adoção; depois dados, segurança e observabilidade se ligam mais ao fornecedor. A produção pode ficar melhor e mais cara de reproduzir. A troca pode ser sensata, mas impede usar o número de certificações como medida de saída.

O contrário é possível se a Murex mantiver artefatos portáteis, opções de banco de dados, fronteiras claras e evidências operacionais comuns. Cada certificação pode padronizar o caminho. Migrações repetidas formam parceiros e ferramentas reutilizáveis. O mercado deve procurar esses recibos, não apenas logotipos.

O escopo dos primeiros casos será revelador. Desenvolvimento e teste, grade de risco, recuperação, produção ou toda a cadeia? Uma retomada deve nomear serviço, ponto, tempo e resultado da conciliação. Uma saída deve acrescentar formato, apoio contratual, pessoas, interfaces e custo integral.