The Rapptr framework for aggregating positions across multiple 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.
The first attribute in the hot seat is the aggregation structure. The basic Rapptr framework works with three different aggregation structures:
The naming and meaning of these three structures has 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 case the MajorGH rule runs on the Legal aggregation structure. The question now is, how are these different types of structures defined and what do they actually mean.
Each structure refers to a parent entity of an account 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 managing the securities
- VotingParent: the entity holding the voting rights to the securities
Note: 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 power associated with a specific account, managed on behalf of a client, remains in the client's control, the VotingParent should be left blank (not specified) for that account. Likewise in the case where the Custodian, for example, holds the legal title to the securities in a portfolio, the LegalParent should be left blank.
When defining these in Rapptr the three structures could look like this, for example:
Hence, all the rules labelled with Legal will run on the aggregation structure on the left hand side, the Management rules will run on the middle structure and the Voting rules will run on the right hand side structure.
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 rights associated with the securities. FundApps captures this in the Voting structure. Similar considerations have been incorporated in the Management and Legal structures.
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 where in the aggregation structure the rule will potentially trigger disclosures.
The screenshot above shows where in 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 the these. The four aggregation levels will trigger as follows:
No portfolios will be aggregated, meaning that the given rule will trigger disclosures on individual fund level.
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 holding 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 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.
Rapptr also has the ability to model umbrella fund structures. For more information around these structures and how Rapptr treats them, please have a read through the article "Umbrella Level Disclosures".
In conclusion, each rule has an aggregation structure and an aggregation level attached to it, specifying on which tree the rule will run and where in 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 firstname.lastname@example.org and we will be happy to assist.