Temenos T24 IA: User Guide

TEMENOS T24
IA
User Guide
No part of this document may be reproduced or transmitted in any form or by any means,
electronic or mechanical, for any purpose, without the express written permission of TEMENOS Holdings NV.
Copyright 2005 TEMENOS Holdings NV. All rights reserved.

IA User Guide
Table of Contents
Overview.................................................................................................................................................. 5
International Accounting ...................................................................................................................... 5
What is IAS39? .................................................................................................................................... 5
Architecture/Design ................................................................................................................................. 6
Recognition and Classification of Assets and Liabilities ...................................................................... 6
Asset Classifications ........................................................................................................................ 7
Held for Trading ............................................................................................................................ 7
Available for Sale .......................................................................................................................... 7
Held to Maturity............................................................................................................................. 7
Loans and Receivables ................................................................................................................ 7
Liability Classifications ..................................................................................................................... 8
Trading Liabilities .......................................................................................................................... 8
Other liabilities .............................................................................................................................. 8
Initial recognition .............................................................................................................................. 8
Measurement ....................................................................................................................................... 8
Fair Value ......................................................................................................................................... 8
Amortised Cost ................................................................................................................................. 9
Hedging and Impairment...................................................................................................................... 9
Hedge Accounting ............................................................................................................................ 9
Impairment of Assets...................................................................................................................... 11
Why a separate IA module? .............................................................................................................. 11
Dual Accounting ............................................................................................................................. 11
Alternative Interpretations .............................................................................................................. 11
IA Module Design............................................................................................................................... 11
A flexible solution for variable interpretations ................................................................................ 12
Prerequisite to installation .................................................................................................................. 12
Structure of IAS module in T24 .......................................................................................................... 15
Parameter files ................................................................................................................................... 16
Installation level parameters .......................................................................................................... 16
Product level parameters ............................................................................................................... 16
User applications ............................................................................................................................ 16
Setup ..................................................................................................................................................... 17
IAS.PARAMETER .............................................................................................................................. 17
IAS.CLASSIFICATION....................................................................................................................... 18
IAS.AMOUNT.TYPE .......................................................................................................................... 18
TEMENOS T24 User Guide

Page 2 of 71
IA User Guide
Calculation of Amount types using functions ................................................................................. 20

Amount types mapped from the underlying contract or position .................................................... 21
Calculations and Amount Types .................................................................................................... 22
IAS.PRODUCT.GROUP .................................................................................................................... 23
Accounting options ......................................................................................................................... 25
Non Contingent: .......................................................................................................................... 25
Contingent .................................................................................................................................. 25
Local reference fields on base applications ....................................................................................... 27
IAS.PRODUCT.CONDITION ............................................................................................................. 27
IAS.APPLICATION.PARAM .............................................................................................................. 32
IAS.CONTRACT.BALANCES ............................................................................................................ 38
IA Contract Details update ............................................................................................................. 38
Rate Types ......................................................................................................................................... 45
IAS.RATE.TYPE definition ............................................................................................................. 45
Retrieving a rate ............................................................................................................................. 47
Dual Accounting process ................................................................................................................... 48
Hedging .............................................................................................................................................. 49
API ......................................................................................................................................................... 51
Calculations ....................................................................................................................................... 51
Amount types calculated through an API routine ........................................................................... 51
IAS.SC.IRR.CALCULATION ...................................................................................................... 52
IAS.SC.IS.DISCPREM................................................................................................................ 54
IAS.SC.IRR.DISCPREM ............................................................................................................. 55
IAS.SC.CALC.IRR.DPA .............................................................................................................. 56
IAS.SC.CORE.ACCRUALS ........................................................................................................ 57
IAS.SC.ADJ.ACCRUALS ........................................................................................................... 58
IAS.SC.FV.CALCULATION ........................................................................................................ 59
IAS.LD.IRR.CALCULATION ....................................................................................................... 60
IAS.LD.IS.DISCPREM ................................................................................................................ 61
IAS.LD.IRR.DISCPREM ............................................................................................................. 62
IAS.LD.RD.DISCPREM .............................................................................................................. 63
IAS.LD.FAIR.VALUE .................................................................................................................. 64
IAS.LD.FAIR.VALUE.REVAL ..................................................................................................... 66
IAS.LD.CREDIT.RISK................................................................................................................. 67
IAS.MM.FAIR.VALUE ................................................................................................................. 68
IAS.MM.FAIR.VALUE.REVAL .................................................................................................... 70

Page 3 of 71
IA User Guide
IAS.MM.CREDIT.RISK ............................................................................................................... 71

Page 4 of 71
IA User Guide
Overview
International Accounting
In response to the ever increasing complexity and globalisation of financial markets, the International
Accounting Standards Committee, and its successor the International Accounting Standards Board,
have issued new standards to address the accounting of financial instruments, the most progressive of
these is IAS39. The aim of the standard is to recognise all the financial assets and liabilities on the
balance sheet (including derivatives that may have previously been held off balance sheet), and move
closer to full fair value accounting for these assets and liabilities.
Unfortunately, their efforts to introduce a new global standard has only been partly successful thus far,
as there are differing interpretations both between different national supervisors, but also at the auditor
level within countries, in part due to focus of the standards being all companies rather than specifically
banks.
The TEMENOS response is to develop an open module allowing users to use (or amend) the
calculations, to produce the accounting practices that they, under agreement of their auditors, see fit.
As IAS39 is the first of potentially many International Accounting Standards that financial institutions
may have to adopt, the IA User guide has been written with this in mind.
What is IAS39?
IAS39 is a standardised set of rules for the accounting and reporting of financial assets and liabilities.
It is being introduced as a global standard with the recognised and announced aim to;
• Replace the various local GAAP regulations
• Provide clarity and confidence for investors
• Evaluate the true financial risk of a company
In broad terms IAS39 can be broken down into three elements:

• Recognition and classification of assets and liabilities
• Measurement
• Hedging and impairment.

Page 5 of 71
IA User Guide
IAS 39
Classification, Measurement Hedge Accounting

Initial & Impairment
Measurement
& Recognition
Architecture/Design
Recognition and Classification of Assets and Liabilities
IAS39 requires that all financial assets and liabilities are recognised on the banks books. This includes
all derivatives, which in many parts of the world had historically not been recorded at all. Derivatives
will now be required to be recorded off balance sheet, with their fair-value revaluation being recorded
above the line.
IAS requires that assets are categorised into one of four classifications, and liabilities into one of two
classifications. The same trade date or value date accounting standard must be deployed within each
classification.

Page 6 of 71
IA User Guide
Asset Classifications
Financial Assets should all be classified as follows:
Held for Trading or Yes Held for short-term

profit making?
Fair value through
profit or loss
No
Changes recorded in Yes Loans and

income statement Originated or receivables
acquired non-
derivative assets
Fair with determinable
Value payments, not Amortised
quoted in an active Cost
market?
Changes recorded in
equity
No
Available for No Intend and ability to Yes Held to

sale hold to maturity? maturity
Asset classification
Held for Trading
All financial instruments (including originated) that are held for short term profit-making purposes
including all derivatives which are not designated as part of a hedge. Measured at fair value and
reported to profit/loss.
Available for Sale
Non-derivative assets which are designated on initial recognition as potentially tradable but which are
not specifically acquired for short-term profit-making. Measured at fair value, and reported in equity
until the asset is sold, when the profit/loss is realised.
Held to Maturity
Fixed maturity investments, such as debt securities, designated with the intention and ability to be held
until maturity. These are measured at amortised cost. There are strict penalties for reclassifying a
held-to-maturity asset, so this category may not be extensive used by banks.
Loans and Receivables
Originated (or acquired) non-derivative assets with determinable payments, not quoted on an active
market, and not held for trading purposes.

Page 7 of 71
IA User Guide
Liability Classifications
Financial Liabilities should all be classified as follows
Yes No
Financial liability Other Amortised
Held for purpose Cost
Fair at fair value Liabilities
of short-term profit
Value through profit or making? Short
loss position?
Liabilities classification
Trading Liabilities
These liabilities are acquired principally for the purpose of short-term profit making, or any short
positions. Measured at fair value and reported to profit/loss.
Other liabilities
These are all non-trading liabilities and measured at amortised cost.
Initial recognition
IAS39 requires recognition of a financial asset or liability only when the entity becomes a party to the
contractual provisions of the instrument. The purchase or sale of financial assets is recognised and
derecognised using either trade date or settlement date accounting. The method used is to be applied
consistently for all the purchases and sales of financial assets that belong to the same IAS39
classification.
All assets and liabilities must be recognised on balance sheet
All derivatives must be reported on balance sheet. Historically, in many parts of the world, derivatives
have not been recognised on company balance sheets. The argument has been that at the time the
derivative contract was entered into, there was no amount of cash or other assets paid.
Measurement
Fair Value
The Fair value is defined as the amount for which an asset could be exchanged, or a liability settled,
between knowledgeable, willing parties in an arm’s length transaction.

Page 8 of 71
IA User Guide
Quoted on an YES Use Market Price

Mark-to-market
Active market?
NO
Are Valuation YES Use Fair Value Based on market inputs, option pricing
Models models, discounted cash flow analysis
models reliable?
NO
Cost less A last resort will need to be justified to
Impairment auditors.
Fair value revaluation
Items held for fair value measurement, must be re-valued periodically and the appropriate accounting
entries raised (either in profit/loss or equity) to reflect the change in value. For instruments with a
quoted market price, the revaluation is a simple mark-to-market at the appropriate bid/offer rate. For
unquoted instruments valuation models can be used, but must be justified to auditors.
Amortised Cost
For items measured through amortised cost an accrual based on the Effective Interest Rate (EIR) is
made rather than a revaluation.
The EIR is the rate that exactly discounts estimated future cash payments or receipts to the net
carrying amount of the asset or liability. This EIR is calculated at initialisation, and is not changed
throughout the life of the instrument, however there are one-off adjustment postings required for
expected credit losses, instruments that are subject to call and where there are subsequent changes
to the expected cash flows.
Hedging and Impairment

