12/06/2020 Setup

You are here: Banking Framework > Delivery > Delivery General > Setup

https://tcsp.temenos.com/R19CD/R19CD.htm?authToken=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6IjZhRmxwMUcxY2ZubGNkWHpa… 1/14
12/06/2020 Setup

Setup

Product Code
A new product code 'SF' has been introduced from R13 for swi messages. With this new product code, swi messages will be forma ed only if ‘SF’ product is
installed, failing which the messages will go to Repair status. This is applicable for both incoming and outgoing messages.

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.

With the replacement of forma ng phantom and ad-hoc processing with the new delivery services the se ngs in DE.PARM may not all be applicable, they are
included as there will be there may be a short parallel usage of them un l the services are fully adopted a er upgrading.

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 forma ng modules. Shut-down can be:

Urgent (a er the message currently being processed)

Normal (when all queues have been processed)

2. Parameters that can be used to op mise the performance of all the Carrier Control
modules and the Inward and Outward Forma ng modules. These give the following
op ons:

A er 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 me can be specified. This is the me that Carrier Control and the
Forma ng modules will wait between finishing the processing of all their
queues and searching them again for input. (A longer wait me 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 me difference from the CET. This is used in
TIME.CET conversion on SWIFT messages and added a er the me.

Note: Shutdown of services using DE.PARM affects only the few remaining phantom services; the newer services are controlled using the TSA.SERVICE
records.

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 sec on 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 forma ng rules (DE.FORMAT.CARRIER) and the carrier module (e.g. SWIFT). If the carrier module is GENERIC the interfacemust 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, forma ng 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 forma ng files and F.DE.O.MSG.interface and F.DE.I.MSG.interface for the interface files.

https://tcsp.temenos.com/R19CD/R19CD.htm?authToken=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6IjZhRmxwMUcxY2ZubGNkWHpa… 2/14
12/06/2020 Setup

Details of all Carrier records available in Delivery

Op on to Enable/Disable Hold Feature for Carriers

A new field is introduced in DE.CARRIER named ‘Allow Hold Output’ with 2 op ons – Yes and No. The default value is No.

This field allows the bank to indicate if the Hold Output related fields can be manually entered or can be setup in DE.CUSTOMER.PREFERENCES and DE.ADDRESS
linked to the respec ve carrier.

a) Allow Hold =YES

b) Allow Hold = NO

https://tcsp.temenos.com/R19CD/R19CD.htm?authToken=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6IjZhRmxwMUcxY2ZubGNkWHpa… 3/14
12/06/2020 Setup

Alterna ve Character Mapping (DE.ALT.CHARS)

The purpose of this customisable table is to hold character mappings for the replacement of language specific characters to SWIFT acceptable characters. For
example, if a field is defined as a language based field, and the data captured is in the French, the system allows standard French characters such as á,è,é,Ç; if
German characters, then it allows ü,ß. When the system uses such informa on on SWIFT messages, it converts it to SWIFT acceptable characters.

The system provides a default set of known characters and the alterna ve replacements. In addi on, it provides means of amending the table, if a client wants to
add more characters.

The key to the table must be a meaningful ID that must be relevant to any valida on or conversion and used in the carrier’s forma ng of the message. Null, one or
more characters may replace a single language specific character.

https://tcsp.temenos.com/R19CD/R19CD.htm?authToken=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6IjZhRmxwMUcxY2ZubGNkWHpa… 4/14
12/06/2020 Setup

The ASCII.VALUES table needs to be configured to ensure that character sets are allowed.

DE.FORMAT.SWIFT
It is possible to define invalid characters and their replacement values by message format types. For example:

SWIFT message types: ‘è’ is not allowed for this message type and should be replaced with ‘e’
CAMT message types: ‘è’ is not allowed for this message type and does not need to be replaced, whereas ‘â’ is not allowed and should be replaced with ‘a’.

This is achieved by a aching CONV*[DE.ALT.CHARS] to the field to be converted as shown in the screenshots below.

Product table (DE.PRODUCT)

The product informa on on the Product table (DE.PRODUCT) is used by the forma ng process when expa

nding the Header record for the copies required for the message. Product informa on consists of status (normal, hold or delete), carrier/delivery address, which
version of the format should be used and how many copies should be made.

