openterms syntax issue 02

OpenTerms project

Operational work stream

Syntax and semantic definitions

Issue 02

12 July 2016

© Schroders plc 2016

This work derived from the work produced by the DMFSA collaboration project, which continues as the OpenTerms project, and is licensed under a Creative Commons Attribution 3.0 License and you may use, copy, distribute, transmit and adapt it (including for your own commercial purposes) under the terms of that licence.

ISO 20022 components have been used where possible to aid compatibility with global financial messaging standards.

http://creativecommons.org/licenses/by/3.0/

OpenTerms syntax and semantic definitions, issue 02, 12 July 2016

Contents

Part 1: Introduction

Part 2: Synoptic charts of the terms of business syntax

Part 3: Syntax rules listed in alphabetic order

Part 4: The periodic charge formula

Part 5: Cash flow adjustments for segregated mandates

Part 6: Syntax semantic definitions

Part 7: HoldingValue function reference


Part 1: Introduction

This document defines a syntax and provides a semantic reference for preparing documents to describe the terms of business between an asset manager and its clients regardless of whether the clients are subscribing to a pooled fund or a segregated account.

The textual listing of the syntax at Part 3 of this document complies with ISO/IEC 14977. A description of that standard including guidance on how to read it is available on the Internet. Those who are not familiar with the standard will find the synoptic charts at Part 2 easier to read initially. The following paragraphs offer a short introduction to how to read the syntax.

The syntax uses a simple set of rules to describe terms of business. 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. For example, the first and most important rule is:

Terms =

Company, {Company}, Counterparty, {Counterparty}, Agreement, [Product, {Product}, {ProductExclusion}], [Market, {Market}, {MarketExclusion}], {TransactionChargeSet}, {PeriodicChargeSet}, {Payment}, {Report};

which means that terms of business are defined by the company and the counterparty who made them, some legal terms, the products and markets to which the terms will apply, the charges and payment mandates, etc.

The syntax commonly uses the following forms of control in its 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.

Iteration Limited iteration is indicated by the "*" character. For example, 4 * 'x' means that the symbol 'x' must be included four times.

The rules also use the following special characters:

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

Group Some terms are grouped together in round brackets (like this) in order to ensure the desired precedence between operators or 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.


Part 2: Synoptic charts of the terms of business syntax Chart 1: Terms.

Chart 2: TransactionChargeSet.

Chart 3: PeriodicChargeSet.

Chart 4: PeriodicCharge.

Chart 5: PeriodicChargeType.

Chart 6: HoldingAddress, HoldingValue, CashFlow.

Chart 7: Payment and Report.

The synoptic charts help the reader to understand the scope and the pattern of the syntax. They also show some of the constraints on the syntax (i.e., in what circumstances some terms should not be used). In the case of a disagreement between a synoptic chart and the syntax, the syntax will prevail.


Terms Company PartyIdentification

Counterparty PartyIdentification

OfferRights PublicOffer

PrivatePlacement

PublicOfferAndPrivatePlacement

DelegationPermitted

OfferRightsNarrative

OpenTermsClear terms of business for the asset management industry

Synoptic chart number: 1

Draft number: 17

Date: 12 July 2016

Origin: Terms (OpenTerms project, issue 02)

The chart reflects the typological constraints that are described in the Schroders syntax.

Key:

0..1 Select the term to the right zero or one times.

0..4 Select the term to the right between zero and four times.

0..N Select the term to the right between zero and as many more times as required.

1..N Select the term to the right at least once and as many more times as required.

▼ Contains underlying terms not shown in these charts.

Select A or B

A

B

CompanyCapacity0..1

1..N

Affiliate0..N

1..N

Agreement

ExecutionDate

LegalAspects

Product

Market

TransactionChargeSet

PeriodicChargeSet

Payment

Report

0..N

0..N

0..N

0..N

See chart 2 below

See chart 3 below

See chart 7 below

See chart 7 below

ISINAndDescription0..N

Country

Proprietary

0..N

AgreementID

VersionNumber

OtherID

ApplicableLawAndJurisdiction

TermAndTermination Term

TerminationNotice Days

Months

CounterpartyCapacity

ContactDetails

ContactDetails1..N

1..N

CompanyCapacityCode

Proprietary

LegalRepresentative

ManagementCompany

GlobalDistributor

OfferRightsAndDelegation

Proprietary

OfferRightsCode

NoneCounterpartyCapacityCode

Proprietary

Platform

Distributor

IntroducingAgent

ProductPackager

InstitutionalInvestor

LegalTerms

LegalVariation0..N

Law

Jurisdiction Country

Name

ISIN

Description

Platform

0..1

0..1

FixedTermMonths

Open

▼▼

URL

URL

▼

▼

▼

▼

▼

▼

▼

0..1

0..1

0..1

0..1

PlacementAgent

CentralisingAgent

MostFavouredTerms0..1

ProductExclusion0..N

MarketExclusion

▼

▼

PartyIdentification

AccessionDate

SecessionDate

ContactDetails

1..N

0..N

▼

▼

0..1

0..1

1..N

1..N

0..N


TransactionChargeSet TransactionChargeSetNumber

TransactionCharge

PaymentCurrency

ShareClassCurrency

SettlementWithin TimeLimitBusinessDays

TimeLimitCalendarDays

1..N

DeMinimisPayment

BaseCurrency

Other

RetrospectiveAdjustmentDeadline TimeLimitMonths

Other

Currency

Threshold

0..1

0..1

0..1

PaymentCurrencyBasis

Currency

MandateCurrency

InvestmentCurrency

LatePaymentPenalty0..1

TransactionChargeType RateTransactionChargeCode

Proprietary

FrontEndLoad

BackEndLoad

Switch

▼

ISIN

Description0..1

▼

HoldingAddressPath

HoldingAddressNumber

Account

HoldingAddressPath

TransactionChargeHoldingAddress

DefinedLater

HoldingAddressPath


1..N

ShareClass

SubFund

Fund

ProductAggregationType

Product ISINAndDescription

OtherID

1..N

URL

▼

RateTransactionCharge

TermStartDate Date

FirstInvestment

TermEndDate Date

Open

Product ISINAndDescription1..N

TransactionChargeHoldingAggregation

TransactionChargePeriod Weekly

Monthly

Quarterly

HalfYearly

Yearly

Discount

CounterpartyShare

CompanyShare

OtherID

SemiMonthly

TransactionChargeNumber

TransactionChargeHolding TransactionChargeHoldingAddress

DefinedLater

1..N

ProductAggregationTransactionChargeAggregation0..1

URL

RateTable FlatBand

SlidingScaleReferenceCurrency

RateTableRow1..N

Threshold

Rate

RateMethod

Movement

FixedCharge FixedChargeType

Amount

Currency

FixedChargeDescription

FixedChargeCode

Proprietary

BenchmarkChange

MinimumPeriodicCharge*

* Not for transaction charges



Draft number: 17

Date: 12 July 2016

Origin: TransactionChargeSet (OpenTerms project, issue 02)


Key:






Select A or B

A

B

PenaltyRate

BaseRate

▼


ISIN

Description

a

0..1

a


▼

▼

TransactionChargeSetName0..1

TransactionChargeName0..1


PeriodicChargeSet PeriodicChargeSetNumber

PeriodicCharge1..N

TerminationMode

See chart 4 below

TerminationType

RunOff PeriodMonths

AdmitNewPositions

CompanyAutoPay

CounterpartyInvoice



Draft number: 17

Date: 12 July 2016

Origin: PeriodicChargeSet (OpenTerms project, issue 02)


Key:






Select A or B

A

B

PaymentCurrency

ShareClassCurrency

SettlementWithin TimeLimitBusinessDays

TimeLimitCalendarDays

DeMinimisCharge

BaseCurrency

Other

RetrospectiveAdjustmentDeadline TimeLimitMonths

Other

Currency

Threshold

0..1

0..1

0..1

PaymentCurrencyBasis

Currency

DeMinimisPayment Currency

Threshold

0..1

PaymentMechanism

CoTerminusAgreement

Survive

NestedCharges0..1

MandateCurrency

InvestmentCurrency

PeriodicChargeSetName0..1


PeriodicCharge PeriodicChargeNumber

TermStartDate Date

FirstInvestment

TermEndDate Date

Open

1..N



Draft number: 17

Date: 12 July 2016

Origin: PeriodicCharge (OpenTerms project, issue 02)


Key:






Select A or B

A

B

Product ISINAndDescription1..N

OtherID

PeriodicChargeHolding PeriodicChargeHoldingDetails

DefinedLater

HoldingAddress

HoldingValue

ISIN

Description0..1

URL

▼

Discount

FixedCharge

PerformancePeriodicCharge

VolumePeriodicCharge

FeeSharePeriodicCharge

PeriodicChargeType Payee

0..1

Company

CounterpartySee chart 5 below

See chart 5 below

See chart 5 below

See chart 5 below

CashFlow

See chart 6 below

See chart 6 below

PeriodicChargeHoldingAggregation Account

HoldingAddressPath

PeriodicChargeHoldingDetails

DefinedLater

1..NHoldingAddress

HoldingValue

ShareClass

SubFund

Fund

ProductAggregation ProductAggregationType

Product ISINAndDescription

OtherID

1..NISIN

Description

PeriodicChargeAggregation0..1

0..1

URL

▼

See chart 6 below

CashFlow See chart 6 below

See chart 6 below

See chart 6 below

PeriodicChargePeriod Weekly

Quarterly

HalfYearly

Yearly

PeriodDays

YearDays

CalendarDays365

CalendarDays366

StandardYear360

CalendarDays365

CalendarDays366

StandardYear360

StandardYear365.25

Monthly

CalculationFrequency Daily

Monthly

Quarterly

HalfYearly

Yearly

Weekly

PartialChargePeriodConvention Long

Short


▼


▼

PeriodicChargeName0..1




Draft number: 17

Date: 12 July 2016

Origin: PeriodicChargeType (several) (OpenTerms project, issue 02)


Key:






Select A or B

A

B

FeeSharePeriodicCharge FeeSharePeriodicChargeCode

LookupFrequency

PerformancePeriodicCharge

Proprietary

RateTable

0..1

FlatBand


RateTableRow1..N

Threshold

Rate

RateMethod

ManagementFee

DistributionFee

Management+DistributionFee

TotalExpenseRatio

VolumePeriodicCharge VolumePeriodicChargeCode

LookupFrequency

Proprietary

RateTable

0..1

FlatBand


RateTableRow1..N

Threshold

Rate

RateMethod

TrailerFee

IntermediaryServiceFee

ItalianSubjectInChargePlacementFee

FranceCentralisingAgentFee

ManagementFee

CustodyFee

ReferralFee

AdvisoryFee

RealEstateFundFee

LifeCompanyFee

ParticipationRate

OutPerformBenchmark

PortfolioReturnMeasure

Hurdle

HighWaterMark

OutPerformCap

PerformancePeriod

SeriesAccounting

SpecialConditions

0..1

0..1

0..1

0..1

Description

TickerIdentifier

CompareMethod

0..1

Arithmetic

Geometric

TermStartDate Date

FirstInvestment

TermEndDate Date

Open

PerformanceMeasurementDate Month

Day

PerformancePeriodType PerformancePeriodTypeCode

PerformancePeriodStartConvention

PerformancePeriodHurdleConvention

PerformancePeriodYears

0..1

0..1

Fixed

Extensible

Rolling

PerformancePeriodStartConventionCode

Proprietary

Neutral

Progressive

AdaptiveSimple

Compound

FixedCharge FixedChargeType

Amount

Currency

FixedChargeDescription

FixedChargeCode

Proprietary

BenchmarkChange

MinimumPeriodicCharge Not for transaction charges▼

▼

▼

▼

1..N

OngoingCharge

TotalExpenseRatioCap

OngoingChargeCap


HoldingAddressType HoldingAddressPath

ClearstreamBankLuxembourg

Euroclear

FundSettle


SharedAccount

SharedAccountHoldingUpdateFrequency0..1

HoldingCount Daily

Monthly

Quarterly

HalfYearly

Yearly

MonthEndMean

QuarterEndMean

HalfYearEndMean

YearEndMean

Monthly

Quarterly

HalfYearly

Yearly

ApplicableNAV ReferHoldingCount

ReferCalculationLookupFrequency

Daily

EligiblePosition IncrementalTrade

DecrementalTrade

Weekly

WeekEndMean

SpecialInstructions0..1

0..1TradeDate

SettlementDate

TradeDate

SettlementDate



Draft number: 17

Date: 12 July 2016

Origin: HoldingAddress, HoldingValue, CashFlow

(Open Terms project, issue 02)


Key:






Select A or B

A

B

HoldingAddress

HoldingValue

Platform PlatformCode

Proprietary

CrestCo

DeutscheBorseClearingAG

CaisseInterprofessionelleDepotsVirementsTitres

FinnishCentralSecuritiesDepositoryLtd

SICOVAM

NECIGEF

Weekly

Daily

▼

CashFlow CashFlowType

CashFlowThresholdRelative

CashFlowThresholdAbsolute

Straight

Backward

Amount

Currency

0..1

0..1




Draft number: 17

Date: 12 July 2016

Origin: Payment, Report (OpenTerms project, issue 02)


Key:






Select A or B

A

BPayment PaymentNumber

ProRataPaymentInstrument PayThruFund

CreditTransferDetails

ChequeDetails

PayThruFundType

Reference

AgreementSectionCrossReference

0..1

1..N

PayThruFundSingleAccount

PayThruFundSet1..N

HoldingAddressPath


PayThruFundPayment1..N

ISINAndDescription

Ratio


PeriodicChargeNumberReference0..1

Currency

IntermediaryAgent1

IntermediaryAgent1Account

IntermediaryAgent2

IntermediaryAgent2Account

CreditorAgent

CreditorAgentAccount

Creditor

CreditorAccount

AgreementSectionCrossReference1..N


PeriodicChargeNumber

0..1

0..1

0..1

0..1

0..1

0..1

0..1

Reference

Currency

PayeeID




0..1

Report ReportNumber

ReportMethod PostalAddress

EmailAddress

FaxNumber

Other

1..N




HoldingAddressPath


ISIN

Description

a

a

0..1


▼

▼

▼

▼

▼

▼

▼

▼

▼

DirectDebitDetails Reference0..1

Currency

Debtor ▼

DebtorAccount ▼


0..1



0..1


PaymentName0..1

ReportName0..1


Part 3: Syntax rules listed in alphabetic order

Terms = Company, {Company}, Counterparty, {Counterparty}, Agreement, [Product, {Product}, {ProductExclusion}], [Market, {Market}, {MarketExclusion}], {TransactionChargeSet}, {PeriodicChargeSet}, {Payment}, {Report};

Affiliate = PartyIdentification, {PartyIdentification}, [AccessionDate, [SecessionDate]], {ContactDetails};

Agreement = AgreementID, VersionNumber, [ExecutionDate], [LegalAspects], [TermAndTermination];

AgreementSectionCrossReference = TransactionChargeNumber | PeriodicChargeNumber;

ApplicableLawAndJurisdiction = Law, Jurisdiction;

ApplicableNAV = 'ReferHoldingCount' | 'ReferCalculationLookupFrequency' | 'Daily';1

CalculationFrequency = 'Daily' | 'Weekly' | 'Monthly' | 'Quarterly' | 'HalfYearly' | 'Yearly';2

CashFlow = CashFlowType, [CashFlowThresholdRelative], [CashFlowThresholdAbsolute];

CashFlowThresholdAbsolute = Amount, Currency;

CashFlowType = 'Straight' | 'Backward'; 3

ChequeDetails = [Reference], Currency, PayeeID, AgreementSectionCrossReference, {AgreementSectionCrossReference};

Company = PartyIdentification, {PartyIdentification}, [CompanyCapacity], ContactDetails, {ContactDetails};

CompanyCapacity = CompanyCapacityCode | Proprietary;

CompanyCapacityCode = 'LegalRepresentative' | 'ManagementCompany' | 'GlobalDistributor' | 'Platform';4

CompareMethod = 'Arithmetic' | 'Geometric';5

ContactDetails = Name, [Title], [GivenName], [Role], [PhoneNumber], [FaxNumber], [EmailAddress], [SpecialInstructions];

Counterparty = PartyIdentification, {PartyIdentification}, [OfferRights], CounterpartyCapacity, {Affiliate}, ContactDetails, {ContactDetails};

CounterpartyCapacity = CounterpartyCapacityCode | Proprietary;

CounterpartyCapacityCode = 'Platform' | 'Distributor' | 'IntroducingAgent' | 'ProductPackager' | 'InstitutionalInvestor' | 'PlacementAgent' | 'CentralisingAgent';

6

CreditTransferDetails = [Reference], Currency, [IntermediaryAgent1], [IntermediaryAgent1Account], [IntermediaryAgent2], [IntermediaryAgent2Account], [CreditorAgent], [CreditorAgentAccount], [Creditor], CreditorAccount, AgreementSectionCrossReference, {AgreementSectionCrossReference};

DecrementalTrade = 'TradeDate' | 'SettlementDate';7

DeMinimisCharge = Currency, Threshold;

DeMinimisPayment = Currency, Threshold;

DirectDebitDetails = [Reference], Currency, [Debtor], DebtorAccount, AgreementSectionCrossReference, {AgreementSectionCrossReference};

EligiblePosition = IncrementalTrade, DecrementalTrade, [SpecialInstructions];

FeeSharePeriodicCharge = FeeSharePeriodicChargeCode | Proprietary, RateTable, [LookupFrequency];

FeeSharePeriodicChargeCode = 'ManagementFee' | 'DistributionFee' | 'Management+DistributionFee' | 'TotalExpenseRatio' | 'OngoingCharge' | 'TotalExpenseRatioCap' | 'OngoingChargeCap';

8

FixedCharge = FixedChargeType, Amount, Currency;

FixedChargeType = FixedChargeDescription | FixedChargeCode | Proprietary;

FixedChargeCode = 'BenchmarkChange' | 'MinimumPeriodicCharge';9

HoldingAddress = HoldingAddressType, HoldingAddressNumber, SharedAccount, [SharedAccountHoldingUpdateFrequency], [EligiblePosition];

HoldingAddressType = HoldingAddressPath | Platform;

HoldingCount = 'Daily' | 'Weekly' | 'Monthly' | 'Quarterly' | 'HalfYearly' | 'Yearly' | 'WeekEndMean' | 'MonthEndMean' | 'QuarterEndMean' | 'HalfYearEndMean' | 'YearEndMean';

10

HoldingValue = HoldingCount, ApplicableNAV;

IncrementalTrade = 'TradeDate' | 'SettlementDate';7


ISINAndDescription = ISIN, [Description];

Jurisdiction = Country, [Name];

LatePaymentPenalty = PenaltyRate, BaseRate;

LegalAspects = LegalTerms, {LegalVariation}, ApplicableLawAndJurisdiction, [MostFavouredTerms];

LookupFrequency = 'Daily' | 'Weekly' | 'Monthly' | 'Quarterly' | 'HalfYearly' | 'Yearly';11

Market = Country | Proprietary | URL;

MarketExclusion = Market;

OfferRights = OfferRightsAndDelegation | Proprietary | OfferRightsNarrative;

OfferRightsAndDelegation = OfferRightsCode, DelegationPermitted;

OfferRightsCode = 'PrivatePlacement' | 'PublicOffer' | 'PublicOfferAndPrivatePlacement' | 'None';12

OutPerformBenchmark = Description, [TickerIdentifier], CompareMethod;

PartialChargePeriodConvention = 'Long' | 'Short';13

PartyIdentification = AnyBIC | LEIIdentifier | ProprietaryID | NameAndAddress;

Payee = 'Company' | 'Counterparty';14

Payment = PaymentNumber, [PaymentName], PaymentInstrument;

PaymentCurrency = PaymentCurrencyBasis | Currency;

PaymentCurrencyBasis = 'BaseCurrency' | 'ShareClassCurrency' | 'MandateCurrency' | 'InvestmentCurrency';15

PaymentInstrument = PayThruFund | CreditTransferDetails | ChequeDetails | DirectDebitDetails, [SpecialInstructions];

PaymentMechanism = 'CompanyAutoPay' | 'CounterpartyInvoice';16

PayThruFund = PayThruFundType, [Reference], AgreementSectionCrossReference, {AgreementSectionCrossReference};

PayThruFundSet = HoldingAddressPath, HoldingAddressNumber, PayThruFundPayment, {PayThruFundPayment};

PayThruFundPayment = ISINAndDescription, [Ratio];

PayThruFundSingleAccount = HoldingAddressPath, HoldingAddressNumber;

PayThruFundType = 'ProRata' | PayThruFundSingleAccount | (PayThruFundSet, {PayThruFundSet});

PerformanceMeasurementDate = Month, Day;

PerformancePeriod = TermStartDate, TermEndDate, PerformanceMeasurementDate, PerformancePeriodType, PerformancePeriodYears;

PerformancePeriodHurdleConvention = 'Simple' | 'Compound';17

PerformancePeriodicCharge = ParticipationRate, [OutPerformBenchmark], PortfolioReturnMeasure, Hurdle, HighWaterMark, [OutPerformCap], PerformancePeriod, SeriesAccounting, [SpecialConditions];

PerformancePeriodStartConvention = PerformancePeriodStartConventionCode | Proprietary;

PerformancePeriodStartConventionCode = 'Neutral' | 'Progressive' | 'Adaptive';18

PerformancePeriodType = PerformancePeriodTypeCode, [PerformancePeriodStartConvention], [PerformancePeriodHurdleConvention];

PerformancePeriodTypeCode = 'Fixed' | 'Extensible' | 'Rolling';19

PeriodDays = 'CalendarDays365' | 'CalendarDays366' | 'StandardYear360';20

