DELIVERY

Application Overview

The Delivery System manages the flow of all messages from T24, such as confirmations, payments
and advices whilst giving users full control over formatting and language of presentation. Messages are
generated automatically as soon as contract entry is complete or when a scheduled diary event occurs.
All messages may be either printed or sent via electronic carrier systems, such as SWIFT, Telex, etc.

Messages from external carrier systems are received by the Delivery System and, if necessary,
formatted according to the user-determined requirements. Following this, printed output containing the
incoming information is produced. For example Payment messages are passed onto the
FUNDS.TRANSFER module, which, after authorisation, updates accounts and related information.

Although the Delivery process is fully automated, users may take control over many aspects of
message management. For this purpose, facilities are provided to inspect and control message queues;
graphical displays are available giving a view of queue status, such as the volume of traffic by priority
and carrier. Once queued, individual messages may be displayed, amended or re-routed.
DELIVERY

Setting up the System

Parameter Files

Parameter table (DE.PARM)

The parameter table, DE.PARM, is a file containing a single record, SYSTEM.STATUS that holds a
number of parameters for controlling the processing of messages in delivery.

There are three general types of data on the file:

1. Parameters that allow the operator to shut down the carrier control modules, and the
inward and outward formatting modules. Shut-down can be:
Urgent (after the message currently being processed)
Normal (when all queues have been processed)
2. Parameters that can be used to optimise the performance of all the Carrier Control
modules and the Inward and Outward Formatting modules. These give the following
options:
After processing all 'Urgent' messages, a specified number of 'Priority'
messages and a specified number of 'Normal' messages are processed before
returning to see whether there are any 'Urgent' messages. (Making these
numbers larger increases the systems efficiency, but causes slight delays to the
processing of Urgent messages.)
A wait time can be specified. This is the time that Carrier Control and the
Formatting modules will wait between finishing the processing of all their
queues and searching them again for input. (A longer wait time gives other
users a faster response, but causes slight delays to messages.)
3. Fields defining the way the Delivery System is installed.
4. Field CET.TIME.DIFF is to define the local time difference from the CET. This is used
in TIME.CET conversion on SWIFT messages and added after the time.

Carrier table (DE.CARRIER)

This file contains details of all the carriers available in Delivery. This file will be delivered
populated with all currently available carriers. You do not need to amend this file unless you are
developing a new interface (see section on “Adding a new interface”).

However, to enable (to be able to use) any of the carriers specified on DE.CARRIER, you must
specify the carrier on the Delivery Parameter file, DE.PARM.

The id of the carrier table is the name of the carrier, as used in DE.PRODUCT. Each record
contains the address type to be used for the carrier (i.e. when accessing DE.ADDRESS); the
formatting rules (DE.FORMAT.CARRIER) and the carrier module (e.g. SWIFT). If the carrier
module is GENERIC the interface must be specified. The interface must reference a record on
DE.INTERFACE, which contains details of the protocol for all generic interfaces (non-generic
interface details are stored on the parameter file, DE.PARM).

When the record is authorised, formatting and carrier files are created if they do not already exist.
These files are F.DE.O.MSG.format-module and F.DE.O.PRI.format-module for the formatting
files and F.DE.O.MSG.interface and F.DE.I.MSG.interface for the interface files.

Figure 18 - Details of all Carrier records available in Delivery

Product table (DE.PRODUCT)

The product information on the Product table (DE.PRODUCT) is used by the formatting process when
expanding the Header record for the copies required for the message. Product information consists of
status (normal, hold or delete), priority (normal, priority or urgent), carrier/delivery address, which
version of the format should be used and how many copies should be made.

After the header record has been expanded, the Product record is not read again for this message, even
if the message is resubmitted and is placed again on the un-formatted queue. Therefore, if language,
format or copies are to be changed after the Header record has been expanded, the message must be
"rerouted" (see section on Re-routing Messages).

Product records may be specified for:

• A particular company
• A customer
• An account

And each of the above may be specified for:

• All message types

• Specific message types
• All banking applications
• A specific application

During formatting, the Product table is read for the most specific record matching the details on the
header record. If the most specific record is not found, the Product table is read again until a more
general record is found.

The key of the Product table is composed as follows:

1. Company code followed by "."
2. C-customer number followed by "." or A-account number followed by "."
(Not present for company level records)
3. Message type or "ALL" followed by "."
4. Application, "ALL" or xxyy where xx is the application code and yy is the Funds Transfer
product code

Figure 19 - Display details of DE.PRODUCT record

The file is searched in the following order:

All of the fields used to find the record on the Product table are stored on the Header record. Therefore,
by using the fields available and searching the Product table in the above order, it is possible to find out
which Product record has been used to expand the multi-value set on the Header record.

The multi-value set on the Delivery Header record will be expanded according to the fields on the
Product record. For example, if the Product record says that, one copy should be sent by SWIFT and
with one by print. The Delivery Header will be updated accordingly. The following fields on the
Delivery Header are updated from the Product record:
CARRIER.ADD.NO
FORMAT
MSG.LANGUAGE
MSG.PRIORITY
MSG.STATUS
MSG.DISPOSITION

If the Product record says that a particular carrier should send two copies, these copies are split on the
Header record into two multi-value sets.
If a single message should be sent to multiple customers, the field MDR.CUSTOMER on the multi-value
set can be used to specify additional customers to whom copies of the message needs to be sent. This
can be specified for customer and account level records and for the PRINT carrier only.

The language on the Product record will not be used to update the Header record if the Product record
used was a company level record, since the language passed from the application is more specific.

If for a particular message type, copies are not allowed, i.e. Copies is set to "NO" on the Message table
(DE.MESSAGE), only the first copy of the message specified on the Product record will be used to
update the Header record.

The product record can also be used to “hold” messages or to delete them, by using the STATUS
field; also the priority of messages can be set.

Address table (DE.ADDRESS)

The Delivery Address table (DE.ADDRESS) contains the names and addresses of a bank's customers
and also of each company within the banking organisation. The basic postal address of each customer
is automatically updated when the address is changed through Customer maintenance (CUSTOMER),
creating a record on the Address table with a key of:

COMPANY ".C-" CUSTOMER ".PRINT.1"

The address on this record cannot be updated through the Address table, but must be updated through
Customer maintenance.

SWIFT ids, Telex numbers and alternative print addresses are also held on the Address table and these
records may be input and amended through the Address table maintenance. The key to records is:

COMPANY ".C-" CUSTOMER ".XXXXXX.N"

Where XXXXXX is a valid carrier defined on the carrier file, DE.CARRIER (e.g. SWIFT, TELEX)
and n is the address number. NOTE: If the carrier is TELEXF or TELEXP, a carrier of TELEX is
used when looking up the Address table.
 Figure 20 - Display details of the DE.ADDRESS record

During formatting, after the product record has been read, the Address table is read for each copy of
the message in the multi-value set on the Header record. The key to the Address table is composed of
the fields in the header record, using the carrier ADDRESS from the DE.CARRIER file and the address
number held in the CARRIER ADD NO field. If the Address record cannot be found on the Address
table, the message will go into Repair.

The address on the Address table appropriate to the carrier in the key is used to update the To
address field on the header record.

It is possible to hold all printed output for this address by setting HOLD.OUTPUT to “Y”. The
message will be going through delivery in the normal way, but instead of being printed, it will be
written to HOLD.CONTROL. When required, till messages for the customer can be printed using
PRINT.CUST.OUTPUT.

Alternate carrier table (DE.ALTERNATE)

The Delivery Alternate carrier table (DE.ALTERNATE) contains alternative carriers or addresses to be
used if a message is to be rerouted. For example, a particular customer may normally have all their
messages sent to a particular Telex number, but that Telex number might be out of order, so all their
messages are to be sent to an alternative Telex number.

The Alternate table is accessed if the MSG.DISPOSITION field on the Header record is set to
"REROUTE". See section on "Re-routing Messages" for information on how this field can be set.

When a message is passing through formatting, if the MSG.DISPOSITION is set to "REROUTE", the
Alternate table is accessed for the carrier, address number, language, format and copies the message
should be sent to.

The key of the Alternate table is composed as follows:

1. Company code followed by "."
2 C-customer number followed by "." or A-account number followed by "."
(Not present for company level records)
3. Carrier followed by "."
4. Address number

When the Alternate table is accessed, only a record at the same level as the Product record
originally read will be accessed. Therefore, if the Product record originally read was at customer
level, the Alternate table will be accessed at customer level. If an appropriate record cannot be
found, the message will go into Repair with a corresponding error message.

Figure 21 – Display DE.ALTERNATE record

Disposition control table (DE.DISP.CONTROL)

The Disposition control table (DE.DISP.CONTROL) is used to specify special conditions for which
particular processing is required. Providing the conditions are satisfied, the requirements specified on
the Disposition control table will override all other requirements. The only proviso to this is that it
cannot override restrictions such as deleting messages for message types, which cannot be deleted
(delete field on the Message table DE.MESSAGE is set to "NO") or copies of messages being
generated for message types that do not allow copies (COPIES on the Message record is set to "NO").

Examples of how the disposition control table could be used are as follows:

• All messages with amounts greater than two million dollars are urgent and require immediate
confirmation.

• All messages for a particular carrier must be rerouted (the Alternate carrier table will be accessed
to find the new carrier).

• Print a copy of all messages, which have a message type of 100 and are for customer 254 or 256.

The above is achieved by setting up conditions on which the message status and/or priority is set.
Alternatively, a user-defined routine can be specified to check complex conditions - the routine passes
back whether the conditions were matched or not. The routine name is placed in FIELD.NAME and
must be prefixed by the @ character. The routine is passed the current DE.O.HEADER record in
argument one, the OPERAND in argument two and the CONDITION in argument three. The return
argument is argument four and should evaluate to true (1) or false (0 or null). The routine itself should
be specified as

EXAMPLE.NAME (HEADER.REC, OPERAND, CONDITION, RETURN.FLAG)

Records are added to the Disposition Control table with a numeric key. When messages go through
formatting, the disposition control table is examined in numerical order until a record is found whose
conditions are satisfied or there are no further records on the Disposition control table. Thus, if a
message matches conditions specified on disposition control records 10 and 50, only record 10 will be
applied to the message. Therefore, it is important when entering records on the Disposition control
table to assign the key according to the importance of the record.

Conditions can be specified on the Disposition control record to compare fields on the Header record to
certain values. For example, CARRIER EQ SWIFT or AMOUNT GT 1000000. The condition fields are
multi-value and assume a condition of "AND". Therefore, complex conditions can be built by setting
up several simple conditions in a multi-value set. E.g. AMOUNT GT 1000000 AND CURRENCY EQ GBP.
All the conditions must be true before the status and/or priority is applied. If "OR" is required, separate
records must be entered. See the Help text for more information on entering conditions.

Also specified on the Disposition control record is what should be done with messages, which match
the conditions specified. This is entered in the STATUS and PRIORITY fields, either or both of which
can be entered. STATUS amalgamates status and disposition and can be "HOLD", "HOLD hh:mm",
"WAIT hh:mm", "RELEASE", "DELETE", "RESUBMIT", "REROUTE" or "PRINT". Priority can be
"U" - urgent, "P" - priority or "N" - normal.

“HOLD” can also be used with the HOLD.UNTIL.DATE field, either specifying an exact date or
entering “VAL” to set the hold date according the days’ delivery for the currency.

Figure 22 – Setting Parameters on the Disposition Control Record

When a new or amended Disposition control record is authorised, the MSG.DISPOSITION,

MSG.STATUS or MSG.PRIORITY in the Header for each message that has been successfully
formatted but not sent (not messages on the Repair queue), is amended if the information in the
Header matches the condition(s) defined in that Disposition control record. This involves examining
numerous queues and files in the Delivery system and could take some considerable time. However,
if the operator does not require the Disposition control record to be applied to messages already
formatted, but only requires them to be applied to newly generated messages, the disposition control
field on the Parameter table (DE.PARM) can be set to "N" before the disposition control record is
authorised, then reset to "Y" after the record is authorised. NOTE: The disposition control field on
the Parameter table refers to all records on the Disposition control table. Therefore care should be
taken in resetting it, as messages currently being processed by Delivery might not have action taken
by relevant records because the disposition flag was turned off. It is recommended that all the
Delivery processes should be stopped before this flag is changed.

The Disposition control records will also be applied to messages that are created by the Delivery
system during formatting, unless the Disposition control field on the Parameter table DE.PARM is set
to "N".

"HOLD", "WAIT", "DELETE", "RESUBMIT" and "REROUTE" affect records with a disposition of
"Formatted" and operate subsequently during Formatting on records that would have been set to
"Formatted". WAIT hh:mm is translated to HOLD hh:mm when the Disposition control record is
applied.

"RELEASE" affects records with a status of "HOLD" and operates subsequently during Formatting.

"PRINT" prints an image of formatted messages, regardless of the carrier used to send the message,
e.g. it will produce a printed copy of a SWIFT message if the message was originally sent by SWIFT.
If the original message was sent out by print, the bottom of each page of this image will have "**
COPY ** COPY ** COPY **" printed across it.

Each Header record that is changed has the ID of the Disposition control record placed in the
appropriate "Disposition No" field for each copy of the message affected. This ensures a less important
disposition control record does not subsequently change it. Records with lower ids take precedence
over higher ids, e.g. 10 takes precedence over 100.

The record should be reversed when the conditions no longer apply.

Interface file (DE.INTERFACE)

This file contains details of the protocols for all interfaces which use the Generic Delivery Interface.
The protocols for interfaces written prior to the introduction of the Generic Delivery Interface are
either stored on DE.PARM or are hard-coded in the program. Sequence numbers for existing
interfaces are stored on F.LOCKING.

You do not need to amend this file unless you are developing a new interface (see section on
“Adding a new interface”).

There is little validation of the fields on DE.INTERFACE. This is to allow for maximum flexibility
when new interfaces are written.

The id of the file is the interface as defined in the INTERFACE field on DE.CARRIER.
DE.SWIFT.DIVERSION
You may wish to send all SWIFT statements, for example, to a Nostro reconciliation package. This
can be achieved through the use of the SWIFT diversion processing. Messages to be diverted are
processed as normal SWIFT messages through to the carrier control stage. However, in the SWIFT
carrier control program, DE.O.CC.SWIFT, instead of the message being sent to the ST400, for
example, it is written to a file which can then be transferred by some other means, e.g. sent by tape,
accessed by a C program, etc.

Messages to be diverted are defined on the SWIFT diversion table, DE.SWIFT.DIVERSION. For
each message type, you can specify that messages for a particular SWIFT address are to be diverted.
Both outgoing and incoming messages can be diverted. Incoming messages may also be ‘copied’ by
setting ALLOW.PASS.THRU to YES

Example
You wish to divert all statements to a Nostro reconciliation package. On DE.SWIFT.DIVERSION,
you will need to set up records for each of the message types concerned.

Figure 23 – Set up record for SWIFT Diversion

You can see that in the above screenshot example, all 950 messages for SWIFT address
NOSTRECS are to be diverted. NOSTRECS is a dummy SWIFT address, which is used to control
the diversion of the required messages. For each customer for whom messages are to be diverted,
two SWIFT addresses will exist: SWIFT.1 for normal SWIFT messages and SWIFT.2 for diverted
messages.
 Figure 24 – Real Swift Address used if field “USE.CUST.ADDRESS” is set to “Y”

When the SWIFT messages are diverted, the dummy SWIFT address will be replaced with the real
SWIFT address if USE.CUST.ADDRESS is set to “Y” on the SWIFT diversion record.

Product records should be set up to route 950 messages to SWIFT address 2; all other messages
should be sent to SWIFT address 1.

Figure 25 – Product records route 950 messages to SWIFT.2 address

Figure 26 – All other messages are routed to SWIFT.1 address

Alternatively, DE.PRODUCT records can be created to produce two copies for 950 messages - the
first copy to SWIFT address 1, the second copy to SWIFT address 2 to be diverted.
DELIVERY

Application Design

Detailed Flow of Outward Messages

The following section will not need to be read by everyday users of the Delivery System. It’s
intended for use only by the Delivery Operator who needs to know Delivery in more detail. If the
client uses the Delivery System in the form supplied by TEMENOS, then this section may not be
required. However, if the client wishes to use different formats for printing for example, or wishes
to utilise the more flexible aspects of the system, then it is advisable that they understand the way in
which messages are processed by Delivery and how the various tables are accessed with details
either passed from the applications (e.g. Funds Transfer) or generated by Delivery from the tables.
Refer to the corresponding Helptext for more information on the contents of fields on tables.

Application Handoff
When an on-line transaction or overnight process requires the sending of a message, the Delivery
process APPLICATION.HANDOFF is invoked. This process simply puts "raw" message data on file
without reformatting it. It gives each message an ID, the Delivery message id and passes this id to the
calling Application, which places it on file to provide an audit trail.

When a banking application needs to send a message, it passes the following data to APPLICATION
HANDOFF:

(i) The key to the required Delivery Mapping record (DE.MAPPING):

Message type
Application
Mapping sub-classification

E.g. 103.FT.1

NOTE: Sub-classification is used when a particular application calls APPLICATION.HANDOFF for

the same Message Type from different programs and supplies different record layouts to map data
from.
(ii) Between 1 - 9 records containing the data that will later be mapped into the Message Detail and
the Message Header (DE.O.HEADER) files.
(iii) A field in which to receive the Delivery Message id generated by Delivery. This reference is
passed back to the banking application as an acknowledgement that the message was received
by the Delivery System.

The Delivery message id is composed as follows:

DYYYYMMDDNNNNNSSSSSQQ where
"X" "D" - message is to be delivered (outward message)
"YYYYMMDD" Is the date
"QQQQQ" Is the system user number of the inputter
"SSSSS" Is the time in seconds since midnight
"QQ" Is the sequence number of transactions within a second
If a single transaction needs to send three different messages, then it has to make three calls to
Application Handoff, which will provide three records of raw message data. Each of these records
has the date and time it was created in the id as described above, and contains the Mapping Key
followed by between 1 and 9 blocks of data.

A user defined subroutine can be called from within APPLICATION.HANDOFF, to enable

modification to the records, making additional information available to delivery, e.g. to additional
fields to a record, to perform calculation for new fields. The routine is specified on DE.MAPPING in
ROUTINE.

The routine is passed all nine of the handoff records in a DIMensioned array as the first argument
and a null in the second argument, which is used as a return error message. If there is a value in the
second value on return from the routine the mapping does not proceed and the error message is
handed back to the calling application.

If all the records are blanked by the call to the user routine the mapping process does not proceed
and an error returned to the calling application.

The routine itself should be specified as:

EXAMPLE.ROUTINE (MAT EXAMPLE.REC, ERR.MSG)

Mapping
The Mapping process, which is part of the interaction between the transaction and delivery, extracts the
fields required in the message from the raw data that was passed to APPLICATION.HANDOFF by the
banking applications. The message information is stored on the Message Detail file. Additionally, for
each message, a Delivery Header record (DE.O.HEADER) is created, for holding controlling
information about the message. The messages are placed on the Unformatted Queue.

The key of an unformatted message is its date/time stamp (the Delivery message id).

The raw data in a message contains up to 9 blocks of data dumped from a program in the layout
defined in that program. Different programs generating the same message type will produce different
raw data, so each require a different record on the mapping table (DE.MAPPING) for converting the
data into the standard message detail and Header records. The id for which mapping record to use is
passed from the banking application.

The mapping process puts fields onto the Message Detail file in positions that correspond to their
definition in the message table, DE.MESSAGE.

E.g. Mapping key is "103.FT.1". Therefore, the key to the message table is "103". On the message
table, the fifth value of Field Name might be "Ordering Customer". This means that on the
Message Detail record generated by the Mapping process, the fifth field should be Ordering
Customer. (This does not normally concern the user because the message contents cannot be
looked at until they have been formatted for output.)

The Mapping record also specifies which fields are used to update the Delivery Header record created
by this process. Fields on the header can be examined using DE.O.HEADER.

Once the Message Detail and the Header record processing is complete, the message is placed on the
unformatted queue.
If there is a field in the originating contract that contains multiple customer numbers or addresses
then a copy of the message can be sent to each. Where this is required then the appropriate field has
its HEADER.NAME in DE.MAPPING completed with "MULTI.CUST" and any associated fields
have the value "ASSOC.FLD" in their HEADER.NAME.

Formatting
Outward formatting (DE.O.SELECT.NEXT.MESSAGE) selects messages for formatting in order of
priority. Priority at this stage can only have been specified within the banking application that
generated the message or by a user amending the priority on the Header record through
DE.O.HEADER.

All "U"rgent messages are processed first, followed by a set number of "P"riority messages, as
specified in the Read Priority field on the System Status record on the Parameter table (DE.PARM).
The urgent queue is then processed again, followed by the set number of priority messages. Once all
urgent and priority messages have been processed, a set number of "N"ormal priority messages are
processed, as specified in the Read Normal field on the System Status record. This order of processing
messages is so that urgent messages do not spend longer than necessary on the Un-formatted queue.

E.g. If the Read Priority field were set to 10 and the read normal field were set to 5, messages would
be processed as follows: All urgent messages would be processed, then up to 10 priority
messages would be processed. Any urgent messages which may have been added to the queue
would then be processed, followed by up to 10 more priority messages. If there were no more
urgent or priority messages, 5 normal messages would be processed before the urgent and
priority queues were re-examined.

If a Header record contains an Override Carrier, this will determine the formatting required and the
Product table will not be read. This override carrier will be the only carrier used, there will only be one
copy of the message, the format will be version 1 and the status, priority and language will be those
picked up during Mapping.

Normally however, a header record will not contain an override carrier so the product table,
DE.PRODUCT will be read. See the section "Product table" for how this file is accessed. If the
relevant product record specifies a message is to be sent by SWIFT but the format record does not exist
on the format SWIFT table (DE.FORMAT.SWIFT), the message will be sent by Telex. If the format
record does not exist on the format Telex table (DE.FORMAT.TELEXF or DE.FORMAT.TELEXP),
the message will be sent by print. If the print format record does not exist on the Format print table
(DE.FORMAT.PRINT) and a special language was requested, the print format in the base language will
be used. If a print format does not exist, the message will go to the repair queue.

If a message is routed by a company level product record, the language of the customer will be used in
formatting, rather than the language on the product record, as the language of the customer is more
relevant.

Although a record may exist on the product table to send all messages to a particular customer by telex
and print for example, if copies are not allowed for a particular message type (copies on the Message
table (DE.MESSAGE) is set to "NO"), only the first carrier specified on the product record will be used
when the message is formatted.

After the product record is read (or override carrier is determined), the header record is expanded to
include a multi-value set of data for each copy of the message. The disposition field is set to
"formatted" and the individual message disposition fields are now used to control the disposition of the
message. The copy number of the message (i.e. the offset in the multi-value set) is appended to the
delivery id, so that when the message copy is placed on a queue, it is apparent which message copy is
being referred to. The delivery id is now in the form:

XYYYYMMDDNNNNNSSSSSQQ.C where C is the copy number

Each message copy is processed in turn, before the next message is processed.

For each message copy, the Delivery Address table (DE.ADDRESS) is accessed to determine the
address to which the message should be sent. See the section "Address table" for how this table is
accessed. NOTE: The product table and the header record can specify carriers of "TELEX",
"TELEXF" and "TELEXP" to refer to the different ways of formatting. TELEX will use the SWIFT
formatting table (DE.FORMAT.SWIFT), TELEXF will use the formatted telex table
(DE.FORMAT.TELEXF) and TELEXP will use the print telex table (DE.FORMAT.TELEXP).
However, when the address table is looked up, the carrier used will be "TELEX", since, regardless of
the way the message is formatted, all Telex messages for a particular customer should be sent to the
same Telex number (different Telex numbers can be specified by using different address numbers).

The appropriate formatting table is accessed to determine the formatting rules. The keys to the files are
as follows:

Format SWIFT, DE.FORMAT.SWIFT

Key is NNNN.1.1 where

NNNN is the message type
E.g. If the message type is 320, the key will be 320.1.1

Formatted Telex, DE.FORMAT.TELEXF

Key is NNNN where

NNNN is the message type
E.g. If the message type is 320, the key will be 320

Format print, DE.FORMAT.PRINT and Print format Telex, DE.FORMAT.TELEXP

Key is NNNN.AANNNN.NNN.AA WHERE

