T24 - Security Management System

The T24 Security Management System course is designed to teach you the SMS
related topics like Overrides, Dispo and Constraint Processing. Click the tabs on
your left to view the course introduction, objectives and structure.

Course Introduction:

“T24 Security Management System” is a self-paced learning course. This course is

recommended for anyone who wishes to learn about the SMS settings in T24. This
does not need any pre-requisites courses to be attended.

“T24 Security Management System” is an audio-enabled course. Please keep your

speakers switched on to optimize your learning experience. You may click the Notes
button on the left pane to view the course notes.

Course Objectives:

In this course, you will learn the SMS related settings in T24.

After completing this course, you will be able to:

 Explain in detail about various applications involved in SMS

 Explain override and error processing in T24

 Explain the password related settings in T24

 Explain the concept of Dispo and Constraint Processing

Course Structure:

The course is divided into four learning units, each comprising of simple, self-
contained topics. Concepts are explained using simple animations, demos and
practices. At the end of each learning unit, you will be presented with a small quiz.
You will receive immediate feedback on your responses to assess your level of
understanding.

Why does SMS need to be a part of T24?.

Irrespective of where you work today, you have a role to play in your organisation.
You can do certain things, and you are restricted from doing others. In a bank, there
are different job profiles that an employee can have. For example, one can be a
Teller, another can be a Loan Disbursal Manager, or just the housekeeper. Now
should a Teller be able to disburse a loan? Will the housekeeper even be allowed
access to T24?.

The software that the bank uses must be able to control what an employee can and
cannot do once logged on. You are going to learn how this is done in T24.

To login to T24, an employee needs to input a sign on name and password.

T24 validates the data entered and if correct, the employee can access T24. If not,
an error message ‘SECURITY VIOLATION’ is displayed. This is the first encounter that
an employee has with T24 SMS.

Now if T24 has to validate this data entered, it must be stored somewhere in the
first place. These login details are stored in an application called USER. So if you
want to login to T24, you need a user profile, in other words a record created for
you in the USER application.
Both sign on name and password are masked when typed.

Once a user is successfully logged in to T24, SMS checks do not end there. Anything
that a user tries to do is tracked and can proceed only if the user has necessary
permissions. Before the bank allows all users to log on to T24 and start using it, it
must decide what a user has access to within this system. This must be done
because when a user tries to input a record in any application, T24 checks to see if
the user has the permission to do so before allowing to create the record.
Permissions that are checked here include whether the user has access to the Input
function and the application in use. This is where the user will encounter T24 SMS
for the second time. To save the record created an employee will click on the
validate button, before storing the record in the database the T24 application may
reference various static tables of data to complete the record just input. The user
does not need to have implicit permission to do so. This is not part of T24 SMS. If all
goes well and no overrides are encountered, the record is now stored in the
unauthorised file.

Every record in T24 must be authorised. When a user tries to authorise a record,
T24 must check to see if the user has the authorisation permission for the
application. User will not be allowed to authorise the record with insufficient
permissions.

Once the record is authorised, it moves to the authorised file.

Static information could be updated at this stage as well, for example accounting
entries etc. Explicit SMS setting is not required for all this. Close Of Business is the
process which does not need any user intervention and hence no SMS check is
required. The user administering COB must have the relevant SMS setting for COB
related applications. SMS comes into the picture even if you just want to execute an
enquiry in T24. In other words, even though you only want to view data, you must
have necessary permissions to do so.

To create a record in T24, you need to input all the mandatory fields and then get
the record authorised.
Inputter is the person who inputs data into the fields in a record. The user must
have access to the Input function.

Authoriser is the person who checks the record and authorises it. The user must
have access to the Authorise function.

The error message “EB.RTN.SAME.NAME.AUTHORISER/INPUTTER” will be displayed

if the same user tries to input and also authorise the record.

1. Every user who needs login and to perform any action in T24 needs to have a
profile or in other words a record in USER application

2. Rights and privileges for a user are defined in his user profile . For example,
access given only to FUNDS TRANSFER and CUSTOMER application and also restrict
the access only to Input and List functions

3. The user profile is nothing but a record in the USER application

To create a user in T24, you will feed values into some mandatory fields in the USER
application. You will now learn to create a simple USER profile. To create a user
record, type USER and the ID of the record you want to create in the command line.
USER ID and the USER NAME can be the same but the SIGN ON NAME has to be
different from the USER ID.

ID : This is the ID of the record in the USER application which can be any
alphanumeric text.

USER NAME : This field holds the name of the user.

SIGN ON NAME : Name which the user will use to sign on to T24. Has to be different
from the name given in the field User Name.
PASSWORD : The password is also stored as part of the user profile. It is encrypted
at database level and is not displayed as part of the record in the USER application.

CLASSIFICATION : Int (Internal) Indicates whether the User is 'Internal', i.e. an

employee of the bank using T24. Ext (External) is currently not working.

LANGUAGE : You have to set up the language field in the USER application for all the
messages, instructions, help text etc. to be displayed when possible in the language
indicated. The language codes are pre defined in the LANGUAGE table. The model
bank setup of T24 supports four languages namely : ENGLISH, FRENCH, GERMAN,
SPANISH. If the translation is not available for other languages, then ENGLISH will be
defaulted.

T24 allows the user to access multiple companies as it supports MULTI COMPANY
set up.

COMPANY CODE : Specify the companies to which the user has access to. The first
company code specified here will be the default company to which the user will log
on to. The companies defined in a T24 installation can be found in the COMPANY
application. The keyword ALL can be used to access all companies.

If the value in the COMPANY CODE field is specified to ALL and in the next multi-
value set if the company code is specified as EU0010001, then when the user logs
into T24 EU0010001 is the default company into which he will log into.

All users must belong to some department or the other in the Bank. Department
Code will allow an easy identification of any user of the T24 System. Department
Codes must be predefined in the static table DEPT.ACCT.OFFICER in T24. The
purpose of this table is to identify each Department and Account Officer in the bank
by means of a code.

DEPARTMENT CODE : Specifies the department to which the user belongs to.

It is always advisable in any software to change the password at specified frequency

to ensure that there is no fraud happening on using the same password for a long
time. T24 allows the user to specify the password valid date and the frequency of
change.

PASSWORD VALIDITY : Specifies how often and on what date the User must change
his Password. Next Change Date entered, must be greater than today's date
(machine date) and not more than 6 months from today. Date until which the
password is valid followed by the frequency of change.

M0601 : M06 – Every six months after 1st Dec 2008

01 – 1st day of the 7th month after 1st Dec 2008 which is 1st June 2009

The next change date would be 1st Dec 2009 and so on.

There are fields in the USER application that controls the validity of the user profile.
This period is controlled by the following fields.

START DATE PROFILE : Date from which the profile of the user will be active. User
will be able to login into T24 from this date onwards. This field takes machine date
and not T24 date. Date entered in this field should not be less than today’s machine
date.

END DATE PROFILE : Date until which the user profile is active. The user will not be
able to login into T24 after this date.

If a user has access to T24, would the bank want to give him a 24hr access to the
system? No, in most cases the working hours of the bank will determine when a
user must be allowed to use the system. The fields Start Time and End Time control
the time span in a day when the user can log in to T24. Input can be like 0-2359,
0000-2359, 00:00-23:59, etc..

START TIME : Based on the 24 hour clock. (one denotes 0001).

END TIME : Based on the 24 hour clock. Irrespective of the time specified here, if the
user is logged in to the system, he will be allowed to continue accessing T24.
However, once logged off user will not be allowed to login after the time specified in
this field.

These two fields form a multi-value set, enabling multiple periods of time to be
defined per day.

If you want to open a savings account with a Bank, the user of the bank has to first
open a new record for you in the CUSTOMER application. In this process, if the user
who is opening the record for you is called for some other important work, he might
have to leave your record without completing and may walk away. No other user is
allowed to open your record and edit it as it will be locked by the first user. In such a
scenario, how long would you wait for the same user to return back and complete
your record? This is practically not possible. Therefore T24 supports the concept of
Time Out Minutes. The Administrator can specify the number of minutes the user
can be active without actually working on the system. If the time limit lapses for the
first user, he is signed off automatically and another user can complete your record.

TIME OUT MINUTES : Specifies the maximum time in minutes during which the User
may be inactive without being Signed Off automatically. Once this time is reached
the user is not allowed to perform any action. The user has to login again to perform
any action in T24. Maximum of three numeric characters which is 999 minutes.

Most websites that require a user name and password, have a check on the number
of times that a user can incorrectly type in a password. The account is then locked
and the user is forced to reset his password. T24 also supports this functionality
that allows the administrator to define how many unsuccessful sign on attempts a
user can have before locking his account. This helps safe guard the profile against
hackers.

ATTEMPTS : Allows only one numeric character to input and hence the maximum
can only be nine.

A user in T24 may not be allowed to perform same set of actions in different
companies. It is possible to specify application, function and field level restrictions
for a company. These set of permissions can be set up in the Associated multi value
set from COMPANY RESTR to DATA TO. The company to which you want to restrict
the access should have been mentioned in the COMPANY CODE field.
COMPANY RESTR : Contains a valid company code. This company should be defined
as part of the COMPANY CODE field. Permits to input "ALL" to allow the access for all
companies listed in the COMPANY.CODE field.

APPLICATION : Can contain a valid application name or if it contains ALL.PG, the

user will have access to all applications in T24 in to the company entered in the
field COMPANY RESTR.

FUNCTION : List of valid functions that the user can use in the company. Type ALL to
give access to all the functions. When the record is committed it will display the
values A 2 B C D E F H I L P R S V automatically. The Q function does not appear by
default. Q stands for Audit Review.

‘A’ is a function which allows the user to authorise an unauthorised record.

‘2’ is not a function. This is used along with the function ‘A’ to allow the user to
authorise a record which needs a second authoriser. (Record status of a record
which needs a second authorisation would be INA2).

‘C’ is a function which allows the user to copy a record.

‘D’ is a function which allows the user to delete a record which is not yet authorised.
A live record cannot be deleted.

‘E’ function allows the user to list the unauthoirsed records.

‘H’ function is used to move a record from history to live file.

‘I’ function allows the user to input a record in an application.

‘L’ function is used to list live records.

‘P’ is used for printing.

‘R’ is used to reverse a record which is no longer used.

‘S’ allows user to only view the records.

‘V’ is a special function which is supported only by some applications in T24. It is

used to produce some extra information and also performs some extra actions.

All the actions performed by the user may or may not be logged. PROTOCOL is the
file in T24 which stores the logging information of a user. If you want to record all
the actions performed by the user, the following fields have to be set to YES. This
file is updated by T24 and therefore records cannot be edited but only viewed.

SIGN ON OFF LOG : If set to YES, will log sign on and sign off details of the user in
the PROTOCOL file.

SECURITY MGMT L : If set to YES will log details in the PROTOCOL file when the user
accesses the following SMS related files in T24

PASSWORD (Used to change companies)

PASSWORD.RESET

USER

APPLICATION LOG : If set to Yes will log details of applications that the user uses on
to the PROTOCOL file.
FUNCTION ID LOG : If set to Yes will log the functions and the IDs used by the user
on to the PROTOCOL file.

INPUT DAY MONTH : Format for the user to input dates. No matter how the date is
input by the user, T24 will store the data in YYYYMMDD format.

CLEAR.SCREEN : This is a mandatory field. This field is more oriented towards CUI
Interface where once a deal is committed the screen is cleared if set to ‘Y’.

If you set the field CLEAR SCREEN to ‘NO’, even after the transaction is complete
the record is still displayed on the screen.

If you set the field CLEAR SCREEN to ‘YES’, after the transaction is complete the
record gets closed and the screen is cleared.

Create a user profile with sign on name as your name with values into all the
mandatory fields that you have just learnt. Authorize the record and try logging in
to T24 with the new user you have created.

If in a particular company you want the user to have access only to few specified
applications and functions? Can you also restrict the user access based on actual
data contained in the records that the user is going to access. Is this possible in
T24?.

Yes. These specific restrictions can be achieved by using the fields from
COMPANY.RESTR to DATA.TO which form a multi value set. The field
COMPANY.RESTR can have the company code in which the user will be allowed
access only to few applications. The APPLICATION field will hold the name of the
application which can be accessed by the user. The field VERSION can contain a
valid version name of the application specified in the field APPLICATION. The field
FUNCTION will hold the function which the user can access in the particular
application.

FIELD NO : Must enter the actual field number of the required field from the record
in an application.

DATA COMPARISON : Must select the valid operand you would want to use for
comparison. This field can be left without any input also. Different operands
available are
EQ which resembles Equal To. This operand can also be used to specify a range of
values.

GE resembles Greater than or Equal To

GT resembles Greater than

LE resembles Lesser than or Equal To

LT resembles Lesser than

NE resembles Not Equal To

LK resembles Like

UL resembles Unlike

DATA FROM : Must enter a valid value for the field specified in Field No. This may
also contain the starting range.

DATA TO : This field holds the end range of the selection.

For example, with reference to the screen shots:

User can access records in the CUSTOMER application for the company GB0010001
in Input mode only and provided the field SECTOR is EQ to 1000.
User can access records in the ACCOUNT application for the company GB0010004 in
Authorize mode only and provided the field CATEGORY ranges from 1000 to 2000.
The operand to use to select the range is EQ.

The following set of fields gives the information for Audit purposes. All these fields
are updated by the system and hence are no input fields.

ATTEMPTS SINCE: Indicates the number of unsuccessful attempts to SIGN.ON since

the last successful SIGN.ON. It is displayed on the SIGN.ON screen.

DATE.LAST.SIGN.ON : Indicates the date this User last Signed On successfully. It is

displayed on the SIGN.ON Screen.

This date is the actual date (system date and not T24 date) on which the User
Signed On.

TIME.LAST.SIGN.ON : Indicates the time of day at which this User last Signed On
successfully. It is displayed on the SIGN.ON Screen.

PASSW CHANGE DATE: Indicates the date on which the password was changed last
time.

PASSW END DATE: Indicates the end date of the password.

DEACTIVATION.DATE : The date that defines the start of the deactivation period.
This can only be entered or changed by the User via the PASSWORD Application.

REACTIVATION.DATE : The date that defines the end of the deactivation period. This
can only be entered or changed by the User via the PASSWORD Application

CLEAR.SCREEN : This is a mandatory field. This field is more oriented towards CUI
Interface where once a deal is committed the screen is cleared if set to ‘Y’.
The code specified here will be defaulted when a transaction is input in some
applications like FUNDS.TRANSFER, FOREX, etc., by this user. The code to be
specified here should have an entry in DEALER DESK table. The currency position
specified for this dealer will be used for the transaction input by this user.

DEALER.DESK : Identifies the dealer desk position which needs to be updated by the
deal being created. Identifies the dealer desk code applicable to the user. If left
blank T24 will default code ‘00’.

PRINTER For Rpts : Name of a T24 printer to which reports will be spooled and
printed. Printer names specified in other report generation specific applications take
priority over this. Printer is set up using the application PRINTER.ID in T24.

Printer For P Func : Name of a T24 printer to which reports will be spooled and
printed when the user uses function P to print.

GB USER.ADDR : Address that will be printed on the report banner page. Each multi-
value represents one line on the banner. A maximum of three lines can be used. If
left blank then the delivery point from the DEPT.ACCT.OFFICER file is used.

RPT.TO.RECEIVE until Last Spool Time: This is a associated multi value set.

RPT TO RECEIVE : The name of the reports this user is to receive from the over-
night batch run. Must be a valid entry on the REPORT.CONTROL file.

RPT.COPIES : The number of copies this user should receive.

LAST.SPOOL.DATE : The date when the report was last spooled.

LAST.SPOOL.TIME : The time the report was last spooled. Both the LAST SPOOL
DATE and LAST SPOOL TIME are no input fields.
The field ATTRIBUTES on the USER profile can be used to control specific T24
functionality. What you set in this field will decide what the user can or cannot do.
Some of the attributes can only be used if the front end is DESKTOP. The various
options available are explained in detail below.

BRANCH.MANAGER : Only if the client has BRANCH RESILIENCE product, this

attribute can be set for the user. Branch Resilience is a backup system for branches
to be used when communications to the head office system are interrupted. Once
repairs to the communication infrastructure at head office are complete and
reliable, the local administrator will begin the process of switching users, back to
the head office system and ensures that updates to and from the branch and head
office are processed. The branch administrator will use the T24 Toolbox to monitor
and maintain the branch backup database. To use the T24 Toolbox the user must
have the value BRANCH.MANAGER selected in the Attributes field in the USER
application.

COMMAND.LINE : The user is allowed the use of the command line in T24 Browser.

DEVSTUDIO : This is reserved for future use.

ENQUIRY.INDEX and EXPLORER : These options does not have enough information.

LOCK.DEACTIVATION : Prevents user access to the User Deactivation listed in Tools

dropdown list.

LOCK.DESIGNERS : Prevents user access to the listed Designer Tools dropdown list.

LOCK.MISC.ITEMS : Will bring up a Security Violation when the User Abbreviations

Toolbar, Enquiry and Report lists are used.

LOCK.PREFERENCES : If the user is given this option then the ‘User Preferences’
option under the ‘Tools’ menu on the Desktop toolbar will be disabled. This will
prevent the user from gaining access to various Desktop settings including file
locations and some system administrative functions.
NO.ENQUIRY.REPORT : Prevents user exporting Enquiry data from an Enquiry
screen, the icon will be dimmed and non reactive.

REALTIMEENQUIRY : Allows the use of real time enquiries for this user. When signing
onto T24, Browser will create another session for use by the real time enquiries.
This does use an additional database license, but not an additional T24 license. Not
enough information is available for this option as well.

SUPER.USER : The user has access to all of the features detailed above, and for all
future functionality with the exception of REALTIMEENQUIRY.

If you want T24 to perform some extra action during sign off process, you have to
define the following field.

SIGN.OFF.ITEM : The name of any BASIC subroutine can be entered into this field.
During the SIGN OFF process, any subroutines defined in this field will be called with
one parameter. If this parameter returns with the values N, or NO the SIGN OFF
processes will be halted

SIGN ON ITEM and PROCESS DEPT fields are obsolete.

OTH.BOOK.ACCESS and OTH.BOOK.BLOCK fields are used only if T24 Multi Book
product is installed.

A Bank may not want its users to login to the system out of its working hours or
may even limit the user’s access to a specific time period. These settings can be
done using the following Associated multi value set.

ALLOWED DAYS : This field is used to specify the access to T24 in particular days.
You can choose a number from the drop down list which can contain a value from
one to seven where one is Monday and seven is Sunday.

DAY ST TIME : Time is based on 24 hour clock. This field indicates the start time of
the user’s access to T24 in a particular day.
DAY END TIME : This field indicates the end time of the user’s access to T24 in a
particular day.

Example with reference to the screen shot : User CHAITANYA1 can access T24 on
Monday from 10:00 to 15:00 and on Wednesday from 16:00 to 23:00

If the above set of multi value fields is not specified for a particular day, then the
values set in the field Start Time and End Time will be used.

If you want to sign on to T24 as soon as you signed on to your system, how can you
do it? This is possible in T24 in the following fields.

Ldap Id and Ldap Dn : These fields are used to configure the Temenos Connector to
use LDAP as part of the authentication mechanism. It is most widely used as part of
a corporate single sign on mechanism. The advantage of this system is that the T24
username and password are never known outside the T24 server. Ldap Dn becomes
mandatory field once Ldap Id is entered.

Lead Pref : Is an obsolete field in T24.

Irrespective of the date format given in the USER application, T24 stores the date in
a single format across. However you can set the display format of

the date at the user level.

Date Format : Describes the format for displaying the date. Options available are

1 - DDMONTHYEAR

2 - DD/MM/YYYY

3 - YYYY/MM/DD

4 - YYYYMMDD
OFFLINE.SMS.PROFILE field is used only if the BRANCH RESILIENCE product is
installed.

When a record is commited or authorised, T24 updates the following audit fields.
They are no input fields attached to the end of every record across applications.

RECORD STATUS: Holds the status of the record. Possible values are INAU, IHLD,
INAO, etc.,. If the record is in live file, then there is no entry in this field.

CURR NO. : Holds the number of times the record was edited.

INPUTTER : Holds the ID of the user who has inputted the record.

DATE TIME : Holds the date and time when the record was last edited.

AUTHORISER : Holds the ID of the user who has authorized the record.

CO CODE : Defaults based on current company logged into.

DEPT CODE : Defaults to the user’s department code.

The two fields below are populated only when a record is audited (Q function),

AUDITOR CODE : Holds the code of the auditor who has reviewed the record.

AUDIT DATE TIME : Holds the audit date and time.

Another SMS check that you may encounter when you try to login outside the time
slab specified in your user profile (in the fields Day St Time and Day End Time).

T24 passwords must follow the rules discussed below.

1. Password should not have more than two repeated characters

2. Last three passwords cannot be used

3. At first sign on, Temenos T24 will ask for Password to be input twice

4. Password should have a minimum of six and a maximum of sixteen characters

The bank can decide the format of all it’s user’s passwords. Many corporate
organizations follow this standard and thus T24 has options of implementing it.

This field defines the number of different passwords a user must input before being
able to repeat the first one.

1. The default number of passwords is three

2. This field defines the minimum number of characters in the password. The
minimum number of characters for a password is six which will be defaulted.

3. This field defines the number of upper case characters mandatory in the
password.

4. This field defines the number of lower case characters mandatory in the
password

5. This field defines the number of numeric values mandatory in the password

6. This field defines any other special characters or numbers or alphabets that
needs to be part of the password
7. Total of PASS.UPPER.ALPHA, PASS.LOWER.ALPHA, PASS.NUMERIC and
PASS.OTHER should not exceed a maximum of 16 characters and cannot be less
than six characters

SYSTEM PARAMETER FILE is an application where all the configuration details are
stored. This application has only one record SYSTEM. Password characteristics are
controlled in this record in six fields.

Earlier, T24 used a proprietary one way hash algorithm to store passwords. This
hash mechanism is replaced to enable use of standard encryption or hashing
algorithms that are generally accepted in the industry. The system can be setup for
using a locally developed algorithm for password encryption. Now, the client has the
option of by-passing the in-built security for user-login provided by T24. This can be
achieved by attaching the algorithm to the SPF application.

The fields PASSWD.ROLLOVER.FR and ENCRYPTION.ALGORIT are used to enable this

functionality.

ENCRYPTION.ALGORIT : This field is used to attach the JAVA routine written to

encrypt the password. This routine should be pre-defined in EB.API. If this is done,
then the system will skip the normal T24 password encryption mechanism and
follow the user-defined encryption method written in the routine. If this field is left
blank, the normal T24 password encryption will happen.

PASSWD.ROLLOVER.FR : This field is a frequency field containing the password

rollover frequency. This is used when ENCRYPTION.ALGORITHM specified to re-
encrypt the password with new security settings for the specified frequency.

What if you forget your password? What if your account is locked since you
unsuccessfully tried different passwords and exceed the maximum number of
attempts? The application PASSWORD.RESET will allow an administrator to reset
your account. You may not have access to this application.

The ID of a record in PASSWORD.RESET can be any alphanumeric text.

USER PW ATTEMPT: This field specifies the ID of the user whose record has been
locked. When this record is authorised T24 resets the password and enables the
profile at the same time. You must set a new password the next time you log in.

In this demo, you will learn how to reset your user account which has been locked
due to maximum unsuccessful attempts. Note that the field ATTEMPTS in USER
application is set to three.

The password has been reset for locked user account.

If a user crosses the number of password attempts or if the user forgets the
password, these can be set in the following fields:

User Attempt : Every user is given a specific number of password attempts after
which the user account gets locked. Maximum number of password attempts is
specified in the application USER. Such locked user accounts can be unlocked by
giving the user name in the field User Attempt.

What if an administrator wants to activate a profile of an user even before the end
of the deactivation period? You can achieve this by setting the following field.

User Deact Perd : Specifies the ID of the user for whom the security administrator
wants to reactivate the profile before the end of the deactivation period.

User Reset : This field has the ID of a user whose password is to be reset.

User Password : A new password must be set in this associated field. This password
will be set up as expired once you login and thus the user will be forced to change it
on the sign-on.

In this demo, you will learn how T24 throws an error if you do not enter a new
password after its is reset.
The new password holds good for this user ID.

1. Create a user named XXXXX (Where XXXXX is your name)

2. User should have access to any one company only – GB0010001

3. User should be allowed to access only the ACCOUNT and CUSTOMER applications

4. User should be allowed to use only functions. See, List and Print for the
CUSTOMER application. See and Exception listing for the ACCOUNT

application

5. User should be able to use the command line

6. User should be able to use the system only between 10:00 and 06:00 on all days

In this demo, you will learn to create a user record in T24.

The user record has been created.

PROTOCOL file in T24 stores all the details of actions performed by user. This file is
updated by T24 and therefore records cannot be edited but only viewed

 Stores login and logoff details if the field Sign On Off Log is set to YES in USER
application. Unsuccessful attempts to SIGN.ON are always logged, regardless of the
value in this field

 Stores the log details if the user accessed SMS related files if the field Security
Mgmt L is set to YES

 Stores the details if the fields Application Log and Function Id Log are set to YES
PROTOCOL file can be accessed in two ways

 By typing PROTOCOL L in the command line to list all the records in the file

 By running an enquiry ENQ %PROTOCOL, which takes you to the selection box

The contents of a PROTOCOL record include-

@ID : This is the code by which a record is identified. The format being:
YYYYMMDD is the date on which the recorded event (security violation or other
activity) occurred.

NNNNNNNNNN is the sequence number allocated to the event when it was

recorded. The first event recorded each day is 0000000001 and so on.

XX is the sequence number to identify the number of activities per one second.

Process Date : Date on which the activity took place. Displayed in the format which
was selected in the DATE FORMAT field in USER application.

TIME : Identifies the time at which the recorded event took place.

TIME.MSECS : Time when the activity took place denoted in the format
hh:mm:ss:msc

TERMINAL ID : The input is in the format NN XX. The first part of the terminal id
denotes the database user number and the second part denotes operating system
port number.

PHANTOM ID : Denotes the terminal at which the activity took place.

COMPANY ID : Denotes the company in which the activity took place.

USER : Holds the USER.ID of the user who has performed the action.

APPLICATION : Identifies the Application which was being used by the user.

LEVEL.FUNCTION : Identifies whether the Application had been accessed directly or

via '!'. Level 1 indicates that the Application was accessed directly. Level 2 indicates
that the Application was accessed from another Application via '!' mark. ! Works
only on the classic user interface of T24 and is used to drilldown from one
application’s field to another.

ID : Holds the record ID of the application used.

REMARK : This field denotes the activity performed and why the system did not
allow the attempted activity.

1. PROTOCOL file gets accumulated with all the activities performed by the user
and hence this file can grow very huge in size

2. Based on the requirements, this file has to be cleared periodically by attaching a

routine to COB. Based on the requirements, this job could be executed daily,
weekly, monthly or on an adhoc basis

1. What do you do if you have to set the same set of privileges to a group of users?

2. Will you set the privileges in every single user’s user profile?

3. Would you like to create something like a role in Oracle (set of privileges) and
apply it to the relevant users?

There are about 10 account managers in the bank for whom the following privileges
need to be granted

1. Restrict usage to the following functions only : Input, See, Delete and Authorize

2. Application that they can have access to is CUSTOMER provided the field Sector
is 1000. This can be done using an application USER.SMS.GROUP in T24

Open a record in the application USER.SMS.GROUP. ID can be any alphanumeric

text.
GB DESCRIPTION: Mandatory field used to input the narrative of the record ID.

APPLICATION: Multi Value Field which is used to input all the applications which this
user group can have access to.

FUNCTION: This field is used to input all the allowed functions for the group of users.

FIELD NO: Specified when used together with fields Data Comparison, Data From
and Data To. For example, a CUSTOMER record can be accessed only if the field
no.23 in the CUSTOMER record, which happens to be field SECTOR is equal to 1000.

The record ID created in USER.SMS.GROUP has to be attached in the profile of the

user in the field Application as “@ID”. When you attach the SMS group for a
particular user, you cannot specify individual privileges to the user. For example,
you cannot input in the fields Version, Function, Field No., Data Comparison, Data
From and Data To in the USER application.

1. Amount Format field specifies the separators to be used when formatting

amounts

2. Specifies the separators to be used when formatting amounts for Enquiries,

REPGEN’s and screen input/display

3. The millions & thousands separator can be a comma, full stop or apostrophe. The
decimal separator can only be either a comma or full stop

Input is restricted to two character pair. For example ., or ‘, or ‘. The first value is
the separator used for millions and thousands. The second value is the one used as
a decimal separator.

If you only enter the amount without any separators in the field Debit Amount and
validate the record, the separators are defaulted as set in the Amount Format field
in user profile.
After completing this learning unit, you will be able to:

 Describe and differentiate types of overrides in T24

 Explain the applications used for Override Processing

 Setup up multi level restrictions on Override access

An override in T24 is required in a situation where the user needs to be warned that
he has to confirm the action which he would be performing.

For example, A customer wants to withdraw $100 from his savings account which
has a balance of $150. Assume that by T24 norms, the minimum balance in the
savings account should be $100. Now if you input the transaction to debit $100,
when committing it T24 must warn you about the insufficient funds available. T24
cannot stop you, but it can warn you. T24 generates an override to do this. You will
have only two options, to accept it and complete the transaction or reject it and
stop.

When you input a record in any Application in T24 and commit it, it is possible that
you come across two types of messages.

Error Messages: Such type of messages are displayed -

 Due to data not being input in mandatory fields

 Due to incorrect data input

 Due to incorrect relationship between field name and the data that is input

In case of Error Messages, you need to correct the data input in the particular fields
and commit the transaction again. A record is not saved till all errors are corrected.
You cannot even put the record on hold.

Override Messages: These are warning messages, at least most of the time. A user
may accept or reject override. If accepted, T24 saves the record and the override
message is stored as part of it in the field OVERRIDE. If you do not want to accept
the Override, you may either put the record on hold to correct it later or amend the
record and commit it again.

In this demo, you will learn how overrides are handled in Classic mode of T24.

You have learnt how to handle overrides in CUI.

1. ‘Override’ is the name of the field which stores the override messages generated
on committing the record

2. This field is part of almost all the applications in T24

3. It is a no input field and updated by T24

4. Old overrides are overwritten with new ones

1. There can be two different types of override messages. They are Non Blocked
and Blocked overrides

