Quase toda plataforma do nosso setor se vende pela esperteza. Um modelo de risco proprietário, um motor de alocação único, uma linguagem específica para regras de compliance. Cada uma delas, um pequeno monumento à genialidade do time que a construiu.
O stack mais esperto raramente vence. O mais aberto quase sempre vence.
Uma breve história do vendor lock-in
A tecnologia de gestão de recursos passou por três ciclos. No fim dos anos noventa, o prêmio era substituir a planilha — a primeira geração de sistemas de controle de posição, que viviam ao lado da mesa. Nos anos 2000 e 2010, foi o PMS integrado — Aladdin, Geneva, SimCorp — prometendo absorver tudo, da gestão de ordens ao risco e ao reporte, debaixo de um teto só. Estamos agora no terceiro ciclo, em que a premissa de que um fornecedor pode ser dono crível do stack inteiro está sendo questionada pela primeira vez em vinte anos.
O motivo não é ideológico. É empírico. O stack integrado falhou em um trabalho específico: sobreviver à mudança sem um projeto de porte enterprise.
Três coisas a que todo stack sobrevive
Se você está construindo ou comprando tecnologia para uma gestora, o teste não é “isso funciona hoje?”. É “isso vai sobreviver às próximas três coisas que sempre acontecem?”.
O próximo regulador. A cada cinco ou sete anos cai uma diretriz nova. NCG 507. UAF. SBS. MiFID II. Os sistemas que sobrevivem são os que têm modelo de dados explícito, APIs abertas e o tipo de trilha de auditoria que você entrega ao regulador sem precisar de tradutor.
O próximo custodiante. Fusões, expansão para outro país, um mandato novo de family office que exige a Pershing. Os sistemas que sobrevivem são aqueles cuja camada de conectores é uma biblioteca, não uma integração feita do zero a cada vez.
O próximo CTO. As pessoas trocam de emprego. Roadmaps mudam. Os sistemas que sobrevivem são aqueles cujo código mora no seu repositório, cujos dados moram no seu banco, e cuja operação a próxima pessoa consegue assumir sem uma passagem de bastão de seis semanas.
O stack mais esperto raramente é o mais aberto. Mas o mais aberto é quase sempre o que ainda vai estar rodando daqui a dez anos.
O que “aberto” quer dizer de fato
É uma palavra escorregadia. Somos específicos sobre o que queremos dizer com ela. Três propriedades, em ordem de importância:
- Dados abertos. Os seus dados são seus. Esquema documentado. Exportação trivial. Sem formato binário proprietário. Sem fornecedor “segurando” o histórico de posições.
- APIs abertas. Toda ação que um usuário consegue fazer, uma API consegue fazer. Nada de “para isso você tem de usar a nossa interface”. A trilha de auditoria é, ela própria, uma API.
- Processo aberto. O roadmap é visível. As discordâncias acontecem à vista. O seu time consegue ler o issue tracker.
Percebemos que as gestoras que insistem nessas três propriedades acabam com uma tecnologia que capitaliza ao longo do tempo — mesmo quando peças individuais dela impressionam menos do que as alternativas. Os projetos de que desistimos costumam ser justamente aqueles em que um fornecedor (ou, às vezes, o time interno da própria gestora) está brigando contra uma dessas três.
Uma confissão
Já construímos ferramental proprietário. É claro que sim. A nossa biblioteca de conectores é propriedade intelectual de verdade, e cobramos pelo acesso a ela. O nosso motor de compliance tem regras que descobrimos no tranco e que só devolvemos ao resto do setor um ano depois.
Mas todo software que entregamos e que sobreviveu mais de três anos foi a opção mais aberta em relação à que tínhamos desenhado no início. Todo software que vimos morrer foi o mais esperto.
Sistemas fechados são sedutores. Parecem propriedade. Parecem um fosso. Na prática, são um imposto — pago sobretudo pelos operadores que os herdam.
Aberto ganha de esperto. Construa de acordo.
Santiago Fuentes é sócio-fundador da finnerve. Esta é uma de uma série ocasional de notas sobre o que aprendemos construindo tecnologia de gestão de investimentos com operadores da América Latina e da Europa.