Source Code

Analysis Tree Structure

1. Balancesheet

1.1. Introduction

  • The BalanceSheet tree is a more standardized tree that includes built-in consistency rules and is linked to other modules for dynamic simulation. This structure is used to represent the financial position of a company, reflecting its assets, liabilities, and equity.

Key Characteristics:

Consistency Rules:

  • The Balance Sheet Structure follows specific rules to ensure that the relationships between different financial elements are accurate and consistent.

Dynamic Simulation:

  • It is integrated with other modules for dynamic simulation, enabling real-time analysis and adjustments based on changing financial conditions.

Standardized Format:

  • The structure is more standardized compared to the Portfolio Tree, ensuring that all necessary financial elements are included and correctly represented.

Parallel Structures:

  • Multiple balance sheet structures can exist simultaneously, allowing for different scenarios or analyses to be conducted in parallel.

1.2. Tables and relations

1.3. BalancesheetController

1.3.1. Create balance sheet

1.3.2. Update balance sheet

1.3.3. Get balance sheet

2. PortfolioStructure

2.1. Introduction

  • The Portfolio Tree is a flexible structure used to organize and analyze financial contracts according to user specifications. It can take any form based on the user’s needs and is primarily a way to arrange financial contracts and their analytical results.

Key Characteristics:

Customizable Structure:

  • The form of the Portfolio Tree is defined by the user, allowing for tailored analysis according to specific requirements.

Organization of Contracts:

  • It helps in organizing financial contracts into a coherent structure, facilitating easier analysis and management.

Analytical Results:

  • It focuses on representing the analytical outcomes of the financial contracts, providing insights into their performance, risks, and returns.

Flexibility:

  • Multiple portfolio tree structures can exist in parallel, allowing different perspectives or analyses to be maintained simultaneously

2.2. Tables and relations

Establishing relationships

  • In relational databases like SQL, relationships between tables are crucial for organizing and querying data effectively. These relationships are typically established using foreign key constraints, which define links between tables based on the values of specific columns. Common types of relationships include one-to-one, one-to-many and many-to-many relationships, each serving different data modeling needs.

2.3. PortfolioController

2.3.1. Create portfolio tree

2.3.2. Update portfolio tree

2.3.3. Get portfolio tree

3. BehaviourTree

3.1. Introduction

3.2. Tables and relations

Establishing relationships

  • In relational databases like SQL, relationships between tables are crucial for organizing and querying data effectively. These relationships are typically established using foreign key constraints, which define links between tables based on the values of specific columns. Common types of relationships include one-to-one, one-to-many and many-to-many relationships, each serving different data modeling needs.

3.3. BehaviourTreeController

3.3.1. Create behaviour tree

3.3.2. Update behaviour tree

3.3.3. Get behaviour tree

4. CounterpartyTree

4.1. Introduction

4.2. Tables and relations

Establishing relationships

  • In relational databases like SQL, relationships between tables are crucial for organizing and querying data effectively. These relationships are typically established using foreign key constraints, which define links between tables based on the values of specific columns. Common types of relationships include one-to-one, one-to-many and many-to-many relationships, each serving different data modeling needs.

4.3. CounterPartyTreeController

4.3.1. Create counterparty tree

4.3.2. Update counterparty tree

4.3.3. Get counterparty tree

Contract Viewer / Loader

1. Introduction

2. Tables and relations

Establishing relationships

  • In relational databases like SQL, relationships between tables are crucial for organizing and querying data effectively. These relationships are typically established using foreign key constraints, which define links between tables based on the values of specific columns. Common types of relationships include one-to-one, one-to-many and many-to-many relationships, each serving different data modeling needs.

3. ContractViewerController

3.1. show contracts

Risk Factor Viewer / Loader

1. Introduction

2. Tables and relations

Establishing relationships

  • In relational databases like SQL, relationships between tables are crucial for organizing and querying data effectively. These relationships are typically established using foreign key constraints, which define links between tables based on the values of specific columns. Common types of relationships include one-to-one, one-to-many and many-to-many relationships, each serving different data modeling needs.

3. MarketController

3.1. market object code list

Market Scenario

1. Introduction

  • Risk factors are external (stochastic) inputs used in various simulations. There are several types of risk factors, including Interest Rates, Yield Curves, FX Rates, (Stock) Indices, Commodities, and Behavioral Elements. Since the state of risk factors is only known today (and in the past), their future evolution is uncertain. A risk scenario represents a specific (assumed) state of any of these risk factor types, enabling us to analyze our financial and operational strategies under these assumptions.

There are primarily two types of risk scenarios:

  • What-if scenarios

  • Monte Carlo (MC) scenarios.

In the GUI, users can:

  • Define and edit What-if scenarios for all types of risk factors.

  • Load What-if or MC scenarios from an external source.

  • Store scenarios in the database.

A What-if or MC scenario represents a single assumption about a risk factor. Multiple such scenarios can be combined into a Scenario Set (MRSS), with many Scenario Sets existing in parallel in the database.

What-if scenarios can be defined in two ways:

  • Static What-if: Define the scenario as a shock to the current (observed) state of the risk factor.

  • Dynamic What-if: Define the scenario as a series of shocks to the current (observed) state of the risk factor, with each shock applied at a specific future time.

A shock consists of two types of operations applied to the current (observed) state of the risk factor:

  • Addition of a certain amount to the current state.

  • Multiplication of the current state by a certain multiplier.

2. Tables and relations