2. A record which generates non blocked overrides can be authorised by any user
in T24
3. A record which generates blocked overrides can be authorised only by users with
appropriate privileges. If you do not have sufficient privileges the record will go to
INAO (Input Not Approved due to Override) status

4. By default, all overrides in T24 are Non Blocked in nature

Where are Override messages stored?

In the OVERRIDE Application. T24 applications generate override messages stored

here.

ID : ID of the record can be any meaningful alphanumeric string

GB Message : This field contains the actual override message that is displayed on
committing the record.

So are override messages only static text messages? What if they need to hold
values from the transaction? In that case, the override message will also contain a
special character ‘&’ and each ‘&’ is then replaced with a value when T24 actually
generates the override.

In the override ACCT.UNAUTH.OD, the first & is used to denote Currency, the second
& to denote Amount and the third & to denote Account number.

Type, Channel and Approve Method : These fields are used only in ARC IB and are
not in the scope of this learning unit. However, to give you little information about
Channel field, based on the type of Channel you select to access T24 (like call
center, branch, internet, etc.,), you can set this Override message to act differently
such as a warning message, an error message, a confirmation message, etc.,.

Now what if we decide to change an override message in T24?

Prev Message : This field in the OVERRIDE application holds the message which was
previously displayed for that particular Override. Only overrides that have changed
over the years will have a value in this field.

Numeric Id : This is a no input field. T24 generates a unique number for every
record in the OVERRIDE application on committing the record. This number is
prefixed with ‘O’ which resembles Override.

App Version, Subroutine and Validation fields is used only in Desktop and does not
have any relevance in Browser.

You will now see an illustration to prove that all overrides in T24 by default are non-
blocked. In other words, no special permission is required to accept it.

You will see how the override ACCT.UNAUTH.OD is generated when you try to
transfer funds from a zero balance account to another account. The screen shot
above is of an account record created exclusively for this illustration. This account
now has a zero balance.

The account created earlier is debited in this FUNDS TRANSFER transaction. The
override message is displayed and you can accept it. The record is now committed.

After the record gets committed, open it in ‘SEE’ mode and check the field
OVERRIDE. You will notice that all the Overrides generated are stored in the record
and are never deleted.

1. Now that you realise what a non-blocked override is, the next thing to learn is
how to block an override

2. Any user can accept blocked overrides when generated and commit the record
thus moving it into INAU status

3. To block an override in other words is to restrict access to particular users when

it comes to authorising a record with this override
4. If the record which has generated blocked overrides is accepted by the user with
appropriate permissions, then the record becomes live or else it will move to INAO
status

To grant the privilege to authorise records that have generated blocked overrides,
you must use the OVERRIDE.CLASS field in the USER application. This field accepts
any string data. The relationship of this data entered here and the override is
clearly visible from the screen shots.

The override record has been modified to include the user class details thus making
it a blocked override.

The user TRAINEE1 can now authorise the record which generated the
ACCT.UNAUTH.OD override.
You will now learn more uses of the fields APPLICATION and CLASS in the OVERRIDE
application.

Application : Specify a * to denote, irrespective of the application from which this

override is generated, only users with Class TRG in their User profile can accept the
override.

You can also specify Class Application wise. For example, if the Override is
generated in the FUNDS.TRANSFER application, then only users with Class TEM in
their User profiles can accept it.

Class : This field specifies a group name. Users belonging to this group alone will be
able to approve this override. Class name can be any descriptive text. Maximum of
four characters only. The group name specified in this field should be attached in
the User profiles in the field ‘Override Class’.

Note that the user Chaitanya is not attached to the class TRG.

Now login as the user Chaitanya and input an FT transaction, accept the overrides
and commit the record. Open it in SEE mode and see the filed Override.3 being
suffixed with *. TRG which implies that only a user belonging to the class TRG can
authorize the record.
Note that the user CHAITANYA1 is not attached to the class TRG.

Now login as CHAITANYA1 and authorize the record. You will see the message ‘YOU
CANNOT APPROVE ALL OVERRIDES’. This is because, the user who tried to authorize
the record is not one among the class specified in OVERRIDE application.

You can see the record status has gone to INAO. Only users with the field Override
class set to ‘TRG’ in the user profile can authorize the record.
Note that the user TRAINEE1 is attached to the class TRG.

Now login as TRAINEE1 and authorize the same FT record. Open the record in SEE
mode and check for the field Override.3 being suffixed with
‘*TRG*TRAINEE1_OFS_BROWSERTC’

TRG is the Class name.

TRAINEE1 resembles the name of the user who has approved the override.

OFS_BROWSERTC denotes that the record has been authorized from Browser
frontend.
Note that the field Authorizer still holds the user CHAITANYA1 and does not change
to TRAINEE1.

Now what if you login as TRAINEE1 who belongs to the class TRG, and input a
FUNDS.TRANSFER transaction and commits it?

Open the record input by TRAINEE1 in SEE mode and look at the value in the
Override field suffixed with *TRG*I which implies that the user belonging to the
class ‘TRG’ has only input the record. In such a case, since TRAINEE1 has only input
the record, any other user who does not belong to the class also can authorize the
record.

Now what if you login as TRAINEE1 who belongs to the class TRG, and input a
FUNDS.TRANSFER transaction and commits it?

Open the record input by TRAINEE1 in SEE mode and look at the value in the
Override field suffixed with *TRG*I which implies that the user belonging to the
class ‘TRG’ has only input the record. In such a case, since TRAINEE1 has only input
the record, any other user who does not belong to the class also can authorize the
record.
1. There might be many such cases in a Bank that a simple Class restrictions may
not be sufficient

2. What if there is a need to restrict access to authorize the record which has a
specific value?

Using an illustration you will learn how to block overrides based on conditions.

1. When an unauthorized overdraft override message is generated in T24, only the

following users should be able to approve the override based on the following
conditions

2. Account Officer classification

Table Row 1 : Only the user ACCTOFF1 can approve the override if the currency is
USD and the overdraft amount is in the range one to 10000
Table Row 2 : Only the user ACCTOFF2 can approve the override if the currency is
USD and the overdraft amount is in the range one to 10000

3. Manager classification

Table Row 1 : Only the user MANAGER1 can approve the override if the currency is
USD and the overdraft amount is in the range 10001 to 50000

Table Row 2 : Only the user MANAGER2 can approve the override if the currency is
USD and the overdraft amount is in the range 10001 to 50000

4. GM classification

Table Row 1 : Only the user GENMGR1 can approve the override if the overdraft
amount is in the range 50001 to 1000000

To set the multiple level restrictions to approve an override you have to use the
application OVERRIDE.CLASS.DETAILS. You can set different groups who can
approve overrides only if the conditions specified in their groups are satisfied.

Data Def : This field refers to the & values in the override message.
ACCT.UNAUTH.OD is the Override in which &1 refers to Currency, &2 refers to
Amount and &3 refers to Account. In this example, conditions are specific to only
Currency and Amount and hence only &1 and &2 are defined.

Classification to Data To field is a multi value set.

Data Def No to Data To field is a sub value set.

Classification : This field holds any user defined text that best defines the group
classification.

Data Def No. : This field indicates which data item, as defined in the field DATA DEF
is to be used for the classification.
The number in this field identifies which multi-value from the field DATA DEF is to be
referred. For example, the number '1' indicates that it is the data item defined by
field DATA DEF.1 and the number '2' indicates that it is the content of field DATA
DEF.2 . You can also define one DATA DEF and use it for all the classifications.

Comparison : It refers the operand to be used. Must select the valid operand you
would want to use for comparison. This field can be left without any input also.
Different operands available are

EQ which resembles Equal To , GE resembles Greater than or Equal To,

GT resembles Greater than, LE resembles Lesser thank or Equal To,

LT resembles Lesser than, NE resembles Not Equal To,

LK resembles Like, NR resembles Out of range,

RG resembles the range, UL resembles Unlike.

Data From : This field holds the value indicated in the field DATA DEF (according to
the field DATA DEF NO), is compared against the value in this field according to the
operator in the field COMPARISON. If the outcome of the comparison is true, the
corresponding CLASSIFICATION group will be allocated the override.

DATA.TO : This field holds the end value of a range.

When the override message is raised from the application FUNDS.TRANSFER, the
conditions specified in the record TRAINING in the OVERRIDE.CLASS.DETAILS
application will be checked and appropriately validated.

If the override message is raised for an amount which is beyond the amount
specified in OVERRIDE.CLASS.DETAILS then only the users who belong to the class
TRG can approve the override.
When the override message is generated for applications other than
FUNDS.TRANSFER (Denoted using a *), users with the field Override Class set to
TRG in their user profiles will be able to approve the override.

Specify the value given in the field CLASSIFICATION (first multi value set) in
OVERRIDE.CLASS.DETAILS and in the field OVERRIDE CLASS in the User profiles of
ACCTOFF1 and ACCTOFF2.

Specify the value given in the field CLASSIFICATION (second multi value set) in
OVERRIDE.CLASS.DETAILS and in the field OVERRIDE CLASS in the User profiles of
MANAGER1 and MANAGER2.

Specify the value given in the field CLASSIFICATION (third multi value set) in
OVERRIDE.CLASS.DETAILS and in the field OVERRIDE CLASS in the User profiles of
GENMGR1.

Login to T24 as any user and input a FT debiting an account with nil balance with
USD 9000.

Login as ACCTOFF1/ACCTOFF2 and authorize the FT.

In this demo, you will learn how to set simple multi level restrictions to approve
overrides in T24.

End of demonstration Multi Level Restriction I.

1. Login as any user and input an FT debiting an account with nil balance with USD
10400

2. Login as ACCTOFF1/ACCTOFF2 and authorize the FT

3. Note that the record status is INAO as ACCTOFF1 does not have the privileges to
authorize transactions with overdraft amount beyond USD 9000
4. Login as MANAGER1 and authorize the record

5. The authorizer field will still show value of ACCTOFF1 only as initially the record
was authorized by the user ACCTOFF1

In this demo, you will learn how the record moves from INAU to INAO to LIVE status
when authorized by users who do not have enough permissions to approve
overrides.

End of demonstration Multi Level Restriction II.

1. Login as any user and input a FT debiting an account with nil balance with USD
51000

2. If ACCTOFF1/ACCTOFF2/MANAGER1/MANAGER2 login and try to authorize the

record, the record will go to INAO status