NNNN is the message type
AANNNN is the application format, which is either application code or numeric or
application code followed by up to 4 numeric characters.
NNN is the format version number
AA is the language

E.g. If the message type is 320, the application format is MM1030, the format version 20 and
the language FR, the key will be 320.MM1030.20.FR

The message type is held in the message type field on the header record and was part of the mapping
key passed in APPLICATION.HANDOFF. The application format is held in the application format
field on the header record and was passed from the banking application during mapping by using
APP.FORMAT. The format version number is held in format field on the header record and was passed
from the product table. The language is held in the msg language field on the header record and was
either passed by the banking application or from the Product table.
If any errors occur during formatting, the message is placed on the Repair queue, with the error
message in the Msg Error Code field. If formatting was successful, the formatted message is placed on
the formatted carrier file, e.g. Formatted SWIFT, formatted print, etc. However, there can be various
exceptions, as follows:

• If a message is to be held, e.g. it is not required to send the message out until business reopens in
Tokyo at the start of the next working day, the message can be placed on the Hold queue.

• If the message is being sent by Telex, the message might be specified as being suitable for
Batching, in which case it will be placed on the Batching queue. Once a batch is complete, it will
be removed from the Batching queue.

• If the message is being sent by Telex, the message may require the input of a test key, in which
case the message will be placed on the Awaiting test key queue (this may include batched
messages). Once the test key has been input and authorised, the message will be placed on the
Formatted Telex queue.

Batching
Telex messages for the same customer may, if desired, be grouped into batched messages. By batching
messages, the customer reduces the cost of sending messages (by removing duplication of data) and
also reduces the work of the customer to whom the messages are sent. If batching of Telex messages is
required, the "Batching Req" field on the System Status record on the Parameter table (DE.PARM)
must be set to "Y".

Messages are only batched as follows:

• Only messages of normal priority "N" are batched

• Messages are batched in groups of the same addressee, the same currency, whether a test key is
required or not and the same batch group.

• Only TELEXP messages (free format Telex messages)

The batch groups are specified on the batch group table, DE.BATCH.GROUP. A batch group may
contain more than one message type, but each message type may only exist in one batch group. If a
message type does not exist in any batch group, messages of that message type will not be batched.

If a message is to be batched, the Batching queue is examined to see if there is a batch to which the
message can be added. If there is a batch satisfying all the above criteria, the message is added to that
batch. If there is not a batch, a new batch will be created, assigning the next available batch number.
When there are ten messages in the batch, the batch is completed and removed from the Batching
queue and added to the Awaiting Test key queue if a test key is required or to the Formatted Telex
queue if a test key is not required.

Batches may be completed manually if desired, for example, just before End of Day or before close of
business in a particular country. In this case, there will be less than ten messages in the batch and there
may only be one message. To complete a batch manually, use the Message Management Display
application, DE.MM.DISPLAY and display the Batching queue. To complete a batch, enter "C"
(complete) beside the batch. The batch will be removed from the Batching queue and placed on the
Awaiting Testkey or Formatted Telex queue as appropriate.
Test key Input and Authorisation
Within Delivery, it is possible to input and authorise test keys, if required. Test keys are normally
added to messages containing financial information, such as Payment advices. By enforcing test key
input, messages are only sent out once they have been authorised by someone of sufficient rank within
the bank.

If a test key is required for a particular message type, the "Test key req." field on the message type
record on the message file, DE.MESSAGE must be set to "Y".

T24 does not provide the Test key calculation routines. The user should calculate the test key using the
calculation tables or a PC based package, for example. To input and authorise test keys, the application
"Input test keys", DE.INPUT.TESTKEY, should be used.

On entering this application, messages currently awaiting test keys are displayed. A message can be
selected by entering the line number. The following functions are available:

• "I" - Input test key

This function will display the Telex message on the screen and allow the input of a testkey. The
message can be paged forwards or backwards in the normal way. For a batched message, however,
a single page summary of the messages in the batch is displayed. When a testkey is input, the
screen display returns to the list of messages with the message marked as input. The input function
is not allowed for a message that has already had a testkey input and authorised (authorised since
this application was initiated). If a testkey has already been input, but not yet authorised, a warning
message will be displayed. The previous testkey will be overwritten with a new entry if the user
proceeds.

• "A" - Authorise test key

This function will display the message on the screen (which may be paged through in the normal
way). For a batch, however, a single page summary of the messages in the batch is displayed. The
test key must be re-entered and if it matches the previously input test key, the screen display will
return to the list of messages with the message marked as authorised.

The authorise function will not be allowed for a message without a test key already input, nor will
it permit the same user to authorise a test key. A maximum number of attempts are allowed to
authorise a test key as defined in the "No. auth attempts" on the Parameter table. If this is exceeded
the test key is erased and must be re-input for this message.

NOTE: Authorisation is dependent on the "Authorise test key" field on the Parameter table.

After a test key has been input or authorised and the screen display returned to the list of messages, the
user may refresh the list by typing "R". This will remove from the display any messages that have been
marked as authorised during the current session.

Once a test key has been authorised (or input if authorisation is not required), a test key line is
inserted into the message, the msg disposition is set to "Formatted" and the message is placed on the
Outward Telex carrier control queue. The test key line on the message is not visible and is displayed
as an asterix.
Outward carrier control processes
Although messages can be sent by different carriers, part of the processing of these messages is
always the same and is documented here to save repetition in the following carrier control sections.

Once messages have been correctly sent (i.e. the acknowledgement is received), the following
processing is performed:

• The message disposition is updated to "ACK" - acknowledged.

• The message is removed from the awaiting acknowledgement queue (or formatted queue for print).

• A copy of the Header record is written to the Header archived file (DE.O.HEADER.ARCH).

• A copy of the formatted message is written to the history files.

The messages are stored on the history files, so that a copy of the message is always accessible.

Generic carrier control

Some interfaces use the generic carrier service, rather than bespoke carrier control programs. All
carriers are defined on the DE.CARRIER file, including whether the generic interface is used
(CARRIER.MODULE is set to “GENERIC”) or not (e.g. CARRIER.MODULE is set to “SWIFT”).

Although the generic carrier service can be used to process many different carriers, a separate
service can be launched for each carrier.

The generic carrier control service will process messages for the carrier specified. Each message
processed will be handed to the interface routine specified on the interface record on DE.INTERFACE,
and will be handled accordingly. If ACKs are required (ACK.REQUIRED is set to “Y” on
DE.INTERFACE), the message will be placed on the awaiting acknowledgement queue. When the
ACK is received (from the inward routine), or if ACKs are not required, the message will be flagged as
having been sent correctly and a copy of the formatted message placed on the history file. If a NAK is
received, the message will be removed from the awaiting acknowledgement queue and placed on the
repair queue. Incoming messages received from the inward interface routines will be placed on the
Unformatted Inward queue. When an acknowledgement received from swift for outward messages,
their OSN (6 digit number as available in Basic header (1)-field position from 23 to 28) is updated in
OSN.NO in application DE.SENT.SWIFT.

The T24 services can be run on-line or automatically during the close of business (cob). Provided as
standard are one for the outward generic service and one for the inward. Records on
TSA.WORKLOAD.PROFILE and TSA.SERVICE called DE.CC.GENERIC.OUT and DE.CC.GENERIC.IN

It should be noted that the specific generic carrier(s) need to be input in the field called DATA on the
BATCH record DE.CC.GENERIC.OUT for the job name DE.CC.GENERIC.OUT. If you wish to segregate
each carrier and have a service for each one then new BATCH, TSA.SERVICE &
TSA.WORKLOAD.PROFILE record needs to be created having the DATA field set appropriately.

The outward delivery service will loop through the carriers mentioned in DATA field in the BATCH
record and process the messages for that carrier. This will be controlled by the CONTROL.LIST
variable in the batch processing. Moreover, the messages are processed based on the priority
settings namely U, P and N. The messages in the queue ‘U’ are processed first, then ‘P’ and ‘N’ at
the end. The same logic would be repeated for all the carriers mentioned.
There is a possibility that while sending the message out of the T24 system, the communication
with the interface goes down or some other abnormal termination occurs. In those cases, when
generic processing is restarted, the message that was in the process of being sent during the
previous process will have to be re-sent first before normal processing starts. This is also handled
by the CONTROL.LIST variable in batch process.

SWIFT Carrier Control

SWIFT messages are sent to the SWIFT network from T24 via a SWIFT mainframe, such as an
ST400. The outward SWIFT carrier control process, DE.O.CC.SWIFT, sends the SWIFT messages
from T24 to the SWIFT mainframe and monitors the responses received from it.

Messages are sent by the SWIFT carrier control process in priority order. When the SWIFT mainframe
receives the message, it performs integrity checking on the message to ensure that the message was
received correctly. If the message fails the integrity checking, an attempt is made to resend the
message. If the integrity checking fails again, it is assumed there is something wrong in the
communication between T24 and the SWIFT mainframe and the SWIFT carrier control process is
terminated, with a message being written to the Syslog file. See the section "Syslog display/clear" for
displaying this message.

If the message was received by the SWIFT mainframe correctly, the SWIFT mainframe user may be
required to input and authorise a test key. Once the message is ready to send, the SWIFT mainframe
will send the message to the SWIFT network. The SWIFT mainframe will either receive an
acknowledgement or a "time out" message after a standard period of time. The resulting ACK or NAK
will be sent to T24 via the Inward SWIFT carrier control process. Therefore, even if inward SWIFT
messages are not processed by T24, the inward SWIFT carrier control process, DE.I.CC.SWIFT, must
always be run to receive the ACKs and NAKs for outward messages.

If Inward SWIFT carrier control receives an "ACK" (acknowledgement), the message is removed from
the Awaiting Acknowledgement queue and the Msg Disposition is updated to "ACK". If a NAK
(negative acknowledgement) is received, the message is removed from the Awaiting
Acknowledgement queue and placed on the Repair queue with a Msg Disposition of "Repair".

See the section "Detailed flow of inward messages - SWIFT carrier control" for details of how inward
messages are processed by DE.I.CC.SWIFT.

SWIFT using CASmf Protocol

SWIFT messages can be sent to/from either the ST400 or Alliance using the CASmf protocol. This is
achieved using the generic delivery phantom (DE.CC.GENERIC).

Print carrier control

The print carrier control process, DE.O.CC.PRINT, spools print formatted messages onto the
appropriate printer "Spool queues" controlled by the computer's operating system.

Messages are printed in company, customer and account sequence. Therefore, it may be possible to put
adjacent messages into the same envelope. However, if both Formatting and Print Carrier Control are
running simultaneously, Print Carrier Control will process messages faster than Formatting, so
messages could be printed in the same sequence as they were formatted in, which is usually date/time
within priority. If the order of company, customer and account is required, Print carrier control could
be started after formatting is completed. However, if large volumes of printout are expected, it is worth
considering how long it will take to print all the messages if print carrier control is only run once
formatting is complete.

Print carrier control is normally run as a phantom. It is possible to run it interactively at a terminal, by
entering DE.O.CC.PRINT at the "Awaiting application" prompt. This gives the advantage of the user
being able to select a specific form type, priority and department, but can result in the screen being tied
up for a considerable length of time. If the print carrier control process is run as a phantom, all form
types, priorities and departments are printed.

Once messages have been output to the spool queues, the Msg Disposition is updated to "ACK" and
the message is removed from the Formatted queue.

NOTE: If HOLD.OUTPUT on DE.ADDRESS is set to “Y”, i.e. all printed output for a customer for a
particular address is to be held, (e.g. if the customer has no contact address but just comes into the bank
on a regular basis to collect all correspondence), the messages are not spooled but instead are written to
the hold control file, HOLD.CONTROL. The message is ACKed by delivery at this stage. When the
customer comes in, all his messages and reports can be printed using PRINT.CUST.OUTPUT.

User fields in DE.MESSAGE / DE.MAPPING

User fields are introduced to preserve local setting/mapping done at the client site in DE.MESSAGE
and DE.MAPPING from overwriting when new record is copied into these applications during
Upgrading or installing patches.

User fields are introduced in DE.MESSAGE and DE.MAPPING wherein the user can define their
local setting in DE.MESSAGE and map them in user fields of DE.MAPPING and it can be used in
DE.FORMAT.SWIFT / DE.FORMAT.PRINT to generate messages with their local setting.

When changed records in DE.MESSAGE, DE.MAPPING is copied during upgrading or installing a

patch and it will overwrite the system fields only and retains the existing user field details.

In DE.MAPPING, system fields can also be mapped to user input position and the details mapped
to user position will have the precedence over the system fields and same will be used in
Application handoff.

Through following example of set-up above functionality can be explained.

A Bank wants to generate MT103 from FT application with tag 23B (Bank operation code) using
their local reference field and to achieve that following set up is done.

Step 1:

In DE.MESSAGE, for id 103, add user field as OPERATION.CODE and give the required field
characteristics like length, Single/Multi value and whether mandatory or Not. If it is mandatory then
the field should have a value in the handoff otherwise message will go into repair.
 Figure 35 - DE.MESSAGE WITH USER FIELDS SETTING FOR TAG 23B

Step 2:

In DE.MAPPING for record 103.FT.1 map the local reference field position of FT for
USR.FLD.NAME- Operation. Code. Like system fields, the mapping can be done directly from the
application or from the application hand off position. If the user field is mandatory for message
type, then record will not be allowed to commit without a mapping for that field in DE.MAPPING

In this example local reference field in FT (field 1.67.4) is mapped to USR.FLD.NAME “Operation
Code”.

Figure 36 - DE.MAPPING WITH USER FIELDS MAPPING TO FT FOR TAG 23B

Step 3:

In DE.FORMAT.SWIFT give the field name along with the tag detail for record 103.1.1.

For tag 23B is mapped to fields name Operation code that is defined in DE.MESSAGE and mapped
in DE.MAPPING as above.
 Figure 37 - DE.FORMAT.SWIFT record for MT103 for tag 23B

Step 4:

Now input the FT details along with the local reference details for Tag 23B. In this example “CRTS”
has been given in FT local reference for Tag 23B.

Figure 38 - FUNDS TRANSFER created with details for Tag 23B using Local ref. Field

Step 5:

Now when we generated MT103 message will have the Tag 23B with the details as given in FT
 Figure 39 - Swift output for MT103 with tag 23B

In normal case whenever there is a up gradation to next release or patch sent for any fix and it
contains a revised data record for DE.MESSAGE or DE.MAPPING, the existing data records in
DE.MESSAGE or DE.MAPPING is overwritten with the latest data record and local mapping done
at the client site is lost. Once again fields needs to be added in DE.MESSAGE and mapped in
DE.MAPPING.

But now the local setting is added in User fields, the local setting done will be preserved and latest
data records received in DE.MAPPING or DE.MESSAGE will be overwriting only the system
fields. Thus in the above case the local setting done for mapping of tag 23B will be available even
after taking the latest data records.

User Header Block 3 details in Outward Swift Message

In outgoing swift messages User Header-Block 3 may contain the user reference for a message. It is
optional on user-to-user messages.

In Block 3 of User header of Swift FIN message following details can be given (Optional):

103 Fin Copy Service Code 3!a

113 Banking Priority 4!x
108 Message User Reference 16x
119 Validation Flag 8!c
115 Payment-Release-Information-Receiver 32x

To generate outgoing Swift message with appropriate values in User Header Block 3 details, field
name can be added in DE.MESSAGE and these field name has to be mapped using DE.MAPPING
and in DE.FORMAT.SWIFT fields USER.BLOCK, USER.FIELD can been used to map the User field
name with the Block name.

In DFS USER.BLOCK can accept block name as SERVICE.ID, BNK.PRIORITY, MUR, VALID.FLAG,
PAY.REL.INF and it correspond to above Swift user header Block 3 fields.
Presently system automatically populates the value in Validation Flag field 119 in MT103 message-
“STP” for MT103+ and “REMIT” in 103Extend. Please refer Funds transfer manual for more
details for MT103 type.

For USER.BLOCK, mapping can be done in DE.MAPPING either with a local reference field or a
field from an application and the field name can be given in USER.FIELD in DFS. While generating
Swift message, based on the mapping, application handoff will be populated with Block details and
it is used while generating the Outward Swift Message. Currently above functionality is supported
only for 103.1.1 record in DFS.

For example while generating MT103, Bank wants to send Payment Release Information Receiver
field 115 details. The details are captured in Funds transfer in Local reference field (67.1). The set-
up required for the above is as follows

Add a field name as PAY.REL.INF.DATA in DE.MESSAGE for the message type 103.

Figure 40 – DE.MESSAGE with field name for User.Block

Map the field name with FT Local reference field in DE.MAPPING for record 103.FT.1.

Figure 41 – DE.MAPPING with FT local reference field

In DE.FORMAT.SWIFT application for 103.1.1, add USER.BLOCK as PAY.REL.INF and USER.FIELD

as PAY.REL.INF.DATA (field as added and mapped as in the above MB-Task)

Figure 42 - DFS for 103 with USER.BLOCK and USER FIELD.

Now input FT with the local reference details and outward Swift Message MT103’s User block
header 3 will be having the details as given in FT local reference field.

Figure 43 – FT record with Local Reference details for User Block field 115
{1:F01TEMEUS33XXXX.SN...ISN.}{2:I103CEDELULLXXXXN}{3:{103:xxx}{115:BLOCK3DET}}{4:
:20:FT01236001000125
:32A:010824USD10000,00
:50A:SWIFGBG1
:59:BENE CUST - BLOCK HEADER
:71A:SHA
-}

In the same way for other user block fields in user header, details can be mapped and generated in
outgoing MT103.

Detailed Flow Of Inward Messages

Inward messages, i.e. messages sent by other banks, can be processed by T24 providing they are in a
format that T24 can decode. Currently SWIFT messages can be decoded and also Telex messages if
the format is described on the TELEXF format table. The TELEXF table could be used to describe
inter-branch messages.

Generic carrier control

Some interfaces use the generic carrier service, rather than bespoke carrier control programs. All
carriers are defined on the DE.CARRIER file, including whether the generic interface is used
(CARRIER.MODULE is set to “GENERIC”) or not (e.g. CARRIER.MODULE is set to “SWIFT”).

Although the generic carrier service can be used to process many different carriers, a separate
service can be launched for each carrier.

The generic carrier control service will process messages for the carrier specified. Each message
processed will be handed to the interface routine specified on the interface record on DE.INTERFACE,
and will be handled accordingly. Incoming messages received from the inward interface routines will
be placed on the Unformatted Inward queue. When an acknowledgement received from swift for
outward messages, their OSN (6 digit number as available in Basic header (1)-field position from 23 to
28) is updated in OSN.NO in application DE.SENT.SWIFT.

The T24 services can be run on-line or automatically during the close of business (cob). Provided as
standard are one for the outward generic service and one for the inward. Records on
TSA.WORKLOAD.PROFILE and TSA.SERVICE called DE.CC.GENERIC.OUT and DE.CC.GENERIC.IN

If you wish to segregate each carrier and have a service for each one then new BATCH, TSA.SERVICE
& TSA.WORKLOAD.PROFILE record needs to be created.
The inward generic service works on the messages, which are fed, into T24 system by the interface.
There are 2 sources in which T24 system can receive messages for inward processing.

One is from IN.IF.ROUTINE attached in the DE.INTERFACE file. This routine passes 1 message at
a time and in DE.CC.GENERIC, this runs in a loop until there is no message received. In the
service, this routine (if attached) will be called in a loop for about 20 items with some pause. So,
approximately, there will be 20 messages received by the system. The information passed by the
IN.IF.ROUTINE will be written into a work file called DE.GEN.IN.WORK. The information
includes the reference to the message, actual message, header record (details of some fields like
priority), code and the error message (if any). The actual process routine will read all this
information with the reference passed in to the routine and process the message normally. After the
message is processed, the details in the work file are deleted.

There is another file in which the messages will be written, which is the DE.O.MSG. <Interface>
file. The interface routines (written locally) will write the messages in to this file and the T24
system can simply select this file and process the messages.

SWIFT carrier control

Messages can be received on the SWIFT mainframe (e.g. an ST400) from the SWIFT network. On the
SWIFT mainframe it is possible to specify that particular message types should be directed to the
mainframe on which T24 is running. If any message is received which should be sent to T24, it will be
processed by the Inward SWIFT carrier control module, DE.I.CC.SWIFT. Since this module is
required for processing the ACKs and NAKs to outward messages, it will always be running if
outward messages are being sent.

When messages are sent from the SWIFT mainframe, integrity checking is performed to ensure that
the message is correctly received by T24. If the message fails the integrity checking, an attempt is
made to resend the message. If the integrity checking fails again, it is assumed there is something
wrong in the communication between T24 and the SWIFT mainframe and the SWIFT carrier control
process is terminated, with a message being written to the Syslog file. See the section "Syslog
display/clear" for displaying this message.

If a message is received from the SWIFT mainframe, it is placed on the Inward Unformatted queue.

See the section "Detailed flow of outward messages - SWIFT carrier control" for details of how
ACKs and NAKs to outward messages are processed by DE.I.CC.SWIFT.
Flow diagram - Incoming SWIFT messages

SWIFT link

DE.I.CC.SWIFT
phantom
or
DE.CC.GENERIC
T24 service

F.DE.MESSAGE D.DE.I.MSG F.DE.PRI

DE.I.SELECT.NEXT.MESSAGE
F.DE.I.HEADER
phantom

F.DE.I.MSG.ap F.DE.I.PRI.ap

ap.IN.PROCESSING
phantom

Fxxx.application$NAU F.DE.RECEIVED.SWIFT
ap application

FT FUNDS.TRANSFER

LC LETTER.OF.CRDIT

Figure 44 - Structure of Incoming Swift Messages

Test key verification
If an inward Telex message is specified as requiring a test key (i.e. the "Test key req." field on the
Message table is set to "Y") and the Telex carrier control process detected a test key in the message, the
message is placed on the Awaiting Test key Verification queue.

Test keys may be verified by using the verify test key application, DE.VERIFY.TESTKEY. On
entering this application, all messages currently awaiting verification are displayed. The list may be
refreshed by entering "R". This will remove from the displayed list, all messages which have been
verified in the current session. A message can be selected by entering the line number of the message.
The cursor may be moved up and down the list of messages in the normal way. Entering "I" for a
message will enable the test key to be verified and will display the message on the screen (which may
also be paged through). Note that test keys may or may not be displayed in the message depending on
the setting of "Display test key" on the Parameter table (DE.PARM). If the test key entered does not
match the test key in the received message, the message will be sent to the Repair queue after the
maximum number of verification attempts allowed ("No. verify attempts" on the parameter table).
Once the test key is correctly verified, the message will be placed on the Inward Unformatted queue
with a Disposition of "Unformatted". After the test key has been input, the screen display will return to
the list of messages awaiting verification.

Formatting
The Inward formatting process, DE.I.SELECT.NEXT.MESSAGE, takes messages from the Inward
Unformatted queue and uses the format SWIFT (DE.FORMAT.SWIFT) and format TELEXF
(DE.FORMAT.TELEXF) tables to decode the messages. If there is a problem with the decoding, the
message is placed on the Inward Repair queue. However, if decoding was successful, the message is
put onto the Inward Message queue for the appropriate banking application, as specified on the
Message record (DE.MESSAGE). The default application is Funds Transfer. The Inward Routing
table (DE.INWARD.ROUTING) is used to mark messages for the attention of particular
departments, depending on the values of selected fields in the Header record.
DE.MONITOR

Either run direct or as an ENQUIRY DE.MONITOR will show the state of the inward/outward queues
and when refreshed to new message count is displayed.

Here is an example of the screen (it’s a mock-up hence the message counts are all the same):

Summary of Delivery Tables

Contained in this section is a list of all the tables used in the Delivery system, with a brief
description of each. Also, there is a note showing where each table is referenced in this manual.
This is not a complete list of all the references for all the Delivery tables, but just the most
important references. For a more detailed description of each table and its function, please refer to
the corresponding Help text or to the sections referenced below.

DE.ADDRESS
Contains the names and addresses of a bank's customers and also of each company within the banking
organisation.

Referenced in: Address table

DE.ALTERNATE
Used when re-routing a message, to specify an alternate carrier is to be used, or format, or language.

Referenced in: Alternate table

Re-routing messages

DE.BATCH.GROUP
Contains a list of all batch groups for Telex messages, containing which message types should be
assigned to the batch group if the message is suitable for batching.

