What is a transaction type calculation?

  • Updated on Jan 7, 2026
  • Published on Aug 20, 2024
Prev Next

A calculation is an optional component of a transaction type that triggers additional functionality for all transactions belonging to that type. 

A calculation:

  • Must have a type that triggers a particular LUSID function.

  • Can have a side to pass extra information to the function.

  • Can have a formula that drives the function.

Note: The result of a calculation can be examined on an output transaction.

TaxAmounts calculation

  • Requires side: YES

  • Requires formula: NO

Calculates tax amounts due. More information.

Note the following:

  • The result is stored in the output property specified by the tax rule set.

  • This calculation is ignored for a particular transaction if no tax rule set can be found to apply.

"calculations": [
  {
    "type": "TaxAmounts",
    "side": "Side1"
  }
]

TransactionSequence calculation

  • Requires side: NO

  • Requires formula: YES

Determines the order in which transactions are processed relative to transactions belonging to other transaction types if all are loaded into LUSID with identical effective at datetimes. More information.

The formula field must contain, or resolve to, an integer. The lower the number, the higher the priority in the processing queue. A formula can contain the following components:

  • A constant value, for example "1" or "98765".

  • A transaction field, for example "units", or property or derived property, for example "Properties[Transaction/default/GrossConsideration]".

  • An instrument field, for example "Instrument.InstrumentDefinition.InstrumentType".

For example, you could specify a TransactionSequence formula of "2" for a Buy transaction type:

"calculations": [
  {
    "type": "TransactionSequence",
    "formula": "2"
  },
]

…and a TransactionSequence formula of "1" for a Sell transaction type:

"calculations": [
  {
    "type": "TransactionSequence",
    "formula": "1"
  },
]

This means that if a Buy transaction and a Sell transaction are loaded into LUSID with identical effective at datetimes then the Sell transaction is processed first, even if it is loaded second in the same request (and therefore has a slightly later as at entry datetime).

Note you can use LUSID derived property formula syntax to create conditional statements, so for example:

"calculations": [
  {
    "type": "TransactionSequence",
    "formula": "If(Instrument.InstrumentDefinition.InstrumentType eq 'Equity') Then 2 Else 3"
  },
]

Txn:TradeToPortfolioRate calculation

  • Requires side: NO

  • Requires formula: NO

Looks up an exchange rate from the transaction to the portfolio currency in the LUSID Quote Store. More information.

Note the following:

  • The lookup is performed for the transaction date, not the settlement date (if they are different).

  • The result is stored in the Transaction/default/TradeToPortfolioRate system property.

  • This calculation is ignored if Transaction/default/TradeToPortfolioRate is explicitly added to a particular transaction.

"calculations": [
  {
    "type": "Txn:TradeToPortfolioRate"
  }
]

Txn:ExchangeRate calculation

  • Requires side: NO

  • Requires formula: NO

Looks up an exchange rate from the transaction to the settlement currency in the LUSID Quote Store. More information.

Note the following:

  • The lookup is performed for the transaction date, not the settlement date (if they are different).

  • The result is stored in the exchangeRate field.

  • This calculation is ignored if exchangeRate is explicitly set on a particular transaction.

"calculations": [
  {
    "type": "Txn:ExchangeRate"
  }
]

Txn:NotionalAmount calculation

  • Requires side: NO

  • Requires formula: NO

Calculates notional amount for transactions in instruments of type Future and ContractForDifference. More information.

Note the following:

  • For most contracts the calculation is txn price * txn units * (contract size / scale factor).

  • The calculated amount is in transaction currency, not settlement currency (if they are different).

  • The result is stored in the Transaction/default/NotionalAmount system property. See an example.

  • This calculation is ignored if Transaction/default/NotionalAmount is explicitly added to a particular transaction.

"calculations": [
  {
    "type": "Txn:NotionalAmount"
  }
]

Txn:BondInterest calculation

  • Requires side: NO

  • Requires formula: NO

Calculates accrued interest for transactions in instruments of type Bond, ComplexBond, InflationLinkedBond, CdsIndex and CreditDefaultSwap. More information.

