The following parameter tables are required to generate the Position Management (PM) data:

PM.POSN.CLASS
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.

These classes are straightforward and defined by PM.POSN.CLASS
application in Temenos Transact.
Some applications have a separate parameter file holding position classes specific to them.
A Position class is allocated to each application specific activity.
MMMPS | Money Market Principal Start |
MMMPM | Money Market Principal Maturity |
MMMIC | Money Market Interest Capitalisation |

Applications allocate Position classes as follows:
Module | Parameter Table |
---|---|
LD | PM.LD.PARAM
|
SC | PM.SC.PARAM
|
SW | PM.SW.PARAMETER
|
PD | PM.PC.PARAM - PD.AMOUNT.TYPE
|
FX | PM.PARAMETER
|
AA Deposits and Lending | AA.PRD.DES.REPORTING
|
DX | PM.DX.PARAMETER
|
Asset and Liability | PM.PARAMETER
|

The following applications have predetermined account class definitions:
Application | Description | Class |
---|---|---|
MM | Contract Start | MMMPS |
MM | Contract Maturity | MMMPM |
MM | Principal Increase | MMMPI |
MM | Principal Decrease | MMMPD |
MM | Interest Decrease | MMMID |
MM | Principal at Rollover Period Maturity | MMMRM |
MM | Principal at Rollover Period Start | MMMRS |
MM | Interest Capitalisation | MMMIC |
MM | Tax on Interest | MMMIT |
FX | Notional Principal Interest Hedge Start (Buy and Sell) | FXIHS |
FX | Notional Principal Interest Hedge Maturity (Buy and Sell) | FXIHM |
FX | Forward Interest Hedge Start (Buy and Sell) | FXINS |
FX | Forward Interest Hedge Maturity (Buy and Sell) | FXINM |
FRA | Contract Maturity | FRFRM |
FRA | Contract Start | FRFRS |
FRA | Contract Maturity Loan Side | FRXLM |
FRA | Contract Maturity Deposit Side | FRXDM |
FRA | Contract Maturity Net Loan and Deposit | FRXNM |
FRA | Pre-Start Date Loan | FRXLS |
FRA | Pre-Start Date Deposit | FRXDS |
FRA | Pre-Start Date Net Amount | FRXNS |
FRA | Notional Principal Start | FRNPS |
FRA | Notional Principal Maturity | FRNPM |

The user assigns Account related position classes to a category code range and movement type associated with it.
It is possible to define more than one PM.AC.PARAM
record, if necessary. For example, to setup different spreading characteristics for the same range of account categories.
The PM.AC.PARAM
application is used to define the category code ranges and associated position classes, which are of four types:

This position class relates to Account balances that include movements till the start of the working day grouped using ranges of category codes.
If it is necessary to differentiate the balance totals for enquiry purposes, a different position class is assigned to each range of category codes. For example, to group customer balances, shares and reserves, and separate Nostro balances:
Cat Code 1000 - 4999 | Customer Accounts | Position Class ACASC |
Cat Code 5000 - 5999 | Nostro Balances | Position Class ACBSC |
Cat Code 18000 - 18999 | Shares and Reserves | Position Class ACASC |
An option is available to spread the total using a range of defined calendar periods.
It allows to spread balances using a percentage amount to any future period.

The user can define a separate position class for online movements (that is, movements generated during the working day).
It is necessary to define an online movement, only (for enquiry purposes) to differentiate between the start of day position (class overnight) and accounting movements, which can be spread using value date that is initiated during the day.
If it is not necessary to do this, then this class need not be defined and the system uses the class overnight position class.

If the online spread class is defined, and it is necessary to report the actual value dates of the online movements for enquiry purposes, then this class needs to be defined.
If this class is not defined, then the class overnight is used to describe the movement.

This class is defined only when the accrued interest totals for the range of category codes specified needs to be reported for position management.

PM.PARAMETER
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

PM.UPDATE.APPL
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.PARAMETER
table.
PM.PARAMETER
cannot be updated online.
The ID of PM.UPDATE.APPL
accepts 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.APPL
records are processed daily during batch, it is essential that these records are reversed after they are processed during the batch.