Referenced in: Detailed flow of outward messages - Batching Telex messages

DE.CARRIER
Contains details of all the carriers available in Delivery. This file is delivered populated with all
currently available carriers. To enable a carrier (i.e. to be able to use it), you must specify it on the
Delivery Parameter file, DE.PARM.

Referenced in: Carrier table

DE.DEPT.PRINTER
Defines the printer id for each department and form type entered. This table is not used by print carrier
control but is used as the standard method for directing all T24 output.

DE.DISP.CONTROL
Specifies conditions, which require the special treatment of messages matching those conditions. E.g.
holding, re-routing, etc.

Referenced in: Disposition control

DE.FORM.TYPE
Defines the width and depth of each printed form type, stating which printer it is to be output on and
any printer attributes that may need to be output. Also used by the T24 batch system.

Referenced in: Creating and amending print format definitions

DE.FORMAT.PRINT
Defines the different versions and formats required for each printed message output by Delivery.

Referenced in: Creating and amending print format definitions

DE.FORMAT.TEMPLATE
Defines the different versions and formats required for each message which is passed by Delivery to
Word for merging with a pre-defined template and spooling to a local or network printer.

Referenced in: Delivery WORD link

DE.FORMAT.SWIFT
Defines how the data content of each message type is to be converted for SWIFT.

Referenced in: Detailed flow of messages - Formatting

DE.FORMAT.TELEXF
Defines how the data content of each message type is to be converted for fixed format Telex (Telexf)
messages.

Referenced in: Creating and amending fixed format Telex definitions

DE.FORMAT.TELEXP
Defines the different versions and formats required for each free format Telex message (Telexp) output
by Delivery.

Referenced in: Creating and amending free format Telex definitions

DE.I.HEADER
Contains the controlling information for each inward message received by Delivery. It is updated
during the flow of the message through Delivery with details of the current disposition of the message.

Referenced in: Detailed flow of inward messages

DE.I.HEADER.ARCH
Contains the controlling information for inward messages, which have been successfully handed to a
banking application, or deleted, and have been archived to the history files.

Referenced in: History display

DE.INTERFACE
Contains details of the protocols for all interfaces which use the Generic Delivery Interface.

Referenced in: Interface table

DE.INWARD.ROUTING
Used to mark inward messages for the attention of particular departments.

Referenced in: Detail flow of messages - Inward formatting

DE.MAPPING
Defines where data for outward messages and message headers is located within the raw message data
passed to Delivery from the banking applications.

Referenced in: Detailed flow of messages - Application handoff

DE.MESSAGE
Contains the contents of each basic message type, listing the fields, describing them as single or multi-
value and stating whether each field is mandatory or optional. Also specifies whether messages of each
message type can be deleted, copied or translated and whether test-keys are required for Telex
messages.

DE.O.HEADER
Contains the controlling information for each message generated by the banking applications. Is
updated during the flow of the message through Delivery with details of how copies of the message
have been formatted and the current disposition of each copy.

Referenced in:

Detailed flow of outward messages

Repairing messages

Holding/releasing messages

DE.O.HEADER.ARCH
Contains the controlling information for outward messages which have been successfully sent, or
deleted, and have been archived to the history files.

Referenced in:

History display

DE.PARM
Contains a single record, SYSTEM.STATUS, holding parameters used for controlling the Delivery system
and the processing of messages.

Referenced in:
Starting/Stopping queues

DE.PRODUCT
Used by outward formatting to determine to whom a message should be sent, by which carrier it
should be sent, whether copies are required, which format should be used and whether the status or
disposition of the message should be amended.

Referenced in:

Product table

Detailed flow of outward messages - Formatting

DE.STATISTICS
Enables user to specify various statistical reports of messages within Delivery.

Referenced in:

Statistical reporting

DE.SWIFT.BOOK
Contains the names and addresses of all banks that use SWIFT.

DE.TRANSLATION
Used to convert codes contained in messages into descriptive text, in various languages.

Referenced in:

Translation file/set-up translation

Creating and amending print format definitions

DE.AUTO.TRANSLATION
The successor to the above application, this one will allow you to store the details of the codes and
whether they are replaced or updated. It is also possible to use the field to retrieve the text from.

DE.MT942.REQUEST
Used for the production of ad-hoc account statements for a specified account.

DE.WORDS
Used to convert numbers to words, in various languages. Used in print and Telexp formatting.
Summary of Outward Dispositions

The following lists, which queue an outward message, can be found in depending on the value of
disposition and message disposition. It does not take into account unauthorised changes to these
fields.

Figure 69 - Summary of Outward Dispositions

Summary of Inward Dispositions

The following lists, which queue an inward message, can be found in depending on the value of
disposition. It does not take into account unauthorised changes to this field.

Figure 70 - Summary of Inward Dispositions

DELIVERY

Overview of Input and Processing

General Flow of Messages

Most on-line transactions within T24 will send messages. For example, when a Funds Transfer
transaction is entered and approved it will usually require the sending of a credit advice to one address
and a debit advice to another, together with one or more payment cables. In addition, some overnight
processing, such as the processing of standing orders, will require the sending of payment messages.

When an on-line transaction or overnight process requires the sending of a message, the Delivery
process APPLICATION.HANDOFF is invoked. This passes all the details of the message to the
Delivery system, whilst passing back a unique identifier to the application, the Delivery message id and
the message is then mapped.

The main processes within Delivery, i.e. formatting and the carrier control processes, are run as
phantom jobs, normally running continuously throughout the day and during the Close of Business
processing, only being stopped for the backups to be taken. Some are currently using T24 services and
are detailed in the sections of this document explaining the inward and outward processing.

The mapping stage examines raw data created by the application a Header record as well as a
Message Detail record are created, using the mapping rules described on the Mapping table
DE.MAPPING. The message is then placed on the Un-formatted queue.

The formatting process DE.O.SELECT.NEXT.MESSAGE examines the Unformatted queue, in

chronological order within priority for any messages to be formatted. The appropriate Product
record DE.PRODUCT is read to determine to whom the message should be sent, how many copies
and which carrier should be used. The carrier, as specified on the product table, is used to access
the carrier table, DE.CARRIER. This file contains the carrier to be used for formatting, address table
look-ups, the carrier module and the interface to be used. E.g. the product table specifies a carrier of
TELEX. The carrier record specifies for telex that “TELEX” should be used for the address record
look-ups, “SWIFT” should be used for formatting, the “GENERIC” carrier control program should
be used and the interface should be “TELEXBOX”. The Address table DE.ADDRESS is accessed to
determine the address to which the message should be sent, e.g. the print address, the SWIFT id, the
Telex number, etc. The appropriate format table (e.g. DE.FORMAT.PRINT, DE.FORMAT.SWIFT)
is read to determine how the message should be formatted, producing a formatted print message,
formatted SWIFT message, etc. The formatted message is then placed on the appropriate Formatted
queue e.g. Formatted SWIFT, Formatted Print, etc. However there can be various exceptions, as
follows:

• If a message is to be held, e.g. it is not required to send the message out until business reopens in
Tokyo at the start of the next working day the message can be placed on the Hold queue.

• If the message is being sent by Telex, the message might be specified as being suitable for
Batching, in which case it will be placed on the Batching queue. Once a batch is complete, it will
be removed from the Batching queue.
 • If the message is being sent by Telex, the message might require the input of a test key, in which
case the message will be placed on the Awaiting test key queue (this may include batched
messages). Once the test key has been input and authorised, the message will be placed on the
Formatted Telex queue.

• If an error was detected during the formatting of the message, the message will be placed on
the Repair queue. It will stay in the Repair queue until the Delivery Operator corrects the
problem and resubmits the message. Messages can also be placed on the Repair queue at any
stage in the processing of messages within Delivery. It is the responsibility of the Delivery
Operator to examine the contents of the Repair queue regularly and correct any problems
highlighted.

The time check process DE.MM.TIMECHECK that runs as a phantom, continuously examines the
Hold queue to see if there are any messages that should be released. E.g. If a message was to be held
until 16:00 and it is now past that time, the message should be released. Released messages are
removed from the Hold queue and placed on the appropriate formatted queue. Note: For Telex
messages, messages will be placed on the Batching queue, Awaiting Test key queue or the Formatted
Telex queue.

There are separate carrier control processes for each of the carriers defined in the Delivery system, e.g.
DE.O.CC.SWIFT, DE.O.CC.PRINT, DE.CC.GENERIC. The carrier control processes are also run as
phantoms.

The print carrier control process DE.O.CC.PRINT sends the print formatted messages to the
appropriate spool queues, placing a copy of the formatted message on the History file.

The SWIFT carrier control process DE.O.CC.SWIFT sends the SWIFT formatted message to the
SWIFT device, e.g. an ST400. Integrity checking exists within the ST400. If this fails, the message will
be rejected immediately, but normally the message will be sent to the SWIFT network. The message
will then be placed on the Awaiting acknowledgement queue.

The Inward SWIFT carrier control process DE.I.CC.SWIFT will receive the resulting
acknowledgement (ACK) or negative acknowledgement (NAK) from the ST400 for messages sent out
by the outward SWIFT carrier control process DE.O.CC.SWIFT. If an ACK is received, the message
will be removed from the Awaiting acknowledgement queue, flagged as having been sent correctly and
a copy of the formatted message placed on the History file. If a NAK is received, the message will be
removed from the Awaiting acknowledgement queue and placed on the Repair queue. The Inward
SWIFT carrier control process can also receive messages from the SWIFT network destined for
GLOBUS. Messages are placed on the Unformatted Inward queue.

SWIFT messages can be sent to/from either the ST400 or Alliance using the CASmf protocol. This is
achieved using the generic delivery phantom (DE.CC.GENERIC) – see the Application Installation
User Guide for more information.

The Generic carrier control service will process messages for any carrier using the generic interface
(i.e. the CARRIER.MODULE in DE.CARRIER is specified as “GENERIC”). Each message processed will
be handed to the interface routine specified on the interface record on DE.INTERFACE, and will be
handled accordingly. If ACKs are required (ACK.REQUIRED is set to “Y” on DE.INTERFACE), the
message will be placed on the awaiting acknowledgement queue. When the ACK is received (from the
inward routine), or if ACKs are not required, the message will be flagged as having been sent correctly
and a copy of the formatted message placed on the history file. If a NAK is received, the message will
be removed from the awaiting acknowledgement queue and placed on the repair queue. For each
generic carrier, incoming messages received from the inward interface routines will be placed on the
Un-formatted Inward queue.

The Inward formatting process DE.I.SELECT.NEXT.MESSAGE takes formatted SWIFT and Telex
messages and reformats them into the raw message details similar to how the message would have
been produced by the T24 applications. The message is then placed on the Inward Formatted queue, to
be processed by the appropriate T24 application, usually Funds Transfer. If an error is detected in the
reformatting of a message, it is placed in the Inward Repair queue, for the Delivery Operator to correct.

Starting/Stopping Queues

Whereas input and maintenance of the tables controlling the Delivery System is performed on-line
from a terminal, the processing of messages is done by "phantom" processes, which run all day
without being attached to a particular terminal. To determine the current status of the processes
controlling the queues, check the SYSTEM.STATUS record on the Delivery Parameter table,
DE.PARM. The status fields are as follows:

Field name Process

SHUTDOWN.INWARD Inward formatting
SHUTDOWN.OUTWARD Outward formatting
SHUTDOWN.TIMECHECK Time check
SHUT IN CARRIER Inward carrier control for the carriers named in
INWARD.CARRIERS
SHOUT OUT CARRIER Outward carrier control for the carriers named in
OUTWARD.CARRIERS
Figure 1 - Delivery Parameter Record Status Fields

The status fields can have the following values:

Figure 2 - Status Field Parameters

Starting queues (DE.PHANTOM)

The phantom processes are initiated by using the application DE.PHANTOM. This prompts for the
name of the process to be run, checks that the process is not already active, starts the process and sets
the status flag to "A" - active. The operator can then either initiate another process or use F1 to exit.

Function required Process Name

Outward formatting DE.O.SELECT.NEXT.MESSAGE
Outward carrier control for:
SWIFT DE.O.CC.SWIFT
Print DE.O.CC.PRINT
 Inward carrier control for:
SWIFT DE.I.CC.SWIFT
Time check (releases held msgs) DE.MM.TIMECHECK
Inward formatting DE.I.SELECT.NEXT.MESSAGE

Alternatively, DE.PHANTOM XXXXXXX where XXXXXXX is the process name can be entered
directly at the "Awaiting application" prompt or, the simplest method, the menu DE.OP can be used to
start the processes.
The print carrier control process can be run attached to a screen, i.e. interactively rather than as a
phantom, by entering DE.O.CC.PRINT at the "Awaiting application" prompt. This gives the
advantage of the user being able to select a specific form type, priority and department, but can
result in the screen being tied up for a considerable length of time. If the print carrier control
process is run as a phantom all form types, priorities and departments are printed.

Stopping queues

The phantom processes can be stopped by updating the status fields in the SYSTEM.STATUS record on the
Parameter table, DE.PARM to:

• "N" to give a "normal" shutdown after processing all messages on the relevant queues.

• "U" to give an "urgent" shutdown after the current message has been processed.

• NOTE: The system status record must be authorised before shutdown can commence.

Starting/stopping queues in batch processing

Before the start of batch and start of day backups are performed in the Batch Processing, the
Delivery phantoms are checked to see if they are running. If they are active, the batch process will
shut them down. If the batch process is unable to close the phantoms, the batch process will
terminate. After the backups have been performed, the delivery phantoms (i.e. those which were
active before the backups) will be restarted.

Displaying the State Of Messages

Each message passed to Delivery from an application or Close of Business process or received from an
external device such as SWIFT or Telex is given a unique identifier, the message id. The message id is
composed as follows:

XYYYYMMDDNNNNNSSSSSSQQ where
“X” "D" - message is to be delivered (outward message) or
"R" - message has been received (inward message)
"NNNNN" is the system user number of the inputter
"YYYYMMDD" is the date
"SSSSSSS" is the time in seconds since midnight
"QQ" is the sequence number of transactions within a second

This unique key is used throughout the life of the message regardless of which queue the message is
currently in. Once the message has been through mapping, a record is created on the Header file
(DE.O.HEADER) with this key. To check the current state of the message, “See the record on the
Header file. There are two state fields on the Header record: DISPOSITION and
MESSAGE.DISPOSITION.

When the message has been through mapping, but has not been formatted, the outward header record is
created with a DISPOSITION of "Un-formatted". If mapping fails, the DISPOSITION is set to "Repair".
During formatting, the DISPOSITION is temporarily set to "Selected" before being reset to
"Formatted". This DISPOSITION field refers to the message as a whole and is set to "formatted", even
though individual copies of a message may be in repair.

Formatting causes the Header record to be expanded to include a multi-value set of data for each copy
of a message, each with its own "message disposition" field. If a problem prevents the expansion of a
message, such as a missing DE.PRODUCT record, then the DISPOSITION will be set to "Repair".
However, problems that relate to the detailed formatting of message fields result in the DISPOSITION
field being set to "Formatted" and a MSG.DISPOSITION of "Repair" being set in the appropriate place
in the multi-value fields at the end of the record. From this point on, the individual copies of each
message will be dealt with separately and can be placed on separate queues. So that it is apparent
which copy of the message is on which queue, the message id is appended with the copy number:

XYYYYMMDDNNNNNSSSSSQQ.C where C is the copy number

Once a message has been formatted, each copy of the message is put on the formatted queue
appropriate to the carrier with a MSG.DISPOSITION of "Formatted". However, if the carrier is TELEXP
and the message is of normal priority, the message will be placed on the Batching queue if batching is
required for this message. Messages to be batched will be placed on the Batching queue with a
MSG.DISPOSITION of "BATCHING" until the batch is complete. Completed batches and individual
Telex messages which do not require batching are put on the Awaiting test key queue if a test key is
required, with the MSG.DISPOSITION set to "ATK" - awaiting test key. Once the test key has been
entered successfully, the message is placed on the formatted queue, with a MSG.DISPOSITION of
"FORMATTED".

Carrier control modules for both SWIFT and Telex pass the message to the carrier device and set the
msg disposition to "WACK" - awaiting acknowledgement. If the message is successfully received by
the recipient (the carrier device receives an acknowledgement), the msg disposition is set to "ACK" -
acknowledged.

MSG.DISPOSITION of Resubmitted and Rerouted can also exist. See sections "Repairing messages"
and "Rerouting messages" for more information.

Displaying Message Queues

DE.MM.DISPLAY

ALL the message queues within Delivery can be viewed from the message management display
function. To invoke this function, enter DE.MM.DISPLAY at the "Awaiting application" prompt.

A menu will be displayed, an example of which is as follows:

 Figure 3 - Display Message Queues within Delivery

The Batching queue is only displayed if the Batching Req field on the Parameter queue is set to "Y".

The number and order of “carrier” queues (e.g. SWIFT, TELEX) depends on the outward carriers on
the DE.PARM file and the order they are specified in. If the "GENERIC" carrier is specified in outward
carriers (OUTWARD CARRIER), the carrier file, DE.CARRIER, is examined and each generic interface is
then displayed, showing the name of the carrier (the id on DE.CARRIER) and the interface.

From each option a list is displayed of the messages on the appropriate message queue. The user
can choose one message listed on the screen by entering its line number, or go to the next page of
the list by pressing F3, or go to a particular page of the list be entering a page number (such as
"P3").
 Figure 4 - List of messages on appropriate message queue from DE.CARRIER

When a line number has been selected the Message Header can be "Seen" by entering "S", amended
("Input") by entered "I", authorised by entering "A" or printed by entering "P". When a message has
been formatted (on all message queues except Un-formatted), the additional facility to view the
formatted message (as opposed to the header record) by entering "V" is available. After "V", the
system gives the following option:

Figure 5 - View the Swift Message

When a formatted message is displayed (function V followed by D), if the message is more than 79
characters wide, the message can be paged left and right by using F7 and F8 respectively. Also, by
entering P5 for example, the display goes to what would have been page 5 of the formatted printed
message, not page 5 of the screen display.

Figure 6 - Display formatted message

If the formatted message is printed (function V followed by P), the bottom of each page will have "**
COPY ** COPY ** COPY **" printed across it.

Several options are also available on batched messages in the Test key or Outward carrier queues.
When a line number corresponding to batch message is entered, the contents of the batch may be
displayed by entering "X". The Delivery reference of messages in the batch are listed and an
individual message may be selected for input ("I"), seeing ("S"), authorisation ("A") or printing
("P"). When the batched message is viewed ("V"), the complete batch message will be displayed or
printed. The batch cannot be viewed from the screen of the expanded batch, only from the list of
queued messages.
Bar charts (DE.MM)

Message management, DE.MM, is used to access a range of bar charts, which give concise
information about the flow of messages within the Delivery system.

There are bar charts showing message volumes for each queue of messages. For each queue,
displays are broken down by priority and by carrier. Additionally, there are the following displays,
broken down by message type:

• Messages being held

• Messages awaiting batching
• Formatted messages that are ready for output
• Messages on the outward repair queue
• Messages on the outward test key queue
• Messages on the inward repair queue
• Messages on the inward test key queue

Keys 1 - 4 allow the scale of the bar charts to be set to the following ranges:

1 0 - 20 messages on screen
2 0 - 200 messages on screen
3 0 - 2000 messages on screen
4 0 - 20000 messages on screen

This will permit the user to "tailor" the bar chart to suit the information being displayed. For example,
the user could choose a detailed chart of the short queues, then switch to a small scale to put the longer
queues into perspective.

When a bar chart has too much information to fit across the screen, the chart can be scrolled right by
using F8, then scrolled back to the left by using F7.

To exit the bar chart, enter F1 or "Q".

Figure 7 - Bar chart showing messages awaiting transmission

 Figure 8 - Bar chart showing messages awaiting transmission – by Message Type

Reprinting messages

It may be required that messages need to be reprinted. For example, a customer did not receive a
particular advice or statement. A printed image can also be obtained for messages, which were
originally sent out by another carrier, e.g. SWIFT or Telex.

To reprint or view the message, the original Delivery id must be known. This can usually be found out
from the original application, e.g. if the Funds Transfer transaction number is known, since most
applications hold the Delivery id on the transaction record.

If the Delivery id is not known, examination of the Delivery queues may be necessary, either through
DE.MM.DISPLAY (see section "Displaying message queues") or DE.MM.HISTORY.DISPLAY (see
section "History display"). On both these displays, certain information is shown on a summary screen,
making it easier to find the message concerned. Alternatively, the T24 list function could be used on
the Delivery header file (DE.O.HEADER) or the Delivery header archived file
(DE.O.HEADER.ARCH) to select records with particular criteria.

