Reporting

A user can opt not to update the EB.CASHFLOW file for select Activities or Properties. This can be achieved by entering an Activity name in the Activity Name field and setting the Cash Flow field is to No. If the user wants to exclude any Property, then the user must set the Property and Exclude EIR fields to the value of the Property and Yes, respectively. The user can exclude any Activity by mentioning the name of the activity in Exclude Activity for the respective APR type.

IAS.CLASSIFICATION - The IFRS Classification field holds the classification of contract based on IFRS standard.

IAS.SUBTYPE - The IFRS Subtype field displays the sub type for the corresponding classification defined in the IFRS Classification field. It has to be a valid sub type for the corresponding classification defined in the IAS.CLASSIFICATION file. This field cannot be amended at arrangement level.

For any type of substantial modification based on the quantitative test on a loan, except ‘IBOR to RFR’ migration, the system raises an override for the user to know that the contract is Derecognised.

Read Introduction to Modification and Derecognition of Loans for more information.

MARKET.KEY - The Market Key field specifies the market rate to calculate the NPV based on future cash flow information. The field can either be a fixed rate or Periodic.Interest key with prefix P. This field is mandatory if value is entered in IFRS Classification field.

MARKET.MARGIN - The Market Margin field calculates the NPV based on future cash flow information.

MARGIN.OPERAND - The Market Operand field is to be used while arriving rate using Market Margin field. Allowed values are ADD, SUB.

EXPECTED.TERM - The Expected Term field displays the values in terms of period such as XXD (Days), XXW (Weeks), XXM (Months) and XXY (Year), where XX denotes any number. When the expected term is beyond the maturity date, maturity is considered as expected end date.

ACTIVITY.NAME - All Activities with related AA.ACTIVITY.CLASS containing Activity Type as CASHFLOW triggers cash flow event by default. But if any activity need not trigger a cash flow then the Activity name has to be input in the Activity Name.1 associated multi-value field and the Cash Flow.1 associated field has to be set as No.

CASH.FLOW - The Cash Flow.1 field is used in association with the Activity Name.1 field wherein Activities that need not trigger a cash flow is selected. In order to ensure that the system does not trigger the cash flow, the Cash Flow.1 field has to be set to No for all Activities that are selected in Activity Name multi-value field.

If Cash Flow.1 field is set to Yes or Null then the activity mentioned against the Activity Name.1 field triggers cash flow.

PROPERTY - All the properties of the Activity for which Cash Flow field is not set to NO is included in cash flow. If a Property is not required to be included in cash flow calculations, then the Property name has to be specified in the Property.1 field associated multi-value field and the Exclude Eir.1 associated field has to be set to Yes. For example, Penalty Interest Property of Interest Property Class need not be included in EIR calculations.

EXCLUDE.EIR - The Exclude Eir.1 field is used in association with the Property.1 field wherein Property that need not be included in the cash flow is selected. If the selected Property has to be excluded from the cash flow, then this field value has to be set to Yes. If the value is set to No or Null then the Property selected against the Property.1 field is included for the cash flow.

PROPERTY.CLASS - The user can specify the Property Class to which the Position Classes are to be associated within the Property Class field. This gives the flexibility to the user to define the relevant Position Classes for each of the Property Classes. The Property Class should be a valid record in the AA.PROPERTY.CLASS record.

For example, the user can configure different set of position classes for interest and principal. If the Property Class is defined then Properties related to this Property Class is not allowed in PROPERTY.ID.

Optionally, the position classes can be defined for a Property Class, in which case all the Properties of that class goes 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 might be 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.

PROPERTY.ID - The Property field specifies the Property to which the user relates the position class. This definition allows users to configure different combination of position class for each Property. The selected Property should be a valid record in AA.PROPERTY and the Property Class relating to this Property should not have been defined in the Property Class field.

For example, the user can configure different set of Position Class for admin fee and processing fee. If the Property is defined then Property Class of this Property is not allowed in Property Class field.

POS.CLASS.START - PM Position Class for Principal Start event for GAP is specified in the Pos Class.1 Start field. The value must exist in PM.POSN.CLASS and mandatory for Principal Property Class or Property. From the Position class defined here, the Position class for Start event for CAS is derived by replacing the 3rd and 4th characters with those of the Position class defined for the category code of the settlement account in PM.AC.PARAM. The Position classes built, display the fourth character as E, where the timing for disbursal or funding event is not certain.

POS.CLASS.MATURITY - PM Position Class for Principal Maturity event for GAP is specified in Pos Class.1 Maturity field. The value must exist in PM.POSN.CLASS and mandatory for Principal Property Class or Property. From the Position class defined here, the Position class for Start event for CAS is derived by replacing the 3rd and 4th characters with those of the Position class defined for the category code of the settlement account in PM.AC.PARAM. The Position classes built for maturity , displays the 4th Character as E, where the timing for disbursal or funding event is not certain.

