T24 Finance Reporting

TEMENOS T24
Reporting
User Guide
Information in this document is subject to change without notice.
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.

Reporting
Table of Contents
Overview .................................................................................................................................................. 4
Main Accounting Files/Entries ............................................................................................................. 4
STMT.ENTRY .................................................................................................................................. 4
CATEG.ENTRY ................................................................................................................................ 4
RE.CONSOL.SPEC.ENTRY ............................................................................................................ 4
CONSOLIDATION OF SPECIAL ENTRIES .................................................................................... 5
CRB Keys/Files .................................................................................................................................... 5
CONSOLIDATE.ASST.LIAB file ....................................................................................................... 5
CONSOLIDATE.PRFT.LOSS file ..................................................................................................... 7
CRB Examples ..................................................................................................................................... 9
Account based example ................................................................................................................... 9
Transaction based example ........................................................................................................... 10
Setup ..................................................................................................................................................... 11
Consolidation Parameters.................................................................................................................. 11
Asset and Liability .............................................................................................................................. 12
Fixed Parameters ........................................................................................................................... 12
General Parameters ....................................................................................................................... 13
Special Parameters ........................................................................................................................ 13
Profit and Loss ................................................................................................................................... 17
Fixed Parameter ............................................................................................................................. 17
Company specific redefinition of variable parameters ....................................................................... 17
IAS Dual Accounting .......................................................................................................................... 18
Architecture/Design ............................................................................................................................... 19
Creation and updating of CRB ........................................................................................................... 19
EB.CONTRACT.BALANCES ............................................................................................................. 19
ACCOUNT ...................................................................................................................................... 20
ASSET & LIABILITY ....................................................................................................................... 21
MONEY MARKET .......................................................................................................................... 21
LETTER OF CREDIT ..................................................................................................................... 21
LIMIT .............................................................................................................................................. 22
LD and PAST DUE ......................................................................................................................... 22
MORTGAGES ................................................................................................................................ 22
SECURITIES .................................................................................................................................. 23
MD DEALS ..................................................................................................................................... 23
ND.DEAL ........................................................................................................................................ 25
FRA.DEAL ...................................................................................................................................... 25
TEMENOS T24 User Guide Page 2 of 115

Reporting
FD.FID.ORDER and FD.FIDUCIARY ............................................................................................ 25

SL.LOAN ........................................................................................................................................ 25
Financial Files .................................................................................................................................... 31
CONSOLIDATE.ASST.LIAB .......................................................................................................... 32
CONSOLIDATE.PRFT.LOSS ........................................................................................................ 33
Revaluation .................................................................................................................................... 35
Re-create CRB ............................................................................................................................... 37
Generic Recreation Request .......................................................................................................... 37
Reporting from CRB ....................................................................................................................... 38
Reports .................................................................................................................................................. 39
Production of Reports..................................................................................................................... 39
Main CRB Files .............................................................................................................................. 44
Deal Level Balances....................................................................................................................... 47
Producing reports in non local currencies ...................................................................................... 50
Internal Files ................................................................................................................................... 51
Multi Company Reporting ............................................................................................................... 53
Company specific Reports ............................................................................................................. 54
Export & Import .............................................................................................................................. 54
Printing back-dated reports from CRB ........................................................................................... 58
USGAPP REPORTING .................................................................................................................. 61
Multi – GAAP Reporting Value Date Accounting ........................................................................... 61
The Ways of Treating Reversal Entries in CRF ............................................................................. 66
End of year procedure ....................................................................................................................... 67
Excluded Types .............................................................................................................................. 69
Grouping ......................................................................................................................................... 70
Accounting ...................................................................................................................................... 72
Grouping ......................................................................................................................................... 75
Virtual Day ...................................................................................................................................... 76
Transaction Journal Reporting ........................................................................................................... 80
TXN.JOURNAL.PRINT Report ....................................................................................................... 81
TRANS.JOURNAL2 Report ........................................................................................................... 81
Accounting Process ............................................................................................................................... 82
ACCRUAL REVERSALS ................................................................................................................... 82
Account application ........................................................................................................................ 84
Final account entries on Interest and Commission accruals ............................................................. 89
POSITION .......................................................................................................................................... 94
Position Accounting ........................................................................................................................ 94

Reporting
Statement of Accounts and History of Position Movements .......................................................... 95

Bypassing TXN.JOURNAL and EB.JOURNAL.SUMMARY ............................................................ 114
Overview
The reporting ('CRB') consolidation module maintains the 'CENTRAL REPORTING BASE' from which
financial reports (such as General Ledger, Balance Sheet, Statement of conditions, Foreign Currency
Control Ledger, Central Bank reports etc.) are produced.
This module consists of two main components, one which controls the updating of the CRB base with
the data passed across from the individual applications while the other component covers the
production of the reports.
Main Accounting Files/Entries

As bankers are used to the concept that for each credit or credits there is a balancing debit or debits
we shall proceed on that premise. In balancing the system T24 uses a few key accounting entry files
and some database type balancing files. These are:
STMT.ENTRY
The STMT.ENTRY file contains the debit/credit entries that are passed over any accounts that are
entered in the ACCOUNT application. If you check a record in ACCOUNT you will see several
balances; such as OPEN.ACTUAL.BAL and OPEN.CLEARED.BAL, this concept could be called a
database type balance in that the amounts are affected by entries.
CATEG.ENTRY
All P/L entries are posted to the CATEG.ENTRY file and are amalgamated into the
CONSOLIDATE.PRFT.LOSS file. There is no actual General Ledger account for these entries, the
„virtual‟ account this uses is explained below.
RE.CONSOL.SPEC.ENTRY
The RE.CONSOL.SPEC.ENTRY file is so named as it contains the special entries used to update
the balances on the consolidation files. The entries are those that are not passed through the
CATEG.ENTRY or STMT.ENTRY files.

Reporting
CONSOLIDATION OF SPECIAL ENTRIES
The ability to consolidate

special entries (Type R) is provided in the application
AC.CONSOLIDATE.COND. Special entries can only be consolidated where the consol key, asset
type and processing date match.
By default all non-contingent special entries raised from accounts and interest and charges will be
consolidated. The presence of an authorised REDEFAULT record in the AC.CONSOLIDATE.COND
application means the consolidation rules are switched on. To revert back to non-consolidated the
record must be reversed.
The ability to consolidate special entries applies only to the account application.
The detail of consolidated entries is available in the tables RE.SPEC.ENTRY.DETAIL and

RE.SPEC.ENTRY.DETAIL.XREF.
CRB Keys/Files
As mentioned earlier, T24 does not require General Ledger accounts, so how does it maintain a
General Ledger system? In order to understand this let us consider the problems in systems that use
General Ledger accounts. An account must be opened in each currency you deal in. For transactions
such as loans you may have many different types such as corporate loans, inter-bank loans, personal
loans, to name just a few. If you need these broken down by residence, nationality and industry, which
would mean for a basket of 12, active currencies there would need to be at least 108 accounts!
Obviously you may not open these all at once, but over a period you will accumulate many accounts
and their administration would require a lot of effort.
In T24 the transaction data is used to feed the General Ledger, this is accomplished by telling T24
how you wish to analyse the data. One of the first files set up on implementation is the
CONSOLIDATE.COND, which has just two records viz. ASSET&LIAB and PROFIT&LOSS. Here you
specify where T24 searches for the required data such as Industry code, Nationality, and Residence.
Once this file and the application parameters are in place, T24 is ready to create and maintain a
General Ledger. See the Reporting section of the User Guide for more details on setting up the CRF
system in T24.
CONSOLIDATE.ASST.LIAB file
This is easier to explain in an example, as the examples below should prove, but in essence consider
this as a record in a simple database. The key is decided by T24 when the underlying transaction is
entered. In its simplest form it could represent just one ACCOUNT where the conditions for the
account are unique (e.g. you only have one Albanian Lek current account for a Mexican national who
is a resident of Australia).

Reporting
The record has details of the debit balance or credit balance in the account currency together with the
local equivalent and the last movements and the total accruals for the matching accounts.
Now consider we want to report all debit balances for accounts, we can simply sum the records in
local currency or by account currency. In reality we would report them by account type; industry;
sector and so on.
The same concept is used when the transaction is a Money Market deal instead of an account.
Consolidate Asset Liabilities screen
Note:
Some asset types are contingent and reported off balance sheet, whereas others are non-contingent.
The CRF types, which we will be referring to, are detailed in the Reporting User Guide

Reporting
CONSOLIDATE.PRFT.LOSS file
Similar in concept and use to the CONSOLIDATE.ASST.LIAB, this file records the balance and
movements based on the P/L categories.
Again when building the General Ledger we can sum records or report them based on our required
decisions.
For example; the income which is earned on current accounts by industry
Consolidate Profit Loss screen

Reporting
Set up of GL in T24

Reporting
Set up of Reporting in T24
CRB Examples
Account based example
An ACCOUNT is opened and an entry is passed creating a debit balance, several days pass and
daily accruals are passed to reflect the overdraft interest being calculated.
The entries would be:

• Value 21 Apr 1997

Reporting
STMT.ENTRY Credit Nostro Account USD 100,000.00cr
STMT.ENTRY Debit Customer Account USD 100,000.00dr
• After the first few days
During the COB process T24 will create two records with CRF types of CREDIT (for the Nostro
account) and DEBIT (for the customer account) respectively. Accruals for the overdrawn customer
account are raised by T24 creating:
CATEG.ENTRY Credit to P/L category Interest earned USD 10.00cr
RE.CONSOL.SPEC.ENTRY Debit to Interest Earned not Collected USD 10.00dr
• At month end
At application of interest and charges the following entries are raised:
STMT.ENTRY Debit Customer Account USD 100.00dr
RE.CONSOL.SPEC.ENTRY Credit to Interest Earned not Collected USD 100.00cr
So during the accrual period the CONSOLIDATE.ASST.LIAB record will show the balance as a
DEBIT with the accrual increasing from USD 10.00 up to USD 100.00 at application time when it will
be cleared by the payment from the client, thus making the new debit balance USD 100,100.00. The
P/L balance will be reflected on the CONSOLIDATE.PRFT.LOSS increasing from day one until it is
left with the USD 100.00 as actual income received.
Transaction based example
We agree (on the 20 April) to take on deposit a USD 1million Money Market contract from 21 April to
25 April 1997.
On the transaction date 20 April 1997
RE.CONSOL.SPEC.ENTRY Credit to Contingent, type FORWARDCR for USD 1million cr
On the value date 21 April 1997
RE.CONSOL.SPEC.ENTRY Debit to Contingent, type FORWARDCR for USD 1million dr

Reporting
Now the contingent is cleared we raise the liability entry.
STMT.ENTRY Debit client account USD 1million dr
RE.CONSOL.SPEC.ENTRY Credit to liability, type LIVECR for USD 1million cr
During the life of the contract accruals will be created
CATEG.ENTRY Debit to P/L category Interest Paid (52000) USD 1000.00 cr
RE.CONSOL.SPEC.ENTRY Credit to Interest Payable USD 1000.00 dr
The same each day until maturity when the accruals will be cleared and the interest paid to
the customer.
Maturity Date
STMT.ENTRY Credit client account (prin.) USD 1million cr
STMT.ENTRY Credit client account (int.) USD 4000.00 cr
RE.CONSOL.SPEC.ENTRY Debit to liability, type LIVECR for USD 1million dr
RE.CONSOL.SPEC.ENTRY Debit to liability, type 52000 for USD 4000.00 dr
At the end of the process we have paid interest of USD 4000 which is reflected on the
CONSOLIDATE.PRFT.LOSS record.
Setup
Consolidation Parameters
The parameters define the 'CENTRAL REPORTING BASE' key under which the data is to be
accumulated. There are two sets of parameters, one that covers the Asset and Liability base, while
the second one covers the Profit and Loss base.

Reporting
Make up of General Ledger consolidation key
Asset and Liability

The parameters for the Asset and Liability base are made up of:
Fixed Parameters
Four fixed parameters:

• The Application ID (module) from which data came e.g. AC, FX, MM etc.
• The Currency Market.
• The Position Type as per the FX.POS.TYPE set.
• The Currency.

Reporting
General Parameters
There can be up to twelve variable parameters.
These parameters cover data held at customer level and data held at individual Deal/Contract/Account
level. Where the data is held at CUSTOMER level the same parameter is used for each application.
Where the data is to be taken from the deal level, the parameter can be told where to find the data in
each application.
A parameter can be any field on either the CUSTOMER file or the application level master files,
providing the field is not more than 10 characters long and not multi-valued (Local Reference fields are
assumed to be single value). However, care should be taken while defining the parameters, as the
total length of a CONSOLIDATE.ASST.LIAB record ID (including Company specific components, if
any) could not exceed 65.
Special Parameters
In addition to using a single field, there are three special conditions. Both conditions can only use data
from an application level master file.
INITIAL AMOUNT
For this condition, a currency field and an amount field are indicated, plus details of amount ranges in
a given currency are loaded together with a value to be stored in the key. All deals equal to and below
£100,000 or the appropriate equivalent, are stored with same value of '1'. With all deals between
£100,000.01 and £1,000,000, or the appropriate equivalent, are stored with same value of '2'. While
all amounts over £1,000,000 or the appropriate equivalent are stored with same value of '3'.
INITIAL TIME
This condition needs two date fields to be indicated. The difference in time between the two dates is
calculated, or if the last date is a notice period then this is used. This time difference is matched
against the time range details loaded to determine the value to be stored in the key.
CALL, NOTICE, TERM SETTINGS
If the maturity date field for MM.MONEY.MARKET or LD.LOANS.AND.DEPOSITS is chosen as

a user variable, then instead of storing the value in the field in the key, values such as C (Call), N
(Notice) or T (Term) can be stored.
The rules being for the setting of this field would be:
• 'C' If MATURITY DATE is 000
• 'N' If MATURITY DATE is 001 - 999
• 'T' If MATURITY DATE is a date

Reporting
4 System Generated CONSOLIDATE.COND

Application Market PositionType Currency Category Sector Residence Init.Term Secured
BALANCE CLASS ASSET.TYPE APPLICATIONS
ACPT LC BL
P
ACPTBANK LC
R ACPTCONTRA LC
ACPTHO LC
I
ACPTSUBS LC
N ADVICE LC
COLL LC BL
C CONTINGENT CONFIRM LC
I CONTCR AC FD MD BL
CONTDB AC FD MD BL
P CONTPL PL
A CONTUW SL
DEFPAY LC
L DXFUTBY DX
DXFUTBUYCR DX
DXFUTBUYDB DX
DXFUTBUYDR DX
DXFUTSELL DX
DXFUTSELLCR DX
DXFUTSELLDB DX
DXFUTSELLDR DX
DXOPTBUY DX
DXOPTBUYCR DX
DXOPTBUYDB DX
DXOPTBUYDR DX
DXUOVCR DX
DXUOVDB DX
DXUOVDR DX
FORWARDCMT LD SL
FORWARDCR FR LD MG MM SC SL SW
FORWARDDB FR LD MG MM SC SL SW
FORWARDPOS AL
FWDCONTCR FD MD BL
FWDCONTDB FD MD BL
FWDMEMOCMT SL LD
FWDMEMOCR MD SL
FWDMEMODB MD
FWDNOTLCR SW
FWDNOTLDB SW
FXFWDBUY FX SW ND
FXFWDSELL FX SW ND
FXWINTBUY FX
FXWINTSEL FX
FXOPTBUY FX
FXOPTSELL FX
FXSPOTBUY FX
FXSPOTSELL FX
ISSUE LC

