1

2
Preferable prerequisites for this course

3
Available training courses in Temenos E-learning related to Payments

4
5
End of Day 1 – Learning objectives will be met.

6
TPS is Payment Hub built on Global payment process which enables Banks / Financial
Institutions move to a sophisticated centralized infrastructure that operates Any
format, any channel to any destination.

7
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 TPS
specific format and to create payment order transaction.

8
TPS Payment Processing Flow Diagram

9
TPS componentized solution caters to accommodate emerging changes in the
market. (i.e. Highly Parametrical Solution). All components put together process a
payment transaction as per configuration done.

10
Pending and Processed Enquiry provides details of the processed payments and
current status of the payment.

11
It is used for Manual payments input by Bank operator i.e. Client initiated payment
through Non-STP channels like FAX or to capture the payment transaction of STP
failures etc.

12
Payment transactions resulted into repair due to incorrect data or payments
validation failure can be repaired using this screen

13
Audit Trail option provides the details of transaction processed by respective
components and its’ outcome.

14
15
Capture table
All configuration or static data that is used in TPS is captured using a form or a
capture table
A capture table is nothing but a T24 application which enables a user to key in
information.
Once data is committed, data is stored in a table called the store table.
All capture table names will begin with ‘PP.’ followed by the table name
Store table
A store table is also a T24 application but of type ‘L’ meaning that it would only be
updated by the system.
A store table is a ‘L’ type application (As defined in PGM.FILE/FILE.CONTROL)
All store table names will begin with ‘PPT.’ followed by the table name
There are also store tables that begining with ‘PPL.’ followed by table name. This will
be covered when we touch on the peeling off mechanism in TPS.
Relationship between capture and store tables
Data keyed in using a capture table can be stored either in a single store table or data
can be split based on business functionality and stored in multiple store tables.
Life cycle management of a record
Since data has to be captured in a capture table and then stored in a store table, the
life cycle of a record in TPS is taken care by TPS. This is in addition to the life cycle
mechanism provided by T24. This will be covered more in detail as we proceed.

16
TPS tables are categorised as Capture and Store table for Static data. Payment
Transaction related data capture table known as “POR” Tables which are updated by
TPS during the processing considering the Static Data maintenance and Received
Message data or User Input.
• PP Table (Capture / Input)
• PPT Table (Stored / Maintenance)
• PPL Table (Stored / Maintenance and Peeling off Mechanism)
• POR Table (Transaction details captured by the system)
POR tables (payment order tables)
POR.TRANSACTION
POR.ACCOUNTINFO
POR.ADDITIONALINF
POR.ADVICE
POR.APPLIEDFEE
POR.CLIENTCONDITIONS
POR.DEBITBANKCONDITIONS
POR.CREDITBANKCONDITIONS
POR.XXXCONFIRMATIONS (SMS/POST etc)
POR.INFORMATION
POR.PARTYCREDIT
POR.PARTYDEBIT
POR.POSTINGLINE

17
POR.STATEMENTLINE
POR.HISTORYLOG

17
Process incoming MT103

18
T24 Bank – Account with Institution / Beneficiary Customer
TPS – Payment Processing company / Branch

19
Flow of MT 103 message.

20
Incoming message received from SWIFT channel

21
Using menu option “Payment Hub -> Received Files” Message status and received
message details can be viewed.

22
POR.TRANSACTION captures payment transaction details processed by TPS along
with current status of the payment.

23
24
Quick Reference Guide for party roles. TRMINS
Contains party role name, description and tag Third Reimbursement Institution
from which value will be retrieved for the party 55A, B or D
INSPTY SENDER
Instructing Party Sender
50 C or L IMPDBT
ORDPTY Implied Debit Account
Ordering Party INTINS
50 A, F, G, H or K Intermediary Institution
SNDINS 56 A, C or D
Sending Institution ACWINS
51A Account with Institution
ASVINS 57 A, B, C or D
Account Servicing Institution BENINS
52A or C Beneficiary Institution
ORDINS 58 A or D
Ordering Institution BENFCY
52A or D Beneficiary
SNDCBK 59A or no letter option
Sender’s Correspondent Bank IMPCDT
53A, B or D Implied Credit Account
RCVCBK RECVER
Receiver Institution of the MT103
message

25
Receiver’s Correspondent Bank
54A, B or D

25
• There are a set of basic tables that need to be configured for payments to be
processed in TPS.
• These tables are termed as static tables and are usually the first set of tables to be
defined during an implementation.

26
Company is a legal entity / Enterprise (i.e. Financial Institution / Bank / Branch)

Companies which can send and receive messages in TPS need to be defined. These
should be valid companies defined in T24 in table COMPANY.

