Skip to main content

Preferences - Transactions

Transaction preferences allow you to set the options available in the fields when defining the information of a transactions in the Transaction window. Transaction type preferences allow you to control how your transactions affect your portfolio's contents.

Transaction cost types

Transaction cost types preferences allow you to define the cost types available for transactions. The cost types are used to categorize the costs and fees recorded to transactions: for example, transaction cost types can include advisory fees, custodian fees or broker commissions.

Transaction cost types can be defined in the Transaction cost types window in the Preferences. A cost type consists of a name and a type: the name is used to view and choose the type in the user interface and the type is used to identify the cost type.

In addition, you can categorize your transaction cost types, allowing you to associate a category to each of your transaction cost types. You can categorize your transaction cost types as Portfolio (investment service costs), Security (product costs) or 3rd (third party payments), and then further as Not categorized (default), One-off charges, On-going charges, Charges related to transactions, Charges related to ancillary services or Incidental charges, or from up to five additional Other cost categories. Cost category of a transaction cost type is utilized in ex-post cost analysis: when a category is set to a transaction cost type, the amount of the cost is summed into the selected cost category. For example, you can categorize the brokerage fees you record on your transactions as Charges related to transactions., when the amount of brokerage fee you enter into your transaction is considered as charges related to transactions in ex-post cost reporting.

Transaction types

Transaction type preferences allow you to see the transaction types available in the system together with the characteristics and effects of the defined transaction types. Transaction types are relevant when creating transactions: the transaction type selected for a transaction determines what kind of a combination of effects the transaction has on the portfolio.

