Momento Pede Cautela com Aplicativos Financeiros

O site Protocol informa que as avaliações de valor das ações das fintechs têm despencado mais rápido e com mais força do que o resto do setor de tecnologia.

Fintech
Imagem: Pexels

De acordo com o artigo no Protocol,

um gráfico publicado pela a16z mostra que o pico de múltiplos [o que são ‘múltiplos’ no contexto das ações] de receita futura para empresas de fintech foi em outubro de 2021, quando atingiu quase 25x. Agora, caiu para menos de 5x. De acordo com dados da F-Prime Capital, esta é uma queda mais acentuada do que a verificada em outros setores da tecnologia.

Até 2019, as fintechs estavam em relativa sintonia com as altas das empresas emergentes dos serviços de nuvem. Entre 2020 e 2021 a valorização subiu como um foguete para ficar muito acima do desempenho das outras empresas de serviços de nuvem. Mas desde o início deste ano, o índice fintech da F-Prime vem caindo. Ele chegou a cair abaixo abaixo do índice de nuvem no final de março. À medida que as fintechs públicas estão vendo seus valores de mercado encolherem, será mais difícil para as empresas ainda privadas justificarem suas próprias avaliações exuberantes.

A queda das avaliações do mercado público golpeou o mercado com força extra esta semana. Mais startups de fintech começaram a fazer cortes. Das 19 demissões em massa listadas no Layoffs.FYI esta semana, nove foram em empresas financeiras. A Klarna disse aos funcionários, por meio de uma mensagem de vídeo, que demitiria 10% de sua força de trabalho. “Quando estabelecemos nossos planos de negócios para 2022, no outono do ano passado, era um mundo muito diferente do que estamos hoje”, disse o CEO Sebastian Siemiatkowski no vídeo.

Definições

Fintech é uma uma palavra composta da língua inglesa que significa “tecnologia financeira”. É um termo genérico para qualquer tecnologia usada para aumentar, simplificar, digitalizar ou competir com os serviços financeiros tradicionais.

Fintech refere-se a software, algoritmos e aplicativos para ferramentas baseadas em computador e dispositivos móveis. Em alguns casos, também inclui hardware – como cofrinhos inteligentes e conectados ou plataformas de negócios baseadas em realidade virtual (VR). As plataformas de fintech permitem que o usuário desempenhe tarefas comuns, como depositar cheques, movimentar dinheiro entre contas, pagar contas ou solicitar ajuda financeira.

Elas também abrangem conceitos tecnicamente complexos, como empréstimos ponto a ponto ou trocas de criptomoedas. Essa complexidade, porém, não impede que influencers [atrizes da lista B, designers de unhas, coaches de maquiagem, nutricionistas autodidatas] e figuras do entretenimento [cantores de funk, DJ’s, sofredoras sertanejas, etc.] posem de consultores financeiros a exaltar as fintechs no horário nobre da televisão e nas infames redes sociais.

Os bancos usam fintechs para processos de back-end – monitoramento da atividade da conta, por exemplo – e soluções voltadas para o consumidor, como o aplicativo que você usa para verificar seu saldo. Indivíduos usam fintech para tudo, desde cálculos de impostos até incursões nos mercados, sem necessidade de experiência prévia em investimento (o horror, o horror!).

As empresas contam com as fintechs para processamento de pagamentos, transações de comércio eletrônico, contabilidade e, mais recentemente, para buscar assistência em programas de assistência governamental. Após a pandemia da COVID-19, mais e mais empresas estão recorrendo às fintechs para habilitar recursos como pagamentos “sem fricção” ou outras transações baseadas em tecnologia.

Aumento da concorrência global

Historicamente, as instituições financeiras tradicionais sempre foram protegidas pelas condições nacionais de seus respectivos mercados. Dentro de cada jurisdição nacional há um conjunto diferenciado de condições e regulamentações financeiras, gerando instituições financeiras compatíveis com serviços adaptados às necessidades locais.

Nos últimos anos, no entanto, essas fronteiras nacionais foram rapidamente erodidas, impulsionadas pela rápida ascensão de empresas de fintech que oferecem soluções financeiras globais. Como resultado, as finanças institucionais foram forçadas a competir de passo a passo com essas empresas aparentemente ágeis ou aprender a cooperar e estabelecer parcerias com elas.