PeriodicCharge = PeriodicChargeNumber, [PeriodicChargeName], PeriodicChargeType, TermStartDate, TermEndDate, Product, {Product}, {ProductExclusion}, PeriodicChargeHolding, [PeriodicChargeAggregation], CalculationFrequency, PeriodicChargePeriod, PartialChargePeriodConvention, PeriodDays, YearDays, Payee, Discount, FeeSharePeriodicCharge | VolumePeriodicCharge | PerformancePeriodicCharge | FixedCharge;

PeriodicChargeAggregation = ProductAggregation, PeriodicChargeHoldingAggregation;

PeriodicChargeHolding = (PeriodicChargeHoldingDetails, {PeriodicChargeHoldingDetails}) | 'DefinedLater';

PeriodicChargeHoldingAggregation = 'Account' | HoldingAddressPath | (PeriodicChargeHoldingDetails, {PeriodicChargeHoldingDetails}) | 'DefinedLater';

PeriodicChargeHoldingDetails = HoldingAddress, (HoldingValue | CashFlow);

PeriodicChargePeriod = 'Weekly' | 'Monthly' | 'Quarterly' | 'HalfYearly' | 'Yearly';21


PeriodicChargeSet = PeriodicChargeSetNumber, [PeriodicChargeSetName], PeriodicCharge, {PeriodicCharge}, [NestedCharges], PaymentCurrency, [SettlementWithin], [RetrospectiveAdjustmentDeadline], [DeMinimisCharge], [DeMinimisPayment], PaymentMechanism, TerminationMode;

Platform = PlatformCode | Proprietary;

PlatformCode = 'ClearstreamBankLuxembourg' | 'Euroclear' | 'FundSettle' | 'CrestCo' | 'DeutscheBorseClearingAG' | 'CaisseInterprofessionelleDepotsVirementsTitres' | 'FinnishCentralSecuritiesDepositoryLtd' | 'SICOVAM' | 'NECIGEF';

22

PortfolioReturnMeasure = 'Net' | 'Gross';23

Product = ISINAndDescription | OtherID | URL;

ProductAggregation = ProductAggregationType | (Product, {Product}, {ProductExclusion});

ProductAggregationType = 'ShareClass' | 'SubFund' | 'Fund';24

ProductExclusion = Product;

RateTransactionCharge = RateTransactionChargeCode | Proprietary, RateTable;

RateTransactionChargeCode = 'FrontEndLoad' | 'BackEndLoad' | 'Switch' | 'Movement';25

RateMethod = 'FlatBand' | 'SlidingScale';26

RateTable = RateMethod, ReferenceCurrency, RateTableRow, {RateTableRow};

RateTableRow = Threshold, Rate;

Report = ReportNumber, [ReportName], ReportMethod, {ReportMethod}, AgreementSectionCrossReference, {AgreementSectionCrossReference}, [SpecialInstructions];

ReportMethod = PostalAddress | EmailAddress | FaxNumber | Other;

RetrospectiveAdjustmentDeadline = TimeLimitMonths | Other;

RunOff = PeriodMonths, AdmitNewPositions;

SettlementWithin = TimeLimitBusinessDays | TimeLimitCalendarDays | Other, [LatePaymentPenalty];

SharedAccountHoldingUpdateFrequency = 'Daily' | 'Weekly' | 'Monthly' | 'Quarterly' | 'HalfYearly' | 'Yearly';27

Term = FixedTermMonths | 'Open';

TermAndTermination = Term, TerminationNotice;

TermEndDate = Date | 'Open';

TerminationMode = TerminationType | RunOff;

TerminationNotice = Days | Months;

TerminationType = 'CoTerminusAgreement' | 'Survive';28

TermStartDate = Date | 'FirstInvestment';

TransactionCharge = TransactionChargeNumber, [TransactionChargeName], TransactionChargeType, TermStartDate, TermEndDate, Product, {Product}, {ProductExclusion}, TransactionChargeHolding, [TransactionChargeAggregation], TransactionChargePeriod, Discount, CounterpartyShare, CompanyShare;

TransactionChargeAggregation = ProductAggregation, TransactionChargeHoldingAggregation;

TransactionChargeHolding = (TransactionChargeHoldingAddress, {TransactionChargeHoldingAddress}) | 'DefinedLater';

TransactionChargeHoldingAddress = HoldingAddressPath, HoldingAddressNumber;

TransactionChargeHoldingAggregation = 'Account' | HoldingAddressPath | (TransactionChargeHoldingAddress, {TransactionChargeHoldingAddress}) | 'DefinedLater';

TransactionChargePeriod = 'Weekly' | 'SemiMonthly' | 'Monthly' | 'Quarterly' | 'HalfYearly' | 'Yearly';29

TransactionChargeSet = TransactionChargeSetNumber, [TransactionChargeSetName], TransactionCharge, {TransactionCharge}, PaymentCurrency, [SettlementWithin], [RetrospectiveAdjustmentDeadline], [DeMinimisPayment];

TransactionChargeType = RateTransactionCharge | FixedCharge;

VolumePeriodicCharge = VolumePeriodicChargeCode | Proprietary, RateTable, {RateTable}, [LookupFrequency];

VolumePeriodicChargeCode = 'TrailerFee' | 'IntermediaryServiceFee' | 'ItalianSubjectInChargePlacementFee' | 'FranceCentralisingAgentFee' | 'ManagementFee' | 'CustodyFee' | 'ReferralFee' | 'AdvisoryFee' | 'RealEstateFundFee' | 'LifeCompanyFee';

30

YearDays = 'CalendarDays365' | 'CalendarDays366' | 'StandardYear360' | 'StandardYear365.25';31


Part 4: The periodic charge formula

This formula applies only when the periodic charge is based on some rate such as a management fee or on the asset volume of the relevant holdings (i.e., when PeriodChargeType is a FeeSharePeriodicCharge or a VolumePeriodicCharge). If the periodic charge is a fixed charge, follow the instructions defined by the rule FixedCharge. If the periodic charge is based on performance, follow the instructions defined by the rule PerformancePeriodicCharge.

For each ISIN at each HoldingAddress, the periodic charge calculated under the terms of a particular PeriodicCharge instruction are:

Value of periodic charge = ∑ HoldingValuec × PeriodicChargeBasisFactor × Ratec ×

Final Cycle

c=1

DayCount

YearDays

where the terms in the formula have the following meaning:

c

The variable "c" counts from the first to the last periodic charge calculation cycle in the PeriodicChargePeriod.

FinalCycle

FinalCycle is the last calculation cycle in the PeriodicChargePeriod. It is set by the following parameters in the relevant PeriodicCharge instruction and the following table:

PeriodicCharge → PeriodicChargePeriod

PeriodicCharge → CalculationFrequency

PeriodicChargePeriod

Weekly Monthly Quarterly HalfYearly Yearly

Calc

ula

tio

nF

requency

Daily 7 Actual number of

calendar days in the month

Actual number of calendar days in the

quarter


half-year


year

Weekly 1 Actual number of

calendar weeks in the month

Actual number of calendar weeks in the

quarter


half-year


year

Monthly 1 3 6 12

Quarterly 1 2 4

HalfYearly Invalid 1 2

Yearly 1

In the case of a weekly CalculationFrequency the number of weeks in a month, quarter, half-year or year will be calculated in accordance with ISO 8601, which is briefly explained below:

ISO 8601 defines a calendar week as "an interval of seven calendar days starting with a Monday … " and it says that "… the first calendar week of a year is the one which includes the first Thursday of that year and […] the last calendar week of a calendar year is the week immediately preceding the first calendar week of the next calendar year."

Since years may be divided into months, quarters and halves, this definition permits the number of calendar weeks in each PeriodicChargePeriod to be calculated precisely. The DayCount and YearDays conventions described below are valid for both short and long ISO years (52 and 53 weeks).

For example, the year 2010 is described in the following table:


2010 Month length Quarter length Half-year length Year length

January 4 weeks, starting on 4 January 2010

February 4 weeks

March 4 weeks Q1: 12 weeks

April 5 weeks

May 4 weeks

June 4 weeks Q2: 13 weeks H1: 25 weeks

July 5 weeks

August 4 weeks

September 5 weeks Q3: 14 weeks

October 4 weeks

November 4 weeks

December 5 weeks, ending on 2 January 2011 Q4: 13 weeks H2: 27 weeks Year: 52 weeks

HoldingValue

HoldingValue is the value of the ISIN at the HoldingAddress, which is used on the cth calculation cycle in the

PeriodicChargePeriod. It is set by the following parameter in the relevant PeriodicCharge instruction:

PeriodicCharge → PeriodicChargeHolding → PeriodicChargeHoldingDetails → HoldingValue

(Note that HoldingValuec is not necessarily the same as the value of the ISIN at the HoldingAddress on the day that

the cth calculation cycle is run.)

PeriodicChargeBasisFactor

PeriodicChargeBasisFactor is a coefficient (of type ISO 20022 PercentageRate) that is set according to the following conditions:

(1) If PeriodicCharge → PeriodicChargeType is a FeeSharePeriodicCharge then:

― if FeeSharePeriodicChargeCode = 'ManagementFee' then set the PeriodicChargeBasisFactor to the Company's management fee applicable to the ISIN in the relevant period.

― if FeeSharePeriodicChargeCode = 'DistributionFee' then set the PeriodicChargeBasisFactor to the Company's distribution fee applicable to the ISIN in the relevant period.

― if FeeSharePeriodicChargeCode = 'Management+DistributionFee' then set the PeriodicChargeBasisFactor to the sum of the Company's management fee and the distribution fee applicable to the ISIN in the relevant period.

― if FeeSharePeriodicChargeCode = 'TotalExpenseRatio' then set the PeriodicChargeBasisFactor to the average total expense ratio applicable to the ISIN in the relevant period.

― If the FeeSharePeriodicCharge → Proprietary option is used then set the PeriodicChargeBasisFactor to the sum of the Company's fees that the parties have described, which were applicable to the ISIN in the relevant periodic charge period (and which must be a percentage rate that can be applied in the periodic charge formula).

(2) If PeriodicCharge → PeriodicChargeType is a VolumePeriodicCharge then set the PeriodicChargeBasisFactor to 100%.

Rate

Rate is set by the following parameters:

FeeSharePeriodicCharge → RateTable or VolumePeriodicCharge → RateTable (including all of its terms)

PeriodicCharge → PeriodicChargeAggregation

If the RateTable is a "flat rate" table, it will contain only one Rate, which should be applied directly to the periodic charge formula. In this case, the PeriodicCharge will contain no PeriodicChargeAggregation term. In all other cases, the Rate is determined by reading the RateTable as a FlatBand or SlidingScale table (see the definition of the rule RateTable) using the sum of the HoldingValues of the ISINs referenced by PeriodicChargeAggregation. The Rate should then be determined at the LookupFrequency or, if it is not defined, at the CalculationFrequency.


DayCount

DayCount is the number of days in the calculation cycle (not in the PeriodicChargePeriod). It is set by the following parameters in the relevant PeriodicCharge and the following table:

PeriodicCharge → PeriodDays

PeriodicCharge → CalculationFrequency

PeriodDays

CalendarDays365 CalendarDays366 StandardYear360

Calc

ula

tio

nF

requency Daily

Count every calendar day in the periodic charge calculation

cycle, except 29 February


cycle, including 29 February

Invalid Weekly

Monthly 30

Quarterly 90

Half-Yearly 180

Yearly 360

YearDays

YearDays is set by the following parameter in the relevant PeriodicCharge and the following table (see also the definition of the rule YearDays):

PeriodicCharge → YearDays

YearDays

CalendarDays365 CalendarDays366 StandardYear360 StandardYear365.25

Count every calendar day in the year,

except 29 February


including 29 February

360

365.25


Part 5: Cash flow adjustments for segregated mandates

Some segregated mandates are charged on the basis of the period-end market valuation of the client's investments (typically a quarter-end valuation). These charging schemes adjust the period-end valuation for cash movements (capital flows) instructed by the client during the period, to ensure that the charges are fair to the client and the manager.

There are two cash flow adjustment methods for calculating period-end charges: the "straight" and the "backward" method.

The straight method takes account of cash flows to calculate the weighted average adjusted assets under management during a period, to which the agreed rate table is applied to calculate the charges. The backward method takes account of cash flows to calculate the adjusted assets under management during each discrete time interval between cash flows during the charging period, and the agreed rate table is applied to each interval to calculate the charges. Cash flow adjustments may be subject to threshold criteria, to ensure that adjustments are not made for immaterial amounts.

Straight method

The value of a periodic charge is determined by the formula:

Value of periodic charge = (1

PeriodDays∑ AUMi × Daysi

n

i=1

) × Rate × DayCount

YearDays

Where:

PeriodDays = PeriodicCharge → PeriodDays.

n = number of discrete time intervals in the charging period delineated by cash flow events, (e.g., two cash flow events means three intervals). Interval 1 is the interval in which the last day of the charging period falls.

AUMi = the value of assets under management during interval i, meaning the market value of assets under management at close of business on the last day of the charging period, adjusted up for cash outflows and down for cash inflows in any interval following interval i. (Take care with direction: the adjustment works backwards from the last day in the charging period and cash flow effects appear inverted. See example below.)

Daysi = the number of calendar days duration of interval i (and the sum of all such days during all intervals i=1..n is equal to PeriodDays). Each interval starts on the day of the cash flow.

Example for the terms in parentheses above:

An account has a value of 12.8 million at the close of business on 31 December. The client withdrew 3 million on 3 December and paid in 5 million on 5 October. The billing period runs from 1 October to 31 December inclusive.

Interval "i" Ending Starting AUMi Comment Daysi

1 31 December 3 December 12.8 million 3 million outflow on 3 December 29

2 2 December 5 October 15.8 million 5 million inflow on 5 October 59

3 4 October 1 October 10.8 million 4

Therefore, the value of the terms in parentheses = 1/92 × (12.8 × 29 + 15.8 × 59 + 10.8 × 4) = 14.63695652 million.

Rate is set by the function to its left according to the following parameters:

VolumePeriodicCharge → RateTable (including all of its terms)


If the RateTable is a "flat rate" table, it will contain only one Rate, in which case, the PeriodicCharge will contain no PeriodicChargeAggregation term. In all other cases, the Rate is determined by reading the RateTable as a FlatBand or SlidingScale table (see the definition of the rule RateTable) using the value of AUMi. The Rate should be determined only once, for the entire charging period.

DayCount and YearDays: see below.


Backward method

The value of a periodic charge is determined by the formula:

Value of periodic charge = 1

PeriodDays ∑ (AUMi × Days

i× Ratei ×

DayCount

YearDays)

n

i=1

Where:

PeriodDays = PeriodicCharge → PeriodDays.

n = number of discrete time intervals in the period delineated by cash flow events, (e.g., two cash flow events means three intervals). Interval 1 is the interval in which the last day of the period falls.

AUMi = the value of assets under management during interval i, meaning the market value of assets under management at close of business on the last day of the charging period, adjusted up for cash outflows and down for cash inflows in any interval following interval i. (Take care with direction: the adjustment works backwards from the last day in the charging period and cash flow effects appear inverted. See the example table in the section above.)

Ratei is the rate set by AUMi according to the following parameters:

VolumePeriodicCharge → RateTable (including all of its terms)


If the RateTable is a "flat rate" table, it will contain only one Rate, in which case, the PeriodicCharge will contain no PeriodicChargeAggregation term. In all other cases, the Rate is determined by reading the RateTable as a FlatBand or SlidingScale table (see the definition of the rule RateTable) using the value of AUMi. The Rate should be determined only once, for the entire charging period.

DayCount and YearDays: see below.

Daysi = the number of calendar days duration of interval i. (See the example table in the section above.)

DayCount and YearDays (for Straight and Backward methods)

DayCount is the number of days in the PeriodicChargePeriod. It is set by the following parameter in the relevant PeriodicCharge and the following table:

PeriodicCharge → PeriodDays

PeriodDays

CalendarDays365 CalendarDays366 StandardYear360

Calc

ula

tio

nF

requency Daily


cycle, except 29 February


cycle, including 29 February

Invalid Weekly

Monthly 30

Quarterly 90

Half-Yearly 180

Yearly 360

YearDays

YearDays is set by the following parameter in the relevant PeriodicCharge and the following table (see also the definition of the rule YearDays):

PeriodicCharge → YearDays

(See table on next page.)


YearDays

CalendarDays365 CalendarDays366 StandardYear360 StandardYear365.25


except 29 February


including 29 February

360

365.25


Part 6: Syntax semantic definitions

Rule

Terms = Company, {Company}, Counterparty, {Counterparty}, Agreement, [Product, {Product}, {ProductExclusion}], [Market, {Market}, {MarketExclusion}], {TransactionChargeSet}, {PeriodicChargeSet}, {Payment}, {Report};

Synopsis

Terms of business are defined by the following elements:

Company A party making pooled funds available under the agreement or a party managing segregated mandates. Counterparty A party being granted sales rights in respect of the pooled funds and markets named in the agreement or a party who awards a segregated mandate to the Company. The Counterparty's affiliates also benefit from the terms of the agreement. Agreement The identity, execution date, legal texts and termination notice terms of the agreement. Product Pooled funds or segregated mandates which are in scope of the agreement. ProductExclusion Any members of a set of products that should be excluded from the scope of the agreement. Market The markets in which the Company grants the Counterparty rights to act in respect of the pooled funds described in Products. MarketExclusion Any members of a set of markets that should be excluded from the scope of the agreement. TransactionChargeSet Event driven charges such as pooled fund front-end loads, back-end loads and conversion (switch) charges and segregated mandate securities transaction charges. PeriodicChargeSet Periodic charges such as pooled fund rebates (ongoing commissions) that the Company will pay to the Counterparty, and segregated account management charges that the Counterparty will pay to the Company. Payment The means by which one party will pay amounts to the other party. Report The means by which one party will report charges to the other party.

Typology and constraints

Company: Defined in this document. Counterparty: Defined in this document. Agreement: Defined in this document. Product: Defined in this document. ProductExclusion: Defined in this document. Market: Defined in this document. MarketExclusion: Defined in this document. TransactionChargeSet: Defined in this document. PeriodicChargeSet: Defined in this document. Payment: Defined in this document. Report: Defined in this document.

User guide

This is the root of the rule set.

An agreement can be made between several Companies and Counterparties. This is useful, for example, in the event that one member of the Company group acts as manager for one fund whilst a second member acts as manager for a second fund and a third and subsequent members of the Company group act as legal representatives in particular jurisdictions, and all parties, funds and jurisdictions are described within a single global agreement to which several members of the Counterparty group are party.

In the context of pooled fund business, the agreement implies that the Counterparty will enjoy certain rights over the Products in all Markets subject to ProductExclusions and MarketExclusions, 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).

If several Products and ProductExclusions are defined, the result should be the relative complement of the union of all Products with respect to the union of all ProductExclusions. The same principle applies to Markets and MarketExclusions. Example:

An agreement has defined two sets of Products P1 and P2 and two sets of ProductExclusions P3 and P4.

The set of Products to which the Counterparty has rights under the agreement is therefore (P1 ∪ P2) \ (P3 ∪ P4).

A TransactionCharge or PeriodicCharge (both of which are defined later in this document) might refer to products that are not members of the set of Products defined by this top-level Terms rule. That is because the products might be related to another agreement between the parties or to another agreement between the Company and another member of the Counterparty's group or possibly vice versa. In that case, the Counterparty will have the right to have holdings in the related products taken into account when determining the transaction charge and period charge rates but it will have no other rights over them under the terms of the agreement (e.g., in the case of pooled funds it will have no right to distribute them).

TransactionChargeSet and PeriodicChargeSet are optional because it is possible that some agreements are made on terms that do not require these payments to be made. Payment and Report are optional because, (i) if no transaction charges or periodic charges are defined, no payments or reports will be necessary and (2) some parties prefer to maintain such details separately.


Rule

Affiliate = PartyIdentification, {PartyIdentification}, [AccessionDate, [SecessionDate]], {ContactDetails};

Synopsis

A party whom the Counterparty wishes to benefit from the terms of this agreement.

PartyIdentification Refer to the party by any BIC, proprietary identifier or name and address. AccessionDate Date upon which the party became the Counterparty's affiliate. SecessionDate Date upon which the party ceased to be the Counterparty's affiliate. ContactDetails Name of a person or department and communication address at which the affiliate can be contacted.


PartyIdentification: Defined in this document. AccessionDate: ISO 20022 ISODate SecessionDate: ISO 20222 ISODate ContactDetails: Defined in this document.

User guide

PartyIdentification may be given in more than one form, e.g., BIC and/or LEI and or a proprietary identifier and/or a name and address provided that each form given refers to the same unique affiliate.

AccessionDate and SecessionDate should be provided if they are known.

Rule

Agreement = AgreementID, VersionNumber, [ExecutionDate], [LegalAspects], [TermAndTermination];

Synopsis

The heads of the legal Agreement comprise the following elements:

AgreementID A text reference that the parties agree to assign to the agreement to aid their communication about the agreement. VersionNumber A number to discriminate this agreement from any others that the parties might have made under the same reference. ExecutionDate The date upon which this version of the agreement was executed. LegalAspects The clauses, variations, law and jurisdiction that are the legal foundation of the agreement. TermAndTermination The term of the agreement and any applicable termination notice periods.


AgreementID: ISO 20022 Max35Text. VersionNumber: ISO 20022 Max35Text. ExecutionDate: ISO 20022 ISODate. LegalAspects: Defined in this document. TermAndTermination: Defined in this document.

User guide

If the parties wish to track their business through order routing systems, they may ensure their anonymity (whilst preserving a unique identifier) by concatenating the AgreementID and VersionNumber values into a text string and transforming it using a suitable one-way hashing function, and using the hash digest as the tracking number.

