Welcome to Payments Temenos Payments Hub, Lesson 3, STP Process

Flow» Part 1.
In this lesson I am going to describe
STP process Flow
Message Acceptance
Message Mapping
Code words
For a payment to be processed, number of internal activities need to happen
on the payment. The activities are listed and each of them are impact payment
processing in a specific way. This is explained in detail as we proceed.
As a payments hub, TPH can receive single as well as bulk messages.
Messages once receives are stored in the database so that no message is
lost. Once the message is accepted and successfully validated, TPH performs
what is called ‘mapping’ which maps the data received on to various internal
TPH tables which ease payments processing.
Being a payments hub, there would be a number of different message formats
that need to be consumed. In order to cater to this, TPH exposes a XML
schema to accept credit transfer as well as direct debit messages.
Hence, once the messages are mapped to this XML schema and sent, TPH,
on successful validation will store the message as well as map them. The
XML schema can accept both single as well as bulk messages.
What can TPH do with messages that it receives?
Receive message from any Channel - Channel agnostic
As the name implies, Message Acceptance denotes accepting messages from
any channel.
Can receive single or bulk messages
Messages can be single messages or bulk messages.
Interpret/Validate messages
Messages such as SWIFT need to be interpreted to obtain message formats
whereas messages such as Batch messages need to validated for content.
Hence, both interpretation and validation of messages are performed when a
message is accepted
Accept or reject messages
Once a message is received, basic message validation such as to check if it is
supported message type, supported channel etc need to be performed. Based
on validations set at the channel level/message level, message is either
accepted for further processing or rejected.
Mark messages to be repaired and resubmitted
If messages result in an error, facility to resubmit the message is available.
Forward messages
There could be messages that are received by TPH which aren’t meant for
processing within TPH, such messages can be identified and forwarded to a
per-determined queue. (This is only provided for messages in 1 and 2 series). Banks
are expected to route the correct messages to TPH.
Check for technical duplicates
In order to avoid messages getting processed more than once, duplicate processing
is enabled at TPH level for bulk messages.
Send ACK/NACK responses
Once a message is received, ACK (Acknowledgement) or NACK (Negative
acknowledgement) can be sent to a pre-configured queue
Transform messages to neutral format (Mapping)
Messages received in any format can be transformed (mapped) into a Payment
Engine generic internal format so that TPH can perform further processing. The
message is parsed into individual fields.
Create Payment Order
Based on the parsed message, a payment order is created and stored in the
database.
Messages can be accepted 24/7
Messages can be accepted from any channel at any time – even while SODEOD
process is in progress in Core Banking
Messages can be mapped only when TPH is online
Messages can be mapped only when the system is online (Not while SODEOD is in
progress)
How to view the status of a message once it has been posted to TPH
Using menu option “Payment Hub -> Received Files” Message status and
received message details can be viewed.

Are there different statuses for a message?

Messages are posted on to Queues and these messages are picked up by
TPH for processing. At the message acceptance level, use the following set of
menus to view the status of messages/Resubmit messages. Services need to
be running in the background for the messages to be picked up and
processed by TPH.

Status of message at this juncture can be any one of the following

RECEIVED
Message has been received by TPH. No validation or any sort of processing
has commenced on the message.
ACCEPTED
Message is in the supported format, is from a valid channel and has been
accepted for further processing
MAPPED
An accepted message of TPH has been mapped to a neutral format and a
payment order has been created. Financial processing can commence on the
message.
REJECTED
Message is not a supported format/incorrect message. If a message is rejected by
TPH, then, the only way would be to make the corrective action (If any) and re-send
the message to TPH.
REPAIR
Message is a supported format but is an erroneous message. A message in REPAIR
can be resubmitted post corrective action. Message need not be re-pumped in.
FORWARDED
Message has been forwarded to another queue.
Define the message formats to be used
For TPH to be able to pick up and process messages, it needs to know the
valid message formats that it can process else it would have to reject them.
All recognized message formats need to be defined.
The key is the Message Format and inside it contains a descriptive text of the
message format.
Any message which has a format other than the ones listed as part of this
table will be rejected by TPH
Any incoming message will have the message format as part of the message.

Define which message formats can come via which channel

While there can be numerous message formats and number of channels,
certain message formats can be dealt only be certain channels. Hence,
message formats need to be linked to channels for ease of processing.
Combination of Channel name, Message Format and Direction of the
message identify each record uniquely.
Message Direction indicates the direction of the message
R – Receive (Incoming)
S – Send (Outgoing)

Define the rules for accepting a message

Message Acceptance Param(eter), as the name suggests, defines the various
rules while processing messages from a specific queue and hence the key is the
queue name.
Various types of messages would come into TPH. For instance,
• It can be message to process salaries for all employees is received. Such a
message would be a bulk message as there would be multiple credits and one
debit.
• It can be a single SWIFT message (For instance 101)
• It can be a single credit message from Payment Router channel
• It can be a BACS local clearing file
How will TPH know
Whether it is a single or a bulk message?
Which channel these types of messages can originate from?
Whether an acknowledgement needs to be sent once the message has been
accepted or a negative acknowledgement needs to be sent of the message is
incorrect (ACK/NACK)?
If ACK/NACK needs to be sent, where should such return messages be placed?
Should any API be triggered to validate/interpret the message?
Should technical duplicates be checked for?
All such details are defined in here.
Key to the records here is always a channel from which the message comes in.
Message Mapping Component interprets the external payment messages
from native format(i.e. SWIFT) to Neutral Payment Object in order to map the
messages into TPH specific format and to create payment order transaction.
 Define the message types to be used
All valid message types need to be defined in PP.MSGPAYMENTTYPE
Define which message type can come via which channel
While there can be numerous message types and number of channels,
certain message types can be dealt only be certain channels. Hence,
message types need to be linked to channels for ease of processing.
This is defined in PP.MSGPAYMENTTYCHANNEL

Define the rules for accepting a message

Once a message has been accepted by TPH for processed, it needs to
transform the message into a neutral format so that further payment
processing can happen. Mapping phase is the one that defines how the
transformation needs to happen. No financial calculations/processing
happens at this stage.
Each message received from a channel is for a specific purpose and
hence will have specific content/format. Hence, the mapping of the
message content would be different for different message formats.
Hence, the key is a combination of message format and channel.
Mapping API
Name of the API to be invoked to map messages
SourceType API
API which can be used perform changes to the message based on payment
values. Optional.
For instance, the API shown above will distinguish if the incoming message is
a CHAPS or FPS based on the sender’s BIC.
A global payment engine receives a number of payments throughout
the day and has to process all of them as quickly and efficiently as
possible. Hence, once a message is accepted, before any financial
processing can commence on the message, it is vital to check if there
are characteristics in the Payment Message that will influence payment
processing.

This weight refers to an overall classification of the payment on a very

broad level.
Weight can be defined as a categorisation of a payment instruction with
a purpose to influence flavour of processing.
The more complex the payment attributes are and more combinations
they can have, the higher the weight they need to posses..

SWIFT - Heavy weight

Outgoing messages in SEPA clearing/USACH clearing – Medium
weight
Other local clearing payment messages – Light weight
Can there be specific weights based on attributes of a message?
Yes, this is possible.
Most payments can be grouped under one of the 3 high level weights. But
there could be expectation for special treatment for smaller sets of payments
which is not covered directly by the high level weights.
Specific weight can be understood as the categorisation through which
customised treatment of those payments can be provided. However, all
specific weights have to relate to a high level weight. Specific weight is
specialisation of high level weight.

In order to understand how weights are assigned to messages, let’s use the
table shown above.

Rank dictates the which record will be used if multiple records are chosen
(Rank 1 will have the highest priority)
The ‘*’ in the above table means that the value in that place can be wild-
carded. This can be used when a bank may want to assign a particular weight
to all the messages from a particular Originating Source or all the sources for
a particular Message Type.

Once a weight is assigned, can it be changed in downstream

