Position classes are the most basic definition for types of events or activities relevant in the management of position risk. For example, a single position class can define principal movements at the beginning of loans and deposits. The Position Management application assigns all business activities recorded in Temenos Transact to a position class. This identifier is then used when building the customised position management reports and enquiries to allocate the activity to its correct position.

A position class is a five digit alphabetic code, which identifies a specific type of position activity in terms of:

• Originating application
• Type of application specific movement
• Type of account related movement

The first two characters always reflect the application where the business is booked. The remaining three characters identify the activity.

System defines the Position classes in a number of the older Temenos Transact applications, however, parameter tables defines the newer applications.

Users setup PM.POSN.CLASS table to identify all the individual activities for each relevant Temenos Transact transaction, each with a unique ID and description. This unique ID can be appended to individual activity records and referenced by other programs (as appropriate) in the construction of enquiry records.

Usually, each time a user inputs a contract in Temenos Transact, several position activities are generated with an associated position class for each.

For example, a MM loan consists of three main activities in PM:

Principal at the start of the contract	Outflow of funds
Principal at the maturity of the contract	Inflow of funds
Interest at the maturity of the contract	Inflow of funds

Each of these components are broken down into two main types:

• Application specific, where rates are taken from the contract.
• Accounts related, where rates are taken from the accounts to which the movements are booked.

The PM.PARAMETER file indicates which applications are to be included in the PM processing and whether or not deal or contract files that are already in existence are to be included in the overnight rebuild of PM data.

PM related processing occurs for an application only if its product is included in the Appln Incfield of PM.PARAMETER. To know more information on inserting a product in this field, refer to PM.UPDATE.APPL.

After inserting a product in the Appln Inc field, the Appln and Proc Code fields need to be updated for the relevant applications whose products are included for PM processing. For applications not linked to PM using the generic interface, the parameters specified in these fields determine the regeneration of PM.TRAN.ACTIVITY records during batch processing. For applications linked to PM using the generic interface, in addition to the value specified in these fields, the parameters defined in the PM.APPL.SELECTION application determines the maintenance of PM.TRAN.ACTIVITY records during batch processing.

It is possible to switch off the generation of the PM.TRAN.ACTIVITY and PM.DRILL.DOWN records for environments which have high volume low value transactions in either Funds Transfer or Teller applications.

Enquiries for high volume modules cannot be drilled down to the transaction level detail.

The Hvl App field in PM.PARAMETER is used to control this functionality, and the valid options available are:

• Null
• FT
• TT

This application enables addition or deletion of a Temenos Transact product for PM processing by inserting or deleting the Product ID in the Appln Inc field of the PM.PARAMETERtable.

The ID of PM.UPDATE.APPLaccepts either ADD or DELETE value. The Application fieldaccepts any valid product. To enable PM processing:

• For an application, specify its product in the PM.UPDATE.APPL record with ID as ‘ADD’.
• For an already enabled product, specify in the PM.UPDATE.APPL record with ID ‘DELETE’.

During batch processing,the products specified in the records with ‘ADD’ and ‘DELETE’ IDs are inserted or deleted in the Appln Incfield of PM.PARAMETER, respectively. Since the PM.UPDATE.APPLrecords are processed daily during batch, it is essential that these records are reversed after they are processed during the batch.

This table defines a series of generic three character position types. It is currently only used for the PD.PAYMENT.DUE (PD) module but is intended to be used widely as new modules, which have interfaces to PM developed.

An example of a position type is Principal at Maturity (PAM). The position class generated for PD is PDPAM.

This table allows the user to define the parameters governing the rules for handling the cash accounts (ACCOUNT application) in the Position Management module, and for online updating of accounts using all cash transfer applications. For example, FUNDS.TRANSFER, TELLER, DATA.CAPTURE, MM.MONEY.MARKET, LD.LOANS and DEPOSITS.

Different treatment and reporting of types of account can be defined. Account types are split by the category of the ACCOUNT record using Category From and Category To fields.

This table defines the parameters for generation of account and Forex (FX) related position movements in PM.TRAN.ACTIVITY, for module or applications linked to PM module using the generic interface.

• For the PD module (Record ID: PD), this table defines the applicable generic position types and an associated character that is used to identify any account related movements for each position type.
• For the modules such as, DATA.CAPTURE, FUNDS.TRANSFER, POR.TRANSACTION and TELLER, which are linked to PM using the generic interface needs to have one record at module level with ID as DC, FT, TT and POR.TRANSACTION (Payments), respectively.
• For applications in other modules linked to PM using generic interface (Applications in modules other than FR, FX, LD, MM, ND, PD, SC and SW) needs to have one record for each application.

An example for PD is as follows:

