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 merchantdisplay_name
- If unavailable you should default to the processor
logo
and displaying merchanttokens
concatenated with the transaction type and location tokens- If the processor
logo
is unavailable but you have a merchant token then we recommend you display no logo and the merchanttoken
concatenated with the transaction type and location tokens - If the merchant tokens are unavailable we recommend displaying the processor
logo
and the transactiondescription
- If the processor
- 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 processorlogo
and thenames
. If these are not available then you should aim to show a generic transfer logo and the transactiondescription
.
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
Updated 12 days ago