☰
Navigation :

Release notes 6.0

info

For the list of issues covered in this release, and known issues, see the Changelog.
For information on upgrading from previous versions, see the Atoti FRTB Migration Notes.

6.0.3

2025-08-25

Summary

New features

Improvements

New features

Virtual hierarchies configuration

Virtual hierarchies can be set with the property frtb.configuration.virtual-hierarchies. You can change the virtual hierarchies from the yaml configuration file with the following configuration:

frtb:
  configuration:
    virtual-hierarchies:
      - Inclusion@Booking
      - Netting Set@Booking
      - Trades@Booking

By default, application.yaml sets the hierarchy Trades@Booking as virtual. See Virtual hierarchies for more information.

Curvature CVR Measure

A new Curvature CVR measure has been added to Atoti FRTB. This measure uses the underlying Curvature CVR Up or Curvature CVR Down measure depending on the “direction” of the Risk Position Scenario at the Bucket level. A new intermediate measure Curvature Bucket Scenario evaluates the Risk Position Scenario measure at the Book level.

This measure is disabled by default in Atoti FRTB 6.0.x versions. Please see the migration notes for details on how to enable it.

This measure has been added for the following risk classes within sa-sbm:

HKMA and MAS jurisdictions

Added initial support for HKMA and MAS jurisdictions.

Cryptoassets Group 2b

Support for Cryptoassets Group 2b has been added.

Foreign zero risk-weight public sector exposures

For DRC non-Sec, when a foreign regulator allows a public sector exposure to have a risk-weight of zero, OSFI allows the exposure to have a risk-weight of 0.5%. This is now supported in Atoti FRTB.

The implementation note for the zero risk-weight exposures has been updated to accommodate these non-zero risk-weights.

DirectQuery incremental refresh support

Added support to handle incremental refresh operations for DirectQuery data sources.

The incremental refresh operations can be pre-configured via templates or specified directly via table and field updates.

Data duplication in horizontal distribution

Setting the frtb.distribution.enable-data-duplication property to true, allows duplicate members in the distribution level of horizontally distributed data cubes. This is typically useful in a hybrid setup where all data is held in DirectQuery and only recent data in-memory.

With data duplication enabled, and by specifying node priorities, the in-memory data can be preferred. Older members can then be periodically unloaded from the in-memory cube and instead accessed from DirectQuery.

Improvements

Improved stability and performance of distributed what-if simulations

What-if simulations now run in a single-phase commit mechanism, creating the user-defined branch and editing data within that branch. This reduces the number of operations required for a single simulation. Stability and performance of the cluster is significantly increased at the expense of some consistency checks.

Improved load performance

Fixed a regression in the performance of data loading.

Initial load times have been improved by reducing the distinct queries run by the HistoricalDatesProvider. The HistoricalDatesProvider no longer runs distinct queries on base stores. Now, the database statistics are used to gather the unique set of dates from the stores. This reduces the time taken for datastore transactions to be committed.

If needed, the HistoricalDatesProvider can be configured to query the base stores by setting the frtb.historical-dates-provider.is-using-approximate-members property to false.

Expanded definition of zero risk-weights

The zero risk-weight can now be specified per obligor and jurisdiction, defaulting to 0%. See the implementation note for further details.

6.0.2

2025-06-26

Summary

New features

Improvements

New features

The depth of the hierarchies is now configurable.

Improvements

Atoti Server upgrade

Upgraded to the latest version of Atoti Server, 6.1.9.

Data Connectors and Common Library upgrade

Upgraded to the latest versions of Data Connectors and the Common Library.

6.0.1

2025-05-29

Summary

  • Upgraded Data Connectors : Upgraded to Data Connectors 5.0.4.

6.0.0

2025-04-25

