# FpML 5.5 Validation Rules - Rules for Shared Elements (confirmation view)

This is the shared element part of the validation rule set accompanying the FpML 5.5 Recommendation . The introductory section in the draft contains background information and documentation for this page.

The rules contained on this page contain links to cut down versions of valid and invalid test cases. These test cases have been analysed using Systemwire's xlinkit rules to highlight relevant document portions accessed by a rule. These cut down test cases are non-normative and are provided for the purpose of documentation only.

Please Note: The Reference and Shared Validation rule are being included in the Reporting, Recordkeeping and Transparency view since FpML version 5.5WD1. The examples and rules associated with these views are currently avaialable only for Confirmation view . The rules are currently in the process of being reviewed and will be added with in the next 5.5 publication.

## Content

- Namespace
- Functions
- Rules
- Rules with comments
  - shared-1
  - shared-10
  - shared-18
  - shared-19
  - shared-21
  - shared-23
  - shared-24

## Namespace

default element namespace = http://www.fpml.org/spec/fpml-5-5-7-rec-1

namespace xs = http://www.w3.org/2001/XMLSchema

## Functions

The following shared functions are used in the rules.

- iff

## Rules

#### Unique contexts:

- BusinessDayAdjustments (complex type): shared-1
- RelativeDateOffset (complex type): shared-4
- DirectionalLeg (complex type): shared-5
- AmericanExercise (complex type): shared-6
- BermudaExercise (complex type): shared-7
- DateRange (complex type): shared-8
- BusinessDateRange (complex type): shared-9
- CalculationAgent (complex type): shared-10
- Trade (complex type): shared-11
- Document (complex type): shared-14
- Offset (complex type): shared-15
- Acknowledgement (complex type): shared-18 shared-19
- AdjustableDates (complex type): shared-20
- BusinessCenters (complex type): shared-21
- CashSettlementReferenceBanks (complex type): shared-23
- RoutingIds (complex type): shared-24
- Schedule (complex type): shared-25
- Bond (complex type): shared-26
- CancelableProvision (complex type): shared-29
- Deprecated rules
- Removed rules

