Welcome to Payments Temenos Payments Hub, Lesson 8, Features » Part 6.

In this lesson I am going to describe Filtering

Risks
Appling charges
Special FX
Financial institutions are required to filter or screen payment instructions
before the funds are made available to avoid any breaching of
sanctions, embargoes and other measures.
This filtering needs to happen real-time before booking the payment.
Therefore a system needs to be in place wherein all
payments/transactions can be monitored and filtered in a timely
manner.

Filtering is necessary to stop transactions which

aid
Terrorist financing, illegal activities financing etc. or
fall under Office of Foreign Assets Control (OFAC) list
or Specially Designated Nationals (SDN) list. This is
an indicative list and every bank can have its own
criteria for filtering. This information is stored on the
 external database and not internally within the
component.
On the contrary, the Filtering component does not perform the actual
filtering of the payment. It will send the payment details to an
external/internal filter service in which the screening is done.
Main features of the component:
Sending payment instruction to filter service with required
information
Receiving Response from filter service
Acting on the ‘Pass’ or ‘Fail’ received

Before sending the payment to warehouse where the calculated due date is
in the future for below mentioned scenarios:
Routing & Settlement has bumped the due date to next working day
because the cut off time for the selected channel has passed
Payment can be executed at a later date to meet the requested settlement
date (CVD)
Configuration part needs to be explained in details. System dependency.
Filtering Component can be skipped based on the company code, Output
Channel and Message Type.
9

TPH send payments to screening system to check if the transaction involves

Terrorist financing activities.
When Screening System sends Seize Funds as response that means the
payment must not go through and must be credited to an internal account.
AML operator further investigates the payment and proceed with processing or
cancelling the payment.
Now TPH can receive Seize Funds Response and credit the payment to
Internal Account.
10

TPS can send the transactions to external sanction screening service to filter
the payment of any dubious details before being processed. This option allows
operator to view the Payment records for which are sent to the screening
service but response is yet to be received. Sometimes a first response from
the screening service is a ‘Possible’ hit but a final response is awaited, such
transactions will also be available in this list.
11

The following list of payments falls in the Hit filter Enquiry:

HIT from Sanction screening
Timed Out due to no response from Sanction screening
Seize Funds was received as response from Sanction screening
HIT from Sanction screening
Timed Out due to no response from Sanction screening
Seize Funds returned as response from Sanction screening but funds cannot
be seized as the payment is neither a Credit Transfer nor a Cheque Credit
received.
Payments that are sent to repair queue from Manual filter payments. Those
payments must not be available in general repair queue.
Cancel/Return - System allows the payment to be cancelled /returned
/rejected from this screen as per existing functionality. In case the payment
does not qualify for a return /reject /cancel, then system should throw an
warning “Inappropriate action performed for AML Hit/Time Out/Sieze Funds’.
Continue processing the payment -No values are input enabled except the
option to accept the warning raised.
Seize Funds- This option opens the payment in standard repair view .Only
Credit Account is input enabled. This is to capture the account to which funds
need to be parked.
View payment information (Standard view payment screen)
View payment information in detail (Standard view in detail payment screen)

.
12

This enquiry provides option to view the payments as it is used for reporting
purposes only.
Receive payment file from sending component:
A payment file with today’s due date or future due date can be received
from the Payment Finalization component of the STP flow.
The filter also receives payments on a daily basis from the Warehouse.
(Payments with future due date for daily filtering)

Send the mapped information of the payment file made to the

external filter service. Once sent the payment is moved to a Pending
queue to await response. The FIFO model is used the component to
send payments out to the external filter. The payment will not be
processed further until the payment engine receives a response from
the filter.

At this point a TRIP status message will be triggered that the payment
has moved to a ‘Pending Response Queue’. This will help to track the
progress of the payment through this component.

Following steps are performed:

1- Pick all information of the Payment File with the original payment received
2- Assign a Request ID to the Payment
3- Send the payment to Filtering interface
4- Move the Payment to ‘Pending Response’ Queue

Request ID – Definition of length of the ID.

This ID is required as receiving responses from external filter is an
asynchronous process.

Process:
1- Receive the response from external filter service
2- Match the Request ID of the response file to the Request ID’s in the
‘Pending Response’ Queue
3- Take action on the payment based on the response
4- Send all the ‘Pass’ payments to Future Due Date component

Receive response from the payment to proceed.

Payment Module will process only ‘PASS’ or ‘FAIL’ responses from the external
filter service and update the payment statuses.

