Welcome to Payments Temenos Payments Hub, Lesson 7, Features » Part 5.

In this lesson I am going to describe Client Conditions

Dates Determination
Duplicate Check
Purpose
A bank processes payment transactions for various clients, both retail &
corporate, with different options, products and services in terms of the way
their transactions are processed. To differentiate and serve better, banks
strive to customise their various services or products that suit the
requirements of these customers.
Allowing customers to choose their preferences from a predefined set of
possible options is an approach that can give customers the flexibility of
defining their choices beforehand and at the same time agreeing to the
services being availed from the bank. Banks on the other hand profit from
better marketing and increased awareness among clients about their service
offerings.
The main purpose of Client Conditions (CC) component is to make available
all the choices to the customer to choose from relating to the processing of a
payment and store these choices for use when applicable.
Overview
Client conditions (CC) are retrieved in all scenarios where the ordering or
beneficiary client has an account with the Processing bank and is not a
financial institution.
Client Conditions (CC) are devised separately for influencing the transaction
processing and the transaction charges.
CC Processing refer to all the conditions set up for influencing the processing of the
payment. The preferences of the client are defined in records which are retrieved from
this component based on the payment characteristics. A customer can have different
agreements based on various payment types defined for extra flexibility and
customisation.
CC Charges on the other hand refer to all conditions regarding the charging of the
client for various services. The agreements hold information regarding
discounts/preferential charging/charges etc. for clients based on their negotiations
with the bank.
 Is it possible to have separate charge accounts for
