Financial Accounting - User Guide

Release R15.000
June 2015

©2015 Temenos Headquarters SA - all rights reserved.

Warning: This document is protected by copyright law and international treaties. Unauthorised reproduction of this document, or any portion of it, may
result in severe and criminal penalties, and will be prosecuted to the maximum extent possible under law.
Table of Contents
Introduction 3
Purpose of this Guide 3
Intended Audience 3
Financial Accounting Overview 4
Financial Accounting Configuration Overview 5
Accrual Reversals 6
Example Set up Using Mortgages 9
Consolidation of Accounting entries 11
Consolidation of Accounting Entries 12
Archiving 13
Consolidation of STMT.ENTRY 14
Consolidated Entry Data 16
Detailed Statement Entries 17
Example Consolidation of STMT.ENTRY 18
STMT.ENTRY.DETAIL.XREF 20
STMT.ENTRY.DETAIL 21
Consolidation of CATEG.ENTRY 23
Consolidation of RE.CONSOL.SPEC.ENTRY's 24
Enforcing Balanced Accounting Entries 25
POSITION File and Position Accounting 28
Position Accounting 29
Example of Position Accounting 31
Position Accounting Set up Example 38
Workflow Explanation 43
Trade Dated Accounting 44
Value Dated Accounting 45
REVALUATION.AL 46
EOD.RE.REVALUATION 47
Exposure Date in STMT.ENTRY for Position Accounts 48
Enquiry POS.STMT.ENT 52
Accounting Systems 54
Trade Dated Accounting 55
Value Dated Accounting 56
Trade Dated GL Accounting 57
Parameter Set-up 58
Recognition of PL and Tax on Trade Date 62
Switching of Accounting System 63
Reporting of Third Party Balance 64
Suspense Processing to Report Under Target Accounts 65

Financial Accounting - User Guide - Release R15.000 - Page 2 of 66

Introduction

Purpose of this Guide

The Banking Framework User Guides provide a profound insight into the developments and changes to the Core Financial Products and Core
Financial Services of T24.

Intended Audience
This Banking Framework User Guides are intended for T24 Customers and Internal Stakeholders to stay informed of the latest developments
and changes on the Licensed Core Financial Products and Core Financial Services of T24, which are constantly revised and upgraded to leverage
new technologies and new technical architectures.

Financial Accounting - User Guide - Release R15.000 - Page 3 of 66

Financial Accounting Overview

The financial accounting and reporting in T24 is very flexible and has a very unique design. It does not have any predefined chart of accounts.
This enables the banks to construct their General Ledger in any manner they desire.

One of the important aspects of T24 is that all dealings with customers are classified either as ‘Accounts’ or ‘Contracts’. There are also Profit
and Loss headings (All these products are Categories in T24).

Accounting entries generated under these three broad headings can be consolidated into user definable AL and PL groupings. The design of
these groupings is driven by the reporting requirements.  For further information on Reporting, refer to the Financial Reporting User guide for
further information on Reporting.

In Accounting, the choice is available to choose Trade dated or value dated accounting and Category codes. In consolidation, key design is done
with reporting requirements in view and is unique to every implementation site.

Financial Accounting - User Guide - Release R15.000 - Page 4 of 66

Financial Accounting Configuration Overview

It is possible to currently configure the following in T24:

l Accrual Reversals
l Consolidation of Accounting Entries
l Enforcing Balanced Accounting Entries
l POSITION

Financial Accounting - User Guide - Release R15.000 - Page 5 of 66

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 rules applied. This file is an INT level file and as such, a record must be created for lead company.

Workflow for accrual reversals: 

The parameter table ACCR.REV.PARAM holds the following information:

l REVERSAL.FCY - Accrual reversal processing for FCY indicator

l REVERSAL.LCY - Accrual reversal processing for LCY indicator
l REVERSAL.RATE - Reversal rate
l PL.CATEGORY - Accrual PL category codes by application
l 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.

The EB.CONTRACT.BALANCE is updated to hold the amounts accrued to date in foreign and local currency, the exchange rate used and book-
ing date.

On input of the transaction, the entries 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

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

l The entries are left as received.

Financial Accounting - User Guide - Release R15.000 - Page 6 of 66

2nd day accrual and up to last day of accrual

l Reversal entries are created using the amounts stored on EB.CONTRACT.BALANCES.

l Today’s accrual amounts are added to the amounts stored on:EB.CONTRACT.BALANCES.
l The Local amount on EB.CONTRACT.BALANCES is recalculated.
l New accrual entries are raised using the updated amounts on EB.CONTRACT.BALANCES.
l The CRF entry is for the full amount, while the PL entry is less than any adjustment PL entries.
l 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 are updated with the accrual amounts.

Capitalisation

l Reversal entries are created using the amounts stored on EB.CONTRACT.BALANCES.

l New accrual entries are raised, if foreign currency then the local amount is recalculated.
l EB.CONTRACT.BALANCES record.
l Original capitalisation entries are raised.