PM.POSN.TYPE
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.

PM.AC.PARAM
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.




PM.AC.PARAM
Setup
For most installations, it is necessary to define one PM.AC.PARAM
record and to only use the class overnight position type.
It still allows to spread account balances over different periods, and any online accounts related activities to have their position class generated from the class overnight.
The basic objective in defining the accounts related position classes is to keep the setup simple for the following reasons:
- To reduce the amount of data generated
- To simplify the setup of the PM enquiries using
PM.POSN.REFERENCE
andPM.ENQ.PARAM
by reducing the number of accounts related position classes, which needs to be entered
1000 – 4999 | Customer accounts | ACASC |
5000 – 5999 | Nostro accounts | ACBSC |
18000 – 18999 | Shares and reserves | ACASC |
Initially, start off with a simple category code range split and complicate it only if required.

Splitting Nostros into primary and secondary types happen often in local currencies.
5000 – 5000 | Primary Nostros | ACBSC |
5001 – 5005 | Secondary Nostros | ACCSC |

The broker account balances need to be reported separately in certain enquiries, so they can be allocated their own position class.
1000 – 2699 | Customer Accounts | ACASC |
2700 – 3000 | Brokers | ACDSC |
3001 - 4999 | Customer Accounts | ACASC |
When the PM.AC.PARAM
records are changed, it is necessary to run a Close of Business (COB) before the new configuration becomes active.

To use in enquiries, different position class can be allocated for each category code grouping. The Class Overnight needs to be defined and used as the default value. If required, separate classes can be defined for online balances (Cls Online Actl), spread balances (Cls Online Sprd) and accrued interest (Cls Accrued Int).
Ensure not to include the below category codes:
- Contingency category codes (For example, Position Accounting or Limit related)
- Category codes in AA Deposits and Loan Accounts

This table is linked to PM.CALENDAR
(Calendar field), which defines the time splits to be used for reporting cash flow updates.
Balances can be spread over time (if required). This is achieved by using the Ccy, Bal Sprd Grp, Spd Grp Sign, Period Id and %Change fields.
Spread can vary according to currency and/or account balance sign.
If spreading of balances is not required, the setting on Period Id needs to be similar to the first defined split in the related PM.CALENDAR
record (that is, OPE or CAL), and the %Change needs to be 100.
Online transactions can be spread similar to the overnight balance or allocated to the value date on the transaction.
Only cash flow movements across accounts can be spread, and not maturity type movements.

The actual interest rate applying to an account is used for reporting or enquiry for an account type. However, for large volumes of accounts or spread balance, a group rate can be specified in the Prd Int Type field or basic interest rate using Flt Int Type field. If the actual rate is required, both the fields needs to be blank.

The user can specify (For example, in Internal FX Revaluation Accounts) that separate FXP type movements need to be raised from Account Balances during batch processing. These movements are raised only for accounts in local currency. The Lcy Fx Posn field specifies whether the associated Class Overnight needs to be used for generation of a FXP type movement. If this field is set to Yes, only a FXP type Position Class is specified in the associated Class Overnight

PM.PC.PARAM
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
andTELLER
, which are linked to PM using the generic interface needs to have one record at module level with ID asDC
,FT
,TT
andPOR.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
andSW
) 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.

PM.LD.PARAM
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.

PM.SC.PARAM
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.

PM.SW.PARAMETER
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.

PM.DX.PARAMETER
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.

The commissions or charges and realised P&L resulting from trade close out impacts the CAS positions. The system updates the following:
- CAS position in
PM.TRAN.ACTIVITY
with record ID ofDX.TRADE
. - Commissions and charges for both primary and secondary customers of the trades.
- CAS position for all the trades, own book or otherwise.

- The DX trades of type (Interest Rate Future) updates GAP position with the interest rate derived from the given Price field. Bond future updates the GAP position with the yield rate for Start Date and End Date fields.
- The Start Date is the First Delivery Date and the End Dateis the summation of Start Date and Life Underlying. If the First Delivery Date and End Date are holidays, system considers the next working day.

