Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Key Principles

Principle

Decision / Discussion

Status

Figures

  • the number and types of figures to be reported should be flexible (MarketValue, Duration, etc.) 

  • while some figures can be aggregated by simple summing up, other figures have a specific "aggregation weight" to be used when aggregating

  • for details see Cinnamon Data Interface - Figures

(Breakdown) Segments

  • should be included in a flexible manner

  • translations to be done in reporting via the translation dictionary

  • breakdown hierarchies are delivered by the separate interface Cinnamon Data Interface - Segmentations

Aggregation

  • The reporting engine should be flexible to aggregate positions from instrument level to any segment level (never to portfolio level)

Status
colourGreen
titleSpecified

Scope is Portfolio

  • the interface should always deliver data on the scope of a single portfolio (or benchmark)

  • the interface delivers key figures also on aggregated level (portfolio or benchmark)

Status
colourGreen
titleSpecified

Unbundling / Legs

  • All unbundling positions have to be provided with all figures (e.g. weights) prepared to be directly included in the overall analysis (replacing the figures of the originating position).

  • Unbundling support three different concepts

    • Constituents: a constituent (like a position of a fund held in the portfolio) is assumed to be a different financial instrument and therefore should provide all needed segments and details for the position. The original position is completely replaced.

    • Legs: derivative instruments (e.g. FX forwards) can be unbundled into two or more legs that can have differing segments and details from the original position. Currently they are handeled identically to constituents.

    • Lots: a position considered a lot, is assumed to stem from the same financial instrument as the original position so only detailing the position with some respect. Therefore the segments as well as details are inherited from the original position but can be overwritten in the lot.

  • When unbundling positions, the following precedence is taken

    • 1. Constituents

      • A constituents of a fund can still have legs and lots

    • 2. Legs

      • Only interpreted if there are no constituents

      • A leg can still have lots

    • 3. Lots

      • Only interpreted if there are neither constituents nor legs.

Will always be interpreted → should be replaced with a full position concept

Status
colourGreen
titleSpecified

Benchmark Data

  • the structures of benchmark constituent positions should be same to portfolio positions (so

even
  • a portfolio can be used as benchmarks)

Status
colourGreen
titleSpecified

Breakdown Segments

should be included in a flexible manner
  • translations to be done in the translation dictionary

  • breakdown hierarchies are delivered by the separate interface CSAM Data Hub - Segmentations

  • Status
    colourGreen
    titleSpecified

    Figures

    • the number and types of figures to be reported should be flexible (MarketValue, Duration, etc.) 

    • while some figures can be aggregated by simple summing up, other figures have a specific "aggregation weight" to be used when aggregating

    • for details see CSAM Data Hub - Figures

    Status
    colourGreen
    titleSpecified

    Interface "PortfolioValuation"

    ...

    Status

    ...

    Greentitleimplemented

    Usage & Contents

    used to produce

    • Asset Breakdowns (e.g. AB001-AB007)

    • Asset Structures (e.g. AS003, AS004)

    • Position Lists (e.g. PL001, PL002)

    contains

    • portfolio level key figures (marketValue, duration etc.)

    • instrument level position for portfolio

    Path

    /portfolio/valuation

    Parameters

    portfolioId*

    string

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

    reportingDate*

    string (date)

    The business date the valuations are queried for.

    segmentationDate

    string (date)

    Date as of the instruments are segmented and the segmentation definition is valid (equals reportingDate if omitted)

    Example call

    /portfolio/valuation?portfolioId=E0002&reporting=2019-03-31&segmentationDate=2019-06-30

    Response structure

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

    Note
    • 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 schema for dataVersioning (should be designed by CSAM)

    Schema

    https://bitbucket.org/banknotes/ngr/src/df61b39d18a16581cd95aed9694991bbe39c5fb1/ngr-csamsolution/src/Model/schema/PortfolioValuation.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.

    Reporting Business Logic

    • aggregation from position to sector/portfolio level of simple and weighted figures

    • top n / bottom n, filtering, sorting

    • build hierarchical view from segment data

    • translation of segment labels

    Consistency Rules

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

    Consistency Rules
    code
    languagejs
    *
    • [P01]

    • All

    • figures

    • used

    • within

    • a

    • valuation

    • object

    • must

    • be

    • defined

    • in

    • the

    • figures

    declaration * All figures having an aggregationMethod <> none have to match the top level figure value when aggregating up the positions * [P02] All segmentationIds referenced within positions must be defined in the Segmentations call * [P03] All segmentIds referenced within positions must be defined under the corresponding segmentation in the Segmentations call * All segmentIds referenced within positions must be "leaf-level" segments within the segmentation (no more child segments)

    Reporting Business Logic

    • aggregation from position to sector/portfolio level of simple and weighted figures

    • top n / bottom n, filtering, sorting

    • build hierarchical view from segment data

    • translation of segment labels

    Interface "BenchmarkValuation"

    Status

    Status
    colourGreen
    titleimplemented

    Usage & Contents

    used to produce

    • Asset Breakdowns AB001-AB007

    • Asset Structures AS003, AS004

    contains

    • benchmark level key figures (duration etc.)

    • instrument level position for benchmark

    Path

    /benchmark/valuation

    Parameters

    benchmarkId
    • declaration

    • [P02] All figures having an aggregationMethod <> none have to match the top level figure value when aggregating up the positions

    • [P03] All segmentationIds referenced within positions must be defined in the Segmentations call

    • [P04] All segmentIds referenced within positions must be defined under the corresponding segmentation in the Segmentations call

    • [P05] All segmentIds referenced within positions must be "leaf-level" segments within the segmentation (no more child segments)

    Path

    /portfolio/valuation

    Parameters

    portfolioId*

    string

    The id of the

    benchmark

    portfolio (or consolidation) in the data source

    reportingDate*

    string (date)

    The business date the valuations are queried for.

    segmentationDate

    string (date)

    Date as of the instruments are segmented and the segmentation definition is valid (equals reportingDate if omitted)

    Example call

    /

    benchmark

    portfolio/valuation?

    benchmarkId

    portfolioId=

    B0002

    E0002&reportingDate=2019-03-31&segmentationDate=2019-06-30

    Response structure

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

    Note
  • 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 schema for dataVersioning (should be designed by CSAM)

  • Schema

    https://bitbucket.org/banknotes/ngr/src/df61b39d18a16581cd95aed9694991bbe39c5fb1/ngr-csamsolution/src/Model/schema/BenchmarkValuation.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

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

    Schema

    Status
    titleon request

    Response

    Status
    titleon request

    Interface "BenchmarkValuation"

    Usage & Contents

    used to produce

    • Asset Breakdowns AB001-AB007

    • Asset Structures AS003, AS004

    contains

    • benchmark level key figures (duration etc.)

    • instrument level position for benchmark

    Reporting Business Logic

    • for comparison with portfolio all same logic needed as stated under PortfolioValuation

    Consistency Rules

    The following rules should be adhered to by any response and will

    eventually

    be checked when consuming a response:

    Consistency Rules
    Code Block
    languagejs
    *
    • [B01]

    • All

    • figures

    • used

    • within

    • a

    • valuation

    • object

    • must

    • be

    • defined

    • in

    • the

    • figures

    • declaration

    *
    • All

    • figures

    • having

    • an

    • aggregationMethod

    • <>

    • none

    • have

    • to

    • match

    • the

    • top

    • level

    • figure

    • value

    • when

    • aggregating

    • up

    • the

    • positions

    *
    • [B02]

    • All

    • segmentationIds

    • referenced

    • within

    • positions

    • must

    • be

    • defined

    • in

    • the

    • Segmentations

    • call

    *
    • [B03]

    • All

    • segmentIds

    • referenced

    • within

    • positions

    • must

    • be

    • defined

    • under

    • the

    • corresponding

    • segmentation

    • in

    • the

    • Segmentations

    • call

    *
    • All

    • segmentIds

    • referenced

    • within

    • positions

    • must

    • be

    • "leaf-level"

    • segments

    • within

    • the

    • segmentation

    • (no

    • more

    • child

    segments)

    Reporting Business Logic

    for comparison with portfolio all same logic needed as stated under PortfolioValuation
    • segments)

    Path

    /benchmark/valuation

    Parameters

    benchmarkId*

    string

    The id of the benchmark in the data source

    reportingDate*

    string (date)


    segmentationDate

    string (date)


    Example call

    /benchmark/valuation?benchmarkId=B0002&reportingDate=2019-03-31&segmentationDate=2019-06-30

    Schema

    Status
    titleon request

    Response

    Status
    titleon request