# Enrichissement de transactions

> Bank transaction enrichment

A layer on top of categorisation: it adds the merchant logo, company profile, MCC, geolocation, a normalised merchant identifier, subscription identification, and more.

_Category: technique_

---

## Definition

**Transaction enrichment** sits on top of categorisation: it adds contextual metadata from external databases to each operation.

In concrete terms, a raw line becomes usable thanks to the merchant logo, the normalised trade name, the address and geolocation, the MCC, the company profile (SIREN, sector), the detection of a recurring subscription, and even the carbon footprint.

## Categorisation vs enrichment

Often confused, but distinct:

| | Categorisation | Enrichment |
|---|---|---|
| Output | A category ("Groceries › Supermarket") | Metadata (logo, geo, SIREN…) |
| Model | ML / rules | External database lookup + ML |
| Databases | History of tagged labels | Pappers, OpenStreetMap, MCC, merchant database |
| Use | Budget, aggregation by category | Rich UI, precise identification, analytics |

In practice, the two go together: a modern AISP, PFM or BFM offers both.

## Common types of enrichment

- **Merchant identity**: `CB AMZN MKTPL DUBLIN IE` becomes "Amazon", with logo and URL.
- **Company profile**: for a corporate counterparty (transfer, direct debit), adding the SIREN, legal form, NAF sector and address (sources: Pappers, INPI).
- **MCC**: a 4-digit code (ISO 18245) for card transactions (5411 supermarket, 4121 taxi, 7011 hotel).
- **Geolocation**: the latitude/longitude of the point of sale, useful for the spending map and geographic fraud detection.
- **Subscription detection**: spotting that a monthly `NETFLIX €13.49` is a subscription, to offer dedicated management.
- **Income detection**: identifying recurring incoming flows (salary, benefits) for scoring or budget protection.
- **Carbon footprint**: estimating the CO2 of each expense (Carbo, Greenly, Doconomy) from an emission factor per sector.

## Why it has become critical

Without enrichment, a transaction stays a rough draft: the user does not recognise the label (and complains to their bank), the app can show neither a logo nor a profile, behavioural analysis is poor and scoring loses precision. An enriched label ("Carrefour Express, 23/04, 75011 Paris, Groceries › Supermarket") is infinitely more useful than a raw `CB CARREFOUR EXP 23/04`.

## Subscription detection: the star use case

Identifying recurring payments has become a service in its own right (Truebill in the US, Bankin' Subscriptions, Bridge Subscriptions):

- spotting the recurrence (monthly, annual, weekly);
- grouping label variants under a single subscription;
- detecting price increases (Netflix going from €13.49 to €17.99);
- assisting cancellation (the Chatel law, direct integration with certain merchants).

## Data sources

- **MCC + merchant name**: provided by the networks (Visa, MC, CB).
- **Pappers, INPI, RCS**: French company profiles.
- **OpenStreetMap, Google Places, Yelp**: geolocated points of sale.
- **Logos**: public databases (Logo.dev, Brandfetch) or proprietary ones.
- **Subscription lists**: maintained manually and supplemented by ML.
- **Carbon emission factors**: ADEME (Base Empreinte), Doconomy.

## What enrichment is not

- **Not a re-categorisation**: it complements the category, it does not replace it.
- **Not always perfect**: a very ambiguous label stays poor. Target: 80 to 95% of card transactions, 30 to 60% of transfers.
- **Not regulated**: it relies on public or proprietary data, without any specific licence.
- **Not harmless for privacy**: geolocating every transaction raises GDPR questions, hence the need for clear consent and purpose.

## In the PSD2 ecosystem

Like categorisation, enrichment is outside DSP2 in the strict sense, but it is the major value-add of modern AIS solutions. Without it, every app would have the same raw data — which justifies the high valuations of the specialists (Bud, Tink, Heron Data).

```mermaid
flowchart LR
    AIS["AIS data<br/>(raw label)"]

    subgraph ENRICH["Enrichment pipeline"]
        IDENT["Merchant identity"]
        LOGO["Logo + URL"]
        GEO["Geolocation"]
        MCC["MCC + sector"]
        SIREN["SIREN / company profile"]
        ABO["Subscription detection"]
        CARBON["Carbon footprint"]
    end

    SOURCES["Pappers, OSM, MCC schemes,<br/>public logos, ADEME…"]
    OUTPUT["Enriched transaction<br/>(ready for UI / analytics)"]

    AIS --> ENRICH
    SOURCES --> ENRICH
    ENRICH --> OUTPUT
```

## Concrete examples

- **Specialists**: Bud (UK), Heron Data (UK, B2B), Tink (Sweden), Powens and Bridge (FR), Yodlee Envestnet and MX (US).
- **Bankin'**: each transaction is displayed with a logo, a category and sometimes geolocation, for immediate recognition.
- **Pennylane / Qonto**: accounting enrichment — supplier recognition (SIREN), reconciliation with OCR-scanned invoices, suggested allocation. A major time saver for freelancers.
- **Greenly / Carbo / Helios**: carbon enrichment, with each expense becoming estimated kilos of CO2.
- **Subscription detection**: Bankin' identifies ~30 subscriptions per user, including 3 to 5 forgotten ones — i.e. €50 to €150 of potential savings per year.
- **Cost**: a full enrichment (logo, geo, subscription, MCC, SIREN) costs €0.002 to €0.02 per transaction, often included in an AIS + categorisation + enrichment offer.
- **Evolution**: real-time enrichment (at the moment of the transaction) for instant budget alerts — already in place at Lydia and Revolut on their own accounts.

## Sources

- [ISO 18245 — Merchant category codes](https://www.iso.org/standard/79450.html) — ISO
- [Base Empreinte](https://base-empreinte.ademe.fr/) — ADEME

---

Source: https://openfinanceguide.com/en/glossary/enrichissement-transactions