# Catégorisation de transactions
> Catégorisation de transactions bancaires
Étape qui transforme un libellé brut (« CB CARREFOUR 23/04 ») en une catégorie utile (« Alimentation › Supermarché »). Brique invisible mais critique pour PFM, BFM, scoring, comptabilité automatique.
_Catégorie: technique_
---
## Définition
La **catégorisation de transactions** transforme une opération brute (libellé technique, montant, date) en une catégorie utile : « Alimentation › Supermarché », « Transport › Uber », « Salaire ».
C'est une brique invisible mais critique pour tout cas d'usage qui consomme de la donnée AIS : PFM, BFM, scoring crédit alternatif, comptabilité automatique, détection de fraude, embedded finance.
## Le problème : des libellés bruts illisibles
Un relevé typique contient des lignes comme :
- `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`
Tel quel, c'est inexploitable. Il faut inférer la catégorie, le marchand réel et la nature de la dépense.
## Règles, ML, hybride
Trois approches, toutes utilisées :
- **Règles déterministes** — regex et tables de correspondance (« CARREFOUR » → Supermarché). Précises sur le connu, incapables de gérer les nouveaux marchands.
- **Machine learning supervisé** — modèles entraînés sur des dizaines de millions de libellés taggés, capables de généraliser (« CARREF EXPRESS PARIS » sans entrée explicite).
- **Hybride** — règles pour les cas certains, ML pour l'inconnu, et boucle de feedback (re-catégorisation manuelle → ré-entraînement).
Les leaders (Bud, Yodlee, Tink, Heron Data) sont tous hybrides, avec des modèles propriétaires entraînés sur des centaines de millions de transactions.
## La taxonomie : pas de standard
Il n'existe pas de taxonomie universelle. Chaque acteur définit la sienne, généralement sur 2 ou 3 niveaux :
- **N1** — grandes familles (Alimentation, Transport, Logement, Salaire…).
- **N2** — sous-catégories (Supermarché, Restaurant, Boulangerie).
- **N3** — précisions (chaîne marchande, type de produit).
Les MCC (_Merchant Category Codes_, ISO 18245, 4 chiffres assignés par les réseaux) aident mais ne suffisent pas : ils sont parfois faux ou trop génériques (le code 5411 « Grocery Stores » couvre aussi bien Carrefour qu'un kebab).
## Critères de qualité
- **Coverage** : part des transactions catégorisées (vs « Autre »). Cible > 95 %.
- **Accuracy** : part correctement catégorisée. Cible > 90 % sur N1, > 80 % sur N2.
- **Latence** : idéalement < 100 ms par transaction pour du temps réel.
- **Multi-langue / multi-pays** : un acteur paneuropéen doit être aussi précis en FR, DE, IT, ES, PL.
- **Stabilité** : ne pas re-catégoriser différemment la même transaction d'un appel à l'autre.
## Cas pro : la catégorisation comptable
Pour le BFM et la compta automatique (Pennylane, Qonto, Indy), l'exercice est plus complexe : il faut relier la transaction à un plan comptable (PCG, IFRS), gérer la TVA (déductible ou non, taux variables), produire des lignes d'écritures et rapprocher automatiquement transactions et factures. Une ligne « FOURNITURES BUREAU » doit ainsi devenir « Compte 6064, TVA 20 % déductible ».
## Ce que la catégorisation n'est pas
- **Pas l'enrichissement** : la catégorisation infère la catégorie ; l'enrichissement ajoute logo, géolocalisation, MCC, fiche entreprise. Deux couches distinctes, souvent associées.
- **Pas un service régulé** : aucun agrément ACPR pour catégoriser ; un AISP qui catégorise ses propres données reste AISP.
- **Pas universelle** : les libellés, MCC et comportements diffèrent par pays ; un modèle global égale rarement un modèle par pays.
- **Pas figée** : chaque nouveau marchand (TikTok Shop, nouvel opérateur) doit être appris en continu.
## Dans l'écosystème PSD2
La catégorisation ne fait pas partie de la DSP2 stricto sensu (qui ne définit que le transport des données), mais elle est la principale valeur ajoutée au-dessus de l'AIS : sans elle, les données restent des libellés bruts. C'est ce qui justifie le business model des agrégateurs et des solutions PFM/BFM.
```mermaid
flowchart LR
AIS["Données AIS
(libellé brut, montant, date)"]
subgraph CAT["Pipeline catégorisation"]
CLEAN["Nettoyage libellé"]
RULES["Règles déterministes"]
ML["Modèle ML"]
FB["Feedback utilisateur"]
end
subgraph OUTPUTS["Sorties"]
N1["Catégorie N1
(Alimentation)"]
N2["Catégorie N2
(Supermarché)"]
MERCHANT["Marchand identifié
(Carrefour)"]
end
USAGES["PFM, BFM, scoring,
compta auto, fraude"]
AIS --> CAT
CAT --> OUTPUTS
OUTPUTS --> USAGES
FB -.->|"Apprentissage continu"| ML
```
## Exemples concrets
- **Leaders** : Bud (UK), Heron Data (UK, focus pro), Yodlee (US, racheté par Envestnet), Tink (Suède, Visa), Bridge et Powens (FR), MX (US).
- **Bankin' / Lydia / Linxo** : s'appuient souvent sur le moteur Powens ou Bridge ; Bankin' a aussi son moteur historique.
- **Pennylane** : catégorisation comptable (PCG), OCR de factures et rapprochement automatique, avec une accuracy revendiquée au-delà de 95 %.
- **Heron Data** : se positionne sur le scoring B2B en qualifiant les flux d'une PME pour évaluer sa santé financière.
- **Limite connue** : les virements P2P sont les plus durs à classer — un « VIRT JEAN DUPONT » sans contexte reste inclassable ; beaucoup de PFM les laissent « à classer ».
- **Coût** : typiquement 0,001 à 0,01 € par transaction chez les leaders — significatif sur des millions de transactions par jour, d'où l'internalisation chez les gros acteurs.
- **Évolution** : usage de LLM pour catégoriser des libellés inédits en _zero-shot_ (testé chez Heron, Bud) — plus de précision sur la longue traîne, mais un coût d'inférence supérieur.
## Sources
- [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)
---
Source: https://openfinanceguide.com/fr/glossary/categorisation-transactions