POS.CLASS.INCREASE - PM Position class for Principal Increase event for GAP is specified in Pos Class.1 Incr field. The value must exist in PM.POSN.CLASS and mandatory for Principal Property Class or Property. From the Position Class defined here, the Position class for Principal Increase event for CAS is derived by replacing the 3rd and 4th characters with those of the Position class defined for the category code of the settlement account in PM.AC.PARAM. The Position classes built, displays the 4th Character as E, where the timing for disbursal or funding event is not certain.

POS.CLASS.DECREASE- PM Position class for Principal Decrease event under GAP is specified in the Pos Class.1 Decr field. The value must exist in PM.POSN.CLASS and mandatory for Principal Property Class or Property. From the Position class defined here, the Position class for Principal Decrease event under CAS is derived by replacing the 3rd and 4th characters with those of the Position class defined for the category code of the settlement account in PM.AC.PARAM. The Position classes built displays the 4th Character as E, where the timing for disbursal or funding event is not certain.

POS.CLASS.REPAYMENT - The Pos Class.1 Repay field specifies the Position Class to which the user wants to relate the Principal Instalment Payment event (a loan instalment or a savings plan instalment). If AAPMR is the position class defined for GAP, then the Position class for CAS is derived as AAXXR (XX is taken from the position class defined in PM.AC.PARAM for the category code of the settlement account). The value must exist in PM.POSN.CLASS and mandatory for Principal Property Class or Property.

To show expected movements for undisbursed or unfunded contracts without any schedule, the 4th character is replaced by E that is, AAXER (X is taken from PM.AC.PARAM).

POS.CLASS.CAPITALISE- Where a Charge payable or Charge receivable and Interest Payable or receivable is capitalised, the Position Class corresponding to the nature of item ,that is, charge or interest, a position class is defined in Pos Class.1 Capitalise field. The value must exist in PM.POSN.CLASS and mandatory for Principal Property Class or Property other than Principal Property Class or Property. To show expected movements for these capitalisation events in case of undisbursed or unfunded contracts the 4th character is replaced by "E", that is, AAPEC or AAPEN.

For example, in case of Charge, it can be AAPMC and in case of interest it can be AAPMN.

POS.CLASS.OVERDUE- The Position Class defined in the Pos Class.1 Overdue field represents the overdue amount receivable either in a loan or a savings plan instalment in CAS report under CAL line. The value must exist in PM.POSN.CLASS and is mandatory if overdue balances are opted to be shown in CAS report.

POS.CLASS.FX- The Pos Class.1 Fx Pos field specifies the Position Class used to show the currency Position in FXP Position reference if the transaction gives raise to currency Position. The Currency Position so shown is real FX position and not Forward FX Position. The value must exist in the PM.POSN.CLASS table.

INCLUDE.FORWARD.RATES- The Fwd Proj field defines whether interest events are to be projected into the future. The next interest movement is always shown in the Position Management system. Subsequent events are not included unless this field is defined. It may take any one of the following values:

• Variable—Show only future payments for variable interest contracts.
• Fixed—Show only future interest and commission payments for fixed rate contracts. A fixed rate contract is a contract where only FIXED.RATE is present in the Interest Property.
• Both—Show fixed and variable rate contract future payments.

POS.CLASS.ROLLOVER.START- The Position Class Rollover Start field specifies the Position Class to which the user wants to relate the rollover start movement for the deal. The value must exist in the PM.POSN.CLASS table and it is mandatory for principal Property Class or Property is defined.

POS.CLASS.OLD.ROLLOVER- The Position Class Rollover Old field specifies the position class to which the user wants to relate the Previous Maturity movement for the deal. The value must exist in the PM.POSN.CLASS table and it is mandatory for principal Property Class or Property is defined.

POS.CLASS.NEW.ROLLOVER- The Position Class Rollover New field specifies the Position Class to which the user wants to relate the rollover maturity event for the deal. The value must exist in the PM.POSN.CLASS table and it is mandatory for principal Property Class or Property is defined.

POS.CLASS.UNALLOCATED- The Position Class Unallocated field specifies the Position Class to build the Balances in UNC (Unallocated Credit Balance) if the same are opted to be included in the CAS report under CAL line. The value must exist in the PM.POSN.CLASS table and it is mandatory for principal Property Class or Property is defined.

DEFAULT.POS.CLASS.CAT- The Default Settlement field specifies a category to build the default settlement account if the liquidation account is not defined in Settlement Condition for the Property Class or Property.