Essa dinâmica do “tradicional versus ágil” alimentou um cenário competitivo em todo o mundo, e os jogadores que desejam prevalecer nessa corrida precisam escolher suas alianças estratégicas com sabedoria.

No caso de muitas fintechs, buscar alianças com terceiros não é uma escolha. Seus modelos de negócios realmente dependem disso. Para as equipes de operações computacionais, a pressão adicional da concorrência e a necessidade de contratar serviços e parcerias de terceiros para se manter à frente são fontes de risco operacional que podem aumentar a exposição além de qualquer controle.

‍Responsabilidade profissional e pessoal

No final das contas, a maioria das fintechs fornece ou habilita um serviço financeiro.

Isso – por si só – expõe a empresa à negligência, erros de serviço, reclamações de fraude e vários outros riscos comuns associados a serviços financeiros. As fintechs, que oferecem produtos financeiros totalmente novos por meio de modelos de serviços inovadores, são especialmente propensas a se encontrar no lado errado das reivindicações de responsabilidade profissional.

Em geral, o problema é de desajuste: as fintechs geralmente sobrecarregam sua própria capacidade operacional e não padronizam novos processos, gerando assim cada vez mais erros. Os consumidores, por outro lado, são propensos a usar os aplicativos de fintech com pouca atenção, sem conhecimento básico de tecnologias da web e quase sempre sem tomar medidas de precaução para proteger a si mesmos, seus dados e seu dinheiro.

Fintechs têm o dever ético de mitigar os riscos operacionais

O risco operacional é o risco de fazer negócios com fintechs, e gerenciar esse risco é uma prioridade inevitável para qualquer liderança de operações. Na maioria das vezes, a maior exposição ao risco pode ser encontrada em processos operacionais mal implementados. A mitigação de riscos geralmente começa com a aplicação de uma estrutura de avaliação de riscos testada e comprovada, e não há garantia de que os aplicativos de fintech populares estejam preocupados com esses aspectos. O marketing irreverente dessas empresas na televisão brasileira e na Internet, usando Youtubers e figuras dos reality shows, não me ajuda a ter muita confiança.

Para terminar

Sem uma abordagem sistemática para definir e demonstrar o comportamento ético, a insistência em uma suposta superioridade prática das fintechs vai sair pela culatra. À medida que a adoção de fintechs continua a aumentar, haverá um número crescente de instâncias em que as fintechs falharão no teste da ética e da segurança operacional. Mesmo que a porcentagem dessas falhas seja menor entre as fintechs do que entre as instituições financeiras tradicionais, isso não ajudará a diminuir as percepções de alto risco associadas a elas.

As fintechs fariam um favor a si mesmas ao abandonar a perigosa superficialidade em seu marketing e a retórica vazia da “conveniência”, em favor da adoção de procedimentos operacionais e de supervisão ética de alto padrão, além de focar na resolução dos complexos problemas dos consumidores e clientes. Se elas estão à altura desses desafios logo saberemos.

PS: Este post se refere aos acontecimentos do momento nos mercado avançados. Essas tendências se refletem, às vezes com um pequeno atraso, nos mercados periféricos, como o Brasil, mas sempre se refletem. Lembro aos leitores que uma gripe lá acaba sendo uma pneumonia aqui.

Fontes adicionais:

https://www.forbes.com

https://www.weforum.org/

Bug nos Smart Contracts aciona um alerta jurídico

Na última quinta-feira [02/12] o blog “Schneier on Security” divulgou o caso [e deu início a uma discussão técnica] do hacker que roubou US $ 31 milhões da empresa de blockchain MonoX Finance, explorando um bug no software que o serviço usa para redigir contratos inteligentes.

Imagem: Pexels.com

Especificamente, o atacante usou o mesmo token tanto para o tokenIn quanto para o tokenOut, que são métodos para trocar o valor de um token por outro neste tipo de operação. Funciona mais ou menos assim: O MonoX atualiza os preços após cada troca, calculando novos preços para ambos os tokens [in e out]. Quando a troca é concluída, o preço do tokenIn, ou seja, o token que é enviado pelo usuário, diminui, e o preço do tokenOut, o token recebido pelo usuário, aumenta.

Ao usar o mesmo token para as diferentes operações de tokenIn e tokenOut, o hacker inflou muito o preço do token MONO porque a atualização do tokenOut sobrescreveu a atualização de preço do tokenIn. O hacker então trocou o token por $ 31 milhões em tokens nas blockchains Ethereum e Polygon.

O problema básico neste evento é que, na arquitetura da blockchain, o código é a autoridade final – não há um protocolo de adjudicação. Então, se houver uma vulnerabilidade no código, não há recurso possível [e, claro, existem muitas vulnerabilidades no código].

Para muito observadores, incluindo Bruce Schneier, essa é uma razão suficiente para não usar contratos inteligentes para algo importante, por enquanto.

Os sistemas de adjudicação baseados na intervenção humana não são uma inútil bagagem humana pré Internet. Eles são vitais.

Bruce Schneier

Código de programação versus arbitragem humana

Na modesta opinião deste bloguista, embora, de fato, estejamos muito longe de o código ser um árbitro da justiça melhor do que um ser humano, acho que o problema básico aqui tem menos a ver com o código sendo a autoridade final e mais a ver com a falta de um protocolo de adjudicação.

No momento, não há uma boa maneira de ajustar retrospectivamente os resultados desses chamados contratos “inteligentes” com base em conhecimentos ou fatos que só podem ser totalmente apreciados ex post ao invés de ex ante, seja o conhecimento de funcionalidades não intencionais do código ou circunstâncias específicas não antecipadas pelas partes contratantes.

Este parece ser um problema bem compreendido por profissionais do direito e um aspecto amplamente suportado por diversos sistemas jurídicos (por meio de várias doutrinas, como quebra de expectativa ou previsibilidade). Já os tecnologistas proponentes de contratos inteligentes [incluindo a mim] parecem não ter ainda uma visão clara desses aspectos.

Uma transferência legítima de acordo com as regras codificadas

Para além do ‘problema básico’ descrito acima, existe um outro problema não menos básico e que se não for tratado corretamente deixará os “Contratos Inteligentes” para sempre quebrados: a maioria dos programadores normalmente escreve código sequencial limitado, não código de máquina de estado completo. Assim, uma grande quantidade elementos computacionais é deixada de fora na implementação dos contratos. Esses elementos, portanto, ficam “pendurados” e esperando para ser usados [e abusados].

Alguns críticos da blockchain dos contratos inteligentes argumentam que seria necessário incorporar uma versão forte da chamada Lógica de Hoare para garantir a integridade da computação na blockchain. A lógica de Hoare é um conjunto fundamental de regras, publicadas no final dos anos 1960. O bloco fundamental da Lógica de Hoare é a Tripla de Hoare.

Uma tripla de Hoare é da forma

{P} C {Q}

Onde {P} e {Q} são afirmações sobre o estado do sistema e C é um comando.

P, é a pré-condição
Q, é a pós-condição

Onde as asserções P e Q são expressas como fórmulas na lógica de predicados.

Quando a pré-condição P é atendida, a execução do comando C causa mudanças no sistema e estabelece a pós-condição Q.

Embora seja possível construir um código de “estado completo” com a lógica de Hoare, não é algo que a maioria das pessoas goste de fazer. Em suma, é um processo tedioso, não criativo, e colocar os pingos nos i’s e cruzar os t’s podem ser tarefas incrivelmente tediosas. Portanto, raramente é implementada, o que acaba inevitavelmente trazendo problemas em um tempo futuro.

Na vida normal, a última coisa que alguém realmente deseja é ter contratos irrevogáveis. Então a arbitragem geralmente fica “embutida” informalmente nos contratos inteligentes, através de métodos ad hoc. Em princípio, não há razão para que os contratos inteligentes não possam ter arbitragem embutida. Mas isso apenas cria uma série de questões subsequentes que ninguém quer abordar.

Até que a arbitragem de fato ou o controle total do estado sejam implementados nos Smart Contracts, veremos muito mais desse tipo de coisa acontecendo.

Move fast, break things