- The DX trades of currency future type updates the FXP position of both Delivery Currency and Contract Currency for the First Delivery Date. If the same happens to be a holiday, the next working day is considered.
It updates the positions when any amendment or settlement is done to DX.TRADE
. The settlement is also done partially by a partial closeout. When partial closeout is done, system updates PM for the outstanding lots and realised P&L for the settled lots.
Field | Description |
---|---|
Update Cas | Set to Yes for the CAS movements (for the commissions) of all the types of DX trades (both futures and options) captured in PM. |
Real Fx Class | Specifies the valid position class ID to capture FX spot position movements for CAS positions captured in PM. |
Fwd Fx Prg Cnt | Specifies whether the FX forward position movements for the CAS positions should be captured in PM. When the field is set to Yes, a valid PM.POSN.CLASS ID is defined in the Fwd Fx Class field, which is used to capture the FX forward positions. |
Fwd Fx Class | Specifies the valid position class ID to capture FX forward position movements for CAS positions captured in PM. |
Fin Int Rt Fut | Specifies the financial interest rate futures in DX.CONTRACT.CLASS for which PM processing is enabled for capturing the GAP (Interest) positions for transactions involving own book. |
Int Rt Start Cls | Specifies the PM.POSN.CLASS , which is used to capture the GAP positions on the Start Date for the financial interest rate futures. |
Int Rt End Cls | Specifies the PM.POSN.CLASS , which is used to capture the GAP positions on the End Date for the financial interest rate future. |
Fin Bond Fut | Specifies the financial bond futures in DX.CONTRACT.CLASS for which PM processing is enabled for capturing the GAP positions for transactions involving own book. |
Bond Start Cls |
Specifies the PM.POSN.CLASS , which is used to capture the GAP (interest) positions on the Start Date for the financial bond future.
|
Bond End Cls | Specifies the PM.POSN.CLASS , which is used to capture the GAP (interest) positions on the End Date for the financial bond future. |
Fin Ccy Fut | Specifies the financial currency futures in DX.CONTRACT.CLASS for which PM processing is enabled for capturing the FXP (Currency) positions for transactions involving own book. |
Ccy Posn Cls | Specifies the PM.POSN.CLASS , which is used to capture the FXP positions for the financial currency future. |
The system uses these set of fields to group Financial Interest Rate, Financial Bond and Financial Currency futures for the PM. DX.CONTRACT.CLASS
is used to form the grouping.
Field | Description |
---|---|
Trade Gap | This is set to Yes, when financial futures (that is, Interest, Bond and Currency) done for trading purposes are also updated in PM files besides the hedge trades, both being own book trades. This field decides whether the trade type of contracts for own book trades have to update PM files or not. By default all hedge transactions done for own book updates the PM files. |

PM.APPLICATION.PARAM
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).

PM.GROUP.TYPE
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’.

Field | Value |
---|---|
Asst Liab Cd | (no value) |
Ast Lib Cal | DEC*ASST.LIAB (operator - DEC and tag - ASST.LIAB) |
Dec Type | ASST.LIAB (tag name) |
Dec Answer | 1 (value returned) |
Dec | PRI BUY SELL (field whose value would be compared) |
Dec Operand | EQ (operand for comparison) |
Dec Value | BUY (value compared to) |
Dec Answer | 2 (value returned) |
Dec | PRI BUY SELL (field whose value would be compared) |
Dec Operand | EQ (operand for comparison) |
Dec Value | SELL (value compared to) |
The operand CAL can be used to return a value after performing arithmetical operations on the value of fields.
For example, to map the Int Key field of PM.TRAN.ACTIVITY
, the sum of the values of the Discount Rate and Load Rate fields is defined as follows:

Field | Value |
---|---|
Interest Key | DISCOUNT.RATE |
Int Key Cal | CALC*RATE |
Cal Type | RATE |
Calc Operand | ADD |
Calc | LOAD.RATE |
The operand REP can be used to map a value from a related table.
For example, to map to the Currency Market field of PM.TRAN.ACTIVITY
, value of the Currency Market field from the LC contract related to the Drawings transaction is defined as follows:

Field | Description |
---|---|
Currency Market | @ID[1,12] (Use the first 12 characters of the ID, which is the ID of the related LC contract) |
Ccy Mkt Cal | REP*MKT |
Replace Type | MKT |
Replace File | LETTER.OF.CREDIT |
Replace | CURRENCY.MARKET |
Additionally, it allows to specify a subroutine to return a value, which can be mapped to PM.TRAN.ACTIVITY
files. The sub-routine name prefixed with ‘@’ character should be entered in the ‘…CAL’ field next to the field to be mapped. The sub-routine can only have two parameters both separated by a ‘,’, the first parameter being the output parameter and the second parameter being the input parameter. If there is more than one input parameter, it is then specified in the second parameter separated by the delimiter ‘:’.
For example, to map to the Value Date field of PM.TRAN.ACTIVITY
, a sub-routine (DX.DATES) with output parameter (RETURN.DATE) and input parameters (CONTRACT.CODE, MAT.PERIOD, DATE.TO.RETURN and RETURN.CODE) is defined as follows:

Field | Value |
---|---|
Value Date | (no value) |
Val Dt Cal | @DX.DATES(RETURN.DATE,CONTRACT.CODE:MAT.PERIOD, :DATE.TO.RETURN:RETURN.CODE) |

PM.APPL.SELECTION
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.ACTIVITY
records with GAP position movements (records with ID: ‘Transaction ID*GAP’). Hence, the PM.TRAN.ACTIVITY
records 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.

PM.PARAMETER
To interface an application to PM, the AA Loans and Deposits is included in PM.PARAMETER
using the PM.UPDATE.APPL
application, and one COB effects the changes. The applications to be added in PM.PARAMETER
are AA loans (AL) and AA Deposits (AD). When new clients migrate to Temenos Transact or existing clients upgrade to a release with AA PM Link, it is ensured that the AL and AD are included in PM.PARAMETER
and necessary parametrisation is in place before migration or upgrade.

Parameterisation is held within AA
module in the Reporting Property Class, and this is different from other Temenos Transact applications which are interfaced to PM. The following is a sample configuration.
Reporting property conditions for PM need to be set in AA.PRD.DES.REPORTING
application as shown in the below screenshot. Below shown record is generic for all Loan products. If user wants for each product or subproduct, multiple records need to be created and attached to product or subproduct.


Similar to the above record, for deposits another record is created as below:


The dealer selection in the above screenshots represents the identity of the data related to loans and deposits in PM. Assigning a separate dealer desk for each subproduct is better as it enables to view the PM data in enquiry output corresponding to each subproduct.
The user definable Position classes shown above are related to GAP except Position class for UNC balances, overdue balances and tax, which are CAS related and FXP for Currency Position.
Property Class and Property Id fields are multi-value fields. Property class or Property ID that impact the PM data are included along with the Position classes relevant to Property class or Property. Optionally, the Position classes can be defined for a Property class, in which case all the properties of that class would go with the same position classes. In case of Interest property class, it is advisable to define interest property-wise only so that any other interest properties (such as Penalty) can be excluded. It is observed that some position classes are appropriate for certain property class or property, such as ACCOUNT having AAPMS, AAPMI, AAPMD and AAPMM. Currency in reporting property ID for PM is optional.
FwdProj attribute is relevant only for Interest Property class or Property. It denotes the user’s choice to project or not to project the interest or coupon payments in PM for the current period or for future period. If it is a future period, include whether it is fixed or floating or both.
The Reporting property class type is TRACKING, that is, a reporting property attached to a product or subproduct can be set to Product only type and the conditions applicable to Arrangement including the dealer desk.
The system derives the CAS Position classes from the GAP Position classes as shown below:
First two characters are AA, second and third characters are derived from PM.AC.PARAM
based on the category of the settlement account and overnight position class mentioned. The last character is same as the one applicable for the GAP position.
For example, if the Position class for GAP for principal increase is ‘AAPMI’, the CAS position class is ‘AAASI’. The third and fourth characters are taken from overnight position class defined for the category of the settlement account.

