Skip to main content
This page explains the changes required to migrate to the stated version of Atoti Market Risk.

Migrate to 6.0.9

Atoti Market Risk uses Atoti Server 6.1.24 and Atoti UI 5.2.x. For what those releases bring, see the Atoti UI documentation, the Atoti UI migration notes and the Atoti Server changelog.

What you must change

A deployment on the standard configuration, building the project as shipped, needs no change. Everything that does need one is listed here; the rest of this page is reference material for these rows. Changes below reach a project two different ways. Library-module changes arrive with the version bump and apply to every deployment. Changes inside mr-application do not, for a project that runs its own copy of it: those have to be ported deliberately, item by item, as Porting mr-application changes sets out. Rows below name the class whenever that distinction decides whether the row applies. Initial data load. This group applies only once the 6.0.9 InitialDataLoadConfig is running, that being where both the new initial-business-dates semantics and the S3 autodiscovery live. See Initial data load for the external behavior, and InitialDataLoadConfig in detail for what to port. Other configuration Code Build Hibernate is deliberately held at the 6.6.36.Final that 6.0.8 shipped, rather than taking Atoti Server’s 6.4.2.Final, so the content service persistence path is unchanged and needs no migration. See What moved.

Sign-Off and Adjustments Services dependency alignment

Both dependencies now track Atoti Server and have moved to a new Maven group. signoff-api.version and adjustments-services.version resolve to ${activepivot.version}, 6.1.24 in this release, where they were pinned at 4.2.1 and 4.1.3. The standard build needs no version change, and a project that overrides either property should drop the override. See Dependencies for what each release ships. Group IDs. The artifact IDs are unchanged, and the root pom.xml manages the versions, so a project importing that dependencyManagement needs no <version>; one that does not must add an explicit version. BranchAwareAdjustmentRequestDTO gains a parentBranch argument, inserted after user, so code that constructs the DTO directly does not compile until the argument is added. The signature is now BranchAwareAdjustmentRequestDTO(String key, String user, String parentBranch, Set<NamedValueDTO> filters, Set<NamedValueDTO> input, String toBranch):
Passing null leaves parentBranch unset, the same state as a request deserialized without the field, and the Atoti Market Risk integration tests do exactly that. The field is inert in this release: the what-if submission path reads only key, user and toBranch, and source-data reads stay on the master branch.

Snowflake key-pair authentication

Snowflake is deprecating single-factor password authentication, so the shipped snowflake profile (application-snowflake.yaml) now authenticates with a key pair. Deployments running that profile must migrate before upgrading. directquery.database.snowflake.password, backed by SNOWFLAKE_PASSWORD, is replaced by directquery.database.snowflake.additional-options.private-key-base64, backed by the new SNOWFLAKE_PRIVATE_KEY_BASE64. Only these keys change; the rest of the snowflake block is unaffected.
SNOWFLAKE_PRIVATE_KEY_BASE64 must be set in the runtime environment before startup: Spring cannot resolve the placeholder otherwise, and the application fails to start. The password property still binds if set, so a deployment staying on password authentication temporarily must keep password: ${SNOWFLAKE_PASSWORD} and not add the private-key-base64 key.
Migration. You need a role that can alter the Snowflake user (SECURITYADMIN, for example) and write access to the environment of the Atoti Market Risk process. Step 1 generates the pair, writing rsa_key.p8 (private) and rsa_key.pub (public) to the current directory:
Step 2 registers the public key:
Step 3 encodes the private key and puts it in the process environment:
The private key grants full access to the Snowflake user. Never commit rsa_key.p8 or its base64 encoding to source control. A shell export lasts only as long as that shell: the value has to reach the process environment the way the deployment supplies its other secrets, a container secret or an orchestrator-injected variable, or startup fails on the unresolved placeholder.
Remove the now-unused SNOWFLAKE_PASSWORD once the connection works. For the full walkthrough, including the encrypted PKCS#8 variant with private-key-pwd, verification and key rotation, see Snowflake key-pair authentication.

Deprecated properties

OpenTelemetry export