distinguished Clients?
Many clients prefer to maintain a separate account for all charges
incurred while using the bank’s services.
This special charges account can be listed in CC so that fees and
posting components can book all charges in that account.
This feature is available only when the client conditions are defined at a
Client ID/Account level although different accounts can be provided for
debit & credit side.
Can a Client negotiate the Lead Time on Cut-Off?
Lead times are configured by the bank so as to ensure that the
operations can successfully process the payment through a channel
before its actual cut-off time is reached.
The clients can negotiate with banks what their lead times can be
before the external cut off times.
For Example,
If the channel specific cut-off time is 17.00 and the Lead time a client
has negotiated is 0.5 Hrs. then the last payment that client can send
through for the day is at 16.30.
All the payments after that will be processed as received after cut off
time for that channel.
Can a Client negotiate on the charges of a currency?
All clients can negotiate a discount on the spreads a bank charges on the spot
rate of a currency.
For Example,
A client who deals in only 3 currencies can have the following discounts stored
in CC: Value in percentage (%).
FX Discount
Client
Discount
Client A
30%
Client B
70%
Client Conditions Enhancements Offered
There are also other enhancements been made available for the Client
through Client Conditions record.
Booking charges in detail with break-up
When charges are posted separately, some clients prefer to have the break-
up of all the charges charged in detail in their statements while some prefer to
have it as a lump sum amount.
Separate Charge Booking
Every client has a preference in how the charges are displayed in their
periodic statements. When charges are not being posted in a separate
account some clients expect to have them booked together with the main
amount while some may prefer to have them booked separately.
Booking charges in detail with break-up
Straight through Processing
Straight through processing (STP) refers to the complete payment being
processed electronically without any manual intervention or keying in of info by
an operator.
Statement Format ID
Floats
A client can choose to have floats taken on his transaction which can result
in lower fees
For Example,
A client negotiates to have 2 day float on the debit transactions while only 1
day floats on the credit transactions.
Language
Every client can have a language preference in which to receive alerts and
intimation of the payments.
Language can be used for language specific statement lines and charge
description in statement lines. While also being taken into consideration for
confirmations (phone/SMS/email).
Billing Indicator
An indicator can be set which tells the other components that the customer
would want the payment module components to send the information to the
billing engine and process charges there.
Special Instructions
For Example,
Client wishes to be informed about any FX transaction that goes Non STP.
Non STP FX Flag
For Example,
A client has a Euro CCY account and wants an intimation before any
payment involving FX is processed on the account. This functionality will allow
the client to receive communication of the same before any processing is
done.
FX STP Limit
For Example,
A client wishes for all FX transactions above €2000 to go NSTP for his Dollar
CCY account.
Path:
Admin Menu > Payment Hub > Client Conditions GUI > Client Condition
Product List
User can create a Client Condition product and associate with Client condition
in order to map with product determination.
What are the factors influencing Client Conditions?
Processing Weight – Weight can influence which CC program will be
called in for the processing of the outputs.
Product – Banks sell services and a service or a combination of
services can be packaged as a product. A client using multiple payment
products may want different conditions set for each product as that
allows for more flexibility. Each payment product has certain
characteristics e.g.
Domestic or International Payment
Customer Transfer or Bank Transfer
High Value or Low Value Payment
Urgent or Normal Payment
Client Agreements – A Bank deals with variety of Clients which could
be retail, High Net worth Individual (HNI) or Corporates to name a few
classifications. Depending on the Client and the business bank is
expecting from the Client, bank will be ready to tailor the services
specifically for that Client.
Source Product – Bank may receive payments from variety of sources.
It is possible that a single product will have a single routing group and
posting group but a single product could be attached to multiple
sources. Taking this factor into consideration it would be more flexible to have
different client conditions for the different sources or have only one client
condition for the source group to which all the actual sources belong to.
Batch Payments
A salary batch contains one parent payment where the ordering customer is
debited and a number of child payments where the beneficiaries are credited.
An indicator on the payment will show whether the parent of child is being
processed.
Although the child payment is debited from a suspense account, the client
conditions are based on the parent customer.
The client condition component will know from the batch indicator field if a
payment is part of a batch (child or parent).
For each child payment, since the debit party is the suspense account, the
client condition component would also need to determine the parent to read
the client conditions of the parent account.
In case of book payments, the client conditions of the credit side (child
payment) would also need to be read.
How to determine whether the payment is part of a batch?
Batch Indicator: The client condition component will also make a check to
see if this payment is part of a batch payment. The indicator tells if the
payment is a ‘Parent’ or a ‘Child’. This is crucial as the client conditions
component needs to determine if the payment is part of a batch or not as the
child payments then have to be linked to the parent payment and conditions
read and retrieved accordingly.
Parent FT Number: This unique FT number assigned to a Parent transaction
is copied onto all child payments to positively identify which child payments
belong to which parent payment.
Once a child parent relationship is identified it’s possible for the Client
conditions to assign the parents conditions to the child payments.
How to choose the right Client Condition for a payment?
We can define the Client Conditions at various levels; at one end it could be
very generic and can be defined at the product level so that all payments with
that product will use those client conditions; on the other end these could be
very specific to a particular client requirements and accordingly defined at the
most specific level (Product/Source/Business Line/Client Id/
Account/Currency).
This means that order in which Client Conditions are retrieved is very
important.
To enable this order, Peeling off mechanism is used to define the order in
which Client Conditions should be read.
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
Calculation of Tax on
Principal using Tax Id
• While calculating Tax for the principal
amount, system check the Tax
percentage(Here 25%) defined in TAX
table for the Tax Id defined in
PP.CLIENT.CONDITION table and
derive the Tax Amount.

• The calculated tax will be booked

(credited to) in the account returned
 from the TAX Table (Field Category in TAX
table – Here 11282) instead of PL account
defined in FeeTypeCreditAccount table.

• Calculated tax will also be available in GL

home currency in POR.APPLIEDFEE and
the same will be displayed in customer
statement

Calculation of Tax on Principal using