Company ID - Mnemonic of the company as defined in COMPANY

Company Description – Holds the description of the company
Company Code - Company code as defined in COMPANY
Status SODCOB - Company is online and SODEOD is not running
Current Business Day - Today’s date
Offset time – UTC offset time calculated based on the time zone defined in
PPT.COMPANYPROPERTIES (Covered in the next section)

27
Each company which is defined in order to participate in processing messages via TPS
will possess number of attributes. These are defined per company. Only a company
defined in PPT.COMPANY can have its properties set here.
Each company needs to have a BIC, a currency, a region to which it belongs to etc.
Such properties are defined per company.

Company ID - The company ID of the company. Should be defined in PPT.COMPANY

Home Country Code - The country code of the company.
Home Currency Code - The local currency of the company
Company BIC – BIC of the company.
Time Zone – Time zone in which the company is located. If this is not specified, server
time zone will be utilised for offset calculation. Calculated offset will be updated in
PPT.COMPANY table.

28
• This holds the list of all currencies that can be transacted per company.
• One company could transact in multiple currencies.

Company ID - Mnemonic of the company as defined in COMPANY

Currency Code – Unique code of Currency name in ISO format
Country of the Currency – Unique code of Country name in ISO format
Fractional digit – Number of decimals applicable for the currency
FX Limit - Specifies the limit in the foreign currency up to which a payment can be
processed STP
Weekend Day1 – Weekly non working day in the country of currency
Weekend Day2 – Weekly 2nd non working day in the country of currency (if
applicable)

29
• Source is the place from where the message originated. Channel is the path
through which the message reached TPS or the one which gives the message to
TPS.
• All payment order in TPS must have an originating source.
• Source maintenance identifies the channel through which payment message will
be received for processing in TPS.
• Source of the payment is one of the important field that influences selection of
payment product which in turn influences fees, client agreements etc.

30
• Channel is the path through which the message reached TPS or the one which
gives the message to TPS.
• A message can come through a channel from various different sources
• To sum it up, a channel can be used by multiple sources.
• SWIFT Channel is used by Sources like CHATS, TARGET, CHAPS etc.,

31
• Every country needs to belong to a region.
• This is for grouping countries in a region

32
• This table stores all the status codes that a payment might pass through during
payment processing life cycle.
• Status code details the current stage of the payment transaction. Status codes are
assigned from the beginning of the transaction till payment completion stage and
also records to status passed through the stages of transaction.
• Payment will pass through multiple status codes during its lifecycle and each status
code indicates payment’s position and current status in the flow. Logical end of
every stage is updated with status codes (Customer validation, Balance
verification, Product determination, Filtering completion, message generation and
payment completion etc.)
• Status code ‘999’ signifies that payment is completed.
• It acts as an input or selection criteria for payment workflow to process by
subsequent and appropriate payment components for payments completion.
• The status codes of a payment transaction are fixed and cannot be changed. The
business logic behind the GUI will validate an entered status code against the
available values. The table Status Code does not have Start Date and End Date for a
record.

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

34
What can TPS 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 TPS which aren’t meant for processing
within TPS, 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 TPS.

35
 Check for technical duplicates
In order to avoid messages getting processed more than once, duplicate processing is
enabled at TPS 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 TPS 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 T24
Messages can be mapped only when TPS is online
Messages can be mapped only when the system is online (Not while SODEOD is in
progress)

35
How to view the status of a message once it has been posted to TPS
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 MQ Queues and these messages are picked up by TPS 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 TPS.

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

RECEIVED
Message has been received by TPS. 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 TPS 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

36
TPS, then, the only way would be to make the corrective action (If any) and re-send
the message to TPS.
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.

36
Define the message formats to be used
For TPS 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 TPS
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

37
while processing messages from a specific queue and hence the key is the queue
name.
Various types of messages would come into TPS. 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 TPS 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.

37
 Define the message types to be used
All valid message types need to be defined in PPT.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
PPT.MSGPAYMENTTYCHANNEL

Define the rules for accepting a message

Once a message has been accepted by TPS 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.

38
For instance, the API shown above will distinguish if the incoming message is a CHAPS
or FPS based on the sender’s BIC.

38
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

39
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?

40
No. Every message needs to have a weight defined. Else, system will throw an error
and processing will stop.

40
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
PPL.PROGRAMSPERWEIGHT.

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.

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

42
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 , TPS ignores the
codeword in the payment object and does not act on it. i.e. the codeword will not be
considered for payment processing