shared-1 (Mandatory)
English Description:
Context: BusinessDayAdjustments (complex type)
businessCentersReference or businessCenters must exist if and only if the value of businessDayConvention is not equal to "NONE" or "NotApplicable".
XPath Description:
Context: BusinessDayAdjustments
iff(exists(businessCentersReference | businessCenters), not(businessDayConvention = ("NONE", "NotApplicable")))
Comment: You only have business centres for business day calculations when there is a business day convention.
Test cases: [Invalid] [Invalid] [Invalid] [Invalid] [Invalid] [Invalid] [Invalid] [Invalid]
shared-4 (Mandatory)
English Description:
Context: RelativeDateOffset (complex type)
If dayType equals to "Business", then the businessDayConvention must be equal to "NONE".
XPath Description:
Context: RelativeDateOffset
[dayType eq "Business"]
businessDayConvention eq "NONE"
Test cases: [Invalid]
shared-5 (Mandatory)
English Description:
Context: DirectionalLeg (complex type)
EquityPremium (complex type)
ExerciseFee (complex type)
ExerciseFeeSchedule (complex type)
FeaturePayment (complex type)
FixedPriceLeg (complex type)
FloatingPriceLeg (complex type)
FxOptionPremium (complex type)
GrossCashflow (complex type)
IndependentAmount (complex type)
InitialPayment (complex type)
InterestRateStream (complex type)
NonPeriodicFixedPriceLeg (complex type)
PassThroughItem (complex type)
Payment (complex type)
PaymentBase (complex type)
PaymentMatching (complex type)
PhysicalLeg (complex type)
PrePayment (complex type)
PrincipalExchangeDescriptions (complex type)
PrincipalMovement (complex type)
QuotablePayment (complex type)
ReturnSwapAdditionalPayment (complex type)
SimplePayment (complex type)
TradeUnderlyer2 (complex type)
payerPartyReference/@href must not be equal to receiverPartyReference/@href.
XPath Description:
Context: DirectionalLeg
EquityPremium
ExerciseFee
ExerciseFeeSchedule
FeaturePayment
FixedPriceLeg
FloatingPriceLeg
FxOptionPremium
GrossCashflow
IndependentAmount
InitialPayment
InterestRateStream
NonPeriodicFixedPriceLeg
PassThroughItem
Payment
PaymentBase
PaymentMatching
PhysicalLeg
PrePayment
PrincipalExchangeDescriptions
PrincipalMovement
QuotablePayment
ReturnSwapAdditionalPayment
SimplePayment
TradeUnderlyer2
payerPartyReference/@href ne receiverPartyReference/@href
Test cases: [Invalid]
shared-6 (Mandatory)
English Description:
Context: AmericanExercise (complex type)
If latestExerciseTime exists, the earliestExerciseTime/hourMinuteTime must be before the latestExerciseTime/hourMinuteTime.
XPath Description:
Context: AmericanExercise
[exists(latestExerciseTime)]
earliestExerciseTime/hourMinuteTime lt latestExerciseTime/hourMinuteTime
Test cases: [Invalid] [Invalid]
shared-7 (Mandatory)
English Description:
Context: BermudaExercise (complex type)
If latestExerciseTime exists, the earliestExerciseTime/hourMinuteTime must be before the latestExerciseTime/hourMinuteTime.
XPath Description:
Context: BermudaExercise
[exists(latestExerciseTime)]
earliestExerciseTime/hourMinuteTime lt latestExerciseTime/hourMinuteTime
Test cases: [Invalid]
shared-8 (Mandatory)
English Description:
Context: DateRange (complex type)
unadjustedFirstDate must be before unadjustedLastDate.
XPath Description:
Context: DateRange
unadjustedFirstDate lt unadjustedLastDate
Test cases: [Invalid] [Invalid] [Invalid]
shared-9 (Mandatory)
English Description:
Context: BusinessDateRange (complex type)
If and only if neither businessCentersReference nor businessCenters exists, businessDayConvention must be equal to "NONE" or "NotApplicable".
XPath Description:
Context: BusinessDateRange
iff(not(exists(businessCentersReference | businessCenters)), businessDayConvention = ("NONE", "NotApplicable"))
Test cases: [Invalid]
shared-10 (Mandatory)
English Description:
Context: CalculationAgent (complex type)
The values of calculationAgentPartyReference/@href attributes shall be unique.
XPath Description:
Context: CalculationAgent
count(distinct-values(calculationAgentPartyReference/@href)) eq count(calculationAgentPartyReference/@href)
Comment: It does not make sense for a party to be listed more than once as calculation agent to a trade.
Test cases: [Invalid]
shared-11 (Mandatory)
English Description:
Context: Trade (complex type)
If businessDateRange exists within any descendant element of the trade, then businessCentersReference/@href, if present in any descendant element of the trade, must match some businessCenters/@id within any descendant of the same trade.
XPath Description:
Context: Trade
[exists(//businessDateRange)]
every $businessCentersReference in //businessCentersReference satisfies $businessCentersReference/@href = //businessCenters/@id
Test cases: [Invalid]
shared-14 (Mandatory)
English Description:
Context: Document (complex type)
For calculationAgentPartyReference/@href anywhere in the document, @href shall match the @id attribute of a party element.
XPath Description:
Context: Document
every $calculationAgentPartyReference in //calculationAgentPartyReference satisfies $calculationAgentPartyReference/@href = party/@id
Test cases: [Invalid]
shared-15 (Mandatory)
English Description:
Context: Offset (complex type)
dayType must only exist if and only if period is "D" and periodMultiplier is non-zero.
XPath Description:
Context: Offset
[exists(dayType)]
iff((period eq "D"), (periodMultiplier ne 0))
Test cases: [Invalid] [Invalid]
shared-18 (Mandatory)
English Description:
Context: Acknowledgement (complex type)
DataDocument (complex type)
Exception (complex type)
ExecutionNotification (complex type)
ExecutionRetracted (complex type)
ExecutionAdvice (complex type)
ExecutionAdviceRetracted (complex type)
TradeChangeAdvice (complex type)
TradeChangeAdviceRetracted (complex type)
RequestConsent (complex type)
RequestConsentRetracted (complex type)
ConsentGranted (complex type)
ConsentRefused (complex type)
RequestConfirmation (complex type)
ConfirmationRetracted (complex type)
ConfirmationStatus (complex type)
ConfirmationAgreed (complex type)
ConfirmationDisputed (complex type)
RequestClearing (complex type)
RequestClearingRetracted (complex type)
ClearingRefused (complex type)
ClearingConfirmed (complex type)
RequestAllocation (complex type)
RequestAllocationRetracted (complex type)
AllocationRefused (complex type)
AllocationApproved (complex type)
Each party/partyId must be unique. Each party/partyName must be unique.
Comment: Both a party's name and party Id must be unique. The partyIdScheme is part of the partyId uniqueness check.
Test cases: [Invalid]
shared-19 (Mandatory)
English Description:
Context: Acknowledgement (complex type)
DataDocument (complex type)
Exception (complex type)
ExecutionNotification (complex type)
ExecutionRetracted (complex type)
ExecutionAdvice (complex type)
ExecutionAdviceRetracted (complex type)
TradeChangeAdvice (complex type)
TradeChangeAdviceRetracted (complex type)
RequestConsent (complex type)
RequestConsentRetracted (complex type)
ConsentGranted (complex type)
ConsentRefused (complex type)
RequestConfirmation (complex type)
ConfirmationRetracted (complex type)
ConfirmationStatus (complex type)
ConfirmationAgreed (complex type)
ConfirmationDisputed (complex type)
RequestClearing (complex type)
RequestClearingRetracted (complex type)
ClearingRefused (complex type)
ClearingConfirmed (complex type)
RequestAllocation (complex type)
RequestAllocationRetracted (complex type)
AllocationRefused (complex type)
AllocationApproved (complex type)
Each account/accountId must be unique.
Comment: Each account Id must be unique. The accountIdScheme is part of the accountId uniqueness check.
Test cases: [Invalid]
shared-20 (Mandatory)
English Description:
Context: AdjustableDates (complex type)
Each unadjustedDate must be distinct.
Test cases: [Invalid]
shared-21 (Mandatory)
English Description:
Context: BusinessCenters (complex type)
Each businessCenter must be unique. A business calendar location is identified by businessCenter.
Comment: Each business calendar location must be uniquely identified. The businessCenterScheme is part of the businessCenter uniqueness check.
Test cases: [Invalid]
shared-23 (Mandatory)
English Description:
Context: CashSettlementReferenceBanks (complex type)
Each referenceBank must be unique. A referenceBank is identified by referenceBank/referenceBankId or by referenceBank/referenceBankName
Comment: Both a reference bank's name and reference bank Id must be unique. The referenceBankIdScheme is part of the referenceBankId uniqueness check.
shared-24 (Mandatory)
English Description:
Context: RoutingIds (complex type)
Each routingId must be unique
Comment: Each routing Id must be unique. The routingIdCodeScheme is part of the RoutingId uniqueness check.
shared-25 (Mandatory)
English Description:
Context: Schedule (complex type)
If there is more than one step, step/stepDate must be unique.
shared-26 (Mandatory)
English Description:
Context: Bond (complex type)
The currency of the parValue is the currency element. When the parValue exists therefore the currency must also exist. This is a workaround because parValue is not defined as a Money type.
XPath Description:
Context: Bond
[exists(parValue)]
exists(currency)
Test cases: [Invalid]
shared-29 (Mandatory)
English Description:
Context: CancelableProvision (complex type)
CommodityOption (complex type)
EquityDerivativeBase (complex type)
ExtendibleProvision (complex type)
Fra (complex type)
GeneralTerms (complex type)
GenericProduct (complex type)
InstrumentTradeDetails (complex type)
Option (complex type)
ReturnSwapBase (complex type)
SinglePartyOption (complex type)
Swaption (complex type)
buyerPartyReference/@href must not be equal to sellerPartyReference/@href.
XPath Description:
Context: CancelableProvision
CommodityOption
EquityDerivativeBase
ExtendibleProvision
Fra
GeneralTerms
GenericProduct
InstrumentTradeDetails
Option
ReturnSwapBase
SinglePartyOption
Swaption
buyerPartyReference/@href ne sellerPartyReference/@href
Test cases: [Invalid] [Invalid]

#### Deprecated rules

#### Removed rules

shared-2 (Mandatory)
REMOVED: Context: Offset; Description: If the dayType element exists then the period must be "D".
shared-3 (Mandatory)
REMOVED: Context: Offset; Description: If the dayType is "Business" then the periodMultiplier must be non-zero.
shared-12 (Mandatory)
REMOVED: Context: Document; Description: every $buyerPartyReference in //buyerPartyReference satisfies $buyerPartyReference/@href = (trade/tradeSide/@id, party/@id). Rationale for deprecation: the constraints that shared-12 expresses are already covered by ref-29 and because element tradeSide does not exist any more.
shared-13 (Mandatory)
REMOVED: Context: Document; Description: For sellerPartyReference anywhere in the document, @href shall match the @id attribute of a party element. Rationale for deprecation: the constraints that shared-13 expresses are already covered by ref-29 and because element tradeSide does not exist any more.
shared-16 (Mandatory)
REMOVED: Context: Document; Description: If trade exists, for party/@href anywhere within the tradeSide element, @href shall match the @id attribute of an /FpML/party element.
shared-17 (Mandatory)
REMOVED: Context: Document; Description: If trade exists, for account/@href anywhere within the tradeSide element, @href shall match the @id attribute of an /FpML/party/account element.
shared-22 (Mandatory)
REMOVED: Context: Contract; Description: Each calculationAgentPartyReference/@href must be unique Rationale for removal: Duplicate rule.Rule is simlar to shared-10
shared-27 (Mandatory)
REMOVED: Context: Document; Description: All timezones must be the same. +00:00, -00:00, and Z are considered equivalent. Rationale for deprecation: allowed for greater flexibility.
shared-28 (Mandatory)
REMOVED: Context: Document; Description: All dates and times must have a timezone or none of them must. Rationale for deprecation: allowed for greater flexibility. See architecture specification section 2.1.1 for best practice.