17 COLLATERAL MANAGEMENT ARCHITECTURE

17.1 Collateral Management Scope

The FpML Collateral Working Group has extended the FpML standard to cover the following business processes:

17.2 Introduction

This documentation is the FpML Collateral Working Group recommended extension of the FpML standard to support the definition of standard messages for the Collateral Management business process. This work builds on the requirements defined by the ISDA Collateral Committee in the November 12, 2009 publication Standards for the Electronic Exchange of OTC Derivative Margin Calls. The following sections describe the margin call, substitution and interest processes.

17.3 Collateral Concepts

The following concepts were applied in the interpretation of the ISDA Collateral Working Group requirements to FpML standard syntax.

17.3.1 Use Messaging as an Enabling Technology

The FpML messages have been designed to provide enough information to allow Collateral Management Systems to automatically process calls based on bilateral rule definition.

17.3.2 Support Real World Customer and Collateral System Needs

The FpML messages embrace the differences between organizations, business lines, service delivery and collateral systems (in house built and 3rd party vendor). The message definition supports the diversity of the collateral industry allowing organizations to communicate both standard and non-standard calls such as Segregated Independent Amounts and Gross Margin Calculations.

17.3.3 Unambiguous Messages

FpML avoids the use of -/+ amounts, all amounts have corresponding indicators of directions i.e. exposed party, due to, held by and supports message neutrality – i.e. values not expressed in caller terms to allow for machine to machine communication.

17.3.4 Variation Margin and Segregated Independent Amount

The FpML proposal provides the ability to identify separate margin requirements that relate to segregated independent amount and/or variation in the same margin call messages. The use of Segregated Independent Amount results from the practice that became more prevalent post Lehman Brothers and as described in the ISDA White Paper on Independent Amount (ISDA Collateral Committee web page, Independent-Amount-WhitePaper-Final.pdf ).

This mechanism was set up so that organizations could avoid having to set up two agreements and send two separate messages when calling for, and processing, both Variation and Segregated Independent Amount margin requirements. The way that the messages are defined however does not preclude organizations from still representing the margin requirements as separate and reflects the fact that some organizations will define agreements as separately.

The ability to process both requirements in a single message is not restricted to just the requestMargin message but applies to all messages. Therefore an organization can respond to a margin call for Variation Margin and Segregated Independent Amount in a single message indicating they can fully agree to the segregated requirement but only partially agree to the Variation requirement.

17.3.5 Margin Call Status

The FpML proposal requires only a single message to respond to a margin call request. This response known as the marginStatus message allows the responder to state the undisputed amount they can agree to in respect to the margin requirements received in the requestMargin message. The result of this approach will require the consumer of the marginStatus message to calculate whether or not the responder had fully agreed, partially disputed or fully disputed. This would be done by comparing the undisputed amount to the original call amount.

This approach was taken to avoid the potential ambiguity of the original ISDA Working Group requirement which could have resulted from a partial agreement message being sent where the agreed amount was then stated as 0 or the same amount as the original call amount. The use of an explicit undisputed amount makes it clearer as to the responders’ intention. It was noted that the consumer of a message that simply stated fully disputed would still have needed to interpret this to be an agreed amount of zero and used this in calculating disputed amounts for example.

The message reflects more a machine to machine interaction than a human to human interaction where you would naturally say I agree to your call or I dispute your call or I partially agree to x amount.

17.3.6 Support Full Disclosure for Effective Risk Mitigation

Both the requestMargin and marginCallStatus messages employ a common model to represent the details of the margin calculation from either the issuer of the requestMargin message or the responder to the requestMargin message in the marginCallStatus message.

  • The issuer is able to provide details of exposure, independent amount, collateral and margin terms related to how they calculated the call make.
  • The responder to the requestMargin message can provide as much detail as they are willing to disclose about how they decided upon the undisputed amount with which they respond to the request.

This ability to disclose more information beyond the requirements in the ISDA Working Group requirements is designed to give as much information as possible to the consumer of the marginCallStatus message to be able to understand the response and to avoid potential manual processes that could occur from a reduced message content transmission.

For example, the FpML proposal would reduce the need for an email or telephone exchange if the responder replied to the issuer of the call with an undisputed amount that was less than the original call amount and where the details of the threshold were provided and this was the cause of the partial dispute. In the ISDA Working Group requirements the Threshold and other Margin Terms such as MTA or Rounding were not required.

The advantage of this approach is that it enables a machine to machine comparison of the two sets of margin details to see differences in the results of the two calculations making exception detection simpler and allowing for enhanced STP options strategically.

17.3.7 Separation of Collateral Proposal from Margin Call Response

The FpML proposal separates out the response to the requestMargin message to details of what the responder is willing to agree to (marginCallStatus) and the details of what collateral they can provide to meet agreed amount (requestCollateralAcceptance).

This approach was taken to support the scenario where the responder wants to notify the issuer of the requestMargin message that they partially dispute the margin call but do not yet know what collateral is available to meet the undisputed amount. So that the dispute process can start as soon as possible the marginCallStatus message can be sent and the subsequent requestCollateralAcceptance will be sent once the collateral has been identified.

This breaks down the response process in to two pieces and provides message flow flexibility because the same requestCollateralAcceptance can be used for resubmission of a proposal following the rejection or counterproposal of the margin call issuing party.

17.3.8 Counter Proposal

The FpML proposal assumes that only the party that received the requestMargin message can send a collateral proposal by using the requestCollateralAcceptance message. It is also assumed that only the issuing party can respond to the requestCollateralAcceptance using the collateralAcceptanceStatus message. This keeps the relationship between the proposer and responder the same throughout the margin call process. This reduces the number of message types required to support the collateral proposal process to two.

The FpML proposal allows for the receiver of the requestCollateralAcceptance message to respond as to whether they accept or reject the proposal. They can also respond, in the case of a rejection with details of the collateral they would like to receive that is different than that being proposed.

The party that sent the requestCollateralAcceptance can then review the expected collateral request from the issuer of the call and choose to send a revised requestCollateralAcceptance message representing the counter proposal details.

17.3.9 Expected Collateral

Expected Collateral is supported in both the requestMargin and collateralAcceptanceStatus messages. They allow the message user to request collateral they would prefer to receive back in the case of returns, allowing for the explicit definition to the instrument identifier level. For deliver expected collateral requests only general collateral types and comments are supported because the user of the message does not know the exact holdings of the other party to be able to explicitly request a specific ISIN or Cusip be delivered.

17.3.10 Dispute Messages

The FpML proposal does not include support at this stage for the MC12 Request Portfolio and MC13 Acknowledgement Portfolio Sent messages because the group identified that this requirement is evolving as a result of the work of the ISDA Working Group on the Dispute Resolution Protocol (see the ISDA Collateral Committee web page) and would be best supported by a set of additional message sequences that reflects the evolving needs of dispute resolution including the use of bilateral and unilateral reconciliation services, the identification of multiple reasons for a dispute beyond the mark to market amounts and the relative maturity of different reconciliation and resolution approaches for each of those reasons. I.e. exposure vs. collateral reconciliation approaches.

17.3.11 Retraction, Acknowledgement and Exception Messages

The FpML proposal allows for retraction of all messages i.e. requestMargin, marginCallStatus, requestCollateralAcceptance, collateralAcceptanceStatus, disputeNotification. There are is also an acknowledgement message to allow the receiving party to acknowledge receipt of the message. The exception messages are used to notify the sending party of issues processing the message on the receiving side.

The Margin Call process defined in the ISDA Collateral Committee document covers the following message flow:

images/collateral/electronic-messaging-pdf_MarginCallProcess.jpg