Model Bank > PAYMENTS > TPS > Parameters >Inbound Codewords> Inbound
Codeword
Configure the output results based on the received inbound codewords here. The
output results impact the overall payment processing. If a payment has more than
one inbound code word, for each code word this table is looked up iteratively. At last,
only one inbound code word is selected for product determination based on
CodeWordPriorityForPD.
Once a record is selected, applicable output results are considered for payment
processing. For example in the above screenshot, the codeword will impact the
message priority as specified under ‘Adjusted Message Priority’. The code word does
not influence Non STP indicator and conditional fees. The code word is also not
considered for Outbound codeword processing. Here there is no mentioning about
‘Processing sequence number’ which ranges from number 1 to 5.

42
Model Bank > PAYMENTS > TPS > Parameters >Inbound Codewords> Processing
Sequence
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.

43
44
Service Level Agreement (SLA) is an agreement that a bank provides to its
correspondent banks defining the various levels of service in payments processing
that it would offer. The SLA will influence the process of payment in payment engine
such as applying special bank conditions and Routing and settling the payment in a
different manner.

When correspondent bank wishes to use an agreement for a particular message, then
in the payment message, special code words agreed for this purpose should be
mentioned. The SLA determination component will determine the SLA for the
payment based on the SLA configuration with respect to the code words specified in
the message.

The output of the SLA determination can be used as a key for further payment
processing (like Bank conditions and Routing and settlement)

Overview
The Service level agreement with the counterparty banks applies a special behaviour
of a message in the payment engine. The agreement can be a general agreement
with the bank or specific level agreements which are linked to specific bi-laterally
agreed code words. The code words can be a standard swift code words or bilaterally
agreed code words
SLA generation

45
The prime responsibility of SLA determination is to generate a SLA ID for a payment
order that results in triggering different processing conditions for a payment. SLA
Determination will be done only once for a payment in its life cycle. The determined
SLA will be used mainly to determine:
The debit and credit bank conditions.
Bank charges for the payment.

Influence of other factors on SLA

Code words
The sending bank, wishing to use a specific level agreement for a particular message,
will specify the agreed code words in the payment message. SLA Determination
component will determine the SLA reference for the payment from the code word
provided in the message. When there is no code word in the message, the generic
SLA agreed with the counterparty bank if exist will be used or the default SLA will be
used for the payment. SLA configurations are specific to a company.
Note!
The SLA determination is always based on the original code words supplied with the
payment order message along with the message priority for a company. It is never
based on the result of the code word determination.

A correspondent bank may supply multiple code words in a message, but only a
single SLA can be applied to a single payment. The SLA configuration will allow to
define priority of possible SLA’s to be specified in such cases. Single or a collection of
code words will lead to one SLA based on the priority of SLAs.

Weight
SLA determination may not be required for all type of messages. This can be
controlled in this component by the weight assigned for the payment by the Assign
Weight component. In this case SLA for the payment will not be populated.
For most payments the decision to continue SLA determination or not can be decided
based on the Overall weight of the payment. However, in certain cases overall weight
might not be the right call to make the decision. So the combinations of Overall
weight and Specific Weight will be used to continue the SLA determination process

Model Bank > PAYMENTS > TPS > Parameters > SLA per CodeWord > SLA per
CodeWord List

45
Purpose
The Debit Authority component is responsible for verifying whether authority can be
granted to payments for which the debit party is in the books of the processing bank.
This is to prevent fraudulent behaviour from third parties as they have to specify the
correct debit party/account in the payment message. By interpreting various payment
characteristics the DA component is able to determine whether authority can be
granted to the transaction.
Overview
Debit Authority is required for a Credit Transfer for which the debit party resides in
the books of the processing bank requires a valid netting agreement. A netting
agreement is a 3-party agreement between the sending bank, the processing bank
and the customer. It states whether another bank is allowed to request a payment
transfer, or send a payment instruction, specifying the debit account of the customer
that is serviced by the processing bank. It is the responsibility of Debit Authority to
validate whether the party requesting a payment transfer, or sending a payment
instruction, has the authority to mention a specific third party as the debit party for
the payment.

Direct debits will use DD.MANDATE to record and use mandates.

46
Netting Agreement

Store the netting agreements which usually state which sender of the payment
instruction has the authority to mention a third party as the debit party for the
payment here. Whenever a message type of a company is not specified under NoDA
list, a lookup is performed on this table for the type of message received from the
specific sending bank. The agreement also holds the exact debit account in the
processing bank for which a debit instruction can be carried out by the sending bank.

NoDA List

Define the list of message types of a company which do not require any authority to
be processed here. If a record is present in this table, the payment will be authorized
straight forward. If not, the transaction is not authorized directly. Rather the
transaction is subjected to further processing such as a look up for valid agreements
between the sending bank and the processing bank to authorize such payments.