In order to determine the category codes to use in the ACCR.REV.PARAM , you need to check the individual parameter records for each applic-
ation as they are user definable, with the exception of the accounts. 

It is recommended that processing for high volume accounts i.e. the consolidation of entries are enabled for these types of transactions. Refer
to the ACCOUNT User Guide for further details on this.

The application FOREX is currently not included in this functionality.

Account Application

Financial Accounting - User Guide - Release R15.000 - Page 7 of 66

There are four CATEGORY codes that are delivered and used by the system for interest. They are: 

l 50000 — Credit interest

l 50100 — Credit interest 2
l 51000 — Debit interest
l 51100 — Debit interest 2

In addition to the above four category codes, it will also be necessary to decide what charges you like this functionality to be applied to. Then
check the relevant table behind the charge for the category code, for example DEBIT.INT.ADDON , GOVERNMENT.margin ,
INTEREST.STATEMENT and so on. 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 directly to PL/customer.

Financial Accounting - User Guide - Release R15.000 - Page 8 of 66

Example Set up Using Mortgages

Note the CATEGORY codes from the MG.PARAMETER fields:

l THIS.MONTH.ACCR
l PREV.MONTH.ADJUST
l PREV.YEAR.ADJUST

Map the values of these fields into the ACCR.REV.PARAM record as shown:

Financial Accounting - User Guide - Release R15.000 - Page 9 of 66

Depending on the setting in the ACCR.REV.PARAM, the system reverses 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 dif-
ferent PL Category codes, in order to catch all the accrued interest in the reversal process. These category codes must be linked to the main Cat-
egory code. 

In this example, the 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 by setting the field RATE.REVERSAL to YDAY.

Once a contract has been input, during the second close of business, the system starts to reverse the accruals against the contract, recalculate
and rebook them. 

Financial Accounting - User Guide - Release R15.000 - Page 10 of 66

Consolidation of Accounting entries

Financial Accounting - User Guide - Release R15.000 - Page 11 of 66

Consolidation of Accounting Entries
T24 supports the consolidation of accounting entries. This is recommended for high volume low value transaction sites.  The
AC.CONSOLIDATE.COND application is used to facilitate this functionality.   There are default records that can be used or it is possible to cre-
ate your own customised records.  These records can be reversed if consolidation is not required.

The following default records are supplied

CLDEFAULT Consolidating STMT.ENTRY records over a customer account

DEFAULT Consolidating STMT.ENTRY records over Nostro and Internal accounts

PLDEFAULT Consolidating CATEG.ENTRY records for IC only

REDEFAULT Consolidating RE.CONSOL.SPEC.ENTRY records

The number at which consolidation is defaulted can be changed in each record, using the field NO.ENTRIES.START.

The system supports the consolidation of STMT.ENTRY, FORWARD STMT.ENTRY, CATEG.ENTRY, and RE.CONSOL.SPEC.ENTRY
records.

Example customer default record STMT.ENTRY

Example Nostro and Internal ac default for STMT.ENTRY

Financial Accounting - User Guide - Release R15.000 - Page 12 of 66

Archiving
The detailed entries that have been consolidated is archived every six months. The detailed entries are extracted from the consolidated state-
ment entry ID in the ACCT.STMT.PRINT. The STMT.ENTRY.DETAIL record in ARCHIVE and defines the archiving details for the detailed
statement entries.

Financial Accounting - User Guide - Release R15.000 - Page 13 of 66

Consolidation of STMT.ENTRY

A value in the field CONSOLIDATE.ENT in the ACCOUNT application indicates that an account is to raise consolidated statement entries.

This must be a valid record on the AC.CONDSOLIDATE.COND application, either the DEFAULT record or the one created. In this example,
the account is being linked to the AC.CONSOLIDATE.COND record TEST.

In the example, AC.CONSOLIDATE.COND record Test consolidation of STME.ENTRY records is set at 400.

Various conditions can be specified in the AC.CONSOLIDATE.COND record, using the fields explained below:

Financial Accounting - User Guide - Release R15.000 - Page 14 of 66

 l The type of entry that should be consolidated, i.e. forward or live or both may be defined under field ENTRY.TYPE
l The field EXCLUDE.SYS.ID defines the system IDs that should not be consolidated
l The field EXCLUDE.TXN defines the transaction codes that should not be consolidated
l The field EXCL.PROD.CAT defines the Product Categories not to be consolidated for P&L entries
l The field EXCLUDE.RTN may hold a routine that indicates if entry is to be consolidated or not
l Additional fields in the entry to be used in the consolidation may be defined under the field ADD.CONSOL.FLD
l The field NO.ENTRIES.START determines the number of entries that should be raised for the day before consolidating for an account. 

If the field CONSOLIDATE.ENT is not set in the account record for Nostro and Internal accounts, then the system refers to a default record
‘DEFAULT’ in the AC.CONSOLIDATE.COND to determine the rule for the consolidation process.  For customer accounts the system defaults
to the record ‘CLDEFAULT’ if there is no value in CONSOLIDATE.ENT