Reporting
LINE LI
LINEMVMT RE
LIVECMT LD SL
LIVEPOS AL
MEMOCHGDB SL
MEMOCMT SL LD
MEMOCR MD SL
MEMODB MD
MEMOINTCR SL
MEMOINTDB SL
MMFIDCR MM
MMFIDDB MM
NNNNNFW SC
NNNNNOFF AC
NNNNNOFFSP AC
NOTIONALCR SW
NOTIONALDB SW
OFFCR AC
OFFDB AC
OFFSUSP AC
OPEN LC
PREADV LC
SWFWNOTLCR SW
SWFWNOTLDB SW
SWOFFBALCR SW
SWOFFBALDB SW
TRCOLL LC
UTIL LI
List of contingent ASSET.TYPE by application

Reporting
CLASS ASSET.TYPE APPLICATIONS
NABCE PD
P
NABCS PD
R OVERDUECE PD
OVERDUCS PD
I
CONTRAAC PD
N CREDIT AC
DEBIT AC
C NON - LIVECR LD MM SC SL SW BL
CONTINGENT LIVEDB LD MG MM SC SL SW BL
I
NABA1 PD
P NAB2 PD
A NABA3 PD
NABA4 PD
L NABA5 PD
NABCH PD
NABCO PD
NABCR LD SL
NABDB LD SL PD
NABIN PD
NABPR PD
NABTX PD
NNNNN SC AC LD MM FD SL LC
BL SW FX DX IA
OVERDUEA1 PD
OVERDUEA2 PD
OVERDUEA3 PD
OVERDUEA4 PD
OVERDUEA5 PD
OVERDUECH PD AZ
OVERDUECO PD
OVERDUECR LD SL
OVERDUEDB LD SL PD
IVERDUEIN PD AZ
OVERDUEPR PD AZ
OVERDUETX PD
PAYRES LC
SUSPS AC
ACCRUED
50000/50100 AC
INCOME
51000/51100
(Interest, Or category code AC MM SC
Commission, from Param Table LD FR MG
Charges) or above +SP AC
List of non-contingent ASSET.TYPE by application

Reporting
Profit and Loss

The parameters for the Profit and Loss base are made up of:
Fixed Parameter
One fixed parameter
• Indicating that the data is maintained for Profit and Loss.
General Parameters
There can be up to twelve variable parameters
Using any field on the CUSTOMER file and any field on the CATEG.ENTRY file, providing the field
is not more than 10 characters long and not multi-valued field (LOCAL.REFERENCE field is an
exception). However, care should be taken while defining the parameters, as the total length of a
CONSOLIDATE.PRFT.LOSS record ID (including Company specific components, if any) could not
exceed 65.
Note that if there is no CUSTOMER on the CATEG.ENTRY, file then all parameters at Customer
level will be set to Null.
4 System Generated
• PL
CONSOLIDATE.COND
• PL Category
• PL Sector
• Product
• PL Init Term
• Officer
Followed by
• Profit Currency
The P/L key can also be linked to a particular part of the Asset and Liability Key parameter (e.g. Initial
Time)
Company specific redefinition of variable parameters

The application CONSOLIDATE.COND is used to define the variable parameters. The
Asset&Liability base parameters are defined in the record with key “ASSET&LIAB” and the Profit&loss
base parameters are defined in the record with key “PROFIT&LOSS”. These are the default records. It
is possible that some of the variable parameters would need to be redefined at Company level. The

Reporting
company level definitions are stored in the records with keys “ASSET&LIAB.XXXXXXXXX” and
“PROFIT&LOSS.XXXXXXXXX”, where xxxxxxxxx is the COMPANY record key.
For example, there could be a requirement for a Company to have a classification for the consolidation
variable parameter SECTOR, which would be different from the default ones. It is possible to have a
local reference field for this purpose in CUSTOMER and use that field in the redefined Company
specific CONSOLIDATE.COND records. In this case, the consolidation key variables would be
formed with two components, which could be separately used in Reports.
If two or more Companies share the same Company specific consolidation definitions, then it is not
necessary to define separate Company specific CONSOLIDATE.COND records for each Company.
It is enough if the Company specific CONSOLIDATE.COND records are defined for one Company
only and other Companies are allowed to share that definition. For this, the ID of the Company whose
Company specific CONSOLIDATE.COND records need to be shared could be attached to the field
CONS.KEY.CO of another COMPANY record.
For example, the Companies CO2 (ID: US0010002) and CO3 (ID: US0010003) could share the same
Company specific consolidation definition. Records with IDs “ASSET&LIAB.US0010002” and
“PROFIT&LOSS.US0010002” defined in CONSOLIDATE.COND. In the COMPANY record of
US0010003, the field CONS.KEY.CO is updated with the value of US0010002. In this case, the
Company CO3 would use the CONSOLIDATE.COND records with IDs “ASSET&LIAB.US0010002”
and “PROFIT&LOSS.US0010002” to determine the Company specific components of consolidation key
variables. If the field CONS.KEY.CO is left blank, then the Company would use its own Company
specific consolidation records.
While inputting values in a Company specific CONSOLIDATE.COND record, various validations

depending on the corresponding parameter in the default record are done. However, if a parameter
definition in a default CONSOLIDATE.COND record were modified, such modification would not
automatically be reflected in a Company specific record, if any. It should be ensured that the
corresponding Company specific record is also suitably modified. For example, in the default
CONSOLIDATE.COND record with ID "ASSET&LIAB", the field SECTOR is defined as the seventh
multi-value and the field SECTOR is redefined in the record with ID "ASSET&LIAB.US0010001" in the
seventh multi-value. If a modification is done to the default record such that the field SECTOR is now
the eighth multi-value, then the record with ID "ASSET&LIAB.US0010001" should be also suitably
modified such that the redefined field SECTOR is now the eighth multi-value in that record.
The formation of consolidation keys when Company specific consolidation parameters are defined is
explained under the paragraph CONSOLIDATE.ASST.LIAB.
IAS Dual Accounting

IAS Balance Sheet
The two CRF files CONSOLIDATE.ASST.LIAB and CONSOLIDATE.PRFT.LOSS have TR or IA
as their POSITION.TYPE in their consolidation key

Reporting
This is used to either suppress or include a reporting line, thus providing the facility to produce an IAS
balance sheet to include the new IA entries and ignore the ones that the system generates.
Set up
1. FX.POS.TYPE IA record to denote IAS position
2. For entries that are to be reported under IA, the POSITION.TYPE on the account input
should be set as IA
3. Input the REVALUATION.PARAMETER for the company a new APPLIC.ID AL.IA with its
relevant details of profit and loss categories and transaction codes.
4. In order for report to reflect the revaluation profit and loss position, the ASSET.APPLIC.ID
and PROFIT.APPLIC.ID fields for the relevant report lines on the RE.STAT.REP.LINE
should be set to IA and their corresponding PL conditions for selection set.
Architecture/Design
Creation and updating of CRB
The update of the CRB financial data is done partly on-line when it creates the
RE.CONSOL.ENT.TODAY records and also as part of the offline (Close of Business) processing
where it uses the records created in this file to generate the RE.CONSOL.SPEC.ENTRY and also
update the CONSOLIDATE.ASST.LIAB and CONSOLIDATE.PRFT.LOSS files. Whenever data
is passed to the CRB, from whichever application, the Asset and Liability CRB is updated. The special
movement entry is written away and when necessary the application link files and reports content files
are updated. The application link files provide a link from a CRB record to the base record from which
the details came.
In Foreign Exchange this is done as part of the Foreign Exchange Close of Business processing
through the central balance file, EB.CONTRACT.BALANCES, where in each Forex deal will create
two record IDs‟, one suffixed with „B‟ to signify the buy leg and the other suffixed with „S‟ to signify the
sell leg of the transaction. Information is passed to the CRB whenever a deal has been loaded and/or
reaches its maturity (value date) on the run date. Details are also passed if the deal moves from being
a Forward contract into the Spot contract period. Information relating to revaluation/accrual of 'interest'
adjustment (for revaluation method 'Interest' and 'Straight Line') is obtained from the accounting
entries raised as part of the FOREX revaluation processing. These accounting entries are a mix of
Profit and Loss (CATEG.ENTRY) and account (STMT.ENTRY). CRB programs will fetch balances
for each asset type from EB.CONTRACT.BALANCES, through a central link file called
RE.CONSOL.CONTRACT. This file will hold contract IDs‟ per Consol key.
EB.CONTRACT.BALANCES
The EB.CONTRACT.BALANCES file provides a single place for CRB reporting to take its
information. It is possible to extract the balance at the close of the last working day as well as the

Reporting
current balance. Balances are updated real-time at the authorisation stage of a transaction. For certain
balance types unauthorised movements are held too. The data in the record is cycled as the record is
updated rather than on a daily basis to avoid potentially time consuming COB processing. The
balances are updated from the core accounting processing based on the Consol entries raised by the
underlying application – there is no direct update from the underlying application. This ensures that the
balance is always a true reflection of the accounting entries raised by the application.
The following applications currently update EB.CONTRACT.BALANCES;
• ACCOUNT
• ASSET & LIABILITY (AL)
• MM.MONEY.MARKET
• LD.LOANS.AND.DEPOSIT
• PD.PAST.DUE
• SC.TRADING.POSITION
• MG.MORTGAGE
• MD.DEAL
• SL.LOAN
• FOREX
• LETTER.OF.CREDIT
• ND.DEAL
• LIMIT
• BL.BILL
• FRA.DEAL
• FD.FID.ORDER AND FD.FIDUCIARY
For all the applications that currently link to EB.CONTRACT.BALANCES, CRB programs will use
the link file RE.CONSOL.CONTRACT to retrieve the balances.
For changes to static data the Asset and Liability CRB is updated after the application level updates
but prior to the Account updates. There are no updates to the Profit and Loss CRB because of static
data changes.
ACCOUNT
The CRB is updated during system wide close of business processing, using the file
EB.CONTRACT.BALANCES. This file gets updated as follows;

Reporting
• Movement entries affecting account balance during the day are updated online, as Debit
/Credit movements.
• Special entries generated for interest accruals and capitalization
• Sign and static change entries, if required generated during close of business.
• Contingent entries generated during close of business, for forward value dated entries if the
system is in value dated accounting.
ASSET & LIABILITY
For A&L a unique EB.CONTRACT.BALANCES record will be updated. This will hold contract
currency, balances by asset types, daily movements for each asset types and Consol key. This file will
be updated by core accounting
MONEY MARKET
For the application MM.MONEY.MARKET, RE.CONSOL.SPEC.ENTRY will be generated online

when a contract is entered. This will update a central balance file called
EB.CONTRACT.BALANCES. Interest accruing during Close of business will also update this file
under appropriate asset type. CRB programs will fetch balances for each asset type through the
central link file RE.CONSOL.CONTRACT. This file holds contract Ids per consol key.
EB.CONTRACT.BALANCES for each Money Market deal will also hold the following updates;
• Movements in principal caused by increase/decrease and maturity.

• Interest accrual and schedule interest received/ paid movements on due date and in advance.
• Profit and Loss entries relating to interest accrual.
• Static change movements affecting consol key and changed consol key.
LMM.ACCOUNT.BALANCES will continue to be used for accruing of interest.
LETTER OF CREDIT
For LETTER.OF.CREDIT, EB.CONTRACT.BALANCES for each contract will be updated online

and during close of business. This file holds information such as contract currency, asset types,
movement for each asset types and CONSOL.KEY. The link file to this balance file will be another
central file RE.CONSOL.CONTRACT. The ID of this file is the consol key and each of the record will
hold the contracts falling under the key.

Reporting
LIMIT
For LIMIT, when the field LIMIT.TO.TAKE is enabled in CONSOLIDATE.COND,

EB.CONTRACT.BALANCES for each product limit will be updated. This file holds information such
as limit currency, asset types, movement for each asset types and CONSOL.KEY. The link file to this
balance file will be another central file RE.CONSOL.CONTRACT. The ID of this file is the consol
key and each of the record will hold the limits falling under the key.
LD and PAST DUE
The LD and PD applications will update the EB.CONTRACT.BALANCES during online and COB.
Both will have the common link file RE.CONSOL.CONTRACT.
On authorising a LD contract system generates the RE.CONSOL.SPEC.ENTRY online, generates

the CONSOL.KEY online and updates EB.CONTRACT.BALANCES. Instead of writing the
CONSOL.KEY of LD in LMM.ACCOUNT.BALANCES it will be held only in
EB.CONTRACT.BALANCES. Application refers this file to read the new and old key. Similarly
during close of business whenever an accounting entry is triggered system generates spec entry
instead of raising CONSOL.ENT.TODAY. Hence the overhead involved in converting them to spec
entry will be avoided.
The following screenshots shows an EB.CONTRACT.BALANCES record for an LD contract.
EB.CONTRACT.BALANCES record for an LD contract
MORTGAGES
The application MG.MORTGAGE will update the EB.CONTRACT.BALANCE file. For each MG
contract, a unique EB.CONTRACT.BALANCES record will be updated. This will hold contract
currency, balances by asset types, daily movements for each asset types and Consol key. This file will
be updated by core accounting process at authorisation level.
The workflow will be;

Reporting
• For each MG contract, EB.CONTRACT.BALANCES will be generated online upon

authorization. However accrual of interest, scheduled payment will be updated during close of
business.
• For this purpose, entries will be generated online instead of through CONSOL.ENT.TODAY
during close of business.
• Consol key will be allocated online and updated in EB.CONTRACT.BALANCES file.
• Link file, RE.CONSOL.CONTRACT will also be updated during close of business.
• Static and schedule changes will be processed through generic static change process during
close of business and EB.CONTRACT.BALANCES will be updated with changed
CONSOL.KEY.
SECURITIES
For each SC.TRADING.POSITION (dealer book positions), a unique