47
48
As the name implies, the next step is to determine the party to be debited.
For instance, when processing a 103, it is imperative to note that the ordering party
has already been debited in the books of the ordering party’s bank. When the 103
reaches us, we need to know whom we need to debit in our books.
A 103 can be sent to us directly from the sender or it can be sent via various parties
as listed below.

While determining the debit party, system will always check if the nearest party to
the receiver is the actual party to be debited. Hence, will check

If a Third party reimbursement institution is present in the message in tag 55A, then,
he is the party to be debited. Search for debit party ends here.
If Receiver’s correspondent is present in the message in tag 54A, then, he is the party
to be debited. Search for debit party ends here.
If Sender’s correspondent is present in the message in tag 53A, then, he is the party
to be debited. Search for debit party ends here.
If the account of the sender is present in the message in tag 53B, then, that is the
account to be debited. Search for debit party ends here.
If none of the above is present, then, sender of the payment (Which will be available
in the header) is the party to be debited.
Whenever a BIC is determined as the debit party (In cases 1,2, 3 and 5), it is assumed
that the determined debit party has either a LORO or a NOSTRO relationship with us.

49
Hence, we extract the appropriate account for the BIC and mark that as that as the
debit account.
In our case, as part of the message, we neither have 55A, nor 54A, nor 53A nor 53B.
Hence, system would extract the sender from the message header and obtain the
LORO/NOSTRO account of the sender
To determine the debit party, no specific configuration is required expect the
definition of the appropriate LORO or NOSTRO accounts (using table
PPL.LORONOSTROACCOUNT)

It is also possible for payments to come in with a forced debit party/account. This is
done during the mapping phase of the payment. In such a case, validation of the
debit account is what is required rather than determining the debit account.

Validating a debit account :

Account exists in PPL.LORONOSTROACCOUNT
Account exists in the DDA
Account is active and not closed
Account does not have any debit posting restrictions

49
Store the accounts of the correspondent banks with which the bank shares a LORO
and NOSTRO relationship here. This table is linked with the BIC table. As the BIC table
is company specific, this table is also company specific. This table is also used in the
credit account determination step.

50
51
52
53
How does Dates impact Payment Warehousing?
Payment Warehousing is performed when the payment has a future Requested Due
Date or Requested Credit Value Date.
The difference between these two dates can be explained with the help of an
example as below.

Requested Due Date

On 7th July, start of MediaMarkt wants to schedule the payment of its invoice
received from Dell computers on 7th July 2012. On 1st July, a payment instruction is
created which is scheduled to be executed on 7th of the Month (Thus 7th July = Due
Date). The payment engine will send this payment to the warehouse.
day, payment is released from warehouse for further payment processing.

Requested Credit Value Date

Albert Hein (AH) has ordered a shipment of 30,000 boxes of Kiwi fruit from a supplier
in New Zealand. The shipment will happen only when the payment is made available
in the supplier’s account on 7th July (Thus 7th July = Credit Value Date).
On 1st July, a payment instruction is created. The bank has to ensure that payment
reaches suppliers account on 7th July. Therefore, payment engine processes the
payment until routing and settlement is chosen for this payment (as opposed to
warehousing it initially)
When does Payment Warehousing executed for a Payment?

54
Payment Warehousing is usually called for payment which consists future due date.
As explained earlier, Payments with a Future Requested Due Date will be
warehoused immediately on understanding that customer has requested a future
execution date. i.e. Customer requests for payments with future due date are always
warehoused.
And, Payments with a Future Requested Credit Value Date will be processed to an
extent, so that R&S is able to figure the route, which is then taken into consideration
while defining the Due Date / Credit Value Date.
In both the cases, such Payments are parked with Payment Warehouse.
Also, these payments will undergo complete STP re-processing as and when they are
released from the warehouse.
Why does a Payment released from Payment Warehouse needs to
undergo STP re-processing?
The reason being that, during the time the payment was in warehouse, certain
payment processing information could have undergone change for e.g. the static data
(BIC table), client condition, R&S agreements etc.
Thus, it is important to process these payments again.

When does Output Warehousing executed for a Payment?

Payments which are already processed by the payment engine and the corresponding
posting entries are booked with future send date are mainly warehoused as the
particular output channel does not accept future dated payments.
For Example,
V&D is a customer for SNS Bank in Netherlands. V&D initiates a cross border payment
to Germany. However, SNS Bank does not have cross border payment system. They
forward all their payments to ABN AMRO Bank (AAB) for processing.
The agreement with SNS bank is that, all payments will be processed and booked as
and when received by AAB (no warehousing)
AAB receives the payment request on 2nd July from SNS bank with a requested CVD
of 10th July. AAB process the payment until routing and settlement.
R&S figures out that payment is to be sent via EBA. However, EBA does not accept
payments with CVD later than today. In such scenario, payment message cannot be
sent today to EBA to avoid rejection.
Hence, payment is processed and booked today (2nd July = Book Date) but the
payment message will only be sent on the requested CVD.
These payments are directly released to the Output Warehousing component.
How Debit Bank Conditions are associated with Warehouse?
The decision to warehouse payments varies from bank to bank.
A bank may choose to use the warehouse functionality for all payments or only for
certain payment types.

