OpenTerms Syntax

OpenTerms project
Operational work stream
Syntax and semantic definitions
Issue 2.1
26 April 2017
© Metrosoft 2017
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.

OpenTerms syntax and semantic definitions, issue 2.1, Apr 2017 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
Further information
For further information on this document please contact:
Mateusz Derejski, Metrosoft Krakow (mateusz.s.derejski@metrosoft.com)

Part 1: Introduction
This document defines a syntax and provides a semantic reference for preparing documents to describe
the terms of business between an asset manager and its clients regardless of whether the clients are
subscribing to a pooled fund or a segregated account.
The textual listing of the syntax at Part 3 of this document complies with ISO/IEC 14977. A description of
that standard including guidance on how to read it is available on the Internet. Those who are not familiar
with the standard will find the synoptic charts at Part 2 easier to read initially. The following paragraphs
offer a short introduction to how to read the syntax.
The syntax uses a simple set of rules to describe terms of business. Rules have a left-hand-side, a right-
hand-side and a separation character "=", which indicates that the left-hand-side of the rule has the
meaning given by the terms on the right-hand-side. For example, the first and most important rule is:
Terms = Company, {Company}, Counterparty, {Counterparty}, Agreement, [Product, {Product},
{ProductExclusion}], [Market, {Market}, {MarketExclusion}], [{TransactionChargeSet}],
[{PeriodicChargeSet}], [{Payment}], [{Report}];
which means that terms of business are defined by the company and the counterparty who made them,
some legal terms, the products and markets to which the terms will apply, the charges and payment
mandates, etc.
The syntax commonly uses the following forms of control in its rules:
Sequence Items appear in a rule from left to right, separated by commas; their order is
important.
Choice Alternative items are separated by the "|" character. One item is chosen from the
list of alternatives; their order is not important.
Option Optional items are enclosed between the characters "[" and "]"; the item can be
included or discarded.
Repetition A repeatable item is enclosed between the characters "{" and "}"; the item can be
repeated zero or more times.
Iteration Limited iteration is indicated by the "*" character. For example, 4 * 'x' means that
the symbol 'x' must be included four times.
The rules also use the following special characters:
Quotation A term enclosed within single quotes stands for itself. For example, 'Clearstream'
means Clearstream Bank.
Group Some terms are grouped together in round brackets (like this) in order to ensure
the desired precedence between operators or to make a rule easier to read.
Termination A semi-colon ";" is used to mark the end of a rule.
Line breaks are sometimes used to make the rules easier to read; they have no special meaning.

Part 2: Synoptic charts of the terms of business syntax
Chart 1: Terms / Company / Counterparty / Agreement / Products / Markets.
Chart 2: TransactionChargeSet.
Chart 3: PeriodicChargeSet (Main).
Chart 4: FeeSharePeriodicCharge.
Chart 5: VolumePeriodicCharge.
Chart 6: PerformancePeriodicCharge / FixedCharge.
Chart 7: PeriodicChargeHolding.
Chart 8: PeriodicChargeAggregation.
Chart 9: Payment / 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.

OpenTerms syntax and semantic definitions, issue 02, 3 June 2016 Page 5
Chart 1: Terms / Company / Counterparty / Agreement / Products / Markets.

Chart 2: TransactionChargeSet.
Chart 3: PeriodicChargeSet (Main).

Chart 4: FeeSharePeriodicCharge.

Chart 5: VolumePeriodicCharge.

Chart 6: PerformancePeriodicCharge / FixedCharge.
Chart 7: PeriodicChargeHolding.

Chart 8: PeriodicChargeAggregation.

Chart 9: Payment / Report.