A er the header record has been expanded, the Product record is not read again for this message, even if the message is resubmi ed and is placed again on the un-
forma ed queue. Therefore, if language, format or copies are to be changed a er the Header record has been expanded, the message must be "rerouted" (see
sec on on Re-rou ng Messages).

Product records may be specified for:

A par cular company

A customer
An account (Note that this is only applicable for Statement types messages)

And each of the above may be specified for:

https://tcsp.temenos.com/R19CD/R19CD.htm?authToken=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6IjZhRmxwMUcxY2ZubGNkWHpa… 5/14
12/06/2020 Setup
All message types
Specific message types
All banking applica ons
A specific applica on

During forma ng, 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 un l 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. Applica on, "ALL" or xxyy where xx is the applica on code and yy is the Funds Transfer product code.

5. Por olio specific DE.PRODUCT for SEC.ACC.MASTER related applica ons.

Display details of DE.PRODUCT record

https://tcsp.temenos.com/R19CD/R19CD.htm?authToken=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6IjZhRmxwMUcxY2ZubGNkWHpa… 6/14
12/06/2020 Setup

SEC.ACC.MASTER

DE.PRODUCT_SCP1

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 mul -value set on the Header record.

The mul -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 par cular carrier should send two copies, these copies are split on the Header record into two mul -value sets.

https://tcsp.temenos.com/R19CD/R19CD.htm?authToken=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6IjZhRmxwMUcxY2ZubGNkWHpa… 7/14
12/06/2020 Setup
If a single message should be sent to mul ple customers, the field MDR.CUSTOMER on the mul -value set can be used to specify addi onal 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 applica on is more specific.

If for a par cular 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.

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 organisa on. The
basic postal address of each customer is automa cally updated when the address is changed through Customer maintenance (CUSTOMER), crea ng a record on the
Address table with a key of:

COMPANY ".C-" CUSTOMER ".PRINT.00001"

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

SWIFT ids, Telex numbers and alterna ve 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.

The address number is in the range 00001 to 99999.

Display details of the DE.ADDRESS record

During forma ng, a er the product record has been read, the Address table is read for each copy of the message in the mul -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.

https://tcsp.temenos.com/R19CD/R19CD.htm?authToken=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6IjZhRmxwMUcxY2ZubGNkWHpa… 8/14
12/06/2020 Setup
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 se ng HOLD.OUTPUT to “Y”. The message will be going through delivery in the normal way, but instead of
being printed, it will be wri en to HOLD.CONTROL. When required, ll messages for the customer can be printed using PRINT.CUST.OUTPUT.

Addi onal Address lines into Delivery Address

A new mul value ADDRESS field is added in DE.ADDRESS.

The current logic which updates the DE.ADDRESS PRINT.1 record when the CUSTOMER’S main address is updated is changed to copy the ADDRESS lines from the
CUSTOMER record to the DE.ADDRESS PRINT.1 record.

For all other DE.ADDRESS records the ADDRESS mul -value field is manually entered.

Alternate carrier table (DE.ALTERNATE)

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

The Alternate table is accessed if the MSG.DISPOSITION field on the Header record is set to "REROUTE". See sec on on "Re-rou ng Messages" for informa on on
how this field can be set.

When a message is passing through forma ng, 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 and also the use of A is for Statement type messages)

3. Carrier followed by "."

4. Address number ( nnnnn as per DE.ADDRESS)

https://tcsp.temenos.com/R19CD/R19CD.htm?authToken=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6IjZhRmxwMUcxY2ZubGNkWHpa… 9/14
12/06/2020 Setup
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.

Display DE.ALTERNATE record

Disposi on control table (DE.DISP.CONTROL)

As the priority of a message can only be ‘N’, the DE.DISP.CONTROL applica on is used to change the status of a message.

Disposi on checks will be done a er the carrier is iden fied at the transac on level itself.

If the messages need to be marked to HOLD, DELETE and REROUTE etc, the appropriate files will be updated. If HOLD the DE.O.HOLD.KEY will be updated if DELETE
the DE.O.HEADER gets deleted and if REROUTE the message is put into alternate carrier ac va on file

On releasing the DE.O.HEADER from HOLD, the held records will be moved into appropriate carrier ac va on files.

DE.DISP.TIMECHECK (now a service) will process the messages marked as HOLD un l par cular me.

