This article describes how the Transaction Class and Transaction Roles are used in the transaction type configuration
Transaction Roles (grouped together in a Class) allow you to configure a taxonomy of transaction types and relate multiple transaction types to each other based on their economic behaviour. An example of where this is used is to relate "buy", "purchase", "sellReverse", and "acheter" (from a system which uses French language) together as equivalent transactions. This allows you to map these to a canonical "buy" in a transaction report.
The two attributes are defined as follows:
(1) Transaction Roles
The Transaction Role describes the economic effect of a transaction.
At its core, every transaction will be taking the portfolio longer (+) or shorter (-) and will apply to a holding which is long or short (a flat position is considered long).
Figure 1: LUSID defines the following roles
Broadly speaking, there are three levels of granularity. At Level 1, we use a value of "AllRoles" to capture transaction codes which can either increase or decrease holding quantities. At Level 2, we differentiate between transactions which increase the holding quantity (with the "Longer" role) and transactions which reduce the holding quantity (with the "Shorter" role). Level 3 offers the most granularity. Here, for example, we differentiate between a long transaction which increases a long position (LongLonger) and a long transaction which reduces a short position (ShortLonger).
Figure 2: How to decode a transaction role
We can also plot the transaction roles on a transaction movement 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.
Figure 3: The movements graph
(2) Transaction Class
The Transaction Class is used to group similar transactions within the same source together. For example, you might have a "FX" class to capture all FX transactions or "Swap" to capture all transactions related to Swaps (Pay Fixed, Receive Floating etc). It is expected that there is only one Transaction Type for each Role in each Class.
When should I use these configurations?
By assigning your transaction types a Role and Class, LUSID is able to link similar transactions together. In the example above, "buy", "purchase", "sellReverse", and "acheter" all originate from different sources so are configured in LUSID with different Groups. By assigning them the same Role and Class, LUSID can now produce a transaction report which maps the various transaction types to a single canonical set.
Some example uses cases listed below:
Example 1: A fund with one source of data
- Example scenario: a fund is loading one source of transaction data into LUSID, which is a set of files from their ABOR. The transaction data covers one long-only Equity fund.
- Proposed configuration: put all Transaction Codes from the external source in the "default" Transaction Group and give them the "AllRoles" Transaction Role. In this case, there is no need to define a granular Transaction Group or Transaction Roles. This is the default LUSID implementation.
Example 2: Mapping multiple codes to one common set for trade reporting
- Example scenario: an asset manager is feeding LUSID with transaction data from multiple ABOR and IBOR systems. These systems have hundreds of codes to represent the same underlying set of movements. For examples, purchases are represented as all the following in the external data set: "BUY", "Purchase", "B", "Buy", "buy", "B123", "BuyLong". This creates a challenge for the Product Managers internally who want to present users of their trade reporting with a set single transaction type.
- Proposed configuration: We recommend using a separate Transaction Group for each of the external sources. By assigning a common set of Classes and maintaining one Transaction Role per Transaction Class, you instruct LUSID to display the canonical codes when calling "get transactions".