Swap module setup

Swap module documentation

• SWAP Data Model
• SWAP.TYPE Overview (parameters)
• SWAP.PARAMETER Overview (parameters)
• Example of IRS deal capture (fixed/floating)
• Detailed Marked to market
• Impact of an IRS on FX Position
• Tips & Tricks on some strange messages / crashes

---

SWAP Data Model

Overview of tables implied in Swaps module implementation:

top

SWAP.TYPE Overview (parameters)

This module covers all Swap’s types of deals. Can be IRS (Inretest Rate Swap), CIRS (Currency and Interest Rate Swap), CDS (Credit Default Swap). Handle amortization of principal or notional. Compute NPV for IRS and CIRS, not for CDS. One of the first table to set for a first installation. Allows to attach to a code (type) of swap, defaulted properties to ease the deal capture. Example, for an IRS :

Have to be defined:

• Field 2 : The product category (here 29000) identifying this type in GL entries
• Field 6 : The balance sheet or off balance sheet type of the instrument.
• Fields 7 & 8 : Internal account used for NPV entries, (to balance the P&L entries Cf fields 12 & 12)
• Field 9 : Valuation method to be used
• Field 10 : Indicates IF NPV results have to be booked or not
• Fields 11 & 12 : P&L category codes to be used for NPV entries

NB : All theses values are defaulted on a deal capture. fields 2 & 9 can be amended on the deal capture itself.

top

SWAP.PARAMETER Overview (parameters)

Main table to be set up.

• Fields 1 to 8 : P&L categories for interest accruals.
• Field 9 : Transaction codes used for netted interest settlements (IRS)
• Field 10 : Accruals frequency
• Field 12 : For Swaps impacting the FX position (CIRS), categories to be used to book reevaluation entries. Theses P&L entries will balance with internal accounts definied in ACCOUNT.CLASS SWREVAL code.
• Fields 13 & 14 : Transaction codes used for P&L FX entries.
• Field 15 : link to PERIODIC.INTEREST key that contains market rates.
• Field 16 to 19 : Rate types to be used for short & long interest periods. (link to PERIODIC.INTEREST). NB : Short period = between valorisation & next interest payment date ; long period = between valorisation & following interest payment dates.
• Field 20 : P&L Broker commissions code
• Field 21 : Number of days after which matured deals swith to  the history file.

top

Example of IRS deal capture (fixed/floating)

Using a standard version such as SWAP,IRS, you get a tabbed deal capture screen such as:

Common part:

Field 17 refers to the mandatory SWAP.AGREEMENT field. Note that to be compliant with SWIFT confirmations, you must define an agreement in this table like this: “Convention name” “slash” “full date of agremeent signature” “double slash” “agreement type”. Example: ISDA/20011119//2001 means an ISDA agreement, signed with the counterparty on 19/11/2001, this agreement follows the type 2001.

Asset Leg (or interest receiving leg):

The bank is receiving a 3.3850 fixed rate quarterly: Field Date/Frequency contains next interest payment-IP (June 19th 2000) and the frequency for next IP “M03” (every 3 months) and “19” (the nineteenth) The “Convention” can be Preceeding (the process date is the first preceding business day.), Following (the process date is the next business day after the date of the schedule or Modified (the process date is the next business day after the date of the schedule providing this date does not fall into the next calendar month. In which case the process date is the first preceding business day.). ‘”Adjustement” (Period or Value) Depending on the date adjustment, the process date of the schedules and the interest effective dates are calculated.

Liability leg (interest paying leg):

The bank is paying a floating rate. Code “3” refers to MARKET.RATE.TEXT code storing:

• a description (compatible to 14F SWIFT 360-361 messages field)
• a link to the PERIODIC.INTEREST curve (+ currency code)
• Interest payments are equivalent to the asset leg. A rate reset event need to be defined for flaoting rate sides.

Settlement instructions:

SWIFT Confirmation:

 Example of message type MT-360 (single currency swap confirmation)

CANCEL / EARLY MATURITYYou can cancel (reverse) a Swap deal already authorised, even months after the initial input. Once a payment occured in the past, you can’t reverse it anymore. But you can always do an early maturity/redemption: to achieve this, remove all futures schedules and set a new maturity date [from today to whatever date in the future].

top

Detailed Marked to market

Main principle: a) Accrued interest amount between last IP and valorisation date b) Interest amount for next IP, calculated using:

	current fixed rate for leg 1
	current floating rate for leg 2
	with forward/forward rates for next IP on leg 2 - cf FRA revaluation. (Theses rates are computed from short & long term rates know at valorisation date)
 Short period= between valorisation & next IPdate 
 Long period= between valorisation & following IP dates

c) Actualisation of interest amounts calculated in b), using zero coupon rates deducted from the market rates curve. Most of IRS deals have a maturity greater than one year, thus an actuarial actualisation type willl be used:

d) Sum of actual interest from each leg to get final NPV of a swap deal.

Complete example of IRS pricing is detailed in attached document:

top

Impact of an IRS on FX Position

An IRS in foreign currency is updating FX position with: – daily accrued interest, @ today’s currency rate. – Net of (yesterday’s – today’s NPV) booking entries, @ an average rate between today and the previous day recalculated fot the net difference amount. This is fully explained in below example:

top

Tips & Tricks on some strange T24 messages or crashes

• When you get: INVALID ACCR.TO.DATE (20101129) OR ACCR.FROM.DATE (20101130) CONTRACT SW10xxxxxxxx

Just check if your Rate Reset has been correctly updated and is not out of date.  If not, change manually the RR with a date in the future. It should fix your problem. In the command line, you can launch SWAP.BALANCES.CHECK (only available in classic). You will then get an audit of all your swap deals. Following checks are performed:

1. That any schedules which have happened (i.e. a PROCESSED.DATE  is present on the SWAP history) are on the SWAP.BALANCES file.
2. That the SWAP.BALANCES records are actually present
3. That the accrue from dates are set to the first of the month, or set to the date of a schedule.
4. That the accrue from dates follow on from the previous accrue  to date.