Confirmation Matching - User Guide

Release R15.000
June 2015

©2015 Temenos Headquarters SA - all rights reserved.

Warning: This document is protected by copyright law and international treaties. Unauthorised reproduction of this document, or any portion of it, may
result in severe and criminal penalties, and will be prosecuted to the maximum extent possible under law.
Table of Contents
Introduction 3
Purpose of this Guide 3
Intended Audience 3
Confirmation Matching - Overview 4
Setup 5
CM.PARAMETER 5
Manual Matching 5
CM.MESSAGE.TYPE 5
CM.HOLDING.QUEUE 9
CM.MESSAGE 9
CM.MATCH.ITEM 12
CM.UNMATCHED.ITEM 12
CM.PAR.UNMATCHED.ITEM 12
Deal / Transaction Processing 13
General Process of Automatic Matching 13
Enquiries 19
Running the Enquiries 19
MANUAL MATCHING USING ENQUIRIES 21

Confirmation Matching - User Guide - Release R15.000 - Page 2 of 25

Introduction

Purpose of this Guide

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

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

Confirmation Matching - User Guide - Release R15.000 - Page 3 of 25

Confirmation Matching - Overview

Messages sent or received by the Electronic Delivery System are copied to the confirmation matching application module. Message types spe-
cified within the CM application parameter files are selected for matching. The incoming messages are matched with the outgoing messages and
the messages are matched where both have identical match keys.

The messages requiring matching need not only be the confirmation messages but can be any other message types. Although the intentions are
that this application is used for confirmation matching, i.e. S.W.I.F.T. message types MT300, MT320, MT324, MT330 and MT350.

Confirmation Matching - User Guide - Release R15.000 - Page 4 of 25

Setup

Setup of Confirmation Matching is minimal. The two files that will need to be populated by the user are the CM.PARAMETER and
CM.MESSAGE.TYPE, which are described in more detail later.

The details here are provided based on a configured T24 database that is already producing inward and outward messages.

CM.PARAMETER
The CM.PARAMETER table contains only a single SYSTEM record. It defines the number of days a message need stay on the system once it
has been matched and is archived to the history file.

It defines parameters for the Confirmation Matching application. The key to this file must always be SYSTEM, as this is the only key allowed.
The DAYS.TILL.ARCHIVE field stores the number of days that messages should remain on the CM.MESSAGE application after successful
matching, before being archived to the history file and removed from the live file.

It is also possible to use a user defined routine in confirmation matching, the name of which is specified here.

CM.PARAMETER file

Manual Matching
Users can manually match the unmatched and partially matched items.

Different Context Based Workflow enquiries have been written to allow these enquiries to launch the CM.MESSAGE application and also to
automatically populate the MATCH field of the record with data from the ENQUIRY.

CM.MESSAGE.TYPE
The CM.MESSAGE.TYPE is used to define the message types to be matched and the match tags to be used, for outgoing and incoming mes-
sages. The outgoing and incoming tags are used with the S.W.I.F.T. message to form the match keys.

There are two types of tags; one the MATCHING.TAG and the other the OPTION.TAG.

These tags must be valid for the S.W.I.F.T . message type entered, i.e. they correspond to the message defined in DE.FORMAT.SWIFT and
should be valid field tags on the DE.TRANSLATION. The MESSAGETYPE,RECEIVER or SENDER can also be defined for the keys.

MATCHING TAGS
These tags are used to form the mandatory part of the match keys.

Confirmation Matching - User Guide - Release R15.000 - Page 5 of 25

OPTIONAL TAGS
These are used to form the optional part of the match key.

LOCAL.REFERENCE
There is one extra field, LOCAL.REF, on this file. The value of this field is held on the CM.MESSAGE file.

The application defines valid message types for confirmation matching which must exist on the DE.MESSAGE application. If this message does
not exist then an error is displayed as shown below.

Error is displayed if message does not exist

Once the message type is read successfully. The body of the message type contains rules for matching this kind of message; these are man-
datory and/or optional S.W.I.F.T. tags.

Message type rules

Notice that the OUT.MATCH.TAG and IN.MATCH.TAG are multi-valued mandatory fields and the OUT.OPTION.TAG and IN.OPTION.TAG
are multi-valued optional fields.

When these tags are entered into the message they are prefixed internally with ‘SW’ and then checked against the DE.TRANSLATION applic-
ation to check if they are valid S.W.I.F.T. tags. If these tags do not exist then an error message is generated at entry time as shown in the fol-
lowing image.

Confirmation Matching - User Guide - Release R15.000 - Page 6 of 25

 OUT.MATCH.TAG displays error if the tag does not exist