Hedge Accounting
Where a derivative financial instrument is being used as an offset in net profit and loss to the change
in fair value or cash flows of another financial instrument, hedge accounting may be employed to allow
the offsetting gains and losses to be recognised simultaneously on the income statement.
Hedge accounting may be applied under the following conditions:

• Hedge is formally documented
• It is highly effective at inception
• Forecasted transaction is highly probable
• Effectiveness is reliably measured

Page 9 of 71
IA User Guide
• Hedge effectiveness assessed on an ongoing basis

• Hedging items may not be designated or documented retrospectively
• A non-derivative may only be designated as hedging instrument for the hedging of a foreign
currency risk.
Two tests of hedge effectiveness are required:

• Prospective test: At inception and throughout its live, each hedge must be highly effective
(changes in FV or CF of hedging instrument almost fully offset change in FV or CF of hedged
item.
• Retrospective test: measured at least every reporting period and hedge should be highly
effective.
Hedge should be discontinued when:
• The hedging instrument is sold, terminated, exercised or expires
• The hedge no longer meets the criteria to qualify as a hedge
• The forecasted future transaction is no longer expected to occur
Hedges may be defined as:
Fair Value Micro Hedges

The hedge of a specific exposure to changes in the fair value of a recognised asset or liability that is
attributable to a particular risk, most commonly an interest rate change. The intention is to nullify the
risk of having a fixed interest asset or liability relative to the floating market rate.
The gain or loss on the hedging instrument and the fair value adjustment of the hedged item are offset
before posting to the income statement. As both elements are posted to the income statement, there
is no separate accounting of effective and ineffective portions of the hedge.
Cash Flow Micro Hedges

The hedge of a specific exposure to changes in cash flow due a particular risk associated with a
recognised asset or liability. The intention is to fix the cash flow, and so it is therefore the opposite of a
fair value micro hedge. For example, a pay fixed, receive floating interest rate swap used to lock in the
cost of a floating rate liability.
The effective portion of the hedging instrument must be recognised in equity, while the ineffective
portion is posted directly to the income statement. There is no accounting impact on the hedged item.
Macro Hedges
Where the hedge is not on a specific risk exposure, but on a net balance sheet position, a macro-
hedge is employed, whereby the change in fair-value of the hedging instrument(s) can be offset
against that of the underlying portfolio of assets. This was not allowed in the original drafting of IAS39,
but was introduced in later amendments.

Page 10 of 71
IA User Guide
Impairment of Assets
A financial asset is considered impaired if its carrying amount exceeds its estimated recoverable
amount. Objective evidence of impairment includes a substantial deterioration of creditworthiness,
delinquency on the part of the debtor, a high probability of bankruptcy or other significant financial
reorganisation.
For assets held at amortised cost, the loss must be calculated as the difference between the carrying
amount and the discounted value of the expected cash flows, and then posted to income statement for
the period.
For Available-for-Sale assets where unrealised profit or loss is deferred through equity, losses on an
impaired asset must immediately be transferred to the income statement for the period.
Why a separate IA module?

During the initial phases of our IAS work it was determined that a separate IA module would be
developed; this was due to the following reasons.
Dual Accounting
Convergence of local GAAP regulations and IAS is still a work in progress, so some banks will need to
report based upon differing sets of standards. This dual accounting is not possible within the individual
TEMENOS T24 modules.
An example of this would be where a bank wishes to use a linear Forex revaluation for their internal or
local reporting, but require a rebate revaluation for IAS reporting.
Alternative Interpretations
By structuring an open module where the required calculations and accounting definitions are user-
defined, we are able to support alternative interpretations of the IAS rules (of which there are many).
N.B. Many aspects of IAS accounting rules have always been present in core TEMENOS T24, and
hence there may be certain clients who will be able to employ IAS39 compliant accounting practices
without the use of the IA module, depending upon the nature of their balance sheet, and the
accounting practices currently employed for national GAAP or internal reporting. This will need to be
assessed on an individual basis.
IA Module Design
The IA module allows for the calculation and posting of a parallel set of accounting entries based on a
revaluation or amortisation method that not being used via the core T24 module.

Page 11 of 71
IA User Guide
A flexible solution for variable interpretations
Core Modules
Not IAS compliant IAS compliant
IA Module
Balances Information
Soft Classification Definitions
Flexible Accounting Rules
API Calculation Routines
IAS Compliant Accounting & Reporting

IA Module Design
Prerequisite to installation
The implications of the IA implementation are:

Page 12 of 71
IA User Guide
Balance
Classification of
Sheet assets & liabilities
SC Own Book Accounting Rules Requirements

IAS Compliance Questionnaire
Definition
Local IAS
Interpretation Migration Plan
Local GAAP vs. IAS

Analysis Install module and
Customize
Minimise Dual Accounting
AUDITORS
IA Implementation diagram
For each of the tables used there is a full description further on but before the tables can be set up
there is action required away from the system and this is given now.
1. Assess the banks actual requirements.

Banks need to assess with their auditors all financial instruments in their balance sheet and
decide what IAS classification and accounting measurement rule to apply.
2. Assess if there is a Dual Accounting requirement.
Banks need to assess whether there are differences between Local GAAP and IAS39 and
where possible apply only one standard to avoid dual accounting.
3. Draw up the accounting entries actually required.
List out for each ‘product’ the final accounting entries required. For this do not need to consider
dual accounting.
4. Review these entries against T24.
The IA module will not always be necessary for all Banks. The banks staff will need to know and
understand what accounting options are available in all transactional T24 modules in order to
determine whether the accounting functionality in the core module is sufficient to fulfil the
requirements.
5. Ascertain any Dual Accounting requirements.
Where there is a different requirement between Local/company reporting and IAS reporting.
Note it down.
6. Ascertain any cases where T24 does not provide the accounting details required.

Page 13 of 71
IA User Guide
7. Draw up a list of products that will be required to use the IA module. This will be where;
a)Dual Accounting is required. For this T24 should raise the IAS entries and the IA module raise
the Local GAAP requirement
b)Different entries to T24. For example balance sheet entries instead P/L entries.
c) Different calculations. .For example amortised cost based on EIR instead of straight line.
d)Extra calculations. For example Fair value calculation
8. Take the list of entries required for each product and see how they can be obtained. Review each
product and for each pair of entries;
a)Allocate an IAS.AMOUNT.TYPE
b)Decide whether entries contingent or non contingent
c) Decide whether Profit and loss are to be treated the same or different.
d)Decide the Category codes or Asset Types to be used.
e)Decide on the transaction codes
9. Add any entries to cancel out T24 entries.
Where T24 entries are either not required or there is a Dual accounting problem then
Decide which T24 entries need to be cancelled out and allocate IAS.AMOUNT.TYPE etc for
each pair of entries.
10. Review when entries are required.
Some may only be required at maturity and others not at maturity.
11. See how each amount type for each pair of entries can be calculated.
a)Review the entry amount types to see if other amount types are required.
b)For a revaluation amount would need original and current value.
12. For each set of accounting entries you need to determine whether accounting ADJUST or I/O
METHOD is used.
a)On an ADJUST basis the system will post the difference between yesterday value and today’s
value. Note this method should be chosen when you want to pass entries on input and the
reverse entry at maturity where the amount has not changed with in the start and end date of
the contract.
b)On I/O METHOD the system will reverse yesterdays value and repost the new value
13. Decide which position type is required for the entries.
If Dual accounting is required then the positions have to be kept separate. The position type IA
needs to be used for this. This will keep the entries separate.
If not Dual accounting then you should be able to use a position type of TR.
Please note that the IA standards have been interpreted differently between banks, between
regions and countries. It is important to understand the banks’ requirements first before
deciding how T24 and the IA module will fulfil the requirements.

Page 14 of 71
IA User Guide
Structure of IAS module in T24
The IA module consists of the following functionality elements:
The architecture of the module is open and has self-contained accounting rules whilst underlying core
applications maintain their standard accounting behaviour.
Various calculations and algorithms required for IAS compliance are linked to the module through API
routines rather than integrated within the core programs; this feature allows users to incorporate their
own algorithms in addition or in replacement of the delivered core API routines without recurring to
core enhancements. Calculations performed within the module can be stored for information purposes
or for accounting.
The IA module is fully integrated with other core T24 modules. Configuration of the appropriate
parameter files detailed later in this manual will indicate whether a contract/trade should populate the
IAS.CONTRACT.BALANCES file.
Financial instruments are classified (in IAS39 terms) by making use of core or local fields within the
Contract or Own book Portfolio, these fields are used by the IA module to allocate the appropriate
group. Each group contains specific accounting rules and calculations. Classifications are not hard-
coded within the core programs and may be fully defined during the implementation phase based on
the Bank’s requirements.
The frequency with which calculations and accounting entries should be produced is configurable at
overall level by the user.

Page 15 of 71
IA User Guide
Parameter files
The following is a summary of parameter files within the IA module:
Installation level parameters
IAS.PARAMETER Contains high-level parameters such as frequency for calculations,

frequency for accounting, and period before transferring to history.
IAS.CLASSIFICATION The file is used as a reference. It contains all IAS39 instruments
classification codes and a description.
Product level parameters

The following applications must be set up per product.
IAS.AMOUNT.TYPE This application contains all the calculations required by IAS39.