Part 3: Syntax rules listed in alphabetic order
Terms = Company, {Company}, Counterparty, {Counterparty}, Agreement, {Product}, {ProductExclusion}, {Market}, {MarketExclusion},
{TransactionChargeSet}, {PeriodicChargeSet}, {Payment}, {Report};
Affiliate = PartyIdentification, {PartyIdentification}, [AccessionDate, [SecessionDate]], [{ContactDetails}], [{PaymentDetails}];
Agreement = AgreementID, VersionNumber, [ExecutionDate], [LegalAspects], [TermAndTermination];
AgreementSectionCrossReference = TransactionChargeNumber | PeriodicChargeNumber;
ApplicableLawAndJurisdiction = Law, Jurisdiction;
ApplicableNAV = 'ReferHoldingCount' | 'ReferCalculationLookupFrequency' | 'Daily';1
AumLimit = AumLimit number, AumLimitType, AumLimitRow, {AumLimitRow};
AumLimitRow = AumLimitRow number, RateMethod, AumAmtFrom, AumAmtTo;
BeneficiaryCrossReference = PartyIdentification, [AllocationPercentage];
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}], [{PaymentDetails}];
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}],
[{PaymentDetails}];
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}, BeneficiaryCrossReference, {BeneficiaryCrossReference};
DecrementalTrade = 'TradeDate' | 'SettlementDate';7
DeMinimisCharge = Currency, Threshold;
DeMinimisPayment = Currency, Threshold;
DirectDebitDetails = [Reference], Currency, [Debtor], DebtorAccount, AgreementSectionCrossReference,
{AgreementSectionCrossReference};
EligiblePosition = IncrementalTrade, DecrementalTrade, [SpecialInstructions];
FeeSharePeriodicCharge = FeeSharePeriodicChargeCode | Proprietary, ReferenceCurrency, [IgnoreMarketFlag], [RateFormat], [RateType],
AumLimit, {AumLimit}, RateTable, {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' | 'WeekEnd' | ‘WeeklyAverage’ | 'MonthEnd' | ‘MonthlyAverage’ | 'QuarterEnd' | ‘QuarterlyAverage’ | 'HalfYearEnd' |
‘Half-YearlyAverage’ | 'YearEnd' | ‘YearlyAverage’ | 'WeekEndMean' | 'MonthEndMean' | 'QuarterEndMean' | 'HalfYearEndMean' |
'YearEndMean';10
HoldingValue = HoldingCount, ApplicableNAV;
IncrementalTrade = 'TradeDate' | 'SettlementDate';7
ISINAndDescription = ISIN, [Description];
Jurisdiction = Country, [Name];
LatePaymentPenalty = PenaltyRate, BaseRate;
LegalAspects = LegalTerms, {LegalVariation}, ApplicableLawAndJurisdiction, [MostFavouredTerms];
LookupFrequency = 'Daily' | 'Weekly' | 'Monthly' | 'Quarterly' | 'HalfYearly' | 'Yearly';11
Market = Country | Proprietary | URL;
MarketExclusion = Market;
OfferRights = OfferRightsAndDelegation | Proprietary | OfferRightsNarrative;
OfferRightsAndDelegation = OfferRightsCode, DelegationPermitted;
OfferRightsCode = 'PrivatePlacement' | 'PublicOffer' | 'PublicOfferAndPrivatePlacement' | 'None';12
OutPerformBenchmark = Description, [TickerIdentifier], CompareMethod;
PartialChargePeriodConvention = 'Long' | 'Short';13
PartyIdentification = AnyBIC | LEIIdentifier | ProprietaryID | NameAndAddress;
Payee = 'Company' | 'Counterparty';14
Payment = PaymentNumber, [PaymentName], PaymentInstrument, PaymentCurrency, BeneficiaryCrossReference,
AgreementSectionCrossReference, [SettlementWithin], [DeMinimisCharge], [DeMinimisPayment], [DeMinimisOption], [PaymentFlow];
PaymentCurrency = PaymentCurrencyBasis | Currency;
PaymentCurrencyBasis = 'BaseCurrency' | 'ShareClassCurrency' | 'MandateCurrency' | 'InvestmentCurrency';15
PaymentDetails = PaymentNumber;
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],
[CalendarStartDate], [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' | ‘Daily’;21
PeriodicChargeSet = PeriodicChargeSetNumber, [PeriodicChargeSetName], PeriodicCharge, {PeriodicCharge}, [NestedCharges],
[RetrospectiveAdjustmentDeadline], TerminationMode, BeneficiaryCrossReference;
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 = AumLimit number, AumLimitRow number, RateTableRow, {RateTableRow};
RateTableRow = RowNumber, RateAmtFrom, RateAmtTo, Rate;
Report = ReportNumber, ReportMethod, {ReportMethod}, AgreementSectionCrossReference, {AgreementSectionCrossReference},
[SpecialInstructions];
ReportMethod = PostalAddress | EmailAddress | FaxNumber | Other;
RetrospectiveAdjustmentDeadline = TimeLimitMonths | Other;
RunOff = RunOffPeriod, AdmitNewPositions;
RunOffPeriod = RunOffType, RunOffValue;
SettlementWithin = [TimeLimitBusinessDays | TimeLimitCalendarDays | Other], [LatePaymentPenalty], [ShiftDateOption];
SharedAccountHoldingUpdateFrequency = 'Daily' | 'Weekly' | 'Monthly' | 'Quarterly' | 'HalfYearly' | 'Yearly';27

ShiftDateOption = [‘DelayedPayment’ | ‘EarlyPayment’];28
Term = TerminationDate | FixedTermMonths | OpenFlag;
TermAndTermination = Term, TerminationNotice;
TermEndDate = Date | 'Open';
TerminationMode = TerminationType | RunOff;
TerminationNotice = Days | Months;
TerminationType = 'CoTerminusAgreement' | 'Survive';29
TermStartDate = Date | 'FirstInvestment';
TransactionCharge = TransactionChargeNumber, 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' | ‘Daily’ | ‘Ad Hoc’;30
TransactionChargeSet = TransactionChargeSetNumber, [TransactionChargeSetName], TransactionCharge, {TransactionCharge},
[RetrospectiveAdjustmentDeadline], BeneficiaryCrossReference;
TransactionChargeType = RateTransactionCharge | FixedCharge;
VolumePeriodicCharge = VolumePeriodicChargeCode | Proprietary, ReferenceCurrency, [IgnoreMarketFlag], [RateFormat], [RateType],
VolumePeriodicChargeCode = 'TrailerFee' | 'IntermediaryServiceFee' | 'ItalianSubjectInChargePlacementFee' | 'FranceCentralisingAgentFee'
| 'ManagementFee' | 'CustodyFee' | 'ReferralFee' | 'AdvisoryFee' | 'RealEstateFundFee' | 'LifeCompanyFee';31
YearDays = 'CalendarDays365' | 'CalendarDays366' | 'StandardYear360' | 'StandardYear365.25';32
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.

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
Daily Weekly Monthly Quarterly HalfYearly Yearly
CalculationFrequency
Daily 1 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:
2010 Month length Quarter length Half-year length Year length
January 4 weeks, starting on 4 January 2010
February 4 weeks
March 4 weeks Q1: 12 weeks
April 5 weeks
May 4 weeks
June 4 weeks Q2: 13 weeks H1: 25 weeks
July 5 weeks
August 4 weeks
September 5 weeks Q3: 14 weeks
October 4 weeks
November 4 weeks
December 5 weeks, ending on 2 January 2011 Q4: 13 weeks H2: 27 weeks Year: 52 weeks
HoldingValue
HoldingValue is the value of the ISIN at the HoldingAddress, which is used on the cth
calculation cycle in
the PeriodicChargePeriod. It is set by the following parameter in the relevant PeriodicCharge instruction:
PeriodicCharge → PeriodicChargeHolding → PeriodicChargeHoldingDetails → HoldingValue
(Note that HoldingValuec
is not necessarily the same as the value of the ISIN at the HoldingAddress on
the day that the cth
calculation cycle is run.)
PeriodicChargeBasisFactor
PeriodicChargeBasisFactor is a coefficient (of type ISO 20022 PercentageRate) that is set according to
the following conditions:
(1) If PeriodicCharge → PeriodicChargeType is a FeeSharePeriodicCharge then:
― if FeeSharePeriodicChargeCode = 'ManagementFee' then set the
PeriodicChargeBasisFactor to the Company's management fee applicable to the ISIN in the
relevant period.
― if FeeSharePeriodicChargeCode = 'DistributionFee' then set the PeriodicChargeBasisFactor
to the Company's distribution fee applicable to the ISIN in the relevant period.
― if FeeSharePeriodicChargeCode = 'Management+DistributionFee' then set the
PeriodicChargeBasisFactor to the sum of the Company's management fee and the
distribution fee applicable to the ISIN in the relevant period.
― if FeeSharePeriodicChargeCode = 'TotalExpenseRatio' then set the
PeriodicChargeBasisFactor to the average total expense ratio applicable to the ISIN in the
relevant period.
― If the FeeSharePeriodicCharge → Proprietary option is used then set the
PeriodicChargeBasisFactor to the sum of the Company's fees that the parties have

described, which were applicable to the ISIN in the relevant periodic charge period (and
which must be a percentage rate that can be applied in the periodic charge formula).
(2) If PeriodicCharge → PeriodicChargeType is a VolumePeriodicCharge then set the
PeriodicChargeBasisFactor to 100%.
Rate
Rate is set by the following parameters:
FeeSharePeriodicCharge → RateTable or VolumePeriodicCharge → RateTable (including all of its
terms)
PeriodicCharge → PeriodicChargeAggregation
If the RateTable is a "flat rate" table, it will contain only one Rate, which should be applied directly to the
periodic charge formula. In this case, the PeriodicCharge will contain no PeriodicChargeAggregation
term. In all other cases, the Rate is determined by reading the RateTable as a FlatBand or SlidingScale
table (see the definition of the rule RateTable) using the sum of the HoldingValues of the ISINs
referenced by PeriodicChargeAggregation. The Rate should then be determined at the
LookupFrequency or, if it is not defined, at the CalculationFrequency.
DayCount
DayCount is the number of days in the calculation cycle (not in the PeriodicChargePeriod). It is set by
the following parameters in the relevant PeriodicCharge and the following table:
PeriodicCharge → PeriodDays
PeriodicCharge → CalculationFrequency
PeriodDays
CalendarDays365 CalendarDays366 StandardYear360
Daily
Count every calendar day
in the periodic charge calculation
cycle,
except 29 February
cycle,
including 29 February
Invalid
Weekly
Monthly 30
Quarterly 90
Half-Yearly 180
Yearly 360
YearDays
YearDays is set by the following parameter in the relevant PeriodicCharge and the following table (see
also the definition of the rule YearDays):
PeriodicCharge → YearDays
YearDays
CalendarDays365 CalendarDays366 StandardYear360 StandardYear365.25

in the year,
except 29 February
in the year,
360 365.25

Part 5: Cash flow adjustments for segregated mandates
Some segregated mandates are charged on the basis of the period-end market valuation of the client's
investments (typically a quarter-end valuation). These charging schemes adjust the period-end valuation
for cash movements (capital flows) instructed by the client during the period, to ensure that the charges
are fair to the client and the manager.
There are two cash flow adjustment methods for calculating period-end charges: the "straight" and the
"backward" method.
The straight method takes account of cash flows to calculate the weighted average adjusted assets
under management during a period, to which the agreed rate table is applied to calculate the charges.
The backward method takes account of cash flows to calculate the adjusted assets under management
during each discrete time interval between cash flows during the charging period, and the agreed rate
table is applied to each interval to calculate the charges. Cash flow adjustments may be subject to
threshold criteria, to ensure that adjustments are not made for immaterial amounts.
Straight method
The value of a periodic charge is determined by the formula:
Value of periodic charge = (
1
PeriodDays
∑ AUMi × Daysi
n
i=1
) × Rate ×
DayCount
YearDays
Where:
PeriodDays = PeriodicCharge → PeriodDays.
n = number of discrete time intervals in the charging period delineated by cash flow events, (e.g.,
two cash flow events means three intervals). Interval 1 is the interval in which the last day of the
charging period falls.
AUMi = the value of assets under management during interval i, meaning the market value of
assets under management at close of business on the last day of the charging period, adjusted up
for cash outflows and down for cash inflows in any interval following interval i. (Take care with
direction: the adjustment works backwards from the last day in the charging period and cash flow
effects appear inverted. See example below.)
Daysi = the number of calendar days duration of interval i (and the sum of all such days during all
intervals i=1..n is equal to PeriodDays). Each interval starts on the day of the cash flow.
Example for the terms in parentheses above:
An account has a value of 12.8 million at the close of business on 31 December. The
client withdrew 3 million on 3 December and paid in 5 million on 5 October. The billing
period runs from 1 October to 31 December inclusive.
Interval "i" Ending Starting AUMi Comment Daysi
1 31 December 3 December 12.8 million 3 million outflow on 3 December 29
2 2 December 5 October 15.8 million 5 million inflow on 5 October 59
3 4 October 1 October 10.8 million 4

Therefore, the value of the terms in parentheses = 1/92 × (12.8 × 29 + 15.8 × 59 + 10.8
× 4) = 14.63695652 million.
Rate is set by the function to its left according to the following parameters:
VolumePeriodicCharge → RateTable (including all of its terms)
If the RateTable is a "flat rate" table, it will contain only one Rate, in which case, the
PeriodicCharge will contain no PeriodicChargeAggregation term. In all other cases, the Rate
is determined by reading the RateTable as a FlatBand or SlidingScale table (see the
definition of the rule RateTable) using the value of AUMi. The Rate should be determined
only once, for the entire charging period.
DayCount and YearDays: see below.
Backward method
The value of a periodic charge is determined by the formula:
Value of periodic charge =
1
PeriodDays
∑ (AUMi × 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)
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
Daily
cycle,
except 29 February
cycle,
Invalid
Weekly
Monthly 30
Quarterly 90
Half-Yearly 180
Yearly 360
YearDays
YearDays is set by the following parameter in the relevant PeriodicCharge and the following table (see
also the definition of the rule YearDays):
PeriodicCharge → YearDays
(See table on next page.)
YearDays
CalendarDays365 CalendarDays366 StandardYear360 StandardYear365.25
in the year,
except 29 February
in the year,
360 365.25

Part 6: Syntax semantic definitions
Rule
Terms = Company, {Company}, Counterparty, {Counterparty}, [Agreement], {Product}, {ProductExclusion}, {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 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).
A TransactionCharge or PeriodicCharge (both of which are defined later in this document) might refer to products that are not members of
the set of Products defined by this top-level Terms rule. That is because the products might be related to another agreement between the
parties or to another agreement between the Company and another member of the Counterparty's group or possibly vice versa. In that case,
the Counterparty will have the right to have holdings in the related products taken into account when determining the transaction charge and
period charge rates but it will have no other rights over them under the terms of the agreement (e.g., in the case of pooled funds it will have
no right to distribute them).
TransactionChargeSet and PeriodicChargeSet are optional because it is possible that some agreements are made on terms that do not
require these payments to be made. Payment and Report are optional because, (i) if no transaction charges or periodic charges are defined,
no payments or reports will be necessary and (2) some parties prefer to maintain such details separately.

Rule
Affiliate = PartyIdentification, {PartyIdentification}, [AccessionDate, [SecessionDate]], [{ContactDetails}], [{PaymentDetails}];
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.
PaymentDetails Bank details used to send payments to the affiliate.
PartyIdentification: Defined in this document.
AccessionDate: ISO 20022 ISODate
SecessionDate: ISO 20222 ISODate
ContactDetails: Defined in this document.
PaymentDetails: Defined in this document.
User guide
PartyIdentification may be given in more than one form, e.g., BIC and/or LEI and or a proprietary identifier and/or a name and address provided
that each form given refers to the same unique affiliate.
AccessionDate and SecessionDate should be provided if they are known.

Rule
Agreement = AgreementID, VersionNumber, [ExecutionDate], [LegalAspects], [TermAndTermination];
Synopsis
The heads of the legal Agreement comprise the following elements:
AgreementID A text reference that the parties agree to assign to the agreement to aid their communication about the agreement.
VersionNumber A number to discriminate this agreement from any others that the parties might have made under the same
reference.
ExecutionDate The date upon which this version of the agreement was executed.
LegalAspects The clauses, variations, law and jurisdiction that are the legal foundation of the agreement.
TermAndTermination The term of the agreement and any applicable termination notice periods.
AgreementID: ISO 20022 Max35Text.
VersionNumber: ISO 20022 Max35Text.
ExecutionDate: ISO 20022 ISODate.
LegalAspects: Defined in this document.
TermAndTermination: Defined in this document.
User guide
If the parties wish to track their business through order routing systems, they may ensure their anonymity (whilst preserving a unique
identifier) by concatenating the AgreementID and VersionNumber values into a text string and transforming it using a suitable one-way
hashing function, and using the hash digest as the tracking number.
A VersionNumber may be assigned to an agreement only once; it may never be reused. It may, however, be cited any number of times in
correspondence about the agreement to which it refers.
Rule
AgreementSectionCrossReference = TransactionChargeNumber | PeriodicChargeNumber;
Synopsis
Defines the relationship between a payment mandate and the charge mandates (e.g., one or several TransactionCharges and/or
PeriodicCharges) of the agreement.
TransactionChargeNumber: ISO 20022 Max3NumberNonZero, > 0.
PeriodicChargeNumber: ISO 20022 Max3NumberNonZero, > 0.
User guide
Every payment mandate must refer to at least one charge mandate and every charge mandate must appear in at least one payment
mandate. A payment mandate may refer to more than one charge mandate where the parties wish to settle through a single account.
Several payment mandates may refer to the same charge mandate where the parties wish to settle in more than one currency.
Rule
ApplicableLawAndJurisdiction = Law, Jurisdiction;
Synopsis
The law applicable to the agreement and the courts of the jurisdiction to which the parties will submit.
Law: ISO 20022 CountryCode
Jurisdiction: Defined in this document.
User guide
Jurisdiction may be used to describe the national jurisdiction and the courts within it, which may be a state within a federal system or some
other tribunal or arbitration venue that the parties agree to use.

Rule
ApplicableNAV = 'ReferHoldingCount' | 'ReferCalculationLookupFrequency' | 'Daily';
Synopsis
Describes how to determine the net asset value per share (NAV) with which to calculate a HoldingValue.
ReferHoldingCount: Use the NAV that is applicable when the HoldingCount is measured.
ReferCalculationLookupFrequency: Use the NAV that is applicable on the calculation day.
Daily: Use every available NAV.
ApplicableNAV is an enumerated type implemented as the following four-letter codes:
'RECF' | 'DAIL' | 'REHC'.
User guide
Refer to the rule HoldingValue.
Rule
AumLimit = AumLimit number, AumLimitType, AumLimitRow, {AumLimitRow};
Synopsis
Determine:
AumLimitNumber A unique identifier that allows easy reference to objects of this type in an agreement.
AumLimitType Defines if the agreement is composed of a single flat rate, a single rate table, or multiple rate tables.
AumLimitRow One or more rows containing the rate method and the holding values for which the rate
table is valid.
AumLimitNumber: ISO 20022 Max3NumberNonZero, > 0.
AumLimitType AumLimitType is an enumerated type implemented as the following four-letter codes:
'FLAT' | 'SIRT' | 'MURT'.
AumLimitRow: Defined in this document.
User guide
The AuM limit table applies Holding restrictions to a given rate table.
For generic scenarios where only one single rate table is required, the AUm limit doesn’t apply any restriction.
For cases where multiple rate table are required, the AuM limit table defines a holding range for which the rate table is applicable.
For further details on what the AuM limit table holds, please refer to the AumLimitRow specifications.
Three types should be available for AuM Limits:
‘FLAT’ – Flat rate fee schedule - no AuM Limit need to be setup.
‘SIRT’ – Single Rate table – no AuM Limit need to be setup.
‘MURT’ – Multiple Rate Table – AuM Limit need to be setup.
Rule
AumLimitRow = AumLimitRow number, RateMethod, AumAmtFrom, AumAmtTo;

Synopsis
Determine:
AumLimitRowNumber A unique identifier that allows easy reference to objects of this type in an agreement.
RateMethod Whether the row describes a FlatBand or SlidingScale rate.
AumAmtFrom Minimum holding amount for which the rate table is valid.
AumAmtTo Maximum holding amount for which the rate table is valid.
AumLimitRowNumber: ISO 20022 Max3NumberNonZero, > 0.
RateMethod: RateMethod is an enumerated type implemented as the following four-letter codes:
'FBND' | 'VWAR'.
AumAmtFrom: ISO 20022 Number, >= 0; > AumAmtTo of AumLimitRow n-1.
AumAmtTo: ISO 20022 Number, > 0; < AumAmtFrom of AumLimitRow n+1. .
User guide
Each row of the AuM Limit table can have a specific rate method. The table then allows to combine rate methods within the same periodic
charge.
Each row should explicitly be defined by a minimum and maximum holding amount.
The minimum amount of the first row is always zero.
The maximum amount of the last row is always the maximum amount allowed by the application.
The minimum amount of each subsequent AumLimitRow n is AumAmtFromn-1 + 0.01.
Ex:
Row
Number
RateMethod AumAmtFrom AumAmtTo
1 FBND 0 4,999,999.99
2 FBND 5,000,000.00 14,999,999.99
3 VWAR 15,000,000.00 999,999,999,999.99

Rule
BeneficiaryCrossReference = PartyIdentification, [AllocationPercentage];
Synopsis
Defines the relationship between the charge mandates (e.g., one or several TransactionCharges and/or PeriodicCharges) of the agreement, and
the payable entity.
Quite often, the counterparty used for payment is the same one used for charge calculation. It can however happen that a portion or the entire
charge calculated for a given counterparty is paid to a different entity.
It can also happen that the payable and calculation counterparties are one and the same, but the counterparty may decide to split the payments
among its affiliates, or split the payment through various different channels (part paid in cash, part reinvested in shares,etc …)
AllocationPercentage: ISO 20022 PercentageRate, > 0.
User guide
The BeneficiaryCrossReference can be any entity linked to the agreement, whether it is a Company, a Counterparty, or an Affiliate. The only
condition is that the entity is somehow connected to the term.
There can be only one BeneficiaryCrossReference for each charge calculated. (TransactionCharge or PeriodicCharge).
The AllocationPercentage defines what portion of the fee can be paid to the entity listed as Beneficiary. In that sense, it is possible to have
several similar charges, with the same products / holdings / rates, as part of one single agreement. There can however be only one single
Beneficiary per charge number.
If AllocationPercentage is not defined, then it is equal to 100.00%.
Rule
CalculationFrequency = 'Daily' | 'Weekly' | 'Monthly' | 'Quarterly' | 'HalfYearly' | 'Yearly';
Synopsis
Determines the frequency with which the periodic charges are calculated.
CalculationFrequency is an enumerated type implemented as the following four-letter codes:
'DAIL' | 'WEEK' | 'MNTH' | 'QUTR' | 'SEMI' | 'YEAR'.
User guide
Not defined.

Rule
CashFlow = CashFlowType, [CashFlowThresholdRelative], [CashFlowThresholdAbsolute];
Synopsis
Prepare a PeriodicCharge using a cash flow adjusted valuation:
CashFlowType Use a straight or backward cash flow adjustment method.
CashFlowThresholdRelative Cash flow adjustment is to be applied only if the cash flow in the period exceeds the value of the
relevant
portfolio measured at the start of the PeriodicChargePeriod.
CashFlowThresholdAbsolute Cash flow adjustment is to be applied if the cash flow in the period exceeds this absolute measure
during
the PeriodicChargePeriod.
CashFlowType: Defined in this document.
CashFlowThresholdRelative: ISO 20022 PercentageRate, > 0.
CashFlowThresholdAbsolute: Defined in this document.
User guide
If neither CashFlowThresholdRelative nor CashFlowThresholdAbsolute are defined then CashFlow must be applied.
If CashFlowThresholdRelative is defined then CashFlow should not be applied unless the cash movement for the HoldingAddress in the
PeriodicChargePeriod expressed as a percentage of the value of the assets at the HoldingAddress measured at the start of the
PeriodicChargePeriod exceeds the threshold.
If CashFlowThresholdAbsolute is defined then CashFlow should not be applied unless the cash movement for the HoldingAddress in the
PeriodicChargePeriod exceeds the amount stated.
If CashFlowThresholdRelative and CashflowThresholdAbsolute are silmultaneously defined then CashFlow should not be applied unless
both of the thresholds are exceeded (i.e., a logical AND test).
Rule
CashFlowThresholdAbsolute = Amount, Currency;
Synopsis
Set a threshold for the application of a cash flow adjustment method by reference to an amount and a currency.
Amount: ISO 20022 Number, > 0.
Currency: ISO 20022 CurrencyCode.
User guide
See rule CashFlow.
Rule
CashFlowType = 'Straight' | 'Backward';
Synopsis
Determine whether a cash flow adjustment is to be calculated using the straight or the backward method.
CashFlowType is an enumerated type implemented as the following four-letter codes:
'STRT' | 'BKWD'.
User guide
See Part 5 of this document.

Rule
ChequeDetails = [Reference], Currency, PayeeID, AgreementSectionCrossReference, {AgreementSectionCrossReference};
Synopsis
Charges will be paid by one or more cheques using the following information:
Reference The reference that the parties have agreed to attach to the advice note covering each cheque.
Currency The currency in which the cheque is to be issued.
PayeeID The party to whom the cheque will be payable.
AgreementSectionCrossReference References to the charge mandates for which this cheque mandate is to be used.
Reference: ISO 20022 Max35Text.
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}], [{PaymentDetails}];
Synopsis
Define the name and address of the Company and its contact and payment details.
CompanyCapacity: Defined in this document.
User guide
PartyIdentification may be given in more than one form, e.g., BIC and/or LEI and or a proprietary identifier and/or a name and address
provided that each form given refers to the same unique Company.
When more than one member of the Company group is a party to the agreement, CompanyCapacity may be used to indicate the capacity in
which each member of Company group is acting. For example, it may be acting as management company to certain funds or as the legal
representative in a certain jurisdiction.

