☰
Navigation :

What's New

This page provides a brief overview of the user-facing new features and improvements in the latest version of Atoti Limits.

For bug fixes and developer-facing changes, see our Changelog.

2.0.1-ui-update-2

Summary

This is a UI-only release that allows you to exclude values from the Limit Scope dropdown when creating limits.

warning

This version of Atoti Limits can only be used with Business Cubes that are on Atoti UI 5.1.x.

2.0.1-ui-update-1

Summary

This is a UI-only release that makes Atoti Limits compatible with Atoti UI version 5.1.0 or higher.

warning

This version of Atoti Limits can only be used with Business Cubes that are on Atoti UI 5.1.x.

2.0.1

Summary

Bug fixes.

2.0.0-ui-update-1

Summary

This is a UI-only release containing performance improvements for creating limits for very large cardinality hierarchies.

2.0.0

Summary

New features

Redesigned Inventory for easier limit management

A risk appetite framework may require managing a large number of limits, which can be time-consuming and overwhelming. That’s why we’ve revamped our limit Inventory to help you add multiple similar limits. This feature will help increase productivity and streamline the process of managing hundreds or even thousands of limits. For more details, see the following topics:

Temporary limits, in a fully governed way

Atoti Limits now offers a solution to automate temporarily limit increases, to facilitate business needs in a controlled manner.

A temporary limit is a Limit that co-exists with an official limit for a given period of time. On evaluation, a temporary limit will take precedence over the official limit.

A temporary limit will have the same lifecycle as the official limit, but will terminate before the official limit terminates. A temporary limit must spawn from an official limit, it cannot be created as a standalone limit.

In practice, a temporary limit is used to handle extraordinary non-lasting events. For example, a trader may have an official limit of 1mm on Book A, with no expiration. The trader has an open position on Book A of 900,000, so she is not in breach of her limit. However, due to market volatility, prices have increased and her position has risen to 1.1mm, putting her in breach. She consults her risk manager, and the risk manager envisages that volatility in the market will subside in the next month, but he grants her a temporary limit on Book A of 1.15mm for 6 months. Now, the temporary limit will take precedence over the official limit for 6 months, so the trader’s position of 1.1mm is no longer in breach.

The difference between a temporary limit and an update to an official limit is that official limits are usually set periodically by the Risk department of a firm. If the terms upon which the official limit was agreed change, for example, the credit rating on Counterparty X was Aaa at the time the official limit was set and it has since been reevaluated to Ba, then the logical step is to update the official limit. However, if the limit only needs to be adjusted to account for a change that is deemed to be non-lasting, the temporary limit is the best approach.

For instructions on how to set a temporary limit, see Set a temporary limit.

Dedicated breach management view

The new Breach management view simplifies the workflow to help you focus on the root cause analysis and resolution of the incident. Breach management gathers breach occurrences and requests stakeholder input in detailing, categorizing, and addressing breaches. For details, see the following topics:

Improvements

Limits in top navigation bar

You can now navigate to limits and breaches from anywhere in the application using the menu in the top navigation bar:

1.1.0

Summary

  • Email notifications on limit breaches.
  • Context menu action to view utilizations of a limit.
  • Limits Auto-Configuration
  • Copy action
  • Swagger UI is available at {base.url}/swagger-ui/index.html. This will display some REST endpoints exposed by the Limits server. It can be enabled/disabled by setting property swagger.enable to true/false.
  • Performance improvements.

New features

Email notifications

The Limits Module can be configured to send email notifications about limit breaches.

See Configuring breach email notifications for details.

View Utilizations context menu action

A new context menu action has been added that lets you view the utilization of limits from a pivot table. This is helpful when investigating exceptions. The feature works on all pivot tables in the Limits project, including the Limits Inventory widget.

See View Utilizations for details.

Auto-Configuration

You can now use auto-configuration to integrate the Limits Module with atoti+. See Auto-configuration for details.

Copying Limits

You can now click the Copy button in the Limits Inventory to duplicate an existing limit.

For more information, see Copy a limit

1.0.1+1

Summary

This is a UI-only release that has updated Accelerator-sdk and ActiveUI dependencies.

For details, see the Release notes.

1.0.1

Summary

  • Calculated Measures can now be published to the Cube. For more information, see Publishing a Calculated Measure.
  • Breach and alert reports: Breach and alert reports are now split into separate files per KPI. The file name format is: “/alert*{kpiName}*{lastUpdateTimeStamp}.csv”
  • Sample limits and bookmarks: We have created new sample limits that correlate with our sample data for FRTB, as well as added bookmarks tailored for these limits, which can be added to your deployment.
  • Upgrade to ActiveUI 5.0.15.
  • Performance improvement for limit evaluation and KPI creations.
  • Bug fixes.