Within the IA module, calculations are known as “amount types”.
IAS.PRODUCT.GROUP Determines the calculation types required for a particular IAS39
instrument classification and the respective accounting rules per
calculation type.
IAS.APPLICATION.PARAM Identifies the base applications that need to be linked to IA. It defines
the static data that needs to be mapped to IA and the calculation
types allowed for a contract of the underlying application.
IAS.PRODUCT.CONDITION Contains the rules by which an underlying contract/position should be
classified (as per IAS financial instrument classification).
IAS.RATE.TYPE Indicates whether the rate type in question is a spread (initial or

current) and whether the rate is FIXED or VARIABLE.
IAS.HEDGE.METHOD Contains per hedge method the API subroutine to be used for
hedge effectiveness calculation
IAS.HEDGE.TYPE Contains per hedge type the name of the amount that should be
retrieved for the hedge effectiveness calculation.
User applications
The following is a summary of all user applications within the IA module:
IAS.CONTRACT.BALANCES This application is the master file for the module and contains
details for each contract/position that is being processed, by
the IA module with the static data defined in
IAS.APPLICATION.PARAM and the calculations (amount
types) specified in IAS.PRODUCT.GROUP. The

Page 16 of 71
IA User Guide
IAS.PRODUCT.CONDITION is used to determine which

records should be mapped into this file.
IAS.CONTRACT.BALANCES.HIST After maturity of an IAS.CONTRACT.BALANCES record
the module archives a copy of the last record for information
purposes.
IAS.BUILD.CONT.BALANCES Using the verify function, this application allows the on-line
update of the balance application. No accounting
movements will take place, but calculation figures can be
viewed for information purposes.
IAS.HEDGE.GROUP This application is used to define micro-hedge groups and
identify individual hedged and hedging items.
Setup
The IAS.PARAMETER and IAS.CLASSIFICATION files are installation level and must be set up
prior to using the IA module.
IAS.PARAMETER
The IAS.PARAMETER record will need to be defined in the system. This parameter file contains
high-level parameters such as frequency for calculations, frequency for accounting, and period before
transferring to history. The key to the file is the company code.
Nb: If in a Multi company/Multi Book area this will need to be done for each Lead Company.
Example IAS.PARAMETER record

Page 17 of 71
IA User Guide
IAS.CLASSIFICATION
IAS39 requires a strict classification of financial assets and liabilities according to their purpose. This
classification is extremely important as it defines specific revaluation and measurement rules to be
applied. Within the IA module this classification is not hard-coded, but totally flexible and should be
defined during the implementation stage of the module. The application IAS.CLASSIFICATION is
used to define these. An example is shown below.
Example IAS.CLASSIFICATION record
Once the IAS.PARAMETER record and the individual IAS.CLASSIFICATION records have been
entered into the system. The user can then start to enter the data in to the product level files for the
items previously decided should be maintained in the IA Module. . This will be the actual entries
required under IAS or Local GAP rules, and the reversal of the original entries passed in T24.
Accounting entries are passed as a pair so that the system is kept in balance. For each amount that
requires accounting entries there needs to be an IAS.AMOUNT.TYPE assigned.
IAS.AMOUNT.TYPE
Rather than encoding the various required IAS39 algorithms within the base module programs, it was
decided to structure the applications in such a way that core, regional, or local API routines may be
easily incorporate through links. This helps our clients to independently develop their own algorithms if
needed.
Amount types are required for ‘amounts’ for which entries are raised. These entries maybe for:
• The reversal of figures from T24

• New calculations.

Page 18 of 71
IA User Guide
To be able to obtain these amounts calculations may need to be performed some of these are straight
mathematical Plus, Minus, Divide Multiply. While others require revaluation processing or other
formulas to be performed and thus a routine needs to be used.
Data may also need to be taken from the T24 files. This can be done by straight mapping of the fields
if the data is on the main T24 application file or by the use a routine to obtain the data from other files.
The various calculations needed within the IA module are known in the IA module as “AMOUNT
TYPES”, and will be referred at such through out this user manual.
This application will contain all the calculations required within the IA Module. Once the bank has
identified all “amount types” per product required a record must be entered in the
IAS.AMOUNT.TYPE file for each.
An amount type may be obtained or calculated through the following means:
• Through an API routine
• By mapping specific figures from the underlying contract or position
• Using a function. The module allows summation, subtraction, multiplication and division
functions to be applied on various amount types to produce a final result. For example: The
cost could be subtracted from the fair value calculation to obtain the unrealised P&L, all
through configuration.
Basic IAS.AMOUNT.TYPE through API routine
The field DEF.EXTRACT.RTN should contain the routine/API that will extract the initial value of the
amount type. This can be specified for each application in IAS.APPLICATION.PARAM, but can be
used if no specific routine is defined for the application.

Page 19 of 71
IA User Guide
The field DEF.VALUE.RTN will hold the routine/API that will perform the latest calculation of the
amount type. The option to calculate the amount type will also be provided per application, If not
defined for the application this is the default.
Calculation of Amount types using functions

If a particular calculation is the product of two or more amount types, rather than developing a routine
to derive the figure, it is possible to configure the calculation.
The CALC.AMT.TYPE field can be used when another IAS.AMOUNT.TYPE record is used to derive
the value in this one. The value in this field must be another valid record from IAS.AMOUNT.TYPE.
This is used in conjunction with field CALC.AMT.OP, which will contain the option to be applied to the
CALC.AMT.TYPE, the value in this field may be one of the operations:
• Plus
• Minus
• Divide
• Multiply
In some instances it may be required to calculate the difference between the original and current
value. Thus an amount type will need to be set up to hold the original value.
Below is an example IAS.AMOUNT.TYPE which is using other IAS.AMOUNT.TYPE’S to derive
its value.

Page 20 of 71
IA User Guide
IAS.AMOUNT.TYPE using a calculation
Amount types mapped from the underlying contract or position

In this case, a similar concept to that used by static data is applied to amount types. The following
configuration steps are required:
1. Create the amount type in IAS.AMOUNT.TYPE. Since this calculation is not performed by an
API routine, the amount type will not contain subroutine names.
2. Map the amount in IAS.APPLICATION.PARAM. In the following example, amount type
LD.COST is being mapped from field DRAWDOWN.NET.AMT of the
LD.LOANS.AND.DEPOSITS application.
AMOUNT.TYPE LD.COST
BALANCE.FIELD MAIN*DRAWDOWN.NET.AMT

Page 21 of 71
IA User Guide
3. Add the amount type to the appropriate IAS.PRODUCT.GROUP record
Calculations and Amount Types

It is possible to specify whether an amount type should be converted to local currency or not. By
default the module will attempt to convert amounts to local currency and store both local and foreign
currency figures in IAS.CONTRACT.BALANCES, if the field CALC.LCY.EQUIV in
IAS.AMOUNT.TYPE is set to “NO”, then the amount will not be converted.
It is possible to treat an amount type as local. By setting the field LCY.AMT.TYPE to “YES” mean’s
that the amount type is treated as a local amount type with the foreign currency being calculated from
the local amount. Any entries raised will be in the local currency thus if an internal account is being
raised the currency in the key will be the local currency. The foreign currency amount is calculated
from the local amount and is used in any P/L entry raised. If set to “No” or “Null” then the amount type
is treated as being for the currency of the contract. Any entries will be raised in the currency of the
IAS.CONTRACT.BALANCES record
The reason why amounts types need to be define in IAS.APPLICATION.PARAM and in

IAS.PRODUCT.GROUP is due to the fact that contracts/positions from various T24 modules could
belong to the same product group.
The following logic is followed when amount types are run:
1. A particular record in IAS.CONTRACT.BALANCES is selected for processing. The first

field in the record identifies the underlying application, for example,
LD.LOANS.AND.DEPOSITS or MM.MONEY.MARKET. This record also identifies
the IAS.CLASSIFICATION, which is automatically assigned by the module.
2. The IAS.PRODUCT.GROUP record is accessed; a list of all amount types or
calculations required for the IAS group is obtained.
3. From the list of amount types, only those found in the underlying
IAS.APPLICATION.PARAM record are run and stored in
IAS.CONTRACT.BALANCES.
With this logic it is possible to have separate routines per module, for example, the routine that
calculates the fair value for a loan can be different to the routine for a securities position.
The account entries can be raised at different stages. The field ACCTNG.STAGE controls this. If the
movement amount is zero the entries will not be raised. The three values are:
• AT-INP or null entries are checked for each day and the reverse entry, raised at maturity.
• AT-REV means entries only checked for at the maturity of the deal

Page 22 of 71
IA User Guide
• NO-REV means entries are checked for each day but at maturity there is no reversal.
The entries can be either CONTINGENT therefore the entries must be CRF below the line or NON-
CONTINGENT (null) entries can be anything and will therefore be above the line. The field
ACCTNG.TYPE is used to determine which.
Examples of amount types are: Fair Value, Premium Discount accrual, Credit Risk, and others.
The following example diagram illustrates the use of amount types:
IAS.PRODUCT.GROUP
This file determines the actual default conditions and accounting treatment to be applied to a contract
that meets the criteria defined in IAS.PRODUCT.CONDITION.

Page 23 of 71
IA User Guide
Example IAS.PRODUCT.GROUP record
As seen in the above screen, a multi-value set of fields identify all the calculations required for a
particular classification, these calculations are known as AMOUNT.TYPES within the IA module. Each
amount type has its own accounting rules, including:
• Whether a particular amount type should produce accounting movements or not. If not, the
amount will be calculated and stored in IAS.CONTRACT.BALANCES, but will not produce
any accounting entries.

