Aggregation Framework
Overview
The Rapptr framework for aggregating positions across multiple portfolios/accounts has roots in two elements which are specified at an individual rule basis: an aggregation structure and an aggregation level. This means that a rule's Value Expressions are summed up differently depending on the aggregation structure and level required by the rule. This article describes these two attributes and how Rapptr uses them.
Aggregation Structure
The first attribute in the hot seat is the aggregation structure. The basic Rapptr framework works with three different aggregation structures:
- Legal
- Management
- Voting
The naming and meaning of these three structures have been chosen based on our interpretation of the legal memos provided by Allen & Overy. Each rule in Rapptr is labelled with one of the three aggregation types, defining which aggregation structure the rule will run on.
In this example, the MajorAR rule runs on the Legal aggregation structure. But how are these different types of structures defined and what do they actually mean?
Each structure refers to a parent entity of a portfolio in the three different scenarios described above, meaning that the Legal, Management, and Voting parent entity should be specified for each account monitored by Rapptr. The three structures are defined as:
- LegalParent: please see this article - The Legal Aggregation Structure
- ManagementParent: the entity holding direct discretionary management authority over securities in a portfolio
- VotingParent: the entity holding direct voting authority over the securities in a portfolio
Note: There is also the aggregation structure "None" which will capture all portfolios regardless of the structure and does not require setup. In addition to the above structures, we have two more aggregation structures relating to EU Short Selling Regulation (SSR) rules. Please refer to this article for more detail.
Should it be the case that the voting authority associated with a specific portfolio, managed on behalf of a client, remains in that client's control, the VotingParentID should be left blank (not specified) for that portfolio.
The three structures can be viewed on the portfolio page:
The three structures have been defined based on what the different regulators are interested in. For example, some regulators are only interested in securities where the investor actually holds the voting authority over the securities. FundApps captures this in the Voting structure. Similar considerations have been incorporated in the Management and Legal structures.
Aggregation Level
The second element that defines the Rapptr aggregation framework is the aggregation level. Rapptr works with a total of four possible aggregation levels, which again have their roots in the legal memos provided by Allen & Overy. The aggregation level defines wherein the aggregation structure the rule will potentially trigger disclosures.
The screenshot above shows wherein a given rule a disclosure might potentially be triggered, i.e. on Portfolio, Sub-Entity, or Top Level Company level. Further, some rules will potentially trigger disclosures on a combination of these. The four aggregation levels will trigger as follows:
Portfolio:
No portfolios will be aggregated, meaning that the given rule will trigger disclosures on the individual portfolio/fund level.
In the case that a portfolio has an Umbrella as its Parent in any aggregation structure, the given rule will run on the Umbrella instead of the Portfolio. For more information on Umbrellas and how Rapptr treats them, please have a read through the article "Umbrella Level Disclosures".
All Entities:
The rule will aggregate all portfolios up to a specific Sub-Entity and trigger a disclosure based on all the assets of the Sub-Entity child portfolios. Further, should there be a Top Level Company being to ultimate the parent, the rule will also trigger a disclosure based on the aggregate holdings across all portfolios.
All Entities and Portfolio:
The level will trigger disclosures on both Sub-Entities and Top Level Company, but in contrast to the "All Entities" level, a disclosure on each individual portfolio is possible here as well. So, this is a combination of "Portfolio" and "All Entities".
Top Level Entity:
This level will only trigger one disclosure, which will be an aggregation across all portfolios in the given aggregation structure (i.e. a disclosure will only trigger on the ultimate parent of the structure).
Top Level Entity and Portfolio:
This level checks for disclosures at the Top Level as described above, and also at each individual portfolio level.
Summary
In conclusion, each rule has an aggregation structure and an aggregation level attached to it, specifying on which tree the rule will run and wherein the tree any disclosures will trigger.
The legislation around aggregation is some of the most complex within the Allen & Overy memorandums. We welcome any questions or comments you might have. Please contact us via support@fundapps.co and we will be happy to assist.