Technical release notes Q1 / 2023
From Q1/2023 release onward, our release notes will include Technical release notes. The purpose of these release notes is to communicate the restructuring we do under the hood every quarter for the FA Platform. Application release notes mainly focus on new features and improvements visible to the user, while these technical release notes focus on the improvements that are not directly visible on the user interface. Topics covered in these release notes include for example performance, security, reliability, quality and new integrations.
At the same time, we renamed the old Technical release notes section to Developer release notes to better convey their audience. We will continue to provide separate release notes directed for developers who extend or customize the FA Platform, just under a new title.
Performance
Only pre-paid orders trigger report updates
Why?
We made unnecessary report calculations while updating trade orders.
Who is this for?
This improvement is for all FA Back users who use trade orders.
Details
We limited the triggering of report updates only to pre-paid orders (a trade order with a payment date) when saving a trade order from the trade order window.
Cosmetic updates to transactions no longer trigger unnecessary report calculations and posting rule runs
Why?
Before, when you made changes to transactions either by importing or by making changes in the UI the updates triggered report calculation and posting rules to be run which had an impact on performance. This is not needed in every case and is possibly heavy for the system.
Who is this for?
This improvement is for all users who make updates in existing transactions.
Details
Earlier we triggered report calculation and posting rule run always when any information in a transaction was changed, even if it only has been a small cosmetic change. This is unnecessary because all the fields don’t have an effect on the report calculation or posting rules.
FA will not trigger report calculation or posting rule run if you have updated fields that do not influence on report calculation or posting rules, this will have a positive impact on the performance. The fields that do not influence report calculation or posting rules are: Reference, Counter, Counter portfolio, Settlement place, Hidden, Description, Internal info or tags. Changes to any other fields (e.g. transaction date, amount, fee, fx rate…) still require posting rule run and report calculation.
Improved performance of Reconciliation - Bank Statement report
Why?
This performance improvement was made because in some environments, the Reconciliation - Bank statement report took a very long time to generate.
Who is this for?
This improvement is for anyone working with reconciliation.
Details
The report Reconciliation - Bank Statement is using our accounts API which, in turn, makes two queries (one for balance and one for transactions), and the former query was very inefficient. The balance query was optimised so that it now uses indexed conditions, which means that the report is significantly faster to generate.
Better reuse of cached portfolio data in FA Client Portal
Why?
This performance improvement was made because we noticed the FA Client Portal was fetching unnecessary order and transaction data.
Who is this for?
This improvement is for all users of FA Client Portal.
Details
We noticed the FA Client Portal was fetching portfolio data when getting orders and transactions, when it could instead re-use data from the cache.
We implemented a "cache-first" policy, meaning it will first check if the requested portfolio id is in the cache, and only fetch new data from FA Back via the APIs if the needed data is not in the cache.
This change slightly improves performance.
Additional flexibility and improved performance of GraphQL calls with limited visibility
Why?
Users with limited visibility and extended limited visibility cannot make certain kinds of GraphQL API calls for portfolios or contacts, even if the data they are trying to access is something they should be allowed to access.
Who is this for?
For everyone who uses GraphQL with limited visibility.
Details
To make it more flexible to request data with limited and extended limited visibility we are now checking the limited visibility checks to every move between portfolios and contacts. This means that when requesting e.g. a parent portfolio for a portfolio, we are only returning the portfolio if it passes the limited visibility check for the user, otherwise we don’t return anything.
The new way of checking limited visibility is a bit more efficient than before and will have a positive impact on the performance.
Improved performance monitoring of microservices
Why?
This improvement was made to enhance performance monitoring of the microservices within the FA Platform.
Who is this for?
This is for FA’s internal use and not accessible for the clients.
Details
Monitoring is done using the service application Datadog. Datadog is commonly used for observability of cloud applications through SaaS-based platforms. We have previously had this for larger applications such as FA Back, FA Front, Keycloak etc. and now also adding it to an array of microservices.
Other performance fixes
Improved performance when searching for securities with a lot of key figures.
Improved speed of some position calculation jobs through batch-saving.
Security
Why?
We’ve implemented a variety of security-related improvements in the FA Platform for the Q1/2023 release. Maintaining the security of the FA Platform is crucially important and requires continuous effort. Doing so has been an important part of our development process for a long time.
Details
The Q1/2023 security improvements include routine dependency scans and updates across many of our applications and services, including but not limited to FA Back, FA Front and FA Fund Management. Additionally, several security-related fixes and enhancements were made to specific features and APIs.
Reliability
Improved reliability of precalculating position data
Why?
We have encountered reliability issues with our background operations related to precalculating position data. Specifically, some of our customers have encountered situations where position updates occasionally fail due to problems with scheduling these calculations.
Who is this for?
This improvement aims to improve the reliability of position calculation for all FA customers.
Details
Our scheduling of position calculations relies on a messaging mechanism. To prevent problems originating from this messaging mechanism, we upgraded our Azure service bus library to the latest version (7.13.1).
Retry functionality in trade order messaging system
Why?
This feature was added after we noticed some trading messages would fail if there would be a temporary issue with the messaging system.
Who is this for?
This improvement is for clients using the trading connections in FA Platform.
Details
Added functionality for trading routes to attempt retries when connection to the message system is failing. There have been cases where our messaging system connection has failed resulting in failed trading messages. This means that even though our routes are running the trading messages cannot be sent further to trading and FA Back. However, these types of connection failures are usually temporary, and we have therefore added retry logic to prevent these types of message failures.
New integrations
Standard connections for DNB settlement and additional route for reconciliation
Why?
This feature was developed because we did not have any standard connection to DNB for settlement and reconciliation files.
Who is this for?
This feature is for those who have the need to send settlement files to DNB and to receive reconciliation material.
Details
Before, our routes to DNB only handled payments and DNB proprietary reconciliation format. Our standard routes are now also able to send settlement files (MT540-MT543), and to receive MT535 position reconciliation files.
Learn more: Set up DNB bank and custody connection in FA Admin guide.
Certification of Bloomberg EMSX drop copy
Why?
Clients have requested the ability to integrate and support drop copy functionality from Bloomberg in addition to the already existing order staging functionality. This will allow our users an additional approach in order handling via Bloomberg.
Who is this for?
This is for clients who use Bloomberg for trade order management and execution.
Details
Counterparties that provide FIX connectivity usually also provide something called “Drop copy” sessions. These sessions are specific one-way connections that provide a feed of trade order updates. Using a drop copy session enables the user to add orders directly in the external terminal and have the completed order imported directly into FA.
FA now supports drop copy sessions for equity security types utilising the FIX 4.2 format towards Bloomberg. The incoming feed either updates or creates new trade orders in FA depending on if there is an existing order or not. External ID is used to map to relevant portfolios in FA. The integration is now a standard feature in FA and new clients who wish to use the connection need to have an agreement with Bloomberg.
Counterparties such as Bloomberg require certifications of these types of connectivity which ensures production stability once the connections are established in production environments. FA’s EMSX drop copy integration is now completed and certified by Bloomberg.
Other highlights from services
Log in with MitID
Why?
FA used to support logging in via Danish NemID, but that was deprecated in 2022 and NemID was replaced with MitID. Starting from this version FA supports log in with MitID for Danish clients.
Who is this for?
This feature is for all Danish clients who would like to take MitID login into use.
Details
To make it easy for your clients to log in to FA we now provide the possibility to log in with MitID. When configured, the login screen will show a button for MitID login, allowing your clients to log in with that instead of FA login credentials.
For you to start providing the possibility to log in with MitID you need to agree with Signicat to use a MitID integration and to agree with Signicat to have a CPR matching feature so that it can be mapped in our system. At the same time, you need help from our consultants to set up the MitID login possibility on FA’s side.