When a customer taps their card, the bank's issuer system receives a tightly structured but surprisingly thin bundle of card network transaction data. The fields are standardised, the values are constrained, and most of what an end user expects to see in their app - clean merchant names, logos, recognisable categories, exact shop locations - is simply not in the message. Everything from statement clarity to credit decisioning is built downstream of this raw payload, which makes the gap between what arrives and what a customer needs the single most consequential data problem in retail banking.
How card network transaction data is created
Every card transaction passes through three distinct stages: authorisation, clearing, and settlement. Authorisation is the real-time check that runs in the seconds after the cardholder taps or enters their PIN. The merchant's terminal sends a request through the acquirer to the card network (Visa, Mastercard, Amex, Discover) which routes it to the issuing bank for an approve or decline decision. Most of these messages are built on ISO 8583, the standard that has governed card-originated messaging since 1987.
Clearing happens later, usually in batches at the end of the day. It is when the acquirer formally submits the transaction for funds movement, and it can carry slightly different or enriched data than the original authorisation message.
Most of the data a bank uses for real-time customer-facing features (push notifications, in-app feeds, fraud checks) comes from the authorisation message. That message was designed for speed across 1980s telecoms infrastructure, not for human readability.
What data is in a payment message
A typical card authorisation message contains a small set of fields that matter for downstream banking products. ISO 8583 references these by data element number - Visa calls them "Field x", Mastercard "DE x", with broadly aligned but not identical numbering.
The fields a bank's issuer system reliably extracts include:
- Primary Account Number (DE 2) - the card number, used to identify the account.
- Transaction amount and currency (DE 4 and DE 49) - the value charged and the ISO 4217 currency code.
- Date and time (DE 7 and DE 12) - when the transaction was initiated, in network time and local time.
- Merchant Category Code (DE 18) - a four-digit ISO 18245 code intended to classify the merchant's primary line of business.
- POS entry mode (DE 22) - how the card was read: chip, contactless, magstripe, manual, e-commerce.
- Acquirer ID (DE 32) - identifies the acquiring bank routing the transaction.
- Card Acceptor Terminal ID (DE 41) - the terminal where the payment was taken.
- Card Acceptor ID, also called Merchant ID or MID (DE 42) - identifies the merchant within the acquirer's system.
- Card Acceptor Name and Location (DE 43) - a free-text string typically capped at around 40 characters, containing the merchant descriptor, city, and country code.
- Card BIN - the first six to eight digits of the PAN, which identify the issuing institution and card product.
That is essentially the raw feed. It is enough for the issuer to make an authorisation decision and to write a row to the cardholder's ledger. It is not enough to populate a clean transaction screen in a mobile banking app.
DE 43 causes most of the visible damage in customer-facing products. The acquirer or processor populates it as constrained free text - SQ *MERCHANT NAME LDN, PAYPAL *ABOUTYOUSEC, WWW.SHOP.COM 4083334000 CA, or a bare trading name with a city tag. Most banks display this bare data string unless they invest in enrichment.
What is not included
Equally important is what the network message does not carry. There is no clean merchant brand name, no logo, no verified physical address, no product-level breakdown of what was bought, and no consumer-facing spending category. There is no information about whether the merchant is a franchise location, a brand within a marketplace, or a sub-tenant of a shopping centre. There is rarely a usable URL, never a phone number, and almost never a structured location identifier like a Google Place ID.
The MCC field hints at the merchant's industry, but it was designed for interchange fee calculation, not consumer-facing categorisation. The gap widens online: when a customer pays through a gateway like Stripe, PayPal or Adyen, the descriptor often reflects the gateway rather than the underlying business, and the MCC may follow the processor's classification.
These gaps are not bugs in the network protocol. ISO 8583 was built to move money, not to show detailed purchases to a user. Filling the gap is the bank's problem.
Why raw data varies between networks
Within the ISO 8583 framework, every card network maintains its own extensions and conventions. Visa, Mastercard, Amex, Discover and JCB each publish proprietary specifications defining which optional fields they use, which subfields they populate, and how values are encoded. Decades of independent evolution have left the network specifications with more differences than similarities at the field level.
Acquirers add another layer of variation. The way a merchant name is formatted into DE 43, whether the city is included, whether the country code uses two or three characters, and whether prefixes like the Square SQ * or PayPal PP* are stripped or preserved - all of this is decided at the acquirer or processor level. A single merchant chain with multiple acquirers across different countries can appear to the issuer under a dozen different descriptor formats.
The consequence is that the same real-world purchase, made at the same retailer, in the same currency, can produce very different raw strings in the issuer's system depending on which network and which acquirer routed it. This inconsistency is the root cause of most downstream data quality issues.
Why this matters for digital banking products
Every customer-facing feature that touches the transaction feed inherits the quality of this raw data. A clean transaction list, push notifications with merchant context, in-app search, smart filters, spending insights, subscription management, PFM and budgeting tools, credit assessment, fraud and dispute workflows - all of them are downstream of the same underlying fields.
When the merchant name is a vague description, the customer cannot search or filter for it. When the MCC is wrong, spending insights mislabel the category. When the payment gateway masks the underlying merchant, recurring payment detection fails to group repeated charges together. The downstream cost shows up as support tickets, friendly fraud disputes, abandoned features, and customers who quietly move to competitors with better-presented apps.
For credit decisioning, the stakes go higher. Affordability assessment under regimes like CCD2 in the EU depends on classifying customer spend into income, essential expenses, and discretionary spend. If the underlying transaction data is noisy and inconsistent, every layer of the credit model suffers. Fraud models follow the same pattern in reverse - they depend on detecting deviation from a customer's normal merchant set, unusual location, or atypical category mix, and all three signals collapse when merchants are inconsistently named, locations missing, and categories drawn from MCC alone.
From raw fields to usable data
Closing the gap requires enrichment - a deliberate processing layer that turns raw network data into product-ready output. It does four things the network message cannot.
It resolves merchant identity, turning SQ *KAFFEE 12 LDN and KAFFEE 12 LIMITED and KAFFEE12.COM into a single canonical merchant entity with a clean trading name, a high-resolution logo, and a verified location hierarchy. It applies a categorisation model that goes several levels deeper than MCC - capturing not just "Food & Drink" but the difference between a takeaway, a fine-dining restaurant, and a coffee subscription. It fills in location data at shop level rather than HQ level, so the address shown matches where the purchase actually happened. And it detects patterns across transactions to identify subscriptions, recurring direct debits, and split purchases that span multiple authorisation events.
Tapix sits exactly at this layer. The API takes in raw card data - descriptor, MCC, MID, terminal ID, country, amount, currency - and returns a structured object containing clean merchant name, 512x512 logo, four-level category, GPS coordinates, URL, phone number, Google Place ID, payment gateway flag, and CO2 metadata. It runs at 99.99% accuracy and is used by 70+ banks and fintechs globally, including Société Générale, UniCredit, Erste, Revolut and bunq, processing over 1.5 billion transactions a month.
The point is not the API itself but what it represents architecturally. Banks that treat raw card network transaction data as the end of the data pipeline ship customer-facing products at the quality ceiling set by ISO 8583. Banks that treat it as the start of the pipeline - and invest in a deliberate enrichment layer between the network and the product - get a foundation that every downstream feature can build on.
