Skip to content

Class: PayoutBase

A data type that contains the common attributes (e.g. payer and receiver parties) and validation conditions that apply across all payout types

URI: common_domain_model:PayoutBase

 classDiagram
    class PayoutBase
    click PayoutBase href "../PayoutBase/"
      PayoutBase <|-- CommodityPayout
        click CommodityPayout href "../CommodityPayout/"
      PayoutBase <|-- CreditDefaultPayout
        click CreditDefaultPayout href "../CreditDefaultPayout/"
      PayoutBase <|-- InterestRatePayout
        click InterestRatePayout href "../InterestRatePayout/"
      PayoutBase <|-- OptionPayout
        click OptionPayout href "../OptionPayout/"
      PayoutBase <|-- PerformancePayout
        click PerformancePayout href "../PerformancePayout/"
      PayoutBase <|-- SettlementPayout
        click SettlementPayout href "../SettlementPayout/"
      PayoutBase <|-- FixedPricePayout
        click FixedPricePayout href "../FixedPricePayout/"
      PayoutBase <|-- AssetPayout
        click AssetPayout href "../AssetPayout/"

      PayoutBase : payerReceiver





        PayoutBase --> "1" PayerReceiver : payerReceiver
        click PayerReceiver href "../PayerReceiver/"



      PayoutBase : priceQuantity





        PayoutBase --> "0..1" ResolvablePriceQuantity : priceQuantity
        click ResolvablePriceQuantity href "../ResolvablePriceQuantity/"



      PayoutBase : principalPayment





        PayoutBase --> "0..1" PrincipalPayments : principalPayment
        click PrincipalPayments href "../PrincipalPayments/"



      PayoutBase : settlementTerms





        PayoutBase --> "0..1" SettlementTerms : settlementTerms
        click SettlementTerms href "../SettlementTerms/"

Inheritance

Slots

Name Cardinality and Range Description Inheritance
payerReceiver 1
PayerReceiver		 Canonical representation of the payer and receiver parties applicable to each... direct
priceQuantity 0..1
ResolvablePriceQuantity		 Each payout leg must implement the quantity concept as a 'resolvable' type, w... direct
principalPayment 0..1
PrincipalPayments		 The specification of the principal exchange direct
settlementTerms 0..1
SettlementTerms		 Each payout leg must specifies its settlement terms, including the delivery t... direct

In Subsets

Comments

  • Rosetta condition: FinalPrincipalAmountExists — if principalPayment -> principalPaymentSchedule -> finalPrincipalPayment exists and priceQuantity -> quantitySchedule exists and priceQuantity -> reset is absent then principalPayment -> principalPaymentSchedule -> finalPrincipalPayment -> principalAmount exists or principalPayment -> principalPaymentSchedule -> finalPrincipalPayment -> presentValuePrincipalAmount exists

Identifier and Mapping Information

Schema Source

Mappings

Mapping Type Mapped Value
self common_domain_model:PayoutBase
native common_domain_model:PayoutBase

LinkML Source

Direct

name: PayoutBase
description: A data type that contains the common attributes (e.g. payer and receiver
  parties) and validation conditions that apply across all payout types
comments:
- 'Rosetta condition: FinalPrincipalAmountExists — if principalPayment -> principalPaymentSchedule
  -> finalPrincipalPayment exists and priceQuantity -> quantitySchedule exists and
  priceQuantity -> reset is absent then principalPayment -> principalPaymentSchedule
  -> finalPrincipalPayment -> principalAmount exists or principalPayment -> principalPaymentSchedule
  -> finalPrincipalPayment -> presentValuePrincipalAmount exists'
