Dimensions
This section describes the dimensions in the Limits Cube.
| Dimension | Description | Value Example |
|---|---|---|
| Group | Name of a group of limits. Group is a way of organizing similar limits. | Equity Desk |
| Comment | Free text note about the limit. | These are equity delta limits managed by the GMCCR department. |
| PollingFrequency | Specifies how often the limit is checked for a breach. The available options are: End of day and Intraday. | EOD |
| Reference ID | The Reference ID for a limit in an external system, if you have one in your organization. | id_desk_00023 |
| Limit Structure Name | The KPI name created in the business cube. | Delta |
| MeasureName | Measure of the KPI. | PV |
| Scope | This restricts which members the new limit applies to. You can choose any hierarchy of the currently selected Cube and a corresponding value from said hierarchy. An example scope filter is “Desk=Rates”. Multiple scope filters can be added to a single limit definition. Every scope filter is separated by a pipe. | Desk=Bonds |
| AbsoluteValueIndicator | Specifies whether the Limit Value is an absolute value. | false |
| WarningThreshold | Percent value from a breach. | Within 10% of breach value, the user receives a warning. |
| KpiType | The type of KPI. | Greater Than |
| Precedence | Precedence of a limit to be applied to a Location. If two limits apply to a location in the Cube, Precedence can help to enforce which limit takes effect. | 10 |
| userID | The limit creator’s user ID. | |
| CubeName | Name of the Cube for the KPI. | Sensitivity Cube |
| ServerName | Name of the server the Cube is running. | MR |
| Timestamp | The time the limit was created. | 13:43:23.478 |
| Exception Status | Status of the breach or warning after the evaluation. The options are: - BREACHED - WARNING - REVIEWED |
BREACHED |
| Exception Category | While reviewing the exception, the reviewer can specify the cause of the exception. The current options are: 1. Technical Data Issue 2. Real Breach. |
Technical data issue. |
| Exception Comment | Comment added during reviewing the warning or breach. This comment is audited. | Have notified the trader to correct the trade. |
| Limit Changes Workflow | Limit management workflow type. This workflow is required for amending the limit value on a defined/approved limit. The approval types in the core solution are: - StraightThrough: There is no approval needed. - FourEyes: In addition to the person doing the action, another person needs to approve for the action to be effective. When this workflow is selected, you need to specify an Examiners user group for approval. - SixEyes: In addition to the person doing the action, two other separate people need to approve for the action to be effective. |
StraightThrough |
| Limit Changes Workflow Parameters | The party charged with reviewing a limit’s workflow. Potential options are USERS or MANAGERS. | Examiner=ROLE_USERS |
| Exception Workflow | Exception workflow type, which handles Breaches and Warnings. | Exception |
| Pending Status | Status of the pending workflow. Once the pending workflow is approved, the limit will take on the values of the Pending Limit Definition. | PENDING_DELETION |
| System State | Optional field to note the state of the limit structure in the upstream system. | |
| limitKey, displayed as “Actions” | Hashed value of concatenation of all key fields. | Delta,2020-01-01,2020-01-31,OFFICIAL,EOD,Desk=Equity,Sensitivity Cube, MR |
| Limit Name | The KPI name created in the business cube. | Delta |
| Start Date | Effective Start Date. | 2020-01-01 |
| End Date | Effective End Date. | 2020-01-31 |
| Limit Type | The type of limit: either OFFICIAL or TEMPORARY. | OFFICIAL |
| LimitStatus | Workflow status. | APPROVED |