Establishing relationships

  • In relational databases like SQL, relationships between tables are crucial for organizing and querying data effectively. These relationships are typically established using foreign key constraints, which define links between tables based on the values of specific columns. Common types of relationships include one-to-one, one-to-many and many-to-many relationships, each serving different data modeling needs.

static market risk scenario master
Figure 1. static market risk scenario master Entity-relationship diagram

Tables

  • Schema

    1. Table static_market_risk_scenario_master

      Index Name Data type

      * 🔑

      scenarioId

      int

      *

      scenarioName

      varchar

      * ⬈

      scenariosetId

      int

      1. Indexes

        Type Name On

        🔑

        scenario_master_pkey

        scenarioId

      2. Constraints

      Name Definition

      —

      —

    (🔑) - Primary key

    (*) - Mandatory

    (⬈) - Foreign key

    (🔎) - Constraint
static market risk scenario set master
Figure 2. static market risk scenario set master Entity-relationship diagram

Tables

  • Schema

    1. Table static_market_risk_scenario_set_master

      Index Name Data type

      * 🔑

      id

      int

      *

      riskscenariosetName

      varchar

      * ⬈

      userId

      varchar

      *

      scenariosetType

      varchar

      1. Indexes

        Type Name On

        🔑

        scenario_set_master_pkey

        id

      2. Constraints

      Name Definition

      —

      —

    (🔑) - Primary key

    (*) - Mandatory

    (⬈) - Foreign key (if userid maps to another table like users)

    (🔎) - Constraint
static market risk scenario data
Figure 3. static market risk scenario data Entity-relationship diagram

Tables

  • Schema

    1. Table static_market_risk_scenario_data

      Index Name Data type

      * 🔑

      id

      int

      *

      scenarioId

      int

      *

      marketType

      varchar

      *

      selectionType

      varchar

      *

      groupName

      varchar

      *

      marketId

      int

      *

      additive

      varchar

      *

      multiplication

      varchar

      *

      state

      varchar

      *

      volaState

      varchar

      *

      volaMultiplication

      varchar

      *

      volaAdditive

      varchar

      *

      curve

      double

      *

      rateType

      varchar

      *

      shockType

      varchar

      *

      volaType

      varchar

      1. Indexes

        Type Name On

        🔑

        scenario_data_pkey

        id

      2. Constraints

      Name Definition

      —

      —

    (🔑) - Primary key

    (*) - Mandatory

    (⬈) - Foreign key

    (🔎) - Constraint

3. StaticRiskFactorController

3.1. Create static scenario set

3.1.1. Sequential flow

create-static-scenario.puml

Static Scenario Set Creation Process:

  • The user sends scenarioSetName, scenarioName, and encrypted userId to the createStaticScenario service.

  • The service decrypts the userId using PasswordProtection.

  • It fetches the actual userId from the database using UserDetailsService.

  • It checks if the scenario set already exists for the user.

If scenario set doesn’t exist:

  • A new scenario set is created and saved.

  • A new scenario is created and linked to the set.

  • The response returns the created scenarioSetId.

If scenario set already exists:

  • An exception is thrown indicating the scenario set already exists.

3.1.2. Endpoint

Description

This endpoint allows users to create a new static market scenario set by providing necessary scenario details. The scenario is associated with a specific user and a scenario set.

URL

/createStaticScenario

Method

POST

Request Body

The request body must be a JSON object that adheres to the structure of the StaticScenarioRequestDTO class.

Example Request Body

{
  "scenarioSetName": "InterestRateShockSet",
  "userId": "SDZnRU9yU3pkbEU4M1AwVDJ6UWNhUT09",
  "scenarioName": "Plus200BP"
}

Responses

200 OK: Static market scenario created successfully. Returns the ID of the newly created static scenario set.

Example Response Body

{
  "status": 200,
  "message": "SUCCESS",
  "data": 72562
}

  • 400 Bad Request:

  • Returned when required fields are missing or invalid in the request payload.

Example

{
  "status": 400,
  "message": "scenarioName must not be null",
  "data": null
}

  • 401 Unauthorized:

  • Returned when the user is not authenticated or lacks permission to perform this operation.

  • 500 Internal Server Error:

  • Returned if an unexpected error occurs while processing the request.

Example

{
  "status": 500,
  "message": "Unexpected error occurred while creating the scenario",
  "data": null
}

3.1.3. Methods

Description

The method createNewStaticScenarioSet is responsible for creating a new static market scenario set and associating it with a scenario. It ensures that duplicate scenario sets are not created for the same user.

Parameters

  • staticScenarioRequestDTO (StaticScenarioRequestDTO): An object containing the required input data to create a new static scenario set, including the encrypted userId, scenarioSetName, and scenarioName.

Returns

  • Integer: The ID of the newly created static scenario set. If the scenario set already exists, an exception is thrown.

Example Usage