EB.CONTRACT.BALANCES record will be updated. This will hold contract currency, balances by
asset types, daily movements for each asset types and Consol key.
MD DEALS
For MD.DEAL, when a record is input, RE.CONSOL.SPEC.ENTRY will be generated online and
will update the central balance file EB.CONTRACT.BALANCES. Commission amortised/accrued
during COB will also update this file under appropriate asset type. CRB programs will fetch balances
for each asset type through the central link file called RE.CONSOL.CONTRACT.
EB.CONTRACT.BALANCES for each MD.DEAL will also get updated for the following events:
 Principal movements.
 Commission amortised/accrued.
 Static changes affecting the consol key.
However, MD.BALANCES will continue to be used for amortising/accruing.

Reporting
.
EB.CONTRACT.BALANCES record for MD.DEAL
BL.BILL (BL)
The application BL.BILL will update the EB.CONTRACT.BALANCES file. For each BL.BILL
contract a unique EB.CONTRACT.BALANCES record with the id of attached BL.REGISTER(S)
will be updated. This will hold contract currency, balances by asset types, daily movements for each
asset types and Consol key. This file will be updated by core accounting process at authorization level.

Reporting
• For each BL.BILL contract, EB.CONTRACT.BALANCES will be generated online upon

authorisation.
• For this purpose, entries will be generated online instead of through CONSOL.ENT.TODAY
• Consol key will be allocated online and updated in EB.CONTRACT.BALANCES file.
• Link file, RE.CONSOL.CONTRACT will be updated during close of business.
ND.DEAL
Similar to Forex contract, in the case of a ND contract, two separate records would be updated in
EB.CONTRACT.BALANCES during Close of Business processing with record IDs‟ made up of
contract number and leg identifier (i.e. „B‟uy or „S‟ell). These records will hold the currency of the
respective leg, balances by asset types, daily movements for each asset type and Consol key.
CRB programs will fetch balances for each asset type from EB.CONTRACT.BALANCES through
the central link file RE.CONSOL.CONTRACT.
FRA.DEAL
The application FRA.DEAL will update a record in EB.CONTRACT.BALANCES file for each
contract during close of business processing. This record will hold information such as contract
currency, asset types, movements for each asset type, CONSOL.KEY and other CRF information
related to the contract.
FD.FID.ORDER and FD.FIDUCIARY
For the fiduciary orders input in FD.FID.ORDER and placements input in FD.FIDUCIARY,
corresponding records will get created in EB.CONTRACT.BALANCES with record-ids, same as
found in these applications. These records will hold information such as fiduciary currency, asset types,
movements for each asset type, CONSOL.KEY and other related CRF information.
SL.LOAN
For each SL contract, a unique EB.CONTRACT.BALANCES record will be updated. This will hold
contract currency, balances by asset types, daily movements for each asset types and Consol key.

Reporting
This file will be updated by core accounting process at authorisation level, and the central link file
RE.CONSOL.CONTRACT will be used.
CRB reporting will fetch the balances from EB.CONTRACT.BALANCES rather than from
SL.LOAN.BALANCES.
1. For each SL contract, EB.CONTRACT.BALANCES will be generated online upon authorization.
However accrual of interest, scheduled payment will be updated during close of business.
2. For this purpose, entries will be generated online instead of through CONSOL.ENT.TODAY
3. Consol key will be allocated online and updated in EB.CONTRACT.BALANCES file.
4. Link file, RE.CONSOL.CONTRACT will also be updated during close of business.
5. Static and schedule changes will be processed through generic static change process during
close of business and EB.CONTRACT.BALANCES will be updated with changed
CONSOL.KEY.
The EB.CONTRACT.BALANCES record is also used to retain all entry id‟s for a contract, in one
place. In the ACCOUNT.PARAMETER the field UPDATE.ENTRIES is used to control how many
entries ids (e.g. STMT.ENTRY, CATEG.ENTRY RE.CONSOL.SPEC.ENTRY id‟s) will be updated on
the EB.CONTRACT.BALANCE record. There are 3 options;
ALL – This will update all entries in EB.CONTRACT.BALANCE. Once the entry id count has
reached 100 the system will split the records and a number of the older ids will be written to the file
EB.CONTRACT.ENTRIES.
1. NO or NULL – No entries will be updated in the EB.CONTRACT.BALANCE

2. RECENT - This will update only the most recent 100 entries in EB.CONTRACT.BALANCE.
No other entries will be maintained.

Reporting
Field options for UPDATE.ENTRY
In the following example the account 10103 has had 100 STMT.ENTRY IDS written against its
EB.CONTRACT.BALANCES record
EB.CONTRACT.BALANCE record 100 ids
STMT.ENTRY.ID is written, the system will move a portion of the old ids to the
Once the next
EB.CONTRACT.ENTRY record for this account.

Reporting
EBC record after old ids moved
EB.CONTRACT.ENTRIES for ac 10103
The @id to this file is the contract number*type of entry*sequential number. In the example above it is
ACCOUNT*STMT.ENTRY ID*1
10103*S*1
An individual EB.CONTRACT.ENTRIES record can hold up to 200 entry ids. Once it reaches this
figure the system will create a new record incrementing the sequential number. The field

Reporting
STMT.SPLIT.IDin the EB.CONTRACT.BALANCES record will contain the current

EB.CONTRACT.ENTRIES record id.
ECB with STMT.SPLIT.ID incremented
EB.CONTRACT.ENTRIES for AC 10103
It is also possible to filter what type of entry id‟s are updated on the EB.CONTRACT.BALANCE file,
this can be filtered either by product or transaction code and is controlled by the fields FILTER.SYSID
and FILTER.TXNID found in the AC.CONSOLIDATE.COND application.

Reporting
AC.CONSOLIDATE.COND record
In the example above we would not be updating any entry ids in EB.CONTRACT.BALANCES
records for any entry which originated from Interest and Charges or which had a transaction code of
51

Reporting
Reporting workflow
Financial Files
The two financial files are the CONSOLIDATE.ASST.LIAB and the CONSOLIDATE.PRFT.LOSS
files. The former holds details relevant to all Assets and Liabilities while the latter holds details
relevant to Profit and Loss.

Reporting
Financial files
CRB Updates for Financial Transactions are listed below:
• New Deal
• Interest Accrual
• Maturity
• Account Entries
• Financial Deal Maintenance
• (E.g. amount increases)
CONSOLIDATE.ASST.LIAB
This file maintains details within a record by 'Type' where 'Type' is used to differentiate between the
different stages of a deal, the sign of the deal and also the accrued interest and/or commission etc.
Examples of value of 'Type' are CREDIT, DEBIT, LIVEDB, FORWARDCR, FXSPOTBUY, and
FXFWDSELL, 50000, 51000 and 52020. Within each Type, the Details of Balance, debit and credit
movements both in original currency and local currency equivalent are maintained. Also maintained
for principal amounts of contract deals, are the details of the value date, maturity date and amount so

Reporting
that maturity spread reports may be produced. Foreign Exchange deals will be stored under the
MATURITY.DATE field.
If a variable parameter is redefined for a Company, then the variable parameters of the keys of the
ASSET&LIAB and PROFIT&LOSS base would be formed with two components separated by „_‟
where the first component value would depend on the default consolidation definition and the second
component value would depend on the Company specific consolidation definition. Variable parameters,
which are not redefined at Company level, would have only one component with out any „_‟ suffixed.
An example for an ASSET&LIAB consolidation file key is given below to explain how the default and
Company specific consolidation definition are used to form the default and Company specific
components for the variable parameters:
Key: AC.1.TR.GBP.1001..1_10.5400_001.8530_8530._8.GB.003_._._100
Variable Value Explanation

1 1001 The first variable parameter is not redefined at Company level, its value is
1001 for the default definition; it is represented by '1001'
2 Null The second variable parameter is not defined for the application AC in
default as well as in Company specific CONSOLIDATE.COND records; it is
represented by a null value ''.
3 1_10 The third variable parameter is redefined at Company level, its value is 1
for the default definition and 10 for Company specific definition; it is
represented by '1_10'
4 5400_001 Similar to variable 3
5 8530_8530 Similar to variable 3
6 _8 The sixth variable parameter is redefined at Company level, it has a null
value for default definition and 8 for Company specific definition; it is
represented by '_8'.
7 GB Similar to variable 1
8 003_ The eighth variable parameter is redefined at Company level, its value is
003 for default definition and it has a null value for Company specific
definition; it is represented by '003_'.
9 The ninth variable parameter is redefined at Company level, it has a null
value for default definition and a null value for Company specific definition;
_
it is represented by '_'.
10 _10 Similar to variable 6
CONSOLIDATE.PRFT.LOSS
This file maintains details within a record by currency code. For each currency code, the balance and
the credit and debit values are maintained in local currency and in original currency. The current
month‟s balances and the year to date balances are both maintained.

Reporting
Similar to CONSOLIDATE.ASST.LIAB, the variable parameters of the keys of this consolidation file
could have two components; the first one determined by the default consolidation definition and
second one determined by the Company specific consolidation definition.
System Flow
On the first working day of new financial period, the Close out of the previous period Profit and Loss
takes place. This is run in an application of the batch process.
Updating of the CRB base with data from the individual applications like FOREX are part of the
application‟s off-line processing.
The following will be performed as part of the system wide off-line processing:
• Changes in the CUSTOMER and Application main file static data for Accounts and Forex.
• The system wide ACCOUNT and Interest and Charges Application.
• The revaluation of the Asset and Liability Currency Position and the revaluation of the
CONSOLIDATE.ASST.LIAB file.
• Processing of the CATEG.ENTRY file.
• The following will be performed as part of the reporting off-line processing:
• Production of the Consolidation reports.
• If specified, the recreation of the Consolidation base and the second production of the reports
using the new base.
Update Timing
Off-line (End of Day) Updates On-line Updates

• Contract/Deal Files • Contract/Deal Files
• Account File • Account File
• STMT.ENTRY • STMT.ENTRY
• CATEG.ENTRY • CATEG.ENTRY
• RE.CONSOL.SPEC.ENTRY • CONSOL.ENT.TODAY
• Key generation for new transactions
o A/L
o P/L
• Key Maintenance
Timing of updates
Movement Details
In order to support the total movement amounts held on the CRB records, the system makes use of
existing data where possible or creates a special movement entry.

Reporting
• For Profit and Loss movements, the CATEG.ENTRY file records are used.
• For Asset and Liabilities, the STMT.ENTRY file records are used for ACCOUNT balance
movements.
• For all other movements, a Reporting Consolidation Special Movement Entry is raised and
stored on the file RE.CONSOL.SPEC.ENTRY.
An entry is raised for the drawing down of a loan or loans; this type of entry will specify the deal/
contract number.
• Special entries are also raised for interest accruals and capitalisation; these entries are
accumulated together as much as possible.
• Special movement entries are raised when an account balance changes (from a credit
balance to a debit balance or vice versa) between the day‟s opening and closing balance.
• Special movement entries are raised when there are changes to the CUSTOMER and
ACCOUNT and Contract deal level static data that is used to form the key of the
consolidation records.
Revaluation
At the end of the run prior to report production, all non-contingent foreign currency records are re-
valued. That is, all details except those which refer to Forward loans and deposits and those referring
to any Foreign Exchange deal.
The revaluation involves revaluing each currency record by type. The total new local equivalent from
all currency records with the same market and position type is checked against the
LOCAL.EQUIVALENT from the Asset and Liability records on the Position file. If there is a difference,
then the last record for the currency on the Asset and Liability Consolidate file is adjusted by that
amount.
Special movement entries are raised for the amount of each revaluation based upon the settings in
REVALUATION.PARAMETER.
The value in field APPLIC.ID is validated against records held in the table FX.POS.TYPE. If
multiple FX.POS.TYPE records have been created for example for Multi - GAAP reporting then a
suitable configuration in field APPLIC.ID for AL needs to be established.

Reporting
Revaluation Parameter Input screen
The contingent CRB records can be re-valued using either the REVAL.RATE (if specified in the
CURRENCY record) or, where no REVAL.RATE has been specified, by the mid market rate. In
order to do this, both the application and the type have to be specified for revaluation in the
CONSOLIDATE.COND record for Assets and Liabilities. If a record is re-valued through either a
movement in the mid-market rate or by the REVAL.RATE, then a special movement entry is raised.
No Profit and Loss entry is raised for contingent revaluation.
Accounting entries for revaluation
The revaluation is calculated on spot or rebate basis as specified for the application in the parameter
record.

Reporting
Asset/Liability revaluation is specified in the revaluation parameters as a special application.
PRODUCT
ENTRY SOURCE STAT ENTRY CATEG.ENTRY TXN CODE
CATEGORY
LOSS.DR.TXN.CD
Revaluation Loss N/A NA LOSS.CATEG LOSS.PROD.CATEG
LOSS.CR.TXN.CD
DR P&L Exchange ACCOUNT.CLASS LCYCATEGNNNN N/A N/A
CR Exchange Adjustment = ExchAdj
PRFT.DR.TXN.CD
Revaluation Profit ACCOUNT.CLASS LCYCATEGNNNN N/A N/A
= ExchAdj
PRFT.CR.TXN.CD
CR P&L Exchange N/A N/A PRFT.CATEG PRFT.PROD.CATEG
Accounting Entries for revaluation
Re-create CRB
For any application (module), it is possible to recreate the CRB either for that application alone, for all
Asset and Liability applications, for the Profit and Loss CRB or for Asset and Liability as well as Profit
and Loss.
Application RE.REGEN.CRF is available for requesting recreation of CRB. Currently ACCOUNT,

LIMIT and PROFIT &LOSS applications are supported by this application. CRB recreation through
this application can be performed either online or as a COB process.
A generic request record called RE.REGEN.REQUEST can be used for regeneration of CRB base
on a given date. The ID of RE.REGEN.REQUEST is the date on which recreation is to be done.
The request can be used for a single contract in an application or for the entire application.
The request can be made for specific company/book or for all.
An option is provided in the template to suppress movement entries from being generated. This
however will be applicable when recreation is requested for an entire product but not for individual
contract/account.
Batch records RE.REGEN.CRF and REGEN.UPDATE.LINK will process recreation during close
of business. Batch record RE.RECREATE.CRF will be used when online rebuild is requested via
TSA.SERVICE.
Generic Recreation Request
Request of recreation for CRB REGEN is controlled from RE.REGEN.REQUEST. The REGEN
process runs as part of the system end of day or in background as a service.

Reporting
Regeneration of the CRB details can be requested by:

• Application (can be all)
• By Company (can be all for a multi-book implementation)
• For an individual contract
Reporting from CRB
Reporting Tools
To produce reports, it is necessary to load details about the columns to be printed, the report headings
required, the totals to be printed and the details to be printed on a particular line. This information is
loaded onto the report static data files, from which a report contents file is updated. This latter file is
also updated with the key and type/currency of the CRB records, which are to be printed on each line.
Workflow for production of reports

