T24 UTILITIES

INTRODUCTION
The previous generation of banking systems had fixed screen, menu and report designs that
required considerable expense for even simple changes. However, when T24 was designed,
great emphasis was placed on providing the client with the ability to customise their system as
required. To this means the utilities were developed and are delivered as standard. All the
utilities are documented in detail in the T24 System Administration and User Guides, as well
as in the on-line helptext. In this section, these applications are highlighted to show the scope
of customisation that can be achieved by using the standard utilities.

Application Menus

The main method for displaying available menus, the Menu Explorer, can be incorporated as
part of a composite screen.

Again, the text that appears represents HELPTEXT.MENU records and instructions within
them, so that when the text (in the example below, ‘Trade finance dept’) is clicked, it displays
the contents of the HELPTEXT.MENU that underlies it. When text represents an enquiry,
version or application, this is run upon being double-clicked.
 Figure 2 – Application Menus

It is possible to link a single menu to a user, so that as soon as a user enters the system that
menu is displayed. This is done through the INIT.APPLICATION field on the USER profile.
If a user has an INIT.APPLICATION set, he will not be able to use any applications that lie
outside of that menu. If no menu is linked to the USER profile, all HELPTEXT.MENU
records which are not accessed through another HELPTEXT.MENU can be accessed as drop-
down menus from the File menu.

The HELPTEXT.MAINMENU file may still be used as before, and is still supported,
whereby a single menu contains only other menus and may be entered in the
INIT.APPLICATION field. However, use of HELPTEXT.MENU for this role is now the more
flexible and preferred choice.

The Menu Structure

The HELPTEXT.MENU record can be used to launch applications, versions of applications,

enquiries and even other menus. In effect, selecting an option from a menu has the same
effect as entering it in the command line. Anything that can be entered in the command line
can be entered on the APPLICATION field of the HELPTEXT.MENU.

See the Application Menu chapter in the System Administration Guide for more information.
VERSION

VERSION is a standard T24 application allowing the creation of customised screens for input,
printing, display etc.

It will be rare for any client to use the standard (main) screen input for all T24 applications. In
fact we supply many useful Versions covering the majority of T24; we encourage clients to
copy and amend them to suit local requirements.

The creation of versions can be divided into three main categories; input of the header or title;
the fields required for input or display; and the defaults to be pre-filled when using that
specific version.

All T24 trading applications are capable of supporting more than one product, e.g.
LD.LOANS.AND.DEPOSITS supports loans, deposits, commitments etc. and it also supports a
wide variation of options e.g. discounts, maturity, liquidation, rollovers, schedules to
highlight a few. In order to support this functionality, the main LD contract has over one
hundred fields. Although all the fields are necessary, only a few are needed for the input or
maintenance of a particular contract type. VERSION allows you to create screens that reflect
each contract type, presenting only the necessary fields and defaulting data into other fields.

Each VERSION you define is referenced by the name of the application and the name of the
version separated by a “,”. For example, a LD version for inputting call deposits could have an
id of LD.LOANS.AND.DEPOSITS, CALLDEP. To ‘run’ the VERSION simply enters the
application name with the version reference.

SMS control can be defined specifically for the VERSION by entering the name of the
VERSION, with the comma, in USER in the field VERSION. Subsequently you can restrict
access to the contract types as well as the application itself.

The creation of VERSION records can be divided into three main categories; input of the
header or title; the fields required for input or display; and the defaults to be pre-filled when
using that specific VERSION.

Screen Builder

The Screen Builder, in ToolBox allows you to create screens using a wizard. The wizard
provides predefined layouts.

Defaults

The last section of the Version record allows the user to pre-fill values at input using that
Version, make fields non-input; no change; mandatory. Version also allows the usage of sub-
routines (small programs written locally) that can add local validation to the application. An
example of this could be a check that ensures that the Passport Expiry Date (a local reference)
was greater than the system date. More information on the use of sub-routines can be found in
the Application Program Interfaces section of this manual.

