Extensions Q4 / 2020 - Release notes

Deferral processes (Deferral of accrued interest, Deferral of bond prices and Deferral of other securities) now allow you to optionally create postings on the deferrals without saving new transactions into the system. As a consequence, the created posting is not linked to a transaction since a transaction does not exist. This allows you to avoid huge number of transactions in the system, that are often even unnecessary especially when deferrals are reversed the next day.

Deferral processes (Deferral of accrued interest, Deferral of bond prices and Deferral of other securities) now generate a unique reference on all transactions generated from a deferral. This allows you to link transactions from one deferral run together.

Bookkeeping rules now pick up transaction's reference as the reference of each generated posting. This provides you with more tools to identify the link between a posting and a transaction, especially if you are creating deferrals without transactions.

Bookkeeping reporting process now allows you to optionally filter bookkeeping postings to be reported based on latest reported posting number - this picks up only postings with a higher number than previously reported posting into the report. This allows you to identify which posting to report without having to rely on postings' statuses "Ready" and "Reported".

Deferral of accrued interest and Deferral of other securities processes no longer overwrite transactions they create, if transactions are created for multiple securities at once. This was an issues introduced in the earlier versions of the process.

Deferral of other securities now works correctly when run retroactively on a date in the past, correctly picking up positions that were open during the date the process is run but have been closed later on.

Bookkeeping rules now allow you to create postings on fund's accrual. If you build a bookkeeping rule with "accrued interest", the logic now picks up the value from "accrual" for funds.

Bookkeeping rules now calculate and generate a currency gain / loss also on cash transactions, such as deposits, withdrawals and cashflows in / out. In addition, postings capturing currency account profit / loss using postings using CASH type postings now longer generate double postings for FX contracts - type CURRENCY should be used instead.

In addition, performance of Bookkeeping rules has been optimized: aspects of the rule (loading purchase lot date or historical transactions to calculate accrued interest) are now run only when applicable to the posting rule and the transaction, instead of always doing this on each transaction.

Strategy Analyzer now provides support for rebalancing benchmarks also quarterly, in addition to daily, weekly, monthly and yearly. This is available as a new option "Quarterly" under "Rebalance benchmark".

Strategy Analyzer now correctly calculates and aggregates contribution figures on group levels and total level within the analysis.

API: Analytics+ has a query parameter to include sub portfolios in the POST variant (includesubs = true) - this parameter now works correctly also in versions FA 3.7+.

You can now run the Send messages process against a list of portfolios searched on the Portfolios view, allowing you to mass-send messages regarding specific portfolios (e.g. mass-send emails to customers who own a certain type of portfolio).

You can now configure the Send messages process to optionally tag the contacts, portfolios, transactions or trade orders a message was sent based on, allowing you to ensure you don't send out messages again when you have already sent them.

Send messages process now also supports the use of email templates: when sending a message, you can select to use one of your pre-defined email templates to fill in the content of your email based on the template. In addition, the process now better guides you through which keys you can use in your templates to dynamically fill in information on your contact when mass-sending messages.

Messaging processes Send message and Send messages have an option to attach files to the messages, and these files are now again correctly included in the e-mails themselves and in the completed tasks recorded into FA with versions FA 3.8+.

Portfolio/asset value monitoring process now allows you to optionally tag the contacts or portfolios who got a value drop in order to be able to identify and search for them later. In addition, the process now saves the information regarding value drops in a contact or portfolio profile, allowing you to fill in the information later dynamically with a specific key. These improvements allow you to combine the Portfolio/asset value monitoring process with the Send messages process to first manually review value drops in your contacts or portfolios, and then mass-send emails about them to your clients later on.

Limit history and Detailed limit history queries allow you to get more information on past limit runs on multiple portfolios at once. The detailed version lists individual limits (1 row per limit per limit run per portfolio), whereas the non-detailed version only shows the overall result per limit run (1 row per limit run per portfolio).

Four eyes approval process now contains an example rule to enforce the four eyes principle before approving a trade order as having status "Accepted", allowing you to start use the four eyes approval on trade order status changes easier.