54
Bank Condition decides whether to warehouse payments or not
If Bank condition says NO Warehousing, then payment will never fall in warehouse
Release of Payment from Warehouse
On the exact Release Date (i.e. Processing date / Send date), payments are released
back to the respective payment engine flows / components.
Release of Payment to STP Flow
When the Processing Date <= Current Business Date of the processing company, At
SOD the payment is released from warehouse back to the STP flow.
Release of Payment to Payment Flow / Output Generation
When the Send Date = Current Business Date of the processing company, At SOD the
payment is released from warehouse back to Payment flow.

54
When a payment gets processed by the payment engine, after the debit party is
identified, the payment date would be checked to see if it is future dated or not.
If it is future dated and the sender bank has opted to warehouse a future dated
payment, system will mark the payment as ‘To be warehoused’.
Payment Warehousing - Releasing payments from warehouse on the due date for
further payment processing.
Sending warehoused payments to the Filtering Module to perform daily checks
Output Warehousing - Releasing payment to the Clearing systems in order to honour
the Credit Value Date (CVD)
Cancellation / Amendment of warehoused

55
Purpose
Balance Check, as the name suggests, is considered as a vital component as it is
imperative for the Bank to ensure that the Debit account has enough funds for the
payment to be processed.
If the required balance is available for the transaction then the DDA (Demand Deposit
Account) carries out a Reservation on the Debit account.
This Reservation implies that the Transaction amount is earmarked for the payment.

Balance Check

The Balance Check Component within the payment engine covers the functionality
for two major facets
Funds Authorization
Funds Authorization is the process of checking whether the Debit Account has
enough funds for the payment to be processed and if present then Reserving
(Earmarking) the funds for the same.
Cancel Reservation
Cancel Reservation is the process of removing a reservation that is already
applied on an account. This is required when a payment is Cancelled and it
has a valid reservation applied on the debit account. Or in cases wherein the
debit account is changed and the old debit account had a reservation applied
on it.

56
Note!
The check for Debit Authority and Debit Party determination is completed before the
call to the Balance Check Component. Balance Check Component will use the debit
account determined by Debit Party Determination for the Reservation.

56
The main objective of Balance Check is to reserve funds before proceed further in
processing a payment in TPS.

There are totally 3 components involved in Balance Check process.

1. Balance Check
2. Balance Interface
3. DDA

After determining the Debit Party, it is necessary to ensure the required Balance is
available in it.
When balance is found available then the amount should be locked so that another
transaction cannot utilize that balance.
Balance Check component ensures these jobs done before proceeding further with
the processing.
Since Balance Check is below the Warehouse, it reserves the amount from the day in
which it is called, assuming it is called on the requested day of execution.

57
Balance Check Required List
Specify if balance check is required based on the characteristics of the payment such
as Originating Source, Account Type, Incoming Message Type and Clearing Nature
Code here.
If balance check required is set as “Y” then funds authorization is required for the
payment. Else funds authorization is not required for the payment. The entries in this
table are searched for a match in the order of its Ranking. The Balance check required
flag is retrieved from the first entry that matches the payment characteristics. If no
entry meets the match criteria then a default value of ‘Y’ is considered.

Manual Auth Required List

Define the Manual Auth Reqd Flag based on the characteristics of the payment such
as Business Line, Originating Workflow, Originating Source, Message Priority, Banking
Priority, Transaction Amount Limit, Incoming Message Type and Clearing Nature Code
here.
The Manual Authorization Required flag is not checked for Funds Authorization
requests with a Pre-Authorization key. Such requests are never sent for manual
approval within the DDA.
If this flag is set to ‘Y’ then a Manual Authorization can be requested within the DDA
if the debit account does not have the required balance for the reservation to go
through.
If this flag is set to ‘N’ then a Manual Authorization cannot be requested even if the

58
debit account does not have the required balance for the reservation to go through.
Such a payment would get a ‘Reject’ response
The entries in this table are searched for a match in the order of its Ranking. The
Manual Auth Reqd Flag is retrieved from the first entry that matches the payment
characteristics. If no entry meets the match criteria then a default value of ‘Y’ is
considered.