A VersionNumber may be assigned to an agreement only once; it may never be reused. It may, however, be cited any number of times in correspondence about the agreement to which it refers.

Rule

AgreementSectionCrossReference = TransactionChargeNumber | PeriodicChargeNumber;

Synopsis

Defines the relationship between a payment mandate and the charge mandates (e.g., one or several TransactionCharges and/or PeriodicCharges) of the agreement.


TransactionChargeNumber: ISO 20022 Max3NumberNonZero, > 0. PeriodicChargeNumber: ISO 20022 Max3NumberNonZero, > 0.

User guide

Every payment mandate must refer to at least one charge mandate and every charge mandate must appear in at least one payment mandate. A payment mandate may refer to more than one charge mandate where the parties wish to settle through a single account. Several payment mandates may refer to the same charge mandate where the parties wish to settle in more than one currency.


Rule

ApplicableLawAndJurisdiction = Law, Jurisdiction;

Synopsis

The law applicable to the agreement and the courts of the jurisdiction to which the parties will submit.


Law: ISO 20022 CountryCode Jurisdiction: Defined in this document.

User guide

Jurisdiction may be used to describe the national jurisdiction and the courts within it, which may be a state within a federal system or some other tribunal or arbitration venue that the parties agree to use.

Rule

ApplicableNAV = 'ReferHoldingCount' | 'ReferCalculationLookupFrequency' | 'Daily';

Synopsis

Describes how to determine the net asset value per share (NAV) with which to calculate a HoldingValue.

ReferHoldingCount: Use the NAV that is applicable when the HoldingCount is measured. ReferCalculationLookupFrequency: Use the NAV that is applicable on the calculation day. Daily: Use every available NAV.


ApplicableNAV is an enumerated type implemented as the following four-letter codes:

'RECF' | 'DAIL' | 'REHC'.

User guide

Refer to the rule HoldingValue.

Rule

CalculationFrequency = 'Daily' | 'Weekly' | 'Monthly' | 'Quarterly' | 'HalfYearly' | 'Yearly';

Synopsis

Determines the frequency with which the periodic charges are calculated.


CalculationFrequency is an enumerated type implemented as the following four-letter codes:

'DAIL' | 'WEEK' | 'MNTH' | 'QUTR' | 'SEMI' | 'YEAR'.

User guide

Not defined.


Rule

CashFlow = CashFlowType, [CashFlowThresholdRelative], [CashFlowThresholdAbsolute];

Synopsis

Prepare a PeriodicCharge using a cash flow adjusted valuation:

CashFlowType Use a straight or backward cash flow adjustment method. CashFlowThresholdRelative Cash flow adjustment is to be applied only if the cash flow in the period exceeds the value of the relevant portfolio measured at the start of the PeriodicChargePeriod. CashFlowThresholdAbsolute Cash flow adjustment is to be applied if the cash flow in the period exceeds this absolute measure during the PeriodicChargePeriod.


CashFlowType: Defined in this document. CashFlowThresholdRelative: ISO 20022 PercentageRate, > 0. CashFlowThresholdAbsolute: Defined in this document.

User guide

If neither CashFlowThresholdRelative nor CashFlowThresholdAbsolute are defined then CashFlow must be applied.

If CashFlowThresholdRelative is defined then CashFlow should not be applied unless the cash movement for the HoldingAddress in the PeriodicChargePeriod expressed as a percentage of the value of the assets at the HoldingAddress measured at the start of the PeriodicChargePeriod exceeds the threshold.

If CashFlowThresholdAbsolute is defined then CashFlow should not be applied unless the cash movement for the HoldingAddress in the PeriodicChargePeriod exceeds the amount stated.

If CashFlowThresholdRelative and CashflowThresholdAbsolute are silmultaneously defined then CashFlow should not be applied unless both of the thresholds are exceeded (i.e., a logical AND test).

Rule

CashFlowThresholdAbsolute = Amount, Currency;

Synopsis

Set a threshold for the application of a cash flow adjustment method by reference to an amount and a currency.


Amount: ISO 20022 Number, > 0. Currency: ISO 20022 CurrencyCode.

User guide

See rule CashFlow.

Rule

CashFlowType = 'Straight' | 'Backward';

Synopsis

Determine whether a cash flow adjustment is to be calculated using the straight or the backward method.


CashFlowType is an enumerated type implemented as the following four-letter codes:

'STRT' | 'BKWD'.

User guide

See Part 5 of this document.


Rule

ChequeDetails = [Reference], Currency, PayeeID, AgreementSectionCrossReference, {AgreementSectionCrossReference};

Synopsis

Charges will be paid by one or more cheques using the following information:

Reference The reference that the parties have agreed to attach to the advice note covering each cheque. Currency The currency in which the cheque is to be issued. PayeeID The party to whom the cheque will be payable. AgreementSectionCrossReference References to the charge mandates for which this cheque mandate is to be used.


Reference: ISO 20022 Max35Text. Currency: ISO 20022 CurrencyCode. PayeeID: ISO 20022 NameAndAddress5. AgreementSectionCrossReference: Defined in this document.

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.

AgreementSectionCrossReferences define the relationship between a cheque mandate and the charge mandates (e.g., one or several TransactionCharge and/or PeriodicCharge) of the agreement.

AgreementSectionCrossReferences are not intended to be quoted directly in a cheque cover letter but they may be quoted in the charge statements and reports that are transmitted between the parties to an agreement. If the parties wish to agree to use operational references in their cheque cover letters to help them trace the payment to the agreement and the underlying TransactionCharges and/or PeriodCharges, they should define them in Reference.

Payments may be made separately according to the parties' preferences for arranging their business functionally, geographically or by product, or to keep periodic charges separate from transaction charges.

Rule

Company = PartyIdentification, {PartyIdentification} [CompanyCapacity], ContactDetails, {ContactDetails};

Synopsis

Define the name and address of the Company and its contact details.


PartyIdentification: Defined in this document. CompanyCapacity: Defined in this document. ContactDetails: Defined in this document.

User guide

PartyIdentification may be given in more than one form, e.g., BIC and/or LEI and or a proprietary identifier and/or a name and address provided that each form given refers to the same unique Company.

When more than one member of the Company group is a party to the agreement, CompanyCapacity may be used to indicate the capacity in which each member of Company group is acting. For example, it may be acting as management company to certain funds or as the legal representative in a certain jurisdiction.

Rule

CompanyCapacity = CompanyCapacityCode | Proprietary;

Synopsis

A Company's capacity may be defined by a pre-defined capacity code or by a proprietary capacity code.


CompanyCapacityCode: Defined in this document. Proprietary: ISO 20022 GenericIdentification30.

User guide

CompanyCapacityCode provides a set of common pre-defined capacities in which Company may act. The term "Proprietary" enables the parties to use an alternative code (alphanumeric, exactly 4 characters long) provided that they agree what it is and who issued it. For example, if the message is being used in the context where Company is a platform and Counterparty is a participating member, the parties may agree proprietary capacity codes that are suitable for their purposes. The meaning of these codes would be defined by the proprietary code issuer.


Rule

CompanyCapacityCode = 'LegalRepresentative' | 'ManagementCompany' | 'GlobalDistributor' | 'Platform';

Synopsis

The company may be acting in the capacity of:

LegalRepresentative The legal representative in a jurisdiction of some or all of the products covered by the agreement. ManagemementCompany The appointed management company to some or all of the products covered by the agreement. GlobalDistributor The global distributor of some or all of the products covered by the agreement. Platform A party providing administration and execution services to sales agents and/or intermediaries.


CompanyCapacityCode is an enumerated type implemented as the following four-letter codes:

'LREP' | 'MGCY' | 'GLDR' | 'PLFM'.

User guide

Company may be defined as one or more entities which promote or distribute a fund range or manage a segregated mandate. For example, it may be common for three Company entities to be party to an agreement:

Entity 1: a fund's management company, which has the responsibility for the commercialisation of a fund under home state law.

Entity 2: a fund's legal representative in a host state (for example, the legal representative for a foreign fund that is being sold in Switzerland).

Entity 3: a fund's global distributor, which may be different from its management company, and which may be responsible for granting and managing commercial rights to distribute the fund in several countries around the world.

In the event that an entity performs more than one role (for example, management company and global distributor), the Company should select the role that it considers to be the most significant (typically the management company).

These capacity descriptions are intended to be generally accepted industry roles. They are not meant to be precise legal definitions. If general roles would be unsatisfactory or if the parties want more definition than is provided by this rule, they may adopt proprietary capacity codes with attendant definitions in as much detail as they wish (see the rule CompanyCapacity → Proprietary).

Rule

CompareMethod = 'Arithmetic' | 'Geometric';

Synopsis

Describes how the outperformance of a portfolio is calculated with respect to the benchmark:

Arithmetic Calculate arithmetically. Geometric Calculate geometrically.


CompareMethod is an enumerated type implemented as the following four-letter codes:

'ARIT' | 'GEOM'.

User guide

Outperformance is the amount by which a portfolio return exceeds the benchmark return, usually expressed as a percentage. It can be calculated arithmetically or geometrically. Example:

Portfolio return: 10% Benchmark return: 5%

Arithmetic outperformance = 10% - 5% = 5%

Geometric outperformance = (1+10%) ÷ (1+5%) - 1 = 4.8%


Rule

ContactDetails = Name, [Title], [GivenName], [Role], [PhoneNumber], [FaxNumber], [EmailAddress], [SpecialInstructions];

Synopsis

Name of a person or department and communication address at which the affiliate can be contacted.

Name The name of the person or the department. Title If a person, their title (e.g., Mr, Mrs, Ms, Doctor). GivenName If a person, their given name or the name by which they are known. Role If a person, their role. PhoneNumber The telephone number to be used for contact. FaxNumber The facsimile number to be used for contact. EmailAddress The email address to be used for contact. SpecialInstructions Any special instructions to be used when making contact.


Name ISO 20022 Max70Text. Title ISO 20022 Max70Text. GivenName ISO 20022 Max70Text. Role ISO 20022 Max70Text. PhoneNumber ISO 20022 PhoneNumber. FaxNumber ISO 20022 PhoneNumber. EmailAddress ISO 20022 Max256Text. SpecialInstructions ISO 20022 Max2000Text.

User guide

Not defined.

Rule

Counterparty = PartyIdentification, {PartyIdentification}, [OfferRights], CounterpartyCapacity, {Affiliate}, ContactDetails, {ContactDetails};

Synopsis

Define the name and address of the Counterparty, its offer rights and optionally provide further information on the capacity in which it acts under the terms of this agreement. Also name any Counterparty affiliates that will benefit from the terms of the agreement and the contact persons.


PartyIdentification: Defined in this document. OfferRights: Defined in this document. CounterpartyCapacity: Defined in this document. Affiliate: PartyIdentification, defined in this document. ContactDetails: Defined in this document.

User guide

PartyIdentification may be given in more than one form, e.g., BIC and/or LEI and or a proprietary identifier and/or a name and address provided that each form given refers to the same unique Counterparty.

OfferRights should only be available if Markets have been defined.

Rule

CounterpartyCapacity = CounterpartyCapacityCode | Proprietary;

Synopsis

A Counterparty's capacity may be described by a pre-defined capacity code or by a proprietary capacity code.


CounterpartyCapacityCode: Defined in this document. Proprietary: ISO 20022 GenericIdentification30.

User guide

CounterpartyCapacityCode provides a set of common pre-defined capacities in which Counterparty may act. The term "Proprietary" enables the parties to use an alternative code (alphanumeric, exactly 4 characters long) provided that they agree what it is and who issued it.


Rule

CounterpartyCapacityCode = 'Platform' | 'Distributor' | 'IntroducingAgent' | 'ProductPackager' | 'InstitutionalInvestor' | 'PlacementAgent' | 'CentralisingAgent';

Synopsis

The Counterparty may be acting in the capacity of:

Platform A party providing administration and execution services to sales agents and/or intermediaries. Distributor An intermediary distributing shares to underlying investors or executing orders as global custodian. IntroducingAgent An introducing agent. ProductPackager A product packager, such as a life company or a structured product manufacturer. InstitutionalInvestor An institutional investor, investing for its own account.


CounterpartyCapacityCode is an enumerated type implemented as the following four-letter codes:

'PLFM' | 'DIST' | 'INAG' | 'PKGR' | 'INIV' | 'PLMA' | 'CENA'.

User guide

Counterparty should select the role that it considers to be most representative of the capacity in which it will act.

These capacity descriptions are intended to be generally accepted industry roles. They are not meant to be precise legal defintions. If general roles would be unsatisfactory or if the parties want more definition than is provided by this rule, they may adopt proprietary capacity codes with attendant definitions in as much detail as they wish (see the rule CounterpartyCapacity → Proprietary).

Rule

CreditTransferDetails = [Reference], Currency, [IntermediaryAgent1], [IntermediaryAgent1Account], [IntermediaryAgent2], [IntermediaryAgent2Account], [CreditorAgent], [CreditorAgentAccount], [Creditor], CreditorAccount, AgreementSectionCrossReference, {AgreementSectionCrossReference};

Synopsis

Describes one or more bank accounts to which a party will make credit transfers in respect of the charges due under the terms of the agreement:

Reference An operational reference that the parties have agreed to attach to each payment. Currency The currency of the CreditorAccount. IntermediaryAgent1 The first intermediary agent's identity. IntermediaryAgent1Account The first intermediary agent's account. IntermediaryAgent2 The second intermediary agent's identity. IntermediaryAgent2Account The second intermediary agent's account. CreditorAgent The creditor agent's identity. CreditorAgentAccount The creditor agent's account. Creditor The creditor's identity. CreditorAccount The creditor's account. AgreementSectionCrossReference Cross references to the related transaction charge and periodic charge mandates.


Reference ISO 20022 Max35Text. Currency ISO 20022 CurrencyCode. IntermediaryAgent1 ISO 20022 FinancialInstitutionIdentification7Choice. IntermediaryAgent1Account ISO 20022 AccountIdentificationAndName3. IntermediaryAgent2 ISO 20022 FinancialInstitutionIdentification7Choice. IntermediaryAgent2Account ISO 20022 AccountIdentificationAndName3. CreditorAgent ISO 20022 FinancialInstitutionIdentification7Choice. CreditorAgentAccount ISO 20022 AccountIdentificationAndName3. Creditor PartyIdentificationChoice, defined in this document. CreditorAccount ISO 20022 AccountIdentificationAndName3. AgreementSectionCrossReference Defined in this document.

User guide

This rule defines the creditor side of a payment chain.

AgreementSectionCrossReferences define the relationship between a credit transfer mandate and the charge-earning mandates (e.g., one or several TransactionCharges and PeriodicCharges) of the agreement.

AgreementSectionCrossReferences are not intended to be quoted directly within a SWIFT credit transfer message but they may be quoted in the charge statements and reports that are transmitted between the parties to an agreement. If the parties wish to agree to use operational references in their SWIFT payment messages to help trace the payment to the agreement and the underlying TransactionCharges and/or PeriodicCharges, they should define them in Reference. Parties who wish to use Reference in SWIFT FIN messages should limit the length of the field to 16 characters. Parties should also take care to ensure that the destination system that will process the message payload is capable of handling the character set used within the message. For example, many systems need special configuration to support character sets other than Latin-1.

Payments could be made through several mandates according to the parties' preferences for arranging their business functionally, geographically or by product, or to keep periodic charges separate from transaction charges, or for any other reason that the parties choose.


Rule

DecrementalTrade = 'TradeDate' | 'SettlementDate';

Synopsis

Determine how decremental trades (i.e., redemptions, switches out and transfers out) are measured for PeriodicChargeHolding and PeriodicChargeHoldingAggregation purposes:

TradeDate The trade is effective from the trade date. SettlementDate The trade is effective from the settlement date.


DecrementalTrade is an enumerated type implemented as the following four-letter codes:

'TRAD' | 'SETT'.

User guide

See also the rule EligiblePosition.

Rule

DeMinimisCharge = Currency, Threshold;

Synopsis

Determine the minimum threshold at which charges will be applied under the agreement:

Currency Charges might be in several currencies and must be converted to a single currency to perform the test. Threshold The threshold value to be used in the test.


Currency: ISO 20022 CurrencyCode. Threshold: ISO 20022 Number, > 0.

For pooled funds, DeMinimisCharge → Threshold <= DeMinimisPayment → Threshold.

User guide

For pooled funds, DeMinimisCharge is intended to ensure that the Counterparty earns periodic charges only if its holdings are commercially significant. If the Threshold is not exceeded, the Counterparty will forfeit the charges calculated for its business in that period.

For segregated mandates, DeMinimisCharge is intended to ensure that the Company receives at least the Threshold level of charges for managing the Counterparty's mandates (the actual charge applied shall be the greater of the charges calculated on the Counterparty's mandates and the Threshold).

See also the rules DeMinimisPayment and RateTableRow (which can be used in a complementary way in pooled funds).

Rule

DeMinimisPayment = Currency, Threshold;

Synopsis

Determine the minimum threshold at which charges will be paid under the agreement:

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


Currency: ISO 20022 CurrencyCode. Threshold: ISO 20022 Number, > 0.

For pooled funds, DeMinimisCharge → Threshold <= DeMinimisPayment → Threshold.

User guide

DeMinimisPayment is used to ensure that payments are generally made for commercially sensible amounts, equal to or greater than a threshold that is set by the parties to the agreement. The test is to be applied on the aggregate (i.e., total) amount payable.

Note that we do not apply the previous rule, DeMinimisCharge, to transaction charges because they are automatically deducted at the time of each transaction. However, we do apply the rule DeMinimisPayment because payment amounts might fall below a commercially reasonable level.


Rule

DirectDebitDetails = [Reference], Currency, [Debtor], DebtorAccount, AgreementSectionCrossReference, {AgreementSectionCrossReference};

Synopsis

Describes the debtor's bank account from which the creditor can directly debit the charges due under the terms of the agreement:

Reference An operational reference that the parties have agreed to attach to each payment. Currency The currency of the DebtorAccount. Debtor The debtor's identity. DebtorAccount The debtor's account. AgreementSectionCrossReference Cross references to the related transaction charge and periodic charge mandates.


Reference ISO 20022 Max35Text. Currency ISO 20022 CurrencyCode. Debtor PartyIdentification, defined in this document. DebtorAccount ISO 20022 AccountIdentificationAndName3. AgreementSectionCrossReference Defined in this document.

User guide

Not defined

Rule

EligiblePosition = IncrementalTrade, DecrementalTrade, [SpecialInstructions];

Synopsis

Determine a convention for measuring positions with respect to trade date or settlement date, and whether to include or exclude certain positions from a charge calculation:

IncrementalTrade Trades that increase the Counterparty's positions (subscriptions, switches in, transfers in). DecrementalTrade Trades that decrease the Counterparty's positions (redemptions, switches out, transfers out). SpecialInstructions Instructions to include or exclude certain positions.


IncrementalTrade: Defined in this document. DecrementalTrade: Defined in this document. SpecialInstructions: ISO 20022 Max2000Text.

User guide

The parties should set the trade date and settlement date parameters consistently for all trades that increase the Counterparty's position and for all trades that decrease the Counterparty's position. Therefore, these are the possible combinations for incremental and decremental trades:

IncrementalTrade: TRAD TRAD SETT SETT DecrementalTrade: TRAD SETT TRAD SETT

For the purposes of this rule the German concept of "valuta" is considered to be equivalent to 'SETT'.

The SpecialInstructions field may be used to include or exclude certain positions when calculating periodic charges. For example:

(1) When transferring accounts from one or more central transfer agents onto a consolidating platform, positions that existed before the consolidation date can be identified and treated separately.

(2) If a promoter / fund manager wishes to make a special promotion, in which the special rate persists for assets that are raised during the promotional period, the positions can be identified and treated separately.

The ability to identify positions with respect to time is a function of the system in which the shares are registered (not every system can do it). The SpecialInstructions free text field provides the flexibility to identify positions in a way that is compatible with the underlying system.


Rule

FeeSharePeriodicCharge = FeeSharePeriodicChargeCode | Proprietary, RateTable, [LookupFrequency];

Synopsis

Determine:

FeeSharePeriodicChargeCode The type of fee share periodic charge by reference to a standard code. Proprietary The type of fee share periodic charge by reference to a proprietary code. RateTable The rate at which the periodic charge should be applied. LookupFrequency How often the rate should be looked up.


FeeSharePeriodicChargeCode: Defined in this document. Proprietary: ISO 20022 GenericIdentification30. RateTable: Defined in this document. LookupFrequency: Defined in this document.

User guide

PeriodicCharge → PeriodicChargePeriod <= LookupFrequency <= PeriodicCharge → 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.

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

Rule

FeeSharePeriodicChargeCode = 'ManagementFee' | 'DistributionFee' | 'Management+DistributionFee' | 'TotalExpenseRatio' | 'OngoingCharge' | 'TotalExpenseRatioCap' | 'OngoingChargeCap';

Synopsis

A fee share periodic charge is based upon the rate of a fund's management fee, the distribution fee, the sum of the two, the fund's total expense ratio (TER), the ongoing charge (OGC), a total expense ratio cap or an ongoing charge cap.


FeeSharePeriodicChargeCode is an enumerated type implemented as the following four-letter codes:

'MANF' | ''DISF' | 'MADF' | 'TERF' | 'OGCF' | 'TERC' | 'OGCC'.

User guide

FeeSharePeriodicChargeCode is intended for use in pooled funds, which publish the relevant rates in their prospectuses or their financial reports.

The fund's total expense ratio will be calculated according to the methodology used by the fund's management company. Counterparty should inform itself of that methodology before using that option. The fund's ongoing charge will be calculated according to the methodology imposed upon the fund by its home state regulations governing the calculation of ongoing charges for use in point-of-sales materials (e.g., key information documents in the European Union).

