A Soberania Financeira Requer Infraestrutura Soberana: Por Que o Fintech Europeu Precisa de Banca Central Construída na Europa
A soberania financeira requer independência em nível de infraestrutura. Um ledger hospedado em infraestrutura de nuvem dos Estados Unidos, roteando pagamentos através de redes controladas pelos Estados Unidos, governado por capital liderado pelos Estados Unidos, não é soberano independentemente de onde o banco esteja constituído.
A dependência é mensurável. 63% da infraestrutura de nuvem europeia opera em provedores controlados pelos Estados Unidos. Mais de 90% das transações com cartão na Europa são roteadas através de Visa e Mastercard. Cada rodada de financiamento superior a um bilhão de euros em fintech europeu em 2025 foi liderada por investidores estadounidenses. Desapareceriam 9 bilhões de euros em financiamento anual se o capital estadounidense se retirasse do fintech europeu. A dependência de infraestrutura e a dependência de capital não são problemas separados. Elas se reforçam mutuamente. Os fornecedores financiados por capital estadounidense estão sujeitos à pressão regulatória estadounidense, controles de exportação estadounidenses e jurisdição de tribunais estadounidenses, independentemente de onde seus servidores estejam localizados.
DORA transforma isso de uma preferência geopolítica em um requisito regulatório.
As Três Camadas de Dependência
As instituições financeiras europeias enfrentam dependências de infraestrutura em três camadas distintas. Cada camada tem implicações legais diferentes, diferentes exposições à DORA e diferentes prazos de remediação.
Camada 1: Infraestrutura de nuvem. AWS, Azure e Google Cloud fornecem a maior parte da infraestrutura de computação, armazenamento e rede para instituições financeiras europeias. Esses provedores operam centros de dados na Europa, mas as entidades-mãe são corporações estadounidenses sujeitas à jurisdição estadounidense. A Lei CLOUD (2018) permite às autoridades de aplicação da lei dos Estados Unidos obrigar os provedores de nuvem estadounidenses a divulgar dados armazenados em qualquer lugar do mundo, incluindo centros de dados europeus, sem exigir um processo legal europeu. A residência de dados em Frankfurt não cria soberania de dados se a matriz estadounidense do provedor puder ser obrigada a produzi-los.
O Artigo 28 da DORA exige que as entidades financeiras avaliem e monitoreem os riscos de terceiros provedores de ICT, incluindo o risco de concentração. O Artigo 30 exige acordos contratuais escritos com provedores de ICT que incluam direitos de auditoria, requisitos de localização de dados, disposições de estratégia de saída e o direito de realizar testes de penetração. Para os provedores de nuvem estadounidenses, o direito de auditoria é real, mas o que uma instituição europeia encontra quando audita pode ser um sistema que não pode modificar, não pode migrar rapidamente e não pode avaliar completamente porque a arquitetura interna do provedor é proprietária.
Camada 2: Redes de pagamento. Visa e Mastercard processam mais de 90% das transações com cartão na Europa. Ambas são corporações estadounidenses. A SWIFT, que roteia mensagens interbancárias, está constituída na Bélgica mas governada por uma diretoria com participação significativa estadounidense e historicamente sujeita à pressão do governo estadounidense. Em 2012, o Departamento do Tesouro dos Estados Unidos obrigou a SWIFT a cortar o Irã de sua rede, afetando a capacidade dos bancos europeus de processar transações legítimas com contrapartes iranianas.
A SEPA fornece infraestrutura operada por europeus para transferências de crédito e débitos diretos. O Banco Central Europeu opera o TARGET2 (e seu sucessor T2) para pagamentos de alto valor em euros. Mas os pagamentos com cartão, que representam a maioria do volume de transações de consumo, não têm uma alternativa operada por europeus com volume comparável. A EPI (European Payments Initiative) está construindo o Wero como alternativa de pagamento com cartão, mas cobre apenas uma fração do volume atual de Visa/Mastercard em meados de 2026.
Camada 3: Capital e governança. Os fornecedores de infraestrutura estão sujeitos às prioridades de governança de seus fornecedores de capital. Um fintech europeu financiado principalmente por capital de risco estadounidense enfrentará pressão para expandir-se para mercados estadounidenses, adotar padrões de infraestrutura estadunidenses e aceitar termos contratuais padrão estadunidenses, incluindo termos de dados que podem entrar em conflito com GDPR e DORA.
O relatório State of European FinTech 2026 da Finch Capital quantifica a lacuna de capital: poderiam ser desbloqueados 37,5 bilhões de euros por ano se os fundos de pensão europeus igualassem as taxas de alocação de fintech de suas contrapartes estadunidenses. Essa lacuna não está preenchida. O resultado é uma dominação de capital liderada pelos Estados Unidos continuada na etapa de crescimento, que se traduz em governança orientada aos Estados Unidos nas empresas que constroem a infraestrutura financeira europeia.
O Que Significa a Infraestrutura Soberana Tecnicamente
A soberania não é uma certificação nem uma bandeira em um centro de dados. Em nível de infraestrutura, ela exige quatro propriedades específicas.
Residência de dados com controle jurisdicional. Os dados devem ser armazenados dentro da UE/EEE sob uma entidade legal sujeita exclusivamente à jurisdição da UE. Isso significa que a empresa-mãe do provedor de nuvem, não apenas a subsidiária operacional, deve estar vinculada aos requisitos de proteção de dados da UE. A German Sovereign Cloud (operada pela T-Systems e SAP em infraestrutura Azure) tenta isso através de um modelo onde a Microsoft não tem acesso aos dados sem aprovação do fiduciário alemão. As ofertas de EU Sovereign Cloud da AWS e Google são arquitetonicamente similares. Cada modelo proporciona soberania parcial: tecnologia de origem estadunidense com sobreposição de governança europeia.
Acesso de auditoria sem controle do fornecedor. O Artigo 30(2)(d) da DORA exige que a entidade financeira possa auditar seu provedor de ICT, diretamente ou através de um terceiro. Para infraestrutura de caixa-preta onde o código-fonte, a cadeia de dependências e o comportamento em tempo de execução são proprietários, esse direito de auditoria é nominal. Um auditor pode verificar que o sistema produz as saídas esperadas; não pode verificar como. Um sistema com código-fonte publicado, cadeia de dependências documentada e comportamento determinístico pode ser auditado por completo. O direito de auditoria é substancial, não nominal.
Transparência da cadeia de suprimentos. O Artigo 9 da DORA exige a avaliação do risco da cadeia de suprimentos. Para um sistema de banca central, a cadeia de suprimentos inclui cada biblioteca da qual o sistema depende, cada serviço de terceiros que chama, e cada processador de dados através do qual encaminha dados. Um sistema com 5.000 dependências transitivas não pode ter sua cadeia de suprimentos auditada de forma significativa: o grafo de dependências é muito grande para raciocinar sobre ele. Um sistema com 30 dependências transitivas em seu núcleo financeiro pode fazê-lo.
Estratégia de saída com custo de migração limitado. O Artigo 28(7) da DORA exige que o risco de concentração seja gerenciado, o que inclui a capacidade de sair de um provedor de ICT crítico sem uma interrupção operacional inaceitável. Para um sistema de banca central construído sobre a pilha de um fornecedor proprietário (APIs personalizadas, formatos de dados proprietários, ferramentas específicas do fornecedor), o custo de saída é medido em anos e dezenas de milhões de euros. Para um sistema com interfaces padrão (ISO 20022, APIs abertas), formatos de dados abertos e modelos de implantação portáteis, o custo de saída é limitado.
As Disposições da DORA sobre Risco de Concentração
O Artigo 28(5) da DORA aborda explicitamente o risco de concentração em dependências de terceiros provedores de ICT. As Autoridades Supervisórias Europeias estão habilitadas a designar provedores de serviços de terceiros de ICT críticos (CTPPs) e impor requisitos de supervisão adicionais, incluindo testes de resiliência, planejamento de saída e relatórios operacionais.
Para instituições financeiras europeias, a análise de risco de concentração tem duas dimensões. Primeiro, se algum provedor de ICT individual representa uma dependência sistêmica: se esse provedor falhar ou se tornar indisponível, a instituição também falha? Segundo, se o setor financeiro da UE como um todo tem uma concentração excessiva em algum provedor ou categoria de provedor individual.
As ESAs publicaram sua primeira análise CTPP em 2025 e encontraram concentração significativa em nuvem e tecnologia de banca central. A resposta regulatória não é mandatar a mudança de fornecedor, mas exigir que as instituições possam demonstrar que avaliaram o risco e têm estratégias de saída plausíveis. Uma instituição que não pode articular uma rota de migração para outro provedor de banca central porque a arquitetura do fornecedor atual é incompatível com qualquer alternativa tem um risco de concentração que a DORA exige que seja documentado e abordado.
O Argumento da Arquitetura Transparente
O argumento de soberania não se trata principalmente de onde a infraestrutura está fisicamente localizada. Trata-se de se a infraestrutura pode ser auditada por completo, operada independentemente e migrada em um cronograma definido.
Um sistema de banca central construído na Europa, executando-se em provedores de nuvem europeus, com código-fonte proprietário e opaco proporciona garantias de soberania mais fracas do que um sistema construído em qualquer lugar com arquitetura publicada, interfaces documentadas, dependências externas mínimas e formatos de dados padrão. A jurisdição de constituição é uma propriedade legal. A auditabilidade da arquitetura é uma propriedade operacional. Aos reguladores sob DORA importa a propriedade operacional.
A pergunta prática para um CTO que avalia infraestrutura de banca central: você pode satisfazer os requisitos de acesso de auditoria, transparência da cadeia de suprimentos e estratégia de saída da DORA com seu fornecedor atual? Se a resposta requer confiança nas afirmações do fornecedor em vez de verificação de sua própria auditoria, a arquitetura não satisfaz o requisito. O requisito é evidência, não afirmação.
Compromissos
A soberania de infraestrutura tem custos que são reais e não devem ser minimizados.
Seleção de fornecedores mais estreita. Os provedores de nuvem sob jurisdição europeia têm menos capacidade e menos regiões geográficas do que os hyperscalers estadunidenses. Uma estratégia de nuvem puramente europeia pode significar aceitar custos de infraestrutura de linha de base mais altos, menos localizações de edge e serviços gerenciados menos maduros.
Complexidade de migração. Mudar-se de um provedor de nuvem estadunidense estabelecido para uma alternativa europeia é um projeto de vários trimestres que envolve avaliação serviço por serviço, renegociação de contratos de fornecedor e validação operacional. Para instituições com anos de investimento em ferramentas de nuvem estadunidenses, o custo de mudança é alto.
As alternativas de rede de pagamento estão incompletas. O Wero e outras iniciativas de pagamento europeias abordam parte da dependência de Visa/Mastercard, mas a cobertura é parcial em meados de 2026. Uma instituição ainda não pode construir uma pilha de infraestrutura de pagamento completamente europeia que iguale a aceitação e o volume das redes dominadas pelos Estados Unidos.
Incerteza regulatória. O quadro CTPP das ESAs ainda está sendo operacionalizado. O que constitui documentação de estratégia de saída suficiente, risco de concentração aceitável e acesso de auditoria adequado não foi definido uniformemente entre jurisdições. Construir infraestrutura para satisfazer um requisito regulatório que ainda está sendo escrito requer design para flexibilidade, não para uma especificação fixa.
Fernel Context
O núcleo financeiro da Fernel está construído em Zig com uma contagem de dependências de aproximadamente 30 dependências transitivas. A arquitetura está publicada: três camadas estritamente isoladas com interfaces documentadas, modelos de dados nativos ISO 20022 e contratos de API padrão que não são proprietários. O código-fonte e o inventário de dependências estão disponíveis para auditoria sem controle do fornecedor. A implantação é portátil entre provedores de nuvem. Não é necessário runtime de fornecedor: nenhum serviço gerenciado proprietário, nenhum ambiente de execução de caixa preta que a instituição não possa inspecionar ou substituir.
Leia mais: Segurança e Compliance | A Arquitetura de um Sistema Operacional Financeiro | DORA para Provedores de Infraestrutura Financeira
Fontes:
- Finch Capital, State of European FinTech 2026: dados de concentração de nuvem, análise de lacuna de capital, dependência de financiamento de 9 bilhões de euros
- DORA, Regulamento (UE) 2022/2554, Art. 28 (Gestão de Riscos de Terceiros Provedores de ICT), Art. 28(5) (Risco de Concentração), Art. 28(7) (Estratégias de Saída), Art. 30 (Acordos Contratuais), Art. 9 (Risco da Cadeia de Suprimentos)
- Lei CLOUD dos Estados Unidos, Pub. L. 115-141 (2018), disposições de acesso a dados transfronteiriços
- SWIFT e sanções contra o Irã: ação OFAC do Departamento do Tesouro dos Estados Unidos, 2012, precedente para controle extraterritorial de rede de pagamentos
- European Payments Initiative (EPI), documentação do produto Wero (2025-2026)
- ESAs, Quadro de Supervisão de Provedores de Terceiros de ICT Críticos (CTPP), análise inicial de designação 2025
- ECB TARGET2 e consolidação T2: documentação operacional