Rule
CompanyCapacity = CompanyCapacityCode | Proprietary;
Synopsis
A Company's capacity may be defined by a pre-defined capacity code or by a proprietary capacity code.
CompanyCapacityCode: Defined in this document.
Proprietary: ISO 20022 GenericIdentification30.
User guide
CompanyCapacityCode provides a set of common pre-defined capacities in which Company may act. The term "Proprietary" enables the
parties to use an alternative code (alphanumeric, exactly 4 characters long) provided that they agree what it is and who issued it. For
example, if the message is being used in the context where Company is a platform and Counterparty is a participating member, the parties
may agree proprietary capacity codes that are suitable for their purposes. The meaning of these codes would be defined by the proprietary
code issuer.
Rule
CompanyCapacityCode = 'LegalRepresentative' | 'ManagementCompany' | 'GlobalDistributor' | 'Platform';
Synopsis
The company may be acting in the capacity of:
LegalRepresentative The legal representative in a jurisdiction of some or all of the products covered by the agreement.
ManagemementCompany The appointed management company to some or all of the products covered by the agreement.
GlobalDistributor The global distributor of some or all of the products covered by the agreement.
Platform A party providing administration and execution services to sales agents and/or intermediaries.
CompanyCapacityCode is an enumerated type implemented as the following four-letter codes:
'LREP' | 'MGCY' | 'GLDR' | 'PLFM'.
User guide
Company may be defined as one or more entities which promote or distribute a fund range or manage a segregated mandate. For example,
it may be common for three Company entities to be party to an agreement:
Entity 1: a fund's management company, which has the responsibility for the commercialisation of a fund under home state law.
Entity 2: a fund's legal representative in a host state (for example, the legal representative for a foreign fund that is being sold in
Switzerland).
Entity 3: a fund's global distributor, which may be different from its management company, and which may be responsible for granting and
managing commercial rights to distribute the fund in several countries around the world.
In the event that an entity performs more than one role (for example, management company and global distributor), the Company should
select the role that it considers to be the most significant (typically the management company).
These capacity descriptions are intended to be generally accepted industry roles. They are not meant to be precise legal definitions. If
general roles would be unsatisfactory or if the parties want more definition than is provided by this rule, they may adopt proprietary capacity
codes with attendant definitions in as much detail as they wish (see the rule CompanyCapacity → Proprietary).