1.0.0

Summary

  • Separate Limit Change and Exception workflows
  • Exception UI
  • Performance improvements
  • Creator can now approve the limit

New features

Exceptions UI

The Exception and Exception Audit tabs have been added to the Limits Drawer to help you investigate warnings and breaches.

See Manage exceptions for details.

Separate Limit Change and Exception workflows

Redesigned the workflow to separate the limit change/update/delete workflow and the limit exception/breach/warning workflow. The Limit Change workflow now has Straight-through and four-eyes options. The Limit Exception workflow handles the breach and warning events. The workflow associated with exceptions is defined in the application.yml property file.

Improvements

  • Performance improvements: Many performance improvements have been implemented to improve the startup time and KPI query time. For details on configuring performance tuning properties, see Performance.
  • Creator can now approve the limit: The user who created the limit can now approve it if canTheApproverBeTheSameAsTheCreator in limits.properties is set to true. The default value for this property is false.

1.0.0 Alpha

Summary

  • New workflow names
  • Added property to specify the URL of the Limits Module
  • Audit trail screen
  • Added validation to Limit Definition
  • Ui improvements
  • Upgrade to AUI 5.0.11
  • Upgrade to Accelerator-sdk 5.0.7
  • Limits on Calculated Measures
  • Workflow triggered after editing and deleting a limit

New features

Audit trail screen

An audit trail screen has been added to the Limits Inventory Widget, allowing you to see the audit history of the selected limit.

See Viewing the audit history for details.

Improvements

  • New workflow names: The workflows have been renamed.
    - Straight through: no approval needed, created in approved state.
    - Four eyes: previously called single eye. One person creates the workflow, another person approves.
    - Six eyes: previously called 4 eyes. One person creates the workflow, two people approve.

note

To make sure your limit workflow works as expected, please discard any previous testing data in the datastore and Activiti databases. On top of the workflow name changes, the reference implementation now has the Role_Users by default to be able to create the limit definition instead of Role_Managers.

  • Added property to specify the URL of the Limits Module: Limits now supports being run from any location; previously Limits was assumed to be running at localhost.
  • Added validation to Limit Definition: Limit Definitions are validated when loaded through CSV or File Upload.
  • Limits on Calculated Measures : Limits can now be created on Calculated Measures via File Upload.

note

Limits cannot be created on calculated measures through the UI. See LIM-320 in the Known Issues

  • UI improvements: Enabled Lazyloading for Limits Inventory Widget, numerous bug fixes, added column sorting to the Limits Inventory Widget, enabled Storytelling, better error handling.
  • Workflow after editing and deleting a limit: After editing or deleting a limit in the Limits Inventory Widget, the workflow is triggered. Editing triggers the Limit Change Workflow, deleting triggers the Straight through workflow and an audit record is created in the audit database.
  • Roles: All the KPIs created by the Limits module now have LIM_ROLE as the owner and viewer.

0.3.0

Summary

  • UX re-design : Based on feedback from demos we have redesigned the UX of the Limits Module.
  • Upgrade to ActivePivot 5.10.7 and ActiveUI 5.0.6.
  • Amber support : Amber support has been added through the use of warningThreshold field. This lets you specify a percent of the limit value where the KPI should show amber status. For more information, see Create a New Limit.
  • New KPI Types : Previously, all limits were interpreted as “Greater Than”. Now, through the KPI Type field, you can specify “Less Than”, “Between”, and “Not Between”. For more information, see Create a New Limit.
  • Added support for Atoti+: For steps on how to use the Limits Module with Atoti+ please read the Integrating the Limits Module with the Atoti+ Python API page.
  • Added support for workflow: Integrating the Limits Module with the Atoti+ Python API page.

0.2.0

Summary

  • Support Multiple ActivePivot Instances : The Limits Module now supports multiple ActivePivot instances. Clients can use one Limits Module to monitor and create KPI in the Limits Inventory Dashboard, such as monitoring MRA and FRTB in one place.
  • On-Demand Limits Monitoring : LimitEvaluation restful endpoint is available for clients to trigger the evaluation on demand. The result is written into alert csv files with timestamps and exposed in the Breach Count measure.
  • Trend Analysis of Limits: By including AsOfDate hierarchy in the business cubes, users can now analyze KPI goal changes over a period of time.
  • Upgrade to AUI 4.3.17
  • Documentation Improvements