In our next example we have created an extra multiple entry for the OUT.MATCH.TAG and IN.MATCH.TAG. Notice that duplicate values have
been entered, but these are not allowed. At the commit record stage, errors will be generated as shown below. This will also apply for the
OUT.OPTION.TAG and IN.OPTION.TAG.

Duplicate tags are not allowed

The tag enrichment displayed comes from the DE.TRANSLATION record so the user can verify that the correct tag(s) have been used.

Confirmation Matching - User Guide - Release R15.000 - Page 7 of 25

 Swift tag from DE.TRANSLATION

A further check is made on the DE.FORMAT.SWIFT application. From our example the message type is ‘300’. This message type is then suf-
fixed with ‘.1.1’ so that it becomes 300.1.1, which must be a valid key on the DE.FORMAT.SWIFT application. The record is read from
DE.FORMAT.SWIFT, as displayed in the example screenshot below, and the system verifies that the tag is used in that record.

Once a check is made for a valid Swift tag the record is displayed from DE.FORMAT.SWIFT

Any S.W.I.F.T. tags entered into the message type ‘300’ must also exist in the DE.FORMAT.SWIFT record. If it does not then an error is gen-
erated at entry time as shown below.

Confirmation Matching - User Guide - Release R15.000 - Page 8 of 25

 Tag must exist in the DE.FORMAT.SWIFT record for the message

CM.HOLDING.QUEUE
The delivery system will place all S.W.I.F.T. messages in the internal  CM.HOLDING.QUEUE file and those of types defined in the
CM.MESSAGE.TYPE application are passed forward to CM.MESSAGE.

CM.MESSAGE
This file stores messages received by the delivery process. Originally the message key and the message body are held in its raw format in the
CM.HOLDING.QUEUE. The message is read and written in a sensible format to the CM.MESSAGE application. Most of the message details
are generated by the system from the S.W.I.F.T. message content.

Confirmation Matching - User Guide - Release R15.000 - Page 9 of 25

 WFM – Waiting for match

The STATUS will be defaulted to ‘WFM’, which stands for “Waiting For Match”. The MATCH field will be empty and allows a user to select a
message key from a list of messages generated from the CM.MESSAGE application.

Confirmation Matching - User Guide - Release R15.000 - Page 10 of 25

 Select a message key from list of messages generated

The STATUS flag can also be changed by selecting one from the predefined list.

Confirmation Matching - User Guide - Release R15.000 - Page 11 of 25

 Status flag can be changed from predefined list

CM.MATCH.ITEM
This file stores messages that are to be matched. When these messages are processed, if corresponding messages do not exist on the
CM.UNMATCHED.ITEM application, then one is created and marked as processed. It in effect becomes the unmatched side. If however a mes-
sage is matched against an unmatched message, then they are matched.

CM.UNMATCHED.ITEM
The file stores messages from the CM.MATCH.ITEM application, the key being the full matching criteria.

CM.PAR.UNMATCHED.ITEM
The file stores messages from the CM.MATCH.ITEM application, the key being the partial matching criteria.

Confirmation Matching - User Guide - Release R15.000 - Page 12 of 25

Deal / Transaction Processing

General Process of Automatic Matching

A copy of generated S.W.I.F.T. messages (sent out or received) is placed onto the confirmation matching holding queue file,
CM.HOLDING.QUEUE. Each message on this queue is individually taken and processed; its entry effectively removed. If the required message
type is of the type specified in the confirmation matching application file, CM.MESSAGE.TYPE, it is passed for matching, otherwise it is dis-
carded.

General process of Automatic Matching

A match key is generated for the message using the S.W.I.F.T. tag contents and the matching tags. For each message type that needs matching
the matching tags are defined in CM.MESSAGE.TYPE. If the match key has a value then the message is selected for matching. The selected
message is stored on CM.MESSAGE and the MATCH.KEY is written to CM.MATCH.ITEM, both with the same record key.

Two additional work files are used for the matching process, CM.UNMATCHED.ITEM and CM.PAR.UNMATCHED.ITEM . The
CM.UNMATCHED.ITEM file is used for full matching and the CM.PAR.UNMATCHED.ITEM file for partial matching. The unmatched item is
written to the CM.UNMATCHED.ITEM file with a record key of the matching key.