DEALER.DESK- The Dealer Selection field, if provided by the user, the same defaults to the Reporting Property attached to an arrangement. Else, it defaults to ‘00’. Alpha or Numeric or combination of both as allowed in DEALER.DESK table. The value selected from Dealer Selection field must be an existing ID on the DEALER.DESK table.

Assigning a separate dealer desk for each sub-product is a better idea to view the PM data in enquiry output corresponding to each such sub-product.

UPDATE.OVERDUE.POS- The Overdue Update field indicates whether the user wants to include the overdue movements for the contract balances in CAS report. To enable the inclusion, the check box must be selected.

The Linkage between AA module for Loans and Deposits and Position Management grants inclusiveness to the data presented by PM to its users.

While no changes were needed on PM side to enable the data inflow from AA, as the framework is generic, the design of AA PM Link, compared to other modules, is different in many ways. This is because of the Architecture and the flexibility AA offers in building Products and the Product Conditions.

To interface an application to PM, the same should be included in PM.PARAMETER using PM.UPDATE.APPL application and one COB to give effect to the change. 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 has be ensured that AL and AD are included in PM.PARAMETER and necessary parametrisation is in place before migration or upgrade.

Different from the way the other Temenos Transact applications are interfaced to PM, parameterisation is held within AA module in the Reporting Property Class. The following is a sample configuration.

Reporting Property Conditions for PM need to be set as displayed.

Below is a generic record is applicable for all Loan products. Multiple records are created for each product or sub product, as per the user’s preference and is attached to Product or Sub-product.

Similar to the above, for Deposits another record is created as under.

The Dealer selection in the above screenshots represent the identity of the data related to loans and deposits in PM. Assigning a separate dealer desk for each subproduct enables the user to view the PM data in enquiry output corresponding to each such sub product.

The user definable Position Classes as displayed above are related to GAP except for Position class for UNC balances, overdue balances and tax, which are CAS related and FXP for currency position.

Property Class and the Property ID field is a multi-value field. Property class or Property ID field, which impact the Position Management data are included here along with the Position Classes relevant to such Property class or Property. Optionally, the Position classes can be defined for a Property Class, in which case all the properties of that class 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 can be 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.

The FwdProj attribute is relevant only for Interest Property Class or Property. It denotes the user’s choice to whether or not the interest or coupon payments can be projected in PM for the current period or for future period too. In future period either fixed or floating or both are included.

The Reporting Property Class type is TRACKING, meaning a Reporting Property attached to a product or sub-product can be set to Product only type and the conditions thereof are applicable to arrangement including the dealer desk.

From the GAP Position classes system derives the CAS Position classes as under.

First two Characters are AA, second and third characters are derived from PM.AC.PARAM based on the category of the settlement account and the overnight position class mentioned therein. The last character is same as applicable for the GAP position.

If the Position Class for GAP for Principal increase is AAPMI, the CAS position class is AAASI, the third and fourth characters 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. The data passed from AA to PM is identified with this dealer desk. AA user might want to assign different dealer desks at sub-product level to be able to drilldown to PM data relevant to that sub-product or Product (by grouping the dealer desks of the sub-products).

As the dealer desk associated with an arrangement in relation to PM essentially represents a product or sub-product for facilitating PM Drilldown to product or sub-product level, it is not considered necessary to provide an option to change the dealer desk at arrangement level.

Using the PM.GRP application, dealer desks assigned to sub-products can be grouped to reflect a Product and using that Dealer desk group a separate PM.CAS or 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 present in the Loan or Deposit contract. Unlike in other modules, presence of settlement account is not mandatory in an AA loan or deposit. To cater to this scenario, a default suspense category code is defined in Reporting Property, which is linked to PM.AC.PARAM in order to be able to build the position classes based on the Overnight Position Class mentioned for that Suspense category. It is not mandatory that a suspense account must be created with the suspense category defined here.

Upon giving the settlement account in the arrangement subsequently, the system rebuilds the position classes considering the category code of the settlement account.

It might be observed in the PM.PC.PARAM setup in Model Bank the category code range 3000 to 3999 and 3600 to 3999 are excluded as the same are meant for AA Deposit and AA Loan Account category codes. On the other hand, the category codes used for AA Retail accounts have to be 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 can 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 utilization anytime, it is shown under 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 once it crosses the due date. Such overdue balances, are considered as likely inflows and shown under 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 if not paid on due date.

The two Position classes for both UNC and Overdue balances are also user definable in the Reporting Property Class. Option to or not to include them is again a user’s choice.

