Cartões de débito cripto expõem riscos de provedores de pagamento compartilhados

SOL
infraestrutura de pagamento compartilhadagarantia em stablecoinbanking-as-a-servicecartões de débito criptoinsolvência da Kulipaexploit da Rainbanco patrocinador
há 1 horaFonte: crypto.news
Cartões de débito cripto expõem riscos de provedores de pagamento compartilhados

Falhas em cartões de débito cripto expuseram o quão pouco controle algumas marcas de carteiras e fintechs detêm sobre seus serviços de pagamento, com uma exploração de contrato da Rain de US$ 1,1 milhão ilustrando os riscos da infraestrutura compartilhada.

Resumo

  • Bancos, processadores e middleware compartilhados podem deixar marcas de cartões separadas expostas à mesma falha.
  • A exploração da Rain em agosto teve como alvo saldos de cartões financiados, deixando as carteiras pessoais e as chaves privadas dos clientes intactas.
  • Ron Tarter, CEO do MNEE App, recomenda relacionamentos bancários diretos e registros de clientes acessíveis de forma independente.
  • O seguro de depósitos dos EUA cobre depósitos bancários elegíveis contra a falha do banco, não o colapso de um provedor fintech.

Ron Tarter, cofundador e CEO do MNEE App, disse ao crypto.news que empresas que dependem fortemente de plataformas de banking-as-a-service podem controlar pouco além de seu aplicativo, design do cartão e marketing.

Um banco patrocinador fornece as permissões bancárias e mantém depósitos em moeda fiduciária, enquanto um processador autoriza transações. Verificações de identidade, conformidade, prevenção de fraudes e serviços de carteira cripto podem ficar com fornecedores separados, explicou ele.

“Você pode ter milhões de usuários e uma marca forte e ainda assim não deter a autoridade final sobre seu próprio produto.”

Marcas de cartões de débito cripto dependem de decisões upstream

No relato de Tarter, fundadores frequentemente subestimam a autoridade do banco patrocinador. Um banco ou gerente de programa pode restringir ou encerrar um programa que considere arriscado demais, deixando a empresa voltada ao consumidor incapaz de restaurar o serviço por conta própria.

Ele citou a insolvência da Kulipa no verão, que, segundo ele, interrompeu programas de cartões que atendiam cerca de vinte carteiras e fintechs. Os clientes, acrescentou, podem descobrir uma interrupção apenas ao tentar pagar.

Incidentes separados envolveram perdas dentro da infraestrutura que sustenta os pagamentos. A Gnosis disse que seu ataque de 1º de junho explorou módulos de software usados por seu sistema card-safe, forçando os serviços de cartão a ficar offline. Seu postmortem de 3 de julho disse que os atacantes extraíram US$ 1,5 milhão e tornaram outros US$ 300.000 inacessíveis. A empresa absorveu as perdas e restaurou os fundos dos usuários, conforme abordado na reportagem sobre a exploração de junho.

Em 28 de agosto, um contrato desatualizado da Rain expôs vários programas de cartões baseados em Solana a aproximadamente US$ 1,1 milhão em roubo, de acordo com as descobertas da Blockaid detalhadas na exploração do cartão Rain. O atacante teve como alvo a garantia em stablecoin depositada para gastos com cartão, sem acessar carteiras pessoais ou chaves privadas.

Registros de clientes precisam sobreviver ao colapso de um provedor

Antes de selecionar um parceiro, Tarter recomenda estabelecer exatamente onde o dinheiro do cliente está: contas bancárias individuais ou uma conta agrupada mantida para clientes, comumente descrita como conta FBO.

Com fundos agrupados, disse ele, as empresas devem perguntar quem reconcilia o livro-razão de clientes, com que frequência isso acontece e se o banco mantém sua própria cópia. Suas salvaguardas preferidas incluem contas individuais em nome dos clientes e cópias diárias de saldos e registros mantidos pela marca.

A proteção de seguro dos EUA tem condições separadas. A análise de aplicativos de pagamento do Consumer Financial Protection Bureau explica que o seguro de depósitos pass-through depende do cumprimento de requisitos regulatórios. O seguro de depósitos protege contra a falha do banco segurado; não cobre a falha da empresa de aplicativo não bancária.

Para verificações de segurança, o executivo recomenda avaliações independentes, como relatórios SOC 2 Type II, e perguntas sobre como uma plataforma supervisiona outros programas que compartilham sua infraestrutura. As discussões sobre seguro devem estabelecer o tamanho das perdas cobertas e se um incidente grave poderia sobrecarregar financeiramente o provedor.

Parceiros de backup podem compartilhar o mesmo banco subjacente

Escolher dois provedores não necessariamente cria arranjos de backup independentes, alertou Tarter. Ambos podem depender do mesmo banco patrocinador, deixando a marca exposta às decisões de uma única instituição.

Múltiplos emissores e processadores de backup podem ajudar durante interrupções mais curtas, disse ele, mas cada relacionamento traz outra integração técnica, processo de conformidade e livro-razão a reconciliar. Fintechs maiores podem arcar com esses arranjos mais facilmente; empresas menores podem ter dificuldades com o custo e o trabalho envolvidos.

“Passar pela análise de crédito de um banco nos levou mais de um ano.”

Uma violação de dados separada em novembro na Gnosis Pay afetou seus cartões de consumo da marca, enquanto a empresa disse que sua plataforma empresarial e os fundos dos clientes não foram afetados.

Para se preparar para a falha de um provedor, Tarter recomenda direitos contratuais diretos para continuar um programa ou transferi-lo, juntamente com períodos de aviso prévio antes da rescisão. Ele disse que a MNEE anteriormente abandonou os planos de lançar contas FBO por meio de um provedor não identificado após preocupações sobre a falta de um relacionamento bancário direto. O provedor subsequentemente encerrou as atividades e entrou em processo de Chapter 11, segundo seu relato.