Skip to end of metadata
Go to start of metadata
Key Principles
Principle | Decision / Discussion |
---|
Flexible aggregation over time | |
Scope one Portfolio | |
Benchmark Data | |
Frequency | |
Calendar Days | |
Period Definitions | |
Return Types | Gross: return without portfolio level fees (but including transaction fees) Net: return including portfolio level fees BM: return of the benchmark Other return types (secondary benchmark, other flavours of fee recognition)
|
Completeness & Ultimo-Data | Daily return data can have gaps (e.g. weekends) but there should be no daily return entry without both gross/net values. Monthly data have are interpreted to be valid for the calendar ultimo of the month Daily data does not have to be artificially completed with a month end record (so March 31st can be missing in daily if this was a weekend) If an order requests data for a period before the performanceMeasurementStartDate) no valid response should be returned If an order requests data for a period reaching into the future (with respect to the most current data available) no valid response should be returned As the end of the performance history of a portfolio is (currently) not defined in masterdata, all month till the endDate are expected to be contained in the response
|
Incomplete month periods | If a portfolio starts it's performance history in the middle of a month, the initial index value is interpreted for the performanceMeasurementStartDate If the endDate of a request lies in the middle of a month, the last daily index value previous to the endDate is interpreted (the endDate can be missing in the daily records)
|
Interface "PortfolioReturns"
Usage & Contents | |
---|
Reporting Business Logic | cumulation over time (monthly → quarterly, YTD, ITD etc.) or rather de-cumulating index values to monhtly / quarterly returns alignment of data frequencies (monthly ITD history with daily for more current periods) relative return calculation for different return types formatting of returns (in %, in bps)
|
---|
Consistency Rules | The following rules should be adhered to by any response and will be checked when consuming a response: |
---|
Path | /portfolio/returns
|
---|
Parameters | portfolioId *
| string | The id of the portfolio (or consolidation) in the data source |
---|
startDate *
| string (date) | The start date of the period for which return data is requested |
---|
endDate *
| string (date) | The end date of the period for which return data is requested |
---|
includeDailyReturns
| boolean (default: false) | Response to include daily return data (where available) |
---|
includeBenchmark
| boolean (default: false) | Response to include benchmark return data |
---|
customBenchmarkId
| string | parameter to query data of the portfolio measured against another benchmark |
---|
Example call | /portfolio/returns?portfolioId=E0002&startDate=2011-04-01&endDate=2019-03-31
|
---|
Schema | |
---|
Example | |
---|
Interface "InstrumentReturns"
Usage & Contents | |
---|
Reporting Business Logic | |
---|
Consistency rules | |
---|
Path | /instrument/returns
|
---|
Parameters | startDate
| string (date) | The start date the reporting is produced for |
---|
endDate
| string (date) | The end date the reporting is produced for |
---|
instrumentIds
| string[] | The list of instruments the return series should be generated |
---|
includeDailyReturns
| boolean (default: false) | Response to include daily return data (where available) |
---|
Example call | /instrument/returns?startDate=2019-01-01&endDate=2019-03-31&instrumentIds=FTSEEUR,SWIIT,SF0003M
|
---|
Schema | |
---|
Example | |
---|
0 Comments