17.4.1 Mapping Table of ISDA Collateral Committee Messages to FpML Collateral Working Group Messages

The ISDA Collateral Committee Electronic Messaging Working Group defined 15 messages that represented the collateral Margin Call process. The following table shows the mapping of these 15 messages to their FpML equivalent.

ISDA Collateral Committee FpML
MC1 - Issuance of Margin Call requestMargin
MC2 - Rescind Issued Call requestMarginRetracted
MC3a - Accept Call & Propose Collateral marginCallStatus, requestCollateralAcceptance
MC3b - Accept Call marginCallStatus
MC3c - Propose Collateral requestCollateralAcceptance
MC4 - Rescind Call Response marginCallStatusRetracted
MC5 - Full Dispute marginCallStatus
MC6 - Partial Dispute marginCallStatus, requestCollateralAcceptance
MC7 - Accept Notification of Collateral collateralAcceptanceStatus
MC8 - Reject Notification of Collateral & Counter Propose collateralAcceptanceStatus
MC9 - Accept Counter Proposal collateralAcceptanceStatus
MC10 - Reject & Counter Propose collateralAcceptanceStatus
MC11 - Acknowledge Dispute Notification disputeNotification
MC12 - Request Portfolio Out of Scope
MC13 - Acknowledgement Portfolio Sent Out of Scope
No Equivalent requestCollateralAcceptanceRetracted, collateralAcceptanceStatusRetracted, disputeNotificationRetracted

17.4.2 Proposed FpML Workflow

The following sequence diagram shows the proposed flow of FpML messages for the margin call process.

images/collateral/FpML_collateral_MessageFlow_MarginCall.jpg

17.4.3 FpML Margin Call Messages

This section describes the different FpML messages that support the margin call process.

17.4.3.1 Margin Call Request (MC1) - requestMargin

The margin call request message, requestMargin, communicates the details of a margin calculation to the receiving party. This message supports the communication of both Variation Margin and Independent Amount requirements.

schemaDocumentation/schemas/fpml-collateral-processes-5-4_xsd/complexTypes/RequestMargin.png

The main components of this message are as follows:

  • Parties
    • marginCallIssuerPartyReference - The party issuing the margin call
    • marginCallReceiverPartyReference - The party receiving the margin call
  • Agreement Details
    • Credit Support Agreement - The agreement executed between the parties and intended to govern the collateral arrangement for all OTC derivatives transactions between those parties.
    • Valuation Date - Close of Business date the Local Counterparty is valuing and issuing the margin call
    • Base Currency - Denomination currency as specified in the margin agreement
  • MarginDetails.model

    schemaDocumentation/schemas/fpml-collateral-processes-5-4_xsd/groups/MarginDetails.model.png

    • Mark to Market
      • Exposure - Consists of two elements, the first MarkToMarkExposureParty supports the definition of which party is the exposed party and which is the obligated party. Within FpML it is important to state both parties roll in the exposure details to avoid ambiguity. The parties referenced should be one of those defined in the Parties element. Therefore if Party A is the exposed party there Party Reference ID would be quoted and Party B would be the obligated party. The second element is the exposureAmount this is the amount to which the exposed party is exposed. This uses the Money type that can take but an amount and a currency.
      • Support for Gross Calculations - The mark to market model also supports the definition of the MarkToMarketConventionEnum. This allows two values Netted or Gross. When the value is Netted the exposureAmount is assumed to be the net market value of the portfolio (excluding independent amount, collateral, threshold and MTA). If Gross then two exposureAmounts could be provided one each for the two parties referenced in the Parties section respective exposure to each other. In the case of a Gross Margin Calculation both parties could be expected to call one other. Depending on the level of disclosure each party wishes to make they could decide to only provide the exposure amount from the perspective of the call they are making on the other party.
    • Independent Amount

      This element represents the aggregated independent amount related to a collateral agreement. In other areas of FpML independent amount has been used to define independent amounts related to individual trades within a portfolio.

      For the Collateral Messages the Aggregated Independent Amounts can be classified and quantified based on three types:

      • Trade - This is the total Independent Amount defined in the confirmations of individual trades. This would relate to the same Independent Amount defined in other FpML messages aggregated for a specific agreement.
      • valueAtRisk - A portfolio level Independent Amount that reflects portfolio change over a short time period using statistical techniques such as volatility and risk factor correlations. These amounts reflect the summation of independent Amounts due to Party A or Party B.
      • netOpenPosition - A portfolio level Independent Amounts related to a Parties Net Open Position (NOP). Net Open Position means the total of the Net Long FX and the Net Options in respect of each currency where: Net Long FX for any currency shall be the net amount (if any) of that currency which the Party "A" is long as against Party "B" in respect of all FX transactions.

      For each type it is necessary to define the giverPartyReference, the party that is required to post the independent amount and the takerPartyReference, the party that will receive the independent amount. The independent amount is defined in the paymentAmount element and a convention is provided. The convention can be NettedAfterThreshold, NettedBeforeThreshold or Segregated.

      Segregated Independent Amount is treated separately from Variation Margin. NettedAfterThreshold relates to independent amounts that are taken in to account once the exposure has been compared to the Threshold the residual being adjusted for any Netted After Threshold independent amount and before comparing to the collateral position. Netted Before Threshold is an additional amount that is applied to the exposure amount prior to comparison to the Threshold.

    • Margin Term - Margin Terms can be defined as they apply to Variation Margin and/or Segregated Independent Amount. For Variation Margin Terms a threshold, minimumTransferAmount and transferRounding are defined. For Segregated Independent Amount it is only necessary to provide a minimumTransferAmount and transferRounding. TransferRounding takes to elements direction and amount. The directions are either Up, Down or Closer. A currency can also be defined to represent the currency in which the margin terms are defined, which can be different to the baseCurrency.
    • Collateral - Collateral balances can be defined as they apply to Variation Margin, Segregated Independent Amount or both. Within each of these collateral categories it is possible to define the pendingCollateral, collateral that is currently agreed to be settled but not yet settled and heldCollateral, collateral that has already settled. For pending collateral it is required to supply details who is the giver of the collateral and the taker of the collateral in addition to the amount. For held collateral it is required to supply the holding party and the posting party in addition to the amount that is held.
  • Margin Requirement

    schemaDocumentation/schemas/fpml-collateral-processes-5-4_xsd/complexTypes/RequestMargin/marginRequirement.png

    schemaDocumentation/schemas/fpml-collateral-processes-5-4_xsd/complexTypes/MarginRequirement/variationMargin.png

    This composite type supports the breakdown of the margin call in to its various requirements components. It is possible to define requirements for Variation Margin and/or Segregated Independent Amount. For each requirement type a deliver and or return element can be designated. A deliver or return will require the definition of the delivering party and the receiving party, the currency and the amount of the requirement. The margin requirement block supports up to 4 different requirement definitions:

    • Variation Delivery
    • Variation Return
    • Segregated Independent Amount Delivery
    • Segregated Independent Amount Return
  • Margin Call Result This composite type is really just an aggregation of the data supplied in the Margin Requirement composite type. It allows for the sum of the deliver and return requirements in to a single Margin Call Amount for Segregated Independent Amount and/or Variation Margin. It is necessary to confirm the giver party and the taker party in addition to the margin call amount. This block exists more for usage/comparison to the other messages i.e. the comparison of Agreed Amount in the MarginStatus message to determine whether there is partial or full acceptance or disputing of the margin call amount.
  • Expected Collateral Expected Collateral allows for the definition of collateral that the party making the margin call would prefer to receive or have returned. This can be defined for the Variation Requirement and /or the Segregated Independent Amount Requirement. For deliveries only the type of cash i.e. USD or security type i.e. US Treasuries is expected to be defined. For the return the calling party will know what they posted and therefore can define the expected collateral down to the specific instrument identifier, currency and amount.