TotalExpenseRatioCap and OngoingChargeCap differ from the other types of this charge in that the charge payable is the monetary value of the TER or OCG (calculated monthly using unaudited data) in excess of the TER or OGC cap described in the rate table. See also rule RateTableRow.

Rule

FixedCharge = FixedChargeType, Amount, Currency;

Synopsis

A PeriodicCharge or a TransactionCharge may be a fixed amount:

FixedChargeType The description of the charge. Amount The financial amount of the charge. Currency The currency in which Amount is expressed.


FixedChargeType: Defined in this document. Amount: ISO 20222 Number, > 0. Currency: ISO 20022 CurrencyCode.

User guide

Not defined.


Rule

FixedChargeType = FixedChargeDescription | FixedChargeCode | Proprietary;

Synopsis

A fixed charge may be described using a text description, a standard charge code or a proprietary charge code.


FixedChargeDescription: ISO 20022 Max2000Text. FixedChargeCode: Defined in this document. Proprietary: ISO 20022 GenericIdentification30.

User guide

Standard charge codes are defined by FixedChargeCode. New codes can be defined as proprietary codes provided that the parties to the agreement agree upon their definition.

Rule

FixedChargeCode = 'BenchmarkChange' | 'MinimumPeriodicChargeAmount';

Synopsis

Fixed charges may be applied for the following reasons:

BenchmarkChange When the parties to the agreement change the benchmark that they use to measure the performance of a Product. MinimumPeriodicChargeAmount To ensure that the PeriodicCharges applicable in a PeriodicChargePeriod are not less than a defined amount.


FixedChargeCode is an enumerated type implemented as the following four-letter codes:

'BMCH' | 'MPCA'.

User guide

A BenchmarkChange charge is the fixed charge applicable when the Counterparty requests the Company to change the benchmark that is used to measure the performance of a product, whether or not the benchmark is used in a performance fee. The charge is applied to each product; for example, five products measured to a common benchmark 'A' will give rise to five fixed charges when they change to a common benchmark 'B'.

A MinimiumPeriodicChargeAmount is the total PeriodicCharge that shall be applied in the event that the sum of all PeriodicCharges (excluding PerformanceBasedCharges) calculated in a PeriodicChargePeriod are less than the MinimiumPeriodicChargeAmount.

Rule

HoldingAddress = HoldingAddressType, HoldingAddressNumber, SharedAccount, [SharedAccountHoldingUpdateFrequency], [EligiblePosition];

Synopsis

Describe the addresses at which the Counterparty's investments are held:

HoldingAddressType The address refers to a holding at a transfer agency or a custodian or an internal accounting system or at Clearstream, Euroclear or FundSettle. HoldingAddressNumber The address number. SharedAccount The HoldingAddressType is an account-level address type and the account is shared with one or more other beneficial owners. SharedAccountHoldingUpdateFrequency The frequency at which the Counterparty's interest in a shared account will be analysed. EligiblePosition Positions are to be measured by trade date or settlement date and optionally included or excluded.


HoldingAddressType: Defined in this document. HoldingAddressNumber: ISO 20022 Max35Text. SharedAccount: ISO 20022 YesNoIndicator. SharedAccountHoldingUpdateFrequency: Defined in this document. EligiblePosition: Defined in this document.

SharedAccountHoldingUpdateFrequency must only be used if SharedAccountFlag is set to 'Yes' or 'True'.

User guide

Some parties prefer explicitly to define the SharedAccountHoldingUpdateFrequency for shared accounts, but it is not compulsory and charge calculation agents will infer a frequency from HoldingValue. Shared accounts are not normally analysed more frequently than monthly.

In some circumstances, the Counterparty may wish to include in the agreement an iCSD account number (e.g., Clearstream or Euroclear) whereas the Company's charge calculation agent may need to know the agent code that will be issued by the Company's transfer agent. Both are valid HoldingAddresses, although they point to the same holdings. It is acceptable to include both in the agreement provided that the charge calculation agent ensures that the holdings are not double-counted when calculating charges.


Rule

HoldingAddressType = HoldingAddressPath | Platform;

Synopsis

For each HoldingAddressNumber, the parties must say which organisation issued the number and, if it is a proprietary system, at which level in the system the number is meaningful.


HoldingAddressPath: ISO 20022 Max350Text. Platform: Defined in this document.

User guide

HoldingAddressPath is a string capable of addressing a specific transfer agency, global custodian, fund platform, etc., and the level in that agent's system at which the HoldingAddressNumber is meaningful. It does not require the syntax to know anything about the agent's identity or system design (for example, whether it defines objects such as investor identifiers, account numbers, agent codes, plan numbers, etc), but the parties must agree to use a meaningful string. We recommend that the parties adopt a "dotted" notation in the form "organisation.domicile.system_level" such as this:

"schroders.luxembourg.agentcode" HoldingAddressNumber is an agent code at Schroders' transfer agent in Luxembourg

"schroders.luxembourg.account" HoldingAddressNumber is an account number at Schroders' transfer agent in Luxembourg

"schroders.hongkong.agentcode" HoldingAddressNumber is an agent code at Schroders' transfer agent in Hong Kong

"ifds.uk.agentcode" HoldingAddressNumber is an agent code at IFDS' transfer agent in the UK

Rule

HoldingCount = 'Daily' | 'Weekly' | 'Monthly' | 'Quarterly' | 'HalfYearly' | 'Yearly' | 'WeekEndMean' | 'MonthEndMean' | 'QuarterEndMean' | 'HalfYearEndMean' | 'YearEndMean';

Synopsis

The number of shares or units of an ISIN at a holding address may be measured in the following ways (in each case at the close of business on the relevant day):

Daily Upon each calendar day. Weekly On the last day of a calendar week (Sunday). Monthly On the last day of a calendar month (31 January, 28/29 February, 31 March, 30 April, etc). Quarterly On the last day of a calendar quarter (31 March, 30 June, 30 September, 31 December). HalfYearly On the last day of a calendar half-year (30 June, 31 December). Yearly On the last day of a calendar year (31 December). WeekEndMean The arithmetic mean of the last day of a calendar week and the last day of the prior calendar week. MonthEndMean The arithmetic mean of the last day of a calendar month and the last day of the prior calendar month. QuarterEndMean The arithmetic mean of the last day of a calendar quarter and the last day of the prior calendar quarter. HalfYearEndMean The arithmetic mean of the last day of a calendar half-year and the last day of the prior calendar half-year. YearEndMean The arithmetic mean of the last day of a calendar year and the last day of the prior calendar year.


HoldingCount is an enumerated type implemented as the following four-letter codes:

'DAIL' | 'WEEK' | 'MNTH' | 'QUTR' | 'SEMI' | 'YEAR' | 'WKEM' | 'MNEM' | 'QUEM' | 'SAEM' | 'YREM'.

User guide

The parties should set HoldingCount to a value that is compatible with the holding address.

The start of a calendar week is each Monday (ISO 8601).


Rule

HoldingValue = HoldingCount, ApplicableNAV;

Synopsis

The value of a holding of an ISIN upon which a periodic charge is calculated is the product of the number of shares or units of the ISIN that are held and the applicable NAV per share or unit.


HoldingCount: Defined in this document. ApplicableNAV: Defined in this document.

User guide

The HoldingValue is a function of the HoldingCount and the ApplicableNAV and (by inference) the CalculationFrequency if the function is being used for periodic charge calculation or the LookupFrequency if it is being used for holding aggregation. The function is expressed in several forms. For example:

(1) The product of holdings and NAV on a particular day:

dd NAVHoldingsueHoldingVal

(2) The arithmetic mean of the product of holdings and NAV on each day in a particular period (e.g., every day in a month):

n

1idd ii NAVHoldings

n

1ueHoldingVal

Where:

n = number of days in the month d

i = day i

(3) The arithmetic mean of the product of holdings and NAV in nested periods (e.g., every month's-end holdings in a quarter and every day's NAV in each month):

a

1i

b

1jdd ji NAVHoldings

n

1ueHoldingVal

Where:

n = number of days in the quarter a = number of months in the quarter b = number of days in month i d

i = last day of month i

dj = day j in month i

There are many variants of the function, which permit different holdings and NAVs to be used. Only a few of them (the simple ones) are commonly used. A complete reference of the function HoldingValue for all 198 combinations of HoldingCount, ApplicableNAV and CalculationFrequency/LookupFrequency is at Part 6 of this document.

Some of the functions are deprecated (i.e., they should not be used except for system backward compatibility purposes). This is because they sample the NAV less often than they sample the HoldingCount, when it is clearly better to sample the NAV at least as often as the HoldingCount.

System designers should note that the functions are intended to perform mathematical division as late as possible in order to minimise the effect of rounding errors on the periodic charge calculation.

Rule

IncrementalTrade = 'TradeDate' | 'SettlementDate';

Synopsis

Determine how Incremental trades (i.e., subscriptions, switches in and transfers in) are measured for PeriodicChargeHolding and PeriodicChargeHoldingAggregation purposes:

TradeDate The trade is effective from the trade date. SettlementDate The trade is effective from the settlement date.


IncrementalTrade is an enumerated type implemented as the following four-letter codes:

'TRAD' | 'SETT'.

User guide

See also the rule EligiblePosition.


Rule

ISINAndDescription = ISIN, [Description];

Synopsis

An international securities identification number and a descriptor (typically the full name of the share class).


ISIN: ISO 20022 ISINIdentifier. Description: ISO 20022 Max140Text.

User guide

Not defined.

Rule

Jurisdiction = Country, [Name];

Synopsis

The courts of the jurisdiction to which the parties will submit in respect of the agreement.


Country: ISO 20022 CountryCode. Name: ISO 20022 Max70Text.

User guide

Not defined.

Rule

LatePaymentPenalty = PenaltyRate, BaseRate;

Synopsis

Determines any late payment penalties that may be agreed between the parties:

PenaltyRate The penalty rate of interest to be applied, set as an annual equivalent rate. BaseRate The base rate of interest with respect to which penalty interest should be calculated.


PenaltyRate: ISO 20022 PercentageRate, >= 0. BaseRate: ISO 20022 Max350Text.

User guide

LatePayment penalties should become payable from the day following the expiry of the payment deadline set by the term SettlementWithin and be calculated daily using the day count convention actual/actual.


Rule

LegalAspects = LegalTerms, {LegalVariation}, ApplicableLawAndJurisdiction, [MostFavouredTerms];

Synopsis

The essential legal framework for the agreement:

LegalTerms The legal terms of the agreement (industry standard terms or proprietary terms). LegalVariation Any variation to the LegalTerms. ApplicableLawAndJurisdiction The law which will govern the agreement and the courts to which the parties will submit. MostFavouredTerms The Company has most favoured nation status and in what respect.


LegalTerms: ISO 20022 Max350Text. LegalVariation: ISO 20022 Max350Text. ApplicableLawAndJurisdiction: Defined in this document. MostFavouredTerms: ISO 20022 Max2000Text.

User guide

LegalTerms is a text field that can contain the name of a model agreement, such as a model fund sales agreement or the Swiss Funds Association model distribution agreement, or a reference to a proprietary legal agreement.

An agreement may have several legal variations. For example:

(1) A generic model fund sales agreement may be extended by a model support annex that is relevant to a specific sector, such as the structured products sector, the life sector or the platform sector.

(2) A model agreement may be amended by the parties, the amendments being recorded in a legal variation document.

(3) An enabling agreement may be applied, such as may happen when a Counterparty gives a Company notice of a new sub-distributor's appointment.

(4) A proprietary agreement may be modified by a side letter.

LegalVariation is a free text field, which allows the parties to describe the legal variation in natural language. It may take the form of a reference to a document containing one or more statements of variation from the contracted legal terms of the agreement. It may also be a reference to a model document (e.g., a sector-specific extension of a master model agreement) or a proprietary document drawn up by the contracting parties. For example: "Amendment to the Agreement between ABC Promoter and XYZ Distributor dated 10 May 2011."

Rule

LookupFrequency = 'Daily' | 'Weekly' | 'Monthly' | 'Quarterly' | 'HalfYearly' | 'Yearly';

Synopsis

How often in a period the Counterparty's total holding values should be used to look up the Rate:

Daily Upon each calendar day. Weekly On the last day of a calendar week (Sunday). Monthly On the last day of a calendar month (31 January, 28/29 February, 31 March, 30 April, etc). Quarterly On the last day of a calendar quarter (31 March, 30 June, 30 September, 31 December). HalfYearly On the last day of a calendar half-year (30 June, 31 December). Yearly On the last day of a calendar year (31 December).


LookupFrequency is an enumerated type implemented as the following four-letter codes:


User guide

The start of a calendar week is each Monday (ISO 8601). If LookupFrequency is not defined, RateTable lookup will happen at the same frequency as CalculationFrequency.


Rule

Market = Country | Proprietary | URL;

Synopsis

Define a market to be a single country or a proprietary market definition or accessible via a URL.


Country: ISO 20022 CountryCode. Proprietary: ISO 20022 GenericIdentification1. URL: ISO 20022 Max256Text.

User guide

The Company may assemble the countries of a region into a set and assign a name (an identity, being a Max35Text field within the definition of the Proprietary type) to it, which its sales force and operations staff can use. For example, "Europe" might mean the set of countries including France, Germany, Italy, Spain, etc. The Company may define as many regions as it wishes and hold their names in its proprietary systems as standing data. Such definitions will be proprietary but they should not be considered private data, and should be disclosed to the Counterparty.

For example, a proprietary identifier for Schroders' definition of Europe, Middle East and Africa ("EMEA," which comprises at least three regions and many countries) would appear in message XML as:

<Mkt> <Prtry> <Id>EMEA</Id> <Issr>Schroders</Issr> </Prtry> </Mkt>

Because a proprietary definition is under the Company's control, the Company must provide the Counterparty with the means to expand it into the complete list of its members.

The Company must maintain each proprietary definition and ensure that new and historical definitions are made available to the Counterparty. The parties must agree how updates should be made, including whether they should support a "push model" (Company sends updates to Counterparty), a "pull model" (Counterparty requests updates from Company), or the use of third party agents such as KNEIP, WM Daten, Telekurs, etc., to support information exchange; incremental and entire updates; error correction, etc.

The Company may prefer to provide a URL to a web page or a document at which it will maintain its market definitions for its clients' easy access. For example:

http://www.schroders.lu/emea

(this is for illustration purposes only and is not a live URL)

Rule

MarketExclusion = Market;

Synopsis

Define a market exclusion to be a single country or a proprietary market definition or accessible via a URL.


See the definition of the rule Market in this document.

User guide

If the markets within the scope of the agreement are defined by reference to a pre-defined set of markets, one of more members of the set may be excluded from the scope. For example, if we define a proprietary market identifier "Nordics":

Nordics = 'DK', 'FI', 'IS', 'NO', 'SE';

And if we now wish to make an agreement covering all countries except Iceland:

Market = Nordics; MarketExclusion = 'IS';

See also the user guide of the rule Market in this document. If the practitioner prefers to define an exclusion using a free text statement (with care to ensure that it can be understood clearly), the URL option in the Market definition is a free text field of 256 characters.


Rule

OfferRights = OfferRightsAndDelegation | Proprietary | OfferRightsNarrative;

Synopsis

For pooled funds, determines what rights the Counterparty has to sell the Company's Products in the Markets, by reference to:

OfferRightsAndDelegation Offer and delegaton rights as defined by standard codes. Proprietary Rights as defined by some other proprietary code. OfferRightsNarrative Offer rights described in free text.


OfferRightsAndDelegation: Defined in this document. Proprietary: ISO 20022 GenericIdentification1. OfferRightsNarrative: ISO 20022 Max350Text.

User guide

OfferRightsAndDelegation is likely to be sufficient when the Counterparty is distributing funds by public offer and/or private placement in accordance with the Company's registrations and applicable laws, or where the Counterparty has no offer rights.

The term "Proprietary" enables the parties to use an alternative descriptor (a short text field of 35 characters) provided that they agree what it is and who issued it. For example, if the message is being used in the context where Company is a platform and Counterparty is a participating member, the parties may agree proprietary descriptors that are suitable for their purposes. The meaning of these descriptors would be defined by the platform, acting as the issuer of the proprietary scheme.

OfferRightsNarrative might be used when the parties do not wish to define proprietary descriptors but wish to use a short text description of the Counterparty's offer rights.

Rule

OfferRightsAndDelegation = OfferRightsCode, DelegationPermitted;

Synopsis

Determines:

OfferRightsCode What offer rights the Counterparty has. DelegationPermitted Whether the Counterparty may delegate its offer rights to a third party.


OfferRightsCode: Defined in this document. DelegationPermitted: ISO 20022 YesNoIndicator.

User guide

If the DelegationPermitted flag is set (='Yes' or 'True') the Counterparty may delegate to a third party its rights to sell the Company's products subject to the LegalTerms and any LegalVariation.

If the DelegationPermitted flag is not set (='No' or 'False') the Counterparty may only delegate to members of its own group its rights to sell the Company's products subject to the LegalTerms and any LegalVariation. The Counterparty may not delegate its offer rights to a third party.

Rule

OfferRightsCode = 'PrivatePlacement' | 'PublicOffer' | 'PublicOfferAndPrivatePlacement' | 'None';

Synopsis

Determines what rights the Counterparty has to sell the Company's Products in the Markets:

PublicOffer Counterparty may sell Company's products by public offer only. PrivatePlacement Counterparty may sell Company's products by private placement only. PublicOfferAndPrivatePlacement Counterparty may sell Company's products by public offer and private placement. None Counterparty has no rights to sell Company's products.


OfferRightsCode is an enumerated type implemented as the following four-letter codes:

'PPLA' | 'POFR' | 'POPP' | 'NONE'.

User guide

The Counterparty's right to sell the Company's products by public offer in a particular market is subject to that product being authorised for sale to the public in that market. The process of obtaining such authority and the practice of whether it is procured by the Company or the Counterparty, and the parties' compliance with applicable public offering rules is beyond the scope of the technical part of this project.

The Counterparty's right to sell the Company's products in a particular market by private placement is subject to that market's private placement rules, and is beyond the scope of the technical part of this project.

The option 'None' is relevant to agreements in which purpose is only to pay the Counterparty periodic charges on its investments.


Rule

OutPerformBenchmark = Description, [TickerIdentifier], CompareMethod;

Synopsis

Defines the benchmark that is used in performance fee calculations:

Description Free text description of the benchmark used to determine the performance of a portfolio. TickerIdentifier Free text short representation of the benchmark description, given by its sponsor. CompareMethod Describes how the outperformance of a portfolio is calculated with respect to the benchmark.


Description: ISO 20022 Max350Text. TickerIdentifier: ISO 20022 TickerIdentifier (which is ISO 20022 Max35Text). CompareMethod: Defined in this document.

User guide

Not defined.

Rule

PartialChargePeriodConvention = 'Long' | 'Short';

Synopsis

Determine how to calculate charges in the event that a PeriodicCharge does not align to the end of a calendar month, quarter, half-year or year:

Long Extend the adjacent period to create a long period. Short Calculate charges for the partial period separately from the adjacent period.


PartialChargePeriodConvention is an enumerated type implemented as the following four-letter codes:

'LONG' | 'SHOR'

User guide

In the example where a PeriodicCharge starts on 12 December in an agreement with quarterly calculation periods:

A long calculation period would run from 12 December to 31 March inclusive.

A short calculation period would run from 12 to 31 December inclusive.

Rule

PartyIdentification = AnyBIC | LEIIdentifier | ProprietaryID | NameAndAddress;

Synopsis

Identify a party by reference to:

AnyBIC Its business identifier code (ISO 9362). LEIIdentifier Its legal entity identifier (ISO 17442). ProprietaryID A proprietary identifier. NameAndAddress A name and address.


AnyBIC ISO 20022 AnyBICIdentifier. LEIIdentifier ISO 20022 LEIIdentifier. ProprietaryID ISO 20022 GenericIdentification1. NameAndAddress ISO 20022 NameAndAddress5.

User guide

Not defined.


Rule

Payee = 'Company' | 'Counterparty';

Synopsis

Determine who the beneficiary of a PeriodicCharge is:

Company The Company (e.g., in the case of a segregated management fee). Counterparty The Counterparty (e.g., in the case of a pooled fund periodic charge).


Payee is an enumerated type implemented as the following four-letter codes:

'CPNY' | 'CPTY'

User guide

Not defined.

Rule

Payment = PaymentNumber, [PaymentName], PaymentInstrument;

Synopsis

Payment mandates contain a mandate PaymentNumber, a PaymentName (a short name given by the Company for ease of reference) and a PaymentInstrument.


PaymentNumber: ISO 20022 Max3NumberNonZero, > 0. PaymentName: ISO 20022 Max70Text. PaymentInstrument: Defined in this document.

The PaymentNumber assigned to each Payment section should be unique within the scope of the agreement. For good administration, these numbers should be assigned in a contiguous sequence starting with '1'.

User guide

The PaymentNumber enables the parties to an agreement to uniquely refer to a payment mandate in their correspondence.

Rule

PaymentCurrency = PaymentCurrencyBasis | Currency;

Synopsis

Determine in what currency transaction charges and/or periodic charges will be paid:

PaymentCurrencyBasis In multiple currencies. Currency In a single currency.


PaymentCurrencyBasis: Defined in this document. Currency: ISO 20022 CurrencyCode.

User guide

If the Currency option is selected, all payments will be converted into that currency in accordance with the Company's normal operating procedures (i.e., auto FX is enabled).


Rule

PaymentCurrencyBasis = 'BaseCurrency' | 'ShareClassCurrency' | 'MandateCurrency' | 'InvestmentCurrency';

Synopsis

Payables for transaction charges and periodic charges should be:

