Extensions Q3 / 2020 - Release notes

All deferral processes (Deferral of bond purchase price, Deferral of accrued interest and Deferral of other securities) now allow you to (optionally) create the generated deferral transactions as "Hidden", and to optionally to run the processes with a single click without a user interface, without the user having to make selections or to enter additional parameters when creating the deferrals. The latter allows you to for example automate deferrals.

Bookkeeping rules are now able to capture the profit / loss on the currency account that the transaction was made against. This allows you to create a posting rule on a security transaction (e.g. buy or sell) that is done against a currency account, that would capture the profit or loss on FX against the currency account. For example, "Deposit" 1000 USD on USD account with USD/SEK FX rate 10, and "Buy" a USD stock with 1 000 USD with USD/SEK FX rate 11 would result in 1 000 SEK profit on FX against the account since the deposit was worth approximately 10 000 SEK and implicit withdrawal along with buy was 11 000 SEK.

Deferral of bond purchase price process now correctly interprets a maturity price of 0 as 0, preventing the system for example from unnecessarily proposing deferrals for written-down bonds.

Deferral of accrued interest process now correctly creates deferrals even when the accrued interest is negative. Bonds can have negative accrued interest for example during their ex-coupon period, and deferral of accrued interest now creates deferrals also in such a case.

When generating deferrals per security, the Deferral of accrued interest process now applies FX rates correctly for accrued interest for non-portfolio currency securities.

Strategy Analyzer has been extended to support multiple strategies, contribution division between sec and fx and performance analysis against benchmark using a risk free rate. You can now select which strategy you want to use in the analysis, and you can now define the risk-free rate you want to use in the calculations either as a fixed percentage, percentage from security, or return from an index. In addition, performance analysis now allows you to track volatility, volatility (bm), risk free rate, alpha, beta, tracking error and Sharpe.

Strategy Analyzer can now better handle weight calculation in situations when either portfolio has a position that strategy does not have or vice versa.

Benchmark target weight calculation in Strategy Analyzer now correctly calculates the target weight as an average target for the given period, and min / max are no longer available on other levels than the sector.

Standard overview/position API now contains the following new fields: "securityId", which contains the security's DB ID for normal positions, and is not returned at all for accounts, "accountId", which contains the account's DB ID for the account rows that we return, and which is not returned at all otherwise, "fixing", which returns the security's "coupon" value, "dailyValueChange" and "dailyRecValueChange".

Standard transactionNote API has been extended with the following transaction and contact data: trade amount (tr.tradeAmount), accrued interest (tr.accruedInterest), taxes (tr.tax and tr.tax2), unit price corrected with multipliers (tr.unitPriceView), external ID (tr.extId) and contact external ID (contact.externalId).

Standard reports API now works correctly with API-based reports (i.e. 3.0 reports available from FA AppStore) in version FA 3.5 or newer. This API now uses the correct server API URL.

Standard documents API now correctly lists file paths (document/list?filePaths), i.e. correctly returning details of documents.

Standard user management/permissions API now work again correctly with versions FA 3.4 or newer.

Standard user management/authentication API is no longer part of the package - it is deprecated and removed from releases targeted for FA3.5+. Use KeyCloak APIs for authentication in FA3.5+.

M2Wealth integration now increases the level of detail in security import when interpreting security types. For some instruments the field "asstDetail.type" is not enough to determine the proper security type - for example, "Money Market" instruments can either be "Deposit" or "Loan", and the information comes in a sub-field "asstMnyMktDetails" which is now taken into account.

M2Wealth integration now properly handles loan and deposit transactions containing cash movement details inside the same transaction. New logic to pick the account details from the within the same "movement" allows you to get rid of an additional account mapping done by using "Default data mapping for external integration".

M2Wealth integration now supports picking up the dividend ex-date information when it is available for dividend transactions. Whenever available in M2 files in "addInfo" field on DIV movement types, the dividend ex-date is now mapped to the transaction date of the dividend transaction.

With M2Wealth integration, it is now easier to automatically process "light" asset details. With a lighter delivery of the security master data, the asset detail section ("asstDetail") might not contain all required data, and the integration now automatically determines if enough information is available in "asstDetail", and if not, uses codes from outside the section.

M2Wealth integration now allows you (optionally) to create the imported transactions as "Not finished". This allows you to set up a workflow where you review the imported transaction data: the "Not finished" transactions are reviewed by a user, who then sets the transactions to be "Accepted".

