Displaying enriched transactions

Transaction descriptions are often long, cryptic and not designed to be read by humans - showing customers enriched transactions is one of the easiest ways to improve your digital channels and increases your customer's ability to recognise transactions by 47%.

The Transactions Enrichments

Each enriched transaction will contain an enrichments object and a tags list. The enrichment object can contain information about the following elements;

Enrichment	Description
Categories	A level 1 and level 2 category that is predicted for the transaction, for example `food_and_drink`, `coffee`
Merchant	The merchant entity predicted for the transaction, this is typically the store or business that the customer has interacted with, for example `tesco`
Processor	Any other entities that have been detected as being involved in the transaction, for example `paypal`
Regularity	If detected, the regularity in which the transaction occurs, for example, `weekly`
Location	The location of where the transaction occurred including the full street address and the latitude and longitude coordinates
Transaction types	Any transaction types associated with the transaction, for example `card`, `debit`
Names	Any names associated with the transaction, typically found when transferring money to individuals, for example `jane doe`
Tokens	In many of our enrichment entities we include an attribute name `tokens`, this represents a list of strings correlated to the enrichment itself taken from the raw transaction information
Tags	A list of potential tags associated with the transaction after contextual enrichment which can be used for filtering, for example, `income`,`subscription`,`online`

More information and examples of each of these elements can be found in our Transactions guide.

Proposed Logic

When you combine the various elements of our transaction enrichments you can create a series of rules that utilise Bud's transaction enrichment as efficiently as possible and ensure the greatest percentage of your transactions are displayed enriched to your users. We propose following the rules listed below.

When available you should use the merchant logo and merchant display_name
If unavailable you should default to the processor logo and displaying merchant tokens concatenated with the processor name, transaction type, and location tokens
1. If the processor logois unavailable but you have a merchant token then we recommend you display no logo and the merchant token concatenated with the processor tokens, transaction type, and location tokens
2. If the merchant tokens are unavailable we recommend displaying the processor logo and the transaction description
If the processor logo and merchant tokens are both unavailable then we recommend you display no logo and the transaction description

📘
Please note, the exception to these rules is when we predict a transaction with the l1 category of transfers, in this case it is recommended to show the processor logo and the names. If these are not available then you should aim to show a generic transfer logo and the transaction description.

Displaying Totals

If you want to allow your customers to review their spending, it's best to do so by grouping transactions by categories or merchants, this can easily be achieved by using our Category Totals, or Merchant Totals endpoints. If you would like to compare spending in a category over time this can be achieved by calling the Category Totals Trends endpoint.

When displaying these totals back to customers there are a few design principles that we recommend you follow:

If displaying merchants or l2s you should also include a search bar
Categories or merchants should be ordered by the total spent (typically over the last 30 days or current month)
Categories that don't have any transactions should be hidden behind a 'see more' to avoid cognitive overload
Some customers find it valuable to see the number of transactions within each group
Business is a more customer-friendly term than merchant