Por que o e-mail bancário é uma preocupação operacional regulada?
Para um banco brasileiro autorizado pelo Banco Central, uma fintech com licença SCD, SEP, SCFI ou IP, ou uma plataforma de pagamentos regulada pela Resolução BCB 80/2021, a infraestrutura de email que entrega confirmações de transação, alertas de fraude, notificações KYC/AML e extratos cai no escopo regulatório da Resolução CMN 4.893/2021 (Política de Segurança Cibernética) e da Circular Bacen 3.909/2018. Para fintechs brasileiras com clientes europeus ou subsidiária europeia, soma-se o regulamento DORA (UE 2022/2554), em aplicação desde janeiro de 2025. As decisões de infraestrutura que funcionam para um SaaS B2C não funcionam aqui porque a resiliência operacional, a gestão do risco de terceiros e as cláusulas contratuais exigidas pelos supervisores financeiros são específicas e prescritivas.
O que a Política Bacen de Cibersegurança exige do seu provedor.
A Resolução CMN 4.893/2021 e a Circular Bacen 3.909/2018 estabelecem requisitos para contratação de serviços relevantes de processamento e armazenamento de dados e de computação em nuvem: avaliação prévia do risco operacional do provedor, registro do contrato no Bacen para serviços de cloud em até 60 dias da assinatura, cláusulas contratuais específicas (artigo 13 da Resolução 4.893: monitoramento, auditoria, plano de continuidade, plano de saída, notificação de incidentes), classificação de criticidade dos serviços contratados, manutenção do DRP (Diretor Responsável pela Segurança da Informação) com atribuições formais. Nosso plano Enterprise inclui as cláusulas alinhadas com o artigo 13 e a documentação para registro junto ao Bacen quando aplicável.
O que a DORA exige adicionalmente para empresas com atuação na UE?
Se sua fintech brasileira tem subsidiária financeira europeia ou presta serviço a entidade financeira europeia, DORA aplica em paralelo à regulação Bacen. O artigo 30 do DORA exige cláusulas contratuais específicas: descrição completa dos serviços, localizações de dados e operações, SLA com créditos, monitoramento, plano de continuidade, controles de subcontratação (artigo 28.7), direitos de auditoria, direitos de saída. O artigo 28 obriga a manter registro de informação no formato ITS publicado pela EBA. Para clientes brasileiros com dupla exposição regulatória, nosso plano Enterprise oferece dual-compliance: um único contrato com cláusulas alinhadas tanto com a Resolução Bacen 4.893/2021 quanto com o DORA artigo 30, evitando negociação duplicada com bufetes separados.
Particularidades do mercado brasileiro de pagamentos.
Três particularidades operacionais do mercado brasileiro impactam diretamente o email: (1) o PIX, criado em 2020 e operado pelo Banco Central, gera volume massivo de emails transacionais de confirmação de pagamento com SLA implícito de segundos entre recebimento do PIX e notificação ao usuário — qualquer atraso superior a 30 segundos é percebido como falha; (2) a Lei do Cadastro Positivo (Lei Complementar 166/2019) e o Bureau Positivo do Bacen geram comunicações estruturadas com prazos de oposição do consumidor; (3) o Open Finance brasileiro (Resolução BCB 32/2020 e seguintes) cria fluxo de notificações entre instituições participantes que exigem entrega garantida e rastreabilidade. Servimos esses casos com SLA de admissão sub-200ms e webhooks de notificação para integração com seus sistemas de monitoramento Bacen.
Como o reporte de incidentes da DORA afeta o seu provedor de e-mail?
A DORA obriga você a classificar um incidente TIC grave nas 24 horas seguintes a tomar conhecimento dele, a apresentar uma notificação inicial à sua autoridade competente nas 4 horas seguintes a essa classificação, um relatório intermediário em 72 horas e um relatório final com análise de causa-raiz em um mês. O relógio começa na classificação, não na detecção, então a própria decisão de classificar precisa ser rápida e ficar documentada. O RTS 2024/1772 fixa seis critérios —clientes afetados, perdas de dados, impacto reputacional, duração e indisponibilidade, extensão geográfica e custo econômico com limiar de 100 mil euros—, e um incidente é grave quando cruza dois deles, ou um de forma severa. Aqui está por que isso importa para um provedor de e-mail. Se param de chegar confirmações de transação ou prompts SCA e você não consegue saber se a causa está do seu lado ou do nosso, você não consegue classificar, e a janela de quatro horas já está correndo. O nosso tratamento de incidentes para clientes do setor financeiro é construído para alimentar essa janela em vez de competir com ela: contato com um CSM nomeado em 30 minutos a partir da detecção, uma avaliação inicial escrita em duas horas e um relatório de incidente escrito em 24 horas, que é o documento que você anexa às suas notificações inicial e intermediária. Você apresenta através da sua autoridade nacional assinando com o seu próprio certificado qualificado eIDAS; nós fornecemos os fatos técnicos na ordem em que a planilha do RTS 2025/301 os pede.
O e-mail transacional é um serviço TIC que suporta uma função importante.
Um erro recorrente no procurement fintech é arquivar o e-mail sob ferramentas de marketing. Sob a DORA o teste é funcional: o serviço suporta uma função crítica ou importante? O e-mail que transporta prompts de autenticação reforçada de cliente, alertas de fraude e de anomalias de login, confirmações de pagamento e entrega de extratos suporta funções que um supervisor vai ler como importantes, porque uma falha de entrega sustentada tem impacto direto sobre o cliente e sobre a prudência. Isso coloca o seu provedor de e-mail dentro dos acordos TIC com terceiros que os artigos 28 e 30 governam, o mesmo regime de registro e de contrato que você aplica ao provedor da sua plataforma de core banking, dimensionado ao risco real. A consequência prática é que o acordo não pode ser um contrato SaaS de aceite com um clique. Ele precisa das cláusulas do artigo 30(2): descrição do serviço, localizações de dados e de processamento, níveis de serviço, monitoramento e reporting, continuidade de negócio, controles de subcontratação, direitos de auditoria e termos de saída e portabilidade. O nosso addendum DPA Enterprise carrega cada uma delas como cláusula padrão em vez de negociação caso a caso, que é o que mantém a revisão jurídica em uma ou duas rodadas em vez de um trimestre de idas e vindas. Somos igualmente claros sobre o que não somos: não somos um Provedor TIC Crítico, porque essa designação as Autoridades Europeias de Supervisão fazem por motivos de importância sistêmica e a nossa base está bem abaixo. As suas obrigações do artigo 30 aplicam independentemente do nosso status CTPP, então o que importa são os termos e não o rótulo.
O que você precisa para o Registro de Informação da DORA?
O artigo 28 da DORA exige que toda entidade financeira mantenha um Registro de Informação que descreva os seus acordos TIC com terceiros, e que o apresente a cada ano à autoridade competente, com o prazo fixado em 30 de abril. O registro não é um inventário de texto livre. As Autoridades Europeias de Supervisão publicam um template estruturado com campos definidos: identificadores legais do provedor incluindo o LEI, a função suportada e se é crítica ou importante, localizações de dados e de processamento, datas de início e fim do acordo, a cadeia de subcontratação e uma avaliação de substituibilidade. Preencher esses campos para um provedor de e-mail que esconde a sua infraestrutura atrás de uma descrição genérica de "nuvem global" é doloroso, porque metade dos campos fica sem resposta. Aos clientes do setor financeiro damos um export do portal pré-mapeado aos campos do registro: a nossa entidade legal e o seu LEI, as localizações precisas dos datacenters UE em uso para aquela conta, a lista de suboperadores com os seus papéis e a data contratual de início. Quando a sua equipe de GRC monta o envio anual, a linha do e-mail se preenche a partir do nosso export em vez de ser reconstruída a partir de tickets de suporte antigos. Parece um detalhe menor até o prazo de 30 de abril estar a duas semanas e o registro ter um buraco onde deveria ir o provedor de e-mail.
Controles de subcontratação: a cadeia que você de fato assina.
O RTS de 2024 sobre subcontratação de serviços TIC que suportam funções críticas ou importantes endureceu o que as entidades financeiras devem conhecer e controlar sobre os provedores dos seus provedores. Você tem direito de ver a cadeia de subcontratação, de ser notificado das mudanças materiais antes de elas surtirem efeito e de se opor. Para um provedor de e-mail a cadeia é curta mas não está vazia: a conectividade de rede a montante, o CDN na frente do portal de cliente, o processador de pagamentos para o faturamento e qualquer feed de terceiros de dados semente ou de reputação. A nossa cadeia padrão para contas do setor financeiro fica escrita no addendum DPA em vez de enterrada numa página de suboperadores que muda sem aviso. Onde um supervisor nacional restringe suboperadores com matriz estadunidense para cargas sensíveis, podemos rotear evitando os defaults estadunidenses habituais com um CDN alternativo e gestão de pagamentos só-UE, por 499 euros por mês adicionais e cerca de duas semanas de configuração. Preferimos cotar isso com honestidade em vez de fingir que a configuração padrão já satisfaz uma restrição de residência que ela não cumpre.
Como DORA, NIS2 e PCI DSS se sobrepõem no e-mail?
Poucos remetentes regulados estão sujeitos unicamente à DORA. O artigo 21 da NIS2 acrescenta obrigações de segurança da cadeia de suprimentos e de tratamento de incidentes para entidades importantes e essenciais, e o provedor de e-mail de um banco faz parte dessa cadeia. O PCI DSS v4.0 transformou o tratamento de DMARC em um requisito para as organizações que processam dados de cartão de pagamento, o que puxa a autenticação de e-mail para a conversa sobre dados do portador do cartão. A parte útil é o quanto esses regimes compartilham. Um único conjunto de controles —DMARC em p=reject, processamento fixado na UE, prazos de incidente documentados, uma cadeia de suboperadores auditada e evidência anual de resiliência— responde de uma vez às partes dos três que tocam o e-mail. Estruturamos a conta do setor financeiro para que os mesmos artefatos sirvam a cada apresentação: a atestação de resiliência que produzimos a cada janeiro corresponde às expectativas de teste e reporting da DORA, suporta a narrativa de gestão de risco da NIS2 e dá ao seu avaliador PCI a evidência de autenticação de e-mail num só lugar. O objetivo é parar de responder as mesmas perguntas três vezes, em três formatos, para três auditores distintos.
O que quebra quando um banco regulado usa um hyperscaler estadunidense?
A comparação honesta vale a pena fazer, porque as equipes de procurement a pedem. SendGrid, Amazon SES, Mailgun e Postmark são remetentes competentes, e para um produto de consumo não regulado são escolhas padrão razoáveis. O problema dentro de uma entidade financeira UE regulada é estrutural antes de ser técnico. Cada um opera sob uma matriz corporativa estadunidense, o que torna o Schrems II uma questão de transferência viva que o seu DPO precisa documentar em vez de encerrar, e que mantém o CLOUD Act e o FISA 702 dentro do escopo da sua avaliação de impacto de transferência. Os seus contratos padrão são de aceite com um clique e não carregam as cláusulas do artigo 30(2) da DORA; conseguir que esses termos sejam adicionados, quando é possível, vira uma negociação sob medida que a equipe jurídica deles não está montada para mover rápido. O suporte é por níveis e por tickets, o que serve para uma pergunta de configuração e encaixa mal quando um relógio de quatro horas da DORA está correndo e você precisa de um engenheiro que saiba o que é um seletor DKIM e o que acontece quando uma IP cai numa lista da Spamhaus. Nada disso os torna ruins. Significa que o perfil regulatório e operacional de uma entidade financeira supervisionada é um problema distinto daquele que eles foram construídos para resolver, e a migração que vemos com mais frequência é um banco movendo os seus fluxos regulados voltados ao cliente para infraestrutura UE enquanto deixa o correio interno de baixo risco onde já está.
Saída e portabilidade, por escrito antes de você precisar.
O artigo 30 da DORA e as diretrizes de terceirização da EBA exigem ambos que um contrato para uma função importante detalhe uma estratégia de saída: como você recupera os seus dados e operações, e como se move para outro provedor ou para uma solução interna, sem uma brecha de continuidade inaceitável. Para o e-mail isso significa três coisas concretas. Os seus domínios de envio e os seus seletores DKIM continuam sendo seus e se movem com você. As suas listas de supressão, templates e dados históricos de eventos são exportados em formatos abertos. E a reputação que você construiu sobre IPs dedicadas não evapora na saída. O nosso contrato padrão do setor financeiro documenta uma janela de saída de 90 a 180 dias com passos de transferência definidos: um export completo de configuração e dados, um período de execução em paralelo no qual o provedor entrante aquece as suas próprias IPs enquanto nós seguimos entregando, e um cutover documentado. Colocamos isso por escrito na assinatura e não na rescisão, porque uma cláusula de saída negociada quando você já está indo embora vale muito pouco. Um supervisor que revise os seus acordos com terceiros vai pedir para ver o plano de saída, e você deveria conseguir entregá-lo sem redigi-lo na hora.