Page 24 of 71
IA User Guide
• Link profit type. The user may define different categories/accounts to be updated for profit
entries and for loss entries within one amount. This decision may be dependant not on the
value of the amount in question, but on the value of a different related amount. In this latter
case, the LINK.PROFIT.TYPE field would identify the related amount type.
• Profit category and reserve category. These two categories will be used to book profit
amounts (positive amount).
• Profit debit and credit transaction codes. These fields will identify the transaction codes with
which profit bookings will be performed; these codes must be available in the
TRANSACTION application.
• Loss category and reserve category. These two categories will be used to book loss amounts
(negative amounts).
• Loss debit and credit transaction codes. These transaction codes will be used for loss
accounting entries.
Accounting options
The system will calculate a Profit and Loss Flag and populate the field PRFT.LOSS.FLAG with either
PROFIT or LOSS; this will be set for each amount type on the IAS.CONTRACT.BALANCES
The options available for each amount type are –
Non Contingent:
Post an entry to a PL category or an internal account, with the opposite entry to an internal account or
CRF Asset Type
• Profit
The PL category or Internal account (PRFT.CAT.INTER) is taken to be the credit entry with the
credit transaction code (PRFT.TXN.CD.CR) being used and the other entry (PRFT.RESER.CAT
or PRFT.CRF.CAT) is taken to be the debit entry with the debit transaction code
(PRFT.TXN.CD.DR) being used.
• Loss
PL category or Internal account (LOSS.CAT.INTER) is taken to be the debit entry with the debit
transaction code (LOSS.TXN.CD.DB) being used and the other entry (LOSS.RESER.CAT or
LOSS.CRF.CAT) is taken to be the credit entry with the credit transaction code
(LOSS.TXN.CD.CR).
Contingent
Only post to CRF Asset Type. The entry raised is the opposite entry.

Page 25 of 71
IA User Guide
• Profit
The other entry (PRFT.CRF.CAT) is taken to be the debit entry with the debit transaction code
(PRFT.TXN.CD.DR) being used. Except when the entry is for the maturity of the contract when
the credit transaction code (PRFT.TXN.CD.CR) is used
• Loss
The other entry (LOSS.CRF.CAT) is taken to be the credit entry with the credit transaction code
(LOSS.TXN.CD.CR) being used. Except when the entry is for the maturity of the contract when
the debit transaction code (LOSS.TXN.CD.DB) is used
This allows for the transaction codes of NEW and MAT to be used.
Preferred positing style
Two methods are available. The field POSTING.STYLE on the IAS.PRODUCT.GROUP can be set
to either:
• ADJUST entries are raised for the difference between the previously booked figure and the
new amount
• I.O method (input/output method) entries are raised to reverse previous posting. These entries
will be to the same P/L, Account or CRF using the same transaction codes and amounts
except that the amounts will have the opposite sign. New entries will be raised for the current
amounts etc.
When raising an internal account the entry can either be in the currency of the contract or local
currency. This is determined by the setting of the field LCY.AMT.TYPE on the IAS.AMOUNT.TYPE
record. If it is set to Yes then the internal account is a local currency account. Other wise the account
is in the currency of the contract.
Entries can be between the local currency and the foreign currency of the contract thus the
POSITION can be updated This means that the POSITION updates from this accounting needs to
be kept separate from those from T24 this is achieved by the use of the POSITION.TYPE field which
can be set to IA.
For accounting entries to be raised the field REVAL.ACCTNG in IAS.PRODUCT.GROUP must be

set to Y for accounting processing to occur.
Accounting entries are produced only during the close of business process, and not on-line regardless
of whether the IAS.APPLICATION.PARAM record of the underlying application has been
configured to on-line updates.

Page 26 of 71
IA User Guide
Local reference fields on base applications

In IAS.PRODUCT.CONDITION you need to be able to identify which deals are to be extracted and
by which groups so as to be able to raise the required accounting entries. It may be possible to do
this using the existing fields on the applications do not allow for the full classification to be made it may
by necessary to set up some local reference fields to handle this.
For Loans and Deposits it was thought that two fields may be required an IAS.CLASSIFIC and
IAS.HEDGE field. If these are required then two local references fields need to be set up for
LD.LOANS.AND.DEPOSITS.
For securities processing the local references fields will need to be set up on the SEC.ACC.MASTER
with pointers from the SEC.TRADE.
IAS.PRODUCT.CONDITION
The parameter file IAS.PRODUCT.CONDITION is used to identify the criteria with which to group
the underlying contracts. Groups or classifications are specified at T24 application level, therefore the
key to IAS.PRODUCT.CONDITION is the T24 application name, such as
LD.LOANS.AND.DEPOSITS.
A record is set up for each application where details need to be mapped into the IA module. If a
contract does not match any of the conditions then it will not be taken across, only one record may be
defined per application.
Please note that for multi currency applications like FOREX the key to this field will only be the
application name i.e FOREX.

Page 27 of 71
IA User Guide
Example IAS.PRODUCT.CONDITION for LD module
In the above example we are stating that LD – Available for Sale Asset contracts fall in the category
range 21050 – 21099 and LD Available for Sale Liability contracts fall in the range of 21001-21049.

Page 28 of 71
IA User Guide
IAS.PRODUCT.CONDITION
In the above example, two fields are verified in the LD.LOANS.AND.DEPOSITS application to
classify IAS contracts, these are: IAS.CLASSIFIC and IAS.HEDGE. In this example the fields used
are LOCAL FIELDS; any field within the data dictionary of the main application can be used.
The above setup translates into the following:

Page 29 of 71
IA User Guide
IAS Classification Criteria 1 Criteria 2

AFS (available for sale) Field IAS.CLASSIFIC must No further criteria required
contain value “AFS”
AFS.FVH (available for sale, fair Field IAS.CLASSIFIC must AND, field IAS.HEDGE must
value hedge) contain value “AFS” contain value “FV.HEDGE”
There will be cases where the classification is not defined by fields in the underlying contract, but
rather by a separate application. Such is the case of own book securities portfolios. The IAS
classification will not be identified within the SEC.TRADE transactions, but within the portfolio
definition in SEC.ACC.MASTER.

Page 30 of 71
IA User Guide
IAS.PRODUCT.CONDITION using pointers to SEC.ACC.MASTER
Although the above definition appears to be identical to the one previously shown for
LD.LOANS.AND.DEPOSITS, in this case fields IAS.CLASSIFIC and IAS.HEDGE are not local
fields within SEC.TRADE but pointers (I-descriptors) to local fields created in SEC.ACC.MASTER.

Page 31 of 71
IA User Guide
In summary the
combination of definitions in IAS.PRODUCT.GROUP and
IAS.PRODUCT.CONDITION allows the user to decide:
• What IAS classifications are relevant to the Bank’s balance sheet?

• Per IAS classification, what calculations are required? These calculations will be performed
by API routines known as “AMOUNT TYPES”.
• Per amount type, decide the accounting rules to be applied.
IAS.APPLICATION.PARAM
In order to map data to the IAS.CONTRACT.BALANCES record, the
IAS.APPLICATION.PARAM must be configured. This file identifies the base applications that need
to be linked to IA.
As well as the static data, the amount types allowed for a contract of the underlying application should
also be defined here. The key to the IAS.APPLICATION.PARAM is the name of the underlying
application which triggers an IA update. It is the T24 authorisation process that triggers an update to
IA, therefore application names defined in this parameter file should be user applications rather than
internal applications, for example; a valid id would be SEC.TRADE, but not
SC.TRADING.POSITION.
The IAS.CONTRACT.BALANCES records only show one currency plus local currency equivalent
thus for applications like FOREX which have records with two currencies in it, two records need to be
maintained. To cater for entries needing to be raised in local currency at the deal level a third record
is required. For FOREX these are FOREX-BUY, FOREX-SELL and FOREX-NET. For each of these a
record has to be set up here on IAS.APPLICATION.PARAM
The fields APPL.FIELD, BALANCES.FIELD and MAP.ACTION are used to specify the mapping of
static information, from the underlying contract to the corresponding IAS.CONTRACT.BALANCES
record. In the following example we are using the LD.LOANS.AND.DEPOSIT application.

Page 32 of 71
IA User Guide
Example IAS.APPLICATION.PARAM record
For most contracts, the information will be taken from the underlying application identified in the ID of
this parameter file. In areas such as SECURITIES, the IA figures should be maintained at position
level rather than transaction/contract level. For example, the authorisation of a SEC.TRADE
containing own book trade should trigger an update to IAS.CONTRACT.BALANCES; nevertheless,
the ID of the record updated should not be the SEC.TRADE key, but rather the

Page 33 of 71
IA User Guide
SECURITY.POSITION key. Furthermore, the static data populated for IAS should be from the
under lying position rather than the trade. To cater for these cases IAS.APPLICATION.PARAM
allows the definition of a BASE.APPLICATION and BASE.KEY
IAS.APPLCATION.PARAM record for SEC.TRADE
When mapping static data; either the BASE application or the MAIN application could be used as a
source.
Although the field BASE.KEY must be a data dictionary item of the main application, this dictionary
item could be an i-descriptor containing a subroutine.
The BASE.KEY is the field which will give the key to the base application and for securities it can be
two fields, separated by a coma, which will give the two components for SC.TRADING.POSITION
file. That is the SEC.ACC.MASTER in field CUST.SEC.ACC and the SECURITY.MASTER key in

Page 34 of 71
IA User Guide
SECURITY.CODE, which will be combined together separated by a dot to form the key to
SC.TRADING.POSITION.
For applications like FOREX which have two currencies on them. The base application needs to be
set to FOREX and the base key can be any field on a FOREX file, recommended to use
COUNTERPARTY.
Example using both MAIN and BASE application