For more information on the creation and use of versions, see the Version chapter in the
System Administration guide for more information.
ENQUIRY

The ENQUIRY allows you to construct views of the T24 database by enabling you (with
given syntax) to construct statements that extract the database records according to specified
criteria. These statements are extremely versatile, and can be used to access and manipulate
data, or can be expanded and combined to create a flexible and powerful data presentation in
form of either a screen or report.

In addition to presenting simple or complex data from a single or multiple tables, you can:

• Drilldown enquiries (using an item from a summary ENQUIRY as a selection for a

detail one)
• Export ENQUIRY result into a Windows application such as an Excel worksheet
• Launch an ENQUIRY as context sensitive while working with a related application

Creating an Enquiry

ToolBox provides a wizard for create simple enquiries, much like the Screen Builder.
Enquiries can later be customized using the ENQUIRY application.

Figure 4 – Example of a simple Enquiry

ABBREVIATION

Abbreviations, or shortcuts can be created to run any T24 application, enquiry, version, etc.

For example, abbreviations could be set up as follows:

Abbreviation Full command

LD LD.LOANS.AND.DEPOSITS
LDSP LD.LOANS.AND.DEPOSITS,SPECIAL
SPECIAL LD,SPECIAL I

NOTE: In the example SPECIAL, the abbreviation of LD has been used in the command.

Abbreviations can be used in menus where the text would exceed the space available for the
command.

All abbreviations can be used by all users, subject to the SMS restrictions for each user. In
addition, user abbreviations can be created for use by only the assigned user.

Local Reference

Local reference gives you the ability to add your own fields to a file. For example, you may
wish to record a customer’s passport number on the CUSTOMER file. This can be achieved
by use of the LOCAL.TABLE and LOCAL.REF.TABLE applications.

Most T24 applications have a field called LOCAL.REF; this field can be replaced by up to 999
user-defined fields.

Any new field that you want to add to a file as a local reference field must be entered on
LOCAL.TABLE. Here you specify the name of the field, the type, minimum and maximum
length, allowed values (vetting table) or replacement files to use such as CUSTOMER.

The example below shows a simple field called PASSPORT.NBR being added.
 Figure 5 – Local Table Input Record

The field now needs to be linked to an application. To do this, a record must be added to
LOCAL.REF.TABLE, with the id of the record set to the application name. Up to 999 fields
can be linked to an application; fields can be added as simple fields or associated with other
fields.

In the example below, the local reference field for passport number is being linked to the
CUSTOMER file.
 Figure 6 – Local Ref Table Input Record

Note that once a field has been linked to an application (updated on LOCAL.REF.TABLE), it
cannot be removed.

See the Local Reference chapter in the System Administration Guide for more detailed
information.

Override

Another aspect of the control of T24 concerns the override messages given at input time to the
user. In the plainest form the inputter confirms the override, although this option is not
recommended.

T24 allows the client to specify classes of authorisation for overrides on the user profile.
According to these classes either one of the inputters (or authorisers) must have the authority
to approve the override before the record can be completed.

A further option is provided where local development can be used to customise the validation
of the override messages by use of user defined sub-routines (see the Application Program
Interface section in this manual).

NOTE:

If the inputter has the class on their user profile, the override is flagged as approved at input
stage. Another user without that class can then authorise the record. If neither the inputter nor
first authoriser has the override class, a user who does have the correct user profile must also
authorise the record.

This is reflected in the record status, a status of INAO means the record is partially authorised
but awaits a user with the correct authority. For audit purposes, the override message, code
required and who approved it, is stored in the audit information fields.
The three component applications for override settings are:

OVERRIDE.CLASS
OVERRIDE.CLASS.DETAILS
USER

OVERRIDE.CLASS

Each record on OVERRIDE.CLASS is a T24 application, and details the override message
and what class of authority is required. Since the override messages can include variable data
such as accounts, amounts and currencies, these are substituted with placeholder markers of
‘&’, e.g.