Summary

  • Upgrade to Atoti Server 6.1.7 : Upgraded to the latest version of Atoti Server. Please see the migration notes for more information.
  • Upgrade to Atoti UI 5.2.x : Upgraded to the latest version of Atoti UI.
  • Upgrade to Data Connectors 5.0.1 : Upgraded to the new version of Data Connectors.
  • Moved Sample Data out of Starter : Moved sample data out of the frtb-starter module and split out the data directory into three properties.
  • frtb-application module: Replaced the frtb-starter module’s function with a new module that contains the configuration and builds a full Spring Boot application. This module is provided as a reference implementation and is intended to be used as a reference for clients to build their own applications.
  • Simplified OpenTelemetry Configuration: We now rely on OpenTelemetry’s GlobalOpenTelemetry to configure the export of logs and metrics.
  • FX Translation Risk: Allow FX translation risk to be calculated upstream for multiple different reporting currencies.
  • Inclusion hierarchy: Added “Inclusion” hierarchy to support filtering and what-ifs on trades. For example, Banking book or speculative trades.
  • Default Jurisdiction: The default jurisdiction can be changed from BCBS.
  • CRIF Files: Improvements to our support for CRIF files.
  • What-If Configuration: Simple what-if simulations that alter the datastore can now be created through configuration.
  • Support for DirectQuery Aggregate Tables: Added support for using Aggregate Tables to improve startup time & reduce DirectQuery database compute costs.
  • DoctorPivot Service Moved Into AdminUI: The DoctorPivot service is now integrated into the AdminUI and is no longer a standalone component.

ISDA version

This release is compliant with ISDA v.3.4.1.

frtb-application module

The new frtb-application Maven module has been split out of the frtb-starter Maven module.

The following components have been moved into the new module:

  • FRTBApplication class including the main() method.
  • Spring security configuration
  • OpenTelemetry configuration
  • Logging configuration
  • Content Service configuration
  • Configuration files

Alternative root parameter sets

The root parameter set can now be changed to something other than “BCBS”.

If your input files are generated for a parameter set other than BCBS (e.g. CRR3 or US-NPR), then you can set this parameter set as the root. The BCBS parameter set (and others) can then be specified as differences to your specified root parameter set.

Improvements to CRIF file support

  • Previously we used the label “Portfolio ID”, but loaded the contents into the trade ID. For backwards compatibility, we have changed the label to “Trade ID” in the default CRIF format we support.
  • We have added support for the “Portfolio ID” field, this is mapped to the “Book” field when loading.
  • The order and inclusion of fields in the CRIF files can be customized—for example, either “Trade ID”, “Portfolio ID”, or both may be included; and fields like “TrancheThickness” can optionally be omitted if not loading securitized products for DRC.
  • CRIF files can now be loaded even if the target stores have been customized.

Inclusion hierarchy

A new Inclusion hierarchy has been added to support filtering individual trades. Additionally, what-if simulations can be used to change this filtering.

In the common MDX context, the “default member” for this hierarchy is “Y”. So, by default all MDX queries will filter on Inclusion=Y. However, if you add the “Inclusion” hierarchy to your query, then you can explicitly control the filtering.

While the value of “Y” is a special value (defined for the default filtering), members of the “Inclusion” level can take any value.

To support this new hierarchy. An “Inclusion” field has been added to both the Trade_Attributes.csv file and to the Trade Mapping store. In both places, it takes the default value of “Y”, to be included with the default filtering.

The what-if simulation to change the value of this “Inclusion” field, uses a new what-if simulation configuration. It is configured using the following in the application.yaml file:

whatif.datastore:
  inclusion-change:
    name: "Inclusion Flag Change"
    base-store: "TradeMapping"
    filters:
      - name: "As-of Date"
        store-field: "AsOfDate"
        level: "AsOfDate@Date@Dates"
      - name: "Trade Id"
        store-field: "TradeKey"
        level: "TradeId@Trades@Booking"
    inputs:
      - store-field: "Inclusion"

What-if Simulation Configuration

Simple what-if simulations that change the value of a field in the datastore can now be defined by configuration. The configuration describes the changes to the datastore, and links some of the fields to the cube levels.

The configuration is used to create a REST Endpoint for executing the what-if simulation, and to create a context menu and UI widget to allow users to execute the simulation.

See Simple Datastore Changes for details.