public Integer createNewStaticScenarioSet(StaticScenarioRequestDTO staticScenarioRequestDTO) {
String decryptedUserName = PasswordProtection.getDecryptedData(staticScenarioRequestDTO.getUserId()); (1)
String userId = userDetailsService.getUserId(decryptedUserName);

boolean exists = isScenarioSetAlreadyExistsAtUserDynamic(userId, staticScenarioRequestDTO.getScenarioSetName()); (2)
if (exists) {
    throw new IllegalArgumentException(Constants.SCENARIO_SET_ALREADY_EXIST); (3)
}
StaticMarketRiskScenarioSetMaster setMaster = new StaticMarketRiskScenarioSetMaster();
setMaster.setRiskScenarioSetName(staticScenarioRequestDTO.getScenarioSetName());
setMaster.setUserId(userId);
setMaster.setScenarioSetType(Constants.SWI);

Integer setId = saveStaticRiskScenarioSetMasterService(setMaster); (4)

StaticMarketRiskScenarioMaster scenario = new StaticMarketRiskScenarioMaster();
scenario.setScenarioName(staticScenarioRequestDTO.getScenarioName());
scenario.setScenarioSetId(setId);

int scenarioId = staticMarketRiskScenarioMasterService.saveScenarioSetDynamic(scenario); (5)


return setId; (6)

}

Internal Workflow:

1 Decrypt the encrypted userId from the request DTO to obtain the actual username, then retrieve the corresponding userId.
2 Check if a scenario set with the same name already exists for the user.
3 If it exists, throw an IllegalArgumentException with the message SCENARIO_SET_ALREADY_EXIST; otherwise, proceed to create the new scenario set.
4 Create a new StaticMarketRiskScenarioSetMaster entity with the scenario set name, user ID, and set type (SWI), then save it to obtain the setId.
5 Create a new StaticMarketRiskScenarioMaster entity linked to the setId with the provided scenario name, then save it to obtain the scenarioId.
6 Return the setId of the newly created scenario set.

Exceptions:

  • IllegalArgumentException: Thrown when a scenario set with the same name already exists for the user.

3.1.4. Model classes

Description

The StaticScenarioSetRequestDTO class is a Data Transfer Object (DTO) used for retrieving or managing static market scenarios based on the scenario set and user context. It carries the key information required to identify and fetch scenarios relevant to a specific user.

Attributes

  1. scenarioSetName

    • Type: String

    • Description: The name of the scenario set from which static scenarios are to be fetched or manipulated.

    • Example: "InterestRateShockSet1"

  2. scenarioName

    • Type: String

    • Description: The name of a specific static scenario within the scenario set.

    • Example: "ShockScenario"

  3. userId

    • Type: String

    • Description: Unique identifier for the user requesting or associated with the static scenario.

    • Example: "USE21"

{
      "scenarioSetName": "InterestRateShockSet1",
      "userId": "SDZnRU9yU3pkbEU4M1AwVDJ6UWNhUT09",
      "scenarioName": "Plus200BP"
}

3.1.5. Testing

3.2. Rename static scenario set

3.2.1. Sequential flow

create-static-scenario.puml

Static Scenario Set Rename Process:

  • The user sends scenarioSetName, renameScenarioSetName, and encrypted username to the renameStaticScenarioSet endpoint.

  • The service decrypts the username using PasswordProtection.

  • It retrieves the actual userId from UserDetailsRepository from UserDetailsService.

  • It fetches the list of existing scenario sets for the user from StaticMarketRiskScenarioMasterService.

  • It checks if the new scenario set name already exists (case-insensitive)

If the name exists:

  • The method returns false (rename not performed).

If the name does not exist:

  • Updates the scenario set name in StaticMarketRiskScenarioSetMasterRepository.

  • Fetches the updated list of scenario sets from YieldCurveIdentificationService.

  • Formats the names with their type prefixes (SWI or SMC) for UI display.

  • Returns true indicating a successful rename.

3.2.2. Endpoint

Description

This endpoint allows users to rename an existing static market scenario set by specifying its current name, the new desired name, and the requesting user.

URL

/renameStaticScenarioSet

Method

PUT

Request Body

The request body must be a JSON object that adheres to the structure of the RenameStaticScenarioSetRequestDTO class. Example Request Body

{
  "scenarioSetName": "InterestRateShockSet",
  "renameScenarioSetName": "Stock",
  "username": "SDZnRU9yU3pkbEU4M1AwVDJ6UWNhUT09"
}

Responses

200 OK: Static market scenario set renamed successfully. Returns true if the rename was successful, otherwise return false.

Example Response Body