Reporting
Reports
Production of Reports
The reports are produced as part of the off line, i.e. Close of Business processing. The details of the
reports to be produced are entered as part of the variable data in the Batch reporting job for 'CRB'.
The main reports can be produced as according to the specifications in the
RE.STAT.REPORT.HEAD and RE.STAT.REP.LINE applications. A report may be specified to be
a closing report or a movement report, in which case the movement details are printed.
On a detail level print, reporting line prints the amounts from each consolidation record. The day‟s
entries can be included in a report by specifying in the Report Header record a key to the entry format
file. The format and details to be printed are specified in the entry format file.
A contract level report can also be produced which will print the contracts/accounts by report line and
within line by currency and contract. This is a separate report and shows the contracts in both local
and original currency in a fixed format.
It is possible to allow for the accumulation of historically reported data. This option is available at the
report header definition level. If this option has been chosen, the system will maintain enough
information to be able to print backdated reports.
The main reports can be printed during the off-line processing within the batch process
EB.STAT.PRINT and on-line by the application RE.STAT.REQUEST. The contract reports can
only be printed in the batch process.
The data, headings and totals to be printed are defined by the static data files set up as part of the
on-line day. The report content file, which is updated as part of the on-line and off-line consolidation
processing, is also used in the actual printing of the reports.
The content file is called the RE.STAT.LINE.CONT. This file contains the details concerning the
type of line to be printed, the totals to be accumulated/printed, the spacing from the
RE.STAT.REP.LINE file, plus the actual CRB records to be printed. Thus this file is used to control
the printing of each report.
There is the possibility to print all the movements by report line for any report. These movements can
be printed as part of the standard flow by specifying the format on RE.STAT.ENT.FORMAT and
linking this format to a report in RE.STAT.REPORT.HEAD.
A trial balance report for all customer and internal accounts can be produced during off- line
processing by running the batch process EB.ACCT.TRIAL.BAL. The format of this report is fixed,
but the entries may be displayed in amount order either ascending or descending.
The static files used in the printing of reports are:

Reporting
• RE.STAT.COLUMN.TYPE
• RE.STAT.REPORT.HEAD
• RE.STAT.REP.LINE
• RE.STAT.ENT.FORMAT
• RE.STAT.RANGE
• RE.STAT.NAME
• RE.AMT.ABBREV
• RE.STAT.OUTPUT
RE.STAT.COLUMN.TYPE
RE.STAT.COLUMN.TYPE contains details for each column that can be printed. These details
indicate whether a movement amount or balance amount is to be printed. Whether the balance
amount should be for all currencies, local currency or foreign currencies only can be specified. Profit
and Loss details can be treated as local currency or as the currency in which they were earned/paid.
Also entered is the narrative to be printed at the top of the column.
Definition of columns

Reporting
RE.STAT.REPORT.HEAD
RE.STAT.REPORT.HEAD contains the heading details indicating the columns to be printed, the
amount size, whether reports are by currency or all currencies, the report heading and whether entries
are to be printed. The following definitions are required to be done:
• Definition of Description Columns.
• Definition of TOTAL /CALC Columns.
• Definition of SPLIT / BREAK Conditions.
• Definition of PROFIT Currency.
• Definition of - Amount Size / Suppression rules.
• LINKS to Financial Columns.
• Whether Company specific Report.
• If a Company specific Report, the Company for which the Report needs to be populated.
• The width of the Report if it is more than 132 characters (maximum 256), which should be
consistent with the Form width applicable to the Report as specified in DE.FORM.TYPE.
HEADER – REPORT TITLE

LINE DESCRIPTION CB n TOTAL CALC
T24 Central TOTAL

Description of Calculation
Line Bank OF ANY
the line Line
of a New
REPORT
N N LINKS TO COLS COL
COL
FROM
DESCRIPTIVE
COLUMNS RE.STAT.COLUMN
Heading details
RE.STAT.ENT.FORMAT
Contains the details about the presentation of 'entries' which are to be included in a movement type
report.
RE.STAT.RANGE
RE.STAT.RANGE contains the details to allow for a single name to be set to cover several values of
any consolidation parameter. E.g. for the parameter 'residence' a range record called 'EEC' could be
set up listing the country codes of the EEC.
RE.STAT.REP.LINE
RE.STAT.REP.LINE contains the details about the different lines and line contents for each report.
Covers details on totalling, spacing of the lines as well as which type of CRB records are to be printed
on the line.

Reporting
REPORT LINE
Identification
• Type • Netting
• Description - Asset
• Totalling - Profit/Loss
• Layout • Variable 2 (PL Category)
• Maturity Splits
Detailed Specifications
Asset/Liability Profit/Loss
• Application • Variable 1 (Application)
• Market • Variable 2 (PL Category)
• Position Type • Variable 3 (PL Sector)
• Currency • Variable 4 (Product)
• Variable 1 (Category) • Variable 5 (PL Initial Term)
• Variable 2 (Sector) • Variable 6 (Officer)
• Variable 3 (Residence) • Variable 7 (Currency)
• Variable 4 (Initial Term)
• Variable 5 (Secured)
• Variable 6 (Type)
Line details
LINE 5 DESCRIPTION DEBIT CREDIT

BALANCE BALANCE
0010 ASSETS
0011
0020 CASH LCY
0030 CASH FCY
0040 TOTAL CASH
0050 OVERDRAWN CURRENT ACCOUNTS
0060 PLACEMENTS BANKS <= 6 MONTHS
0070 PLACEMENTS BANKS 7 MONETHS – 5 YEARS
0080 PLACEMENTS BANKS 2 YEARS – 5 YEARS
0090 PLACEMENTS BANKS > 5 YEARS
0100 OTHER PLACEMENTS
0110 TOTAL PLACEMENTS
0120 INTEREST RECEIVABLE Cur / Accts
0130 INTEREST RECEIVABLE Placements
0140 TOTAL ASSETS
0200 LIABILITIES
0201
0210 CAPITAL
0220 Current Accounts Residents
0230 Current Accounts Non Residents
0240 Savings Accounts
0250 Deposits Bank
0260 Deposits Other
0270 Total Deposits
0280 Interest payable cur + savings accounts
0290 Interest Payable Deposits
0300 Total Interest Payable
0310 TOTAL LIABILITIES
0500 Forex bought – Spot & Forward

0510 Forex sold – Spot & Forward
0520 Forward deposits
0530 Forward Placements
0540 Forward Securities Sales & Purchases
Line details (cont.)

Reporting
Line FIXED PARAM USER PARAMETERS

ASSET.
N Line Line ACC- Total Init Dept ASSET
APPLIC CCY CATEGORY SECTOR RESIDENCE EXT.
Type Description UML Print Term Acc TYPE
DUP.
Off
10 Header Cash AC USD DEBIT MAT

20 Detail Cash LCY 1 MM EUR CREDIT DUP
30 Detail Cash FCY 1 FX GBP FORWARDDB DEF
40 Total Total CASH 1 SC Etc. FORWARDCR
ETC ETC 1 LD LIVEDB
TO To MG LIVECR
9999 9 FR Etc.
LC
FI
Additional line details
Displaying the content of Lines
The enquiry RE.STAT.LINE.CONTENT can be used to show the content of a particular report
(RE.STAT.REP.LINE) line record. For a given line, the CONSOLIDATE.ASST.LIAB keys and
asset types, or CONSOLIDATE.PRFT.LOSS keys with currencies are shown, together with the
balance in the currency of the key and in local currency. This enquiry only shows those lines and
asset types where there is a balance. Asset and Liability details shown do not reflect any maturity
ranges that may be defined for the line.
This enquiry can be particularly useful when investigating the content of an unassigned report line.
RE.STAT.LINE.CONTENT
RE.STAT.NAME
Contains the details for a group, which is to be used in more than one report thus saving the need to
keep entering the details in each report. E.g. a record for current accounts could be set up. The
details maintained are the same as those entered in the RE.STAT.REP.LINE file for line content.

Reporting
RE.STAT.OUTPUT
The reporting module allows the output of details to a sequential disk file as well as or in place of the
standard printed output. RE.STAT.OUTPUT is used to define the content and layout of this output
file.
The output is written to a sequential file under the directory RE.CRF.EXTRACT. Output is redirected
to disk by specifying the name of a record on RE.STAT.OUTPUT in field OUTPUT.MODE on the
report request file RE.STAT.REQUEST.
The RE.STAT.OUTPUT record defines the structure of data extracted from the report in terms of line.
The types of report line available for printing or data extraction are:
• „HEADING‟
• „DETAIL‟ or „LINK‟ in which line details and amounts are printed
• „CCY‟ which prints out the currency for that line
• „TOTAL‟ which are used to print running totals
RE.AMT.ABBREV
Contains the narrative to be printed at the top of a report describing how the amounts are shown in the
report i.e. in millions, in thousands etc.
Main CRB Files
CONSOLIDATE.ASST.LIAB
The CONSOLIDATE.ASST.LIAB contains the consolidation data for Asset and Liabilities. Details
are held by consolidation parameters and within by type of balance or type of 'reserve' account. The
details held are the opening balance, the debit and the credit movements in original currency and local
currency. Also held are details concerning value and maturity dates etc. These details are for the
production of maturity report lines.
Opening balance: This reflects Yesterday's closing balance.

Note Principal details are held under types indicating the sign of the principal. E.g.
Money Market Loans type will be LIVEDB or FORWARDDB.
Debit Movements: They reflect the amounts of DEBITS that a 'CRB' key had during a given day.
Credit Movements: They reflect the amounts of CREDITS that a 'CRB' key had during a given
day.

Reporting
Example 1:
MM.1.TR.USD.21030.BE.40 Type OP BAL DR CR

LIVECR 10000 1000 500
This indicates that for the module 'Money Market':
Currency Market 1
Position Type 1
Currency USD
Category 21030 (Time Deposits)
Residence BE (Belgium)
Sector 40 (Banks)
An opening balance of USD 10,000.00

Debit movements amounting to USD 1,000.00.
Credit movements for USD 500.00
Thus a closing balance of USD 9,500.00
Example 2: (One account in the consolidation record.)
AC.1.TR.BEF.01001.GB.40 Type OP BAL DR CR

DEBIT 500 700 1200
CREDIT 700
This indicates that for the module 'Account'
Currency Market 1
Position TR
Currency BEF
Category 1001 (Current accounts)
Residence GB (Great Britain)
Sector 40 (Private)
An opening balance of -500 (overdrawn)

Credit movements for BEF 1200
and thus a closing balance of 700 BEF credit.

Reporting
NB. As the sign of the balance has changed, the new closing balance for the account is moved from
the DEBIT TYPE to the CREDIT TYPE (with 2 consolidation special entries being raised in
RE.CONSOL.SPEC.ENTRY for BEF 700).
Example 3: (Two accounts in the consolidation record.)
AC.1.TR.EUR.01001.GB.40 Type OP BAL DR CR

DEBIT 500 800 1200
CREDIT 800
The key is as example 2 but the data is now made up from 2 accounts as follows:
OPBAL DR CR CL.BAL
ACCOUNT 1 -300 200 -100
ACCOUNT 2 -200 1000 800
As account 2 has changed sign, the closing balance of this account is moved from the DEBIT TYPE to
the CREDIT TYPE by raising 2 consolidation special entries for 800.
CONSOLIDATE.PRFT.LOSS
This file contains the consolidation data for Profit and Loss. Details are held by consolidation
parameters and within by currency in which the profit/loss was earned/paid. The details held are
opening balance and debit and credit movements in both local and currency earned/paid.
PL.YR.END.ENTRY
This file contains the details of the individual movements of the amounts from the Profit and Loss
Consolidation file to the appropriate Asset and Liability account. Credit and debit STMT.ENTRY file
records are raised for each 999 PL.YR.END Entries. The reference fields are used to provide a link
between the records of the two files.
RE.CONSOL.SPEC.ENTRY
This file contains details of movements to the Asset and Liability Consolidation file, which are not
covered by a STMT.ENTRY record. The layout of this file is similar to that of the STMT.ENTRY file.
RE.STAT.LINE.CONT
This file contains the details for each report line, of type of line, spacing, totalling, line name plus the
keys of the CONSOLIDATE.ASST.LIAB and CONSOLIDATE.PRFT.LOSS records that are to be
included in each line.

Reporting
RE.ACCT.OPEN.BAL
This file contains the details for each customer and internal account of the opening balance today (i.e.
closing balance yesterday) and currency. This file is updated during the printing of the Trial Balance
Report.
RE.CONSOL.ASSET.LINE
This file contains details of the variable parameters and the report lines that the details have been
specified for. This file is used to determine which report lines a particular
CONSOLIDATE.ASST.LIAB record is to appear on. The key to this file is the first user variable
specified for the Asset and Liability consolidation file. The processing allows for a default option (i.e.
no specific value applies) for any variable when specifying a report. The value used to signify this is}
(a right hand curly bracket). This value cannot be entered on the keyboard so the value to be entered
to display this default record is DEFand.
Deal Level Balances
Lookup Files
RE.CCY.CONSOL
Contains details of the CONSOLIDATE.ASST.LIAB records by currency, currency market and

position type.
RE.CONSOL.CONTRACT & RE.CONSOL.CONTRACT.SEQU
These files contain details of the accounts feeding each CONSOLIDATE.ASST.LIAB record and
within by balance type. These files will also be used for MM.MONEY.MARKET and FOREX
contracts.
RE.CONSOL.BONDS & RE.CONSOL.BONDS.SEQU
These files contain the details of the Bonds positions feeding each CONSOLIDATE.ASST.LIAB
records.
RE.CONSOL.LOAN & RE.CONSOL.LOAN.SEQU
These files contain the details of the Loans and Deposits records feeding each
CONSOLIDATE.ASST.LIAB record.
RE.CONSOL.PROFIT
This file contains details of the CATEG.ENTRY file records feeding each
CONSOLIDATE.PRFT.LOSS record for a particular run date.

Reporting
RE.CONSOL.SPEC.ENT.KEY
This file contains the details of the RE.CONSOL.SPEC.ENTRY records that are linked to each Asset
and Liability Consolidation record and type for a particular run date.
Utility Files
The following files will require the user to input data and will then perform actions such as the
production of a report.
RE.CLEAR.CONSOL.REQ
This file contains the records that are required to clear the appropriate parts of the CRB base before
the base is recreated.
RE.STAT.BAL.REC
This file is used in the reporting of the deals and/or accounts and the appropriate balance or
Interest/charge amounts that make-up the individual lines of a report or part of a report.
RE.STAT.LINE.CHANGE
This file is used to indicate the lines that are to be moved (renumbered) within a report.
RE.STAT.REQUEST
This file is used in the production of the CRB reports. The file specifies the reports that are printed,
the language that the reports are to be printed in and the output device to which the report is sent.
The output device may be specified as a printer or a hard disk. The level of the report required can
also be specified. This means the report can be specified to be a „SUMMARY‟, „DETAIL‟ or „BOTH‟
type of report.
RE.STAT.MISMATCH
This file is checked if there are any mismatches between the CRB files and the application files.
RE.EXTRACT.PARAMS –
• KEY.FORMAT to be set to LINE.IDS

