CASE STUDY 02 PRODUCT DESIGN · FINTECH · DESIGN DEPURÁVEL · CLASSIFICAÇÃO INTELIGENTE

Classificador Inteligente PF/PJ – Motor de Regras com Aprendizado Observável

Reduzindo erros e retrabalho contábil por meio de regras configuráveis, decisão assistida e automação evolutiva

PROBLEMA

Microempreendedores misturam gastos pessoais e empresariais, gerando erros operacionais e retrabalho contábil.

SOLUÇÃO

Classificação automática pós-transação com regras progressivas e revisão assistida.

DECISÕES-CHAVE

Menor precisão inicial para não interromper o fluxo de pagamento
Maior fricção no início para acelerar o aprendizado do sistema

RESULTADO ESPERADO

80% de classificações automáticas
Redução de erros e retrabalho

Este é um projeto conceitual, não implementado.

Contexto

Microempreendedores operam em uma zona cinzenta entre finanças pessoais e empresariais. Mesmo com contas separadas, o uso simultâneo de PIX, cartões, transferências e boletos cria um ambiente propenso a erro.

Segundo o Sebrae (2025):

Este problema foi identificado a partir de:

O padrão observado não é falta de conhecimento, mas falha do sistema em acomodar o comportamento real do usuário.

Homem pensativo com dois cartões ao redor, um de pessoa física e outro de pessoa jurídica.
O microempreendedor entre dois contextos financeiros — pessoal e empresarial.

Problema

O modelo atual exige que o usuário decida corretamente a cada transação — e corrija depois quando erra.

Isso gera:

O erro não é pontual — é estrutural.

Linha do tempo mostrando compra, decisão manual de alocação, erro recorrente e correções posteriores.
Fluxo atual: a decisão de classificação depende da memória do usuário — e o erro é consequência estrutural.

Pergunta de Design

Como reduzir erros de classificação PF/PJ sem exigir decisão manual em cada transação?

Abordagem de Produto

O erro humano é inevitável, mas pode ser absorvido pelo sistema.

A decisão foi deslocar a classificação para o pós-transação, onde pode ser tratada de forma consistente, auditável e reversível — mesmo ao custo de menor precisão inicial.

Diagrama circular com o motor de classificação PJ/PF ao centro, conectado ao usuário, Open Finance e contadores.
Motor de classificação no centro: o usuário configura regras, o sistema decide, contadores recebem dados estruturados.

Solução

Classificação pós-transação com regras progressivas

Após a transação, o sistema aplica regras configuráveis e sugere — ou define — a classificação como “Pessoal” ou “Empresarial”.

A operação financeira não é alterada. A inteligência atua na organização posterior.

Central de Regras

Configuração progressiva baseada em sinais ordenados por confiabilidade:

Hierarquia de Decisão

Para garantir a explicabilidade total do sistema, a decisão segue uma hierarquia lógica e determinística, sem o uso de pesos matemáticos opacos:

1. Regras Personalizadas (Overrides)
Vontade explícita do usuário (sempre prioritária). Se o usuário definiu que "Posto Shell → PJ", essa regra é soberana e ignora todos os sinais.

2. Sinal Documental (Decisão Direta)
Na presença de NF-e emitida para o CNPJ do usuário, o sistema classifica automaticamente como PJ sem necessidade de convergência adicional.

3. Leitura Estruturada de Sinais (Fallback)
Na ausência dos anteriores, o sistema avalia os sinais em ordem de confiabilidade — identidade do favorecido, categoria fiscal, afinidade, recorrência, contexto de gasto e, por último, horário.

O sistema opera por convergência: quando os sinais são consistentes entre si, a automação é liberada. Quando há contradição — por exemplo, um CNPJ inédito com padrão de horário familiar — o sistema não decide: solicita validação direta do usuário.

Horário atua como sinal de contexto de baixo peso, utilizado apenas na ausência de sinais mais fortes.

Tela do aplicativo mostrando a Central de Regras com fornecedores fixos, valor, débitos recorrentes e horário comercial.
Central de Regras: configuração progressiva com hierarquia clara e funcionamento imediato mesmo sem personalização.