An example for POR.TRANSACTION is as follows:

In this case, the accounts related position class generated for PAM is PDxxP, where xx depends on the setup of PM.AC.PARAM.

An example screen shot for the DRAWINGS application (linked to PM using the generic interface), is shown above.

In this case, the accounts related position movement generated for DRAWINGS and its Position Class can be as follows:

‘DRxxP’ where,

• ‘DR’ is the first two characters of the application.
• ‘xx’ depends on the parameter defined in PM.AC.PARAM.
• ‘P’ is the Acc Mvmt Char specified for a Transaction Code ‘yyy’ provided the transaction code in the transaction’s statement entry is ‘yyy’.

If the value of Acc Mvmt Char is not specified, then the parameters defined is used.

The Real Fx Class, Fwd Fx Class and Fwd Fx Prg Cnt fields are used to specify the parameters related to FX position movements, for the applications linked to PM using generic interface. The following fields are used to specify the position class:

• Real Fx Class for FX positions created by real accounting entries
• Fwd Fx Class for FX positions created by forward (cash-flow) entries

Further, the Fw Fx Prg Cnt field can be used to specify whether FX position movements for forward (cash-flow) accounting movements need to be generated in PM.TRAN.ACTIVITY, and it could have the following values:

• NO – No FX forward position details are generated.
• YES – FX forward position details are generated.
• APPLIC – Application determines the need to generate forward position movement details.

The PM.TRAN.ACTIVITY records which are generated based on the parameters in PM.PC.PARAM is formed with IDs of ‘Transaction ID*REAL’ and ‘Transaction ID*FWD’, depending on whether the position data is generated from real or forward (cash flow) accounting entries. However, only for PD module, PM.TRAN.ACTIVITY records would continue to be generated with ID equal to Transaction ID.

An example screenshot for the POR.TRANSACTION application (linked to PM using the generic interface) is shown below.

This table defines the parameters governing the rules that processes the contracts of LOANS AND DEPOSITS (LD) application. This is performed by specifying the range of category codes identifying LD contracts, and the PM.POSN.CLASS IDs allocated to each activity.

For example, classes are related to principal at start date, principal and interest at maturity date, and any principal increases or decreases applied to the contracts. Similarly, it defines amounts of commissions and charges, and taxes.

This table defines the bank's portfolios (both trading and investment) that needs to be considered for PM. It shows how different types of security are treated depending on the date or period applied to the various activities. It additionally provides an option of choosing market or input rates to be applied against the portfolios, facilitating price valuations to be included in PM.

Following is the functionality of the Incl Redeem Pri field:

If the field is set to Yes,

• YTM calculation considers the redemption price (Redem Price in SECURITY.MASTER), which is different from Par Value. This calculated YTM rate reflects in the Interest Rate Gap (IRG) report.
• Maturity value of a Fixed Rate Bond in Cash Flow enquiry will be at the redemption price (Redem Price in SECURITY.MASTER) of the bond, which is different from the Par Value.

If set to No or None,

• It does not consider the redemption price (Redem Price in SECURITY.MASTER) in the above mentioned case.

This table defines the parameters to govern the rules that handles processing of Interest Rate Swaps. This is performed by linking the Swap Schedule types with the PM.POSN.CLASS IDs allocated for each activity.

Each schedule type denotes a business event in the trade cycle.This is done by assigning a PM.POSN.CLASS ID, which results in defining the types of events or activities relevant to the management of position risk.

TheTrade Gapfield determines whether the trade type of contracts can be included in PM reports.The Pm Max Period field controls the period for which the projection for swap deals in PM reports is required. The above setting shows an input of 60 (60 months or 5 years). This option helps in reducing the input overhead of creating data that is not used.

The Amort Sched Rr field provides an option to deal with the projection of an amortisation schedule of an asset or liability with floating rate in Interest Rate Gap (IRG) report in two ways.

If this field is set to Yes, the projection of residual principal amount on the floating rate leg- side displays on the next rate fixing (insert foot note) or resets the date as a single amount in the IRG report, instead of amount amortised during each bucket with interest rate same as current period.

If the option is set to No or None, the projection in IRG on Liability Amount is same as it is shown in Asset Amount column, that is, each amortised notional amount is shown against the future time buckets with interest rate projected same as the one applicable for current period.

This table with ID as SYSTEM is setup to update the files of PM module for trade and hedge types of derivative transactions.

• GAP and FXP positions in PM module is updated for financial future trades (such as, interest rate, currency, and bond futures) done for own book hedge transactions.
• CAS is updated for all transactions irrespective of own book or otherwise.

All hedge type transactions updates PM files by default, while inclusion of trade type transactions is optional.