17.4.3.2 Rescind Margin Call (MC2) - requestMarginRetracted

This message is used to notify the other party that you wish to rescind a previously sent requestMargin message. This requires reference to the parties, the original message being retracted and the reason for retraction.

schemaDocumentation/schemas/fpml-collateral-processes-5-4_xsd/complexTypes/RequestMarginRetracted.png

The retraction reason includes a description and a reason code. The reason codes include:

  • NewerCalculations - New exposure and/or collateral related data received which means there is now a newer calculation. This message rescinds the original call and notifies of a new message to come
  • PartyReferenceMismatch - The message was sent to the wrong party or for the wrong agreement
  • RevisedMarginTerms - The margin terms have been updated and the original margin call is no longer accurate a new margin calculation will be delivered reflecting the change or the call is simply rescinded as the result is a no action
17.4.3.2.1 Message Correlation

The initiator of a business process should allocate a unique correlation identifier for each process instance it begins and any subsequent message related to the same process should contain the same identifier.

Any response or follow up to this message should contain the same 'correlationId' definition.

The rescind margin call message (MC2) reuses the same correlationId that was set in the margin request (MC1) message.

The correlation mechanism is described in detail in section 3.2.9 “Message Correlation” of the Business Process Architecture.

17.4.3.3 Margin Call Response (MC3b/MC5/MC6) - marginCallStatus

This message is used by the party that received the requestMargin message to respond detailing the extent to which they agree with the requested margin amounts. This message includes the same MarginDetails.model that is used in the requestMargin message however the responding party expresses the details based on their own margin calculation. It is optional as to the amount of information the responding party wishes to disclose. The more information provided the easier it is to identify differences in calculation and therefore which data needs to be reconciled. This message will not include details of the actual collateral that is proposed to meet the amounts being agreed to, this is covered by the requestCollateralAcceptance message.

schemaDocumentation/schemas/fpml-collateral-processes-5-4_xsd/complexTypes/MarginCallStatus.png

  • Agreed Amount - The agreedAmount block allows the responder to detail the undisputed amount for any Variation Margin requirement and/or Segregated Independent Amount requirement they may have received in the corresponding requestMargin message. They will confirm who they believe the giving and taking parties are and the amount and currency of the agreement amount.
  • schemaDocumentation/schemas/fpml-collateral-processes-5-4_xsd/complexTypes/MarginCallStatus/agreedAmount.png

  • MarginCallResponseReason - This element allows you to provide additional details about your response. This takes the form of a description and a reason code. The description can be used to give information that may help the receiver understand your response and could hold information about your calculation that is not obvious from your calculation details i.e. stating that you considered the call date to be a non valuation day. The reason code covers many dispute reason types so that you can specify explicit details that would complement the information that could be garnered from full disclosure of the margin details. The list of reason codes are as follows:
    • MarkToMarketMismatch
    • BaseCurrencyMismatch
    • CreditSupportAgreementMismatch
    • HeldCollateralMismatch
    • IndependentAmountConventionMismatch
    • MarkToMarketConventionMismatch
    • NetOpenPositionIndependentAmountMismatch
    • PartyReferenceMismatch
    • PendingCollateralMismatch
    • SegregatedIndependentAmountMinimumTransferAmountMismatch
    • SegregatedIndependentAmountRoundingMismatch
    • SegregatedIndependentAmountThresholdMismatch
    • TradeLevelIndependentAmountMismatch
    • ValuationDateMismatch
    • ValueAtRiskIndependentAmountMismatch
    • VariationMarginMinimumTransferAmountMismatch
    • VariationMarginRoundingMismatch
    • VariationMarginThresholdMismatch

    Note: the reason codes will be populated in case of dispute or partial dispute.

  • Modeling MC3/MC5/MC6 The ISDA Collateral Working Group specified three different message options in response to a margin call request. These related to full acceptance, full dispute and partial dispute. These can be modeled in the marginCallStatus message as follows:
    • Full Acceptance - The agreed amount will be the same as the margin call amount for the requirement type i.e. Variation Margin or Segregated Independent Amount
    • Full Dispute - The agreed amount will be zero for the requirement type i.e. Variation Margin or Segregated Independent Amount
    • Partial Dispute - The agreed amount will be greater than zero but less than the call amount for the requirement type i.e. Variation Margin or Segregated Independent Amount

    Note that the following combinations are supported:

    • Fully Agree to Variation Margin and Segregated Independent Amount
    • Fully Dispute to Variation Margin and Segregated Independent Amount
    • Partially Dispute Variation Margin and Segregated Independent Amount
    • Fully Agree to Variation Margin and Fully Dispute Segregated Independent Amount
    • Fully Agree to Variation Margin and Partially Dispute Segregated Independent Amount
    • Fully Dispute Variation Margin and Fully Agree Segregated Independent Amount
    • Fully Dispute Variation Margin and Partially Dispute Segregated Independent Amount
    • Partially Dispute Variation Margin and Fully Agree Segregated Independent Amount
    • Partially Dispute Variation Margin and Fully Dispute Segregated Independent Amount

    It is also possible to respond to just the Variation Margin or Segregated Independent Amount requirements separately.

17.4.3.4 Rescind Margin Call Response (MC4) - MarginCallStatusRetracted

This message allows the sender of a MarginCallStatus message to rescind their response. This could be used prior to sending a revised message. Details are provided about the two parties involved and the reference to the marginCallStatus message being rescinded and retraction details can also be provided. The retraction reason includes a description and a reason code.

schemaDocumentation/schemas/fpml-collateral-processes-5-4_xsd/complexTypes/MarginCallStatusRetracted.png

The reason codes include:

  • NewerCalculations - New exposure and/or collateral related data received which means there is now a newer calculation. This message rescinds the original margin call response and notifies of a new message to come
  • PartyReferenceMismatch - The message was sent to the wrong party or for the wrong agreement
  • RevisedMarginTerms - The margin terms have been updated and the original margin call response is no longer accurate a new margin status message will be delivered reflecting the change
17.4.3.5 Collateral Proposal (MC3c) - requestCollateralAcceptance

The requestCollateralAcceptance message is used to communicate the details of collateral that the receiver of the requestMargin message is willing to provide to meet the obligations agreed to in the marginCallStatus message. The message supports provision of collateral details to meet Variation Margin and/or Segregated Independent Amount obligations. The message requires details of the margin call issuer and margin call receiver and the agreed amounts that are being satisfied by the collateral proposal.

schemaDocumentation/schemas/fpml-collateral-processes-5-4_xsd/complexTypes/RequestCollateralAcceptance.png

For each margin type being satisfied the proposedCollateral.model is used.

schemaDocumentation/schemas/fpml-collateral-processes-5-4_xsd/groups/ProposedCollateral.model.png

This consists of choice to provide the collateral details for Variation Margin only, both Variation Margin and Segregated Independent Amount or Segregated Independent Amount obligation details only. For each obligation type the ProposedCollateral composite type is used. This consists of a choice to provide details of either Deliver details only, both Deliver and Return details or only Return details.

schemaDocumentation/schemas/fpml-collateral-processes-5-4_xsd/complexTypes/ProposedCollateral.png

schemaDocumentation/schemas/fpml-collateral-processes-5-4_xsd/complexTypes/ProposedCollateralDeliveryReturn.png