Eu temo que o problema descrito aqui seja um resultado lógico da abordagem “mova-se rápido e quebre coisas” preconizadas pelo Manifesto Ágil. As pessoas precisam pensar com clareza sobre até onde [e se] podemos utilizar certos paradigmas de desenvolvimento de sistemas na construção da infraestrutura da blockchain.

E como eu disse em outros posts aqui, precisamos parar de chamar as coisas de “inteligentes” quando elas são estúpidas. Antigamente, um dispositivo que não era útil sem uma conexão de rede era apropriadamente chamado de terminal burro. O código é sempre vulnerável, e qualquer desenvolvedor que não entenda isso é um “stupid hire”.

Facebook Muda de Nome Rumo ao Metaverso

O Facebook costumava ser visto de forma positiva pelos usuários, pois conectava o mundo e aproximava as pessoas. Isso não é mais o caso. Tem havido escândalos após escândalos e os usuários agora associam o Facebook a todas as coisas negativas que o Facebook dizia combater.

Imagem: Pexels

Neste ponto da história, o Facebook não pode mais vencer a guerra para ganhar os corações e mentes das pessoas a respeito uma série de questões. Então, em vez disso, ele precisa construir “uma nova narrativa”. A empresa está, assim, abandonando o nome e a marca Facebook e se concentrando em uma nova visão em torno do chamado Metaverso.

Não importa se essa visão é possível ou não, ou se a realidade virtual (RV) vai ou não se tornar o próximo paradigma de interação social. O importante é que trata-se de um segmento novo e interessante para construir uma nova marca e Mark Zuckerberg não quer perder a oportunidade.

O metaverso em minha opinião, sempre foi um grande embaraço. O Second Life existe há 20 anos e ainda é uma novidade divertida. O que o Facebook quer é adicionar publicidade e conteúdos de marca e fazer um second-life mais caro devido aos requisitos de hardware de última geração [além de torná-lo mais lento, com uma interface mais difícil – porque é RV].

Ninguém descobriu ainda uma maneira de proporcionar uma boa experiência de usuário em sistemas de realidade virtual, e também nenhum “caso de uso matador”. Não acho que o Facebook seja particularmente capaz de lançar algo que possa competir com qualquer coisa que a Microsoft ou a Apple possam lançar. Todos os CEOs que compram essa ideia de metaverso só falam sobre o universo de possibilidades, mas sinto que a única possibilidade que estão eles perseguindo é construir um Wal-Mart na Times Square.

A maioria desses CEOs aponta com aprovação o execrável [filme] “Jogador 1” como exemplo de uma visão a ser realizada. Eu sinto muito, mas penso que um garoto excitado de 15 anos raspando os pêlos do corpo para ser mais aerodinâmico na RV, enquanto se envolve em extensos monólogos de autocongratulação sobre como ele é um cara legal por não sentir repulsa por sua namorada “rubenesca”, enquanto recita versos de Ghostbusters em uma série de vinhetas incoerentes do tipo “lembra disso?”, não é uma visão para o futuro.

É uma pena porque acho que há obviamente usos legítimos para a telepresença via RV. Ela pode ser a próxima fronteira da videochamada, o que parece estar de acordo com a missão declarada do Facebook de conectar o mundo. Mas, suspeito que na realidade tudo o que nós teremos será um videogame extremamente ruim em vez disso – será que eles também terão NFTs?.

Posso ver como pode ser frustrante administrar uma empresa cheia de esforços diferentes, alguns dos quais pretendem ser novidadeiros ou pelo menos representar uma mudança de direção. Mas, debalde todos os esforços, ainda assim não deixam de ser percebidos e lembrados como mais uma coisa azul.

Espero que essa jogada permita que Zuckerberg permaneça tecnologicamente relevante, ocupando o lugar ao qual seus dons pessoais o levaram, em vez de ficar atolado em questões sobre os padrões éticos [ou falta de] em suas plataformas usadas por adolescentes e crianças.

Idealmente, uma plataforma ética também poderia ser cultivada por meio de algum tipo de transferência de parte do poder tecnológico acumulado pelas Big Techs à comunidade, de alguma forma. Um dos maiores desafios para o futuro é, em minha opinião, permitir que tais sistemas éticos se desenvolvam de forma padronizada, mas de maneira diversa. Em um mundo ideal, cada nova comunidade ou grupo deve ter sua própria dinâmica psicológica e merece a oportunidade de existir sem ser arrastada para a mesmice da(s) plataforma(s) por um conjunto agressivo, irritado ou tóxico de usuários.