M2Wealth integration now allows you (optionally) to reconcile cash account balances in specific portfolios in addition to reconciling cash account balances throughout the system with a specific account number. This allows you to have duplicate account numbers in use in different portfolios, but still to reconcile cash balances portfolio-by-portfolio, without summing up account balances from accounts with the same account number.

For easier support and maintenance, M2Wealth integration now attaches the "raw" M2 files to all tasks created by the integration. This includes files received for transaction import, security import, cash reconciliation and position reconciliation. In addition, M2Wealth integration now produces audit system logs for "M2Wealth XML file received for processing" and "M2Wealth data processed", allowing you to follow up when files are processed.

M2Wealth integration no longer unnecessarily imports a break-down of costs for "fee" type transactions - cost break-down is relevant only for other types of transactions.

M2Wealth integration now correctly does cash reconciliation on settlement date instead of transaction date. Cash is usually settled per settlement date, and the "available balance" M2 sends is in reality "settled balance" - reconciling correctly on the settlement date prevents unnecessary settlement error when there are some unsettled transactions.

Coupons and expirations process now allows you to schedule the corporate action to be run on the ex-coupon date for ex-coupon bonds. When run has been selected to be done on the "Transaction date", the corporate action run will be scheduled on the ex-coupon date instead of the coupon date for bonds with an ex-coupon period.

Positions import process now allows you to import positions into your portfolios with a specific trade amount, instead of always using current market value as the positions' trade amount. You can now define your positions' trade amount either in security or portfolio currency, and the system will calculate the other required figures with the latest available FX rate.

When importing FX Contracts programmatically through the general importer, the contracts are no longer imported automatically to the system if the "auto import mode" has been set to "false" - data is imported to the system only after you "Confirm" the import from the import task.

MiFIR transaction reporting process now provides you with an additional .csv file of the reported data in addition to the .xml file that is sent to authorities. The .csv file allows you to view the to-be-reported data in Excel, which is easier to read and check than the official .xml format. In case the reported data contains varying number of elements (e.g. a transaction can have 0 to n number of decision makers), the data is concatenated into a single column.

FATCA reporting and CRS/DAC2 reporting processes now allow you to report multiple countries of residence and TIN/IN numbers, as specified by the authorities. You can add the TIN/IN numbers as concatenated string, separated by colon, for example as FI:020280-123A.

FATCA reporting and CRS/DAC2 reporting processes now allow you to set the "payment transaction currency", allowing you to report payment transactions in a fixed currency (such as EUR), in addition to reporting payment transaction in transaction's account's currency.

AIFMD reporting process now nets together future cashflow positions related to FX derivatives in the "MainInstrumentsTraded" (positions in the portfolio sorted by market value descending) section of the report with versions FA 3.7 and newer. With older versions of FA, future cashflows are excluded from the report.

AIFMD reporting process also contains various specific fixes. The report now correctly reports OTC rates in the corresponding section of the report, FX rate against EUR has been added for portfolios with currency other than EUR in "FXEURRate", "AggregatedValueRate" values are limited to maximum 100%, and identification type is now LEI in "BorrowingSourceIdentification" when LEI is used.

Fixed an issue related to number field conversions in the AIF profile available for portfolios in the Portfolio window, which resulted in errors with the AIFMD reporting process when certain sections were enabled.

You can now configure the "ReportingMemberState" for the AIFMD reporting process. Before, this was hard-coded to "FI".

AIFMD reporting process for DNB custody process contains various bug fixes. The report now uses the FX rate from the end date of the report to valuate unsettled transactions in the reporting currency in the Other assets and liabilities section, transaction type's effects are now considered when reporting values in Fund unit transactions section, and you can now exclude transactions from these sections in the report with a tag. In addition, the report no longer crashes when there is accrued interest to be reported.

In addition, fixed an issue in automatically upgrading to the latest version of AIFMD reporting process and AIFMD reporting process for DNB custody process during an upgrade to FA 3.8.

You can now select to show the "to" account to your users for your customer's deposits through an optional filed in FA Front's Deposit / Withdrawal process. This allows you to show which account your customer's withdrawal is deposited to.

FA Front's trading processes (Buy/Sell/Switch and Deposit/Withdrawal) now apply a proper date formatting in their date fields. Date formatting is fetched from Preferences, and matches the date formatting used to show dates throughout FA Front when the user logs in.

When doing a switch with the Buy/Sell/Switch process, both the buy and sell parts of the switch now get the same, configured trade order status. Before, the buy part of the switch was always created with status "Open", regardless of the status configured to be used.