For example, a transaction type "Sell" has a positive cash effect (e.g. money is deposited to portfolio's account with the transaction), negative amount and FIFO effects (e.g. a sell reduces the amount of the security in the portfolio), a sell would realize profits or losses and finally, taxes and costs reduce the trade amount of a sell (e.g. when there is a cost recorded to a sell of a security, the cost is deducted from the original trade amount and reduces the money you will actually get from the sell).

Note

Do not modify the standard transaction types' effects - instead, create a new transaction type and use one of the existing types as an example. Transaction type effects often work as a combination, and changing one and not the other might not have a desirable outcome - avoid making your own combinations.

preferences-transaction_types.png

Transaction types are defined with the basic information of the transaction type (code and name) and through relevant effects for each transaction type. When creating a new transaction type, effects are by default No effect or similar.

Type code*

Unique transaction type code that separates it from other transaction types.

Short name*

Short name for the transaction type, which is used in the reports as the abbreviation of the transaction type. Transaction's short name can be translated into different languages, while the transaction type's type code is used to identify the transaction types within the system and cannot be translated.

Name*

Name of the transaction type.

Cash effect

Choose from No effect, Adds cash or Reduces cash. The cash effect describes the effect the transaction has on the cash balance of the account linked to the transaction. For example, a "Buy" transaction reduces cash and a "Sell" adds cash on the portfolio's account by the trade amount of the transaction.

Net effect

Choose from No effect, Add or Reduce. The net effect affects the transaction's net cash flow to the portfolio. If there is no net cash flow on the transaction, then any effect the transaction has on the market value of the portfolio will affect the portfolio's performance (TWR). Net effect would counter these effects otherwise. The net effect works differently depending on the transaction type's cash effect: when the transaction doesn't have cash effect, then the net cash flow is directly depending on net effect and transaction's trade amount (for example, "Add" transaction type has the net effect "add" => positive net cash flow, and "Remove" transaction type has the net effect "reduce" => negative net cash flow). However, if the transaction also has a cash effect, the net cash flow of the transaction is the combination of the cash and net effects: "add" cash and net effects => positive net cash flow; "add" cash but "reduce" net effect => negative net cash flow; "reduce" cash but "add" net effect => negative net cash flow; "reduce" cash and net effects => positive net cash flow. For example, "Withdrawal" transaction type has the cash effect of "reduce" and the net effect "add", which results in a negative net cash flow effect.

Amount effect

Choose from No effect, Adds amount or Reduces amount. The amount effect describes the effect of the transaction's amount (i.e. units) on the amount of the security in the portfolio. For example, a "Buy" transaction adds amount and a "Sell" reduces amount of a position by the amount of the transaction.

FIFO

Choose from No effect, Add or Reduce. FIFO describes whether the FIFO valuation method is taken into account: no effect means that the valuation method is not taken into account, add means that the transaction is "in" and adds the amount of the security, and reduce means that the transaction is "out" and reduces the amount of the security.

Return effect

Choose from No effect, Adds return (profit) or Reduces return (cost). The return effect describes the effect of the transaction on the portfolio return. For example, a "Dividend" transaction adds return. From FA 3.9 onward, return effect determines whether a transaction is a profit (adds return) or a cost (reduces return). This allows you to explicitly control "Other profits" and "Other costs" in TWR calculation. For example, a "Dividend" transaction adds return and is considered as "Other profits". In addition, you can control for example where you want see the effect of kickbacks - even with positive cashflow, you can configure your kickbacks to reduce return (a cost), when kickbacks would increase your (negative) costs instead of reducing your (positive) returns.

Realized profit effect

Choose from No effect, Realize profits/losses, Realize profits/losses by closing open positions or Realize profit indirectly. The profit effect defines, whether the transaction realizes profits - Realize profits/losses calculates realized profits from the transaction, such as sell, and shows it as “realized profit” and as “capital gain” for taxation purposes, while Realize profits/losses indirectly calculates realized profits from the transaction, and shows it only as “realized profit” but not as "capital gain". For example, a "Sell" transaction realizes profits (shown realized profits from performance's point of view and as capital gains for taxation purposes), while a "Remove" transaction realizes profits indirectly (shown as realized profit from performance's point of view but not as capital gains on tax reports). From FA 3.9 onward, the effect "Realize profits/losses" works on its own, independent of other effects. This allows you to realize profits also when your position’s units don’t change, not only when buying or selling.

Purchase price effect

Choose the purchase price effect from the alternatives. Purchase price effect allows you to adjust your position's purchase price directly with your transaction's trade amount, even when your transaction doesn't have an amount effect. For example, transactions such as "capital return", "value adjustments" at year-end and "mark-to-market" for futures' handling often have a purchase price effect, only affecting your position's purchase value. For example "buy" and "sell" transactions don't have a separate purchase price effect, since they affect the position through the amount effect.

  • "No effect" - transaction's trade amount has no direct effect on the purchase price of the position.

  • "Add", "Add, record orig values", "Add in security currency", "Add in security currency, record orig values", "Add and set fx" and "Add and set fx, record orig values" - transaction's trade amount adds the position's trade amount in different ways. These options allow you to manage "value adjustments" at year-end for bookkeeping or "mark-to-market" on your futures' positions even for non-portfolio currency securities.

  • "Reduce", "Reduce, record orig values", "Reduce in security currency", "Reduce in security currency, record orig values", "Reduce and set fx" and "Reduce and set fx, record orig values" -transaction's trade amount reduces the position's trade amount in different ways. These options allow you to manage "capital returns", "value adjustments" at year-end for bookkeeping or "mark-to-market" on your futures' positions even for non-portfolio currency securities.

  • "Keep original purchase price", "Keep original purchase time" and "Keep original purchase price and time" - allows you to keep your position's original purchase times and values when changing a position to another. These allow you to maintain your FIFO chain and values for example for "exchanges" (keep original purchase time) or "subscriptions" when the new shares's purchase value is combined with existing lots (keep original purchase price).

Purchase price profit effect

Choose from No effect, Unrealized profit or Realizes negative purchase lots. Only available when transaction type has a “Purchase unit price effect”. Controls whether adding or reducing purchase price affects unrealized profits. This allows you to control TWR calculation: value adjustments for accounting purposes don't change “original” purchase value and thus don’t affect TWR, while capital returns change purchase value from TWR’s point of view. (Available from FA 3.9 onward)

  • No effect - purchase value is changed, but the “original” trade amount is not changed. Therefore, the unrealized profits in TWR are not affected.

  • Unrealized profit - also the “original trade amount” is affected and therefore the unrealized profits as well. In addition, if there is a difference in FX rates, which is possible if adding / reducing purchase value is done "in security currency" or with "set FX", the difference due to the FX rates is booked separately as "Realized FX profit".

  • Realizes negative purchase lots - same as the previous, but if purchase value is reduced with any of the "Reduce" effects AND the purchase value on a purchase lot would go negative, the negative part is recorded as realized profit. This effect is only used for “Capital return” transactions in Finland.

  • Unrealized profit via cost - affects the "original trade amount" of the buy transaction to which the cost is linked. Used, for example, for a legal fee that is added as a separate transaction ("Transaction cost" transaction type). The fee transaction must have the same Amount as the Buy transaction (to create a link between these tranasactions). The fee's Trade amount is added to the "original trade amount" of the buy transaction.

Market price effect

Сhoose from No effect, Adds market value or Reduces market value. Market price effect allows you to adjust your position's market value directly with your transaction's trade amount. This is useful if you don't get daily market prices on your securities, and want to instead adjust the market value of your position directly with transactions, for example for "Private Equity" and "real estate" investments. If you feed market prices on your security, transactions with market price effect has no effect on your position.

Cost category group

Сhoose a cost category group for your transaction from Portfolio (investment service costs), Security (product costs) or 3rd (third party payments). Within each group, select a further cost category from the next field.

Cost category

Сhoose a cost category for your transaction from Not categorized (default), One-off charges, On-going charges, Charges related to transactions, Charges related to ancillary services or Incidental charges, or from up to five additional Other cost categories. Cost category of a cost transaction is utilized in ex-post cost analysis: when a category is set to a cost transaction, the trade amount of such a transaction is summed into the selected cost category. For example, you can categorize your asset management fees as On-going charges, when the trade amount of your asset management fee transaction is considered as on-going charges in ex-post cost reporting.

Date effect

Сhoose from Effect on position on transaction date to Effect on position on settlement date. The date effect allows you to decide whether you transaction affects your portfolios positions on the defined effective transaction date (booked date if defined, otherwise transaction date) or on the defined settlement date. By default transactions have an effect on position on transaction date, but changing the effect on position on settlement date is especially useful for example when the effect of a deposit or withdrawal should not be shown on your bank account before the settlement date, allowing you to directly track the settled, actual available cash within your portfolio. If you configure your transactions to take effect on the settlement date, the transaction will affect all calculations, including positions, profits and other analysis, only from the settlement date onward.

Ratio effect

Choose from No effect or Relative effect on amount and unit price. The ration effect defines, whether the Ratio field of the Transaction window is available (no effect -> field not in use), and what kind of an effect the value in the field has on the security's amount and unit price.

Security 2

Сhoose from None, Is second security or Based on another security. The security 2 defines, whether the Second security field of the Transaction window is available (none -> field not in use), and whether the transaction type involves another security in addition to the security chosen to the transaction.

Group

Сhoose from No, Yes - same or Yes - opposite. Grouping defines, whether the transactions of the transaction type are grouped to a separate position, and do the transactions affect the same or opposite position.

Tax effect

Сhoose from No effect, Adds trade amount or Reduces trade amount. The tax effect relates to the upper tax field in the Transaction window (tax from trade amount). The tax effect describes the effect of the tax on the final trade amount.

Tax effect 2

Сhoose from No effect, Adds trade amount or Reduces trade amount. The tax 2 effect relates to the lower tax field in the Transaction window (tax from fees). The tax effect describes the effect of the tax on the final trade amount.

Cost effect 1

Сhoose from No effect, Adds trade amount or Reduces trade amount. The cost effect describes the effect of the cost on the final trade amount.

Cost effect 2

Сhoose from No effect, Adds trade amount or Reduces trade amount. The cost effect describes the effect of the cost on the final trade amount.

Paid in capital effect

Choose from No effect, Adds paid in capital or Reduces paid in capital. Defines how the transaction affects paid in capital value visible in Analytics+. The paid in capital is calculated based on transactions trade amount excluding taxes. If commitment type is “amount”, the paid in capital is calculated based on the transaction’s amount. (Available from FA 3.9 onward)

Commitment effect

Сhoose from No effect, Adds commitment or Reduces commitment. Defines how the transaction affects the total commitment of a position. The remaining commitment is then determined by subtracting paid in capital from the total commitment. For example, private equity transaction type "PE - Commit" increases commitment into a position.

Commitment type

Сhoose from Not defined, Price or Amount. Defines whether commitment is calculated based on transaction's amount (i.e. units) or price (i.e. amount x unit price). Mandatory to be selected (Price or Amount) if transaction has a "Commitment effect". (Available from FA 3.9 onward)

Distribution effect

Сhoose from No effect, Adds distribution or Reduces distribution. Defines how the transaction affects distribution visible in Analytics+. The distribution is calculated based on transactions trade amount excluding taxes. (Available from FA 3.9 onward)

Following buttons are available at the bottom of the Preferences:

Translate

Opens the Translations window for translating the transaction type, allowing you to save translations for the transaction type to be used in reports and the user interface, when a language other than the language of the transaction type is chosen.

Update

Updates the changes made to the transaction type to all the transactions of the updated type. The trade amounts and cash flows of the transactions in the all portfolios are re-calculated to take into account the changes made to transaction types, and the affected reports are re-calculated.

Versions

Opens the Versions window to allow you to follow the changes made to the information.

Clicks of the "Update" button are audited - user audit tracks user clicks on transaction type updates that might lead to report recalculation. Every time a user clicks Update in the Transaction type Preferences, user audit contains a message ”User [username] clicked Update in Preference/Preference”. Also, every time a report recalculation is started, system audit logs which portfolios' reports are recalculated and from which date onward. (Available from FA 3.9 onward)

Transactions

Transactions preferences allow you to enable the Transaction window to ask confirmation messages and to set the settlement date automatically. You can also define the default purchase price (original or transaction) to be used on the reports, and the trade order statuses available for your trade order flows:

Confirmation if the balance of the account is less than the total value of the transaction / Confirmation if the amount of the security in the portfolio is less than the amount defined in the transaction

By default, neither of these confirmation messages is enabled: you can set the system to ask one or both of the confirmation messages from the check box. The purpose of these confirmation messages is to make sure that a transaction does not by mistake make the account balance or the amount of the security in the portfolio negative. When a transaction is saved, the system confirms the action with a Yes/No pop-up window, if the total value of the transaction exceeds the account balance, or the amount of a security exceeds the amount of the security in the portfolio.

Set transaction's settlement date automatically based on transaction date

Enable or disable setting the settlement date automatically. When enabled, whenever you enter a transaction date, the settlement date is automatically set a certain number of business days from the transaction date.

Amount of business days to add to transaction's settlement date

efine, how many business days ahead the settlement date is set from the transaction date. You can override this on the security level: if the "Enable settlement date" has been enabled for the transaction's security (or cash transaction's currency's), the number of days defined in "Settlement date" is used to calculate the settlement date for trades in that security. In addition to how many business days trades take to settle, the transaction's security's (or cash transaction's currency's) holiday calendar is used to determine which days are business days.

Set trade order's settlement date automatically based on transaction date

Enable or disable setting the settlement date automatically. When enabled, whenever you enter a transaction date, the settlement date is automatically set a certain number of business days from the transaction date.

Amount of business days to add to trade order's settlement date

Define, how many business days ahead the settlement date is set from the transaction date. You can override this on the security level: if the "Enable settlement date" has been enabled for the transaction's security (or cash transaction's currency's), the number of days defined in "Settlement date" is used to calculate the settlement date for trades in that security. In addition to how many business days trades take to settle, the transaction's security's (or cash transaction's currency's) holiday calendar is used to determine which days are business days.

Use original purchase value in portfolio reports by default

By enabling this setting, the original purchase value is used in the portfolio reports by default for transactions with original transaction information defined. By default, this setting is not enabled, and the portfolios reports use the transaction purchase value - however, if original transaction information is defined for a transaction, this information can be set to be shown on the reports by default. No matter which price is used by default, you can always change this selection when creating reports.

Deleting a transaction is not allowed

By enabling this setting, deleting a transaction or a trade order is disabled, i.e. the Delete button in the Transaction or Trade order window is greyed out, and you cannot delete transactions or trade orders manually from the system through the corresponding window. In addition, when enabled, transactions with status "Deleted" cannot be modified by other than ADMIN users. See also Permissions for usage for preventing deleting transactions for a certain user role with permissions.

Available trade order statuses

Enable the trade order statuses you want to be able to utilize in your trade order flows. The available trade order statuses include Open, Accepted, Executable, Sent to execution, In execution, Partially executed in the market, Executed in the market, Settled in the market, Executed, Cancelled, Rejected and Expired. The statuses Open and Executed are always selected, since they are utilized by the system in different functions - the other statuses are free for you to choose from, depending on the trade order life cycle you want to maintain.