Page 35 of 71
IA User Guide
The above definitions for currency and account officer translate as follows:
IAS.CONTRACT.BALANCES
Map from SEC.TRADE or Source field to map Update on
field to be mapped? SC.TRADING.POSITION? BUILD and/or
MODIFY
CURRENCY Map from MAIN application SECURITY.CURRENCY BUILD
SEC.TRADE
ACCOUNT.OFFICER Map from BASE application ACCOUNT.OFFICER MODIFY
SC.TRADING.POSITION
A constant can be mapped in which case it must start with either ‘ or “. This is required for the
currency on FOREX-NET record and will be the local currency code. For each AMOUNT.TYPE that
needs to be maintained on IAS.CONTRACT.BALANCES an entry in the multi value field set
AMOUNT.TYPE to CALC.ALSO needs to be made.
IAS.APPLICATION.PARAM BALANCE.FIELD
In this set for amounts both foreign and local can be mapped to fields BALANCE.FIELD and
BALANCE.FLD.LCL. As shown in the above example

Page 36 of 71
IA User Guide
If the mapping is enclosed by brackets it means that the amount in this field is multiplied by -1 before
storing on IAS.CONTRACT.BALANCES, see example below.
IAS.APPLCIATION.PARAM with a bracketed BALANCE.FIELD
As amount type can be used by another amount type the order in which they are processed is
significant thus the field CALC.ORDER may need to be set.
Sometimes an API routine will calculate two pieces of information in which case the field CALC.ALSO
needs to be set linking back to a previous AMOUNT.TYPE.

Page 37 of 71
IA User Guide
IAS.APPLCIATION.PARAM using CALC.ORDER & CALC.ALSO
IAS.CONTRACT.BALANCES
Application IAS.CONTRACT.BALANCES is the repository of all IAS balances calculated for a
specific contract or position. This application is also updated with static data needed for calculations
and procedures; Examples of static data should be mapped from the underlying contract/position are:
Currency, Maturity date and Customer.
Static data may be mapped once upon creation of the contract or position (BUILD), or could be
updated subsequently when changes take place (MODIFY).
All figures returned by the API routines linked to the IA module are stored in
IAS.CONTRACT.BALANCES. These figures can be used either for information purposes, or for
accounting.
IA Contract Details update
There are three methods by which to create and update an IAS.CONTRACT.BALANCES.

Page 38 of 71
IA User Guide
At Authorisation Stage: If Application IAS.APPLICATION.PARAM, field

TRIGGER.UPD.AT.AUT determines whether the IA
application should be updated on-line (upon authorisation of
the underlying contract/transaction) or during the Close of
Business.
When on-line update is requested, the static data will be
mapped online and all amounts/calculations defined at product
group level will be executed and updated in IA, but no
accounting entries will be produced as these only take place
during the close of business.
During Close of Business: If application IAS.APPLICATION.PARAM, field
TRIGGER.UPD.AT.AUT contains a flag indicating that
updates should occur only during close of business, the
authorisation process of core T24 would update a reference
of the contract/transaction in an internal file called
IAS.CONTRACTS.PENDING, this includes first-time
contracts/positions and modifications to existing
contracts/positions. The close of business process will
retrieve all pending contracts and update
IAS.CONTRACT.BALANCES.
On demand with
application Ad-hoc updates to IAS.CONTRACT.BALANCES can be
IAS.BUILD.CONT. BALANCES: performed by using application
IAS.BUILD.CONT.BALANCES with function Verify.
The methods which can be used within this application are:
BUILD:
Will clear the contents of IAS.CONTRACT.BALANCES for
the contract/position being processed, and will rebuild the
static data and will recalculate all the amounts.
MODIFY:
Will only update IAS.CONTRACT.BALANCES without
clearing current information.
REVERSE:
Will simulate a reversal of the underlying contract.
It is expected that this application will only be used during the
implementation phase for ad-hoc tests.
The above methods are used when the underlying application has a new contraction/position or when
an existing contract/position is modified and an update to IAS.CONTRACT.BALANCES is required,
for example, if the MATURITY.DATE of the underlying contract is modified, this would trigger an
update to IAS.CONTRACT.BALANCES.
The first part of the IAS.CONTRACT.BALANCES record contains the ‘static’ type information about
the contract.

Page 39 of 71
IA User Guide
Static data for IAS.CONTRACT.BALANCES
There are then a set of multi value fields for each AMOUNT.TYPE. These fields are split into two
sections those covering the calculation and those cover the accounting entries.
For the Calculation there are the following fields;
• TYPE.ORIG.BAL and TYP.ORG.LCY.BAL these are created when the record is built
• TYPE.LAST.BAL and TYP.LAST.LCL.BAL these are created when the record is built and
updated by the calculation run made in the COB.
• When the calculation run is made the fields LAST.VALUE.MVMT, LST.VAL.MVT.LCL,
LAST.MVMT.DATE and PRFT.LOSS.FLAG are updated, when there is a change in the
TYPE.LAST.BAL.
If an AMOUNT.TYPE is set for local equivalent to be calculated (CALC.LCY.EQUIV is YES) then only
the field TYP.LAST.LCL.BAL is updated, if no mapping or API is attached.

Page 40 of 71
IA User Guide
IAS.CONTRACT.BALANCES – Calculation fields
For Accounting there are the following fields;
• ACCOUNTING.BAL, ACCOUNTING.LCL and ACCOUNTING.DATE which are updated when

the first set of accounting entries raised for this amount type
• When accounting run next made the fields LAST.ACTG.BAL and LAST.ACTG.LCL are
updated with the amounts in ACCOUNTING.BAL and ACCOUNTING.LCL then
ACCOUNTING.BAL and ACCOUNTING.LCL are calculated and updated and
ACCOUNTING.DATE is also updated.
• When the contract reaches Maturity the LAST.ACTG.BAL and LAST.ACTG.LCL fields are
updated. The ACCOUNTING.BAL and ACCOUNTING.LCL are not changed but the
ACCOUNTING.DATE field is updated.
• For an AMOUNT.TYPE which is set NO-REV then the Accounting fields are not updated on
the maturity date and the date in ACCOUNTING.DATE will be the run before maturity.
• For an AMOUNT.TYPE which is AT-REV then the ACCOUNTING.BAL, ACCOUNT.LCL and
ACCOUNTING.DATE will only be updated on the maturity date

Page 41 of 71
IA User Guide
IAS.CONTRACT.BALANCES account fields
The field CONSOL.KEY will contain the CONSOL.KEY from the base application with the SYSTEM.ID
part changed to IA.

Page 42 of 71
IA User Guide
IAS.CONTRACT.BALANCES showing CONSOL.KEY
For applications like FOREX where more than one record needs to be maintain on
IAS.CONTRACT.BALANCES there will be a record under the Contract ID and it will only have the
fields LINK.APP.ID and LINK.REC.ID completed
For FOREX there will be three entries
ICB record showing linked records

Page 43 of 71
IA User Guide
List of ICB for a FOREX deal
Periodic updates to IAS.CONTRACT.BALANCES are required in order to refresh the calculations.

On user-defined frequencies, two close of business processes will run, the first will call the API
routines and will update the new figures, the second process will book accounting entries for those
amounts that have been flagged to do so. Parameter file IAS.PARAMETER will contain the
frequencies for calculation and bookings.
Example IAS.PARAMETER

Page 44 of 71
IA User Guide
Rate Types
Different rates types and spreads are need for IAS39 calculations. A rate type can be a fixed
rate/spread or a key to PERIODIC.INTEREST.
The application IAS.RATE.TYPE is used to identify all rates required by the API routines. Although this
application will not contain the actual rate or key to be used, it is vital to define all rates in the
application in order for IAS.CONTRACT.BALANCES to be populated with the appropriate
information.
The IA module is deployed with API routines that make use of rate types. The identifier of the rate type
is important, since it is hard-coded in the subroutines. For example, rate type FV.RATE will be used in
the fair value calculation for Loans and Deposits.
The following steps should be followed to define rate types.
IAS.RATE.TYPE definition
This application identifies whether the rate type is:
• Fixed or Variable: If variable the API routine will expect to find a PERIODIC.INTEREST entry.
• Initial Spread or Current Spread
IAS.RATE.TYPE
All RATE.TYPES required by an IAS calculation must be added to IAS.AMOUNT.TYPE as follows:

Page 45 of 71
IA User Guide
IAS.AMOUNT.TYPE with rate type linked
If the value of a rate

type is found in the underlying contract/portfolio, then
IAS.APPLICATION.PARAM should contain the field from which the value will be mapped.
IAS.APPLICATION.PARAM with rate type mapped
In the above example rate type FV.RATE will be mapped from application
LD.LOANS.AND.DEPOSITS, field FV.RATE.KEY.
If the value of a rate type is common to all contracts/portfolios within an IAS39 classification, then
rather than defining it at individual contract level, it can be defined at group level.

Page 46 of 71
IA User Guide
IAS.PRODUCT.GROUP with rate type defined
In the above example, any IAS.AMOUNT.TYPES using rate type FV.RATE would use the rate/key
defined in IAS.PRODUCT.GROUP.
The definition in IAS.APPLICATION.PARAM will have higher priority than that found in
IAS.PRODUCT.GROUP.
Retrieving a rate
The IA module will attempt to update IAS.CONTRACT.BALANCES with the relevant rate
information during the close of business process.
Through this process, there would be no need for each amount type to apply the logic and obtain the
appropriate rate, but rather, access IAS.CONTRACT.BALANCES and obtain the rate/key directly.
The logic followed by the IA module to populate the rate type values is as follows:
1. Each IAS.CONTRACT.BALANCES record is processed individually

2. The amount types needed by each contract are retrieved, each amount type is read from
IAS.AMOUNT.TYPE
3. The list of RATES needed by each amount type is obtained.
4. Each IAS.RATE.TYPE is then assessed and the value populated in
IAS.CONTRACT.BALANCES. The logic used to retrieve the value is as described above
using IAS.APPLICATION.PARAM and IAS.PRODUCT.GROUP)

