Configuring transaction types

LUSID has a flexible transaction modelling system which allows you to configure your own transaction types and/or use a set of canonical types.

The Problem

One of the biggest challenges in migrating your investment records from one system to another is in ensuring that your transactions are represented correctly in the new system.

It is critical that the new system can interpret each transaction appropriately and determine what the underlying movements in cash and securities are.

This can be difficult when transactions are given esoteric types such as '1085' or 'STP' (STP is the MT940 SWIFT transaction type for Stamp Duty, but it could just as easily be an acronym for 'Sale Third Party' or 'Sale Transaction Processed').

The end result is typically a lot of time spent chasing down the handful of people in the organisation that understand the meaning of each transaction type and then laboriously mapping those to the new system's available types. This is one of the reasons that migrations between systems can take so long.

The Solution

Rather than forcing a set of transaction types onto you, LUSID allows you to configure your own set of transaction types. Each type specifies the underlying movements that should occur when a transaction with this type is upserted into LUSID.

Each type also contains a list of aliases. These allow you to specify multiple transaction type codes that may have the same underlying movements. For example the transaction types 'BUY', 'BY' and 'B' may all represent a buy transaction which results in an increase in the number of securities held and a corresponding decrease in the cash balance.

Details

Aliases

Each alias has the following fields:

  • type - This is the transaction type that this configuration will apply to
  • description - A text description of the transaction type
  • transactionGroup - Identifies a group of transaction types e.g. all types from a given accounting system
  • transactionClass - The class that groups together all the available transaction roles
  • transactionRoles - The roles used to map holdings back to appropriate output transactions

Movements

Each movement has the following fields:

  • movementTypes - Movement types determine what the impact of the movement is on the holdings.
  • side - The side determines which of the fields from our Transaction are used to generate the Movement. Side1 means the "security" side of the transaction, ie the Instrument and Units; Side2 means the "cash" side, ie the Total Consideration
  • direction - a multiplier to apply to Transaction amounts; the values are -1 to indicate to reverse the signs and 1 to indicate to use the signed values from the Transaction directly. For a typical Transaction with unsigned values, 1 means increase, -1 means decrease
  • properties - This allows you to attach a property to the underlying holding
  • mappings - This allows you to map a transaction property to a property on the underlying holding

Examples

{

"aliases": [

{

"type": "Buy",

"description": "Purchase",

"transactionClass": "Basic",

"transactionGroup": "default",

"transactionRoles": "LongLonger"

},

{

"type": "BY",

"description": "PURCHASE",

"transactionClass": "Basic",

"transactionGroup": "alt1",

"transactionRoles": "LongLonger"

},

{

"type": "B",

"description": "PURCHASE",

"transactionClass": "Basic",

"transactionGroup": "alt1",

"transactionRoles": "LongLonger"

}

],

"movements": [

{

"movementTypes": "Settlement, Traded",

"side": "Side1",

"direction": 1,

"properties": [],

"mappings": []

},

{

"movementTypes": "Commitment, CashSettlement",

"side": "Side2",

"direction": -1,

"properties": [],

"mappings": []

}

],

"properties": []

}

Technical Specifications

You can see further details on how to configure your own transaction types in our technical documentation. You can also find an example of setting up your transaction type configuration here.