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 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):

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):

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:

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.

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:

In this scenario, whether you produce a transaction report for input or 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: