Versions Compared

Key

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

...

Info

This page tree gives an overview about Cinnamon’s (current) interface for data consumption

The following data interfaces are proposed to allow for the production of full-fledged fund and mandate reports.

Interfaces Overview

Interface

Usage

PortfolioMasterData

To control the contents of a mandate report, several master data points are needed (valid at the given reporting data):

  • client / portfolio / pm name

  • mandate / performance start dates

  • benchmark / strategy definition

  • etc.

PortfolioFundData

  • Additional master data for funds (e.g. sales registrations, shareclasses, cost transparency, etc.)

PortfolioValuation

Interface to deliver portfolio valuation data (valid at the reporting date) to produce:

  • asset allocation breakdowns along several segmentations

  • position lists (full, top-n) with details like CUSIP, ISIN, Valor, Instrument Name etc. 

BenchmarkValuation

Interface to deliver benchmark valuation data (valid at the reporting date) to produce:

  • asset allocation breakdowns along several segmentations

  • comparison of portfolio weights to benchmark weights 

PortfolioReturns

One or multiple interfaces to deliver performance / return data:

  • for a given period

  • for the portfolio as well as the associated / chosen benchmark

  • on portfolio level vs. on segment / instrument level

PortfolioAttributions

Interfaces that return data about the source and decomposition of performance.

PortfolioRiskExPost

Ex post risk figures

PortfolioRiskExAnte

Interface that return data about the ex-ante risk and risk decomposition of the portfolio.

PortfolioRiskStatus

  • the portfolios current risk status (CSAM specific calculation based on past returns)

PortfolioProfitLoss

P&L figures on portfolio level

PortfolioTransactions

List of transactions

PortfolioProjectedCashflows

Projected Cashflows

PortfolioGuidelineAnalysis

  • information about guideline checking (BVV2, investment restrictions) etc.

InstrumentReturns

Returns for a list of instruments and for a given period

Segmentations

Interface to fetch all base segmentations from the DWH

Data availability, quality & security

Interfaces to support a data-driven report production and allow transparency of data quality within reports, e.g.

  • get list of portfolios with their last status per quality level (unpublished vs. signed-off)

  • get lists of portfolios to be authorised for local reporting specialists (e.g. SG-based)


Technological Aspects

Aspect

Proposal

Discussion

Structured Files

Json (or XML)

  • Wherever adding to the understandability of data, structuring should be used

  • Examples are

    • Flexible number of breakdown segments should not be deliverd as normal tags but listed by abstract <segment> tag

    • Flexible numbers of measures

    • Flexible number of legs, unbundling instruments

    • Groups of fields that can be reused between portfolio and benchmark data or between calls

    • etc.

Data format

Json

  • Json is more compact then XML and most easily consumed at reporting engine side

  • We can also consume XML

  • please only use JavaScript compatible identifiers (e.g. no "-")

  • XML can be converted in NodeJS to JSON using camaro

Request & Parameters

mirrored in response

  • The full API request is mirrored in the response including:

    • The path

    • All parameters passed

Network Protocol

HTTP / restful API

  • Standard technology to communicate between services

  • could also send XQuery execution but this would bring data hub technical design dependency to the report engine

Compression

gzip

  • body of reply should be compressed

Paging

no paging

  • While many UI-oriented rest-interfaces do paging, we don't propose paging because

    • a batch reporting mechanism can't work without the complete response (some responses like valuations are hierarchical by nature)

    • Cinnamon has proven to work even with large response sizes (~1GB)

Interface Versioning

/v1
/v2
/LATEST

  • we propose to have only major versioning in the URL (minor versions should be neutral to clients by definition)

  • we propose to add a /LATEST version

Security

certificates

  • The Cinnamon server will authenticate itself to the data source by a server certificate (other methods on request)

Data Versioning

open

  • Additional metadata should be added to the result that uniquely depict the timestamp/version of the data (for data lineage reasons)

  • The report engine will not consider this information in process the data (e.g. business logic)

...