New Rebate contracts process now allows you to manage different kinds of rebate structures, even complex ones, in a unified way. An example of a complex rebate structure is one, where investors receive rebates with various different rebate percentages, which vary from one security to another, and vary depending on the value of the client's total investments in the given security. This process also supports multi-tiered hierarchies of contracts, sales owners and investors, with the ability to pay out rebates to various levels within this hierarchy. We may, for example, pay out rebates to the investors themselves, or the investor's sales owner.

Standard capitalization process now allows you to capitalize the entire account balance. When entire account balance is capitalized, the process does not look for previous transactions to define the capitalization period and amount to capitalize but it looks for the account balances of the accounts-to-be-capitalized in pre-calculated portfolio report data. This allows you to accrue fees and kickbacks and capitalize them with correct effect on TWR even when you don't manage clients' cash accounts.

Income distribution formula, part of the Fund management process, can now allocate bought and sold income distribution per share class.

Fund management process now allows you to define cash-value-based swing thresholds (in addition to the current percentage-based swing thresholds) and two swing percentages. In addition, the process now stores prices before swing into fund security's market date in the "Close 4" field.

Fund management process now allows you to override the default logic for determining which accounts should be included in GAV (gross asset value) in NAV calculation. You can now use an account tag to indicate that a non-cash account should have an effect on NAV and not on GAV, allowing you to have and account balance that is positive and affects only NAV.

Fund management process now allows you to define an account number for the cash transactions into the fund, allowing you to direct the cash transactions into a specific cash account in the fund. If not defined, cash transactions' account is picked with the "AUTO" logic.

Fund management process now allows you to separately define a settlement date offset separately for positive and negative cashflows, which is used to set the settlement date of both the client orders and cash transactions into the fund. A settlement date offset on the fund security overrides this setting. In addition, the process now manages different settlement dates in client orders in cash transactions into the fund portfolio. When generating cash transactions into the fund portfolio, the logic aggregates all subscriptions and all redemptions per settlement date, and creates one transaction for subscriptions and one transactions for redemptions into the fund portfolio with the aggregate's settlement date.

Fund management process now allows you to (optionally) create the transactions into the funs as "Not finished". This includes cash transactions and all fee transactions, and would allow someone to separately accept the transactions before they affect the fund portfolio's contents.

Fund management process now allows you to generate just the NAV reports as a "preview" to the NAV calculation before actually calculating the NAV and saving the results. You can now create the reports as a preview to multiple funds at the same time - the NAV reports are stored under your funds' documents. In addition, Fund management process now allows you to calculate NAV on multiple funds at the same time with one click, without a preview in between.

Cash transactions the Fund management process creates to the fund portfolio based on unit holder withdrawals now have a correct sign also when the cashflow is negative.

In addition, Fund management process now maps cash transactions correctly based on the settlement date of the unit orders. The created cash transactions are grouped by cashflow direction, security and settlement date, and their total equals to the total value of the executed orders.

Fund management process now calculates the income distribution correctly also when the fund has more than one share class. In addition, the "Description" on the income distribution transaction now shows also "previous net income".

Fund management process now correctly considers the defined "Swing threshold for swinging down, in fund currency" correctly as a negative number, ensuring that swing is applied only if the net flow into the fund is over the defined "up" and "down" cash thresholds.

UCITS xml report process now correctly takes into account the effect of swing pricing: the report now uses the stored NAV in portfolio currency (multiplied with an FX rate) instead of using prices after swing to calculate the NAV of a share class.

UCITS xml report process now also correctly reports account balance (<BalAmt>) without unsettled transactions in portfolio currency.

Accrued kickback formula now allows you to use the actual number of days in the year for the calculations - this is available if you choose the Accrued kickback (ACT/ACT) formula instead of the Accrued kickback (ACT/365) formula.

Importing security data from a market data connector no longer attempts to run empty results through mapping and import. In addition, failed imports now produce audit system logs.

Market data connector to Stamdata no longer returns any unnecessary data if the security is not found from Stamdata (the basic info returns nothing).

Execute cash transfers process now sets the created transactions' transaction dates to be the date on which the transfer was executed. At the same time, the dates on the original trade order remain as-is for tracking purposes, and are not changed when executing the cash transfers.

New Avatalegiro profile allows you to track Avtalegiro payment registration status, related to outgoing/incoming payments and processes for handling Nets registrations. Before, the status information was only available for the Monthly savings process, but the new profile allows you to use these Avtalegiro payments even in situations where we don't want to use monthly payments.

Direct remittance has been added as a new payment file format for General incoming payments and General outgoing payments processes.

General incoming payments process now only allows you to execute cash orders automatically. Before, general incoming payments had logic to execute all matching non-executed trade orders it finds, but now automatic execution is applied only on cash orders.