Rule
CompareMethod = 'Arithmetic' | 'Geometric';
Synopsis
Describes how the outperformance of a portfolio is calculated with respect to the benchmark:
Arithmetic Calculate arithmetically.
Geometric Calculate geometrically.
CompareMethod is an enumerated type implemented as the following four-letter codes:
'ARIT' | 'GEOM'.
User guide
Outperformance is the amount by which a portfolio return exceeds the benchmark return, usually expressed as a percentage. It can be
calculated arithmetically or geometrically. Example:
Portfolio return: 10% Benchmark return: 5%
Arithmetic outperformance = 10% - 5% = 5%
Geometric outperformance = (1+10%) ÷ (1+5%) - 1 = 4.8%
Rule
ContactDetails = Name, [Title], [GivenName], [Role], [{PhoneNumber}], [{FaxNumber}], [{EmailAddress}], [SpecialInstructions];
Synopsis
Name of a person or department and communication address at which any entity listed in the agreement (Company, Counterparty,Affiliate) can
be contacted.
Name The name of the person or the department.
Title If a person, their title (e.g., Mr, Mrs, Ms, Doctor).
GivenName If a person, their given name or the name by which they are known.
Role If a person, their role.
PhoneNumber The telephone number to be used for contact.
FaxNumber The facsimile number to be used for contact.
EmailAddress The email address to be used for contact.
SpecialInstructions Any special instructions to be used when making contact.
Name ISO 20022 Max70Text.
Title ISO 20022 Max70Text.
GivenName ISO 20022 Max70Text.
Role ISO 20022 Max70Text.
PhoneNumber ISO 20022 PhoneNumber.
FaxNumber ISO 20022 PhoneNumber.
EmailAddress ISO 20022 Max256Text.
SpecialInstructions ISO 20022 Max2000Text.
User guide
Contact details can be provided for each entity playing a role in the agreement (Company, Counterparty, Affiliates). Each entity can have one or
multiple contact persons. Each contact person can be assigned one or multiple phone / fax / email details.