If the message is still on the live files (i.e. DE.O.HEADER), it may be possible, if required, to
produce another copy of the message by resubmitting the message (see section "Repairing messages
- Resubmitting messages at other stages"). NOTE: Resubmitting a message has the following
limitations:

(i) Certain message types do not allow copies, so the message cannot be resubmitted.
(ii) The message will be marked as being a copy and will have the copy text specified on the
format print record (DE.FORMAT.PRINT).
(iii) The message will have to go through formatting and carrier control and so will not produce an
instantaneous copy such as described below.

If the message was found through the displaying queues or displaying history queues applications,
the function "V" to view the message can be taken, followed by "D" to display the message on
screen or "P" to print the message. NOTE: Printing the message this way will have the following
limitations:
 (i) The bottom of the page will have "** COPY ** COPY ** COPY **" printed across it.
(ii) The message will be printed on the printer assigned to the terminal requesting the reports (not
necessarily the same printer that the original message was printed on)
(iii) The message will be printed on default stationery.

DE.MM.PRINT.MSG

If the Delivery id is known, the message can be printed or displayed on screen using the application,
DE.MM.PRINT.MSG. This is similar to the "V" function in DE.MM.DISPLAY and
DE.MM.HISTORY.DISPLAY. It also has the same limitations described above as the "V" function.
The main advantage is that when the Delivery id is known, the message can be printed directly from
this application, rather than going through the queues display described above.

On entering the DE.MM.PRINT.MSG application, the user is prompted to "Enter D (Display) or P

(Print) or <RETURN> to end".

When "D" or "P" is chosen, the user is requested to enter the Delivery id. This may either be the
Delivery Header id, the full id including the copy number of the message or a batch number. If a
specific copy is requested then only that copy will be displayed, otherwise each copy of the message
will be printed, or displayed on screen by pressing F1, before returning to the prompt to enter another
Delivery id. If a batch number was entered, the complete batch message will be displayed or printed.

Whether a message is on "Hold", ready for carrier control, awaiting a test key or batching, or in history,
if it has been formatted, it can be displayed.

When a message is displayed on screen, the following facilities are available:

(i) F2 and F3 go backwards and forwards through the display in the normal way.

(ii) If the message is more than 79 characters wide, the display can be paged left and right by using
F7 and F8 respectively.

(iii) It is possible to go directly to a particular formatted page of a printed message. For example, P5
displays what would be page 5 when printed, not screen 5.

Repairing Messages

There are numerous reasons why messages go into repair, i.e. there is something wrong with the
message, which the Delivery Operator should investigate and, hopefully, be able to correct. However,
once all the Delivery tables are set up, messages should rarely go into repair.

As already described in the section "Displaying the state of messages", there are two disposition
fields on the Delivery header record. Either of these could contain a disposition of "Repair".
Associated with each of the disposition fields is an error code field. If the disposition is set to
"Repair", the message will be in the Repair queue and the associated error code field will have a
description of the error that occurred.
Mapping

Errors occurring in mapping are very unusual. If an error has occurred in mapping, it indicates that
there is an error in the application, which produced the message. The disposition will be set to
"Repair", the error code will have an error message indicating an error occurred during mapping
and the multi-value message set at the end of the header record will not have been expanded. Errors,
which occur in mapping, cannot be corrected in Delivery by resubmitting the message. The user,
possibly with the help of the TEMENOS Help Desk, must determine the problem within the
application, which called Delivery. Once the error has been resolved, the message can be deleted
within Delivery. This is achieved by amending the Delivery Header record, changing the
Disposition to "Delete" and authorising the record. The message will be removed from the Repair
queue. The header record will still be accessible on the Delivery Header, but no further action can
be taken with the record.

Formatting

There are two areas into which formatting errors fall. The first area is before the Product record is
read. Any errors occurring during this stage of formatting will be reported in Disposition with the
associated error message in Error code. The message will then be placed on the Repair queue. To
correct the message, first of all investigate what caused the error, for example, a missing Product
record. Once the cause of the error has been corrected, e.g. by adding the Product record to the
Product table, the message can be resubmitted. This is achieved by amending the Delivery Header
record, changing the Disposition to "Resubmit" and authorising the record. The Disposition will be
changed to "Resubmitted", the error message removed; the message will be removed from the
Repair queue and added to the Un-formatted queue for a further attempt at formatting.

Figure 9 – Display Formatting errors queue – message placed on Repair Queue

The other type of error, which can occur during formatting, is after the Product record has been
read. Once the Product record is read, the multi-value message set at the end of the Delivery header
record is expanded with details of all the copies of the message to be produced. For example, two
copies of a message may be required, one to be sent by Telex and one to be printed. Therefore, the
multi-value set will have the details of the two copies of the message. Once the multi-value set has
been added to the Header record, the DISPOSITION will be set to "Formatted" and the user should
look at the MSG.DISPOSITION field and associated MSG.ERROR.CODE field to determine the state of
the message. From this point on in Delivery, the copies of the message will be treated separately.
When a copy of the message appears in a queue, the Delivery id will have the copy number added
to it so the user can determine which message copy is being processed.

Figure 10 – Formatting Error after Product has been read

 Figure 11 – Two copies of a message may be required – Messages are treated separately

E.g. a message DYYYYMMDDNNNNNSSSSSQQ has two copies: copy 1 is to be sent by Print,

copy 2 is to be sent by SWIFT. Copy 1 has been formatted and is on the Print carrier control queue;
copy 2 is in Repair because the SWIFT address for the addressee cannot be found. If the user were
to look at the queues (through DE.MM.DISPLAY), he would see message
DYYYYMMDDNNNNNSSSSSQQ.1 on the Print carrier control queue and message
DYYYYMMDDNNNNNSSSSSQQ.2 on the Repair queue.

Most errors, which occur during formatting, would normally be because an Address record is
missing. To correct the error, add the Address record to DE.ADDRESS, amend the DE.O.HEADER
record changing the MSG.DISPOSITION to "Resubmit" and authorise the record. The
MSG.DISPOSITION will be changed to "Resubmitted" and a new multivalue set will be added to the
end of the record with the same details as the message being resubmitted. The MSG.DISPOSITION
on the new multivalue set will be set to "Resubmit". This is so that the history of the message is
available, with the fact that the first time an attempt was made to format the message an error
occurred, the error message still being set on the original copy of the message. When the message is
resubmitted, the message will be added to the Unformatted queue for another attempt at formatting
and removed from the Repair queue. The message sequence number of the new message will be
included in the key of the record on the Unformatted queue. In the example above, if copy number 1
was resubmitted, message DYYYYMMDDNNNNNSSSSSQQ.3 would be added to the Unformatted queue.
 Figure 12 - Example of NETTING.AGREEMENT record

Resubmitting messages at other stages

Messages may be resubmitted not only from the Repair queue, but also when they have been
successfully formatted. However, if copies are not allowed (COPIES on the DE.MESSAGE record is set
to "NO") for the message type being processed and the MSG.DISPOSITION is "ACK" (acknowledged -
the message has been successfully sent) or "WACK" (awaiting acknowledgement - the message has
been sent but the acknowledgement that it has been received successfully by the recipient has not been
received yet), the message cannot be resubmitted.

If a message with a MSG.DISPOSITION of "ACK" or "WACK" is resubmitted, its MSG.DISPOSITION

becomes "ACK - RESUBMITTED" or "WACK - RESUBMITTED" and a new copy is generated as
described above.

Once the Product record has been read successfully (i.e. the multi-value set has been expanded),
subsequent attempts at formatting will not read the Product record again.

Messages in the Test key queue and the Batching queue may also have their disposition changed to
"Resubmit". The MSG.DISPOSITION is changed to "Resubmitted" and a new message copy is
generated as described above, placing the new copy on the Un-formatted queue. Completed batches of
Telex messages, which have a message, removed from them will be re-completed and placed back on
the Test key queue.

Completed Telex batches elsewhere in the Delivery system, which have messages removed from them
are re-completed. The changed batch will then be placed back in the carrier queue it was originally
located in or returned to the test key queue if a test key is required for it. The individual message
removed is then treated in the same way as a resubmitted message.
Holding/Releasing Messages

Within Delivery, it is possible to hold messages indefinitely, for a length of time or until a certain time.
To hold a message means that the message will go through formatting normally, but will not be placed
on the appropriate carrier control queue until the wait time has elapsed, the time the message is to be
held until has passed or the message has been released. Instead of being placed on a carrier control
queue, the message is placed on the "Hold" queue. The time check phantom (DE.MM.TIMECHECK)
continuously examines this queue to determine if there are any messages to be released. If a message is
found which should be released, it is removed from the Hold queue and added to the appropriate carrier
control queue. However, if the message is to be sent by Telex and batching is required, the message
will be added to the Batching queue. Similarly, if the message is to be sent by Telex and batching is not
required but a test key is, the message is added to the Test key queue.

An application may pass a message to Delivery as "Hold", "Wait hh:mm" or "Hold hh:mm" already
specified. If a hold requirement is passed to Delivery, during Mapping the hold details are used to
update the Status field on the Delivery header record. Wait times are always added to the current time
to produce a status of HOLD hh:mm.

During formatting, when the Product record is read, the status on the Header record may be updated
with the status details on the Product record. The status details on the Product record will not override
any status details passed from the banking application.

Status can be amended on the Delivery Header record (DE.O.HEADER) before the multi value set has
been expanded, i.e. when the message is Un-formatted or in repair before the Product record was read.
Status can be changed to HOLD, HOLD hh:mm, WAIT hh:mm or RELEASE (RELEASE can only be
entered if status is currently HOLD or HOLD hh:mm). When the record is authorised, RELEASE will
remove a status of HOLD or HOLD hh:mm; WAIT hh:mm will be translated to HOLD hh:mm.

Before formatting, the STATUS field is not used and the record will be processed during formatting as
normal. However, when the multi-value set at the end of the Header record is added, the contents of
STATUS will be used to update each value of the MSG.STATUS fields. Once each copy of the message is
formatted, the copies will be added to the Hold queue if appropriate.

If a message has been formatted but has not yet been sent by a carrier (i.e. MSG.DISPOSITION is not
"WACK" or "ACK"), the MSG.STATUS can be amended on the Delivery header record. As for
status, the MSG.STATUS can be changed to HOLD, HOLD hh:mm, WAIT hh:mm or RELEASE.
Once the record is authorised, if the message is to be held, it is removed from the current queue and
added to the Hold queue. If the message is to be released, it is removed from the Hold queue and
added to the carrier control queue, Test key queue or Batching queue as appropriate. In addition,
messages can be held by specifying particular requirements on the disposition control table
(DE.DISP.CONTROL). This table is read during formatting to see if any of the conditions match.
See the section on "Disposition Control table - DE.DISP.CONTROL" for more information.

Re-routing Messages

There may be circumstances when it is required that messages should be sent either to a different
address from usual or via a different carrier. For example, if a customer's Telex is out of order, they
may wish all their Telex messages to be sent to a different number. Alternatively, if the bank's
connection to SWIFT is not working, they may wish to send everything out by print.
If a message is to be rerouted, the Alternate table (DE.ALTERNATE) is accessed as described in the
section "Alternate table", for the carrier, address number, language, format and copies the message
should be sent to.

There are various different ways messages may be rerouted. It is up to the customer to decide which
method best suits the current situation.

Header record

The simplest method of re-routing messages is to update the header record (DE.O.HEADER). This
method can be used when the Delivery id of the message is known and only a few messages are to be
re-routed or when a message has gone into Repair because of an error in the carrier or the carrier
address.

The MSG.DISPOSITION field on the Header record should be updated to "Reroute" and authorised.
The MSG.DISPOSITION will then be updated to "Rerouted", the message removed from the current
queue, the multi value set expanded according to the details on the Alternate table and the new
message (or messages) added to the Un-formatted queue. Note: More than one copy of message
may be generated from one message being rerouted. E.g. A SWIFT message being rerouted may be
replaced by a Telex message and a Print message.

Disposition control

Messages can be rerouted by specifying particular conditions, which must be met on the Disposition
control table (DE.DISP.CONTROL). This table is read during formatting to see if any of the
conditions match. See the section on "Disposition Control" for more information.

Processing Inward Messages using OFS.GLOBUS.MANAGER

SWIFT Inward Message Subroutines and Local Development TEMPLATE.S

Certain SWIFT payment messages are processed using the Inward Delivery
OFS.GLOBUS.MANAGER method. This generic method relies on OFS.GLOBUS.MANAGER and
on message specific and Tag-field specific subroutines to improve functionality and maintainability
and allow the flexibility of locally developed message subroutines, and has been developed largely
in response to increased STP requirements.

The supported Messages are MT101, MT103, MT200, MT205, MT210 (more will be converted to
this method in the future). A subroutine is provided for each of these messages, although this may
be replaced by a locally developed routine if required: a template subroutine, TEMPLATE.S, is
provided for this purpose (please refer to an Account Manager for details).

SWIFT Inward Tag field Processing Routines - DE.I.SUBROUTINE.TABLE

Inward Tag Processing routines named DE.I.TAGxx (where xx is the SWIFT Tag field number) are
supplied for all supported SWIFT Tag fields. Local type S subroutines may be substituted.

The DE.I.SUBROUTINE.TABLE indicates which Tag subroutine to use for each TAG field number
supported (default routines are supplied).
 Figure 13 - DE.I.SUBROUTINE.TABLE for Tag 32 with routine DE.I.TAG32

Note: The Tag field subroutine listed in field SUBROUTINE will be used for all occurrences of the
field Tag, regardless of the SWIFT message type or the application the data will be passed to.

Set up OFS.GLOBUS.MANAGER processing for a SWIFT message

Create An OFS.SOURCE record

This defines an OFS interface for OFS.GLOBUS.MANAGER.

Figure 14 - OFS.SOURCE for Processing Inward Messages

Values are:
SOURCE.TYPE ‘GLOBUS’ This interface will be called from a subroutine.
LOG.FILE.DIR ‘LOGDIR’ The name of the OFS log directory.
LOG.DETAIL.LEVEL ‘FULL’ A full history of each OFS message is maintained.
MAINT.MSG.DETS ‘Y’ Creates an audit record for each OFS message
DET.PREFIX ‘INW’ Audit record prefix
SYNTAX.TYPE ‘OFS’ Messages will use OFS syntax
Create a VERSION record for the application to be called

This will be used by OFS to add a record to the required application. For example, a zero
authoriser version of FUNDS.TRANSFER.

Figure 15 - VERSION for FT Application

GTS.CONTROL ‘1’ Place error messages on hold and accept overrides

Modify a message’s DE.MESSAGE record to indicate OFS.GLOBUS.MANAGER processing

and the subroutine to use.

Figure 16 - DE.MESSAGE for MT103 Processed by OFS.GLOBUS.MANAGER

APPLICATION.QUEUE “null”
INWARD.OFS.RTN Routine The supplied or local subroutine, which should be
name called to process this message type.
IN.OFS.VERSION Version Indicates to OFS which version of an application
should be used to create records.
OFS.SOURCE Source The OFS Source interface to use when processing
this message.

Flow of Inward Mapping

Inward SWIFT messages are received from the SWIFT interface (e.g. Alliance) and are placed on
the Inward Unformatted queue by the SWIFT Carrier service.
The Inward Formatting Phantom (DE.I.SELECT.NEXT.MESSAGE) processes the queued
messages.

The OFS SWIFT inward message processing subroutine indicated in INWARD.OFS.RTN in

DE.MESSAGE (when APPLICATION.QUEUE is null) is executed using Tag subroutines indicated in
DE.I.SUBROUTINE.TABLE. The subroutine creates an OFS record populating fields for the target
application from information in the SWIFT message, and then calls OFS.GLOBUS.MANAGER.
A history log is produced for each message as per the set-up in OFS.GLOBUS.MANAGER.
The transactions will appear successfully in the application or they may be placed in IHLD if there
are any errors. While processing Inward Messages, which creates FUNDS.TRANSFER records,
field IN.PROCESS.ERR is updated with processing information (with tag which is not mapped or
error/s encountered in FT) and IN.SWIFT.MSG field with Incoming Swift Message details.

Figure 17 - Funds Transfer Processing Details after OFS processing

Soft Delivery

Previously, within GLOBUS, delivery for each application was initiated from Application specific
routines, which in a number of instances contained an element of ‘hard coding’; the effect of this
was that the user had little control of the message type produced for each contract activity.

The Soft Delivery mechanism is to enable the user to control the creation of the delivery messages
(whether in the form of S.W.I.F.T. messages or printed output) this is achieved by defining
activities that will generate a specific message type at each stage of a contract life cycle.

EB.ACTIVITY

The main concept of Soft Delivery is to define each different stage in the lifecycle of a contract as a
discrete event, by means of defining Activities on the file EB.ACTIVITY. Each of these events will,
by necessity, be unique to the Application.

The delivery messages relating to each of these events may, if required, be produced prior to the
event itself. The number of days in advance of the event that the messages are produced is defined
on this file.

Figure 27 – Event activities can be defined on the EB.ACTIVITY file

EB.ADVICES

Once the events are defined in EB.ACTIVITY, the file EB.ADVICES can be used to control the output
of delivery messages, the format of the messages and deal slip formats for an EB.ACTIVITY. The key
to this file is EB.ACTIVITY-TYPE with the TYPE being optional.

By defining the records on this file the user will have total control of the type and format of the
eventual output. Users are also able to use their own mapping records instead of the standard ones
supplied with T24, which in some cases, may not cater for particular elements of business (i.e.
optional fields or sequences on a S.W.I.F.T. message).
 Figure 28 – The EB.ADVICES file controls delivery and format of messages and deal slips

EB.MESSAGE.CLASS

This file is used to classify S.W.I.F.T. message types into different message classes, e.g.
CONFIRMATION, ADVICE and PAYMENT.

The idea is to allow the users the flexibility to classify S.W.I.F.T. message types on the EB.ADVICES
file and to control the production of the eventual messages from the main contract.

For example, a contract amendment activity has been defined to produce a confirmation and a
payment advice. If, for some reason, the production of the payment advice for a particular contract
is to be suppressed, a user could say ‘NO’ to send advice on that contract instead of changing the
EB.ADVICES record to stop the payment advice and change back afterwards.

Figure 29 – EB.MESSAGE.CLASS classifies SWIFT message types into classes

End of Period Processing

The Delivery End of Period processing consolidates all statistical data and clears the files of deleted,
acknowledged and printed messages.

The Delivery End of Period processing is independent of the T24 Close of Business and can be run
whenever required by the user. The suggested approach is to run it weekly. However, it is up to the
user to determine when he finds it is best to run it and how often. Running Delivery End of Period
removes messages, which have been finished with from the live files and places them on the history
files. Therefore, regular running of End of Period keeps the live files to a reasonable size and therefore
improves processing time within Delivery.

The Delivery operator must shutdown all the Delivery phantoms before the End of Period processing is
run. The shutdown of each process can be affected urgently (after the current message being processed)
or normally (after all messages have been processed). See the section "Starting/Stopping queues" for
more information.

There are two End of Period processing modules: Outward End of Period
(DE.MM.O.END.OF.PERIOD) and Inward End of Period (DE.MM.I.END.OF.PERIOD). It is
recommended that both these procedures be run. However, if no inward messages are received by T24,
it is not necessary to run Inward End of Period.

Once the shutdown of all the Delivery processes has been completed, the Outward End of Period
processing can be initiated by entering DE.MM.O.END.OF.PERIOD at the "Awaiting application"
prompt. This module begins by prompting the user to enter the archive date or <RETURN> to
terminate the program. Only records older than the date entered (using the date in the id of the
records) will be purged.

Figure 30 - Start Outward End of period processing

A report will be produced listing any messages, which are awaiting acknowledgement and still
outstanding from the previous period. The files are then cleared of deleted, printed and acknowledged
messages, which are older than the specified date, copying the records to the history files provided
MAINTAIN.HIST is specified on DE.PARM.

The final part of Outward End of Period processing is the Statistics update. Once this has been
completed, statistics reports can be produced. (See the section "Statistical reporting" for more
information.)

After Outward End of Period processing has been run, Inward End of Period can be run, if required.
The processing for inward is the same as described above for outward, but is performed on the inward
queues and files.

Once End of Period processing is complete, the Delivery phantom processes can be re-started.
History Display (DE.MM.HISTORY.DISPLAY)

Once messages have been removed from the live files and copied to the history files by running the
End of Period processes, the messages can no longer be viewed through DE.MM.DISPLAY (see the
section "Displaying message queues"). Instead, they can be viewed through the message management
history display, by entering DE.MM.HISTORY.DISPLAY at the "Awaiting application" prompt.

The user is prompted to choose either inward or outward messages and this is then followed by two
options:

(i) Enter a date (in the format yyyymmdd, year, month, day) to obtain a list of all the messages
received by the Delivery system on that day.
(ii) Press enter for a complete list of messages. (This may be quite slow due to the number of
messages involved).

Figure 31 - History files can be viewed through DE.MM.HISTORY.DISPLAY

When the list of messages has been obtained, the option to go directly to a particular page is available
(e.g. P5 goes to page five or the last page if there are less than five pages). The user may also enter a
line number to select a message on the current page.

Having selected a message, the functions available are:

P Print the message header (not allowed on batches)

S See the message header (not allowed on batches)
V Present the user with a further choice:
P Print the formatted message
D Display the formatted message
 X Expand a batched message to list its contents (only allowed on batches). When
expanded, the P and S functions above are available for each message in the
batch.

When a formatted message is displayed (function V followed by D), if the message is more than 79
characters wide, the message can be paged left and right by using F7 and F8 respectively. Also, by
entering P5 for example, the display goes to what would have been page 5 of the formatted printed
message, not page 5 of the screen display.

If the formatted message is printed (function V followed by P), the bottom of each page will have "**
COPY ** COPY ** COPY **" printed across it.

If a batched message is selected, the "V"iew function will display or print the completed batch
message.

No input can be made to any of the fields of a message header record on the history file.

Syslog Display/Clear

When an error occurs in any of the Delivery phantom processes, it will be handled in either of the
following ways:

• If the error is associated with a particular message, the error is reported in the Error Code or Msg
error code fields on the Delivery Header record (DE.O.HEADER) and the message is placed on
the Repair queue.

• If the error is not associated with a particular message, since the error cannot be reported
immediately to a screen (because phantom processes are not attached to screens), the error is
written to a file called the Delivery System Log.

A report of all errors on the Delivery System log, the Syslog file, can be seen from any screen by
using the application DE.MM.SYSLOG.DISPLAY.

Syslog display (DE.MM.SYSLOG.DISPLAY)

On entering this application, a screen is displayed giving options to select a particular part of the log
and either display it on the screen or print it. However, defaults are set up so that pressing F5 causes
all today's messages to be displayed on the screen. F2 and F3 can be used in the standard way to
page backwards and forwards through the part of the log selected.
 Figure 32 - View Delivery System Log Details

See the Help text for more information on the options available in selecting syslog error messages
to be displayed.

Syslog clear (DE.MM.SYSLOG.CLEAR)

Without user intervention, the Syslog file will grow continuously and will eventually impact
performance. Even without errors occurring in the phantom processes, the file will grow, since
messages are written to the Syslog file every time a phantom process starts or stops. Therefore, it is
the responsibility of the Delivery operator to periodically clear the file. The frequency with which to
clear the file depends on the rate at which messages are being written to it, but weekly or even
monthly should be sufficient.

Before clearing the Syslog file, all the Delivery phantom processes should be stopped (see section on
"Starting/stopping queues"). To clear the Syslog file, run the application "Syslog clear" by entering
DE.MM.SYSLOG.CLEAR at the "Awaiting application" prompt.

A message will be displayed:

Enter date to clear log to (DD MM YYYY)

Only messages written to the Syslog file up to and including that date will be cleared. Once the date
has been correctly entered, all messages matching the date criteria will be deleted.

Statistics

Within Delivery, there is the facility to produce, either on screen or print, statistical reports of either
inward or outward messages.
Statistics are calculated during End of Period processing. The quantities accumulated are:

• Number of messages.
• Amount in each currency (if currency is one of the selection criteria).

• Time taken to deliver the message (from application hand-off to being successfully handed to the
carrier).

These totals include all messages or only those where particular conditions apply. The statistics
table (DE.STATISTICS) is used to define the conditions for which statistics should be maintained
and the sequence in which they should be presented.

Statistics table (DE.STATISTICS)

A Statistics table record is set up for each statistics report required. For the collection of statistics, the
id of the record is unimportant, because all Statistics records are checked with each message to see if
the message should be added into the statistics totals. Different ranges of ids could be used perhaps to
separate weekly from monthly reports.

Statistics table records are set up containing multi-value sets of:

FIELD.NAME
OPERAND
CONDITION

Complex conditions can be built by setting up several simple conditions in a multi-value set. All the
conditions must be true for the combined condition to apply. Where the Operand and Condition are
omitted, the field name indicates the sequence of the report.

Example:

The user might choose to select urgent messages for customer number 1234 and to display the totals
primarily in order of currency code and then, within each currency code, by message type. To achieve
this a statistics table record is set up as follows:

.FIELD NAME 1 .CURRENCY

.OPERAND 1
.CONDITION 1

.FIELD NAME 2 .MESSAGE.TYPE

.OPERAND 2
.CONDITION 2

.FIELD NAME 3 .MESSAGE.PRIORITY

.OPERAND 3 .EQUAL
.CONDITION 3 .U

.FIELD NAME 4 .CUSTOMER

.OPERAND EQUAL
.CONDITION 4 .1234
Note that the report generated would contain separate totals for each message type within each
currency, but no overall total (for all messages types) by currency. To obtain this an additional
record (producing an additional report) is required as follows:

.FIELD NAME 1 .CURRENCY

.OPERAND 1
.CONDITION 1

.FIELD NAME 2 .MESSAGE.PRIORITY

.EQUAL
.OPERAND 2 .U
.CONDITION 2

.FIELD NAME 3 .CUSTOMER

.EQUAL
.OPERAND 3 .1234
.CONDITION 3

Note: For improved performance, put the least common selection parameter first, i.e. the one that
will exclude most records. For example, if there are fewer records with a priority of "U" than
messages for customer 1234, specify the priority selection before the customer selection.

Statistical reporting (DE.MM.STATS.REPORTING)

To produce the report, enter DE.MM.STATS.REPORTING, at the "Awaiting application" prompt.

Initially the user will be prompted as to whether he wishes to see inward or outward statistics. An
abbreviation can be set up for "DE.MM.STATS.REPORTING O" for outward or
"DE.MM.STATS.REPORTING I" for inward, thus eliminating the prompt.

A list of all the reports available and their sort and selection criteria will be displayed. The user can
then enter the number of the report and whether he wishes to "D" - display the report or "P" - print the
report.

Reports can be viewed on-line at any time and will contain the totals, starting from when the report was
last printed, up to the latest End of Period run. The report can also be printed, but all associated totals
will then be zeroed and "Date Printed" will be updated. Therefore, if a report is printed weekly, it will
contain weekly totals and if printed monthly, it will contain monthly totals.

Translation Table/Set-up Translation

Translation table (DE.TRANSLATION)

The Delivery Translation table, DE.TRANSLATION, is used to convert codes passed in messages into
descriptive text (in various languages).

It is also used to contain all the SWIFT field codes. This serves two purposes:

(i) To validate codes entered in DE.FORMAT.SWIFT

(ii) To put meaningful descriptions against fields in SWIFT messages if they need to be
displayed for inspection.
Codes to be translated by the Formatting modules will have a prefix (defined on the appropriate
Format table) inserted before accessing the Translation table. If a prefix is not specified, SW (the
default) will be used. Field tags use this prefix, e.g. SWIFT field tag 50, meaning "Ordering
customer" will be entered on the Delivery Translation table with a key of SW50. If a different
description of a tag is required when it occurs in a particular message type then the description
should be entered in a DE.TRANSLATION in the form SWtt-mmm for example, SW50-900 for tag
50 in MT900.

Figure 33 - Delivery Translation Table Codes

For Print formatting, a special prefix can be specified in the Conversion field of the Format Print
record (DE.FORMAT.PRINT). The required text is then placed in the Translation table with the prefix
and code as the key. This technique allows applications to use the same code for different types of data,
or to translate the same code differently in various sorts of messages.

Example:

Suppose a value of 1 is used for two different types of code. We require to print "Basic rate
commission" for commission code 1, and "17.5% VAT" for tax code 1.
On DE.FORMAT.PRINT

On DE.TRANSLATION

Example:

Suppose a field is to be translated differently in different contexts. In one instance a field "OT"
containing the value "OT" is to be translated as "Telex", in another instance it is to be translated as "our
direct payment to":

On DE.FORMAT.PRINT

On DE.TRANSLATION

Shorter keys are slightly faster to look up, so, although it is important to use meaningful codes, very
long prefixes should be avoided.

Set-up translation (DE.MM.SETUP.TRANSLATION)

The Translation table will be delivered with various records, which should not be deleted. In
addition, there are records required by formats, which are file dependent and must be added to the
Translation table after the files have been updated. E.g. category codes are passed to Delivery for
translation in printed messages.
The setup translation application, DE.MM.SETUP.TRANSALATION is provided mainly to setup the
Delivery Translation table initially, but can also be used to update the Translation table from time to
time. This application enables the user to copy the description from all records on a particular file to
the Translation table, prefixing the codes with the prefix required in formatting.

Initially the user will be asked whether he wishes records on the Translation table,
DE.TRANSLATION, to be overwritten. If "Y" is entered, existing records will be updated (but never
deleted); if "N" is entered, only records that do not already exist will be created. The user will then
be required to enter the file name (without company mnemonic) from which records are to be
copied, and the prefix to be used when updating the Translation table.

Example:

If a category code requires translation, the conversion on the Delivery Format record might be
"CATG/". Therefore, the prefix required when copying records from the category file would be
"CATG/".

Once the records have been copied, the number of records created and updated will be displayed.
The user can then enter another file name or press F1 to end.

Figure 34 - Copy the description from all records on a particular file to the Translation table
using DE.MM.SETUP.TRANSLATION

When T24 is installed, after the files mentioned below have been entered, records must be copied from
the appropriate files to the Translation table using DE.MM.SETUP.TRANSLATION before the
Delivery phantoms can be run to process messages:

File name Prefix

FT.COMMISSION.TYPE COM/
FT.CHARGE.TYPE CHG/
 TAX TAX/
CATEGORY CATG/
TRANSACTION TXNL/
TRANSACTION TXNS/
LMM.CHARGE.CONDITIONS CHRG/
LMM.CHARGE.CONDITIONS MMCHG/

NOTE: The set-up Translation table application will always copy the description from the first field on
the file being copied from. Therefore, for records copied from the Transaction file where a short
description is required (TXNS/), the description on the Translation table must be amended to the
required length.

If a field is specified on the format tables as requiring translation, the field, with the appropriate
prefix will be looked up on the Translation table. If the record is not found on the Translation table,
the message will go into Repair. Therefore, it is important always to keep the Translation table up to
date. If new records have been added to any of the above files, the Translation table must be
updated accordingly, either by running set-up translation or by entering the records directly onto the
Translation table.

Set-up frequent tables using DE.AUTO.TRANSLATION

The DE.AUTO.TRANSLATION application is used for tables used as a source of translation text that
are updated more frequently. The input selections are stored and can be re-run easily.

Clear Handoff (DE.MM.CLEAR.HANDOFF)

The Delivery Handoff file, DE.O.HANDOFF, contains the raw message data passed from the
applications to Delivery and is used by the mapping phantom, DE.O.MAP.MESSAGES, for
extracting the data required by Delivery. The file is also used if a recovery is needed after a system
failure.

The clear handoff application, DE.MM.CLEAR.HANDOFF, is run under the GLOBUS batch
program control, from the batch process CUS.FILE.TIDY.UP, in the start of day.
DE.MM.CLEAR.HANDOFF clears the ids of messages whose processing has been completed, off
the Handoff file. It only clears the ids of messages that have been removed from the live files by the
End of Period processing (see section "End of Period Processing). DE.MM.CLEAR.HANDOFF
should be run as an ad hoc job and, since the handoff file is used for recovery, this program should
only be run after backups after the End of Period processing have been successful.

Recovery

In the event of a system failure, the disposition control table, DE.DISP.CONTROL and the Inward
routing table, DE.INWARD.ROUTING, are not recovered (see below). All other tables in the Delivery
system use the standard T24 recovery techniques. Files, which contain messages, Message Headers
and Indices to the messages, have a recovery system of their own.

Records are input to the Disposition control and Inward routing tables to deal with current
circumstances. For this reason, neither of these tables are recovered as these circumstances may have
changed and recovery therefore of these tables, will be irrelevant.
When the Delivery System receives an acknowledgement from a SWIFT or Telex device that a
message has reached its destination, it records the message id (either in the sent SWIFT file
(DE.SENT.SWIFT) or the sent Telex file (DE.SENT.TELEX) as appropriate). In the event of a system
failure, neither of these files are restored. If the files are still readable they will be used, otherwise, they
will be cleared.

After a system failure, the T24 database will be restored and, where possible, rolled forward to shortly
before the system failure occurred. The SPF file will be updated with the "crash time". At this stage,
Delivery messages, which may have been processed and sent out before the crash, will be on the Un-
mapped queue. Due to T24's recovery system, messages will have the same Delivery id as they did
when they were created before the system failure. Part of the Delivery id of messages is the date time
stamp, which is the date and time the messages were originally created.

The Delivery phantoms should be started as normal (see section "Starting/Stopping queues"). Each
message will pass through mapping and formatting as normal. As each message is processed by the
appropriate carrier control module, the date time stamp of each SWIFT or Telex message is compared
to the crash time on the SPF file. Messages created after the system failure (i.e. messages with ids after
the crash time) are sent out as normal. Messages created before the system failure (i.e. messages with
ids before the crash time) are not sent if their ids are on the sent SWIFT or sent Telex file, as
appropriate. If a message was created before the system failure but is not on the appropriate sent file,
the message is sent out as "Possible Duplicate Entry" (PDE). If the sent SWIFT or sent Telex file is
unreadable after a system failure, they will be cleared, so all messages subsequently processed which
were created before the system failure will be sent out as PDEs.

The same reason that neither Disposition Control nor Inward Routing can be restored also applies to
both the Outward and Inward Header files (DE.O.HEADER and DE.I.HEADER). However, care
should be taken if the Input function was used to change fields on the Header files as these changes
may have to be re-applied after a Recovery, if the conditions for the original changes still apply.

When the Format Print table is recovered (DE.FORMAT.PRINT), the sample print layouts are not
re-produced.

Creating and Amending Print Format Definitions (DE.FORMAT.PRINT)

The Print format table, DE.FORMAT.PRINT, holds the definitions for all printed messages in Delivery.
Due to the great flexibility offered by the print format definitions, this table may seem rather
complicated. In this section, the main methods and fields used in creating and amending Print format
records are described briefly. If further information is required, the corresponding field should be
referred to in the Help text.

Id of print format

The id of the Print format record is as follows:

NNNN.AANNNN.NNN.AA where
NNNN Is the message type
AANNNN Is the application format, which is either application code or numeric or
application code followed by up to 4 numeric characters.
NNN Is the format version number
AA Is the language
E.g. If the message type is 320, the application format is MM1030, the format version 20 and the
language FR, the key will be 320.MM1030.20.FR

The application format is passed from the banking application, which originally generated the message.
The format version number is specified by the Product record in determining, which format to use.
Therefore, when assigning the id, it must be decided whether the banking application invoking the
message or the fields in the Product key (i.e. company code, customer number, account number,
message type and application code), or both, will determine which format should be used.

Form size

The first decision to be made in creating a new print format layout is the size of the stationery to be
used. In the field, Form type, the name of the form type to be used should be entered. If this field is left
blank, "default" stationery will be used. The name of the form type should exist on the Form type table,
DE.FORM.TYPE. This table describes the form width (number of characters), depth (number of lines),
the printer to be used and special print attributes to be used when the report is printed. Where possible,
existing form types should be used, since the operator will be asked to load different stationery (the
form type name). However, if the operator is to load pre-printed stationery, a special form type should
be specified, even if the form type dimensions are the same as other form types used.

The following fields on the format record, i.e. fields 3.1, "Line(s)" to 15.1, "PAGE.OVERFLOW", are
multi-value associated fields and are used to describe what fields are to be printed, where they are
printed and any special conversions, masks, etc. that should be used.

Line(s)

LINE(S) specifies how far down a page the item defined in FIELD/'TEXT' should be printed. It
contains either an explicit line number or the line number relative to the last item printed.
Additionally it is possible to specify the highest line number that this item may be printed on or the
maximum number of lines to print. Fields or text to be printed must all be defined in sequence,
down the page.

This field contains:

1. Either:
a) The line number (counting from 1 at the top of the page) on which to print.
Example: 1 (print at the top of the page.)
or
b) The relative line position: the number of lines to move down the page from the
last item printed.
Example: +2 (miss 1 line after the last item, then print on the next line.)
2. “-“
3. Either:
a) The highest line number to be used.
Example: +1-55 (print on the next line, but not if line is 56 or higher.)
Or
b) "+" and the maximum number of lines to be printed.
Example: +0-+5 (print on the same line as the last item, then print subsequent
multi- or subvalues on the following lines, but do not print more than 5 lines.)
Part 1 is always required but parts 2 and 3 specified together are optional.