Note - For account records defined as INTERNAL or NOSTRO Type accounts, a value of NO is also allowed. Once set, this account is then
excluded from any consolidation processing.

Note: The field NO.ENTRIES.START in the ‘DEFAULT’ record is set to 0, this means that consolidation of STMT.ENTRY records starts
immediately for entries raised for the day to both Internal and Nostro accounts.  For customer accounts the ‘NO.ENTRIES.START’ is set to 50
in the CLDEFAULT record.

Financial Accounting - User Guide - Release R15.000 - Page 15 of 66

Consolidated Entry Data
The system raises consolidated statement entries for those accounts specified, each consolidated statement entry is keyed by the following con-
solidated elements of the entry, each element is separated by the “!” delimiter.

l Entry Type      - S, C or F
l Account Number or P&L category
l Currency
l System Id
l Transaction Code
l Value Date
l Exposure Date
l Reversal Marker
l Currency Market
l Suspense Category
l Terminal Number
l Account Officer (P&L only)
l Product Category (P&L only)
l Plus any additional elements defined in AC.CONSOLIDATE.COND

Financial Accounting - User Guide - Release R15.000 - Page 16 of 66

Detailed Statement Entries
The system keeps the link between the main consolidated entry and the detailed entries in STMT.ENTRY.DETAIL.XREF while the detailed
statement entries are held in STMT.ENTRY.DETAIL.

Statement Printing
Although the statement entry is consolidated, the statement contains the contents of detailed entries.

Financial Accounting - User Guide - Release R15.000 - Page 17 of 66

Example Consolidation of STMT.ENTRY

Example of FUNDS.TRANSFER entries consolidated under the same STMT.ENTRY. 

Two funds transfer records are entered with the same DR and CR accounts.

This screen shot shows the consolidated STMT.ENTRY for the above Funds transfers.

Financial Accounting - User Guide - Release R15.000 - Page 18 of 66

The detailed statement entries generated by the two FT entries have been consolidated based on the AC.CONSOLIDATE.COND record.

The AMOUNT.LCY and AMOUNT.FCY from the detailed entries are added to the value in the consolidated entry. A new EXCHANGE.RATE is
calculated based on the value of the local and foreign amounts.

The TRANS.REFERENCE and OUR REFERENCE in the consolidated entry contain the value NET-consolidated ID.

The original SYSTEM.ID is suffixed with the value NET – this allows existing enquiries to drill down to the consolidated entry rather than the
originating application since the contract reference is not present. The STMT.NO field indicates the number of statement entries that have been
consolidated.

Financial Accounting - User Guide - Release R15.000 - Page 19 of 66

STMT.ENTRY.DETAIL.XREF

In order to keep these records as a manageable size in STMT.ENTRY.DETAIL.XREF , for every 200 detailed statement entries under a con-
solidated statement, a new record is created and the sequence number is incremented by one.

The ID to the STMT.ENTRY.DETAIL.XREF is the consolidated statement ID-the sequence number and each record holds up to 200 state-
ment entry IDs.

This is an example STMT.ENTRY.DETAIL.XREF showing the STMT.ENTRY IDS consolidated.

Financial Accounting - User Guide - Release R15.000 - Page 20 of 66

STMT.ENTRY.DETAIL

The STMT.ENTRY.DETAIL application is a replicate of the STMT.ENTRY but which holds only the detailed statement entries that have been
consolidated. The Detail ID is the key to STMT.ENTRY.DETAIL and it holds the details of the statement entry.

The following shows the details of the two entries that have been consolidated:

Detailed entry for the first DETAIL.ID

Financial Accounting - User Guide - Release R15.000 - Page 21 of 66

 Detailed entry for the second DETAIL.ID

 It is possible to turn off the detail level entries using the field NO.DETAIL.APP in the relevant AC.CONSOLIDATE.COND record.  The system
accepts any value from the application EB.SYSTEM.ID.   This functionality can also be turned back on by the removal of values from
NO.DETAIL.APP.  

Financial Accounting - User Guide - Release R15.000 - Page 22 of 66

Consolidation of CATEG.ENTRY

CATEGORY may also indicate that consolidated P&L entries are to be raised if the CONSOLIDATE.ENT field holds a valid record in the
AC.CONSOLIDATE.COND.

The system then raises consolidated category entries for those categories specified; the detail of the underlying entries is maintained in a new
file, CATEG.ENTRY.DETAIL. Details are linked to the consolidated entry by a cross-reference file CATEG.ENTRY.DETAIL.XREF.

The consolidated entries are written to the CATEG.ENTRY file and will be the entries presented in standard account statements and enquiries.

Financial Accounting - User Guide - Release R15.000 - Page 23 of 66

Consolidation of RE.CONSOL.SPEC.ENTRY's

The ability to consolidate special entries (Type R) is defined in the application AC.CONSOLIDATE.COND. Special entries can only be con-
solidated where the consol key, asset type and processing date match.

By default, all non- contingent special entries raised 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 initially applies to the account application.  The details of consolidated entries are available in the new
tables RE.SPEC.ENTRY.DETAIL and RE.SPEC.ENTRY.DETAIL.XREF.

Financial Accounting - User Guide - Release R15.000 - Page 24 of 66

Enforcing Balanced Accounting Entries

In order to maintain the financial integrity of the system, T24 performs a check that the accounting entries raised by an application balance. 

The following applications are an exception to this, for they can genuinely raise one sided entries:

DATA.CAPTURE (DC) There is a mechanism to stop unbalanced batches already in place

FIDUCIARY (FD) Can make two separate calls to accounting

REVALUATION.AL Generates one sided entries during the COB

Set up
In order to use this functionality you need to input a CATEGORY code to be used specifically for balancing entries raised by the system.

Example CATEGORY record

A new TRANSACTION code is required.

Example TRANSACTION record

The Internal account for Local currency needs to be opened for the above CATEGORY code.

Financial Accounting - User Guide - Release R15.000 - Page 25 of 66

 Internal ACCOUNT to be used by the system for balancing entries

The following tables have been released in T24.

EB.FIN.SYSTEM record

Example default EB.FINANCIAL.SYSTEM record

Financial Accounting - User Guide - Release R15.000 - Page 26 of 66

The table EB.FINANCIAL.SYSTEM is used to customise the setting that you require. However, our recommended setting for this in your live
environment is as in the above example. If you require BALANCED.INTRNL to be set to Y, then the field INTRNL.BAL.TYPE becomes man-
datory and must contain the ID of a record from AC.BALANCE.TYPE , which has a REPORTING.TYPE of INTERNAL.

The field SYS.ID.POS.TYPE is validated against the FX.POS.TYPE table so different rules can be specified per Position type if required.”

NB For test environments we recommend that the field AUTO.BL.SYS.ONL be set to N as a minimum.  The system
does not then raise balancing entries and the user is unable to commit the transaction. 

Depending on the setting in EB.FINANCIAL.SYSTEM , the following updated files are updated with the details.

EB.EOD.ERROR EXCEPTION.LOG PROTCOL

Auto Bal Online: Yes

Auto Bal Online:  No

Auto Bal COB:  Yes

Auto Bal COB:  No

Total Net to Zero but not by System ID

Table displaying where error is reported

Financial Accounting - User Guide - Release R15.000 - Page 27 of 66

POSITION File and Position Accounting

The position file is updated ONLY when a specific transaction actually impacts the position of a particular currency i.e. when because of a spe-
cific transaction, the position of a particular currency increases or decreases. In other words, if a transaction involves the SAME foreign cur-
rency on the debit and credit side with the same amount on both sides, NO position updates are raised. There are no REAL accounting entries
behind the POSITION file.  

The POSITION file is used extensively by FX. Refer to the Foreign Exchange User Guide for additional functionality. 

Financial Accounting - User Guide - Release R15.000 - Page 28 of 66

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 is determined by the type of envir-
onment, single company, multi company or multi-book. Refer to the ACCOUNT User guide for additional information. The example format
given below is from a multi-book environment  and will be CCYCCYCCCCCDDSSBBBB. 

l The first CCY is the currency code of the account.

l The 2nd CCY is the other currency of the Position relationship. See below.
l CCCCC is a category code in the range 10000 – 19999.
l DD is the DEALER.DESK code.
l SS is sequence number, which allows the user access to sub account processing.
l 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.

l The EURUSD account is the EUR account with the amounts signed as for EUR.
l The USDEUR account is 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 IDs 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 uses 18 for the account number format. 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
DEPT.FOR.REVAL is 998 then this is expanded to 0998. The system uses 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, move-
ments as of any date and between any dates. The accounts are populated with REAL accounting entries each time a transaction raises a pos-
ition in a particular currency. These accounting entries are included in the STMT.ENTRY file where all T24 account entries are kept.  

Each of these currency position accounts have a corresponding Account in LOCAL currency, which contains the local currency counter-value of
the foreign currency position.

For example if there is an account GBPUSD1055000010001 and local currency is USD, there will be a corresponding
USDGBP1055000010001 account.

The benefits of position accounting are:

l 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.’
l 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 is managed by the
use of CONTINGENT or NON-CONTINGENT accounts. The Off Balance Sheet position accounts is furthermore subdivided between the spot,
forward and all forward position accounts. 

Once a forward contract enters in the Forward position account, it stays and remains there, until its final value date, even when the forward con-
tracts come 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
are available as of any date or within any date range with opening and closing balance.

Refer to the following pages for additional information on Position Accounting:

Financial Accounting - User Guide - Release R15.000 - Page 29 of 66

l Example of Position Accounting
l Position Accounting set up example
l Workflow's
l Exposure date in STMT.ENTRY for Position Accounts

Financial Accounting - User Guide - Release R15.000 - Page 30 of 66

Example of Position Accounting

A simple CAD/USD funds transfer value today is input .

The ENQ TXN.ENTRY is run for FT0130300SDS010FR1 

Financial Accounting - User Guide - Release R15.000 - Page 31 of 66

You can see from the above, that the system has raised two additional entries to update the 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 fol-
lowing has happened in the above example: 

In the FT DR CAD 1000

CR USD 925.50

Position accounting has raised CR CAD 1000

STMT.ENTRY records DR USD 925.50

The sum of both entries for each currency is 0

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

However, the POSITION file reflects the original funds transfer. 

l DR CAD 1000
l CR USD 925.50 

The following is the ENQ STMT.ENT.BOOK for both position accounts. 

Financial Accounting - User Guide - Release R15.000 - Page 32 of 66

After the close of business, the TXN.JOURNAL report for FT has been updated with all four entries generated by the FT. 

TXN.JOURNAL report

The EB.SYSTEM.SUMMARY has been updated as follows. 

Financial Accounting - User Guide - Release R15.000 - Page 33 of 66

 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:

RE.CONSOL.SPEC.ENTRY USD -593.68 TRANSACTION.CODE  RVN RE

CATEG.ENTRY  USD  593.68 PL 53000 RV

RE.CONSOL.SPEC.ENTRY USD  593.68 TRANSACTION.CODE RVN RE

STMT.ENTRY   USD -593.68 USDCAD1055000100001       RV

Financial Accounting - User Guide - Release R15.000 - Page 34 of 66

Financial Accounting - User Guide - Release R15.000 - Page 35 of 66
 RV section TXNJOURNAL report

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 sec-
tion of the TXN.JOURNAL report.

Financial Accounting - User Guide - Release R15.000 - Page 36 of 66

 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. Refer to the ACCOUNT User Guide for further details.

Financial Accounting - User Guide - Release R15.000 - Page 37 of 66

Position Accounting Set up Example

In order to set up position accounting, four new CATEGORY codes must be created. One for each of the following; 

l AL — (Non contingent)
l ALFWD — (Contingent)
l FXSP — (Contingent)
l FXFW— (Contingent)

Create four new transaction codes, one for each of the following:

l IN.CR.TXN.CODE
l IN.DR.TXN.CODE
l MAT.CR.TXN.CODE
l MAT.DR.TXN.CODE

Financial Accounting - User Guide - Release R15.000 - Page 38 of 66

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 field:

l CONT.DESC,
l CONT.CAT.STR
l CONT.CAT.END

You need to log out of the system, so that the changes in the ACCOUNT.PARAMETER can take effect.  

Financial Accounting - User Guide - Release R15.000 - Page 39 of 66

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 is necessary to create a separate record for each lead company in
existence.

Financial Accounting - User Guide - Release R15.000 - Page 40 of 66

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, 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.  In this example,
EB.POSITION.PARAMETER has been created with a different dealer desk to be used for MM transactions.

If the field JOUR.PRINT.EXC.RVN in the EB.POSITION.PARAMETER is set to YES, then the RE section is not printed in the
TXN.JOURNAL report. 

Once the structure is 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 func-
tionality will be active. 

Financial Accounting - User Guide - Release R15.000 - Page 41 of 66

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, the currency must be USD. The system then uses this as a template to open fur-
ther accounts as and when required.

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 para-
meter table EB.POSITION.PARAMETER , the position entries have been raised while updating the POSITION record.

Financial Accounting - User Guide - Release R15.000 - Page 42 of 66

Workflow Explanation

The field POSITION.ENTRY has to be set to ACCOUNT in CONSOLDIATE.COND to raise the position accounting entries. Based on the para-
meter table EB.POSITION.PARAMETER , the position entries have been raised while updating the POSITION record. 

Financial Accounting - User Guide - Release R15.000 - Page 43 of 66

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 is updated for AL category code. 

For example:

For a CAD movement, where the local currency is USD. The accounts CADUSD105500001 and USDCAD105500001 is 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 cor-
responding LOCAL Position account.

Only the AL currency position accounts are re-valued

If there is a difference the following entries are raised:

l Entry for the revaluation amount to the LCY position account

l Entry to the P/L category code for revaluation for the opposite amount.
l For reporting purpose, the CRF base is also re-valued with the appropriate RE.CONSOL.SPEC.ENTRY records raised with a Trans-
action code of RVN.

Financial Accounting - User Guide - Release R15.000 - Page 44 of 66

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 equals to 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.

Financial Accounting - User Guide - Release R15.000 - Page 45 of 66

REVALUATION.AL
The following processing workflow applies to revaluation if the option on CONSOLIDATE.COND is ACCOUNT in the record ASSET&LIAB: 

l Revalue the Position record as present, but accounting entries are not raised.
l Revalue the FCY A/L position account using mid rate and compare this value to that LCY position account.
l A STMT.ENTRY to the LCY position account for the difference is raised
l A CATEG.ENTRY for the opposite sign for the P/L for the amount is raised.
l The following CRF information is updated in the work file called POS.CRF.WORK and is used to raise the relevant
RE.CONSOL.SPEC.ENTRY records (CRF entry).
l ID     - CONSOL.KEY of the  Position account
l ASSET.TYPE
l POSITION.ACCOUNT.NO
l ACCOUNT BALANCE
l ACCOUNT BALANCE LCY EQUIVALENT
l REVALUATION DIFFERENCE
l The FCY position accounts total is checked if it nets to zero for each currency.
l The LCY position accounts total is checked if it nets to zero. If not, a set of adjustment entries is raised for the last LCY position
account processed.

