This section provides a detailed description of the product architecture for ‘Repo’. Support for REPO and associated mid life events have been introduced in FpML version 4.3.
The Business Process scope includes confirmations, valuations and reporting.
In the next phase, the working group will look at Security Borrowing/Lending.
In ‘Repurchase Agreement’ or ‘Repo’, the Repo Seller sells securities now, in return for cash to the Repo Buyer, and agrees to repurchase those securities from the Repo Buyer at a later time for the original cash amount and an additional sum, determine by the repo rate.
A Reverse Repo is a Repurchase Agreement described from the Repo Buyer's perspective.
In a Repo there is the transfer of ownership of the securities from Repo Seller to Repo Buyer, but without any economic loss on the underlyer - coupons on the securities get directly passed on to the Repo Seller.
Repos are short term instrument.
Repo versus Sell/Buy Back (Reverse Repo versus Buy/Sell Back): A Repo is technically a single transaction while a Sell/Buy Back is a pair of transactions (a sell and a buy). Any coupon payment on the underlying security during the life of the Sell/Buy Back will generally be passed back to the seller of the security by adjusting the cash paid at the termination of the Sell/Buy Back. In a Repo the coupon will be passed on immediately to the seller of the security.
Repo versus Security Lending: Securities Borrowing/Lending is typically done to temporarily obtain the security for other purposes, such as covering short positions or for use in complex financial structures. Securities are generally lent out for a fee.
Other useful links: TBC
As with all products in FpML the Repo is accessed through a global element ‘repo’ which can substitute the 'product' element used in the construction of trade structures. The following diagram outlines the product structure.
The 'Repo' structure only defines parameters for product related information (e.g. dates, rates, underlying assets, midlife events etc.) other trade related information (e.g. trade date, identifiers, legal documentation, etc.) is held in the containing trade structure and is not specific to Repo.
A simple Repo contains two legs, one spot and one forward leg (the forward transaction must be specified, unless the Repo is open ended) and are described later.
The fixedRateSchedule element specifies the repo rate initial value. The rate can change during the life of the repo. The changes are expressed through the step element. In case of with Sell/Buy Back, the cardinality for the step element is always ‘0’ as in this case the initial value will not change.
The ‘floatingRateCalculation’ element is used to detail a floating Repo rate. In Europe, EONIA is the most commonly used floating index for Repos. Sell/Buy Backs do not have floating repo rate. The floatingRateCalculation element is reusing the IR’s ‘FloatingRateCalculation’ structure. In most case, ‘floatingRateIndex’, ‘indexTenor’ and ‘spreadSchedule’ structures will be used.
The 'dayCountFraction' element is of type 'DayCountFraction'. It uses the 'dayCountFractionScheme' scheme of values for specifying how the number of days between two dates is calculated for purposes of calculation of a fixed or floating payment amount and the basis for how many days are assumed to be in a year (e.g ACT/356.FIXED).
The 'noticePeriod' element is of type 'AdjustableOffset'. It uses relative values to expresses the number of days to give notice for the second leg of a repo.
(For example: noticePeriod = 2 'Business' days subject to holidays applicable in referenced business center.)
Notice period for open ended or long dated repos in number of days.
The possible values for the ‘duration’ element of type ‘RepoDurationEnum’ (an enumeration) are:
Overnight -indicates that a contract is classified as overnight, meaning that there is one business day difference between the start and end date of the contract. Business rule: When the repo is overnight, the number of business days between the spot and forward value dates must be one. Forward leg must be specified.
Term - indicates that a contract is a regular term contract, with a start date and an end date. When the repo is 'Term', both spot and forward legs must be specified..
Open - indicates that a contract is open ended; this means that the end date is unspecified, and will be agreed by the two parties at a later date. When the repo is Open, the forward transaction leg must not be present.
The ‘margin’ element of type ‘Margin’ - defines the margin, also called haircut in repo and securities lending terminology, that will be applied to a transaction. It is essentially a premium, expressed in percentage, to compensate collateral quality (or lack thereof) and liquidity.
‘marginType’, an enumeration with possible values 'Cash' and ' Instrument', is the type of margin being specified to apply to the transaction.
‘marginFactor’ which is a multiplication factor to reflect the quality of the collateral (default value is 1). Also called margin ratio as per Section 2, paragraph (z) of the TBMA/ISMA Global Master Repurchase Agreement.
The 'spotLeg' is of type 'RepoTransactionLeg'. The spot leg, i.e. the transaction that will be executed on the settlement date of the contract.
The parties of the repo are expressed using the 'BuyerSeller' model which specifies the 'buyerPartyReference' and 'sellerPartyReference' and references to the buyer and seller of the repo contract.
The role of the remaining elements is as follows:
The Settlement.model group has cash settlement elements and includes: The 'settlementDate' and ‘SettlementAmountOrCurrency.model’. The 'settlementDate' structure supports either the definition of dates as either a series of unadjusted dates along with a date roll convention and business center list for adjustment, or as set of adjusted dates relative to some other date schedule defined elsewhere in the product (e.g. in the ‘forwardLeg’). The ‘SettlementAmountOrCurrency.model’ group uses either ‘settlementAmount’ structure of ‘Money’ type where the settlement amount and currency are explicitly expressed, or the ‘settlementCurrency’ structure for use where the Settlement Amount cannot be known in advance.
The ‘collateral’ element type ‘CollateralValuation’ is used to carry the quantity and price details that are required to ensure that a repo contract is executed at fair value, with the value of the collateral matching the cash amount of the repo. Collateral is declared as optional here, with multiple cardinalities, since we can do a repo "Multi", with multiple instruments specified, or a "Cash Borrow/Loan" and “TriPartyRepo” with no collateral. In general cases, however it should be specified.
The 'forwardLeg' is of type 'ForwardRepoTransactionLeg'. The forward leg of the repo contract, i.e. the repurchase transaction.
As with the 'spotLeg', the buyer and seller parties are explicitly indicated in the 'buyerPartyReference' and 'sellerPartyReference' of the 'BuyerSeller' model. Note that the BuyerSeller model in this transaction must be the exact opposite of the one found in the 'spotLeg'. The 'forwardLeg' transaction must be specified, unless the Repo is 'open ended'.
The role of the remaining element is as follows:
The ‘repoInterest’ is basically the difference between the settlement amounts at spot and forward date. It is a fully figured amount, but it does not have to be specified in the message. It is not a 'Money' amount as it is implicitly expressed in the settlement currency.
The optional 'midLifeEvent' element of the ‘MidLifeEvent’ type - is a placeholder for Repo’s mid life events that occur during the lifetime of the Repo.
Midlife events include:
A global element ‘cashRepricing’ of type ‘CashRepricingEvent’ - is representing a collateral substitution. ‘CashRepricingEvent’ structure is an adjustment of the price of the underlying collateral done to reflect current market conditions. The par amount is preserved constant, which means that the collateral quantity is unchanged. It is the settlement amount that changes after cash repricing, so a cash repricing will trigger a cash movement.
A global element ‘collateralSubstitution’ of type ‘CollateralSubstitutionEvent’ - is representing a collateral substitution. ‘CollateralSubstitutionEvent’ structure is used by Buy/Sell Backs trades to describe when a coupon is paid and what reinvestment rate will be applied. The amount is in the instrument currency. To be able to represent a Buy/Sell Backs with more than one collateral we use a ‘href’ link to the underlying asset. This enables us to represent multiple coupons during the life of the trade, with different reinvestment rates, and possibly different instruments.
A global element ‘couponEvent’ of type 'CouponEvent’ - is representing a coupon event. ‘CouponEvent’ structure is used for Buy/Sell Back trades to describe when a coupon is paid and what reinvestment rate will be applied. The amount is in the instrument currency. To be able to represent a Buy/Sell Backs with more than one collateral we use an ‘href’ link to the underlying asset. This enables us to represent multiple coupons during the life of the trade, with different reinvestment rates, and possibly different instruments.
A global element 'interestPayout’ of type ‘InterestPayoutEvent’ is representing an interest payout. ‘InterestPayoutEvent’ structure is used the amount to be paid. Note that we do not specify who is paying the amount. Implicitly, the party that pays the Repo Interest at maturity is the only party that can do an interest payout. When necessary, it is possible to make the interest payout fully explicit, with parties and settlement instructions. Note that the ‘transfer’ date may differ from the ‘eventDate’ specified by the event; for example the date the payment is made can be 1 or 2 days after the interest has been calculated. Note that for an interest payout the transfer can only contain a ‘cashTransfer’ as there are no security movements for an interest payout.
A global element 'markToMarketEvent' of type 'MarkToMarketEvent' – is Global element representing a nominal repricing. A mark to market event. This type of event is an adjustment of the price of the underlying collateral done to reflect current market conditions. Depending on the direction of the collateral valuation, one of the contracting parties will either pledge more/less collateral in the contract, or add/substract cash from the contract value.
A global element 'rateChange' is a mid life event where on a given date, the Repo rate to apply is changed as a result of a bilateral agreement between the two parties. There is no cash or security movement associated with a rate change. The repo structure allows you to specify repo rates as a schedule, so this type is not strictly required within the repo. We need it for consistency and to allow a discrete event message to declare a rate change on a trade.
A global element ‘rateObservation’ type of ‘RateObservationEvent’ is representing a rate change. ‘RateObservationEvent’ structure is used only when a Repo is done against an index (typically EONIA Repos) and we want to record the observed rates during the lifetime of the trade. This is similar in structure to a rate change, but the application context is different. A rate observation has no cash or security movement attached, so there is no transfer structure here. Rate observations are required on floating rate Repos to calculate the accrued Repo Interest.
Most Repos are done using Bonds and Bond subclasses as collateral. However, it is technically possible to execute a repo on equity as long as the mark to market is correctly done during the lifetime of the repo.
The ‘bond’, ‘covetableBond’ and ‘equity’ elements are used to substitute for the ‘underlyingAsset’ element of the ‘UnderlyingAsset’ type and are defined in fpml-asset-4.2.sxd.
Please see examples in the /repo/examples/ directory
Previous | Top | Next |
---|