FA Back 3.22 - Release notes
Released: March 2024
FA Back 3.22 offers many new features. To mention a few, you can now create security groups, get better insight into report calculation statuses, and compound interests on a bond. There are also several bookkeeping improvements.
Security groups
Why?
We added this feature to allow users to control which securities customers can trade in FA Client Portal. In the future, security groups will have other uses in FA Back and extensions as well.
Who is this for?
For now, this feature is for users who want to control the securities customers can trade in FA Client Portal.
Details
You can now create security groups in Groups view if you want to restrict trading by, for example, underaged or non-professional customers. Security groups do not currently affect trading in FA Back, only in FA Client Portal.
You can create two types of groups:
Static groups, where you manually select securities to include in the group.
Dynamic groups, where you create criteria which the system uses to automatically include securities in the group. For example, you can create a group that includes all bonds in the currency EUR.
Select which securities a portfolio can trade in the Portfolio window. You can see in which groups a security is and edit the static groups for it in the Security window, but you can only edit dynamic groups by changing the criteria in Groups view.
 |
 |
 |
Learn more: Groups view in FA Back reference
New fields in extended search criteria
Why?
We added this feature to improve the precision of searches in FA Back views.
Who is this for?
This feature is for users who want to follow up on items that have been changed in the system or who want to search for trade orders based on the execution method.
Details
We added the Last modified field as an extended search criterion in all FA Back search views. We also added the Execution method field as an extended search criterion in the Trade orders view. You can use the new filters for more precise search results.
 |
Learn more: Quick search and filtering in FA Back reference
Showing report calculation statuses
Why?
We made this update because until now, users couldn't follow report calculation processes. The new functionality enables the users to monitor the status of portfolio calculations before generating reports.
Who is this for?
This update is for all FA Back users, and especially users who generate reports.
Details
We added new tools to help you monitor the status of report calculations. You can now:
Check when and what kind of calculations were last done for a portfolio. By clicking the new icon in the Portfolio window, you can view the completed and failed report calculations. The window shows what kind of calculation was done, if it was completed or failed, when it took place, and the date from which onward the calculation was done. In Preference, you can configure the number of days the completed calculations are stored which determines which report calculations are automatically deleted after the nightly position calculation. You can get the same information also in the Portfolio view columns Purchase lots updated and Positions updated or through GraphQL APIs.
See pending, ongoing, and failed report calculations. The Update menu now has an option for checking the pending, ongoing, and failed report calculations in a new window. The window shows when the calculations were scheduled, from which date onward the calculation should be done, the type of the calculation, and what portfolio the calculation is for. You can export the list as an XLSX file or delete the records. The system automatically deletes failed calculations after 30 days. You can also get the data through GraphQL APIs.
Get notified if there are portfolios with pending report calculations when generating reports. Report generation now shows you a notification if the report you want to generate includes portfolios with pending calculations.
Learn more: Portfolio window, Update in FA Back reference
Option to include exchange day in TWR for end-of-day fund exchanges
Why?
We implemented this feature to improve flexibility in end-of-day exchanges of fund share classes so users can choose if performance should be based on the current or previous day’s NAV.
Who is this for?
This feature is for fund companies that do end-of-day exchanges in share classes.
Details
You can now get TWR based on the current day’s NAV. This is useful, for example, if you increase or decrease the amount you invest in a fund so that the total investment qualifies for a different share class with a different fee.
You can use the new transaction type effect Removes 2nd security, end of day with the purchase price effect Keep time. The position is then moved to the exchange date and the performance of the old position is calculated until the end of the exchange date. Previously, performance was only calculated until the day before the exchange.
Learn more: Preference - Transactions in FA Back reference
Option to compound interest on a bond instead of paying out the coupon
Why?
We implemented this feature to allow users to compound coupon payments on a bond because coupons are not always paid out and booked separately as transactions in a portfolio.
Who is this for?
This is for back-office users who create bonds in the system and need to compound interest on bonds. This is especially relevant in the Danish market where Payment in Kind (PIK) bonds are common.
Details
Until now, you could only have bonds that capitalize interest as a transaction in FA. This is not ideal with, for example, Payment in Kind (PIK) bonds where interest is compounded and accrued on the compounded coupon as if it were capital. Another example case is if you have a bond in a model portfolio for which you want to track bond performance with coupons but without separate transactions.
There is a new Payment type field in the Security window with three options:
Payment in cash - Default option, same as was available before.
No payment, accrued coupons - Accrue up unpaid coupons and show them as accrued interest instead of accrued profit.
Payment in kind, accrued coupons - Accrue up unpaid coupons and accrue interest on them across the life of the PIK bond.
 |