3. Only user GENMGR1 will be able to approve the override and authorize the
record

In this demo, you will learn how to set multi level restrictions to approve overrides
and try to authorize the record with different users in T24.

End of demonstration Multi Level Restriction III.

1. Login as any user and input an FT debiting an account with nil balance with USD
2000000

2. Note that the Override message is suffixed with *TRG

3. Since the overdraft amount does not fall into any of the ranges defined in the
OVERRIDE.CLASS.DETAILS application, the default class TRG defined for FT has
been used
4. Therefore, this override can be approved only by users who have class set to
TRG in their User profile

In this demo, you will learn how to any T24 user can approve overrides which do not
fall under the amount which are set in OVERRIDE.CLASS.DETAILS.

End of demonstration Multi Level Restriction IV.

T24 always checks for conditions in the order specified in the

OVERRIDE.CLASS.DETAILS record.

For example, If an FT is input and the overdraft amount is 9000, the override
message will always appear as <Override Message>* ACOF.

A user with MGR override class set will not be able to approve the above mentioned
override.

When an override is to be approved T24 checks to see if the override class

mentioned in the user profile matches the override class suffixed with the override
message. If yes, approval is possible, else, record will got to INAO status.

Logically a user with MGR override class set should be able to approve an override
of 9000 USD. To get this done, you need to add ‘ACOF’ apart from the ‘MGR’ class in
the user profile of MANAGER1 and MANAGER2.

1. Amend the ACCT.UNAUTH.OD override to allow only the following users to

approve the override.

2. Create the necessary users

3. Default class to be used is TRG

4. Two trainees to form a group

The first group needs to create a record in OVERRIDE.CLASS.DETAILS application.
The ID should be TEMENOS.TRG. The first group to create the record and add in
details appropriate to GRP1. Once done, GRP2 needs to edit the record
‘TEMENOS.TRG’ and input appropriate details. Then, record passes on to GRP3 and
so on. GRP10 to link the OVERRIDE.CLASS.DETAILS record to OVERRIDE application.
All groups will then have to create new accounts and input FTs debiting the account
and check override processing.

You are now familiar with the concept of override processing in T24. Can an
override message be triggered as an error in T24?

The answer is yes. The field TYPE in OVERRIDE application has the following options
– Error, Auto, Message and Warning. When TYPE is set to Error, the override
message becomes an error. When TYPE is set to Auto, the override message will be
automatically accepted by T24 , the user acceptance is not required.

You will not be allowed to commit the record when an error is raised in T24.

In the previous example, the override was displayed as an error message. Now can
you display customised error messages for overrides?

To display customised error messages for overrides, create a record in EB.ERROR

application. The message is specified in the field ERROR.MSG.

The above created record should be attached to the OVERRIDE application in the
field MESSAGE.

When the override is triggered in a transaction, you could see the customised error
message displayed.
1. Can you simply create a new Override without any hassels?

2. No. OVERRIDE is one of the core applications in T24. It is not possible to simply
create a new record in OVERRIDE application and let it to populate for any records
in any applications. Only TEMENOS DEVELOPMENT can do it. However Client
customization is possible but is not as simple as creating any record in OVERRIDE
application. All the override messages to be generated should be defined in the
OVERRIDE application in T24

For example, When T24 wishes to raise an override stating that a particular account
has been over drawn, it will only say that an override ACCT.UNAUTH.OD needs to be
raised. T24 core then picks up the actual message from the field GB Message in
OVERRIDE application and displays it.
DISPO PROCESSING:

After completing this learning unit, you will be able to:

 Differentiate between blocking and non blocking overrides

 Explain the use of the following applications - OVERRIDE, DISPO.ITEMS,

DISPO.OFFICER

 Create DISPO Officers in T24

 Explain the process DISPO Processing has on overrides

 Explain the use of enquiries DISPO.DETAILS and DISPO.SUMMARY

 Differentiate partial and full DISPO processing

Sometimes when committing a transaction in T24, one or more warning messages

are generated. These messages are called Overrides.

2.There can be two different types of override messages. They are Non Blocking
and Blocking overrides.

2.1 A record which generates non blocking overrides can be authorized by any user
in T24.

2.2 A record which generates blocking overrides can be authorized only by users
with appropriate privileges. If you do not have sufficient privileges the record will go
to INAO (Input Not Approved due to Override) status.
By default, all overrides in T24 are Non Blocking in nature.

Teaching you how to block and un-block overrides are not in the scope of this
learning unit.

How can you make a non-blocking override a blocking override?

You are absolutely right if you think that this can be achieved through
OVERRIDE.CLASS.DETAILS

However, you can also achieve this using DISPO Processing.

What is DISPO Processing? An example will make this clear.

Tom wants to transfer funds from his account to Tim’s account. The T24 way to do
this is by using the application FUNDS.TRANSFER. What if Tom’s account does not
have enough funds? Will the transaction abort? No.

T24 will allow him to perform the transaction by overdrawing his account. The
system will raise an override on committing the transaction, telling the T24 user
that Tom’s account does not have enough funds and is being overdrawn.

What if the bank wants to set a limit on the amount of overdraft that a particular
user can authorize?

Even though this can be achieved using OVERRIDE.CLASS.DETAILS, Dispo

Processing allows you to do this with extra options.

1. The same override can be generated by any application depending upon

business requirement. The Override ACCT.UNAUTH.OD, is raised by many
applications like FUNDS.TRANSFER, LD.LOANS.AND.DEPOSITS etc., the applications
that involve an account in the transactions.
2. To enable DISPO Processing for a particular application set the field APPLICATION
to either the name of the application or ‘*’ (star enables DISPO for all applications
generating the override) and the field DISPO to ‘YES’, in the Override record.

In the override record, you have to specify a valid DISPO Officer ID in the field
DISPO.OFFICER

Now that you have done the base work, will it be feasible if any T24 user can view
the records in DISPO.ITEMS and approve or reject or comment it?

If this is done than the whole idea of DISPO Processing is in vain.

To control such a situation, you need to assign a DISPO Officer to a particular user
in the USER application. The field DISPO.OFFICER is used to assign the Officer. The
input in this field should be a valid officer defined in DISPO.OFFICER application.

DISPO Officer is the one of the important fields in the DISPO.ITEMS application.
DISPO Officer has the right to approve or reject or comment on DISPO Items

A DISPO officer can be created using the DISPO.OFFICER application

ID : The ID of a record can be any alphanumeric input

SHORT.TITLE : This is a multi lingual field which holds the description for the DISPO
officer in different languages

OVERRIDE.ID : This field holds the ID of an override record, for which DISPO
processing has been enabled. This is a multi value field and will hold all the override
IDs that this officer will deal with

DISPO.AMOUNT : This field holds the amount up to which the Officer can comment
on an override
OVERDRAFT.AMT : This field holds the amount up to which the Officer can approve
or reject an override

OVERDRAFT.AMT should be less than or equal to DISPO.AMOUNT

NEXT.DISPO.OFF : This field holds the ID of the next level Officer for financial
Overrides, to whom the DISPO Item would be assigned, in case the current Officer
does not have privileges to approve an override

When a particular DISPO Officer is not available for a specific time, you can set an
alternate DISPO Officer who will be acting like the actual Officer for the specified
time.

ROUTE.TO : This field holds the ID of the DISPO Officer to whom the DISPO items
should be routed for the dates and times specified in the DATE.FROM, DATE.TO,
TIME.FROM, TIME.TO fields. Only if this field contains a valid DISPO Officer ID, the
other fields like DATE.FROM, DATE.TO, TIME.FROM, TIME.TO will be input able.
Otherwise all these fields are no input fields.

DATE.FROM : This field holds the date from which the DISPO Item should be routed
to the alternate DISPO Officer

DATE TO : This field holds the date till which the DISPO Item should be routed to the
alternate DISPO Officer

TIME FROM : This field holds the starting time on a day from which a particular
DISPO item should be routed to the alternate DISPO Officer.

TIME TO : This field holds the ending time on a day till which a particular DISPO item
should be routed to the alternate DISPO Officer.

Whenever an override, that has been subject to DISPO Processing, is accepted in a

transaction, a record is created in an application called DISPO.ITEMS
User inputs an FT transaction. When the user accepts the override message
generated, the transaction is complete and the record goes to INAU status. At this
stage a record in DISPO.ITEMS is created.

A record in DISPO.ITEMS is created internally by the system only when the

transaction generating the override enabled for dispo is committed. The record ID is
TransactionID*CompanyMnemonic.

Example : FT08009436R9*BNK

APPLICATION : This field holds the application name by which the override has been
generated.

OVERRIDE.TEXT : This field holds the actual override message as generated in the
transaction.

CURRENCY : This field holds the currency of the account which has been debited in
the transaction.

AMOUNT : This field holds the total amount overdrawn on the debited account.

ACCOUNT.OFFICER : This field holds the ID of the account officer responsible for the
account.

DATE and TIME : These fields hold the date and the time in which the override was
raised in the transaction .

CUSTOMER.NO : This field holds the ID of the customer who holds the account.

OVERRIDE.ID : This field holds the ID of the override record that is generated.

ACCOUNT.NO : This field holds the debit account number.

In the OVERRIDE record, ACCT.UNAUTH.OD, set the field DISPO.OFFICER to 101.

In the DISPO.OFFICER record with ID 101 set the ROUTE.TO field 102. This means
that the DISPO item should actually be approved or rejected or commented upon by
DISPO officer 101, however since he is not available the item will be assigned to
DISPO Officer 102.

Input an FT transaction, accept the overrides and commit the record. A record in
DISPO.ITEMS should have been created with ID as TransactionID * Company
mnemonic. Now open the record in the DISPO.ITEMS application and check for the
fields DISPO.OFFICER and COMMENT.OFFICER.

You will note that both these fields are defaulted to officer 102 and not 101 though
the amount falls under the officer 101 range. This is because, the ROUTE.TO field in
the officer 101 record is set to officer 102 for 9th Jan from 10AM to 06PM, and the
FT transaction was input and committed within this time frame.

DISPO.ITEMS is the application used to view the DISPO items. However, you can use
an enquiry DISPO.DETAILS to

view the items specific to an officer.

2. Enquiry DISPO.SUMMARY can be used to view all the pending DISPO items for
approval.

3. You have been hearing the words approve, reject, comment a DISPO item all
through the course. Can you simply open a record in DISPO.ITEMS and authorize it?
The system will not allow you to do so. You can perform this action only by using
the enquiry DISPO.SUMMARY or DISPO.DETAILS.

Try authorizing a DISPO item. The system will not allow you to do so. This is
because, the record status is INAU. To authorize a DISPO item, the record should be
in INAO status. Try to authorize the record with a user who is not assigned an
appropriate DISPO officer and then check the record status. The record will now be
in INAO status and is ready for authorizing or rejecting or commenting.

4. Only a user who is assigned a DISPO officer can open the record in see mode.
However, a user who is not assigned any DISPO officer can still list the DISPO items.
Also remember, user with an appropriate DISPO officer can only approve or reject or
comment an item with in his limits defined in the DISPO.OFFICER application.

Whenever an override, that has been subject to DISPO Processing, is accepted in a

transaction, a record is created in an application called DISPO.ITEMS

User inputs an FT transaction. When the user accepts the override message
generated, the transaction is complete and the record goes to INAU status. At this
stage a record in DISPO.ITEMS is created.

Open the item and note that the fields DISPO.OFFICER and COMMENT.OFFICER are
defaulted to officer 100 as the transaction amount falls in his approval limits.
Login as another user who do not have the DISPO officer set and try authorizing the
FT record.

Login as the user who has appropriate DISPO authorities and approve the DISPO
item. Open the enquiry DISPO.DETAILS for the officer – 100. All the DISPO items
available for the officer 100 are displayed. Click on the button ‘ADD COMMENT’ to
either approve or reject or comment the item. After the record is open, approve it
and commit the record. Now you should be able to authorize the corresponding FT
record. The transaction is complete and the FT is authorized by the appropriate
DISPO officer. If the DISPO officer reject the DISPO item, then you will not be able to
authorize the FT transaction.

The record is in live status

Enquiry DISPO.SUMMARY will display all the records enabled for DISPO processing
for all the DISPO officers. If the user has sufficient privileges, he can add the
required comments, approve or reject the DISPO item. All the comments made are
recorded in the DISPO.ITEMS record.

Enquiry DISPO.SUMMARY will display all the records enabled for DISPO processing
for all the DISPO officers. If the user has sufficient privileges, he can add the
required comments, approve or reject the DISPO item. All the comments made are
recorded in the DISPO.ITEMS record.

Officers can either comment or approve or reject based on the amount involved in
the override generated by a transaction.

1. The amount up to which an Officer can comment on an override is given in the

field DISPO.AMOUNT and the amount up to which an Officer can approve or reject
an override is in the field OVERDRAFT.AMOUNT in DISPO.OFFICER application.

2. The officer who can comment an override is the COMMENT.OFFICER and the
officer who can approve or reject the override is the DISPO.OFFICER

With reference to the table in the slide:

Table Column 1 holds the record IDs of DISPO Officers.

Table Column 2 holds the amount up to which an Officer can comment on.

Table Column 3 holds the amount up to which an Officer can approve or reject an
override.

Table Column 4 holds the ID of a DISPO Officer who is the next level financial
approver.

An example will make things clear.

The officer with ID 100 can comment on amounts lesser than or equal to 20,000 and
can approve or reject overrides with overdraft amount lesser than or equal to
10,000. If this DISPO Officer cannot approve or reject overrides, then 101 is the next
Officer who has privileges to approve or reject or comment on the override.

Illustration of the table.

When an FT transaction was input for 20,123, which falls under the officer 101, both
the DISPO.OFFICER and COMMENT.OFFICER fields are populated with the respective
officers in DISPO.ITEMS record. This implies that only officer 101 can comment and
either approve or reject this override.

Now try answering the following questions. The transaction amount is 20,100.

1. No, because the limit to comment on is only 20,000

2. No, because the limit to approve is only 10,000

3. Officer 101 can do it, because his limit to approve/reject is up to 30,000

4. Officer 101 can do it, because his limit to comment on is 40,000

5. Officer 101

6. Officer 102

1. All that you have seen till now is partial DISPO processing. There is much more
added functionality for DISPO processing

2. If DISPO field is set to ‘YES’, then DISPO processing can be enabled with limited
features.

1. To enable an override for full DISPO processing, the field DISPO.ALLOWED in

OVERRIDE application should be set to ‘YES’

2. DISPO.ALLOWED field is set at the core and cannot be modified by any user. The
field DISPO should also be set to ‘YES’

3. If an override is enabled for full DISPO processing, then the fields PRECEDENCE,
TRANSACTION.IND, CONDITION.CON in the OVERRIDE application can be used

4. You can also set the fields DISPO.AMOUNT and OVERDRAFT.AMT in

DISPO.OFFICER application

1. Most of the overrides in T24 are stored in an application called OVERRIDE. The
example which was discussed in the previous slide is a record in the OVERRIDE
application with ID as ACCT.UNAUTH.OD. Based on the special certifications
required for a transaction, DISPO Processing may or may not be allowed for an
Override

2. To enable full DISPO Processing for an Override, the first step is to check if the
field DISPO.ALLOWED is set to ‘YES’ in the OVERRIDE application. This field is set at
the core which means whether or not an Override is allowed for DISPO is decided by
Temenos and T24 user cannot modify this field

Now you should be able to differentiate that if the field DISPO.ALLOWED is set to ‘’
(NULL) and the field DISPO is set to ‘YES’, then the override is enabled for partial
DISPO processing. If the field DISPO.ALLOWED is set to ‘YES’ and the field DISPO is
set to ‘YES’, then the override is enabled for full DISPO processing

In the OVERRIDE application, the fields from APPLICATION to DISPO.OFFICER form a

multi-value set. The fields CLASS and DETAIL are not to be used when an override is
enabled for dispo processing. All the other fields are used for dispo processing.
However, the fields CON.OVERRIDE, TRANSACTION.IND, PRECEDENCE can be used
only if the field DISPO.ALLOWED is set to YES which implies that an override is
enabled for full dispo processing.

1. A DISPO officer can be set in the CUSTOMER, ACCOUNT, POSTING.RESTRICT and

LIMIT applications apart from the OVERRIDE application

2. If the field PRECEDENCE is set for an override, then the officer assigned in that
particular application will take precedence over the officer set in the OVERRIDE
application. When no officer is identified in the application, then the item will be
assigned to the default officer specified in the override record

3. The value in this field must be input in the format ‘APPLICATION NAME>FIELD
NAME FOR OFFICER IN THE APPLICATION’. Example : ACCOUNT>DISPO.OFFICER

To check the functionality of the field PRECEDENCE, set the DISPO.OFFICER field in
ACCOUNT record - 35475 to a valid DISPO officer - 101. Open the record
ACCT.UNAUTH.OD in the OVERRIDE application, and set the field PRECEDENCE as
ACCOUNT>DISPO.OFFICER and in the field DISPO.OFFICER, set an officer other than
the one set in the ACCOUNT record - 100. Attach the officer 101 in the field
DISPO.OFFICER in a user record. Input an FT transaction by debiting the account
35475. Accept the overrides and view the transaction in DISPO.ITEMS. Note that the
fields DISPO.OFFICER and COMMENT.OFFICER are defaulted to 101 as set in the
ACCOUNT record and not to 100 as set in the OVERRIDE record.
1. To disable DISPO processing for a transaction, the field TRANSACTION.IND should
be set to ‘YES’

2. When an accounting entry is raised, a small description is given about the

transaction which is called as ‘NARRATION’. T24 describes different types of
transactions in an application called TRANSACTION. The ID of a record should be
numeric and a maximum of three numbers. For example, record 213 is used for
‘TRANSFER’, which means any transaction which involves transfer of funds between
accounts will have the TRANSACTION ID set to 213

To enable the functionality of the field TRANSACTION.IND, the first step is to open
an FT record, and note the statement number generated for the transaction. Open
the corresponding STMT.ENTRY record and note the value in the field
TRANSACTION.CODE - 213. Now view the record - 213 in the TRANSACTION
application and note the field GB.NARRATIVE. Set the field DISPO.EXEMPT to ‘YES’.
Set the field TRANSACTION.IND in the OVERRIDE application to ‘YES’. Input a new FT
record with TRANSACTION.TYPE ‘AC’ as the transaction code is 213 and commit the
record. Now try to view the same record in DISPO.ITEMS application. There will be
no DISPO item for this transaction as you have exempted transaction type 213 from
DISPO processing.

There will be no dispo item as you have enabled TRANSACTION.IND

In TRANSACTION application set the field DISPO.EXEMPT to ‘YES’

You already know that a particular transaction can be exempted from DISPO
processing in spite of the override being enabled for DISPO.

It is also possible to exempt overrides generated for a particular ACCOUNT or

CUSTOMER record from DISPO processing. This can be done by specifying the field
DISPO.EXEMPT to ‘YES’ in a record in ACCOUNT or CUSTOMER application.

1. You can set conditional DISPO processing using the field CON.OVERRIDE which
will hold the ID of another override
2. For the transaction to be enabled for DISPO processing, the actual override and
the override specified in this field should be generated. If either of the overrides is
generated, the transaction will not be subject to DISPO processing and will not have
an entry in DISPO.ITEMS.

3. Both the overrides generated in the transaction will be subject to DISPO

processing

To understand the functionality of the field CON.OVERRIDE, check out for override
records which have the field DISPO.ALLOWED set to ‘YES’. Open the record
LIMIT.UNAVAIL in the OVERRIDE application and set the field CON.OVERRIDE to
‘EXCESS.ID’ which is ID of an override record and is enabled for full DISPO
processing. Check if both the records LIMIT.UNAVAIL and EXCESS.ID has the field
DISPO.ALLOWED set to ‘YES’ and DISPO.OFFICER set to the same officer – 105. In
the record 105 in DISPO.OFFICER application, add both the override IDs. Input a new
LD record and note that both the overrides are generated. Accept the overrides and
commit the transaction. Now view the record in DISPO.ITEMS. Note that both the
overrides generated are recorded in the DISPO item. Input another LD record and
validate the transaction. Note that only one override has been generated for this
record. Accept the overrides and commit the record. Copy the record ID and check if
there is any DISPO item for this transaction. There will not be any DISPO item as the
LD has generated only one override and therefore the transaction is not enabled for
DISPO processing.

No dispo item will be found which matches the ID, as this record has generated only
one override and is therefore not enabled for dispo processing