For each movement direction type the ProposedCollateralDeliveryReturn type is used to describe the movements being proposed this type includes details of the delivering and receiving parties and the types of collateral being proposed. Multiple movements can be defined for each movement direction type. There are three collateral type options:

  • Cash
      For cash collateral the following details are provided
    • Currency - When proposing cash collateral the currency of the cash collateral being proposed i.e. USD cash
    • nominalAmount - The amount of cash to be moved
    • valueDate - The date on which the proposed collateral will be settled
    • marketValue - The value of the proposed collateral movement prior to the application of any haircut amount.
    • haircut - The amount to which the collaterals market value will be discounted to take into account the ability to realize the value of that collateral. This amount will be defined as a multiplier i.e. 97% would be represented as 0.97. Typically for cash this would be 1 (100%) however it is noted that cash collateral can be subject to a haircut and therefore has been provided to support all potential scenarios.
    • collateralValue - This is the value of the proposed collateral after the application of the haircut. This amount would be defined in base currency for ease of comparison to the agreed amount to which the proposal is being used towards satisfying.
  • Security
      The security type consists of the following elements:
    • assetReference - This is the reference to an instrument that is defined in the Asset block. This is the asset to be moved.
    • valueDate - The date on which the proposed collateral will be settled
    • Quantity - To represent the quantity of collateral to be moved there is a choice to provide either a nominalAmount or use the UnitContract.model whereby the numberOfUnits and unitPrice are provided. The UnitContract.model is typically used to represent equities and the nominalAmount is used for bonds.
      • NominalAmount.model
        • nominalAmount - nominal amount of the collateral to be moved.
        • dirtyPrice - Bond dirty price, expressed in percentage points, 100 is the initial value of the bond.
      • UnitContract.model
        • numberofUnits - The number of units (index or securities) to be moved.
        • unitPrice - The price of each unit
    • marketValue - The value of the proposed collateral movement based on price and quantity but prior to the application of any haircut.
    • haircut - The amount to which the collaterals market value will be discounted to take into account the ability to realize the value of that collateral. This amount will be defined as a multiplier i.e. 97% would be represented as 0.97.
    • collateralValue This is the value of the proposed collateral after the application of the haircut. This amount would be defined in based currency for ease of comparison to the agreed amount to which the proposal is being used towards satisfying.
  • Letter of Credit
      For Letters of Credit two elements are required; identifier and amount. Note that the partyReference within the contract identifier should refer to the issuing bank.
    • amountThe value of the letter of credit
    • identifier A type defining a contract identifier issued by the indicated party
      • partyReference - A reference to a party identifier defined elsewhere in the document. The party referenced has allocated the contract identifier.
      • contractId - A contract id which is not version aware.
      • versionedContractId - A contract id which is version aware.
      • id
    • marketValue, haircut and collateralValue can be specified but are optional
    • Note: the collateral schema is using a copy of the existing LcSummary type defined in the Loan 4.8 schema. The plan is to reference the official LcSummary once it is available in a later draft of FpML 5.1.

17.4.3.5.1 Assets

This block removes the need to repeat static data details for Assets that may be referred to in the different movement type sections. For example, if the requestCollateralAcceptance message was describing the collateral to be delivered to meet both a Variation Margin and Segregated Independent Amount with both obligation types requiring both a return of collateral and a delivery of new collateral then there could be four instances where the same asset is referred to in each of those sections.

		
<security>
	<assetReference href="xyz" />
	<valueDate>2010-06-02</valueDate>
	<nominalAmount>5000</nominalAmount>
	<dirtyPrice>100</dirtyPrice>	
	<marketValue>5000</marketValue>	
	<haircut>0.90</haircut>		
	<collateralValue>4500</collateralValue>
</security>

	

The assetReference element references the actual definition of the security within the assets block using an id/href mechanism.

The assets block contains a number of FpML underlying assets (i.e., defined by the underlyingAsset substitution group) that define the details of the asset being proposed. Many asset types such as bonds, equities, or cash are available in FpML.

schemaDocumentation/schemas/fpml-collateral-processes-5-4_xsd/complexTypes/RequestMargin/assets.png

		
<assets>
	<bond id="xyz">
		<instrumentId instrumentIdScheme="ISIN">GB0002634946</instrumentId>
		<description>BAE Systems</description>
		<currency>EUR</currency>
		<maturity>2030-10-14</maturity>
	</bond>       
	<equity id="eq01">
		<instrumentId instrumentIdScheme="ISIN">IBM.N</instrumentId>
		<description>ABN AMRO HOLDING NV</description>
		<currency>USD</currency>
		<exchangeId>AEX</exchangeId>
		<relatedExchangeId>LIFFE</relatedExchangeId>
	</equity>
	<cash id="cash01">
		<instrumentId instrumentIdScheme="cash">cash</instrumentId>
		<currency>USD</currency>
	</cash>
	...
	
17.4.3.6 Collateral Proposal Response (MC7/MC8) - collateralProposalStatus

The collateralProposalStatus is used by the party that receives a requestCollateralAcceptance message to provide feedback on whether they can accept the collateral proposals detailed.

schemaDocumentation/schemas/fpml-collateral-processes-5-4_xsd/complexTypes/CollateralProposalStatus.png

This message references the parties involved in the message sequence and the reference to the margin call being responded to. The responding party can provide feedback for either Variation Margin proposals only, both Variation Margin and Segregated Independent Amount proposals and Segregated Independent Amount only proposals. The response details are handled through the ProposedCollateralResponse.model. This model provides the choice for defining which margin types to respond to and then margin type response has the following elements:

proposalApproved This is a Boolean response True or False as to whether the responder accepts the specific movements associated with a specific margin type proposal. Please note therefore that in the same message you can reject a Variation Margin movement proposal and accept a Segregated Independent Amount proposal and vice versa.

collateralResponseReason The responder has the option to provide a reasonCode and description or just a description related to the response to provide more information to the party requesting acceptance. The reasonCode options for rejection include:

expectedCollateral The expected collateral block allows the responder to provide additional details of collateral that they would prefer to receive from the other party. This block can be used when the responder rejects a set of movements and wants to provide feedback on the type of collateral they would prefer to receive. For a delivery the user can provide details of the type of collateral they would prefer to receive i.e. cash, securities or letters of credit. This will not go down to the individual instrument identifier level just to a type i.e. US Treasuries. This is because the responding party does not know the exact holdings of the other party.

For returns the responding party can state the exact movement composition they would prefer to receive back because they know the collateral they have previously posted to the other party that they would now like back. For returns this definition will be the same definition (ProposedCollateralDeliveryReturn) that is used within the requestCollateralAcceptance message.

The use of the expected collateral block allows for counter proposal it is expected that the party that sent the original requestCollateralAcceptance message will review the expected collateral suggestions and then submit a revised requestCollateralAcceptance message that takes into account the counter proposal. This differs from the ISDA Collateral Working Group requirements to allow the original proposer to accept or reject the counter proposal.

  • InsufficientCollateral
  • ConcentrationLimitExceeded
  • InvalidIdentifier
  • NonEligibleSecurity
17.4.3.7 Acknowledge Dispute (MC11) - disputeNotification

The disputeNotification message allows the party that receives the marginCallStatus message, where the responding party either fully or partially disputed the margin call, to acknowledge the dispute and state the expected resolution method.

schemaDocumentation/schemas/fpml-collateral-processes-5-4_xsd/complexTypes/DisputeNotification.png