Financial Accounting - User Guide - Release R15.000 - Page 46 of 66

EOD.RE.REVALUATION
Workflow without position accounting:

l The A/L asset type figures in each CAL record are re-valued and RE.CONSOL.SPEC ENTRY is raised.
l 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.
l 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 is done only if the CONSOLIDATE.COND is set to ACCOUNT:

l If the consol key (for position account) already exists in the POS.CRF.WORK file, then this CRF record for position accounts need not
need to be re-valued.
l Instead, the movement amount is calculated from POS.CRF.WORK for the position accounts for each asset type.
l CRF entry is 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.

Financial Accounting - User Guide - Release R15.000 - Page 47 of 66

Exposure Date in STMT.ENTRY for Position Accounts

The exposure date of Position accounting entries is only updated in the field POS.EXP.DATE in either the STMT.ENTRY and
STMT.ENTRY.DETAIL (for consolidated entries) records that have been raised for the position accounts. This field provides a facility to query
on the actual exposure dates.

This functionality can only be used for position accounts.

This exposure date can be used for reporting/enquiries without having to query and access each individual modules/applications in T24 to get
the value date of the exposure.

Note the category codes for position accounts are defined in the EB.POSITION.PARAMETER record. An example record is shown below.

TRADE DATED Accounting example

A forward value dated cross currency funds transfer transaction is entered.

l The system date is 07 MAR 2012

l The FT is value 08MAR2012

Financial Accounting - User Guide - Release R15.000 - Page 48 of 66

The field POS.EXP.DATE has been updated with the booking date of the transaction as this is the date of the position exposure.

Financial Accounting - User Guide - Release R15.000 - Page 49 of 66

VALUE DATED Accounting example

A forward value dated cross currency funds transfer transaction is entered.

l The system date is 07 MAR 2012

l The FT is value 08MAR2012

Financial Accounting - User Guide - Release R15.000 - Page 50 of 66

The field POS.EXP.DATE is updated with the forward value date of the transaction as this is the date of the position exposure.

Financial Accounting - User Guide - Release R15.000 - Page 51 of 66

Enquiry POS.STMT.ENT
The ENQUIRY POS.STMT.ENT shows the currency exposure or movements for a specific currency pair and category code for a range of dates,
which may be either of VALUE.DATE or Position exposure date (POS.EXP.DATE). The selection criteria is:

l Currency Pair (E.g. EURUSD) (Mandatory)

l Category (Mandatory and must be defined EB.POSITION.PARAMETER)

Financial Accounting - User Guide - Release R15.000 - Page 52 of 66

 l Dealer Desk (Optional)
l At least one of the Value.Date or Processing.Date
l Application Drill down (Optional)

Enquiry Lay out design for selection and output :

The following is the Position Entries Detail enquiry for position accounts beginning GBPUSD14016:

The Enquiry drill downs to show either of STMT.ENTRY or Transaction application.

Financial Accounting - User Guide - Release R15.000 - Page 53 of 66

Accounting Systems

Financial Accounting - User Guide - Release R15.000 - Page 54 of 66

Trade Dated Accounting
Under Trade dated accounting, all transactions from the cash based applications such as Data Capture, Funds Transfer, Teller, Securities, Deriv-
atives update the Customer’s balance and Bank’s positions immediately i.e. on the trade date, irrespective of whether they are processed with a
forward value date.

l Account actual balances are updated immediately

l Movements appear on account statements on the trade date
l Movements are reflected in the balance sheet on the trade date
l Foreign currency positions updated by foreign movements are updated with the trade date and are revalued as the current Asset and
Liability Positions

Financial Accounting - User Guide - Release R15.000 - Page 55 of 66

Value Dated Accounting
Value Dated accounting is an option that T24 supports for cash based applications. When selected, transactions that are processed with a for-
ward value date are treated as forward movements until the value date, which means:

l Account actual balances are not updated until the value date
l Movements do not appear on account statements until the value date
l Movements are not reflected in the balance sheet (they are shown as contingent items)
l Foreign currency positions updated by foreign movements are updated with the value date and can be revalued in the style of forex con-
tracts

Financial Accounting - User Guide - Release R15.000 - Page 56 of 66

Trade Dated GL Accounting
Under this new accounting treatment, the customer's balance is updated on the value date. However, the Balance sheet General Ledger is
updated on the trade date but under Payable/Receivable. This new accounting treatment is ‘TDGL’, Trade dated Accounting. Under ‘TDGL’
Trade dated GL accounting, future value dated entries treated as follows:

l Account actual balances are not updated until the value date
l Movements do not appear on account statements until the value date
l Movements are reflected in the balance sheet but under “Payable and Receivable”
l Foreign currency positions updated by foreign movements are updated with the trade date and are revalued as the current Asset and
Liability Positions. P&L movements are not reflected in the balance sheet (they are shown as contingent items).

