The DMFSA specification that was developed in the earlier stages of the project does not describe how parties to an agreement should exchange information on the business that they have done together. This work package will examine how they should exchange information about holdings, commissions due, and payments, and how they might reconcile their business together using straight-through processing techniques.

Deliverables

Abstract (implementation independent) definitions of protocols for reporting and reconciling commissions and their underlying holdings and transactions.

Time

Not likely to start until late autumn 2010. Completion date not set.

Comments

What follows is simply a discussion of how we might do this. It is not a formal design but it does use many DMFSA defined terms and concepts and it provides a good insight into what the DMFSA reporting and reconciliation service might look like.

Unlike the agreement term sheet editor (see work package T2 – advanced prototype), where it is important to provide companies with a printed “half-way house” to encourage the use of DMFSA in the agreement creation process, this work package will remain within the STP domain, producing a design to enable reporting via XML messages. We do not intend to provide instructions on how to interpret those designs to create paper or PDF or spreadsheet reports.

We will start by defining the top level structure of a report. In this example we have included only rebate and reconciliation data. In a full design we would expect the report to contain transaction charge data such as front-end and back-end loads, switch charges, etc. You can see that the report is very simple:

The rebate reports

A DMFSA agreement permits parties to set up many different rebate mandates (known as rebate sets) and the rebate report allows the results of those mandates to be reported separately:

Each rebate set report is uniquely linked to the relevant rebate set in the sales agreement by its local identifier. The report also includes summary earnings totals and a list of detailed rebate reports:

Earnings totals are reported in relevant rebate earning currency (as opposed to settlement currency, which is a matter for the settlement instruction, not the rebate report). The earnings total may be a single currency or several currencies if the agreement describes rebates for multi-currency investments:

The reconciliation data

Reconciliation cannot be performed without knowing (1) the currency conversion rates that were used by the party that calculated the commissions (questions of best execution must be resolved outside of DMFSA) when it aggregated multi-currency holdings in order to look up the relevant rebate rate in the reference currency of the rate table and (2) the detailed holdings data that were employed in the commission formula and (3) how products are related for aggregation purposes and (4) their price history during the rebate period.

The reconciliation data must include all currency cross rates and all holdings and products that were used to generate the rebate payments. (There is possibly a problem with this design because it will not detect an omission. If a product has not been used in a calculation when it should have been, it will not be delivered to the other party for reconciliation. We might overcome this by extending VerifyDMFSA to deliver a complete product directory or an alias. See “further ideas”, below.)

That sounds complex but in reality it is simple:

The top level product report is constructed in a similar way to the holding report, being a list of detailed product reports, which show the price history of each product that was used to calculate the rebates. In this case, each product’s name and the product families to which it belongs (i.e., share class, sub-fund, fund families and any other family aliases, such as an asset class or style category, all of which are necessary to test whether the product aggregation rules have been correctly applied):

Further ideas

The discussion above is intended to suggest how the DMFSA design might develop. It is not a complete design. It does not, for example consider whether the report should include DMFSA concepts such as “Discount”, “CompanyShare” and “CounterpartyShare” – the implication is that the report shows only “CounterpartyShare”. Nor does it consider whether the report should confirm the payment mandate that will be used for settlement, either by reference to its LocalID in the sales agreement or perhaps more conveniently by repeating it in the report. Note that when we say payment mandate we mean the co-ordinates of the payment rather than the settlement amount, which might involve the transmission of information about foreign exchange, value date, etc., which will probably not be known when the earning and reconciliation report is generated.

Some of the ideas in the discussion obviously require expansion. For example, the rule ProductReport (immediately above) provides the ability to name one or more aliases, which might have been included in the aggregation instructions for a rebate mandate. An alias is a set of ISINs, the members of which can be implied by searching for every product in the reconciliation data set that bears the name of the alias. This might be sufficient for our purposes but we won’t know until we have worked the design through in detail. An alternative approach might be to provide an alias history in the form of a baseline membership and a set of updates during the report period. This alternative approach has the advantage that it might also be used as a directory update operation within the VerifyDMFSA function (see work package T3 – lifecycle management). The function might have the following definition: