# Catégorisation de transactions

> Categorização de transações bancárias

Etapa que transforma um descritivo bruto ("CB CARREFOUR 23/04") em uma categoria útil ("Alimentação › Supermercado"). Bloco invisível, mas crítico para PFM, BFM, scoring e contabilidade automática.

_Categoria: technique_

---

## Definição

A **categorização de transações** transforma uma operação bruta (descritivo técnico, valor, data) em uma categoria útil: "Alimentação › Supermercado", "Transporte › Uber", "Salário".

É um bloco invisível, mas crítico, para todo caso de uso que consome dados de AIS: PFM, BFM, scoring de crédito alternativo, contabilidade automática, detecção de fraude, embedded finance.

## O problema: descritivos brutos ilegíveis

Um extrato típico contém linhas como:

- `CB SNCF MOBILE 24/04 0612345678`
- `VIRT SARL XYZ COMM/AVR2025`
- `PRLV EDF FACT N12345678`
- `CB CARREFOUR EXP 23/04 75011 PARIS`
- `CB AMZN MKTPL DUBLIN IE`

Assim como está, é inaproveitável. É preciso inferir a categoria, o estabelecimento real e a natureza da despesa.

## Regras, ML, híbrido

Três abordagens, todas usadas:

- **Regras determinísticas** — regex e tabelas de correspondência ("CARREFOUR" → Supermercado). Precisas no que é conhecido, incapazes de lidar com novos estabelecimentos.
- **Machine learning supervisionado** — modelos treinados em dezenas de milhões de descritivos rotulados, capazes de generalizar ("CARREF EXPRESS PARIS" sem entrada explícita).
- **Híbrido** — regras para os casos certos, ML para o desconhecido, e um ciclo de feedback (recategorização manual → retreinamento).

Os líderes (Bud, Yodlee, Tink, Heron Data) são todos híbridos, com modelos proprietários treinados em centenas de milhões de transações.

## A taxonomia: nenhum padrão

Não existe uma taxonomia universal. Cada ator define a sua, geralmente em 2 ou 3 níveis:

- **N1** — grandes famílias (Alimentação, Transporte, Moradia, Salário etc.).
- **N2** — subcategorias (Supermercado, Restaurante, Padaria).
- **N3** — detalhamentos (cadeia varejista, tipo de produto).

Os MCC (_Merchant Category Codes_, ISO 18245, 4 dígitos atribuídos pelas redes) ajudam, mas não bastam: às vezes estão errados ou são genéricos demais (o código 5411 "Grocery Stores" cobre tanto o Carrefour quanto um quiosque de comida).

## Critérios de qualidade

- **Coverage**: parcela das transações categorizadas (x "Outros"). Alvo > 95%.
- **Accuracy**: parcela corretamente categorizada. Alvo > 90% no N1, > 80% no N2.
- **Latência**: idealmente < 100 ms por transação para tempo real.
- **Multilíngue / multipaís**: um ator pan-europeu precisa ser igualmente preciso em FR, DE, IT, ES, PL.
- **Estabilidade**: não recategorizar de forma diferente a mesma transação de uma chamada para outra.

## Caso empresarial: a categorização contábil

Para o BFM e a contabilidade automática (Pennylane, Qonto, Indy), o exercício é mais complexo: é preciso ligar a transação a um plano de contas (PCG, IFRS), tratar o imposto (dedutível ou não, alíquotas variáveis), produzir linhas de lançamento e conciliar automaticamente transações e faturas. Uma linha "FOURNITURES BUREAU" (material de escritório) deve assim se tornar "Conta 6064, imposto de 20% dedutível".

## O que a categorização não é

- **Não é o enriquecimento**: a categorização infere a categoria; o enriquecimento adiciona logo, geolocalização, MCC e ficha da empresa. Duas camadas distintas, muitas vezes combinadas.
- **Não é um serviço regulado**: nenhuma autorização da ACPR para categorizar; um AISP que categoriza seus próprios dados continua sendo AISP.
- **Não é universal**: os descritivos, MCCs e comportamentos diferem por país; um modelo global raramente iguala um modelo por país.
- **Não é estática**: cada novo estabelecimento (TikTok Shop, novo operador) precisa ser aprendido continuamente.

## No ecossistema PSD2

A categorização não faz parte da PSD2 stricto sensu (que só define o transporte dos dados), mas é o principal valor agregado sobre o AIS: sem ela, os dados continuam sendo descritivos brutos. É o que justifica o modelo de negócio dos agregadores e das soluções de PFM/BFM.

```mermaid
flowchart LR
    AIS["Dados de AIS<br/>(descritivo bruto, valor, data)"]

    subgraph CAT["Pipeline de categorização"]
        CLEAN["Limpeza do descritivo"]
        RULES["Regras determinísticas"]
        ML["Modelo de ML"]
        FB["Feedback do usuário"]
    end

    subgraph OUTPUTS["Saídas"]
        N1["Categoria N1<br/>(Alimentação)"]
        N2["Categoria N2<br/>(Supermercado)"]
        MERCHANT["Estabelecimento identificado<br/>(Carrefour)"]
    end

    USAGES["PFM, BFM, scoring,<br/>contabilidade auto, fraude"]

    AIS --> CAT
    CAT --> OUTPUTS
    OUTPUTS --> USAGES
    FB -.->|"Aprendizado contínuo"| ML
```

## Exemplos concretos

- **Líderes**: Bud (UK), Heron Data (UK, foco empresarial), Yodlee (US, comprada pela Envestnet), Tink (Suécia, Visa), Bridge e Powens (FR), MX (US).
- **Bankin' / Lydia / Linxo**: muitas vezes se apoiam no motor da Powens ou da Bridge; a Bankin' também tem seu motor histórico.
- **Pennylane**: categorização contábil (PCG), OCR de faturas e conciliação automática, com uma acurácia declarada acima de 95%.
- **Heron Data**: posiciona-se no scoring B2B, qualificando os fluxos de uma PME para avaliar sua saúde financeira.
- **Limitação conhecida**: as transferências P2P são as mais difíceis de classificar — um "VIRT JEAN DUPONT" sem contexto permanece inclassificável; muitos PFMs as deixam "a classificar".
- **Custo**: tipicamente € 0,001 a € 0,01 por transação nos líderes — significativo em milhões de transações por dia, daí a internalização nos grandes players.
- **Evolução**: uso de LLMs para categorizar descritivos inéditos em _zero-shot_ (testado na Heron, na Bud) — mais precisão na cauda longa, mas um custo de inferência superior.

## Fontes

- [ISO 18245:2023 — Retail financial services — Merchant Category Codes](https://www.iso.org/standard/79450.html) — ISO, 2023
- [About Tink](https://tink.com/about/) — Tink (Visa)

---

Fonte: https://openfinanceguide.com/pt-br/glossary/categorisation-transactions