Como categorizar transação bancária automaticamente

Categorizar extrato parece o tipo de problema que se resolve numa tarde. Você olha algumas centenas de transações, percebe os padrões, escreve as regras, e pronto.

E funciona mesmo. Nas primeiras centenas.

O problema aparece quando o décimo cliente entra e metade do extrato dele cai em "outros".

O conceito

Categorizar transação bancária automaticamente é classificar cada lançamento num conjunto fixo de categorias, a partir da descrição, do valor, do sinal e do contexto da conta.

Dá para fazer com regra. Dá para fazer com modelo. A escolha entre as duas não é ideológica, é uma questão de quanto da cauda longa você precisa cobrir.

Por que regra para de funcionar

Todo mundo começa por regra, e está certo em começar. O ponto é saber onde ela trava.

A descrição bancária brasileira não tem padrão. Cada instituição escreve do seu jeito, com limite de caracteres próprio e abreviação própria. O mesmo estabelecimento aparece escrito de várias formas dependendo de onde a compra passou.

O adquirente aparece no lugar do lojista. Em compra com cartão, boa parte das descrições carrega o prefixo da maquininha ou do intermediador, e não o nome de quem vendeu. A regra casa com o intermediador, não com o negócio.

Em Pix, a descrição é texto livre. Literalmente o que a pessoa digitou na hora de transferir. Não tem padrão a ser descoberto ali, porque não existe padrão.

A cauda longa é a maior parte do volume. Para cada rede grande que uma lista cobre, existem milhares de padarias, mercadinhos, clínicas e prestadores que nenhuma lista vai conter. Em extrato de pessoa física brasileira, essa cauda não é o detalhe, é o grosso.

Regra não avisa quando quebra. Se o banco muda o formato da descrição, a regra simplesmente deixa de casar. Nada falha, nada alerta: as transações só começam a cair em "outros" e alguém descobre pelo suporte, semanas depois.

O que um modelo faz que a regra não faz

Três coisas, e vale separar porque elas resolvem problemas diferentes.

Generaliza para o que nunca viu. Uma regra só acerta o que alguém escreveu antes. Um modelo treinado em descrição bancária brasileira reconhece a forma de um estabelecimento mesmo sem aquele nome específico estar em lista nenhuma.

Usa mais que a descrição. O sinal do valor, a ordem de grandeza, o tipo de conta e o código da categoria do estabelecimento no cartão são informação. R$ 12 e R$ 1.200 com a mesma descrição provavelmente não são a mesma coisa.

Aprende com correção. Quando alguém corrige uma categoria errada, aquilo vira dado. Com regra, correção vira mais uma linha de código que alguém vai ter que manter.

Isso não quer dizer que regra não serve para nada. O arranjo que funciona bem é modelo como base e regra por cima, para os casos em que você sabe a resposta e não quer discutir.

Quantas categorias fazem sentido?

Esse é o erro silencioso mais comum. Time que começa do zero costuma criar categorias demais ou de menos, e os dois doem.

Poucas categorias deixam a informação inútil: saber que 60% do gasto foi em "serviços" não ajuda ninguém a decidir nada.

Muitas categorias derrubam a precisão e cansam o usuário. Se existe uma categoria para cada coisa, o modelo erra mais e a tela vira ruído.

O caminho que resolve os dois é árvore em vez de lista. Categorias gerais no topo, específicas embaixo, e cada produto escolhe em que nível quer trabalhar. Um app de controle de gastos quer o nível fino; um relatório gerencial quer o nível grosso. A mesma transação atende aos dois.

Como medir se está boa

"A categorização está boa?" não é uma pergunta respondível sem métrica. Quatro números resolvem.

Cobertura. Que percentual das transações recebeu alguma categoria. É a métrica mais fácil de enganar: dá para ter 100% jogando tudo que sobrou em "outros".

Acerto na amostra. Pegue algumas centenas de transações, classifique na mão, compare. É trabalhoso e é o único jeito honesto.

Taxa de correção pelo usuário. Se o seu produto permite corrigir categoria, essa é a métrica mais barata e mais sincera que existe. Ela mede o erro que incomodou de verdade.

Acerto por categoria, não só no total. Uma média de 90% pode esconder que a categoria mais importante do seu produto acerta 60%. Olhe sempre separado.

E vale medir por tipo de conta. Extrato de conta corrente, fatura de cartão e conta PJ têm comportamentos diferentes, e um número único mistura três realidades.

Construir ou usar pronto?

A pergunta real não é "consigo construir". Times bons constroem. A pergunta é o que você assume junto.

Construir categorização significa manter, para sempre: um conjunto de dados rotulados que precisa crescer, um ciclo de retreino, uma rotina de avaliação e alguém responsável por investigar quando a qualidade cai.

Faz sentido quando a categorização é o produto, ou quando você opera num nicho tão específico que nenhum modelo geral entende o seu extrato.

Faz menos sentido quando categorizar é pré-requisito de outra coisa. Se o seu produto é conciliação, gestão financeira ou crédito, a categorização é insumo, e o seu cliente nunca vai te escolher por causa dela. Vai só te abandonar se ela for ruim.

E a Pluggy nisso tudo?

Na Pluggy a categorização vem no próprio objeto da transação, nos campos category e categoryId. Não é um segundo passo que você orquestra.

As categorias são uma árvore de até três níveis, com os nomes disponíveis também em português, e cada categoria carrega a sua categoria pai. É o que resolve a questão do nível de detalhe: você escolhe trabalhar no nó fino ou no pai, conforme a tela.

Quando o modelo não reconhece a transação, category vem null em vez de vir com a categoria mais próxima. Num relatório financeiro, categoria errada contamina soma e decisão; campo vazio só pede atenção.

E existe o caminho da correção: dá para atualizar a categoria de uma transação, e essa correção volta como sinal para o modelo. Quando você recategoriza, também é criada uma regra de categoria própria da sua conta, que passa a valer antes da classificação automática. É o arranjo de modelo com regra por cima, só que sem você manter nenhum dos dois.

O contexto maior está em o que é enriquecimento de dados bancários, e a página do produto é enriquecimento de dados. A referência técnica, com a árvore completa de categorias, está na documentação.

Perguntas frequentes

Dá para categorizar com regex?

Dá, para os casos óbvios. O problema é a cauda longa, que em extrato brasileiro é a maior parte do volume.

O que acontece quando o modelo não sabe?

A categoria volta nula. É melhor que chutar, porque chute errado contamina relatório e decisão.

Dá para corrigir uma categoria errada?

Dá. E a correção vale para a sua conta dali em diante, além de servir de sinal para o modelo.

Funciona em conta PJ?

Funciona. Vale informar o tipo de conta, porque o padrão de gasto de empresa é diferente do de pessoa física.

Quantas categorias existem?

A árvore tem três níveis, de categorias gerais como Renda e Transportes até nós específicos como Postos de gasolina. A lista completa está na documentação.

Categorização e enriquecimento são a mesma coisa?

Não. Categorizar é uma das camadas do enriquecimento. Identificar o estabelecimento, resolver a contraparte e detectar recorrência são outras.

Conclusão

Categorização é um daqueles problemas que parecem pequenos até você assumir a manutenção. Se ela é o seu produto, construa. Se ela é insumo para o seu produto, a conta costuma fechar do outro lado.

Se quiser comparar antes de decidir, dá para ver como a transação chega categorizada com o seu próprio extrato.