Downloaded 12 times
![OpenTerms syntax and semantic definitions, issue 02, 12 July 2016 Page 3
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.](https://image.slidesharecdn.com/opentermssyntaxissue02-160713172037/85/OpenTerms-Syntax-Issue-02-3-320.jpg)
![OpenTerms syntax and semantic definitions, issue 02, 12 July 2016 Page 12
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](https://image.slidesharecdn.com/opentermssyntaxissue02-160713172037/85/OpenTerms-Syntax-Issue-02-12-320.jpg)
![OpenTerms syntax and semantic definitions, issue 02, 12 July 2016 Page 13
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](https://image.slidesharecdn.com/opentermssyntaxissue02-160713172037/85/OpenTerms-Syntax-Issue-02-13-320.jpg)
![OpenTerms syntax and semantic definitions, issue 02, 12 July 2016 Page 14
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](https://image.slidesharecdn.com/opentermssyntaxissue02-160713172037/85/OpenTerms-Syntax-Issue-02-14-320.jpg)
![OpenTerms syntax and semantic definitions, issue 02, 12 July 2016 Page 16
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
CalculationFrequency
Daily 7
Actual number of
calendar days in the
month
Actual number of
calendar days in the
quarter
Actual number of
calendar days in the
half-year
Actual number of
calendar days in the
year
Weekly 1
Actual number of
calendar weeks in the
month
Actual number of
calendar weeks in the
quarter
Actual number of
calendar weeks in the
half-year
Actual number of
calendar weeks in the
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:](https://image.slidesharecdn.com/opentermssyntaxissue02-160713172037/85/OpenTerms-Syntax-Issue-02-16-320.jpg)
![OpenTerms syntax and semantic definitions, issue 02, 12 July 2016 Page 22
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.](https://image.slidesharecdn.com/opentermssyntaxissue02-160713172037/85/OpenTerms-Syntax-Issue-02-22-320.jpg)
![OpenTerms syntax and semantic definitions, issue 02, 12 July 2016 Page 23
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.
Typology and constraints
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.
Typology and constraints
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.
Typology and constraints
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.](https://image.slidesharecdn.com/opentermssyntaxissue02-160713172037/85/OpenTerms-Syntax-Issue-02-23-320.jpg)
![OpenTerms syntax and semantic definitions, issue 02, 12 July 2016 Page 25
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.
Typology and constraints
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.
Typology and constraints
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.
Typology and constraints
CashFlowType is an enumerated type implemented as the following four-letter codes:
'STRT' | 'BKWD'.
User guide
See Part 5 of this document.](https://image.slidesharecdn.com/opentermssyntaxissue02-160713172037/85/OpenTerms-Syntax-Issue-02-25-320.jpg)
![OpenTerms syntax and semantic definitions, issue 02, 12 July 2016 Page 26
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.
Typology and constraints
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.
Typology and constraints
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.
Typology and constraints
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.](https://image.slidesharecdn.com/opentermssyntaxissue02-160713172037/85/OpenTerms-Syntax-Issue-02-26-320.jpg)
![OpenTerms syntax and semantic definitions, issue 02, 12 July 2016 Page 28
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.
Typology and constraints
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.
Typology and constraints
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.
Typology and constraints
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.](https://image.slidesharecdn.com/opentermssyntaxissue02-160713172037/85/OpenTerms-Syntax-Issue-02-28-320.jpg)
![OpenTerms syntax and semantic definitions, issue 02, 12 July 2016 Page 29
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.
Typology and constraints
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.
Typology and constraints
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.](https://image.slidesharecdn.com/opentermssyntaxissue02-160713172037/85/OpenTerms-Syntax-Issue-02-29-320.jpg)
![OpenTerms syntax and semantic definitions, issue 02, 12 July 2016 Page 31
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.
Typology and constraints
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.
Typology and constraints
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.](https://image.slidesharecdn.com/opentermssyntaxissue02-160713172037/85/OpenTerms-Syntax-Issue-02-31-320.jpg)
![OpenTerms syntax and semantic definitions, issue 02, 12 July 2016 Page 32
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.
Typology and constraints
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.
Typology and constraints
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.
Typology and constraints
FixedChargeType: Defined in this document.
Amount: ISO 20222 Number, > 0.
Currency: ISO 20022 CurrencyCode.
User guide
Not defined.](https://image.slidesharecdn.com/opentermssyntaxissue02-160713172037/85/OpenTerms-Syntax-Issue-02-32-320.jpg)
![OpenTerms syntax and semantic definitions, issue 02, 12 July 2016 Page 33
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.
Typology and constraints
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.
Typology and constraints
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.
Typology and constraints
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.](https://image.slidesharecdn.com/opentermssyntaxissue02-160713172037/85/OpenTerms-Syntax-Issue-02-33-320.jpg)
![OpenTerms syntax and semantic definitions, issue 02, 12 July 2016 Page 36
Rule
ISINAndDescription = ISIN, [Description];
Synopsis
An international securities identification number and a descriptor (typically the full name of the share class).
Typology and constraints
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.
Typology and constraints
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.
Typology and constraints
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.](https://image.slidesharecdn.com/opentermssyntaxissue02-160713172037/85/OpenTerms-Syntax-Issue-02-36-320.jpg)
![OpenTerms syntax and semantic definitions, issue 02, 12 July 2016 Page 37
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.
Typology and constraints
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).
Typology and constraints
LookupFrequency is an enumerated type implemented as the following four-letter codes:
'DAIL' | 'WEEK' | 'MNTH' | 'QUTR' | 'SEMI' | 'YEAR'.
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.](https://image.slidesharecdn.com/opentermssyntaxissue02-160713172037/85/OpenTerms-Syntax-Issue-02-37-320.jpg)
![OpenTerms syntax and semantic definitions, issue 02, 12 July 2016 Page 40
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.
Typology and constraints
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.
Typology and constraints
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.
Typology and constraints
AnyBIC ISO 20022 AnyBICIdentifier.
LEIIdentifier ISO 20022 LEIIdentifier.
ProprietaryID ISO 20022 GenericIdentification1.
NameAndAddress ISO 20022 NameAndAddress5.
User guide
Not defined.](https://image.slidesharecdn.com/opentermssyntaxissue02-160713172037/85/OpenTerms-Syntax-Issue-02-40-320.jpg)
![OpenTerms syntax and semantic definitions, issue 02, 12 July 2016 Page 41
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).
Typology and constraints
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.
Typology and constraints
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.
Typology and constraints
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).](https://image.slidesharecdn.com/opentermssyntaxissue02-160713172037/85/OpenTerms-Syntax-Issue-02-41-320.jpg)
![OpenTerms syntax and semantic definitions, issue 02, 12 July 2016 Page 42
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.
Typology and constraints
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.
Typology and constraints
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.](https://image.slidesharecdn.com/opentermssyntaxissue02-160713172037/85/OpenTerms-Syntax-Issue-02-42-320.jpg)
![OpenTerms syntax and semantic definitions, issue 02, 12 July 2016 Page 43
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.
Typology and constraints
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.
Typology and constraints
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.
Typology and constraints
HoldingAddressPath: ISO 20022 Max350Text.
HoldingAddressNumber: ISO 20022 Max35Text.
PayThruFundPayment: Defined in this document.
User guide
Not defined.](https://image.slidesharecdn.com/opentermssyntaxissue02-160713172037/85/OpenTerms-Syntax-Issue-02-43-320.jpg)
![OpenTerms syntax and semantic definitions, issue 02, 12 July 2016 Page 44
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.
Typology and constraints
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.
Typology and constraints
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.
Typology and constraints
ProRata: Literal.
PayThruFundSingleAccount: Defined in this document.
PayThruFundSet: Defined in this document.
User guide
Not defined.](https://image.slidesharecdn.com/opentermssyntaxissue02-160713172037/85/OpenTerms-Syntax-Issue-02-44-320.jpg)
![OpenTerms syntax and semantic definitions, issue 02, 12 July 2016 Page 46
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.
Typology and constraints
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.
Typology and constraints
PerformancePeriodStartConventionCode: Defined in this document.
Proprietary: ISO 20022 GenericIdentification30.
User guide
Not defined.](https://image.slidesharecdn.com/opentermssyntaxissue02-160713172037/85/OpenTerms-Syntax-Issue-02-46-320.jpg)
![OpenTerms syntax and semantic definitions, issue 02, 12 July 2016 Page 47
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.
Typology and constraints
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.
Typology and constraints
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.
Typology and constraints
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.](https://image.slidesharecdn.com/opentermssyntaxissue02-160713172037/85/OpenTerms-Syntax-Issue-02-47-320.jpg)
![OpenTerms syntax and semantic definitions, issue 02, 12 July 2016 Page 49
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.
Typology and constraints
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.](https://image.slidesharecdn.com/opentermssyntaxissue02-160713172037/85/OpenTerms-Syntax-Issue-02-49-320.jpg)
![OpenTerms syntax and semantic definitions, issue 02, 12 July 2016 Page 52
Rule
PeriodicChargePeriod = 'Weekly' | 'Monthly' | 'Quarterly' | 'HalfYearly' | 'Yearly';
Synopsis
Determines the duration of a periodic charge period.
Typology and constraints
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.
Typology and constraints
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.](https://image.slidesharecdn.com/opentermssyntaxissue02-160713172037/85/OpenTerms-Syntax-Issue-02-52-320.jpg)
![OpenTerms syntax and semantic definitions, issue 02, 12 July 2016 Page 57
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.
Typology and constraints
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.
Typology and constraints
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.](https://image.slidesharecdn.com/opentermssyntaxissue02-160713172037/85/OpenTerms-Syntax-Issue-02-57-320.jpg)
![OpenTerms syntax and semantic definitions, issue 02, 12 July 2016 Page 59
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.
Typology and constraints
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).
Typology and constraints
SharedAccountHoldingUpdateFrequency is an enumerated type implemented as the following four-letter codes:
'DAIL' | 'WEEK' | 'MNTH' | 'QUTR' | 'SEMI' | 'YEAR'.
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.
Typology and constraints
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.](https://image.slidesharecdn.com/opentermssyntaxissue02-160713172037/85/OpenTerms-Syntax-Issue-02-59-320.jpg)
![OpenTerms syntax and semantic definitions, issue 02, 12 July 2016 Page 62
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.
Typology and constraints
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)](https://image.slidesharecdn.com/opentermssyntaxissue02-160713172037/85/OpenTerms-Syntax-Issue-02-62-320.jpg)
![OpenTerms syntax and semantic definitions, issue 02, 12 July 2016 Page 65
Rule
TransactionChargePeriod = 'Weekly' | 'SemiMonthly' | 'Monthly' | 'Quarterly' | 'HalfYearly' | 'Yearly';
Synopsis
Determines the duration of a transaction charge period.
Typology and constraints
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.
Typology and constraints
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.](https://image.slidesharecdn.com/opentermssyntaxissue02-160713172037/85/OpenTerms-Syntax-Issue-02-65-320.jpg)
![OpenTerms syntax and semantic definitions, issue 02, 12 July 2016 Page 66
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.
Typology and constraints
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.
Typology and constraints
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.
Typology and constraints
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.](https://image.slidesharecdn.com/opentermssyntaxissue02-160713172037/85/OpenTerms-Syntax-Issue-02-66-320.jpg)
![Member Services Update, by Vivek Nigam [APNIC 38]](https://cdn.slidesharecdn.com/ss_thumbnails/memberservicesupdate1410934926-140917181312-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
OpenTerms Syntax Issue 02
- 1. OpenTerms project Operational workstream 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.
- 2. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 2 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
- 3. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 3 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.
- 4. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 4 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.
- 5. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 5 Terms Company PartyIdentification Counterparty PartyIdentification OfferRights PublicOffer PrivatePlacement PublicOfferAndPrivatePlacement DelegationPermitted OfferRightsNarrative OpenTerms Clear 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 CompanyCapacity 0..1 1..N Affiliate 0..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 ISINAndDescription 0..N Country Proprietary 0..N AgreementID VersionNumber OtherID ApplicableLawAndJurisdiction TermAndTermination Term TerminationNotice Days Months CounterpartyCapacity ContactDetails ContactDetails 1..N 1..N CompanyCapacityCode Proprietary LegalRepresentative ManagementCompany GlobalDistributor OfferRightsAndDelegation Proprietary OfferRightsCode NoneCounterpartyCapacityCode Proprietary Platform Distributor IntroducingAgent ProductPackager InstitutionalInvestor LegalTerms LegalVariation 0..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 MostFavouredTerms 0..1 ProductExclusion 0..N MarketExclusion ▼ ▼ PartyIdentification AccessionDate SecessionDate ContactDetails 1..N 0..N ▼ ▼ 0..1 0..1 1..N 1..N 0..N
- 6. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 6 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 LatePaymentPenalty 0..1 TransactionChargeType RateTransactionChargeCode Proprietary FrontEndLoad BackEndLoad Switch ▼ ISIN Description 0..1 ▼ HoldingAddressPath HoldingAddressNumber Account HoldingAddressPath TransactionChargeHoldingAddress DefinedLater HoldingAddressPath HoldingAddressNumber 1..N ShareClass SubFund Fund ProductAggregationType Product ISINAndDescription OtherID 1..N URL ▼ RateTransactionCharge TermStartDate Date FirstInvestment TermEndDate Date Open Product ISINAndDescription 1..N TransactionChargeHoldingAggregation TransactionChargePeriod Weekly Monthly Quarterly HalfYearly Yearly Discount CounterpartyShare CompanyShare OtherID SemiMonthly TransactionChargeNumber TransactionChargeHolding TransactionChargeHoldingAddress DefinedLater 1..N ProductAggregationTransactionChargeAggregation 0..1 URL RateTable FlatBand SlidingScaleReferenceCurrency RateTableRow 1..N Threshold Rate RateMethod Movement FixedCharge FixedChargeType Amount Currency FixedChargeDescription FixedChargeCode Proprietary BenchmarkChange MinimumPeriodicCharge* * Not for transaction charges OpenTerms Clear terms of business for the asset management industry Synoptic chart number: 2 Draft number: 17 Date: 12 July 2016 Origin: TransactionChargeSet (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 PenaltyRate BaseRate ▼ ProductExclusion 0..N ISIN Description a 0..1 a ProductExclusion 0..N ▼ ▼ TransactionChargeSetName 0..1 TransactionChargeName 0..1
- 7. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 7 PeriodicChargeSet PeriodicChargeSetNumber PeriodicCharge 1..N TerminationMode See chart 4 below TerminationType RunOff PeriodMonths AdmitNewPositions CompanyAutoPay CounterpartyInvoice OpenTerms Clear terms of business for the asset management industry Synoptic chart number: 3 Draft number: 17 Date: 12 July 2016 Origin: PeriodicChargeSet (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 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 NestedCharges 0..1 MandateCurrency InvestmentCurrency PeriodicChargeSetName 0..1
- 8. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 8 PeriodicCharge PeriodicChargeNumber TermStartDate Date FirstInvestment TermEndDate Date Open 1..N OpenTerms Clear terms of business for the asset management industry Synoptic chart number: 4 Draft number: 17 Date: 12 July 2016 Origin: PeriodicCharge (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 Product ISINAndDescription 1..N OtherID PeriodicChargeHolding PeriodicChargeHoldingDetails DefinedLater HoldingAddress HoldingValue ISIN Description 0..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..N HoldingAddress HoldingValue ShareClass SubFund Fund ProductAggregation ProductAggregationType Product ISINAndDescription OtherID 1..N ISIN Description PeriodicChargeAggregation 0..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 ProductExclusion 0..N ▼ ProductExclusion 0..N ▼ PeriodicChargeName 0..1
- 9. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 9 OpenTerms Clear terms of business for the asset management industry Synoptic chart number: 5 Draft number: 17 Date: 12 July 2016 Origin: PeriodicChargeType (several) (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 FeeSharePeriodicCharge FeeSharePeriodicChargeCode LookupFrequency PerformancePeriodicCharge Proprietary RateTable 0..1 FlatBand SlidingScaleReferenceCurrency RateTableRow 1..N Threshold Rate RateMethod ManagementFee DistributionFee Management+DistributionFee TotalExpenseRatio VolumePeriodicCharge VolumePeriodicChargeCode LookupFrequency Proprietary RateTable 0..1 FlatBand SlidingScaleReferenceCurrency RateTableRow 1..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
- 10. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 10 HoldingAddressType HoldingAddressPath ClearstreamBankLuxembourg Euroclear FundSettle HoldingAddressNumber SharedAccount SharedAccountHoldingUpdateFrequency 0..1 HoldingCount Daily Monthly Quarterly HalfYearly Yearly MonthEndMean QuarterEndMean HalfYearEndMean YearEndMean Monthly Quarterly HalfYearly Yearly ApplicableNAV ReferHoldingCount ReferCalculationLookupFrequency Daily EligiblePosition IncrementalTrade DecrementalTrade Weekly WeekEndMean SpecialInstructions 0..1 0..1 TradeDate SettlementDate TradeDate SettlementDate OpenTerms Clear terms of business for the asset management industry Synoptic chart number: 6 Draft number: 17 Date: 12 July 2016 Origin: HoldingAddress, HoldingValue, CashFlow (Open Terms 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 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
- 11. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 11 OpenTerms Clear terms of business for the asset management industry Synoptic chart number: 7 Draft number: 17 Date: 12 July 2016 Origin: Payment, Report (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 Payment PaymentNumber ProRataPaymentInstrument PayThruFund CreditTransferDetails ChequeDetails PayThruFundType Reference AgreementSectionCrossReference 0..1 1..N PayThruFundSingleAccount PayThruFundSet 1..N HoldingAddressPath HoldingAddressNumber PayThruFundPayment 1..N ISINAndDescription Ratio TransactionChargeNumber PeriodicChargeNumberReference 0..1 Currency IntermediaryAgent1 IntermediaryAgent1Account IntermediaryAgent2 IntermediaryAgent2Account CreditorAgent CreditorAgentAccount Creditor CreditorAccount AgreementSectionCrossReference 1..N TransactionChargeNumber PeriodicChargeNumber 0..1 0..1 0..1 0..1 0..1 0..1 0..1 Reference Currency PayeeID AgreementSectionCrossReference 1..N TransactionChargeNumber PeriodicChargeNumber 0..1 Report ReportNumber ReportMethod PostalAddress EmailAddress FaxNumber Other 1..N AgreementSectionCrossReference 1..N TransactionChargeNumber PeriodicChargeNumber HoldingAddressPath HoldingAddressNumber ISIN Description a a 0..1 SpecialInstructions 0..1 ▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼ DirectDebitDetails Reference 0..1 Currency Debtor ▼ DebtorAccount ▼ AgreementSectionCrossReference 1..N 0..1 TransactionChargeNumber PeriodicChargeNumber 0..1 SpecialInstructions 0..1 PaymentName 0..1 ReportName 0..1
- 12. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 12 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
- 13. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 13 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
- 14. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 14 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
- 15. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 15 Important: the syntax does not fully define every term in the above table through a separate rule as you would expect if it was complied strictly in accordance with ISO/IEC 14977. These "missing terms" are defined as ISO 20022 types or otherwise derived from another rule within Part 6 of this document. Notes for converting the syntax into an XML schema Certain enumerated types are implemented in ISO 20022 through the following code lists: 1 ApplicableNAV1Code = 'RECF' | 'DAIL' | 'REHC'; 2 PeriodicChargeCalculationFrequency1Code = 'DAIL' | 'WEEK' | 'MNTH' | 'QUTR' | 'SEMI' | 'YEAR'; 3 CashFlowTypeCode = 'STRT' | 'BKWD'; 4 CapacityOrganisationRole1Code = 'LREP' | 'MGCY' | 'GLDR' | 'PLFM'; 5 CompareMethodCode = 'ARIT' | 'GEOM'; 6 CapacityOrganisationRole2Code = 'PLFM' | 'DIST' | 'INAG' | 'PKGR' | 'INIV' | 'PLMA' | 'CENA'; 7 PositionDate1Code = 'TRAD' | 'SETT'; 8 FeeSharePeriodicChargeCode = 'MANF' | 'DISF' | 'MADF' | 'TERF' | 'OGCF' | 'TERC' | 'OGCC'; 9 FixedChargeCode = 'BMCH' | 'MPCA'; 10 MeasurementMethod1Code = 'DAIL' | 'WEEK' | 'MNTH' | 'QUTR' | 'SEMI' | 'YEAR' | 'WKEM' | 'MNEM' | 'QUEM' | 'SAEM' | 'YREM'; 11 EventSchedule2Code = 'DAIL' | 'WEEK' | 'MNTH' | 'QUTR' | 'SEMI' | 'YEAR'; 12 OfferRights1Code = 'PPLA' | 'POFR' | 'POPP' | 'NONE'; 13 PartialChargePeriodConventionCode = 'SHOR' | 'LONG'; 14 PayeeCode = 'CPNY' | 'CPTY'; 15 PaymentCurrency1Code = 'BCCY' | 'SCCY' | 'MCCY' | 'ICCY'; 16 PaymentMechanism1Code = 'CPNY' | 'CPTY'; 17 RollingHurdleConventionCode = 'SMPL' | 'CPND'; 18 PerformancePeriodStartConventionCode = 'NEUT' | 'PROG' | 'ADAP'; 19 PerformancePeriodTypeCode = 'FIXD' | 'XTND' | 'ROLL'; 20 PeriodDays1Code = 'A365' | 'A366' | 'A360'; 21 PeriodFrequency5Code = 'WEEK' | 'MNTH' | 'QUTR' | 'SEMI' | 'YEAR'; 22 FundPlatform1Code = 'CEDE' | 'EOCC' | 'FSTL' | 'CRST' | 'DAKV' | 'CIKB' | 'APKE' | 'SICV' | 'NECI'; 23 PortfolioReturnMeasureCode = 'NETT' | 'GROS'; 24 ProductAggregation1Code = 'SHRE' | 'SFND' | 'FUND'; 25 RateTransactionChargeCode = 'FEND' | 'BEND' | 'SWIT' | 'MVMT'; 26 RateMethod1Code = 'FBND' | 'VWAR'; 27 EventSchedule1Code = 'DAIL' | 'WEEK' | 'MNTH' | 'QUTR' | 'SEMI' | 'YEAR'; 28 PeriodicChargeTerminationModeCode = 'COTM' | 'SURV'; 29 PeriodFrequency1Code = 'WEEK' | 'TWMN' | 'MNTH' | 'QUTR' | 'SEMI' | 'YEAR'; 30 VolumePeriodicChargeCode = 'TRLF' | 'INSF' | 'ISIP' | 'FCAF' | 'MANF' | 'CUSF' | 'RFLF' | 'ADVF' | 'REFF' | 'LCOF'; 31 PeriodDays2Code = 'A360' | 'A365' | 'A366' | 'JYER';
- 16. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 16 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 CalculationFrequency Daily 7 Actual number of calendar days in the month Actual number of calendar days in the quarter Actual number of calendar days in the half-year Actual number of calendar days in the year Weekly 1 Actual number of calendar weeks in the month Actual number of calendar weeks in the quarter Actual number of calendar weeks in the half-year Actual number of calendar weeks in the 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:
- 17. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 17 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 c th 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 c th 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.
- 18. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 18 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 CalculationFrequency Daily Count every calendar day in the periodic charge calculation cycle, except 29 February Count every calendar day in the periodic charge calculation 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 Count every calendar day in the year, including 29 February 360 365.25
- 19. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 19 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) PeriodicCharge → PeriodicChargeAggregation 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.
- 20. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 20 Backward method The value of a periodic charge is determined by the formula: Value of periodic charge = 1 PeriodDays ∑ (AUMi × Daysi × 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) PeriodicCharge → PeriodicChargeAggregation 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 CalculationFrequency Daily Count every calendar day in the periodic charge calculation cycle, except 29 February Count every calendar day in the periodic charge calculation 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.)
- 21. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 21 YearDays CalendarDays365 CalendarDays366 StandardYear360 StandardYear365.25 Count every calendar day in the year, except 29 February Count every calendar day in the year, including 29 February 360 365.25
- 22. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 22 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.
- 23. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 23 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. Typology and constraints 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. Typology and constraints 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. Typology and constraints 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.
- 24. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 24 Rule ApplicableLawAndJurisdiction = Law, Jurisdiction; Synopsis The law applicable to the agreement and the courts of the jurisdiction to which the parties will submit. Typology and constraints 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. Typology and constraints 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. Typology and constraints CalculationFrequency is an enumerated type implemented as the following four-letter codes: 'DAIL' | 'WEEK' | 'MNTH' | 'QUTR' | 'SEMI' | 'YEAR'. User guide Not defined.
- 25. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 25 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. Typology and constraints 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. Typology and constraints 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. Typology and constraints CashFlowType is an enumerated type implemented as the following four-letter codes: 'STRT' | 'BKWD'. User guide See Part 5 of this document.
- 26. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 26 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. Typology and constraints 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. Typology and constraints 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. Typology and constraints 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.
- 27. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 27 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. Typology and constraints 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. Typology and constraints 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%
- 28. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 28 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. Typology and constraints 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. Typology and constraints 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. Typology and constraints 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.
- 29. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 29 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. Typology and constraints 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. Typology and constraints 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.
- 30. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 30 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. Typology and constraints 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. Typology and constraints 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. Typology and constraints 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.
- 31. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 31 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. Typology and constraints 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. Typology and constraints 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.
- 32. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 32 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. Typology and constraints 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. Typology and constraints 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. Typology and constraints FixedChargeType: Defined in this document. Amount: ISO 20222 Number, > 0. Currency: ISO 20022 CurrencyCode. User guide Not defined.
- 33. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 33 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. Typology and constraints 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. Typology and constraints 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. Typology and constraints 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.
- 34. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 34 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. Typology and constraints 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. Typology and constraints 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).
- 35. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 35 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. Typology and constraints 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 1i dd ii NAVHoldings n 1 ueHoldingVal Where: n = number of days in the month di = 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 1j dd ji NAVHoldings n 1 ueHoldingVal Where: n = number of days in the quarter a = number of months in the quarter b = number of days in month i di = 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. Typology and constraints IncrementalTrade is an enumerated type implemented as the following four-letter codes: 'TRAD' | 'SETT'. User guide See also the rule EligiblePosition.
- 36. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 36 Rule ISINAndDescription = ISIN, [Description]; Synopsis An international securities identification number and a descriptor (typically the full name of the share class). Typology and constraints 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. Typology and constraints 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. Typology and constraints 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.
- 37. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 37 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. Typology and constraints 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). Typology and constraints LookupFrequency is an enumerated type implemented as the following four-letter codes: 'DAIL' | 'WEEK' | 'MNTH' | 'QUTR' | 'SEMI' | 'YEAR'. 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.
- 38. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 38 Rule Market = Country | Proprietary | URL; Synopsis Define a market to be a single country or a proprietary market definition or accessible via a URL. Typology and constraints 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. Typology and constraints 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.
- 39. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 39 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. Typology and constraints 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. Typology and constraints 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. Typology and constraints 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.
- 40. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 40 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. Typology and constraints 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. Typology and constraints 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. Typology and constraints AnyBIC ISO 20022 AnyBICIdentifier. LEIIdentifier ISO 20022 LEIIdentifier. ProprietaryID ISO 20022 GenericIdentification1. NameAndAddress ISO 20022 NameAndAddress5. User guide Not defined.
- 41. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 41 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). Typology and constraints 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. Typology and constraints 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. Typology and constraints 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).
- 42. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 42 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. Typology and constraints 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. Typology and constraints 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.
- 43. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 43 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. Typology and constraints 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. Typology and constraints 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. Typology and constraints HoldingAddressPath: ISO 20022 Max350Text. HoldingAddressNumber: ISO 20022 Max35Text. PayThruFundPayment: Defined in this document. User guide Not defined.
- 44. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 44 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. Typology and constraints 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. Typology and constraints 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. Typology and constraints ProRata: Literal. PayThruFundSingleAccount: Defined in this document. PayThruFundSet: Defined in this document. User guide Not defined.
- 45. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 45 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. Typology and constraints 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. Typology and constraints 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. Typology and constraints 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).
- 46. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 46 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. Typology and constraints 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. Typology and constraints PerformancePeriodStartConventionCode: Defined in this document. Proprietary: ISO 20022 GenericIdentification30. User guide Not defined.
- 47. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 47 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. Typology and constraints 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. Typology and constraints 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. Typology and constraints 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.
- 48. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 48 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. Typology and constraints 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
- 49. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 49 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. Typology and constraints 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.
- 50. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 50 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. Typology and constraints 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. Typology and constraints PeriodicChargeHoldingDetails Defined in this document. DefinedLater Literal. User guide Not defined.
- 51. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 51 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. Typology and constraints 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. Typology and constraints 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.
- 52. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 52 Rule PeriodicChargePeriod = 'Weekly' | 'Monthly' | 'Quarterly' | 'HalfYearly' | 'Yearly'; Synopsis Determines the duration of a periodic charge period. Typology and constraints 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. Typology and constraints 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.
- 53. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 53 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. Typology and constraints 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. Typology and constraints 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. Typology and constraints 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.
- 54. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 54 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. Typology and constraints 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. Typology and constraints 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.
- 55. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 55 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. Typology and constraints 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 Typology and constraints 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. Typology and constraints RateTransactionChargeCode: Defined in this document. Proprietary: ISO 20022 GenericIdentification30. RateTable: Defined in this document. User guide Not defined.
- 56. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 56 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. Typology and constraints 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). Typology and constraints 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. Typology and constraints RateMethod: Defined in this document. ReferenceCurrency: ISO 20022 CurrencyCode. RateTableRow: Defined in this document. User guide Not defined.
- 57. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 57 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. Typology and constraints 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. Typology and constraints 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.
- 58. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 58 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. Typology and constraints 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. Typology and constraints 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. Typology and constraints 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.
- 59. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 59 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. Typology and constraints 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). Typology and constraints SharedAccountHoldingUpdateFrequency is an enumerated type implemented as the following four-letter codes: 'DAIL' | 'WEEK' | 'MNTH' | 'QUTR' | 'SEMI' | 'YEAR'. 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. Typology and constraints 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.
- 60. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 60 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. Typology and constraints 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. Typology and constraints 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. Typology and constraints 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. Typology and constraints 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.
- 61. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 61 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. Typology and constraints 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. Typology and constraints 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.
- 62. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 62 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. Typology and constraints 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)
- 63. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 63 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. Typology and constraints 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. Typology and constraints TransactionChargeHoldingAddress Defined in this document. DefinedLater Literal. User guide There should be no duplicates in the tuple (HoldingAddressPath, HoldingAddressNumber) within TransactionChargeHoldingAddress.
- 64. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 64 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. Typology and constraints 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. Typology and constraints 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.
- 65. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 65 Rule TransactionChargePeriod = 'Weekly' | 'SemiMonthly' | 'Monthly' | 'Quarterly' | 'HalfYearly' | 'Yearly'; Synopsis Determines the duration of a transaction charge period. Typology and constraints 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. Typology and constraints 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.
- 66. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 66 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. Typology and constraints 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. Typology and constraints 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. Typology and constraints 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.
- 67. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 67 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). Typology and constraints 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
- 68. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 68 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 NAVHoldingsueHoldingVal Where dc = relevant calculation day 3. DAIL DAIL DAIL cc dd NAVHoldingsueHoldingVal Where dc = relevant calculation day 4. DAIL WEEK RHC n 1i dd ii NAVHoldings n 1 ueHoldingVal Where: n = number of days in the week di = day i 5. DAIL WEEK RCLF Deprecated. See user guide. n 1i dd zi NAVHoldings n 1 ueHoldingVal Where: n = number of days in the week di = day i dz = last day in the week 6. DAIL WEEK DAIL n 1i dd ii NAVHoldings n 1 ueHoldingVal Where: n = number of days in the week di = day i 7. DAIL MNTH RHC n 1i dd ii NAVHoldings n 1 ueHoldingVal Where: n = number of days in the month di = day i
- 69. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 69 Nr. HC CF / LF ANAV HoldingValue definition 8. DAIL MNTH RCLF Deprecated. See user guide. n 1i dd zi NAVHoldings n 1 ueHoldingVal Where: n = number of days in the month di = day i dz = last day in the month 9. DAIL MNTH DAIL n 1i dd ii NAVHoldings n 1 ueHoldingVal Where: n = number of days in the month di = day i 10. DAIL QUTR RHC n 1i dd ii NAVHoldings n 1 ueHoldingVal Where: n = number of days in the quarter di = day i 11. DAIL QUTR RCLF Deprecated. See user guide. n 1i dd zi NAVHoldings n 1 ueHoldingVal Where: n = number of days in the quarter di = day i dz = last day in the quarter 12. DAIL QUTR DAIL n 1i dd ii NAVHoldings n 1 ueHoldingVal Where: n = number of days in the quarter di = day i 13. DAIL SEMI RHC n 1i dd ii NAVHoldings n 1 ueHoldingVal Where: n = number of days in the half-year di = day i 14. DAIL SEMI RCLF Deprecated. See user guide. n 1i dd zi NAVHoldings n 1 ueHoldingVal Where: n = number of days in the half-year di = day i dz = last day in the half-year
- 70. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 70 Nr. HC CF / LF ANAV HoldingValue definition 15. DAIL SEMI DAIL n 1i dd ii NAVHoldings n 1 ueHoldingVal Where: n = number of days in the half-year di = day i 16. DAIL YEAR RHC n 1i dd ii NAVHoldings n 1 ueHoldingVal Where: n = number of days in the year di = day i 17. DAIL YEAR RCLF Deprecated. See user guide. n 1i dd zi NAVHoldings n 1 ueHoldingVal Where: n = number of days in the year di = day i dz = last day in the year 18. DAIL YEAR DAIL n 1i dd ii NAVHoldings n 1 ueHoldingVal Where: n = number of days in the year di = day i 19. WEEK DAIL RHC zz dd NAVHoldingsueHoldingVal Where dz = last day in the week 20. WEEK DAIL RCLF cz dd NAVHoldingsueHoldingVal Where: dz = last day in the week dc = relevant calculation day 21. WEEK DAIL DAIL cz dd NAVHoldingsueHoldingVal Where: dz = last day in the week dc = relevant calculation day 22. WEEK WEEK RHC zz dd NAVHoldingsueHoldingVal Where dz = last day in the week 23. WEEK WEEK RCLF zz dd NAVHoldingsueHoldingVal Where dz = last day in the week 24. WEEK WEEK DAIL n 1i dd iz NAVHoldings n 1 ueHoldingVal Where: n = number of days in the week dz = last day in the week di = day i
- 71. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 71 Nr. HC CF / LF ANAV HoldingValue definition 25. WEEK MNTH RHC n 1i dd ii NAVHoldings n 1 ueHoldingVal Where: n = number of weeks in the month di = last day of week i 26. WEEK MNTH RCLF Deprecated. See user guide. n 1i dd zi NAVHoldings n 1 ueHoldingVal Where: n = number of weeks in the month di = last day of week i dz = last day in the month 27. WEEK MNTH DAIL a 1i b 1j dd ji NAVHoldings n 1 ueHoldingVal Where: n = number of days in the month a = number of weeks in the month b = number of days in week i di = last day of week i dj = day j in week i 28. WEEK QUTR RHC n 1i dd ii NAVHoldings n 1 ueHoldingVal Where: n = number of weeks in the quarter di = last day of week i 29. WEEK QUTR RCLF Deprecated. See user guide. n 1i dd zi NAVHoldings n 1 ueHoldingVal Where: n = number of weeks in the quarter di = last day of week i dz = last day in the quarter 30. WEEK QUTR DAIL a 1i b 1j dd ji NAVHoldings n 1 ueHoldingVal Where: n = number of days in the quarter a = number of weeks in the quarter b = number of days in week i di = last day of week i dj = day j in week i 31. WEEK SEMI RHC n 1i dd ii NAVHoldings n 1 ueHoldingVal Where: n = number of weeks in the half-year di = last day of week i
- 72. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 72 Nr. HC CF / LF ANAV HoldingValue definition 32. WEEK SEMI RCLF Deprecated. See user guide. n 1i dd zi NAVHoldings n 1 ueHoldingVal Where: n = number of weeks in the half-year di = last day of week i dz = last day in the half-year 33. WEEK SEMI DAIL a 1i b 1j dd ji NAVHoldings n 1 ueHoldingVal Where: n = number of days in the half-year a = number of weeks in the half-year b = number of days in week i di = last day of week i dj = day j in week i 34. WEEK YEAR RHC n 1i dd ii NAVHoldings n 1 ueHoldingVal Where: n = number of weeks in the year di = last day of week i 35. WEEK YEAR RCLF Deprecated. See user guide. n 1i dd zi NAVHoldings n 1 ueHoldingVal Where: n = number of weeks in the year di = last day of week i dz = last day in the year 36. WEEK YEAR DAIL a 1i b 1j dd ji NAVHoldings n 1 ueHoldingVal Where: n = number of days in the year a = number of weeks in the year b = number of days in week i di = last day of week i dj = day j in week i 37. MNTH DAIL RHC zz dd NAVHoldingsueHoldingVal Where dz = last day in the month 38. MNTH DAIL RCLF cz dd NAVHoldingsueHoldingVal Where: dz = last day in the month dc = relevant calculation day 39. MNTH DAIL DAIL cz dd NAVHoldingsueHoldingVal Where: dz = last day in the month dc = relevant calculation day
- 73. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 73 Nr. HC CF / LF ANAV HoldingValue definition 40. MNTH WEEK RHC zz dd NAVHoldingsueHoldingVal Where dz = last day in the month 41. MNTH WEEK RCLF cz dd NAVHoldingsueHoldingVal Where: dz = last day in the month dc = last day in the relevant week 42. MNTH WEEK DAIL n 1i dd iz NAVHoldings n 1 ueHoldingVal Where: n = number of days in the week dz = last day in the month di = day i 43. MNTH MNTH RHC zz dd NAVHoldingsueHoldingVal Where dz = last day in the month 44. MNTH MNTH RCLF zz dd NAVHoldingsueHoldingVal Where dz = last day in the month 45. MNTH MNTH DAIL n 1i dd iz NAVHoldings n 1 ueHoldingVal Where: n = number of days in the month dz = last day in the month di = day i 46. MNTH QUTR RHC n 1i dd ii NAVHoldings n 1 ueHoldingVal Where: n = number of months in the quarter di = last day of month i 47. MNTH QUTR RCLF Deprecated. See user guide. n 1i dd zi NAVHoldings n 1 ueHoldingVal Where: n = number of months in the quarter di = last day of month i dz = last day in the quarter 48. MNTH QUTR DAIL a 1i b 1j dd ji NAVHoldings n 1 ueHoldingVal Where: n = number of days in the quarter a = number of months in the quarter b = number of days in month i di = last day of month i dj = day j in month i
- 74. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 74 Nr. HC CF / LF ANAV HoldingValue definition 49. MNTH SEMI RHC n 1i dd ii NAVHoldings n 1 ueHoldingVal Where: n = number of months in the half-year di = last day of month i 50. MNTH SEMI RCLF Deprecated. See user guide. n 1i dd zi NAVHoldings n 1 ueHoldingVal Where: n = number of months in the half-year di = last day of month i dz = last day in the half-year 51. MNTH SEMI DAIL a 1i b 1j dd ji NAVHoldings n 1 ueHoldingVal Where: n = number of days in the half-year a = number of months in the half-year b = number of days in month i di = last day of month i dj = day j in month i 52. MNTH YEAR RHC n 1i dd ii NAVHoldings n 1 ueHoldingVal Where: n = number of months in the year di = last day of month i 53. MNTH YEAR RCLF Deprecated. See user guide. n 1i dd zi NAVHoldings n 1 ueHoldingVal Where: n = number of months in the year di = last day of month i dz = last day in the year 54. MNTH YEAR DAIL a 1i b 1j dd ji NAVHoldings n 1 ueHoldingVal Where: n = number of days in the year a = number of months in the year b = number of days in month i di = last day of month i dj = day j in month i 55. QUTR DAIL RHC zz dd NAVHoldingsueHoldingVal Where dz = last day in the quarter
- 75. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 75 Nr. HC CF / LF ANAV HoldingValue definition 56. QUTR DAIL RCLF cz dd NAVHoldingsueHoldingVal Where: dz = last day in the quarter dc = relevant calculation day 57. QUTR DAIL DAIL cz dd NAVHoldingsueHoldingVal Where: dz = last day in the quarter dc = relevant calculation day 58. QUTR WEEK RHC zz dd NAVHoldingsueHoldingVal Where dz = last day in the quarter 59. QUTR WEEK RCLF cz dd NAVHoldingsueHoldingVal Where: dz = last day in the quarter dc = last day in the relevant week 60. QUTR WEEK DAIL n 1i dd iz NAVHoldings n 1 ueHoldingVal Where: n = number of days in the week dz = last day in the quarter di = day i 61. QUTR MNTH RHC zz dd NAVHoldingsueHoldingVal Where dz = last day in the quarter 62. QUTR MNTH RCLF cz dd NAVHoldingsueHoldingVal Where: dz = last day in the quarter dc = last day in the relevant month 63. QUTR MNTH DAIL n 1i dd iz NAVHoldings n 1 ueHoldingVal Where: n = number of days in the relevant month dz = last day in the quarter di = day i 64. QUTR QUTR RHC zz dd NAVHoldingsueHoldingVal Where dz = last day in the quarter 65. QUTR QUTR RCLF zz dd NAVHoldingsueHoldingVal Where dz = last day in the quarter 66. QUTR QUTR D n 1i dd iz NAVHoldings n 1 ueHoldingVal Where: n = number of days in the quarter dz = last day in the quarter di = day i
- 76. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 76 Nr. HC CF / LF ANAV HoldingValue definition 67. QUTR SEMI RHC n 1i dd ii NAVHoldings n 1 ueHoldingVal Where: n = number of quarters in the half-year di = last day of quarter i 68. QUTR SEMI RCLF Deprecated. See user guide. n 1i dd zi NAVHoldings n 1 ueHoldingVal Where: n = number of quarters in the half-year di = last day of quarter i dz = last day in the half-year 69. QUTR SEMI DAIL a 1i b 1j dd ji NAVHoldings n 1 ueHoldingVal Where: n = number of days in the half-year a = number of quarters in the half-year b = number of days in quarter i di = last day of quarter i dj = day j in quarter i 70. QUTR YEAR RHC n 1i dd ii NAVHoldings n 1 ueHoldingVal Where: n = number of quarters in the year di = last day of quarter i 71. QUTR YEAR RCLF Deprecated. See user guide. n 1i dd zi NAVHoldings n 1 ueHoldingVal Where: n = number of quarters in the year di = last day of quarter i dz = last day in the year 72. QUTR YEAR DAIL a 1i b 1j dd ji NAVHoldings n 1 ueHoldingVal Where: n = number of days in the year a = number of quarters in the year b = number of days in quarter i di = last day of quarter i dj = day j in quarter i 73. SEMI DAIL RHC zz dd NAVHoldingsueHoldingVal Where dz = last day in the half-year
- 77. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 77 Nr. HC CF / LF ANAV HoldingValue definition 74. SEMI DAIL RCLF cz dd NAVHoldingsueHoldingVal Where: dz = last day in the half-year dc = relevant calculation day 75. SEMI DAIL DAIL cz dd NAVHoldingsueHoldingVal Where: dz = last day in the half-year dc = relevant calculation day 76. SEMI WEEK RHC zz dd NAVHoldingsueHoldingVal Where dz = last day in the half-year 77. SEMI WEEK RCLF cz dd NAVHoldingsueHoldingVal Where: dz = last day in the half-year dc = last day in the relevant week 78. SEMI WEEK DAIL n 1i dd iz NAVHoldings n 1 ueHoldingVal Where: n = number of days in the week dz = last day in the half-year di = day i 79. SEMI MNTH RHC zz dd NAVHoldingsueHoldingVal Where dz = last day in the half-year 80. SEMI MNTH RCLF cz dd NAVHoldingsueHoldingVal Where: dz = last day in the half-year dc = last day in the relevant month 81. SEMI MNTH DAIL n 1i dd iz NAVHoldings n 1 ueHoldingVal Where: n = number of days in the relevant month dz = last day in the half-year di = day i 82. SEMI QUTR RHC zz dd NAVHoldingsueHoldingVal Where dz = last day in the half-year 83. SEMI QUTR RCLF cz dd NAVHoldingsueHoldingVal Where: dz = last day in the half-year dc = last day in the relevant quarter 84. SEMI QUTR DAIL n 1i dd iz NAVHoldings n 1 ueHoldingVal Where: n = number of days in the relevant quarter dz = last day in the half-year di = day i
- 78. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 78 Nr. HC CF / LF ANAV HoldingValue definition 85. SEMI SEMI RHC zz dd NAVHoldingsueHoldingVal Where dz = last day in the half-year 86. SEMI SEMI RCLF zz dd NAVHoldingsueHoldingVal Where dz = last day in the half-year 87. SEMI SEMI DAIL n 1i dd iz NAVHoldings n 1 ueHoldingVal Where: n = number of days in the half-year dz = last day in the half-year di = day i 88. SEMI YEAR RHC n 1i dd ii NAVHoldings n 1 ueHoldingVal 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 1i dd zi NAVHoldings n 1 ueHoldingVal Where: n = number of half-years in the year di = last day of half-year i dz = last day in the year 90. SEMI YEAR DAIL a 1i b 1j dd ji NAVHoldings n 1 ueHoldingVal Where: n = number of days in the year a = number of half-years in the year b = number of days in half-year i di = last day of half-year i dj = day j in half-year i 91. YEAR DAIL RHC zz dd NAVHoldingsueHoldingVal Where dz = last day in the year 92. YEAR DAIL RCLF cz dd NAVHoldingsueHoldingVal Where: dz = last day in the year dc = relevant calculation day 93. YEAR DAIL DAIL cz dd NAVHoldingsueHoldingVal Where: dz = last day in the year dc = relevant calculation day 94. YEAR WEEK RHC zz dd NAVHoldingsueHoldingVal Where dz = last day in the year
- 79. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 79 Nr. HC CF / LF ANAV HoldingValue definition 95. YEAR WEEK RCLF cz dd NAVHoldingsueHoldingVal Where: dz = last day in the year dc = last day in the relevant week 96. YEAR WEEK DAIL n 1i dd iz NAVHoldings n 1 ueHoldingVal Where: n = number of days in the week dz = last day in the year di = day i 97. YEAR MNTH RHC zz dd NAVHoldingsueHoldingVal Where dz = last day in the year 98. YEAR MNTH RCLF cz dd NAVHoldingsueHoldingVal Where: dz = last day in the year dc = last day in the relevant month 99. YEAR MNTH DAIL n 1i dd iz NAVHoldings n 1 ueHoldingVal Where: n = number of days in the relevant month dz = last day in the year di = day i 100. YEAR QUTR RHC zz dd NAVHoldingsueHoldingVal Where dz = last day in the year 101. YEAR QUTR RCLF cz dd NAVHoldingsueHoldingVal Where: dz = last day in the year dc = last day in the relevant quarter 102. YEAR QUTR DAIL n 1i dd iz NAVHoldings n 1 ueHoldingVal Where: n = number of days in the relevant quarter dz = last day in the year di = day i 103. YEAR SEMI RHC zz dd NAVHoldingsueHoldingVal Where dz = last day in the year 104. YEAR SEMI RCLF cz dd NAVHoldingsueHoldingVal Where: dz = last day in the year dc = last day in the relevant half-year
- 80. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 80 Nr. HC CF / LF ANAV HoldingValue definition 105. YEAR SEMI DAIL n 1i dd iz NAVHoldings n 1 ueHoldingVal Where: n = number of days in the relevant half-year dz = last day in the year di = day i 106. YEAR YEAR RHC zz dd NAVHoldingsueHoldingVal Where dz = last day in the year 107. YEAR YEAR RCLF zz dd NAVHoldingsueHoldingVal Where dz = last day in the year 108. YEAR YEAR DAIL n 1i dd iz NAVHoldings n 1 ueHoldingVal Where: n = number of days in the year dz = last day in the year di = day i 109. WKEM DAIL RHC 2 NAVHoldingsNAVHoldings ueHoldingVal 1z1zzz dddd Where: dz = last day of current week dz-1 = last day of prior week 110. WKEM DAIL RCLF c 1zz d dd NAV 2 HoldingsHoldings ueHoldingVal Where: dz = last day of current week dz-1 = last day of prior week dc = relevant calculation day in current week 111. WKEM DAIL DAIL c 1zz d dd NAV 2 HoldingsHoldings ueHoldingVal Where: dz = last day of current week dz-1 = last day of prior week dc = relevant calculation day in current week 112. WKEM WEEK RHC 2 NAVHoldingsNAVHoldings ueHoldingVal 1z1zzz dddd Where: dz = last day of current week dz-1 = last day of prior week 113. WKEM WEEK RCLF z 1zz d dd NAV 2 HoldingsHoldings ueHoldingVal Where: dz = last day of current week dz-1 = last day of prior week
- 81. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 81 Nr. HC CF / LF ANAV HoldingValue definition 114. WKEM WEEK DAIL n 1i d dd i 1zz NAV 2 HoldingsHoldings n 1 ueHoldingVal Where: n = number of days in the week dz = last day of current week dz-1 = last day of prior week di = day i 115. WKEM MNTH RHC n 1i dddd 2 NAVHoldingsNAVHoldings n 1 ueHoldingVal 1i1iii Where: n = number of weeks in the month di = last day of week i 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 NAV 2 HoldingsHoldings n 1 ueHoldingVal Where: n = number of weeks in the month di = last day of week i di-1 = last day of the week prior to week i dz = last day of the month 117. WKEM MNTH DAIL a 1i d b 1j dd j 1ii NAV 2 HoldingsHoldings n 1 ueHoldingVal Where: n = number of days in the month a = number of weeks in the month b = number of days in week i di = last day of week i di-1 = last day of the week prior to week i dj = day j in week i 118. WKEM QUTR RHC n 1i dddd 2 NAVHoldingsNAVHoldings n 1 ueHoldingVal 1i1iii Where: n = number of weeks in the quarter di = last day of week i di-1 = last day of the week prior to week i 119. WKEM QUTR RCLF Deprecated. See user guide. z 1ii d n 1i dd NAV 2 HoldingsHoldings n 1 ueHoldingVal Where: n = number of weeks in the quarter di = last day of week i di-1 = last day of the week prior to week i dz = last day of the quarter
- 82. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 82 Nr. HC CF / LF ANAV HoldingValue definition 120. WKEM QUTR DAIL a 1i d b 1j dd j 1ii NAV 2 HoldingsHoldings n 1 ueHoldingVal Where: n = number of days in the quarter a = number of weeks in the quarter b = number of days in week i di = last day of week i di-1 = last day of the week prior to week i dj = day j in week i 121. WKEM SEMI RHC n 1i dddd 2 NAVHoldingsNAVHoldings n 1 ueHoldingVal 1i1iii Where: n = number of weeks in the half-year di = last day of week i di-1 = last day of the week prior to week i 122. WKEM SEMI RCLF Deprecated. See user guide. z 1ii d n 1i dd NAV 2 HoldingsHoldings n 1 ueHoldingVal Where: n = number of weeks in the half-year di = last day of week i di-1 = last day of the week prior to week i dz = last day of the half-year 123. WKEM SEMI DAIL a 1i d b 1j dd j 1ii NAV 2 HoldingsHoldings n 1 ueHoldingVal Where: n = number of days in the half-year a = number of weeks in the half-year b = number of days in week i dj = last day of week i dj-1 = last day of the week prior to week i dj = day j in week i 124. WKEM YEAR RHC n 1i dddd 2 NAVHoldingsNAVHoldings n 1 ueHoldingVal 1i1iii Where: n = number of weeks in the year di = last day of week i di-1 = last day of the week prior to week i 125. WKEM YEAR RCLF Deprecated. See user guide. z 1ii d n 1i dd NAV 2 HoldingsHoldings n 1 ueHoldingVal Where: n = number of weeks in the year di = last day of week i di-1 = last day of the week prior to week i dz = last day of the year
- 83. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 83 Nr. HC CF / LF ANAV HoldingValue definition 126. WKEM YEAR DAIL a 1i d b 1j dd j 1ii NAV 2 HoldingsHoldings n 1 ueHoldingVal Where: n = number of days in the year a = number of weeks in the year b = number of days in week i dj = last day of week i dj-1 = last day of the week prior to week i dj = day j in week i 127. MNEM DAIL RHC 2 NAVHoldingsNAVHoldings ueHoldingVal 1z1zzz dddd Where: dz = last day of current month dz-1 = last day of prior month 128. MNEM DAIL RCLF c 1zz d dd NAV 2 HoldingsHoldings ueHoldingVal Where: dz = last day of current month dz-1 = last day of prior month dc = relevant calculation day in current month 129. MNEM DAIL DAIL c 1zz d dd NAV 2 HoldingsHoldings ueHoldingVal Where: dz = last day of current month dz-1 = last day of prior month dc = relevant calculation day in current month 130. MNEM WEEK RHC 2 NAVHoldingsNAVHoldings ueHoldingVal 1z1zzz dddd Where: dz = last day of current month dz-1 = last day of prior month 131. MNEM WEEK RCLF c 1zz d dd NAV 2 HoldingsHoldings ueHoldingVal Where: dz = last day of current month dz-1 = last day of prior month dc = last day in the relevant week 132. MNEM WEEK DAIL n 1i d dd i 1zz NAV 2 HoldingsHoldings n 1 ueHoldingVal Where: n = number of days in the week 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 NAVHoldingsNAVHoldings ueHoldingVal 1z1zzz dddd Where: dz = last day of current month dz-1 = last day of prior month
- 84. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 84 Nr. HC CF / LF ANAV HoldingValue definition 134. MNEM MNTH RCLF z 1zz d dd NAV 2 HoldingsHoldings ueHoldingVal Where: dz = last day of current month dz-1 = last day of prior month 135. MNEM MNTH DAIL n 1i d dd i 1zz NAV 2 HoldingsHoldings n 1 ueHoldingVal Where: n = number of days in the current month dz = last day of current month dz-1 = last day of prior month di = day i 136. MNEM QUTR RHC n 1i dddd 2 NAVHoldingsNAVHoldings n 1 ueHoldingVal 1i1iii Where: n = number of months in the quarter di = last day of month i 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 NAV 2 HoldingsHoldings n 1 ueHoldingVal Where: n = number of months in the quarter di = last day of month i di-1 = last day of the month prior to month i dz = last day of the quarter 138. MNEM QUTR DAIL a 1i d b 1j dd j 1ii NAV 2 HoldingsHoldings n 1 ueHoldingVal Where: n = number of days in the quarter a = number of months in the quarter b = number of days in month i di = last day of month i di-1 = last day of the month prior to month i dj = day j in month i 139. MNEM SEMI RHC n 1i dddd 2 NAVHoldingsNAVHoldings n 1 ueHoldingVal 1i1iii Where: n = number of months in the half-year di = last day of month i di-1 = last day of the month prior to month i
- 85. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 85 Nr. HC CF / LF ANAV HoldingValue definition 140. MNEM SEMI RCLF Deprecated. See user guide. z 1ii d n 1i dd NAV 2 HoldingsHoldings n 1 ueHoldingVal Where: n = number of months in the half-year di = last day of month i di-1 = last day of the month prior to month i dz = last day of the half-year 141. MNEM SEMI DAIL a 1i d b 1j dd j 1ii NAV 2 HoldingsHoldings n 1 ueHoldingVal Where: n = number of days in the half-year a = number of months in the half-year b = number of days in month i di = last day of month i di-1 = last day of the month prior to month i dj = day j in month i 142. MNEM YEAR RHC n 1i dddd 2 NAVHoldingsNAVHoldings n 1 ueHoldingVal 1i1iii Where: n = number of months in the year di = last day of month i di-1 = last day of the month prior to month i 143. MNEM YEAR RCLF Deprecated. See user guide. z 1ii d n 1i dd NAV 2 HoldingsHoldings n 1 ueHoldingVal Where: n = number of months in the year di = last day of month i di-1 = last day of the month prior to month i dz = last day of the year 144. MNEM YEAR DAIL a 1i d b 1j dd j 1ii NAV 2 HoldingsHoldings n 1 ueHoldingVal Where: n = number of days in the year a = number of months in the year b = number of days in month i dj = last day of month i dj-1 = last day of the month prior to month i dj = day j in month i 145. QUEM DAIL RHC 2 NAVHoldingsNAVHoldings ueHoldingVal 1z1zzz dddd Where: dz = last day of current quarter dz-1 = last day of prior quarter
- 86. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 86 Nr. HC CF / LF ANAV HoldingValue definition 146. QUEM DAIL RCLF c 1zz d dd NAV 2 HoldingsHoldings ueHoldingVal Where: dz = last day of current quarter dz-1 = last day of prior quarter dc = relevant calculation day in current quarter 147. QUEM DAIL DAIL c 1zz d dd NAV 2 HoldingsHoldings ueHoldingVal Where: dz = last day of current quarter dz-1 = last day of prior quarter dc = relevant calculation day in current quarter 148. QUEM WEEK RHC 2 NAVHoldingsNAVHoldings ueHoldingVal 1z1zzz dddd Where: dz = last day of current quarter dz-1 = last day of prior quarter 149. QUEM WEEK RCLF c 1zz d dd NAV 2 HoldingsHoldings ueHoldingVal Where: dz = last day of current quarter dz-1 = last day of prior quarter dc = last day in the relevant week 150. QUEM WEEK DAIL n 1i d dd i 1zz NAV 2 HoldingsHoldings n 1 ueHoldingVal Where: n = number of days in the week dz = last day in the current quarter dz-1 = last day of the prior quarter di = day i in the relevant week 151. QUEM MNTH RHC 2 NAVHoldingsNAVHoldings ueHoldingVal 1z1zzz dddd Where: dz = last day of current quarter dz-1 = last day of prior quarter 152. QUEM MNTH RCLF c 1zz d dd NAV 2 HoldingsHoldings ueHoldingVal Where: dz = last day of current quarter dz-1 = last day of prior quarter dc = last day in the relevant month 153. QUEM MNTH DAIL n 1i d dd i 1zz NAV 2 HoldingsHoldings n 1 ueHoldingVal Where: n = number of days in the relevant month dz = last day in the current quarter dz-1 = last day of the prior quarter di = day i in the relevant month
- 87. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 87 Nr. HC CF / LF ANAV HoldingValue definition 154. QUEM QUTR RHC 2 NAVHoldingsNAVHoldings ueHoldingVal 1z1zzz dddd Where: dz = last day of current quarter dz-1 = last day of prior quarter 155. QUEM QUTR RCLF z 1zz d dd NAV 2 HoldingsHoldings ueHoldingVal Where: dz = last day of current quarter dz-1 = last day of prior quarter 156. QUEM QUTR DAIL n 1i d dd i 1zz NAV 2 HoldingsHoldings n 1 ueHoldingVal Where: n = number of days in the current quarter dz = last day of current quarter dz-1 = last day of prior quarter di = day i 157. QUEM SEMI RHC n 1i dddd 2 NAVHoldingsNAVHoldings n 1 ueHoldingVal 1i1iii Where: n = number of quarters in the half-year di = last day of quarter i 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 NAV 2 HoldingsHoldings n 1 ueHoldingVal Where: n = number of quarters in the half-year di = last day of quarter i di-1 = last day of the quarter prior to quarter i dz = last day of the half-year 159. QUEM SEMI DAIL a 1i d b 1j dd j 1ii NAV 2 HoldingsHoldings n 1 ueHoldingVal Where: n = number of days in the half-year a = number of quarters in the half-year b = number of days in quarter i di = last day of quarter i di-1 = last day of the quarter prior to quarter i dj = day j in quarter i 160. QUEM YEAR RHC n 1i dddd 2 NAVHoldingsNAVHoldings n 1 ueHoldingVal 1i1iii Where: n = number of quarters in the year di = last day of quarter i di-1 = last day of the quarter prior to quarter i
- 88. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 88 Nr. HC CF / LF ANAV HoldingValue definition 161. QUEM YEAR RCLF Deprecated. See user guide. z 1ii d n 1i dd NAV 2 HoldingsHoldings n 1 ueHoldingVal Where: n = number of quarters in the year di = last day of quarter i di-1 = last day of the quarter prior to quarter i dz = last day of the year 162. QUEM YEAR DAIL a 1i d b 1j dd j 1ii NAV 2 HoldingsHoldings n 1 ueHoldingVal Where: n = number of days in the year a = number of quarters in the year b = number of days in quarter i di = last day of quarter i di-1 = last day of the quarter prior to quarter i dj = day j in quarter i 163. SAEM DAIL RHC 2 NAVHoldingsNAVHoldings ueHoldingVal 1z1zzz dddd Where: dz = last day of current half-year dz-1 = last day of prior half-year 164. SAEM DAIL RCLF c 1zz d dd NAV 2 HoldingsHoldings ueHoldingVal Where: dz = last day of current half-year dz-1 = last day of prior half-year dc = relevant calculation day in current half-year 165. SAEM DAIL DAIL c 1zz d dd NAV 2 HoldingsHoldings ueHoldingVal Where: dz = last day of current half-year dz-1 = last day of prior half-year dc = relevant calculation day in current half-year 166. SAEM WEEK RHC 2 NAVHoldingsNAVHoldings ueHoldingVal 1z1zzz dddd Where: dz = last day of current half-year dz-1 = last day of prior half-year 167. SAEM WEEK RCLF c 1zz d dd NAV 2 HoldingsHoldings ueHoldingVal Where: dz = last day of current half-year dz-1 = last day of prior half-year dc = last day in the relevant week
- 89. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 89 Nr. HC CF / LF ANAV HoldingValue definition 168. SAEM WEEK DAIL n 1i d dd i 1zz NAV 2 HoldingsHoldings n 1 ueHoldingVal Where: n = number of days in the week dz = last day in the current half-year dz-1 = last day of the prior half-year di = day i in the relevant week 169. SAEM MNTH RHC 2 NAVHoldingsNAVHoldings ueHoldingVal 1z1zzz dddd Where: dz = last day of current half-year dz-1 = last day of prior half-year 170. SAEM MNTH RCLF c 1zz d dd NAV 2 HoldingsHoldings ueHoldingVal Where: dz = last day of current half-year dz-1 = last day of prior half-year dc = last day in the relevant month 171. SAEM MNTH DAIL n 1i d dd i 1zz NAV 2 HoldingsHoldings n 1 ueHoldingVal Where: n = number of days in the relevant month dz = last day in the half-year dz-1 = last day of prior half-year di = day i 172. SAEM QUTR RHC 2 NAVHoldingsNAVHoldings ueHoldingVal 1z1zzz dddd Where: dz = last day of current half-year dz-1 = last day of prior half-year 173. SAEM QUTR RCLF c 1zz d dd NAV 2 HoldingsHoldings ueHoldingVal Where: dz = last day of current half-year dz-1 = last day of prior half-year dc = last day in the relevant quarter 174. SAEM QUTR DAIL n 1i d dd i 1zz NAV 2 HoldingsHoldings n 1 ueHoldingVal Where: n = number of days in the relevant quarter 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 NAVHoldingsNAVHoldings ueHoldingVal 1z1zzz dddd Where: dz = last day of current half-year dz-1 = last day of prior half-year
- 90. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 90 Nr. HC CF / LF ANAV HoldingValue definition 176. SAEM SEMI RCLF z 1zz d dd NAV 2 HoldingsHoldings ueHoldingVal Where: dz = last day of current half-year dz-1 = last day of prior half-year 177. SAEM SEMI DAIL n 1i d dd i 1zz NAV 2 HoldingsHoldings n 1 ueHoldingVal Where: n = number of days in the current half-year dz = last day of current half-year dz-1 = last day of prior half-year di = day i 178. SAEM YEAR RHC n 1i dddd 2 NAVHoldingsNAVHoldings n 1 ueHoldingVal 1i1iii Where: n = number of half-years in the year di = last day of half-year i 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 NAV 2 HoldingsHoldings n 1 ueHoldingVal Where: n = number of half-years in the year di = last day of half-year i di-1 = last day of the half-year prior to half-year i dz = last day of the year 180. SAEM YEAR DAIL a 1i d b 1j dd j 1ii NAV 2 HoldingsHoldings n 1 ueHoldingVal Where: n = number of days in the year a = number of half-years in the year b = number of days in half-year i di = last day of half-year i di-1 = last day of the half-year prior to half-year i dj = day j in half-year i 181. YREM DAIL RHC 2 NAVHoldingsNAVHoldings ueHoldingVal 1z1zzz dddd Where: dz = last day of current year dz-1 = last day of prior year 182. YREM DAIL RCLF c 1zz d dd NAV 2 HoldingsHoldings ueHoldingVal Where: dz = last day of current year dz-1 = last day of prior year dc = relevant calculation day in current year
- 91. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 91 Nr. HC CF / LF ANAV HoldingValue definition 183. YREM DAIL DAIL c 1zz d dd NAV 2 HoldingsHoldings ueHoldingVal Where: dz = last day of current year dz-1 = last day of prior year dc = relevant calculation day in current year 184. YREM WEEK RHC 2 NAVHoldingsNAVHoldings ueHoldingVal 1z1zzz dddd Where: dz = last day of current year dz-1 = last day of prior year 185. YREM WEEK RCLF c 1zz d dd NAV 2 HoldingsHoldings ueHoldingVal Where: dz = last day of current year dz-1 = last day of prior year dc = last day in the relevant week 186. YREM WEEK DAIL n 1i d dd i 1zz NAV 2 HoldingsHoldings n 1 ueHoldingVal Where: n = number of days in the week dz = last day in the current year dz-1 = last day of the prior year di = day i in the relevant week 187. YREM MNTH RHC 2 NAVHoldingsNAVHoldings ueHoldingVal 1z1zzz dddd Where: dz = last day of current year dz-1 = last day of prior year 188. YREM MNTH RCLF c 1zz d dd NAV 2 HoldingsHoldings ueHoldingVal Where: dz = last day of current year dz-1 = last day of prior year dc = last day in the relevant month 189. YREM MNTH DAIL n 1i d dd i 1zz NAV 2 HoldingsHoldings n 1 ueHoldingVal Where: n = number of days in the relevant month dz = last day in the year dz-1 = last day of prior year di = day i 190. YREM QUTR RHC 2 NAVHoldingsNAVHoldings ueHoldingVal 1z1zzz dddd Where: dz = last day of current year dz-1 = last day of prior year
- 92. OpenTerms syntax andsemantic definitions, issue 02, 12 July 2016 Page 92 Nr. HC CF / LF ANAV HoldingValue definition 191. YREM QUTR RCLF c 1zz d dd NAV 2 HoldingsHoldings ueHoldingVal Where: dz = last day of current year dz-1 = last day of prior year dc = last day in the relevant quarter 192. YREM QUTR DAIL n 1i d dd i 1zz NAV 2 HoldingsHoldings n 1 ueHoldingVal Where: n = number of days in the relevant quarter dz = last day in the current year dz-1 = last day of the prior year di = day i 193. YREM SEMI RHC 2 NAVHoldingsNAVHoldings ueHoldingVal 1z1zzz dddd Where: dz = last day of current year dz-1 = last day of prior year 194. YREM SEMI RCLF c 1zz d dd NAV 2 HoldingsHoldings ueHoldingVal Where: dz = last day of current year dz-1 = last day of prior year dc = last day in the relevant half-year 195. YREM SEMI D n 1i d dd i 1zz NAV 2 HoldingsHoldings n 1 ueHoldingVal Where: n = number of days in the relevant half-year dz = last day in the current year dz-1 = last day of the prior year di = day i 196. YREM YEAR RHC 2 NAVHoldingsNAVHoldings ueHoldingVal 1z1zzz dddd Where: dz = last day of current year dz-1 = last day of prior year 197. YREM YEAR RCLF z 1zz d dd NAV 2 HoldingsHoldings ueHoldingVal Where: dz = last day of current year dz-1 = last day of prior year 198. YREM YEAR DAIL n 1i d dd i 1zz NAV 2 HoldingsHoldings n 1 ueHoldingVal Where: n = number of days in the current year dz = last day of current year dz-1 = last day of prior year di = day i