1. The field DISPO should be set to ‘YES’ and the field DISPO.ALLOWED to ‘’ (NULL)
to enable partial DISPO processing. The field DISPO.ALLOWED should be set to ‘YES’
along with the field DISPO set to ‘YES’ for full DISPO processing. If an override is
enabled for partial DISPO processing, then the fields PRECEDENCE,
TRANSACTION.IND, CONDITION.CON in the OVERRIDE application cannot be used.
You cannot set the fields DISPO.AMOUNT and OVERDRAFT.AMT in DISPO.OFFICER
application
2. Create Officers using DISPO.OFFICER application

3. Set up the override record with all the required options

4. If the PRECEDENCE field is set, then set the DISPO.OFFICER field in the
appropriate application

5. Assign the DISPO officers to USER profiles

6. Input a new transaction and get the record status to INAO

7. Open the record using the enquiry LLS to reject or approve or to add a comment

1. Create an account

2. Ask the trainer to modify ACCT.UNAUTH.OD in your training area with

precedence set as ACCOUNT>DISPO.OFFICER

3. Create a DISPO.OFFICER record with your name

4. Attach the Officer to a new USER profile

5. Log in as another user, enter an FT

6. Authorize the FT, transaction will go to INAO

7. Log in as the USER to whose account the DISPO.OFFICER is attached

8. Open the Dispo Item assigned to you

9. Authorize the Override

After completing this learning unit, you will be able to:

 Explain the need for constraint processing in T24

 Define the steps in constraint processing

 Create single and cumulative constraints

 Explain the constraint related applications in T24

When you input a record in any Application in T24 and commit it, it is possible that
you come across two types of messages.

Error Messages: Such type of messages are displayed -

Due to data not being input in mandatory fields

Due to incorrect data input

Due to incorrect relationship between field name and the data that is input.

In case of Error Messages, you need to correct the data input in the particular fields
and commit the transaction again.
A record is not saved till all errors are corrected. You cannot even put the record on
hold.

Override Messages: These are warning messages, at least most of the time. User
has only one option to Accept Overrides. If accepted, T24 saves the record and the
override message is stored as part of it in the field OVERRIDE. If you do not want to
accept the Override, you may either put the record on hold to correct it later or
amend the record and commit it again.

1. Constraint means limitation or restriction.

2. From a T24 perspective, constraints are a set of conditions on transactions to

prevent certain activities.

3. One can either enable or disable constraint processing in T24

1. Have you ever been able to generate an override message for a condition of
your choice?

2. Have you ever been able to generate an error message for a condition of your
choice?

At this point you may be thinking if you really can generate errors and overrides for
a condition of your choice in T24.

T24 allows you to create errors and overrides for custom defined conditions using
the Constraint Processing.

Constraint Processing may or may not be enabled at different levels in T24.

Different applications are used to set this at different levels.

The application EB.GC.PARAMETER is used to enable constraint processing for all

the companies in a T24 set up. The ID should be ‘SYSTEM’
The application EB.GC.PARAMETER is used to enable constraint processing for a
specific company. The ID should be <COMPANY CODE>. Eg.: GB0010001

The application EB.GC.ACTIVE is used to enable constraint processing for a specific

application in T24. The ID should be <APPLICATION NAME>. Eg.: FUNDS.TRANSFER

The field COM.PROCESSING in EB.GC.PARAMETER decides whether or not constraint

processing is enabled for a specific company or for all companies. If this field is set
to ‘NO’, then constraint processing is disabled and if set to ‘YES’ constraint
processing is enabled

EB.GC.PARAMETER can have two types of records. The ID of the record may be
‘SYSTEM’ or <COMPANY CODE> Eg.: GB0010001

Values set at the global level (in the SYSTEM record) will be overridden by the
values set in the records created for specific company.

EB.GC.ACTIVE is a FIN type file and the values that are set here are company
specific. This application is used to disable or enable constraint processing for a
particular application. The ID of the record should be <APPLICATION NAME> Eg.
LD.LOANS.AND.DEPOSITS. The field APP.PROCESSING should be set to ‘YES’ to
enable or ‘NO’ to disable constraint processing.

The following is the order of precedence in setting up constraint processing

Application level (EB.GC.ACTIVE)

Company level (EB.GC.PARAMETER record with ID as <COMPANY CODE>)

Global level (EB.GC.PARAMETER record with ID as ‘SYSTEM’)

For example, if the field COM.PROCESSING in the records ‘SYSTEM’ and

‘GB0010001’ is set to ‘NO’ in the EB.GC.PARAMETER table and if the field
APP.PROCESSING in the record LD.LOANS.AND.DEPOSITS is set to ‘YES’ in the
application EB.GC.ACTIVE (in GB0010001 company), then constraint processing is
still enabled for the application LD.LOANS.AND.DEPOSITS.

What could be the next step after constraint processing is enabled for an
application?
The next step to do after an application is enabled for constraint processing is to
define the conditions and the message to be generated. This can be achieved
through EB.GC.CONSTRAINTS. The ID should be the application name. Eg.:
LD.LOANS.AND.DEPOSITS.

TEST.FIELD : This field holds a valid field from the respective application (record ID
is the application name). Eg.:The value in this field is given as INTEREST.RATE which
is a valid field in the application LD.LOANS.AND.DEPOSITS.

T24 performs a validation check on this field. If a wrong field name from the
application is entered, an error is thrown at the user.

OPERAND : This field holds the operand against which a condition is generated.

EVAL.VALUE : This field holds the value or set of values for comparison against
which an override or an error is generated.

SEPERATOR : This field holds the separator to be used for the values mentioned in
the field EVAL.VALUE

ERROR.OVERRIDE : This field holds the type of message to be generated, either an

override or an error.

NARRATIVE : This field holds the actual message to be generated as an error or

override.

FIRST.VALID.DATE : This field holds the value date from which the constraint
becomes active. The date in this field should be current date or a date greater than
today.

You are now ready to generate the override set in constraint processing. Input an
LD record with the value in the field INTEREST.RATE greater than five.

Note that the overrides set by the core and the overrides set in constraint
processing are generated. The value given in the field NARRATIVE in the
LD.LOANS.AND.DEPOSITS record in the EB.GC.CONSTRAINTS application is
generated as the override.

An override ‘Debit Amount is less than 100000’ needs to be generated when a

record in the FUNDS.TRANSFER application is committed with the field
DEBIT.AMOUNT set to a value less than 100000

Now that you know how to generate an override, you can generate an error
message also. Give the conditions for an application (Eg.:FUNDS.TRANSFER) in the
EB.GC.CONSTRAINTS application. To generate a message as an error, set the field
ERROR.OVERRIDE to ‘ERROR’.
Eg.: If a record is committed in the FT application, an error should be generated if
the field TRANSACTION.TYPE is not equal to ‘AC’.

Note that the error message is generated as it is given in the field NARRATIVE in
EB.GC.CONSTRAINTS application when the field TRANSACTION.TYPE is not set to AC
in FUNDS.TRANSFER application.

An error ‘DEBIT CURRENCY SHOULD BE USD’ needs to be generated when a record

in the FUNDS.TRANSFER application is committed if the field DEBIT.CURRENCY has a
value other than USD

What if you wish to generate same errors or overrides for different applications?

Eg.: When contracts are input in applications such as LD, MM and FT, if the loan
amount or deposit amount or debit amount transacted is greater than 200000, an
error message “Amount should be less than 200000’ needs to be generated.

You could simply create three records in EB.GC.ACTIVE and EB.GC.CONSTRAINTS

(one for each application) and set appropriate conditions for the specific fields. But
what if the bank wants several applications to generate same override or error
message? Creating different records in these applications becomes a tedious job. So
then what else can you do to accomplish this setting?

1. T24 has the functionality to generate the same error or override message for
multiple applications, based on specific fields

2. Grouping users is done to set same set of privileges for a group of users in
USER.SMS.GROUP. Grouping applications for constraint processing is similar to that

3. To group applications that generate same error or override, EB.GC.GLOBAL is

used

EB.GC.GLOBAL is the application in which all the application names and their
respective fields for which you wish to check the condition and raise the same
override or error are stored. The ID of the record in EB.GC.GLOBAL can be any user
defined value. Eg.: ABCD, FT, 1235, TOM, etc..
APPLICATION : This is a multi value field which specifies the application name for
which the override or error has to be generated

TARGET.FIELD : The field holds the field name from the application mentioned in the
previous field for which the condition has to be checked.

Both these fields form a associated multi value set.

Even before you set up the record, the applications that are to be used in
EB.GC.GLOBAL should be enabled for constraint processing. As you know by now,
this can be achieved by using the application EB.GC.ACTIVE.

Eg.: The field DEBIT.AMOUNT in FUNDS.TRANSFER, the field AMOUNT in

LD.LOANS.AND.DEPOSITS and the field PRINCIPAL in MM.MONEY.MARKET should
generate an error message if the respective fields holds a value greater than
200000

After the applications are grouped in EB.GC.GLOBAL, a record in

EB.GC.CONSTRAINTS is to be created with ID set to GLOBAL. When there are
multiple applications involved in constraint processing, the ID of the record in
EB.GC.CONSTRAINTS should be ‘GLOBAL’. If only one application is involved, the ID
is the application name itself.

The field TEST.FIELD should contain a field name of the application which is the ID
of the record in EB.GC.CONSTRAINTS application. What will you specify in this field if
the ID is set to ‘GLOBAL’?

In the record ‘GLOBAL’ the field TEST.FIELD should hold the ID of the record (in
which the applications are grouped) from EB.GC.GLOBAL application.

1. An application can have two constraints defined in EB.GC.CONSTRAINTS

If you recollect the example you have seen in the earlier slides, the applications
LD.LOANS.AND.DEPOSITS and FUNDS.TRANSFER have application specific records in
EB.GC.CONSTRAINTS. The conditions were - If interest rate is greater than 5%, an
override to be raised and if TRANSACTION.TYPE is not AC, an error to be raised
respectively.
You have also set the group which is a part of the record ‘GLOBAL’ in
EB.GC.CONSTRAINTS application in which LD, FT and MM are included. The
constraint set for this record is - If amount is greater than 200000, then an override
is to be raised.

2. Will the conditions set in the application specific records as well as the conditions
set in the GLOBAL record be executed for LD and FT? Yes. If both the conditions are
executed, then this is known as Cumulative constraint processing.

