Every payment that reaches a banking app arrives as a handful of technical fields, and transaction categorisation is what turns them into something a customer can read. A card payment brings a shortened merchant description, a four-digit category code and a terminal number, while a bank transfer may carry little more than a free-text reference and the recipient’s account.
What the customer sees is something else entirely: a feed sorted into spending groups, a monthly breakdown, a budget showing how much is left for eating out.
What is transaction categorisation
Transaction categorisation is the classification of individual payments into predefined spending groups. In a banking app, it is what places a supermarket purchase under Groceries and a train ticket under Transport, usually with an icon and a colour that make the feed easier to scan.
The term also appears in accounting, where it describes sorting a company's ledger entries for bookkeeping and reconciliation. In this article, we look closer on the issuer side: how banks and fintechs categorise the card payments, transfers and open banking transactions that flow through their customers' accounts.
What a transaction carries before it is categorised
A raw card transaction arrives with a small set of fields: a free-text description, a merchant category code (MCC), a merchant ID (MID), a terminal or POS ID, the amount, and a city and country. These fields exist to authorise, route and settle the payment.
Want to know more? What transaction data actually contains covers each field in detail.
The inputs change with the payment rail. Card payments carry an MCC and a descriptor set by the merchant or its processor. Bank transfers carry a free-text reference written by the payer, with no MCC at all. Open banking feeds pass through whatever the account-holding bank exposes, which can be a merchant string, a payment reference or a counterparty name.
Take an illustrative card record with the description SPOTIFY P2B4C1D9, an MCC from the digital goods range, and a country code. Categorisation resolves it to the merchant Spotify, places it under Entertainment, and adds a subscription tag. The customer sees a recognisable name and a meaningful category, and the bank gains a data point it can use in budgeting and cash-flow features.
How transaction categorisation works
Accurate categorisation runs in three steps.
Identify the merchant. The description is cleaned and matched, together with the MID, POS ID and location, to a known merchant and shop. This step decides everything that follows, because a category is only as reliable as the merchant it is attached to. Descriptors are short and inconsistent, and one merchant can arrive under dozens of identifiers.
Assign a category. Once the merchant or shop is known, it is mapped to a category in a taxonomy. Because the mapping is made at shop level, every future transaction from that shop inherits the same category, which keeps the feed consistent.
Add tags. Tags carry the detail a single category cannot: whether a payment is a subscription, whether the shop is online or physical, or whether a fuel purchase was petrol or electricity.
The matching itself can use hand-written rules, machine learning models trained on labelled transactions, or a hybrid of both. Rules are predictable and easy to audit, while models handle the long tail of new descriptor variants. Most production systems combine them, with rules covering high-volume merchants and models filling the gaps.
Transaction categorisation vs MCC codes
The MCC is a four-digit code describing a merchant’s primary line of business. The acquirer assigns it when the merchant account is set up, and card networks use it to set interchange fees and apply category rules. It is a useful starting signal. However, it describes the merchant account in a single code instead of the purchase the customer made.
In practice, relying on the MCC alone runs into the same handful of problems:
- Too broad. One dining code covers a takeaway coffee and a tasting menu, so a restaurant budget cannot tell the two apart.
- Blind to new behaviour. A conventional petrol station and an EV charging point can share the same fuel MCC, hiding the difference in both spending breakdowns and carbon estimates.
- Blind to how people pay. A subscription and a one-off purchase from the same merchant carry the same code, so recurring spending stays invisible.
- Missing outside card payments. Bank transfers and many open banking records carry no MCC at all.
Tapix measured the scale of this by comparing MCC-only categorisation with multi-factor categorisation that also uses merchant identity and context.
In our comparison, only 63% of transactions were categorised correctly from the MCC alone.
Categories, subcategories and tags
A practical taxonomy has depth. A top-level category gives the broad picture (Dining), a subcategory adds precision (Coffee Shops), and the merchant level names the business itself. A customer can then see whether their dining budget goes on coffee or on restaurants, which a single label cannot show.
The main question to ask is: how many top-level categories should a bank show? Monzo works with 17 pre-set spending categories, while Revolut lets customers create their own. Tapix ships 25 main categories by default with 530+ store-level category tags, giving each purchase a proper depth.
Taken together, these numbers point to a sweet spot of roughly 15 to 25 top-level categories: enough to separate the spending customers care about, and few enough to fit on a single summary screen. Depth belongs one level down, in subcategories and tags, where it feeds budgeting, analytics and scoring without crowding the interface.
Tags sit alongside the hierarchy as a second layer. A subscription tag separates recurring charges from everyday spending. Eco labels support carbon estimates. Online and physical flags help with fraud rules and location features.
Business accounts need their own logic. A small business wants to see software, travel and supplier payments, so categorisation for SME and corporate clients uses business expense categories alongside the consumer set. Many banks also remap a provider’s taxonomy to the categories their app already uses, so the enriched data fits the existing interface.
Why transaction categorisation matters for banks and fintechs
Personal finance management: Budgets, spending breakdowns and monthly summaries are built directly on categories. When categories are accurate, customers trust the insights and return to them.
Transaction history: A category icon next to a clean merchant name helps customers recognise a payment in a second, which reduces "I don't recognise this charge" contacts.
Credit and affordability: Income and expense categories show regular commitments, discretionary spending and risk signals such as gambling. That evidence supports the creditworthiness assessments lenders are preparing for under the EU's revised Consumer Credit Directive.
Card controls: Category-level blocking lets customers switch off gambling payments and lets companies restrict business cards to approved spending types.
Personalisation and sustainability: Targeted offers, lifestyle segments and per-transaction carbon estimates all depend on knowing what was bought and where.
What is CCD2? Read all the details.
How Tapix categorises transactions
Tapix starts with the merchant. The descriptor, MID, POS ID and location fields are resolved to a specific shop, which links to a merchant with a clean name and logo. This follows the merchant, shop and terminal hierarchy used across the API. The category is attached to that shop, so it stays consistent whichever terminal or acquirer the next payment comes through.
Each transaction is then placed into one of 25 main categories and tagged from a set of 530+ store-level tags, covering retail, business, investment and CO2 labelling. Banks can use the default taxonomy, consolidate it into a smaller set, or receive their own category structure through custom categories and remapping in the API.
Calling the API as early as possible, ideally at pre-authorisation or authorisation, makes the category available in real time for push notifications and the transaction feed. The Transaction Categorisation page shows the full taxonomy and a sample of category tags.