Rule
Counterparty = PartyIdentification, {PartyIdentification}, [OfferRights], [CounterpartyCapacity], [{Affiliate}], [{ContactDetails}],
[{PaymentDetails}];
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. Also define the payment details attached to the Counterparty.
OfferRights: Defined in this document.
CounterpartyCapacity: Defined in this document.
Affiliate: Same as PartyIdentification, 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.
Rule
CounterpartyCapacityCode = 'Platform' | 'Distributor' | 'IntroducingAgent' | 'ProductPackager' | 'InstitutionalInvestor' | 'PlacementAgent' |
'CentralisingAgent';
Synopsis
The Counterparty may be acting in the capacity of:
Platform A party providing administration and execution services to sales agents and/or intermediaries.
Distributor An intermediary distributing shares to underlying investors or executing orders as global custodian.
IntroducingAgent An introducing agent.
ProductPackager A product packager, such as a life company or a structured product manufacturer.
InstitutionalInvestor An institutional investor, investing for its own account.
CounterpartyCapacityCode is an enumerated type implemented as the following four-letter codes:
'PLFM' | 'DIST' | 'INAG' | 'PKGR' | 'INIV' | 'PLMA' | 'CENA'.
User guide
Counterparty should select the role that it considers to be most representative of the capacity in which it will act.
These capacity descriptions are intended to be generally accepted industry roles. They are not meant to be precise legal defintions. If
general roles would be unsatisfactory or if the parties want more definition than is provided by this rule, they may adopt proprietary capacity
codes with attendant definitions in as much detail as they wish (see the rule CounterpartyCapacity → Proprietary).

Rule
CreditTransferDetails = [Reference], Currency, [IntermediaryAgent1], [IntermediaryAgent1Account], [IntermediaryAgent2],
[IntermediaryAgent2Account], [CreditorAgent], [CreditorAgentAccount], [Creditor], [CreditorAccount], AgreementSectionCrossReference,
{AgreementSectionCrossReference}, BeneficiaryCrossReference, {BeneficiaryCrossReference};
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.
BeneficiaryCrossReference Cross references to the related Beneficiary entity.
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.
BeneficiaryCrossReference Defined in this document.
User guide
This rule defines the creditor side of a payment chain.
AgreementSectionCrossReferences define the relationship between a credit transfer mandate and the charge-earning mandates (e.g., one or
several TransactionCharges and PeriodicCharges) of the agreement.
AgreementSectionCrossReferences are not intended to be quoted directly within a SWIFT credit transfer message but they may be quoted in the
charge statements and reports that are transmitted between the parties to an agreement. If the parties wish to agree to use operational
references in their SWIFT payment messages to help trace the payment to the agreement and the underlying TransactionCharges and/or
PeriodicCharges, they should define them in Reference. Parties who wish to use Reference in SWIFT FIN messages should limit the length of
the field to 16 characters. Parties should also take care to ensure that the destination system that will process the message payload is capable
of handling the character set used within the message. For example, many systems need special configuration to support character sets other
than Latin-1.
Payments could be made through several mandates according to the parties' preferences for arranging their business functionally,
geographically or by product, or to keep periodic charges separate from transaction charges, or for any other reason that the parties choose.

Rule
DecrementalTrade = 'TradeDate' | 'SettlementDate';
Synopsis
Determine how decremental trades (i.e., redemptions, switches out and transfers out) are measured for PeriodicChargeHolding and
PeriodicChargeHoldingAggregation purposes:
TradeDate The trade is effective from the trade date.
SettlementDate The trade is effective from the settlement date.
DecrementalTrade is an enumerated type implemented as the following four-letter codes:
'TRAD' | 'SETT'.
User guide
See also the rule EligiblePosition.
Rule
DeMinimisCharge = Currency, Threshold;
Synopsis
Determine the minimum threshold at which charges will be applied under the agreement:
Currency Charges might be in several currencies and must be converted to a single currency to perform the test.
Threshold The threshold value to be used in the test.
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.
Threshold: ISO 20022 Number, > 0.
For pooled funds, DeMinimisCharge → Threshold <= DeMinimisPayment → Threshold.
User guide
DeMinimisPayment is used to ensure that payments are generally made for commercially sensible amounts, equal to or greater than a
threshold that is set by the parties to the agreement. The test is to be applied on the aggregate (i.e., total) amount payable.
Note that we do not apply the previous rule, DeMinimisCharge, to transaction charges because they are automatically deducted at the time
of each transaction. However, we do apply the rule DeMinimisPayment because payment amounts might fall below a commercially
reasonable level.
Rule
DirectDebitDetails = [Reference], Currency, [Debtor], DebtorAccount, AgreementSectionCrossReference,
{AgreementSectionCrossReference};
Synopsis
Describes the debtor's bank account from which the creditor can directly debit the charges due under the terms of the agreement:
Reference An operational reference that the parties have agreed to attach to each payment.
Currency The currency of the DebtorAccount.
Debtor The debtor's identity.
DebtorAccount The debtor's account.
AgreementSectionCrossReference Cross references to the related transaction charge and periodic charge mandates.
Reference ISO 20022 Max35Text.
Currency ISO 20022 CurrencyCode.
Debtor PartyIdentification, defined in this document.
DebtorAccount ISO 20022 AccountIdentificationAndName3.
AgreementSectionCrossReference Defined in this document.
User guide
Not defined

Rule
EligiblePosition = IncrementalTrade, DecrementalTrade, [SpecialInstructions];
Synopsis
Determine a convention for measuring positions with respect to trade date or settlement date, and whether to include or exclude certain
positions from a charge calculation:
IncrementalTrade Trades that increase the Counterparty's positions (subscriptions, switches in, transfers in).
DecrementalTrade Trades that decrease the Counterparty's positions (redemptions, switches out, transfers out).
SpecialInstructions Instructions to include or exclude certain positions.
IncrementalTrade: Defined in this document.
DecrementalTrade: Defined in this document.
SpecialInstructions: ISO 20022 Max2000Text.
User guide
The parties should set the trade date and settlement date parameters consistently for all trades that increase the Counterparty's position and
for all trades that decrease the Counterparty's position. Therefore, these are the possible combinations for incremental and decremental
trades:
IncrementalTrade: TRAD TRAD SETT SETT
DecrementalTrade: TRAD SETT TRAD SETT
For the purposes of this rule the German concept of "valuta" is considered to be equivalent to 'SETT'.
The SpecialInstructions field may be used to include or exclude certain positions when calculating periodic charges. For example:
(1) When transferring accounts from one or more central transfer agents onto a consolidating platform, positions that existed before the
consolidation date can be identified and treated separately.
(2) If a promoter / fund manager wishes to make a special promotion, in which the special rate persists for assets that are raised during the
promotional period, the positions can be identified and treated separately.
The ability to identify positions with respect to time is a function of the system in which the shares are registered (not every system can do it).
The SpecialInstructions free text field provides the flexibility to identify positions in a way that is compatible with the underlying system.

Rule
FeeSharePeriodicCharge = FeeSharePeriodicChargeCode | Proprietary, ReferenceCurrency, [IgnoreMarketFlag], [RateFormat], [RateType],
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.
ReferenceCurrency Reference currency for the periodic charge.
IgnoreMarketFlag Flag that determines whether the charge takes ignores market fluctuations or not.
RateFormat If the rate is expressed as a Basis point or a percentage.
RateType If the rate is referring to the portion kept by the Company, or paid to the Counterparty.
AumLimit The Assets under Management range for which the rate table is applicable.
RateTable The rate at which the periodic charge should be applied.
LookupFrequency How often the rate should be looked up.
FeeSharePeriodicChargeCode: Defined in this document.
ReferenceCurrency: ISO 20022 CurrencyCode.
IgnoreMarketFlag: ISO 20022 YesNoIndicator
RateFormat: RateFormat is an enumerated type implemented as the following three-letter codes:
'BPS' | 'PCT'.
RateType: RateType is an enumerated type implemented as the following three-letter codes:
'RET' | 'PAY'.
AumLimit: Defined in this document.
RateTable: Defined in this document.
LookupFrequency: Defined in this document.
User guide
Rates can be setup in basis points or percentage for both volume periodic charges and fee share periodic charges. The rate format will describe
the precision of the rate. That allows to avoid any interpretation or conversion of any kind when setting up a new term.
Rates can be of 2 types, payable or retain.
Payable means that the rate set in the rate table represents what will be paid to the Beneficiary.
Retain means that the rate set in the rate table represents what will be kept by the Company.
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 IgnoreMarketFlag is not defined then it is equal to ‘N’.
If RateFormat is not defined then it is equal to ‘BPS’.
If RateType is not defined then it is equal to ‘PAY’.
If LookupFrequency is not defined then it is equal to CalculationFrequency.
The IgnoreMarketFlag indicates that the NAV and FX fluctuations should be ignored for the determination of the charge rate. The rate is applied
based on the initial price for the period.