BaseCurrency Paid in the fund's base currency (with automatic FX as necessary). ShareClassCurrency Paid in the currency of the share class in respect of which they were calculated. MandateCurrency Paid in the currency of the sub-mandate in respect of which they were calculated. InvestmentCurrency Paid in the currency in which the investments are denominated.


PaymentCurrencyBasis is an enumerated type implemented as the following four-letter codes:

'BCCY' | 'SCCY' | 'MCCY' | 'ICCY'.

User guide

The payment basis applies to pooled funds and segregated mandates as follows:

Basis Pooled fund Segregated mandate

BCCY The base currency of each fund (sub-fund within an umbrella) The reporting currency of the top-level mandate

SCCY The currency of each share class Not applicable

MCCY Not applicable The reporting currency of the sub-mandate

ICCY Not applicable The investment currency of the assets within a mandate

If the parties wish to ensure auto FX to a single currency they should use the option Currency in the rule PaymentCurrencyBasis.

Rule

PaymentInstrument = PayThruFund | CreditTransferDetails | ChequeDetails | DirectDebitDetails, [SpecialInstructions];

Synopsis

Payments of charges due can be made in four ways:

PayThruFund Through a purchase or sale of securities for or from a specific holding account. CreditTransferDetails Paying cash to one or more bank accounts. ChequeDetails Issuing one or more cheques. DirectDebitDetails Directly debiting the debtor's bank account. SpecialInstructions Any special instruction that might aid the understanding or application of the payment instruction.


PayThruFund: Defined in this document. CreditTransferDetails: Defined in this document. ChequeDetails: Defined in this document. DirectDebitDetails: Defined in this document. SpecialInstructions: ISO 20022 Max2000Text.

User guide

If a payment is by the Company to the Counterparty (e.g., in the case of a pooled fund commission) and the payment instrument is PayThruFund then the payment will be made as a purchase of shares or units the Company's funds indicated in that instrument.

If a payment is by the Counterparty to the Company (e.g., in the case of management fees for a pooled account) and the payment instrument is PayThruFund then the Company will take payment by selling the investments indicated in that instrument and retaining the proceeds.


Rule

PaymentMechanism = 'Company' | 'Counterparty';

Synopsis

Determine how periodic charge payments are initiated at the end of a charging period:

Company The Company will initiate the process. Counterparty The Counterparty will initiate the process.


PaymentMechanism isan enumerated type implemented as the following four-letter codes:

'CPNY' | 'CPTY'.

User guide

In the case of a segregated account it will be normal for the Company to initiate the process by sending an invoice to the Counterparty. In the case of pooled funds it is normal for the Company to initiate the process by preparing and paying charges and automatically, sending a statement to the Counterparty. However, sometimes the Counterparty prefers to initiate the payment of pooled fund periodic charges by sending an invoice to the Company, and in some markets this is common.

Rule

PayThruFund = PayThruFundType, [Reference], AgreementSectionCrossReference, {AgreementSectionCrossReference};

Synopsis

Payment of a transaction charge and/or a periodic charge is to be made through a purchase or sale of securities for or from one or several holding accounts:

PayThruFundType The accounts and securities through which the payment is to be made. Reference The operational references that the parties have agreed to attach to each related purchase or sale of securities. AgreementSectionCrossReference The transaction charges and periodic charges for which this PayThruFund mandate is to be used.


PayThruFundType: Defined in this document. Reference: ISO 20022 Max35Text. AgreementSectionCrossReference: Defined in this document.

User guide

Not defined.

Rule

PayThruFundFundSet = HoldingAddressPath, HoldingAddressNumber, PayThruFundPayment, {PayThruFundPayment};

Synopsis

Payment of a transaction charge and/or a periodic charge is to be made through a purchase or sale of one or several specific securities for or from a single specific holding account:

HoldingAddressPath Where the account is. HoldingAddressNumber The number of the account. PayThruFundPayment The purchase or sale instruction.


HoldingAddressPath: ISO 20022 Max350Text. HoldingAddressNumber: ISO 20022 Max35Text. PayThruFundPayment: Defined in this document.

User guide

Not defined.


Rule

PayThruFundPayment = ISINAndDescription, [Ratio];

Synopsis

A security through the purchase or sale of which the payment of a transaction charge or a periodic charge may be made. The Ratio is used to allocate the payment when this security is one of several through which the payment is to be made.


ISINAndDescription: Defined in this document. Ratio: ISO 20022 Max3NumberNonZero, > 0.

User guide

If Ratio is provided it must be provided for every security in the PayThruFundSet. For example, if three securities are provided with Ratios 3, 6 and 5 respectively, the total value of the payment should be allocated to them in the ratio 3:6:5. If Ratio is not provided then the total value should be allocated equally to each security.

Rule

PayThruFundSingleAccount = HoldingAddressPath, HoldingAddressNumber;

Synopsis

Payment of a transaction charge and/or a periodic charge is to be made through a purchase or sale of one or several securities for or from this specific account.


HoldingAddressPath: ISO 20022 Max350Text. HoldingAddressNumber: ISO 20022 Max35Text.

User guide

The identity of the securities to purchase or sell is derived from the context of the charge:

If it is a charge payable by the Company to the Counterparty (e.g., a pooled fund periodic charge), purchases are to be made for the account in the same securities on which the charges were calculated.

If it is a charge payable by the Counterparty to the Company (e.g., a segregated mandate management charge), sales are to be made from all available securities in the account, equally weighted by value.

Rule

PayThruFundType = 'ProRata' | PayThruFundSingleAccount | (PayThruFundSet, {PayThruFundSet});

Synopsis

The payment of a transaction charge or periodic charge is to be made through a purchase or sale of securities:

ProRata In proportion to the holdings in the securites upon which the charge was earned, and in the same holding accounts. PayThruFundSingleAccount Through a purchase or sale of one or several securities for or from a specific account. PayThruFundSet Through a purchase or sale of one or several specific securities for or from a single specific holding account.


ProRata: Literal. PayThruFundSingleAccount: Defined in this document. PayThruFundSet: Defined in this document.

User guide

Not defined.


Rule

PerformanceMeasurementDate = Month, Day;

Synopsis

Define the month and day in each year when portfolio performance will be measured against benchmark performance for the purpose of calculating performance-based fees.


Month: Integer range 1..12. Day: Interger range 1..31 (range to be truncated for short months)

User guide

Not defined.

Rule

PerformancePeriod = TermStartDate, TermEndDate, PerformanceMeasurementDate, PerformancePeriodType, PerformancePeriodYears;

Synopsis

Determine the parameters for a performance period:

TermStartDate Date on which this performance fee becomes valid (i.e., valid on and from this date). TermEndDate Date after which this performance fee ceases to be valid (i.e., valid on this date but not after). PerformanceMeasurementDate Month and day in each year on which portfolio performance is measured against benchmark. PerformancePeriodType Whether the performance period is fixed or rolling and how to deal with part periods. PerformancePeriodYears The duration of the performance period.


TermStartDate Defined in this document. TermEndDate Defined in this document. PerformanceMeasurementDate Defined in this document. PerformancePeriodType Defined in this document. PerformancePeriodYears Integer range 1..9.

User guide

Not defined.

Rule

PerformancePeriodHurdleConvention = 'Simple' | 'Compound';

Synopsis

Determine the convention for applying a performance fee hurdle:

Simple Compare the annualised performance of the portfolio in the performance period to the annualised performance of the benchmark plus the hurdle in the same period. Compound Compare the annualised performance of the portfolio in the performance period to the annualised performance of the benchmark plus the hurdle in each year of the performance period.


PerformancePeriodHurdleConvention is an enumerated type implemented as the following four-letter codes:

'SMPL' | 'CPND'.

User guide

For the simple method apply the function:

Annualise (Benchmark_Year1, Benchmark_Year2, Benchmark_Year3) + Hurdle.

For the compound method apply the function:

Annualise (Benchmark_Year1 + Hurdle, Benchmark_Year2 + Hurdle, Benchmark_Year3 + Hurdle).


Rule

PerformancePeriodicCharge = ParticipationRate, [OutPerformBenchmark], PortfolioReturnMeasure, Hurdle, HighWaterMark, [OutPerformCap], PerformancePeriod, SeriesAccounting, [SpecialConditions];

Synopsis

Defines the parameters for performance-based charges:

ParticipationRate The amount of the outperformance to be paid to the Company. OutPerformBenchmark The benchmark for measuring outperformance PortfolioReturnMeasure Whether portolio performance is to be measured net or gross of fees for performance fee calculations. Hurdle The level of return that the portfolio must achieve before it can apply a performance fee. HighWaterMark The highest net asset value of the portfolio during a performance period. OutPerformCap The limit of outperformance at which the ParticipationRate will become zero. PerformancePeriod The period of time in which the Company is eligible to earn a performance fee. SeriesAccounting Whether series accounting should be applied (see user guide below). SpecialConditions Any special conditions to the performance fee that have not been described by these parameters.


ParticipationRate: ISO 20022 PercentageRate, > 0. OutPerformBenchmark: Defined in this document. PortfolioReturnMeasure: Defined in this document. Hurdle: ISO 20022 PercentageRate, > 0. HighWaterMark: ISO 20022 YesNoIndicator. OutPerformCap: ISO 20022 PercentageRate, > 0. PerformancePeriod: Defined in this document. SeriesAccounting: ISO 20022 YesNoIndicator. SpecialConditions: ISO 20022 Max2000Text.

User guide

Hurdle should be set to zero if no hurdle is required.

If the SeriesAccounting flag is set (= "Yes" or "True"), assets purchased with funding provided by the Counterparty during the performance period should be measured separately from previously funded assets, as if they were a series of unrelated asset pools. Two or more pools may subsequently be combined into a single pool in the event that they crystallise a performance fee upon a common PerformanceMeasurementDate.

Rule

PerformancePeriodStartConvention = PerformancePeriodStartConventionCode | Proprietary;

Synopsis

Determine the convention for starting a rolling period:

PerformancePeriodStartConventionCode Apply a standard convention. Proprietary Apply a proprietary convention.


PerformancePeriodStartConventionCode: Defined in this document. Proprietary: ISO 20022 GenericIdentification30.

User guide

Not defined.


Rule

PerformancePeriodStartConventionCode = 'Neutral' | 'Progressive' | 'Adaptive';

Synopsis

Determine the convention for starting a performance period when there is insufficient portfolio performance history to make a complete comparison with the benchmark:

Neutral For periods in which portfolio performance is not available, simulate it based on benchmark performance. Progressive Calculate portfolio performance based on a one-year return in year one, a two-year return in year two, a three-year return in year three etc. Adaptive Apply the progressive convention and when a full portfolio performance history is available, recalculate the performance fee for the entire period based on the now-available performance history and adjust the already-billed fees as necessary.


PerformancePeriodStartConventionCode is an enumerated type implemented as the following four-letter codes:

'NEUT' | 'PROG' | 'ADAP'.

User guide

If the initial performance period does not align to the PerformanceMeasurementDate, use PartialChargePeriodConvention.

Rule

PerformancePeriodType = PerformancePeriodTypeCode, [PerformancePeriodStartConvention], [PerformancePeriodHurdleConvention];

Synopsis

Determine whether the performance period is fixed or rolling, how to deal with part periods, and how to manage the hurdle in the case of a rolling performance period:

PerformancePeriodTypeCode The performance period is fixed, extensible or rolling. PerformancePeriodStartConvention The convention for starting a performance period. PerformancePeriodHurdleConvention The convention for managing the hurdle in a performance period.


PerformancePeriodTypeCode: Defined in this document. RollingStartConvention: Defined in this document. RollingHurdleConvention: Defined in this document.

User guide

Not defined.

Rule

PerformancePeriodTypeCode = 'Fixed' | 'Extensible' | 'Rolling';

Synopsis

A performance period is:

Fixed Fixed to a definite duration expressed in years, after which a new period will begin. Extensible Fixed to a definite duration expressed in years, but may be extended in the case of under-performance. Rolling: Expressed as a rolling period of a specified duration.


PerformancePeriodTypeCode is an enumerated type implemented as the following four-letter codes:

'FIXD' | 'XTND' | 'ROLL'

User guide

In a fixed performance period, the duration of the period cannot exceed the limit of PerformancePeriodYears and a new performance period will begin immediately after the limit of the current performance period is reached. In an extensible performance period, if portfolio performance during the period is negative when the limit of PerformancePeriod is reached, the performance period will be extended until performance recovers to par, immediately after which a new performance period will begin. In a rolling performance period, the duration of the performance period is set by PerformancePeriodYears and rolls forward one year upon each PerformanceMeasurementDate.


Rule

PeriodDays = 'CalendarDays365' | 'CalendarDays366' | 'StandardYear360';

Synopsis

Determines the number of days to take into account in the periodic charge 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. StandardYear360 Every year is considered to be 360 standard days (and every month 30 standard days).

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


PeriodDays is an enumerated type implemented as the following four-letter codes:

'A365' | 'A366' | 'A360'.

User guide

PeriodDays should not be set to 'StandardYear360' if CalculationFrequency is set to 'Daily' or 'Weekly' because it does not adequately define on which days in a period the periodic charge calculation should be performed. For all other values of PeriodDays, CalculationFrequency may be set to 'Daily'.

If PeriodDays is set to 'StandardYear360' (a standard year) and CalculationFrequency is set to:

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

Typically, the members of this rule will correspond to the members of the rule YearDays in the following manner:

YearDays PeriodDays

CalendarDays365 CalendarDays365 CalendarDays366 CalendarDays366 StandardYear360 StandardYear360 StandardYear365.25 CalendarDays366


Rule

PeriodicCharge = PeriodicChargeNumber, [PeriodicChargeName], PeriodicChargeType, TermStartDate, TermEndDate, Product, {Product}, {ProductExclusion}, PeriodicChargeHolding, [PeriodicChargeAggregation], CalculationFrequency, PeriodicChargePeriod, PartialChargePeriodConvention, PeriodDays, YearDays, Payee, Discount, FeeSharePeriodicCharge | VolumePeriodicCharge | PerformancePeriodicCharge | FixedCharge;

Synopsis

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

PeriodicChargeNumber A unique identifier that allows easy reference to objects of this type in an agreement. PeriodicChargeName A short name given by the Company for ease of reference. PeriodicChargeType Whether this is a fee share, a volume-based, or a performance-based charge. TermStartDate Date on which this periodic charge becomes valid (i.e., valid on and from this date). TermEndDate Date after which this periodic charge ceases to be valid (i.e., valid on this date but not after). Product The products to which the periodic charges are to be applied. ProductExclusion Any members of a set of products to which the periodic charges should not be applied. PeriodicChargeHolding The holding addresses to which the periodic charges are to be applied. PeriodicChargeAggregation The products and holding addresses which are to be taken into account when looking up the periodic charge rate in RateTable. CalculationFrequency The frequency with which the periodic charges are calculated. PeriodicChargePeriod The duration of this periodic charge period. PeriodDays The number of days in the periodic charge period. YearDays The number of days in the year. Payee The beneficiary of the periodic charge. Discount The charge is a deduction from other amounts owed by the payor (see user guide). FeeSharePeriodicCharge The periodic charge is based on a fee share. VolumePeriodicCharge The periodic charge is based on asset volume. PerformancePeriodicCharge The periodic charge is based on outperformance relative to certain conditions. FixedCharge The periodic charge is a fixed amount.


PeriodicChargeNumber: ISO 20022 Max3NumberNonZero, > 0. PeriodicChargeName: ISO 20022 Max70Text. PeriodicChargeType: Defined in this document. TermStartDate: Defined in this document. TermEndDate: Defined in this document. Product: Defined in this document. ProductExclusion: Defined in this document. PeriodicChargeHolding: Defined in this document. PeriodicChargeAggregation: Defined in this document. CalculationFrequency: Defined in this document. PeriodicChargePeriod: Defined in this document. PeriodDays: Defined in this document. YearDays: Defined in this document. Payee Defined in this document. Discount ISO 20022 YesNoIndicator. FeeSharePeriodicCharge Defined in this document. VolumePeriodicCharge Defined in this document. PerformancePeriodicCharge Defined in this document. FixedCharge Defined in this document.

The PeriodicChargeNumber assigned to each PeriodicCharge section should be unique within the scope of the agreement. For good administration, these numbers should be assigned in a contiguous sequence starting with '1'.

User guide

The PeriodicChargeNumber should be unique within the scope of a particular agreement. The same value of PeriodicChargeNumber can therefore be used in different agreements between the same parties. If the parties wish to refer uniquely to a particular periodic charge amongst all of their agreements, they should do so by a combination of AgreementID and the periodic charge section's PeriodicChargeNumber.

Different PeriodicCharges may be created to define periodic charges by Product (e.g., bond funds, equity funds, style funds) or by PeriodicChargeHolding (if the parties wish to set different rates for different business divisions within the Counterparty). By varying certain terms such as the TermStartDate, TermEndDate and the RateTable it is possible to create periodic charges which are valid for an introductory or otherwise special period and which will be replaced with standard charges after that period.

Duplicate periodic charges may occur where the Products, PeriodicChargeHoldings and time dimensions of two or more PeriodicCharges intersect. Normally this indicates an error and by default duplicates should be treated as such: charge calculation agents should normally investigate and correct them. If the parties wish to permit duplicate periodic charges (and in some circumstances they do), they should record their agreement in their proprietary legal terms or a legal variation statement, which should include a description of how the duplicates should be processed (for example, whether the charge calculation agent should pay all duplicates or select only one for payment using agreed criteria).

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

The concept of aggregation (i.e., to obtain the best possible charge rate from a multi-row RateTable) is not applicable if the RateTable is a "flat rate" table because there is only one row in the RateTable). In such cases (and only in such cases), the term PeriodicChargeAggregation should be excluded from the PeriodicCharge.


Rule

PeriodicCharge (continued)

User guide (continued)

If an aggregation rule uses a special aggregation list (see the relevant definition of each rule), care should be taken to verify that there is a reasonable connection between the members of that list and the holding addresses and products to which the periodic charges are being applied. Generally in such cases:

Product ProductAggregation and PeriodicChargeHolding PeriodicChargeHoldingAggregation

If the Discount flag is set, the value of charges calculated in this PeriodicCharge instruction will be deducted from any amounts owed by the payor to the payee in the period. This enables the parties to the agreement to set up charges with the correct Payee setting and corresponding correct tax treatment but apply the benefit in the reverse direction. For example, in the case of a segregated account management fee the Payee would be the Company; setting the Discount flag to "Yes" or "True" would credit the fee to the Counterparty.

Rule

PeriodicChargeAggregation = ProductAggregation, PeriodChargeHoldingAggregation;

Synopsis

Determines the aggregation policy for a periodic charge based upon related products and holding addresses.


ProductAggregation: Defined in this document. PeriodicChargeHoldingAggregation: Defined in this document.

User guide

Aggregation policy may be used to modify the rate of a periodic charge based upon a set of products and holding addresses greater than those to which periodic charges are to be applied under the terms of an individual PeriodicCharge. For example, a periodic charge applicable to equity funds sold by the retail division of a financial institution may use a rate based upon the aggregated holdings of all types of fund held by that institution's retail, institutional and wealth management divisions.

Rule

PeriodicChargeHolding = (PeriodicChargeHoldingDetails, {PeriodicChargeHoldingDetails}) | 'DefinedLater';

Synopsis

Determine a party's holdings upon which periodic charges will be calculated:

PeriodicChargeHoldingDetails The holding address and valuation instructions. DefinedLater The holdings address and valuation instructions will be defined later.


PeriodicChargeHoldingDetails Defined in this document. DefinedLater Literal.

User guide

Not defined.


Rule

PeriodicChargeHoldingAggregation = 'Account' | HoldingAddressPath | (PeriodicChargeHoldingDetails, {PeriodicChargeHoldingDetails}) | 'DefinedLater';

Synopsis

Aggregation is the calculation of periodic charges on individual securities or mandates at rates that reflect a larger business relationship. In each case, the holding value of the security or mandate is aggregated with the related holdings of relevant products according to the following options:

Account Within the same holding account. HoldingAddressPath Within holding accounts that share the same HoldingAddressNumber as the periodic charge-earning security (which is determined by reference to the HoldingAddressPath) PeriodicChargeHoldingDetails Within a special list of holding addresses. DefinedLater Within a special list of holding addresses that will be defined later.


Account: Literal. HoldingAddressPath: ISO 20022 Max350Text. PeriodicChargeHoldingDetails: Defined in this document. DefinedLater: Literal.

User guide

Aggregating holdings on the basis of HoldingAddressPath using an account-level address type is synonymous with aggregating on the basis of the Account flag. Generally, the Account flag option should be used if account-level aggregation is required because its context comes from the account upon which the charges are being processed. It can therefore switch context (e.g., from a central transfer agency account to a global custodian account to a Clearstream account) easily as the charge calculation process moves from one account to another. The HoldingAddressPath cannot do this, and it should only be used if aggregation at a different level (e.g., agent code) is required within the context of a specific administration system.

The Account flag and HoldingAddressPath options cannot aggregate holdings from several depositories. To do that, the parties to the agreement must provide a special list of holding addresses (PeriodicChargeHoldingDetails, in the rule above) that they wish to aggregate. The parties can use such a list to construct sophisticated aggregation policies, for example, by aggregating retail holdings with private banking and institutional holdings within the context of a global agreement.

When the Account flag or HoldingAddressPath options are used, positions should be measured on the same basis as the charge-earning positions (i.e. as determined by the parameter PeriodicCharge → PeriodicChargeHolding → PeriodicChargeHoldingDetails → HoldingValue).

Rule

PeriodicChargeHoldingDetails = HoldingAddress, (HoldingValue | CashFlow);

Synopsis

Determine a party's holdings upon which periodic charges will be calculated:

HoldingAddress The holding address. HoldingValue The policy for measuring the value of the holdings. CashFlow The policy for measuring the value of the holdings when using adjusted cash flow principles.


HoldingAddress: Defined in this document. HoldingValue: Defined in this document. CashFlow: Defined in this document.

User guide

There should be no duplicates of HoldingAddress in PeriodicChargeHoldingDetails.


Rule

PeriodicChargePeriod = 'Weekly' | 'Monthly' | 'Quarterly' | 'HalfYearly' | 'Yearly';

Synopsis

Determines the duration of a periodic charge period.


PeriodicChargePeriod is an enumerated type implemented as the following four-letter codes:

'WEEK' | 'MNTH' | 'QUTR' | 'SEMI' | 'YEAR'.

User guide

The start date of a periodic charge period is derived in the following way:

If the value is Weekly, each period will start on a Monday (ISO 8601).

If the value is Monthly, each period will start on the first calendar day of each calendar 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 HalfYearly, each period will start on 1 January and 1 July.

If the value is Yearly, each period will start on 1 January.

If the TermStartDate or the TermEndDate does not coincide with the first or last day of a period respectively, the Company must manually adjust the first or last period according to PartialChargePeriodConvention.

PeriodicCharge periods of SemiMonthly duration are not used in periodic charge calculations.

A period normally contains one or more calculation cycles.

Rule

PeriodicChargeSet = PeriodicChargeSetNumber, [PeriodicChargeSetName], PeriodicCharge, {PeriodicCharge}, [NestedCharges], PaymentCurrency, [SettlementWithin], [RetrospectiveAdjustmentDeadline], [DeMinimisCharge], [DeMinimisPayment], PaymentMechanism, TerminationMode;

Synopsis

Define what periodic charges are payable and under what conditions:

PeriodicChargeSetNumber A unique identifier that allows easy reference to objects of this type in an agreement. PeriodicCharge terms are arranged as repeating groups according to product, functional or geographic preferences. PeriodicChargeSetName A short name given by the Company for ease of reference. NestedCharges In segregated mandates comprising multiple underlying accounts including Company funds, determines whether charges are to be applied at the top level account only or to the top level account and to each underlying account and Company fund. PaymentCurrency Payment is to be made in the currencies of the securities in respect of which charges were calculated or in a single currency. SettlementWithin Payments are to be made within an agreed number of days of the end of the period. RetrospectiveAdjustmentDeadline Adjustments to erroneous calculations may only be made within a certain deadline. DeMinimisCharge The minimum threshold at which charges will be applied. DeMinimisPayment The minimum threshold at which charges will be paid. PaymentMechanism How payments will be initiated TerminationMode How charges will survive the termination of the agreement.


PeriodicChargeSetNumber: ISO 20022 Max3NumberNonZero, > 0. PeriodicChargeSetName: ISO 20022 Max70Text. PeriodicCharge: Defined in this document. NestedCharges: ISO 20022 YesNoIndicator. PaymentCurrency: Defined in this document. SettlementWithin: Defined in this document. RetrospectiveAdjustmentDeadline: Defined in this document. DeMinimisCharge Defined in this document. DeMinimisPayment Defined in this document. PaymentMechanism Defined in this document. TerminationMode Defined in this document.

The PeriodicChargeSetNumber assigned to each PeriodicChargeSet section should be unique within the scope of the agreement. For good administration, these numbers should be assigned in a contiguous sequence starting with '1'.

User guide

If SettlementWithin, RetrospectiveAdjustmentDeadline and DeMinimisPayment are not defined, then the settlement, adjustment and de minimis payment terms will be determined according to the Company's normal business practice. DeMinimisCharge may not be applied unless it is defined in the agreement.

If NestedCharges is set to 'No' or 'False', charges must be applied at the top-level account only and if it is set to 'Yes' or 'True' charges must be applied to the top level account and to each underlying account and fund. NestedCharges instructions must be provided for segregated mandates.


Rule

Platform = PlatformCode | Proprietary;

Synopsis

Identifies a platform for periodic charge holdings:

PlatformCode The platform has a pre-defined ISO 20022 code. Proprietary The platform is identified by a proprietary code.


PlatformCode: Defined in this document. Proprietary: ISO 20022 GenericIdentification30.

User guide

The PlatformCode list initially identifies only Clearstream, Euroclear and FundSettle. Other codes may be defined in the future but until then parties to an agreement can extend the code list with additional proprietary codes (alphanumeric, exactly 4 characters long).

Rule

PlatformCode = 'ClearstreamBankLuxembourg' | 'Euroclear' | 'FundSettle' | 'CrestCo' | 'DeutscheBorseClearingAG' | 'CaisseInterprofessionelleDepotsVirementsTitres' | 'FinnishCentralSecuritiesDepositoryLtd' | 'SICOVAM' | 'NECIGEF';

Synopsis

A list of codes for commonly used platforms.


PlatformCode is an enumerated type implemented as the following four-letter codes:

'CEDE' | 'EOCC' | 'FSTL' | 'CRST' | 'DAKV' | 'CIKB' | 'APKE' | 'SICV' | 'NECI'.

User guide

Not defined.

Rule

PortfolioReturnMeasure = 'Net' | 'Gross';

Synopsis

Determine whether to measure portfolio performance net or gross of fees when calculating performance fees.


PortfolioReturnMeasure is an enumerated type implemented as the following four-letter codes:

'NETT' | 'GROS'.

User guide

If the net method is used the parties should make clear what they mean by "fees", describing them in the main body of their agreement or in a LegalVariation statement.


Rule

Product = ISINAndDescription | OtherID | URL;

Synopsis

Defines the product or set of products in respect of which the Company grants the Counterparty rights in the Markets (in the case of pooled fund distribution) and/or upon which transaction charges or periodic charges will be based (whether directly, or indirectly by aggregation). Can be a single product or a proprietary product definition or a definition accessible via a URL:

ISINAndDescription A single ISIN with its description. OtherID Another identifier, which may be a securities identifier or a proprietary identifier for a set of securities. URL: A URL at which the definition of Product is maintained by the Company.


ISINAndDescription: Defined in this document. OtherID: ISO 20022 OtherIdentification1. URL: ISO 20022 Max256Text.

Each member of Products should be unique: there should be no duplicates of any ISINAndName or OtherID. Charge calculation agents should manage the undesirable effects of duplicate products arising from an intersection of one OtherID with another by ensuring that duplicates are removed before charge calculations are performed.

User guide

The Company may assemble similar funds (e.g., equity, fixed income, sector, etc.) or similar categories of products (e.g., A shares) into a set and assign to it a name (an identity, being a Max35Text field within the definition of type OtherID), which its sales force and operations staff can refer to in its agreements. The Company may define as many product sets as it wishes and hold their names in its proprietary systems as standing data. Such definitions will be proprietary but they should not be considered private data, and should be disclosed to the Counterparty.

For example, a proprietary identifier for the set of "Schroder International Selection Fund SICAV equity funds 'A' accumulation shares" (which is a set of more than 100 ISINs) would appear in message XML as:

<OthrId> <Id>SISF Equity A Acc</Id> <Tp> <Prtry>Schroders</Prtry> </Tp> </OthrId>

Because OtherID is a proprietary definition under the Company's control, the Company must provide the Counterparty with the means to expand it into the complete list of its members.

The Company must maintain each proprietary definition of OtherID and ensure that new and historical definitions are made available to the Counterparty. The parties must agree how updates should be made, including whether they should support a "push model" (Company sends updates to Counterparty); a "pull model" (Counterparty requests updates from Company); the use of third party agents such as KNEIP, WM Daten, Telekurs, etc., to support information exchange; incremental and entire updates; error correction, etc.

The Company may prefer to provide a URL to a web page or a document at which it will maintain its product definitions for its distributors' easy access. For example:

http://www.schroders.lu/SISF/Equity/A/Acc

(this is for illustration purposes only and is not a live URL)

Rule

ProductAggregation = ProductAggregationType | (Product, {Product}, {ProductExclusion});

Synopsis

Aggregation is the calculation of transaction charges and/or periodic charges on individual securities or mandates at rates that reflect a larger business relationship. In each case, the holding value of the charge-earning security or mandate is aggregated with the relevant holdings of related products. ProductAggregation can be defined in two ways:

ProductAggregationType With all securities or mandates that belong to the same family. Product With all securities or mandates that are members of a special list of products. ProductExclusion Any members of a set of products that should be excluded for aggregation purposes.


ProductAggregationType: Defined in this document. Product: Defined in this document. ProductExclusion: Defined in this document.

User guide

The parties to an agreement can use the special list of products to construct sophisticated aggregation policies, for example, by aggregating all equities or bonds or shares of a certain class (e.g., A, B, C) without restriction of what range of funds or fund or sub-fund they belong to.


Rule

ProductAggregationType = 'ShareClass' | 'SubFund' | 'Fund';

Synopsis

Aggregation is the calculation of transaction charges and periodic charges on individual ISINs at rates that reflect a larger business relationship. In each case, the holding value of the charge-earning ISIN is aggregated with the relevant holdings of related products according to the following options:

Share With shares that have the same ISIN. SubFund With all ISINs that are members of the same sub-fund within an umbrella fund. Fund With all ISINs that are members of the same single-compartment fund or multiple-compartment "umbrella" fund.


ProductAggregationType is is an enumerated type implemented as the following four-letter codes:

'SHRE' | 'SFND' | 'FUND'.

User guide

ProductAggregationType may only be used for pooled funds. All other types of aggregation must be defined in terms of Product (see the definition in this document).

Rule

ProductExclusion = Product;

Synopsis

Define a product exclusion to be a single product or a proprietary product definition or a definition accessible via a URL


See the definition of Product in this document;

User guide

If the products referred to by any part of the agreement are defined by reference to a pre-defined set of products, one of more members of the set may be excluded from the scope of that part of the agreement. For example, if we define a proprietary product identifier "Equities":

Equities = 'Fund A', 'Fund B', 'Fund C', 'Fund D', 'Fund F';

And if we now wish to use that definition of the product set Equities excluding Fund C:

Product = Equities; ProductExclusion = 'Fund C';

See also the user guide of the rule Product in this document. If the practitioner prefers to define an exclusion using a free text statement (with care to ensure that it can be understood clearly), the URL option in the Product definition is a free text field of 256 characters.

Rule

RateTransactionCharge = RateTransactionChargeCode | Proprietary, RateTable;

Synopsis

Determine:

RateTransactionChargeCode The type of rate transaction charge by reference to a standard code. Proprietary The type of rate transaction charge by reference to a proprietary code. RateTable The rate at which the transaction charge should be applied.


RateTransactionChargeCode: Defined in this document. Proprietary: ISO 20022 GenericIdentification30. RateTable: Defined in this document.

User guide

Not defined.


Rule

RateTransactionChargeCode = 'FrontEndLoad' | 'BackEndLoad' | 'Switch' | 'Movement';

Synopsis

The transaction charge may be a front-end load, a back-end load, a switch or a movement charge.


RateTransactionChargeCode is an enumerated type implemented as the following four-letter codes:

'FEND' | 'BEND' | 'SWIT' | 'MVMT'.

User guide

A "movement" charge is raised by Company for each purchase or sale of securities for Counterparty's account.

Rule

RateMethod = 'FlatBand' | 'SlidingScale';

Synopsis

Determines how to interpret a rate table of several rows:

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, also known as a volume weighted average rate).


RateMethod is is an enumerated type implemented as the following four-letter codes:

'FBND' | 'VWAR'.

User guide

When the FlatBand method is used, the total value of the Counterparty's holdings is used to look up a single Rate, which is then applied to the entire value of the calculation (i.e., front-end load, back-end load, switch or periodic charge).

When the SlidingScale method is used, the total value of the Counterparty's holdings is used to look up a series of Rates, which are then applied to tranches of the transaction. In effect, a volume-weighted average periodic charge 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 RateTableRow in the RateTable.

A "flat rate" charge can be implemented by creating a table with a single row. It should be treated as a special form of FlatBand table.

Rule

RateTable = RateMethod, ReferenceCurrency, RateTableRow, {RateTableRow};

Synopsis

A RateTable is determined by:

RateMethod Whether the table describes a FlatBand or SlidingScale rate. ReferenceCurrency The currency into which the Counterparty's total holding values should be converted for the lookup. RateTableRow One or more rows containing transaction charge or periodic charge rates and the holding values for which they are valid.


RateMethod: Defined in this document. ReferenceCurrency: ISO 20022 CurrencyCode. RateTableRow: Defined in this document.

User guide

Not defined.


Rule

RateTableRow = Threshold, Rate;

Synopsis

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

Threshold The value of holdings from and above which a party is eligible to receive a charge at Rate. Rate The charge rate.


For each RateTableRow n (n >= 1):

Threshold n: ISO 20022 Number, > 0; > Threshold of RateTableRow n-1. Rate: ISO 20022 PercentageRate, >= 0.

User guide

Each Threshold represents the entry value of a band which has an implied limit. The Threshold of the first RateTableRow of the RateTable is the value set by the parties, which may be zero or higher. The Threshold of each subsequent RateTableRow n is Thresholdn-1 + 1. Example (only the shaded cells are included in the terms syntax):

Row Number Threshold Limit Rate

1 0 4,999,999 40

2 5,000,000 14,999,999 50

3 15,000,000 Not defined (infinite)

60

The parties must be careful to ensure that when a periodic charge is a 'VolumePeriodicCharge' the Rate is set with the precision of basis points and in all other cases it is set with the precision of a standard percentage rate (ISO 20022 PercentageRate supports both levels of precision).

If the parties wish to create an agreement in which the Counterparty must first accumulate a certain value of assets before periodic charges apply, they may define a multi-row RateTable in which the Threshold of the first RateTableRow is set to the holding value from which periodic charges will be earned. By definition, holdings below that Threshold will be out of scope of any charge. This technique may also be used to carve out a periodic charge from any general DeMinimisCharge threshold that the parties might have applied to their business (e.g., to set a higher charge-earning threshold for a capacity-constrained fund or a special line of business). A RateTable with a single RateTableRow where Rate = 0 is not permitted.

In cases where FeeSharePeriodicCharge → TotalExpenseRatioCap or OngoingChargeCap is being applied, the Rate in RateTable defines the TER or OGC cap. Thus, in a FlatBand table, if Rate = 60 and the fund's actual TER or OGC was measured to be 70, Company would pay Counterparty 10 bps of the applicable asset volume.

Rule

Report = ReportNumber, [ReportName], ReportMethod, {ReportMethod}, AgreementSectionCrossReference, {AgreementSectionCrossReference}, [SpecialInstructions];

Synopsis

The parties should agree some high-level principles by which the Company will report transaction charges and/or periodic charges to the Counterparty, including:

ReportNumber A unique identifier that allows easy reference to report mandates in an agreement. ReportName A short name given by the Company for ease of reference. ReportMethod Whether reports will be sent by post, e-mail, fax or a combination of them. AgreementSectionCrossReference A reference to a section of an agreement that defines the charges. SpecialInstructions Any special instruction that might aid the despatch, routing, reception and comprehension of the reports.


ReportNumber: ISO 20022 Max3NumberNonZero, > 0. ReportName: ISO 20022 Max70Text. ReportMethod: Defined in this document. AgreementSectionCrossReference: Defined in this document. SpecialInstructions: ISO 20022 Max2000Text.

The ReportNumber assigned to each Report section should be unique within the scope of the agreement. For good administration, these numbers should be assigned in a contiguous sequence starting with '1'.

The values assigned to AgreementSectionCrossReference must correspond to values that have been assigned to a TransactionChargeNumber or PeriodicChargeNumber (i.e., unallocated values should not be assigned to AgreementSectionCrossReference).

User guide

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


Rule

ReportMethod = PostalAddress | EmailAddress | FaxNumber | Other;

Synopsis

The Company might send reports by post, e-mail or fax, in which case an address or number must be provided for each. A free text field ("Other") is provided to enable the parties to define other report methods.


PostalAddress: ISO 20022 PostalAddress1. EmailAddress: ISO 20022 EmailAddress. FaxNumber: ISO 20022 PhoneNumber. Other: ISO 20022 Max350Text.

User guide

Not defined.

Rule

RetrospectiveAdjustmentDeadline = TimeLimitMonths | Other;

Synopsis

The parties should agree the deadline, starting from the date on which the Company despatches a statement of transaction charges or periodic charges, within which the Counterparty may request changes (for example, in respect of holdings that the Counterparty considers to be within or without the scope of the charges, but which are not described in the relevant transaction charge or periodic charge terms) which may cause the charges to be restated.


TimeLimitMonths: ISO 20022 Max3NumberZero, >= 0. Other: ISO 20022 Max2000Text, which allows the parties to describe some other limit on retrospective adjustment.

User guide

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

This rule makes clear to both parties the limit at which they will retrospectively admit charges on investments that were unknown to the Company when it initially calculated the charges for a particular period. A TimeLimitMonths value of zero (0) amounts to a policy not to permit retrospective adjustment.

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

This rule applies only to the calculation basis for transaction charges and periodic charges. It does not apply to payment errors, which are governed by normal commercial practice.

Rule

RunOff = PeriodMonths, AdmitNewPositions;

Synopsis

Determines the application of charges during a run-off period after the termination of the agreement:

PeriodMonths The duration of the run-off period in months, starting from the effective date of termination. AdmitNewPositions Determines whether positions added after the effective date of termination will attract charges during the run-off period.


PeriodMonths: ISO 20022 Max3NumberNonZero, > 0. AdmitNewPositions: ISO 20022 YesNoIndicator.

User guide

This rule is to be used only in the case of pooled funds where the Company pays periodic charges to the Counterparty.

If the AdmitNewPositions flag is set to 'Yes' or 'True' the Company will continue to pay periodic charges during the run-off period, including on new positions. The Company will pay no periodic charges after the run-off period.

If the AdmitNewPositions flag is set to 'No' or 'False' the Company will continue to pay periodic charges during the run-off period in respect of positions that were created before the agreement was terminated for as long as they remain but it will pay none in respect of new positions. The Company will pay periodic charges after the run-off period.


Rule

SettlementWithin = TimeLimitBusinessDays | TimeLimitCalendarDays | Other, [LatePaymentPenalty];

Synopsis

Defines when the parties will settle payments of transaction charges and/or periodic charges after they become due:

TimeLimitBusinessDays The number of business days after the due date within which the party will make settlement. TimeLimitCalendarDays The number of calendar days after the due date within which the party will make settlement. Other Whether settlement will be defined in some other way. LatePaymentPenalty Whether to apply late payment penalties and at what rate.


TimeLimitBusinessDays: ISO 20022 Max3NumberNonZero, > 0. TimeLimitCalendarDays: ISO 20022 Max3NumberNonZero, > 0. Other: ISO 20022 Max2000Text. LatePaymentPenalty: Defined in this document.

User guide

In this rule, a business day is every Monday through to Friday except public holidays in the relevant fund's domicile.

An example of an "Other" settlement instruction might be the "last business day of the month after the period".The due date is 30 calendar days after the last day of the period.

Rule

SharedAccountHoldingUpdateFrequency = 'Daily' | 'Weekly' | 'Monthly' | 'Quarterly' | 'HalfYearly' | 'Yearly';

Synopsis

Determine the frequency at which the Counterparty's interest in a shared account will be analysed:

Daily Upon each calendar day. Weekly On the last day of a calendar week (Sunday). Monthly On the last day of a calendar month (31 January, 28/29 February, 31 March, 30 April, etc). Quarterly On the last day of a calendar quarter (31 March, 30 June, 30 September, 31 December). HalfYearly On the last day of a calendar half-year (30 June, 31 December). Yearly On the last day of a calendar year (31 December).


SharedAccountHoldingUpdateFrequency is an enumerated type implemented as the following four-letter codes:


User guide

This rule defines how often the shared account should be analysed. In other words, it tells the charge calculation agent how often the bank which holds the shared account will send the charge calculation agent a file containing the holdings (and possibly the transactions) of the party to whom the charge is due. The rate at which holdings should be reported within the file is determined by the rule HoldingCount.

Rule

Term = FixedTermMonths | 'Open';

Synopsis

An agreement may be for a fixed term measured in months from the execution date or it may be for an open term, which is to be determined by one party giving the other notice of termination.


FixedTermMonths: ISO 20022 Max3NumberNonZero, >= 1. Open: Literal.

User guide

The syntax does not support the many variations of termination provision, including minimum length term, initial term of fixed length with automatic roll-over, asymmetric notice periods, etc. If the parties want more flexible terms they may provide for them by a LegalVariation to standatd LegalTerms or through proprietary LegalTerms.

When FixedTermMonths is defined under this rule, PeriodicCharges and TransactionCharges may still be defined with their TermEndDate set to Open or to a date that is later than the expiry of FixedTermMonths, in which case:

(1) For pooled fund agreements, PeriodicCharges will terminate in accordance with the rule TerminationMode and TransactionCharges will be deemed to terminate on the last day of the FixedTermMonths, and

(2) For segregated accounts PeriodicCharges and TransactionCharges will continue until the Company is no longer managing the Counterparty's assets.


Rule

TermAndTermination = Term, TerminationNotice;

Synopsis

Determine the term of the agreement and the termination notice period that one party must give to the other(s):

Term The term of the agreement. TerminationNotice A party that wishes to terminate the agreement must give a minimum period of notice.


Term: Defined in this document. TerminationNotice: Defined in this document.

User guide

Not defined.

Rule

TermEndDate = Date | 'Open';

Synopsis

Transaction charges and periodic charges and performance periods 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 TermStartDate and ExecutionDate. Open: Literal.

User guide

The date specified by this rule is included in the valid period of the relevant transaction charge or periodic charge section.

Rule

TerminationMode = TerminationType | RunOff;

Synopsis

Determines the treatment of charges in the event of the termination of the agreement:

TerminationType Determines whether charge terms will be coterminus with the agreement or survive termination. RunOff Defines a run-off period and determines what to do in respect of new positons taken during that period.


TerminationType Defined in this document. RunOff Defined in this document.

User guide

A termination mode is only defined for periodic charges. See also the user guide to the rule Term.

Rule

TerminationNotice = Days | Months;

Synopsis

Determines the notice in calendar days or months that one party must give to the other when terminating the agreement.


Days: ISO 20022 Max3NumberNonZero, > 0. Months: ISO 20022 Max3NumberNonZero, > 0.

User guide

The terminating party should make clear in its termination notice to the other party what the final day of the term of the agreement will be.


Rule

TerminationType = 'CoTerminusAgreement' | 'Survive';

Synopsis

Determines the type of a periodic charge TerminationMode:

CoTerminusAgreement Periodic charges will terminate on the day that the agreement terminates. Survive Periodic charges will survive the termination of the agreement, subject to the restrictions described below.


TerminationType is is an enumerated type implemented as the following four-letter codes:

'COTM' | 'SURV'.

User guide

In pooled fund agreements, if the 'Survive' option is selected, the Company will continue to pay periodic charges in respect of positions that were created before the agreement was terminated for as long as the positions remain but it will not pay periodic charges in respect of new positions.

See also the user guide to the rule Term.

Rule

TermStartDate = Date | 'FirstInvestment';

Synopsis

Transaction charges and periodic charges and performance periods 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 TermEndDate, and, in respect of periodic charges only, may be earlier than ExecutionDate, and may be in the past. FirstInvestment: Literal, which, in respect of periodic charges only, may also indicate a date in the past.

User guide

Some companies agree to apply periodic charges retrospectively, for example, when they have started to do business together with the expectation that an agreement will be contracted within a few weeks. In that case, the TermStartDate of some periodic charge terms may be earlier than the ExecutionDate of the agreement. This can be achieved explicitly, by using the Date option and setting a date in the past, or implicitly, by using the FirstInvestment flag if the Counterparty made its first investment before the sales agreement's ExecutionDate. If the Counterparty's investment history is long and the parties wish to retrospectively apply periodic charges only to a recent part of it then the explicit method should be used.

The date determined by the FirstInvestment flag may include a date in the past where it is operationally feasible to do so, such as when applying back-dated management fees, rebates, etc. It may not be feasible in some circumstances, such as where a transaction charge is deductible at the time of a transaction (e.g., front-end and back end loads applied by the Company on transactions presented by the Counterparty acting as intermediary for third parties).

The date specified by this rule is included in the valid period of the relevant transaction charge and periodic charge section.


Rule

TransactionCharge = TransactionChargeNumber, [TransactionChargeName], TransactionChargeType, TermStartDate, TermEndDate, Product, {Product}, {ProductExclusion}, TransactionChargeHolding, [TransactionChargeAggregation], TransactionChargePeriod, Discount, CounterpartyShare, CompanyShare;

Synopsis

Define how a transaction charge is to be calculated and whether it is paid on all products or only upon a named set of products:

TransactionChargeNumber A unique identifier that allows easy reference to transaction charge sets in an agreement. TransactionChargeName A short name given by the Company for ease of reference. TransactionChargeType The type of transaction charge (front-end load, back-end load, switch charges, securities sales and purchases). TermStartDate Date from which this transaction charge becomes valid (inclusive of the start date). TermEndDate Date after which this transaction charge ceases to be valid (inclusive of the end date). Product The products to which transaction charges are to be applied. ProductExclusion Any members of a set of products to which the transaction charges should not be applied TransactionChargeHolding The holding addresses to which transaction charges are to be applied. TransactionChargeAggregation The products and holding addresses which are to be taken into account when looking up the transaction charge rate in RateTable. TransactionChargePeriod The time period in which transaction charges are collected until a payment process is run. Discount The percentage rate of the transaction charge that is due to the investor who placed the deal. CounterpartyShare The percentage rate of the transaction charge that is due to the Counterparty. CompanyShare The percentage rate of the transaction charge that is due to the Company.


TransactionChargeNumber: ISO 20022 Max3NumberNonZero, > 0. TransactionChargeName: ISO 20022 Max70Text. TransactionChargeType Defined in this document. TermStartDate Defined in this document. TermEndDate Defined in this document. Product Defined in this document. ProductExclusion: Defined in this document. TransactionChargeHolding Defined in this document. TransactionChargeAggregation Defined in this document. TransactionChargePeriod Defined in this document. Discount: ISO 20022 PercentageBoundedRate, >= 0; <= 100. CounterpartyShare: ISO 20022 PercentageBoundedRate, >= 0; <= 100. CompanyShare: ISO 20022 PercentageBoundedRate, >= 0; <= 100.

The following additional constraints apply to the members of this rule:

(1) Discount + CounterpartyShare + CompanyShare == 100% <= maximum transaction charge permitted by the prospectus.

(2) TermStartDate may take the value of an explicit date or 'FirstInvestment' (see the definition of the rule TermStartDate) but there can be no retrospective application of transaction charges if TermStartDate is in the past.

The TransactionChargeNumber assigned to each TransactionCharge section should be unique within the scope of the agreement. For good administration, these numbers should be assigned in a contiguous sequence starting with '1'.

User guide

The terms Discount, CounterpartyShare and CompanyShare are intended to be used only in the context of pooled fund distribution agreements. For segregated account agreements, set Discount and CounterpartyShare to zero and Company share to 100.

This rule is intended to apply only to charges raised directly by the Company; it is not intended to be used to describe the treatment of broker commissions.

This rule can be used to define transaction charges in three formats:

(1) Constant transaction charge

The same rate is set for all deals that match the transaction charge section.

To construct a transaction charge in this format, omit the TransactionChargeAggregation term and ensure that the RateTable contains a single RateTableRow.

(2) Discrete variable transaction charge

The rate of the transaction charge reduces as individual deal size increases.

To construct a transaction charge in this format, omit the TransactionChargeAggregation term and ensure that the RateTable contains several RateTableRows.

(3) Cumulative variable transaction charge

The rate of the transaction charge reduces as individual deal size, aggregated with existing investments, increases.

To construct a transaction charge in this format, include the TransactionChargeAggregation term and ensure that the RateTable contains several RateTableRows.

Duplicate transaction charges may occur where the Product, TransactionChargeHolding and time dimensions of two or more TransactionCharges intersect. Normally this indicates an error and by default duplicates should be treated as such: charge calculation agents should normally investigate and correct them. If the parties wish to permit duplicate transaction charges (and in rare circumstances they do), they should record their agreement in their proprietary legal terms or a legal variation statement, which should include a description of how the duplicates should be processed (for example, whether the charge calculation agent should pay all duplicates or select only one for payment using agreed criteria).

(continued)


Rule

TransactionCharge (continued)

User guide (continued)

If an aggregation rule uses a special aggregation list (see the relevant definition of each rule), care should be taken to verify that there is a reasonable connection between the members of that list and the holding addresses and products to which the transaction charges are being applied.

Generally in such cases:

Product ProductAggregation and TransactionChargeHolding TransactionChargeHoldingAggregation

