Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Key Principles

Principle

Decision / Discussion

Status

Scope is Portfolio

  • the interface should always deliver data on the scope of a single portfolio

  • the interface delivers key figures also on portfolio level (no aggregation needed)

SPECIFIED

Benchmark Data

  • benchmark data is inherently delivered as part of the analysis (see figures)

SPECIFIED

Models & Figures

  • the risk model can be chosen / setup on Aladdin side while the reporting engine is flexible towards new models as well as the number of figures and their effects

  • aggregation of figures as with Valuation

  • decomposition of figures with effects → see CSAM Data Hub - Figures

SPECIFIED

Aggregation of instruments / segments

  • The reporting engine should be flexible to aggregate risk effects from instrument level to segment level

OUT OF SCOPE


Interface "PortfolioRiskExPost"

Status

IMPLEMENTED

Usage & contents

  • used to produce PO006, PO006C, CO001, RA001..RA003

  • Ex-post portfolio level risk figures for multiple periods.

  • The risk figures will only be delivered on a monthly basis, so calls for a reportingDate within a month will typically deliver risk figures for periods ending at the ultimo of the previous month.

Path

/portfolio/riskexpost

Parameters

portfolioId

string

The id of the portfolio (or consolidation) in the data source

reportingDate

string (date)

The date, the reporing is produced for.

Example call

/portfolio/riskexpost?portfolioId=E0002&reportingDate=2019-03-31

Response structure

If the API can fulfill the request (response status code 200 = OK) the response must follow the below json-schema.

  • The request part of the response has to match the path and parameters used in the API call/request

  • The json schema currently excludes the schemas for dataVersioning (should be designed by CSAM) as well as segmentations (will be defined separately)

Schema

https://bitbucket.org/banknotes/ngr/src/df61b39d18a16581cd95aed9694991bbe39c5fb1/ngr-csamsolution/src/Model/schema/PortfolioRiskExPost.schema.json?at=release%2Fcurrent

Error handling

If the request can't be fulfilled an appropriate response status code (4xx or 5xx) must be used. Possible errors could be

  • bad request structure → expected status = 400

  • portfolioId not found or reportingDate in future → expected status = 404

  • etc.

The body of the response should contain information about the reason of the error in plain text or as json object.

Consistency rules

The following rules should be adhered to by any response and will eventually be checked when consuming a response:

Consistency Rules
* All figures used within a risk object should be defined in the figures declaration
* All risk objects have to name a period that ends earlier than or at the reportingDate
* All end dates of risk object periods have to be the same and have to be a month's ultimo date

Reporting business logic

  • aggregation of figures / effects

  • detection of available periods in result

  • top n, filtering, sorting

Potential problems

  • As the ex-post figures are calculated on Aladdin side, no arbitrary periods are possible

Interface "PortfolioRiskExAnte"

Status

IMPLEMENTED

Usage & contents

used to produce

  • RA001, RA003

  • RA006..RA008

  • CO001 (some metrics)

Contents

  • Ex-ante portfolio level risk figures for a given date and predefined time horizons

  • This interface will include the previousely used interface PortfolioRiskDecompositions

Path

/portfolio/riskexante

Parameters

portfolioId

string

The id of the portfolio (or consolidation) in the data source

reportingDate

string (date)

The date, the reporing is produced for.

Example call

/portfolio/riskexante?portfolioId=E0002&reportingDate=2019-03-31

Response structure

If the API can fulfill the request (response status code 200 = OK) the response must follow the below json-schema.

  • The request part of the response has to match the path and parameters used in the API call/request

  • The json schema currently excludes the schemas for dataVersioning (should be designed by CSAM) as well as segmentations (will be defined separately)

Schema

https://bitbucket.org/banknotes/ngr/src/df61b39d18a16581cd95aed9694991bbe39c5fb1/ngr-csamsolution/src/Model/schema/PortfolioRiskExAnte.schema.json?at=release%2Fcurrent

Error handling

If the request can't be fulfilled an appropriate response status code (4xx or 5xx) must be used. Possible errors could be

  • bad request structure → expected status = 400

  • portfolioId not found or reportingDate in future → expected status = 404

  • etc.

The body of the response should contain information about the reason of the error in plain text or as json object.

Consistency rules

The following rules should be adhered to by any response and will eventually be checked when consuming a response:

Consistency Rules
* All figures used within a risk object should be defined in the figures declaration
* All risk objects have the same referenceDate
* The referenceDate is not later than the reportingDate
* A model referenced in a risk object has to be declared under models
* Every effect used within a risk object has to be a declared effect of the referenced model
* Every effect declared within a model has to be also declared as figure
* All effects of a model having effectAggregation = sum should sum up to the value of the figure they explain


Reporting business logic

  • aggregation of figures / effects

  • filtering, sorting

Potential problems



Interface "PortfolioRiskStatus"

Status

IMPLEMENTED

Usage & contents

used to produce cover overviews

Path

/portfolio/riskstatus

Example call

/portfolio/riskstatus?portfolioId=E0002&reportingDate=2019-03-31

Response structure

"riskstatus": {
    "calcDate": "2019-03-31",
    "statusText": "moderate",
    "performanceHistoryMonths": 97,
    "SRRI": 3,
    "SRI": 2
}

where

  • calcDate and statusText are mandatory

  • any other attributes are only for data lineage reasons (not to be interpreted for reporting)

Schema

https://bitbucket.org/banknotes/ngr/src/df61b39d18a16581cd95aed9694991bbe39c5fb1/ngr-csamsolution/src/Model/schema/PortfolioRiskStatus.schema.json?at=release%2Fcurrent

Error handling

  • If retrieving the risk status fails, an error is produced

  • If the retrieved risk status is none, the risk gauge is shown without any active segment

Parameters

  • portfolioId

  • reportingDate

Consistency rules

  • Calculation date must not be newer than reporting date

Reporting business logic

none

Example


Potential problems



  • No labels