Page 47 of 71
IA User Guide
IAS.CONTRACT.BALANCES with rate types mapped
Dual Accounting process

As part of the IAS39 project, the need to produce separate general ledgers for LOCAL GAAP and for
IAS39 was identified.
The Ledger Reporting module allows the exclusion of particular report lines based on the type of
report being produced. The RE.STAT.REPORT.HEAD application allows different versions of
reports to be produced (e.g. in foreign currency, in local currency) and will now additionally allow
specific lines to be suppressed for that version of the report.
Please refer to the Reporting User Guide for dual accounting set-up and operation details.

Page 48 of 71
IA User Guide
Hedging
Currently the IA Module only supports basic hedging functionality. It will identify the difference
between hedged and non hedge contract and deal with each separately within accounting. However
the current functionality does not monitor hedged deals, therefore both monitoring and adjusting must
be done manually.
The first release of the module includes application IAS.HEDGE.GROUP to allow the user to
document the micro hedge relationship.
IAS.HEDGE.GROUP
The application IAS.HEDGE.TYPE should contain all the possible hedge types along with the
IAS.AMOUNT.TYPES that should be retrieved by the module to calculate the hedge effectiveness.
The amount type figures will be obtained from IAS.CONTRACT.BALANCES and placed in
IAS.HEDGE.GROUP.

Page 49 of 71
IA User Guide
IAS.HEDGE.TYPE
The application IAS.HEDGE.METHOD contains the names of the API routines to be run for the
calculation of hedge effectiveness. This functionality has not yet been activated.
IAS.HEDGE.METHOD

