dematerialised mutual fund sales agreements - issa · part of a collaborative project by: blackrock...

Dematerialised mutual fund sales

agreements

Initial industry briefing and request for comment

Issue 01, revision 01

06 January 2009

Part of a collaborative project by:

BlackRock BNP Paribas Brown Brothers Harriman DWS Franklin Templeton Fund-F JPMorgan Schroders UBS

Dematerialised Mutual Fund Sales Agreements, initial industry briefing, issue 01, revision 01, 06 January 2009

Important

This document is intended only to be used as a preliminary briefing paper. It should be treated as a work-in-progress. It might contain errors and it is subject to change without notice. It is the joint work of the companies named above but they have not yet endorsed it. This project is not presently aligned to any official institution or industry association.

This document is limited to certain legal and operational aspects of mutual fund sales agreements. It does not exhaustively address the question of how dematerialisation could be achieved. For example, it does not contain a model for the ownership and governance of the design and it does not explain in detail how the design might be implemented. It also does not consider the commercial and operational benefits of dematerialisation in functions such as fund order routing and commission calculation, reporting and payment. The authors have developed some ideas about these issues and will describe them in the next phase of their work.

Please note that the aim of this project is not to restrict the commercial freedom with which companies sell mutual funds.

Its aim is to improve the commercialisation of mutual funds by developing a common legal foundation and an adaptable technical framework that is capable of supporting a wide variety of business models.

It aims to make the process of selling mutual funds more efficient for all parties involved.

This is an open project, which welcomes wide industry participation from promoters, distributors, fund buyers and industry associations.


Contents

Part 1: Introduction

Part 2: Draft master fund sales agreement

Part 3: Synoptic chart for commercial terms

Part 4: Syntax for commercial terms

Part 5: Standard rebate formula

Part 6: Detailed specification for commercial terms

Part 7: Model appointment document (pro-forma term sheet)

Preface

This paper is the product of a collaborative project involving BlackRock, BNP Paribas Securities Services, Brown Brothers Harriman, DWS, Franklin Templeton Investments, Fund-F, JPMorgan Asset Management, Schroder Investment Management and UBS AG.

The project's objective is to make it easier for companies to create sales agreements for mutual funds.

In preparation for the next phase of work, the project has invited the following organisations to participate: Association of the Luxembourg Fund Industry, Ikano Fund Management, International Securities Services Association, Kneip, RBC Dexia Investor Services and SWIFT. Other participants would be welcome.

Further information

For further information on this document please contact:

Noel Fessey, Schroders Luxembourg ([email protected])

© 2008, 2009

mailto:[email protected]


Part 1: Introduction

Abstract

Mutual fund sales agreements and the associated commissions processing activities are some of the least standardised and automated aspects of the world-wide fund industry. It's a commonly-held view that there is little possibility for improvement. This paper argues otherwise, and shows how the development of open standards could be achieved with no loss of flexibility or competitive potential.

Current practice

In today's mutual fund industry, fund sales agreements are very often customised documents. They are individually written by lawyers using word-processors, printed onto paper and signed with ink by each party.

When firms talk about "standardisation" as a means to avoid the expense and delay of the customised process, they invariably mean using their own standard form of an agreement. That is clearly not equivalent to an industry standard, as every firm of significant size, whether on the sell-side or the buy-side, has developed its own "standard" fund sales agreement. The first step to contracting most agreements is therefore a "battle of forms", in which the parties involved decide whose preferred form they will use as the basis for their agreement and how much modification will be necessary to make it acceptable to both sides.

This is essentially a zero-sum effort: each party reviews / negotiates the other's agreement(s) to ensure that the other's preferred form is acceptable to it. However, this rarely achieves more than ensure that the agreement is reasonable from the perspective of both parties and that it conforms to some basic legal principles, which are commonplace in the mutual fund industry throughout the world.

Figure 1: current practice – paper, ink, expense and delay

Promoter

Lawyer Commissions payable

Agent

Lawyer Commissions receivable

Promoter salesman

Agent(e.g. distributor)

Agreement

Agreements slow to contract, expensive, non-standard (“battle of forms”), difficult to store, track & maintain. Process misuses scarce lawyers and paralegals, adds no value

2

Agreements made quickly in principle1

Little STP in commission calculation, notification & payment between counterparts; many non-standard processes between each party and sometimes hundreds of counterparties

4

Internal communication manual, expensive, prone to error and omission

3

Promoter

Lawyer

Promoter

Lawyer Commissions payable

Agent

Lawyer

Agent

Lawyer Commissions receivable

Promoter salesman


Agreement

Agreements slow to contract, expensive, non-standard (“battle of forms”), difficult to store, track & maintain. Process misuses scarce lawyers and paralegals, adds no value

2 Agreements slow to contract, expensive, non-standard (“battle of forms”), difficult to store, track & maintain. Process misuses scarce lawyers and paralegals, adds no value

2

Agreements made quickly in principle1 Agreements made quickly in principle1

Little STP in commission calculation, notification & payment between counterparts; many non-standard processes between each party and sometimes hundreds of counterparties

4 Little STP in commission calculation, notification & payment between counterparts; many non-standard processes between each party and sometimes hundreds of counterparties

4

Internal communication manual, expensive, prone to error and omission

3 Internal communication manual, expensive, prone to error and omission

3

This practice presents the fund industry with several problems (see also Figure 1 above):

⎯ Expense Fund sales agreements are expensive to implement because they need lawyers or paralegals to


draft them and each amendment must be explained, considered and debated, often in writing between the parties, before it is accepted. For what are often not much more than a collection of commonplace legal principles committed to paper, such agreements are poor value for money, and firms should be able to contract a satisfactory agreement at a much lower cost.

⎯ Misuse of legal resource There is a shortage of legal skills within the mutual fund industry and time spent on fund sales agreements cannot be spent on higher value professional work, such as the design of new products.

⎯ Constraint on growth There are limits to the legal resources that firms can employ on fund sales agreements, which constrain their ability to build and maintain distribution networks. Consequently, distribution networks are smaller than they otherwise could be and are not easily maintained as the promoter develops its product range (in fact, few distribution networks are maintained as actively as they ought to be). In effect, neither the promoter nor the distributor can realise the full economic potential of the distribution network.

⎯ Poor communication Precedent agreements do not always ensure or enable the complete and accurate transfer of information between sales representatives, lawyers, commission calculation agents, transfer agents and other service providers. This means that the terms of business provided for in the finished agreement might only be an approximation of what the sales representatives agreed and, notwithstanding any omission or transcription error that might arise as the agreement is implemented in the back office, often contain insufficient information for the commission calculation agent and transfer agent to allow for clear interpretation and implementation of the agreement.

⎯ No support for automation Because no standard description of fund sales agreements exists, there is little opportunity for straight-through processing within the order-routing and commission calculation processes, and little prospect of improving the speed and accuracy with which commissions are calculated and paid throughout the industry.

A model for the future

Fund sales agreements could and should be made more cost effectively, using a universally acceptable master agreement and custom-made term sheets (see Figure 2 below). The contributors to this project have prepared a draft text for the master agreement (see Part 2 of this paper), which provides a suitable legal foundation for domestic and cross-border fund sales. They have also prepared a standard syntax for term sheets (see Parts 3, 4, 5 and 6 of this paper), which encourages comprehensive and standardised communication and processing across the industry without limiting the ability of companies to do business together on entirely proprietary terms.

The concept of an industry standard master agreement is not new to the financial services industry. The best known example is the International Swap Dealer's Association master agreement (commonly known as the "ISDA" agreement). Within the mutual fund industry, the most successful standard fund sales agreement is probably the Swiss Fund Association's. The benefit of such standards is that they:

⎯ Establish a commonly accepted legal foundation upon which industry participants can do business.

⎯ Help to reduce legal risk and cost.

⎯ Encourage basic standards of good practice.

⎯ By promoting standardisation in services where difference provides no competitive advantage, help firms to concentrate their effort upon services where they believe they can make a difference, which


in turn improves competition and service.

Figure 2: a model for the future – universally standard terms with custom-made commercials

1. International Swap Dealers’ Association, Inc.

Universal agreementUniversal agreement

Promotersalesman


Think of the universal agreement as something similar to the ISDA1

master agreement but simpler.

Globalterms

Globalterms

Localcountryterms

Localcountryterms

+Agreement

Specific commercial

terms

Specific commercial

terms

2 Agreement adheres to universally standard terms, which everyone in the industry uses without amendment.

Commercials are the essence of the agreement. They say what role the agent performs, for what funds, in what territories and for what reward.

31 Agreement made

quickly in principle.

Terms common to all territories and employed in every agreement.

Terms special to certain jurisdictions and employed only in those agreements that need them

Agreements might be contracted several ways – physically if the parties want to or by electronic message exchange if both parties subscribe to a messaging community that adheres to the universal agreement.

Specific commercial terms are usually simple and can be described by a simple structured syntax. In other words, the process can substantially be reduced to a form-filling exercise within the sales/operations divisions, which is capable of completion within hours.

It would not be very difficult from that point to automate the process within a messaging community (see later pages).

1. International Swap Dealers’ Association, Inc.

Universal agreementUniversal agreement

Promotersalesman


Think of the universal agreement as something similar to the ISDA1

master agreement but simpler.

Globalterms

Globalterms

Localcountryterms

Localcountryterms

+

Globalterms

Globalterms

Localcountryterms

Localcountryterms

+Agreement

Specific commercial

terms

Specific commercial

terms



Commercials are the essence of the agreement. They say what role the agent performs, for what funds, in what territories and for what reward.

3 Commercials are the essence of the agreement. They say what role the agent performs, for what funds, in what territories and for what reward.

31 Agreement made

quickly in principle.

1 Agreement made quickly in principle.

Terms common to all territories and employed in every agreement.

Terms special to certain jurisdictions and employed only in those agreements that need them

Agreements might be contracted several ways – physically if the parties want to or by electronic message exchange if both parties subscribe to a messaging community that adheres to the universal agreement.

Specific commercial terms are usually simple and can be described by a simple structured syntax. In other words, the process can substantially be reduced to a form-filling exercise within the sales/operations divisions, which is capable of completion within hours.

It would not be very difficult from that point to automate the process within a messaging community (see later pages).

The draft master agreement that has been prepared in the course of this project has been written within the context of European Union law to support domestic and cross-border fund sales within the European Union and international fund sales beyond the European Union's borders, excluding the United States. With the exception of some important references to the European Directive 91/308/EEC on the prevention of the use of the financial system for the purpose of money laundering and the European Directive 2003/48/EC on the taxation of savings, the draft contains no explicit reference to national legislation, and it requires the contracting parties to declare in their term sheet which law their agreement is made under and to which courts they will submit.

The master agreement is also designed to be invoked in several parts:

⎯ Global terms, which are common to all territories and which are employed in every agreement.

⎯ Local country terms, which are unique to a particular country and should only be invoked if the parties are contracting an agreement for business to be conducted in that country.

At present, only the global terms have been written. An example of something that might be included in a set of local country terms might be Luxembourg's requirement that fund sales agreements should contain provisions to defend funds against market timing.

The adoption of a standard master agreement allows firms to concentrate upon their term sheets, where they can achieve true competitive differentiation. The syntax for commercial term sheets can be used to create term sheets efficiently, either as printable documents, which may be signed in ink according to current practice, or as electronic messages, which if exchanged using a suitable message protocol over a suitable infrastructure, would permit the industry to "dematerialise" agreements in the manner imagined in Figure 3 below. To keep it simple, the syntax for commercial term sheets is limited to what must be defined in order to construct a valid agreement (which is often surprisingly little) and excludes what else the parties to an agreement might wish to define in support of the business between them (reporting messages for commissions, for example). When the dematerialisation concept starts to win general acceptance, work on commission reporting and payment can begin.

If a firm wished to manage its term sheets in a word processor using macros to control data entry or in a simple database application linked to a document generator, it could do so very quickly. The syntax of


commercial terms is well-developed, being supported by a comprehensive technical reference, and is simple for a technician to understand. Such a tool would effectively shift the agreement preparation process from the legal domain to the sales and operations domains, and reduce production time to a matter of minutes. In that scenario, agreements are transformed into operational documents with a legal basis. The contributors to this project have prepared a model term sheet in Microsoft Word (without macros, see Part 7 of this paper) to illustrate the concept, and have prepared a concept demonstrator in software, which shows how agreements can be prepared and stored in a database application before being printed to paper or written as a structured electronic message, ready for transmission over a computer network.

Figure 3: infrastructure – emergent dematerialised platforms

Fund promoter (global distributor)

Internet or financial messaging network Agent (distributor,

dealing agent, introducer)

Agent (distributor, dealing agent,

introducer)

Small agentDistribution portal & message store

Fund promoter (global distributor)

Hosted sessionHosted session Parties not equipped to format, send, store & process their own

messages

Web-based application hosted on a service provider’s computers, providing the means to exchange messages with other parties. User-friendly interface allows messages to be written and read and records to be stored, retrieved and exported in common formats such as Excel.

Large scale promoters and agents will build STP links to their rebate management & payment systems

Membership of a message exchange community will entirely eliminate physical agreements:

All messages will adhere to the global terms of the universal agreement

Counterparties will exchange messages to agree what local country terms apply to their business together

Counterparties will exchange messages to agree what commercial terms apply to their business together

An authentic message (offer) and a reply (acceptance) are a binding contract

The message infrastructure exists today in systems such as SWIFT. This is not a radical vision of the future.

Parties equipped to format, send, store & process their own

messages

Messages written in standard syntax similar to SWIFT XML messages. Primitive constructs will support sophisticated transactions

Commercial terms between two parties remain strictly private; they cannot be seen by other members of the community