Dealer Desk introduced in AA Reporting Property for PM, is assigned to an arrangement from the Reporting property attached to the product. If the field is blank in AA Reporting property, an arrangement is identified with default ‘00’ dealer desk. As stated earlier, the data passed from AA to PM is identified with this dealer desk. The AA user can assign different dealer desks at subproduct level, to drilldown PM data relevant to that subproduct or product (by grouping the dealer desks of the subproducts).
As the dealer desk associated with an arrangement in relation to PM represents a product or subproduct for facilitating PM drill down to product or subproduct level, it is not considered necessary to provide an option to change the dealer desk at Arrangement level.
Using PM.GRP
application, dealer desks assigned to subproducts can be grouped to reflect a product, and using that dealer desk group a separate PM.CAS or PM.GAP enquiry can be created to view the data pertaining to such product.

CAS related Position classes are built in PM, based on the category code of the settlement account available in the loan or deposit contract. Unlike in other modules, presence of settlement account is not mandatory in an AA loan or deposit. In this scenario, a default suspense category code is defined in Reporting property. This is linked to PM.AC.PARAM
to build the position classes based on the Overnight position class mentioned for that suspense category. It is not mandatory to create a suspense account with the suspense category defined.
On giving the settlement account in Arrangement, system subsequently rebuilds the Position classes considering the category code of the settlement account.


.png)
In the PM.PC.PARAM
setup of Model Bank, the category code range between 3000 to 3999 and 3600 to 3999 are excluded, because the same are meant for AA deposit and AA loan account category codes. Alternatively, the category codes used for AA retail accounts are included in PM.AC.PARAM
, as they hold customer cash balances.
The suspense category defined in Reporting property conditions is 14008, and in PM.AC.PARAM
, it may be observed that 14008 goes with overnight position class ‘ACASC’.

Based on the product conditions, an AA loan account can contain unallocated credit balance, which represents excess money received from the borrower over and above the actual due. As this money belongs to the customer and is susceptible to utilisation (anytime), it is shown in CAL bucket as a likely outflow (until it is utilised or adjusted).
Similarly, an overdue balance represents the amount due from the customer but not paid on due date. The projection shown as a likely inflow disappears from CAS statement after it crosses the due date. Such overdue balances are considered as likely inflow and displayed in the CAL bucket. Although, over dues arise mainly on account of loans, it is also possible to observe over dues in a savings plan account (where the monthly instalments become overdue, when not paid on due date).
The two Position classes for both UNC and overdue balances are also user definable in the Reporting property class. Additionally, it is the user’s choice to include or not to include the option.



AA Arrangement for a loan or deposit allows the use of applications, such as FT
, TT
or DD
for funding, disbursements and repayments. When auto settlement or a schedule for funding or disbursal is not defined and Fund transfer application or an equivalent is considered to do the principal funding or disbursal subsequently, it would not be clear to PM as to when the cash flow in or out happens. In such scenarios, the cash flow in or out can be projected only on anticipated basis. In order to provide the flexibility to the PM users, whether to include or not such undisbursed or unfunded arrangements, two sets of Position classes are used to represent the data called Optional and mandatory position classes. Optional position classes represent data in PM on account of undisbursed or unfunded arrangements with no certainty about disbursal or funding dates, while mandatory position classes are used where there is certainty.
The difference between Mandatory and Optional position classes is the fourth character in a Position class, which is always ‘E’ for Optional position class. System has the intelligence to use either optional or mandatory position classes, based on the certainty about principal funding or disbursal dates. Both the Position classes have to be defined in PM.POSN.CLASS
and also included in CAS and GAP records in PM.POSN.REFERENCE
, if the PM user opts to include the optional position classes also in PM projections. For example, if the Mandatory position class is built with AAPMS (start event for a loan or deposit with timing certainty), an Optional position class is built with AAPES (start event with no timing certainty).
It needs to be mentioned here that once a partial funding or disbursal is done under the arrangement, system builds the mandatory position classes for the actual amount funded or disbursed and no data is built for the balance commitment amount using the optional position classes any more.

