Risk Participation Agreement

Table of Contents

A risk participation agreement protects the credit of a swap counterparty. ORE models it with the trade type RiskParticipationAgreement. This note records the domain grounding, as ORE documents it in its product catalogue.

1. Identifiers

What a trader books it as, and what to grep for. The codes are the trade type catalogue's, which is what the database enforces.

Field Value
Full name Risk Participation Agreement
Short name RPA
ORE Studio product code RiskParticipationAgreement
Asset class credit
Family none; see below
ORE trade data node RiskParticipationAgreementData
ORE documentation rpa.tex

2. Summary

A risk participation agreement (RPA) is a credit derivative between two counterparties. The protection buyer pays a premium. In return, the seller covers a share of the liabilities of an underlying swap when its payer defaults. The share is the participation rate. The protection runs for a defined period, often the life of the underlying swap. The premium can be one upfront payment or a series. The product transfers the credit risk of a derivative exposure.

3. Detail

3.1. What it is

ORE defines the product as follows:

A RPA is a credit derivative between two counterparties. The protection buyer pays a premium to the protection seller.

Source: ORE User Guide, Products catalogue, rpa.tex.

In return, the seller agrees to pay a percentage share of the liabilities of a referenced underlying swap transaction. The share is the participation rate. The liabilities fall on one counterparty of that transaction, the reference entity, in case of its default. The protection is granted for a defined period, which often coincides with the lifetime of the underlying swap. In case of a credit event, premiums due after the event are cancelled.

3.2. In plain terms

An RPA is insurance on a swap counterparty. One bank enters a swap with a client and wants protection if the client defaults. Another party takes a share of that credit risk for a fee. The client's swap itself stays untouched.

3.3. How it works in ORE

The trade uses a RiskParticipationAgreementData block. It holds a ParticipationRate and the protection window, from ProtectionStart to ProtectionEnd. The CreditCurveId names the reference entity. A FixedRecoveryRate makes the trade a fixed recovery RPA. A ProtectionFee block holds one or more legs for the fees paid by the protection buyer. An Underlying block carries the legs of the underlying swap, or the Treasury-Lock data that the contract references.

The direction follows the premium leg. Payer true means protection is bought and the fee is paid. Payer false means protection is sold and the fee is received. If the reference entity defaults, the protection buyer receives the present value of the underlying if this value is positive. The underlying value is computed with the payer and receiver flags of its own legs.

3.4. Mathematical notes

The protection is a credit product on the value of a swap. At default, the seller pays the positive present value of the underlying times the participation rate. The fee pays on the premium leg until the credit event or the end of the window. After a credit event, the remaining fee payments are cancelled.

3.5. What moves its value (static sensitivities)

  • The credit curve of the reference entity. It prices the default risk.
  • The underlying swap. Its present value sets the protection amount, so rates and other underlying risk factors move the trade.
  • The participation rate. It scales the exposure.
  • The fee structure, upfront or running.
  • The recovery assumption.

A protection buyer gains when the reference entity's credit worsens. A seller gains when it improves. The trade carries a hybrid exposure, credit risk on a rates position.

3.6. How the profile ages (dynamic sensitivities)

The protection window runs to its end date, often the maturity of the underlying swap. The underlying ages like the swap it covers, so its present value drifts with the market. A credit event settles the protection and cancels the remaining premiums. Without one, the trade runs to the end of the window and stops.

3.7. Why a customer would want it

A bank shares the credit risk of its swap book without novating the trades. An insurer or another bank earns a fee for taking the risk. The product is a building block of counterparty credit management. In ORE Studio a customer books RPA to value them and run sensitivities on the ORE engine.

3.8. Example

ORE's catalogue shows a trade with an 80 percent participation rate:

<RiskParticipationAgreementData>
  <ParticipationRate>0.8</ParticipationRate>
  <ProtectionStart>2018-10-01</ProtectionStart>
  <ProtectionEnd>2038-10-01</ProtectionEnd>
  <CreditCurveId>RED:008CA0|SNRFOR|USD|MR14</CreditCurveId>
  <IssuerId>CompanyXZY</IssuerId>
  <SettlesAccrual>true</SettlesAccrual>
  <FixedRecoveryRate>0.6</FixedRecoveryRate>
  <ProtectionFee>
    <LegData>
      <LegType>Cashflow</LegType>
      <Payer>true</Payer>
      <Currency>EUR</Currency>
      <CashflowData>
        <Cashflow>
          <Amount date="2018-10-03">91171.72</Amount>
        </Cashflow>
      </CashflowData>
    </LegData>
  </ProtectionFee>
  <Underlying>
    ...
  </Underlying>
</RiskParticipationAgreementData>

Source: ORE User Guide, Products catalogue, rpa.tex, listing RiskParticipationAgreement Data (underlying abbreviated).

The example pays a one-off fee of 91171.72 EUR for protection on a 20-year window. The credit mechanics follow the Credit Default Swap family.

4. See also

Emacs 29.3 (Org mode 9.6.15)