Screen message of ‘ACCOUNT-256 UNAUTHORISED OVERDRAFT USD 100.00’

would be input as:

ACCOUNT and UNAUTHORISED OVERDRAFT & &

In addition to the override class, more complex override checking can be defined by
referencing a record in OVERRIDE.CLASS.DETAIL, as detailed next.

OVERRIDE.CLASS.DETAILS

This application allows the definition of what can be termed literal checks and sub-routine
checks. As already shown, an override message can contain variable data, in the example
there are three placeholders shown as ‘&’. These are referred to as &1, &2 and &3.

A literal check could be if &2 (currency in our example) is USD the class ABC is required.

A sub-routine example could take the values in &2 and &3 and convert to local currency
amounts. The class required could then depend on the amount in local currency.

Local reference fields that generate overrides can also be included in this decision process and
complex authorities for approval can be created.
 Figure 7 – Override Class Details Input Record

Delivery

Most of the information that is sent out to customers is produced through delivery, e.g.
confirmations, advices, statements, etc. The manner in which the information is presented
depends on the carrier being used, such as SWIFT, telex and print. The type of the message
generated is dependant upon the application creating the message and the activity, e.g.
maturity of a money market deal. In all the existing applications in T24, this is hard-coded.
However, in the Repos module and new modules being developed, “soft delivery” is being
used. This means that you can define what message type is generated by the application when
a particular activity occurs. For example, you might want to generate an additional free format
message, or instead of the standard message type being generated, you might want to generate
an inter-branch message used by your bank. It is hoped that gradually existing applications
will be amended to use soft delivery. See the Repos section in the Application Delivery User
Guide for more detailed information.

The method used for sending messages out through delivery and the way they are presented,
is dependant upon the message being sent and whom it is being sent to. Records can be
created on DE.PRODUCT to specify the carrier to be used (e.g. SWIFT, PRINT etc.), the
address the message should be sent to, the number of copies and the language to be used.
This can be specified by company, customer or account and also by message type and
application. Therefore, a customer can have two printed copies of their statements sent to
different addresses, one in English, the other in French, whilst all other messages are sent via
SWIFT. See the Product table (DE.PRODUCT) section in the Delivery User Guide for more
details.

Although the format of SWIFT messages generated by T24 should never be changed, the
format of the printed delivery massages can be changed as required. You can either amend
the supplied layouts or design new documents from scratch. Printed messages are defined on
either DE.FORMAT.PRINT for standard printing in delivery or DE.FORMAT.TEMPLATE
for printing via the delivery WorkLink. Different layouts can be specified for different
customers (using the format in the id of the record that can be specified in DE.PRODUCT),
the application format (which depends upon the activity which generated the message and is
passed through from the application) and the language. See the DE.FORMAT.PRINT and
DE.FORMAT.TEMPLATE sections in the Delivery User Guide for more detailed information.

Although SWIFT and PRINT are standard interfaces that are delivered with T24, you may
wish to add new interfaces or carriers. For example, you may wish to use the SWIFT carrier
(i.e. you want to create standard SWIFT messages to the normal SWIFT addresses), but
instead of using one of the supplied interfaces, such as ST200 or ST400, you may wish to
interface with an in-house routing device. Or, you may wish to create a completely new
interface, to send messages either via fax or email. Both of these scenarios can be achieved
by using the DE.CARRIER and DE.INTERFACE tables. DE.INTERFACE defines the
interface to be used, which can be simply writing to a flat file or calling a user-written
subroutine to interface to an external or internal device. DE.CARRIER defines how the
messages are to be formatted, the type of addresses to be used and the interface. See the
section Creating a new interface in the Delivery User Guide for more information.

Repgens

The utility REPGEN.CREATE (Repgens) is used to create reports that cannot be created by
the ENQUIRY application. The format of the report, the data required, calculations and
manipulation of the data is entered and the report code is automatically generated. The steps
involved in the creation and output of a report are:

REPGEN.CREATE Details files used, fields printed, etc