General incoming payments process now uses the "trade amount" field of a trade order to track the payment related to the order. This allows you to use payments also to other types of orders than just "cash" orders (e.g. "Deposit"), when the trade amount rather than the amount determines the "cash" related to the order.

Creditor name in NETS payments file now has a character limit of 25, ensuring that the name no longer spills over to the next field.

Reconcile cash balances process now considers portfolio information included in the reconciliation file, allowing you to use the process to reconcile cash account balances in specific portfolios in addition to reconciling cash account balances with a specific account number. If the reconciliation file doesn't include information on the reconciled portfolio, cash reconciliation assumes reconciliation is done against given account number (account balance summed up from all portfolios with an account with same account number), and if the reconciliation file includes portfolio information, reconciliation is done against the specific portfolio's account (not all the portfolios with same account number).

Reconcile positions process no longer incorrectly complains about a mismatch when the reconciliation file includes a position with zero units - positions with 0 units is now considered as a match to "no position at all". Before, the position reconciliation showed an error because FA didn't contain a zero position.

Transaction confirmation and Trade order confirmation reports have been improved through small fixes, including number formatting for amount and unit price fields, showing the unit price correctly for bonds and showing costs and taxes with their correct translations in the summary section. In addition, the layout of these reports has been improved.

Settle transactions with a file (SWIFT) process now allows you to override the book entry account used in the SWIFT message through transaction's "Internal info". This allows you to control on the transaction level, transaction-per-transaction, which book entry account the transaction should be marked against in the generated settlement files. This is useful if your portfolios are associated with multiple book entry accounts, and you cannot use the one book entry account defined on the portfolio directly to all transactions.

Settle transactions with a file (SWIFT) process now works with DNB as the custody when creating MT540-MT543 settlement instructions. In addition, the process now works with DNB so that the settlement files for DNB contain only one transaction per file, and the DNB settlement files now contain required header information.

Settle transactions with a file (SWIFT) process has been enhanced to work with Handelsbanken (SHB). SHB settlement files now include account number for internal transfers (transactions are interpreted as internal transfers if their counter is not of contact type "Counterparty" (3)), and SHB swift message's application header block {2} format now matches SHB's requirements (message mode is "I" with no extra zeros).

End-client report for KU31 for Swedish tax reporting now contains the withholding tax from "fk003" for foreign individuals or companies who receive dividends from Swedish companies and pay withholding tax on these dividends.

In addition, fixed an error in Swedish tax reporting related to adding new data for "fk003", or withholding tax for foreign individuals or companies from dividends from Swedish companies.

Validate orders process now allows you to (optionally) analyze pre-trade limits on the orders-to-be-approved. The results of this pre-trade limit check are saved, and if pre-trade limits are breached, the validated orders are rejected.

Trade order execution process now allows you to decide whether you want the transactions created based on executing the orders to end up with the corresponding currency account ("AUTO" logic) or always with portfolio's default account ("DEFAULT" logic). By default, transactions are directed to the corresponding currency account, but you can change the behaviour through configurations.

Mass adjust trades process now takes into account multipliers correctly when dealing with unit prices.

Trading connectors operating through the trading micro-service contains various improvements. When connecting to the trading micro-service, the connector now identifies the receiver of the trade through a tag and the format of the trade through internal info, trading connectors now sends an "OrderStatusUpdate" message with status rejected from orders that can't be imported to FA, trading connectors can now identify portfolios based on portfolio's External ID, and cash-value orders are imported with price 1 to avoid import errors if the amount of decimals isn't large enough.

Allfunds trading connector now applies the possible rounding errors from the received redemption order confirmations in the correct "direction".

Trading connectors operating through the trading micro-service contains various fixes. Connectors now handle unit-based transaction types correctly, costs are imported correctly if they have been set up, "OrderStatusUpdate" message now contains a description, switf processor no longer crashes if it receives invalid data, order types are now dynamically determined based on the data, proper number formatter now ensures that order values get imported with the correct number of zeros even when the environment used different number formatting, and status "cancelled" results in orders being rejected.

Design-based importer now allows you to import multiple objects of same type. This allows you to for example create multiple contacts or multiple securities simultaneously with a single form.

In addition, QueryUtils now uses a read-only datasource. QueryUtils is used by several extensions to run queries to return information. These features no longer include a potential security vulnerability, since QueryUtils no longer uses a database connection which would allow inserting/updating/deleting data instead of only allowing to fetch data.

Design-based importer process has support for macros, and the process now allows you to schedule it even if it contains macros.

Workflow builder process now passes the "postings" variable to processes launched based on a saved search.