Two export methods coexist, both gated behind mr.enable.tracing.open-telemetry (default false):
  • Modern OTLP, the default. Traces, metrics and log records go over OTLP, configured with otel.exporter.otlp.*, and service.name is market-risk-accelerator. otel.exporter.otlp.protocol selects the transport: http/protobuf (default, endpoint http://localhost:4318) or grpc (http://localhost:4317). otel.exporter.otlp.headers and otel.exporter.otlp.compression apply to both.
  • Legacy Zipkin plus stdout, opt-in. mr.open-telemetry.legacy-mode: true exports spans to Zipkin (mr.open-telemetry.zipkin-span-exporter-url, default http://localhost:9411/api/v2/spans), writes metrics to stdout through LoggingMetricExporter and log records through console logging, and resolves service.name to Atoti Server when otel.service.name is unset.
Legacy mode takes precedence over the modern configuration: with legacy-mode: true, every otel.exporter.otlp.* property is ignored and nothing reaches an OTLP collector even if one is running. An overridden endpoint must also match the chosen protocol: an HTTP endpoint does not accept gRPC traffic, or the reverse, and a mismatch produces repeated export-failure warnings with no data arriving. Ports 4317 and 4318 are conventions only, so confirm the receiver’s protocol rather than trusting the port.
mr.open-telemetry.zipkin-span-exporter-url is deprecated and scheduled for removal in 7.0. In legacy mode it is the only span destination; in the modern method, setting it adds a Zipkin exporter alongside OTLP and logs a deprecation warning at startup. Most backends (Jaeger >= 1.35, Grafana Tempo, Honeycomb, Datadog) accept OTLP natively; in front of a Zipkin backend, put an OpenTelemetry Collector and use its zipkin exporter. TLS and mTLS. The OTLP HTTP exporter uses the JVM’s default SSLContext and trust store; the OTel auto-configure properties (otel.exporter.otlp.certificate, otel.exporter.otlp.client.key and similar) are not read by the accelerator’s manual exporter wiring. For an HTTPS endpoint behind an internal CA or a self-signed certificate, import the CA into the JVM trust store or point at your own with -Djavax.net.ssl.trustStore and -Djavax.net.ssl.trustStorePassword; for mTLS add -Djavax.net.ssl.keyStore and -Djavax.net.ssl.keyStorePassword. Property-based TLS support is tracked as a follow-up. Also worth knowing. The Micrometer OTLP metrics registry (management.otlp.metrics.export, HTTP only, disabled by default) is a separate pipeline, unaffected by otel.exporter.otlp.protocol. Log records go through BatchLogRecordProcessor (about a second’s delay, up to 512 records per batch), so records from the final second before a JVM crash can be lost. For synchronous export, set mr.enable.tracing.open-telemetry: false and wire an SdkLoggerProvider bean using SimpleLogRecordProcessor.

OpenTelemetry: SDK registered as global instance

The accelerator registers its OpenTelemetrySdk as the process-wide GlobalOpenTelemetry. A Java agent that has already claimed the global (AWS OTel, Datadog, New Relic, Dynatrace, or any other) takes precedence: the accelerator logs a warning, closes its own unused providers and reuses the existing instance. This also applies in legacy mode, where spans are then routed by the agent rather than exported to Zipkin. No action is required.

Service-driven DirectQuery cache routing

IMarketShiftDirectQueryCachingPostProcessorEx is a new sub-interface of IMarketShiftDirectQueryCachingPostProcessor, implemented by the standard shift post-processors (AShiftVectorPostProcessor, FXMarketShiftPostProcessor, APnlVectorFromRiskSensiPostProcessor). The MarketShift DirectQuery cache secondary index is added automatically. For the full API, see the Cache routing page. Single-store 6.0.7 and 6.0.8 wiring keeps working unchanged. The default resolveShiftCacheNames returns the empty set, and legacyFallbackIfEmpty substitutes the one registered store name. Multi-store wiring. Declare several CacheConfiguration beans. Spring autowires them into the new marketShiftCacheConfigurations injection point, and one shift evaluation prefetches every relevant cache. The legacy single-bean point (marketShiftCacheConfiguration) still works, wrapping its bean in a singleton list.
With two or more CacheConfiguration beans, RiskPostProcessorInjector skips the legacy single-bean injection entirely, rather than injecting one declaration-order-dependent bean. A post-processor implementing only the legacy interface then receives no cache configuration and silently prefetches nothing; a startup WARN names it. With exactly one bean the fallback goes the other way and overrides a differing service result, with a one-time WARN. For genuine service-driven routing, declare the routed stores as beans instead of relying on it.
Service-driven dispatch. When the store depends on the query coordinates (one store per sensitivity kind, or per risk class), override IMarketDataRetrievalService.resolveShiftCacheNames (common-accelerator-library GENACL-1449):
MarketShiftCacheNameResolverUtils.routeViaMarketDataService runs at prefetch time, expanding the location over riskClassLevel × sensitivityNameLevel (cube-filter-aware through PostProcessorUtils.grantedMembersCondition) up to the per-post-processor LEAF_EXPANSION_LIMIT (a measure-builder parameters[] key, default 16, not a Spring property). Each surviving point fires one resolveShiftCacheNames(...) call and the union of the names is prefetched. FX shifts follow the same path through IFxShift.resolveShiftCacheNames, whose default FXShift implementation delegates to the service, so overriding the service alone is enough. For a worked example, see the end-to-end example.

Breaking changes for forks of the shift post-processors

  1. RiskPostProcessorInjector constructor. The marketShiftCacheConfiguration parameter is now a List<IMarketShiftDirectQueryCachingPostProcessor.CacheConfiguration>. Update any super(...) call or direct construction. This change is only needed if the class is taken from mr-application, which is source a project copies rather than a library it depends on: a project that has not ported the 6.0.9 version keeps the old constructor and needs no change here. See Porting mr-application changes.
  2. marketShiftCacheConfiguration field removed from the three standard post-processors, replaced by marketShiftCacheConfigurationMap (Map<String, ILocationToCachePartitionConverter>). The getMarketShiftCacheConfiguration() accessor is preserved and returns the first entry, so code going through it is unaffected.
  3. Default converter is now ExpandingLocationConverter, not BestEffortLocationToCachePartitionConverter. Above the partition levels (wildcard asOfDate or scenarioSet) it expands the wildcards, cube-filter-aware, where the old converter prefetched nothing: a functional superset, at a higher prefetch volume.
  4. databaseCacheManager is @ConditionalOnDirectQueryCacheEnabled (the cache preview defaults to off), so the bean may not exist. RiskPostProcessorInjector treats it as @Nullable; a required @Autowired IDatabaseCacheManager elsewhere fails context startup when the preview is off.
Items 2 to 4 are in library modules (mr-common-lib and mr-sensi-lib for the post-processors, mr-sensi-config for the stock marketShiftCacheConfiguration bean, mr-directquery for databaseCacheManager), so they arrive with the dependency upgrade regardless of how you consume mr-application. Only item 1 depends on that. Post-processors implementing the Ex interface install MRDatabaseCachePrefetcher instead of the Atoti-core DatabaseCachePrefetcher. The two are functionally equivalent for a single registered cache: same prefetchCacheAsync(...) shape, same partition derivation. IPrefetcher.getName() returns the new class name, so logs, Grafana panels and APM queries filtering on DatabaseCachePrefetcher go blank for shift post-processors until they accept MRDatabaseCachePrefetcher too. The three standard post-processors are in library modules, so this reaches every deployment, single-store ones included.

Initial data load

Both changes are on com.activeviam.mr.application.sources.InitialDataLoadConfig. They are only needed if the class is taken from mr-application, which is source a project copies rather than a library it depends on: a project that has not ported the 6.0.9 version keeps the 6.0.8 behavior, whatever mr.data-load.initial-business-dates is set to. See InitialDataLoadConfig in detail for what has to be ported. Signatures. The constructor takes a MeterRegistry, and allAvailableDates takes two more parameters, used to discover dates from AWS S3:
Inject the MeterRegistry via Spring, or pass new SimpleMeterRegistry() in tests. allAvailableDates is a @Bean method, so Spring autowires the two new parameters; both are @Nullable, so a non-AWS deployment declares nothing extra. Date autodiscovery. The meaning of an explicit empty list changed for all sources; leaving the property unset changed for AWS only: An empty list is now how the initial load is suppressed. A deployment that used it to mean “discover everything” must remove the property instead. AWS discovery lists the prefixes matching the dlc.csv.aws.sources prefix up to #{AsOfDate}; set the property to keep control of what loads.

Limits dependency alignment

Atoti Limits is an optional solution, licensed separately. Its client library limits-auto-config-61 only reaches the classpath under the limits Maven profile, so pass -P limits when building or running. Deployments without Atoti Limits can skip this section. 6.0.9 moves the client library from 4.0.1 to 6.1.24 and its groupId from com.activeviam.solutions.limits to com.activeviam.modules.limits. The version jump is a renumbering, not years of change: Atoti Limits now shares the Atoti Java SDK’s version line, so 6.1.24 directly succeeds 4.2.2, and limits.version resolves to ${activepivot.version} rather than a fixed value.
This concerns the client library only. The Atoti Limits server stays on the 4.x stream, and the 6.1.24 client library is compatible with a 4.2.x server. There is no 6.1.24 Limits server to deploy.
Atoti Sign-Off and Adjustments move group in this release too, to com.activeviam.modules.signoff-api and com.activeviam.modules; see Sign-Off and Adjustments Services. Renaming the group alone is not enough for any of the three: the old groups publish only 4.x, so each move has to be paired with a 6.1.24 or later version.

Maven dependency

The standard project ships the new coordinates and needs no action. A deployment that declares or overrides Atoti Limits itself must change the groupId and the version together: com.activeviam.modules.limits publishes only 6.x and the old group only 4.x, so a 4.x version on the new group resolves to an artifact that does not exist.
limits.version remains available to pin the client library independently of Atoti Server, and any value must be 6.1.24 or later. The declaration in the limits profile of mr-application/pom.xml carries no version, so only its groupId changes.
On Atoti Server 6.2, switch to limits-auto-config-62. limits-auto-config-61 is also published at 6.2.0, so a 6.2.x activepivot.version resolves without error but silently loads the auto-configurer targeted at Atoti Server 6.1.

Application properties

6.1.24 authenticates with JWT and rejects the basic-auth properties 4.0.1 accepted: remove limits.autoconfiguration.authentication, .limits-authentication and .content-server.authentication. Add service-principal, the username Atoti Market Risk authenticates with. Atoti Limits also pushes limit changes back to Atoti Market Risk to refresh its lookup cache in real time, a mechanism absent from 4.0.1. On a single host, limits-auto-config-61 auto-detects the callback URL from server.port and server.servlet.context-path. In containerized or load-balanced deployments where that URL is unreachable from the Limits server, set atoti-base-url; without it the connection still succeeds, but limit evaluation results only appear on the next polling cycle.
service-principal and atoti-base-url are the only additions; enabled, limits-base-url and as-of-date keep their 6.0.8 meaning. Point limits-base-url at wherever the Limits server actually runs.

Atoti Server upgrade to 6.1.24

From Atoti Server 6.1.20, the distributed query engine builds its location translator once per application ID rather than per cube. Atoti distribution already required every data cube sharing an application to have the same topology (the same hierarchies, levels and measures), and the engine now relies on that directly, so the hierarchy ordering must match too. The base and summary cubes of each domain share one application ID by default (VaR, Sensi, PnL), so the Risk-dimension hierarchy ordering of the VaR-ES and Sensitivity summary cubes has been aligned with their base cubes. The standard configuration needs no action; if you customize cube dimensions, keep base and summary orderings consistent.

Dependency management aligned with Atoti Server

The root POM now declares the activepivot-server-spring BOM ahead of common-dependencies-bom, so Atoti Server’s pins win where both manage an artifact, and upgrades Common Dependencies BOM and Common Parent POM to 2.6.0 (Spring Boot baseline 3.5.8 to 3.5.16). Under the previous order Atoti Server’s pins were overridden, so the application ran older artifacts, including unpatched ones, than the server was tested against. The build changes this may need are in What you must change.

What moved

Up. Spring Boot 3.5.16, Spring Framework 6.2.19, Spring Security 6.5.11, Jackson 2.21.4, logback 1.5.21 to 1.5.34, commons-collections4 4.6.0, OpenTelemetry 1.49.0 to 1.55.0, and lombok 1.18.42 to 1.18.46, pinned here because the version also drives the lombok-maven-plugin delombok step. From Atoti Server’s security pins: embedded Tomcat 10.1.57, netty 4.1.137.Final, Apache HttpClient 5 5.6.2 and HttpCore 5 5.4.3, mssql-jdbc 13.2.1.jre11, thymeleaf 3.1.5.RELEASE, bcprov-jdk18on 1.85 and libthrift 0.24.0. All six Tomcat artifacts now ship on one patch release, 10.1.57. In 6.0.8 the tomcat.version property and its single dependencyManagement entry held tomcat-embed-core at 10.1.52, while tomcat-embed-el, tomcat-embed-websocket, tomcat-annotations-api, tomcat-jdbc and tomcat-juli came from spring-boot-dependencies at 10.1.49. Both are gone: the family follows Atoti Server, and mr-application drops its now-redundant tomcat-embed-core exclusion and explicit version. For the CVE identifiers, see the Security heading of each release in the Atoti Server 6.1 changelog. Atoti Market Risk 6.0.8 ran Atoti Server 6.1.19, so the fixes span the 6.1.20 to 6.1.24 entries: 17 for embedded Tomcat alone, three of them critical. The Tomcat fixes are itemized in the Apache Tomcat 10 security advisories. Jackson is the largest of those jumps, two minor versions from 2.19.4 to 2.21.4. It stays within the 2.x line, where Jackson keeps its public API and wire format stable, so no behavioral change is expected: databind defaults, annotations and serialized output are unchanged. It is the version Spring Boot 3.5.16 selects, so Spring’s own converters are tested against it. Down. Two artifacts on the classpath resolve lower than in 6.0.8, both because Atoti Server declares an older version than the accelerator BOM: commons-io 2.21.0 to 2.20.0 and velocity-engine-core 2.4.1 to 2.4. DB2 jcc moves 12.1.3.0 to 11.5.9.0 for a bug similar to mssql-jdbc#2042, but it is managed only and never reaches the classpath. Nothing else decreases. Held back deliberately. Four families do not take Atoti Server’s version:
  • H2 stays at 2.3.232, the version 6.0.8 shipped and the one Spring Boot 3.5.16 selects. H2 changed its database file format in 2.2.220, so Atoti Server’s 2.1.214 cannot read a file written by 2.3.232 (Unsupported database file version or invalid file header), which is what the shipped content service database and any 6.0.8 deployment’s is. CVE-2022-45868, accepted in PIVOT-8021 because the server uses H2 in test scope only, affects just the command-line H2 console, which this project never starts. To take 2.1.214 anyway, set h2.version and migrate the file with SCRIPT/RUNSCRIPT.
  • Hibernate stays at 6.6.36.Final, the version 6.0.8 shipped. hibernate-core reaches the classpath at compile scope through content-server-storage, on the content service persistence path, and Atoti Server’s 6.4.2.Final comes from PIVOT-9994: 6.4.3.Final failed its CI, and the ticket is in triage proposing the pin be dropped. No CVE is involved. Holding it also keeps ByteBuddy coherent, since 6.4.2.Final declares 1.14.7 against the baseline’s 1.17.8, and keeps hibernate-commons-annotations 7.0.3.Final and jandex 3.2.0 rather than 6.0.6.Final and 3.1.2. To take 6.4.2.Final anyway, set hibernate-orm.version. Only hibernate-core is pinned here, so any other org.hibernate.orm module added to a project (hibernate-envers, for instance) must be declared at ${hibernate-orm.version} too, otherwise it resolves at Atoti Server’s 6.4.2.Final and Hibernate supports its modules only as a matched set.
  • io.zipkin.reporter2 stays on the version Spring Boot selects, through a zipkin-reporter-bom 3.5.3 import ahead of the server BOM. Atoti Server pins 3.4.2, below the 3.5.1 that opentelemetry-exporter-zipkin 1.55.0 is compiled against. The family BOM is imported rather than the artifacts listed individually, so zipkin-sender-pulsar-client (absent from Atoti Server’s 3.4.2 BOM, and therefore resolved from Spring Boot) stays on the same version as the rest. Only the Zipkin export paths use these artifacts (mr.open-telemetry.legacy-mode=true and the deprecated mr.open-telemetry.zipkin-span-exporter-url), not the default OTLP one. To take 3.4.2, set zipkin-reporter.version.
  • OkHttp resolves at 5.2.1 throughout. opentelemetry-exporter-sender-okhttp 1.55.0, behind the default OTLP export, needs OkHttp 5 (com.squareup.okhttp3:okhttp-jvm), while zipkin-sender-okhttp3 still needs OkHttp 4 (com.squareup.okhttp3:okhttp): the same okhttp3.* packages under two artifact ids, so both would land on the classpath and whichever exporter lost the class-loading order would run against bytecode it was not compiled for. mr-application therefore excludes com.squareup.okhttp3:okhttp from opentelemetry-exporter-zipkin, and both export paths are exercised against 5.2.1.
Also in this release. Common Parent POM moves from 2.5.0 to 2.6.0. It manages no dependency version, but moves 17 build plugin versions forward (Surefire 3.5.6, Compiler 3.15.0, JAR 3.5.1, JaCoCo 0.8.15) and carries spring-boot.version 3.5.16, so the repackaged fat jar embeds a spring-boot-loader matching its Spring Boot libraries where 2.5.0’s 3.5.8 loader did not. In logback-spring-file.xml, the MAIN appender moves to ..._main-plain_...log.zip to clear its collision with JSON; no logger references MAIN, so no log file the application writes changes name.

Properties changed

mr-common-config module: Impact on existing deployments. Deployments that do not override mr.cubes.levels.day-to-day-members gain the Previous member in the DayToDay hierarchy of every cube built on the date dimension (Sensitivity, VaR-ES, PnL, and their summary cubes). No existing value changes: DayToDay is a slicer hierarchy, so it does not aggregate across its members, and because Previous=CUB+1 is appended last the default member of the hierarchy remains Yesterday=DAY-1. Queries that enumerate DayToDay members (for example [Dates].[DateDtD].Members) now return one additional member, so saved dashboards built on all members show an extra row or column, and any baseline test that pins the member list needs updating. Previous resolves to the preceding date actually present in the cube, and returns an empty result rather than an error when no earlier date exists. To keep the earlier member list, override the property with the old default value. Next=CUB-1 remains opt-in.

CSV topic override filePattern fallback

MRNamedDescriptionUtil.merge() used to set filePattern to null when a YAML topic override (dlc.csv.topics) did not specify one; it now falls back to the base description’s filePattern. An override that omitted filePattern in order to match nothing therefore now matches the code-defined pattern: set the pattern explicitly on any such topic.

DirectQuery vector layout properties

Four new Spring properties select the vector layout of a store’s external table. Set only the stores whose schema uses a layout other than the resolved default. They are the declarative equivalent of the manual migrator.vectorsTableBehaviour(...) call described in DirectQuery vector emulation options, in the 6.0.8 notes. Each is resolved with VectorType.valueOf() after upper-casing, so any constant of com.activeviam.accelerator.common.directquery.migration.schema.VectorType is accepted, case-insensitively. Leaving a property unset is the same as setting DEFAULT. Both resolve at runtime from the target database: NATIVE where the database stores vectors natively, ROW otherwise. An unrecognized value fails startup with an IllegalArgumentException naming the offending property and listing the accepted values, rather than silently falling back to the default.
These properties are applied only where DirectQueryActivePivotConfig builds the Migrator itself. An application that supplies its own Migrator bean overrides that step, and all four are then ignored with no warning and no startup failure.

VaR scenario resolution failure handling

VaR scenario-based adjustments (VAR_ADD_ON, VAR_OVERRIDE, VAR_SCALING) are fixed in this release (MR-2456). The fix is in AdjustmentExecutionHelper and AdjustmentExecutionConfig, both in mr-application, so a project running its own copy of that module gets it only by porting the 6.0.9 code. See Porting mr-application changes. No API or configuration change is required, but the corrected behavior is visible to monitoring and automation:
  • Resolution no longer depends on the order the Scenarios store returns rows. Rows out of Index order, common with several partitions or REST-loaded data, previously threw a silently swallowed IndexOutOfBoundsException, leaving the execution intermittently stuck at PENDING and caching the partial result for the as-of-date.
  • Scenarios that cannot be resolved (a query failure, or no rows for the as-of-date and scenario set) now log under [ADJUSTMENTS][EXECUTION] and report FAILED, instead of proceeding into a downstream NullPointerException. In a bulk execution only the scenario group that failed is marked FAILED; the others still execute.
  • A scenario set whose Index values are not exactly 0..n-1 (a duplicate, a gap or a null) is excluded from resolution and reported FAILED, rather than silently resolving to a scenario list mis-aligned with the PnL vector it is applied to. A set that appeared to work on that corrupt behavior now fails, with an error naming it and its Index values.
Executions previously stuck at PENDING for these reasons now finish as EXECUTED or FAILED.

Adjustment execution failure handling

Defects in AdjustmentExecutionConfig and BulkAdjustmentExecutionConfig are fixed in this release (MR-2455). Both classes are in mr-application, so a project running its own copy of that module gets the fix only by porting the 6.0.9 code. See Porting mr-application changes. No API or configuration change is required: only the reported execution status changes, and it is now accurate, which affects monitoring that relied on the previous behavior:
  • Scalar adjustments (*_ADD_ON, *_OVERRIDE, *_SCALING) that threw while generating a value or writing to a store stayed at PENDING indefinitely, with nothing logged and the transaction left open. They now log under [ADJUSTMENTS][EXECUTION], roll back the failing store’s write and report FAILED.
  • Cube-level adjustments (*_CUBE_LEVEL) that failed reported EXECUTED, because FAILED was immediately overwritten, for every execution in a bulk batch, including one skipped because its fields could not be resolved. Only executions that contributed rows to the committed transaction now report EXECUTED.
  • Roll-overs (*_ROLL_OVER) had the same unguarded body as the scalar executors, so a failure in date parsing, trade selection or tuple generation left the execution at PENDING. They now log and report FAILED, failing the batch for bulk roll-overs. A bulk roll-over that resolved no books for its desk, or no trades for its book, previously failed only that one execution and left the rest of the batch at PENDING; the whole batch is now failed, as it already was on the method’s other abort paths.
  • All executors now report FAILED for an Error as well as an Exception, and still rethrow the Error afterwards, so a JVM-level failure is not swallowed. If setting the terminal status itself fails (an unavailable status service, say), the original failure still reaches the caller with the status-update failure attached as a suppressed exception, where it used to be replaced by it.
  • The scalar executor’s dedicated Failed to run query: log line is folded into its outer failure handler. The stack trace is still logged under [ADJUSTMENTS][EXECUTION], but alerting keyed on that exact string needs updating. The bulk executor still emits it.

Admin UI measure lineage tab

The doctorPivotApi block has been removed from static/atoti-admin-ui/env.js, and the DiagnosticsRedirectController serving the legacy /tree/cubes and /tree/measures endpoints it relied on has been deleted. The measure lineage tab now uses the Atoti Data Lineage APIs embedded in Atoti Server. If you serve your own copy of env.js, remove its doctorPivotApi block; the endpoints it points to no longer exist. The unused dr-pivot.version POM property has also been removed.

Porting mr-application changes into your own application module

The library modules (mr-common-lib, mr-sensi-lib, mr-var-lib, mr-pnl-lib and their -config counterparts) reach a project as Maven artifacts, so the version bump picks their changes up automatically. mr-application is the runnable entry point, which most projects copy into a module of their own rather than depend on, so nothing that changes inside it arrives that way.
Upgrading the Accelerator version applies none of the changes below. In an application module built from a copy of mr-application, each has to be copied or re-applied by hand. Anything not taken is simply absent from the build, in most cases with no error at startup to signal it.
What follows is what 6.0.9 changed in mr-application, and it is a decision per item rather than an all-or-nothing upgrade: most rows are feature-scoped, so skip any whose feature is unused. Three are not optional on any upgrade, being compile-level or behavioral changes to code already present: the InitialDataLoadConfig constructor now requires a MeterRegistry (below), RiskPostProcessorInjector takes its cache configuration as a List (Service-driven DirectQuery cache routing), and the Limits groupId changes for a build using Limits (Limits dependency alignment).
Diffing the module against mr-application at the 6.0.8 and 6.0.9 tags is the most reliable approach. The tables below say what to look for and which parts are optional.

POM

The new maven-dependency-plugin unpack-shared-metadata execution only extracts Spring metadata for the Accelerator’s own documentation build. Do not port it.

Spring factories

Add mr-application/src/main/resources/META-INF/spring.factories, a new file in 6.0.9:
If your module already has a spring.factories, merge these entries into the existing EnvironmentPostProcessor key rather than replacing the file. Register only the processors whose feature you use.

New classes to copy

Modified classes

Re-apply these if you have diverged from them, or re-copy them if you have not: main/DiagnosticsRedirectController was deleted. Remove it from your module; the legacy /tree/cubes and /tree/measures redirects no longer exist.

InitialDataLoadConfig in detail

The externally visible parts of these changes, the allAvailableDates signature and the date autodiscovery behavior, are covered in Initial data load.

Resources

Do not copy application-paas.yaml, application-datanode-paas.yaml, application-querynode-paas.yaml or application-directquery-paas.yaml. The paas profile configures ActiveViam’s own hosted test environment and is not intended for customer deployments. A module that already holds copies of these files needs no cleanup: they are inert unless paas appears in SPRING_PROFILES_ACTIVE.
The Grafana dashboards and the local LGTM stack under docker/observability/ sit at the repository root rather than inside mr-application. They are development tooling and are not required to run the application.

Migrate to 6.0.8

Atoti Market Risk uses Atoti Server 6.1.19 and Atoti UI 5.2.x. For new features and fixes included in these releases, please see the Atoti UI documentation and Atoti UI Migration Notes, and the release notes for Atoti Server.

Migration Helper REST endpoint

The new MRMigrationHelperRestController is automatically registered when running in in-memory mode via InMemoryDatastoreExtractionMigratorConfig (com.activeviam.mr.migration.config), which is imported by the default MarketRiskConfig. If you maintain your own copy of MarketRiskConfig, add InMemoryDatastoreExtractionMigratorConfig.class to your @Import list to pick up the new controller.
The migration helper requires in-memory data cubes: it reads rows directly from the in-memory IDatastore to produce the CSV exports and the DDL. It therefore does not apply to DirectQuery deployments (starter.deployment.type=direct-query) or to query-only nodes (starter.deployment.type=query-node); the controller is skipped on both. See the Migration helper page in the DirectQuery section for the intended workflow (extract an in-memory dataset, then start the application in DirectQuery mode).
CSV file exports (POST /extract and POST /extractForDatabase/{database}) are restricted to a configurable base directory via mr.migration.export.base-dir (defaults to the JVM temp directory). To allow exports to a custom path, set this property:
To disable the endpoint entirely (for example, in production deployments where the extraction helper is not needed), set mr.migration.export.enabled to false (defaults to true):
If your project implements a custom ISideStoresToMigrate bean or sets the storesToMigrate field on DirectQueryActivePivotConfig, note that both are now deprecated. The migration helper controller manages store selection through its getDefaultExtractionBuilder() method. You can continue using the deprecated APIs, but they will be removed in a future release.

Deprecated APIs

REST clients: Content-Type: application/json is now required

The POST /migrationHelper/extract and POST /migrationHelper/extractForDatabase/{database} endpoints now declare consumes = application/json and produces = text/plain;charset=UTF-8 (inherited from the underlying common library REST controller). REST clients that previously omitted the Content-Type header on these calls will receive an HTTP 415 Unsupported Media Type response. Update your scripts to send Content-Type: application/json alongside the JSON body.

DirectQuery vector emulation options

Two new vector emulation modes are available to complement the existing ROW mode used by the 6.0.3 Databricks row-based vectors example:
  • VectorType.ROW_SAME_TABLE: vector fields stay inline in the original table with an index column added, which duplicates the scalar fields across the resulting rows. Best for stores that contain only key fields and vector fields, where there is little to duplicate.
  • VectorType.COLUMN: each vector field is expanded into a fixed number of scalar columns in the same table.
Configure them per-store on the Migrator bean exactly like the existing ROW mode:
Alternatively, opt every key-only-plus-vector table into ROW_SAME_TABLE in one call:
The same modes can be selected at runtime through the migration helper REST endpoint by passing vectorStoreBehaviours, columnVectorSizes, or autoRowSameTable in the JSON body of POST /migrationHelper/extract. Explicit per-table overrides always take precedence over autoRowSameTable. For COLUMN mode, schema discovery picks up the columns that actually exist in the live database and adjusts the in-memory schema accordingly, so existing DirectQuery tables continue to work without any size configuration. The size only matters when discovery is not performed, primarily when generating DDL via GET /migrationHelper/sqlSchema or when bootstrapping a fresh database. The DDL emitter uses a fixed <fieldName>_0, <fieldName>_1, … layout; discovery does not require that exact shape. The global default (250) used during DDL generation can be raised via the Spring property:
For per-field control during DDL generation, pass columnVectorSizes in the extraction DTO:

Atoti Server upgrade to 6.1.19

Atoti Market Risk 6.0.8 upgrades to Atoti Server 6.1.19 (from 6.1.17). PIVOT-12863 patch files removed. The patch files for PIVOT-12863 (CompositeVersionAccessor and SqlVersionAccessorWithCache) that were introduced in 6.0.5 have been removed, as the fix is now included in core. If your project overrides or references these classes, remove those overrides. QueryCubeSync test utility relocated. The QueryCubeSync test utility class has been relocated from com.activeviam.activepivot.dist.test.internal.cube to com.activeviam.activepivot.dist.querynode.test.internal.cube. If your test code imports this class, update the import accordingly. Distributed messaging API rework. Atoti Server 6.1.19 also reworks the distributed messaging API. The legacy broadcast-message types (ABroadcastMessageV2, IMessageAnswer, IMessageHandler, IMessageHandlerRegistrar, SyncMessageHandler, IBroadcastResult) have been replaced with the new Request / Answer / ProcessedOutput records and the CommunicationRegistration builder.
Atoti Market Risk does not reference any of the distributed messaging classes affected by this change. No code change is required in projects that build on top of the standard Atoti Market Risk configuration. The sections below describe the underlying changes for projects that extend the distributed messaging or Snowflake integration directly.
Removed helper types. The following helper types are no longer available because their Atoti Server base classes were removed in 6.1.19: If a Registry.RegistryContributions setup listed SharedMessageHandlerRegistrar or ServicesMessageHandlerRegistrar, simply drop those entries. Message types are now records. DistributedParametersMessage and EndPointFinderMessage are now record types implementing com.activeviam.activepivot.dist.impl.avinternal.communication.Request. DistributedParametersData and EndPointFinderMessage.EndPointFinderMessageAnswer now implement Answer (the latter also ProcessedOutput). Replace getter calls with record accessors (message.getBranch()message.branch(), etc.). DistributedParametersRetriever constructor change. The retriever now registers its own message handler at construction time via CommunicationRegistration, so it needs the IActivePivotManager:
Snowflake JDBC driver package moves. The Snowflake JDBC driver bundled with Atoti Server 6.1.19 relocates several public classes. If you reference them in Java imports, update them: If you have custom JGroups protocol XML files and are upgrading from 6.0.5 (or earlier), also apply the auth_class change described in SharedSecretAuthToken replaces AtotiAuthToken in the 6.0.6 → 6.0.7 section.

POM file changes

The upgrade bumps the activepivot.version and common-lib.version properties in the root pom.xml; see the Dependencies page for the resolved versions per release. A new com.activeviam.apps:services library dependency is also introduced. It contains REST endpoint services (such as EndPointFinderService and LevelPathService) that were previously bundled inside com.activeviam.apps:shared and the Atoti Server core. Managed entry to add in the root pom.xml <dependencyManagement> block:
Direct dependency to add in mr-application/pom.xml:
If your project repackages mr-application or maintains a pom.xml derived from Atoti Market Risk, add the services dependency (no <version> needed if you import the Atoti Market Risk BOM or copy the managed entry above).

FX shift factor moved to IFxShift service

The FX shift factor (mr.fx.shift-factor) was previously applied within the measure chain, which caused incorrect results for inverse and cross-currency pairs. The shift factor is now applied directly inside the IFxShift service before any pair inversion or cross-currency computation.
If your project uses a non-unit shift factor (mr.fx.shift-factor != 1.0), results for inverse and cross-currency FX pairs will change after upgrading. The previous behavior applied the shift factor incorrectly for these pairs, so the new results are mathematically correct. Review your FX risk outputs after migration to confirm the expected values.
If you use the default FXShift implementation (provided by FXShiftsServiceConfig), no action is required. The shift factor is automatically read from IFxProperties.getShiftFactor(). If you have a custom IFxShift implementation, ensure the shift factor is applied to the raw shift vectors before any inversion or cross-currency resolution.

FX relative sensitivity formula fix

The FX_RELATIVE sensitivity formula in ASensiFormulaProvider.fxRelativeShiftFormula() applied the priceFactor after the non-linear FX inversion, which is mathematically incorrect. The formula has been corrected to apply the priceFactor before the inversion:
If your project uses FX_RELATIVE sensitivity rules with a priceFactor other than 1.0, Taylor VaR and PnL Explain results for FX sensitivities will change after upgrading. The new results are mathematically correct. This fix is consistent with the FX shift factor fix in the IFxShift service described above.

Stable names for hidden technical measures

Hidden intermediate technical measures in the MTM, Notional, and OriginalNotional chains have been renamed. Previously their names were generated automatically by Copper (for example MTM.SUM__#__0__#__VaR). These names are now stable, explicit, and include the cube name (for example MTMVaR-ES Cube.TECHNICAL). Impact on DirectQuery aggregate tables. If your DirectQuery aggregate table configuration references any of the old auto-generated names, update those references to the new names: Impact on MDX queries. If any MDX query targeted one of these technical measures by its auto-generated name, update the measure name accordingly. Extenders overriding the suffix. The nameTechnicalMeasure(String) method is a default method on IMeasureParameters. If a custom suffix is needed, override it in your IMeasureParameters implementation. Clash risk for deprecated factory overloads. The deprecated no-arg factory methods INotionalMeasures.notional(), INotionalMeasures.originalNotional(), and IVaRESMeasures.mtmNative() produce unqualified names such as Notional.TECHNICAL. If an extender calls a deprecated overload from more than one cube, startup will fail with a duplicate-measure-name error. Migrate to the cube-aware overloads (notional(String cube), originalNotional(String cube), mtmNative(String cube)) without delay.

Deprecated APIs

The following APIs have been deprecated for removal in a future version:

FXShift constructor change

The FXShift class now accepts IFxProperties instead of individual String parameters for the common currency. The new constructor also reads the shift factor from IFxProperties.getShiftFactor(). If you instantiate FXShift directly, update your code:

Properties added

mr-common-config module:

Exclude FX risk from the VaR cube

The new property mr.fx.enable-fx-risk-on-var-cube defaults to true. No action is required to preserve the current behavior. To opt in and exclude FX risk from the VaR cube, set the property to false:
Setting this property to false is incompatible with mr.fx.enable-var-base-currency-dimension=true. The application will fail at startup if both properties are set together. In distributed deployments, set this property on each data node that hosts the VaR cube. Keep the value consistent across all data nodes to avoid schema reconciliation failures at startup. Setting the property on a query node alone has no effect.

6.0.6 to 6.0.7

Upgrading from version 6.0.6, see Atoti Market Risk 6.0.7 Release Notes. Atoti Market Risk uses Atoti Server 6.1.17 and Atoti UI 5.2.x. For new features and fixes included in these releases, please see the Atoti UI documentation and Atoti UI Migration Notes, and the release notes for Atoti Server.

Summary

  • Atoti Server upgrade: Atoti Server has been upgraded to 6.1.17.
  • Base Currency dimension extracted to conditional beans: The Base Currency dimension is now registered as a conditional Spring bean in each cube’s dimension config, replacing inline static method calls. Action required if you override dimension config classes or call BaseCurrencyDimensionConfig.fxEffectDimension() directly in custom dimension builders.
  • Sensitivity cube configuration refactoring: Taylor-specific dimensions have been extracted into a separate configuration class. Action required if you have custom extensions.
  • New CubeMoveKind date members available: Previous=CUB+1 and Next=CUB-1 can now be configured in mr.taylor.market-shift-date-specific and mr.cubes.levels.day-to-day-members to enable cube-relative date shifting. These are opt-in features that must be explicitly added to your configuration.
  • JGroups authentication class changed: The JGroups AUTH protocol class has been changed from AtotiAuthToken to SharedSecretAuthToken. Action required if you have custom JGroups protocol XML files.

Base Currency dimension extracted to conditional beans

The Base Currency dimension was previously added to each cube via inline calls to BaseCurrencyDimensionConfig.fxEffectDimension() inside dimension builder lambdas. These inline calls have been removed. The dimension is now registered as a separate conditional Spring bean in each cube’s dimension config class. The affected classes are:
  • VarESCubeDimensionsConfig: new bean varFxEffectDimension, annotated with @ConditionalOnVarFxDimensionEnabled
  • VarESSummaryCubeDimensionsConfig: new bean varSummaryFxEffectDimension, annotated with @ConditionalOnVarFxDimensionEnabled
  • SensiCubeDimensionsConfig: new bean sensiFxEffectDimension, annotated with @ConditionalOnSensiFxDimensionEnabled
  • SensiSummaryCubeDimensionsConfig: new bean sensiSummaryFxEffectDimension, annotated with @ConditionalOnSensiFxDimensionEnabled
  • BaseCurrencyDimensionConfig: the common fxEffectDimension bean is now annotated with @ConditionalOnSensiFxDimensionEnabled
Impact on custom projects: If you override any of the above dimension config classes, remove any remaining inline calls to BaseCurrencyDimensionConfig.fxEffectDimension() from dimension builder lambdas and define a dedicated conditional bean instead. If you call BaseCurrencyDimensionConfig.fxEffectDimension() directly in a custom dimension builder, replace that call with a bean definition annotated with the appropriate condition annotation, or use the static overload that accepts individual parameters such as displayCurrencies and localRiskMember. No action required if:
  • You use the standard Market Risk configuration without custom extensions
  • You do not override any of the dimension config classes listed above

Configuration changes

Taylor dimensions extraction

The following three dimensions have been moved from SensiCubeDimensionsConfig to a new configuration class TaylorDimensionsConfig:
  • Scenario Analysis Hierarchy
  • Liquidity Horizon Hierarchy
  • Scenario Set Hierarchy
These dimensions are now imported via TaylorMeasuresConfig. Impact on custom projects: If you have custom configuration that extends or overrides SensiCubeDimensionsConfig, you may need to update your imports. If you have custom configuration that directly references these dimension beans, ensure your configuration imports TaylorDimensionsConfig or has a dependency on TaylorMeasuresConfig. No action required if:
  • You use the standard Market Risk configuration without custom extensions
  • You do not override Sensitivity cube dimension configuration

New CubeMoveKind date members available

The CUB prefix is now supported for date shifting in the following properties. The CUB prefix stands for Cube-relative shift: it resolves to the nearest date that actually exists in the cube (dates are sorted in the cube’s natural descending order, from most recent to oldest), as opposed to DAY which shifts by a fixed number of business days.
  • mr.taylor.market-shift-date-specific (MarketShiftDate hierarchy)
  • mr.cubes.levels.day-to-day-members (Day-to-Day hierarchy)
To enable CubeMoveKind add Previous=CUB+1 and/or Next=CUB-1 to your configuration:
Note that the first entry in each list becomes the default member of the hierarchy. To make Previous the default member, place it first in the list.

Dependency upgrades

JGroups authentication class change

SharedSecretAuthToken replaces AtotiAuthToken
The JGroups AUTH protocol class has been changed from com.activeviam.activepivot.dist.impl.internal.distribution.security.impl.AtotiAuthToken to com.activeviam.common.distribution.security.SharedSecretAuthToken. If you have custom JGroups protocol XML files (protocol-tcp.xml or protocol-udp.xml), update the AUTH element:
No action required if you use the standard JGroups protocol files shipped with the accelerator.

6.0.5 to 6.0.6

Upgrading from version 6.0.5, see Atoti Market Risk 6.0.6 Release Notes. Atoti Market Risk uses Atoti Server 6.1.15 and Atoti UI 5.2.x. For new features and fixes included in these releases, please see the Atoti UI documentation and Atoti UI Migration Notes, and the release notes for Atoti Server.

Summary

  • Atoti Server upgrade: Atoti Server has been upgraded from 6.1.13 to 6.1.15.
  • Atoti What-If upgrade: Atoti What-If has been upgraded to 4.1.6-AS6.1. To migrate any custom What-If configuration, see the migration guides for this release.
  • Common-lib upgrade: Common-lib has been upgraded from 2.1.11-AS6.1 to 2.1.12-AS6.1.
  • Scenario handling rework: Scenario index decoding now uses a join-based approach via ScenarioNameFromJoinPostProcessor, replacing the old store-based ScenarioNamePostProcessor.
  • DirectQuery incremental refresh: The IRefreshTask interface has a new method signature accepting a ChangeDescription parameter.
  • Branch permissions config moved: ActivePivotBranchPermissionsManagerConfig has moved from mr-common-config to mr-application.
  • Measure parameter constructors updated: VaRMeasureParameters and PnLMeasureParameters constructors now accept an IFxProperties object instead of separate FX parameters.

API updates

IRefreshTask interface change

The IRefreshTask functional interface has been updated. The old refresh() method is now deprecated and replaced by refresh(@Nullable ChangeDescription changeDescription). If you have custom implementations of IRefreshTask, update them to accept the new ChangeDescription parameter:
The ChangeDescription parameter allows incremental refresh operations. Pass null if a full refresh is desired.

VaRMeasureParameters constructor change

The VaRMeasureParameters constructor that accepted separate String fxRiskClass and Double defaultFxRate parameters has been deprecated. The new constructor accepts an IFxProperties object instead:
The same change applies to PnLMeasureParameters. If you have custom measure parameter beans (e.g. in classes extending VarMeasureParametersBeans or PnlMeasureParametersBeans), update the constructor calls accordingly.

RiskDimension.getRiskClassesHierarchyWithNA() deprecated

The method RiskDimension.getRiskClassesHierarchyWithNA() has been deprecated. Its behavior (contributing unknown members with AUTO_CONTRIBUTE_UNKNOWN_MEMBER_ALWAYS) has been merged into getRiskClassesHierarchy(). Replace any calls to getRiskClassesHierarchyWithNA() with getRiskClassesHierarchy().

Deprecated classes and methods

The following deprecations have been introduced in 6.0.6. These will be removed in a future release.

ActivePivotBranchPermissionsManagerConfig in mr-common-config

The class com.activeviam.mr.common.datastore.permissions.ActivePivotBranchPermissionsManagerConfig in the mr-common-config module has been deprecated (@Deprecated(forRemoval = true, since = "6.0.6")). The replacement class is com.activeviam.mr.application.config.security.ActivePivotBranchPermissionsManagerConfig in the mr-application module. The new implementation uses AtotiSecurityProperties to dynamically resolve admin roles instead of a hardcoded list. If you have a custom implementation of branch permissions, migrate to extend or replace the new mr-application version.

Scenario measure methods

Several scenario-related methods have been deprecated in favor of new “Ex” variants that use the ScenarioNameFromJoinPostProcessor (join-based) instead of the old ScenarioNamePostProcessor (store-based): The new methods require an additional underlier for the scenario index measure. If you override any of these methods, update your implementations to use the new variants.

IMeasureResolver.getMeasureBeans()

The method getMeasureBeans() has been deprecated (since 6.0.5). Use getCopperBeans() instead, which returns Publishable<?> beans (a broader scope including both measures and non-measure copper elements).

Scenario join-based configuration

Scenario hierarchies and scenario name decoding have been reworked to use a left-join approach. This is the most significant architectural change in 6.0.6.

New classes

  • JoinScenarioHierarchy (mr-common-config): Provides base left-join configurations for scenario analysis, liquidity horizon, and scenario set hierarchies.
  • JoinScenarioHierarchyVaR (mr-var-config): VaR cube-specific scenario join configuration.
  • JoinScenarioHierarchySensi (mr-sensi-config): Sensitivity cube-specific scenario join configuration.
  • ScenarioNameFromJoinPostProcessor (mr-common-lib): New post-processor that decodes scenario indices using the join rather than direct store lookups. Implements IDistributedPostProcessor for distributed cube support.

New Spring qualifier constants

New qualifier constants have been added to SpringConstants for injecting scenario store joins and hierarchies: If you have custom cube dimension configurations, update them to use the new join-based hierarchy builders and Spring qualifiers.

Cube dimension configuration changes

The dimension configuration classes for all cubes have been updated to use the new join-based scenario hierarchies:
  • VarESCubeDimensionsConfig: New beans scenarioAnalysisHierarchyVaR() and liquidityHorizonHierarchyVaR() using JoinScenarioHierarchyVaR. The deprecated method scenarioSetLeftJoinVaR() will be removed in a future release.
  • VarESSummaryCubeDimensionsConfig: Updated to use JoinScenarioHierarchyVaR for summary cube.
  • SensiCubeDimensionsConfig: Updated to use JoinScenarioHierarchySensi.
  • SensiSummaryCubeDimensionsConfig: Updated to use JoinScenarioHierarchySensi for summary cube.
If you maintain custom copies of these configuration classes, align them with the new join-based approach. The Base Currency and FX Effect hierarchies are added to the VaR cube when mr.fx.enable-var-base-currency-dimension=true.

EsVaRMetricLevelsProperties interface extension

The EsVaRMetricLevelsProperties interface has four new default methods: These are used by the multi-jurisdiction FX improvements. If you have custom implementations of this interface, these defaults ensure backward compatibility, but you may want to provide actual level identifiers if you use FX risk features.

DirectQuery incremental refresh

This release introduces support for incremental refresh of DirectQuery data sources. The MRDirectQueryRestServices class now propagates ChangeDescription objects through to all IRefreshTask instances. If you have custom refresh tasks or extend the DirectQuery REST services, update your implementations to handle the new ChangeDescription parameter. See the incremental refresh documentation for details.

Dependency version changes

6.0.4 to 6.0.5

Apply patched Atoti Server 6.1.13 classes.

Atoti Server 6.1.13 has a few issues which require the application of patched classes to every project using DirectQuery features. We provide these patched classes in the mr-application module. If you are not using this module as-is, please copy the following classes to the application module of your project: mr-application/src/main/java/com/activeviam/database/composite/internal/version/CompositeVersionAccessor.java mr-application/src/main/java/com/activeviam/databasecache/private_/database/SqlVersionAccessorWithCache.java

SensitivityType hierarchy

The new property named mr.sensi.display-taylor-var-by-sensitivity is by default set to true. If set to false, the Taylor VaR by Sensitivity measures are not displayed in the Sensitivity cube. The SensitivityType hierarchy is created to replace this set of measures. Set the property mr.sensi.display-sensitivity-type-hierarchy to false to hide this new hierarchy. For instance Delta Taylor VaR measure is replaced by Taylor VaR with filter on sensitivityType = Delta. If the FX effect is categorized as “Delta FX”, it is important to hide the original [Sensitivity] Taylor VaR measures by setting mr.sensi.display-taylor-var-by-sensitivity=false. The FX effect is only moved on the [Sensitivities].[SensitivityType] hierarchy but not on the sensitivities specific measures. If the hierarchies used to translate the FX effect must contain the desired location or be virtual. To do so, the Risk Class hierarchy has ‘N/A’ as default parameter that is used when the ‘FX’ member is absent. More precisely, when mr.fx.enable-fx-risk-location-shift=true, a location can only be displayed if the respective hierarchies contains the correct members, or are declared as virtual. Otherwise, the FX risk may not be visible in the cube. To do so, the following analysis hierarchy HierarchyWithFxRiskFactors can be used to add the FX risk factor members to the Risk Factors@Risk hierarchy. In the event that the member is not present on the hierarchy and this one is not declared as virtual, the default member will be used. To display the default member, the property AUTO_CONTRIBUTE_UNKNOWN_MEMBER_PROPERTY=AUTO_CONTRIBUTE_UNKNOWN_MEMBER_ALWAYS must be set on the hierarchy. The translation between the currency pair and the risk factor is done by the IRiskFactorFXPairTranslator bean. It may be customized to fit your risk factor naming convention. Please see the Relation between RiskFactor and currency pair chapter for more details.

Properties added

Sensitivities module properties: In addition:
  • The Spring properties mr.data-load.csv have been removed, and the default Data Connector properties are now used instead.
  • The source definition is described in the application.yaml configuration file. For convenience, the content specific to Data Connectors is set in the application-dlc-local-csv.yaml and application-dlc-azure-csv.yaml file.
  • The topics used by Atoti Market Risk are defined via Java beans of type ILoadingTopicDescription or IUnloadTopicDescription. The topics defined as ILoadingTopicDescription are still using the file-patterns Configuration Properties, which you can override in the application.yaml configuration file.

Migration to Atoti Market Data

The Market Data API, introduced in Atoti Market Risk 5.3, is now an external dependency called Atoti Market Data, using version 1.3.1 . The market data artifacts (market-data-lib, market-data-config, and market-data-spring-boot-starter) are versioned independently, and the source code is no longer provided alongside the Atoti Market Risk source code. For more information, see the Atoti Market Data Documentation. As part of this migration, several changes have been made: mr-common-config module: mr-common-config module: mr-common-config: mr-sensi-config:

Refactor of SensiMeasureParameters

With the removal of the vector data model, the SensiMeasureParameters constructor has been refactored to remove the boolean isVector field.

DirectQuery configuration

The DirectQueryActivePivotConfig class no longer extends the ADirectQueryApplicationConfig class from Atoti Server. Atoti Server 6.1.2 introduced some bean name changes in this class that cause bean resolution issues. These will be resolved in a following Atoti Server release, at which time this change can be reversed.

Schema rebuild

In the MarketRiskConfig class in mr-application we create a bean to schedule an Atoti schema rebuild. Previously this would run after 5 minutes and every 30 minutes thereafter. This was more frequent than necessary and may impact performance. We have increased the default to 1,440 minutes (24 hours) so the rebuild occurs once a day. We have also added new properties (mr.application.rebuild...) to customize this for your requirements.

Sign-Off REST services

The implementation of the Sign-Off REST services now has a Boolean to enable/disable them. Out of the box, the Sign-Off REST services are disabled until the initial load is completed. This prevents the Sign-Off server from sending requests on those services before the end of the initial load. Atoti core exceptions are now used instead of the previously used Javax exceptions. Error messages and constants have been fixed. Their prefix and/or content was previously incorrect. In particular, the constant ERROR_MESSAGE has been replaced by the constant ERROR_MESSAGE_NO_VALID_DTO_PROVIDED.

Webservices

The following outdated dependency has been removed from the POM file of the mr-common-lib module:
The String constant for the "application/json" media type from the Spring class org.springframework.http.MediaType is used instead of the corresponding constant from thejavax.ws.rs.core.MediaType class.

Sorting order of beans

The class StartupSpringBeanOrder has been added with constants used to define the order in which some of the beans are loaded: In increasing order:
  • START_MANAGER: Starts the Atoti Server manager.
  • REGISTER_DATABASE_LISTENERS: Registers the parent/child listeners.
  • INITIAL_CONFIGURATION_DATA_LOAD: Starts the initial data load.
  • INITIAL_DATA_LOAD: Instantiates beans after the initial data load is completed.
  • START_DISTRIBUTED_MESSENGERS: Starts the distribution messengers.

Fix for trailing white space incorrectly added with empty string suffix

The methods *Suffix in the class VaRMetricParametersAndNames now trim the generated measure names to avoid the incorrect addition of a trailing white space.

DirectQuery Cache

This release includes a new DirectQuery caching mechanism that dynamically loads slices of data into memory to improve the performance of retrievals from external stores (stores not joined to the base store). Currently, this only supports market data stores - those from Atoti Market Data and the additional stores from the mr-sensi-config module. Additionally, this is a preview feature that is disabled by default. To enable the feature, set the property: mr.enable.preview.directquery-cache=true. When you are using the cache, a “slice” of market data will be stored in memory when it is required for a query. A slice corresponds to all the market data for a given combination of asOfDate and marketDataSet. These slices will be added and removed from the cache based on the maximum number of slices that can be held at any one time. You can configure the maximum number of slices for a particular table with the directquery.cache.max-slice-count property, otherwise the value set in the directquery.cache.max-slice-count-default property will be used.

Scalar reference data

The reference dataset that is provided in mr-application/src/main/resources/data has been updated so that sensitivities are now in a scalar format rather than vectorized. This is primarily for clarity now that the Sensitivities Cube no longer supports a vectorized model. It is still possible to provide sensitivity vectors as input, but be aware that these will be converted and stored as scalar values in the application.

Distribution and measures

Atoti Market Risk cubes and their summary variants (for example the VaR-ES Cube and the VaR-ES Summary Cube) are created as a horizontal distribution. This enables Atoti Market Risk to show a single measure (for example VaR) with some dates coming from the full cube and other date contributions from the summary cube. This is a useful feature, but it comes with a warning. Atoti Server expects that all cubes in a horizontal distribution have exactly identical measure chains. If they do not, this can lead to errors or incorrect results when queries are executed on a query cube with both cubes. The measure chains in Atoti Market Risk are not identical between main and summary cubes but, in this release, we have made changes to avoid these failure scenarios. We strongly recommend that, if you are using summary cubes, you add any new measures both to the main and summary cubes.

6.0.3 to 6.0.4

Upgrading from version 6.0.3, see Atoti Market Risk 6.0.4 Release Notes. Atoti Market Risk uses Atoti Server 6.1.11 and Atoti UI 5.2.x. For new features and fixes included in these releases, please see the Atoti UI documentation and Atoti UI Migration Notes, and the release notes for Atoti Server.

Summary

  • Migrated to the DirectQuery Local Cache : The preview DirectQuery cache, included in Atoti Market Risk 6.0.0 has been replaced with the full Atoti Server version.

Breaking changes

The following classes were used in the configurations or descriptions of the preview DirectQuery cache introduced in Atoti Market Risk 6.0.0. The preview cache was a preview feature, and the cache has now been integrated into Atoti Server. Therefore, these classes have been removed rather than deprecated.
  • DirectQueryCacheConfig removed: This class was used to configure the preview DirectQuery cache and the configuration is no longer required.
  • DQSensiCacheConfig removed: This class contained correlation/dividend/splitRatio cache descriptions for the preview DirectQuery cache. These descriptions have been moved to their own classes: CorrelationMarketDataDirectQueryCacheConfig etc.
  • DirectQueryCacheProperties removed : This class contained properties to configure the preview DirectQuery cache. The API has been changed to configure the cache size. These properties are no longer used.

Configuration properties

Properties removed

mr-common-config module:
The two properties listed in the following table were used to configure cache sizes for the preview DirectQuery cache introduced in Atoti Market Risk 6.0.0. The cache has now been integrated into Atoti Server, and, while migrating to this new API, we have changed the API to configure the cache size.

Other changes

Migrate to the DirectQuery Local Cache

Atoti Market Risk 6.0.0 included the preview for a DirectQuery cache that balanced fast Get-By-Key query performance with controllable memory consumption. This cache was integrated into Atoti Server 6.1.9 as a robust, fully supported feature. In Atoti Market Risk the preview cache has been removed and replaced with the Atoti Server version. This cache is still enabled by setting the property mr.enable.preview.directquery-cache=true. With this setting enabled, all market data stores (specifically CubeMarketData, CurveMarketData, FxRateMarketData, SpotMarketData, SurfaceMarketData, and MarketShifts) are now cached when using DirectQuery. In previous versions, the MarketShifts store was not cached. The preview cache used classes in the private module: com.activeviam.mr.directquery.cache._private. These classes have been removed. For details on how to use the cache in your project, see Cache side stores.

Cache description imports

In Atoti Market Risk 6.0.0, cache descriptions for the preview DirectQuery cache were imported via the SensiCompleteConfig and MRDirectQueryConfig classes. The cache has now been integrated into Atoti Server, and all cache descriptions are now imported directly in MarketRiskConfig.

Data Connectors versioning

The Data Connectors dependencies (Data Load Controllers and Data Extraction Engine) are now versioned alongside Atoti Server. In the future, Data Connectors documentation will be included with the main Atoti Server documentation. For now, however, you may continue to use the previous documentation. The only change in this release is the introduction of the dlc.csv.implicit-topics-enabled property, which allows you to disable implicit topics entirely for load operations. The default is “true”, which means that implicit topics are enabled. Set to false to disable implicit topics.

6.0.2 to 6.0.3

Upgrading from version 6.0.2, see Atoti Market Risk 6.0.3 Release Notes. Atoti Market Risk uses Atoti Server 6.1.9 and Atoti UI 5.2.x. For new features and fixes included in these releases, please see the Atoti UI documentation and Atoti UI Migration Notes, and the release notes for Atoti Server.

Summary

  • Extensible tail measure types: You can now define custom tail measure types for use in calculations by ITailMeasureCalc and IWeightedTailMeasureCalc.
  • DtD % metric formula: The percentage change metrics named ... DtD % Difference formula can be changed to use the absolute value of the amount, by default it uses the legacy behaviour.
  • clear-filter parameter is taken in account for Drill-up comparative measures: The parameters clear-filter located on mr.metrics.booking, mr.metrics.trades, mr.metrics.custom-metrics.* path is taken in account for the post-processor=ParentValue setup.
  • DLC Warning logs and potential errors: After upgrading to Atoti Market Risk 6.0.3 you may see WARN logs such as: Implicit topic for table '...' cannot be built as the table does not exist in the datastore when loading data. See more details here

Breaking changes

  • Added imports to SensiSummaryCsvSourceConfig: The SensiSummaryCsvSourceConfig imports a number of underlying Spring configuration classes that create beans to load Sensitivity Summary stores. We have added imports to this class in Atoti Market Risk 6.0.3 for configuration classes that create DLC load and unload topics for the Correlation, Dividend, and SplitRatio market data stores. These stores are required by the Sensitivity Summary cube and, when running with only the Sensitivity Summary cube enabled, these imports are necessary to enable data loading to the stores. If you do not require these imports, please replace SensiSummaryCsvSourceConfig with a custom Spring configuration class, importing only the classes you require. In Atoti Market Risk 6.0.3, SensiSummaryCsvSourceConfig imports the following classes:
  • Added imports to SensiCsvSourceConfig: In the case of the main Sensitivity cube. The Correlation, Dividend, and SplitRatio load and unload topic beans were created in the SensiCsvLoadConfig and SensiCsvUnloadConfig configuration classes. These beans have now been extracted from these classes so they can be used by the Sensitivity Summary cube. Imports have been added to the SensiCsvSourceConfig class to configure these beans. As above, if you do not require these imports, please replace SensiCsvSourceConfig with a custom Spring configuration class, importing only the classes you require. In Atoti Market Risk 6.0.3, SensiCsvSourceConfig imports the following classes:
  • MRDlcDescriptionConfig import in MarketRiskConfig: the class com.activeviam.mr.common.sources.MRDlcDescriptionConfig from the mr-common-config is now imported in the MarketRiskConfig class instead of the com.activeviam.mr.application.sources.MRDlcDescriptionConfig class defined in the mr-application module. If you maintain your own copy ofMarketRiskConfig, you may wish to make a similar change in your project, but this is not required as both classes are still maintained for this version.

Deprecations

  • CalcType enums: ITailMeasureCalc.CalcType and IWeightedTailMeasureCalc.CalcType have been deprecated. There is a new TailMeasureCalcType class that allows you to define custom types. All methods that used these enums have also been deprecated and there are new methods using TailMeasureCalcType.
  • DLC Converter classes: GlobToRegexConverterConfig and RegexPassThroughGlobToRegexConverter were added in Atoti Market Risk 6.0.0 to provide additional functionality to the DLC when loading from cloud sources. This functionality is now part of the DLC and so these classes are not required. They have been deprecated to avoid breaking changes, but they are essentially empty and do not do anything. They should not be used and will be removed in the next breaking release of Atoti Market Risk.
  • MRCombinedCube property: The property mr.enable.cubes.common and the annotation @ConditionalOnCommonCubeEnabled are now deprecated. The property mr.enable.cubes.combined with a default value of true and the annotation @ConditionalOnCombinedCubeEnabled have been introduced to rename and in the future replace mr.enable.cubes.common and @ConditionalOnCommonCubeEnabled respectively. If you declare both properties, please ensure both are set to true to enable the MRCombinedCube.
  • MRDlcDescriptionConfig and MRNamedDescriptionUtil: com.activeviam.mr.application.sources.MRDlcDescriptionConfig and com.activeviam.mr.application.sources.MRNamedDescriptionUtil have been deprecated. These class have been copied, otherwise unchanged, to the mr-common-config module in the com.activeviam.mr.common.sources package.

DLC Warning logs and potential errors

After upgrading to Atoti Market Risk 6.0.3 you may see WARN logs such as: Implicit topic for table '...' cannot be built as the table does not exist in the datastore when loading data. This is due to a change in the DLC, which now highlights when you try to load a topic that does not exist. The topic aliases we provide in the application.yaml file load all topics including Sensitivities, VaR, and PnL. When you disable cubes with mr.enable.cubes... not all topics are created and so the WARN logs will be shown. These logs can be ignored. Or you can modify the aliases to load only the stores necessary for your use-case.
Please be aware that if you instruct the DLC to load a topic that you have not configured, and the topic matches the name of a store in your application, the DLC will throw an error.

DtD % metric formula

Depending on the mr.enable.dtd-absolute-increase property the computation of the ... DtD % Difference measures have changed.
  • If mr.enable.dtd-absolute-increase=false, the default and non-breaking behaviour, the formula is increase=todayyesterdayyesterdayincrease=\frac{today-yesterday}{yesterday}.
  • If mr.enable.dtd-absolute-increase=true, the formula is increase=todayyesterdayyesterdayincrease=\frac{today-yesterday}{|yesterday|}.

Configuration properties

Properties added

mr-common-config module:

Properties deprecated

mr-common-config module:

Other changes

springdoc-openapi version fix

In Atoti Market Risk version 6.0.2, the wrong version of springdoc-openapi was used - version 2.5.x - which is incompatible with the Spring Boot version 3.4.x used by the project. This has been corrected in version 6.0.3, which now uses springdoc-openapi version 2.8.9. For details on compatibility, see: https://springdoc.org/faq.html#_what_is_the_compatibility_matrix_of_springdoc_openapi_with_spring_boot The main POM file of the project has been updated accordingly: the property springdoc.version has now a value equal to 2.8.9 instead of 2.5.0 previously.

6.0.1 to 6.0.2

Upgrading from version 6.0.1, see Atoti Market Risk 6.0.2 Release Notes. Atoti Market Risk uses Atoti Server 6.1.8 and Atoti UI 5.2.x. For new features and fixes included in these releases, please see the Atoti UI documentation and Atoti UI Migration Notes, and the release notes for Atoti Server.

Summary

  • Properties to enable data overlap: Cube properties have been added that enable data overlap within a horizontally distributed setup.
  • Updated business calendar logic: Atoti Market Risk uses a new business calendar for PnL Explain calculations, considering all days business days. Please see below for further details.

Updated business calendar logic

PnL Explain calculations use an implementation of IBusinessDayCalendarFactory to determine business days. The default implementation is now PassThroughBusinessDayCalendarFactory, which categorizes all days as business days. If you need different behavior, you can provide your own implementation by publishing a new bean:
The previous default implementation was TargetBusinessDayConvention.Factory. This provided some simple business day logic, such as skipping weekends and holidays, but it is not appropriate for all cases. You can revert to this implementation by publishing the following bean:

Configuration properties

Properties added

mr-combined-config module
This property is defined in the CombinedDistributionProperties class, which is enabled in the MRCombinedCube class. If you have customized the import structure in your project, please ensure this properties class is enabled in your application to use the property.
mr-pnl-config module
These properties are defined in the PnlDistributionProperties class, which is enabled in the PnlPropertiesConfig class. If you have customized the import structure in your project, please ensure this properties class is enabled in your application to use these properties.
mr-sensi-config module
These properties are defined in the SensiDistributionProperties class, which is enabled in the SensiPropertiesConfig class. If you have customized the import structure in your project, please ensure this properties class is enabled in your application to use these properties.
mr-var-config module
These properties are defined in the VarDistributionProperties class which, is enabled in the VarPropertiesConfig class. If you have customized the import structure in your project, please ensure this properties class is enabled in your application to use these properties.

Measures

Modified

6.0.0 to 6.0.1

Upgrading from version 6.0.0, see Atoti Market Risk 6.0.1 Release Notes. Atoti Market Risk uses Atoti Server 6.1.6 and Atoti UI 5.2.x. For new features and fixes included in these releases, please see the Atoti UI documentation and Atoti UI Migration Notes, and the release notes for Atoti Server.

Summary

  • Configurable FX conversion default rate: FX conversion post-processors can now be configured to use a default FX rate if the actual rate cannot be computed for the FX pair.

Deprecations

  • MRDataLoadControllerRestServiceConfig: Deprecated MRDataLoadControllerRestServiceConfig from mr-application as this configuration class is no longer used after upgrading to DLC 5.0. This will be removed in the next major version of Atoti Market Risk.

Configuration properties

Properties added

mr-common-config module

Properties modified

mr-common-config module

5.4.0 to 6.0.0

Upgrading from version 5.4.0, see Atoti Market Risk 6.0 Release Notes.
To see what has changed since 6.0.0-Beta, check out Updates since 6.0 pre-releases.
Atoti Market Risk uses Atoti Server 6.1.5 and Atoti UI 5.2.x. For new features and fixes included in these releases, please see the Atoti UI documentation and Atoti UI Migration Notes, and the release notes for Atoti Server.

Summary

  • Atoti Server upgrade: Atoti Market Risk has been upgraded to Atoti Server 6.1.5. This version requires Java 21.
  • Upgraded to JDK 21: Upgraded from JDK 17 to JDK 21 to utilize the latest features.
  • Deprecated vector sensitivities data model code removed: Code specific to the vectorized sensitivities data model, which was deprecated in Atoti Market Risk 5.4, has been removed.
  • Move to Atoti Market Data: The Market Data API, introduced in Atoti Market Risk 5.3, is now an external dependency called Atoti Market Data, using version 1.3.1. For details, see the dedicated Atoti Market Data documentation.
  • Removal of solutions dependency management: Solution dependencies are now explicitly versioned, without a dependency management import of the Solutions Tools BOM.
  • Upgraded dependencies: All the Solution’s dependencies have been upgraded to their latest releases. See Dependency versions for the exact version numbers and links to their respective documentation pages.
  • Deprecated market data and FX services removed: Several deprecated services made obsolete by the move to Atoti Market Data have been removed.
  • Measure chain changes related to Atoti Market Data: FX conversions and market data retrieval are now done through Atoti Market Data APIs, leading to several measure chain changes.
  • Market data set changes: Market data sets have significantly changed in this release. Most notably MarketDataSet is now a field on all base stores ensuring each fact is specifically associated to a set.
  • Liquidity Horizon: The Liquidity Horizon parameter is now taken into account when computing VaR/Es metrics. To achieve this, the parameter has been moved to the Scenario table.
  • Removed fields from PnL Actual tables: Fields related to risk factors have been removed from the stores PnL and PnLBaseStore and the cubes PLCube and PL Summary cube.
  • Market data file format configuration clean-up: Market data file formats now match Atoti Market Data tables, no longer requiring explicit file naming patterns to be declared. Backwards compatibility has been maintained by matching the configured file naming pattern to the deprecated file formats. For details, see Market data API data loading.
  • Updated dashboards: A number of dashboards have been updated due to market data measure and context value changes. In addition, dashboards have been migrated to use Atoti UI’s Investigation feature instead of the story-telling feature, which has been decommissioned. For details, see Updated dashboards. For more information on the Investigation feature, see Investigations.
  • Configurable parent-child depth: You can now configure the maximum depth of parent-child hierarchies.
  • Removal of RoundingMethods and Quantiles stores: These stores are no longer needed.
  • Added optional LegId attribute: The attribute LegId has been added to the PLCube to enable sending in trades that will have multiple legs under a single TradeId. Only available when the property mr.pnl.enable.leg-id is set to true. LegId should be added to the end of PLActuals and PLPCActuals.csv, and to .json summary export files. Please update database scripts accordingly to use with DirectQuery.
  • Data Connectors 5.0: This version of Atoti Market Risk uses Atoti Data Connectors 5.0.0, which has a completely reworked API. For details, see Data Connectors upgrade.
  • New DirectQuery cache: This release includes a new DirectQuery caching mechanism that pulls slices of market data into memory when required to improve the performance of market data retrievals. This is a preview feature, disabled by default. See DirectQuery cache for details.
  • Measure folders: Measures related to a fixed confidence level are now placed in the folders related to fixed confidence levels.
  • Data node market data: During the initial data load (within the InitialDataLoadConfig class), market data is now loaded for all available dates, without taking the DLC scope into account.
  • Base stores and aggregate providers are now partitioned by AsOfDate: Added the new String property mr.partitioning.as-of-date.partition-type to configure the type of partitioning used for the field AsOfDate and the Integer property mr.partitioning.as-of-date.number-of-partitions to configure the number of partitions for the field AsOfDate when modulo partitioning is used. AsOfDate uses value partitioning by default.
  • DoctorPivot: The functionality previously provided by DoctorPivot is now available through Atoti Admin UI in the Measure dependencies tab. The DoctorPivot app no longer exists.
  • Replaced APM starter dependency: Replaced the dependency apm with atoti-server-apm-starter in market-risk/pom.xml and added the dependency atoti-server-apm-starter to mr-application/pom.xml.

Breaking Changes

  • Atoti Market Data dependencies: The way Atoti Market Risk specifies the Atoti Market Data dependency has changed. Please see the full details below.
  • Measure chain changes related to Atoti Market Data: FX conversions and market data retrieval are now done through Atoti Market Data APIs, leading to several measure chain changes.
  • Rebuild schedule change: Previously the Atoti schemas would be rebuilt every 30 minutes. This has now changed to once a day, and we have added properties to configure this for your requirements.
  • Removed risk factor FX pair fallback logic: Removed logic that would default to using the risk factor as a base currency and the display currency as a counter currency when the risk factor did not contain a currency pair in the XXX/YYY format.
  • Removed Cash sensitivities: Cash sensitivities were dependent on risk factor FX pair fallback logic and have therefore been removed.
  • Adjustment Config classes moved: SupportedAdjustment and AdjustmentExecution config classes have moved from mr-pnl/sensi/var-config modules to mr-application to make it easier to disable specific adjustments.
  • Cube-level adjustments: The implementation of cube-level adjustments has been changed: now only add-ons are supported for cube-level adjustments, and the add-ons are aggregated. Measures with the suffix _Adjusted have been removed. The configuration of the initial measures for which cube-level adjustments are now modified to take into account the add-on values, and new measures with the suffix Add-on have been created to display those add-on values. For details, see Cube-level adjustments.
  • Data Connectors 5.0: This version of Atoti Market Risk uses Atoti Data Connectors 5.0.0, which has a completely reworked API. For details, see Data Connectors upgrade.
  • Removal of obsolete DispatcherServlet configuration classes: Removed a configuration class and two utility classes setting up a DispatcherServletRegistrationBean as a workaround to Spring Boot incompatibilities in previous versions of Atoti Server. For details, see DispatcherServlet configuration removal.
  • Market data set changes: MarketDataSet is now a field on all base stores ensuring each fact is specifically associated to a set.
  • Liquidity Horizon: The parameter has moved to the Scenario table. See VaRTimePeriod context value for the behavior of the field.
  • Removed fields from PnL Actual tables: The attributes RiskFactor, RiskFactorType,RiskFactorCcy, CurveType, RiskClass and Qualifier have been removed from the stores PnL and PnLBaseStore and the cubes PLCube and PL Summary cube.
  • Removed datastore constant: DatastoreConstants.STORE_DATE_FIELD_FORMAT has been removed. ILiteralType.LOCAL_DATE should be used instead.
  • TRADE_KEY for PNL table: The value of the TRADE_KEY column of the PNL table for summary data is now the concatenation of “Book#VaR Inclusion#PLDriver” to avoid collision on the PLDriver field.
  • Removed file format details from tuple publisher: The MultipleStoreTuplePublisher no longer contains methods related to file columns and column calculators.
  • Sign-Off: This release is compatible with Sign-Off 6.0.
  • Updated MarketRiskConfig imports: CorporateActionMarketDataRetrievalConfig, DividendMarketDataRetrievalConfig, and CorrelationMarketDataRetrievalConfig are no longer imported in MarketRiskConfig. They are instead imported in SensiCompleteConfig and SensiSummaryConfig.
  • Removed properties files: jwt.properties has been removed. The properties from this file have been moved to the main application.yaml file. reporting.properties has been removed. These properties were used for a feature that is no longer present in the application. Both files were previously imported in MarketRiskConfig with an @PropertySource annotation. This too has been removed.

Atoti Server upgrade

For details on migrating your code to Atoti Server 6.1.5, see the Atoti Server migration notes.

Java 21

Update your Java version to Java 21 or later in order to run Atoti Market Risk.

Atoti Spring Boot Starter changes

Atoti Server now ships with a suite of Spring Boot Starters. These dependencies auto-configure default imports required by Atoti Server, that you may override at runtime. The following core classes have been removed, as they are now inherited from starters:
  • ActiveViamPropertyFromSpringConfig.class
  • ActivePivotServicesConfig.class
  • PartitionManagerConfig.class
  • ApplicationJwtConfig.class
  • SameSiteConfig.class
  • ActiveViamRestServicesConfig.class
  • ActiveViamWebSocketServicesConfig.class
  • ContentServerWebSocketServicesConfig.class
  • ApplicationMonitoringConfig.class
  • MonitoringRestServicesConfig.class
  • MonitorConfig.class
  • JwtRestServiceConfig.class
  • VersionServicesConfig.class
  • StreamingMonitorConfig.class
  • ActivePivotXmlaServletConfig.class
  • All beans with return type JMXEnabler

Security configuration changes

The upgrade to Atoti Server 6.1.5 includes changes to the security configuration. We expect you to implement your own security, but we provide a sample configuration in the com.activeviam.mr.application.config.security package.
This is not a production grade sample.
For details on how to implement your own security, please see the Atoti Server documentation.

DispatcherServlet configuration removal

Older versions of Atoti Server contained incompatibilities with Spring Boot. As a workaround, Atoti Market Risk provided the DispatcherServletConfig configuration class, exposing a DispatcherServletRegistrationBean registering the DispatcherServlet to the Atoti Server Spring context, and two ServletContextInitializer beans, registering SQL driver cleaners and a Java Logging to SLF4J logging bridge. These workarounds are no longer needed and clash with tests using multiple SQL connections, such as what-if testing with a local content service. The following classes have been deleted:

Data Connectors upgrade

Atoti Data Connectors 5.0 has a new API that avoids technical beans and instead, makes extensive use of properties.

Video overview

Check out our video on migrating to Data Connectors 5.0 in Atoti Market Risk 6.0:

Details of changes

Certain Spring Configuration and classes are no longer useful and have been removed:
Certain Spring Configuration and classes have been renamed to follow a common naming pattern:
The topics are defined for csv file upload and unload queries in the following spring configuration regrouped in the *.topics packages:
In addition:
  • The Spring properties mr.data-load.csv have been removed, and the default Data Connector properties are now used instead.
  • The source definition is described in the application.yaml configuration file. For convenience, the content specific to Data Connectors is set in the application-dlc-local-csv.yaml and application-dlc-azure-csv.yaml file.
  • The topics used by Atoti Market Risk are defined via Java beans of type ILoadingTopicDescription or IUnloadTopicDescription. The topics defined as ILoadingTopicDescription are still using the file-patterns Configuration Properties, which you can override in the application.yaml configuration file.

Migration to Atoti Market Data

The Market Data API, introduced in Atoti Market Risk 5.3, is now an external dependency called Atoti Market Data, using version 1.3.1. The market data artifacts (market-data-lib, market-data-config, and market-data-spring-boot-starter) are versioned independently, and the source code is no longer provided alongside the Atoti Market Risk source code. For more information, see the Atoti Market Data Documentation. As part of this migration, several changes have been made:

Removal of deprecated market data and FX services

Configurable parent child depth

You can now configure the maximum depth of the parent-child hierarchies (books, legal entities, counterparties) with new properties. To achieve this, the stores BookHierarchy, CounterpartyHierarchy, LegalEntityHierarchy now also have a variable number of fields to store the corresponding level entries. In addition, the summary flat stores (PnLBaseStore, SensiBaseStore, BaseStore) have a variable number of fields to be in line with the variable depth.

Removal of risk factor FX pair fallback logic

Previous versions of Atoti Market Risk would parse the risk factor for a currency pair when computing FX-related PnL Explain and when retrieving the FX rate to use for PnL vectors in the VaR cube. If the risk factor could not be parsed as an XXX/YYY-formatted currency pair, the logic would attempt to use the risk factor as a base currency and the display currency as a counter currency for the FX rate. This fallback logic has now been removed, with VaR Cube PnL conversion using the default FX rate retrieval (which uses the fact currency and the display currency). PnL Explain logic will fail to retrieve an FX rate if the risk factor is not in the correct format.

Measure chain changes

Cube-level adjustments

Cube-level adjustments are no longer defined in the general measure configuration files of each module. The following MeasurePublisher objects have been removed: The class SensitivitySignOffMeasuresConfig has been removed. Cube-level adjustments are now defined as a modified configuration of the adjusted measures in the following files, imported in the MarketRiskConfig class:
  • VarESCubeLevelAdjustmentsMeasuresConfig
  • SensiCubeLevelAdjustmentsMeasuresConfig
  • PnLCubeLevelAdjustmentsMeasuresConfig
The service class CubeLevelAdjustmentsMeasureBuilder, needed for the configuration classes mentioned above, is now also imported in the MarketRiskConfig class. The class CubeLevelAdjustedMeasuresBuilder is not used anymore in the project configuration and is marked as deprecated. Measures with the suffix _Adjusted have been removed. The configuration of the initial measures for which cube-level adjustments are now modified to take into account the add-on values, and new measures with the suffix Add-on have been created to display those add-on values.

PnL

A new MeasureCreator method has been added for FX conversion: IPnLMeasures#convert(MarketDataDateShift shift, NameRetriever<PnLMeasureNames> nameRetriever). For this method, a market data set level identifier has been added to the PnLMeasureParameters configuration object.

Sensitivities

API changes
The CopperMarketDateMeasure typo has been fixed, with the class now named CopperMarketDataMeasure. New FX-related MeasureCreator methods have been added to the factory interfaces: The replaced methods have been removed: Additionally, the ATaylorFactory factories now implement IBaseMeasures, gaining access to the added FX MeasureCreator methods.
Removal of measures required by vectorized sensitivities
In order to support vectorized sensitivities, the following measures types were required in the sensitivity chain: These measures have now been removed for every sensitivity type, with the chain being simplified to: This simplification has resulted in the following changes:

VaR

FX conversion
New FX-related MeasureCreator methods have been added to the factory interface: The replaced methods have been removed:

Updated dashboards

  • The following dashboards have been updated with the levels [Sensitivities].[Sensitivity].[SensitivityName] and [Risk].[Risk Classes].[RiskClass] added to their MDX queries so that market data can be displayed.
    • Atoti MR & PL/Story-Telling Target Views/Delta and Gamma P&L Explain
    • Atoti MR & PL/Story-Telling Target Views/Vega P&L Explain
    • MR/03 - PnL Explain/02 - Example for one trade
    • MR/03 - PnL Explain/03 - Vega Market data
  • The following dashboards have been updated to remove any usage of Cash-related measures:
    • Atoti MR & PL/How It Works/Computing Greek-Based PL
    • Atoti MR & PL/How It Works/How Taylor VaR is computed
    • Atoti MR & PL/How It Works/Taylor VaR using previous MD
    • Atoti MR & PL/Story-Telling Target Views/Backtesting Risk Factor View
    • Atoti MR & PL/Story-Telling Target Views/Investigate Tail for Taylor
    • Atoti MR & PL/Story-Telling Target Views/Taylor VaR Risk Factor View
    • MR/03 - PnL Explain/01 - PnL explain break-down
MR/01 - VaR-ES/03 - VaR Explain Dashboard has been fixed: a context value that was removed in a previous version was incorrectly used in the dashboard.
  • The following dashboards have been migrated to use Atoti UI’s Investigation feature instead of the story-telling feature, which has been decommissioned.
    • Backtesting Investigation
    • Backtesting Risk Factor View
    • Book and Trade Backtesting
    • Computing Greek-Based PL
    • How Taylor VaR is computed
    • Investigate Tail
    • Investigate Tail for Taylor
    • P&L anomalies
    • PnL & PnL Explain side by side
    • Taylor VaR Risk Factor View
    • Taylor VaR using previous MD
    • Trade by Risk Factor

MarketDataSets

Each market data value in Atoti Market Risk is associated with a market data set. This set is used within calculations to ensure the appropriate market data value is retrieved. Prior to this release MarketDataSets was a slicing analysis hierarchy populated from an external store. With this release MarketDataSet is now a field on each of the base stores. This reflects that each fact is associated to a given market data set and this should be used consistently within calculations. As you can see below, the store definitions and input file formats have been updated to accommodate this change. The MarketDataSets hierarchy is now based on these fields, and the external MarketDataStore has been removed. By default, MarketDataSets remains a slicing hierarchy. However, we now offer a property (mr.cubes.levels.slicing-market-data-set) to toggle this to a non-slicing hierarchy.
Setting MarketDataSets to non-slicing can have a significant impact on calculations. Please ensure this is appropriate for your use-case.

Input file formats

Modified

Removed

Configuration

Configuration properties

Properties added
mr-application module: mr-common-config module: mr-pnl-config module:
Properties modified
mr-application module: mr-common-config module: Market data properties (e.g. mr.sensi.market-data.vega.any.custom.interest-rate-risk.market-data-type=cube) have been updated to reject incorrect (or unsupported) configuration: mr-pnl-config module: mr-sensi-config module: mr-var-config module:
Properties removed
mr-application module: mr-common-config: mr-sensi-config:

Properties files

Files added
Files modified

Files Removed

  • azureCredentials.properties has been replaced by the application-dlc-azure-csv.yaml profile.
  • jwt.properties has been removed and the properties from this file are now in the main application.yaml
  • reporting.properties has been removed. These properties were used for a feature that is no longer present in the application.
  • apm.properties has been removed. This file is currently not used in the application.

Datastores

Modified stores

Deleted stores

Stores relating to the removal of the vectorized sensitivity data model The following stores have been deleted due to the removal of the vectorized sensitivity data model:
  • mr-sensi-config/src/main/java/com/activeviam/mr/sensi/datastore/description/complete/stores/MarketDataStoreConfig.java. If you continue to use the deprecated market data API, you can find this store configuration in the MarketDataStoreConfig class. You will need to import this class to use the store.
  • mr-sensi-config/src/main/java/com/activeviam/mr/sensi/datastore/description/complete/stores/CorporateActionStoreConfig.java
  • mr-sensi-config/src/main/java/com/activeviam/mr/sensi/datastore/description/complete/stores/TenorsStoreConfig.java.
  • mr-sensi-config/src/main/java/com/activeviam/mr/sensi/datastore/description/complete/stores/VectorMarketDataStoreConfig.java
  • mr-sensi-config/src/main/java/com/activeviam/mr/sensi/datastore/description/complete/stores/VectorTradeSensitivitiesStoreConfig.java
  • mr-sensi-config/src/main/java/com/activeviam/mr/sensi/datastore/description/summary/VectorSensiAggregatedStoreConfig.java
  • mr-sensi-config/src/main/java/com/activeviam/mr/sensi/datastore/description/summary/VectorSensiFlatStoreConfig.java
If you were using the Tenor, Maturity, or Moneyness stores for the StoreQueryMaturityConverter, the configuration for these classes has been removed. To continue using this, please add a store configuration for each.
Other stores

Database

Modified tables

Deleted tables

Cube schema

Added

Modified

Removed

As part of the removal of the vectorized sensitivities data model we have removed configuration of dimensions for it, but no actual dimension has been removed.

Measures

Added

Modified

  • All measures in the Value at Risk folder have moved to the Value At Risk folder, and those in Value at Earnings have moved to Value At Earnings.
  • Confidence level-specific measures can now be found in the correct folders corresponding to the associated confidence level. The default implementation of methods in the interface IFixedConfidenceMeasures has been changed accordingly.
Market data
Sensitivity- and risk-class-agnostic market data measures have been added, replacing the previously visible FX-converted and Native measures. For sensitivities that used a single type of market data (for example, CrossGamma only uses Spot market data), the PnL Explain chains have been updated to use those market data types directly. When a sensitivity uses multiple types of market data depending on risk class, such as Delta with Spot for equities and Curve for GIRR, the top level market data measures have been updated to behave as a location-based switcher between the available market data types. For details about the market data measures made available in Market Risk 6.0.0, the Market Data section covers the types of market data available in the Sensitivity Cube as well as which market data types are used for each sensitivity. A complete list of measures is also available.

Removed

Vector-specific measures
All vector counterparts of the sensitivities measures have been removed. This affects any annotated CopperMeasure bean with @ConditionalOnVectorizedSensitivity.

Context values

Added

Other changes

Adjustments

The MarketDataSet level is now a required input for all adjustments. See the SupportedAdjustments(Sensi/PnL/VaR)Config classes for full configuration. This reflects the fact that MarketDataSet is now a base store field. Currency is now an optional filter for the PnL Roll-over adjustment. This means that adjustments for native PnL measures contain all necessary filters. The inputs to all supported adjustments, as defined in the SupportedAdjustments<cube>Config files, all now include a label. This is used by the UI to make it clearer what value the user is expected to provide. Similarly, the Currency input for all cube-level adjustments now includes a level path. This allows the UI to provide appropriate values for that field.

DLC

The StaticSensiPillars topic alias has been removed. This was used to load data into the Tenors, Maturities, and Moneyness stores. These stores have been removed as part of the removal of vectorized sensitivities, so this topic is no longer required. The SignOffDigestStore topic has been renamed to CubeLevelAdjustments to reflect the new name of the store and this has been moved from the Attributes alias to a new SignOff alias to reflect the fact that not all projects use Sign-Off.

Removed duplicate store field constant

The store field constant STORE_DATE_FIELD_FORMAT was duplicated and bore the same value in each case. We have kept the iteration in DatastoreConstants (mr-common-config) and removed the following ones:
  • com/activeviam/mr/pnl/datastore/description/complete/PnLStoreConfig.java
  • com/activeviam/mr/var/datastore/description/complete/VaRStoreConfig.java

FXShifts

FXShiftsServiceConfig has been split out of the existing FXRatesServiceConfig class. To use the market shift service (IFxShift), you must now import the FXShiftsServiceConfig class. By default, it is imported in MarketRiskConfig.

Removal of deprecated code

Code
Adjustments
The following methods have been removed:
  • SupportedAdjustmentsSensiConfig.sensiadd-on
  • SupportedAdjustmentsSensiConfig.sensiScaling
  • SupportedAdjustmentsSensiConfig.sensiOverride
  • AdjustmentsExecutionSensiConfig.getSensiScalingExecution
  • AdjustmentsExecutionSensiConfig.getSensiOverrideExecution
These methods were used to create and support adjustment types for the vectorized model of the sensitivities cube. The Add-on, Override, and Scaling adjustments are still available when using the scalar model of the sensitivities cube.
DEE Templates
The following DEE templates (found in mr-application/src/main/resources/dee-templates) were used for vectorized sensitivities. They have been removed in this release:
  • SensiCubeExport
  • SensiAggregatedCubeExport
The CubeAdjustmentTemplate DEE template (found in mr-application/src/main/resources/dee-templates) has been updated to use the CubeLevelAdjustments store.

Cube-level adjustments

Cube-level adjustments now rely on the creation of facts added to the base store (and on entries added to stores referenced by the base store if needed) to define the location at which they are applied, and on entries in an isolated store to define the measures for which they are defined, along with the adjusted values. Only add-ons are now supported for cube-level adjustments. The add-ons are aggregated using dynamic aggregation on the adjustment source field of the base store of the cube for which the adjustment is created. The notion of location digest has been removed from the logic used for cube-level adjustments. Please see additional details in Testing custom adjustment types. Measures with the suffix _Adjusted have been removed. The configuration of the initial measures for which cube-level adjustments are now modified to take into account the add-on values, and new measures with the suffix Add-on have been creat to display those add-on values. The store SignOffDigestStore has been renamed to CubeLevelAdjustments and its field updated - please see description of the changes in the Datastores and Database sections. The following method has been removed:

Supported Adjustments definitions

  • The Type level and the Instrument Type level have been added to the SupportedAdjustmentDTO SupportedAdjustmentsPnLConfig.pnlCubeLevelAdjustment().
  • The Scenario Set, Calculation Id and Instrument Type levels have been added to the SupportedAdjustmentDTO SupportedAdjustmentsVaRConfig.varEsCubeLevelAdjustment().
  • The Instrument Type level has been added to the SupportedAdjustmentDTO SupportedAdjustmentsSensiConfig.sensiCubeLevelAdjustment().
Tests
Removed
Modified

Refactor of SensiMeasureParameters

With the removal of the vector data model, the SensiMeasureParameters constructor has been refactored to remove the boolean isVector field.

DirectQuery configuration

The DirectQueryActivePivotConfig class no longer extends the ADirectQueryApplicationConfig class from Atoti Server. Atoti Server 6.1.2 introduced some bean name changes in this class that cause bean resolution issues. These will be resolved in a following Atoti Server release, at which time this change can be reversed.

Schema rebuild

In the MarketRiskConfig class in mr-application we create a bean to schedule an Atoti schema rebuild. Previously this would run after 5 minutes and every 30 minutes thereafter. This was more frequent than necessary and may impact performance. We have increased the default to 1,440 minutes (24 hours) so the rebuild occurs once a day. We have also added new properties (mr.application.rebuild...) to customize this for your requirements.

Sign-Off REST services

The implementation of the Sign-Off REST services now has a Boolean to enable/disable them. Out of the box, the Sign-Off REST services are disabled until the initial load is completed. This prevents the Sign-Off server from sending requests on those services before the end of the initial load. Atoti core exceptions are now used instead of the previously used Javax exceptions. Error messages and constants have been fixed. Their prefix and/or content was previously incorrect. In particular, the constant ERROR_MESSAGE has been replaced by the constant ERROR_MESSAGE_NO_VALID_DTO_PROVIDED.

Webservices

The following outdated dependency has been removed from the POM file of the mr-common-lib module:
The String constant for the "application/json" media type from the Spring class org.springframework.http.MediaType is used instead of the corresponding constant from thejavax.ws.rs.core.MediaType class.

Sorting order of beans

The class StartupSpringBeanOrder has been added with constants used to define the order in which some of the beans are loaded: In increasing order:
  • START_MANAGER: Starts the Atoti Server manager.
  • REGISTER_DATABASE_LISTENERS: Registers the parent/child listeners.
  • INITIAL_CONFIGURATION_DATA_LOAD: Starts the initial data load.
  • INITIAL_DATA_LOAD: Instantiates beans after the initial data load is completed.
  • START_DISTRIBUTED_MESSENGERS: Starts the distribution messengers.

Fix for trailing white space incorrectly added with empty string suffix

The methods *Suffix in the class VaRMetricParametersAndNames now trim the generated measure names to avoid the incorrect addition of a trailing white space.

DirectQuery Cache

This release includes a new DirectQuery caching mechanism that dynamically loads slices of data into memory to improve the performance of retrievals from external stores (stores not joined to the base store). Currently, this only supports market data stores - those from Atoti Market Data and the additional stores from the mr-sensi-config module. Additionally, this is a preview feature that is disabled by default. To enable the feature, set the property: mr.enable.preview.directquery-cache=true. When you are using the cache, a “slice” of market data will be stored in memory when it is required for a query. A slice corresponds to all the market data for a given combination of asOfDate and marketDataSet. These slices will be added and removed from the cache based on the maximum number of slices that can be held at any one time. You can configure the maximum number of slices for a particular table with the directquery.cache.max-slice-count property, otherwise the value set in the directquery.cache.max-slice-count-default property will be used.

Scalar reference data

The reference dataset that is provided in mr-application/src/main/resources/data has been updated so that sensitivities are now in a scalar format rather than vectorized. This is primarily for clarity now that the Sensitivities Cube no longer supports a vectorized model. It is still possible to provide sensitivity vectors as input, but be aware that these will be converted and stored as scalar values in the application.

Distribution and measures

Atoti Market Risk cubes and their summary variants (for example the VaR-ES Cube and the VaR-ES Summary Cube) are created as a horizontal distribution. This enables Atoti Market Risk to show a single measure (for example VaR) with some dates coming from the full cube and other date contributions from the summary cube. This is a useful feature, but it comes with a warning. Atoti Server expects that all cubes in a horizontal distribution have exactly identical measure chains. If they do not, this can lead to errors or incorrect results when queries are executed on a query cube with both cubes. The measure chains in Atoti Market Risk are not identical between main and summary cubes but, in this release, we have made changes to avoid these failure scenarios. We strongly recommend that, if you are using summary cubes, you add any new measures both to the main and summary cubes.