Act on the response for the payment to proceed.

If ‘PASS’ is the response then the payment is fine and it can proceed to the
‘Future Due Date’ check component. The asynchronous reply can be with a
due date in the past, present or future.
E.g. Payment with due date 5th sent to filtering on 5th and reply received on 5th
– Present
Payment with due date 7th sent on 5th and reply received on 5th – Future
Payment with due date 5th sent on 5th and reply received on 7th – Past
If ‘FAIL’ then the possible actions are- (based on banks choice of operation
and investment)
Seize of funds (for USD)
This essentially means that the bank has the authority to seize the funds of the
payment and route the funds to appropriate accounts. Also this type of seize
can only be done by banks on US Dollar as the US Government requires all
questionable transacted funds to be deposited with it by banks all over the
world.
Automatic Seize – Here the filter will seize funds, change the credit party
(internal account for the purpose) and book the payment automatically.

Manual Seize – Filter sends the payment to Repair. It’s the operator’s
responsibility then to seize funds and place them in the internal account by
changing the credit party.
Once the payment releases from the repair (payment has to be identified as
Seize release) and comes to Filtering component again. Now it is being
processed without any issues.
Cancellation – Any payment with CCY other than USD will be cancelled.
Automatic Cancellation – Any Outgoing payment will be cancelled
automatically as its still within the payments module and the transaction has
not been booked.
Manual Cancellation – Any incoming or re-direct payment will be sent to
repair and cancelled. Operations then have the option of creating a new entry
through the Order Entry Screen to make return payments.
IF events are generated when the payment is sent to filtering engine.
When the payment is sent to filtering engine, the transaction is parked with
status code 602.
Once the payment is approved from filtering engine, system will continue the
filtering process.
Highlighted field is to indicate the payment has hit filtering engine and
received the approved status.
This is a sample message when a response is reject hit from Filtering engine
Payment moved to repair queue when filtering engine response is reject
Highlighted field is to indicate the payment has hit filtering engine and
received the Reject status.
Risk Filtering helps banks to monitor and control risks based on Country,
Currency and Counterparty before payment is allowed to be booked
successfully.
In the above example, risk filter checks have been configured to check:
For credit leg of the payment
In currency GBP
Arising from any message type (SWIFT, Clearing etc)
Can be a customer or a bank transfer
Provided the receiver is CITIUS33
Amount limits mentioned in USD
Each transaction can be for a maximum of 100000 USD
Maximum credit per day is 100000 EUR
Maximum credit per week is 1000000 EUR
Maximum credit per month is 10000000 EUR
Maximum number of transactions per day is 10
No cap set on number of transactions per week/month
The purpose of the Fee Determination component is to provide a very
flexible and comprehensive definition of charges (fee).

It also supports the below functionalities.

Definition and maintenance of charges for clients and correspondent

banks (sending and receiving banks)
Ability to identify the party(Debit/Credit) for which we need to apply
charges for
Ability for an operator to impose fee which will override fee configured in
the system
Ability to apply multiple charges to a payment transaction
Ability to support both conditional and unconditional charges
Ability to calculate charges while the payment is being processed
Ability to define different profit and loss accounts for each fee type
Ability to apply charges based on
Business line of customers (Group based on customer type)
A specific account and its currency which is used in payment
 transaction
Residency status of a customer
Type of payment (Internal transfer, intra company payment, outgoing
payment etc)
Various types of charges can be applied to a payment. Few are listed
below.
Transaction Fee – Charges levied by the Bank for processing the
payment
Phone Confirmation Fee – Charges taken by the Bank for making call to
the customer for the payment confirmation
Manual Repair Fee – Charges taken by the Bank to repair the payment
and process it correctly.

These charges can be classified broadly into two categories.

Unconditional – Applied in all conditions.
Conditional – Applied only under certain conditions

Charging options
All the 3 charges types namely SHA, BEN and OUR are supported by
TPS
BEN
This charging option indicates that all charges are to be borne by the
beneficiary.
SHA
This charging option indicates that charges are to be shared by the originating
and beneficiary party.
OUR
This charging option indicates that charges are to be borne by the originating
party.

Fee can be linked to transaction amount too. Low amount transactions will
attract low fees whereas high amount transactions will attract high fees.
Fixed charges – A fixed amount which will not vary with the transaction
amount.
Variable charges – As the name suggests, charges are linked to the
transaction amount as certain percentage of transaction amount is taken as
the charge amount.