PM.POSN.REFERENCE
Similar to the position classes defined for other applications in PM.POSITION.CLASS
and included in PM.POSN.REFERENCE
, the Position classes are also defined for AA and included in PM.POSN.REFERENCE
.
The following table has the sample Position classes for AA to PM. The user can define the GAP and CAS Position classes relating to UNC, overdue, tax and FXP position class.
Suggested Position Classes for AA in PM | CAS | |||
---|---|---|---|---|
Event | GAP | Cust/Susp A/C | Nostro A/C | FXP |
Deposit/Loan Start Event | AAPMS | AAASS | AABSS | |
Deposit/Loan Mat Event | AAPMM | AAASM | AABSM | |
Principal Increase Event | AAPMI | AAASI | AABSI | |
Principal Decrease Event | AAPMD | AAASD | AABSD | |
Principal Repayment | AAPMR | AAASR | AABSR | |
Interest Capitalisation | AAPMN | |||
Interest Pay out | AAASN | AABSN | ||
Charge Capitalisation (payable or receivable) | AAPMC | |||
Charge Liquidation (payable or receivable) | AAASC | AABSC | ||
Rollover Start | AAPRS | |||
Rollover Old Maturity | AAPRN | |||
Rollover New Maturity | AAPRM | |||
UNC Balances | AAUNC | |||
Overdue Balances | AAASO | |||
Tax | AAAST | |||
FX Position | AAFXP |
The system builds the relevant CAS position classes (corresponding to the GAP position classes) defined by the user, where the 3rd and 4th characters are replaced with the overnight position class defined in PM.AC.PARAM
against the category code of the settlement account used in AA Deposit or Loan. If the settlement account used is a Nostro account, then the Position class built will be overnight position class meant for the Nostro category.
System builds Optional position classes representing anticipated events by replacing the 4th character with ‘E’. If the user opts to include them in PM data, then Position classes with ‘E’ is also defined in PM.POSN.CLASS
and included in PM.POSN.REFERENCE
. As stated earlier, Optional position classes are used either partially or fully, until the first funding or disbursal.
If the settlement account is Nostro, the Position classes based on the setup in PM.AC.PARAM
would be different from the ones representing Non-Nostro accounts.
The PM.NOS enquiry shows the cash flow pertaining to the Nostro accounts. Therefore, only the Position classes relating to Nostro account are included. The following Position classes, based on the setup in Model Bank, are included in PM.NOS on account of AA.
Mandatory Position Classes– AABSC, AABSS, AABSD, AABSI, AABSM, AABSN, AABSR
Optional Position Classes –AABEC, AABES, AABED, AABEI, AABEM, AABEN, AABER

PM.POSITION.CAPTURE
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.

PM.POSN.REFERENCE
The prerequisite for position capture is to create a Position Class for the position movement that needsto be updated. The creation of Position Class is achieved using the PM.POSN.CLASS
application, similar to how it is done for all the other applications and the position class, so created is included in PM.POSN.REFERENCE
as per the position type.
The newly created PM.POSITION.CLASS
record is attached to GAP record (depending on the position type) of PM.POSN.REFERENCE
as shown in the example below:





PM.POSITION.CAPTURE
and validating PM.TRAN.ACTIVITY
The PM.POSITION.CAPTURE
application assists in capturing the position movement data in PM.TRAN.ACTIVITY
manually.
The fields in PM.POSITION.CAPTURE
is a replication of PM.TRAN.ACTIVITY
fields and the numbers are keyed in manually to effect the position movement. The PM.TRAN.ACTIVITY
is generated as a result of PM.POSITION.CAPTURE
record.
The subsequent reflection of position movement data in PM enquiries is taken care automatically and the position data is included in the relevant position enquiries. For example, in this case PM.GAP enquiry. If the item need not be added in PM enquiries,the PM.POSITION.CAPTURE
record can be reversedat any point before reaching the value date.
In this topic