Rule
FeeSharePeriodicChargeCode = 'ManagementFee' | 'DistributionFee' | 'Management+DistributionFee' | 'TotalExpenseRatio' |
'OngoingCharge' | 'TotalExpenseRatioCap' | 'OngoingChargeCap';
Synopsis
A fee share periodic charge is based upon the rate of a fund's management fee, the distribution fee, the sum of the two, the fund's total
expense ratio (TER), the ongoing charge (OGC), a total expense ratio cap or an ongoing charge cap.
FeeSharePeriodicChargeCode is an enumerated type implemented as the following four-letter codes:
'MANF' | ''DISF' | 'MADF' | 'TERF' | 'OGCF' | 'TERC' | 'OGCC'.
User guide
FeeSharePeriodicChargeCode is intended for use in pooled funds, which publish the relevant rates in their prospectuses or their financial
reports.
The fund's total expense ratio will be calculated according to the methodology used by the fund's management company. Counterparty
should inform itself of that methodology before using that option. The fund's ongoing charge will be calculated according to the methodology
imposed upon the fund by its home state regulations governing the calculation of ongoing charges for use in point-of-sales materials (e.g.,
key information documents in the European Union).
TotalExpenseRatioCap and OngoingChargeCap differ from the other types of this charge in that the charge payable is the monetary value of
the TER or OCG (calculated monthly using unaudited data) in excess of the TER or OGC cap described in the rate table. See also rule
RateTableRow.
Rule
FixedCharge = FixedChargeType, Amount, Currency;
Synopsis
A PeriodicCharge or a TransactionCharge may be a fixed amount:
FixedChargeType The description of the charge.
Amount The financial amount of the charge.
Currency The currency in which Amount is expressed.
FixedChargeType: Defined in this document.
Amount: ISO 20222 Number, > 0.
User guide
Not defined.
Rule
FixedChargeType = FixedChargeDescription | FixedChargeCode | Proprietary;
Synopsis
A fixed charge may be described using a text description, a standard charge code or a proprietary charge code.
FixedChargeDescription: ISO 20022 Max2000Text.
FixedChargeCode: Defined in this document.
User guide
Standard charge codes are defined by FixedChargeCode. New codes can be defined as proprietary codes provided that the parties to the
agreement agree upon their definition.

Rule
FixedChargeCode = 'BenchmarkChange' | 'MinimumPeriodicChargeAmount';
Synopsis
Fixed charges may be applied for the following reasons:
BenchmarkChange When the parties to the agreement change the benchmark that they use to measure the
performance of a Product.
MinimumPeriodicChargeAmount To ensure that the PeriodicCharges applicable in a PeriodicChargePeriod are not less than a
defined amount.
FixedChargeCode is an enumerated type implemented as the following four-letter codes:
'BMCH' | 'MPCA'.
User guide
A BenchmarkChange charge is the fixed charge applicable when the Counterparty requests the Company to change the benchmark that is
used to measure the performance of a product, whether or not the benchmark is used in a performance fee. The charge is applied to each
product; for example, five products measured to a common benchmark 'A' will give rise to five fixed charges when they change to a common
benchmark 'B'.
A MinimiumPeriodicChargeAmount is the total PeriodicCharge that shall be applied in the event that the sum of all PeriodicCharges
(excluding PerformanceBasedCharges) calculated in a PeriodicChargePeriod are less than the MinimiumPeriodicChargeAmount.
Rule
HoldingAddress = HoldingAddressType, HoldingAddressNumber, SharedAccount, [SharedAccountHoldingUpdateFrequency],
[EligiblePosition];
Synopsis
Describe the addresses at which the Counterparty's investments are held:
HoldingAddressType The address refers to a holding at a transfer agency or a custodian or an internal accounting
system
or at Clearstream, Euroclear or FundSettle.
HoldingAddressNumber The address number.
SharedAccount The HoldingAddressType is an account-level address type and the account is shared with one
or more other beneficial owners.
SharedAccountHoldingUpdateFrequency The frequency at which the Counterparty's interest in a shared account will be analysed.
EligiblePosition Positions are to be measured by trade date or settlement date and optionally included or
excluded.
HoldingAddressType: Defined in this document.
HoldingAddressNumber: ISO 20022 Max35Text.
SharedAccount: ISO 20022 YesNoIndicator.
SharedAccountHoldingUpdateFrequency: Defined in this document.
EligiblePosition: Defined in this document.
SharedAccountHoldingUpdateFrequency must only be used if SharedAccountFlag is set to 'Yes' or 'True'.
User guide
Some parties prefer explicitly to define the SharedAccountHoldingUpdateFrequency for shared accounts, but it is not compulsory and charge
calculation agents will infer a frequency from HoldingValue. Shared accounts are not normally analysed more frequently than monthly.
In some circumstances, the Counterparty may wish to include in the agreement an iCSD account number (e.g., Clearstream or Euroclear)
whereas the Company's charge calculation agent may need to know the agent code that will be issued by the Company's transfer agent.
Both are valid HoldingAddresses, although they point to the same holdings. It is acceptable to include both in the agreement provided that
the charge calculation agent ensures that the holdings are not double-counted when calculating charges.

Rule
HoldingAddressType = HoldingAddressPath | Platform;
Synopsis
For each HoldingAddressNumber, the parties must say which organisation issued the number and, if it is a proprietary system, at which level
in the system the number is meaningful.
HoldingAddressPath: ISO 20022 Max350Text.
Platform: Defined in this document.
User guide
HoldingAddressPath is a string capable of addressing a specific transfer agency, global custodian, fund platform, etc., and the level in that
agent's system at which the HoldingAddressNumber is meaningful. It does not require the syntax to know anything about the agent's identity
or system design (for example, whether it defines objects such as investor identifiers, account numbers, agent codes, plan numbers, etc), but
the parties must agree to use a meaningful string. We recommend that the parties adopt a "dotted" notation in the form
"organisation.domicile.system_level" such as this:
"schroders.luxembourg.agentcode" HoldingAddressNumber is an agent code at Schroders' transfer agent in Luxembourg
"schroders.luxembourg.account" HoldingAddressNumber is an account number at Schroders' transfer agent in Luxembourg
"schroders.hongkong.agentcode" HoldingAddressNumber is an agent code at Schroders' transfer agent in Hong Kong
"ifds.uk.agentcode" HoldingAddressNumber is an agent code at IFDS' transfer agent in the UK
Rule
HoldingCount = 'Daily' | 'WeekEnd' | ‘WeeklyAverage’ | 'MonthEnd' | ‘MonthlyAverage’ | 'QuarterEnd' | ‘QuarterlyAverage’ | 'HalfYearEnd' | ‘Half-
YearlyAverage’ | 'YearEnd' | ‘YearlyAverage’ | '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.
WeekEnd On the last day of a calendar week (Sunday).
MonthEnd On the last day of a calendar month (31 January, 28/29 February, 31 March, 30 April, etc).
QuarterEnd On the last day of a calendar quarter (31 March, 30 June, 30 September, 31 December).
HalfYearEnd On the last day of a calendar half-year (30 June, 31 December).
YearEnd On the last day of a calendar year (31 December).
WeeklyAverage Weekly average of daily values calculated on the last day of a calendar week (Sunday).
MonthlyAverage Monthly average of daily values calculated on the last day of a calendar month (01 Jan – 31 Jan)
QuarterlyAverage Quarterly average of daily values calculated on the last day of a quarter (01 Jan– 31 Mar)
HalfYearlyAverage Half-Yearly average of daily values calculated on the last day of a Half-Year (01 Jan– 30 Jun)
YearlyAverage Yearly average of daily values calculated on the last day of a Year (01 Jan– 31 Dec)
WeekEndMean The arithmetic mean of the last day of a calendar week and the last day of the prior calendar week.
MonthEndMean The arithmetic mean of the last day of a calendar month and the last day of the prior calendar month.
QuarterEndMean The arithmetic mean of the last day of a calendar quarter and the last day of the prior calendar quarter.
HalfYearEndMean The arithmetic mean of the last day of a calendar half-year and the last day of the prior calendar half-year.
YearEndMean The arithmetic mean of the last day of a calendar year and the last day of the prior calendar year.
HoldingCount is an enumerated type implemented as the following four-letter codes:
'DAIL' | 'WEEK' | ‘WAVG’ | 'MNTH' | ‘MAVG’ | 'QUTR' | ‘QAVG’ | 'SEMI' | ‘SAVG’ | 'YEAR' | ‘YAVG’ | 'WKEM' | 'MNEM' | 'QUEM' | 'SAEM' |
'YREM'.
User guide
The parties should set HoldingCount to a value that is compatible with the holding address.
The start of a calendar week is each Monday (ISO 8601).

