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.



New features

Custom error handling

Atoti Limits now gives you the ability to display custom error messages on its screens. This feature not only improves the look-and-feel of Atoti Limits, but lets you pinpoint issues using your own terminology.

See Adding Custom UI Exceptions for details.

Enhanced table features

In the Inventory and Status screens the columns can now be resized, reordered, and hidden. The styling of the table has also been updated to improve the visibility of active filters and increase the real estate available to display data.

New engine

Atoti Limits 3.2.0 is powered by the latest version of Atoti Server and Spring. The result is a faster, safer application, which you can customize using the most modern stack available.

Smarter startup

When starting out, creating and loading files to start Atoti Limits can be tricky. To help with this, Atoti Limits now generates empty default files if it doesn’t find yours on startup, allowing you to get to work quicker.



New features

Holistic limit status overview

The all-new Status screen replaces the previous Breaches screen. This design aims to enhance efficiency and streamline your workflow. The new screen provides a comprehensive view of limit statuses and utilization across your entire limit inventory. All the essential breach-processing functionality has been seamlessly integrated into the new Status screen, retaining the core capabilities you rely on. The Status screen leverages a brand-new table design, providing an intuitive and user-friendly interface. You can easily filter limit evaluations based on specific limits and their attributes.

For more details on the new UI, see Status screen.

Improved breach root cause analysis - Linked dashboards

Atoti Limits now provides seamless navigation from limits and limit breaches to dashboards, enhancing your ability to dissect and analyze limit usage data. This feature is leveraging Atoti’s native BI capabilities for flexible data exploration to enable drill-down to the most granular level - trade, risk factor, or scenario - and help analyze the root cause of breaches or drivers of limit utilizations on a daily basis.

Check out Linked dashboards on how to get started.


Improved limit reporting in the Limits Cube

The Limits Cube is your canvas for visualizing limit evaluations alongside essential limit attributes in a dynamic dashboard. To further enrich your analysis, a new Utilization measure has been added to the Limits Cube. This measure succinctly displays utilization for every limit.



New features

On-demand limit evaluations

This feature enables you to re-evaluate limits whenever needed. In addition to the evaluations triggered automatically, you can now request evaluations directly from the UI. This is especially useful when underlying risk data might have changed and you want to ensure that you have the most up-to-date results.

To start leveraging the benefits of on-demand limit evaluations, see Evaluate limits.


Smarter limit definitions

Now you can use various functions for limit scope selection and add limits based on specific criteria. Discover the simplicity and flexibility of this enhancement today. See Complex scopes to get started.

Enhanced audit trail

You can now easily view before and after values for modified fields, gaining better insights into limit changes. For workflows involving four or six-eyes approval processes, we’ve added requester and approver details, ensuring complete visibility and accountability. Stay in control of your limits with this improved audit trail feature.

For details, see View the limit history.



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


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



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


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



Bug fixes.



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



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 temporary 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:


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:



  • 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.


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



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

For details, see the Release notes.



  • 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.



  • 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.


  • 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


  • 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.


  • 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.


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.


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.



  • 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.



  • 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