Tax Type Id
• Based on Tax Type Id, Tax is
calculated
• The calculated tax will be booked
(credited to) in the account returned
from the TAX Table
• Calculated tax will also be available
in GL home currency in
POR.APPLIEDFEE and the same
will be displayed in customer
statement
Value dates are an integral part of the transaction as it provides the input to
calculate debit or credit interest. Other dates which are required to process
the transaction completely e.g. booking date required by the ledger, send date
to decide when exactly we need to send the message out in case of outgoing
and redirected payments.

A Bank processes payment transaction for various clients which could be

retail or corporate clients; it also process transactions from other banks. Each
one of them might have different requirement in terms of the way transaction
is processed. Some banks may want us to warehouse the payment if future
dated and certain other banks may want us to process even future dated
payment as and when received without warehousing. Some clients might be
fine if we take floats instead of the charges but certain other client would
prefer urgent transfer and ready to pay for that.

Purpose
he purpose of the Date Determination component is derive the various dates
required to process the payments.
Purpose of calculating various dates for the payment are.
• Date at which we need to book the ledger
• In case of Outgoing and Redirected payments, decide on when exactly we
 need to send out the message
• Warehouse the payment if future dated.
• Input to calculate debit/credit interest which is due from/to customer.
Due Date or Processing Date
Date on which transaction is actually processed inside bank. This could be a
future date as well, in which case payment will be warehoused till the due
date.
Debit Value Date (DVD)
Settlement date till which interest is calculated/credited to the customer's bank
account on the old balance
Credit Value Date (CVD)
Settlement date from which interest is calculated/credited to the customer's
bank account on the new balance
Book Date (BD)
Date on which funds are debited from the debit party’s account
Exposure Date
It’s the date from which credited funds are available for the use of client.
Payment Send Date (PSD)
Date on which payment message (MT103, MT202) is send out to the receiving
bank or clearing.
Cover Send Date (CSD)
Date on which MT202 cover message is send out when payment is settled
through a cover.
Requested CVD
In certain cases we receive payment instructions, where in customer or other bank is
requesting a specific Credit Value Date instead of the execution date. E.g. It’s the 32A
date in MT103 or tag 30 date in MT101 when it comes with codeword OTHR/BBDD.
BBDD (beneficiary bank due date) indicates that even though it’s MT101 (request for
transfer) but the date in Tag30 should be treated as requested Credit Value date
instead of execution date. In this case BBDD is just an example codeword and it can
be any other bilaterally agreed codeword. This codeword must be configured in the
codeword component so that date is read as requested credit value date.
 Factors influencing Dates
Routing & Settlement
In Outgoing and Redirected payments, Routing & Settlement is used to
identify the channel through which the payment can be settled. The
channel may require settlement shifts to settle the payment. These
shifts are taken into account while calculating Dates
Client Agreements
Bank agrees with client on the floats which could be taken on their
payments. Floats are taken into account while calculating Dates.
Bank Agreements
Certain banks would like to warehouse the payment till the requested
date and process the payment only on the requested date. Warehouse
flag is used for that purpose.
Currency
International payments involves currencies other than base currency in
such we may require additional days to process the transaction. These
kind of FX shifts are taken into account while calculating Dates
Holidays
TPH supports definition of Non-Working days (Holidays) separately for
Countries, Currencies and Clearings. Week end days can be included
as Holidays. These holidays should be considered while calculating Dates.
Order Entry/Repair
Operator can provide the value dates through Order Entry/ Repair screen. In
such cases the dates given by the operator should be honoured.
Settlement Shift – The settlement cycle time for the channel through
which payment is settled. This is the number of business days the
settlement channel and/or parties after processing bank require to
complete the payment.

FX Shift – Currency conversion time for the FX department. This is

applicable when the debit account and credit account currencies are not
same.

Cut-off time – Each payment have a cut-off time which indicates the
time by which a payment can be processed by the bank and if a
payment comes after the cut-off time then bank might take additional
day(cut-off shift) to process the payment.

Cut-off time with FX – In cases when currency conversion is involved