Page 50 of 71
IA User Guide
API
Calculations
Amount types calculated through an API routine
The arguments required or returned by the API routine are the following:
Argument 1 - (AMOUNT.TYPES.PASS) Incoming: Contains the name of the AMOUNT TYPE being
processed
Argument 2 Outgoing argument: Contains the figure calculated by the
(AMOUNT.BALANCES.PASS) amount type routine.
Argument 3 - (REF.RATE.KEYS) Incoming: This argument will contain rate types associated
with the amount type being processed.
Argument 4 - (R.APPLICATION.PARAM Incoming: Copy of IAS.APPLICATION.PARAM record.
Argument 5- (APPL) Incoming: Name of underlying MAIN application.
Argument 6 - (TRANSACTION.ID) Incoming: ID of the IAS.CONTRACT.BALANCES record
being updated.
Argument 7 - (R.RECORD.APPL) Incoming: Copy of underlying contract/position record.
Argument 8 - (APPL.MULTI.VALUE) Incoming: Indicates whether multiple processing is to be
performed.
Argument 9 - (BASE.APPL) Incoming: Name of BASE application.
Argument 10 - (R.RECORD.BASE) Incoming: Contains name of base application, if it has
been defined in IAS.APPLICATION.PARAM.
Argument 11 - Incoming: Copy of IAS.CONTRACT.BALANCES record.
(R.CONTRACT.BALANCES.PASS) This will only contain figures for amount types calculated
during the current process. All previous amount types will
be cleared.
Argument 12 - (R.PRODUCT.GROUP) Incoming: Copy of IAS.PRODUCT.GROUP record
Argument 13 - (ACTION) Incoming: indicates whether the update is due to an initial
update “BUILD”, a modification “MODIFY” or the reversal
of the underlying contract “REVERSE”
The following sequence of configuration is required for amount types:
1. Develop a subroutine using the above-described arguments. For further information

regarding Please refer to the T24 programming standards section of the API Developers
Guide of the T24 user manual for further information.
2. Create a PGM.FILE record for the subroutine. Ensure that Type is set to “S”.
3. Create a record in IAS.AMOUNT.TYPE specifying the AMOUNT.TYPE name and
subroutine name.
4. Include the amount type in the appropriate IAS.APPLICATION.PARAM record.

Page 51 of 71
IA User Guide
5. Add the amount type to the IAS group definition in IAS.PRODUCT.GROUP.
IAS.SC.IRR.CALCULATION
This routine is used to return the Internal Rate of Return (IRR) of basic bond type securities.
The IRR will be calculated at the end of the day. The TRIGGER.UPD.AT.AUT flag should be set to
NO in IAS.APPLICATION.PARAM keyed on the application used (e.g. SEC.TRADE,
ENTITLEMENT).
Format Subroutine name

Subroutine name must be defined in the PGM.FILE as a type S program.
Invoked From IAS.AMOUNT.TYPE

Defined in DEF.EXTRACT.RTN and DEF.VALUE.RTN fields
Details The IRR is calculated only for the bonds and for the portfolios that do not already use
the COMPOUND method.
This routine calls IAS.SC.CALC.IRR.DPA subroutine with the parameter “IRR” to
calculate the appropriate IRR values.
The calculation is performed during the end of the day.
The IRR / Yield calculation is performed using the following calculation
⎛ redemption rate ⎞ ⎛ par ⎛ A rate ⎞ ⎞

⎜⎜ + ⎟⎟ − ⎜⎜ + ⎜⎜ × ⎟⎟
⎝ 100 frequency ⎠ ⎝ 100 ⎝ E frequency ⎟⎠ ⎟⎠ frequency × E
YTM = ×
par ⎛ A rate ⎞ DSR
+ ⎜⎜ × ⎟⎟
100 ⎝ E frequency ⎠

Page 52 of 71
IA User Guide
Where:
Variable Definition
A number of days from the beginning of the coupon period to the settlement
date (accrued days)
DSR number of days from the settlement date to the redemption date
E number of days in the coupon period
⎡ ⎤ ⎡ ⎤
⎢ ⎥ ⎢ 100 *
CF ⎥
⎢ redemption ⎥ ⎢N frequency ⎥ ⎛ CF A⎞
PRICE = ⎢ ⎛ DSC ⎞
⎥ + ⎢∑ ⎛ DSC ⎞
⎥ − ⎜⎜100 * * ⎟⎟
⎢⎛ ⎜ N −1+
E ⎠ ⎥
⎟ ⎢ k =1 ⎛ ⎜ k −1+
E ⎠ ⎥
⎟ ⎝ frequency E ⎠
YTM ⎞ ⎝ YTM ⎞ ⎝
⎢ ⎜⎜1 + ⎟ ⎥ ⎢ ⎜⎜1 + ⎟ ⎥
⎣⎢ ⎝ frequency ⎟⎠ ⎦⎥ ⎣⎢ ⎝ frequency ⎟⎠ ⎦⎥
Variable Definition
YTM Yield to Maturity

PRICE market price
Redemption security's redemption value
CF security's annual coupon rate
Frequency number of coupon payments per year (for annual payments, frequency = 1; for semi-
annual, frequency = 2; for quarterly, frequency = 4)
DSC number of days from settlement to next coupon date
A number of days from beginning of coupon period to settlement date
E number of days in coupon period in which the settlement date falls
N number of coupons payable between settlement date and redemption date

Page 53 of 71
IA User Guide
IAS.SC.IS.DISCPREM
This routine is used to return the Issued Discount Premium Accrual of securities on transactions.
The accruals are calculated at the end of the day. The TRIGGER.UPD.AT.AUT flag should be set to
NO in IAS.APPLICATION.PARAM keyed on the application used (e.g. SEC.TRADE,
ENTITLEMENT).


Details The Issued Discount Premium Accrual is calculated only for the bonds and for those
portfolios that do not already use the COMPOUND method.
This routine calls the IAS.SC.CALC.IRR.DPA subroutine with the parameter “DPA” to
get the Issued Discount Premium Accrual.

Page 54 of 71
IA User Guide
IAS.SC.IRR.DISCPREM
This routine is used to return both the IRR and Issued Discount Premium Accrual of basic bond-type
securities. This routine may replace the two previously stated routines as it uses the same processing.
This routine performs the calculations during the end of the day. The TRIGGER.UPD.AT.AUT flag
should be set to NO in IAS.APPLICATION.PARAM keyed on the application used (e.g.
SEC.TRADE, ENTITLEMENT).

Invoked From the two IAS.AMOUNT.TYPE records defined for the IRR and the Issued
Discount Premium Accrual (IDPA)
Details The IRR and Issued Discount Premium Accrual are calculated only for the bonds and
for the portfolios that don’t already use the COMPOUND method.
This subroutine can be used instead of the IAS.SC.IRR.CALCULATION and the

IAS.SC.IS.DISCPREM routines to have the both calculations in the same time. This
routine can’t be used to have either the IRR or IDPA.
This routine calls the IAS.SC.CALC.IRR.DPA subroutine with the parameter “BOTH”
to get the Issued Discount Premium Accrual as first parameter and IRR as the second
one.

Page 55 of 71
IA User Guide
IAS.SC.CALC.IRR.DPA
This subroutine is used to calculate the IRR and/or the Issued Discount Premium Accrual of securities
on transactions depending on the input parameters.
Format Three input parameters
R.RECORD.BASE – the record BASE

APPL – application
IRR.DPA – that can be “IRR”, “DPA” or “BOTH”
One output parameter
RESULT - that can be IRR and/or DPA depending on the IRR.DPA input
parameter
Invoked This subroutine is called from IAS.SC.IRR.CALCULATION, IAS.SC.IS.DISCPREM,

IAS.SC.IRR.DISCPREM and IAS.SC.FV.CALCULATION.

Page 56 of 71
IA User Guide
IAS.SC.CORE.ACCRUALS
This routine is used to return the discount accruals calculated in the core system after the end of the
day. This routine can be used as information purpose to check the adjustment done between the
linear and compound accruals.
The TRIGGER.UPD.AT.AUT flag should be set to NO in IAS.APPLICATION.PARAM keyed on the

application used (e.g. SEC.TRADE, ENTITLEMENT).

Invoked From the two IAS.AMOUNT.TYPE

Details The core accruals are picked up only for the no compound portfolio that has bond
security.
The information is done at the end of the day depending on the updating of the
SC.TRANS.POS.HISTORY file keyed on the same portfolio and security.

Page 57 of 71
IA User Guide
IAS.SC.ADJ.ACCRUALS
This routine returns the adjustment between the core linear accruals and the compound accruals
calculated for the new standard rules.
This calculation is done at the end of the day depending on the TRIGGER.UPD.AT.AUT flag set to
NO in IAS.APPLICATION.PARAM keyed on the application used (e.g. SEC.TRADE).


Details The adjustment is calculated only for the bonds and for the portfolios that do not
already use the COMPOUND method.
This routine calls the IAS.SC.CALC.IRR.DPA subroutine with the parameter “DPA” to
get the Issued Discount Premium Accrual and subtracts the core linear accruals.
The calculation is done at the end of the day.

Page 58 of 71
IA User Guide
IAS.SC.FV.CALCULATION
This routine is used to return the revaluation of the security.
This routine is called at the end of the day depending on the TRIGGER.UPD.AT.AUT flag set to NO
in IAS.APPLICATION.PARAM keyed on the application used (e.g. SEC.TRADE).


Details The routine calculates first an estimation of the position regarding the nominal and the
last price. Then the current cost is subtracted. In case of bond, this revaluation
amount should also include the Issued Discount Premium Accruals as calculated via
IAS.SC.CALC.IRR.DPA called with the “DPA” input parameter.
Fair Value is calculated as follows:

Bonds:
• CURRENT.POSITION * (LAST.PRICE / 100) +/- DISCOUNT ACCRUED or PREMIUM
AMORTISED TO DATE
Shares:
• CURRENT.POSITION * LAST.PRICE

Page 59 of 71
IA User Guide
IAS.LD.IRR.CALCULATION
This routine is used to return the Effective Interest Rate (EIR) of loans and deposits.
The EIR should be calculated at the end of the day. The TRIGGER.UPD.AT.AUT flag should be set
to NO in IAS.APPLICATION.PARAM keyed on the LD.LOANS.AND.DEPOSITS application.


Details The EIR is calculated only if the IAS.CLASSIFICATION is defined in the

LD.LOANS.AND.DEPOSITS record
The IAS.LD.IRR.CALCULATION routine calls IAS.CALC.IRR.LD subroutine to
calculate the EIR. This subroutine will calculate the NPV future movement on an exact
base 365 days on an actuarial base.
⎡ ⎤ ⎛ nbd − D ⎞
⎢ k
Ax ⎥ ⎜ ⎟
S = ⎢∑ ⎛ k *m* f ⎞ ⎥
(1 + i ) ⎝ 365 ⎠
Formula ⎜ ⎟
⎢ (1 + i ) ⎝ x ⎠ ⎥
i =1
⎣ ⎦
Where S = capital
k = number of days between the date of payment and the date of future movement
m = total number of days of the contract
i = iteration
A = amount of the movement
k = payment number
m = 365/12
f = number of frequency
D = frequency * number of days per month
nbd = number of days between the value date of the contract and the first movement
date

Page 60 of 71
IA User Guide
IAS.LD.IS.DISCPREM
This routine is used to return the Issued Discount Premium Accrual (DPA) of loans and deposits.
DPA should be calculated at the end of the day. The TRIGGER.UPD.AT.AUT flag should be set to
NO in IAS.APPLICATION.PARAM keyed on the LD.LOANS.AND.DEPOSITS application.

Subroutine name must be defined in the PGM.FILE as a type S program

Details The DPA is calculated only if the IAS.CLASSIFICATION is defined in the

The effective rate is applied to the total issued premium or discount to calculate the
discount/premium amortization
The calculation is done at the end of the day
⎛ ⎟⎞
⎛ NBD ⎞
⎜ (1 + YM )⎜
⎝ YD ⎠ ⎟ − 1
Amort = Discount. Pr emium * ⎝ ⎠

Formula
⎛ ⎟⎞
⎛ DM ⎞
⎜ (1 + YM )⎝ YD ⎠ ⎟ − 1
⎜
⎝ ⎠
Where YM = Effective rate

NBD = number of days to accrue
DM = number of days to maturity
YD = number of days in year
DISCOUNT.PREMIUM is fetched from the ISSUE.PL.AMOUNT field of LD
application.

Page 61 of 71
IA User Guide
IAS.LD.IRR.DISCPREM
This routine is used to return both of the Effective Interest Rate (EIR) and the Issued Discount
Premium Accrual (DPA) of loans and deposits. This routine may replace the two previous one.
These values should be calculated at the end of the day. The TRIGGER.UPD.AT.AUT flag should be
set to NO in IAS.APPLICATION.PARAM keyed on the LD.LOANS.AND.DEPOSITS application.

Invoked From IAS.AMOUNT.TYPE records defined for EIR and DPA

Details The EIR and DPA are calculated only if the IAS.CLASSIFICATION is defined in the
The effective rate is applied to the total issued premium or discount to calculate the
discount/premium amortization

Page 62 of 71
IA User Guide
IAS.LD.RD.DISCPREM
This routine is used to return the Redemption Discount Premium Accrual (RDPA) of loans and
deposits. It is calculated like the Issued Discount Premium amortization.
RDPA should be calculated at the end of the day. The TRIGGER.UPD.AT.AUT flag should be set to
NO in IAS.APPLICATION.PARAM keyed on the LD.LOANS.AND.DEPOSITS application.

Subroutine name must be defined in the PGM.FILE as a type S program

Details The RDPA is calculated only if the IAS.CLASSIFICATION is defined in the

The effective rate is applied to the total redemption premium or discount to calculate
the redemption discount/premium accrual
⎛ ⎟⎞
⎛ NBD ⎞
⎜ (1 + YM )⎝ YD ⎠ ⎟ − 1
⎜
Amort = Discount. Pr emium * ⎝ ⎠

Formula
⎛ ⎟⎞
⎛ DM ⎞
⎜ (1 + YM )⎝ YD ⎠ ⎟ − 1
⎜
⎝ ⎠
Where YM = Effective rate

NBD = number of days to accrue
DM = number of days to maturity
YD = number of days in year
Discount.Premium is fetched from the REIMBURSE.PL.AMOUNT field of LD
application.

Page 63 of 71
IA User Guide
IAS.LD.FAIR.VALUE
This routine is used to return the Fair Value of loans and deposits.
There are three different methods of calculating Fair Value done thru this routine at the end of the day.

Invoked The IAS.AMOUNT.TYPE keys should be the name of the Fair Value method of
calculation used:
1. “IAS.LD.FAIR.VALUE.1” discounts cash flow using maturity date
2. “IAS.LD.FAIR.VALUE.2” discounts cash flow using duration rate
3. “IAS.LD.FAIR.VALUE.3” discounts cash flow using cash flow rates
IAS.LD.FAIR.VALUE routine should be called in DEF.EXTRACT.RTN and

DEF.VALUE.RTN fields for these 3 methods of calculating Fair Value.
Details The Fair Value is calculated only if the IAS.CLASSIFICATION is defined in the
LD.LOANS.AND.DEPOSITS record.
This routine will calculate the Fair Value with a method of calculation based on the
IAS.AMOUNT.TYPE key defined.
• “IAS.LD.FAIR.VALUE.1” The future cash flows are discounted using the rate
of the maturity date of the instrument
of the duration of the instrument
of the future cash flow date
For these 3 methods of calculating Fair Value the rate is either fixed or variable
depending on the FIXED.VARIABLE field of the IAS.RATE.TYPE application keyed
on “FV.RATE” and/or “FV.MARGIN”. A fixed rate uses a percentage. A variable rate
uses the PERIODIC.INTEREST curve.

Page 64 of 71
IA User Guide
Formula The 3 methods of calculating Fair Value used the same formula. Only the EIR
changed depending on the maturity date (method 1), duration date (method 2) or
payment date (method 3).
⎛ i=k ⎞
⎜ Ak ⎟
FairValue =sum ⎜ − FVDATE ⎞ ⎟⎟
i =1 ⎜ (1 + EIR )⎛⎜⎝ TODAY YD ⎟
⎝ ⎠ ⎠
Where k = number of payment

Ak = amount of the movement
EIR = Effective Interest Rate
FVDATE = event date
YD = number of days per year.

Page 65 of 71
IA User Guide
IAS.LD.FAIR.VALUE.REVAL
This routine is used to return both of the Fair Value and the revaluation amounts of loans and deposits.
This routine should be used like the IAS.LD.FAIR.VALUE routine. The Fair Value will be returned as
one output parameter. And the revaluation between the original Fair Value calculated and the last one,
will be also returned.
There are always the 3 different methods of calculating Fair Value done thru this routine at the end of
the day. The TRIGGER.UPD.AT.AUT flag should be set to NO in IAS.APPLICATION.PARAM
keyed on the LD.LOANS.AND.DEPOSITS application.

calculation used:
1. “IAS.LD.FAIR.VALUE.1” discounts cash flow using maturity date
2. “IAS.LD.FAIR.VALUE.2” discounts cash flow using duration rate
3. “IAS.LD.FAIR.VALUE.3” discounts cash flow using cash flow rates
IAS.LD.FAIR.VALUE.REVAL routine should be called in DEF.EXTRACT.RTN and

DEF.VALUE.RTN fields for these 3 methods of calculating Fair Value. This routine
should be also input in the IAS.AMOUNT.TYPE records of the Revaluation.
Details The Fair Value and revaluation are calculated only if, the IAS.CLASSIFICATION is
defined in the LD.LOANS.AND.DEPOSITS record.
The details and the formula used are the same than ones of IAS.LD.FAIR.VALUE
routine.

Page 66 of 71
IA User Guide
IAS.LD.CREDIT.RISK
This routine is used to return the credit risk of loans and deposits at the end of the day. The
TRIGGER.UPD.AT.AUT flag should be set to NO in IAS.APPLICATION.PARAM keyed on the
The credit risk is based on the Fair Value using an initial and a current spreads. Thus, the same
methods of calculating Fair Value as described above will be used.

Invoked The IAS.AMOUNT.TYPE keys should be based on a one of the methods of

calculating the Fair Value used:
1. “IAS.LD.CREDIT.RISK.1” discounts cash flow using maturity date
2. “IAS.LD. CREDIT.RISK.2” discounts cash flow using duration rate
3. “IAS.LD. CREDIT.RISK.3” discounts cash flow using cash flow rates
4. “IAS.LD.CREDIT.RISK” discounts cash flow using maturity date and the
interest day basis defined in LD application.
AS.LD.CREDIT.RISK routine should be called in DEF.EXTRACT.RTN and

DEF.VALUE.RTN fields for these 4 methods of calculating.
Details The credit risk is calculated only if the IAS.CLASSIFICATION is defined in the
LD.LOANS.AND.DEPOSITS record.
This routine will calculate the credit risk with a method of calculation based on the
The Fair Value rate and the Fair Value margin are either fixed or variable depending
on the FIXED.VARIABLE field of the IAS.RATE.TYPE application keyed on
“FV.RATE” and/or “FV.MARGIN”.
The initial spread and the current spread have to be defined in IAS.RATE.TYPE as
“INITIAL.SPREAD” and “CURRENT.SPREAD”.
Formula See the Fair Value formula above.

Page 67 of 71
IA User Guide
IAS.MM.FAIR.VALUE
This routine is used to return the Fair Value of Money Market.
There are four different methods of calculating Fair Value done thru this routine at the end of the day.
MM.MONEY.MARKET application.

calculation used:
1. “IAS.MM.FAIR.VALUE.1” discounts cash flow using maturity date
2. “IAS.MM.FAIR.VALUE.2” discounts cash flow using duration rate
3. “IAS.MM.FAIR.VALUE.3” discounts cash flow using cash flow rates
4. “IAS.MM.FAIR.VALUE” discounts cash flow using maturity date and the
interest day basis defined in MM application.
IAS.MM.FAIR.VALUE routine should be called in DEF.EXTRACT.RTN and

DEF.VALUE.RTN fields for these 4 methods of calculating Fair Value.
Details The Fair Value is calculated only if the IAS.CLASSIFICATION is defined in the
MM.MONEY.MARKET record.
This routine will calculate the Fair Value with a method of calculation based on the
• “IAS.MM.FAIR.VALUE.1” The future cash flows are discounted using the rate
of the maturity date of the instrument
of the duration of the instrument
of the future cash flow date
• “IAS.MM.FAIR.VALUE” The future cash flows are discounted using the rate of
the maturity date and the interest day basis defined in MM application.
For these 4 methods of calculating Fair Value the rate is either fixed or variable
depending on the FIXED.VARIABLE field of the IAS.RATE.TYPE application keyed

Page 68 of 71
IA User Guide
on “FV.RATE.MM” and/or “FV.MARGIN.MM”. A fixed rate uses a percentage. A

variable rate uses the PERIODIC.INTEREST curve.
Formula The 4 methods of calculating Fair Value used the same formula. Only the EIR
changed depending on the maturity date (method 1), duration date (method 2),
payment date (method 3), or maturity date and interest day basis (method 4).
⎛ i=k ⎞
⎜ Ak ⎟
FairValue =sum ⎜ − FVDATE ⎞ ⎟⎟
i =1 ⎜ (1 + EIR )⎛⎜⎝ TODAY YD ⎟
⎝ ⎠ ⎠
Where k = number of payment

Ak = amount of the movement
EIR = Effective Interest Rate
FVDATE = event date
YD = number of days per year.

Page 69 of 71
IA User Guide
IAS.MM.FAIR.VALUE.REVAL
This routine is used to return both of the Fair Value and the revaluation amounts of Money Market.
This routine should be used like the IAS.MM.FAIR.VALUE routine. The Fair Value will be returned as
one output parameter. And the revaluation between the original Fair Value calculated and the last one,
will be also returned.
There are always the 4 different methods of calculating Fair Value done thru this routine at the end of
the day. The TRIGGER.UPD.AT.AUT flag should be set to NO in IAS.APPLICATION.PARAM
keyed on the MM.MONEY.MARKET application.

calculation used:
1. “IAS.MM.FAIR.VALUE.1” discounts cash flow using maturity date

2. “IAS.MM.FAIR.VALUE.2” discounts cash flow using duration rate
3. “IAS.MM.FAIR.VALUE.3” discounts cash flow using cash flow rates
4. “IAS.MM.FAIR.VALUE” discounts cash flow using maturity date and the
interest day basis defined in MM application.
IAS.MM.FAIR.VALUE.REVAL routine should be called in DEF.EXTRACT.RTN and

DEF.VALUE.RTN fields for these 4 methods of calculating Fair Value. This routine
should be also input in the IAS.AMOUNT.TYPE records of the Revaluation.
Details The Fair Value and revaluation are calculated only if the IAS.CLASSIFICATION is
defined in the MM.MONEY.MARKET record.
The details and the formula used are the same than ones of IAS.MM.FAIR.VALUE
routine.

Page 70 of 71
IA User Guide
IAS.MM.CREDIT.RISK
This routine is used to return the credit risk of money market at the end of the day. The
TRIGGER.UPD.AT.AUT flag should be set to NO in IAS.APPLICATION.PARAM keyed on the
MM.MONEY.MARKET application.
The credit risk is based on the Fair Value using an initial and a current spreads. Thus, the same
methods of calculating Fair Value as described above will be used.

Invoked The IAS.AMOUNT.TYPE keys should be based on a one of the methods of

calculating the Fair Value used:
1. “IAS.MM.CREDIT.RISK.1” discounts cash flow using maturity date

2. “IAS.MM.CREDIT.RISK.2” discounts cash flow using duration rate
3. “IAS.MM.CREDIT.RISK.3” discounts cash flow using cash flow rate
4. “IAS.MM.CREDIT.RISK” discounts cash flow using maturity date and the
interest day basis defined in LD application.
IAS.MM.CREDIT.RISK routine should be called in DEF.EXTRACT.RTN and

DEF.VALUE.RTN fields for these 4 methods of calculating.
Details The credit risk is calculated only if the IAS.CLASSIFICATION is defined in

the MM.MONEY.MARKET record.
This routine will calculate the credit risk with a method of calculation based on the
The Fair Value rate and the Fair Value margin are either fixed or variable depending
on the FIXED.VARIABLE field of the IAS.RATE.TYPE application keyed on
“FV.RATE.MM” and/or “FV.MARGIN.MM”.
The initial spread and the current spread have to be defined in IAS.RATE.TYPE as
“INITIAL.SPREAD” and “CURRENT.SPREAD”.
Formula See the Fair Value formula above.

Page 71 of 71

Temenos T24 IA: User Guide

Uploaded by

Copyright:

Available Formats

Temenos T24 IA: User Guide

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Temenos T24 IA: User Guide

Uploaded by

Copyright:

Available Formats

TEMENOS T24

Copyright 2005 TEMENOS Holdings NV. All rights reserved.

TEMENOS T24 User Guide

Calculation of Amount types using functions ................................................................................. 20

TEMENOS T24 User Guide

TEMENOS T24 User Guide

In broad terms IAS39 can be broken down into three elements:

TEMENOS T24 User Guide

Classification, Measurement Hedge Accounting

TEMENOS T24 User Guide

Financial Assets should all be classified as follows:

Held for Trading or Yes Held for short-term

Changes recorded in Yes Loans and

Available for No Intend and ability to Yes Held to

Held for Trading

Available for Sale

Loans and Receivables

TEMENOS T24 User Guide

Financial Liabilities should all be classified as follows

These are all non-trading liabilities and measured at amortised cost.

All assets and liabilities must be recognised on balance sheet

TEMENOS T24 User Guide

Quoted on an YES Use Market Price

Fair value revaluation

Hedging and Impairment

Hedge accounting may be applied under the following conditions:

TEMENOS T24 User Guide

• Hedge effectiveness assessed on an ongoing basis

Two tests of hedge effectiveness are required:

Hedges may be defined as:

Fair Value Micro Hedges

Cash Flow Micro Hedges

TEMENOS T24 User Guide

Why a separate IA module?

TEMENOS T24 User Guide

A flexible solution for variable interpretations

IAS Compliant Accounting & Reporting

TEMENOS T24 User Guide

SC Own Book Accounting Rules Requirements

Local GAAP vs. IAS

1. Assess the banks actual requirements.

TEMENOS T24 User Guide

TEMENOS T24 User Guide

Structure of IAS module in T24

The IA module consists of the following functionality elements:

TEMENOS T24 User Guide

Installation level parameters

IAS.PARAMETER Contains high-level parameters such as frequency for calculations,

Product level parameters

IAS.AMOUNT.TYPE This application contains all the calculations required by IAS39.

IAS.RATE.TYPE Indicates whether the rate type in question is a spread (initial or

TEMENOS T24 User Guide

IAS.PRODUCT.CONDITION is used to determine which

Example IAS.PARAMETER record

TEMENOS T24 User Guide

Example IAS.CLASSIFICATION record

• The reversal of figures from T24

TEMENOS T24 User Guide

Basic IAS.AMOUNT.TYPE through API routine