The FpML Collateral Working Group has extended the FpML standard to cover the following business processes:
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.
The following concepts were applied in the interpretation of the ISDA Collateral Working Group requirements to FpML standard syntax.
The FpML messages have been designed to provide enough information to allow Collateral Management Systems to automatically process calls based on bilateral rule definition.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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 |
The following sequence diagram shows the proposed flow of FpML messages for the margin call process.
This section describes the different FpML messages that support the margin call process.
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.
![]() |
|
The main components of this message are as follows:
![]() |
|
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:
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.
![]() |
|
![]() |
|
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:
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.
![]() |
|
The retraction reason includes a description and a reason code. The reason codes include:
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.
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.
![]() |
|
![]() |
|
Note: the reason codes will be populated in case of dispute or partial dispute.
Note that the following combinations are supported:
It is also possible to respond to just the Variation Margin or Segregated Independent Amount requirements separately.
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.
![]() |
|
The reason codes include:
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.
![]() |
|
For each margin type being satisfied the proposedCollateral.model is used.
![]() |
|
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.
![]() |
|
![]() |
|
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:
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.
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.
![]() |
|
<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> ...
The collateralProposalStatus is used by the party that receives a requestCollateralAcceptance message to provide feedback on whether they can accept the collateral proposals detailed.
![]() |
|
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.
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.
![]() |
|
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.
The Substitution process defined in the ISDA Collateral Committee document covers the following message flow:
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 |
The following sequence diagram shows the proposed flow of FpML messages for the collateral substitution process.
The following sections describe the different FpML messages that support the substitution process.
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.
![]() |
|
The main components of this message are as follows:
![]() |
|
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.
![]() |
|
The main components of this message are as follows: (Structures that have been covered earlier -such as header, correlationId, creditSupportAgreement, parties- have been omitted.)
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>
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.
![]() |
|
The main components of this message are as follows:(Structures that have been covered earlier -such as header, correlationId, creditSupportAgreement, parties- have been omitted.)
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>
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
Bilateral Interest Message Exchange - not utilizing matching service
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 |
The following sequence diagram shows the proposed flow of FpML messages for the collateral interest process.
Interest Message Exchange using a Matching Service
Bilateral Interest Message Exchange
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).
The following sections describe the different FpML messages that support the interest process.
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:
![]() |
|
The main components of this message are as follows: (Structures that have been covered earlier -such as header, correlationId, creditSupportAgreement, parties- have been omitted.)
![]() |
|
![]() |
|
![]() |
|
![]() |
|
![]() |
|
![]() |
|
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.
![]() |
|
The elements are:
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>
![]() |
|
Net Treatment
For a net treatment, the following fields are required:
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:
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>
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.
![]() |
|
![]() |
|
The available fields within dailyInterestCalculation are:
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>
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.
![]() |
|
The main components of this message are as follows. (Structures that have been covered earlier -such as header, correlationId, creditSupportAgreement- have been omitted.)
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.
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>
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.
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.
![]() |
|
The main components of this message are as follows: (Structures that have been covered earlier -such as header, correlationId, creditSupportAgreement, parties- have been omitted.)
![]() |
|
<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 |
---|