• CRB.REPORT to be set to Y, only then MISMATCH details will be displayed
• OPTIONS – need to include NET.LINE.BAL only then the TOTAL details will be displayed

Reporting
Batch record – RE.PRINT.DEAL.RPT
Input the report name (id of RE.RETURN.EXTRACT) in the data field for RE.OUTPUT.EXTRACT
& RE.OUTPUT.EXTRACT.MISMATCH jobs.
RE.RETURN.EXTRACT
This application is used to load details of the CRF reports that are to be extracted to a disk file in the
batch run.
Underlying balances
The application RE.RETURN.EXTRACT provides an additional option, which will allow balances and
details from the underlying contracts to be output in the created extract file. This option may be
required when producing an extract file based on a CRB report for handoff to a local reporting
package.
If the field CONTRACT.DETAILS is set to YES, the details of the underlying Asset and Liability
contracts will be output as separate records. The following fields are appended to the end of the
output record:
• ID Sequence Number * Contract / account Id * Asset Type

• Customer number
• Deal Balance for Asset Type in Deal Currency
• Deal Balance for Asset Type in Local Currency
• Interest Rate (or Exchange Rate in the case of FX deals)
• Value Date
• Maturity Date
• Initial Term in Days
• Remaining Term in Days
Note that records will still be created for each CONSOLIDATE.ASST.LIAB / PRFT.LOSS record as
before with no contract details. These records will not contain any contract reference or asset type in
the key.
Automatic build of dictionary for extract file
An option to build the dictionary for the CRB extract file created when the application
RE.RETURN.EXTRACT is run is available. If the field BUILD.DICTIONARY is set to YES, a
STANDARD.SELECTION record for the extract file RE.CRF.XXX (where XXX is the report name),
will be created / amended. Fields will be built based on the contents of the associated
RE.EXTRACT.PARAMS record.

Reporting
Existing USR… fields in the STANDARD SELECTION will not be amended by the rebuild of the
dictionary.
Producing reports in non local currencies
RE.BASE.CCY.PARAM
This file contains information necessary for producing CRB/CRF reports in a currency other than the
local currency.
To convert a report, enter the key of this record in the BASE.CCY.PARAM field of the appropriate
record in the RE.STAT.REQUEST file. This alone is not enough to provide the report. To enable the
information to be extracted for reporting, a record must be entered in RE.BASE.CCY.REQ and the
extract must be run by either:
• Verifying the RE.BASE.CCY.REQ record online

Or
• Inputting and authorising the BATCH record EOD.RE.BASE.CCY.CRF so that it runs daily and the
currency code of the RE.BASE.CCY.PARAM record is in the DATA field.
CRF REPORT:-
• Verifying the RE.STAT.REQUEST record

Or
• Identifying it in the BATCH job EB.STAT.PRINT will produce the report.
CRB REPORT:-
To convert a CRB report append an asterisk and the currency code to the report name in the BATCH
record EOD.RE.BALANCE.PRINT, e.g. SBSUSA*USD.
RE.BASE.CCY.REQ
This file controls the extraction of information necessary for producing CRB/CRF reports in a currency
other than the local currency. Each record on this file is linked to a record on
RE.BASE.CCY.PARAM via the PARAM.ID field.
Verification of a record on this file causes the extraction of CRF report information. Verification of a
RE.STAT.REQUEST record with the appropriate currency code in the BASE.CCY.PARAM field then
this causes the report to be printed.

Reporting
Internal Files
The following files are used within the processing of the moving of report lines within a report. Due to
possible number of lines being moved and associated records changed, there are special back-up and
recovery routines for this function.
• BK.RE.CONSOL.ASSET.LINE
• BK.RE.CONSOL.PROFIT.LINE
• BK.RE.REP.STAT.LINK
• BK.RE.STAT.CROSS.LINE
• BK.RE.STAT.LINE.CONT
• BK.RE.STAT.NAME.REPORT
• BK.RE.STAT.RANGE
• BK.RE.STAT.REP.LINE
• BK.STAT.LINE.CONT.TEMP
• RE.STAT.REP.LINE.TEMP
• RE.STAT.TOTAL.RANGE
RE.CONSOL.PROFIT.LINE
This file contains details of the variable parameters and the report lines that the details have been
specified for. This file is used to determine which report lines a particular
CONSOLIDATE.PRFT.LOSS record is to appear on. The key to this file is the first user variable
specified for the Asset and Liability consolidation file. The processing allows for a default option (i.e.
no specific value applies) for any variable when specifying a report. The value used to signify this is}
(a right hand curly bracket). This value cannot be entered on the keyboard so the value to be entered
to display this default record is DEFand.
RE.FOREX.OPTION
This file contains records for option deals only. For each deal, it holds the latest option settlement
dates and amounts, whether paid or not. This information is used within the FOREX Close of
Business CRB processing to determine the CRB updates to be made for payments and/or changes
etc.
RE.LD.CHARGE.COND
This file contains the details of the CATEGORY code for each charge code and is used in
determining whether a change of CATEGORY code has occurred. In which case, the appropriate
movement entries are raised.

Reporting
RE.LMM.INSTALL.CONDS
This file contains the previous day‟s LMM.INSTALL.CONDS record and is used in determining
whether changes of category code have occurred. If they have then the appropriate movement
entries are raised.
RE.PL.YTD.HOLD
This file contains the year to date total amounts for those report lines, which contain year to date
details separately from current month details. These details are calculated the first time the report is
produced in the month and is recalculated if the report specification is changed.
RE.REP.LINE.CALCULATE
This file is used to tell the off-line processing that the Asset and/or Profit Line details on the
RE.STAT.LINE.CONT file need to be recalculated due to the changes made to the
RE.STAT.REP.LINE file.
RE.STAT.CROSS.LINE
This file contains details of lines linked for maturity date splits and for lines linked for Profit sign splits.
RE.STAT.VAR1
This file contains the details of individual values of variable 1 and which report‟s specification they
have used.
RE.STAT.VAR1.RANGE
This file contains the details of the ranges for variable 1, the name given to the range and the reports
in which it has been used.
RE.STAT.NAME.REPORT
This file contains the details of the report line numbers that each RE.STAT.NAME record has been
used.
RE.MM.CHANGED.DEALS
Thisfile is a work file used between the two programs RE.MM.BAL.MOVE and
RE.MM.INT.ACCRUAL, to pass details of deals that have moved from one CRB record to another
so that the accrual entry is posted to the old CRB record.

Reporting
RE.NEW.ACCOUNT
This file is a work file, which is used during the interest and charges processing. It is updated when
the first entry posted to an account is an interest and charges entry. As soon as the interest and
charges processing is finished, this file is used to update the RE.CONSOL.CONTRACT file.
RE.PROFIT.WORK.FILE & RE.SELECT ENTRIES
These two files are used within the CRB report printing process as work files.
RE.STAT.TOTAL.RANGE
This file contains the definitions of a range of values, or a set of individual values, for report line
content definitions. Total lines may be split according to the above values.
Multi Company Reporting
These reports are like the main reports produced under the same name but the difference being that
they are consolidated reports for one or more companies.
These reports are normally produced through the Close of Business process EB.CONSOL.PRINT or
can be produced on-line using the RE.CONSOL.REQUEST application.
The layout and contents of the reports are the same.
There are various options as to which exchange rate needs to be used when producing the reports in
a currency other than the local currency. These options allow for a special reporting rate rather than
the normal daily exchange rate being used.
The applications used to produce these reports have been discussed below.
RE.CONSOL.REQUEST
This file is used for generating Multi Company reporting requests. The exchange rate to be used for
currency conversion is specified from any of the following sources:
• DEFAULT - Taken from the currency file specified on the Company Consol Record.
• COMPANY - Taken as the rate between the local currency for the company and the reporting
currency for the Currency file for that company.
• SPECIAL - Indicates that the rates on the RE.RPT.CCY.RATE file for the record pointed to by
the field SPEC.RATE.ID is to be used.

Reporting
RE.RPT.CCY.RATE
This file is used to specify an exchange rate when a special currency exchange rate needs to be used
in multi-company reporting.
Company specific Reports
It is possible to define whether a Report is Company specific and for which Company the Report
needs to be populated, by using the fields BRANCH and BRANCH.MODE in the application
RE.STAT.REPORT.HEAD.
When the field BRANCH is set to 'Y', a Consolidation key would be fitted into the Report using the
Company specific (second) component of the key variables. If for a particular key variable, there is no
Company specific definition (i.e. the key variable has only one component without „_‟ suffixed), then
the value of the variable would be used to fit the Report.
When the field BRANCH is not set to „Y‟, the consolidation keys would be fitted into the Report using
the default (first) component of the consolidation file key variables.
Since Reports are common to all Companies, the field BRANCH would be used to further specify for
which Company the consolidation keys need to be fitted into the Report. For other Companies, the
Report will not have any contents.
Example: The consolidation variable SECTOR is redefined for the Company with ID US0010002 in the
Company specific CONSOLIDATE.COND records ASSET&LIAB.US0010002 and
PROFIT&LOSS.US0010002. The Report CO2STD is required to report for the Company US0010002
using the Company specific values of consolidation variables. Lines of the report CO2STD are defined
with values of SECTOR relevant to the Company US0010002. In this case, the fields BRANCH.MODE
and BRANCH should be respectively updated with 'Y' and 'US0010002'.
If the value of BRANCH is set to 'Y', while fitting the consolidation key
AC.1.TR.GBP.1001.1_10.5400_001.8530_8530._8.GB.003_._._100 into the Report CO2STD, for the first
and seventh variables which have only one component their values „1001‟ and „GB‟ would be used.
However, for other variables, which have a second component, only those values would be used.
Thus the values of „10‟ for the third variable '1_10', „001‟ for the fourth variable '5400_001', '8530' for
the fifth variable '8530_8530', „8‟ for the sixth variable '_8', null for the eight variable '003_', null for the
ninth variable '_' and „100‟ for the tenth variable '_100' would be used.
If the value of the field BRANCH.MODE were not set to 'Y', then for all the variables, values of the first
component of the variables would be used to fit into the Report. Thus the values of 1001,null,
1,5400,8530,null, GB, 003,null, null would be respectively used for the ten variables to fit into the
Report.
Export & Import

The system allows for exporting CRB information from one or more T24 systems such as branches or
offices and importing it into another T24 system in order to run combined reports.

Reporting
The accounts department at the Head Office create a General Ledger, which will contain details from
their database combined with data from branches. The branches export the data in a standard format,
then the main office imports all the data and runs the CRB report.
Three records are produced at each export. One is the detail from CONSOLIDATE.ASST.LIAB; the
second has details from CONSOLIDATE.PRFT.LOSS and the third contains control data from files
such as RE.STAT.REP.LINE and CONSOLIDATE.COND.
The following example reviews how a branch sets up the files in order to send CRB data to its Head
Office where a combined General Ledger is to be produced. Typically the layout of the General
Ledger is created so that the Head Office and Branch (es) export/import the data in the same format.
Exporting
The T24 system exporting data will need to have:

• A valid RE.STAT.REPORT.HEAD and associated files.
• A correctly setup RE.TRANSFER.PARAMETER defined for the export.
• A RE.EXPORT.REQUEST record defining the system copy commands and the data
medium.
RE.TRANSFER.PARAMETER - Export
The branch database RE.TRANSFER.PARAMETER record SYSTEM is configured to export the

CRB data from the CRB files through some temporary internal files to the transfer medium. The
commands used to copy the data, whether on a Unix system or Windows NT, can be file-to-file,
involve the creation of tapes or perhaps FTP or TCPIP transfers.
The example screen shows the branch COMPANY GB0010008. To avoid any possibility of
overwriting data from other branches, it has a unique identifier, in this case BR1.

Reporting
RE.TRANSFER.PARAMETER
RE.EXPORT.REQUEST
This application is used for specifying the UNIX or Windows NT commands that will do the transfer of
data out of the source T24 system. The application can also specify the companies for which the
transfer needs to be performed.
The export process is activated using the Verify function.
RE.EXPORT.REQUEST

Reporting
Importing
The T24 system importing data will need to have:

• A valid RE.STAT.REPORT.HEAD and associated files
• A correctly setup RE.TRANSFER.PARAMETER and associated files
• A RE.EXPORT.REQUEST record defining the system copy commands and the data
medium
RE.TRANSFER.PARAMETER - Import
The Head Office database RE.TRANSFER.PARAMETER record SYSTEM is configured to import the
CRB data from the transfer media through some temporary internal files and then onto CRB database.
The commands used to copy the data, whether on a Unix system or Windows NT, can be file-to-file,
involve the creation of tapes or perhaps FTP or TCPIP transfers.
The example screen shows the Head Office is COMPANY GB0010001. To avoid any possibility of
overwriting data from other branches, it has a unique identifier, in this case BR1.
RE.TRANSFER.PARAMETER
RE.IMPORT.REQUEST
This application is used for specifying the UNIX or Windows NT commands that will do the transfer of
data into the target T24 system. The application can also specify whether the recalculation of the
CRB needs to be started immediately after the import of data is complete. In case this option is not
desired, the recalculation procedure needs to be initiated by running the application
RE.RECALC.REP.LINES from the T24 command line.

Reporting
RE.IMPORT.REQUEST
Printing back-dated reports from CRB
The CRB module allows for the maintenance of historic information so that it may be possible to print
reports as at a date in the past. This feature is optional and may be switched on whenever required.
In order to switch on the feature, the following actions should be performed:
RE.STAT.REPORT.HEAD – The field MAINTAIN.BALANCE can be set to either

„SUMMARY‟ or „DETAIL‟ in order to allow the system to build balance level information or
balance and underlying movement level information respectively. This field is relevant to the
entire report.
RE.STAT.REP.LINE – The field LINE.BALANCE can be set to either „SUMMARY‟ or
„DETAIL‟ in order to allow the system to build balance level information or balance and
underlying movement level information respectively. This field is relevant only to the particular
line in a report.
For ease of reference to the CRB report lines, a mnemonic has been added to the
RE.STAT.REP.LINE record.
An optional mnemonic field has been added to CATEGORY, which can be used to reference a P&L
code in Funds Transfer, Data Capture and Teller applications.
In order to allow enrichment of CRB transaction codes, the RE.TXN.CODE file will allow CRB
transaction codes to be defined together with a description. These codes will be recorded solely for
information purposes and cannot be used as transaction codes in applications.
The following files will be maintained to achieve this functionality.