AA Arrangement for a loan or deposit allows use of applications like 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 contemplated to do the principal funding or disbursal subsequently, it is not clear to PM as to when the cash flow in or out happens. In such scenarios, the cash flow in or out can only be projected on anticipated basis. In order to give 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. The 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.

Similar to the way the position classes are defined for all other applications in PM.POSITION.CLASS and included in PM.POSN.REFERENCE, the Position classes need to be defined for AA too and included in PM.POSN.REFERENCE.

Following table contains the sample Position classes for AA to PM. User has the flexibility to define the GAP Position classes and CAS Position classes relating to UNC, Overdue, Tax and FXP position class.

Relevant CAS position classes, corresponding to the GAP position classes defined by the user, are built by the system where the 3rd and 4th Characters are replaced with that of 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, the Position class built is based on overnight position class meant for the Nostro Category.

Optional Position classes representing anticipated events are built by the system by replacing the 4th character with E. Where the user opts to include them in PM data, Position classes with “E” should also be defined in PM.POSN.CLASS and included in PM.POSN.REFERENCE. As stated already, the optional position classes are used until the first funding or disbursal either partially or fully.

Where the settlement Account is a Nostro, the Position classes, based on the setup in PM.AC.PARAM, is different from the ones representing Non-Nostro accounts.

The enquiry PM.NOS is meant to show the cash flows 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

Read the PM Link to AA section for more information.

The system computes APR as an annualised rate. Temenos Transact calculates the APR for all the cash flow activities. APR is also calculated at the time of creating a new arrangement and for simulated contracts. APR can be calculated for different scenarios by excluding a Property (say solicitor fee in Internal APR calculation) type.

The APR is calculated and stored in the APR Type and APR Rate fields of the Account Property Class as follows:

• In Loans and Deposit contracts, the <PRODUCT.LINE>-UPDATE.CASHFLOW-<REPORTING> activity updates the APR when cashflow type of activities are processed.
• In all other cases, the <PRODUCT.LINE>-UPDATE.APR-<ACCOUNT> activity updates the APR for the arrangement.

If a forward-dated change is captured after the arrangement is created, then the APR is recalculated and stored as of the future effective date, that is, the effective date of the change. The system updates the recalculated APR in the APR Type and APR Rate fields as a forward-dated account condition for the arrangement. Read here for more information about recalculation of APR for forward dated changes.

The different APR scenarios can be configured in the Product definition through Reporting Property Class with the help of the attributes:

• APR Type - Used to specify the APR type (For example, internal, external).
• Exclude Property - Used to exclude a Property type from APR calculation.

APR Type

The APR Type field indicates the reference for APR calculation. It must map to ID of AA.APR.TYPE, which defines the source type, calculation routine, and recalculation method for APR calculation.

• Source used for APR calculation can either be cashflows of the contract or interest rate.
• User-defined routine to calculate the APR based on the source type.
• Derive the APR of a contract based on its cash flow.
• Recalculate APR whenever there is a change to the components forming the Cash flow or Interest rate sources (Principal balance, Charge amount, Interest rate conditions, Payment schedule and so on).
• APR for a contract based on the cashflow option in Source Type is recalculated using either the net present value or the outstanding principal.
• Calculates multiple APR types for an arrangement, when the different APR calculations are made of different components.
• Triggers APR calculation for cash flow activities except for the activities which are excluded.

• The APR Type and APR Rate are stored in the Account Property Class through:

  • <PRODUCT.LINE>-UPDATE.CASHFLOW-<ACCOUNT> activity when cashflow type of activities are processed in loans and deposits.
  • <PRODUCT.LINE>-UPDATE.APR-<ACCOUNT> activity in all other cases.
• Displays the date on top of the list continued with other dates in a chronological order.

Exclude Property

The Exclude Property field indicates the Properties, which are excluded for APR calculation for the given APR scenario. The value must have a valid entry in AA.PROPERTY table and must be a valid Property of the arrangement. This field cannot be input when the corresponding APR Type is not input.

Exclude Activity

The Exclude Activity field indicates the activities, which are excluded for APR calculation for the given APR scenario. The value must have a valid entry in AA.ACTIVITY table and must be a valid activity of the arrangement.

This field allows the user to input only when the corresponding Apr Type has been specified. It applies only for the cashflow based APR types.

The Charge Off Amount and Charge Off Percentage attributes in the Reporting Property Class are shown below:

Field	Description
Chargeoff Amount	User can specify the charge off amount for the arrangement.
Chargeoff Percentage	User can specify percentage for loan outstanding which needs to be considered for charge-off. Example: 100 for full charge off.

AA Activity Class

To handle loan charge off under FASB regulation the CHARGEOFF-REPORTING activity class is used.