The matching process tries to read a record from the CM.MATCH.ITEM and compares it to the MATCH.KEY of each work file on the
CM.UNMATCHED.ITEM file. If this record exists on CM.UNMATCHED.ITEM then a match has been found. The entries on CM.MESSAGE
and CM.MATCH.ITEM referenced by the item found on CM.UNMATCHED.ITEM are updated, as are the originating entries for the current
CM.MATCH.ITEM. The entry on CM.UNMATCHED.ITEM is removed. If the entry for the full MATCH.KEY does not exist on
CM.UNMATCHED.ITEM, then a record is created on the CM.UNMATCHED.ITEM work file for a matching message.

Confirmation Matching - User Guide - Release R15.000 - Page 13 of 25

The partial matching procedure is similar to the full matching procedure, the difference being that this uses the partial match key and the
CM.PAR.UNMATCHED work file for matching.

The user using manual matching matches any unmatched or partial unmatched messages.

Detailed Process of Automatic Matching

Confirmation Matching - User Guide - Release R15.000 - Page 14 of 25

Starting / Stopping Processors
Two services, CM.NEW.MESSAGE and CM.FIND.MATCH.MESSAGE automate the matching of messages. The service CM.NEW.MESSAGE
selects the messages for automatic matching from the CM.HOLDING.QUEUE and the matches the messages.

The EB.PHANTOM application is used to control the starting, stopping and trouble shooting of these phantoms.

Automatic Matching Process

The process of automatic matching is divided into two distinct tasks; firstly to get the new messages for automatic matching and secondly to
perform the matching of the messages. As said above, these are performed by two services:

CM.NEW.MESSAGE
The CM.NEW.MESSAGE service selects messages from the CM.HOLDING.QUEUE in readiness for matching. A message is selected for match-
ing only if its message type is defined in the CM.MESSAGE.TYPE file.

The message types requiring matching are held as records on the  CM.MESSAGE.TYPE file with the S.W.I.F.T. message type as their key. The
matching tags to be used for each message type are defined within these records. Also, the MESSAGE.TYPE, SENDER or RECEIVER can be
used for matching.

The MATCH.KEY is built by locating, within the message, each tag specified on the message type record of the CM.MESSAGE.TYPE file and
retaining the corresponding contents. These values are concatenated to produce the MATCH.KEY.

For example, for message type 300 the MATCH.TAGS requiring a match are 20 and 30T.

l CM.MESSAGE.TYPE
l RECORD ID 300
l KEY1 20
l KEY2 30T

The message MT300 holds the entry:

:20:REF1A

:30T:20000506

The tags will be located in the message and the values, “REFIA” for 20 and “20000506” for 30T, are retained for match keys. In this case the
MATCH.KEY would be “REFIA:20000506”. In the above example only the relevant details are shown.

Two types of match key are generated, a full match key and a partial match key. If there is a value in either match key then the message is selec-
ted for matching.

The status and various other details of the message are written to a record in the CM.MESSAGE file. The match keys are written to a separate
record on the CM.MATCH.ITEM file. These two records have the same key as received from the CM.HOLDING.QUEUE file and this is also
the same as on the originating S.W.I.F.T. message. The full contents of these two files are detailed later in this document.

The processed message is deleted from the CM.HOLDING.QUEUE.

Confirmation Matching - User Guide - Release R15.000 - Page 15 of 25

 CM.NEW.MESSAGE service

CM.FIND.MATCH.MESSAGE

Full Match
The CM.FIND.MATCH.MESSAGE service matches the messages from the CM.MATCH.ITEM file.

This reads the CM.MATCH.ITEM record and gets the match keys. For the message to be matched, first it tries to find the match using the
FULL.MATCH.KEY with the messages held on the CM.UNMATCHED.ITEM file. If a match is found, i.e. a record is found on the
CM.UNMATCHED.ITEM file with the same match key, then the message on the CM.MESSAGE status is changed to ‘MAT’ (matched) and the
key of the matched message is copied into the field MATCH. Similarly, the record of the ‘matched with’ message is also modified. The message
keys of these two matched messages are removed from the CM.PAR.UNMATCHED.ITEM records, in the field MESSAGE.KEY.

If a full match is not found then a new record is created in the CM.UNMATCHED.ITEM file with the FULL.MATCH.KEY record key.

Confirmation Matching - User Guide - Release R15.000 - Page 16 of 25

 CM.FIND.MATCH.MESSAGE Service

Part Match
If a full match is not found then, a match is attempted from the PART.MATCH.KEY with the items already held in the
CM.PAR.UNMATCHED.ITEM. If a match is found on the CM.PAR.UNMATCHED.ITEM then the original message ID is added to the
MESSAGE.KEY field on this record (of CM.PAR.UNMATCHED.ITEM) and all the message keys held on this record are copied to the message
record of the new matching message on the CM.MESSAGE file. Now, the message key of this record is added to the messages, whose keys are
held on the MESSAGE.KEY field of the  CM.PAR.UNMATCHED.ITEM record. In fact, this field contains the list of all messages having the
same partial match key.