Reporting
RE.STAT.LINE.BAL
This file will be used to maintain balance at report line level on a daily basis. Currency and the period
end date hold the details in this file, and the following data is recorded:
• Opening Balance
• Opening Balance Local Equivalent
• Credit Movement
• Credit Movement Local Equivalent
• Current Month‟s Credit Movement
• Current Month‟s Credit Movement Local Equivalent
• Year to Date Credit Movement
• Year to Date Credit Movement Local Equivalent
• Debit Movement
• Debit Movement Local Equivalent
• Current Month‟s Debit Movement
• Current Month‟s Debit Movement Local Equivalent
• Year to Date Debit Movement
• Year to Date Debit Movement Local Equivalent
• Closing Balance
• Closing Balance Local Equivalent
Data will be recorded at this level if the field LINE.BALANCE contains a value of DETAIL or
SUMMARY. For reports where historical movement / balance details are not required, the
LINE.BALANCE field should be left empty.
Creating Year to Date & Monthly RE.STAT.LINE.BAL movements
If the functionality to report historical movements and balance details is activated mid-year, it is
possible to recreate the movements from the start of the financial year and populate these fields on
the RE.STAT.LINE.BAL records. Launching routine BUILD.LINE.BAL.G10.0.01, which should be
entered into the CLASSIC interface of T24, may do this.
Before starting on the conversion, check that RE.STAT.LINE.BAL files have been correctly resized,
as this can have a significant effect upon conversion times.
RE.STAT.LINE.MVMT
This file will be used to maintain an index to the underlying movements in the files STMT.ENTRY,
CATEG.ENTRY and RE.CONSOL.SPEC.ENTRY, as a RE.STAT.LINE.BAL record may be

Reporting
maintained if the field LINE.BALANCE in the associated RE.STAT.REP.LINE record is set to

„DETAIL‟.
Note that Movement details are only recorded for MOVEMENT type reports. For CLOSING reports,
the debit and credit movements will not be recorded.
For each report line, currency, date and file type, a list of the entry keys raised are held. In order to
hold data efficiently, the system will split these records every n keys to maintain an even spread of
data. One record will contain data from only one file, identified by a file identifier code of:
• „A‟ (Account) - STMT.ENTRY

• „P‟ (Profit and Loss) - CATEG.ENTRY
• „R‟ (Special Entry) - RE.CONSOL.SPEC.ENTRY
Maturity Splitting
Where a line has maturity splits defined, the balances will be recorded against the first line of the
maturity split lines when the report type is a MOVEMENT report (this is indicated by the value of the
field GROUP in RE.STAT.COLUMN.TYPE for the first COLUMN.TYPE). The balance and
movements for the other lines will be recorded as zero. This is the same logic as followed by the
existing CRB reporting.
For CLOSING reports, the system will record balances against each maturity-split line.
Back dated reports
Three Enquiries, which can be produced as reports, are provided for by the system. These are
discussed as below:
Journal
This report shows for any one system date, a transaction journal by application, showing report line
number or mnemonic, transaction reference, transaction description, amount, currency and local
equivalent.
Trial Balance
This report shows for any given period (usually a month) by report line number, the opening balance,
total debit movement, total credit movement, total net movement and closing balance for the period.
General Ledger
This report shows for any given period and report line number (it may show all or a range of report line
numbers), the opening balance, the transaction date, the transaction reference, transaction description,
currency, sign, amount and local equivalent, with the closing balance for the period.

Reporting
USGAPP REPORTING
In order to meet the minimum requirements for US GAAP reporting standards:
The LOCAL.REF field in the COMPANY application can be used to allow the recording of the parent
company residence.
The ability to group countries and commodities as per the US GAAP standards into unique groupings
can be achieved via GROUP fields in LIMIT.COUNTRY.GRP and LIMIT.COMMODITY.GRP.
The Money Markets and the Loans and Deposits modules can be linked to an interest table to be able
to provide the fair value interest rate for revaluation purposes of the loan. The application is
additionally required to be able to link to an interest table to provide the margin to be applied to the fair
value interest rate.
The FV rate can be entered in manually in MM.MONEY.MARKET or
LD.LOANS.AND.DEPOSITS by populating the FV.RATE.KEY first then FV.MARGIN.KEY, or
their values can be defaulted according to CATEGORY of the transaction. These defaults are set in
LMM.ADVICES.
Multi – GAAP Reporting Value Date Accounting
If required for GAAP reporting purposes the table FX.POS.TYPE and its defined id‟s can be utilised
by the system to create and differentiate between different Position Types The CRF base can then be
updated and specific reports can be run.
FX.POS.TYPE record MI.

Reporting
These records in association with the ACCOUNT records created per Position Type and the
appropriately configured ACCOUNT.PARAMETER and REVALUATION.PARAMETERS can
then be utilised by applications that are set to Value dated accounting and the CRF will be updated
accordingly.
Configuration and worked example –

The following CATEGORY code is established for the purpose of MI (Management Information)
reporting. The value of MI can be entered in the POSITION.TYPE field.
CATEGORY code for MI.
Once the CATEGORY code has been created then suitable ACCOUNT records can be created.
Note – Only INTERNAL type accounts are permitted with a type other than TR.

Reporting
ACCOUNT record for MI type.
The REVALUATION.PARAMETER needs to be configured for any new FX.POS.TYPE records

created. The example of HF can be seen below.
REVALUATION.PARAMETERS with HF configured.

Reporting
The ACCOUNT.PARAMETER file fields ENTRY.CATEGORY and SUS.CATEGORY can be

configured like below to identify a CATEGORY code per FX.POS.TYPE.
ACCOUNT.PARAMETER with specific Entry codes.
As in this case FT is set to value dated accounting being specified in fields VAL.DATE.SYS.ID and
VAL.DATE.BY.SYS.
As seen in the example below when a FUNDS.TRANSFER transaction is entered that uses these
Category codes in the DEBIT/CREDIT.ACCT.NO fields then these suspense accounts will be utilised
in the processing of accounting records.

Reporting
FUNDS.TRANSFER using MI accounts.
STMT.ENTRY records created from the FUNDS.TRANSFER.

Reporting
The Ways of Treating Reversal Entries in CRF
The transaction entries that are reflected in CRF for Debit/Credit movement depends upon the sign of
the numeric entry, ie if the sign of the transaction amount is negative, it is shown as a debit movement
and if it is positive it is shown as a credit movement. The settings of the parameter fields
CRF.REVERSAL.FLAG in ACCOUNT.PARAMETER and the REVERSAL.MARKER for REV in
RE.TXN.CODE, gives the functionality to reflect reversal entries in CRF in two different ways. One
way is to treat the reversal entries like the non-reversals where the movements are exaggerated in
their respective direction of their signs of the transactions involved. This will not set off the movement
of the original entry. The other way, unlike the non-reversals, the reversal entry movements are not
exaggerated in their respective directions. They not only reflect in the same direction as the original
entries, but also nullify the total movement of the whole transaction.
The above functionality can be invoked by setting the above parameters to YES in
ACCOUNT.PARAMETER as well as in RE.TXN.CODE.
Hypothetical illustration:
Consider a scenario where given below is the only place on a business day.
A Loan is drawn down on Day 1 and an EOD is run, then the Loan is reversed out on Day 2.
Accounting Entries:
Account 1 Account 2
Debit Credit Debit Credit
Day 1 -1000 1000
After Reversal
Day 2 1000 -1000
Balance 0 0
CRF Entries without the Reversal flag/marker:
Debit Movement Credit Movement

CRF Type Debit Type Credit Type Debit Type Credit Type
Day 1 -1000 1000
After Reversal
Day 2 -1000 1000
Total Movement -2000 2000
CRF Entries with the Reversal flag/marker:

Reporting
Debit Movement Credit Movement

CRF Type Debit Type Credit Type Debit Type Credit Type
Day 1 -1000 1000
After Reversal
Day 2 1000 -1000
Total Movement 0 0
End of year procedure
The PL.CLOSE.PARAMETER has 5 settings of note.

• Reports
• Year End
• Excluded Types
• Grouping
• Halt Process
Reports
The reports section has three related fields, REPORT.TYPE, REPORT & REPORT.DATA these control
the reports that are produced during the close out process. The reports can be ENQUIRY,
REPGEN.CREATE or program driven; this is where REPORT.TYPE is used to specify the type
(CRF, RTN, RPG or ENQ). REPORT contains the key to REPGEN.CREATE, ENQUIRY.REPORT,
RE.STAT.REQUEST or a valid compiled program name. Lastly, the REPORT.DATA field allows the
program driven routines to be passed a parameter

Reporting
PL.CLOSE.PARAMETER report fields

Reporting
Year End
The financial period end, usually yearly but it can be defined as Monthly, Quarterly, Semi-Annual or
Annual is set in CLOSE.FREQ.DATE as a month end date and the frequency to cycle.
PL.CLOSE.PARAMETER Year End cycle
Excluded Types
Certain PL categories are used for non-financial purposes and these would not normally be included in
the close out (though they are parameterised in case there is a specific need to include them).
TYPES.TO.EXCLUDE contains the types which should not be included. As a default we exclude the
types
• CP – Contingent
• CI – IAS P&L
• CL – Local Gap P&L

Reporting
Grouping
The structure of the keys in the CONSOLIDATE.PRFT.LOSS file is set in