Sinceramente, me deprime que esse revival do termo metaverso esteja sendo levado a sério e que provavelmente irá grudar no vocabulário como o desprezível termo “nuvem” e, pior, que o desenvolvimento dessas tecnologias esteja sendo conduzido por uma empresa como o Facebook.

Pessoalmente não estou interessado na visão particular de Mark Zuckerberg sobre o metaverso. Em vez disso, tenho medo de quantos mais caminhos errados podemos tomar no modo como desenvolvemos nossa tecnologia da informação e a aplicamos na sociedade. A visão FOSS [Free Open-Source Software – software livre] da computação, em que o progresso do software é compartilhado e atua como um equalizador, e onde as pessoas controlam o comportamento do seu software é o que precisamos, e não um lixo novo e melhor de vigilância-vigilância-propaganda-usuário-hostil [Agora em 3D!]

Voltaremos ao tema, certamente.

Multiplique sua Estimativa por Pi

A estimativa de projetos é uma arte hermética, em nenhum lugar isso é mais verdadeiro do que no desenvolvimento de sistemas computacionais. Certa vez, ouvi falar de uma misteriosa confraria de numerólogos, que multiplicavam suas estimativas de tempo por π. A prática supostamente dava a eles uma margem de segurança suficiente para definir novos requisitos, testes, iteração e outras mudanças aleatórias no escopo do projeto.

Imagem: Pexels

Isso me pareceu curioso e arbitrário, mas fiquei intrigado. Depois de refletir um tanto, pude colocar a conjectura da estimativa circular (CEC) em bases matemáticas sólidas.

Alguém – um designer, seu líder, o produtor executivo, um amigo, sua mãe – pede que você faça algo. Você pensa um pouco, faz algumas anotações, considera o que é necessário e apresenta um projeto e uma estimativa de tempo para a conclusão.

Mas as coisas mudam. Acontece que havia algumas coisas que seu designer/ líder/produtor/ amigo/mãe esqueceu de mencionar e, à medida que você fazia o trabalho, sugiram algumas ideias para estender o projeto um pouco mais. Seu escopo cresceu.

E é claro que nem tudo correu bem. Sua primeira tentativa foi um fracasso [instrutivo]. Então você focou na segunda tentativa e acabou criando uma serie de problemas que demoraram um tanto mais para serem ajustados. Você gastou dois dias extras para encontrar uma solução alternativa. Em suma, você seguiu um caminho positivamente tortuoso até seu objetivo.

Quanto tempo demorou a sua jornada em comparação com o plano original? Parece que os numerólogos estavam certos…

E aí está – não importa o que você pense quando começa um projeto. Depois de passar pela pesquisa, design, discussões, protótipos, falhas, testes, rotatividade de requisitos e todos os outros caprichos do processo criativo, você certamente terá gasto π vezes o tempo que você planejou originalmente.

Alguns podem questionar meu rigor matemático e até mesmo contestar o que acredito ser a conclusão incontestável. Alguém poderá alegar que o multiplicador correto não é de fato π – mas 2, ou √2, ou e, ou a razão áurea φ. No entanto, não conheço ninguém que chegue a alegar que o multiplicador seja < 1.

Independentemente de quaisquer inclinações numerológicas, o argumento é que você se permita admitir que no início de um projeto você a) não tem o panorama completo, b) você não sabe como as coisas vão se encaminhar, e c) há trabalho pela frente sobre coisas que você ainda não tem ideia.

Nenhuma quantidade de planejamento e análise de tarefas pode mudar isso, então não tente. Em vez disso, dê a si mesmo uma reserva de tempo plausível e então mergulhe no trabalho.

Ah, e aquela lista de tarefas que você fez no fim de semana passado? Não é por acaso que você conseguiu concluir apenas cerca de um terço dos itens da lista. ;-)

Os Perigos do Software Evidencial – ou Quem Garante o Bafômetro?