{
  "status": 200,
  "message": "SUCCESS",
  "data": [
    {"scenarioSetName": "SMC | sdvdsvds"},
    {"scenarioSetName": "SMC | Test"},
    {"scenarioSetName": "SMC | rf"},
    ]

  • 400 Bad Request:

  • Returned when required fields are missing or invalid in the request payload.

Example

{
  "status": 400,
  "message": "scenarioName must not be null",
  "data": null
}

  • 401 Unauthorized:

  • Returned when the user is not authenticated or lacks permission to perform this operation.

  • 500 Internal Server Error:

  • Returned if an unexpected error occurs while processing the request.

Example

{
  "status": 500,
  "message": "Unexpected error occurred while creating the scenario",
  "data": null
}

3.2.3. Methods

Description

The method renameStaticScenarioSet is responsible for renaming an existing static market scenario set for a given user. It ensures that the new scenario set name does not already exist (case-insensitive) for the same user before performing the rename.

Parameters

  • dto (RenameStaticScenarioSetRequestDTO): An object containing the current scenario set name, the new scenario set name, and the encrypted username of the requesting user.

Returns

List<Map<String, String>>

A formatted list of renamed scenario set names, where each entry is a map with the key scenarioSetName and the value prefixed with SWI | or SMC | depending on the scenario set type.

Example Usage

	@Override
	public List<Map<String, String>> renameStaticScenarioSet(RenameStaticScenarioSetRequestDTO dto) {
		String decryptedUserName = PasswordProtection.getDecryptedData(dto.getUsername());(1)
		String userId = userDetailsService.getUserId(decryptedUserName);
		// Check if the new scenario set name already exists (case-insensitive)

	    // Check if the new scenario set name already exists (case-insensitive)
	    boolean exists = staticMarketRiskScenarioMasterService
	            .scenarioSetListAtUserStatic(userId) (2)
	            .stream()
	            .anyMatch(name -> name.equalsIgnoreCase(dto.getRenameScenarioSetName()));

	    if (exists) {
	        throw new IllegalArgumentException(Constants.SCENARIO_SET_NAME_ALREADY_EXIST);(3)
	    }		// Perform the rename
		staticMarketRiskScenarioMasterService.riskScenarioSetUpdate(userId, dto.getRenameScenarioSetName(),(4)
				dto.getScenarioSetName());
		// Refresh the scenario list (if this is meant for UI purposes)
		List<String> updatedNames = yieldCurveIdentificationService.getScenarioSetName(userId);(5)
		List<Map<String, String>> formattedScenarioSets = new ArrayList<>();
		for (String setName : updatedNames) {
			String setType = getscenariosetType(setName, userId);
			String formattedName = (setType == null || setType.equalsIgnoreCase(Constants.SWI)) ? Constants.SWI + setName
					: Constants.SMC + setName;                 (6)
			Map<String, String> nameMap = new HashMap<>();
			nameMap.put(Constants.SCENARIO_SET_NAME, formattedName);
			formattedScenarioSets.add(nameMap);
		}
		return formattedScenarioSets; // Rename succeeded  (7)
	}

Internal Workflow:

1 Decrypt the encrypted username from the request DTO to obtain the actual username, then retrieve the corresponding userId.
2 Retrieve the list of existing scenario sets for the user and check if the new name already exists (case-insensitive).
3 If the new name exists, throw IllegalArgumentException.
4 Update the scenario set name in the database using the provided userId, newName, and oldName.
5 Refresh the updated scenario set list (for UI purposes).
6 Reformat each entry with a type prefix (SWI or SMC).
7 Return the formatted list of scenario set names.

3.2.4. Model classes

Description

The RenameStaticScenarioSetRequestDTO class is a Data Transfer Object (DTO) used for renaming an existing static market scenario set. It encapsulates the necessary details to identify the target scenario set, specify the new name, and associate the action with a specific user.

Attributes

  1. scenarioSetName

    • Type: String

    • Description: The current name of the scenario set to be renamed.

    • Example: "InterestRateShockSet"

  2. renameScenarioSetName

    • Type: String

    • Description: The new name to assign to the scenario set.

    • Example: "FX"

  3. username

    • Type: String

    • Description: The username of the person requesting the rename operation (it is encrypted for security).

    • Example: "SDZnRU9yU3pkbEU4M1AwVDJ6UWNhUT09"

{
    "scenarioSetName": "InterestRateShockSet",
    "renameScenarioSetName": "CreditRate",
    "username": "SDZnRU9yU3pkbEU4M1AwVDJ6UWNhUT09"
}

3.2.5. Testing

3.3. Get static scenario set

3.3.1. Sequential flow

get-static-scenario-set.puml

Static Market Scenario Retrieval:

  • User request to the getStaticScenario with scenarioSetName.

  • Controller forwards request to StaticMarketRiskScenarioMasterService.

  • Service fetches (scenarioName, scenarioId) from repository and returns matching scenarioId.

  • Controller calls StaticMarketRiskScenarioDataService with scenarioId.

  • Service builds Map<marketType, List<entries>> from repository data.

  • Response is returned to the user with data.

3.3.2. Endpoint

Description

This endpoint retrieves static market scenario data for a given scenario set.

URL

/getStaticScenario

Method

GET

Request Parameters

Parameters

Type

Required

Description

scenarioSetName

String

Yes

The ID of the scenario set (as a string) whose static market scenario data is to be fetched.

Responses

200 OK:

Returns a map where each key represents a data category, and each value is a list of associated scenario data entries.

Response body

{
"status": 200,
"message": "Success",
"data": [
{
"scenarioName": "FX",
"scenarioId": "743"
}
]
}

403 Forbidden

  • If the user is not authorized to access the scenario data.

500 Internal Server Error

  • If an unexpected error occurs while retrieving the static market scenario information.

3.3.3. Methods

  1. staticRiskFactorMap(int staticScenarioId)

Description

This method retrieves the list of risk factor names and their corresponding scenario IDs for a given static scenario set ID.

Parameters

  • staticScenarioId (int): The scenario set ID used to fetch associated risk factors.

Return type

List<Map<String, String>>: A list of key-value pairs where each entry maps:

  • scenarioName → the name of the risk scenario

  • scenarioId → its corresponding ID (as a String)

Example usage

@Override
public List<Map<String, String>> staticRiskFactorMap(int staticScenarioId) {
List<Map<String, String>> resultList = new ArrayList<>(); (1)
List<Object[]> data = staticMarketRiskScenarioMasterRepository
.findScenarioNameAndIdByScenarioSetId(staticScenarioId); (2)
for (Object[] obj : data) { (3)
String scenarioName = (String) obj[0];
Integer scenarioId = (Integer) obj[1];
Map<String, String> map = new HashMap<>();
map.put(Constants.SCENARIO_NAME, scenarioName);
map.put(Constants.SCENARIO_ID, scenarioId.toString());
resultList.add(map); (4)
}
return resultList; (5)
}

Internal Workflow

1 Initialize an empty list to hold the result.
2 Query the repository to retrieve all scenario names and IDs linked to the given staticScenarioId.
3 Loop through each record in the query result.
4 Create a map for each scenario and add it to the result list.
5 Return the complete list of scenario mappings.

3.3.4. Testing

3.4. Add static scenario

3.4.1. Sequential flow

add-scenario.puml

Static Market Scenario Creation Process:

The user sends a request to the addStaticScenario service with:

  • scenarioSetId

  • scenarioName

  • Encrypted userId

Internal Process:

  • The service decrypts the userId using the PasswordProtection utility.

  • It retrieves the actual user ID using the user details service.

  • It checks whether a scenario with the same name already exists for the given user and scenario set.

If the scenario name does not exist:

  • A new scenario is created and saved under the specified scenario set.

  • The service retrieves all scenario details related to that set.

  • The response includes a list of scenario names and their IDs.

If the scenario name already exists:

  • The service returns an empty list, indicating no new scenario was added.

3.4.2. Endpoint

Description

This endpoint allows users to add a new static market scenario based on the provided data. The scenario is linked to a specific user and scenario set.

URL

/addStaticScenario

Method

POST

Request Body

The request body should contain a JSON object representing the data required to create a new static market scenario. The structure must follow the AddScenarioRequestDto format.

Example Request Body

{
"scenarioSetID": "434",
"userId": "SDZnRU9yU3pkbEU4M1AwVDJ6UWNhUT09",
"scenarioName": "Plus 200BP"
}

Responses:

200 OK: Static market scenario added successfully. Returns a JSON response containing a list of details for the added scenario.

Example Response Body

{
"status": 200,
"message": "SUCCESS",
"data": [
{
"scenarioName": "Minus 100BP",
"scenarioId": "72562"
},
{
"scenarioName":"Plus 200BP",
"scenarioId":"70906"
}
]
}

400 Bad Request: If the input is missing required fields or contains invalid data.

Example

{
"status": 400,
"message": "scenarioSetName must not be null",
"data": null
}

401 Unauthorized: If the user is not authenticated or does not have permission to add scenarios.

500 Server Error: If an internal server error occurs while processing the request.

Example

{
"status": 500,
"message": "Unexpected error occurred while adding the scenario",
"data": null
}

3.4.3. Methods

Description

The method addScenario is responsible for creating a new static market scenario based on the provided scenario request details. It ensures that duplicate scenarios are not created for the same scenario set and user.

Parameters

  • addScenarioRequestDto (AddScenarioRequestDto): An object containing the necessary data required to create a new static market scenario, including the encrypted userId, scenarioSetName, and scenarioName.

Returns

  • List<Map<String, String>>: A list of maps where each map contains scenario-related information such as scenarioId and scenarioName. The list is empty if the scenario already exists.

Example Usage

public List<Map<String, String>> addScenario(AddScenarioRequestDto addScenarioRequestDto) {
String decryptedUserName = PasswordProtection.getDecryptedData(addScenarioRequestDto.getUserId()); (1)
String userId = userDetailsService.getUserId(decryptedUserName);

List<Map<String, String>> list = new ArrayList<>();

boolean validScenarioName = isScenarioNameAlreadyExistsAtScenarioSetAndUser(
    userId,
    Integer.parseInt(addScenarioRequestDto.getScenarioSetName()),
    addScenarioRequestDto.getScenarioName()
); (2)

if (!validScenarioName) {
    StaticMarketRiskScenarioMaster riskScenarioSet = new StaticMarketRiskScenarioMaster();
    riskScenarioSet.setScenarioName(addScenarioRequestDto.getScenarioName());
    riskScenarioSet.setScenarioSetId(Integer.parseInt(addScenarioRequestDto.getScenarioSetName()));

    int savedScenarioId = saveScenarioSetDynamic(riskScenarioSet); (3)

    List<ScenarioProjection> findByScenarioSetId =
        staticMarketRiskScenarioMasterRepository.findByScenarioSetIds(savedScenarioId); (4)

    for (ScenarioProjection sp : findByScenarioSetId) {
        Map<String, String> map = new HashMap<>();
        map.put(Constants.SCENARIO_NAME, sp.getScenarioName());
        map.put(Constants.SCENARIO_ID, String.valueOf(sp.getScenarioId()));
        list.add(map); (5)
    }
}

return list; (6)
}

Internal Workflow:

1 Decrypts the encrypted userId from the request.
2 Validates whether the given scenario name already exists for the scenario set and user.
3 If the name is unique, it creates a new StaticMarketRiskScenarioMaster Object and saves it.
4 Fetches the newly saved scenario(s) using the scenario set ID.
5 Constructs the response list with relevant scenario data.
6 Returns the list, which may be empty if the scenario already existed.

Exceptions

  • No explicit exceptions are thrown by this method.

3.4.4. Model classes

Description

The AddScenarioRequestDto class represents the data transfer object (DTO) used to add a new static market scenario in the system. It captures the essential information needed to associate a specific scenario name with a user and scenario set.

Attributes:

  1. scenarioSetId

    • Type: String

    • Description: The name of the scenario set to which the static market scenario is to be added.

    • Example: "1223"

  2. userId

    • Type: String

    • Description: The identifier of the user creating or owning the scenario.

    • Example: "SDZnRU9yU3pkbEU4M1AwVDJ6UWNhUT09"

  3. scenarioName

    • Type: String

    • Description: The name assigned to the new static market scenario.

    • Example: "Minus200Bp"

Example

{
"scenarioSetId": "1347",
"userId": "SDZnRU9yU3pkbEU4M1AwVDJ6UWNhUT09",
"scenarioName": "Minus 200Bp"
}

3.4.5. Testing

3.5. Rename static scenario

3.5.1. Sequential flow

rename-static-scenario.puml

Static Scenario Rename Process:

  • The user sends scenarioSetName, scenarioName, renameScenarioName, and encrypted userName to the renameStaticScenario endpoint.

  • The service decrypts the username using PasswordProtection.

  • It retrieves the actual userId from UserDetailsRepository via UserDetailsService.

  • It checks in StaticMarketRiskScenarioMasterRepository whether the new scenario name already exists within the same scenario set (case-insensitive).

If the name exists:

  • The method returns an empty list (rename not performed).

If the name does not exist:

  • Retrieves the scenarioId of the current scenario from StaticMarketRiskScenarioMasterRepository.

  • Updates the scenario name in StaticMarketRiskScenarioMasterRepository.

  • Fetches the updated list of scenarios in the scenario set from YieldCurveIdentificationService.

  • Formats the results into a list of maps with scenarioName and scenarioId for UI display.

  • Returns the updated list of scenarios.

3.5.2. Endpoint

Description

This endpoint allows users to rename an existing static market scenario within a specific scenario set by providing the current scenario set name, the existing scenario name, the new desired scenario name, and the requesting user.

URL

/renameStaticScenario

Method

PUT

Request Body

The request body must be a JSON object that adheres to the structure of the RenameStaticScenarioRequestDTO class.

Example Request Body

{
"scenarioSetName": "InterestRateShockSet",
"userName": "SDZnRU9yU3pkbEU4M1AwVDJ6UWNhUT09",
"scenarioName": "InterestRateShockScenario1",
"renameScenarioName": "FXScenario"
}

Responses

200 OK: Static market scenario renamed successfully. Returns the updated list of scenarios under the given scenario set.

Example Response Body

{
"status": 200,
"message": "SUCCESS",
"data": [
          {"scenarioName": "InterestRateShockScenario2"},
          {"scenarioName": "FXScenario1"},
          {"scenarioName": "CommodityScenario1"}
        ]
  }

  • 400 Bad Request:

  • Returned when required fields are missing or invalid in the request payload.

Example

{
  "status": 400,
  "message": "renameScenarioName must not be null",
  "data": null
}

  • 401 Unauthorized:

  • Returned when the user is not authenticated or lacks permission to perform this operation.

  • 500 Internal Server Error:

  • Returned if an unexpected error occurs while processing the request.

Example

{
  "status": 500,
  "message": "Unexpected error occurred while renaming the static scenario",
  "data": null
}

3.5.3. Methods

Description

The method renameStaticScenario is responsible for renaming an existing static market scenario within a specific scenario set for a given user. It ensures that the new scenario name does not already exist within the same scenario set before performing the rename.

Parameters

  • renameStaticScenarioRequestDTO (RenameStaticScenarioRequestDTO): An object containing the scenario set name (as ID), the current scenario name, the new desired scenario name, and the encrypted username of the requesting user.

Returns

List<Map<String, String>>

A formatted list of scenario names for the specified scenario set, where each entry is a map containing scenarioName and its corresponding scenarioId.

Example Usage

@Override
public List<Map<String, String>> renameStaticScenario(RenameStaticScenarioRequestDTO renameStaticScenarioRequestDTO) {

String decryptedUserName = PasswordProtection.getDecryptedData(renameStaticScenarioRequestDTO.getUserName()); (1)
String userId = userDetailsService.getUserId(decryptedUserName);
int scenarioSetId = Integer.parseInt(renameStaticScenarioRequestDTO.getScenarioSetName());

boolean alreadyExists = isScenarioNameAlreadyExistsAtScenarioSetAndUserStatic(
        scenarioSetId,
        renameStaticScenarioRequestDTO.getRenameScenarioName()); (2)

List<Map<String, String>> scenarioList = new ArrayList<>();
if (alreadyExists) {
    return scenarioList; // or return early if rename should not proceed (3)
}

int scenarioId = getScenarioIdDynamic(userId, scenarioSetId, renameStaticScenarioRequestDTO.getScenarioName()).getScenarioId(); (4)

riskScenarioUpdate(scenarioId, renameStaticScenarioRequestDTO.getRenameScenarioName()); (5)

List<Object[]> rawList = yieldCurveIdentificationService.getScenarioNames(scenarioSetId, userId); (6)
for (Object[] obj : rawList) {
    String scenarioName1 = (String) obj[0];
    int scenarioId2 = (Integer) obj[1];
    Map<String, String> hsMap = new HashMap<>();
    hsMap.put(Constants.SCENARIO_NAME, scenarioName1);
    hsMap.put(Constants.SCENARIO_ID, String.valueOf(scenarioId2));
    scenarioList.add(hsMap);
}
return scenarioList; // Return updated list of scenarios (7)

}

Internal Workflow:

1 Decrypt the encrypted username from the request DTO to obtain the actual username, then retrieve the corresponding userId.
2 Check if the new scenario name already exists in the same scenario set for the user.
3 If the new name exists, return an empty list (or abort the operation).
4 Retrieve the scenarioId of the scenario to be renamed using the current name, set, and user.
5 Update the scenario’s name in the database with the new name.
6 Refresh the updated list of scenarios in the given scenario set for the user.
7 Return the list of updated scenarios, each entry containing scenarioName and its associated scenarioId.

3.5.4. Model classes

Description

The RenameStaticScenarioRequestDTO class is a Data Transfer Object (DTO) used for renaming an existing static market scenario within a scenario set. It encapsulates the necessary details to identify the target scenario set, specify the existing scenario, define the new scenario name, and associate the action with a specific user.

Attributes

  1. scenarioSetName

    • Type: String

    • Description: The current name of the scenario set to be renamed.

    • Example: "InterestRateShockSet"

  2. scenarioName

    • Type: String

    • Description: The current name of the static market scenario to be renamed..

    • Example: "FX"

  3. username

    • Type: String

    • Description: The username of the person requesting the rename operation (it is encrypted for security).

    • Example: "SDZnRU9yU3pkbEU4M1AwVDJ6UWNhUT09"

  4. renameScenarioName

    • Type: String

    • Description: The new name to assign to the static market scenario.

    • Example: "FXScenario1"

{
    "scenarioSetName": "InterestRateShockSet",
    "userName": "SDZnRU9yU3pkbEU4M1AwVDJ6UWNhUT09",
    "scenarioName": "InterestRateShockScenario1",
    "renameScenarioName": "FXScenario1"
}

3.5.5. Testing

3.6. Get static scenario

3.6.1. Sequential flow

get-scenarios.puml

Scenario Retrieval Process:

  • The user makes a request to fetch scenarios, supplying the scenarioSetName and userName.

  • User ID retrieval

    • Decrypt userName.

    • Retrieve corresponding userId using UserDetailsService.

  • Scenario Set ID retrieval

    • Fetch staticScenarioId using userId and scenarioSetName.

  • Scenario details retrieval

    • Using the staticScenarioId, retrieve all scenario names and their IDs.

    • Format the result as a list of maps (each containing scenarioName and scenarioId).

  • The controller returns the list of scenarios in the response.

3.6.2. Endpoint

Description

This endpoint retrieves the list of static risk factor names for a given scenario set and user.

URL

/getStaticScenarios

Method

GET

Request Parameters

Parameters

Type

Required

Description

scenarioSetName

String

Yes

The name of the scenario set for which risk factors are to be fetched.

userName

String

Yes

Encrypted username, which used to determine the user ID internally.

Responses

200 OK:

Returns the list of risk factor names (as key-value maps).

Response body

{
"status": 200,
"message": "Success",
"data": [
{
"scenarioName": "FX",
"scenarioId": "743"
}
]
}

403 Forbidden

  • If the user is not authorized to access the scenario data.

500 Internal Server Error

  • If an unexpected error occurs while retrieving the scenario information.

3.6.3. Methods

  1. getScenarioSetId(String userId, String scenarioSetName)

    Description

    This method retrieves the unique scenario set ID based on the user ID and scenario set name.

    Parameters

    • userId (String): The unique identifier for the user.

    • scenarioSetName (String): The name of the scenario set.

      Return type:

      int: Returns the scenario set ID if found; otherwise, returns 0.

      Example usage

      @Override
public int getScenarioSetId(String userId, String scenarioSetName) {
Integer id = staticMarketRiskScenarioSetMasterRepository
.findIdByUserIdAndRiskScenarioSetName(userId, scenarioSetName); (1)
return id != null ? id : 0; (2)
}

      Internal Workflow

      1 Query the repository to fetch the scenario set ID for the provided userId and scenarioSetName.
      2 Return the ID if it’s found; if the result is null, return 0.

  2. staticScenarioRiskFactorMap(int staticScenarioId)

    Description

    This method retrieves the list of risk factor names and their corresponding scenario IDs for a given static scenario set ID.

    Parameters

    • staticScenarioId (int): The scenario set ID used to fetch associated risk factors.

      Return type

      List<Map<String, String>>: A list of key-value pairs where each entry maps:

    • scenarioName → the name of the risk scenario

    • scenarioId → its corresponding ID (as a String)

      Example usage

    @Override
public List<Map<String, String>> staticScenarioRiskFactorMap(int staticScenarioId) {
List<Map<String, String>> resultList = new ArrayList<>(); (1)
List<Object[]> data = staticMarketRiskScenarioMasterRepository
.findScenarioNameAndIdByScenarioSetId(staticScenarioId); (2)
for (Object[] obj : data) { (3)
String scenarioName = (String) obj[0];
Integer scenarioId = (Integer) obj[1];
Map<String, String> map = new HashMap<>();
map.put(Constants.SCENARIO_NAME, scenarioName);
map.put(Constants.SCENARIO_ID, scenarioId.toString());
resultList.add(map); (4)
}
return resultList; (5)
}

Internal Workflow

1 Initialize an empty list to hold the result.
2 Fetch the repository to retrieve all scenario names and IDs linked to the given staticScenarioId.
3 Loop through each record in the result.
4 Create a Map<String, String> for each scenario and add it to the result list.
5 Return the full list of scenario mappings.

3.6.4. Testing

Credit Scenario

1. Introduction

Within the credit risk scenario module it is possible to stress or shock the

  • Rating of the counter parties

  • Recovery rates of the counter parties

2. Tables and relations

Establishing relationships

  • In relational databases like SQL, relationships between tables are crucial for organizing and querying data effectively. These relationships are typically established using foreign key constraints, which define links between tables based on the values of specific columns. Common types of relationships include one-to-one, one-to-many and many-to-many relationships, each serving different data modeling needs.

3. CreditScenarioController

3.1. create scenario

Behavior Scenario

1. Introduction

  • Behavior covers the risk category where financial contracts are affected by external shocks. In other words, these are changes to the financial contracts outside the contractual agreements.

The most important categories are:

Drawing behavior in current and saving accounts:

  • Such accounts typically do not have set terms which define when the outstanding amount can be reduced or increased. In general the account holder is at liberty to do so at any point in time.

Prepayments:

  • Mortgages do have in many countries an explicit option to prepay. Mortgage holders however, do in general not exercise such options optimally. For this reason, these options have to be modelled following statistically observed behavior.

  • Within the behavior scenario module, it is possible to exercise such behavior. New behavior patterns may appear such as the enforcement of moratorium by governments. The ACTUS algorithm allows the new definition of such behaviors, they however, have to be implemented which takes time.

2. Tables and relations

Establishing relationships

  • In relational databases like SQL, relationships between tables are crucial for organizing and querying data effectively. These relationships are typically established using foreign key constraints, which define links between tables based on the values of specific columns. Common types of relationships include one-to-one, one-to-many and many-to-many relationships, each serving different data modeling needs.

3. BehaviourScenarioController

3.1. Create behaviour scenario

Operational Strategy

1. Introduction

  • It is again used only in the context of dynamic simulation. An operational strategy set represents a collection of instructions for specific nodes in the balance sheet structure, detailing how much (e.g., dollar amount or quantity) and what types (e.g., investments or quantity-units) of operational business should be generated over time. A collection of these instructions is called a Strategy. The collaboration of such Strategies constitutes a Strategy Set. An arbitrary number of Strategies can exist and are stored in external Spreadsheets. The operational strategy module integrates via an Excel interface, allowing users to import an Excel sheet (i.e., a Strategy Set) and use these values for dynamic simulation.

2. Tables and relations

Establishing relationships

  • In relational databases like SQL, relationships between tables are crucial for organizing and querying data effectively. These relationships are typically established using foreign key constraints, which define links between tables based on the values of specific columns. Common types of relationships include one-to-one, one-to-many and many-to-many relationships, each serving different data modeling needs.

3. OperationalStrategyController

3.1. Create strategy

Financial Strategy

1. Introduction

  • It is used only in the context of dynamic simulation. A financial strategy provides instructions to the balance sheet structure on the amount (e.g., notional amount) and types (e.g., financial contracts) of business to be generated over time. A collection of these instructions is called a Strategy. The collaboration of such Strategies constitutes a Strategy Set. An arbitrary number of Strategies can exist and are stored in the database.

2. Tables and relations

Establishing relationships

  • In relational databases like SQL, relationships between tables are crucial for organizing and querying data effectively. These relationships are typically established using foreign key constraints, which define links between tables based on the values of specific columns. Common types of relationships include one-to-one, one-to-many and many-to-many relationships, each serving different data modeling needs.

3. FinancialStrategyController

3.1. Create strategy

3.2. Update strategy

3.3. Get strategy

Model Builder

1. Introduction

  • In the model and solve , different types of simulations can be performed. A simulation is conducted based on a specific combination of the objects defined in the modules.

There are five generic types of models, each requiring different inputs:

Canonical

Input parameters: Analysis date ,time definition and tree structure ( balance sheet ,portfolio,counter party)

Output results : Values (nominal ,fair, IFRS, LGAAP, accrued),liquidity ( marginal,cumulative),rate-reset gap and duration&convexity

Static What-if

Input parameters: Analysis date ,time definition , tree structure ( balance sheet ,portfolio,counter party) and market ,behavior and credit scenarios.

Output results : Values (nominal ,fair, IFRS, LGAAP, accrued),liquidity ( marginal,cumulative) and rate-reset gap.

Static montecarlo

Input parameters: Analysis date ,time definition , tree structure ( balance sheet ,portfolio,counter party) and market ,behavior and credit risk scenarios.

Output results : Values (nominal ,fair, IFRS, LGAAP

Dynamic What-if

Input parameters: Analysis date ,time definition , tree structure ( balance sheet ,portfolio,counter party) and market ,credit,financial and operational strategies.

Output results: Values (nominal ,fair, IFRS, LGAAP, accrued),income,liquidity and cashflow

Dynamic montecarlo

Input parameters: Analysis date ,time definition , tree structure ( balance sheet ,portfolio,counter party) and market ,credit,financial and operational strategies.

Output results: Values (nominal ,fair, IFRS, LGAAP, accrued),income,liquidity ,cashflow and Summary Statistics.

2. Tables and relations

Establishing relationships

  • In relational databases like SQL, relationships between tables are crucial for organizing and querying data effectively. These relationships are typically established using foreign key constraints, which define links between tables based on the values of specific columns. Common types of relationships include one-to-one, one-to-many and many-to-many relationships, each serving different data modeling needs.

3. SolveController

3.1. Save static analysis

3.2. Solve report

3.3. Save dynamic analysis

3.4. Dynamic what if model data

Solve and Reports

1. Introduction

2. Tables and relations

Establishing relationships

  • In relational databases like SQL, relationships between tables are crucial for organizing and querying data effectively. These relationships are typically established using foreign key constraints, which define links between tables based on the values of specific columns. Common types of relationships include one-to-one, one-to-many and many-to-many relationships, each serving different data modeling needs.

3. SolveandReportsController

3.1. Run static solve