bank may set the cut-off time earlier than the normal cut-off time to
compensate for the additional time required for the currency conversion.

Cut-off Shift – This is the number of business days to include in the date
formulas when payment is after cut-off but we still want to process it
today (ASAP). Adding this shift means that Credit Value Date is accordingly
shifted in future. If we are working in ALAP then we don’t apply cut-off shift but
rather warehouse the payment till next working day.

Floats – It’s the difference between the Credit Value Date and Debit Value
Date on which bank earns the interest.
Debit Float – It is the number of business days to adjust the Debit Value Date
(DVD) into the past from the Credit Value Date (CVD), adding float to the
transaction. This is applicable to the debit client.
Credit Float – It is the number of business days to adjust the Credit Value
Date (CVD) into the future, potentially adding float to the transaction. This is
applicable to the credit client.
MT103 Payment is received from Citi Bank (CITIUS33) in New York and
Sending Bank warehouse flag is equal to Yes and transaction currency is
EUR.
Credit Customer account is in USD and currency conversion is performed.
Credit side Client Conditions record for this payment says take Credit float of 1
day.
TPH supports definition of Non-Working days (Holidays) separately for
Countries, Currencies and Clearings. Week end days can be included as
Holidays. These holidays should be considered while calculating Dates.
Path: Admin Menu > Date Determination GUI > Boundary Date

If a date doesn’t fall into that boundary then that will be routed to the repair
operator. This will be done by logging a functional error based on which
Payment finalization will route the payment to repair.
The mentioned check should be done only after the initial date calculation has
been completed for the respective date type.
The configuration can be based on the following parameters
Source
In certain Clearing payments we have to honor the debit value date by
clearing (e.g. EBA, TARGET). Source is used to determine the clearing
from which the payment is received.
Direction
Direction is used to apply floats differently for Outgoing and Book
Payments, as against Incoming Payments. Also, for PSD compliance,
the Debit Value Date of the payment can be in the past for Outgoing
and Book payments.
Debit Account Type (Loro or Nostro)
Account Type (Loro/Nostro) determines the debit value date of the
payment. Nostro is only a mirror account and hence we keep the debit
value date same as being given by the correspondent bank who has the
actual Loro account.
Customer Transfer/Bank Transfer
Certain regulations such as PSD are applicable only for Customer
Transfers. Hence, such payments can be filtered to determine and
apply the debit value date.
Outgoing Channel
The outgoing channel through which the payment is routed, can determine the
Debit Value Date (e.g. SEPA).
If PSD Compliant
It takes 5 different values
D – Debit Leg of the payment is PSD compliant
C – Credit Leg of the payment is PSD compliant
Y – Both Legs of the payment are PSD compliant
N – Both Legs of the payment are not PSD compliant
I – Ignore, PSD not applicable
These values are derived from the output of the Product
Apply Debit Float
If this flag is set to “Y”, then debit float (defined in the Client Agreement) is
applied to the payment.
Debit Value Date derived from
The base date from which the Debit Value date is derived, can be defined
here. It can take the values
Today – Take the base as today (Business Date) and apply debit float, if
applicable
RCVD – Take the base as “Requested Credit Value Date” and subtract the
debit float, if applicable
CVD – Take the base as “Credit Value Date” (calculated) and subtract the debit
float, if applicable
RCVD1/CVD1 - Calculated as explained above for RCVD/CVD and
additionally it is checked if payment is PSD Compliant and if so, the date is
changed to “Today”.
TPH allows configuration of exposure date conditions based on
Processing Company
Client Product determined from Payment characteristics
Exposure Base Date (DUE or CVD)
Offset (plus/minus) days – To be added to the Exposure Base Date
Various holidays can be defined namely
Currency Holiday
Country Holiday
Regional Holiday
Channel Holiday
Weekend days – Each country/currency have working days defined
when financial transactions can be processed. In most of the
countries/currencies it’s Saturday & Sunday which is a non-
working/weekend days but there are some countries/currencies where
in it’s other than Saturday or Sunday (e.g. Gulf countries observe Friday
as non-working day). We should be able to define the non-
working/weekend days for a country & currency and the mentioned
days (e.g. Saturday/Sunday) will be treated as a holiday for that
country/currency.

