Building a Transaction Categorization Taxonomy That Models and People Can Both Use

The short answer: A good transaction categorization taxonomy starts from what the categories are used for, such as budgeting, underwriting or spend control; uses a small number of levels; defines each category with inclusion and exclusion rules and examples; handles transfers, refunds, marketplaces and mixed-purpose merchants explicitly; and is versioned alongside a maintained merchant reference list. Labels built on it are consistent enough for models and clear enough for users. Teams labeling at volume often use specialist financial data annotation providers.

Start with what the categories are for

A budgeting app needs categories people recognize, such as groceries, dining, transport and subscriptions. A lender needs categories that reveal income stability, essential spending and risky behavior. A corporate spend tool needs categories that map to accounting codes and policy rules. One taxonomy rarely serves all three well, so the first step is deciding which decisions the categories support.

Write the purpose down and test every proposed category against it. A category nobody uses for a decision adds labeling cost and confusion without improving any model or product.

Keep the structure shallow and exclusive

Deep hierarchies look thorough but are hard to label consistently. Two or three levels, such as a broad group, a category and an optional subcategory, are usually enough. Categories at each level should be mutually exclusive, so a transaction belongs in one place, and collectively cover the common cases, with a clearly defined other category for the rest.

Avoid categories that overlap in meaning, such as entertainment and leisure, unless definitions make the difference explicit. Overlap is the main cause of disagreement between annotators and of inconsistent model output.

Write definitions with inclusion and exclusion rules

Each category needs a written definition, a list of what belongs, a list of what does not and examples of real descriptors. For example, groceries might include supermarkets and grocery delivery but exclude convenience store fuel purchases and restaurant delivery. Clear exclusions resolve most borderline decisions before they reach a reviewer.

Definitions should be reviewed by people who will use the categories, such as product managers, credit analysts or finance teams, so the rules reflect real needs and not only an annotator’s judgment.

Transfers, refunds and reversals

Some of the most important labels are not spending at all. Transfers between a customer’s own accounts, credit card payments, loan repayments, refunds, reversals and chargebacks must be identified so they are not counted as income or spending. Mislabeling them inflates or hides cash flow, which matters for budgeting tools and especially for lending decisions.

Rules should explain how to recognize each type from descriptors, amounts and timing, and how to link a refund to the original purchase where data allows. See payments reconciliation for how the same patterns are handled in finance operations.

Merchant identification and marketplaces

Categories depend on knowing the merchant, and descriptors are messy: processor prefixes, truncated names, location codes and reference numbers. A maintained merchant reference list maps cleaned merchant names to categories, so the same merchant is labeled the same way every time. New merchants are researched and added, and mistakes are corrected centrally.

Marketplaces and payment platforms are a special challenge, because one descriptor can hide thousands of sellers selling different things. Rules should say when to use a marketplace category and when other data allows a more specific label.

Mixed-purpose merchants and cash

Some merchants sell many kinds of things: big-box retailers sell groceries, electronics and clothing; warehouse clubs sell fuel and food; pharmacies sell medicine and snacks. Without item-level data, the taxonomy needs a rule, such as assigning the merchant’s primary category or using a general merchandise category. Whatever rule is chosen should be applied consistently.

Cash withdrawals, peer-to-peer payments and money transfers also need rules, because their purpose is unknown. Labeling them as their own categories is usually better than guessing. See fintech outsourcing for products that rely on these labels.

Version the taxonomy and track changes

Taxonomies change as products evolve: a new category is added, two are merged, a definition is clarified. Every change should get a version number, a change note and a mapping from old to new categories. Labels should record which version they were made under, so training data can be converted or filtered when the taxonomy changes.

Without versioning, datasets mix incompatible labels and model performance drifts for reasons nobody can trace.

Measuring categorization quality

Report accuracy by category, not only overall, because errors concentrate in a few hard categories. Agreement between annotators on the same transactions shows where definitions are unclear. Gold sets with reviewed labels should be mixed into production work and refreshed as new merchants and patterns appear.

User feedback, such as people recategorizing transactions in an app, is another useful signal. Patterns in corrections often point to definitions or merchant mappings that need updating.

Taxonomy documentation for model governance

Banks and regulated lenders must explain the data behind their models. A documented taxonomy, with definitions, version history, merchant list changes and quality results, gives model risk teams the evidence they need. Labels should be traceable to the taxonomy version and guideline that produced them.

This documentation also helps product teams explain categories to customers and regulators when questions arise about how spending or income was classified.

Taxonomies across markets

Spending patterns and merchant types vary by country: local payment apps, utilities, transit systems and retailers differ. Global products often keep one top-level taxonomy and add market-specific subcategories and merchant lists. Annotators familiar with each market label its transactions more accurately.

Currency, tax and fee descriptors also differ by market and need their own rules.

Running a categorization program

Start with a pilot on your messiest descriptors, refine definitions with the people who use the categories and build the merchant list as you go. Mask account identifiers and work in secure environments.

Our financial data annotation outsourcing page explains how vetted Philippine teams with finance backgrounds categorize transactions and label financial documents, and table annotation guidelines for document AI covers statement and filing tables in the same cluster.