Stage 5 — Merchant

2.8 Stage 5 — Merchant resolution

Every receipt is mapped to a merchant_id. The fingerprint uses a weighted multi-signal model. Signals include tax identifier, normalised merchant name, address fragment, and receipt template fingerprint. Tax identifier is the primary signal when present. Specific weights are managed in the internal operations layer.

Chain mapping

A merchant resolved to a known chain (BIM, A101, Migros, ŞOK) gets a chain_id. Chains drive two things:

• Cross-branch aggregation for the B2B data product (basket prices at "Migros nationwide").
• Geographic enrichment — when the user opts in, the branch address is enriched with city/region from the merchant master table.

Geo enrichment (opt-in only)

If the user enabled location sharing, the receipt is tagged with the resolved city/region. The system uses city-level geography. This satisfies the privacy commitment in 08 and the B2B data product's k-anonymity requirement in 05.

Unknown merchant

If the fingerprint resolves to the merchant queue, the receipt is written with merchant_id = null and merchant_raw_name is kept. The trust scorer (03) treats unknown-merchant as a mild negative signal. The merchant queue is drained the same way as the canonicalisation queue.