Charges can be taken

By debiting the client (Debit/Credit) separately for the charges. Charges could
be debited from the main client account or a separate charge account if there
is one defined inside Client Conditions.
By debiting the client for both transaction amount and charges as a single
debit for a payment
From transaction amount, eventually leading to lesser amount towards
beneficiary.

Factors influencing Fees

Product
Combination of services offered by a bank can be packaged as a Product.
Each payment product has certain characteristics. Hence it is important for a
bank to take charges accordingly. As Product already takes into account all
these characteristics before arriving at a product, we will take Product as one
of the input to deciding the charges which gets applied to the payment.
Client Agreements
Client specific charges are defined for the specific clients or it could be defined
for a specific product & source combination, in which case it gets applied to all
the clients who don’t have specific charges defined.
Source
Charges are not applied for payments originating from certain sources or apply
preferential charges.
Business Line
Each customer belongs to a specific group which is called business line. Each
business line can have specific objective from the Fee perspective and
accordingly they want to price the charges and hence it’s very important to
take business line into account while determining the charges.
Residency Status
For most of the countries there is a VAT imposed by the government. This VAT
is levied on the payment or the charges calculated. Residency Status is used
to identify whether the customer is a resident of that country or not
PSD Compliance
In case of PSD compliance, Charges are not allowed to be taken directly from
transaction amount. Also the charges should be shared between the
originating and beneficiary party.
Charging options
All the 3 charges types namely SHA, BEN and OUR are supported by TPS

BEN
This charging option indicates that all charges are to be borne by the
beneficiary.
SHA
This charging option indicates that charges are to be shared by the originating
and beneficiary party.
OUR
This charging option indicates that charges are to be borne by the originating
party.
 Client Conditions
Debit or credit confirmation controls e.g. phone confirmation, email
confirmation, Fax confirmation
Billing flag
Non STP flag
VAT on principal amount
VAT on charges
Client Charges account – This doesn’t affect the fee calculation directly
but it affects the way charges are posted for the client.
Product Determination
Fee Product code
Source or Source group to be used in peeling off
PSD Flag
Order Entry/Repair
Manual repair performed
Charges waived or not (which could be both conditional or
unconditional)
Imposed charges
VAT imposed flag (on Principal & Charge amount)
 Client Charges
Client charges can be applied to Debit party or Credit party or both
depending upon the direction.
Incoming payment
In this case debit party is the sending bank and credit party holds an
account with us. We will be reading the client charges for the credit
party which is with us.
Outgoing payment
In this case debit party is the customer holding an account with us and
credit party is the bank. We will be reading the client charges for the
debit party in this case.
Book payment
In this case both debit and credit party holds an account with us and we
will be reading the client charges twice, once for the debit party for debit
side charges and second time for the credit party for the credit side
charges.
There could be various Fee types. We can segregate them in two categories

Conditional Fee Types – These are the Fee types which can only be applied
for a transaction if there is a particular condition which is met. E.g. Non-STP
Fee, this Fee can only be applied if the transaction has actually been
processed non-STP. If the transaction is STP then we cannot take this charge
even if it’s defined in the Client Charges table.

Unconditional Fee Types – These are the Fee types which needs to be
applied in all the cases if it’s defined for the Client e.g. Transaction Fee

Calculating Tax for Charges is same as calculation of Tax for Principal:

• Tax Id or Tax Type Id should be defined in PP.FEETYPE. We can define

different Taxes for different Fee types.

• Tax amount will be calculated separately for each fee that are defined in
PP.CLIENT.CHARGES table. So, there will be a separate record in
POR.APPLIEDFEE for each Tax.
• If same Tax defined in two or more Fee types, then total tax amount will be
calculated and stored in POR.APPLIEDFEE in a single record
30

TPH allows you to define a Fee API in PP.FEETYPE application. The API can
be defined for a conditional or an unconditional fee. This fee can be imposed
from Order Entry/Repair application also. The following features are now
available in Temenos Payments (TP) as part of this feature. You can now able
to arrive at a fee based on the custom conditions, which are defined in an API.
The defined API is linked to a fee type. The fee type can be conditional or
unconditional. The API is used only for charge calculation and cannot return
tax on the charge.
In case of Conditional Fee type, if the condition is met, then the system
calculates the fee using the API. The fee returned by the API is considered as
the final fee for that fee type. However, if the condition to trigger the fee type is
not met or the API attached to the fee type, does not return a value (returns 0);
then the specific fee is not applied on the payment.
A particular fee type for which an API has been attached to it, can be imposed
when keyed in using PP.ORDER.ENTRY application or when a payment is
being repaired. If imposed, the imposed rate is used and the API is not
invoked. Similarly, Tax on this fee type can be imposed from Order Entry as
well when the payment is repaired. If tax is imposed, the imposed value will be
used.
The charge amount returned by the API is the final charge for the fee type. No
other validations such as min charge, max charge, discount, rise and so on; is applied
on the returned fee amount. Once the API returns the fee amount in fee currency, the
system calculates the equivalent of the fee amount in local currency and charges the
account currency.
31