It is likely to be some time before the industry will adopt fully dematerialised agreements, principally because it will take time for companies to develop the necessary message protocols and services. The vision of dematerialised fund sales agreements does not call for a single infrastructure, and there is no need for a central message repository because the messages between a fund promoter and its distributors or agents must remain private bilateral agreements. The definition should therefore be stateless (i.e., it should not call for the creation of a central repository in which all participants' commission terms will be stored, and each message need not be "aware" of previous messages that parties have exchanged). However, in practice the parties who will use the concept must keep a record of the history – or state – of the communication between them, which will form the corpus of their dematerialised sales agreements. The vision therefore allows market participants to decide whether they will build for themselves the capability to create, send, receive, store and generally manage their messages or whether they will buy the capability from specialised service companies. What is important is that the industry should promote open standards and encourage people to adapt existing systems to exchange and manage messages (e.g., over SWIFT and through bureau service companies).

The success of dematerialisation will depend on the extent to which it is adopted (the "network effect"), which in turn will be determined by how well it can be applied by a large number of companies to their normal business practices. For that reason the draft master agreement and the syntax of commercial terms have aimed to strike a good balance between detail and generality, standardisation and flexibility, prescription and choice.

To maintain standardisation and inter-operable, open systems, the project must go on to define a legal governance model for the master agreement (perhaps like ISDA) and a technical authority (perhaps through ISO, in co-operation with SWIFT) for the syntax of commercial terms and any common message protocols. That work will begin in the following months. It is the opinion of the contributors to this project


that neither they nor any other company or industry association should profit through controlling the governing authority, which should be established to advance the concept of dematerialised mutual fund sales agreements for the common good of the industry.

Next steps

The member companies of this project intend to begin a consultation exercise to invite feedback from industry participants and associations with a view to developing the draft master fund sales agreement and the syntax of commercial terms, and encouraging their adoption as standards for mutual fund sales within Europe on a domestic and cross-border basis and internationally between Europe and other markets.


Part 2: Draft master fund sales agreement

General terms and conditions applying to the promotion of investment funds

1. Interpretation

1.1 Under these Terms:

"Agreement" means these Terms and the Appointment Document;

"Appointment Document" means the document signed between the Distributor and the Company incorporating these Terms by reference and under which the Company appoints the Distributor to distribute the Shares of the Funds. The Appointment Document contains, in particular, the details of the Distributor, of the Shares, of the Region and the terms of remuneration for the Distributor;

"Articles" means the constitutive document of a Fund as amended from time to time;

"Company" means the Fund or its management company or any other entity duly authorised to appoint distributors for the Shares;

"Distributor" means the entity appointed hereunder to promote and distribute the Shares to investors in the Region through a sales force, banking network, private banking or similar organisation;

"Funds" means the investment funds as listed in the Appointment Document;

"Market Timing" means subscriptions or purchases into, switches between or redemptions or sales from the various Funds (whether such acts are performed singly or severally at any time by one or several persons) that seek or could reasonably be considered to appear to seek profits through arbitrage or market timing opportunities as more fully defined by the Funds' Prospectus or by applicable laws or regulations;

"Operating Memorandum" means a document agreed between the Company and the Distributor which elaborates on all operational aspects of the relation;

"Prospectus" means the current prospectus and simplified prospectus of a Fund and any supplement or addendum (when applicable) or updated version of the prospectus and simplified prospectus as approved by the relevant regulator;

"Region" means the jurisdiction(s) indicated in the Appointment Document;

"Share" means a share or unit of a Fund;

"Country Schedule" means the document signed by the Distributor (if any) and the Company incorporating these Terms by reference and containing any additional terms specific to the Region, and

"Terms" means these terms and conditions.

1.2 In these Terms, unless otherwise specified:

1.2.1 references to "clauses", "sub-clauses", "appendices" and "paragraphs" are to clauses, sub-clauses, appendices and paragraphs of these Terms;

1.2.2 headings to clauses are for convenience only and do not form part of the operative provisions of these Terms and shall be ignored in construing the same;


1.2.3 a reference to any statute or statutory provision shall be construed as a reference to the same as it may have been, or may from time to time be, re-enacted;

1.2.4 references to a "person" shall be construed so as to include any individual, firm, company, government, state or agency of a state, local or municipal authority or government body or any joint venture, association or partnership (whether or not having a separate legal personality); and

1.2.5 references to a "document in writing" and "signed" shall be construed to include dematerialised forms of communication including electronic signatures and documents sent via electronic media as agreed between the parties from time to time.

2. Appointment of a Distributor

2.1 The Company appoints the Distributor, on a non-exclusive basis, to promote and distribute Shares of the Funds authorised for sale or distribution to the public in the jurisdictions of the Region as further defined in the Appointment Document. The Distributor is further allowed to sell and place the Shares in accordance with relevant local private placement rules where a Fund is not authorised for public distribution. The Distributor hereby accepts such appointment on the terms and conditions set out in these Terms.

2.2 The Distributor may, for the purpose of these Terms, use its network of offices as further described in the Appointment Document and undertakes that its network of offices shall comply with the provisions of this Agreement. Any failure of its subsidiaries/branches to comply with these Terms will be deemed a failure of the Distributor.

2.3 The Distributor shall promote the Shares and shall for such purpose use the Prospectus and sales material relating to the Shares, which will be made available by the Company. Upon notification by the Distributor to the Company, the Distributor may also produce and issue its own sales material, on the condition that the Company reserves the right to object to the use of the Distributor's sales material and to make, or to cause the Distributor to make, any changes it deems required. The Distributor bears sole responsibility for the content of the sales materials it produces.

2.4 The Distributor shall only offer or make available Shares to third parties:

2.4.1 in circumstances where,

(i) it has no reason to know or suspect that the source of the third parties' funds would not comply with the requirements of the European Community's Council Directive 91/308/EEC, as amended from time to time ("EU Directive 91/308/EEC") and

(ii) it is aware of the identity of such third parties;

2.4.2 where the Distributor, after making reasonable enquiries, has satisfied itself that each third party is a person to whom an offer of Shares may properly be made, or to whom Shares may otherwise be made available;

2.5 The Distributor shall not offer or make available Shares to a US Person as defined in regulation [S] of the 1933 US Securities Act, unless the Prospectus and/or Articles of the relevant Fund provide for exceptions.

2.6 The Distributor shall not market the Shares of any Funds through the internet or otherwise make information about any Funds available through the internet without the prior written consent of the Company. To the extent that the Distributor does make information regarding any Fund available on an internet web-site, the Distributor shall ensure that the marketing via the internet is such that it could not be considered to be the marketing of any Fund in any country in which the Fund has not been registered for sale to the public.


3. Specific obligations of the Company

3.1 The Company shall make available to the Distributor, in written or by electronic means, such information as the Distributor reasonably requires to perform its duties hereunder as reasonably requested by the Distributor from time to time. The Company may post such information on a website at its discretion.

3.2 The Company shall procure that it shall keep the Distributor informed of approved changes to the investment policies of the Funds or restrictions on the distribution of Shares and any supplements relating to the Prospectus.

4. Restriction to the promotion of Shares by the Distributor

The parties further agree that the Company may, from time to time, restrict the promotion of Shares by the Distributor and limit the orders placed by or through the Distributor with respect to all or some Shares as further described in the Appointment Document to a certain amount (which may be zero) for a given period. The Distributor undertakes to abide to such restrictions. In case of breach, no remuneration is due to the Distributor for the relevant subscriptions/purchases.

5. Operating Memorandum

The Distributor shall act in accordance with the provision of the Prospectus and the Operating Memorandum in respect of subscription/purchases, switches or redemptions/sales of Shares. If the Distributor holds Shares on behalf of its customers, whether in its own name, the name of an Affiliate or a nominee name, then it, its Affiliate or its nominee, will be the legal owner of all Shares of the Funds in the account for all purposes under the terms of the relevant Fund's Prospectus.

6. Expenses

The Distributor shall not be required to meet any costs and expenses that are to be met by the Fund under the terms of the Prospectus and Articles, but shall be responsible for all other costs, including all out-of-pocket expenses incurred in connection with the promotion of the Fund.

7. Remuneration of the Distributor

The Distributor shall be entitled to such remuneration in relation to its distribution, sales of Shares and servicing of its clients, as described in the Appointment Document. All commission or remuneration payable under these Terms shall be inclusive of any tax due, in particular value added tax. Both parties may disclose such remuneration as required by the applicable laws and shall comply with applicable laws with respect to the receipt or the payment of such remuneration.

8. Representations by the Distributor

The Distributor warrants and undertakes that:

8.1 in exercising its powers and performing its duties under these Terms, it shall:

(i) observe all applicable laws and regulations; and

(ii) not contravene the provisions of the relevant Articles and of the Prospectus.

(iii) offer Shares only to persons who have duly been identified as beneficial owner in accordance with local legislation and international laws on anti-money laundering as may be in force from time to time.

8.3 it has all necessary legal, regulatory or other licenses required to conduct business in the Region and to perform its obligations under these Terms;


8.4 where the Fund is not authorised for public offering in all or part of the Region, it will only market and make the Shares available to the extent, if any, that this is permitted by applicable law to a person to whom an offer of shares can be properly made in accordance with the terms of the Prospectus;

8.5 it has full authority to enter into these Terms and recognises and agrees that these Terms shall be a valid and binding obligation on the Distributor;

8.6 whenever the Distributor is making Shares available in a non-FATF (Financial Action Task Force) jurisdiction, the Distributor undertakes to apply FATF equivalent money laundering prevention standards and to further provide, upon request by the Company, a written certification of such an undertaking and if required by a competent authority, to provide the Company with identification documents, which may include documentation to identify underlying beneficial owners(s) (e.g. as nominee or trustee). Failure to provide required documents may result in the refusal to issue Shares, the withholding of redemption proceeds and/or commissions and/or the inability to effect further transactions.

8.7 it is aware of any tax implications arising from its involvement in the Distribution of Shares and will act in compliance therewith, as described in these Terms;

8.8 it will not hold itself out to any third party as having the authority to act as a representative of the Company or of the Fund;

8.9 it will not initiate or permit any transactions which it knows to be, or has reason to believe to be, related to Market Timing; and

8.10 it will comply with the cut-off time set out in the Prospectus and to ensure in any event that all orders sent to the Company for execution at that day's net asset value are only those which are received before the cut-off time. The Distributor acknowledges the right of the Company to process any orders received after the relevant cut-off time on the following business day.

9. EU Tax Considerations [APPLICABLE ONLY IF COMPANY IS DOMILCILED IN THE EUROPEAN UNION]

The Distributor understands that for the purposes of the EU Savings Directive (EU Directive 2003/48 of June 3, 2003) and implementing legislation, the Company is required to determine whether the Company is acting as paying agent as further described in the Appointment Document. Upon request of the Company, the Distributor agrees to provide all information that the Company may require to comply with its obligations under any implementing legislation of the EU Savings Directive.

10. Liability and Indemnification

10.1 Neither party shall be held liable for any actions, costs, damages, expenses or reasonable legal fees incurred by the other, its officers or employees save to the extent these are caused by negligence, bad faith, fraudulent behaviour, wilful default or otherwise any breach of these Terms.

10.2 Both parties agree and undertake to indemnify and hold harmless each other and their respective agents, officers and employees against any actions, costs, damages, expenses, proceeds and reasonable legal fees ("Claims") arising out of any breach by either party of these Terms or of any failure by either party to comply with all applicable laws and regulations, save to the extent that the Claims arise as a result of the negligence, bad faith, fraudulent behaviour, wilful default or otherwise any breach of these Terms by either party or any of their agents, officers or employees.

10.3 In the event paragraph 10.2 is invoked, neither party shall admit liability to a third party with respect to Claims arising and shall not accept or pay or compromise any such actions, proceedings, claims and liabilities without the prior written consent of the other party.

10.4 Neither party shall be liable for any loss caused by a delay in performing or a failure to perform their obligations under these Terms, if such a delay or failure results from events or circumstances beyond their reasonable control, which constitutes "force majeure" events.


10.5 Neither party shall be liable to the other for any special, indirect, incidental, punitive or consequential damages whether foreseeable, known or otherwise.

11. Assignment

A party may assign this Agreement in whole or in part only with the prior written consent of the other party. However, the Company may, but only with the prior notice to the other party, assign this Agreement to another entity belonging to its group.

12. Intellectual property rights

The use of names, trade marks and other intellectual property matters is addressed in the Appointment Document.

13. Termination

13.1 Either party shall be entitled to terminate these Terms by giving not less than 30 days' notice in writing.

13.2 Notwithstanding the provisions of Clause 13.1, these Terms may be terminated forthwith by one party giving notice in writing to the other in the event that:

(i) the recipient of the notice has commenced liquidation or any analogous process (except a voluntary liquidation for the purpose of reconstruction or amalgamation upon terms previously approved in writing by the other party) or is unable to pay its debts or if a receiver is appointed of any of the assets of the recipient or if the recipient shall cease to be authorised to act as contemplated by these Terms;

(ii) the recipient of the notice has committed a material breach of its obligations under these Terms and (if such breach shall be capable of remedy) has failed within 30 days of a written request from the other party to make good such breach.

13.3 Termination is without prejudice to transactions already initiated under these Terms which will be dealt with in accordance with these Terms. On termination of these Terms, the Distributor shall be entitled to receive all fees and other monies accrued prior to such termination but shall not be entitled to compensation in respect of such termination.

14. Confidentiality

14.1 Each party shall treat as strictly confidential all information received or obtained as a result of entering into or performing these Terms which relates to the subject matter of these Terms or the other party. However, each party may disclose information which would otherwise be confidential, if required by applicable laws and regulations. For the avoidance of doubt, the appointment of Distributor under this Agreement and any information which is publicly available regarding the Company or the Funds, is not covered by this clause.

14.2 In addition, the Distributor authorises that any data supplied to the Company under these Terms may be disclosed by the Company to any affiliate of the Company and other parties which intervene in their business relationship (e.g. external processing centres, dispatch or payment agents) including companies based in countries where data protection laws might not exist or be of a lower standard than in the EU.

14.3 Each party undertakes to take such steps as are necessary to ensure that in relation to the performance of its functions under these Terms, it complies with all relevant data protection legislation.

14.4 The restrictions contained in this clause shall continue to apply after the termination of these Terms without limit in time.


15. Notices

Any notice or other communication given or made under these Terms shall be in writing and sent by ordinary post, registered mail, personal delivery, electronic mail or facsimile to the relevant address included in the Appointment Document.

16. Variation

These Terms can only be modified by a document in writing signed by both parties.

17. Severance

The possible nullity or invalid nature of any of the provisions contained within these Terms shall not affect the validity of the remaining provisions. Furthermore, the parties shall endeavour to replace the void provision by another of equivalent economic effect.

18. Governing law

These Terms shall be governed by and construed in accordance with the laws indicated in the Appointment Document and the parties submit to the exclusive jurisdiction of the courts indicated in the Appointment Document.


Part 3: Synoptic chart for commercial terms

Agreement Company Name

PostalAddress AddressLine

PostalCode

Country

Counterparty Name

AgreementID

ExecutionDate

MasterAgreementVersion

CounterpartyCapacity Distributor

Dealer

FinalBeneficialOwner

FundofFunds

PlacementAgent

SubNetworksAllowedCountry

Version

CountrySchedule

GoveriningLaw

JurisdictionCourts

AddressLine

PostalAddress AddressLine

PostalCode

Country

AddressLine

Legend

Iteration: use zero or more times

Option: use only once or not at all

Recursion: use at least once and as many more times as necessary

Selection: use only one of options

ProductSet ProductSetID

ISIN

Name

ISIN

Name

Markets Region

Country

RegionID

Country


ISIN

Name

ISIN

Name

Country

ISIN

ProductSetID

Rebates RebateSet RebateSetID

RebateTermStartDate Date

FirstInvestment

RebateTermEndDate Date

Open

Products ProductSet

PaymentCurrency

ISIN

AppliedLookup RebateApplied

LookupOnly

HoldingAccountSetID

HoldingAccount

Holdings HoldingAccountSet

AccountTypeDefineLater

AccountNumber

Euroclear

FundSettle

Other

Clearstream

CentralTransferAgency

Name

Name

HoldingValue

Quarterly

SemiAnnual

Annual

SharedAccount

PeriodEndHolding

DailyHolding

PeriodAverageHolding

MonthlyPeriodAverageHolding

QuarterlyPeriodAverageHolding

GrossSalesValue

NetSalesValue

HoldingUpdateFrequency Monthly

PaymentFrequency

AccountTypeHoldingAccount

AccountNumber

Euroclear

FundSettle

Other

Clearstream

CentralTransferAgency

AppliedLookup RebateApplied

LookupOnly

Monthly

Quarterly

Annual

DistributionFee

TotalExpenseRatio

SemiAnnual

Daily

CombinationFee

PeriodDays

CalendarDays366

BusinessDays

30

CalendarDays365

CalendarDays366

BusinessDays

360

Percentage

SlidingScale

BasisPoints

FlatBand

RebateFee ManagementFee

CalculationFrequency

CalendarDays365

YearDays

RebateMethod

RebateRateType

RebateRateTable LookupFrequency

Rows

Currency

Rate

Ceiling

Floor

Monthly

Quarterly

SemiAnnual

Annual

HoldingValue

PeriodEndHolding

DailyHolding

PeriodAverageHolding

MonthlyPeriodAverageHolding

QuarterlyPeriodAverageHolding

GrossSalesValue

NetSalesValue

Monthly

Quarterly

SemiAnnual

Annual

SharedAccount

HoldingUpdateFrequency

SettlementWithin

RetrospectiveAdjustmentPeriod

Number

BusinessDaysOther

CalendarDays

Number

Payments

ReinvestFunds

PaymentType FrontEndLoad

Rebate

GeneralPayment

ProRata

DeMinimisEarnings

DeMinimisPayment

DeMinimisEarningsCurrency

DeMinimisEarningsThreshold

DeMinimisPaymentCurrency

DeMinimisPaymentThreshold

Months

Years

Other

AccountType CentralTransferAgency

ClearstreamAccountNumber

Ratio

Name

ISIN

FundSettle

Euroclear

Other

Daily

Monthly

Quarterly

SemiAnnual

Annual

SingleAccount

ReinvestFundSet AccountType CentralTransferAgency

ClearstreamAccountNumber

FundSettle

Euroclear

Other

Ratio

Name

ISIN

Cheque Currency

AddressLine

AddressLine

PostalCode

Country

ReportMethod

PostalAddress

PaymentReference

Reports

Reference

SpecialInstructions

CompanyContactPerson ContactPerson

SpecialInstructions

CounterpartyContactPerson ContactPerson

SpecialInstructions

AddressLine

AddressLine

PostalCode

Country

Postal

PostalAddress

Email

EmailAddress

Fax

FaxNumber

BeneficiaryName

BankTransfer Currency

BeneficiaryAccountName

BeneficiarySWIFT_BIC_Code

BeneficiaryAccountNumber

BeneficiaryBankSWIFT_BIC_Code

BeneficiaryBankBranchNumber

BeneficiaryBankName

BeneficiaryBankAddress

CorrespondentBankName

PaymentReference

CorrespondentBankSWIFT_BIC_Code

CorrespondentBankAccountNumber

DeMinimisPaymentThreshold

FrontEndLoad

Payment Currency


Name

Name

ISIN

ISIN

PaymentFrequency

SettlementWithin

RetrospectiveAdjustmentPeriod

DeMinimisPayment

Monthly

Quarterly

SemiAnnual

Annual

Number

BusinessDaysOther

CalendarDays

Number

Other

DeMinimisPaymentCurrency

Months

Years

FrontEndLoadSet FrontEndLoadSetID

Discount

CounterpartyShare

CompanyShare

DealAtNAV


Part 4: Syntax for commercial terms

Introduction

The syntax defines a simple set of rules to describe mutual fund sales terms. For example, the first and most important rule is:

Agreement =

Company, Counterparty, AgreementID, ExecutionDate, MasterAgreementVersion, {CountrySchedule}, GoverningLaw, JurisdictionCourts, {ProductSet}, Markets, FrontEndLoad, [Rebates], [Payments], Reports, CompanyContactPerson, CounterpartyContactPerson;

which means that a mutual fund sales agreement is defined by the company and the counterparty who made it; an agreement identification number; an execution date; a master agreement to which it adheres with optional country-specific schedules; a governing law; a declaration of the jurisdiction to whose courts the parties will submit, etc.

Rules have a left-hand-side, a right-hand-side and a separation character "=", which indicates that the left-hand-side of the rule has the meaning given by the terms on the right-hand-side. We have commonly used the following forms of control in our rules:

Sequence Items appear in a rule from left to right, separated by commas; their order is important.

Choice Alternative items are separated by the "|" character. One item is chosen from the list of alternatives; their order is not important.

Option Optional items are enclosed between the characters "[" and "]"; the item can be included or discarded.

Repetition A repeatable item is enclosed between the characters "{" and "}"; the item can be repeated zero or more times.

The rules also use the following special characters:

Quotation A term enclosed within quotes stands for itself. For example, 'Clearstream' means Clearstream Bank.

Group Some terms are grouped together in round brackets (like this) in order to make a rule easier to read.

Termination A semi-colon ";" is used to mark the end of a rule.

Line breaks are sometimes used to make the rules easier to read; they have no special meaning. More information about how to read the rules can be found in ISO/IEC 14977, which is available on the Internet, and with which this document complies.

Whilst these rules look like a computer programming language, they are not. They are a simple and concise way to describe the information that parties exchange when they contract a mutual fund sales agreement. With a little effort, they are easy to read and understand.


The rules in alphabetic order

Agreement = Company, Counterparty, AgreementID, ExecutionDate, MasterAgreementVersion, {CountrySchedule}, GoverningLaw, JurisdictionCourts, ProductSet, {ProductSet}, Markets, FrontEndLoad, [Rebates], [Payments], Reports, CompanyContactPerson, CounterpartyContactPerson;

AccountType = 'CentralTransferAgency' | 'Clearstream' | 'Euroclear' | 'FundSettle' | 'Other';

AppliedLookup = 'RebateApplied' | 'LookupOnly';

BankTransfer = Currency, BeneficiaryAccountName, [BeneficiarySWIFT_BIC_Code], BeneficiaryAccountNumber, BeneficiaryBankSWIFT_BIC_Code, [BeneficiaryBankBranchNumber], [BeneficiaryBankName], [BeneficiaryBankAddress], {PaymentReference}, [CorrespondentBankSWIFT_BIC_Code, [CorrespondentBankName], [CorrespondentBankAccountNumber]];

CalculationFrequency = Frequency;

Cheque = Currency, BeneficiaryName, PostalAddress, {PaymentReference};

Company = Name, PostalAddress;

CompanyContactPerson = ContactPerson, [SpecialInstructions], [CompanyContactPerson];

Counterparty = Name, PostalAddress, CounterpartyCapacity;

CounterpartyCapacity = (('Distributor', ['SubNetworksAllowed']) | 'Dealer' | 'FinalBeneficialOwner' | 'FundofFunds' | 'PlacementAgent'), [CounterpartyCapacity];

CounterpartyContactPerson = ContactPerson, [SpecialInstructions], [CounterpartyContactPerson];

CountrySchedule = Country, Version;

DeMinimisEarnings = DeMinimisEarningsCurrency, DeMinimisEarningsThreshold;

DeMinimisPayment = DeMinimisPaymentCurrency, DeMinimisPaymentThreshold;

Frequency = 'Daily' | 'Monthly' | 'Quarterly' | 'SemiAnnual' | 'Annual';

FrontEndLoad = 'DealAtNAV' | (FrontEndLoadSet, [PaymentCurrency, PaymentFrequency, [SettlementWithin], [RetrospectiveAdjustmentPeriod], [DeMinimisPayment]]);

FrontEndLoadSet = [FrontEndLoadSetID], Discount, CounterpartyShare, CompanyShare {ProductSet}, [FrontEndLoadset];

HoldingAccount = AccountType, AccountNumber, HoldingValue, ['SharedAccount', [HoldingUpdateFrequency]];

HoldingAccountSet = [HoldingAccountSetID], HoldingAccount, {HoldingAccount};

Holdings = HoldingAccountSet, AppliedLookup, [Holdings];

HoldingValue = 'DailyHolding' | 'PeriodEndHolding' | 'PeriodAverageHolding' | 'MonthlyPeriodAverageHolding' | 'QuarterlyPeriodAverageHolding' | 'GrossSalesValue' | 'NetSalesValue';

Markets = (Region | Country), [Markets];

PaymentCurrency = 'ShareclassCurrency' | SingleCurrency;

PaymentFrequency = Frequency - 'Daily';

Payments = PaymentType, (ReinvestFunds | BankTransfer | Cheque), [Payments];

PaymentType = 'FrontEndLoad' | 'Rebate' | 'GeneralPayment';

PeriodDays = 'CalendarDays365' | 'CalendarDays366' | 'BusinessDays' | '30';

PostalAddress = AddressLine, {AddressLine}, PostalCode, Country;

Products = ProductSet, AppliedLookup, [Products];

ProductSet = [ProductSetID], (ISIN, [Name]), {ISIN, [Name]};

RebateFee = 'ManagementFee' | 'DistributionFee' | 'CombinationFee' | 'TotalExpenseRatio';

RebateMethod = 'BasisPoints' | 'Percentage';

RebateRateTable = [LookupFrequency], Currency, Rows;

RebateRateType = 'FlatBand' | 'SlidingScale';

Rebates = RebateSet, PaymentCurrency, PaymentFrequency, [SettlementWithin], [RetrospectiveAdjustmentPeriod], [DeMinimisEarnings], [DeMinimisPayment], [Rebates];


RebateSet = [RebateSetID], RebateTermStartDate, RebateTermEndDate, Products, (Holdings | 'DefineLater'), RebateFee, CalculationFrequency, PeriodDays, YearDays, RebateMethod, RebateRateType, RebateRateTable, [RebateSet];

RebateTermEndDate = Date | 'Open';

RebateTermStartDate = Date | 'FirstInvestment';

Region = [RegionID], Country, {Country};

ReinvestFunds = 'ProRata' | ('SingleAccount', AccountType, AccountNumber) | ReinvestFundSet;

ReinvestFundSet = AccountType, AccountNumber, (ISIN, [Name], Ratio), {ISIN, [Name], Ratio}, [ReinvestFundSet];

ReportMethod = (('Postal', PostalAddress) | ('Email', EmailAddress) | ('Fax', FaxNumber)), [ReportMethod];

Reports = ReportMethod, {Reference}, [SpecialInstructions], [Reports];

RetrospectiveAdjustmentPeriod = (Number, 'Months' | 'Years') | Other;

Rows = Floor, [Ceiling], Rate, [Rows];

SettlementWithin = (Number, 'BusinessDays' | 'CalendarDays') | Other;

YearDays = 'CalendarDays365' | 'CalendarDays366' | 'BusinessDays' | '360';


Part 5: Standard rebate formula

This section presents a standard formula for mutual fund commission calculations. Note that a firm's ability to differentiate itself from its competitors lies in the operands that it chooses to use with the formula, not in the formula itself. There is therefore no barrier to standardisation in this part of the mutual fund industry.

Formula:

∑=

=

××=nFrequencyCalculatio

quencyPaymentFrei

1iii YearDays

PeriodDaysRateueHoldingValrebatesofvaluetheount,HoldingAcceachinISINeachFor

Where:

The upper limits of "i" are set by the respective values of PaymentFrequency and CalculationFrequency in the Agreement as follows:

PaymentFrequency

Monthly Quarterly SemiAnnual Annual

Daily CalendarDays |BusinessDays

CalendarDays |BusinessDays

CalendarDays | BusinessDays

CalendarDays |BusinessDays

Monthly 1 3 6 12

Quarterly Not applicable 1 2 4

SemiAnnual Not applicable Not applicable 1 2

Cal

cula

tionF

requ

ency

Annual Not applicable Not applicable Not applicable 1

The appropriate upper limit of "i" for daily calculations is the number of calendar days or business days

in the relevant period, determined by the value of PeriodDays specified in the Agreement as follows:

― if PeriodDays = CalendarDays365, count every calendar day in the period except 29 February;

― if PeriodDays = CalendarDays366, count every calendar day in the period, including 29 February;

― if PeriodDays = BusinessDays, count every day on which the relevant fund's NAV is struck.

And where "i" means:

― for HoldingValue, the ith day, month or quarter within the period, and;

for Rate, the weighted average rebate rate that is determined by reading the RebateRateTable at the LookupFrequency specified in the Agreement or, if LookupFrequency is not defined, at the CalculationFrequency specified in the Agreement.


Part 6: Detailed specification for commercial terms Rule

Agreement = Company, Counterparty, AgreementID, ExecutionDate, MasterAgreementVersion, {CountrySchedule}, GoverningLaw, JurisdictionCourts, ProductSet, {ProductSet}, Markets, FrontEndLoad, [Rebates], [Payments], Reports, CompanyContactPerson, CounterpartyContactPerson;

Synopsis

A mutual fund sales agreement is defined by the following elements:

Company The promoter of the funds. Counterparty The distributor of the funds or the buyer in some other capacity. AgreementID The unique identifier that the Company gives to the agreement. ExecutionDate The date upon which the agreement was executed. MasterAgreementVersion The terms of the master agreement (industry standard terms) under which it was contracted. CountrySchedule The terms of the country-specific schedules (industry standard terms) under which it was contracted. GoverningLaw The laws of the jurisdiction under which the agreement was made. JurisdictionCourts The courts of the jurisdiction to which the parties will submit. ProductSet The products that the Company grants the Counterparty rights to in the Markets. Markets The markets in which the Company grants the Counterparty rights to act. FrontEndLoad The front-end load that the Company will pay to the Counterparty. Rebates The rebates (ongoing commissions) that the Company will pay to the Counterparty. Payments The means by which the Company will pay front-end load and rebates to the Counterparty. Reports The means by which the Company will report front-end load and rebates to the Counterparty. CompanyContactPerson The people in the Company who may be contacted in respect of this agreement. CounterpartyContactPerson The people in the Counterparty who may be contacted in respect of this agreement

Typology and constraints

AgreementID: ISO 20022 Max256Text, must uniquely identify an Agreement between the parties ExecutionDate: ISO 20022 ISODate. MasterAgreementVersion: ISO 20022 Max35Text. GoverningLaw: ISO 20022 CountryCode. JurisdictionCourts: ISO 20022 CountryCode.

All other elements are defined in this paper.

User guide

This is the root of the DMFSA rule set.

In respect of the MasterAgreementVersion, a governing body will issue and control a master agreement in a similar manner to the ISDA master agreement under which derivatives are purchased. The version number will identify which edition of the master agreement was used by the parties when they contracted their mutual fund sales agreement.

The Agreement implies that the Counterparty will enjoy equal rights over every product in ProductSet in all Markets subject to its CounterpartyCapacity and regulatory restrictions (for example, a fund may not be sold to the public unless it has been registered for that purpose with the relevant authority; that is why this specification does not explicitly say whether, if the Counterparty is a distributor, it is restricted to private placement or free to sell the Company's funds by public offer). The rights to receive rebates are separately described for each product.

The purpose of the ProductSet ("A") in this rule is to grant the Counterparty certain rights over those products in the Markets. The ProductSet(s) defined under the rule FrontEndLoadSet will be a sub-set of A. The ProductSet(s) ("R") defined under the rule RebateSet may be a sub-set of A or may only intersect A. That is because R may contain products in respect of which the Counterparty's only right is to have its holdings in them recognised when setting the rate at which rebates will be paid on its eligible holdings in the intersection of A and R.

Rebates are optional because it is possible that some fund sales agreements are made on terms that do not require the Company to pay rebates to the Counterparty. Payments is optional because, if no rebates are defined or if the rule FrontEndLoad states that the Company's transfer agent will place deals at NAV, no payments will be necessary.

Industry consultation questions

Comments requested.


Rule

AccountType = 'CentralTransferAgency' | 'Clearstream' | 'Euroclear' | 'FundSettle' | Other;

Synopsis

An account can be held at the Company's central transfer agency or at a clearing house.


CentralTransferAgency: Constant, meaning that the "account" is at the fund's central transfer agent Clearstream: Constant, meaning that the account is at Clearstream Euroclear: Constant, meaning that the account is at Euroclear Fundsettle: Constant, meaning that the account is at Fundsettle Other ISO 20022 Max2000Text, meaning that the account is at some other place described in the text

User guide

This rule is used by the Company's commission agent to locate an account to determine its holdings, which will be used to determine the front-end load and rebates payable to the Counterparty.

A central transfer agency account might mean an individual account or an agent code or some other form of group identifier that identifies the Counterparty's investments with sufficient precision to support the commission process.


Is this definition satisfactory for Companies that employ more than one transfer agency?

Rule

AppliedLookup = 'RebateApplied' | 'LookupOnly';

Synopsis

For each ProductSet and for each HoldingAccount, AppliedLookup indicates whether rebates should be applied to it or whether it should only be used by the rule RebateRateTable to set the rebate rate.


AppliedLookup is an enumerated type with two members: 'RebateApplied' and 'LookupOnly'.

User guide

This rule permits an agreement to recognise a Counterparty's entire holding of the Company's funds when setting the rate at which rebates will be paid on a specific set of holdings.

For example, if bond funds were marked RateApplied and equity funds were marked LookupOnly, the Company would pay rebates on bond funds at a rate determined by the Counterparty's holdings of bond funds and equity funds.


Comments requested.


Rule

BankTransfer = Currency, BeneficiaryAccountName, [BeneficiarySWIFT_BIC_Code], BeneficiaryAccountNumber, BeneficiaryBankSWIFT_BIC_Code, [BeneficiaryBankBranchNumber], [BeneficiaryBankName], [BeneficiaryBankAddress], {PaymentReference}, [CorrespondentBankSWIFT_BIC_Code, [CorrespondentBankName], [CorrespondentBankAccountNumber]];

Synopsis

Describes one or more bank accounts to which the Company will make cash payments in respect of the front-end loads and rebates due under the terms of the agreement.

Currency The currency in which the account is denominated. BeneficiaryAccountName The account name. BeneficiarySWIFT_BIC_Code The Counterparty's SWIFT/BIC. BeneficiaryAccountNumber The account's number. BeneficiaryBankSWIFT_BIC_Code The SWIFT/BIC of the bank at which the account is held. BeneficiaryBankBranchNumber The branch number of the bank at which the account is held. BeneficiaryBankName The name of the bank at which the account is held. BeneficiaryBankAddress The address of the bank at which the account is held. PaymentReference The reference that the parties have agreed to attach to each payment. CorrespondentBankSWIFT_BIC_Code The SWIFT/BIC of the Counterparty's correspondent bank. CorrespondentBankName The name of the correspondent bank, if one is used. CorrespondentBankAccountNumber The number of the account at the correspondent bank.


Currency ISO 20022 CurrencyCode. BeneficiaryAccountName ISO 20022 Max70Text. BeneficiarySWIFT_BIC_Code ISO 20022 BICIdentifier. BeneficiaryAccountNumber ISO 20022 Max70Text, which could be proprietary or standardised (e.g., IBAN). BeneficiaryBankSWIFT_BIC_Code ISO 20022 BICIdentifier. BeneficiaryBankBranchNumber ISO 20022 Max35Text. BeneficiaryBankName ISO 20022 Max70Text. BeneficiaryBankAddress PostalAddress, defined in this document. PaymentReference ISO 20022 Max35Text. CorrespondentBankSWIFT_BIC_Code ISO 20022 BICIdentifier. CorrespondentBankName ISO 20022 Max70Text. CorrespondentBankAccountNumber ISO 20022 Max70Text.

User guide

PaymentReference may be a static reference defined when the agreement is contracted or a list of RebateIDs or some other indicator that the Company may add to a payment instruction to help the Counterparty or its correspondent bank trace the payment to the agreement and the underlying products or holding accounts.

This rule has been defined to satisfy the requirements of Companies that make payments throughout the world.


This rule declares the term BeneficiaryBankSWIFT_BIC_Code to be compulsory and the term BeneficiaryBankBranchNumber to be optional. Would that create a problem for industry participants who make payments to counterparties whose banks don't use SWIFT (e.g., banks who communicate using tested telex)?


Rule

CalculationFrequency = Frequency;

Synopsis

Describes the frequency at which the rebate calculations are performed.


Frequency is defined in this document.

PaymentFrequency <= LookupFrequency <= CalculationFrequency, where the symbol "<=" means that the term on the left hand side must be equal to or less frequent than the term on the right hand side.

User guide

The parties to an agreement may choose to perform rebate calculations with varying frequency, typically as often as daily, but sometimes as infrequently as annually. The following values of CalculationFrequency are compatible with the respective values of HoldingValue:

CalculationFrequency: Daily Monthly Quarterly SemiAnnual Annual

DailyHolding PeriodEndHolding PeriodAverageHolding MonthlyPeriodAverageHolding QuarterlyPeriodAverageHolding GrossSalesValue NetSalesValue

Note that when CalculationFrequency is "Daily", the HoldingValues "DailyHolding" and "PeriodEndHolding" are synonymous.

See also the user guide for the rule HoldingValue.


Comments requested.

Rule

Cheque = Currency, BeneficiaryName, PostalAddress, {PaymentReference};

Synopsis

Describes how the Company will pay front-end load and rebates to the party by one or more cheques using the following information:

Currency The currency in which the cheque is to be issued. BeneficiaryName The person to whom the cheque will be payable. PostalAddress The address to which the cheque should be sent. PaymentReference The reference that the parties have agreed to attach to the advice note covering each cheque.


Currency: ISO 20022 CurrencyCode BeneficiaryName: ISO 20022 Max70Text. PostalAddress: Defined in this document. PaymentReference: ISO 20022 Max35Text.

User guide

Cheques are uncommon but some countries still use them, and so this scheme must define a rule by which they can be used.

PaymentReference may be a static reference defined when the agreement is contracted or a list of RebateIDs or some other indicator that the Company may add to a payment instruction to help the Counterparty trace the payment to the agreement and the underlying products or holding accounts.

Payments could be made separately according to the parties' preferences for arranging their business functionally, geographically or by product, or to keep rebates separate from front-end loads.


Comments requested.


Rule

Company = Name, PostalAddress;

Synopsis

Define the name and address of the Company.


Name: ISO 20022 Max350Text. PostalAddress: Defined in this paper.

User guide

Not defined.


Is it acceptable to admit only two parties to each Agreement? If more parties should be admitted, in what capacities would they act?

Rule

CompanyContactPerson = ContactPerson, [SpecialInstructions], [CompanyContactPerson];

Synopsis

Describe the people within the Company who may be contacted about the agreement.


ContactPerson: ISO 20022 ContactIdentification1. SpecialInstructions: ISO 20022 Max2000Text.

User guide

ISO 20022 ContactIdentification1 describes a person's Name, NamePrefix, GivenName, Role, PhoneNumber, FaxNumber, and EmailAddress.

Use the SpecialInstructions field to give short instructions such as, "Send legal notices here".


Comments requested.

Rule

Counterparty = Name, PostalAddress, CounterpartyCapacity;

Synopsis

Define the name and address of the Counterparty and the capacity in which it acts under the terms of this agreement.


Name: ISO 20022 Max350Text. PostalAddress: Defined in this paper. CounterpartyCapacity: Defined in this paper.

User guide

A Counterparty must act in at least one capacity and it may act in several capacities.


Comments requested.


Rule

CounterpartyCapacity = (('Distributor', ['SubNetworksAllowed']) | 'Dealer' |'FinalBeneficialOwner' | 'FundofFunds' | 'PlacementAgent'), [CounterpartyCapacity];

Synopsis

The Counterparty may act in one or more capacities with respect to the Company's funds. If the Counterparty is acting as distributor, its right to establish sub-distribution networks is indicated by the inclusion of the term "SubNetworksAllowed".


CounterpartyCapacity is an enumerated type with the following members: 'Distributor', 'SubNetworksAllowed', 'Dealer', 'FinalBeneficialOwner, FundofFunds and 'PlacementAgent'.

User guide

A distributor is a party who purchases shares in the Company's funds in its own name with the intention of selling them on to third parties.

A dealer is a party who purchases shares in the Company's funds in the name of a third party.

The term "SubNetworksAllowed" means that the Company grants the Counterparty the right to enter into sub-distribution agreements with third parties, including entities that are not its subsidiaries or affiliates, for the purpose of selling shares or units in the Company's funds. The root of these sub-networks will be within the Counterparty's operations and will not be visible to the Company. If the Company and the Counterparty wish to agree special terms for the establishment of sub-networks, they should do so through a side-agreement.

A final beneficial owner is a party who purchases shares for their own account.

A fund of funds is a party that is an investment fund seeking to invest in the Company's funds.

A placement agent is a party that acts in an agency capacity only, placing orders on behalf of third parties.


Are these definitions correct and in what capacity would the following parties act, and do we simply need another class of counterparty, "purchaser", under which they may buy shares or units in funds for their own account: family office, corporate treasurer, pension fund, etc?

Rule

CounterpartyContactPerson = ContactPerson, [SpecialInstructions], [CounterpartyContactPerson];

Synopsis

Describe the people within the Counterparty who may be contacted about the agreement.


See CompanyContactPerson.

User guide

See CompanyContactPerson.


Comments requested.


Rule

CountrySchedule = Country, Version;

Synopsis

Describes the country-specific schedules under the terms of which the agreement is to be contracted.


Country: ISO 20022 CountryCode. Version: ISO 20022 Max30Text.

The values of Country and Version should be unique for each edition of a CountrySchedule.

CountrySchedules should be issued by the same industry body that issues and controls the master agreement.

User guide

A CountrySchedule is an addendum to the industry-standard master agreement upon the terms of which agreements will be contracted. It will be issued and controlled by the same industry body that will issue and control the master agreement upon which this scheme will be based. The Version is used uniquely to identify different editions of a CountrySchedule.

A CountrySchedule will contain terms that are required by regulation or industry rules in a country, without which a fund sales agreement for that country cannot be defined, but which are not suitable for inclusion in the global master agreement.


Comments requested.

Rule

DeMinimisEarnings = DeMinimisEarningsCurrency, DeMinimisEarningsThreshold;

Synopsis

Determine whether the Counterparty is entitled to receive rebates on its holdings:

DeMinimisEarningsCurrency: Earnings might be in several currencies and must be converted to a single currency to perform the test. DeMinimisEarningsThreshold: The threshold below which rebates will be forfeit.


DeMinimisEarningsCurrency: ISO 20022 CurrencyCode. DeMinimisEarningsThreshold: Integer, >= 0.

User guide

DeMinimisEarnings is a test of the total earnings on the Counterparty's holdings, and is intended to ensure that the Counterparty earns commissions only if its holdings are commercially significant. If the DeMinimisEarningsThreshold is not exceeded, the Counterparty will earn no rebates on its holdings.

See also DeMinimisPayment.


Comments requested.


Rule

DeMinimisPayment = DeMinimisPaymentCurrency, DeMinimisPaymentThreshold;

Synopsis

Determine when the Counterparty will be paid front-end load and rebates on its holdings:

DeMinimisPaymentCurrency: Payment might be in several currencies and must be converted to a single currency to perform the test. DeMinimisPaymentThreshold: The threshold below which amounts will not be paid but will be carried forward on account.


DeMinimisEarningsCurrency: ISO 20022 CurrencyCode. DeMinimisEarningsThreshold: Integer, >= 0.

User guide

The test of whether the Counterparty is eligible to earn front-end load and rebates on its holdings is performed by the rule DeMinimisEarnings. This rule DeMinimisPayment is used to ensure that payments are generally made for commercially sensible amounts, above a threshold that is set by the parties to the agreement. The test is to be applied on the aggregate (i.e., total) amount due to the Counterparty.

Note that we do not apply the previous rule, DeMinimisEarnings, to front-end load because it is automatically deducted at the point of sale. However, we do apply the rule DeMinimisPayment because payment amounts might fall below a commercially reasonable level.


Comments requested.

Rule

Frequency = 'Daily' | 'Monthly' | 'Quarterly' | 'SemiAnnual' | 'Annual';

Synopsis

Determine the frequency at which certain processes will run.


Frequency is an enumerated type with five members: 'Daily', 'Monthly', 'Quarterly', 'SemiAnnual', 'Annual'.

User guide

Not defined.


Comments requested.


Rule

FrontEndLoad = 'DealAtNAV' | (FrontEndLoadSet, [PaymentCurrency, PaymentFrequency, [SettlementWithin], [RetrospectiveAdjustmentPeriod], [DeMinimisPayment]]);

Synopsis

Define whether a front-end load is payable and at what rate and under what conditions:

DealAtNAV The Company's transfer agent will place all deals at NAV. FrontEndLoadSet How is front-end load calculated and is it paid on all products or only upon a named set of products? PaymentCurrency Payment is to be made in the currencies of the relevant share classes or in a single currency. PaymentFrequency With an agreed frequency. SettlementWithin Within an agreed settlement deadline. RetrospectiveAdjustmentPeriod Permitting adjustments to be made within a certain period. DeMinimisPayment Provided that the amounts to be paid must exceed a certain threshold.


DealAtNAV: Constant, meaning that the Company's transfer agent must place all deals at NAV. All terms are defined in this document.

User guide

FrontEndLoad may be used in the following ways:

1. Front-end load is managed exclusively by the Counterparty. The term 'DealAtNAV' is selected within the rule FrontEndLoad. The Counterparty may charge front-end load up to the maximum rate defined in the prospectus. The fund's central transfer agent will process shareholder deals at the NAV per share on dealing day.

2. Front-end load is managed exclusively by the Company, which may allocate it to one or more of (i) the investor who placed the deal, (ii) the Counterparty, and (iii) the Company. The term 'DealAtNAV' is not selected and remainder of the rule FrontEndLoad is used. The allocation is described in more detail in the rule FrontEndLoadSet.

The terms by which the Company remits front-end loads to the Counterparty are defined in this rule rather than in the rule FrontEndLoad set because the payment terms will be constant for several different front-end load sets (which might be defined for bond funds, equity funds, for example).

Note that selecting the term 'DealAtNAV' in this rule does not necessarily have exactly the same financial effect as setting "Discount" to 100 in the rule FrontEndLoadSet; that depends upon the operational practices within the Counterparty and the Company's back offices.


Comments requested.


Rule

FrontEndLoadSet = [FrontEndLoadSetID], Discount, CounterpartyShare, CompanyShare, {ProductSet}, [FrontEndLoadSet];

Synopsis

Define how front-end load is to be calculated and whether it is paid on all products or only upon a named set of products:

FrontEndLoadSetID A unique identifier that allows the parties to the agreement to refer easily to a FrontEndLoadSet. Discount The amount of the front-end load that is due to the investor who placed the deal. CounterpartyShare The amount of the front-end load that is due to the Counterparty. CompanyShare The amount of the front-end load that it due to the Company. ProductSet The list of products to which front-end load is to be restricted. See user guide below.


FrontEndLoadSetID ISO 20022 Max30Text Discount: ISO 20022 PercentageRate, >=0; <= 100. CounterpartyShare: ISO 20022 PercentageRate, >= 0; <= 100. CompanyShare: ISO 20022 PercentageRate, >= 0; <= 100. ProductSet: Defined in this document.

Discount + CounterpartyShare + CompanyShare == 100% == maximum front-end load permitted by the prospectus.

User guide

If it is applied by the Company, front-end load will by default be calculated on every subscription that the counterparty makes on every product. If the parties wish to restrict front-end load to one or more products or to apply different rates to different products, they should list them in the ProductSet, and define as many different FrontEndLoadSets as are necessary to meet their needs.

The amounts of front-end load collected by the Company's transfer agent may be allocated between the investor, the Counterparty and the Company. Provided that it is not zero, the Discount will be used to buy shares for the investor's account. How that is represented on the investor's contract note is an operational matter between the Counterparty and the Company, but it might be in one of the following ways:

(1) The Discount is implicit. The contract note will show the investor's order, including the amount of front-end load that is deducted and the net amount that is invested. The deduction will be the sum of CounterpartyShare + CompanyShare.

(2) The Discount is explicit. The investor's contract note will show two deals. The first deal will show the investor's original order, including the amount of front-end load that is deducted and the net amount that is invested. The deduction will be the sum of Discount + CounterpartyShare + CompanyShare (i.e., the maximum front-end load permitted by the prospectus). The second deal will show an investment into the same fund, for the gross value of the Discount. This technique is used to achieve the effect of a fidelity scheme in some distribution channels.


Is it necessary to define the holding accounts to which front-end load will be applied in the same way as products are defined, or are front-end loads charged on every account?

Should this rule be defined in a way that does not prevent parties from giving and accepting "forced rate" subscriptions, in which the Counterparty indicates on the subscription what Rate of front-end load should be charged, regardless of any Rate that might have been set in the Agreement?

Should FrontEndLoadSetID be an obligatory term? It would certainly make it easier to refer to a specific FrontEndloadSet.


Rule

HoldingAccount = AccountType, AccountNumber, HoldingValue, ['SharedAccount', [HoldingUpdateFrequency]];

Synopsis

Describe the accounts in respect of which the Counterparty's rebates are to be calculated:

AccountType Is the account held at the central transfer agency or Clearstream, Euroclear or Fundsettle? AccountNumber What is the account's number? HoldingValue What is the value of its holding? SharedAccount Does it have a single beneficial owner or is it shared between two or more beneficiaries? HoldingUpdateFrequency If it's a shared account, how often will the underlying beneficiaries' holdings be determined?


AccountType: Enumerated type, defined in this document. AccountNumber: Not defined. HoldingValue: Enumerated type, defined in this document. SharedAccount: Constant, meaning the holding account has more than one beneficial owner. HoldingUpdateFrequency: Frequency - 'Daily', where Frequency is defined in this document.

User guide

It is desirable to define the HoldingUpdateFrequency for shared accounts, but it is not compulsory, and commission agents will infer a frequency from HoldingValue.


What type should AccountNumber be?

Rule

HoldingAccountSet = [HoldingAccountSetID], HoldingAccount, {HoldingAccount};

Synopsis

HoldingAccounts upon which rebates are based are collected into sets of related accounts, which are defined by:

HoldingAccountSetID A unique identifier that allows the parties to the agreement to refer easily to a HoldingAccountSet. HoldingAccount The accounts that are members of the set.


HoldingAccountSetID ISO 20022 Max30Text, must be unique within the scope of the Agreement. See also the user guide. HoldingAccount: Defined in this document.

User guide

The HoldingAccountSetID is useful in the context of a sophisticated agreement in which the Counterparty's business with the Company is segmented into several groups of holding accounts, for example, in the manner that a financial group might arrange its business functionally and geographically. By giving each such group of accounts identity, the parties to the agreement can simplify how they maintain the accounts and communicate about them. Under the terms of this document, a HoldingAccountSetID has meaning only within the scope of the Agreement, within which it must be unique. If the parties wish to use a particular value of HoldingAccountSetID in several agreements, they must ensure that it is properly maintained for that purpose, in their papers or in their computer systems, if they have them. If it is to be used globally in this manner, a particular value of HoldingAccountSetID should only have meaning in the context of a particular relationship between the Company and the relevant Counterparty.

The HoldingAccountSetID is optional but its use is encouraged.


Is Max30Text long enough for HoldingAccountSetID, or would the industry prefer to have the ability to create longer names?

Should HoldingAccountSetID be an obligatory term? It would certainly make it easier to refer to a specific HoldingAccountSet.


Rule

Holdings = HoldingAccountSet, AppliedLookup, [Holdings];

Synopsis

Determine the Counterparty's holdings upon which rebates will be calculated. The holdings are in one or more HoldingAccountSets, to which the rebates will be applied or which will be taken into account when setting the rebate rates.


HoldingAccountSet: Defined in this document. AppliedLookup: Defined in this document.

User guide

The HoldingAccountSet is important when calculating commissions for Counterparties who invest in many accounts, particularly if they wish to keep their rebates functionally segregated whilst benefiting from rebate rates based on their total group holdings. However, the holding accounts might not exist at the time that the Agreement is contracted. Therefore, for whatever reason, including expediency, the parties can agree to define the holding accounts later. If the holding accounts do exist, the parties to the Agreement would be wise to specify them at the time the Agreement is first contracted.


Comments requested.


Rule

HoldingValue = 'DailyHolding' | 'PeriodEndHolding' | 'PeriodAverageHolding' | 'MonthlyPeriodAverageHolding' | 'QuarterlyPeriodAverageHolding' | 'GrossSalesValue' | 'NetSalesValue';

Synopsis

Determine how Counterparty holding values should be measured for the purpose of calculating rebates:

DailyHolding The values at the end of each day. PeriodEndHolding The values at the end of the last day in the period. PeriodAverageHolding The average of values on the last days in the previous and the current periods. MonthlyPeriodAverageHolding The average of values on the last day of each month in the period. QuarterlyPeriodAverageHolding The average of values on the last day of each quarter in the period GrossSalesValue The value of gross sales in the period. NetSalesValue The value of net sales in the period.


HoldingValue is an enumerated type with seven members.

User guide

Holding values are measured in respect of each Product in each HoldingAccount.

Most of the terms in this rule require the commission agent to know on what day to measure holding values (for example, on a business day or a calendar day, and what to do about public holidays). The agent should look to the definition of PeriodDays in the relevant RebateSet, which will declare whether commissions should be calculated on CalendarDays365, CalendarDays366, BusinessDays or standard 30-day months (in which case holdings should be measured on BusinessDays).

Some of the terms in this rule require the commission agent to know what a period's duration is. If the HoldingValue is being used to calculate a rebate amount, then the period is derived from the value of CalculationFrequency. If it is being used to lookup the applicable rate in the RebateRateTable, then the period is derived from the value of LookupFrequency (c.f. the user guide for rule RebateRateTable: if LookupFrequency is not defined then it is equal to CalculationFrequency). The following table illustrates this:

CalculationFrequency/LookupFrequency: Daily Monthly Quarterly SemiAnnual Annual

PeriodEndHolding PeriodAverageHolding MonthlyPeriodAverageHolding QuarterlyPeriodAverageHolding

For example, if CalculationFrequency is 'Monthly' and LookupFrequency is 'Quarterly' and the HoldingValue of the account is 'PeriodAverageHolding', then the commission agent would use the monthly average holding value (i.e., the average of values on the last days in the previous and the current months) to calculate rebates and the quarterly average holding value (i.e., the average of values on the last days in the previous and the current quarters) to lookup the rebate rate.

Note that for 'Daily' values of CalculationFrequency and LookupFrequency, the HoldingValues 'DailyHolding' and 'PeriodEndHolding' are synonymous.

Some of the terms in this rule require the commission agent to know on what day a period starts. In a similar manner to its duration, it is derived from the value of CalculationFrequency and/or LookupFrequency in the following way:

If the value is Monthly, each period will start on the first calendar day of each month. If the value is Quarterly, each period will start on the first calendar day of January, April, July and October. If the value is SemiAnnual, each period will start on 1 January and 1 July. If the value is Annual, each period will start on 1 January.

If the RebateTermStartDate or the RebateTermEndDate does not coincide with the first or last day of a period respectively, the commission agent must manually adjust the first or last calculation period and/or lookup period in order to take the value of the Counterparty's holdings into account. This paper does not define how such adjustments should be made.

Note that a "period" is not synonymous with PaymentFrequency.

See also the user guide for the rule CalculationFrequency.


Are there any other measures of HoldingValue that we should use?


Rule

Markets = (Region | Country), [Markets];

Synopsis

Define a market set to be a list of one or more regions or a list of one or more countries.


Region: A list of one or more countries. Country: ISO 20022 CountryCode.

No duplicates should be permitted in each list.

User guide

Promoters may assemble the countries in a region into a list and assign a name to it, which the sales force and operations staff can use. For example, "Europe" might mean the set of countries including France, Germany, Italy, Spain, etc. Promoters may define as many regions as they wish and hold them in their proprietary systems as standing data. A regional definition is not necessarily private data, and so it may be disclosed to the Counterparty. However, the meaning of "Europe" and other regions may differ from one promoter to another.

Because the region is a proprietary definition under the control of the Company, it should be expanded into the complete list of its members when an appointment document or dematerialised message is generated. For example, "Europe" would expand to "Germany, France, Italy, Spain" etc. This will ensure that proprietary meanings are completely resolved when the agreement is contracted.

Although no duplicates are permitted in each list, it is possible that one Region may intersect another.


Comments requested.

Rule

PaymentCurrency = 'ShareclassCurrency' | SingleCurrency;

Synopsis

Determine whether front-end loads and rebates will be paid:

ShareclassCurrency In the currencies of the share classes in which the investments are made. SingleCurrency In a single currency.


ShareclassCurrency: Constant, meaning the currency of the share classes in respect of which the amounts were earned. SingleCurrency: ISO 20022 CurrencyCode.

User guide

Foreign exchange into the single currency is made in accordance with the Company's normal operating procedures.


Comments requested.


Rule

PaymentFrequency = Frequency - 'Daily';

Synopsis

The Company will pay front-end load and rebates to the Counterparty at a certain frequency.


PaymentFrequency: Derived from the enumerated type Frequency (defined in this document) except that payments will not be daily.


User guide

Not defined.


Comments requested.

Rule

Payments = PaymentType, (ReinvestFunds | BankTransfer | Cheque), [Payments];

Synopsis

The Company will make payments to the Counterparty by:

PaymentType Is the payment to be made in respect of front-end load or rebate or both? ReinvestFunds Reinvesting the earnings into shares or units of the Company's Products. BankTransfer Paying cash to one or more bank accounts. Cheque Issuing one or more cheques.


PaymentType, ReinvestFunds, BankTransfer and Cheque are all defined in this document.

User guide

Payments allows the parties to construct a payment schedule in separate Currencies, in respect of separate HoldingAccounts or groups of HoldingAccounts (which might reflect the structure of the Counterparty's businesses), Products, etc.


Comments requested.

Rule

PaymentType = 'FrontEndLoad' | 'Rebate' | 'GeneralPayment';

Synopsis

Payments to the Counterparty (by bank transfer, cheque or by a reinvestment in the Company's funds) will be made for the following reasons:

FrontEndLoad In respect of front-end loads only. Rebate In respect of rebates only. GeneralPayment In respect of front-end loads and rebates.


All terms are constants with the meaning defined in the synopsis above.

User guide

This rule is used to allow the parties to set up standing instructions for the payment of front-end load or rebates, indicating for each instruction whether front-end load and rebates are to be segregated or paid to a common destination. For each standing instruction that they establish, the parties can agree to make one or several payments in each Period, marking each payment with an agreed Reference if they wish, indicating the products or holding accounts in respect of which it is paid, which will allow the payment process to reflect the functional and geographic arrangement of the Counterparty's business.


Comments requested.


Rule

PeriodDays = 'CalendarDays365' | 'CalendarDays366' | 'BusinessDays' | '30';

Synopsis

Determines the number of days to take into account in the period:

CalendarDays365 Every calendar day is taken into account except 29 February on leap years. CalendarDays366 Every calendar day is taken into account including 29 February on leap years. BusinessDays Every day that is defined as a business day in the relevant fund's dealing calendar is taken into account. 30: Every month is considered to be 30 standard days.

Note: this rule does not determine the length of a period; that is set by CalculationFrequency.


PeriodDays is an enumerated type with four members.

User guide

PeriodDays should not be set to '30' if CalculationFrequency is set to 'Daily' because it does not adequately define on which days in a period the rebate calculation should be performed. For all other values of PeriodDays, CalculationFrequency may be set to 'Daily' and each period will be one day.

If PeriodDays is set to '30' (a standard month) and Calculation Frequency is set to:

'Monthly': The period will have 30 days (1 standard month). 'Quarterly': The period will have 90 days (3 standard months). 'SemiAnnual': The period will have 180 days (6 standard months) 'Annual': The period will have 360 days (12 standard months)


Comments requested.

Rule

PostalAddress = AddressLine, {AddressLine}, PostalCode, Country;

Synopsis

A postal address is a set of address lines, a post code and a country.


AddressLine: ISO 20022 Max350Text. PostalCode: ISO 20022 Max10Text. Country: ISO 20022 Country

User guide

Not defined.


The ISO 20022 business component StructuredPostalAddress was not used because, with 18 fields, the working group considered it too complex. Is this definition of PostalAddress acceptable?


Rule

Products = ProductSet, AppliedLookup, [Products];

Synopsis

Defines the set of products upon which rebates will be based, indicating for each:

ProductSet A list of related products. AppliedLookup Whether rebates should be applied to them or whether they should only be used to look up the rebate rate.


The members of this rule are defined in this document.

There should be no duplicates of ProductSet in Products. Commission agents should manage the undesirable effects of duplicate products arising from an intersection of one ProductSet with another by removing duplicates when rebate calculations are performed.

User guide

Not defined.


Comments requested.

Rule

ProductSet = [ProductSetID], (ISIN, [Name]), {ISIN, [Name]};

Synopsis

Assemble related products in an (optionally) named list, giving each product's ISIN and (optionally) its name.


ProductSetID ISO 20022 Max30Text ISIN: ISO 20022 ISINIdentifier. Name: ISO 20022 Max70Text.

The optional Name should be applied or omitted consistently for every ISIN in the ProductSet.

User guide

A Company can assemble similar funds (e.g., equity, fixed income, sector, etc) or similar categories of products (e.g., A shares, C shares, etc) into a group and assign a name to it, which the sales force and operations staff can use to prepare an agreement. A Company can define as many product groups as it wishes and hold them in its proprietary systems as standing data.

The Company should retain the right to create named lists of products in its sole discretion and it should use its definitions consistently for all Counterparties.


We must decide what to do when products change. If a prescriptive list is used to describe the products that attract a rebate, then both parties will want some means to acknowledge the change. General definitions like "equities" can cope with such changes, but if we propose definitively to resolve a product group into its member products at the point that an appointment document or dematerialised message is generated, then we remove the generality that would allow us to extend agreements unless we include in the master agreement a term that permits such updates by reference to a list that the Company must put into the public domain (rather than by sending a legal notice to the Counterparty).

Should ProductSetID be an obligatory term? It would certainly make it easier to refer to a specific ProductSet.


Rule

RebateFee = 'ManagementFee' | 'DistributionFee' | 'CombinationFee' | 'TotalExpenseRatio';

Synopsis

A rebate is a function of:

ManagementFee The management fees that the Company charges to the relevant product. DistributionFee The distribution fees that the Company charges to the relevant product. CombinationFee The sum of the management and distribution fees. TotalExpenseRatio The total expense ratio of the relevant product.


RebateFee is an enumerated type with four members: 'ManagementFee', 'DistributionFee', 'CombinationFee' and 'TotalExpenseRatio'.

User guide

Not defined.


Comments requested.

Rule

RebateMethod = 'BasisPoints' | 'Percentage';

Synopsis

Determine which of the following types of rebate rate will be used in the agreement:

BasisPoints Rebates are calculated as a basis point measure of the value of the Counterparty holdings. Percentage Rebates are calculated as a percentage share of the relevant fee (RebateFee) on the Counterparty holdings.


RebateMethod is an enumerated type with two members: 'BasisPoints' and 'Percentage'

User guide

When the BasisPoints method is used, the Counterparty will be entitled to receive rebates as a function of the value of its holdings at the relevant Rate irrespective of any change in the relevant Products' management or distribution fees. The obligation to pay rebates at the Rate continues even if management or distribution fees have been waived. When this method is used, the rule RebateFee only indicates how the Company will charge the rebates in its management accounts; it does not mean that rebates will be payable for as long as the Company's relevant income accounts remain in credit in respect of the Counterparty's holdings.

When the Percentage method is used, the Counterparty's rebates will vary directly with changes in management and distribution fees, and the obligation to pay rebates ceases when the Company waives the relevant fee.

The BasisPoints or Percentage method may be combined with the RebateFee option TotalExpenseRatio with the following caveats. When the BasisPoints method is used, rebates are calculated as a basis point measure of the value of the Counterparty holdings in the normal way and the TotalExpenseRatio is ignored because it is meaningless in that context. When the Percentage method is used, rebates are calculated as a percentage share of the value of TotalExpenseRatio applied to the Counterparty holdings. In each case, how the rebates are accounted for within the Company's management accounts is not defined.


Would it be better to say that when the BasisPoints method is used, the RebateFee field should be null?


Rule

RebateRateTable = [LookupFrequency], Currency, Rows;

Synopsis

A RebateRateTable is determined by:

LookupFrequency How often in a Period the Counterparty's total holding values should be used to look up the Rate. Currency The currency into which the Counterparty's total holding values should be converted for the lookup. Rows One or more rows containing rebate rates and the holding values for which they are valid.


LookupFrequency: Type Frequency, defined in this document. Currency ISO 20022 CurrencyCode. Row Defined in this document.


User guide

If LookupFrequency is not defined then it is equal to CalculationFrequency.


Comments requested.

Rule

RebateRateType = 'FlatBand' | 'SlidingScale';

Synopsis

Rebate rates can be defined in two ways:

FlatBand A single Rate is applied to all of the Counterparty's holdings (a "flat band" rate). SlidingScale Several Rates are applied to tranches of the Counterparty's holdings (a "sliding scale" rate).


RebateRateType is an enumerated type with two members: 'FlatBand' and 'SlidingScale'.

User guide

When the FlatBand method is used, the total value of the Counterparty's holdings is used to look up a Rate, which is then applied uniformly to every holding.

When the SlidingScale method is used, a weighted average rebate rate for the Counterparty's total holdings is calculated, which is based upon the Rate that is applicable to the holdings that are allocated to each Row in the RebateRateTable.


Comments requested.


Rule

Rebates = RebateSet, PaymentCurrency, PaymentFrequency, [SettlementWithin], [RetrospectiveAdjustmentPeriod], [DeMinimisEarnings], [DeMinimisPayment], [Rebates];

Synopsis

Define what rebates are payable and under what conditions:

RebateSet Rebate terms are arranged as repeating groups according to product, functional or geographic preferences. PaymentCurrency Payment is to be made in the currencies of the relevant share classes or in a single currency. PaymentFrequency With an agreed frequency. SettlementWithin Within an agreed settlement deadline. RetrospectiveAdjustmentPeriod Permitting adjustments to be made within a certain period. DeMinimisEarnings Provided that the amounts earned must exceed a certain threshold. DeMinimisPayment And provided that the amounts to be paid must exceed a certain threshold.


All terms are defined in this document.

User guide

None.


Comments requested.


Rule

RebateSet = [RebateSetID], RebateTermStartDate, RebateTermEndDate, Products, (Holdings | 'DefineLater'), RebateFee, CalculationFrequency, PeriodDays, YearDays, RebateMethod, RebateRateType, RebateRateTable, [RebateSet];

Synopsis

An agreement may contain several sets of rebate terms, each of which is determined by:

RebateSetID A unique identifier within the scope of the agreement, given by the Company for ease of reference. RebateTermStartDate Date upon which the rebate term starts. RebateTermEndDate Date upon which the rebate term ends. Products The products to which the rebates are to be applied or which are to be taken into account when setting the Rate. Holdings The holdings to which the rebates are to be applied or which are to be taken into account when setting the Rate. DefineLater The accounts in which the holdings exist will be specified after the Agreement is contracted. RebateFee Whether the rebates are based on management fees, distribution fees, etc. CalculationFrequency The frequency with which the rebate are calculated. PeriodDays The number of days in the rebate period. YearDays The number of days in the year. RebateMethod Whether it's a BasisPoint or Percentage calculation. RebateRateType Whether it uses a FlatBanded or SlidingScale rate table. RebateRateTable A table of rebate rates and holding values for which they are valid.

Two or more RebateSets in the same Agreement may be identical except for their RebateIDs, which must be unique and their RebateTermStartDate and RebateTermEndDate, which must define a period that does not overlap with the other related RebateSets.


RebateSetID: ISO 20022 Max30Text. RebateTermStartDate: ISO 20022 ISODate. RebateTermEndDate: ISO 20022 ISODate. DefineLater: Constant, with the meaning in the synopsis above.

All other terms are defined in this document.

User guide

The RebateSetID should be unique within the scope of a particular Agreement. The same value of RebateSetID can therefore be used in different agreements between the same parties. If the parties wish to refer uniquely to a particular rebate set amongst all of their agreements, they should do so by a combination of AgreementID and RebateSetID.

Different RebateSets may be created to define rebates by ProductSet (e.g., bond funds, equity funds, style funds) or by HoldingAccountSet (if the parties wish to set different rates for different types of business written by the Counterparty). By varying the RebateTermStartDate, RebateTermEndDate and the RebateRateTable for constant values of ProductSet and HoldingAccountSet, it is possible to create rates for a Counterparty, which are valid for an introductory or otherwise special period, which will be replaced after that period with standard rebate rates.

The term Holdings is deliberately placed within the RebateSet rather than elsewhere in the Agreement to ensure that, when calculating commissions for Counterparties who invest in many accounts, it is possible to keep rebates functionally segregated (e.g., retail sales, private banking, institutional) whilst benefiting from rebate rates based on total group holdings. However, the holding accounts might not exist at the time that the Agreement is contracted. Therefore, for whatever reason, including expediency, the parties can agree to define the holding accounts later. If the holding accounts do exist, the parties to the Agreement would be wise to specify them at the time the Agreement is first contracted.


Should RebateSetID be an obligatory term? It would certainly make it easier to refer to a specific RebateSet.


Rule

RebateTermEndDate = Date | 'Open';

Synopsis

Rebate terms may be valid until:

Date A future date determined by the parties at the time that they contracted the agreement. Open A future date that is to be determined by one of the parties giving a notice to the other.


Date: ISO 20022 ISODate, which must be in the future with respect to the relevant RebateTermStartDate and ExecutionDate. Open: Constant.

User guide

Not defined.


Comments requested.

Rule

RebateTermStartDate = Date | 'FirstInvestment';

Synopsis

Rebate terms may be valid from:

Date A date determined by the parties at the time that they contracted the agreement. FirstInvestment The date upon which the Counterparty will (or did) make its first investment in the relevant products.


Date: ISO 20022 ISODate, which must be earlier than RebateTermEndDate, and may be earlier than ExecutionDate, and may be in the past.

FirstInvestment: Constant, which may also indicate a date in the past.

User guide

Not defined.


Comments requested.

Rule

Region = [RegionID], Country, {Country};

Synopsis

Define a Region to be a list of one or more countries.


RegionID: ISO 20022 Max30Text. Country: ISO 20022 CountryCode.

User guide

See Markets.


Comments requested.


Rule

ReinvestFunds = 'ProRata' | ('SingleAccount', AccountType, AccountNumber) | ReinvestFundSet;

Synopsis

The front-end load and rebates due in respect of the Counterparty's holdings may be reinvested in the Company's funds:

ProRata In proportion to the holdings in the funds upon which they were earned, and in the same holding accounts. SingleAccount In proportion to the holdings in the funds upon which they were earned, but in a single named account. AccountType The type of the SingleAccount. AccountNumber The number of the SingleAccount. ReinvestFundSet In a different set of funds, which the Counterparty must specify.


ProRata: Constant, with the meaning in the synopsis above. SingleAccount: Constant, with the meaning in the synopsis above. AccountType: Defined in this document. AccountNumber: Not defined. ReinvestFundSet: Defined in this document.

User guide

If reinvestments are to be made ProRata, they will be made into the same HoldingAccounts as the products upon which the rebates were earned.

The ProRata option should be used by Counterparties who have an obligation to ensure that rebates are paid to the clients in respect of whose investments they were earned.

The SingleAccount option should be used if the Counterparty wishes rebates to be reinvested in the funds upon which they were earned but in a designated single HoldingAccount.

The ReinvestFundSet option permits the Counterparty to reinvest rebates in as many designated funds and as many designated HoldingAccounts as it wishes.



Is it common industry practice that front-end load is always paid as cash and is never reinvested in the Company's funds?

Rule

ReinvestFundSet = AccountType, AccountNumber, (ISIN, [Name], Ratio), {ISIN, [Name], Ratio}, [ReinvestFundSet];

Synopsis

A Counterparty who wishes to receive rebates in the form of shares or units in specific funds (different funds to those in respect of which the rebates were earned) should specify:

ISIN The ISIN of the fund in which the rebate is to be invested. Name The name of the fund. Ratio The ratio in which this fund will receive an allocation of the total amount of rebates payable. AccountType The type of the account in which the reinvestment is to be made. AccountNumber The number of the account in which the reinvestment is to be made.


ISIN ISO 20022 ISINIdentifier Name ISO 20022 Max70Text. Ratio ISO 20022 PercentageRate; > 0; the sum of all Ratio in each ReinvestFundSet must = 100. AccountType Defined in this document. AccountNumber Not defined.

User guide

Not defined.



Can front-end load or rebates be reinvested into shared accounts (e.g., Clearstream, Euroclear)?

Should we provide a facility to give a PaymentReference, as we do for BankTransfer and Cheque?


Rule

ReportMethod = (('Postal', PostalAddress) | ('Email', EmailAddress) | ('Fax', FaxNumber)), [ReportMethod];

Synopsis

The Company might send rebate reports by post, e-mail or fax, in which case an address or number must be provided for each.


Postal: Constant. PostalAddress: Defined in this document. Email: Constant. EmailAddress: ISO 20022 EmailAddress. Fax: Constant. FaxNumber: ISO 20022 PhoneNumber.

User guide

Not defined.


Comments requested.

Rule

Reports = ReportMethod, {Reference}, [SpecialInstructions], [Reports];

Synopsis

The parties should agree some high-level principles by which the Company will report rebates to the Counterparty, including:

ReportMethod Whether reports will be sent by post, e-mail, fax or a combination of them. Reference Any references that might help the parties to identify the agreement and specific terms, products or accounts. SpecialInstructions Any special instructions that might aid the despatch, routing, reception and comprehension of the reports.


ReportMethod: Defined in this document. Reference: ISO 20022 Max35Text. SpecialInstructions: ISO 20022 Max2000Text.

User guide

ReportMethod is defined iteratively because some Counterparties want to receive the same report by more than one method.

Reference may be a static reference defined when the agreement is contracted or a list of RebateIDs or some other indicator that the Company may add to a report to help the Counterparty link it to the agreement and the underlying products and holding accounts.


Comments requested.


Rule

RetrospectiveAdjustmentPeriod = (Number, 'Months' | 'Years') | Other;

Synopsis

The parties should agree the period, starting from the date on which the Company despatches a statement of rebate earnings, within which the Counterparty may request changes (for example, in respect of holdings that the Counterparty considers to be eligible for rebates, but which are not described in the relevant rebate terms).


Number: Integer, >= 0. Months: Constant, meaning that Number indicates a number of months within which retrospective adjustment will be allowed. Years: Constant, meaning that Number indicates a number of years within which retrospective adjustment will be allowed. Other: ISO 20022 Max2000Text, which allows the parties to describe some other limit on retrospective adjustment.

User guide

In large, international, multi-layered distribution networks, Counterparties often make investments in Companies' funds through new accounts (particularly through central securities depositories) that are eligible for rebates under the terms of the agreement (i.e., they are in eligible Markets and Products) but are omitted from rebate calculations because the commission agent is not aware that the accounts have been created. Retrospective adjustments are therefore a common feature of rebates processing.

This rule makes clear to both parties the limit at which the Company will retrospectively pay rebates on investments that were unknown to it when it initially calculated and paid rebates for a particular period.

This rule is not intended to determine whether a new agreement will retrospectively pay rebates on investments that pre-dated it. To do that, the parties should create a RebateSet with an appropriate start date in the past; the commission calculation agent will then take prior periods into account when it calculates the Counterparty's earnings for the first time.


Comments requested.

Rule

Rows = Floor, [Ceiling], Rate, [Rows];

Synopsis

Rebate Rates are defined in a table, each row of which is comprised of:

Floor The value of holdings at or above which the Counterparty is eligible to receive a Rate. Ceiling The value of holdings up to which the Counterparty is eligible to receive a Rebate Rate. Rate The rebate rate.


For each Row n:

Floor n: Integer, >=0; = Ceiling of Row n-1; < Ceiling of Row n. Ceiling n: Integer, > Floor n. May be unconstrained (i.e., it is optional for the highest row in the table). Rate: Integer, > 0.

Rate is valid for each row where Floor < Counterparty holding value <= Ceiling.

User guide

Rate is an absolute value. The rule RebateMethod determines whether it's a basis point or percentage measure, and the rule RebateFee determines the account to which it is attributed.

Example 1, a Rate = 50, a RebateMethod = 'BasisPoints' and a RebateFee = 'ManagementFee' means that the Counterparty will receive 50 basis points of the value of the relevant holdings, which the Company will attribute to its management fee account.

Example 2, a Rate = 60, a RebateMethod = 'Percentage' and a RebateFee = 'CombinationFee' means that the Counterparty will receive 60 percent of the sum of the Company's management and distribution fees income on the relevant holdings.


Comments requested.


Rule

SettlementWithin = (Number, 'BusinessDays' | 'CalendarDays') | Other;

Synopsis

Defines when the Company will settle payments of front-end load and commission to the Counterparty after they become due:

Number The number of days after the due date within which the Company will make settlement. BusinessDays Whether the number of days is counted as business days. CalendarDays Whether the number of days is counted as calendar days. Other Whether settlement will be defined in some other way.


Number Integer, >0. BusinessDays Constant. CalendarDays Constant. Other ISO 20022 Max2000Text.

User guide

An example of an "other" settlement instruction might be the "last business day of the month after the period".


Comments requested.

Rule

YearDays = 'CalendarDays365' | 'CalendarDays366' | 'BusinessDays' | '360';

Synopsis

Determines the number of days to take into account in the year:

CalendarDays365 Every calendar day is taken into account except 29 February on leap years. CalendarDays366 Every calendar day is taken into account including 29 February on leap years. BusinessDays Every day that is defined as a business day in the relevant fund's dealing calendar is taken into account. 360: Every year is considered to be 360 standard days.


YearDays is an enumerated type with four members.

User guide

Not defined.


Comments requested.


Part 7: Model appointment document (pro-forma term sheet) Introduction

This part was prepared for the purpose of demonstrating how the DMFSA Specific Commercial Terms might be used to prepare the "appointment document" that the DMFSA Master Agreement foresees.

One advantage of preparing a model appointment document is that it readily demonstrates the practicality of the DMFSA concept. A static template of this type is not as effective as a software demonstrator, but with some modest programming, a word-processor or simple database program could be configured to create an easy-to-use data entry tool to generate printable documents that would allow companies quickly to adopt the DMFSA Master Agreement with negligible expense. Even if such an application had no standing data memory of the type that the DMFSA concept demonstrator software has, it would be very cost-effective substitute for the manual processes that almost every firm uses today to prepare mutual fund sales agreements.

The following points should be borne in mind when reading the model appointment document:

⎯ The fields that are not required by the parties to an agreement (the unused optional fields) would very probably be discarded when the parties created an execution copy appointment document.

⎯ Repeatable fields or groups of such fields are represented only once in the model appointment document, with notes to guide the document user on what should be repeated. An execution copy appointment document would contain as many such fields, with differing data, as the parties wish to define.

⎯ The model appointment document contains label text on the left-hand-side, being text that indicates the purpose of each field. The label text would be included with each relevant field in an execution copy of the appointment document. This draft has implemented the label text using the defined terms from the DMFSA Specific Commercial Terms. The author attempted to create another draft based upon a natural language description of each field to see if it would be more accessible to the reader. On the contrary, it made the model document verbose and more difficult to read. It seems better to propose that the practitioners who prepare and consult mutual fund sales agreements will quickly become familiar with the DMFSA Master Agreement, the Specific Commercial Terms and this model appointment document, and will be comfortable to exchange concise documents using the defined terms.

⎯ The model appointment document contains guidance text for the user, generally about which fields may be repeated when the execution copy is being prepared. The guidance notes would very probably be discarded when the parties created the execution copy. However, the section headings would remain.

⎯ The model appointment document is divided into numbered sections for ease of reference. These numbers are not significant within the context of the DMFSA Master Agreement clauses or the Specific Commercial Terms. Whether they should be included in the execution copy appointment document has not yet been decided. The clear advantage of doing so would be ease of reference between an execution copy and the model from which it was derived. On the other hand, such a numbering scheme is unlikely to be necessary in a fully dematerialised scheme (when appointment documents are passed by structured electronic message) and might hinder the emergence of a more appropriate message syntax.


Model appointment document

1. GENERAL

This Appointment Document incorporates by reference the "General Terms and Conditions applying to the promotion of Investment Funds, version September 2008" (the "Terms") which shall together form the entire agreement between the parties. The Company and the Counterparty have read and understood the Terms and agree to be bound by the Terms. The Terms and this Appointment Document including its Parts 1 to 8 form a single agreement. In case of a conflict between the Terms and this Appointment Document, the Appointment Document shall prevail.

1.1. Company: Insert name and address

1.2. Counterparty: Insert name and address

1.3. CounterpartyCapacity: Indicate in which one or more of the following roles the Counterparty will act:

"Distributor", "Dealer", "FinalBeneficialOwner", "FundofFunds", "PlacementAgent"

1.3.1. SubnetworksAllowed: Only if Box 1.3 contains "Distributor"

Insert "Yes" or "No"

1.4. AgreementID: Insert Identification number

1.5. ExecutionDate: Insert day, month, year

1.6. MasterAgreementVersion: Insert MFSA master agreement version number

(Repeat sections 1.7 and 1.7.1 for as many country schedules as the parties wish to invoke)

1.7. CountrySchedule: Insert MFSA country schedule name

1.7.1. CountryScheduleVersion: Only if Box 1.7 is used

Insert MFSA country schedule version number

1.8. GoverningLaw: Insert governing law

1.9. JurisdictionCourts: Insert jurisdiction


2. PRODUCTS

(Repeat section 2 for as many ProductSets as the parties wish to employ under this Agreement)

2.1. ProductSetID: Optional

Insert the identifier of a pre-defined set of products (e.g., "Bond Funds")

(Repeat sections 2.1.1 and 2.1.2 for as many ISINs and Names as the Company has defined for each ProductSetID or, if Box 2.1 is not used, for as many products as the parties wish to define)

2.1.1. ISIN: Insert an ISIN number

2.1.2. Name: Optional

Insert the name of the product identified by the ISIN number at Box 2.1.1


3. MARKETS

(Repeat section 3 for as many Markets as the parties wish to employ under this Agreement)

3.1. RegionID: Optional

Insert the identifier of a pre-defined region (e.g., "Europe")

(Repeat section 3. 2 for as many Countries as the Company has defined for each Region)

3.1.1. Country: Insert a country name

3.2. Country: Only if Box 3.1.1 is not used

Insert a country name


4. FRONT END LOAD

4.1. Deal at NAV: Optional

Insert "DealAtNAV"

(Repeat section 4.2 and its sub-sections for as many front-end load sets as the parties wish to define)

Front-end load set

4.2. FrontEndLoadSetID: Only if Box 4.1 is not used

Insert identification number of this FrontEndLoadSet

Front-end load set products

(Repeat section 4.2.1 and its sub-sections for as many ProductSets as the parties wish to employ under this FrontEndLoadSet)

4.2.1. ProductSetID: Optional

Insert the identifier of a pre-defined set of products (e.g., "Bond Funds")

(Repeat sections 4.2.1.1 and 4.2.1.2 for as many ISINs and Names as the Company has defined for each ProductSetID or, if Box 4.2.1 is not used, for as many products as the parties wish to define)

4.2.1.1. ISIN: Insert an ISIN number

4.2.1.2. Name: Optional

Insert the name of the product identified by the ISIN number at Box 4.2.1.1

Allocation instructions for front-end loads collected under the terms of this set

4.2.2. Discount: Insert Rate

4.2.3. CounterpartyShare: Insert Rate

4.2.4. CompanyShare: Insert Rate


Front-end load payment

4.3. PaymentCurrency: Optional and only if Box 4.1 is not used

Insert PaymentCurrency

4.4. PaymentFrequency: Only if Box 4.3 is used

Insert "Monthly", or "Quarterly", or "SemiAnnual" or "Annual"

4.5. SettlementWithin:

(Use Boxes 4.5.1 and 4.5.2 or only Box 4.5.3)

4.5.1. Number: Optional and only if Box 4.3 is used

Insert Number of days

4.5.2. Business Days or Calendar Days: Only if Box 4.5.1 is used

Insert "BusinessDays" or "CalendarDays"

4.5.3. Other: Optional and only if Box 4.3 is used and Boxes 4.5.1 and 4.5.2 are not used

Insert whatever other settlement terms the parties agree

4.6. RetrospectiveAdjustmentPeriod:


4.6.1. Number: Optional and only if Box 4.3 is used

Insert Number

4.6.2 Business Days or Calendar Days: Only if Box 4.6.1 is used

Insert "Months" or "Years"

4.6.3 Other: Optional and only if Box 4.3 is used and Boxes 4.6.1 and 4.6.2 are not used

Insert whatever other adjustment terms the parties agree


4.7. DeMinimisPaymentCurrency: Optional and only if Box 4.3 is used

Insert DeminimisPaymentCurrency

4.7.1. DeMinimisPaymentThreshold: Only if Box 4.7 is used

Insert DeMinimisPaymentThreshold


5. REBATES

Rebate set

(Repeat sections 5.1 and its sub-sections for as many RebateSets as the parties wish to define)

5.1. RebateSetID: Optional

Insert identification number

5.1.1 RebateTermStartDate: Insert day, month, year or "First Investment"

5.1.2 RebateTerrmEndDate: Insert day, month, year or "Open"

Rebate set products

(Repeat section 5.1.3 and its subsections and section 5.1.4 for as many ProductSets as the parties wish to employ under this RebateSet)

5.1.3. ProductSetID: Optional

Insert the identifier of a pre-defined set of products (e.g., "Bonds")

(Repeat sections 5.1.3.1 and 5.1.3.2. for as many ISINs and Names as the Company has defined for each ProductSetID or, if Box 5.1.3 is not used, for as many products as the parties wish to define)

5.1.3.1. ISIN: Insert an ISIN number

5.1.3.2. Name: Optional and only if Box 5.1.3.1 is used

Insert the name of the product identified by the ISIN number at Box 5.5

5.1.4. Applied or LookupOnly: Insert "RebateApplied" or "LookupOnly"

Rebate set holdings

5.1.5. DefineLater: Optional

Insert "DefineLater"


(Repeat sections 5.1.6 and its sub-sections and section 5.1.7 for as many sets of holding accounts as the parties wish to define in this rebate set)

5.1.6. HoldingAccountSetID: Optional and only if Box 5.1.5 is not used

Insert identification number

(Repeat sections 5.1.6.1 to 5.1.6.4 and its sub-section for as many holding accounts as the parties wish to define in this set of holding accounts)

5.1.6.1. AccountType: Insert "CentralTransferAgency", "Clearstream", "Euroclear", "Fundsettle" or whatever other name the parties agree

5.1.6.2. AccountNumber: Insert AccountNumber for the account identified in Box 5.1.6.1

5.1.6.3. HoldingValue: Insert "DailyHolding", "PeriodEndHolding", "PeriodAverageHolding", "MonthlyPeriodAverageHolding", "QuarterlyPeriodAverageHolding", "GrossSalesValue", or "NetSalesValue"

5.1.6.4. SharedAccount: Optional

Insert "SharedAccount"

5.1.6.4.1. HoldingUpdateFrequency: Optional and only if Box 5.1.6.4 is used:

Insert "Monthly", "Quarterly", "SemiAnnual" or "Annual"

5.1.7. Applied or LookupOnly: Insert "RebateApplied" or "LookupOnly"

Rebate set terms

5.1.8. RebateFee: Insert "ManagementFee", "DistributionFee", "CombinationFee" or "TotalExpenseRatio"

5.1.9. CalculationFrequency: Insert "Daily", "Monthly", "Quarterly", "SemiAnnual" or "Annual"

5.1.10. PeriodDays: Insert "CalendarDays365", "CalendarDays366", "BusinessDays" or "30"

5.1.11. YearDays: Insert "CalendarDays365", "CalendarDays366", "BusinessDays" or "360"

5.1.12. RebateMethod: Insert "BasisPoints" or "Percentage"

5.1.13. RebateRateType: Insert "FlatBand" or "SlidingScale"


Rebate Rate Table

5.1.14. LookupFrequency: Optional

Insert "Daily", "Monthly", "Quarterly", "SemiAnnual" or "Annual"

5.1.15. Currency: Insert Currency

(Repeat sections 5.1.16 to 5.1.18 for as many Rows as the parties wish to define in the RebateRateTable)

5.1.16. Floor: Insert Integer

5.1.17. Ceiling: Optional

Insert Integer

5.1.18. Rate: Insert Rate

Rebate settlement for all rebate sets

5.2. PaymentCurrency: Insert PaymentCurrency

5.3. PaymentFrequency: Insert "Monthly", or "Quarterly", or "SemiAnnual" or "Annual"

5.4. SettlementWithin:


5.4.1. Number: Optional

Insert Number of days

5.4.2. Business Days or Calendar Days: Only if Box 5.4.1 is used

Insert "BusinessDays" or "CalendarDays"

5.4.3. Other: Optional and only if Boxes 5.4.1 and 5.4.2 are not used

Insert whatever other settlement terms the parties agree


5.5. RetrospectiveAdjustmentPeriod:


5.5.1. Number: Optional

Insert Number

5.5.2 Business Days or Calendar Days: Only if Box 5.5.1 is used

Insert "Months" or "Years"

5.5.3 Other: Optional and only if Boxes 5.5.1 and 5.5.2 are not used

Insert whatever other adjustment terms the parties agree

5.6. DeMinimisEarningsCurrency: Optional

Insert DeminimisEarningsCurrency

5.6.1. DeMinimisEarningsThreshold: Only if Box 5.6 is used

Insert DeMinimisEarningsThreshold

5.7. DeMinimisPaymentCurrency: Optional

Insert DeminimisPaymentCurrency

5.7.1. DeMinimisPaymentThreshold: Only if Box 5.7 is used

Insert DeMinimisPaymentThreshold


6. PAYMENTS

(Repeat section 6 for as many times as the parties wish to define payment instructions)

6.1. PaymentType: Insert "FrontEndLoad", "Rebate" or "GeneralPayment"

(For each PaymentType, complete section 6.2 (reinvestment into funds) or 6.3 (bank transfer) or 6.4 (cheque))

6.2 Reinvestments into funds

Choose either Pro Rata or Single Account or Reinvest Fund Set

Pro Rata

6.2.1 ProRata: Choose this box or Box 6.2.2 or Boxes 6.2.5 et seq

Insert "ProRata"

SingleAccount

6.2.2 Single Account: Choose this box or Box 6.2.1 or Boxes 6.2.5 et seq

Insert "SingleAccount"

6.2.3. AccountType: Only if Box 6.2.2 is used

Insert "CentralTransferAgency", "Clearstream", "Euroclear", "Fundsettle" or whatever other name the parties agree

6.2.4. AccountNumber: Only if Box 6.2.2 is used

Insert the account number

Reinvest Fund Set

(Repeat sections 6.2.5 to 6.2.9 for as many reinvestment fund sets as the parties wish to define)

6.2.5. AccountType: Insert "CentralTransferAgency", "Clearstream", "Euroclear", "Fundsettle" or whatever other name the parties agree

6.2.6. AccountNumber: Insert the account number


(Repeat sections 6.2.8 to 6.2.9 for as many reinvestment funds as the parties wish to define within this reinvestment fund set)

6.2.7. ISIN: Insert an ISIN number

6.2.8. Name: Optional, and only if Box 6.2.7 is used

Insert the name of the product identified by the ISIN number at Box 6.2.7

6.2.9. Ratio: Insert the ratio of the total available for reinvestment that is to be reinvested into the ISIN named at Box 6.2.7

6.3 Bank transfers


6.3.2. BeneficiaryAccountName: Insert BeneficiaryAccountName

6.3.3. BeneficiarySWIFT_BIC_Code: Optional

Insert BeneficiarySWIFT_BIC_Code

6.3.4. BeneficiaryAccountNumber: Insert BeneficiaryAccountNumber

6.3.5. BeneficiaryBankSWIFT_BIC_Code: Insert BeneficiaryBankSWIFT_BIC_Code

6.3.6. BeneficiaryBankBranchNumber: Optional

Insert BeneficiaryBankBranchNumber

6.3.7. BeneficiaryBankName: Optional

Insert BeneficiaryBankName

6.3.8. BeneficiaryBankAddress: Optional

Insert BeneficiaryBankAddress

(Repeat section 6.3.9 for as many payment references as the parties wish to attach to this bank transfer)

6.3.9. PaymentReference: Optional

Insert the payment reference(s) that the parties agree


6.3.10. CorrespondentBankSWIFT_BIC_Code: Optional

Insert CorrespondentBankSWIFT_BIC_Code

6.3.10.1. CorrespondentBankName: Optional and only if Box 6.3.10 is used

Insert CorrespondentBankName

6.3.10.2. CorrespondentBankAccountNumber: Optional and only if Box 6.3.10 is used

Insert CorrespondentBankAccountNumber

6.4 Cheque


6.4.2. BeneficiaryName: Insert BeneficiaryName

6.4.3. Address: Insert Address

(Repeat section 6.4.4 for as many payment references as the parties wish to attach to this cheque)

6.4.4. PaymentReference: Optional

Insert the payment reference(s) that the parties agree


7. REPORTS

(Repeat section 7 for as many combinations of report methods, references and special instructions as the parties wish to define)

7.1. ReportMethod: Insert one of the following:

"Postal" and the postal address "Email" and the e-mail address "Fax" and the fax address.

7.2. Reference: Optional

Insert the report reference(s) that the parties agree for this ReportMethod

7.3. SpecialInstructions: Optional

Insert the special instructions that the parties agree


8. CONTACT PEOPLE

8.1. CompanyContactPerson

(Repeat sections 8.1.1 and 8.1.2 as many times as the parties wish)

8.1.1. ContactPerson: Insert ContactPerson

8.1.2. SpecialInstructions: Optional, only if Box 8.1.1 is used

Insert SpecialInstructions

8.2. CounterpartyContactPerson

(Repeat sections 8.2.1 and 8.2.2 as many times as the parties wish)

8.2.1. ContactPerson: Insert ContactPerson

8.2.2. SpecialInstructions: Optional, only if Box 8.2.1 is used

Insert SpecialInstructions


IN WITNESS WHEREOF the parties have executed this Agreement:

For the Company: For the Counterparty:

Name: Name:

Position: Position:

Signature:

Signature:

Name: Name:

Position: Position:

Signature:

Signature:

dematerialised mutual fund sales agreements - issa · part of a collaborative project by: blackrock...

Documents