Financial Accounting - User Guide - Release R15.000 - Page 57 of 66

Parameter Set-up
The accounting treatment may be selected at the following different levels in the ACCOUNT.PARAMETER table:

l For the entire system

l Specific application
l Category range(s) for the entire system
l Category ranges under specific application

System Level

The following screenshot shows the accounting treatment set-up at the system level. The default setting is:

The system level set-up is under the fieldVALUE.DATED.ACCTNG with the following values:

l None is for Trade dated Accounting

l Y is for Value Dated Accounting
l TDGL is for Trade dated GL Accounting

Specific Application

The following shows the accounting set-up at Application level.

The set-up for the application is done using the fields VAL.DATE.SYS.ID and VAL.DATE.BY.SYS.

The following screenshot shows that the default system level set-up is Trade dated Accounting. However, the following cash based applications
follow a different accounting treatment. The following screenshot shows that the default system level set-up is Trade dated Accounting.
However, the following cash based applications follow a different accounting treatment:

l IC (Interest and Charges) follows Trade dated accounting

l SCSP (Sec.Trade) follows Trade dated GL Accounting
l SC (all other Securities application) follows Value dated Accounting

The set-up at application level is done using the fields VAL.DATE.SYS.ID and VAL.DATE.BY.SYS.

Financial Accounting - User Guide - Release R15.000 - Page 58 of 66

Category range at System level

The accounting treatment can be set at Category range; this applies to all future dated entries to the Internal account or P&L from any cash
based application.

Note: that P&L movement under TDGL and Value dated accounting is treated in the same way, i.e. posted to contingent between the
trade date and the value date)

The set-up for a category range is done through VD.CAT.START, VD.CAT.END and VAL.DATE.BY.CAT as shown below:

Category range(s) under specific application:

If the accounting treatment for a Category range has to be different under a specific application, then the set-up has to be done under the applic-
ation as shown below:

Example of Accounting entries:

The following is an example of a future FT transaction under the 3 accounting treatment:

Financial Accounting - User Guide - Release R15.000 - Page 59 of 66

 l Today’s date: 15th January 2014,
l Value date: 20th January 2014
l Debit Account 1234 : USD 10,015
l Credit Account 5678: USD 10,000
l Credit P&L: USD 15

Trade Dated Accounting

All the movements are processed on the 15th Jan

Transaction Target Account Amount (USD) Booking.Date Value.Date Processing.date Stmt/Categ/CRF Asset.Type
Debit 1234 -10,015 15th Jan 20th Jan 15th Jan Stmt.Entry DEBIT
Credit 5678 10,000 15h Jan 20th Jan 15th Jan Stmt.Entry CREDIT
Credit P&L 15 15th Jan 20th Jan 15th Jan Categ.Entry

Value dated Accounting

All the movements are processed on the 20th Jan. Between the 15th and 20th, the movements are booked as Contingent.
On the 20th, the contingent movements are offset:

Transaction Target Amoun- Book- Value.Dat- Pro- Stmt/Categ/CR- Asset.Typ- Notes

Account t ing.Date e cessing.date F e
(USD)

Debit 1234 -10,015 15th Jan 20th Jan 15th Jan CRF CONTDB Contin-
gent

Credit 5678 10,000 15h Jan 20th Jan 15th Jan CRF CONTCR Contin-
gent

Credit Contin- 15 15th Jan 20th Jan 15th Jan Categ.Entry Contin-
gent P&L gent

Credit 1234 10,015 15th Jan 20th Jan 20th Jan CRF CONTDB Contin-
gent

Debit 5678 -10,000 15h Jan 20th Jan 20th Jan CRF CONTCR Contin-
gent

Debit Contin- -15 15th Jan 20th Jan 20th Jan Categ.Entry Contin-
gent P&L gent

Debit 1234 -10,015 15th Jan 20th Jan 20th Jan Stmt.Entry DEBIT

Credit 5678 10,000 15h Jan 20th Jan 20th Jan Stmt.Entry CREDIT

Credit P&L 15 15th Jan 20th Jan 20th Jan Categ.Entry

Trade Dated GL Accounting

The movements are processed on the 20th. Between 15th Jan and 20th Jan, the movements to the accounts are booked under “PAY” and
“RECEIVE” , the P&L are booked as contingent. In order to keep the entries in balance, system automatically generates a balancing entry in the
Suspense account.

Transaction Target Account Amount (USD) Booking Date Value Date Processing Date Stmt/Categ/CRF Asset.Type Notes
Debit 1234 -10,015 15th Jan 20th Jan 15th Jan CRF RECEIVE
Credit 5678 10,000 15h Jan 20th Jan 15th Jan CRF PAY
Credit Contingent P&L 15 15th Jan 20th Jan 15th Jan Categ.Entry Contingent

Financial Accounting - User Guide - Release R15.000 - Page 60 of 66

