The SWAP.TYPE file has definition of all types of swap contracts handled by the system. 

For example, IRS, CIRS and so on.

The file has the following information required for the deal:

• Description of the SWAP.TYPE
• Product category code and product category hedge for trade and hedge type of deals
If you specify the category code on either one of the fields and leave the other one blank, then the system will apply the mentioned category code on both the fields, irrespective of the trade type.
• Transaction index to indicate the characteristic of the swap in single leg transaction, such as deposit or loan
• Balance sheet to indicate whether the swap can be treated as on balance or off balance sheet instrument
• Internal category code for the provision of unrealised profit or loss generated by revaluation
• Revaluation type
• Booking of unrealised profit required or not
• P&L category for revaluation profit or loss
• Option to process the deal in Start of the day (SOD) instead of Close of Business (COB)
• If the deal should be processed and limits to be updated during SOD (instead of COB)

The examples below illustrate IRS and CIRS SWAP.TYPE:

There are two other standard SWAP.TYPE records released with this module, which cater to simple loan and deposit contracts:

• LOAN –  Asset side of swap
• DEPOSIT – Liability side of swap

The following example illustrates the Loan in SWAP.TYPE:

The following example illustrates the Deposit in SWAP.TYPE:

This file defines the schedules permitted in a swap contract. The first two characters of the ID determine the type of schedules. The schedule type are fixed and the details are given below:

Below is an illustration of SWAP.SCHEDULE.TYPE record:

Different schedules can be added but the first two characters must be one amongst the above-defined codes. For each schedule defined, the following associated information are held:

• Description of schedule
• Transaction code to be used on entries (mandatory except: CI, CM, NR, RL and RR. If IS, it needs to be unique)
• P&L category code (Mandatory: if PM, RV or IS)
• Charge codes
• Fee codes 

SWAP.AGREEMENT.TYPE file stores different types of agreements used in swap contracts, for example, ISDA, BBAIRS, and MASTER, and so on. Every contract is linked to an agreement type and the agreement type that is linked, is validated against the definition on SWAP.AGREEMENT.TYPE file and enriched with the associated description. Swift confirmation messages (that is, MT 360 and MT 361) require this information to be exchanged with the counterparty.

The module has few swap agreement type records and they are:

• ISDA – ISDA Definition
• OTHER – Specific to products, such as simple loan and deposit contracts 

This file holds the system level parameters for the processing of swap transactions, in a single SYSTEM record. This is the highest-level file within the Swap module and is set up before any data is entered into the module. The SYSTEM record consists of the following:

• Interest income accrual categories
• Interest expense accrual categories
• Additional data such as transaction code to use on net payments, date and frequency of accruals and categories of upfront allocation of P&L

The allowed values in the Mat Payment Date field are Yes, No and Null. Validations for No and Null are the same.

When set to Yes, it specifies whether the value date (payment date) for the schedules that fall on a maturity date (being a weekend or a holiday) should be updated with the next or previous working day.

• The value date moves to the next working day when Day Convention is set as Following or Modified (if the last day of the month is a working day) and Date Adjustment is set to Period.
• The value date moves to the previous working date, if the last day of the month is a non-working day and if Day Convention is set as Modified with Date Adjustment set to Period.
• The value date moves to the previous working day when Day Convention is set as Preceding and Date Adjustment is set as Period.
• The value date remains on same maturity date, if Date Adjustment set as Value.

When set to No or None, it specifies that the value date (payment date) for the schedules that fall on the maturity date along with interest calculation should be updated till the same maturity date of the deal currency when the maturity date of the Swap contract is a holiday.

This functionality is applicable only for the schedules that fall on the maturity date, provided Day Convention is set as Following or Modified or Preceding.

The interest calculation logic takes place based on the Mat Int field setup.

The Mat Int field has Include, Exclude, and None as allowed values. It decides the interest calculation logic for the Swap deals which has Date Adjustment set as Period and Day Convention set as Following or Modified (if last day of month is working day) only when the Mat Payment Date field is set as Yes in SWAP.PARAMETER.