Learn more: Fixings in FA Back reference
Ability to import and use stored performance history data in Analytics+
Why?
This feature was implemented to provide users the option to import TWR data instead of dynamically calculating it to improve performance and make migration to FA more convenient.
Who is this for?
This feature is for Analytics+ users with a long transaction history and new customers who want to import old TWR data into FA.
Details
If you have a long history of TWR data (for example, 15-30 years), it is often unnecessary to dynamically calculate TWR data from the start. It can also be useful to be able to lock some TWR data if you are migrating data from another system to FA.
There is a new field Use imported TWR up to in Preference. You can use the field to lock imported TWR data that should be used until the selected date instead of calculating TWR dynamically. For later dates, TWR calculation is done dynamically based on transactions and position data in FA. By default, the date is set as 01-01-1970.
When you have selected a date, you can import TWR data as a CSV file, and the imported data is used up to the selected date. When you export TWR data, you can see what data was imported and what was dynamically calculated.
 |
 |
Learn more: File formats for importing TWR in FA Back reference
New preference for posting generation
Why?
We implemented this feature to allow users to choose when postings should be generated based on individual needs.
Who is this for?
This feature is for users who generate bookkeeping postings.
Details
Until now, FA Back always prompted the user if they wanted to generate postings when using posting rules. Some users want postings to always be generated and others want to mass-generate postings, so the prompt is unnecessary. In Preference, you can now choose if you want to be prompted or if the system should automatically generate postings or not:
Ask the user if postings should be generated
Always generate postings when saving a transaction
Never generate postings when saving a transaction
 |
Learn more: Preference - Bookkeeping in FA Back reference
Visibility into transactions for which no postings were generated
Why?
We implemented this feature to give users visibility into which transactions did not get postings during mass generation.
Who is this for?
This feature is for users who mass-generate bookkeeping postings.
Details
Until now, you had to open transactions individually to see which ones did not get postings during mass generation. The system now notifies you of the transactions that are missing postings in a new window, and you can export the list of transactions as an XLSX file. This functionality is useful, for example, if your bookkeeping preferences are set to not generate postings when saving transactions.
 |
Learn more: Posting-based bookkeeping in FA Back reference
Postings on parent portfolio level
Why?
We implemented this feature to enable users who have both parent portfolios and subportfolios to aggregate all postings on the parent portfolio level.
Who is this for?
This feature is for users who generate bookkeeping postings and have parent portfolios and subportfolios.
Details
Until now, in cases where there is a parent portfolio and all transactions are in subportfolios, bookkeeping postings have also been in the subportfolios. You can now get an aggregated view of the postings on the parent portfolio level. This feature only supports simple parent portfolio + subportfolios structures.
Portfolio window has a new checkbox Postings on parent level. If you enable this setting and the portfolio has a parent portfolio, postings are generated into the parent portfolio instead.
 |
