A given EntityA in a corporate structure can be party to an agreement covering a portfolio (grouping of assets) where it delegates either discretionary management power (Management) or the power to exercise voting rights (Voting) to another EntityB.

Generally, EntityA would have an initial agreement (for example, an investment management agreement or "IMA") with a third party (their client perhaps), and then sign an additional agreement (or amend the initial agreement) with another EntityB so that EntityB will perform the day-to-day Management or Voting relationship/duties over the portfolio. These agreements are often called "sub-delegation" agreements.

In this basic delegation scenario, EntityB can be an affiliated/controlled entity (internal) or a third party (external). Where we have legal information distinguishing between this, we should specify these nuances in relationships.

Multiple delegation: A portfolio (group of assets) can also be delegated more than once ("multiple delegation"). See the multiple delegation section below for more details.

Let's cover the single internal delegation case first. In this case, EntityA can be called the "Delegator" of Management or Voting and EntityB the "Delegatee" of the same power(s), although, in our model, we don't need to label EntityB as Delegatee, it's just the normal "Management" entity (default) as it actually manages the assets.

We can model internal delegation by identifying the relationship that each entity has to a FundApps portfolio. In the scenario above, where we can assume EntityA has delegated Management of Portfolio1 to EntityB, then:

(Visualisation of a Delegation of Management relationship (internal))

How about external delegation? In the image below, EntityA can be called the "Delegator" of Management or Voting and ExternalEntity (see image) the "Delegatee" of the same power(s). In the model, we will not include external entities in FundApps as they are not part of your firm's corporate structure. Whatever obligations that external party has are their responsibility.

Like the case of internal delegation, EntityA has a relationship to Portfolio1 which can be described as a "delegator of management power" or Management Delegator.

That's it; the holder only has a Delegator relationship with the portfolio so should aggregate assets for regimes that require a delegator to aggregate. Later we will address how this can be specified.

An entity (EntityA) might delegate management (or voting power etc.) to EntityB, but then EntityB then signs another delegation agreement with EntityC, where EntityC is the entity this is actually managing (voting, etc.) the assets, or what we can call the ultimate delegatee. There might be any number of delegation steps between parties.

In the image below, EntityA and EntityB have a relationship to the "MultiDelegated" portfolio in the image below as delegators of management power. They are both delegators in a chain.

EntityC has a relationship to the portfolio "MultiDelegated" which can be described as the actual (default) management power or just "Management"

For rules which indicate that delegators of management or voting (or both) have an obligation, they will have "Delegators required to aggregate" set to True.

The image above for the Multiple Delegation scenario shows the results one would expect. See the assumptions and red coloured percentages.

First, confirm that a given entity (or entities) is delegator of Management or a delegator of Voting (see the section above for a description of these terms) and which portfolios (or umbrellas) it has this relationship for. We recommend going through this for each portfolio and checking internally at your firm - likely with legal by investigating your agreements.

For such entities, in the Aggregation Structure (either Management, Voting, or Legal), you can identify the delegator Entity (or chain of delegator entities) in a column associated with a given portfolio in the Portfolio file (csv) with the following naming convention: [AggregationStructure]DelegatorParentId

For example, if a given portfolio has a relationship with an entity where the entity is a Delegator of Voting, then do not modify the existing Voting tree (e.g. VotingParentID), but add a new column VotingDelegatorParentID and insert the PortfolioID of the Entity which has this relationship. (This entity will also be specified in the LegalDelegatorParentID column since that describes entities that are delegators of voting or management).

Umbrellas: So far, we assumed a Portfolio is the object which is the "bucket" of assets that has these relationships with entities. However FundApps also models "umbrellas" which act as ensembles of portfolios, and in some cases then they can be delegated just like portfolios but depending on if you have a separate tree to handle umbrella level disclosures, it is likely better to set Delegation at the portfolio level, even if the portfolios are part of an umbrella. The only case in which one should model a full umbrella as delegated is when two things are true: a) All sub-funds must have the SAME delegator entity(s) and b) all sub-funds must have the SAME default parent (delegatee) entity(s), if the delegatee is internal (if not, forget b). Note that it's generally the case that all sub-funds (i.e. the portfolios with an umbrella as their direct Parent) must share the same Management Company (e.g. UCITS ManCo) which is commonly a delegator but they may or may not share the same chain or delegators or default manager(s)/voting rights holder. If they don't share them all, then the umbrella should not be setup with a Delegator but individual portfolios should be. If there is any confusion with Umbrellas, please contact Support and we can gladly help.

Applies to Major rules only: First, it's important to keep in mind that aosphere only supplies legal information on the obligations of delegators of management or voting for the MAJOR shareholding regimes, not for Takeover, Short or other regimes. This means that our rules will only reflect analysis for Major rules (and in a few exceptions for Takeover regimes which are clear extensions of the Major regime or where the rule logic from Takeover is tied to the Major regime).

General (default) case: For each rule in FundApps, regulatory information (from our legal information provider) specifies which type of relationship an entity must have with assets (which are delivered in portfolios) to require an aggregation and disclosure obligation. We use the property Aggregation Structure to specify this. By default, we assume that there is ONE entity with this relationship for a given portfolio - this is the entity which practically holds the "power" referred to by the values "Legal, Management or Voting - see the above article on the Aggregation Framework for detail on these values. Content makes this judgement for each rule from memo wording - mainly from the Managed Holdings appendix.

Delegator requirement: In certain rules (regimes), the regulatory info also specifies (usually in the "Managed Holdings" appendix) that apart from the entity that has discretionary management power (Management) or Voting power, there are OTHER entities that also have an independent obligation to aggregate and disclose. These particular entities are delegators of Management or Voting, as described in the section above.

aosphere has only recently added answers to the question about whether a delegator of management or voting has an obligation in addition to the default management or voting right holding entity.

In absence of legal info specifying that a delegator also has a requirement, we assume they do not! The rule in such cases, will not show any information about the delegator requirement.

After interpreting the legal information (see above), FundApps will set the property "Delegators required to aggregate" to either true or false.

Where we have no legal information (or haven't yet analysed the memo), this will default to false, which means the rule will only aggregate to the (default) standard parent entity(s). In this case, the property will not be displayed in the FundApps UI.

If set to True, then the portfolio which has a delegator relationship with an entity in a tree with the Aggregation Structure that corresponds to that rule will be aggregated to that entity (and entities that are its parent/control it).

Major rules with AggregationType: Portfolio. For rules which only run on FundApps portfolios, the regulatory interpretation indicates that entities which hold discretionary management or voting power (aside from the portfolio legal personality wrapper or underlying owner of the portfolio), do not need to aggregate those assets. For example, it might be that only a fund itself has a disclosure obligation. In such cases, the analysis from the aosphere Managed Holdings section is not applicable since the question of whether delegators also have an obligation relates only to entities holding management or voting discretion. For these rules, FundApps will not apply an assessment for this property.

Visibility: Currently, you will not be able to visually see which entities you have designated as Delegators in Portfolio and Entities screen, and cannot see in a given entity result, if assets included were a result of a Delegator relationship. We thought it best to release the functionality early; do let us know if you have any thoughts or ideas on how to make this more transparent.