A particular fee type for which an API has been attached to it, can be imposed
when keyed in using PP.ORDER.ENTRY application or when a payment is
being repaired. If imposed, the imposed rate is used and the API is not
invoked. Similarly, Tax on this fee type can be imposed from Order Entry as
well when the payment is repaired. If tax is imposed, the imposed value will be
used.
The charge amount returned by the API is the final charge for the fee type. No
other validations such as min charge, max charge, discount, rise and so on; is
applied on the returned fee amount. Once the API returns the fee amount in
fee currency, the system calculates the equivalent of the fee amount in local
currency and charges the account currency.
Multiple tax feature is applicable only to the client charges. For a specific
charge, it is possible to apply multiple taxes. The system is now enabled to
setup multiple taxes on a charge type using the T24 Tax Engine only. Each of
the taxes that are to be applied are configuration driven. Tax thus calculated is
debited from the debit/credit main account depending on which side the tax is
calculated for or from a charge account (if configured).
Feature is applicable only to the client charges. It is now possible to apply tax
on tax, for the tax that is calculated on a charge. System is enabled to define
tax on tax using the T24 Tax Engine.
Each of the taxes that are to be applied are configuration driven. Tax thus calculated
is debited from the debit/credit main account depending on which side the tax is
calculated for or from a charge account (if configured)
Client Charges
There can be multiple Fee types which can be attached to a single client
charges record. These Fee types will have certain controls based on which it
will be decided if a particular charge need to be taken from this client payment
or not.

Always Apply Flag – If this flag is set to Y against a particular Fee type then
that Fee will always be taken if evaluated for a particular payment. Both
conditional and unconditional fees can be marked as ‘Always apply’.

Apply me only flag – If we encounter any fee type with this flag then only this
Fee type should be applied and rest of the fee type should be ignored except
where Always apply flag is set as Y.

Each fee type could further be linked with a formula to calculate the actual
charge; this could be a fixed charge formula or variable (percentage).

All Fee types linked with a Client charges record must have the same
currency.
The Client charges table is only read if fees module calculates the charges.
This table will not be read in case OE imposes charges.

ClientChargesFeeFormulaId: Unique Id to identify the Client Charges Fee Formula

Id. This would be a sequential number and increased by 1 for every record being
added in this table. This Id need not be available in the GUI.

ClientChargesFeeTypeId: This table is linked with the Client Charges Fee Type
Table using this field. One Client charges Fee Type Id can be linked with multiple
records in this table.
FeeTierRangeLowerLimit. This is the lower tier amount and if the transaction amount
is greater than this limit (in case of FX, converted amount) and is lesser than the next
tier (if there is any), then this record will be selected.

FixedChargeAmount: Fixed charge amount

PercentageVariableFee: In case of variable fee this will be defined as the

percentage (up to 9 decimal places)

BaseChargeAmount: Fixed positive amount which would be added to charge

amount in case of percentage charge.

ChargeDiscountAmount: Fixed positive amount which would be deducted from

charge amount in case of percentage charge.

ChargeRiseAmount: Fixed positive amount which could be added to the calculated

Fee (fixed or variable) to arrive at the final fee.

MinimumChargeAmount: Charge amount has to be equal to or greater than this

minimum charge amount.

MaximumChargeAmount: Charge amount has to be equal to or lesser than this

