View ex-post costs and charges
Overview
Report showing breakdown of realized costs and charges on the portfolio according to the ESMA classification: One-off charges, Ongoing charges, Transaction charges, Ancillary services, Incidental costs, third-party payments and other costs. Costs and charges are grouped by Investment services, Financial Instruments and Total costs and charges. In addition, the report shows the return of the portfolio (TWR) before and after costs and charges.
The report requires that all the applicable transaction and costs types are categorized according to ESMA classifications, and that securities have ex-post costs defined.
Getting started
Categorize you cost transactions and define ex-post costs
 |
 |
Ex-post figures in FA
Figures in Analytics+
The figures are available via Analytics+, and are based on ex-post-cost categorization.
Column | Description | Data source |
|---|---|---|
%-figures for charges (top table) | Fee in question / (Average portfolio market value during given time period + total ex-post costs) We are comparing to a gross portfolio value rather than a net value, because comparing to a net value would lead to misleading results in extreme cases. It might be slightly more correct to compare to an average gross portfolio value, but we don't have that kind of figure available. | |
Gross and net return (bottom table) | Gross and net TWR. Note, that this will usually not exactly match the percentage figures in the top table, because TWR is not the same as a simple return! | |
Other costs (currency) | Sum of other costs 1-5 | |
Other costs (percent) | Sum of other costs 1-5 / (Average portfolio market value during given time period + total costs) = Other costs percentage of gross portfolio value. | |
Total costs and charges -columns | Sum of the corresponding Investment services -column and Financial Instruments -column. We sum these up in the report instead of directly using the total field provided by analytics+, because the one from analytics+ would also include possible third-party payments of that category, which we report in a separate row instead of a new column. |
Third-party payments logic
Regulations require listing third-party payments separately from other costs. I.e. we can't just consider it a part of the security's fees. The report handles this by picking up all third-party payments and adding those to the portfolio's costs. HOWEVER, these third-party payments are NOT included in the total figures. This is because including kickbacks in the total figures would mean that we end up counting them twice: once as security costs and again as kickbacks.
In practice, third-party payments should be managed with two kinds of transactions:
Kickbacks, which are configured similarly to a dividend (i.e. adds cash, adds return etc.), and categorized under security costs (e.g. ongoing costs)
Un-distributed kickbacks, which are configured to have no effect on anything (except for FIFO effect), but categorized under third-party payments (e.g. ongoing costs)
→ Transactions should be added to portfolios corresponding to the amount kickbacks which belong to the portfolio but were not distributed. Note, that these transactions must currently be entered against a position in the portfolio; entering un-distributed kickbacks as "cash" transactions doesn't currently (3.4.15, 3.6.0) work.
 |
*this reversed setup is counterintuitive, but mandatory pre-3.4.13 (3.5.2), because otherwise paid-out kickbacks would show up as increased costs instead of reduced costs. |
The idea here is, that kickbacks which are paid back to the end customers effectively reduce the fees associated with securities which they came from. This can be achieved with transaction type 1.
Kickbacks which the asset management company keeps, however, need to show up on the report, but cannot affect the portfolio in any way. The effect of the fund's fees is already taken into account via its ex-post security costs, and the return effect is reflected in the fund's valuation etc.
Example: asset management company AMC receives sum X of kickbacks from fund Y, and customer Bob's share of it is 1000€. AMC distributes 600€ of it back to Bob, and keeps 400€. During this time, Bob has paid (directly or indirectly) 2000€ of fees to fund Y, corresponding to 1,5%. This should result in two transactions:
A kickbacks transaction with trade amount -600€, which effectively reduces the ex-post costs of that security (fund Y) from 1,5% to 1,05%.
An un-distributed kickbacks transaction with trade amount 400€, which has no effect on the security costs, but shows up as a third-party payment of 400€ on the ex-post costs and charges -report.
NOTE, that the un-distributed kickbacks transaction doesn't reduce the ex-post cost associated with the security. That's because the third-party payments figures aren't summed up into total ex-post costs and charges -figures. Instead, the idea is that the security costs also include kickbacks which aren't distributed back to the end client. The third party payments -row is just makes this part of the costs more visible to the end clients (in accordance with regulatory requirements)
Getting the ex-post report
When you have added a ex-post categorisation for you costa and installed the ex-post report, you can generate it in report - window.
Questions about ex-post costs and charges
The report uses ex-post costs for the wrong date. I entered 2018 costs for the report for 2018-12-31, since that's when they were confirmed, but it's using the 2017-12-31 costs for 2018 reporting.
Ex-post costs are indeed confirmed retroactively. So you'd get the final ex-post cost figures for 2018 at the very end of the year, or some time in January 2019. But with ex-post costs, you actually have to record them on the date when they enter into effect, NOT the date when figures are confirmed. Ex-post costs always have a time period that they're calculated from; we need to use the starting date. So if an ex-post cost figure is valid from 2018-01-01 - 2018-12-31, it would have to be entered as an ex-post costs row on 2018-01-01. And if there are any existing ex-cost rows within that time period, those would have to all be updated with the cost in question. How this all works is, that report calculations take these into account by finding the most recent (relative to the daily position being calculated) security ex-post cost percentages when it's calculating daily values for positions. This also means, that if a security has ex-post costs of X entered for 2018-01-01, and costs of Y entered for 2018-07-01, it'll use costs X for the first half of the year, and costs Y from that point forward (for that security).
Note, that our standard extensions for importing cost information take this into account.
If you entered the ex-post costs for 2018-01-01 but the report is still showing costs from 2017, then you probably have to recalculate the reports of the portfolios containing this security (see question below).
I entered ex-post costs for my security, but they aren't showing up in the report
Did you enter them for the correct date? See above for an explanation of what the correct date is. If so, did you remember to recalculate reports for the portfolios which contain this security? That's unfortunately something you have to do, because ex-post data is included in the daily report calculations, and updating this information into the securities won't automatically recalculate the reports (unless you click the save and update button... possibly)