processing?
No. This is not possible.
Can a message not have a weight defined?
No. Every message needs to have a weight defined. Else, system will throw an error
and processing will stop.
Flexibility to make a decision whether a specific processing within the
payment engine needs to be invoked for a payment leading to reduction in
processing time
Some processing may not be applicable to certain payments. This distinction
can be done based on weight. Table to be used to configure this is
PP.PROGRAMS.PER.WEIGHT.
A specific weight code “CLM” is created for CLAIM functionality which is an
internal process for creation of MT191 message by creating new transaction
as part of payment transaction demands to send charge claim. This type of
transaction need not to process all payment programs hence irrelevant
programs are skipped using this functionality
For a payment to be processed, number of internal activities need to happen
on the payment. The activities are listed and each of them are impact payment
processing in a specific way. This is explained in detail as we proceed.
Codewords are added as part of the payment message to convey payment
processing information for financial institutions. ‘SWIFT codewords’ are codes
wherein SWIFT has defined and detailed the meaning of each codeword along
with the method to read and interpret these codes. This is to ensure that various
financial institutions process these codes in a consistent manner.
Banks / financial institutions can also make special agreements and come up with
codewords to trigger bilateral agreements amongst themselves, the presence of
these codewords can trigger special payment processing as agreed between the
banks. These are termed as ‘Bilaterally agreed codewords’.
Note!
The use of Codewords to identify specific processing requirements is not limited
to SWIFT messages. Any other message sources may also supply codewords as
part of the payment request.
Codewords received in the payment object (inbound codewords) are searched
against the Inbound Codeword table to see if any processing logic is defined for
that particular codeword and thereby evaluates, whether the codeword influences
/ affects the manner in which the payment is to be processed within the payment
engine.
Inbound codewords are codewords which are received in the payment instruction
as part of the SWIFT fields. Below are the tags where codewords may be present
in a SWIFT message.
13C, 23E, 72, 77B and 56/57/58 for //RT
These are read by the Mapper and stored in a payment object. These codewords
are then input for Inbound Codeword processing module.The input / inbound codewords
are searched in the Inbound Codeword table to see if a match for that particular
codeword is available.
If a match is not found, then for Inbound Codeword Processing , TPH ignores the
codeword in the payment object and does not act on it. i.e. the codeword will not be
considered for payment processing.
Swift Tag Information Code Code word Description
Tag 13C TIMIND
CLSTIME The time by which the funding payment must be credited, with confirmation,
to the CLS Bank’s account at the central bank, expressed in Central European Time
(CET).
RNCTIME The time at which a TARGET payment has been credited at the receiving
central bank, expressed in Central European Time (CET).
SNDTIME The time at which a TARGET payment has been debited at the sending
central bank, expressed in Central European Time (CET).
Tag 23E INSBNK
SDVA Payment must be executed with same day value to the beneficiary.
INTC The payment is an intra-company payment, ie, a payment between two
companies belonging to the same group.
REPA Payment has a related e-Payments reference.
CORT Payment is made in settlement of a trade, eg, foreign exchange deal,
securities transaction.
HOLD Beneficiary customer/claimant will call; pay upon identification.
CHQB Pay beneficiary customer only by cheque. The optional account number line in
field 59 must not be used.
PHOB Please advise/contact beneficiary/claimant by phone.
TELB Please advise/contact beneficiary/claimant by the most efficient means of
telecommunication. PHON Please advise account with institution by phone.
TELE Please advise account with institution by the most efficient means of
telecommunication.
PHOI Please advise the intermediary institution by phone.
TELI Please advise the intermediary institution by the most efficient means of
telecommunication CMSW This transaction contains a cash management instruction,
requesting to sweep the account of the ordering customer.
CMTO This transaction contains a cash management instruction, requesting to top
the account of the ordering customer above a certain floor amount. The floor amount,
if not pre-agreed by the parties involved, may be specified after the code.
CMZB This transaction contains a cash management instruction, requesting to zero
balance the account of the ordering customer.
EQUI This transaction contains an instruction requesting to pay the beneficiary
customer an amount in one currency, equivalent to an instructed amount in a different
currency.
 NETS This transaction contains a payment that should be settled via a net settlement