NOTE: When part 1 b) in the above details is used it differs from part 3 b) as follows:

• "+" In 1 b) specifies a displacement of the given number of lines from the previous field printed.

• "+" In 3 b) specifies the maximum number of lines to be printed, not the maximum displacement
from the previous field position.

Examples:

02 Print on line 2
+2 Print 2 lines down from the last item printed (miss 1 line)
+0 Print on the same line as the last item
1-10 Start printing on line 1, put the next multivalue on line 2 ... put the 10th value on line 10,
if that many exist. If more than 10 values exist, page overflow may occur (see below).
+2- Start printing 2 lines down from the last item printed and do not print past line 55. If the
55 previous item was printed on line 54 or more, this item will overflow immediately onto
the next page (see below).
+4- Start printing 4 lines down from the last item printed and do not print more than 2 lines.
+2

If the number of multi-values or sub values in a field exceeds the number of lines specified then page
overflow is required. If the PAGE OVERFLOW field is set to "NO", the message will go into Repair. If
PAGE.OVERFLOW is set to "Y" and the item has overflowed, nothing else with a relative line position
(i.e. line number starts with "+") will be printed on that page unless it has a HEADING set to "B" or "S"
(see HEADING later in this section).

Example:

.LINES(S) 3-55
.FIELD/"TEXT" AMOUNT
.LINE(S) +2
.FIELD/"TEXT" TOTAL

If "AMOUNT" needs to go beyond line 55, page overflow will occur. "TOTAL", which has a
"relative" line position, will not print until all the values of AMOUNT have been printed, even
though "TOTAL" is allowed to be printed past line 55.

Indent

Indent specifies the position of the field across the page and is expressed as the number of characters
across the page. This field contains a numeric value. Unless a MASK (see MASK later in this section) is
specified, printing will be left justified, so that the field is printed starting at the number of characters
specified in INDENT.
Example:

5 The field/text will be printed starting at the fifth character across the page.

Fields to be printed must all be defined in sequence down a page, but fields may be superimposed
across a line, so that when one field is not present, another will show.

When a field is positioned on a line, it starts from the character position defined by INDENT then,
regardless of the length of the field, the gap between the end of the field and the end of the print line is
set to blanks. This has the advantage that a short field may optionally be used to overwrite a long field,
but it does mean that variables cannot be inserted into text.

Fields can be printed on the same line as follows:

LINE(S) 2
INDENT 10
FIELD/"TEXT" "CUSTOMER NAME:"
LINE(S) +0
INDENT 25
FIELD/"TEXT" CUSNAME

The following line would be printed:

Customer name: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Where multi-value or sub value fields are specified as appearing on a group of lines, all other
fields/text to be printed on these lines must be specified as appearing on the same group of lines, even
though they contain only a single field.

Example:

LINE(S) +2-+4
INDENT 10
FIELD/"TEXT" ADDRESS
LINE(S) +0-+4
INDENT 60
FIELD/"TEXT" DATE

"ADDRESS" will start printing two lines down from the last field printed (i.e. missing one line) and
will print on four lines (if there are that many lines in the address). "DATE" will printed in column
60 on the first line of the address and providing that MULTI (see MULTI later in this section) is left
blank, will only be printed once.

Heading

HEADING is used to control on which page a field or text is printed. If "B" is entered, the field/text
will be printed on all pages; is "S" is entered, the field/text will be printed on all subsequent pages
(i.e. on all pages except the first); if banner is left blank, the field/text will be printed once only.

Multi

MULTI specifies whether the field contains "M" – multi-values, "S" - sub values, or, if left blank, the
field/text contains a single value. If multi is left blank and the field does contain multi or sub values, all
values will be printed alongside each other, separated by spaces. If the field contains a singe value or is
text but multi is entered as "M", the field or text will be printed on every line in a group of lines
alongside the multi-value set.

Example:

.LINE(S) .+2-+4
.INDENT .1
.FIELD/"TEXT" ."ADDRESS"
.MULTI .M
.LINE(S) .+0-+4
.INDENT .10
.FIELD/"TEXT" .ADDRESS
.MULTI .M

If "ADDRESS" contains four lines, the following would be printed:

Address xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Address xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Address xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Address xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Complete

COMPLETE specifies whether a set of sub values in a multi-value field should be printed only if there is
enough room on the current page to print all the sub values together. This field can only be used if
MULTI contains "S" (sub values). If there is not enough room, the sub values will be printed on the next
page (providing PAGE overflow" is "Y", otherwise the message will go into Repair). If there will never
be enough room to print all the sub values together on a page, then printing will begin on the current
page.

Example:

A field contains:

1. Multi 1 Sub 1
2. Multi 1 Sub 2
3. Multi 1 Sub 3
4. Multi 2 Sub 1
5. Multi 2 Sub 2
6. Multi 3 Sub 1
7. Multi 3 Sub 2
8. Multi 3 Sub 3
9. Multi 3 Sub 4
10. Multi 3 Sub 5

"LINE (S) is specified as +2+4 with COMPLETE specified as "Y" and PAGE.OVERFLOW as "Y". 1, 2
and 3 would always be printed together, even if it were necessary to go onto the next page before
printing. 1; 4 and 5 would be printed together even if it were necessary to go onto the next page
before printing. 4; 6, 7, 8, 9 and 10 could never be printed together, since only 4 lines have been
specified in LINE(S). Therefore, 6 will be printed on the current page, with as many sub values as
possible, before printing the rest on the next page.

Field/”Text"

FIELD/"TEXT" specifies what is actually to be printed at the position specified. It can contain:

i) A field name, which must be defined in the corresponding Message record on the
Message table (DE.MESSAGE).
ii) Text, contained in quotes, e.g. "Name".
iii) A reserved word as follows:

TOTAL.n where n is 1 to 9. Print formatting can maintain totals when printing

amounts (see "Calculation" later in this section). Specifying a field/"text" of
TOTAL.n will cause the previously calculated total to be printed.

PAGE.NO - the current page number.

DATE - prints today's date.

TIME - prints the current time.

TO.ADDRESS - the address to which the message is being sent as specified in

the "TO.ADDRESS" field on the message Header record (DE.O.HEADER).

DELIVERY.REF - the Delivery reference of the message being printed.

&ATTIxxxxxx or &ATTRxxxxxx - If the message is destined for a printer

which supports various graphics or character attributes such as bold or
underlined, these facilities can be used within Delivery messages. Field/"text"
may contain a link to the PRINTER.ATTRIBUTES table, such as
"&ATTIBOLD&". &ATTIxxxxxx specifies the initiation of the attribute and
&ATTRxxxxxx specifies the resetting of the attribute. This is converted at
printing time to an escape sequence to invoke the attribute for the printer
concerned. The name of the attribute ("BOLD" in this example) is prefixed with
the printer type from the PRINTER.ID table and looked up on the
PRINTER.ATTRIBUTES table (e.g. LASERJET.BOLD). If the desired attribute is
not defined, the controlword is ignored. Such attribute controlwords may be
inserted anywhere within the text of a message and be used and reset as many
times as required. They will not be displayed on the screen when the message is
viewed and will be removed from the body of the message when it is written to
history.

Conversion

CONVERSION can be used to specify special treatment of the field named in FIELD/'TEXT', as
follows:

CUS*xxxxxxxxxxxxxx
 If the field contains a company code or customer number, the name and address will be
retrieved from the Delivery Address table, DE.ADDRESS. If the field contains neither a
company code nor a customer number, it is assumed that it contains a name and an address.

CUS must be followed by either *FULL to print the full address or one of the following to print
one line of the address:

*SHORT.NAME
*NAME.1
*NAME.2
*STREET.ADDRESS
*TOWN.COUNTY
*POST.CODE
*COUNTRY

CUS*TEXT*ORD

Prints the standard text from the ORD record of the DE.TRANSLATION file in the language
of the receiving bank when the CONFID.TXT field on the CUSTOMER record is set to
‘YES’, otherwise customer short name and address is printed. Setting the text on the
DE.TRANSLATION to NO TEXT will bypass this conversion and use the default method.

TABLE xxxx

A conversion of table is used to specify a lookup of the Translation table, DE.TRANSLATION.

If xxxx is entered, the field is prefixed with xxxx before the table lookup; otherwise the field is
prefixed by "SW" before the Translation table is accessed. The field is then replaced with the
translation of the code in the language

Examples:

Field contains GBP

Conversion is specified as TABLE
Text to be printed will be found by looking up SWGBP on the Translation table.

Field contains GBP

Conversion is specified as TABLE CCY/
Text to be printed will be found by looking up CCY/GBP on the Translation table.

If the field is a multi-value set and conversion of "TABLE xxxxxx" is specified, only values
prefixed by ":" will be looked up on the Translation table (the prefix of ":" will be removed
before the lookup). This is so that multi-value fields can contain a mixture of fields, which
should be translated, and fields for which no translation is required.

TRANS

A full multi-language set of text can be passed from an application calling Delivery. The use of
"TRANS" will cause print formatting to use the language of the formatted message to select
text in the corresponding language.

DATE
 DATE translates dates into the following formats:

DATE DD MMM YYYY (Three letter month)

DATE/F DD MMMMMMMMM YYYY (Full month name)
DATE/S DD MM YY (Two digit month)
DATE/US MMM DD YYYY (Three letter month)
DATE/F/US MMMMMMMMM DD YYYY (Full month name)
DATE/S/US MM DD YY (Two digit month)

WORDS

Translates numbers into words in the appropriate language (e.g. "22" will be translated as
"twenty two"). Large amounts require two lines, therefore "Multi" should be "M".

COPY

The field or text specified will only be printed if the formatted message is a copy, i.e. the
message has previously been successfully formatted for printing (possibly with a different
"TO.ADDRESS"). The disposition of the original printed message must be "Formatted",
"WACK" or "ACK".

DUPLICATE

The field or text specified will only be printed if the formatted message is a duplicate message,
i.e. the message is flagged as being "PDE" (possible duplicate entry) on the Header record as it
has had to be formatted twice or because the banking application which generated the message
set the header field APP.PDE.

@xxxxxxx

Where xxxxxxx is a user-created subroutine to carry out customised conversions. The

subroutine must exist in PGM.FILE as a type ‘S’ record. The leading ‘@’ character must be
entered before the subroutine name or it will not be recognised. The arguments used in
calling the subroutine are xxxxxxx (IN.FIELD, HEADER.REC, MV.NO, OUT.FIELD,
ERROR.MSG), where

IN.FIELD – unconverted data from calling routine

HEADER.REC – dynamic variable containing current Header record from calling routine
MV.NO – Current value number for carrier address (references Header record) from calling
routine
OUT.FIELD – converted data from subroutine
ERROR.MSG - text error message generated by subroutine. If this is not null on return from the
subroutine, the calling program will abort the conversion and place the message in the
Repair queue.

TIME.CET
 This conversion will print the time as passed and add the CET.TIME.DIFF after the time in
the SWIFT format. The CET.TIME.DIFF is defined on the DE.PARM file.

Mask

MASK can be used to control the formatting of fields, as follows (n is 1 or more digits; x is 1 or more
characters):

Bn Right adjust into a length of n by inserting blanks on the left