To generate GAP movements in PM.TRAN.ACTIVITY for applications attached to PM using generic interface (applications in modules other than DC, FR, FT, FX, LD, MM, ND, PD, SC, SW and TT), two parameter files are used. The first one is PM.APPLICATION.PARAM, which is used to define the conditions for grouping transactions input in an application.  Records in this parameter file can be defined with an application name as its ID (that is, LETTER.OF.CREDIT, FD.FIDUCIARY, and so on).

For example, a sample setup of PM.APPLICATION.PARAM for DRAWINGS is as follows:

In the above screenshot, the transaction group (Pm Group Type field) with value ‘DISCEXP’ gets returned for generating the GAP position movements provided the conditions defined for this Group are satisfied. If more than one transaction group condition is satisfied, all those groups would be returned for generating the GAP position movements.

Complex conditions can be defined using the Rel Next Fd field, and prioritised using the Brackets Op and Brackets Cl fields.

The Multi Val Driv field (if required) helps to generate GAP position movements for each multi-value set in an application.

The Replace File and Replace Fld fields can also help validate the field values from another related application (if required).

This table is the second parameter file used for generating GAP position movements for applications attached to PM using generic interface. A record can be defined in this table, as follows: 

• For each transaction group defined for an application in PM.APPLICATION.PARAM.
• With an ID format ‘Application*Group.Name’, where the ‘Group Name’ is a valid transaction group (value of the Pm Group Type field) in the PM.APPLICATION.PARAM record.

For example, a record ID in PM.GROUP.TYPE can be ‘DRAWINGS*DISCEXP’, where ‘DISCEXP’ is a transaction group field (Pm Group Type) defined in PM.APPLICATION.PARAM for the DRAWINGS application.

This table is used to map the transaction fields to the fields in PM.TRAN.ACTIVITY. It also allows to map a transaction group to more than one set of GAP position movement data to be generated in PM.TRAN.ACTIVITY.

The PM.TRAN.ACTIVITY records are generated based on the parameters defined in the PM.APPLICATION.PARAM and PM.GROUP.TYPE applications with an ID format ‘Transaction ID*GAP’.

For example, a sample setup for the DRAWINGS application and transaction group ‘DISCEXP’ for that application is shown in the screenshot below:

For each field in PM.TRAN.ACTIVITY, a value can be directly mapped from a field in theapplication.It also allows to mapthe values after processing using pre-defined operators DEC or CAL or REP.  The operators are specified with a tag name separated by ‘*’ (For example, ‘DEC*ASST.LIAB’) in the ‘CAL’ fields, which are available next to the fields that needs to be mapped. The rules and tag names for the pre-defined operators (DEC or CAL or REP) can be specified in the multi-value sets Dec Type or Cal Typeor Replace Typedepending on the type of operator.

For example, the DEC operator can map the Asst Liab Cd field of PM.TRAN.ACTIVITY as follows:

• If the value of the Pri Buy Sell field is equal to Buy, it maps a value of ‘1’.
• If the value of the Pri Buy Sell field is equal to Sell, it maps a value of ‘2’.

This application is used to define the conditions for the maintenance of PM.TRAN.ACTIVITY records for applications linked to PM using generic interface (applications in modules other than DC, FR, FT, FX, LD, MM, ND, PD, SC, SW, TT), during batch processing. 

During batch processing, the first sets of fields in this application (from Open Bracketto Link To Nxt Fld)  defines the conditions to regeneratePM.TRAN.ACTIVITYrecords with GAP position movements (records with ID: ‘Transaction ID*GAP’). Hence, the PM.TRAN.ACTIVITYrecords for GAP movements is regenerated only for those transactions that satisfies the defined conditions. 

The second set of fields in the application (from Open Bracket to Mat Nxt Fld) defines the conditions to delete the PM.TRAN.ACTIVITY records for matured contracts. 

In the above screenshot, only for transactions satisfying the specified conditions would the PM.TRAN.ACTIVITY records with ID ‘Transaction ID*GAP’ be regenerated during batch processing.

The linkage between AA module for Loans and Deposits (LD) and PM grants inclusiveness to the data presented by PM to its users.

To enable the data inflow from AA, the system requires no changes on PM side for the following reasons:

• Framework is generic.
• Design of AA PM link is different from other modules.

This is mainly because of the architecture and flexibility that AA offers in building products and product conditions.

This application enables to introduce movements deriving from transactions not supported by the applications that are currently available in Temenos Transact or other third party or manual systems. In other words, it allows to update the PM directly (without generating any accounting entries), which otherwise are not handled by the applications that are interfaced to PM. The update is a manual effort and the transaction data is from a system external to Temenos Transact, thus,the user needs to ensure when updating the movements in PM application.