Rule
HoldingValue = HoldingCount, ApplicableNAV;
Synopsis
The value of a holding of an ISIN upon which a periodic charge is calculated is the product of the number of shares or units of the ISIN that
are held and the applicable NAV per share or unit.
HoldingCount: Defined in this document.
ApplicableNAV: Defined in this document.
User guide
The HoldingValue is a function of the HoldingCount and the ApplicableNAV and (by inference) the CalculationFrequency if the function is
being used for periodic charge calculation or the LookupFrequency if it is being used for holding aggregation. The function is expressed in
several forms. For example:
(1) The product of holdings and NAV on a particular day:
dd NAVHoldingsueHoldingVal 
(2) The arithmetic mean of the product of holdings and NAV on each day in a particular period (e.g., every day in a month):


n
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.
IncrementalTrade is an enumerated type implemented as the following four-letter codes:
'TRAD' | 'SETT'.
User guide
See also the rule EligiblePosition.
Rule
ISINAndDescription = ISIN, [Description];
Synopsis
An international securities identification number and a descriptor (typically the full name of the share class).
ISIN: ISO 20022 ISINIdentifier.
Description: ISO 20022 Max140Text.
User guide
Not defined.
Rule
Jurisdiction = Country, [Name];
Synopsis
The courts of the jurisdiction to which the parties will submit in respect of the agreement.
Country: ISO 20022 CountryCode.
Name: ISO 20022 Max70Text.
User guide
Not defined.

Rule
LatePaymentPenalty = PenaltyRate, BaseRate;
Synopsis
Determines any late payment penalties that may be agreed between the parties:
PenaltyRate The penalty rate of interest to be applied, set as an annual equivalent rate.
BaseRate The base rate of interest with respect to which penalty interest should be calculated.
PenaltyRate: ISO 20022 PercentageRate, >= 0.
BaseRate: ISO 20022 Max350Text.
User guide
LatePayment penalties should become payable from the day following the expiry of the payment deadline set by the term SettlementWithin
and be calculated daily using the day count convention actual/actual.
Rule
LegalAspects = LegalTerms, {LegalVariation}, ApplicableLawAndJurisdiction, [MostFavouredTerms];
Synopsis
The essential legal framework for the agreement:
LegalTerms The legal terms of the agreement (industry standard terms or proprietary terms).
LegalVariation Any variation to the LegalTerms.
ApplicableLawAndJurisdiction The law which will govern the agreement and the courts to which the parties will submit.
MostFavouredTerms The Company has most favoured nation status and in what respect.
LegalTerms: ISO 20022 Max350Text.
LegalVariation: ISO 20022 Max350Text.
ApplicableLawAndJurisdiction: Defined in this document.
MostFavouredTerms: ISO 20022 Max2000Text.
User guide
LegalTerms is a text field that can contain the name of a model agreement, such as a model fund sales agreement or the Swiss Funds
Association model distribution agreement, or a reference to a proprietary legal agreement.
An agreement may have several legal variations. For example:
(1) A generic model fund sales agreement may be extended by a model support annex that is relevant to a specific sector, such as the
structured products sector, the life sector or the platform sector.
(2) A model agreement may be amended by the parties, the amendments being recorded in a legal variation document.
(3) An enabling agreement may be applied, such as may happen when a Counterparty gives a Company notice of a new sub-distributor's
appointment.
(4) A proprietary agreement may be modified by a side letter.
LegalVariation is a free text field, which allows the parties to describe the legal variation in natural language. It may take the form of a
reference to a document containing one or more statements of variation from the contracted legal terms of the agreement. It may also be a
reference to a model document (e.g., a sector-specific extension of a master model agreement) or a proprietary document drawn up by the
contracting parties. For example: "Amendment to the Agreement between ABC Promoter and XYZ Distributor dated 10 May 2011."

Rule
LookupFrequency = 'Daily' | 'Weekly' | 'Monthly' | 'Quarterly' | 'HalfYearly' | 'Yearly';
Synopsis
How often in a period the Counterparty's total holding values should be used to look up the Rate:
Daily Upon each calendar day.
Weekly On the last day of a calendar week (Sunday).
Monthly On the last day of a calendar month (31 January, 28/29 February, 31 March, 30 April, etc).
Quarterly On the last day of a calendar quarter (31 March, 30 June, 30 September, 31 December).
HalfYearly On the last day of a calendar half-year (30 June, 31 December).
Yearly On the last day of a calendar year (31 December).
LookupFrequency is an enumerated type implemented as the following four-letter codes:
'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.
Rule
Market = Country | Proprietary | URL;
Synopsis
Define a market to be a single country or a proprietary market definition or accessible via a URL.
Country: ISO 20022 CountryCode.
URL: ISO 20022 Max256Text.
User guide
The Company may assemble the countries of a region into a set and assign a name (an identity, being a Max35Text field within the definition
of the Proprietary type) to it, which its sales force and operations staff can use. For example, "Europe" might mean the set of countries
including France, Germany, Italy, Spain, etc. The Company may define as many regions as it wishes and hold their names in its proprietary
systems as standing data. Such definitions will be proprietary but they should not be considered private data, and should be disclosed to the
Counterparty.
For example, a proprietary identifier for Schroders' definition of Europe, Middle East and Africa ("EMEA," which comprises at least three
regions and many countries) would appear in message XML as:
<Mkt>
<Prtry>
<Id>EMEA</Id>
<Issr>Schroders</Issr>
</Prtry>
</Mkt>
Because a proprietary definition is under the Company's control, the Company must provide the Counterparty with the means to expand it
into the complete list of its members.
The Company must maintain each proprietary definition and ensure that new and historical definitions are made available to the
Counterparty. The parties must agree how updates should be made, including whether they should support a "push model" (Company sends
updates to Counterparty), a "pull model" (Counterparty requests updates from Company), or the use of third party agents such as KNEIP,
WM Daten, Telekurs, etc., to support information exchange; incremental and entire updates; error correction, etc.
The Company may prefer to provide a URL to a web page or a document at which it will maintain its market definitions for its clients' easy
access. For example:
http://www.schroders.lu/emea
(this is for illustration purposes only and is not a live URL)

Rule
MarketExclusion = Market;
Synopsis
Define a market exclusion to be a single country or a proprietary market definition or accessible via a URL.
See the definition of the rule Market in this document.
User guide
If the markets within the scope of the agreement are defined by reference to a pre-defined set of markets, one of more members of the set
may be excluded from the scope. For example, if we define a proprietary market identifier "Nordics":
Nordics = 'DK', 'FI', 'IS', 'NO', 'SE';
And if we now wish to make an agreement covering all countries except Iceland:
Market = Nordics;
MarketExclusion = 'IS';
See also the user guide of the rule Market in this document. If the practitioner prefers to define an exclusion using a free text statement (with
care to ensure that it can be understood clearly), the URL option in the Market definition is a free text field of 256 characters.
Rule
OfferRights = OfferRightsAndDelegation | Proprietary | OfferRightsNarrative;
Synopsis
For pooled funds, determines what rights the Counterparty has to sell the Company's Products in the Markets, by reference to:
OfferRightsAndDelegation Offer and delegaton rights as defined by standard codes.
Proprietary Rights as defined by some other proprietary code.
OfferRightsNarrative Offer rights described in free text.
OfferRightsAndDelegation: Defined in this document.
OfferRightsNarrative: ISO 20022 Max350Text.
User guide
OfferRightsAndDelegation is likely to be sufficient when the Counterparty is distributing funds by public offer and/or private placement in
accordance with the Company's registrations and applicable laws, or where the Counterparty has no offer rights.
The term "Proprietary" enables the parties to use an alternative descriptor (a short text field of 35 characters) provided that they agree what it
is and who issued it. For example, if the message is being used in the context where Company is a platform and Counterparty is a
participating member, the parties may agree proprietary descriptors that are suitable for their purposes. The meaning of these descriptors
would be defined by the platform, acting as the issuer of the proprietary scheme.
OfferRightsNarrative might be used when the parties do not wish to define proprietary descriptors but wish to use a short text description of
the Counterparty's offer rights.