Holiday check will be a two-step process where in we

First check which holidays(currency, country etc.) need to be checked
for the respective date (Due/Processing, CVD or DVD) based on the
business day/holiday logic table. E.g. if we are doing the CVD
calculation then we will look at the row for CVD date type in Business
day logic table and identify holidays which we need to check (in this case it will
be Credit party country, Credit party region, Credit currency, Channel holiday
and non-working days for owning bank)
Based on the above output we will check the holiday table for all those
holidays (applicable currency, country etc.) and then see if there exist any
holiday entry in the table when we are processing the payment. E.g. we are
processing a payment on Monday and calculated CVD as Wednesday (due to
various shifts) and in the holiday table there exist an entry for the currency
holiday on Tuesday and credit party country holiday on Wednesday. In that
case we will shift the CVD to Friday (pushed in future by 2 days due to
holidays).
The purpose of Duplicate Check component is to ensure no duplicate
payments are processed by the payment engine. The Duplicate check is
performed on the message characteristics of the payment and for all
payments. This component is therefore responsible for the functional duplicate
of each individual payment and not for technical duplicate.
 Check for duplicate
If the credit account is already present in the payment file, then the
credit party does not have to be determined again. The account can be
directly routed to the Account & Customer interface for validation.
Scenarios wherein credit account is already present in the payment file:
Order entry payments.
Payments released from repair queue
Payments released from warehouse queue
Payments processed again by STP when the Posting Scheme validates
that the channel cut-off time has passed
Payments processed again by STP when response is received from the
Filtering interface after the Release date (i.e. Filtering response equals
“PASS”)

Inbound payments
These payments can be either single credit transfer or individual
transactions part of a clearing file.
Clearing files will trigger an additional settlement transaction for
reconciliation purpose (Book payment)
Account of the Credit Party: This is the actual credit account that will be used
for Posting.
Currency of the Credit Account: Account Currency as present in the Account
and Customer Database
Transaction Amount mentioned in the payment instruction (Interbank Settled
Amount)
Transaction Currency mentioned in the payment instruction
Due Date: As determined by the Payment Engine

Sender’s Reference: The reference assigned by the Sender to

unambiguously identify the message.
Remittance Information : Transaction details that need to be transmitted to
the beneficiary customer
Outbound payments
These are outgoing payments originated by the customer of the Bank where
the beneficiary belongs to other Bank.

o Account of the Debit Party: This is the actual debit account that will be used
for Posting.
o Currency of the Debit Account : Account currency as present in the Account
and Customer Database
o Transaction Amount mentioned in the payment instruction (Interbank Settled
Amount)
o Transaction Currency mentioned in the payment instruction
o Due Date: As determined by the Payment Engine
o Sender’s Reference : The reference assigned by the Sender to
unambiguously identify the message.
o Remittance Information: Transaction details that need to be transmitted
to the beneficiary customer
Note!
In cases where STO payments do not have unique sender’s reference for
each payment, he Message mapping component will add the transaction
number as the reference number

Book payments
These are payment transfers between two accounts belonging to the Bank.
o Account of the Debit Party: This is the actual debit account that will be used
for Posting.
o Currency of the Debit Account: Account currency as present in the Account
and Customer Database
o Transaction Amount mentioned in the payment instruction (Interbank Settled
Amount)
o Transaction Currency mentioned in the payment instruction
o Due Date: As determined by the Payment Engine
o Sender’s Reference: The reference assigned by the Sender to
unambiguously identify the message
o Remittance Information: Transaction details that need to be transmitted
to the beneficiary customer
o Account of the Credit Party : This is the actual credit account that will be
used for Posting.
o Currency of the Credit Account :Account Currency as present in the Account
and Customer Database
o Transaction Amount mentioned in the payment instruction
o Credit Value Date :If not requested in the payment message ,it will be
determined by the Payment Engine