58
Reject Response Action List
Defines the Reject Response Action Flag based on the characteristics of the payment
such as Business Line, Originating Workflow, Originating Source, Message Priority,
Banking Priority, Transaction Amount Limit, Incoming Message Type and Clearing
Nature Code here.
The Reject Response Action flag is not checked for the responses received against a
Funds Authorization requests with a Pre-Authorization key.
If this flag is set to ‘R’ then the payment for which a Funds Authorization response of
‘Rejected’ is received is to be sent to Repair.
If this flag is set to ‘C’ then the payment for which a Funds Authorization response of
‘Rejected’ is received is to be sent for Cancellation.
The entries in this table are searched for a match in the order of its Ranking. The
Reject Response Action flag is retrieved from the first entry that matches the
payment characteristics. If no entry meets the match criteria then a default value of
‘R’ is considered.
Note that the fields in this table are the same as the entries for the Manual
Authorization Required table. Defining a new table for Reject Response action (and
not using the same as Manual Authorization Required) gives the user an ease in
operationally maintaining the tables

59
60
Overview
When a payment is processed, it is imperative for the system to know the direction of
the payment. This would influence further processing of the payment.
In general, 4 different types of direction can be identified for payments not
originating from Order Entry and Repair:
Incoming: the Originating Party of the payment does not reside in the
processing bank’s ledger, the Beneficiary Party of the payment resides in the
processing bank’s ledger
Outgoing: the Originating Party of the payment resides in the processing
bank’s ledger, the Beneficiary Party of the payment does not reside in the
processing bank’s ledger
Redirect: neither the Originating Party nor the Beneficiary Party of the
payment resides in the processing bank’s ledger
Book: both the Originating Party and the Beneficiary Party of the payment
reside in the processing bank’s ledger
For instance, if it is an outgoing or a redirect payment, we need to find out how best
to reach the final beneficiary (Account with institution).
The direction of a payment is based on the following criteria:
Originating source of the payment instruction
Incoming message type of the payment instruction
Debit account type
Presence of certain code words

61
 Whether the ultimate beneficiary of the payment resides in the processing
bank’s ledger (On us / Off us)
The nature of the transfer (Bank or Customer transfer) can also influence the
payment processing. For example, conditions differ between banks and customers
and so will the charges and floats. Therefore, it is important to distinguish between
these two types of transfers.
Whether the payment is a bank or client transfer is based on the following criteria:
Originating source of the payment instruction
Incoming message type of the payment instruction
The direction (I, O, R, and B) and transfer type (B, C) must be determined for every
payment otherwise the payment cannot be properly processed.

61
There are 4 types of possible directions
Incoming
Outgoing
Redirect
Book
Direction component not only determines Direction but also Transfer type of a
payment.
There are two types of Transfer type
Bank transfer
Customer Transfer
If both the ultimate parties are Bank then it is Bank transfer.
If either one of the parties are Customer ( or can be both) then it is Customer
Transfer.

62
Each payment can only be one of the following two types:
Customer transfer: either the originating party or the beneficiary party is a
customer (or both)
Bank transfer: both the originating party as well as the beneficiary party is a
bank
It is vital that a payment can only be a customer transfer or bank transfer, it can never
be both.
The table above shows the Transfer Type indicator for all payments that are relevant
for the Payment Engine.

Note!
* The transfer type for Order Entry/Repair payments does not have to be determined
here as the operator will already have set the Transfer Type indicator via the input
screen or direction is already determined before the payment is put to the Repair
queue.

Note** : BATCH and clearing payments will be covered later on in the course and
these will be explained in detail then. Information provided for high level overview.

63
Different flavours of Product Determination based on the High Level Weight (Light,
Heavy) to enable simple definition and efficient processing of payments
Ability to build additional flavours of Product Determination (Middle Weight, in
future) and Specific Weight
Definition of attributes which determine the Product for the different flavours via GUI
Definition of Output flags (via GUI) which drive the processing of the subsequent
components of the Payment Engine (Client Condition, Routing & Settlement, Date
Determination, Fees and Posting Scheme)
Logic to determine and derive some of the Product Determination attributes, which
are not directly available in the Payment transaction, from related fields in the
Payment transaction
Peeling off mechanism to retrieve the right product for Heavy Weight Payments
Logic to retrieve the product for light weight payments

Overview
The main feature of Product Determination component is to arrive at the Product of
the Payment and retrieve the Output Parameters, which become input to a number
of components to assist in making decisions.

A bank can serve a wide variety of corporate clients and offer Payment Products to
suit their business needs. When processing a payment, it is vital for the system to
know which payment product is being used so that any further processing of the

64
payment can be influenced.
There are two characters of product determination and depending on the weights of
a payment the appropriate production determination character is used