Setting different execution times on coupons, maturities and calls now again works correctly in the Coupons and expirations process.

Coupons and expirations and Corporate action import processes now correctly create corporate action runs and transactions with a proper FX rate to portfolios with different currency than the corporate action's security - the latest available FX rate is automatically fetched when the corporate action is run. Before, these processes always created corporate action runs with FX rate 1.

Import MiFID costs from EMT file process now supports the updated version 3 of the EMT file.

Positions reconciliation and import process now takes portfolio's price source into account when fetching FX rates, ensuring that the prices used within the import are fetched from the "close" linked to the portfolio in case prices are maintained in multiple "closes" simultaneously.

AIFMD reporting for DNB custody process now supports saving generated report file into filesystem, allowing you to automate sending the report forward through polling a certain folder in the filesystem.

AIFMD reporting for DNB custody process now correctly uses the last reporting date + 1 as the starting date for the report (instead of using the last reporting date directly).

AIFMD reporting for DNB custody process now also adds a description (Desc) element for all transaction types in "Other assets and liabilities" reporting.

For FATCA and CRS/DAC2 processes with report scope "Funds", reporting level selection now works when the report scope is "Funds", reports with scope "Funds" now produce correct results when there are multiple share classes with same IN, ReportingFI/IN tag now has sufficient attributes when creating the report for reporting scope "Funds", and report generation no longer results in an exception when reporting scope is "Funds".

FATCA process now correctly adds the "sponsor" section to the report only if the filer category is FATCA607.

FATCA process now contains the correct namespace specification <ftc:FATCA_OECD in the beginning of the report.

SIRA report process creates a done task when report is completed successfully. In addition, proper audit system logging has been added to the process

SIRA profile (used for investment fund reporting for Bank of Finland) now contains additional choices in the sector selector.

SIRA report process now calculates the ten largest unit holders per portfolio's primary contact in IF record's field #11 (instead of per unit holding portfolio).

SIRA report process now leaves out expired contacts, no longer resulting in unnecessary empty rows.

FA Front's Online trading process now supports accounts that are not "visible". This allows you to select an account for a trade that is not "visible" based the account's settings, which means the system doesn't keep track of that account's balance. Such accounts are now treated in the trading process so that it doesn't show an account balance for them and doesn't try to perform validation based on the balance. This allows you to for example show the end client's account to trade against, even though that account's balance is not followed in FA.

Approve document(s) process for FA Front now works again with version FA 3.7+ due to incompatibility of how this process handled logging.

Rebate contracts process now supports stepwise rebate percentage handling. This allows you to manage scenarios when rebate percentages are 30% for AUM below 100 000 and 50% for AUM above 100 000, and you want the process to apply rebate percentage 30% for the first 100 000 and 50% for the AUM above 100 000.

Accrued management fee and Accrued kickbacks formulas are now available also as versions that create separate fee transactions daily for each day during the time period that the fees are calculated for. These formulas allow you spit your fees (calculated during NAV calculation) into daily transactions even when the fees are calculated for a longer time period than just one day.

Fund-related fee formulas are now available with two versions: with ACT/365 and ACT/ACT.

Standard capitalizations process no longer crashes when run manually from the user interface

Accrued management fee and Accrued performance fee formulas no longer contain unnecessary logging that prevented running the formulas for example as part of calculating NAV in FA Fund Management application.

Accrued performance fee based on NAV and hurdle rate formula now picks up the correct NAV based on the start date to compare against.

Fund settings and Share class settings profiles (used for controlling fund-related parameters on fund portfolio and fund security) have been re-named and restructured. Fields are divided into categories, all sections have instructions on what to fill in, and styling has been made consistent throughout the tabs. In addition, new fields have been added for FA Fund Management application's purposes.

Fund management process allows you to optionally mark "ready" postings up till the NAV date as "reported" during the NAV calculation. Postings that are included in the NAV calculation are then marked as "reported", allowing you to easily see which postings were taken into consideration when calculating the NAV.