Rule
OfferRightsAndDelegation = OfferRightsCode, DelegationPermitted;
Synopsis
Determines:
OfferRightsCode What offer rights the Counterparty has.
DelegationPermitted Whether the Counterparty may delegate its offer rights to a third party.
OfferRightsCode: Defined in this document.
DelegationPermitted: ISO 20022 YesNoIndicator.
User guide
If the DelegationPermitted flag is set (='Yes' or 'True') the Counterparty may delegate to a third party its rights to sell the Company's products
subject to the LegalTerms and any LegalVariation.
If the DelegationPermitted flag is not set (='No' or 'False') the Counterparty may only delegate to members of its own group its rights to sell
the Company's products subject to the LegalTerms and any LegalVariation. The Counterparty may not delegate its offer rights to a third
party.
Rule
OfferRightsCode = 'PrivatePlacement' | 'PublicOffer' | 'PublicOfferAndPrivatePlacement' | 'None';
Synopsis
Determines what rights the Counterparty has to sell the Company's Products in the Markets:
PublicOffer Counterparty may sell Company's products by public offer only.
PrivatePlacement Counterparty may sell Company's products by private placement only.
PublicOfferAndPrivatePlacement Counterparty may sell Company's products by public offer and private placement.
None Counterparty has no rights to sell Company's products.
OfferRightsCode is an enumerated type implemented as the following four-letter codes:
'PPLA' | 'POFR' | 'POPP' | 'NONE'.
User guide
The Counterparty's right to sell the Company's products by public offer in a particular market is subject to that product being authorised for
sale to the public in that market. The process of obtaining such authority and the practice of whether it is procured by the Company or the
Counterparty, and the parties' compliance with applicable public offering rules is beyond the scope of the technical part of this project.
The Counterparty's right to sell the Company's products in a particular market by private placement is subject to that market's private
placement rules, and is beyond the scope of the technical part of this project.
The option 'None' is relevant to agreements in which purpose is only to pay the Counterparty periodic charges on its investments.

Rule
OutPerformBenchmark = Description, [TickerIdentifier], CompareMethod;
Synopsis
Defines the benchmark that is used in performance fee calculations:
Description Free text description of the benchmark used to determine the performance of a portfolio.
TickerIdentifier Free text short representation of the benchmark description, given by its sponsor.
CompareMethod Describes how the outperformance of a portfolio is calculated with respect to the benchmark.
Description: ISO 20022 Max350Text.
TickerIdentifier: ISO 20022 TickerIdentifier (which is ISO 20022 Max35Text).
CompareMethod: Defined in this document.
User guide
Not defined.
Rule
PartialChargePeriodConvention = 'Long' | 'Short';
Synopsis
Determine how to calculate charges in the event that a PeriodicCharge does not align to the end of a calendar month, quarter, half-year or
year:
Long Extend the adjacent period to create a long period.
Short Calculate charges for the partial period separately from the adjacent period.
PartialChargePeriodConvention is an enumerated type implemented as the following four-letter codes:
'LONG' | 'SHOR'
User guide
In the example where a PeriodicCharge starts on 12 December in an agreement with quarterly calculation periods:
A long calculation period would run from 12 December to 31 March inclusive.
A short calculation period would run from 12 to 31 December inclusive.
Rule
PartyIdentification = AnyBIC | LEIIdentifier | ProprietaryID | NameAndAddress;
Synopsis
Identify a party by reference to:
AnyBIC Its business identifier code (ISO 9362).
LEIIdentifier Its legal entity identifier (ISO 17442).
ProprietaryID A proprietary identifier.
NameAndAddress A name and address.
AnyBIC ISO 20022 AnyBICIdentifier.
LEIIdentifier ISO 20022 LEIIdentifier.
ProprietaryID ISO 20022 GenericIdentification1.
NameAndAddress ISO 20022 NameAndAddress5.
User guide
Not defined.

Rule
Payee = 'Company' | 'Counterparty';
Synopsis
Determine who the beneficiary of a PeriodicCharge is:
Company The Company (e.g., in the case of a segregated management fee).
Counterparty The Counterparty (e.g., in the case of a pooled fund periodic charge).
Payee is an enumerated type implemented as the following four-letter codes:
'CPNY' | 'CPTY'
User guide
Not defined.
Proposed change to the rule
Payment = PaymentNumber, [PaymentName], PaymentInstrument, PaymentCurrency, BeneficiaryCrossReference,
AgreementSectionCrossReference, [SettlementWithin], [DeMinimisCharge], [DeMinimisPayment], [DeMinimisOption],
[PaymentFlow];
Synopsis
Payment mandates contain a mandate PaymentNumber and a PaymentInstrument.
PaymentName A custom name to allow the identification of a specific mandate.
PaymentCurrency Payment is to be made in the currencies of the securities in respect of which charges were
calculated or in a single currency.
BeneficiaryCrossReference Entity receiving the payments pertaining to charges.
AgreementSectionCrossReference Identification of the charge received by the beneficiary.
SettlementWithin Payments are to be made within an agreed number of days of the end of the period.
DeMinimisCharge The minimum threshold at which charges will be applied.
DeMinimisPayment The minimum threshold at which charges will be paid.
DeMinimisOption How are below threshold accruals / payments handled.
PaymentFlow How payments will be initiated.
PaymentNumber: ISO 20022 Max3NumberNonZero, > 0.
PaymentName: ISO 20022 Max70Text.
PaymentInstrument: Defined in this document.
PaymentCurrency: Defined in this document.
BeneficiaryCrossReference: Defined in this document.
AgreementSectionCrossReference: Defined in this document.
SettlementWithin: Defined in this document.
DeMinimisCharge: Defined in this document.
DeMinimisPayment: Defined in this document.
DeMinimisOption: Defined in this document.
PaymentFlow: 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.
If SettlementWithin, and DeMinimisPayment / DeMinimisOption are not defined, then the settlement 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 PaymentFlow is not defined, then it is equal to ‘Direct Payment’

Rule
PaymentCurrency = PaymentCurrencyBasis | Currency;
Synopsis
Determine in what currency transaction charges and/or periodic charges will be paid:
PaymentCurrencyBasis In multiple currencies.
Currency In a single currency.
PaymentCurrencyBasis: Defined in this document.
User guide
If the Currency option is selected, all payments will be converted into that currency in accordance with the Company's normal operating
procedures (i.e., auto FX is enabled).
Rule
PaymentCurrencyBasis = 'BaseCurrency' | 'ShareClassCurrency' | 'MandateCurrency' | 'InvestmentCurrency';
Synopsis
Payables for transaction charges and periodic charges should be:
BaseCurrency Paid in the fund's base currency (with automatic FX as necessary).
ShareClassCurrency Paid in the currency of the share class in respect of which they were calculated.
MandateCurrency Paid in the currency of the sub-mandate in respect of which they were calculated.
InvestmentCurrency Paid in the currency in which the investments are denominated.
PaymentCurrencyBasis is an enumerated type implemented as the following four-letter codes:
'BCCY' | 'SCCY' | 'MCCY' | 'ICCY'.
User guide
The payment basis applies to pooled funds and segregated mandates as follows:
Basis Pooled fund Segregated mandate
BCCY The base currency of each fund (sub-fund within an umbrella) The reporting currency of the top-level mandate
SCCY The currency of each share class Not applicable
MCCY Not applicable The reporting currency of the sub-mandate
ICCY Not applicable The investment currency of the assets within a mandate
If the parties wish to ensure auto FX to a single currency they should use the option Currency in the rule PaymentCurrencyBasis.

OpenTerms Syntax

Recommended

Recommended

More Related Content

Similar to OpenTerms Syntax

Similar to OpenTerms Syntax (20)

Recently uploaded

Recently uploaded (20)

OpenTerms Syntax