The amounts of transaction charge applied to pooled funds may be allocated between the investor, the Counterparty and the Company. If it is not zero and the transaction is a subscription or a switch, 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 transaction charge 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 transaction charge that is deducted and the net amount that is invested. The deduction will be the sum of Discount + CounterpartyShare + CompanyShare (up to the maximum transaction charge 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.

Provided that the parties agree, the Counterparty may override the terms of a transaction charge by giving a "forced rate" transaction, in which it indicates on the transaction order what rate of transaction charge should be applied and what (if any) the Discount, CounterpartyShare and CompanyShare should be.

Rule

TransactionChargeAggregation = ProductAggregation, TransactionChargeHoldingAggregation;

Synopsis

Determines the aggregation policy for a transaction charge based upon related products and holding addresses.


ProductAggregation Defined in this document. TransactionChargeHoldingAggregation Defined in this document.

User guide

Aggregation policy may be used to modify the rate of a transaction charge based upon a set of products and holding addresses greater than those to which transaction charges are to be applied under the terms of an individual transaction charge section. For example, a transaction charge applicable to equity funds sold by the retail division of a financial institution may use a rate based upon the aggregated holdings of all types of fund held by that institution's retail, institutional and wealth management divisions.

Rule

TransactionChargeHolding = (TransactionChargeHoldingAddress, {TransactionChargeHoldingAddress}) | 'DefinedLater';

Synopsis

Tranasction charges may be applied to holdings at one or more transaction charge holding addresses, which may be defined after the agreement is contracted.


TransactionChargeHoldingAddress Defined in this document. DefinedLater Literal.

User guide

There should be no duplicates in the tuple (HoldingAddressPath, HoldingAddressNumber) within TransactionChargeHoldingAddress.


Rule

TransactionChargeHoldingAddress = HoldingAddressPath, HoldingAddressNumber;

Synopsis

The Company may only apply transaction charges to holdings in a system under its control (i.e., not at Clearstream, Euroclear, FundSettle, global custodian accounts with shared beneficial owners, etc):

HoldingAddressPath The system address (e.g., "schroders.luxembourg.agentcode"). HoldingAddressNumber The address number.


HoldingAddressPath: ISO 20022 Max350Text. HoldingAddressNumber: ISO 20022 Max35Text.

User guide

For the purposes of this rule, the meaning of a system under the Company's control can include two or more different systems, including outsourced agents.

Rule

TransactionChargeHoldingAggregation = 'Account' | HoldingAddressPath | (TransactionChargeHoldingAddress, {TransactionChargeHoldingAddress}) | 'DefinedLater';

Synopsis

Aggregation is the calculation of transaction charges on individual securities at rates that reflect a larger business relationship. In each case, the holding value of the charge-earning security is aggregated with the related holdings of relevant products according to the following options:

Account Within the same holding account. HoldingAddressPath Within holding accounts that share the same HoldingAddressNumber as the charge-earning security (which is determined at deal-time by reference to the HoldingAddressPath) TransactionChargeHoldingAddress Within a special list of holding addresses. DefinedLater Within a special list of holding addresses that will be defined later.


Account: Literal. HoldingAddressPath: ISO 20022 Max350Text. TransactionChargeHoldingAddress: Defined in this document. DefinedLater: Literal.

User guide

Aggregation requires two dimensions: products and holding addresses. The rules TransactionChargeHoldingAggregation and ProductAggregation are therefore mutually inclusive: if one is used, the other must be used. The rule ProductAggregation determines which products are relevant to the aggregation process.

Aggregating holdings on the basis of HoldingAddressPath using an account-level address type is synonymous with aggregating on the basis of the Account flag. Generally, the the Account flag should be used if account-level aggregation is required. The HoldingAddressPath should be used if aggregation at a different level (e.g., agent code) is required within the context of a specific system.

The Account flag and HoldingAddressPath options cannot aggregate holdings from several related lines of business (e.g., several different agent codes). To do that, the parties to the agreement must provide a special list of holding addresses (TransactionChargeHoldingAddress, in the rule above) that they wish to aggregate. The parties can use such a list to construct sophisticated aggregation policies, for example, by aggregating retail holdings with private banking and institutional holdings within the context of a global distribution agreement.

Transaction charge holding aggregation can only be applied within the limits of each transfer agent's operations. It is normally not possible to aggregate holdings at two or more different transfer agents because they do not exchange the necessary data.

Holding aggregation for transaction charges is calculated using positions and NAVs per share as at the close of business on the day upon which the deal was executed.


Rule

TransactionChargePeriod = 'Weekly' | 'SemiMonthly' | 'Monthly' | 'Quarterly' | 'HalfYearly' | 'Yearly';

Synopsis

Determines the duration of a transaction charge period.


TransactionChargePeriod is is an enumerated type implemented as the following four-letter codes:

'WEEK' | 'TWMN' | 'MNTH' | 'QUTR' | 'SEMI' | 'YEAR'.

User guide

The start date of a transaction charge period is derived in the following way:

If the value is Weekly, each transaction charge period will start on a Monday (ISO 8601).

If the value is SemiMonthly, each transaction charge period will start on the first and the sixteenth calendar day of each calendar month.

If the value is Monthly, each transaction charge period will start on the first calendar day of each calendar month.

If the value is Quarterly, each transaction charge period will start on the first calendar day of January, April, July and October.

If the value is HalfYearly, each transaction charge period will start on 1 January and 1 July.

If the value is Yearly, each transaction charge period will start on 1 January.

If the TermStartDate or the TermEndDate does not coincide with the first or last day of a transaction charge period respectively, the Company must manually adjust the first or last period.

Rule

TransactionChargeSet = TransactionChargeSetNumber, [TransactionChargeSetName], TransactionCharge, {TransactionCharge}, PaymentCurrency, [SettlementWithin], [RetrospectiveAdjustmentDeadline], [DeMinimisPayment];

Synopsis

Define whether a transaction charge is payable and at what rate and under what conditions:

TransactionChargeSetNumber A unique identifier that allows easy reference to transaction charge mandates in an agreement. TransactionChargeSetName A short name given by the Company for ease of reference. TransactionCharge Instructions for applying transaction charges to specific products, holding addresses at specific rates, etc. PaymentCurrency Payment is to be made in the currencies of the relevant share classes or in a single currency. SettlementWithin Payments are to be made within an agreed number of days of the end of the period. RetrospectiveAdjustmentDeadline Adjustments to erroneous calculations may only be made within a certain deadline. DeMinimisPayment The amounts to be paid must exceed a certain threshold.


TransactionChargeSetNumber: ISO 20022 Max3NumberNonZero, > 0. TransactionChargeSetName: ISO 20022 Max70Text. TransactionCharge Defined in this document. PaymentCurrency Defined in this document. SettlementWithin Defined in this document. RetrospectiveAdjustmentDeadline Defined in this document. DeMinimisPayment Defined in this document.

The TransactionChargeSetNumber assigned to each TransactionChargeSet section should be unique within the scope of the agreement. For good administration, these numbers should be assigned in a contiguous sequence starting with '1'.

User guide

For pooled funds:

The Company may only apply a transaction charge to a deal if the deal matches the terms of a TransactionCharge section in the agreement. If the agreement contains no TransactionCharges or if the deal matches none of the TransactionCharges that have been defined then the Company will process the deal at the NAV per share on dealing day.

If the agreement contains TransactionCharges and the deal matches one of the TransactionCharge sections that have been defined then the Company will apply the charge to the deal at the rate defined in the TransactionCharge section and allocate it to one or more of (i) the investor who placed the deal, (ii) the Counterparty, and (iii) the Company. The allocation is described in more detail in the rule TransactionCharge.

Some of the terms that control how the Company remits transaction charges to the Counterparty are defined in this rule rather than in the rule TransactionCharge because the payment terms may be constant for several different TransactionCharges.

If SettlementWithin, RetrospectiveAdjustmentDeadline and DeMinimisPayment are not defined, then the settlement, adjustment and de minimis payment terms will be determined according to the Company's normal business practice.


Rule

TransactionChargeType = RateTransactionCharge | FixedCharge;

Synopsis

Determines the type of a transaction charge:

RateTransactionCharge The charge is calculated as a rate with respect to the asset volume of the transaction. FixedCharge The charge is a fixed amount per transaction.


RateTransactionCharge: Defined in this document. FixedCharge: Defined in this document.

User guide

There is no Payee term in this rule (unlike the rule PeriodicChargeType) because the parties to whom a transaction charge is paid is determined by the terms Discount, CounterpartyShare and CompanyShare in the rule TransactionCharge.

Rule

VolumePeriodicCharge = VolumePeriodicChargeCode | Proprietary, RateTable, {RateTable}, [LookupFrequency];

Synopsis

Determine:

VolumePeriodicChargeCode The type of volume periodic charge by reference to a standard code. Proprietary The type of volume periodic charge by reference to a proprietary code. RateTable The rate at which the periodic charge should be applied. LookupFrequency How often the rate should be looked up.


VolumePeriodicChargeCode: Defined in this document. Proprietary: ISO 20022 GenericIdentification30. RateTable: Defined in this document. LookupFrequency: Defined in this document.

User guide

A series of rate tables may be used to set graduated commercial terms. For example three tables may be used:

Table 1: set an initial volume weighted average rate across the first three tranches of asset volume; Table 2: set an improved volume weighted average rate across the next three traches of asset volume; Table 3: set a final flat rate for any higher asset volume.

PeriodicCharge → PeriodicChargePeriod <= LookupFrequency <= PeriodicCharge → 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.

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

Rule

VolumePeriodicChargeCode = 'TrailerFee' | 'IntermediaryServiceFee' | 'ItalianSubjectInChargePlacementFee' | 'FranceCentralisingAgentFee' | 'ManagementFee' | 'CustodyFee' | 'ReferralFee' | 'AdvisoryFee' | 'RealEstateFundFee' | 'LifeCompanyFee';

Synopsis

A volume periodic charge can be calculated for many purposes, including trailer fees to fund distributors, service fees to intermediaries such as fund platforms, Italian "subjects in charge of placement", French "centralising agents", introducing agents, etc. It may also be used to calculate management, custody and other fees.


VolumePeriodicChargeCode is an enumerated type implemented as the following four-letter codes:

'TRLF' | 'INSF' | 'ISIP' | 'FCAF' | 'MANF' | 'CUSF' | 'RFLF' | 'ADVF' | 'REFF' | 'LCOF'.

User guide

The volume based code is provided only to allow the operator of the agreement to understand a charge's purpose. It has no effect on the calculation of the charge.

Many codes may be defined to allow practitioners to determine the nature of a charge for tax purposes. For example, in some countries life company fees are subject to preferential tax rates.


Rule

YearDays = 'CalendarDays365' | 'CalendarDays366' | 'StandardYear360' | 'StandardYear365.25';

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. StandardYear360 Every year is considered to be 360 standard days. StandardYear365.25 Every year is considered to be 365.25 standard days (a Julian Year).


YearDays is an enumerated type with four members.

User guide

Typically, the members of this rule will correspond to the members of the rule PeriodDays in the following manner:

YearDays PeriodDays

CalendarDays365 CalendarDays365

CalendarDays366 CalendarDays366

StandardYear360 StandardYear360

StandardYear365.25 CalendarDays366


Part 7: HoldingValue function reference

The following abbreviations are used in this table:

DAIL Daily WEEK Weekly MNTH Monthly QUTR Quarterly SEMI HalfYearly YEAR Yearly WKEM WeekEndMean MNEM MonthEndMean QUEM QuarterEndMean SAEM HalfYearEndMean YREM YearEndMean

RHC ReferHoldingCount RCLF ReferCalculationLookupFrequency

HC HoldingCount CF CalculationFrequency LF LookupFrequency ANAV ApplicableNAV NAV Net asset value per share

Nr. HC CF / LF ANAV HoldingValue definition

1. DAIL DAIL RHC cc dd

NAVHoldingsueHoldingVal

Where dc = relevant calculation day

2. DAIL DAIL RCLF cc dd



3. DAIL DAIL DAIL cc dd



4. DAIL WEEK RHC

n

1idd ii NAVHoldings

n

1ueHoldingVal

Where:

n = number of days in the week

di = day i

5. DAIL WEEK RCLF Deprecated. See user guide.

n

1idd zi NAVHoldings

n

1ueHoldingVal

Where:


di = day i

dz = last day in the week

6. DAIL WEEK DAIL

n

1idd ii NAVHoldings

n

1ueHoldingVal

Where:


di = day i

7. DAIL MNTH RHC

n

1idd ii NAVHoldings

n

1ueHoldingVal

Where:

n = number of days in the month

di = day i



8. DAIL MNTH RCLF Deprecated. See user guide.

n

1idd zi NAVHoldings

n

1ueHoldingVal

Where:


di = day i

dz = last day in the month

9. DAIL MNTH DAIL

n

1idd ii NAVHoldings

n

1ueHoldingVal

Where:


di = day i

10. DAIL QUTR RHC

n

1idd ii NAVHoldings

n

1ueHoldingVal

Where:

n = number of days in the quarter

di = day i

11. DAIL QUTR RCLF Deprecated. See user guide.

n

1idd zi NAVHoldings

n

1ueHoldingVal

Where:


di = day i

dz = last day in the quarter

12. DAIL QUTR DAIL

n

1idd ii NAVHoldings

n

1ueHoldingVal

Where:


di = day i

13. DAIL SEMI RHC

n

1idd ii NAVHoldings

n

1ueHoldingVal

Where:

n = number of days in the half-year

di = day i

14. DAIL SEMI RCLF Deprecated. See user guide.

n

1idd zi NAVHoldings

n

1ueHoldingVal

Where:


di = day i

dz = last day in the half-year



15. DAIL SEMI DAIL

n

1idd ii NAVHoldings

n

1ueHoldingVal

Where:


di = day i

16. DAIL YEAR RHC

n

1idd ii NAVHoldings

n

1ueHoldingVal

Where:

n = number of days in the year

di = day i

17. DAIL YEAR RCLF Deprecated. See user guide.

n

1idd zi NAVHoldings

n

1ueHoldingVal

Where:


di = day i

dz = last day in the year

18. DAIL YEAR DAIL

n

1idd ii NAVHoldings

n

1ueHoldingVal

Where:


di = day i

19. WEEK DAIL RHC zz dd


Where dz = last day in the week

20. WEEK DAIL RCLF cz dd


Where:


dc = relevant calculation day

21. WEEK DAIL DAIL cz dd


Where:



22. WEEK WEEK RHC zz dd



23. WEEK WEEK RCLF zz dd



24. WEEK WEEK DAIL

n

1idd iz NAVHoldings

n

1ueHoldingVal

Where:



di = day i



25. WEEK MNTH RHC

n

1idd ii NAVHoldings

n

1ueHoldingVal

Where:

n = number of weeks in the month

di = last day of week i

26. WEEK MNTH RCLF Deprecated. See user guide.

n

1idd zi NAVHoldings

n

1ueHoldingVal

Where:




27. WEEK MNTH DAIL

a

1i

b

1jdd ji NAVHoldings

n

1ueHoldingVal

Where:


a = number of weeks in the month

b = number of days in week i


dj = day j in week i

28. WEEK QUTR RHC

n

1idd ii NAVHoldings

n

1ueHoldingVal

Where:

n = number of weeks in the quarter


29. WEEK QUTR RCLF Deprecated. See user guide.

n

1idd zi NAVHoldings

n

1ueHoldingVal

Where:




30. WEEK QUTR DAIL

a

1i

b

1jdd ji NAVHoldings

n

1ueHoldingVal

Where:


a = number of weeks in the quarter




31. WEEK SEMI RHC

n

1idd ii NAVHoldings

n

1ueHoldingVal

Where:

n = number of weeks in the half-year




32. WEEK SEMI RCLF Deprecated. See user guide.

n

1idd zi NAVHoldings

n

1ueHoldingVal

Where:




33. WEEK SEMI DAIL

a

1i

b

1jdd ji NAVHoldings

n

1ueHoldingVal

Where:


a = number of weeks in the half-year




34. WEEK YEAR RHC

n

1idd ii NAVHoldings

n

1ueHoldingVal

Where:

n = number of weeks in the year


35. WEEK YEAR RCLF Deprecated. See user guide.

n

1idd zi NAVHoldings

n

1ueHoldingVal

Where:




36. WEEK YEAR DAIL

a

1i

b

1jdd ji NAVHoldings

n

1ueHoldingVal

Where:


a = number of weeks in the year




37. MNTH DAIL RHC zz dd


Where dz = last day in the month

38. MNTH DAIL RCLF cz dd


Where:



39. MNTH DAIL DAIL cz dd


Where:





40. MNTH WEEK RHC zz dd



41. MNTH WEEK RCLF cz dd


Where:


dc = last day in the relevant week

42. MNTH WEEK DAIL

n

1idd iz NAVHoldings

n

1ueHoldingVal

Where:



di = day i

43. MNTH MNTH RHC zz dd



44. MNTH MNTH RCLF zz dd



45. MNTH MNTH DAIL

n

1idd iz NAVHoldings

n

1ueHoldingVal

Where:



di = day i

46. MNTH QUTR RHC

n

1idd ii NAVHoldings

n

1ueHoldingVal

Where:

n = number of months in the quarter

di = last day of month i

47. MNTH QUTR RCLF Deprecated. See user guide.

n

1idd zi NAVHoldings

n

1ueHoldingVal

Where:




48. MNTH QUTR DAIL

a

1i

b

1jdd ji NAVHoldings

n

1ueHoldingVal

Where:


a = number of months in the quarter

b = number of days in month i





49. MNTH SEMI RHC

n

1idd ii NAVHoldings

n

1ueHoldingVal

Where:

n = number of months in the half-year


50. MNTH SEMI RCLF Deprecated. See user guide.

n

1idd zi NAVHoldings

n

1ueHoldingVal

Where:




51. MNTH SEMI DAIL

a

1i

b

1jdd ji NAVHoldings

n

1ueHoldingVal

Where:


a = number of months in the half-year




52. MNTH YEAR RHC

n

1idd ii NAVHoldings

n

1ueHoldingVal

Where:

n = number of months in the year


53. MNTH YEAR RCLF Deprecated. See user guide.

n

1idd zi NAVHoldings

n

1ueHoldingVal

Where:




54. MNTH YEAR DAIL

a

1i

b

1jdd ji NAVHoldings

n

1ueHoldingVal

Where:


a = number of months in the year




55. QUTR DAIL RHC zz dd


Where dz = last day in the quarter



56. QUTR DAIL RCLF cz dd


Where:



57. QUTR DAIL DAIL cz dd


Where:



58. QUTR WEEK RHC zz dd



59. QUTR WEEK RCLF cz dd


Where:



60. QUTR WEEK DAIL

n

1idd iz NAVHoldings

n

1ueHoldingVal

Where:



di = day i

61. QUTR MNTH RHC zz dd



62. QUTR MNTH RCLF cz dd


Where:


dc = last day in the relevant month

63. QUTR MNTH DAIL

n

1idd iz NAVHoldings

n

1ueHoldingVal

Where:

n = number of days in the relevant month


di = day i

64. QUTR QUTR RHC zz dd



65. QUTR QUTR RCLF zz dd



66. QUTR QUTR D

n

1idd iz NAVHoldings

n

1ueHoldingVal

Where:



di = day i



67. QUTR SEMI RHC

n

1idd ii NAVHoldings

n

1ueHoldingVal

Where:

n = number of quarters in the half-year

di = last day of quarter i

68. QUTR SEMI RCLF Deprecated. See user guide.

n

1idd zi NAVHoldings

n

1ueHoldingVal

Where:




69. QUTR SEMI DAIL

a

1i

b

1jdd ji NAVHoldings

n

1ueHoldingVal

Where:


a = number of quarters in the half-year

b = number of days in quarter i


dj = day j in quarter i

70. QUTR YEAR RHC

n

1idd ii NAVHoldings

n

1ueHoldingVal

Where:

n = number of quarters in the year


71. QUTR YEAR RCLF Deprecated. See user guide.

n

1idd zi NAVHoldings

n

1ueHoldingVal

Where:




72. QUTR YEAR DAIL

a

1i

b

1jdd ji NAVHoldings

n

1ueHoldingVal

Where:


a = number of quarters in the year




73. SEMI DAIL RHC zz dd


Where dz = last day in the half-year



74. SEMI DAIL RCLF cz dd


Where:



75. SEMI DAIL DAIL cz dd


Where:



76. SEMI WEEK RHC zz dd



77. SEMI WEEK RCLF cz dd


Where:



78. SEMI WEEK DAIL

n

1idd iz NAVHoldings

n

1ueHoldingVal

Where:



di = day i

79. SEMI MNTH RHC zz dd



80. SEMI MNTH RCLF cz dd


Where:



81. SEMI MNTH DAIL

n

1idd iz NAVHoldings

n

1ueHoldingVal

Where:



di = day i

82. SEMI QUTR RHC zz dd



83. SEMI QUTR RCLF cz dd


Where:


dc = last day in the relevant quarter

84. SEMI QUTR DAIL

n

1idd iz NAVHoldings

n

1ueHoldingVal

Where:

n = number of days in the relevant quarter


di = day i



85. SEMI SEMI RHC zz dd



86. SEMI SEMI RCLF zz dd



87. SEMI SEMI DAIL

n

1idd iz NAVHoldings

n

1ueHoldingVal

Where:



di = day i

88. SEMI YEAR RHC

n

1idd ii NAVHoldings

n

1ueHoldingVal

Where:

n = number of half-years in the year

di = last day of half-year i

89. SEMI YEAR RCLF Deprecated. See user guide.

n

1idd zi NAVHoldings

n

1ueHoldingVal

Where:




90. SEMI YEAR DAIL

a

1i

b

1jdd ji NAVHoldings

n

1ueHoldingVal

Where:


a = number of half-years in the year

b = number of days in half-year i


dj = day j in half-year i

91. YEAR DAIL RHC zz dd


Where dz = last day in the year

92. YEAR DAIL RCLF cz dd


Where:



93. YEAR DAIL DAIL cz dd


Where:



94. YEAR WEEK RHC zz dd





95. YEAR WEEK RCLF cz dd


Where:



96. YEAR WEEK DAIL

n

1idd iz NAVHoldings

n

1ueHoldingVal

Where:



di = day i

97. YEAR MNTH RHC zz dd



98. YEAR MNTH RCLF cz dd


Where:



99. YEAR MNTH DAIL

n

1idd iz NAVHoldings

n

1ueHoldingVal

Where:



di = day i

100. YEAR QUTR RHC zz dd



101. YEAR QUTR RCLF cz dd


Where:



102. YEAR QUTR DAIL

n

1idd iz NAVHoldings

n

1ueHoldingVal

Where:



di = day i

103. YEAR SEMI RHC zz dd



104. YEAR SEMI RCLF cz dd


Where:


dc = last day in the relevant half-year



105. YEAR SEMI DAIL

n

1idd iz NAVHoldings

n

1ueHoldingVal

Where:

n = number of days in the relevant half-year


di = day i

106. YEAR YEAR RHC zz dd



107. YEAR YEAR RCLF zz dd



108. YEAR YEAR DAIL

n

1idd iz NAVHoldings

n

1ueHoldingVal

Where:



di = day i

109. WKEM DAIL RHC

2

NAVHoldingsNAVHoldingsueHoldingVal

1z1zzz dddd

Where:

dz = last day of current week

dz-1

= last day of prior week

110. WKEM DAIL RCLF

c

1zz

ddd NAV

2

HoldingsHoldingsueHoldingVal

Where:


dz-1


dc = relevant calculation day in current week

111. WKEM DAIL DAIL

c

1zz

ddd NAV

2


Where:


dz-1


dc = relevant calculation day in current week

112. WKEM WEEK RHC

2


1z1zzz dddd

Where:


dz-1


113. WKEM WEEK RCLF

z

1zz

ddd NAV

2


Where:


dz-1




114. WKEM WEEK DAIL

n

1id

ddi

1zzNAV

2

HoldingsHoldings

n

1ueHoldingVal

Where:



dz-1


di = day i

115. WKEM MNTH RHC

n

1i

dddd

2

NAVHoldingsNAVHoldings

n

1ueHoldingVal

1i1iii

Where:



di-1

= last day of the week prior to week i

116. WKEM MNTH RCLF Deprecated. See user guide.

z

1ii

d

n

1i

dd NAV2

HoldingsHoldings

n

1ueHoldingVal

Where:



di-1


dz = last day of the month

117. WKEM MNTH DAIL

a

1id

b

1j

ddj

1iiNAV

2

HoldingsHoldings

n

1ueHoldingVal

Where:


a = number of weeks in the month



di-1



118. WKEM QUTR RHC

n

1i

dddd

2


n

1ueHoldingVal

1i1iii

Where:



di-1


119. WKEM QUTR RCLF Deprecated. See user guide.

z

1ii

d

n

1i

dd NAV2

HoldingsHoldings

n

1ueHoldingVal

Where:



di-1


dz = last day of the quarter



120. WKEM QUTR DAIL

a

1id

b

1j

ddj

1iiNAV

2

HoldingsHoldings

n

1ueHoldingVal

Where:


a = number of weeks in the quarter



di-1



121. WKEM SEMI RHC

n

1i

dddd

2


n

1ueHoldingVal

1i1iii

Where:



di-1


122. WKEM SEMI RCLF Deprecated. See user guide.

z

1ii

d

n

1i

dd NAV2

HoldingsHoldings

n

1ueHoldingVal

Where:



di-1


dz = last day of the half-year

123. WKEM SEMI DAIL

a

1id

b

1j

ddj

1iiNAV

2

HoldingsHoldings

n

1ueHoldingVal

Where:


a = number of weeks in the half-year


dj = last day of week i

dj-1



124. WKEM YEAR RHC

n

1i

dddd

2


n

1ueHoldingVal

1i1iii

Where:



di-1


125. WKEM YEAR RCLF Deprecated. See user guide.

z

1ii

d

n

1i

dd NAV2

HoldingsHoldings

n

1ueHoldingVal

Where:



di-1


dz = last day of the year



126. WKEM YEAR DAIL

a

1id

b

1j

ddj

1iiNAV

2

HoldingsHoldings

n

1ueHoldingVal

Where:


a = number of weeks in the year


dj = last day of week i

dj-1



127. MNEM DAIL RHC

2


1z1zzz dddd

Where:

dz = last day of current month

dz-1

= last day of prior month

128. MNEM DAIL RCLF

c

1zz

ddd NAV

2


Where:


dz-1


dc = relevant calculation day in current month

129. MNEM DAIL DAIL

c

1zz

ddd NAV

2


Where:


dz-1


dc = relevant calculation day in current month

130. MNEM WEEK RHC

2


1z1zzz dddd

Where:


dz-1


131. MNEM WEEK RCLF

c

1zz

ddd NAV

2


Where:


dz-1



132. MNEM WEEK DAIL

n

1id

ddi

1zzNAV

2

HoldingsHoldings

n

1ueHoldingVal

Where:


dz = last day in the current month

dz-1

= last day of the prior month

di = day i in the relevant week

133. MNEM MNTH RHC

2


1z1zzz dddd

Where:


dz-1




134. MNEM MNTH RCLF

z

1zz

ddd NAV

2


Where:


dz-1


135. MNEM MNTH DAIL

n

1id

ddi

1zzNAV

2

HoldingsHoldings

n

1ueHoldingVal

Where:

n = number of days in the current month


dz-1


di = day i

136. MNEM QUTR RHC

n

1i

dddd

2


n

1ueHoldingVal

1i1iii

Where:



di-1

= last day of the month prior to month i

137. MNEM QUTR RCLF Deprecated. See user guide.

z

1ii

d

n

1i

dd NAV2

HoldingsHoldings

n

1ueHoldingVal

Where:



di-1


dz = last day of the quarter

138. MNEM QUTR DAIL

a

1id

b

1j

ddj

1iiNAV

2

HoldingsHoldings

n

1ueHoldingVal

Where:


a = number of months in the quarter



di-1



139. MNEM SEMI RHC

n

1i

dddd

2


n

1ueHoldingVal

1i1iii

Where:



di-1




140. MNEM SEMI RCLF Deprecated. See user guide.

z

1ii

d

n

1i

dd NAV2

HoldingsHoldings

n

1ueHoldingVal

Where:



di-1



141. MNEM SEMI DAIL

a

1id

b

1j

ddj

1iiNAV

2

HoldingsHoldings

n

1ueHoldingVal

Where:


a = number of months in the half-year



di-1



142. MNEM YEAR RHC

n

1i

dddd

2


n

1ueHoldingVal

1i1iii

Where:



di-1


143. MNEM YEAR RCLF Deprecated. See user guide.

z

1ii

d

n

1i

dd NAV2

HoldingsHoldings

n

1ueHoldingVal

Where:



di-1



144. MNEM YEAR DAIL

a

1id

b

1j

ddj

1iiNAV

2

HoldingsHoldings

n

1ueHoldingVal

Where:


a = number of months in the year


dj = last day of month i

dj-1



145. QUEM DAIL RHC

2


1z1zzz dddd

Where:

dz = last day of current quarter

dz-1

= last day of prior quarter



146. QUEM DAIL RCLF

c

1zz

ddd NAV

2


Where:


dz-1


dc = relevant calculation day in current quarter

147. QUEM DAIL DAIL

c

1zz

ddd NAV

2


Where:


dz-1


dc = relevant calculation day in current quarter

148. QUEM WEEK RHC

2


1z1zzz dddd

Where:


dz-1


149. QUEM WEEK RCLF

c

1zz

ddd NAV

2


Where:


dz-1



150. QUEM WEEK DAIL

n

1id

ddi

1zzNAV

2

HoldingsHoldings

n

1ueHoldingVal

Where:


dz = last day in the current quarter

dz-1

= last day of the prior quarter


151. QUEM MNTH RHC

2


1z1zzz dddd

Where:


dz-1


152. QUEM MNTH RCLF

c

1zz

ddd NAV

2


Where:


dz-1



153. QUEM MNTH DAIL

n

1id

ddi

1zzNAV

2

HoldingsHoldings

n

1ueHoldingVal

Where:


dz = last day in the current quarter

dz-1

= last day of the prior quarter

di = day i in the relevant month



154. QUEM QUTR RHC

2


1z1zzz dddd

Where:


dz-1


155. QUEM QUTR RCLF

z

1zz

ddd NAV

2


Where:


dz-1


156. QUEM QUTR DAIL

n

1id

ddi

1zzNAV

2

HoldingsHoldings

n

1ueHoldingVal

Where:

n = number of days in the current quarter


dz-1


di = day i

157. QUEM SEMI RHC

n

1i

dddd

2


n

1ueHoldingVal

1i1iii

Where:



di-1

= last day of the quarter prior to quarter i

158. QUEM SEMI RCLF Deprecated. See user guide.

z

1ii

d

n

1i

dd NAV2

HoldingsHoldings

n

1ueHoldingVal

Where:



di-1



159. QUEM SEMI DAIL

a

1id

b

1j

ddj

1iiNAV

2

HoldingsHoldings

n

1ueHoldingVal

Where:


a = number of quarters in the half-year



di-1



160. QUEM YEAR RHC

n

1i

dddd

2


n

1ueHoldingVal

1i1iii

Where:



di-1




161. QUEM YEAR RCLF Deprecated. See user guide.

z

1ii

d

n

1i

dd NAV2

HoldingsHoldings

n

1ueHoldingVal

Where:



di-1



162. QUEM YEAR DAIL

a

1id

b

1j

ddj

1iiNAV

2

HoldingsHoldings

n

1ueHoldingVal

Where:


a = number of quarters in the year



di-1



163. SAEM DAIL RHC

2


1z1zzz dddd

Where:

dz = last day of current half-year

dz-1

= last day of prior half-year

164. SAEM DAIL RCLF

c

1zz

ddd NAV

2


Where:


dz-1


dc = relevant calculation day in current half-year

165. SAEM DAIL DAIL

c

1zz

ddd NAV

2


Where:


dz-1


dc = relevant calculation day in current half-year

166. SAEM WEEK RHC

2


1z1zzz dddd

Where:


dz-1


167. SAEM WEEK RCLF

c

1zz

ddd NAV

2


Where:


dz-1





168. SAEM WEEK DAIL

n

1id

ddi

1zzNAV

2

HoldingsHoldings

n

1ueHoldingVal

Where:


dz = last day in the current half-year

dz-1

= last day of the prior half-year


169. SAEM MNTH RHC

2


1z1zzz dddd

Where:


dz-1


170. SAEM MNTH RCLF

c

1zz

ddd NAV

2


Where:


dz-1



171. SAEM MNTH DAIL

n

1id

ddi

1zzNAV

2

HoldingsHoldings

n

1ueHoldingVal

Where:



dz-1


di = day i

172. SAEM QUTR RHC

2


1z1zzz dddd

Where:


dz-1


173. SAEM QUTR RCLF

c

1zz

ddd NAV

2


Where:


dz-1



174. SAEM QUTR DAIL

n

1id

ddi

1zzNAV

2

HoldingsHoldings

n

1ueHoldingVal

Where:


dz = last day in the current half-year

dz-1

= last day of the prior half-year

di = day i

175. SAEM SEMI RHC

2


1z1zzz dddd

Where:


dz-1




176. SAEM SEMI RCLF

z

1zz

ddd NAV

2


Where:


dz-1


177. SAEM SEMI DAIL

n

1id

ddi

1zzNAV

2

HoldingsHoldings

n

1ueHoldingVal

Where:

n = number of days in the current half-year


dz-1


di = day i

178. SAEM YEAR RHC

n

1i

dddd

2


n

1ueHoldingVal

1i1iii

Where:



di-1

= last day of the half-year prior to half-year i

179. SAEM YEAR RCLF Deprecated. See user guide.

z

1ii

d

n

1i

dd NAV2

HoldingsHoldings

n

1ueHoldingVal

Where:



di-1



180. SAEM YEAR DAIL

a

1id

b

1j

ddj

1iiNAV

2

HoldingsHoldings

n

1ueHoldingVal

Where:


a = number of half-years in the year

b = number of days in half-year i


di-1


dj = day j in half-year i

181. YREM DAIL RHC

2


1z1zzz dddd

Where:

dz = last day of current year

dz-1

= last day of prior year

182. YREM DAIL RCLF

c

1zz

ddd NAV

2


Where:


dz-1


dc = relevant calculation day in current year



183. YREM DAIL DAIL

c

1zz

ddd NAV

2


Where:


dz-1


dc = relevant calculation day in current year

184. YREM WEEK RHC

2


1z1zzz dddd

Where:


dz-1


185. YREM WEEK RCLF

c

1zz

ddd NAV

2


Where:


dz-1



186. YREM WEEK DAIL

n

1id

ddi

1zzNAV

2

HoldingsHoldings

n

1ueHoldingVal

Where:


dz = last day in the current year

dz-1

= last day of the prior year


187. YREM MNTH RHC

2


1z1zzz dddd

Where:


dz-1


188. YREM MNTH RCLF

c

1zz

ddd NAV

2


Where:


dz-1



189. YREM MNTH DAIL

n

1id

ddi

1zzNAV

2

HoldingsHoldings

n

1ueHoldingVal

Where:



dz-1


di = day i

190. YREM QUTR RHC

2


1z1zzz dddd

Where:


dz-1




191. YREM QUTR RCLF

c

1zz

ddd NAV

2


Where:


dz-1



192. YREM QUTR DAIL

n

1id

ddi

1zzNAV

2

HoldingsHoldings

n

1ueHoldingVal

Where:



dz-1


di = day i

193. YREM SEMI RHC

2


1z1zzz dddd

Where:


dz-1


194. YREM SEMI RCLF

c

1zz

ddd NAV

2


Where:


dz-1


dc = last day in the relevant half-year

195. YREM SEMI D

n

1id

ddi

1zzNAV

2

HoldingsHoldings

n

1ueHoldingVal

Where:

n = number of days in the relevant half-year


dz-1


di = day i

196. YREM YEAR RHC

2


1z1zzz dddd

Where:


dz-1


197. YREM YEAR RCLF

z

1zz

ddd NAV

2


Where:


dz-1


198. YREM YEAR DAIL

n

1id

ddi

1zzNAV

2

HoldingsHoldings

n

1ueHoldingVal

Where:

n = number of days in the current year


dz-1


di = day i

openterms syntax issue 02

Economy & Finance