No Lawfare Blog, Susan Landau escreve um excelente ensaio sobre os riscos apresentados pelos aplicativos usados em dispositivos de coleta de evidências (um bafômetro é provavelmente o exemplo mais óbvio). Bugs e vulnerabilidades nessa classe de equipamento podem levar a evidências imprecisas. Para compor o problema, a natureza proprietária do software torna difícil para a equipe de defesa dos réus examiná-lo. A seguir um brevíssimo resumo da essência do material.

Imagem: iStock

[…]

Os engenheiros de software propuseram um teste de três partes.

Primeiro, o tribunal deve ter acesso ao “Log de erros conhecidos”, algo que deve fazer parte de qualquer bom projeto de software desenvolvido profissionalmente.

Em seguida, o tribunal deve considerar se as provas apresentadas podem ser afetadas materialmente por um erro de software. Ladkin e seus co-autores observaram que a maioria das funcionalidades não apresentará erro, mas o momento preciso em que o software registra o uso do dispositivo pode facilmente estar incorreto.

Finalmente, os especialistas em confiabilidade recomendaram verificar se o código adere a um determinado padrão da indústria usado em uma versão não computadorizada da tarefa (por exemplo, os contadores sempre registram todas as transações – portanto, o software usado na contabilidade também deve registrar).

[…]

Objetos inanimados há muito servem como prova em tribunais: a maçaneta da porta contendo uma impressão digital, a luva encontrada na cena de um crime, o resultado do bafômetro que mostra um nível de álcool no sangue três vezes o limite legal. Mas o último desses exemplos é substancialmente diferente dos outros dois. Os dados de um bafômetro não são a entidade física em si, mas sim um cálculo de um software a respeito do nível de álcool no hálito de um motorista potencialmente bêbado. Desde que a amostra de respiração tenha sido preservada, pode-se sempre voltar e testá-la novamente em um dispositivo diferente.

O que acontece se o software cometer um erro e não houver mais nenhuma amostra para verificar? Ou, e se o próprio software produzir a evidência contra o réu? No momento em que escrevemos este artigo, não havia nenhum precedente no qual a lei permita que o próprio réu examine o código subjacente.

[…]

Dada a alta taxa de erros em sistemas de software complexos, meus colegas e eu concluímos que, quando programas de computador produzem uma prova, os tribunais não podem presumir que o software probatório seja confiável. Em vez disso, a acusação deve disponibilizar o código para uma “auditoria contraditória” pelos especialistas designados pelo réu[1]. E para evitar problemas em que o governo não tenha o código para que este seja inspecionado, os contratos de compras governamentais devem incluir a garantia de entrega do código-fonte do software adquirido – código que seja mais ou menos legível pelas pessoas – para cada versão do código ou dispositivo.

Ler o trabalho na íntegra [em inglês] em Lawfare Blog.

* * *

O comentário pertinente é: o Estado pode exigir calibração regular do bafômetro, mas quem os inspeciona? Há garantia de que o poder público multará a polícia por não verificar se os bafômetros estão calibrados de forma adequada além de estar também funcionando corretamente? E quem calibra os calibradores?

Se nenhuma amostra da respiração for retida, apenas o registro da observação do software, como a leitura de um bafômetro é essencialmente diferente de um boato ou palavra-de-boca? Será porque o bafômetro é “tecnológico”? Assumir que o instrumento é mais preciso que uma testemunha humana, apenas porque é tecnológico, gera outros grandes problemas conceituais.

Mas acho que o ponto mais amplo é este: dada a quase total falta de responsabilidade da indústria do software, a inescrutabilidade do código proprietário e a qualidade duvidosa da maioria do software comercial, um tribunal – que busca a verdade – não deve acolher prima facie evidências que consistam exclusivamente do resultado de um software.

Este não é um problema técnico, mas um problema legal causado por políticas inadequadas: a indústria do software precisa de regulamentação, responsabilidade e reforma das leis de direitos autorais.

[1] Um especialista que consultei – que um dia estará escrevendo neste espaço, gentilmente me explicou [o que agradeço penhoradamente] que esse protocolo não existe no ordenamento brasileiro. Mas da explicação depreendo que a lei brasileira pode comportar soluções análogas a essa.