---
title: "How do transaction type class and roles work?"
slug: "how-do-transaction-type-class-and-roles-work"
tags: ["roles", "transaction type class"]
updated: 2025-11-19T09:00:11Z
published: 2025-11-19T09:00:11Z
canonical: "support.lusid.com/how-do-transaction-type-class-and-roles-work"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://support.lusid.com/llms.txt
> Use this file to discover all available pages before exploring further.

# How do transaction type class and roles work?

A transaction type must have a *role* and a *class*. Together, these optionally enable you to classify economically-similar transaction types in different [sources](/v1/docs/grouping-related-transaction-types-using-scopes-and-sources) together **for reporting purposes**.

For example, you can relate “B”, "purchase", "sellReverse", and "acheter" (from a system which uses French language) together as equivalent transaction types. This allows you to map these to a canonical "Buy" in a transaction report.

> **Note**: It’s important to remember that a transaction type’s role and class does not affect its economic impact. A transaction with a type of “purchase” uses the movements of that type to impact portfolio holdings, and similarly a transaction with a type of “acheter” uses the movements of *that* type. But you can classify both as the same transaction type in a transaction report.

## The `transactionRoles` field

A transaction type must have at least one alias, and each alias has a `transactionRoles` field that expects one of the values below describing the effect of all transactions belonging to that transaction type.

Fundamentally, every transaction takes the portfolio either longer (+) or shorter (-), and itself applies to a holding that is long or short (a flat position is considered long):

![](https://cdn.document360.io/d575ad81-c0ed-4980-bbd1-d59ac5c3de82/Images/Documentation/265b04ab-156c-4268-8174-12c5439c3390.png)

Broadly speaking, there are three levels of granularity. At Level 1, we use a value of `AllRoles` to classify transactions that can either increase or decrease holding quantities. At Level 2, we differentiate between those that increase the holding quantity (with the `Longer` role) and those that reduce the holding quantity (with the `Shorter` role). Level 3 offers the most granularity. Here, for example, we differentiate between long transactions that increase a long position (`LongLonger`) and long transactions that reduce a short position (`ShortLonger`):

![](https://cdn.document360.io/d575ad81-c0ed-4980-bbd1-d59ac5c3de82/Images/Documentation/049e7c78-af20-451f-b924-bf59a72fa816.png)

We can plot this on a graph. As you can see, `LongLonger` and `ShortLonger` are used to increase a portfolio's position, but they start from a different point in the portfolio:

## ![](https://cdn.document360.io/d575ad81-c0ed-4980-bbd1-d59ac5c3de82/Images/Documentation/3976bd3b-3bc3-496f-ab8b-39cec46d4ab6.png)

## The `transactionClass` field

A transaction type must have at least one alias, and each alias has a `transactionClass` field that expects a value grouping together similar transaction types from the same [source](/v1/docs/grouping-related-transaction-types-using-scopes-and-sources).

For example, you might have a `FX` class to capture all FX transaction types, or `Swap` to capture all transaction types related to swaps (Pay Fixed, Receive Floating and so on). It is expected that there is only one transaction type for each role in each class.

## Example usage

By assigning your transaction types a role and class, LUSID is able to map similar transactions together for reporting purposes. In the example above, "B", "purchase", "sellReverse", and "acheter" all originate from different data providers, and so transaction types are grouped in different sources.

By assigning them the same role and class, however, LUSID can produce a transaction report that maps various transaction types to a single canonical type. This is one with the same role and class residing in the built-in `default` source provided with LUSID, for example:

| Transaction type | Source | Class | Roles |
| --- | --- | --- | --- |
| `B` | `Refinitiv` | `Trading` | `LongLonger` |
| `purchase` | `BBG` | `Trading` | `LongLonger` |
| `sellReverse` | `Rimes` | `Trading` | `LongLonger` |
| `acheter` | `CreditSuisse` | `Trading` | `LongLonger` |
| `GenericBuy` | `default` | `Trading` | `LongLonger` |

In this scenario, whether you produce a transaction report for [input or output transactions](/v1/docs/input-and-output-transactions), LUSID displays:

- The canonical transaction type from the `default` source in the `type` field (highlighted in yellow below). The movements in this type are *not* used to impact the portfolio’s holdings; this type is purely for reporting purposes.
- The original transaction type in the `Transaction/default/TxnInputType` system property (highlighted in green below). The movements in these types *are* used to impact portfolio’s holdings, but this is obfuscated for reporting purposes:

![](https://cdn.document360.io/d575ad81-c0ed-4980-bbd1-d59ac5c3de82/Images/Documentation/image-CCNY654S.png)