If a match is not found with the CM.PAR.UNMATCHED.ITEM then a new record is created with the ID of the PART.MATCH.KEY and the
details containing the ID of the message being processed.

The STATUS on the CM.MATCH.ITEM is changed to “PROCESSED”.

The process is repeated for the next message. If there are no more messages to be processed then it will wait for the next message.

After processing a message, the process checks to see if the user has requested a stop, in which case the process terminates and exits.

Confirmation Matching - User Guide - Release R15.000 - Page 17 of 25

 Part Match using CM.PAR.UNMATCHED.ITEM

Confirmation Matching - User Guide - Release R15.000 - Page 18 of 25

Enquiries

The three main enquiries involved in Manual Matching are:

l CM.MSG.VIEW.DETAILS
l CM.I.SEARCH
l CM.O.SEARCH

Running the Enquiries

The above enquiries can be run by:

l Selecting one of the enquiries from the ENQUIRY Index Menu.

l Preceding the ENQUIRY Name with ‘ENQ’ at the command line.
l Through the stack list in the Enquiry Toolbar, which stores recently used enquiries.

ENQ CM.MSG.VIEW.DETAILS
This enquiry may be used to view details of a record on the CM.MESSAGE File. The required record is selected by entering the Message ID as
the selection criteria.

Enquiry CM.MSG.VIEW.DETAILS, details of CM.MESSAGE record

Confirmation Matching - User Guide - Release R15.000 - Page 19 of 25

ENQ CM.I.SEARCH
This enquiry may be used to display inward swift messages for manual matching. You can choose to view all messages. Other selection criteria
include MESSAGE.TYPE,DATE and TIME. The displayed messages show the MESSAGE.KEY and the MATCH.KEY.

Enquiry ENQ.CM.I.SEARCH displays inward Swift Messages for manual matching

ENQ CM.O.SEARCH
This enquiry may be used to display outward swift messages for manual matching and it is selected and displayed similarly to the
CM.I.SEARCH Enquiry.

Confirmation Matching - User Guide - Release R15.000 - Page 20 of 25

 Enquiry CM.O.SEARCH displays Outward Swift Messages for manual matching

MANUAL MATCHING USING ENQUIRIES

Since the Match Keys for both the inward and the outward Swift Delivery Messages are displayed in the above enquiries, possible matches,
with similar Match Keys can be easily spotted.

Viewing Records
To see a more detailed view of the record, click the mouse on any of the Delivery Messages in the CM.I.SEARCH or the CM.O.SEARCH Enquir-
ies to display the following options:

View Record: (magnifying glass icon)

This shows the Delivery Message as a Report Enquiry, with the Message Key in the header, and full details including Swift Body and Swift tags
in the body of the report.

Confirmation Matching - User Guide - Release R15.000 - Page 21 of 25

 Delivery Message as a Report Enquiry with Message Key in Header

View Details

This option may be used to view details of a record on the CM.MESSAGE file. The SWIFT.TAGS are arranged in ascending order with the cor-
responding SWIFT.BODY.

Confirmation Matching - User Guide - Release R15.000 - Page 22 of 25

 View details of a record on the CM.MESSAGE file

Matching Records
Match Items

This option brings up the CM.MESSAGE record for the relevant MESSAGE.KEY.

Confirmation Matching - User Guide - Release R15.000 - Page 23 of 25

 Match items from CM.MESSAGE record

Records can be manually matched from this screen, either by typing an existing delivery message key in the MATCH field, or by double clicking
on the Delivery Message key in the CM.I.SEARCH and CM.O.SEARCH Enquiries.

Confirmation Matching - User Guide - Release R15.000 - Page 24 of 25

 Match records manually using CM.MESSAGE,MATCH.ITEM

Using features such as Auto Launch Enquiries and displaying the messages can make the manual matching a lot easier.

View CM.HOLDING.QUEUE
This file will not have a T24 program behind it as it contains the actual S.W.I.F.T. message in one field, which could be too long for T24 to
interpret. Viewing this file is done through a specially written enquiry CM.HOLDING.PREVIEW. The file is made up of a general T24 message
key of D/R for delivery or received and 8 -digit date and 7- digit time (from midnight). There is only one field that contains the whole message.

Confirmation Matching - User Guide - Release R15.000 - Page 25 of 25