64
 How do I decide if my payment product is heavy, medium or light?
This is based on a business requirement. To cater the payments based on their
characteristics, there is a feature called as Weights Assignment.
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 the payment processing priority, and deciding flavour of processing.
Heavy Weight
Usually, All International Payments and Domestic Payments (Outgoing or
Book) are categorized as Heavy Weight. Cross border payments received and
sent via SWIFT network and foreign currency book payments are categorised
as “International” payments”. Payments in local currency originating and
ending within the same Country are categorized as “Domestic”.
Medium Weight
Medium Weight is specifically meant for SEPA
Light Weight
Generally, all Incoming or Re-direct Domestic Payments through Clearing
Channels are treated as Light Weight.
Can Local Clearing messages have Heavy Weight processing?
TPS provides a robust configuration engine to define agreements based on message
characteristics and cater varied customer at varied levels.
Its indigenous and state-of-art architecture allows to set up configurations
responsible for payment process with respect to the client interests.

65
If Local Clearing messages are meant to be distinguished under Heavy weights,
priority can be assigned in product determination accordingly.
How is a Payment processed under Heavy Weight / Light Weight Product
Determination?
A payment is processed as ‘Heavy Weight’ or ‘Light Weight’ based on its
characteristics and pertaining to the processing Bank’s business requirement.
To serve the payments based on their characteristics, there is a feature called as
Weights Assignment.
Essential elements are picked up from the Payment and based on it, the whole
processing takes place.
For Example,
Mike in US, wishes to pay his supplier Magnum located in UK, USD 1000. Magnum
holds an account with T24 Bank while Mike has an account with CITI Bank in UK. CITI
Bank, on behalf of Mike sends a 103 to T24 Bank. Hence, an incoming MT103 is
received.
From the payment received, the Processing Company BIC and Message type is
retrieved. TPS can receive payments from various channels namely SWIFT, BACS etc.
Pertaining to this scenario, the channel from which we are expecting is “SWIFT” and
the Originating Source is also “SWIFT”.
These three key values are regarded as vital and based on them, the Weights
Assignment is performed.
The flavour of Product Determination is based on the High Level Weight (Light,
Heavy) to enable simple definition and efficient processing of payments.
In simple terms, High Level Weight (Weight Code) from the Payment Object will be
read and if the High level Weight is “Heavy” it should call Heavy Weight Product
Determination and if the High Level Weight is “Light” it should call Light Weight
Product Determination.
For Example, if the Weight Code is configured as ‘H”, then the payment will be
processed under Heavy Weight Product.
How does Product Determination impact the business requirement based
on payment characteristics?
Based on a payment, Product Determination calculates several attributes and these
attributes can be considered as crucial in enhancing the Bank’s business process.
For Example,
Based on the payment direction, the Payment can be distinguished as ‘Domestic’ or
‘International’.
And on classifying the payment as ‘Domestic’ or ‘International’, the processing of
payment becomes easy with respect to Fee calculations, etc.

If Direction is "Incoming”

65
 Product Determination checks if the Debit Account Currency equals Home
Currencies (this can be multiple) and Transaction Currency equals Home
Currencies and Ordering Institution Country equals Home (Local) Countries
(this can be multiple).
If Ordering Institution is not present, checks “Sender Country” and if “Sender
Country” not present, then payment set as “International”.
If both Transaction Currency and Debit Account Currency equals Home
Currency and Ordering Institution or Sender Country (as determined above)
equals Home (Local) Country then payment set “Domestic”, else
“International”.
If Direction is “Book”
Product Determination checks if Debit Account Currency and Transaction
Currency match the Home Currencies. If above check is successful, then the
payment is set to “Domestic”, else “International”.
If Direction is “Outgoing” or “Re-direct”
Product Determination checks if the Debit Account Currency matches Home
Currencies (this can be multiple) and Transaction Currency matches Home
Currencies and Beneficiary Country (from BENINS or ACWINS) equals Home
(Local) Countries (this can be multiple). If yes, the payment is set as
“Domestic”, else “International”.
If both BENINS and ACWINS are not present, then extracts Beneficiary
(BENFCY) Country from the “Beneficiary IBAN” and decide if the payment is
“Domestic” or “International”, as explained above. If BENFCY does not have a
valid IBAN, set “International”.