The Disposi on control table (DE.DISP.CONTROL) is used to specify special condi ons for which par cular processing is required. Providing the condi ons are
sa sfied, the requirements specified on the Disposi on control table will override all other requirements. The only proviso to this is that it cannot override
restric ons such as dele ng 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 disposi on control table could be used are as follows:

All messages for a par cular 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 se ng up condi ons on which the message status is set. Alterna vely, a user-defined rou ne can be specified to check complex condi ons
- the rou ne passes back whether the condi ons were matched or not. The rou ne name is placed in FIELD.NAME and must be prefixed by the @ character. The
rou ne 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 rou ne itself should be specified as

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

Records are added to the Disposi on Control table with a numeric key. When transac on is entered and goes through forma ng stage, the disposi on control table
is examined in numerical order un l a record is found whose condi ons are sa sfied or there are no further records on the Disposi on control table. Thus, if a
message matches condi ons specified on disposi on control records 10 and 50, only record 10 will be applied to the message. Therefore, it is important when
entering records on the Disposi on control table to assign the key according to the importance of the record.

Condi ons can be specified on the Disposi on control record to compare fields on the Header record to certain values. For example, CARRIER EQ SWIFT or AMOUNT
GT 1000000. The condi on fields are mul -value and assume a condi on of "AND". Therefore, complex condi ons can be built by se ng up several simple
condi ons in a mul -value set. E.g. AMOUNT GT 1000000 AND CURRENCY EQ GBP. All the condi ons must be true before the status is applied. If "OR" is required,
separate records must be entered. See the Help text for more informa on on entering condi ons.

Also specified on the Disposi on control record is what should be done with messages, which match the condi ons specified. This is entered in the STATUS field and
can be "HOLD", "HOLD hh:mm", "WAIT hh:mm", "RELEASE", "DELETE", "RESUBMIT", "REROUTE" or "PRINT".

“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.

https://tcsp.temenos.com/R19CD/R19CD.htm?authToken=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6IjZhRmxwMUcxY2ZubGNkWHp… 10/14
12/06/2020 Setup

Se ng Parameters on the Disposi on Control Record

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

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

"HOLD", "WAIT", "DELETE", "RESUBMIT" and "REROUTE" affect records with a disposi on of "Forma ed" and operate subsequently during Forma ng on records
that would have been set to "Forma ed". WAIT hh:mm is translated to HOLD hh:mm when the Disposi on control record is applied.

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

"PRINT" prints an image of forma ed 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 bo om 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 Disposi on control record placed in the appropriate "Disposi on No" field for each copy of the message
affected. This ensures a less important disposi on 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 condi ons no longer apply.

Running disposi on control is by use of the TSA.SERVICE record DE.DISP.TIMECHECK

Interface file (DE.INTERFACE)

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

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

There is li le valida on of the fields on DE.INTERFACE. This is to allow for maximum flexibility when new interfaces are wri en.

The id of the file is the interface as defined in the INTERFACE field on DE.CARRIER.

https://tcsp.temenos.com/R19CD/R19CD.htm?authToken=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6IjZhRmxwMUcxY2ZubGNkWHp… 11/14
12/06/2020 Setup

Diversion (DE.SWIFT.DIVERSION)
You may wish to send all SWIFT statements, for example, to a Nostro reconcilia on 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, SWIFT.OUT,
instead of the message being sent to the ST400, for example, it is wri en 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 par cular
SWIFT address are to be diverted. Both outgoing and incoming messages can be diverted. Incoming messages may also be ‘copied’ by se ng ALLOW.PASS.THRU to
YES

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

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.

https://tcsp.temenos.com/R19CD/R19CD.htm?authToken=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6IjZhRmxwMUcxY2ZubGNkWHp… 12/14
12/06/2020 Setup

Real Swi 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.

Product records route 950 messages to SWIFT.2 address

https://tcsp.temenos.com/R19CD/R19CD.htm?authToken=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6IjZhRmxwMUcxY2ZubGNkWHp… 13/14
12/06/2020 Setup
All other messages are routed to SWIFT.1 address

Alterna vely, 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.

Published on: 06/05/2019

https://tcsp.temenos.com/R19CD/R19CD.htm?authToken=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6IjZhRmxwMUcxY2ZubGNkWHp… 14/14