Learn more: Portfolio window in FA Back reference
Other improvements
We removed the option to manually add or edit key figure values related to portfolio credit, meaning collateral value, used credit, and available credit. The key figures are now automatically calculated when you use the portfolio credit feature.
Model portfolios now have a unique code. This code is needed for importing and exporting model portfolios which is a feature to be implemented later on.
Account details and account interest details are now displayed more clearly in versions.
Bookkeeping view now supports limited visibility.
Bookkeeping account sets now have a Code field.
Fixes
APIs
GraphQL API for importing transactions and trade orders now properly returns Ext.id when creating or updating a transaction or trade order.
Fixed a small issue in deleting multiple documents simultaneously.
You can now query portfolios based on currency code.
You can now assign a task to a contact with a single call using GraphQL.
You can now use effective date parameters when using a query to fetch postings.
Compliance investment restrictions
Fixed an issue with profile values in limit analysis. The process now works when limit analysis is empty.
Corporate actions
Capital calls now calculate the remaining commitments correctly also when the Paid in capital effect for the transaction type is “Amount” and the price is not 1.
Data aggregation
The general importer global error status now displays correctly when you import multiple trade orders or transactions with one or more errors.
Fixed an issue that caused slowness in importing corporate actions. Importing corporate actions is now significantly faster.
Fixed an issue that caused importing a security price without an optional currency to produce a false error message despite the import being successful. A missing optional currency no longer causes an error message.
Importing a JSON string to portfolio key figures now works also when using standard import.
Portfolio management
Processes configured to run against positions in Overview and Positions view now get the correct portfolio IDs when a contact, group, or parent portfolio with subportfolios is selected.
Fixed an issue that prevented users from deleting ex-post costs without an audit trail. You can now search for ex-post costs missing audit trails using an upgrade script, correct the versions, and delete the ex-post cost.
Fixed an issue that caused the modify transaction functionality to not update posting dates in the other transaction if a user modified two transactions simultaneously.
Fixed an issue that caused a transaction to be removed fully from the search view when it was removed from the search results. Now transactions are visible in the search results again if you make a new search that matches the transaction.
Fixed an issue that caused duplicates in the portfolio asset managers table.
Fixed an issue that caused bond positions to display multiple decimals in Overview.
Extended information on accounts now shows unsettled balances correctly in situations when shared account is used and account is viewed on the contact level.
Other
Versions info now loads faster.
Fixed an issue that caused an error message when a user upgraded an environment without any transactions. You can now upgrade environments without error messages.
Updates to FA Back 3.22
FA Back 3.22.1 - Release notes
FA Back 3.22.1 is an update to FA Back 3.22. This update includes the following fixes:
Account interest is now correctly calculated on a settled balance.
Overview now correctly shows security totals when an account has accrued interest.
Setting portfolio credit to zero now updates the available credit correctly.
Adding or deleting a portfolio credit key figure now triggers portfolio recalculation to update the key figure values.
Fixed an issue where certain internal GraphQL queries within the FA Platform did not return data even for valid queries.
Fixed the order of the upgrade scripts that are used when upgrading to the newest version of FA Back.
FA Back 3.22.2 - Release notes
FA Back 3.22.2 is an update to FA Back 3.22. This update includes the following fixes:
Account accrued interest now shows the same value in the Overview as in report tables. Until now, a rounding error could occur depending on the calendar setting used.
Dirty and clean market values are now shown correctly also when the account has accrued interest.
Portfolio recalculation is now triggered also when you change a security market price that is a base instrument for a credit account.
Report calculator is no longer triggered when the market data connector returns invalid market data observations older than the date validation set in Preference.
Fixed an issue that prevented FA Monitoring resource use from showing any data in FA Back.
Fixed an issue that caused the Flowable process to fail with data imported from several forms.
Purchase value is now correctly calculated for a new security in exchanges. Until now, the costs were considered incorrectly.
Fixed an issue that caused an incorrect purchase value after an exchange where the security currency changed.
Fixed a rarely occurring issue that caused a portfolio to not be saved after updating portfolio credit key figures. The issue occurred when saving during or right after the report calculation microservice updated the portfolio reports.
Dynamic portfolio group filtering for “Portfolio profile attribute” now works. This issue appeared in FA 3.22.
FA Back 3.22.3 - Release notes
FA Back 3.22.3 is an update to FA Back 3.22. This update includes the following fixes:
Creating new benchmarks now works. This issue appeared in FA Back 3.22.
Updating the collateral ratio for a security now also updates the portfolio collateral value.
The “Grouping” column was renamed “groupingType” in the performance data table to prevent causing issues in the MySQL database.