maximum charge amount.
PP supports processing payments in currencies other than the local currency.
Debit account currency or credit account currency need to be the same as
transaction currency. PP does not support all three to be different currencies.
(In essence - FX can happen either on the debit side or on the credit side but
not on both.)
PP fetches the FX rates from Core Banking CURRENCY table when a
payment is processed.
When FX needs to be performed on charges (Charge currency is different
from the charge account currency), then, always midrate is used to calculate
the charge amount.
To request for a new exchange rate from Treasury when the FX Threshold
Limit exceeds.
There are number of banks which may require to not to have a manual
process to enter the new rate and continue the foreign currency payment if FX
Limit exceeds the limit specified by the bank. This functionality will enable STP
by sending a request to Treasury for a new rate and process the payment with
the new rate once the response is received from Treasury. This reduces the
time delay in processing the payment and manual human error can be
avoided.
FX Threshold Limit for the Foreign currency payment can be
configured/verified at 3 different levels:
1. Company
2. Client
3. Currency
If the Rate Request is configured as STP and FX Threshold limit is breached
will be parked in a queue and request has been sent to Core Banking-
Treasury for new rate. Once the rate is received continue processing the
payment and raise entries.
Path: Payment Hub > Static Data GUI > Company Properties
Enable STP FX payment by setting Rate Request and FXRateReqCutOff
fields in the company properties table. Rate Request value of “S” will enable
STP for FX if threshold limit is breached
Set the flag in Company Properties table:
Rate Request and FXRateReqCutOff are set in the Company Properties table.
Rate Request takes a value of ‘’ or M or S.
• Send a rate request to Core Banking Treasury provided system is within
the FX rate cut off time, await rate from Treasury, use the Treasury rate
received and arrive at the amount. This is the ‘S’TP mode.
• Park the payment in the repair queue for an operator to intervene.
• Operator can then choose to impose a FX rate and continue.
• When FX rate is imposed, FX threshold check is not performed.
• System will only check if the rate is within the tolerance configured in
PP.COMPANYPROPERTIES. In this case, this process is set to be
‘M’anual.

The FX CutOff time to send the request to Treasury has been breached –
payment will be routed to Repair queue for manual intervention
Failure in Treasury on processing the sent request – payment will be routed to
Repair queue for manual intervention
Utilization of the new rate provided by Treasury – send acknowledgement to Treasury
Non-Utilization of the new rate provided by Treasury – clean up the FX related data
and process the payment as a new payment. Send acknowledgement to Treasury
Client level STP FX limit can be maintained.
Path: Payment Hub > Client Condition GUI > Client Conditions
FX Limit for the currency can be defined.
Path: Payment Hub > Static Data GUI > Currency
After a payment is successfully submitted and Authorised (no
screen/component errors left), the status of the payment is updated (and the
Order Entry flow ends) to indicate that this payment can be picked up for
further processing which will pass the payment through to the Filtering
component. Filtering is the first component in the workflow to be invoked after
the end of the STP-module followed by Fee, Posting and Payment Generation
Components.
FX Threshold limit
“FX Threshold” limit and Rate Request as STP has been set at the company
level. As payment transaction has been breached the FX Threshold limit,
during payment status has been updated with status code “645” and also
Payment has been parked under Pending FX Rate Request queue to get the
rate from Core Banking-Treasury system.
After successful completion of the rate request process from the Core
Banking-Treasury system, payment transaction status has been moved from
“645” to continue other process in order to complete the payment. This
concludes the FX rate request from TPH and obtains the rate from treasury
system.
42

When a transaction is entered into the system the relevant exchange rate for
some currencies may not be available for that day. In this case, the system
can be configured to either process the transaction with the existing rate and
record the positions; or park these transactions till the new rates are available
in the system and then process them accordingly.
43

• When the Rate Fixing is set as ‘Yes’ at the Company Properties or at the
Product Condition table and the rates are not fixed for today (the 'Fixing
Date' field in the Core CURRENCY table is less than the Current Business
Date or 'Blank'), then TP/TPH parks the transaction in a new Status code
as 'Awaiting Rate Fixing'.

• This check happens after the Threshold check for automated FX Payments
(as defined in the Company Properties). If the Debit/Credit Exchange or
Treasury Rate is imposed, or Threshold limit is breached or if the
processing date is in the Future in the Order Entry application, the Rate
Fixing check is skipped.
44

Once the new rates are loaded in the system, the TPH picks up all the
payments with the status 'Awaiting Rate Fixing' and releases them with the
new rate.
It is then posted with the default transaction dealer desk code of '00'.
If the payment ends up in Repair or in Payment Warehouse and sent again
to the start of the flow, the Rate Fixing flag is removed.
System also drops the forward position entries raised earlier. Also, an
enquiry similar to 'View and Action Parked Payments' is provided to the
operator so that the payments with status 'Awaiting Rate Fixing' can be
manually released/put to repair or cancelled.
In this lesson I described Filtering
Risks
Appling charges
Special FX