Redirect payments
These payments are received from other banks to be routed to another bank
(Beneficiary does not belong to the Bank processing the payment).

o Account of the Debit Party: This is the actual debit account that will be used
for Posting.
o Currency of the Debit Account :Account currency as present in the Account
and Customer Database
o Transaction Amount mentioned in the payment instruction (Interbank Settled
Amount)
o Transaction Currency mentioned in the payment instruction
o Due Date: As determined by the Payment Engine
o Sender’s Reference : The reference assigned by the Sender to
unambiguously identify the message
o Remittance Information: Transaction details that need to be transmitted
to the beneficiary customer

Number of Days (Days to check)

Also these payments should have been processed in last few days as
calculated from the processing date (processing dates minus a pre-defined
number of days) .This number of days in the past can be defined based on the
Bank requirement and is configurable in Company properties table.
Override duplicate check
Payments in repair queue because of being identified as duplicate by this
component can be overridden by the operator and released when the operator
accepts the duplicate payment warning message on the screen. Each time
when duplicate check has to be performed for the payment, there is no need to
validate if the payment was identified previously as duplicate and whether it
was overridden by screen operator. The component returns a warning
message each time if it happens to be a duplicate payment based on the
selection criteria.

Skip duplicate check

When duplicate check is invoked, every payment has a specific weight and
high level weight. Certain components inside the payment engine can decide
whether the component should be skipped for all payments or only for some
payments based on the specific weight and high level weight of the payment
as the criteria.
These steps are used to enable the Functional Duplicate Check.
Application for which duplicate check is intended should be indicated in
APPLICATION Field
Field values that are to be compared for determining whether the transaction
is duplicate or not is indicated in multi value Fields
If DEBIT.AMOUNT and DEBIT.ACCT.NO are indicated, a transaction will be
termed as duplicate, if only its debit account as well as amount are the same
as of another transaction
LINKED.APPLICATION Secondary application multi value set, with the
following subset of fields:
LINKED.BY – the common ID identifier between the primary application and
the linked application. (it is a valid field from primary application, which holds
the ID of a record in the linked application)
LINK.FIELD.VALUE.API – To extract the ID of a record in linked
application(when the ID is not Known).
LINKED.APP.FIELDS – multi value set of fields in the linked application which
will be used in the duplicate check
LINK.FIELD.VALUE.API – API extracts the ID of a record from linked
application when the ID of the application is not known
PURGE.DAYS - Details retained for comparison for the period defined
 One or more records of EB.DUPLICATE.TYPE can be attached to required
Product condition records
When the first TPH of the chosen transaction type is input, System creates a
record in EB.DUPLICATE
Id depends on Fields defined in EB.DUPLICATE.TYPE
GBP*23701*1100.00 if Currency, Debit account number and amount have
been selected
When a transaction is input, system checks EB.DUPLICATE for similar Id,
and if present, generates override and when approved, records details of that
transaction also in EB.DUPLICATE When another transaction matches these
definitions, it records details of that also
Path: Static data> Company Properties
Number of Days (History Days)
PP.COMPANYPROPERTIES – DaysDuplicateCheck
The number of days required to consider for duplicate check is maintained.
(Checks Working Days from PP.COUNTRYNONWORKINGDAY)
Sample message given to identify how the duplicate check works in TPH.
EB.DUPLICATE key is formed with the FT number reference
Duplicate Check can be skipped in the following ways
1. In the Programs Per weight application set Programs skip indicator to Yes
for the record Duplicate Check to skip the Duplicate Check
In this lesson I described Client Conditions
Dates Determination
Duplicate Check