Fund management process now again correctly includes fund's accrual in the market value when calculating NAV. In addition, accrual is correctly rounded to two decimals when updating unit holder subscription and redemption orders.

Fund management process now interprets swing thresholds values correctly if only cash-based thresholds are used - default value 0 is now applied for the percentage thresholds when percentages have not been filled in.

Fund management process now stores a correct "Description" on the income distribution transactions created.

Fund management process now correctly runs the unit holder cash transactions created into the fund portfolio through any custom rules defined in the system.

Fund management processes automatic execution of orders now handles order's dates correctly: if automatic execution is enabled, trade orders are kept as they are (with the exception of updating the status to executed), and only the transactions are updated with the correct information (amount, unit price, trade amount and accrual, transaction date set to NAV date and settlement date calculated based on the offset defined in the fund profile). Without automatic execution, trade order is updated with the information (amount, unit price, trade amount and accrual, settlement date calculated based on the offset defined in the fund profile if not already defined).

Import MiFID costs from Morningstar process now works again correctly - the process is now using REST APIs for authentication and requests due to changes in requirements on Morningstar's end.

Rebalance templates process now uses the same rebalancing logic as FA Back does, ensuring that any fixes and improvements done in rebalancing in FA Back are also taken into account in the process. As a result, rebalancing no longer unnecessarily sells short if your cash is positive but would be pushed negative an outstanding withdrawal trade order and you have no investments in your portfolio - rebalancing logic now sells short only if your investment plan or model portfolio specifically contains a negative share for a short position.

Email synchronization process for Office 365 no longer tries to save email attachments to FA when the attachment is of a file type not allowed in FA - not allowed email attachments are filtered out when synchronizing emails.

General outgoing payments process now groups the payment file content correctly with total counting with NETS, direct remittance and Avtalegiro. When payment file is generated for NETS, Direct remittance or Avtalegiro with transactions that are based on different "contracts" (NETS or Direct remittance) or "creditor account" (Avtalegiro), the file now recognizes these groups correctly.

General outgoing payments process now allows you to override account and contract numbers in security level through a security profile for outgoing payment processing for NETS and Direct remittance.

General incoming payments process for incoming NETS payment processing now allows you to capture declined payments also when generating payments based on orders instead of transactions - orders that failed in NETS are set as "Cancelled" in FA.

General incoming payments process for incoming CAMT053 payment processing picks up creditor information and passes it on to the "Internal info" of the created payment transaction.

Swedish OCR number generation process now supports automatically generating OCR numbers for new portfolio without separate scheduling: OCR numbers now automatically get added to new portfolios after a 10-second delay, with no separate scheduling required.

General incoming payments process now works again with version FA 3.8+ due to removing unused dependencies.

General incoming payments process for incoming NETS (OCR) payment file processing now adds a new value to the generated reference to make it always unique. This ensures the process creates a payment transaction in FA even when there are multiple payments coming to the same portfolio on the same date and with the same trade amount.

General outgoing payments process no longer mixes up payer and receiver accounts in direct remittance.

Mandate request generation and approval process now works without showing an unnecessary error when it saves files that have errors in validation.

New Document checker process allows you to tag Contacts, Portfolios, Securities, Transactions or Trade orders depending on whether or not they contain any documents. You can use this process for example to find active portfolios or transactions that don't have any agreements attached.

Populate fixings for floating rate notes now supports creating all missing fixings starting from last found fixing date and ending to current date when security specific offset is applied. This allows you to use the process to correctly fill in the fixing history instead of only creating fixings for the current date.

For improved usability, Transfer assets between portfolios process now uses the standard group, customer, portfolio selector when transferring assets between different client's portfolios and the portfolio list can be very long.

New queries Audit: Securities created during time period and Audit: Transactions and trade orders created during time period allow you to easily find out when security / trade data was entered into FA. The queries displays identifiers of securities / trades that were created during a chosen time period, as well as the creator and exact date/time that data was entered.

New Market value distribution of all portfolios query produces statistics regarding the number of portfolios of various sizes in the system, broken down into categories: this query provides a distribution of the number of portfolios with market values in specified ranges.