Credit Suspense 15 15th Jan 20th Jan 15th Jan Stmt.Entry DEBIT System generated

Credit 1234 10,015 15th Jan 20th Jan 20th Jan CRF RECEIVE
Debit 5678 -10,000 15h Jan 20th Jan 20th Jan CRF PAY
Debit Contingent P&L -15 15th Jan 20th Jan 20th Jan Categ.Entry Contingent
Debit Suspense -15 15th Jan 20th Jan 20th Jan Stmt.Entry DEBIT System generated

Debit 1234 USD 10015 15th Jan 20th Jan 20th Jan Stmt.Entry DEBIT
Credit 5678 USD 10000 15h Jan 20th Jan 20th Jan Stmt.Entry CREDIT
Credit P&L USD 15 15th Jan 20th Jan 20th Jan Categ.Entry

Financial Accounting - User Guide - Release R15.000 - Page 61 of 66

Recognition of PL and Tax on Trade Date
Under TDGL set-up, future dated P&L movements are treated the same way as under Value Dated accounting, i.e the movements are booked as
contingent between the trade date and the value date.

Financial Accounting - User Guide - Release R15.000 - Page 62 of 66

Switching of Accounting System
Treatment of cash based transactions can be switched from one system to another. Any combination mentioned below is possible.

Original Accounting Set-up Target Accounting Set-up

Trade dated Value dated
Trade dated Trade dated GL
Value dated Trade dated
Value dated Trade dated GL
Trade dated GL Trade dated
Trade dated GL Value dated

l New Accounting system switch applies to new transactions only.

l The existing cash based transactions with a future date follows the set-up applied when the transaction were raised. The field
“TDGL.DETAILS” in STMT.ENTRY holds the details of the accounting method followed for the transaction.
l Exception to the above is SEC.TRADE – Actual Settlement: If contract input is in existing set-up and authorised in the modified set-
up, then the system follows the modified set-up.

How to - Trade Dated Accounting Systems

Financial Accounting - User Guide - Release R15.000 - Page 63 of 66

Reporting of Third Party Balance

The payable/receivable movements relating to a 3rd party counterparty may be reported under reporting properties of the broker or customer
record. This functionality is available only for SEC.TRADE application.

These include the movements posted under the asset types “PAY”, “RECEIVE”, “PAYSUS” and “RECEIVESUS”.

l The payable/receivable movements relating to a 3rd party broker is raised under the CRF of the customer record of the Broker instead
of the Nostro account.
l Since the third party does not maintain an account, the PR.CUSTOMER.BALANCE table records the static details for the 3rd Party
Customer Payable/Receivable movements.
l The key to the PR.CUSTOMER.BALANCE is:- “PR”- Customer Id – Transaction Id. The following screenshot shows an example of a
PR.CUSTOMER.BALANCE record for Suspense movement from a Sec.Trade to a third party broker:

l When raising the payable/receivable movements under the 3rd party customer for suspense entries and future dated entries under
TDGL to Nostro accounts, the category code ‘22000’ is used for Sec.Trade.

l The financial details relating to payable/receivable movements are recorded in the EB.CONTRACT.BALANCES, which is under the
application PR.CUSTOMER.BALANCE and the CRF key is prefixed with “PR".

l When the trade is settled, the PR.CUSTOMER.BALANCE record is deleted from the system.

See: How to - Trade Dated Accounting Systems

Financial Accounting - User Guide - Release R15.000 - Page 64 of 66

Suspense Processing to Report Under Target Accounts

Suspense processing can be reported as Payable and Receivable Movements using the reporting properties of the Target Accounts instead of
accounting entries to Internal Account, if the target account is passed to the core accounting by the underlying application.

Note: The only application that is supporting this functionality is SEC.TRADE actual settlement.

This functionality is only allowed to Internal Account Category. In order to enable this functionality, the set- up must be done in
ACCOUNT.PARAMETER to indicate that the suspense processing uses the “Payable”/”Receivable” processing. This is defined at different
levels:

l USE.PAY.RECEIVE for System Level

l USE.PAY.REC.SYS for Application level
l USE.PAY.REC.CAT for the category range(s) at the System level

l Suspense processing set-up for a range(s) of categories under an application:

n VD.CAT.SYS.ID, the application
n VD.CAT.SYS.START, the category range start under the application
n VD.CAT.SYS.END, the category end under the application
n VAL.DATE.BY.CAT.SYS, accounting treatment set-up for the range of category
n USE.PAY.RECEIVE.CAT.SYS, the suspense processing set-up for the range of category

When the flag is set, the entry to the Internal Suspense is converted to a Special (CRF) entry under the Asset types “PAYSUS” or
“RECEIVESUS” to the target account passed from the underlying application.

Financial Accounting - User Guide - Release R15.000 - Page 65 of 66

 Note: For Sec.Trade Actual Settlement ,the transaction code REV is used while reversing the trade whereas transaction code NPR is used
while reversing the settlement.

How to - Trade Dated Accounting Systems

Financial Accounting - User Guide - Release R15.000 - Page 66 of 66