*n Right adjust into a length of n by inserting asterisks ("*") on the left
Zn Right adjust into a length of n by inserting zeros ("0") on the left
, Insert commas (",") to separate thousands
. Change decimal points (".") to commas (",")
., Insert points (".) to separate thousands and use a comma for decimals
,. As above
- Put the sign after the amount (the sign normally precedes the amount)
A Print the absolute value (i.e. without a sign)
D Print "DR" after the amount if it is negative
C Print "CR" after the amount if it is positive and "DR" if negative
% Print "%" after the data
00x00x000x Digits will be substituted for the zeros. Any other characters ("x" represents 1
or more characters) will be printed wherever they were in the mask.
e.g. Field contains 123456; mask is 00-(00-00); field will be output as 12-(34-
56)

More than one mask parameter may be specified, separated by a space. E.g. "B10 - ,". However
00x00x000x may not be combined with other masking parameters.

Calculation

Various calculations can be performed by print formatting, using up to nine working fields. The
contents of these working fields can then be printed by specifying FIELD.TEXT of TOTAL.n where n
is 1 - 9. Calculation can be performed by setting CALCULATION to one of the following values:

+,TOTAL.n Add the contents of the field into TOTAL.n

-,TOTAL.n Subtract the contents of the field from TOTAL.n
*,TOTAL.n Multiply TOTAL.n by the contents of the field
/,TOTAL.n Divide TOTAL.n by the contents of the field
ZERO Zeroise the field after printing (may only be used if the FIELD.TEXT is
TOTAL.n).

NOTE: When multiplying or dividing, the first field determines the number of decimal places. This
is not suitable for such purposes as calculating a local currency equivalent.
DEPENDENT.ON

Specifies that the FIELD/'TEXT' is not to be printed if the field named in DEPENDENT.ON is blank or
zero, or is only printed if the field named in DEPENDENT.ON matches the condition specified in
DEPENDENT.OPERAND and DEPENDENT.COND. DEPENDENT.ON can contain any field in the message (it
need not be one of the fields being printed) or the name of any field in the format record prefixed by
"*" (i.e. it must be a field being printed) or "TOTAL.n".

DEPENDENT.ON is generally used to prevent a heading from being printed when the associated data is
not present.

Example:

.FIELD..TEXT ."PAYMENT DETAILS"

.DEPENDENT ON .PAY DET

.FIELD..TEXT .PAY DET

The heading "Payment details" is only output if the field PAY DET contains something to be
printed.

In addition, a field or text can be printed depending on the value of the DEPENDENT.ON field. Fields can
only be compared to constants (and not to other fields).

For example, print an amount in a credit or debit column according to the value of the amount.

.LINE(S) .10
.INDENT .35
.FIELD..TEXT .AMOUNT
.DEPENDENT .ON .AMOUNT
.DEPEND .OPERAND .LT
.DEPEND COND .0

.LINE(S) .10
.INDENT .50
.FIELD..TEXT .AMOUNT
.DEPENDENT .ON .AMOUNT
.DEPEND .OPERAND .GE
.DEPEND COND .0

In the above example, if the amount is less than 0, it will be printed in column 35; if it is greater
than or equal to 0, it will be printed in column 50.

DEPEND.OPERAND

DEPEND.OPERAND is used to specify how the DEPENDENT.ON field is to be compared against the
DEPEND.COND field in determining whether to print the FIELD..TEXT or not. This field can contain the
following values:
 EQ EQUAL
NE NOT EQUAL
LT LESS THAN
LE LESS THAN OR EQUAL
GT GREATER THAN
GE GREATER THAN OR EQUAL

DEPEND.COND

DEPEND.COND specifies the constant value that the DEPENDENT.ON field is to be compared against in
determining whether to print the FIELD..TEXT or not.

PAGE.OVERFLOW

PAGE.OVERFLOW specifies whether a field is allowed to overflow onto the next page. If a field
overflows a page and PAGE.OVERFLOW is set to "NO", the message will go into Repair.

Delivery WORD link

Delivery message data can be handed to a Windows application, such as a Word processor, so that
the formatting and printing of the document is done outside of Delivery, in Microsoft Word, for
example. This gives two significant benefits:

• All the functionality of Word is available giving greatly enhanced formatting capabilities, e.g.
multiple fonts and styles, headers and trailers, watermarks, inclusion of graphics and pictures,
etc.
• The need for someone with the technical skills to understand DE.FORMAT.PRINT is removed:
anyone who can understand Word can create and amend advices, confirmations, statements,
etc.

DE.FORMAT.TEMPLATE

The table, DE.FORMAT.TEMPLATE, is used to specify all the data required to produce each type
of delivery message. The id to the file is the same as the id to DE.FORMAT.PRINT, i.e.

NNNN.AANNNN.NNN.AA where
NNNN is the message type
AANNNN is the application format, which is either application code or numeric
or application code followed by up to 4 numeric characters.
NNN is the format version number
AA is the language

E.g. If the message type is 320, the application format is MM1030, the format version 20 and the
language FR, the key will be 320.MM1030.20.FR.
The record can be populated from an existing DE.FORMAT.PRINT record, from a DE.MESSAGE
record, or can be entered manually. The record can contain:

Figure 45 - Data required for DE.FORMAT.TEMPLATE delivery messages

Each field/text is assigned a DATA.NAME that can either be entered or defaulted. The data name is
the name of the field when it is accessed in Word.

Fields can be converted, using the conversions previously described in DE.FORMAT.PRINT.

Additional conversions have been added:

Figure 46 - Additional conversion fields in DE.FORMAT.PRINT

Fields can be masked, following the existing rules in DE.FORMAT.PRINT.

Masking and conversion can be carried out on the same field. However, the conversion is done
first. If you wish to convert the masked field, you must specify a conversion on the output of the
masked field. In the MB-Task example below, MASK.TRANS.REF is the masked transaction
reference, which is then converted to remove leading spaces.
 Figure 47 – DE.FORMAT.TEMPLATE Table

Fields can also be output or not, depending on the value of another field.

When a format template record is input, a TEMPLATE is required. This is the name of the Word
document, which will be used to print the message. The Word document should be created as a
Mail Merge document, specifying the DATA.NAMES of the fields to be printed. It should contain all
the necessary text, fonts, styles and graphics necessary for creating the formatted message. NOTE:
It may still be necessary for some text to be present on the DE.FORMAT.TEMPLATE record, if, for
example, it is dependent upon another field being present.
 Figure 48 - A Mail Merge document is used to create the formatted message

Templates can be shared between DE.FORMAT.TEMPLATE records. For example, the Word
document for debit advices may be the same as credit advices, even though these are different
message types in Delivery. Text can be passed from delivery to indicate whether the advice is a
debit advice or credit advice.

When the DE.FORMAT.TEMPLATE record is authorised, a sample file is created which can then
be used for merging into the Word document. This file will contain the data names and dummy
data. The file can be recreated at any time by running the application
DE.MM.TEMPLATE.LAYOUT. See the User Guide chapter on Navigation to see how this sample
file is used as a merge data source.

Also upon validation of the DE.FORMAT.TEMPLATE record, a REPORT.CONTROL record is

created, with an id the same as the id of DE.FORMAT.TEMPLATE, prefixed by $. To ensure that
the formatted messages are sent by the Print Server to Word, you should make sure that the printer
to be used has the COMMAND field set to LOCAL.SPOOL. When the message is “spooled” by
DE.CC.GENERIC, the message information will be written to the GUI printer server queue. From
here, the GUI printer server, PRINT.SERVER, will merge the data with the Word template and
spool the merged document to the local or network printer.
 Figure 49 - Debit advices may be the same as credit advices

Messages can be directed to template formatting by either specifying a carrier of TEMPLATE on

the appropriate DE.PRODUCT record, or by changing the DE.CARRIER record for PRINT to use
TEMPLATE formatting and output.

Figure 50 – Messages can be directed by setting the parameters on the Delivery Carrier
Parameter Record
Overview/Installation of Macros

In order to create the Word Mail Merge files (or amend an existing one) you can use the data file
created by inputting/amending the DE.FORMAT.TEMPLATE record. This file contains the names
of the fields used by Word to place the data passed from T24 into the Mail Merge documents.

To facilitate the installation of the macros we have provided a Word template called WordLink.dot,
which contains the macros GLOBUSMerge; MergeWiz; WordLinkOFF and WordLinkON. This
macro (supplied on the GUI CD) should be copied to your start-up directory (typically C:/Program
Files/Microsoft Office/Office/Startup) so that they are available for use.

Figure 51 - Installation of Macros

Select Macro in Word menu and using the Organizer option on the Word Macro dialog box you
should copy the GLOBUSMerge macro into the normal.dot template and assign the macro to keys
ALT+F12. This allows GUI to invoke the macro automatically.
 Figure 52 - Copy the Merge macro into the normal.dot template

Figure 53 - Use the Organizer option to copy the GLOBUSMerge macro into the normal.dot
template

The WordLink.dot template will give you a toolbar with three icons; one to suspend the ALT+F12
keys; one to re-activate them whilst the third converts the data.txt file into a valid Word Mail Merge
data file.

Creating/Editing a Word Mail Merge document

Use T24 to create an external Mail Merge data file, this avoids the need to key field names in Word
and then repeat them in T24. When creating a new DE.FORMAT.TEMPLATE or amending an
existing one you will get the opportunity to print an example. Request this and a file will be sent via
GUI to the PRINT.SERVER application and then across to your Wordlink PC. It is advisable to
have the PRINT.SERVER deactivated else your sample may be processed and printed.

Then do the following:

• In Word disable the ALT+F12 macro key by using the WordLinkOFF toolbar icon.
• Now start the PRINT.SERVER.
 • Check you have a data.txt file with the correct date/time settings in C:/Work. If it is there stop
the PRINT.SERVER.
• Run the MergeWiz from the toolbar icon, This converts data.txt to a Rich Text Format (RTF)
called data.rtf and deletes the data.txt file.
• Create a Word Mail Merge document, or open an existing one, and select the C:\work\data.rtf
as your data source. You will now see the field names in the drop down list of the Mail Merge
toolbar, finalise and save your document.
• Enable the ALT+F12 macro keys by using the WordLinkOn toolbar icon.
• You can delete the data.rtf file if you want or leave it until your advice is tested.
• Restart the PRINT.SERVER, it will resend the example.

Figure 54 - Creating/Editing a Word Mail Merge document

The above screen shows Word in Mail Merge mode, the next screen shows the fields created from
T24 as Word Mail Merge fields.
 Figure 55 - Fields created from T24 as Word Mail Merge fields

Automatic T24 to Word Printing

The automatic print from T24 to Word is made via delivery phantoms and the PRINT.SERVER
process.

• Start the Mapping, formatting and Generic phantoms.

• Start PRINT.SERVER
• Collect prints from Printer.

Creating and Amending Free Format Telex Definitions (DE.FORMAT.TELEXP)

The Free format TELEXP table, DE.FORMAT.TELEXP, holds the definitions for all free format Telex
messages in Delivery. With a few exceptions, this table is essentially the same as the Format print
table, DE.FORMAT.PRINT. Therefore, rather than duplicating all the explanations of the fields, the
user should initially read the section on print format definitions, then read this section which highlights
the differences between the two tables.

Whereas a print formatted message may be several pages long, a Telex message is always only one
page. However, there is no limit to the length of this page. Therefore, there are no page breaks and
there is not the need to specify page overflow, headers, etc. In addition, the width of a Telex message is
always 69 characters wide.

Therefore, the following fields which are present on the Format print table, do not appear on the
Format Telexp table:
FORM.TYPE
HEADING
 COMPLETE
PAGE.OVERFLOW

ID

The id of the Format Telexp table is in the same format as the id of the Format print table. The same
considerations should be taken into account when assigning new ids.

Line(s)

From and to line numbers can each be three numeric characters long, as opposed to two characters for
print. In addition, 999 is treated as infinity. This means there is no limit to the line number being
printed on. 999 can be used as a finite line number or a relative line number.

Examples:

120 Output on line 120

120-130 Output starting on line 120 and do not go beyond line 130
60-999 Start outputting on line 60 and continue until all values have been output
+2-+999 Start 2 lines down from the last line formatted and continue until all values have
been output

Indent

Indent must be a value between 1 and 69 inclusive.

Field/"text"

The following reserved words available for print formatting are not available for Telexp:

• PAGE.NO
• &ATTIxxxxxx
• &ATTRxxxxxx

The following reserved words, which are not available for print formatting, are available for Telexp:

• HEADER - Specifies that everything output before this keyword forms part of the header of a
Telexp message. If the message is included in a batched message, only the header portion of the
first message will be included in the batch, followed by the detail of all the messages in the batch,
ending with the trailer portion of the last message in the batch. Before batching is complete, a line
will appear in the message, "&HEADER", showing where the header portion of the message is.
This "&HEADER" line will be removed from the completed batch. If the message is not included
in a batch but is output on its own, the "&HEADER" line will be removed and the header portion
will remain in the message. "HEADER" must be specified as being output in column 1 on a line on
its own.

• TRAILER - Specifies that everything output after this keyword forms part of the trailer of a
Telexp message. If the message is included in a batched message, only the header portion of the
first message will be included in the batch, followed by the detail of all the messages in the batch,
 ending with the trailer portion of the last message in the batch. Before batching is complete, a line
will appear in the message, "&TRAILER", showing where the trailer portion of the message is.
This "&TRAILER" line will be removed from the completed batch. If the message is not included
in a batch but is output on its own, the "&TRAILER" line will be removed and the trailer portion
will remain in the message. "TRAILER" must be specified as being output in column 1 on a line on
its own.

• COLL.TOTAL - Specifies that this keyword should be replaced by a collective total of the
amounts in a batched message, when the batch is completed. COLL.TOTAL can only be specified
in the TRAILER portion of a message. COLL.TOTAL will appear in a message awaiting
completion of batching as "&COLL.TOTAL". COLL.TOTAL is calculated by adding the absolute
value of the amounts in each message in the batch, ignoring the decimal points. The amount in
each message is contained in the "Amount" field on the Header record (DE.O.HEADER).

Creating and Amending Fixed Format Telex Definitions (DE.FORMAT.TELEXF)

The Fixed format TELEXF table, DE.FORMAT.TELEXF, holds the definitions for all fixed format
Telex messages in Delivery. The messages are formatted in a similar manner to SWIFT messages, but
the user is able to define his own messages, rather than being limited to the SWIFT messages. (NOTE
that when the carrier is TELEX rather than TELEXF, formatting is done by using the Format SWIFT
table, DE.FORMAT.SWIFT.)

TELEXF messages differ from SWIFT messages in that only one field is associated with each field
tag, although fields can be multi-valued and would then appear on separate lines. Only one format can
be defined for each message, although the message can be sent in different languages.

The advantage of TELEXF messages is that if they are sent to another T24 customer (e.g. another
branch) with the same messages defined they can be decoded as incoming messages and passed
automatically to the appropriate banking application.

TELEXF are in the general format:

nnn : xxxxxxxxxx
nnn : xxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxx
nnn : xxxxxx

Id

The id is the message type, which must exist on the Message table, DE.MESSAGE.

The following fields on the Telexf format record are multi-value, associated fields.

Field tag

Messages sent by Telexf have codes (Field tags) in front of the fields to define what the fields are.
The field tags must exist on the Translation table, DE.TRANSLATION, when prefixed by SW. e.g.
Field tag is 140. Therefore, SW140 must exist on the Translation table. This not only provides
validation for the field tag, but also enables descriptive enrichment when a message is printed or
displayed on the screen.

Field name

Field name specifies the field to be output and must exist in the Message table record
(DE.MESSAGE) for the message type in the id of this record.

Conversion

Conversion specifies the conversion, if any that is to be performed on the field. The following
conversions are available:

CUS or CUSTOMER
The Telex number will be picked up from the Delivery Address table (DE.ADDRESS) for the
field specified in field name.

TABLE or TABLE xxxxxxx

The contents of the field are used to look up the Translation file as described in "Creating and
amending print format definitions".

TRANS
A full set of language text is maintained by the application calling Delivery. The appropriate
language text will be selected.

Header name

Defines the name of a field on the Header record (DE.I.HEADER), which should be updated with
the contents of the field when an incoming message is decoded.

Adding a new interface

A new interface can be added through the use of the Generic Delivery Interface. By use of the
Carrier table, DE.CARRIER, you can determine how messages are formatted, which address records
should be used and the interface required.

Messages sent and received using the Generic Delivery Interface follow the normal flow of
messages in delivery; the sending and receiving of the messages is performed by the generic carrier
control which determines whether the message should simply be written to a file or should be
handed to a routine.

Example

You wish to create a new interface to a telex package called GLOBUSTLX. Messages should be
sent to telex addresses in standard SWIFT format.

Step 1
Add a record to the Interface table, DE.INTERFACE, for GLOBUSTLX. This table contains details
of the protocols used for the interface. Where possible, these should be stored on the interface
record, rather than being hard-coded in the program, so that options can be amended by the user
(e.g. line speed) and also so that programming changes are not required if the protocol requirements
change.

Figure 56 – Set up a record on the Interface table for GLOBUSTLX

Step 2

Two routines have been specified on the interface record: GLOBUSTLX.OUT to send outward
messages and GLOBUSTLX.IN to receive incoming messages and the ACKs and NAKs to the
outward messages. NOTE: If ACKs and NAKs cannot be received from the interface bFigure 1eing
used, ACK.REQUIRED can be set to “N” on the interface record; messages will then be marked as
“ACK” as soon as they are handed to the outward routine.

You now need to write GLOBUSTLX.OUT and GLOBUSTLX.IN to handle the physical sending
and receiving of messages. These routines do not need to update any of the delivery files, as all of
this processing is done in the generic carrier control program (DE.CC.GENERIC). See the section
“Interactive processing - routine specified” for more information.

Step 3

You have already decided the interface the messages are to be sent to. You now need to decide on
the format of the body of the messages and the addresses to which they should be sent. This is done
by defining the carrier record on DE.CARRIER. In the example below, although we are sending
telex messages, we will be sending them in standard SWIFT format, i.e. the messages will be
formatted using the rules on DE.FORMAT.SWIFT. The messages will be sent to telex addresses,
i.e. the carrier used to look-up addresses from DE.ADDRESS will be “TELEX” (e.g. US0010001.C-
100017.TELEX.1).
 Figure 57 – Define the carrier record for the telex messages

If you prefer, you can define new formatting rules (see the section “Adding a new formatting
routine”).

When the record is authorised, the following file control records and files are created if they do not
already exist:

F.DE.O.MSG.carrier
F.DE.O.PRI.carrier
F.DE.O.MSG.interface
F.DE.I.MSG.interface
F.DE.SENT.carrier

In this example, the following files are created:

F.DE.O.MSG.TELEX
F.DE.O.PRI.TELEX
F.DE.O.MSG.GLOBUSTLX
F.DE.I.MSG.GLOBUSTLX
F.DE.SENT.TELEX

Step 4

Set up telex address records for any customers to whom you will be sending telex messages.
 Figure 58 – Set up telex address records

Step 5

Add the carrier to the list of valid carriers (OUT.CARRIERS) on DE.PARM, if it is not already
present. You do not need to add it to the inward carriers, as the one process will handle both inward
and outward messages.

Figure 59 - Add the carrier to the list of valid carriers on DE.PARM

Step 6
You need to tell Delivery which messages should be sent via the new interface, GLOBUSTLX: set
up records on DE.PRODUCT to route messages for the required message types for any customers
who wish to receive telex messages.

Figure 60 - Set up records on DE.PRODUCT to route messages for the required message
types

You are now ready to send messages via GLOBUSTLX. Start up the delivery phantoms and
monitor the queues, checking the repair queue to ensure that no errors occur.

Generic Carrier Control Service

The generic carrier control program sends and receives messages and processes the ACKs and NAKs
for the outward messages for all the generic interfaces specified on DE.CARRIER.

Specific processing of the messages depends on the options specified on DE.INTERFACE, i.e. whether
messages are to be written to a file or passed to a routine, whether ACKs are required and whether
sequence number checking should be performed. General processing of messages is described here,
with the options available detailed later in this section.

When the service is invoked messages for the carrier selected are processed in priority order, followed
by any incoming ACKs or NAKs to the outward messages and any inward messages. The program
then checks for any more outward messages to be sent, followed by inward messages, etc. Processing
continues until the phantom is stopped by the status flag on DE.PARM having been updated to “U”
(urgent shutdown) or “N” (normal shutdown) or the interface requesting that the phantom stops (passes
a STOP message).

When an outward message is passed to the interface correctly (either passed to the interface routine
if OUT.IF.ROUTINE is specified on DE.INTERFACE or written to the interface file if no routine is
specified), the message is written to the Awaiting acknowledgement file if ACKs are required
(ACK.REQUIRED set to “Y”) and the MSG.DISPOSITION set to “WACK” (awaiting
acknowledgement). If ACKs are not required, the message is written to history and the
MSG.DISPOSITION set to “ACK”.
When an inward message is received (either passed from the interface routine if IN.IF.ROUTINE is
specified or read from the inward interface file if no routine is specified), providing no errors are
found in the message, it is written to the inward delivery queue. If an error is found, the message is
written to the inward repair queue.

Inward messages must be in a format that Delivery can understand. Therefore, headers and trailers
must be removed before the message is passed to Delivery. Similarly, checksum calculations and
test key verification are the responsibility of the interface routines - they are not done by the generic
carrier control.

If an ACK for an outward message is received, the MSG.DISPOSITION on the header record is
updated to ACK, the message is written to history and the message removed from the awaiting
acknowledgement queue. If an NAK is received, the MSG.DISPOSITION on the header record is
updated to “REPAIR”, the message is written to repair and the message removed from the awaiting
acknowledgement queue.

Interactive processing - routine specified

If a routine is specified, it will be called from DE.CC.GENERIC when a message is ready to be

sent. The program should be a Data/Basic routine with four arguments:

• Message sequence number

• Formatted message
• Dynamic array containing miscellaneous data
• Error message

E.g. GLOBUSTLX.OUT (MSG.NO,R.MSG,GENERIC.DATA,ERR.MSG)

MSG.NO (message sequence number) - The message sequence number is a 6-digit sequence number
used to identify the message. It is also used to check that the message received was the next one
expected if sequence number checking is required (AUDIT.SEQ.CHECKING set to “Y” on
DE.INTERFACE).

R.MSG (formatted message) - The formatted message is the message as formatted by the formatting
routine. The outward interface file (DE.O.MSG.INTERACE) is not updated if OUT.IF.ROUTINE is
specified: this file is reserved for the routine to control and use.

GENERIC DATA (dynamic array containing miscellaneous data) - This array contains additional
information that can be passed between DE.CC.GENERIC and the outward routine. The layout of
the array is described in the insert I_DE.GENERIC.DATA.

ERR.MSG (error message) - The error message is null when the interface routine is called. If an
error message is passed back to DE.CC.GENERIC, the message will be written to the Repair queue
and the error message will be used to update the header record.

The interface program should add a header or trailer as required, convert the message if necessary
and physically send the message, handling all the communications protocol. This can either be
done in the Data/Basic routine or the routine can be a very simple Data/Basic program, executing a
C program or VOC entry or shell script - whatever is the skill of the person developing the
interface.
If no error message is passed back to DE.CC.GENERIC, the message is written to the Awaiting
acknowledgement file if ACKs are required (ACK.REQUIRED set to “Y” on DE.INTERFACE) and
the MSG.DISPOSITION set to “WACK” (awaiting acknowledgement) or to history if ACKs are not
required and the MSG.DISPOSITION set to “ACK”.

The inward routine, as specified in IN.IF.ROUTINE is then called, to see if there are any incoming
messages or ACKs or NAKs to the outward messages. The inward routine is called with six
arguments:

• Dynamic array containing miscellaneous data

• Message sequence number
• Type of message (ACK, NAK, MSG)
• Formatted message
• Delivery header record
• Error message

E.g. GLOBUSTLX.IN(GENERIC.DATA,MSG.NO,MSG.TYPE,R.MSG,MAT R.DE.HEADER,ERR.MSG)

GENERIC DATA (dynamic array containing miscellaneous data) - This array contains additional
information that can be passed between DE.CC.GENERIC and the inward routine. The layout of
the array is described in the insert I_DE.GENERIC.DATA.

MSG.NO (message sequence number) - The message sequence number is a 6-digit sequence number
used to identify the message. It is also used to check that the message received was the next one
expected if sequence number checking is required (AUDIT.SEQ.CHECKING set to “Y” on
DE.INTERFACE). For ACKs/NAKs, it is the sequence number of the message, which the
ACK/NAK relates to.

MSG.TYPE (type of message) - “ACK”, “NAK”, or “MSG” if the message is an incoming message.

R.MSG (formatted message) - Message to be formatted by the inward formatting routine. This has
to be in a format, which the inward formatting routine will understand, which normally means that
the header and trailer will have been removed.

R.DE.HEADER (delivery header record) - Update any fields on the header record with any
information which is known, e.g. retrieved from the header or trailer (FROM.ADDRESS for example).

ERR.MSG (error message) - If the error message begins “STOP” (regardless of the type of the
message), the program will terminate. Apart from this, the error message is only used for NAKs, to
indicate why a message was rejected.

If no errors are found in the message, it is written to the inward delivery queue. If an error is found,
the message is written to the inward repair queue.

For both outward and inward routines, if the error message begins “STOP”, the generic delivery
carrier control program will terminate.

Batched processing - No routine specified

If no outward interface routine is specified, messages will simply be written to the

DE.O.MSG.interface file. The id of the message is the message sequence number, i.e. a 6 digit
sequential number. Depending on whether ACKs are required or not, the message will either be
added to the Awaiting acknowledgement queue or will be written to history.

A procedure must be established to process the messages on DE.O.MSG interface. This can be as
simple as a manual process to save the file to tape (e.g. in tar format); ftp the file to a PC; an
automated process to save the file to tape, which can either be run on-line from within T24 (e.g.
from a menu) or from within the Close of Business; a program called from within the Close of
Business to batch the messages before sending them, etc.

NOTE: Delivery will not delete messages from DE.O.MSG interface. Messages should be deleted
by the procedure handling these messages once they have been processed successfully, or by a
routine called from the Close of Business for example.

If an inward routine is not specified, messages on the interface file, DE.I.MSG interface, are
processed in sequential order. The id of the record must be “ACK.nnnnnn” or “NAK.nnnnnn” for
ACKs/NAKs to outward messages (where nnnnnn is the message sequence number of the outward
message); for inward message, if sequence number checking is required, the id must be a 6 digit
sequential number or any characters if sequence checking is not required. For NAKs, the record
should contain the reason why the message was unsuccessful.

Figure 61 - Batched processing

 Figure 62 - Batched Processing

Figure 63 - Batched Processing

Figure 64 - Batched Processing

DE.INTERFACE - Options available

FILE.PATHNAME

All messages sent via the Generic Delivery Interface are written to the interface message file,
DE.O.MSG.interface (e.g. DE.O.MSG.GLOBUSTLX). By default, this will reside in the data area.
However, it is possible to have this file residing on a different disk, or even on a disk mounted from
a network server or PC, by specifying the pathname in FILE.PATHNAME. This field is multi-valued
so that the pathname of the file for outward messages (DE.O.MSG.interface) can be specified as
well as the pathname for the file for incoming messages (DE.I.MSG.interface).

OUT.IF.ROUTINE and IN.IF.ROUTINE

Interface routines can be written depending on whether the interface is to be interactive or batched.
In general terms, if the interface is to be interactive, interface routines are required; if the interface
is to be batched, interface routines are not required.
An outward routine can be specified without an inward routine and vice versa.

ACK.REQUIRED

Some interfaces do not send ACKs (positive acknowledgement) and NAKs (negative
acknowledgement); therefore it has to be assumed that if the message was sent to the interface, it
was received by the recipient correctly. If ACKs are not required, set ACK.REQUIRED to “N”. As
soon as the message is correctly handed to the interface routine or simply written to the interface
file if no interface routine is specified, the message will be flagged as ACK and a copy of the
formatted message written to history. If ACKs are required, the message will be written to the
Awaiting acknowledgement queue. When the ACK is received, the message will be removed from
the Awaiting acknowledgement queue and a copy of the formatted message written to history. If a
NAK is received, the message will be removed from the Awaiting acknowledgement queue and
placed on the repair queue.

AUDIT.SEQ.CHECKING

Normally for both outward and inward messages, the sequence number assigned to the message is
checked by both T24 and the interface. This number is a 5-digit, sequential number. However,
some interfaces may have their own numbering mechanism. For outward messages, T24 will
always assign the message sequence number. This number must be used if ACK/NAKs are sent by
the interface back to delivery. For inward messages, you can decide whether to use the 6-digit
number or your own numbering system. If you set AUDIT.SEQ.CHECKING to “Y”, delivery will
check sequence numbers in the normal way (i.e. the number assigned is the next number expected,
there is not an un-archived message on the audit file, etc). If AUDIT.SEQ.CHECKING is set to “N”,
delivery will just use the number passed to it from the interface without any validation of the
number or checking of the audit file. The LOCKING file normally contains the next expected
number. However, for inward messages where the AUDIT.SEQ.CHECKING is set to “N”, the
LOCKING record contains the last reference received, as the format of the ids is unknown and it is
not possible to increment it. The id of the LOCKING record for the outward sequence number is
OUT-carrier, where carrier is the id of the DE.CARRIER record (e.g. OUT-TELEX); for inward
messages, the id of the LOCKING record is IN-CARRIER (e.g. IN-TELEX).

Adding a new formatting routine

You may need to add a new formatting routine, for example, to send messages to a clearing
interface, e.g. BGC. In addition to the steps included in “Adding a new interface”, you must do the
following things. First of all, you must specify the formatting rules. This is achieved by writing a
program, DE.FORMAT.FORMAT.CARRIER, e.g. DE.FORMAT.BGC, based on TEMPLATE.
This program will allow the user to input the formatting rules and validate them. You will have to
create a PGM.FILE record for the program, a file control record for DE.FORMAT.format.carrier
(specifying that $HIS and $NAU files are required) and run CREATE.FILES to create the new
files. You will also need to write the formatting program,
DE.O.FORMAT.format.carrier.MESSAGE, e.g. DE.O.FORMAT.BGC.MESSAGE, to format the
message based on the formatting rules specified in DE.FORMAT.format.carrier.
Adding a new address carrier

There are no special steps necessary to add addresses to DE.ADDRESS for a new carrier, apart from
the fact that the carrier must be a valid carrier specified on DE.CARRIER. E.g. the user can enter
addresses for BGC without any additional code. The id of the records will be in the format of
US0010001.C-100017.BGC.1. However, you may want to create a version of DE.ADDRESS, so that
access is restricted to certain fields and additional validation is performed.

BIC Database Upload

SWIFT regularly releases a database, on CD, of all currently active BIC (Bank Identifier Code)
codes. These can be uploaded into T24 for its applications to verify and extract data from. Each
entry in the database is loaded as an individual record onto the DE.BIC file held on T24.

The data is received in a Microsoft Access database and needs to be exported into a universally
accepted ASCII formatted text file. Release instructions will provide details of any intricacies
requiring additional processing and any currently available information on how to perform this
export.

At the time of writing the BIC Database Plus program allows the export of data to a flat file using a
TAB delimiter. Note that T24 expects the file to contain 44 fields but the export may only provide
32. To get around this use the option in Bic Database Plus to export the field names in the first row.
Import this into Excel and save as bicplus.txt (a TAB delimited file) this will add the extra TAB
characters for the empty fields. The simply delete the first line containing the field names.

NB. Whereas every effort will be made to ensure that the T24 release instructions are current with
the latest BICPlus product, it is always advisable to read the instructions supplied with it, as,
however unlikely, SWIFT may have included alterations without notice.

Once inside T24 these records can be maintained or additional BIC records added. For example, it
may be required to include branches that have previously been unreleased.

A series of applications have been provided to facilitate the smooth transfer of this data from its
native source into T24. These allow you to set the default parameters, automatic ID generation,
action the upload of the database and maintain new or existing records on the BIC file within T24.

DE.BIC.PARAMETER

The SYSTEM record in DE.BIC.PARAMETER holds information used by the related applications
DE.BIC and DE.BIC.LOAD.

• MAPPING.API is optional and can contain a subroutine name as an alternative API call that the
DE.BIC.LOAD routine can use to override the default formatting of records from the BIC
database into T24.

• DEFAULT.ORIGIN is mandatory because it is used to generate the ID for manually entered

records if the inputter specifies no origin. The first four characters of any record that does not
have a BIC Code is taken from the origin, for example, BICPlus records without BIC codes
have the origin, BCPL. Customer records might be given the origin CUST.
 VALIDATE.BIC is an Optional field, which determines whether the BIC code entered has to
be validated against the BIC codes (Swift Address) available in DE.BIC Application.
BIC can be entered in GLOBUS applications either as BIC code (like in
NETTING.AGREEMENT) or prefixed with “SW-“ (like in FUNDS.TRANSFER.). To
validate BIC code entered in application against the records in DE.BIC application (where
BIC database is maintained), this field can be set to “Yes” & Error message is raised in case
non-existent BIC record is entered in GLOBUS Application.
To raise error message as per above on input of BIC in Applications, records in DE.BIC
application is checked as follows
ƒ When BIC is entered as 11 Characters (Bank, Country, Location & Branch) then
exact match record is checked
ƒ When Bic is entered as 8 Characters (Bank, Country & Location) then first exact 8
Characters BIC is checked and if not found, given 8 characters BIC is padded with
“XXX” (default Branch code) is checked against records in DE.BIC application
Above functionality is available in following applications: FUNDS.TRANSFER,
STANDING.ORDER, AGENCY, DRAWINGS, NETTING.AGREEMENT, DE.ADDRESS
,AC.EXPECTED.RECS, EB.QUERIES.ANSWERS, EB.FREE.MESSAGE,
DE.MT101.REQUEST

VALIDATE.SAK is an optional field in DE.BIC.PARAMETER and is used for validating the

existence of a SWIFT key with the Bank to whom the message is addressed.

When it is set to YES, a check is done when a Swift code is (BIC code prefixed with ‘SW-‘)
used in the fields Receiver Bank & Collrem Bank in FUNDS.TRANSFER and Receiver
Bank in STANDING.ORDER. In case there is no Swift Auth Key in existence then an
override message is given during the creation of the FT/STO itself.

For the above functionality, SWIFT.AUTH.KEY is a field in DE.BIC application which can be
set to ‘Yes” to indicate the existence of Swift key arrangement for the relevant BIC.

Figure 2 - The SYSTEM record in DE.BIC.PARAMETER holds information used by the related applications
DE.BIC and DE.BIC.LOAD

DE.BIC

The ID for creating a new BIC record can be in two formats:

If there is a valid 11-character BIC code for the required record, it can be entered in its entirety. The
first 4 characters are the bank code, then a 2 character ISO Country Code, a 2-digit location code
and finally a 3-character branch code. The branch code should be XXX if one does not exist. The
system will default this if not entered.

If there is not a valid BIC code, a 12-character code is generated from the 4 characters of the
ORIGIN, a two character ISO Country Code and an automatically generated six digit sequential
number. A default value for ORIGIN is held on the BIC.PARAMETER file. As a minimum
requirement it is, therefore, only necessary to enter the country code in order to generate a new
record.

Upon creation the ISO standard country name is automatically written to the COUNTRY field. This
cannot be updated as it is linked to the record ID. If the record is a valid BIC code ID this value is
written to the BIC field. If not, the BICKEY and ORIGIN fields are updated. In all cases the MANUAL
flag is set to ‘Y’, to indicate the method of entry. All other information should be input; the record
committed; and then authorised for use.

SWIFT.AUTH.KEY is a field which can be set to ‘Yes” to indicate the existence of Swift key
arrangement for the relevant BIC.

Figure 66 – Input a SWIFT BIC Database Record

DE.BIC.LOAD

The application DE.BIC.LOAD controls the upload process. Select the function ‘Verify’ and enter a
record ID. If this is not an existing record a new record is created using the value entered as its ID.
• DESCRIPTION is free format and can contain whatever information necessary to provide a
meaningful summary of the process.

• ACTION is mandatory and has two values, ‘Update’ or ‘Overwrite’. ‘Overwrite’ clears the entire
DE.BIC file in T24 prior to commencing the upload. ‘Update’ clears only those records that
have been automatically uploaded previously. Manually entered records remain on the DE.BIC
file.

NB. In ‘Update’ mode, a BIC record from the database cannot overwrite a manually entered record
of the same BIC code, if it exists. Instead, it is written to the unauthorised file to allow the user to
specify a suitable action for it.

• FILE.NAME automatically defaults to bicplus.txt and is a no-input field. This is to simplify the
process, ensure that the correct file is loaded and at the same time provide for any possible
changes in the future.

• FILE.LOCATION is an optional field to allow for an alternative path name to be specified for the
bicplus.txt file. The system automatically assumes the current path if no value is entered here.

• DELIMITER is mandatory requiring one of two possible options, TAB or COMMA. This
specifies the field delimiter character within each BIC record. By default the character is TAB,
however, pre-upload processing may require this to become a COMMA.

Figure 67 – Enter a new DE.BIC.LOAD record using the function Verify

On committing the record, in the Verify function, the upload process begins.

Firstly, depending on the ACTION chosen, either all the existing records are cleared down or just
those added previously by the upload process. Confirmation is required to proceed with this
deletion.
Secondly, the records from the BICPlus database file are read, formatted and written on the DE.BIC
file. Confirmation is required again prior to the re-population of the DE.BIC table and then given as
to the total number of records added, once the process is complete.

Figure 68 - Confirmation is required again for the re-population of the DE.BIC table

Inward / Outward MT101 Processing

Outward MT101 Processing-DE.MT101.REQUEST

Swift message MT101 (Request for Transfer) is sent by a financial institution on behalf of a non-
financial institution account owner, ie, the ordering customer/instructing party, and is subsequently
received by the receiving financial institution and processed by the receiving financial institution or
the account servicing financial institution.

The MT 101 can be used to order the movement of funds:

Between ordering customer accounts, or
In favour of a third party, either domestically or internationally.

The MT 101 consists of two sequences:

Sequence A - General Information is a single occurrence mandatory sequence and
contains information to be applied to all individual transactions detailed in sequence
B.

Sequence B - Transaction Details is a repetitive sequence; each occurrence provides

details of one individual transaction. Fields which appear in both sequences are
mutually exclusive

To generate outward MT101s, application DE.MT101.REQUEST can be used and a receiver of an

MT101 can be specified here either with a valid BIC code prefixed with “SW-“ or a customer
number who has a Swift address.

In the DE.MT101.REQUEST application, fields from RECEIVER.101 to AUTHORISATION forms

single occurrence mandatory sequence A and fields TRANS.REF to EXCH.RATE forms sequence B
transaction details which can be multivalued for repetitive sequence. During input, if SENDERS.REF
details are not given, then system defaults the Id of the application and it is mapped to the outgoing
MT101.

After giving the sequence A and B details, CREATE.MT101 has to be set to “YES” in the
DE.MT101.REQUEST application, which will generate swift message- MT101. Outward delivery
reference number and the date of creation is updated in DELIVERY.REF and DATE.CREATED.101
fields for our reference. Once the MT101 Outward message is generated from the application, the
record is moved to History.
 Figure 1 - MT101.REQUEST –Single Sequence Example

Figure 2 - Outward MT101 Message-Single Sequence Output

To generate an MT101 with repetitive sequence as per the below example, fields can be multi-
valued and an MT101 with more than one sequence can be generated. There is no restriction on the
number of sequences, however if the total characters in MT101 message including the header and
trailer exceeds the Swift allowed maximum characters then the message, during formatting, will be
moved to Repair disposition with appropriate error message.
 Figure 3 - DE.MT101.REQUEST-Repetitive Sequence Example

{1:F01TEMEUS33XXXX.SN...ISN.}{2:I101BNKAGB22XXXXN}{3:{108:xxxxx}}{4:
:20:REQ0133000002
:21R:UKSUPPLIER990901
:28D:1/1
:30:050902
:21:TRANSREF1
:32B:GBP12500,00
:50H:/8754219990
MAG-NUM INC.
PRM SUPPLIER 1 A/C
BAHNOFFSTRASSE 30
ZURICH, SWITZERLAND
:59:/1091282
BENEFICIARY 1
:71A:OUR
:21:TRANSREF 2
:32B:GBP15000,00
:50H:/3456712356
MAG-NUM INC
PRM SUPPLIER 1 A/C
BAHNOFFSTRASSE 30
ZURICH, SWITZERLAND
:59:/8123560
BENEFICIARY 2
:71A:OUR
-}

MT101 Inward processing

An MT101 message type requires Message User Group (MUG) registration and its use governed by
bilateral agreements:

• Between the Account Servicing financial institution and the ordering customer
• Between the sending financial institution and the ordering customer

Hence before processing an incoming MT101 message, agreement details have to be checked for
the sender of the message and the ordering Customer.
To trigger the checking of an agreement before processing an MT101 message, in DE.PARM the
field NETTING.ALLOWED has to be set as “Y” and in DE.MESSAGE, field CHECK.AGREEMENT has to
be set as “Y” for the record id 101. When the above fields are not set in DE.PARM and
DE.MESSAGE, then the Incoming MT101 will be processed without checking the agreement
details.

Figure 4 – DE.MESSAGE-101 record with Check.Agreement as “YES”

Agreement details related to an MT101 can be added in NETTING.AGREEMENT with the customer
number of the sender of MT101 message as ID and the ordering Customer BIC details in
AGREED.CUSTS with SYSTEM.ID as FT.

For example, to process an Inward MT101 received from ABSA Bank and ordered by customer,
whose BIC is “TESTGBT1” – following set-up has to be done in NETTING.AGREEMENT
Application:

Figure 5 - NETTING.AGREEMENT –Set up example

When an Incoming MT101 has ordering customer as Name and Address (Tag 50H), then checking
against the AGREED.CUSTS is skipped and the message is processed normally.

For each repetitive sequence in an MT101 message, a separate Funds Transfer contract is created
for each sequence. If the Ordering customer (tag 50g) is given in sequence A then that account is
used to debit all Sequence B transactions, otherwise Ordering Customer given in the respective
sequence is used as a Debit account. Based on the Txn Code given in DE.I.FT.TXN.TYPES, either
“AC” (both debit and credit account –Customer account) or “IT” (debit to an Nostro / Vostro
account) or “OT” (Credit to Nostro account) type of transaction is created.

The flow for checking the agreement details for inward MT101 message is explained below: *

{1:F01TEMEUS33XXXX.SN...ISN.}{2:I101ABSAZAJJXXXXU3003}{3:{108:xxxxx}}{4:
:20:REQ0133000011
:21R:UKSUPPLIER990901
:28D:1/1
:50G:/8754219990
TESTGBT1
:30:050902
:21:TRANSREF1
:32B:GBP12500,00
:59:/1091282
TEST FOR MT101 SENDER-ORD CUST
:71A:OUR
-}

Sample Inward MT101 message used for Checking Agreement

*Below inward message MT101 is processed through OFS.GLOBUS.MANAGER and refer to Delivery/Funds Transfer
User guide for set-up and other related details about MT101 inward message processing using
OFS.GLOBUS.MANAGER.

Case 1: Agreement details not available for Sender & Ordering Customer

The above MT101 message is processed through inward delivery processing

(OFS.GLOBUS.MANAGER) before adding a record in NETTING.AGREEMENT for Customer
100174 (BIC code –ABSAZAJJ). In such case an error Message is raised indicating agreement
details not existing for the sender of MT101 and the message is placed in “Repair” disposition.
 Figure 6 - DE.I.HEADER- Error - No Netting Agreement available for Sender

Case 2: Agreement details not available for Ordering Customer

The Sender of the MT101 Customer Id (100174) is added in NETTING.AGREEMENT, but ordering
Customer BIC (50g) is not given in AGREED.CUSTS. In this case the message is placed in “Repair”
Disposition with an error indicating agreement is available with the sender but not with the
Ordering Customer.

Figure 7 - DE.I.HEADER-Repair-No agreement for Ordering Customer

Once the Sender of an MT101 and ordering Customer details are available in
NETTING.AGREEMENT, then an inward MT101 is processed and a FUNDS.TRANSFER contract
is created by debiting the Ordering Customer and crediting the Beneficiary Account or by crediting
the Nostro account of Account With Bank Customer. Incoming MT101 Request Execution date
(Tag 30) contains the date on which the request has to be executed. In case the request execution
date is less than the system date, then contracts will be processed with Debit and credit value date as
the request execution date, and processing date as Today otherwise the request execution date will
be used as Debit value date / Credit value date and processing date in the FUNDS TRANSFER
contract.
 Figure 8 - DE.I.HEADER- Processed when Agreement is available

EB.MESSAGE.111 / SWIFT MT111

T24 can produce the additional outgoing SWIFT messages from the application,
EB.MESSAGE.111. The MT111 – Request for stop payment of a cheque will be produced via the
Soft Delivery Mechanism.

Figure 39 - EB Message 111 Input Record

EB.ACTIVITY – MT111

The following EB.ACTIVITY record is released for use with the EB.MESSAGE.111 application.
Populate the DAYS.PRIOR.EVENT field on these records according to your business needs.

Figure 40 - EB Activity Input Record

EB.ADVICES – MT111

The following EB.ADVICES is released for use with the EB.MESSAGE.111 application.

Figure 41 - EB Advices Input Record

Free Format messages

Free Format Outward Messaging (MTn99's)

Free Format messages are stored in the application EB.FREE.MESSAGE. This applies to outward
and inward messages. To send a message, prepare a record on EB.FREE.MESSAGE with the
receiver's customer number, the activity, and the message text. You can choose to see a preview of
the message(s), which will be sent.

When an outgoing record on EB.FREE.MESSAGE is authorised, then the activity identified in

EB.ADVICE.NO is invoked and each message specified in the corresponding EB.ADVICES record is
handed off to the T24 delivery application. Consult the DELIVERY user guide on the use of
EB.ACTIVITY and EB.ADVICES.
 Figure 42 - Free Format Message Input Record

Free Format Inward Messaging (MTn99's)

MTn99's when received by T24 are stored on the EB.FREE.MESSAGE Soft Delivery file. Below
are details of the procedures that must be followed to enable the processing of inward MTn99s.

The 'EB' application must first be added to the received message types, in the DE.MESSAGE file, in
the field APPLICATION.QUEUE. You must then create a VERSION record that should be set up as
below.
 Figure 43 - Version Record

An OFS.SOURCE record must also be set up, and the VERSION added to this record. OFS must be
installed first (please refer to the OFS User Guide). The OFS.SOURCE record should be set up as
below. The directory references should reflect the set-up of your master company.

Figure 44 - OFS Source Record

A record must be added to the EB.PHANTOM file, and set up as in the example below.
 Figure 45 - Phantom Control Record

Once the above procedures have been followed, T24 is then ready to process the inward MTn99's.

To receive the inward SWIFT messages, you should use DE.PHANTOM to run the
DE.CC.GENERIC carrier, and enter 'SWIFT' as the carrier name. Once received, the MTn99
messages will be placed onto the file, F.DE.I.MSG.EB. At this stage the message will only have
been partly processed.

The inward formatting phantom DE.PH.IF must be run by verifying the EB.PHANTOM record
created earlier. A routine called INWARD.99.MAPPING, that should have been plugged into the
OFS.SOURCE record in the IN.DIR.RTN field (as in the example screenshot), will then take the
message from the F.DE.I.MSG.EB file, process it and then write it to the EB.FREE.FORMAT file.

MT942 production

Manual MT942 production - DE.MT942.REQUEST

This application allows SWIFT MT942 interim statements to be produced on an ad-hoc basis for
specified accounts. It requires the 'V' function to initiate the production.
 Figure 46 - DE MT942 Request Verify Record

This application can only produce an MT942 message where the ACCOUNT in question has been
configured for their production, by use of the SEND.942 field in ACCOUNT.STATEMENT. It also
requires that the correct delivery route for the message is defined in a DE.PRODUCT record and an
alternate delivery address in DE.ADDRESS.

Refer to the User Guide - Account, Interest and Charges for further information on Account
statements.

Automatic MT942 production - DE.MT942.REQUEST

Where MT 942 messages are required to be sent automatically, at specified times during the day, an
EB.PHANTOM record must be created in order to run the DE.MT942.REQUEST.CHECK routine
which is entered into the RUN.ROUTINE field. Use the 'V' function to run the process. To stop the
phantom use the 'I' function, and enter the codeword STOP in the field PHANT.STOP.REQ.
 Figure 47 - Phantom Control Verify Record

The phantom process can only work effectively provided the ACCOUNT.STATEMENT,
DE.PRODUCT and DE.ADDRESS records have been configured. Refer to the User Guide -
Account, Interest and Charges for further information.

Interim transaction reports (MT942) – Phantom

Interim transaction reports are produced optionally, either on request, or at specified times during
the day.

Requests are submitted via the file DE.MT942.REQUEST. Timed reports are controlled via
ACCOUNT.STATEMENT. Consult Accounts, Interest and Charges for further details of the
records involved.

The process DE.MT942.REQUEST.CHECK runs as a phantom to produce the timed reports. To

start the phantom, Verify an EB.PHANTOM record for the process.
 Figure 48 - Phantom Control Verify Record for MT942

EB.QUERIES.ANSWERS

This application in T24 caters for some of the general SWIFT messages both inward and outward
that are required to cancel messages sent, make queries on messages received or send and
provide/receive answers to the queries.

Among the Common message group, SWIFT provides for 3 message types covering the whole 9
categories of message types. These are the n92, n95 and n96 messages. So for example, you would
use a 192 to cancel an MT100; a 195 to send a query and a 196 to respond to a query. Since the
message formats are the same across the categories, T24 allows all of the n92, n95 and n96, even
though it may not produce messages in that series. This is to allow a common query/answer
interface for the bank.

The processing of these message types involves the use of the Open Financial Server product,
which must be installed, configured and working. This takes qualifying messages from the
incoming SWIFT queue and creates OFS data records, which then input records to the
EB.QUERIES.ANSWERS file. These will be cancellation requests (n92), new or existing queries
(n95) and replies to your queries (n96).

In short, the types of processing will involve:

• Sending cancellations of various messages you have sent,

• Receiving confirmation of the cancellation, rejection or query related to it.
 • Receiving requests for cancellation,
• You confirm, reject or query the cancellation.

• Sending your queries to a SWIFT bank,

• Receiving responses to them.

• Receiving queries from a SWIFT bank,

• Assigning them to a staff member for resolution,
• Sending your responses back.

• Enquiries on the outstanding items.

In order to work smoothly, it is appropriate that VERSION and ENQUIRY records are configured to
use the workflow methodology. Some example type records are released as a starting point for the
bank to use.

Set-up

EB.QUERIES.ANSWERS is a core application, so it will be installed when upgrading.

To ensure that OFS can create records you should:

• Add the EB.QUERIES.ANSWER program to the COMPANY record in the PGM.AUTO.ID

field.
• Create and authorise an AUTO.ID.START record like the one below:

Figure 49 - Auto ID Start Input Record

• Create an OFS.SOURCE record, the id of which is then added to each n92, n95 and n96
DE.MESSAGE record.
• The Enquiry USER-LIST is used to assign items to staff members. If not present or working it
will need to be created/modified.
• DE.PRODUCT records should be added to send n92, n95 and n96 messages via SWIFT
EB.PHANTOM record to invoke OFS added if not already present.
• Part of the upgrade process will have added records to DE.TRANSLATION and
SWIFT.CODE.WORDS, which are crucial for the correct operation of
EB.QUERIES.ANSWER.
• EB.QUERIES.ANSWER uses T24 soft delivery so records are also supplied for
EB.ADVICES and EB.ACTIVITY, these must be authorised and in place.
Soft Delivery records

Records are supplied ready for use.

EB.ACTIVITY records such as:

Figure 50 - EB Activity Input Record

EB.ADVICES record such as:

Figure 51 - EB Advices Input Record

You probably will not need to change these.

OFS.SOURCE

Used to identify where the OFS data records are located, where to write out logs etc.

Note the id OFS as we use this later.

 Figure 52 - OFS Source Input Record

DE.MESSAGE

There are special fields near the end of the DE.MESSAGE record, which instruct the system on what
is needed for OFS type inward processing.

Figure 53 - DE Message Input Record

Note. The OFS id is entered here. The mapping routines and VERSION to use are supplied already,
but since some users do not have OFS installed, the OFS.SOURCE id must be entered manually or
via EBS.AUTO.FUNCTION.

When an inward SWIFT message arrives it checks for any routines. In the above case a mapping
routine called DE.I.OFS.MAP.MESSAGES is run which converts incoming SWIFT messages into
OFS scripts. The OFS.SOURCE record tells the system where to place the scripts.

EB.PHANTOM

An EB.PHANTOM record is required to trigger the OFS batch process, which waits for data to
appear in the inward files, which are processed to create EB.QUERIES.ANSWER records.

Figure 54 - Phantom Control Input Record

SWIFT.CODE.WORDS

The actual SWIFT messages are quite simple and allow for standard situations to be identified by
using 2-digit numeric codes that have set meanings. Some of these require further data such as
dates, statement numbers etc, which are usually appended to the code in the relevant field.
To assist in the use of these codes, we have added them to the SWIFT.CODE.WORDS application
and used new detail fields to assist in their explanation. The text and codes are derived from
SWIFT to avoid any errors.

Figure 55 - Swift Code Words Input Record

There is a small description field for internal use, the message types that use the code, the number
of supplemental information items and the SWIFT text for the code.

In use this file is viewed by running a context based ENQUIRY, which displays only the codes
pertinent to the query item you are entering. So for example, when responding to a query you
would be entering an n96 reply and the table below would appear, you can then use the drag and
drop feature of T24 browser to select the code you want whilst being able to see the context in
which it is used.
 Figure 56 - List of Query Codes for Swift MTn96

EB.QUERIES.ANSWER application

The application itself looks as below but needs some explanation of its use. Shown is a sample
(populated) record from the application, followed by a few examples of how it is intended to be
used.

First select a pre-designed VERSION for straight contract input from a menu:

Figure 57 - EB Queries Answer Application

Sending a cancellation:
 Figure 58 - EB Cancellation Queries Answers Record

The details required are not too complicated but the process of retrieving the information and
entering it can be automated to some extent.

Sample Workflow

Below is an example of sending a 192 Cancellation request. The correspondent sends a query on it,
which is replied to, and then confirmation is received that the payment was cancelled.

Our cancellation request:

Run an Enquiry to find the reference of the message sent selecting the Enquiry from the menu.

Figure 59 - Example of sending a 192 Cancellation Request

This brings the selection criteria panel, which is important, as the sent messages file is quite large.
 Figure 60 – Enquiry selection criteria panel

Run the enquiry to narrow down the search, for example defining the following results.

Figure 61 - Enquiry of sending a 192 Cancellation Request

Right click on an item (for example the MT100 message) to provide additional options.

Figure 62 - Provide additional options

We run this to narrow down our search and get results such as:
 Figure 63 - Search Results

Now we right-click on the second item (the MT 100 message) and see several choices.

Figure 64 - Right click on an item to see additional choices

This retrieves the data from the Enquiry and ‘pushes’ it into a specified VERSION, avoiding having
to type the details of the message.

Figure 65 - Retrieve data from Enquiry

Only a few fields are required for completion to finish the transaction. Assuming that this
cancellation has been sent and received by the correspondent, there may be a small query on it.
Incoming Query

It is not pertinent to explain how inward delivery works in this document. Rather the events, which
transpire in getting the message in and converting it to an OFS message (which then creates our
new EB.QUERIES.ANSWER transaction), will be shown as bullet points below:

• Inward SWIFT message comes into T24 via hardware or software link to SWIFT.
• Delivery phantoms are running so the message is processed by T24 and if they are in a valid
format end up on the DE.I.MSG file.
• The DE.MESSAGE record is checked to see if this message should be processed as an
incoming OFS type message. If so, the OFS mapping routine will read the message and
translate from format into an OFS script which is placed in a directory ready for OFS to read.
• OFS checks through the script and if valid runs it, thereby creating a T24 transaction; in this
case an EB.QUERIES.ANSWER one.

We should now have the query from our correspondent on the unauthorised
EB.QUERIES.ANSWER file.

Here is what the script looks like:

Figure 66 - Script EB.QUERIES.ANSWER file

We can check for incoming n95 queries by selecting the menu option. This will trigger an
ENQUIRY, which filters the unauthorised file for n95 inward queries. You may wish to first assign
the query to an investigator, or send a n96 reply immediately. You can make the decision from the
ENQUIRY by right clicking on the message and selecting the view, generate answer or assign
options.

Figure 67 - Select n95 queries from the Menu option

Now enter any pertinent selection criteria:

 Figure 68 - Criteria Selection Panel

Then a list of the matches will be displayed:

Figure 69 - Enquiry displays list of matches

Right click on an item to provide additional options.

Figure 70 - Provide Additional Options

Choose from the right click options:

 Figure 71 - Select from the Right Click options

The view details will give you a summary of the message content:

Figure 72 – View details for a summary of the message content

The assign to investigator will open the message for input:

Figure 73 - “Assign to Investigator” to open the message for input

The Generate MTn96 will create a new EB.QUERIES.ANSWER record for you to complete:
 Figure 74 - Generate MTn96 will create a new EB.QUERIES.ANSWER record

Note: The two fields likely to be entered are the ANSWER and NARRATIVE ones. Whilst the
NARRATIVE is for free format text and needs no further explanation, the ANSWER field can contain
short codes to represent the standard answers.

T24 has an option that populates the T24 browser ENQUIRY menu with those that are appropriate
for the task at hand. This is set-up in CONTEXT.ENQUIRY, and we have enabled the
SWIFT.CODE.WORDS relevant for the message type to be available for these actions.

Selecting the ENQUIRY from the menu invokes a display of the codes:

Figure 75 – Select Enquiry from the menu to invoke a display of the codes

The full display of the codes appears as:

 Figure 76 - Full Display of Codes

The drag and drop functionality can be used to drag the code into the ANSWER field and add any
extra text as required.
 Figure 77 - Drag and Drop the code into the “Answer” field adding extra text as required

Conclusion

The three message types are:

N92- Send Cancellation

N95- Sent or received Query
N96 – Sent or received Answer

Whilst we have not covered the use of each message being sent/received the concept is quite easy
and the above examples should be sufficient to familiarise yourself with what the application can
do.

EB.QUERIES.ANSWERS Enquiries

EBQA.I.SWIFT92

This Enquiry has the following functionality:

• View all incoming SWIFT MTn92 messages awaiting replies.

• View a specific message, using different selection criteria, i.e. STATUS,
ASSIGNED.TO or MSG.CNTL.CATEGORY e.g. all ‘195’, ‘INWORK’ or all ‘195’
with user ‘TONY’.
• Generate a MTn96 Answer for the incoming MTn92.
• Update status of the messages accordingly. All incoming MTn92 have the Status
 ‘NEW’ when written to the EB.QUERIES.ANSWERS unauthorised file.
• When the above Enquiry is run, and a reply is generated, the status changes to
‘INWORK’ for both the incoming (MTn92) and outgoing (MTn96) messages.
• When the reply is authorised the status then changes to ‘PROCESSED’ for both
messages.

EBQA.I.SWIFT92.VIEW.DETAILS

Shows the SWIFT MTn92 record in a formatted layout.

EBQA.I.SWIFT95

Similar to EBQA.I.SWIFT92, but this Enquiry processes incoming SWIFT MTn95.

EBQA.I.SWIFT95.VIEW.DETAILS

Shows the SWIFT MTn95 record in a formatted layout.

EBQA.I.SWIFT96

This Enquiry has the following functionality:

• View all incoming SWIFT MTn96 messages awaiting authorisation.

• View a specific message using different selection criteria, i.e. STATUS, ASSIGNED.TO or
MSG.CNTL.CATEGORY e.g. all ‘196’, ‘INWORK’ or all ‘196’ with user ‘TONY’.
• Update status of the incoming SW.I.F.T MTn96 message to ‘PROCESSED’ when
authorised.

SWIFT MTn96 Answer does not require a reply.

EBQA.I.SWIFT96.VIEW.DETAILS

Shows the MTn96 record in a formatted layout

Expected receipts

A new functionality AC.EXPECTED.RECS has been added to the Delivery module. This functionality
records the expected funds or payments in T24 and allows the banks to determine the projected
balances, assisting them to perform their business more efficiently. When the funds are received or
payments made these are recorded and also matched with the expected funds or payments.

The notifications to receive the funds can be by means of incoming SWIFT MT210, TELEX or
PHONE etc. When a notification is received via SWIFT, MT210 inward message, then the expected
receipt record is created automatically in AC.EXPECTED.RECS file with STATUS WAITING and the
ER.BALANCE on the account file is updated with the expected balance for the value date. Likewise
expected payments may be recorded, either manually or automatically, when an unauthorised FT is
entered and the EP.BALANCE on the ACCOUNT file is updated with the expected balance for the value
date.

When the receipt of funds is recorded in FT, or when a payment is authorised, T24 will
automatically create the RECEIPT or PAYMENT record in AC.EXPECTED.RECS with STATUS
WAITING. The application AC.EXPECTED.RECS will try to match this record with the
EXPECTED records in the system. If a match is found then the STATUS of these records will be
changed to MATCHED. If the RECEIPT record is not matched then the funds are received without
notification or the funds are received before the notification. To cater for this, the system also tries
to match the EXPECTED funds with the RECEIPT or PAYMENT funds, whenever the
EXPECTED fund record is created.

On the ACCOUNT record the expected receipt and payment balances for the value date are updated
for all the expected funds in the AC.EXPECTED.RECS for the accounts. The expected funds amount
is added to the appropriate field and the receipt or payment amount is subtracted for the value date.

Also, the AC.EXPECTED.RECS provides the facility to enter the expected funds records manually.

ER.PARAMETER

The table ER.PARAMETER defines the account/s and or account type (category) to be monitored
for the expected receipts and payments as well as some other parameters. There is only one record
in this file and is called SYSTEM.
 Figure 78 – ER.PARAMETER

To set which Accounts qualify for selection in AC.EXPECTED.RECS is defined in the ACCOUNT.ID
and/or CATEGORY fields.

You can set the number of days unmatched items and matched items are kept on the system in the
fields AC.OVER.DAYS and AC.RET.DAYS for an account. The system wide and default values
(when not set for individual account) are defined in OVERDUE.DAYS and RETENTION.DAYS.

Fields to be used in the matching process are defined in MATCH.FIELD. The fields ACCOUNT.ID,
CCY.AMOUNT and VALUE.DATE are mandatory since these are crucial to the matching system. In the
TOLERANCE field the user can specify the tolerance to be used in finding the match, the tolerance is
only allowed on the CCY.AMOUNT and the VALUE.DATE fields.

The CCY.AMOUNT tolerance is defined as a percentage of the expected amount. The receipt and
payment records within the limit of the expected records will be matched. If there is more than one
matching record then the first in the list is matched. The system will first attempt for the exact
match before attempting for the tolerance match, but if it is not found the first record found within
the tolerance limits will be.

The VALUE.DATE tolerance is the number of days, before and after the value date, on the matching
record, these are the calendar days. The lower value date is the value date on record minus the
number of working days and the higher limit is the value date plus the number of working days.
Once again the tolerance is used on the record to be matched and the first attempt is for the exact
match and the tolerance is used if the exact match fails.

Also, in matching process the receipt funds are matched with the expected and visa versa.

AC.EXPECTED.RECS Work Flow

After entering the details in the ER.PARAMETER file and authorising it you may then enter details
in AC.EXPECTED.RECS.
Manual Entry of Expected Funds and Payments

The manual entry of FUNDS.TYPE ER is shown below:

Figure 79 - Manual Entry of Expected Funds

Manual Entry of Receipt Fund

The manual entry of FUNDS.TYPE receipt is shown below:

 Figure 80 - Manual Entry of Receipt Funds

Auto Creation of Expected Funds from Inward MT210

Defining Parameters in DE.MESSAGE

T24 has been enhanced to create the AC.EXPECTED.RECS record from the inward MT210 SWIFT
messages automatically for the qualifying accounts. For this it is necessary to set up the OFS details
in the DE.MESSAGE for 210 and start the EB.PHANTOM to run the OFS background process. If the
OFS processing is active for another inward SWIFT message processing then the same OFS process
can be used for the AC.EXPECTED.RECS, but be sure to enter the correct OFS.SOURCE name on
the DE.MESSAGE for 210.

Figure 81 - DE.MESSAGE - MT210 Showing OFS Settings

It is worth noting that DE.I.OFS.MAP.210 is set in the field INWARD.OFS.RETURN, this program
takes the details from the DE.I.MSG.SWIFT and creates the OFS format record for
AC.EXPECTED.RECS for the qualifying records and queues them to the OFS. The version of
AC.EXPECTED.RECS, OFS is defined in field IN.OFS.VERSION, this takes the input from the OFS
and creates the AC.EXPECTED.RECS records.

In OFS.SOURCE field define the ID of the OFS.SOURCE record. This record (OFS.TEST) holds the
required and necessary details for the OFS queue and the OFS queue manager.

Figure 82 - OFS.SOURCE - Queue Details

Starting and Stopping OFS.QUEUE.MANAGER

The application EB.PHANTOM controls i.e. starting and stopping the OFS phantom.

The OFS phantom is activated by the function “V” and can be stopped by using function “I” and
entering STOP in PHANT.STOP.REQ field.
 Figure 83 - EB.PHANTOM - OFS Control Details

Message in AC.EXPECTED.RECS

The number of authorisation on AC.EXPECTED.RECS, OFS version is set to one and all the
AC.EXPECTED.RECS records created will be in INAU (no errors), if there are errors then this will
be in IHLD. The other point to note is that the INPUTTER for these records will be
…GTUSER_(OFS_ID).

Figure 84 - Records Created Via OFS

The IHLD messages should be completed manually or deleted if required, and INAU records
should be authorised before the end of business day, if not the system will delete these messages in
the batch. This applies to any records entered manually or created by any other automatic means.
Workflow creation of Expected FUNDS from SWIFT Inward

Figure 85 - Inward SWIFT MT210

Figure 86 - OFS - Rejected

Figure 87 - OFS - SELECTED - Valid account for AC.EXPECTED.RECS
 Figure 88 - OFS Formatted - Inward Record

Figure 89 - Auto Created AC.EXPECTED.RECS from MT210

 Figure 90 - DE.I.HEADER Showing AC.EXPECTED.RECS ID - after Authorisation

The above shows the complete cycle of the notification of expected funds received via INWARD
SWIFT MT210 and the corresponding record created in AC.EXPECTED.RECS.

Automatic Creation of Receipt or Payment Funds Record from FT.

The users can set the system so that the receipt or payment records are created in the
AC.EXPECTED.RECS from the incoming FT. For this purpose the field EXPECTED.RECS should
be set to ‘YES’ in the FT.TXN.TYPE.CONDITION record.

Figure 91 - Setting FT.TXN.TYPE.CONDITION to automatic create AC.EXPECTED.RECS

Once this has been defined, qualifying payment FTs will trigger generation of an expected payment
record when unauthorised and authorisation of qualifying FT receipt and payment records will
trigger generation and matching of receipt or payment records in the AC.EXPECTED.RECS file.
Please note that if the EXPECTED.RECS field is not set to ‘YES’ for the FT.TXN.TYPE.CONDITION
and it is not for the qualifying account then a record is not created in AC.EXPECTED.RECS.

If an expected receipt or payment record is created then the ID of this record is displayed in the
information box, and if there was an expected record to which this receipt is automatically matched
then a message to this effect is displayed.

Figure 92 - Auto Creation of AC.EXPECTED.RECS record from FT

Figure 93 - Auto Creation of AC.EXPECTED.RECS record from FT with information

Figure 94 - Auto Created AC.EXPECTED.RECS

 Figure 95 - FT Input Auto Creation of AC.EXPECTED.RECS

Figure 96 - FT Record Showing AC.EXPECTED.RECS Matched record’s ID

 Figure 97 - Auto Swift and Ft Created - Matched

New Records in AC.EXPECTED.RECS

New expected records created in AC.EXPECTED.RECS will have the STATUS WAITING in the
record.

Account File Update

When the new record in AC.EXPECTED.RECS is authorised the ER.VALUE.DATE, ER.BALANCE and
EP.BALANCE fields are updated on the ACCOUNT file for the ACCOUNT.ID on the
AC.EXPECTED.RECS as shown below, but no account balances are updated. The FUNDS.TYPE
ER will increase the ER.BALANCE and FUNDS.TYPE RECEIPT will decrease it. The FUNDS.TYPE
EP will increase the EP.BALANCE and FUNDS.TYPE PAYMENT will decrease it.

Figure 98 - ACCOUNT File Update - ER.BALANCE on ER.VALUE.DATE

Auto Exact Matching Expected with Receipt or Payment

Whenever a new record is authorised in the AC.EXPECTED.RECS the automatic matching

processing kicks in. This will try to match the new record with the existing records of the opposite
FUNDS.TYPE (new RECEIPT/PAYMENT will be matched with the ER/EP or new ER/EP will be
matched with the existing RECEIPT/PAYMENT) and all the MATCH.WITH fields defined in the
ER.PARAMETER.

Auto Matching of Expected and Receipt or Payment within Tolerance

If the exact match is not found and the TOLERANCE is specified in the ER.PARAMETER then the
lower limit and higher limit values are calculated using the base values of the new record and the
TOLERANCE specified. The lower limit and higher limit values are used for TOLERANCE and
MATCH.WITH fields, and exact match for non-tolerance MATCH.WITH fields to find the match from
existing records on the file.

If there is more than one matched record then the first record is selected from the match list.

Matched Records

When two records are matched their STATUS is changed to MATCHED, and the MATCHED.WITH
field will have the corresponding matching records ID.

Figure 99 - AC.EXPECTED.RECS Matched information

Manual Matching

Basic METHOD

It is possible to manually match the expected receipt or payment records. The basic method is to go
to the application AC.EXPECTED.RECS or via a version such as AC.EXPECTED.RECS,MATCH
and use input function and select the record to be matched (current STATUS should be WAITING,
or PARTIAL MATCHED), change the STATUS to F (FORCE MANUAL MATCH) and insert or
select the ID of the record to be matched with in MATCH.WITH field. If the records are compatible
i.e. the ACCOUNT.ID and CURRENCY are the same but the FUNDS.TYPE are different then these will be
matched. The record with a lower amount will have STATUS MATCHED i.e. fully matched and the
record with the higher amount will have STATUS PARTIAL MATCHED. The PARTIAL
MATCHED record can be manual matched again with another record.
Using Context Flow Enquiries – AC.EXP.MATCH and AC.EXP.RECS

Some sample context enquiries and versions are provided which can be used for manual matching
the expected receipts and payments. The AC.EXP.MATCH enquiry displays the expected
receipt/payment messages with FUNDS.TYPE EXPECTED and the STATUS WAITING or
PARTIAL MATCHED.

The enquiry AC.EXP.RECS displays the records with FUNDS.TYPE of RECEIPT and PAYMENT
and with STATUS of either WAITING or PARTIAL MATCHED.

These two enquires are displayed side by side. Highlight the desired record from the
AC.EXP.MATCH and right click the mouse. The options Details and Match expected with the
receipts/payments will be shown. Select ‘Match expected with receipts’ option. This will initiate
AC.EXPECTED.RECS, MATCH version.

Figure 100 - Manual Match – getting ready

Figure 101 - Manual Match - EXPECTED Selected

Highlight the record from the receipt/payment list and drag and drop the record on the MATCH.WITH
field. Then authorise the record. You will notice that when the record is selected it will be removed
from the list (from the expected list).
 Figure 102 - MANUAL MATCH paired

Small Balances Left in ER.BALANCE

When there are match records with in the CCY.AMOUNT tolerances, it is unavoidable that the small
balances will remain on the ER.BALANCE EP.BALANCE fields of the ACCOUNT file although the
Expected fund is fully matched with the Receipt fund. These can be offset with a compensating
receipt/ payment or expected record.

Amounts Matched with Different Value dates

When the expected funds are for one value date but received/payment with an different value date,
then the ER.BALANCE or EP>BALANCE on the ACCOUNT file will have a positive amount for
EXPECTED funds for the expected value date and negative amount for the RECEIPT/PAYMENT
VALUE date. If the tolerance is set then these two will be matched on AC.EXPECTED.RECS but
the ACCOUNT file will give somewhat distorted information. Again, doing two opposite records
for the two dates can rectify this.

Other useful example Enquires

Since the provision of this information does not affect the accounting, interest or charges in T24 the
user will need to evaluate the information via an Enquiry or two. Since we know that the two fields
per value date on Account contain the sum of the amounts receivable and payable (noting the
possible differences caused by tolerance matching), we can apply this to the real account balances
and show a projection of what the account would be like if the amounts are all received as specified.

Whether to use the cleared balance or uncleared balance?

A forward valued item received will impact the uncleared balance today and then the cleared
balance on the value date (or exposure date if set differently). So if we use the cleared balance as a
base, a forward item expected will be included in the projection until it’s authorised then as it won’t
be included in the cleared it will disappear from the projected totals. So it is more appropriate to use
the uncleared balance for this type of information.

The ENQUIRY AC.EXP.BAL below shows there are expected amounts for several days. The last date
shows a negative amount so we know some money has come in unexpectedly. Since it is negative
we cannot use it in the totalling, we should investigate it and create an automatic offset for it.
 Figure 103 - AC.EXP.BAL

The ENQUIRY AC.EXP.TOT below shows the information but with a bias towards the records
themselves so we can display more details.

Figure 104 - AC.EXP.TOT

The next ENQUIRY AC.UNEXPECTED shows a list of received and expected deals and whether they
are waiting or matched. We can see the deal that is causing the negative figure and have used the
right mouse button to activate a link to a Version, which will create the opposite deal for matching
purposes.
 Figure 105 - AC.UNEXPECTED

The version, which is called, is a simple one just to create the opposite deal to balance our figures.

Figure 106 - Create an opposite deal

Alternatively we can use a dedicated ENQUIRY such as AC.UNEXP, which looks at the received
records that have not been matched. This may be a quicker way of finding the unexpected receipt.

Figure 107 - AC.UNEXP

Lastly, there will incoming MT210 messages coming in which are for accounts that are not set-up
to use the AC.EXPECTED.RECS system. We can monitor the incoming messages from
DE.I.HEADER and filter out the ones we do not need to see. Since the transaction reference of the
authorised AC.EXPECTED.RECS record is written back to DE.I.HEADER the Enquiry could be
filtered even more, say to show those that have not been processed in AC.EXPECTED.RECS.

Figure 108 - MT210.RECVD

AC.ENRICHMENT

This is a small table, which holds the enrichment for the STATUS values in AC.EXPECTED.RECS.
It is possible that this may be extended to hold other enrichments in T24.
 Figure 109 - AC.ENRICHMENT - LIST

Batch Processing

The programs AC.EXP.RECS.CLEAR.UNAUTH and AC.EXP.RECS.EOD are run in

SYSTEM.END.OF.DAY2 batch.

AC.EXP.RECS.CLEAR.UNAUTH

This program clears the unauthorised AC.EXPECTED.RECS file and should run daily in the
SYSTEM.END.OF.DAY2 batch.

AC.EXP.RECS.EOD

This program will do all the necessary Close of Business processing and should run daily in the
SYSTEM.END.OF.DAY2 batch.

This will archive records from the AC.EXPECTED.RECS file to the AC.EXPECTED.RECS$HIS
file for those that have reached the value date as determined from the AC.RET.DAYS in the
ER.PARAMETER file for an account and if not defined then the default value from
RETENTION.DAYS.

Calculate the ER.BALANCE for the ER.VALUE.DATE from the records in the AC.EXPECTED.RECS
and update these on the ACCOUNT file, provided the value date is with in the range of
AC.OVER.DAYS for the individual account, if not set then in range of default from OVERDUE as set in
the ER.PARAMETER file.

Delete the records with the STATUS CANCELLED, HISTORY, ARCHIVE, EXP and REVERSAL
from the AC.EXPECTED.RECS file.

Clear the ER.BALANCE and ER.VALUE.DATE from the ACCOUNT file for the accounts not having
any AC.EXPECTED.RECS records.
Please refer to FUNDS TRANSFER user guide for set-up and process related to Corresponding
bank cover limit processing.