Populate fixings for floating rate notes now applies multipliers and takes the holiday calendar into account when offset is used - base instrument’s multiplier is used when fixing value is calculated and base instrument’s holiday calendar is used to calculate correct date when using offset days.

P/L - Performance reports (P/L - Performance, P/L - Performance and value history and P/L - Performance and value history with accrued interest) now work again with version FA 3.8+ due to changes in chart themes used on the reports.

Performance and cashflow and Monthly performance reports now work again with version FA 3.8.5+ due to changes in Analytics+.

Schedulable report generation now saves generated reports into a correct location and works correctly with API-based reports (i.e. 3.0 reports available from FA AppStore) using the correct server API URL in version FA 3.5+.

Schedulable report generation now allows you to schedule generating single-day reports on any date - before, your single-day report had to be generated for the current date in order for it to work with the process.

Positions in currency report now wraps long security names to multiple lines within the report, allowing you to always see the entire security name.

SWIFT process for settlements now allows you to control on custodian level through a tag (SettlementCondition-Allow partials / SettlementCondition-No partials) whether the custodian allows partial settlements or not.

SWIFT process for settlements for Danske now picks up the customer identification number from the transaction's portfolio's Custody contact's external ID "Danske".

Signicat Sign process now uses the language of the email recipient instead of the language of the assignee of the signing task to determine the language used in the email that is sent out. This ensures the email's language corresponds with the preferences of whoever is receiving it, regardless of whom the signing task was assigned to.

VSAPUUSE, VSOMHOIE, VSRAERIE and VSULKOSE reports in Finnish tax reporting process now allow you to configure the contact person's name and phone number, that will then be included in these reports' fields 041 (name of the contact person) and 042 = (telephone number of the contact person).

VSAPUUSE report (Annual notification - Purchases and sales) in Finnish tax reporting process produces a .csv file for the purposes of checking the data - the column order in this extra .csv file now follows the order of the columns in the Tax authority's specification of the report, making it easier to check that all columns contain the correct data according to the specification.

VSAPUUSE report (Annual notification - Purchases and sales) in Finnish tax reporting process now allows you to exclude certain transaction from the report with a tag "VSAPUUSE_exclude". This allows you for example to handle situation when your custodian will report some of the transactions, and you as the wealth manager will only report certain types of transactions, such as sells.

VSOMHOIE report (Annual notification - Asset management fees) in Finnish tax reporting process now leaves proper traces into the system after the process finishes: a "Done" task is now created when process is ended with "Done" button and an audit system log is produced out of the created files. This is now consistent with other reports within the Finnish tax reporting process.

VSTVERIE report (Annual notification - Profits and shares) in Finnish tax reporting process now supports reporting all together 9 payment types taxable under "Income Tax Act" (TVL). In addition to previously supported 2B (Annual distribution paid out on a yield share), 2G (Mutual fund share) and 3L (Shares in foreign UCITS), the report now also supports 2D (Other interest or other income from investment (capital income)), 2E (Aftermarket bonus paid by the filer to the taxpayer (is capital income for the taxpayer concerned)), 2F (Aftermarket bonus withheld (received) by the filer (is a tax deduction for the taxpayer concerned)), 3J (Annual distribution paid out on foreign shares in foreign UCITS), 3M (Interest paid/intermediated from another EU member state) and 3K (Interest paid/intermediated from a non-EU country). Transactions are now picked up to the report based on their tag corresponding with the types above.

VSAPUUSE report (Annual notification - Purchases and sales) in Finnish tax reporting process now correctly fills in field 162 (Purchase price of securities, is known / is not known) as "1 = purchase price is not known" if field 161 (Purchase price of securities) contains a zero value 0,00. This ensures missing purchase prices are reported correctly also in field 162.

VSTVERIE report (Annual notification - Profits and shares) in Finnish tax reporting process no longer unnecessarily reports zero transactions when there are no paid/received accrued interests in bond buy/sell transaction and the transaction has tag 2E/2F.