system, if available.
OTHR Used for bilaterally agreed codes/information.
The actual bilateral code/information needs to be specified in Additional Information.
RTGS This transaction contains a payment that should be settled via a real time
gross settlement system, if available.
URGP This transaction contains a time sensitive payment which should be executed
in an expeditious manner.
Tag 72 INSSDR ACC Instructions following are for the account with institution. INS
The instructing institution which instructed the Sender to execute the transaction. INT
Instructions following are for the intermediary institution. REC Instructions following
are for the Receiver of the message. BNF Information following is for the beneficiary.
PHON Please advise account with institution by phone. PHONBEN Please
advise/contact beneficiary/claimant by phone.
PHONIBK Please advise intermediary by phone. TELE Please advise the account
with institution by the most efficient means of telecommunication. TELEBEN Please
advise the beneficiary/claimant by the most efficient means of telecommunication.
TELEIBK Please advise the intermediary by the most efficient means of
telecommunication. TSU Trade Services Utility transaction Bilaterally agreed Code
words
Tag 77B REGREP
BENEFRES Residence of beneficiary customer
ORDERRES Residence of ordering customer
Codeword is determined by processing the input parameters.
Following are the key fields,
Input Parameters
> CodeWord – User has to enter the actual code being configured.
> Information Code – Tag to which the codeword is associated. Please refer to
‘SWIFT Standard Codewords’ section above for details.
> Message Payment Type – Message types in which the codeword is
expected. User can select one of the available message types in the
dropdown. If user wants to apply this codeword to any message type, then ‘*’
has to be selected.
> Originating Source – Sources from which the message can be received.
This is a dropdown selection from which User can select the specific source or
‘*’ for any source.
Output Parameters –This is a multi value set. User can associate more than
one codeword and its properties and assign a rank to each of those. Based on
input parameters, system selects the most appropriate codeword derived as
per output parameters.
> Codeword Ranking – User to assign a ranking in numeral for the given
codeword. Lowest number gets highest priority.
> Codeword Text – User to enter the possible text that can be associated with
the inbound codeword.
> Codeword Priority for PD – Codeword priority for product determination. Highest
number gets highest priority and is used for determining the product. In multiple
codeword scenario, codeword with highest priority defined in this field will be chosen
as final output codeword.
> Adjusted Message Priority – User can capture the new message priority to be
applied for the inbound message, if the given codeword is present.
> Processing Sequence Number – User to enter a valid processing sequence number
against which the processing routine is attached and this is applicable for processing
the given codeword.
> Non-STP Indicator – if this flag is set to ‘Y’, then the payment received with the
given codeword is processed manually and not STP. This must be set to ‘Y’ only with
codewords that indicate Non-STP request from the sending bank else it is ‘N’.
> Fee Codeword Flag – This flag must be set to ‘Y’, only if the codeword indicates an
instruction for fee processing and should be set to ‘N’ in other cases.
> Outbound Codeword Applicable – This flag should be set to ‘Y’ in cases where the
codeword can have a impact on the outbound message in a redirected payment. In all
other cases, it should be set to ‘N’.
Processing Sequence is a set of pre-defined steps (methods) that influences
the payment processing by setting various flags and indicators that are
subsequently read and taken into consideration for payment processing by the
impacted modules within the payment engine.
If there are multiple code words, Processing Sequences (If any) for all of them
are executed and only then is the final code word arrived at.
Detail
Codewords can stimulate special processing rules for each payment, these
are then defined as Processing Sequence. Processing Sequence detail out
the set of pre-defined processing steps that result in certain flags and indictors
being set in the payment object. These flags/ indicators are subsequently read
by the impacted payment engine module which in turn influences the
processing of the payment within the payment engine.
Processing Sequence related details are stored in a separate database table.
Processing sequence will always be referred to with a number.
* Processing Sequence Routine Name – User has to attach the program
(routine) name in this field.
* Inbound Processing Sequence Flag – Selecting ‘Y’ means that this
processing sequence is applicable for an inbound codeword else it’s not
applicable.
* Outbound Processing Sequence Flag – Selecting ‘Y’ means that this
processing sequence is applicable for an outbound codeword else it’s not applicable.
Some of the program routines for codeword processing that TPH supports are,
Inbound processing sequence 1 : Requested Execution Date will be assigned
to Requested Credit Value Date and Requested Execution Date will be made
blank.
Outbound Processing Sequence 2 : If Account With Institution is derived by
the system and not provided in the incoming request message nor input by
user in Order Entry, then system will set the instruction code to ACC else will
set to REC in the outbound message.
Outbound Processing Sequence 1 : If Intermediary Institution is derived by the
system and not provided in the incoming request message nor input by user in
Order Entry, then system will set the instruction code to INT else will set to
REC in the outbound message.
Inbound Processing Sequence 6 : Requested Execution Date will be assigned
to Requested Credit Value Date and Requested Execution Date will be made
blank.
Above sequence can be attached to any codeword.
Banks maintain certain agreements on payment processing with each other.
This is called ”Service Level Agreement” or SLA. To give effect to SLA in a
payment, sending bank mentions agreed code word in the payment so that the
receiving bank processes the payment based on the code word and the
corresponding SLA. If there are more than one code word, then SLA is
determined by the final output codeword.
In TPH, bank can maintain SLA ID for one code word or group of code words.
TPH determines the corresponding SLA ID considering the message priority,
codeword text, codeword tag and the rank in addition to the codeword (final
output codeword) itself.
TPH uses this SLA ID as one of the input criteria to identify the ‘Bank
Conditions’ record to process the payment based on conditions defined
therein.
In TPH, User can configure the SLA ID and the associated codeword in the
screen ‘SLA Per CodeWord’, which can be accessed through the menu Admin
Menu > Payment Hub > SLA Per Codeword.

