> ## Documentation Index > Fetch the complete documentation index at: https://docs.activeviam.com/llms.txt > Use this file to discover all available pages before exploring further. # Creating DRC P&L export const productName = "Atoti FRTB"; One of the components to the IMA Capital charge is the IMA Default Risk Charge (DRC). The DRC Calculation is a VaR calculation at 99.9% over a year horizon. The section outlines ETL (extract, transform and load processes) involved in the {productName} IMA approach to the DRC PnL creation. In general, {productName} calculates the DRC PnL at a non-securitized trades tuple publish. For details of the CSV files referenced in this section, see the IMA Input File Formats in the [FRTB Input File Formats](../../../input-files/index) documentation. ## Linear PnL Loading ### Scenario Association With Trades A scenario is associated with a trade only if the AsOfDate, the ObligorID and the Seniority are all the same. This also means scenarios for each day of trading should be loaded prior to the first trade loaded for that day. ### DataLoad At file initialization, the "DRC\_SCENARIOS\_COUNT\*.csv" and the "DRC\_LINEAR\_SCENARIOS\*.csv" files will be extracted, published and loaded first with all of the scenarios being stored in the "DRCScenarios" and the "DRC\_SCENARIO\_COUNT" datastores. Trades stored in "DRC\_Trade\_\*.csv" files will then be processed next. This ordering is important for the PnL calculation to be correct as our PnL length will be determined by the amount of scenarios that exist at trade publish time. When ETL is done live both scenario files and trade files can be loaded though their ordering can cause different behaviors. If trades are published before any scenarios are defined for that trade, the trade will be accepted but the DRC PnL will be interpolated as an empty vector. ##### PnL Length As "DRC\_SCENARIOS\_COUNT\*.csv" are published, on the ETL layer, a cache is populated and updated for PnL sizes. PnL sizes are keyed by the dates associated to them. The cache itself is implemented as a Concurrent Sorted/Navigable Java Map where the keys will be sorted concurrently. This gives PnL loading the advantage of quickly querying the most recent date defined for the PnLs associated date and getting the appropriate PnL count. ### Calculation After the scenarios have been loaded then every trade file, that is subsequently extracted, at publish time will calculate the PnLs of that trade by querying the "DRCScenarios" Store and the Scenarios Count cache. #### PnL Values First the Scenarios Count cache is queried for the most recently defined scenario count for the given trades date. If a count is found then the PnL size will be initialized to that count. If a count is not found the PnL size defaults to 0 instead and the PnL will be a empty vector. After the PnL size is determined a query on the "DRCScenarios" store is done to get all the scenarios associated with the trade based on the trade's asOfDate, obligorID, and seniority. Once a scenarios result is queried each scenario in that result set will be used to calculate the PnL along with the trades Recovery Value and Recovery Rate. Once the calculation is complete the Scenario\_ID from the scenario is used as the index to store the PnL value in the PnL vector. For each scenario ID, one of the following calculations is used based on certain conditions and priorities. #### Conditions ##### Condition 1 - Scenario ID exceeds the PnL size. This condition has the highest priority. If the scenario ID of the scenario exceeds the scenario count found then the scenario can not be used to populate the vector. This is assumed to be bad data. No further calculation is done and a warning is logged indicating the scenario was not added. ##### Condition 2 - Premature Default Date This condition has a higher priority then 3, 4, or 5. A check is performed for the scenario to see if the scenario's default date is less then the maturity date of the non-securitized trade. If the trade matures on or before the default date the pnl value is 0. ##### Condition 3 - Multiple Recovery Rates If there is more then 1 recovery rate for a trade then the normal linear interpolation calculation for the PnL value is as follows: ``` Lower Recovery Value + (( Scenario Recovery Rate - Lower Recovery Rate ) * ( Upper Recovery Value - Lower Recovery Value ) / ( Upper Recovery Rate - Lower Recovery Rate )) = PnL Value ``` The scenarioRate comes from the DRCScenarios table for the scenario ID we are finding the PnL for.\ \* The lower and upper rates/values are found in the IMABaseTable based on the rate where the lowerRate is lower then the scenarioRate and\ \* similarly the upper rate is higher then the scenarioRate. If none are found the scenario is calculated as 0. ##### Condition 4 - Single Recovery Rate If the default date is mature and there is only one rate in the IMA table and the scenario rate is greater then that recovery rate then the PnL defaults to that rates recovery value. ##### Condition 5 - No Recovery Rates If the default date is mature and there is no recovery rate for a non-securitized trade the PnL value defaults to 0. ## Non-Linear PnL Loading Exceptional Trades that do not use the linear methodology for creating their PnLs will need to populate the "DRC\_SCENARIO\_COUNT" datastore before publishing the NonLinear PnL trades. At tuple publish time the vector will be initialized to the scenario\_count of the most recent date from the scenarios count cache. If no count is found for the date of the trade the PnL vector defaults to zero. After the vector is initialized, each scenario\_id will be populated with the corresponding value in the PnL provided in the initial tuple. Like with Linear PnL loading, if a scenario ID found in the tuple exceeds the scenario count used for initializing the PnL vector then it is ignored and a warning is logged. This is assumed to be bad data. ## Limitations ### Only Supports Initial Scenarios Because PnL calculations heavily rely on the entire state of the Scenarios Datastore the current implementation does not support users adding more scenarios throughout the day. Only the scenarios that are initially loaded in the day are guaranteed to be used for the PnL calculations. After the initial load of the DRC\_Scenarios store and the first trade is loaded expect the following behavior: * If a new scenarios file is added with new scenarios for a day, it will not update the previously calculated PnLs. * If a new scenario count file is added with a new scenario count for a day, it will not update the previously calculated PnLs. Additional trades could still be processed with the new scenarios added though potentially with inconsistent PnLs compared to previously calculated trades. We highly suggest not adding new scenarios once the first trade has been processed for a given day. ### Recovery If at any point interpolation fails because of a bad scenario count, scenario id value or other issue recovery could still be possible though limited. If only a few trades are affected, you might want to remove those non-securitized trades from the datastore using the DSViewer and reload them after changes are made to correct the underlying interpolation issue. Alternatively if a significant amount of trades are affected then restarting {productName} may be more efficient than directly using the DSViewer. ### No What-If Support What-If support is also not available as the current implementation is done only in the ETL layer. If you wish to perform What-If changes on PnLs you will have to directly modify the Scenario\_Recovery\_Rates field in the DRCIMABaseStore as no PnL interpolation will occur when any other fields are updated. Updating the Scenario\_Count with the DSViewer is also not supported as the scenario count cache used on the ETL layer will only update with ETL changes to the "DRC\_SCENARIOS\_COUNT" store. Instead, for changes to the scenario count, please add a new file with the update on the ETL layer.