The message includes details of the parties of the original margin request as well as the reference to the message itself. The sender can provide dispute notification for Variation Margin only, both Variation Margin and Segregated Independent Amount or Segregated Independent Amount only. For each margin type the following details can be provided.

  • Disputed Amount - This is confirmation of the amount being disputed this would be the difference between the undisputed amount and the call amount from the requestMarginCall message
  • Disputed Date - This is the date from which the Dispute is deemed by the sending party to have occurred on. It can be used for dispute aging purposes.
  • Disputed Resolution Method - The disputeResolutionMethod can consist of either a resolutionCode and description, a resolution code only or a description only. The purpose of this element is to be able to provide details of how the dispute differences will be resolved. There could be more than one action that needs to be performed depending on the reasons for the dispute. For example, in the case of a portfolio difference the resolution method could be to perform a reconciliation of the two portfolios. The resolution method could be reconciliation and the details explain the preferred mechanism i.e. via a bilateral reconciliation service to which both parties will upload their respective portfolios. Or it could be a unilateral reconciliation where the notifying party requests the other party to send them a copy of the portfolio in excel format. Other resolution methods could include reconciliation of Independent Amounts, Collateral Positions or Margin Terms.

The Substitution process defined in the ISDA Collateral Committee document covers the following message flow:

images/collateral/electronic-messaging-pdf_SubstitutionProcess.jpg

17.5.1 Mapping Table of ISDA Collateral Committee Messages to FpML Collateral Working Group Messages

The ISDA Collateral Committee Electronic Messaging Working Group defined 6 messages that represented the substitution process. The following table shows the mapping of these 6 messages to their FpML equivalent.

ISDA Collateral Committee FpML
CS1 – Request Substitution requestSubstitution
CS2 – Agree Collateral Substitution substitutionStatus
CS5 – Reject Collateral Substitution substitutionStatus
CS3 – Confirm Substitution substituteConfirmationStatus
CS4 – Confirm Collateral Returned returnConfirmationStatus
CS6 – Propose new line of Collateral requestSubstitution
No Equivalent requestSubstitutionRetracted, substitutionStatusRetracted

17.5.2 Proposed FpML Workflow

The following sequence diagram shows the proposed flow of FpML messages for the collateral substitution process.

images/collateral/FpML_collateral_MessageFlow_Substitution.jpg

17.5.3 FpML Collateral Substitution Messages

The following sections describe the different FpML messages that support the substitution process.

17.5.3.1 Request Substitution (CS1) - requestSubstitution

The request substitution message requestSubstitution communicates the details of a collateral exchange to the receiving party. This message supports substitutions of collateral related to Variation Margin and Segregated Independent Amount requirements.

Typically, it is the party that owns the collateral held by the other party that proposes a request for substitution.

schemaDocumentation/schemas/fpml-collateral-processes-5-4_xsd/complexTypes/RequestSubstitution.png

The main components of this message are as follows:

  • Parties
    • substitutionIssuerPartyReference - The party requesting the collateral substitution
    • substitutionReceiverPartyReference - The party receiving the collateral substitution
  • Credit Support Agreement - The agreement executed between the parties and intended to govern the collateral arrangement for all OTC derivatives transactions between those parties.
  • Collateal Return (return) - Used by the substitution issuer to request a return of collateral.
    • deliveringPartyReference / receivingPartyReference - specify the direction of the collateral movement
    • For each movement direction type the ProposedCollateralDeliveryReturn type (which was defined for the collateral proposal message) is reused to describe the movements being proposed this type includes details of the delivering and receiving parties and the types of collateral being proposed. Multiple movements can be defined for each movement direction type. There are three collateral type options: cash, security, letterOfCredit (see collateral proposal (MC3c) section for details)
  • Collateral Delivery (deliver) - the substitution issuer proposes to deliver cash or specific securities of equivalent value to the returned collateral (return).
  • assets - defines the set of FpML underlying assets that are to be substituted/exchanged (see section “Assets”)
  • substitutionAmount - specifies the amount of collateral to be substituted.
  • party - defines the parties

schemaDocumentation/schemas/fpml-collateral-processes-5-4_xsd/complexTypes/SubstituteCollateral.png

17.5.3.2 Collateral Substitution Response: Agree (CS2) / Reject (CS5) - substitutionStatus

The substitutionStatus message is used by the party that receives a requestSubstitution message to provide a response on whether or not they accept the proposed collateral exchange.

the original CS2 and CS5 messages can be modeled using this same FpML message.

schemaDocumentation/schemas/fpml-collateral-processes-5-4_xsd/complexTypes/SubstitutionStatus.png