VSTVERIE report (Annual notification - Profits and shares) in Finnish tax reporting process now works without errors if the reported portfolio contains securities that are not included in the report and don't have the required "class 3" information defined. Report now ignores if securities that should not be reported don't contain "class 3" information.

VSULKOSE report (Annual notification - Foreign dividends) in Finnish tax reporting process now uses the correct FX rate from the dividend transaction to report the dividends.

Norwegian tax report process is now using the latest schema version (3.1 for Verdipapirfond and 3.0 for ASK), as required by the tax authorities for 2020 reporting.

Norwegian tax report process now properly supports reporting inheritance and gifts. Gift / heritage transactions are reported in pairs, pairs having matching "give" and "receive" transactions - together with counter portfolio information, transactions should have matching reference numbers to enable proper linking, and type of the transactions to be reported is handled with tags.

Logic to determine which transactions are included as deposits and sells in ASK report in Norwegian tax reportprocess has been improved: instead of checking transaction type’s effects, the logic now checks transaction’s netcashflow, resulting in that subscription and redemption transactions without an account are also picked up on the report.

Reseller reporting within Norwegian tax report process now allows you to correctly report market values of positions at the end of the year in addition to aggregated amounts.

Norwegian tax report process can now properly pick up fund's "accrued income" also from transaction's "accrual" field (in addition to picking that information up from transaction's "internal info" or security's "close 5"). This allows you to store accrual in the specific field developed for it, and to use that field's value directly in tax reporting.

In addition, you can now schedule generating the Norwegian tax report process, allowing you to schedule the report to be run on a time when there is lower server load. This will help in generating the report on large sets of portfolios, which can be very heavy on the system.

Norwegian tax report process now correctly considers RISK, which was used in Norway on purchase lots before 2006. RISK is now also applied on companies / organizations.

ASK report in Norwegian tax report process now calculates values correctly over the year change also when there are no transactions within one calendar year but before and after.

Verdipapirfond report in Norwegian tax report process now reports the amount of positions at the end of the history period (last day of December on reporting year - 1) correctly also if there is a split/merge with some other than 1:1 ratio in the history.

KURED process for Swedish tax reporting is now using the latest schema version (6.0), as required by the tax authorities for 2020 reporting.

New Schedulable trade order execution process now allows you to schedule trade order execution against a search made in Trade orders view - you can make a search on the Trade orders view to find the orders you want to execute, and then schedule this new process to do that automatically.

Bulk trade orders and Bulk order execution processes now consider trade order's execution method - if an execution method is defined for a trade order, that is used to determine whether order is "unit-based" or "trade-amount-based".

In addition, Trading connector toolbox version 1.2 now provides the tools for Trading microservice 1.2. This package contains general outbound connectors per channel for FIX, FundSettle and Allfunds, improved error handling, and tools for a user-friendly way to configure trading connectors through a configuration profile and a decision table. In addition, missing settlement date now correctly prevents a trading message from being created.

Allfunds trading client process now works with version FA 3.8.

Allfunds trading client process now handles rounding errors correctly - the logic now compares involved currencies correctly to determine how to apply rounding error.

New Keystore upload process now allows you to upload keystore files from the user interface to a centralized keystore that is used by integrations. This allows you to import required keys and certificates and immediately start using them without technical work.

New Decision table administration process now allows you to administer decision tables: it allows you to upload decision tables, activate them, and get feedback about the rules that were (or weren't) created as a result.

Design-based importer and Integration startup tool processes have been extended to provide us with the technical facilities to in he future build separate, easy-to-use preference windows to configure setups without user having to go into the complex process configurations.

FA Diagnostics package contains a couple of fixes: "Position validity" query was removed since it was too heavy to be run in many cases, "DIAG Reimport invalid tr dates" query has been updated to pick up transactions with transaction/settlement/payment date more than 1 year in the future (rather than using an outdated fixed cutoff of 2020-01-01) and "DIAG Invalid Tr Dates" query has been updated to also check payment dates.

General monitoring process now works with scripts using extension JARs.

Fixed issues starting Scheduling manager process if triggers were missing.

In addition, proper audit system logging has been added to Scheduling manager and Define mapping for external integration processes.