Note the following:

  • The calculated amount is in transaction currency, not settlement currency (if they are different).

  • Accrual is calculated up to settlement date, not transaction date (if they are different).

  • The result is stored in the Transaction/default/BondInterest system property. See an example.

  • This calculation is ignored if Transaction/default/BondInterest is explicitly added to a particular transaction.

"calculations": [
  {
    "type": "Txn:BondInterest"
  }
]

Txn:GrossConsideration calculation

  • Requires side: NO

  • Requires formula: NO

Calculates gross consideration as an amount including accrued interest but before fees. More information.

Note the following:

  • The calculated amount is in settlement currency, not transaction currency (if they are different).

  • The result is stored in the Transaction/default/GrossConsideration system property.

  • This calculation is ignored if Transaction/default/GrossConsideration is explicitly added to a particular transaction.

"calculations": [
  {
    "type": "Txn:GrossConsideration"
  }
]

The calculation depends on the instrument type:

Instrument type

Calculation

Notes

Future, ContractForDifference

For transactions that increase a position, LUSID sets the gross consideration to 0.

The sign of the calculated amount determines whether it is a profit (+ve) or a loss (-ve), regardless of the direction of the transaction. So for example, both Sell and CoverShort-style transactions have a positive gross consideration if there is a receipt of profit, and a negative gross consideration if there is a payment of loss. See an example.

For transactions that reduce a position (that is, move in the opposite direction to the current holding), LUSID calculates the realised gain as follows:

notionalAmount - (notionalCost + variationMargin)

Bond, ComplexBond, InflationLinkedBond (but not MBS)

The basic calculation is:

txn units * txn price * exchange rate * (contract size / scale factor)

If the transaction price type is CleanPrice or Price, bond interest is then added (this is the value of the Transaction/default/BondInterest system property, or 0 if it is not set).

If the type is DirtyPrice, bond interest is not added.

See an example.

MBS (modelled as special kind of ComplexBond)

The basic calculation is:

txn price * txn units * exchange rate * current face

If the transaction price type is CleanPrice or Price, bond interest is then added (the value of the Transaction/default/BondInterest system property, or 0 if it is not set).

If the type is DirtyPrice, bond interest is not added.

See an example.

CdsIndex, CreditDefaultSwap

The calculation is:

(txn price * txn units) + accrual

Accrual is the value of the Transaction/default/BondInterest system property, or 0 if it is not set.

See an example. If the transaction price type is Price and you specify a par-like price of (for example) 102 or 98 then LUSID automatically converts this to a rate using the formula (100 - txn price) / 100. Alternatively, you can specify the rate directly yourself, for example -0.02 or 0.02.

All other instrument types

The calculation is:

txn price * txn units * exchange rate * (contract size / scale factor).

DeriveTotalConsideration calculation

  • Requires side: NO

  • Requires formula: YES

Calculates total consideration according to a user-specified formula. Note that LUSID typically expects this to be after fees, in contrast with gross consideration which is before fees. More information.

Note: The totalConsideration.amount field must be set to 0 on an input transaction for this calculation to occur. It cannot be omitted. The totalConsideration.currency field can be set as normal.

Note the following:

  • The calculated amount is in settlement currency, not transaction currency (if they are different).

  • The result is stored in the totalConsideration.amount field on an output transaction. See an example.

  • This calculation is ignored if totalConsideration.amount is set to an amount other than 0 on a particular input transaction.

For example, for transactions that increase a position you might want to calculate total consideration as gross consideration plus fees. Note that if you include any other calculations in the formula (such as Txn:GrossConsideration) then you must also include them in the transaction type:

"calculations": [
  {
    "type": "DeriveTotalConsideration",
    "formula": "Txn:GrossConsideration + Properties[Transaction/Fees/TotalCapitalisedFees]"
  },
  {
    "type": "Txn:GrossConsideration"
  }
]

For transactions that reduce a position you might want to calculate total consideration as gross consideration minus fees.

"calculations": [
  {
    "type": "DeriveTotalConsideration",
    "formula": "Txn:GrossConsideration - Properties[Transaction/Fees/TotalCapitalisedFees]"
  },
  {
    "type": "Txn:GrossConsideration"
  }
]