Views:

Every transaction you upsert to a transaction portfolio LUSID must resolve to a known transaction type in order to define the precise economic impact; that is, the effect on your holding in the underlying instrument, and also potentially on holdings in other instruments in the portfolio too (for example, currency holdings).

Note: By default, LUSID operates a ‘data load first’ policy, so transactions are upserted and resolution failures must be handled manually as a post-process step. You can increase the level of validation to reject transactions that do not resolve to transaction types. Find out more about this.

An upserted transaction:

  • Must have its type field set, specifying the name of a transaction type.
  • Can have its source field set, specifying a data provider for a set of transaction types.
  • Can be in a parent portfolio that has its transactionTypeScope field set, specifying a logical repository of transaction types valid for this portfolio.

Find out more about scopes and sources.

For each upserted transaction, LUSID examines the type field and performs the following steps in turn:

  1. LUSID determines the transaction type scope in which to look. If the parent portfolio has a custom scope set, LUSID examines that scope. If not, LUSID examines the built-in default scope. Unlike when resolving instruments, LUSID does not ‘fall back’ from a custom transaction type scope to the default scope.
  2. If a transaction has its source field set (for example, to Goldman) then LUSID searches the Goldman source in the given scope for a matching transaction type.
  3. If no transaction type is found, LUSID searches the default source in the given scope for a matching transaction type.
  4. If no transaction type is found and the transaction has a source of (for example) Goldman, LUSID searches the Goldman source in the given scope for a transaction type with isDefault set to True.
  5. If no transaction type is found, or if the transaction has no source, LUSID searches the default source in the given scope for a transaction type with isDefault set to True.

If a transaction type still cannot be found:

  • By default, the transaction is upserted into LUSID with metadata warnings, but excluded from holdings calculations. You should edit the type field of these transactions to supply a known transaction type.
  • If you have increased the level of validation to reject unresolved transactions, then the transaction is not upserted. You should specify a known transaction type in the API request before attempting to upsert again.

The following flow diagram summarises the mapping logic:
 

Keywords: resolve transactions, transaction types, mapping