REPGEN.SOURCE Creates object code
REPGEN.SORT Initial sorting of data prior to printing
REPGEN.OUTPUT Produces report (to screen or printer)

Repgens can also be produced during the end of day using the batch job EB.PRINT.

See the Report Generator chapter in the System Administration Guide for more information.

T24 Information Server (GIS)

This optional module is specifically designed as an interface to external systems using

standard Structured Query Language (SQL). In essence, a selection of T24 data files are
‘normalised’ into tables, currently for the Oracle database. This normalisation occurs at end of
day and during the on-line process and ensures the Oracle database is up-to-date.

The Oracle database can now be used to provide information such as:

▪ Input data to other systems

▪ Spreadsheets or similar packages accepting SQL commands
▪ SQL report utilities

This allows greater flexibility in the output from T24 Where the output is required for
investigation or reporting purposes, a hard copy may not be the best solution. A direct feed
would be more appropriate.

Reports can be provided in PC format suitable for inclusion in Management reports prepared
in applications such as Word Processors or Databases. It is possible to provide output for mail
merging so for example a mail shot can be sent to customers with savings accounts with high
balances advising them of a new account product.
See the T24 Information Server User Guide for more information.

Open Financial Service (OFS)

The Open Financial Services module (OFS) provides a standard interface to allow update and
interrogation of T24 applications. OFS provides a real time transaction and batch based
mechanism, which accepts messages in a specific format.

OFS complements the existing T24 Transaction Server (GTS) module and will support the
existing field based GTS message syntax described in the GTS chapter of the user guide.

OFS will provide the following functionality:

• Allow real-time update of T24 applications using messages supplied in specified OFS
syntax.
• Allow interrogation of the T24 database by returning information based on ENQUIRY
layouts in a specified layout
• Optional offline store and forward capability
• Optional audit trail for each message processed
• Customisation of message processing using user defined routines
• Allow batch update of the T24 database using files containing messages specified in
either GTS or OFS syntax
• Multi-company processing
• Support for sub-values
• Enhanced error message details
• Ability to run on platforms other than Unix (i.e. NT)

A variety of external sources to use OFS have already been identified, these include:

• Home Banking applications

• ATM processing
• External dealing system feeds

See the Open Financial Service User Guide for more information.

TAKEOVER.MAPPING

The TAKEOVER.MAPPING application is designed to load data from a sequential (flat) file
into the required T24 format. Records are loaded as IHLD. The records can then be input and
authorised, to ensure that the data validates through the T24 application. The utility
EBS.AUTO.FUNCTION (described in the next section) can be used to input and authorise the
records, to automate the input and authorisation process.

The TAKEOVER.MAPPING record defines the location of the flat file, and the mapping of
the data e.g. the data that will be used for a customer name starts at position 12 and is 25
characters in length.

Special conversion programs may be required to extract data from existing systems and write
them as flat files for use in the takeover process.
The example below shows a simple record that could be used in creating new CUSTOMER
records in T24.

Figure 8 – Example of creating new Customer records in T24

EBS.AUTO.FUNCTION

This utility can be used when a large number of records need to be processed. For example,
when taking over data from existing systems, it is common to input the new records en masse
by use of TAKEOVER.MAPPING. Typically the records are input but need to be validated by
T24 to preserve data integrity; therefore the records are put on the unauthorised file with a
status of IHLD.

The EBS.AUTO.FUNCTION can then be used to perform the same actions that the user would
take in order to validate and authorise the records.

Typically this would be done in two stages. First of all the records would be I(nput), to
validate them. Then they would be authorised. To perform these actions through
EBS.AUTO.FUNCTION, two records would need to be created. The first
EBS.AUTO.FUNCTION record would use the I(nput) function and function keys to validate
the record. Records requiring overrides can either be left for manual processing or approved
automatically. A second EBS.AUTO.FUNCTION record would then be used to display the
screens, and using the A(uthorise) function and function keys, complete the takeover process.

An example is shown below to enable the records to be input.

Figure 9 – EBS Auto Function Input