in_subset:
- cdm_product_common_settlement
from_schema: https://w3id.org/lmodel/common-domain-model
slots:
- payerReceiver
- priceQuantity
- principalPayment
- settlementTerms
slot_usage:
  payerReceiver:
    name: payerReceiver
    description: Canonical representation of the payer and receiver parties applicable
      to each payout leg.
    required: true
  priceQuantity:
    name: priceQuantity
    description: Each payout leg must implement the quantity concept as a 'resolvable'
      type, which allows for different payout legs to be linked to each other (e.g.
      in the case of cross-curreny products).
    range: ResolvablePriceQuantity
    required: false
    multivalued: false
  settlementTerms:
    name: settlementTerms
    description: Each payout leg must specifies its settlement terms, including the
      delivery type (i.e. cash vs physical, and their respective terms), the transfer
      type (DvP etc.) and settlement date, if any.
    required: false

Induced

name: PayoutBase
description: A data type that contains the common attributes (e.g. payer and receiver
  parties) and validation conditions that apply across all payout types
comments:
- 'Rosetta condition: FinalPrincipalAmountExists — if principalPayment -> principalPaymentSchedule
  -> finalPrincipalPayment exists and priceQuantity -> quantitySchedule exists and
  priceQuantity -> reset is absent then principalPayment -> principalPaymentSchedule
  -> finalPrincipalPayment -> principalAmount exists or principalPayment -> principalPaymentSchedule
  -> finalPrincipalPayment -> presentValuePrincipalAmount exists'
in_subset:
- cdm_product_common_settlement
from_schema: https://w3id.org/lmodel/common-domain-model
slot_usage:
  payerReceiver:
    name: payerReceiver
    description: Canonical representation of the payer and receiver parties applicable
      to each payout leg.
    required: true
  priceQuantity:
    name: priceQuantity
    description: Each payout leg must implement the quantity concept as a 'resolvable'
      type, which allows for different payout legs to be linked to each other (e.g.
      in the case of cross-curreny products).
    range: ResolvablePriceQuantity
    required: false
    multivalued: false
  settlementTerms:
    name: settlementTerms
    description: Each payout leg must specifies its settlement terms, including the
      delivery type (i.e. cash vs physical, and their respective terms), the transfer
      type (DvP etc.) and settlement date, if any.
    required: false
attributes:
  payerReceiver:
    name: payerReceiver
    description: Canonical representation of the payer and receiver parties applicable
      to each payout leg.
    from_schema: https://w3id.org/lmodel/common-domain-model
    close_mappings:
    - fpml_5_10:CalculateTransferInstruction.payerReceiver
    rank: 1000
    owner: PayoutBase
    domain_of:
    - CalculateTransferInstruction
    - TransferBase
    - CollateralBalance
    - FeaturePayment
    - AssetFlow
    - PayoutBase
    - PrincipalPayment
    - PortfolioReturnTerms
    - PassThroughItem
    range: PayerReceiver
    required: true
  priceQuantity:
    name: priceQuantity
    description: Each payout leg must implement the quantity concept as a 'resolvable'
      type, which allows for different payout legs to be linked to each other (e.g.
      in the case of cross-curreny products).
    from_schema: https://w3id.org/lmodel/common-domain-model
    rank: 1000
    owner: PayoutBase
    domain_of:
    - ExecutionInstruction
    - IndexTransitionInstruction
    - PositionBase
    - PayoutBase
    - TradeLot
    range: ResolvablePriceQuantity
    required: false
    multivalued: false
    inlined: true
    inlined_as_list: true
  principalPayment:
    name: principalPayment
    description: The specification of the principal exchange. Optional as only applicable
      in the case of cross-currency or zero-coupon swaps with a final payment.
    from_schema: https://w3id.org/lmodel/common-domain-model
    rank: 1000
    owner: PayoutBase
    domain_of:
    - PayoutBase
    range: PrincipalPayments
  settlementTerms:
    name: settlementTerms
    description: Each payout leg must specifies its settlement terms, including the
      delivery type (i.e. cash vs physical, and their respective terms), the transfer
      type (DvP etc.) and settlement date, if any.
    from_schema: https://w3id.org/lmodel/common-domain-model
    rank: 1000
    owner: PayoutBase
    domain_of:
    - EquitySwapMasterConfirmation2018
    - PayoutBase
    range: SettlementTerms
    required: false