65
Product can be defined using menu option: Admin Menu > Product Determination >
Heavy weight product Condition > HeavyWeightProductCond List
Heavy Weight (HW) Product Determination
All International Payments and Domestic Payments (Outgoing or Book) are generally
categorized as Heavy Weight.
Cross border payments received and sent via SWIFT network and foreign currency
book payments are categorised as “International” payments”. Payments in local
currency originating and ending within the same Country are categorized as
“Domestic”.
By ascertaining a Payment as Heavy Weight and further processing it under Heavy
Weight Product Determination, several Outputs are being produced. These output
parameters will directly impact the Payment processing or act as a key for other
components to work.
Note!
Heavy Weight Product Determination will set the Charge Type to “SHA”. It will be
invoked when the PSD Compliant Indicator is “Y” and Charge Type is not “SHA”.

Light Weight (LW) Product Determination

Incoming Domestic Payments from Clearing, usually do not require complex Product
set-up and processing logic. Hence, when a payment is identified as light weight by
the “Assign Weight” component, then the Product Determination component will
process it with a much simpler setup and retrieval logic

66
The aspects of the Light Weight Product Determination are different from that of the
Heavy Weight.
Incoming Domestic Payments have the following characteristics:
Company is fixed depending on the Source
Direction is pre-determined
Payments do not have Parent/Child dependency
Payments are Domestic
Message Priority is not relevant, as they are booked as and when received
Currency is local (home) currency
Client Conditions and Fees are not influenced by the Transaction Amount
Charge Type is always SHA
No Code-words are present
Payments are PSD and EC compliant, if they originate in EU/EEA countries
Messages are not repaired by PayFix
Inter/Intra Company payments are not applicable
Output Parameters Updated
Client Condition Product - This will be filled by the User and become input to Client
Condition component to set Client Conditions.
Source Indicator – “S” – “Source” or “G” – “Source Group” will be entered by the
User. This flag is required to group payments from multiple sources and set Source
Product.
Source Product – Product Determination has to read the Source Indicator and fill the
“Source Product” with “Originating Source” if the “Source Indicator” is “S”.
Otherwise, “Source Product Group” table should be looked up and the relevant
“Source Product” linked in the table should be updated.
Routing Product – This defines the Routing Group. It will be input by the User and
become an input parameter for Routing & Settlement.
Impose Routing Flag – This flag is used to impose the appropriate Routing Group for
outgoing payments to be routed via local clearing.
Fee Product – This defines the Fee Group. It will be filled by the User and become an
input parameter for Fees.
Posting Product – This defines the Posting Group. It will be set by the User and
become an input parameter for Posting Scheme.
Ledger Product Code – It enables identification of the Product for description
line/narrative purposes, even if the Posting Group and resulting Posting Lines are
same for two different products.
Debit Book Code – This identifies the booking code for the debit entry on the
payment transaction amount. It will be used by the Posting Scheme.
Credit Book Code – This identifies the booking code for the credit entry on the
payment transaction amount. It will be used by the Posting Scheme.
Debit Charge Book Code – This identifies the booking code for the Charge Debit. It
will be used by the Posting Scheme.

66
Credit Charge Book Code – This identifies the booking code for the Charge Credit. It
will be used by the Posting Scheme.
Debit VAT Book Code – This identifies the booking code for VAT Debit. It will be used
by the Posting Scheme.
Credit VAT Book Code – This identifies the booking code for VAT Credit. It will be
used by the Posting Scheme.
Regulatory Reporting Indicator – This identifies whether the Payment has to fulfil
Regulatory Reporting requirements. It will be input by the user during Product setup.
New Priority – It identifies the new Priority (numeric 0 to 10) of the Payment. User
can choose to ignore the incoming priority and define a new Priority, which will be
picked up during Product Determination.
PSD Compliant Indicator – This defines if the Payment is PSD Compliant. This
indicator will be used by Date Determination and Fee components for processing the
payment.
EC Compliant Indicator – This defines if the Payment is EC Compliant and the values
will be set by the User.
CreditIBANIndicator - This Flag is an output from Product Determination and will be
used by Fee component.
BeneficiaryPartyIBANCountry – This Flag is an output from Product Determination
and it is used in Payment Finalization component.
OrderingPartyIBANCountry – This Flag is an output from Product Determination and
it is used in Payment Finalization component.
HeavyWeightProductID – Product determination component would pass this product
ID of the determined product to payment object. And this ID can be used by Billing
component to retrieve product information.
How to choose the right product for a payment?
As there are several attributes that make a Product, we require an efficient method of
the retrieving the right Product and the Output Flags relating to it.
Product Determination component will use the Peeling off mechanism to achieve
this.
Peeling off means that data is retrieved from the database in several steps, from the
most detail level to high level. The peeling off mechanism works on a Relational
database containing tables with fixed attributes and indexes (views). The file that
stores the information is indexed with a compound key
Peeling off mechanism ensures the following for Product Determination –
Ease of setup
Minimum number of records
Better Performance due to lower database interaction

66
67
68