CONSOLIDATE.COND record PROFIT&LOSS. The essential elements are preset as „PL‟ for the
application id, „CURRENCY‟ based on the transaction of the deals etc. AL.GROUPING can be set to
group the entries based on the user configured elements.
By default the entries produced will be based on the CATEGORY/CURRENCY and one entry will be
passed to the internal account (as defined by the ( ACCOUNT.CLASS record PLCLOSE). Each of
these entries will be the sum of the all the CONSOLIDATE.PRFT.LOSS records matching the
combination of CATEGORY & CURRENCY.
To produce entries summed at different group levels you may add the additional elements from the
PROFIT&LOSS key so that for example the entries are summed for all records matching the same
PLCATEGORY/CURRENCY/PLNATIONALI/PLSECTOR/PLINDUSTRY or whatever local settings you
have defined.
PL.CLOSE.PARAMETER Grouping

Reporting
Halt Process
In essence this is just a flag which allows the cob process to be halted just before the close out
process is run. This allows the users to access reports or files to extract key financial data they require
before the files are updated by the process. If left unchecked the process will run without halting.
Set field PL.CLOSE.HLT.PRCSS as required.
PL.CLOSE.PARAMETER halt option
Note.
Though the halt field is included on each PL.CLOSE.PARAMETER record, there will in fact only be
the one halt to the cob processing. This will happen once all the companies have finished this stage of
the PL close out processing.

Reporting
Accounting
The most essential parts of the PL close out are the accounting and the backup to how this has been
created from the system.
During the financial year the PL accounts will become used and contain both credit and debit
balances; hopefully profit accounts in credit and a small number of loss with debit balances.
Some of these will be simple expense type accounts where just a few accounting transactions can be
seen to build up the balance at year end. Others will be the daily accrual type where a large number of
transactions spread over the year will have affected the balance, together with adjustments, reversals,
cancellations etc. Each day when a General Ledger report is produced it is possible to monitor both
the balances and movements over the PL and as such at the year end the accountants will need to be
able to evidence the totals.
Let‟s assume a simple PL account has built up a balance of USD 1,000.00 over a period and has a
credit of USD 50.00 on the final day of the financial period. The accountant will expect to see a
closing balance of USD 1,050.00 for the old year and a new fresh balance of USD 0.00 for the New
Year; the balance having been transferred to an internal Asset & Liability account.
In the examples below we will show the progression of a single CONSOLIDATE.PRFT.LOSS

record from a populated start point, though to the „virtual year end day‟ and then the new financial
year. First the record (based on PLCATEGORY 50-010) as it appears towards the year end:
Record before year end

Reporting
Entries for 50010 for the PL key - just before we get to year end
Now the record as it appears at the start of the close out process:
Year end totals

Reporting
Enquiry showing entries:
Entry totals for the year
Lastly the record as it appears in the new financial year:
New financial year PL

Reporting
New Financial year entries posted

Note
The entries include the close out figure (128,418.06) which matches our expected results from the last
financial year total for this record. And the new entries which match our new financial year total so far.
The close out entry is easily identifiable from the references on the entry (not shown on the above
listing).
Grouping
By default the system will produce one accounting entry per currency for each PL Category. Since
there will be many CONSOLIDATE.PRFT.LOSS records for each of these the option to group them
by more specific values is permitted.
Let‟s use a simple example to illustrate this.
Our PL Category 51000 for USD has 7 records which total USD 2,001,989.95, this amount will be
debited and posted to the AL Account specified in the PLCLOSE ACCOUNT.CLASS record.
Key Amount
PL.51000.1001.N.1.8002.GB.2510.GB.....US0010001 1,000,000.00
PL.51000.1001.N.1.8003.GB.2520.GB.....US0010001 500,000.00
PL.51000.1001.N.5.3100.US.3120.US.....US0010001 333,333.33
PL.51000.1001.N.45.5400.JP.9000.JP.....US0010001 101,101.11
PL.51000.1001.N.65.3300.US.3900.US.....US0010001 55,555.40
PL.51000.1001.N.75.3300.US.5120.US.....US0010001 11,111.23
PL.51000.1001.N.75.3300.US.5120.US.....US0010001 888.88
Total 2,001,989.95
However, we wish to have the totals split into groups based on the residence of the clients, the first
country code in the keys above. Setting AL.GROUPING in PL.CLOSE.PARAMETER to both
PLCATEGORY & PLRESIDENCE will instruct the system to produce grouped accounting entries.

Reporting
On this basis we would have three sets like this
PLCATEGORY = 51000, CURRENCY = USD & PLRESIDENCE = GB

Key Amount
PL.51000.1001.N.1.8002.GB.2510.GB.....US0010001 1,000,000.00
PL.51000.1001.N.1.8003.GB.2520.GB.....US0010001 500,000.00
Total 1,500,000.00
PLCATEGORY = 51000, CURRENCY = USD & PLRESIDENCE = US
Key Amount
PL.51000.1001.N.5.3100.US.3120.US.....US0010001 333,333.33
PL.51000.1001.N.65.3300.US.3900.US.....US0010001 55,555.40
PL.51000.1001.N.75.3300.US.5120.US.....US0010001 11,111.23
PL.51000.1001.N.75.3300.US.5120.US.....US0010001 888.88
Total 400,888.84
PLCATEGORY = 51000, CURRENCY = USD & PLRESIDENCE = JP
Key Amount
PL.51000.1001.N.45.5400.JP.9000.JP.....US0010001 101,101.11
Total 101,101.11
This is a simple example for the User Guide; of course further sub-division will be possible based on
the key structure. The more sub-divisions used will mean more accounting entries but since the crf key
structure has been created in a desired format the entries are likely to be needed with the same
breakdown.
Virtual Day
The processing of the PL close out effectively creates a second day for the year end, this „virtual day‟
is used to segregate the accounting entries and record updates to enable the year end process audit
to be as clear as possible.
Some of the system files will have system dates with „CL‟ appended to indicate these are unique to the
close out process.

Reporting
EB.JOURNAL.SUMMARY showing year end actual and year end ‘virtual’ (CL)
Below we can see the standard journal summary for the 31 Jan 2001:
31 JAN 2001 summary record
Next we have one which has a suffix of CL on the date, indicating this is the „virtual‟ date when the PL
close processing entries are passed
31 JAN 2001 (CL –virtual day) summary record
Lastly, we have the next record for the new financial year.

Reporting
New financial year summary record
During the close out process the system will produce the end of year accounting entries, create the
requested reports/enquiries and if required halt the cob process for audit purposes.
At this stage the CONSOLIDATE.PRFT.LOSS records are in an intermediate stage showing the
effect of the entries posted for the „virtual day‟, before they are cleared down for the new financial
year. If the halt process is skipped you won‟t see the intermediate records.
Let‟s look at one particular CONSOLIDATE.PRFT.LOSS record as an illustration as it goes through

the year end processing. First the record near the year end.
Record for close of business 29 JAN 2001

Reporting
And the effect when listed in RE.STAT.LINE.BAL
RE.STAT.LINE.BAL movement and ytd figures
Now the same record as it appears during the halted „virtual‟ day:
End of Year record
End of year line movement and total ytd
And finally once the close out has completed the cleared record for the new financial year:

Reporting
New financial year record showing entries for new year only
New financial year line movements.
Transaction Journal Reporting

T24 produces transactional reports grouped by the current working day and application and a total of
debits and credits per application are maintained. The total of debits per application should equal the
total of credits, which is displayed as a net total. The final totals for the day are also displayed.
Entries applicable to the current working day are those that are actually booked to the CRF (Central
reporting files, CONSOLIDATE.ASST.LIAB and CONSOLIDATE.PRFT.LOSS). In a value date
system forward entries will be booked today but will not impact the CRF until the value date, so they
will not appear on the reports until the value date. The PROCESS.DATE field on the entry will indicate
the date that the entries become active.
If the reports are in balance then the total debits for all applications should equal the total of credits.
The reports may be produced for each independent financial entity, or company, which could be a
lead company or a branch.

Reporting
The individual entries are stored in the following tables:

• STMT.ENTRY – updates to accounts
• CATEG.ENTRY – updates to profit and loss
• RE.CONSOL.SPEC.ENTRY – updates to CONSOLIDATE.ASST.LIAB
The following tables contain a list of the day‟s entries and are used for various reports:
• ACCT.ENT.LWORK.DAY
• CATEG.ENT.LWORK.DAY
• SPEC.ENT.LWORK.DAY
T24 allows the use of two transaction journal reports: TXN.JOURNAL.PRINT and TRANS.JOURNAL2
TXN.JOURNAL.PRINT Report
This transaction journal report is generated and maintained by three BATCH jobs:
• TXN.JOURNAL.SORT: A multi threaded job at report stage that selects the data required for printing.
• TXN.JOURNAL.PRINT: A single threaded job at online stage that prints the report.
• TXN.JOURNAL.CLEAR: A multi threaded job at online stage, executed after TXN.JOURNAL.PRINT,
which clears old TXN.JOURNAL keys.
After initial installation when running the next COB the BATCH TXN.JOURNAL.SORT should have the
value held in FREQUENCY set to “Daily”, subsequent to this the record should be amended to set the
FREQUENCY to “Ad-hoc” to reduce the processing overhead. Should the report need to be repaired or
redesigned the BATCH will need to be re-run in the COB to apply changes.
The BATCH job TXN.JOURNAL.PRINT: has the ability to print a report for an alternative date. The
default is to print the report for the batch start date. To print for an alternative date, enter the date in
the BATCH DATA field. Please note that TXN.JOURNAL.PRINT can only print entries where a key has
been generated by TXN.JOURNAL.SORT in the file TXN.JOURNAL.
The batch job TXN.JOURNAL.CLEAR has the ability to remove entries after a specific number of
calendar days. The default is to keeps 1 day worth of data; override this by changing the value in the
BATCH DATA field to a numeric value for the number of calendar days to keep. If the DATA field is
empty or 0, this will default back to 1.
TRANS.JOURNAL2 Report
To activate the generation of this report it is necessary to add the record to BATCH EB.PRINT.

Reporting
BATCH record BNK/EB.PRINT
The report is produced using a REPGEN; this is a user definable method of producing reports from
T24 data via REPGEN.CREATE. It is based on decision tables and incorporates a source code
generator to produce a sort program to produce the data for the report and a print program to actually
print the report, TRANS.JOURNAL2.
The basic structure of REPGEN is as follows:-

• REPGEN.CREATE a decision table that defines the report to be produced
• REPGEN.SOURCE a source code generation program that produces the sort program
(RGS.XX) which will write the print data into a work file of the same name, and a print program
(RGP.XX) that will sort select the work file and produce the print
• REPGEN.SORT will run the sort routine online
• REPGEN.OUTPUT will run the print routine online
Accounting Process
ACCRUAL REVERSALS
Accounting practice is to reverse out yesterday‟s accrual to date and repost today‟s accrual to date.
The reversals for foreign currency can either be booked using today‟s rate or previous rate. The
rebooking of foreign currency accruals is at today‟s MID.RATE.
The setup of this functionality is parameter driven. The application ACCR.REV.PARAM is used to
build up the structure of applications which will have the accruals reversed, and which rules will be
applied. This file is an INT level file and as such a record must be created for lead company.
Workflow for accrual reversals

Reporting
The parameter table ACCR.REV.PARAM will hold the following information;
• REVERSAL.FCY - Accrual reversal processing for FCY indicator

• REVERSAL.LCY - Accrual reversal processing for LCY indicator
• REVERSAL.RATE - Reversal rate
• PL.CATEGORY - Accrual PL category codes by application
• LINK.PL.CATEGORY – some applications allow the calculated back valued interest to be split
between different category codes. This field allows these additional category codes to be linked to
the main interest income category so that the accruals can also be reversed and re booked.
Example ACCR.REV.PARAM
The EB.CONTRACT.BALANCE will be updated to hold the amounts accrued to date in foreign and
local currency, the exchange rate used and booking date.
On input of the transaction, the entries will be passed to a core accounting program to be checked
against the PL Category codes defined in the ACCR.REV.PARAM. If there is a match for both
SYSTEM.IND and PL.CATEGORY the following will happen:
First Day Accrual

• EB.CONTRACT.BALANCES is updated with accrual amounts passed.

Reporting
• The entries are left as received.
2nd day accrual and up to last day of accrual

• Reversal entries are created using the amounts stored on EB.CONTRACT.BALANCES.
• Today‟s accrual amounts are added to the amounts stored EB.CONTRACT.BALANCES.
• The Local amount on EB.CONTRACT.BALANCES is recalculated.
• New accrual entries are raised using the updated amounts on EB.CONTRACT.BALANCES.
• The CRF entry is for the full amount, while the PL entry is less any adjustment PL entries.
• If a second set of entries for the same PL Category is received for the same booking date then the
entries are left as is i.e. no reversal entries raised. EB.CONTRACT.BALANCES will be updated
with the accrual amounts.
Capitalisation
• Reversal entries are created using the amounts stored on EB.CONTRACT.BALANCES.
• New accrual entries are raised, if foreign currency then the local amount is recalculated.
• EB.CONTRACT.BALANCES record.
• Original capitalisation entries are raised.
In order to determine which category codes to use in the ACCR.REV.PARAM you will need to check
the individual parameter records for each application as they are user definable, with the exception of
the accounts.
Account application
There are four CATGEORY codes that are delivered and used by the system for interest, these are;
• 50000 Credit interest

• 50100 Credit interest 2
• 51000 Debit interest
• 51100 Debit interest 2
In addition to the above 4 category codes, it will also be necessary to decide what charges you would
like this functionality to applied to, then check the relevant table behind the charge for the category
code, for example DEBIT.INT.ADDON, GOVERNMENT.MARGIN, INTEREST.STATEMENT
etc. Within the multi set for AC in ACCR.REV.PARAM there should never be any values in the field
LINK.PL.CATEGORY, as any adjustment to a previous capitalisation period is paid direct to
PL/customer.

Reporting
Example ACCR.REV.PARAM for AC application
Setup using a the MG application as an example
MG.PARAMETER US0010001
The category codes that have been used in the ACCR.REV.PARAM record below have been taken
from those input in the MG.PARAMETER record above.

Reporting
Example ACCR.REV.PARAM record
Depending on the setting in the above parameter the system will reverse either or both foreign
currency and local currency accruals. The reversals can be booked at today‟s rate (TODAY) or at the
rate that the accrual was originally booked at (YDAY).
Several applications allow the input of back dated transactions, the interest accrued for these back
dated transactions can be allocated to different PL Category codes, in order to catch all the accrued
interest in the reversal process these category codes must be linked to the main Category code.
In the example above PL.CATEGORY code 51000 is used for interest accruals for Mortgages, but
51020 & 51030 are also used for back dated accruals, so these are linked to the main category code
using the field LINK.PL.CAT. In this example the system is set to reverse both the local and foreign
accruals at the rate that the entry was originally booked under.
Once a contract has been input, during the second close of business the system will start to reverse
the accruals against the contract, recalculate and rebook them.

Reporting
RE.CONSOL.SPEC.ENTRIES 1st COB
RE.CONSOL.SPEC.ENTRY after 2nd COB
Notice that the transaction code for the reversal is different to normal, i.e. ACC for accruals, RAC
reversal of accruals.
Extract from TXN.JOURNAL

Reporting
You can see from the extract of the TXN.JOURNAL that the accrual of CHF 0.14 has been reversed at
the rate it was input with (8.15). The new accrual for 2 nights 0.33 has been accrued at the new rate
(6.379). The EB.CONRACT.BALANCE record has been updated with the accrual and exchange
rate.
EB.CONTRACT.BALANCES record

Reporting
It is recommended that processing for high volume accounts i.e. the consolidation of entries are
enabled for these types of transactions. Please refer to the ACCOUNT User Guide for further details
on this.
The application FOREX is currently not included in this functionality.
Final account entries on Interest and Commission accruals

In some instances it is necessary for a bank to separate the accruals at capitalisation and identify
these differently. Separating these “CASH” entries is done with a „CAS‟ RE.CONSOL.SPEC.ENTRY
record and a unique numerical TRANSACTION code on the CATEG.ENTRY record.
The fields APP.CASH.TXN.CO and CASH.TXN.CODE in the ACCR.REV.PARAM need to be set up.
By using the APP.CASH.TXN.CO field a different transaction code may be used for each application
specified in the ACCR.REV.PARAM. The field CASH.TXN.CODE is a default catch all, any
application where an APP.CASH.TXN.CO will use this TRANSACTION. It is necessary to set up
new TRANSACTION codes as required
Example APP.CASH.TXN.CO in ACCR.REV.PARAM
Example CASH.TXN.CODE in ACCR.REV.PARAM

Reporting
The following screenshots are from entries raised for an LD contract where the interest accrued and
reversed on a daily basis. At capitalisation/maturity the system raised the “CAS”
RE.CONSOL.SPEC.ENTRY. Note if the interest or commission is amortised instead of accrued then
the “CAP” entry is taken upfront. The “CAS” RE.CONSOL.SPEC.ENTRY record is passed on
maturity.
Example ‘CAS’ RE.CONSOL.SPEC.ENTRY records for LD0903300003
In the CATEG.ENTRY file the system has raised the following entries
CATEG.ENTRY list from LD0903300003

Reporting
Example CATEG.ENTRY interest accrual

Reporting
CATEG.ENTRY is reversed
The re-raised using the TRANSACTION 466 specified in the ACCR.REV.PARAM

Reporting
Example CATEG.ENTRY
STMT.ENTRY records passed for the LD
STMT.ENTRY records passed

Reporting
POSITION
The position file is updated ONLY when a specific transaction actually impacts the position of a
particular currency i.e. when, because of that specific transaction, the position of a particular currency
increases or decreases. In other words, if a transaction involves the SAME foreign currency on the
debit and credit side with the same amount on both sides, NO position updates will be raised. There
are no REAL accounting entries behind the POSITION file.
The POSITION file is used extensively by FX, Please refer to the Foreign Exchange User guide for
additional functionality.
Position Accounting
In some instances it is also a requirement that real physical accounting entries are maintained in
addition to the POSITION entries described above. T24 can be parameterised to allow this to run
parallel to Positions. The information produced using position accounts would be more meaningful to
an accountant based role with the bank. Where as POSITION and it‟s enquires are used extensively
by the dealers.
This is made possible by the creation of internal position accounts. The account number format for
these will be determined by the type of environment, single company, multi company or multi-book,
Please refer to the ACCOUNT User guide for additional information, The example format below is
from a multi-book environment and will be CCYCCYCCCCCDDSSBBBB;
• The first CCY is the currency code of the account.

• The 2nd CCY is the other currency of the Position relationship. See below
• CCCCC is a category code in the range 10000 – 19999.
• DD is the DEALER.DESK code.
• SS is sequence number, which will allow the user access to sub account processing.
• BBBB is the branch sub division in a multi book area.
CCYCCY - If the local currency is USD and there is a transaction in EUR. Then the two accounts
need to be updated, the EURUSD and USDEUR.
• The EURUSD account will be the EUR account with the amounts signed as for EUR.
• The USDEUR account will be a local currency account with the opposite sign to that for the
EUR.
When position accounting is to be run it is recommended that only numeric dealer desk id‟s are used,
as the dealer desk id is used in the account number id for the position account.
However, for dealer desks which are non numeric the first two digits of the DEPT.FOR.REVAL are
used for DD part of the account number. For example dealer desk is TR DEPT.FOR.REVAL is 1899.
The system will use 18 for the account number format. Please note that the DEPT.FOR.REVAL is
taken to be a four digit number with leading zeros added if it is less than four digits. For example if the

Reporting
DEPT.FOR.REVAL is 998 then this is expanded to 0998. The system will use 09 for the account
number.
The SS sequence number is used to allow for sub account processing. This uses these two digits in
the range of 01 to 99. Thus for position accounts there is a maximum of 98 sub accounts.
These position accounts use similar functionality to other internal accounts, i.e. statement frequency,
opening balance, closing balance, movements as of any date and between any dates. The accounts
are populated with REAL accounting entries each time a transaction raises a position in a particular
currency. These accounting entries will be included in the STMT.ENTRY file where all T24 account
entries are kept.
Each of these currency position accounts will have a corresponding Account in LOCAL currency which
will contain the local currency counter-value of the foreign currency position.
For example if there is an account GBPUSD1055000010001 local currency is USD there will be a
corresponding USDGBP1055000010001 account.
The benefits of position accounting are;
• On the overall balance sheet i.e. all currencies converted to local currency equivalent, the net
impact of all the position accounts will be exactly „NIL‟ as the net balance of all these position
accounts will be exactly equal to „zero.‟
• The system will be able to balance each currency ledger.
It is necessary to clearly separate the On Balance Sheet position accounts from the Off Balance Sheet
position accounts. This will be managed by the use of CONTINGENT or NON-CONTINGENT
accounts. The Off Balance Sheet position accounts will be furthermore subdivided between the spot,
forward and al forward position accounts.
Once a forward contract enters in the Forward position account, it will stay and remain there until its
final value date even when the forward contracts comes within the Spot period.
Statement of Accounts and History of Position Movements
With positions maintained through „physical‟ accounts, statements can be produced on any frequency
required by the user and any movements will be available as of any date or within any date range with
opening and closing balance
Set up example
In order to set up position accounting, four new CATEGORY codes must be created. One for each of
the following;
• AL (Non contingent)
• ALFWD (Contingent)

Reporting
• FXSP (Contingent)
• FXFWD (Contingent)
Example category for AL
Example Category for ALFWD

Reporting
Example Category for FXSP
Example category for FXFWD
Create four new transaction codes, one for each of the below;
• IN.CR.TXN.CODE
• IN.DR.TXN.CODE
• MAT.CR.TXN.CODE
• MAT.DR.TXN.CODE

Reporting
Transaction record for IN.CR.TXN.CODE
Transaction record for IN.DR.TXN.CODE

Reporting
Transaction code for MAT.CR.TXN.CODE
Transaction code for MAT.DR.TXN.CODE
The category codes created for ALFWD, FXSP and FXFWD need to be made contingent. This is
done by entering the category codes into the ACCOUNT.PARAMETER record, using the fields
CONT.DESC, CONT.CAT.STR and CONT.CAT.END

Reporting
Categories added to the ACCOUNT.PARAMETER
You will need to log out of the system, so that the changes in the ACCOUNT.PARAMETER can
take effect.
Once the above has been completed, the information needs to be entered in the
EB.POSITION.PARAMETER record. The @id to this record is the COMPANY id. In a multi-book
environment it will be necessary to create a separate record for each lead company in existence.
EB.POSITION.PARAMETER record US001001
The use of the field ENT.TYPE in the EB.POSITION.PARAMETER is to allow for the accrual
transactions to be posted to a different dealer desk for Position accounts thus you can enter ACC

Reporting
which is an overall request and then you can enter ACC-MM which means that for MM you wish to do
something different. The field is used in conjunction with fields CHANGE.DD and DEALER.DESK
Example EB.POSITION.PARAMETER with different dealer desk used for MM
Now the structure has been input, the functionality is activated by setting the field value of,
POSITION.ENTRY in CONSOLIDATE.COND ASSET&LIAB record to “ACCOUNT”. Before the
functionality becomes live, it is necessary to exit the system. Upon signing in the functionality will be
active.
If field JOUR.PRINT.EXC.RVN in the EB.POSITION.PARAMETER is set to YES, then the RE

section will not be printed in the TXN.JOURNAL report.
CONSOLIDATE.COND record ASSET&LIAB
Create an internal account for each of the new category codes. The currency of the account must be
the same as the first currency in the @id. For example in internal account USDCHF1055100010001

Reporting
the currency must be USD. The system will then use this as a template to open further accounts as
and when required.
Example internal account for ALFWD category 10551
When opening the first position account for a currency the DDSS part of the account number should
be input as 00 which is for dealer desk 00 followed by sequence 01 as in the above example account
record. This is so that sub accounts can be used and the maximum number of sub accounts allowed
for a position account is 98 meaning that sequence number can have values 01 to 99 with 01 the
master/main and 02 to 99 the sub accounts.
WORKFLOW
The field POSITION.ENTRY has to be set to ACCOUNT in CONSOLDIATE.COND to raise the

position accounting entries. Based on the parameter table EB.POSITION.PARAMETER the
position entries have been raised while updating the POSITION record.
Trade Dated Accounting
For any transaction other than FX and SW application for the input of a forward value dated deal
where there is a cross currency element then for each currency a set of currency positions accounts
will be updated for AL category code.

Reporting
For example;
For a CAD movement, where the local currency is USD. The accounts CADUSD105500001 and
USDCAD105500001 will be updated.
For FX and SW applications where the value dated is forward then the FXSP or FXFWD position
accounts are updated on input. The reverse entries to these position accounts are passed on value
date and also on value date the entries to AL position accounts are passed.
During revaluation, for each FCY position account the balance is converted to local currency and
compared to the balance on the corresponding LOCAL Position account.
Only the AL currency position accounts are re-valued
If there is a difference the following entries will be raised;
• Entry for the revaluation amount to the LCY position account
• Entry to the P/L category code for revaluation for the opposite amount.
• For reporting purpose the CRF base will also be re-valued with the appropriate
RE.CONSOL.SPEC.ENTRY records raised with a Transaction code of RVN.
Value Dated Accounting
For any cross currency transaction there are to be three sets of currency positions accounts to be
updated.
First set to post to the ALFWD accounts today for the position amounts. Thus Value date is equal
today.
Second set to post to the ALFWD accounts on value date for the negated position amounts i.e.
remove amounts from the ALFWD accounts. Value date is to be set with value date from the array.
Third set to post to the AL accounts on value date for the position amounts. Date is to be set with
value date from the array.
REVALUATION.AL
The following processing workflow will apply to revaluation if the option on CONSOLIDATE.COND
is ACCOUNT in the record ASSET&LIAB:
• Revalue the Position record as present, but accounting entries will not be raised.
• Revalue the FCY A/L position account using mid rate and compare this value to that LCY position
account.
• A STMT.ENTRY to the LCY position account for the difference will be raised
• A CATEG.ENTRY for the opposite sign for the P/L for the amount will be raised.
• The following CRF information will be updated in the work file called POS.CRF.WORK and will
be used to raise the relevant RE.CONSOL.SPEC.ENTRY records (CRF entry).
o ID - CONSOL.KEY of the Position account
o ASSET.TYPE
o POSITION.ACCOUNT.NO

Reporting
o ACCOUNT BALANCE
o ACCOUNT BALANCE LCY EQUIVALENT
o REVALUATION DIFFERENCE
• The FCY position accounts total will be checked that it nets to zero for each currency.
• The LCY position accounts total will be checked that it nets to zero, if not a set of adjustment
entries will be raised for the last LCY position account processed.
EOD.RE.REVALUATION
Workflow without position accounting:

• The A/L asset type figures in each CAL record are re-valued and RE.CONSOL.SPEC ENTRY is
raised.
• Totals of A/L asset type balances are written to a work file, and the difference amount between cal
and position is adjusted in the Post routine.
• The forward asset types are re-valued if the setting in CONSOLIDATE.COND says the asset
type should be re-valued.
Workflow with position accounting;

The following will be done only if the CONSOLIDATE.COND is set to ACCOUNT
• If the consol key is (for position account) is already exists in the POS.CRF.WORK file, then this
CRF record for position accounts will not need to be re-valued.
• Instead the movement amount will be calculated from POS.CRF.WORK for the position accounts
for each asset type.
• CRF entry will be raised for the movement amount with different SYSTEM.ID. To achieve this,
Transaction code is to be set to RVN instead of RVL. This is only to happen when the field
POSITION.ENTRY is set to ACCOUNT on the CONSOLIDATE.COND record.
Example
A simple CAD/USD funds transfer value today is input

Reporting
FCY/LCY funds transfer
The ENQ TXN.ENTRY is run for FT0130300SDS010FR1

Reporting
ENQ TXN.ENTRY for FT0130300SDS010FR1
You can see from the above that the system has raised an additional 2 entries to update the new
position accounts.
Normal updated POSITION file for FT0130300SDS010FR1
As the principle of position accounting is to make each transaction net to zero, for both the local
currency and for each foreign currency, the following has happened in the above example
In the FT
DR CAD 1000
CR USD 925.50
Position accounting has raised STMT.ENTRY records
CR CAD 1000
DR USD 925.50
The sum of both entries for each currency is zero.

As a result of this the balance sheet can be produced by currency.

Reporting
However, the POSITION file reflects the original funds transfer.

DR CAD 1000
CR USD 925.50
Below is the ENQ STMT.ENT.BOOK for both position accounts
STMT.ENT.BOOK ac CADUSD105500010001
STMT.ENT.BOOK AC USDCAD1055000100001
After the close of business, the TXN.JOURNAL report for FT has been updated with all 4 entries
generated by the FT.

Reporting
TXN.JOURNAL report
The EB.SYSTEM.SUMMARY has been updated as follows.

Reporting
EB.SYSTEM.SUMMARY
During the close of business the system has re-valued our positions the original USD 925.50 has been
re-valued to 1519.18, the difference being USD 593.53. The system passed the following entries;
1. RE.CONSOL.SPEC.ENTRY USD -593.68 TRANSACTION.CODE RVN RE
2. CATEG.ENTRY USD 593.68 PL 53000 RV
3. RE.CONSOL.SPEC.ENTRY USD 593.68 TRANSACTION.CODE RVN RE
4. STMT.ENTRY USD -593.68 USDCAD1055000100001 RV

Reporting
RE.CONSOL.SPEC.ENTRY’S raised
DR RE.CONSOL.SPEC.ENTRY

Reporting
CATEG.ENTRY raised to PL

Reporting
RE.CONSOL.SPEC.ENTRY to position ac

Reporting
STME.ENTRY raised to position ac
RV section TXNJOURNAL report

Reporting
RE section of TXN.JOURNAL
Note that with position accounting turned on the Transaction code for revaluation is RVN, as displayed
in the above extract from the RE section of the TXN.JOURNAL report.
POSITION file updates
It is recommended that processing for high volume accounts i.e. the consolidation of entries and sub
accounts processing for internal accounts are enabled for these types of transactions. Please refer to
the ACCOUNT User Guide for further details on this.
Bypassing TXN.JOURNAL and EB.JOURNAL.SUMMARY
Within the ACCOUNT.PARAMETER the fields BYPASS.TXN.JOURNAL and

BYPASS.JOURNAL.SUM allow the user to bypass updating the TXN.JOURNAL and
EB.JOURNAL.SUMMARY for high volume sites. A value of Yes will mean the reports will not be
generated in the COB, if a value of No is input then the reports will be generated during the COB.

Reporting
The TXN.JOURNAL is a file which is used to produce the TRANSACTION.JOURNAL report, which
is the list of all entry‟s for the day by application. If after consultation with the banks auditors you have
reached agreement that the TXN.JOURNAL report is not required to be produced from T24 you would
set the field BYPASS.TXN.JOURNAL to Yes.
EB.JOURNAL.SUMMARY is a file which contains the record for each day which gives the totals by
debits and credit that have been passed by each application. You may decide that this is not required
and in which case this is switched of by using the field BYPASS.JOURNAL.SUM.
ACCOUNT.PARAMETER

T24 Finance Reporting

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

T24 Finance Reporting

Hochgeladen von

Copyright:

Verfügbare Formate

TEMENOS T24

Information in this document is subject to change without notice.

Copyright 2005 TEMENOS Holdings NV. All rights reserved.

TEMENOS T24 User Guide Page 2 of 115

FD.FID.ORDER and FD.FIDUCIARY ............................................................................................ 25

TEMENOS T24 User Guide Page 3 of 115

Statement of Accounts and History of Position Movements .......................................................... 95

Main Accounting Files/Entries

TEMENOS T24 User Guide Page 4 of 115

CONSOLIDATION OF SPECIAL ENTRIES

The ability to consolidate

The detail of consolidated entries is available in the tables RE.SPEC.ENTRY.DETAIL and

TEMENOS T24 User Guide Page 5 of 115

Consolidate Asset Liabilities screen

TEMENOS T24 User Guide Page 6 of 115

For example; the income which is earned on current accounts by industry

Consolidate Profit Loss screen

TEMENOS T24 User Guide Page 7 of 115

TEMENOS T24 User Guide Page 8 of 115

Set up of Reporting in T24

The entries would be:

TEMENOS T24 User Guide Page 9 of 115

STMT.ENTRY Credit Nostro Account USD 100,000.00cr

STMT.ENTRY Debit Customer Account USD 100,000.00dr

• After the first few days

CATEG.ENTRY Credit to P/L category Interest earned USD 10.00cr

RE.CONSOL.SPEC.ENTRY Debit to Interest Earned not Collected USD 10.00dr

At application of interest and charges the following entries are raised:

STMT.ENTRY Debit Customer Account USD 100.00dr

RE.CONSOL.SPEC.ENTRY Credit to Interest Earned not Collected USD 100.00cr

Transaction based example

On the transaction date 20 April 1997

RE.CONSOL.SPEC.ENTRY Credit to Contingent, type FORWARDCR for USD 1million cr

On the value date 21 April 1997

RE.CONSOL.SPEC.ENTRY Debit to Contingent, type FORWARDCR for USD 1million dr

TEMENOS T24 User Guide Page 10 of 115

Now the contingent is cleared we raise the liability entry.

STMT.ENTRY Debit client account USD 1million dr

RE.CONSOL.SPEC.ENTRY Credit to liability, type LIVECR for USD 1million cr

During the life of the contract accruals will be created

CATEG.ENTRY Debit to P/L category Interest Paid (52000) USD 1000.00 cr

RE.CONSOL.SPEC.ENTRY Credit to Interest Payable USD 1000.00 dr

STMT.ENTRY Credit client account (prin.) USD 1million cr

STMT.ENTRY Credit client account (int.) USD 4000.00 cr

RE.CONSOL.SPEC.ENTRY Debit to liability, type LIVECR for USD 1million dr

RE.CONSOL.SPEC.ENTRY Debit to liability, type 52000 for USD 4000.00 dr

TEMENOS T24 User Guide Page 11 of 115

Make up of General Ledger consolidation key

Asset and Liability

Four fixed parameters:

TEMENOS T24 User Guide Page 12 of 115

There can be up to twelve variable parameters.

CALL, NOTICE, TERM SETTINGS

If the maturity date field for MM.MONEY.MARKET or LD.LOANS.AND.DEPOSITS is chosen as

TEMENOS T24 User Guide Page 13 of 115

4 System Generated CONSOLIDATE.COND

BALANCE CLASS ASSET.TYPE APPLICATIONS

TEMENOS T24 User Guide Page 14 of 115

TEMENOS T24 User Guide Page 15 of 115

CLASS ASSET.TYPE APPLICATIONS

List of non-contingent ASSET.TYPE by application

TEMENOS T24 User Guide Page 16 of 115

Profit and Loss