The main components of this message are as follows: (Structures that have been covered earlier -such as header, correlationId, creditSupportAgreement, parties- have been omitted.)

  • Parties
    • substitutionIssuerPartyReference - The party requesting the collateral substitution
    • substitutionReceiverPartyReference - The party receiving the collateral substitution
  • The party can approve or reject the substitution request for Variation Margin and Segregated Independent Amount separately.
  • substitutionResponseReason - This element allows you to provide additional details about your response. This takes the form of a free-form description and a reason code. The list of reason codes are as follows:
    • InsufficientCollateral
    • InvalidIdentifier

    Note: the reason code will be populated in case of a rejection. The reason codes are defined in FpML coding list collateral-substitution-response-reason

  • Examples

    		
    <variationMargin>
    	<substitutionApproved>true</substitutionApproved>
    </variationMargin>
    
    <segregatedIndependentAmount>
    	<substitutionApproved>false</substitutionApproved>
    	<substitutionResponseReason>
    		<reasonCode>InsufficientCollateral</reasonCode> 
    		<description>The combined market value of the proposed securities …</description>
    	</substitutionResponseReason>
    </segregatedIndependentAmount>
    	
    17.5.3.3 Confirm Substitution (CS3) - substituteConfirmationStatus

    The substituteConfirmationStatus (of type SubstituteReturnConfirmationStatus) is used by the party that receives a substitution response (substitutionStatus) to notify of the successful transfer of the substitute collateral.

    schemaDocumentation/schemas/fpml-collateral-processes-5-4_xsd/complexTypes/SubstituteReturnConfirmationStatus.png

    The main components of this message are as follows:(Structures that have been covered earlier -such as header, correlationId, creditSupportAgreement, parties- have been omitted.)

    • released - Boolean that specifies whether or not the substitution issuer has transferred the proposed collateral
    • description - free form description

    Examples

    		
    	<variationMargin>
    		<released>true</released>
    	</variationMargin>
    
    	<segregatedIndependentAmount>
    		<released>true</released>
    		<description>Cash has been released please confirm and release your side of the sub</description>
    	</segregatedIndependentAmount>
    	
    17.5.3.4 Confirm Collateral Return (CS4) - returnConfirmationStatus

    The returnConfirmationStatus is used by the substitution receiver to notify the party that issued the substitution request that the collateral has been released. This message uses the same syntax as the CS3 message (both messages share type SubstituteReturnConfirmationStatus). The same released Boolean is used to specify the return status.

    Example

    		
    <segregatedIndependentAmount>
    	<released>true</released>
    	<description>Collateral has been returned.</description>
    </segregatedIndependentAmount>
    	

    The Interest process defined in the ISDA Collateral Committee document covers the following message flows

    Interest Message Exchange - utilizing matching service

    images/collateral/electronic-messaging-pdf_InterestProcess-matching-service.jpg

    Bilateral Interest Message Exchange - not utilizing matching service

    images/collateral/electronic-messaging-pdf_InterestProcess-bilateral.jpg

    17.6.1 Mapping Table of ISDA Collateral Committee Messages to FpML Collateral Working Group Messages

    The ISDA Collateral Committee Electronic Messaging Working Group defined 5 messages that represented the interest payment process. The following table shows the mapping of these 5 messages to their FpML equivalent.

    ISDA Collateral Committee FpML
    IN1 – Send Interest Notification requestInterest
    IN2 – Accept Interest Notification interestStatus
    IN3 – Reject Value Date interestStatus
    IN5 – Dispute Interest interestStatus
    IN4 – Amend Value Date Convention requestInterest
    No Equivalent requestInterestRetracted, interestStatusRetracted, interestStatement

    17.6.2 Proposed FpML Workflow

    The following sequence diagram shows the proposed flow of FpML messages for the collateral interest process.

    Interest Message Exchange using a Matching Service

    images/collateral/FpML_collateral_MessageFlow_Interest-matching-service.jpg

    Bilateral Interest Message Exchange

    images/collateral/FpML_collateral_MessageFlow_Interest-bilateral.jpg

    Matching Service vs Bilateral Exchange

    Adapting the collateral messages to use a matching Service is done easily in FpML through additional header information available in all FpML messages. The copyTo field can be used.

    The header for the IN1 message sent by one party to the matching service may look like:

    		
    <header>
    	<messageId messageIdScheme="http://www.xyzbank.com/message-Id">666777900</messageId>
    	<sentBy>XYZBICXXX</sentBy>
    	<sendTo>MATCHINGSERVICE01</sendTo><!-- COPY SENT TO MATCHING SERVICE  -->
    	<copyTo>ABCBICXXX</copyTo>
    	<creationTimestamp>2010-08-25T12:00:00Z</creationTimestamp>
    </header>
    	

    The matching service is defined as another party at the end of the message.

    		
    <party id="party3">				<!-- MATCHING SERVICE identification -->
    	<partyId>MATCHINGSERVICE01</partyId>
    	<partyName>Matching Corp</partyName>
    </party>
    
    	

    The header for the IN2 message sent by the matching service to one party would look like:

    		
    <header>
    	<messageId messageIdScheme="http://www.xyzbank.com/message-Id">888888888888</messageId>
    	<inReplyTo messageIdScheme="http://www.abcbank.com/message-Id">666777900</inReplyTo>
    	<sentBy>MATCHINGSERVICE01</sentBy><!--  message is sent by a matching service party -->
    	<sendTo>XYZBICXXX</sendTo>
    	<copyTo>ABCBICXXX</copyTo>
    	<creationTimestamp>2010-09-25T15:00:00Z</creationTimestamp>
    </header>
    	

    The ISDA Collateral Working Group requirements only discussed the scenario of utilizing a matching service for the Interest Process. The FpML messaging framework inherently extends the functionality to all collateral processes (i.e., interest, substitution and margin call).

    17.6.3 FpML Interest Messages

    The following sections describe the different FpML messages that support the interest process.

    17.6.3.1 Send Interest Notification (IN1) - requestInterest

    The Interest Notification requestInterest communicates interest owed to the receiving party on collateral held by the issuing party. This message supports the communication of both Variation Margin and Independent Amount requirements. There are two scenarios:

    • During the interest period collateral was held by only one of the parties. Therefore only one party will need to make an interest payment. In FpML the singleDirection block is used to define the interest details. This is the typical scenario.
    • During the interest period, collateral was held at some point by both parties. In this situation both parties owe interest to the other party. In FpML the bothDirections structure is used to the define interest details for each direction. The FpML messages support the definition of whether to treat these obligations on a netted vs gross basis.

    schemaDocumentation/schemas/fpml-collateral-processes-5-4_xsd/complexTypes/RequestInterest.png

    The main components of this message are as follows: (Structures that have been covered earlier -such as header, correlationId, creditSupportAgreement, parties- have been omitted.)

    • Parties
      • IssuerPartyReference - The party issuing the IN1 interest notification
      • ReceiverPartyReference - The party receiving the interest notification
    • Interest Requirement - specifies the interest details (either singleDirection or BothDirections)

      schemaDocumentation/schemas/fpml-collateral-processes-5-4_xsd/complexTypes/RequestInterest/interestRequirement.png

      schemaDocumentation/schemas/fpml-collateral-processes-5-4_xsd/complexTypes/InterestRequirement/interestPeriod.png

      schemaDocumentation/schemas/fpml-collateral-processes-5-4_xsd/complexTypes/InterestRequirement/variationMargin.png

      • InterestPeriod - specifies the startDate and endDate
      • variationMargin and/or segregatedIndependentAmount - The party can specify the interest details for Variation Margin and Segregated Independent Amount separately.
        • singleDirection or bothDirections
    • comment - free form comment

    schemaDocumentation/schemas/fpml-collateral-processes-5-4_xsd/complexTypes/InterestDirection.png

    schemaDocumentation/schemas/fpml-collateral-processes-5-4_xsd/complexTypes/InterestDirection/singleDirection.png

    schemaDocumentation/schemas/fpml-collateral-processes-5-4_xsd/complexTypes/InterestDirection/bothDirections.png

    17.6.3.1.1 Single Direction (singleDirection)

    The single direction structure within variationMargin or segregatedIndependentAmount contains the necessary information to communicate a single interest payment from the party holding collateral to the other.

    schemaDocumentation/schemas/fpml-collateral-processes-5-4_xsd/complexTypes/InterestDirection/singleDirection.png

    The elements are:

    • SingleTreatment
      • paymentDetails
        • payerPartyReference
        • receiverPartyReference
        • paymentDate
        • paymentAmount
        • method - cash or physical settlement
    • InterestAccrued - specifies the interest details (either singleDirection or BothDirections)
      • deliveringPartyReference / receivingPartyReference - the direction of the interest payment
      • interest
        • currency
        • amount
      • withholdingTax
        • currency
        • amount
      • withholdingTaxTerms
        • jurisdiction
        • rate
      • interestCalculationTerms
        • calculationType
        • index
        • spread
        • dayCountFraction
      • interestCalculationDetails optional calculations can be included using this element. within interestCalculationDetails, repeatable a dailyInterestCalculation block can be used for each day of the calculation period (see next section)

    Example

    		
    <singleDirection><!-- typical scenario: only one party will need to make an interest payment. -->
        <singleTreatment>
            <paymentDetails>
                <payerPartyReference href="party1"/>
                <receiverPartyReference href="party2"/>
                <paymentDate>
                    <adjustableDate>
                        <unadjustedDate>2010-09-02Z</unadjustedDate>
                        <dateAdjustments>
                            <businessDayConvention>NONE</businessDayConvention>
                        </dateAdjustments>
                        <adjustedDate>2010-09-02Z</adjustedDate>
                    </adjustableDate>
                </paymentDate>
                <paymentAmount>
                    <currency>USD</currency>
                    <amount>1271.55</amount>
                </paymentAmount>
                <method>PhysicalSettlement</method>
            </paymentDetails>
        </singleTreatment>
        <interestAccrued>
            <deliveringPartyReference href="party1"/>
            <receivingPartyReference href="party2"/>
            <interest>
                <currency>USD</currency>
                <amount>1371.55</amount><!-- the cumulative interest amount  -->
            </interest>
            <withholdingTax><!-- optional tax withholding information -->
                <currency>USD</currency>
                <amount>100</amount>
            </withholdingTax>
            <withholdingTaxTerms>
                <jurisdiction>US</jurisdiction><!-- referencing country code scheme -->
                <rate>0.002</rate>
            </withholdingTaxTerms>
            <interestCalculationTerms>
                <calculationType>Compounding</calculationType>
                <index>EUR-EONIA-Swap-Index</index>
                <spread>-0.0030</spread><!-- 30 basis points -->
                <dayCountFraction>ACT/360</dayCountFraction>
            </interestCalculationTerms>
    	
    17.6.3.1.2 Both Directions (bothDirections)
  • During the interest period, collateral was held at some point by both parties. In this situation both parties owe interest to the other party. In FpML the bothDirections structure is used to the define interest details for each direction. The FpML messages support the definition of whether to treat these obligations on a netted vs gross basis.
  • schemaDocumentation/schemas/fpml-collateral-processes-5-4_xsd/complexTypes/InterestDirection/bothDirections.png

    Net Treatment

    For a net treatment, the following fields are required:

    • netTreatment
      • paymentDetails - netted payment details
    • 2 InterestAccrued - (as detailed earlier for the single direction), one for each interest payment direction.

    Example

    		
    <bothDirections>
        <netTreatment><!--  IF NET treatment (other CHOICE is <grossTreatment>) -->
            <paymentDetails><!-- 1 occurence of <paymentDetails> for Net -->
                <payerPartyReference href="party2"/>
                <receiverPartyReference href="party1"/>
                <paymentDate>
                    <adjustableDate>
                        <unadjustedDate>2010-09-02Z</unadjustedDate>
                        <dateAdjustments>
                            <businessDayConvention>FOLLOWING</businessDayConvention>
                            <businessCenters>
                                <businessCenter>USNY</businessCenter>
                                <businessCenter>BGLO</businessCenter>
                            </businessCenters>
                        </dateAdjustments>
                    </adjustableDate>
                </paymentDate>
                <paymentAmount>
                    <currency>USD</currency>
                    <amount>500</amount>
                </paymentAmount>
                <method>PhysicalSettlement</method>
            </paymentDetails>
        </netTreatment>
        <interestAccrued><!-- 2 occurences of <interestAccrued> -->
            <deliveringPartyReference href="party2"/>
            <receivingPartyReference href="party1"/>
            <interest>
                <currency>USD</currency>
                <amount>1500</amount>
            </interest>
            <interestCalculationTerms>
                <calculationType>Simple</calculationType>
                <index>EUR-EONIA-Swap-Index</index>
                <spread>-0.0030</spread><!-- 30 basis points -->
                <dayCountFraction>ACT/360</dayCountFraction>
            </interestCalculationTerms>
        </interestAccrued>
        <interestAccrued>
            <deliveringPartyReference href="party1"/>
            <receivingPartyReference href="party2"/>
            <interest>
                <currency>USD</currency>
                <amount>1000</amount>
            </interest>
            <interestCalculationTerms>
                <calculationType>Simple</calculationType>
                <index>EUR-EONIA-Swap-Index</index>
                <spread>-0.0030</spread><!-- 30 basis points -->
                <dayCountFraction>ACT/360</dayCountFraction>
            </interestCalculationTerms>
        </interestAccrued>
    </bothDirections>
    

    Gross Treatment

    For a gross treatment, the following fields are required:

    • grossTreatment
      • 2 paymentDetails - one for each interest payment direction
    • 2 InterestAccrued - (as detailed above), one for each interest payment direction.

    Example

    		
    <bothDirections><!-- other CHOICE is <singleDirection> -->
        <grossTreatment><!-- IF GROSS treatment (other CHOICE is <netTreatment>) -->
            <paymentDetails><!-- 2 occurences of <paymentDetails> for Gross -->
                <payerPartyReference href="party1"/>
                <receiverPartyReference href="party2"/>
                <paymentDate>
                    <adjustableDate>
                        <unadjustedDate>2010-09-02Z</unadjustedDate>
                        <dateAdjustments>
                            <businessDayConvention>FOLLOWING</businessDayConvention>
                            <businessCenters>
                                <businessCenter>USNY</businessCenter>
                                <businessCenter>BGLO</businessCenter>
                            </businessCenters>
                        </dateAdjustments>
                    </adjustableDate>
                </paymentDate>
                <paymentAmount>
                    <currency>USD</currency>
                    <amount>1500</amount>
                </paymentAmount>
                <method>PhysicalSettlement</method>
            </paymentDetails>
            <paymentDetails>
                <payerPartyReference href="party2"/>
                <receiverPartyReference href="party1"/>
                <paymentDate>
                    <adjustableDate>
                        <unadjustedDate>2010-09-02Z</unadjustedDate>
                        <dateAdjustments>
                            <businessDayConvention>FOLLOWING</businessDayConvention>
                            <businessCenters>
                                <businessCenter>USNY</businessCenter>
                                <businessCenter>BGLO</businessCenter>
                            </businessCenters>
                        </dateAdjustments>
                    </adjustableDate>
                </paymentDate>
                <paymentAmount>
                    <currency>USD</currency>
                    <amount>500</amount>
                </paymentAmount>
                <method>PhysicalSettlement</method>
            </paymentDetails>
        </grossTreatment>
        <interestAccrued><!-- 2 occurences of <interestAccrued> -->
            <deliveringPartyReference href="party2"/>
            <receivingPartyReference href="party1"/>
            <interest>
                <currency>USD</currency>
                <amount>1500</amount>
            </interest>
            <interestCalculationTerms>
                <calculationType>Simple</calculationType>
                <index>EUR-EONIA-Swap-Index</index>
                <spread>-0.0030</spread><!-- 30 basis points -->
                <dayCountFraction>ACT/360</dayCountFraction>
            </interestCalculationTerms>
        </interestAccrued>
        <interestAccrued>
            <deliveringPartyReference href="party1"/>
            <receivingPartyReference href="party2"/>
            <interest>
                <currency>USD</currency>
                <amount>1000</amount>
            </interest>
            <interestCalculationTerms>
                <calculationType>Simple</calculationType>
                <index>EUR-EONIA-Swap-Index</index>
                <spread>0.25</spread>
                <dayCountFraction>ACT/360</dayCountFraction>
            </interestCalculationTerms>
        </interestAccrued>
    </bothDirections>
    	
    17.6.3.1.3 Interest Calculation Details (interestCalculationDetails)

    The party sending the interest notification can choose to include optional interest calculation details, detailing how the party arrived to the interest amount. Interest calculations are captured using a repeatable dailyInterestCalculation structure. One dailyInterestCalculation structure is used for each day of the interest period.

    schemaDocumentation/schemas/fpml-collateral-processes-5-4_xsd/complexTypes/InterestCalculationDetails.png

    schemaDocumentation/schemas/fpml-collateral-processes-5-4_xsd/complexTypes/InterestCalculationDetails/dailyInterestCalculation.png

    The available fields within dailyInterestCalculation are:

    • calculationDate
    • openingPrincipalAmount - current day's principal amount = previous day's principal amount +/- movement amount for today
    • principalMovement - The aggregated settled collateral movement for the calculation date
    • effectivePrincipalAmount - end of day balance (principalAmount) + previous day's cumulativeInterestAmount
    • observedRate - the observed rate of the index specified in the interestCalculationTerms
    • spread
    • effectiveRate - observed rate adjusted for spread
    • accruedInterestAmount - interest calculated for the calcution date
    • cumulativeInterestAmount - accrued interest to the current calculation date

    Example

    		
    <interestCalculationDetails><!-- optional interest calculations: -->
        <dailyInterestCalculation><!-- calculations for 1st day of period -->
            <calculationDate>2010-08-01Z</calculationDate>
            <openingPrincipalAmount>600000</openingPrincipalAmount>
            <principalMovement>
                <payerPartyReference href="party1"/>
                <receiverPartyReference href="party2"/>
                <paymentAmount>
                    <currency>USD</currency>
                    <amount>100000</amount>
                </paymentAmount>
            </principalMovement>
            <effectivePrincipalAmount>600000</effectivePrincipalAmount>
            <observedRate>0.043</observedRate>
            <spread>-0.0030</spread>
            <effectiveRate>0.040</effectiveRate>
            <accruedInterestAmount>666.66</accruedInterestAmount><!-- (0.40 * 600,000) / 360  -->
            <cumulativeInterestAmount>666.66</cumulativeInterestAmount>
        </dailyInterestCalculation>
        <dailyInterestCalculation>
            <!-- calculations for 2nd day of period -->
            <calculationDate>2010-08-02Z</calculationDate>
            <openingPrincipalAmount>650000</openingPrincipalAmount>
            <principalMovement>
                <!-- aggregated settled collateral movement for the calculation date -->
                <payerPartyReference href="party1"/>
                <receiverPartyReference href="party2"/>
                <paymentAmount>
                    <currency>USD</currency>
                    <amount>50000</amount>
                </paymentAmount>
            </principalMovement>
            <effectivePrincipalAmount>650666.66</effectivePrincipalAmount><!-- end of day balance (principalAmount) + previous day's cumulativeInterestAmount = $650000 + $666.66 -->
            <observedRate>0.042</observedRate>
            <spread>-0.0030</spread><!-- 30 basis points -->
            <effectiveRate>0.039</effectiveRate><!-- = observed rate adjusted with spread -->
            <accruedInterestAmount>704.89</accruedInterestAmount><!-- (0.39 * 650,666.66) / 360  -->
            <cumulativeInterestAmount>1371.55</cumulativeInterestAmount><!-- = day1 accrued interest ($666.66) + day 2 accrued interest ($704.89) -->
        </dailyInterestCalculation>
        <!-- calculations for subsequent days 3, 4, ..., n would go here (not shown) -->
    </interestCalculationDetails>
    	
    17.6.3.2 Response to Interest Notification / Accept (IN2) - Reject Value Date (IN3) - Dispute Interest (IN5) - interestStatus

    The interestStatus is used by the party that receives a requestInterest message to provide a response on whether or not they accept the proposed interest.

    the original IN2, IN3 and IN5 messages can be modeled using the same FpML message.

    schemaDocumentation/schemas/fpml-collateral-processes-5-4_xsd/complexTypes/InterestStatus.png

    The main components of this message are as follows. (Structures that have been covered earlier -such as header, correlationId, creditSupportAgreement- have been omitted.)

    • Parties
      • IssuerPartyReference - The party issuing the IN1 interest notification
      • ReceiverPartyReference - The party receiving the interest notification
    • The party can approve or reject the substitution request for Variation Margin and Segregated Independent Amount separately.
    • interestApproved This is a Boolean response True or False as to whether the responder accepts the specific movements associated with a specific margin type proposal. Please note therefore that in the same message you can reject a Variation Margin interest proposal and accept a Segregated Independent Amount proposal and vice versa.

  • interestResponseReason - This element allows you to provide additional details about your response. This takes the form of a free-form description and a reason code. The list of reason codes are as follows:
    • InterestNotificationAccepted
    • DisputedInterest
    • RejectedValueDate
    • RejectedTreatmentType

    Note: the reason code will be populated in case of a rejection. The reason codes are defined in FpML coding list collateral-interest-response-reason

  • Example

    		
    <interestApproved>false</interestApproved>	<!-- IN5: Dispute Interest -->
    <interestResponseReason>
    	<reasonCode>DisputedInterest</reasonCode>	<!-- coding scheme -->
    	<description>The interest amount is about half that expected</description>
    </interestResponseReason>
    	
    17.6.3.3 Amend Value Date Convention (IN4) - requestInterest

    The Amend Value Date Convention (IN4) message is in effect a new Send Interest Notification (IN1) message. Rather than defining a new, unnecessary message in FpML to model IN4, implementers can simply reissue an IN1 message with amended details.

    17.6.3.4 Interest Statement - interestStatement

    The interest statement is a new message that is not part of the original ISDA business requirements. It is a report detailing interest calculations which can be generated upon request, regardless of interest movements, i.e., independently of an interest notification (IN1).

    The interest statement is similar in structure to the requestInterest (IN1) message except that no treatment is included. The daily calculation details are captured in the mandatory interestCalculationDetails structure. A dailyInterestCalculation is used for each day of the calculation period.

    schemaDocumentation/schemas/fpml-collateral-processes-5-4_xsd/complexTypes/InterestStatement.png

    The main components of this message are as follows: (Structures that have been covered earlier -such as header, correlationId, creditSupportAgreement, parties- have been omitted.)

    • Parties
      • IssuerPartyReference - The party issuing the IN1 interest notification
      • ReceiverPartyReference - The party receiving the interest notification
    • Interest Requirement - specifies the interest details (either singleDirection or BothDirections)

      schemaDocumentation/schemas/fpml-collateral-processes-5-4_xsd/complexTypes/InterestStatementRequirement.png

      • InterestPeriod - specifies the startDate and endDate
      • variationMargin and/or segregatedIndependentAmount - The party can specify the interest details for Variation Margin and Segregated Independent Amount separately.
        • singleDirection or bothDirections
          • interestAccrued
    • comment - free form comment
    		
    <interestCalculationDetails>
    	<dailyInterestCalculation>
    		<!-- calculations for 1st day of period -->
    		<calculationDate>2010-08-01Z</calculationDate>
    		<openingPrincipalAmount>600000</openingPrincipalAmount>
    		<principalMovement>
    			<payerPartyReference href="party1"/>
    			<receiverPartyReference href="party2"/>
    			<paymentAmount>
    				<currency>USD</currency>
    				<amount>100000</amount>
    			</paymentAmount>
    		</principalMovement>
    		<effectivePrincipalAmount>600000</effectivePrincipalAmount>
    		<observedRate>0.043</observedRate>
    		<spread>-0.0030</spread>
    		<effectiveRate>0.040</effectiveRate><!-- = observed rate adjusted with spread -->
    		<accruedInterestAmount>666.66</accruedInterestAmount><!-- (0.40 * 600,000) / 360  -->
    		<cumulativeInterestAmount>666.66</cumulativeInterestAmount>
    	</dailyInterestCalculation>
    	<dailyInterestCalculation>
    		<!-- calculations for 2nd day of period -->
    		<calculationDate>2010-08-02Z</calculationDate>
    		<openingPrincipalAmount>650000</openingPrincipalAmount><!-- current day's principal amount = previous day's principal amount +/- movement amount for today -->
    		<principalMovement>
    			<!-- aggregated settled collateral movement for the calculation date -->
    			<payerPartyReference href="party1"/>
    			<receiverPartyReference href="party2"/>
    			<paymentAmount>
    				<currency>USD</currency>
    				<amount>50000</amount>
    			</paymentAmount>
    		</principalMovement>
    		<effectivePrincipalAmount>650666.66</effectivePrincipalAmount><!-- end of day balance (principalAmount) + previous day's cumulativeInterestAmount = $650000 + $666.66 -->
    		<observedRate>0.042</observedRate>
    		<spread>-0.0030</spread><!-- 30 basis points -->
    		<effectiveRate>0.039</effectiveRate><!-- = observed rate adjusted with spread -->
    		<accruedInterestAmount>704.89</accruedInterestAmount><!-- (0.39 * 650,666.66) / 360  -->
    		<cumulativeInterestAmount>1371.55</cumulativeInterestAmount><!-- = day1 accrued interest ($666.66) + day 2 accrued interest ($704.89) -->
    	</dailyInterestCalculation>
    	<!-- calculations for subsequent days 3, 4, ..., n would go here (not shown) -->
    </interestCalculationDetails>
    	
    Previous Top of Section Next