Tratamento de Ambiguidade

Nem toda transação pode ser classificada com certeza.

Isso cria uma tensão:

Notificar sempre → mais controle, porém fadiga.

Notificar pouco → menos fricção, porém risco de erro.

A classificação (PF/PJ), o nível de confiança e a ação do sistema são tratados como etapas separadas do processo de decisão.

Tela de notificações com cards de alta confiança, sugestão pendente e item aguardando decisão do usuário.
Três níveis de confiança, três comportamentos distintos — classificação silenciosa, sugestão e decisão do usuário.

Intervenção e Controle

O sistema automatiza, mas não remove o controle.

Tela de detalhe de transação com classificação automática, opção de alterar, estorno vinculado e histórico de mudanças.
Detalhe da transação: histórico de alterações, estorno vinculado e reclassificação com um toque.
Protótipo

Decisão de Design / Trade-offs

Fluxo contínuo vs. precisão no momento da compra

A classificação poderia ocorrer durante a transação, aumentando a precisão imediata.

No entanto, isso introduziria fricção direta no pagamento.

A decisão foi deslocar a classificação para o pós-transação, preservando a fluidez e tratando a precisão posteriormente.

Fricção inicial vs. aprendizado do sistema (Cold Start)

No início, o sistema tem baixa base de dados.

A decisão foi aceitar maior volume de notificações nas primeiras semanas.

Isso aumenta o esforço no curto prazo, mas acelera a construção da base e reduz intervenções no uso contínuo.

A fricção inicial foi tratada como investimento.

A Categoria Fiscal mitiga parcialmente esse problema: por operar sem histórico acumulado, eleva a precisão desde o primeiro uso e reduz a agressividade do cold start para o usuário.

Viabilidade

A solução atua apenas na classificação contábil pós-transação.

Isso respeita restrições estruturais:

O sistema atua onde há viabilidade: organização e reconciliação.

Exemplo de notificação:

“Compra de R$ 50,00 na Papelaria Silva — sugerida como Conta PJ. Confirmar?”
Tela de extrato bancário com transações classificadas como PJ ou PF e filtros por categoria.
Extrato com classificação nativa — organização PF/PJ como parte natural da transação, não como camada adicional.

Dados e Evolução

A solução foi intencionalmente projetada sem dependência inicial de machine learning, priorizando explicabilidade, controle e funcionamento imediato (cold start). A arquitetura, no entanto, permite evolução futura para modelos híbridos baseados em score de confiança.

Como isso ocorre:

Métricas

Métrica Tipo O que indica
% de classificações automáticas North Star Maturidade do sistema — quanto o usuário já não precisa decidir
Taxa de reclassificação Qualidade Precisão das sugestões; alta taxa sinaliza ruído nos sinais
Redução de retrabalho contábil Impacto Valor percebido no fechamento mensal — medido via pesquisa com usuários e volume de correções manuais registradas
Volume de tickets de suporte Operacional Custo de manutenção; valida a depurabilidade do sistema
Tempo até classificação final Eficiência Velocidade do ciclo de decisão por transação
NPS / CSAT Satisfação Percepção geral de valor ao longo do tempo

Valor Gerado

Para o Usuário

Para o Banco

  • Retenção elevada pela redução de fricção operacional recorrente
  • Dados financeiros mais qualificados — base para produtos de crédito PJ com menor risco de inadimplência
  • Redução de custo de suporte pela lógica auditável e depurável
  • Redução de estornos e atendimentos

Conclusão

Ao deslocar a decisão do momento da transação para uma camada de software orientada por regras, o sistema transforma a separação PF/PJ em consequência do uso — e não em responsabilidade constante do usuário.

O sistema não evita o erro — ele o absorve.

* Nota técnica: a opção por uma hierarquia determinística de sinais visa garantir que cada decisão seja lógica, rastreável e fácil de manter pela engenharia, eliminando a opacidade de modelos baseados em scoring.

Especificação técnica