• When set to Exclude or None, it follows the existing logic of interest calculation where the interest for additional days is not considered, with the Mat Payment Date field set to Yes. Default value is None.
• When set to Include, it follows the interest calculation logic where the interest for additional days is taken into consideration, with the Mat Payment Date field set to Yes.

The Mat Payment Date field in SWAP application defaults from SWAP.PARAMETER with an option to override the same.

Defer Ol PM Upd and Defer Ol Sched Acc fields help to improve the deal recording time during input and modification of swap contracts. If set to Yes, generation of data related to Position Management and Accounting entries are separated from deal capture and handled using an online service in near real time.

SWAP.ACTIVITY file controls the delivery output on SWAP module. The records on this file define activities that produce delivery output. These activities relate to specific events during the life of the contract. The delivery relating to each of these events can be produced prior to the event (if required). The number of days prior to the event is defined on this file.

Whenever delivery output is generated using the SWAP module, the activity code of the relevant advice is recorded on the contract. When the contract is subsequently viewed, these activity codes are displayed and enriched with the description recorded on this file.

The ID of the file is a three-digit code that represents the following activities:

A sample SWAP.ACTIVITY record is illustrated below:

This file controls the output of delivery messages for a SWAP.ACTIVITY. The record key is SWAP.ACTIVITY-SWAP.TYPE (the latter being optional). For example, 101 or 101-CIRS. 

A SWAP.ADVICES record is linked to another defined SWAP.ADVICES record and can define multiple message types, print formats and deal slips. This can help to customise the output of a swap activity.

The following details are held for each SWAP.ADVICES:

• Description of advices to produce
• Use linked SWAP.ADVICES record
• Message type to produce (DE.MESSAGE)
• Delivery print format
• Optional deal slips to produce

This table plays an important role in SWAP module and is referred in the following instances:

• The key defined in Floating Interest field is a record in MARKET.RATE.TEXT table, which refers to PERIODIC.INTEREST table. The usage of Floating Interest field is to capture the floating rate index and populate in Swift confirmation messages. This field is referred by the ST.GROUP.FIX application for automatic fixing the floating leg rate periodically.
• Rates are defined within PERIODIC.INTEREST for each type of floating rate that is required. For example, three month LIBOR and six month LIBOR are setup as two different records within PERIODIC.INTEREST. For example, 07USDyyyymmdd can represent the three month LIBOR rate and 08USDyyyymmdd can represent the six month LIBOR rate for the same system date.
• Each record needs to have one entry other than the Rest entry.  If the table has more than these two entries, only the first value (by nearest date) is used; the second and any other subsequent values are ignored. The same reference key is also used in floating rate reset using ST.GROUP.FIX application for multiple contracts meeting the criteria.
• The key defined in Fwd Rate Key field in SWAP application refers to the spot interest rate curve. This key is used in deriving the cash flow amounts on the floating leg side of the swap. These derived cash flows are used in swap revaluation process.
• The key defined in Coupon Curve Rate field in SWAP.REVAL.PARAMETER table represents a coupon curve which is bootstrapped to build a zero coupon curve for discounting the cash flows of the swap to arrive at the net present value of the swap. The key also represents a zero coupon curve which can be used straight away to discount the cash flows. Whether the key represents a coupon or zero coupon rate curve is denoted by another field in SWAP.REVAL.PARAMETER, that is, Zero Coupon Rate.

The system allows up to 99 different types of rate sets per day for each currency. 

This is a core table that allows the user to define the rules relating to accrual methods, such as First day, Last day and Both. It also allows to define a principal effective date calculation routine, which is applied in the Eb Accrual Param field of SWAP application.

All the fields related to Swap revaluation are grouped under this table, in a single system record. The system record has the following:

Revaluation related data, such as P&L category for currency revaluation, revaluation transaction codes, coupon curve rate, periodic interest rate Indices, discount formula, NPV related fields and zero coupon rate methods.

Following are the important fields in SWAP.REVAL.PARAMETER: