Delegation of management and voting power

When entities or persons with discretionary management power or voting rights delegate those powers to affiliated (internal) or external parties, this can affect their disclosure obligations. 

Rapptr now automates the aggregation requirements for entities that have delegated management or voting authority, once these are modelled in your portfolio file.


What is delegation and how does it affect aggregation?

  • 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 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.

Internal Delegation

  • 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 Rapptr portfolio. In the scenario above where we can assume EntityA has delegated Management of Portfolio1 to EntityB, then:

    1. EntityA has a relationship to Portfolio1 which can be described as a "delegator of management power" or Management Delegator. Later we will address how this can be specified.
    2. EntityB has a relationship to Portfolio1 which can be described as the actual (default) management power or just "Management" (We can also label this relationship as "delegatee" of Management but this is unnecessary strictly speaking as it's only a term used to help distinguish its role in relation to a delegator if that exists). This is the relationship that we always model by default using the field ManagementParentID - simply which entity is actually managing the portfolio.


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

External Delegation

  • 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 Rapptr 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.


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


Multiple Delegation (internal or external)

  • 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"




How are Rapptr results affected?

    • 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.


How to specify Delegator relationships

  • 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
    • If there exists more than one Delegator entity for a given portfolio, then the list (chain) of entities which are delegators can be specified in comma separated format, in ORDER of the flow of delegation. For example (assuming all entities are internal), if EntityA has the initial management relationship with a portfolio, and then delegates management to EntityB who then delegates management to EntityC which will be the ultimate delegatee, then the field "ManagementDelegatorParentId" should be populated with EntityA,EntityB. The field "ManagementParentId" will be EntityC since it is not a delegator but actually managing the portfolio (this should already be specified in your portfolio file anyway).
    • The field must consist only of entity IDs.
    • It can be specified on portfolios (that are not under an umbrella) and umbrellas (see note below on umbrellas).
    • For entities which are identified as EITHER a delegator of Management or Voting power (or both), they should also be identified as delegators in the Legal tree, by specifying it in a column "LegalDelegatorParentID".
  • 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 Rapptr 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.

The column (field) [AggregationStructure]DelegatorParentId can be considered as modifying the [AggregationStructure] relationship that exists by aggregating a portfolio to another parent entity.

If there is more than one delegator,[AggregationStructure]DelegatorParentId should be populated with all entity Ids which are delegators, in order of delegation and comma-separated.


Sample Portfolio file setup (see image below):

PortfolioId ManagementParentId ManagementDelegatorParentId
TopEntity TopEntity  
EntityA TopEntity  
EntityB TopEntity  
EntityC TopEntity  
EntityD EntityC  
Non_Delegated_1 EntityA  
Delegated EntityB EntityA
MultiDelegated EntityC EntityA,EntityB
Non_Delegated_2 EntityD  
DelegatedExternally   EntityD




How does FundApps interpret legal information for delegation?

  • 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). 
    • There are 58 jurisdictions with major shareholding regimes which is the number of countries which FundApps expects to cover in our (Major) rules for the delegator requirement.
    • FundApps will release new rule versions as aosphere supplies, and as the Content team work through the legal information, at our discretion and priority. Generally speaking we will prioritise jurisdictions where there is an indication that there will likely be a delegator requirement.
  • General (default) case: For each rule in Rapptr, 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 our 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.


How does FundApps specify delegation information in rules?

  • 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 Rapptr 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).
    • For example, in the Multiple Delegation image above, EntityD has a "Management delegator" relationship with the portfolio "DelegatedExternally" so it would aggregate that portfolio to itself for a rule with Delegators required to aggregate set to True. Any parent entities of EntityD (EntityC and TopEntity) would also aggregate those assets.
    • Note on Legal: that for rules with Aggregation Structure, Legal, this means that the parent entity has either Management power, Voting power, legal title, or is the beneficial owner. Legal title and beneficial ownership cannot be delegated in our model, so where Delegators required to aggregate is set to true, this means entities which EITHER delegate management or voting have an obligation.
  • Major rules with AggregationType: Portfolio. For rules which only run on Rapptr 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.


Override Delegation for certain rules

For specific rules, a significant number of clients have indicated that aosphere's legal information on delegation is not nuanced enough or may not align with market practice. Where FundApps has brought such cases to aosphere's attention and they have not yet addressed them in more detail, we allow clients to override the "Delegators required to aggregate" setting (from true to false). The rules which can be overridden to false for this setting are listed in the ValueSet, DelegatorRelationshipsOverrideRuleIDs.

Because this is an interpretive override for a key feature of a rule, namely the entities (delegators) to which assets will be aggregated, this feature is only allowed for a set of rules approved by the FundApps Regulatory Content team.

To set this override, navigate to the Global Setting section entitled  OverrideDelegatorRelationshipsRuleIDs (under Admin > Setup > Global Settings) and select the rules you want to override under "Rules with delegators required to aggregate set to false". Please ensure that you do so under one of the reasons outlined below. Settting this override will mean that all portfolios will NOT aggregate to entities modelled as Delegators in the relevant aggregation tree.

This override is only meant to be used when one holds specific rationale for specific rules. Here are the reasons:

United States (Major):

Here are two reasons we have identified that would justify an override for the Major US rules (including 16A rules, but excluding 13F). Please also see the Major US rules, Explanation>Aggregation section for detail.
  1. Your firm only delegates management or voting to internal entities and you hold the view that delegator entities in such cases do not aggregate delegated portfolios in addition to the delegatee entity.
  2. Your firm only delegates management or voting to entities where the delegation cannot be rescinded within 60 days, and you hold the view that the "60-day" rule for US beneficial ownership applies to delegation.

Japan (Major):

IMPORTANT NOTE: Delegation must be overridden for all of the Major JP rules or none of them. If you only list some of the Rule IDs in OverrideDelegatorRelationshipsRuleIDs, then Rapptr will generate incorrect results. Delegation can also only be overridden for all portfolios in the aggregation tree.

We have identified that clients may be able to justify overriding delegation for the Major Japan rules if the following conditions are met:

As set out in Appendix 1.B of the memo, your firm has completely delegated management and voting power in all delegation agreements, and the original manager never retains any discretion at all for itself.
In particular, the manager does not retain the right to exercise voting rights or make investment decisions without terminating the delegation agreement, nor does the manager otherwise retain ultimate entitlement to exercise voting rights or investment discretion by other means.
At present, Rapptr cannot support scenarios where clients have a mixture of "partial" and "full" delegation. Counsel recommends considering whether a delegation agreement meets the requirements of "full" delegation on a case-by-case basis.


Was this article helpful?
2 out of 2 found this helpful
Share article