A falha no cartão de débito criptografado revelou que algumas carteiras e marcas de fintech têm controle limitado sobre seus serviços de pagamento; o vazamento de contrato da Rain, no valor de US$ 1,1 milhão, ilustra os riscos associados à infraestrutura compartilhada.
- Bancos, processadores e middleware compartilhados podem expor simultaneamente diferentes marcas de cartões ao mesmo tipo de falha.
- A vulnerabilidade enfrentada por Rain em agosto afetou apenas os saldos dos cartões carregados; as carteiras pessoais e as chaves privadas dos clientes não foram afetadas.
- Ron Tarter, CEO da MNEE App, sugeriu estabelecer relações diretas com bancos e garantir que os registros dos clientes sejam acessíveis de forma independente.
- A proteção de depósitos dos Estados Unidos cobre depósitos bancários elegíveis em caso de falência do banco, e não da falência do provedor de serviços de tecnologia financeira.
Ron Tarter, cofundador e CEO da MNEE App, disse ao crypto.news que empresas que dependem fortemente de plataformas de banking-as-a-service podem ter quase nenhum controle sobre outros aspectos, além do aplicativo, do design do cartão e do marketing.
Ele explicou que o banco patrocinador fornece a licença bancária e detém depósitos em moeda fiduciária, enquanto o processador é responsável por autorizar transações; a verificação de identidade, conformidade, anti-fraude e serviços de carteira criptográfica também podem ser realizados por fornecedores distintos.
Você pode ter milhões de usuários e uma marca poderosa, mas ainda assim não ter a última palavra sobre seu próprio produto.
As marcas de cartões de débito criptografados dependem de decisões upstream
Segundo Tarter, os fundadores frequentemente subestimam o poder dos bancos patrocinadores. Se o banco ou a entidade gestora do projeto considerar que um projeto apresenta risco excessivo, pode limitar ou encerrá-lo, enquanto empresas voltadas ao consumidor não conseguem restaurar os serviços por conta própria.
Ele mencionou que a Kulipa entrou em insolvência durante o verão, o que perturbou os projetos de cartões de aproximadamente 20 carteiras e empresas de fintech. Os clientes só podem descobrir a interrupção do serviço ao tentar fazer um pagamento.
Outros incidentes independentes envolveram perdas dentro da infraestrutura de pagamento. A Gnosis afirmou que o ataque de 1º de junho explorou um módulo de software utilizado pelo sistema de segurança do cartão, forçando o serviço de cartões a ser desativado. A análise pós-ataque divulgada pela empresa em 3 de julho indicou que os atacantes retiraram 1,5 milhão de dólares e tornaram outros 300 mil dólares inacessíveis. A empresa assumiu as perdas e recuperou os fundos dos usuários, com detalhes anteriormente divulgados nos relatos de vulnerabilidade de junho.
Segundo a investigação da Blockaid sobre a vulnerabilidade do cartão Rain, em 28 de agosto, um contrato obsoleto do Rain expôs diversos projetos de cartões baseados no Solana a um risco de roubo de aproximadamente US$ 1,1 milhão. Os atacantes visaram os ativos de garantia em stablecoins depositados para consumo de cartão, sem acessar carteiras pessoais ou chaves privadas.
Os registros dos clientes devem permanecer disponíveis após a falência do provedor de serviços.
Antes de escolher um parceiro, Tarter sugere esclarecer onde exatamente os fundos dos clientes estão armazenados: em uma conta bancária separada ou em uma conta agregada mantida em nome dos clientes, geralmente chamada de conta FBO.
Para os fundos consolidados, ele disse que a empresa deveria perguntar quem está realizando o conciliamento das contas dos clientes, com que frequência esse conciliamento ocorre e se o banco mantém sua própria cópia. As medidas de segurança que ele prefere incluem: abrir contas separadas em nome dos clientes e que a marca detenha cópias diárias dos saldos e registros.
A proteção de seguro nos Estados Unidos possui condições separadas. A Análise da Agência de Proteção Financeira do Consumidor dos Estados Unidos sobre aplicativos de pagamento indica que a cobertura de seguro de depósito depende do cumprimento dos requisitos regulatórios. O seguro de depósito protege contra o risco de falência de bancos segurados, mas não cobre a falência de empresas de aplicativos não bancários.
Em relação à segurança, o executivo recomendou avaliações independentes, como relatórios SOC 2 Type II, e perguntou como a plataforma supervisiona outros projetos que compartilham sua infraestrutura. Em relação ao seguro, deve-se esclarecer a escala das perdas cobertas e se o provedor conseguirá suportar financeiramente em caso de um grande incidente.
Parceiros alternativos também podem compartilhar o mesmo banco subjacente
Tarter alertou que escolher dois provedores não significa necessariamente estabelecer um arranjo de backup verdadeiramente independente. Ambos podem depender do mesmo banco patrocinador, deixando a marca ainda exposta às decisões da mesma instituição.
Ele afirmou que múltiplas emissoras e processadores de reserva ajudam a lidar com interrupções curtas, mas cada camada adicional significa uma nova integração técnica, processos de conformidade e livros contábeis que precisam ser reconciliados. Grandes empresas de tecnologia financeira têm mais facilidade para suportar esses arranjos; empresas menores podem ter dificuldade em arcar com os custos e a carga de trabalho associados.
Levamos mais de um ano para passar pela aprovação de crédito de um banco.
Sua sugestão é revisar cada intermediário, obter a lista de subcontratados e confirmar se é possível entrar em contato diretamente com o banco patrocinador. O contrato deve abranger cenários como a aquisição, encerramento, vulnerabilidade de segurança ou decisão de retirada dos serviços dos fornecedores upstream.
Uma outra violação de dados em novembro afetou os cartões de consumidor da Gnosis Pay, mas a empresa afirmou que sua plataforma empresarial e os fundos dos clientes não foram afetados.
Para lidar com a falência de provedores, Tarter sugere incluir nos contratos o direito de continuar operando o projeto ou migrá-lo diretamente, além de estabelecer um período de notificação antes da rescisão. Ele afirmou que a MNEE anteriormente desistiu de implementar uma conta FBO por meio de um provedor não identificado, devido à preocupação com a falta de relacionamento bancário direto. Segundo ele, esse provedor posteriormente falhou e entrou em processo de falência sob o Capítulo 11.