> Message Priority – User can select the Message priority for which this SLA
ID is applicable. User can select ‘*’ to apply this SLA ID to any message type.
> CodeWord – User can configure the specific Codeword or ‘*’ (any codeword)
for which the SLA ID is applicable.
> CodeWord Tag – User enters the specific Information Code (Please refer to ‘SWIFT
Standard Codewords’ section above for details) or ‘*’ (any) for which this SLA ID is
applicable.
> CodeWord Text – User can configure the Codeword text or * for which the SLA ID is
applicable.
> Ranking – User can configure the rank of this SLA ID, based on which the SLA ID is
applied. Lowest number gets highest priority.
> SLA ID – User can configure the SLA ID, which, in turn, is linked to ‘Bank
Conditions’ screen and ‘Routing Contract’ screen.
In this lesson I described
STP process Flow
Message Acceptance
Message Mapping
Codewords
Core Banking Bank – Account with Institution / Beneficiary Customer
TPH – Payment Processing company / Branch
Flow of MT 103 message.
* Path for specific folder is C:\Temenos\R19\Env\Slot01\Data\

TPH internal process steps to send the message into TPH for payment
processing.
Note: If user want to use the same message multiple times, change the value
in Tag 20: Ref and Transfer amount to avoid duplication error
Default Password for TAFJEE : User id – t24user Password – t24User123!
Copy the message from the
folder(Temenos\RXX\Env\Slot01\Products\TPS\Messages\SWIFT\Converted )
and paste the message in TAFJ Shell
View the Message Status in DE.I.HEADER
After running the services the status will change to OFS formatted
Using menu option “Payment Hub -> Received Files” Message status and
received message details can be viewed
Using menu option “Payment Hub ->Inquiry and Queue Management ->
Pending and Processed Payments”, payment transaction’s current status can
be checked. And also using the View button on the screen of respective
transaction will show the payment transaction details on a separate screen

The screen details the payments characteristics and also other information are
in the respective tabbed screen (Debit Credit Info, Error Information, Charge
Information, Routing Information (Applicable for Outgoing and Redirect cases)
Additional Info (i.e. Remittance information).
Using menu option “Payment Hub ->Inquiry and Queue Management ->
Pending and Processed Payments” and View in detailed button, user can find
the complete details of payment transaction using the respective options
(Debit Credit Info, Audit Trail, Messages related etc) on the screen.
Audit Trail option on the payment details screen provides transaction
processed events details in order along with system enriched and derived
values on the Additional Information column. The events are captured from
the message received till payments completion.
POR.TRANSACTION captures payment transaction details processed by TPH
along with current status of the payment.
Thanks for listening. Enjoy the course.