3. Can you specify that the conditions specified in application specific records alone
should be executed for LD and FT? Yes. This is known as Single constraint
processing.

The field COM.METHOD in EB.GC.PARAMETER and the field APP.METHOD in

EB.GC.ACTIVE are the ones which decide whether or not a company or an
application is enabled for ‘SINGLE’ or ‘CUMULATIVE’ constraint processing.

A value SINGLE denotes that only one constraint can be applied.

If an application has constraints set up in the application specific record as well as

GLOBAL record in EB.GC.CONSTRAINTS, which constraint takes the precedence if
the field APP.METHOD is set to SINGLE?

The constraint which is defined in the application specific record in

EB.GC.CONSTRAINTS takes the precedence and only the error or override stored in
this record can be generated.

A value CUMULATIVE denotes that multiple constraints can be applied.

If an application has constraints set up in the application specific record as well as

GLOBAL record in EB.GC.CONSTRAINTS, then, both constraints will be generated.

The value set in the field APP.METHOD in EB.GC.ACTIVE takes precedence over the
value set in the field COM.METHOD in EB.GC.PARAMETER application.
Since CUMULATIVE processing is enabled for FT, constraint set for the application as
well as the constraint set in the GLOBAL record are executed.

Since SINGLE processing is enabled for LD, only the constraint set for the
application in the application specific record is executed.

Note that though the value in the amount field is greater than 200000, an error is
not generated but the application specific override is generated as the field
APP.METHOD in LD record in EB.GC.ACTIVE is set to SINGLE and the application
level setting takes the precedence.

Since CUMULATIVE processing is enabled for MM, constraint set in the GLOBAL
record is only executed as it does not have a constraint set in the application
record.

When contracts are input in applications such as LD.LOANS.AND.DEPOSITS,

MM.MONEY.MARKET and FUNDS.TRANSFER, if the fields CURRENCY and
DEBIT.CURRENCY is not equal to USD, an error message ‘CURRENCY SHOULD BE
USD’ is to be generated

1. What if you wish to restrict a user to use only a particular value in a field?

2. An error should be generated if any other value is used by the user.

Eg.: When contracts are input in LD application by the user CHAITANYA, she should
only be allowed to use a value 21051 in CATEGORY field. If she inputs any other
value other than 21051 , an error ‘CATEGORY SHOULD BE 21051’ is to be
generated.

This is almost similar to setting up a group in EB.GC.GLOBAL

To set constraint for a specific user, create a record in EB.GC.GLOBAL with ID as any
text and specify the application and the field name against which condition is to be
set.

Eg.: USER is the record ID in EB.GC.GLOBAL

After creating the record in EB.GC.GLOBAL, a record in EB.GC.CONSTRAINTS is to be
created with ID set to GLOBAL/////<USER NAME>. Use five forward slashes in
between. Eg.: GLOBAL/////CHAITANYA

As you already know, the field TEST.FIELD should hold the ID of the record (created
for user specific constraint) from EB.GC.GLOBAL application. The other fields should
hold the conditions and the error message to be generated.

The actual expansion of the ID in EB.GC.CONSTRAINTS is

GLOBAL/CUSTOMER/PORTFOLIO/ACCOUNT/CURRENCY/USER which means that you
can also set conditions specific to a customer, an account, etc.,.

If you recollect the constraints set for LD.LOANS.AND.DEPOSITS, it has application

specific record, record with ID as GLOBAL and a user specific record in
EB.GC.CONSTRAINTS. The constraints were - If interest rate is greater than 5%, an
override to be raised ; If amount is greater than 200000, an override to be raised
and If category is not equal to 21051, an error message to be raised.

If the field APP.METHOD is set to SINGLE, then the user specific constraints are only
executed. One important thing to note here is the order of precedence for
constraints to be executed. User specific constraint is to be executed first,
application specific constraint is the second and group specific constraint is the last.

Eg.: When a contract is input in LD with AMOUNT set to 300000 CATEGORY set to
21052 and INTEREST.RATE set to 9%, only one error for the field CATEGORY is
raised and no other constraints are executed as LD enables only SINGLE constraint
processing.

As you know if you set the field APP.METHOD in EB.GC.ACTIVE for LD to

CUMULATIVE, all the constraints will be enabled for a contract if it is input by this
specific user. If any other user inputs the contract, then the constraint pertaining to
the field CATEGORY will not be executed as it is user specific.

User should only be allowed to input ‘EUR’ in the field DEBIT.CURRENCY in FT

application. An error ‘CURRENCY MUST BE EUR’ should be generated if any other
currency is used

By now you should know that a record in EB.GC.CONSTRAINTS can be created

specific to a user, an account, a customer, etc.,. Now if there are different specific
conditions defined in this application for a customer, portfolio, account, currency
and user which means different specific records created and if the constraint
processing is set to single for the company, then which constraint will take the
precedence? How will you control the precedence in such a scenario?

To overcome this, there are a set of fields in EB.GC.PARAMETER which controls the
precedence of constraints when single constraint processing is enabled. The fields
PRECEDENCE.USER, PRECEDENCE.CURR, PRECEDENCE.ACCT, PRECEDENCE.PORT
and PRECEDENCE.CUST will define the order of precedence. These fields can hold a
value from one to five. A value of one in any of the fields means that, this specific
constraints takes the precedence over the other.

You can achieve this by creating another record in EB.GC.GLOBAL with the required
applications and relevant fields, attach the ID of this record in the field TEST.FIELD
and specify other conditions in EB.GC.CONSTRAINTS. This is similar to what you
have already done.

However, you can also achieve this by using another application EB.GC.GROUP

Normal way of achieving this grouping is to create a record with the required
applications (which were already a part of the group) in EB.GC.GLOBAL, and attach
it in EB.GC.CONSTRAINTS application with the condition.

Eg.: Create another group for LD and FT with their relevant fields, with ID set to
CURRENCY. Attach this ID in the record GLOBAL in EB.GC.CONSTRAINTS.

To create a subgroup use the application EB.GC.GROUP. ID of the record can be

text.

APPLICATION : This is a multi value field which specifies the list of applications
which are members of this subgroup. Only the applications which have a record in
EB.GC.ACTIVE can be input in this application.

Eg.: Generate an error ’CURRENCY MUST BE USD’ for the applications LD and FT if
the currency used is not equal to USD
As soon as a record is created and authorized in EB.GC.GROUP, the field GROUP is
updated with the ID of the subgroup record in the corresponding record in
EB.GC.ACTIVE application.

GROUP : This is multi value field and is not inputtable by the user. This field holds
the ID of the records in EB.GC.GROUP

Create a record in EB.GC.GLOBAL with the required applications and their relevant
fields. Create a record in EB.GC.CONSTRAINTS whose ID is the same as the ID in
EB.GC.GROUP. Attach the ID of the record created in EB.GC.GLOBAL in the field
TEST.FIELD in EB.GC.CONSTRAINTS application and specify the relevant conditions.

Eg.: The field DEBIT.CURRENCY and CURRENCY in FT and LD should be USD.

Otherwise, an error should be thrown.

Take a look at the records. In both FT and LD the error ‘CURRENCY MUST BE USD’ is
raised.

As the field APP.METHOD is set to SINGLE in EB.GC.ACTIVE, in FT, error is raised for
DEBIT.AMOUNT field as the value in this field should be less than 200000.

For applications MM.MONEY.MARKET and FUNDS.TRANSFER, the fields CURRENCY

and CREDIT.CURRENCY respectively should accept only EUR. Otherwise an error
‘CURRENCY NOT EQUAL TO EUR’ should be raised.

Use EB.GC.GROUP application to achieve this.

For applications MM.MONEY.MARKET and FUNDS.TRANSFER, the fields CURRENCY

and CREDIT.CURRENCY respectively should accept only EUR. Otherwise an error
‘CURRENCY NOT EQUAL TO EUR’ should be raised.

Use EB.GC.GROUP application to achieve this.

How can an override generated by constraint processing be made a blocking

override?

Eg.: When a credit account with currency other than USD is input in a FT
transaction, an override message ‘CREDIT CURRENCY IS NOT USD’ needs to be
raised. This override should only be approved by user belonging to a particular
class.
The fields COM.DIAG and APP.DIAG can hold the value ‘YES’ or ‘NO’. A value ‘YES‘
denotes that diagnostics recording is enabled. This field decides whether or not the
constraints are to be logged.

The field COM.DIAG.LIFE holds the number of days after which the logs should be
deleted.

The settings in the field APP.DIAG in EB.GC.ACTIVE takes the precedence over the
settings in the field COM.DIAG in EB.GC.PARAMETER application.

When the condition set for a particular field is breached or violated, the constraint is
triggered. At this point, a log will be created in the file EB.GC.DIAGNOSTIC. This is a
live file and updated by the system.

All the details of the constraint are stored in this record. The field DATE holds the
date on which the log was entered and the field DEATH.DATE will hold a date which
is equivalent to the date of the log + the number of days given in the field
COM.DIAG.LIFE.

Eg.: If the log date is 7th August 2008 and the COM.DIAG.LIFE will hold a value of 8,
then the death date will be 19th August 2008.

1. Who will actually delete the logs from the file EB.GC.DIAGNOSTIC and when?

A COB job named EB.GC.DIAGNOSTIC.COB deletes the log if the value in the field
DEATH.DATE is less than today

2. EB.GC.DIAGNOSTIC.COB checks the field DEATH.DATE for all the records and if
this is less than today, then the log record is deleted from the file.

3. The job EB.GC.DIAGNOSTIC.COB is a ‘D’ frequency job and is run daily.

Eg.: If the log date is 7th August 2008 and the COM.DIAG.LIFE will hold a value of 8,
then the death date will be 19th August 2008. This record will be deleted from the
file during COB on 20th August 2008. Note that only working days are calculated to
arrive at death date.

1. T24 allows you to create override and error messages using the ‘Constraint
Processing’

2. EB.GC.PARAMETER is used to enable constraint processing at company level or

SYSTEM level

3. EB.GC.ACTIVE is used to enable constraint processing at application level

4. EB.GC.CONSTRAINTS application decides whether an error or override message

has to be generated

5. EB.GC.GLOBAL allows constraints to be established at Global level across

multiple applications

6. EB.GC.GROUP enables creation of sub groups