Welcome to Payments Temenos Payments Hub, Lesson 12, Clearing

Framework » Part 2.
In this lesson I am going to describe
Credit Transfer
Payments system can receive/accept/interpret and map a Pain.001 XML
message or other CTIs received from customer or indirect participant.
Furthermore, the payment system can differentiate a batch from a bulk.
Payments flow through a separate STP return process based on the fields set
in clearing setting for the clearing. Also based on client conditions, trigger can
be initiated for generating customer status report for the outgoing CTI.
Credit Transfer Initiation - CT - Receive and Execute Customer to Bank credit
transfer payment orders.
Payment Order will executed if there is sufficient funds in the debtor account
and the payment is within the cut-off time and can be routed through a
Correspondent or Clearing. If payment is after the cut-off time, then the
payment can be warehoused, routed through the next available channel or
moved to Repair for operator action.
Payments that are finalised successfully, will be forwarded to the Clearing in
pacs.008 format or any other supported native clearing format.
Settlement entries will be raised when credit transfers are forwarded to the
Clearing.

Credit Transfer – CT - Process Bank to Bank payment orders to credit a

beneficiary in the books of the processing bank.

Credit Transfer Return – RT - Payment Return is an instruction to return a

credit transfer payment order which was previously settled.
Payment Hub can support both inbound and outbound payment returns.
Inbound Payment returns will identify the original Credit Transfer transaction
and credit the debtor/originator of the payment.
Outbound payment returns are processed and sent to the Clearing, when an incoming
Credit transfer cannot be processed (example when Beneficiary cannot be
determined) successfully.

Credit Transfer Cancellation Request – CR - Payment Cancellation request is a recall

of a payment requesting cancellation of the original payment instruction. It is a non-
value investigation message and can result in a Payment Return, if accepted or
Resolution of Investigation (ROI), if rejected.
Payment Hub can support initiation of outbound Payment cancellation requests for
Credit Transfer Payment orders executed and send to the Clearing.
It can also support receipt of Payment Cancellation requests for Credit Transfer
Payment Orders received and processed previously. Based on the business rules
configured, the cancellation request can be resolved with a “Credit Transfer Return
Payment” or rejected with a “Resolution of Investigation”

Resolution of Investigation – RI - Payment Hub supports Resolution of Investigation

which results in a “Rejection” (Negative confirmation) of the “Credit Transfer
Cancellation Request”. It is sent by the assignee (bank receiving the cancellation
request) to the assignor (bank sending the cancellation request).
Payment hub can support sending of the negative confirmation for a payment
cancellation request received. It can also support receipt of an ROI with a
“REJECTED” status and update the “Payment Cancellation Request” as resolved with
a rejection.

Clearing Status Report - Receive Clearing Status Report message sent by the
Clearing/Instructed agent, update the status of payment and trigger appropriate
business workflow to handle positive and negative confirmations. Positive
confirmations will update the payment status as completed and negative
confirmations will trigger exception handling and route the payments to a queue for
operator action or automatically reverse the entries.

Rejection – RJ - Negative confirmations received from a Clearing will result in a

Rejection of a Credit Transfer that was sent previously. System will provide ability to
the debtor bank to mark the original Credit Transfer payments as returned and
generate new payment orders which will reverse the earlier postings. Such reversal
payments can be generated automatically through configuration or manually by an
operator.
Customer Status Report - Customer Payment Status Reports are used to inform the
initiating party of a payment instruction (either single or file) about the positive or
negative status of an instruction. It can also be used to report status of pending
payment instructions.
Customer Credit Transfer initiation is a message sent by the initiating
party (acting on behalf of the debtor) or debtor (ordering customer) to
the debtor agent (bank) to request movement of funds from the debtor
account to a creditor (beneficiary).
Accept/Reject Payment Order
Payment Orders can be received from the following sources –
Temenos Front Office/Channels - through PAYMENT.ORDER
application
Temenos Applications (Standing Order, AA Deposits, Loans, etc) –
through PAYMENT.ORDER application
External Channels – through ISO pain.001 message format or TPH
generic (internal) format for the event/transaction type
Payment received in pain.001 format or TPH internal format is
transformed, debulked, validated and mapped to the TPH Payment
order for processing.
Inward Framework of TPH is responsible for handling the acceptance
and mapping of files and payment messages.
Validate Payment
In this stage of the workflow, following validations will be carried out –
Check if there is sufficient authorisation to debit the Ordering Customer
[DebitAuthority]
Debit account is valid – account is not missing, closed or inactive
Check if the payment is “On-Us” and accordingly mark the direction of the
payment as Book or Outgoing
Determine (Invoke Product Determination – Heavy, Medium or Light) and
arrive at the payment products which will be used to determine Routing
Channel, calculate fees and book the payment. Medium Weight Product table
is additionally introduced as part of the Clearing Framework to support clearing
business events.

Finalise Routing/Clearing
In this stage, the following is handled –
Routing channel is selected based on Routing Product and the Contracts
setup in TPH Routing tables
Reachability check for the Clearing Channel is invoked.
Once it is confirmed that the beneficiary bank is reachable directly or through
an intermediary (Direct participant bank), channel validations are invoked.
Channel validations are configurable per Clearing.
Once channel validations are successful, the payment route/channel is
finalised.
Dates are calculated
If payment route cannot be finalised, the system tries the next available routing
options (driven by configuration) and if none of the options are successful,
then the system raises an exception, which will be handled when the payment
is evaluated for approval.
Approve or Reject the payment
Finalisation of the payment is done at this stage. Payment is checked for
duplicates, screened against sanctions list, fees and FX is calculated and
funds are reserved on the account. If the payment had failed in any of the
validations earlier in the workflow or while performing the checks described
here, a few actions are possible –
Force payment to Manual Repair queue for an operator to repair the payment
or cancel manually
Automatically cancel the payment
 Book Payment
When the payment is successfully finalised, accounting entries are generated,
as per the posting rules applicable for the payment. Posting/Booking rules are
configurable in the system
Clear and Settle
For outgoing payments, clearing and settlement is performed at this stage.
Outgoing payment message is generated for single (RTGS) payments if “Send
Date” of the payment matches the processing date.
For ACH payments, which need to batched and sent, payments will be parked
in “Waiting Clearing” (706) status, until the Cut-off time for forwarding the file to
the Clearing, is reached.
Outward Clearing Framework is responsible for handling outgoing payments to
the Clearing. It is used to manage the sending of outward payment files to the
clearing and generation of the settlement entries.
When a bank receives a Customer Credit Transfer from the clearing, it
is either the creditor agent or acting as an intermediary bank for the
creditor agent. When it is the creditor agent, the payment is an
incoming payment and funds are credited to the Beneficiary/Creditor.
When it is an intermediary, then it I is a redirect payment and it is
forwarded to the creditor agent bank. Redirection is currently supported
only for ‘Instant’ payments.
Credit Transfers
Credit Transfers can be received from RTGS and ACH clearings.
Payment received in pacs.008 format or TPH internal format is
transformed, debulked, validated and mapped to the TPH Credit
Transfer business event/transaction for processing.
Inward Framework of TPH is responsible for handling the acceptance
and mapping of files and payment messages.
Settlement transaction is also mapped during this stage for Bulks
received from the Clearing. For incoming payments from the Clearing,
system decides if settlement booking is required or not, based on the
c o n f i g u r a t i o n i n “ P P. C L E A R I N G . S E T T I N G ” f i e l d
“SettlementBookingIndicator”. When this field holds the value “Y”, then
settlement entry is raised for ACH/SEPA batch payments received from the
Clearing.
Validate Payment
In this stage of the workflow, following validations will be carried out –
Check if the payment is “On-Us” and accordingly mark the direction of the
payment as Incoming, otherwise Redirect*
Check if Debit/Credit accounts are valid – account is not missing, closed or
inactive
Determine (Invoke Product Determination – Heavy, Medium or Light) and
arrive at the payment products which will be used to determine Routing
Channel, calculate fees and book the payment. Incoming Clearing payments
are assigned “Light Weight” (configurable in PP.SPECIFIC.WEIGHT)
Calculate Dates (Debit, Credit Value Date) for incoming payments
*Redirection of batch payments by Intermediary banks is currently not
supported. Future Roadmap
Finalise Routing (Redirect)

In this stage, the following is handled for Redirected single payments–

Routing channel is selected based on Routing Product and the Contracts
setup in TPH Routing tables
Reachability check for the Clearing Channel is invoked.
Once it is confirmed that the beneficiary bank is reachable directly or through
an intermediary (Direct participant bank), channel validations are invoked.
Channel validations are configurable per Clearing.
Once channel validations are successful, the payment route/channel is
finalised.
Dates are calculated for redirect payments.
If payment route cannot be finalised, the system tries the next available routing
options (driven by configuration) and if none of the options are successful,
then the system raises an exception, which will be handled when the payment
is evaluated for approval.

Approve/Reject Payment
Finalisation of the payment is done at this stage. Payment is checked for
duplicates, screened against sanctions list, fees and FX is calculated. If the
payment had failed in any of the validations earlier in the workflow or while
performing the checks described here, a few actions are possible –
Force payment to Manual Repair queue for an operator to repair the payment
or return payment manually
Automatically return the payment
Book Payment
When the payment is successfully finalised, accounting entries are generated,
as per the posting rules applicable for the payment. Posting/Booking rules are
configurable in the system.
Clear and Settle
For redirect payments, clearing and settlement is performed at this stage.
Outgoing payment message is generated for single (RTGS) payments if “Send
Date” of the payment matches the processing date.
For ACH payments, which need to batched and sent, payments will be parked
in “Waiting Clearing” (706) status, until the Cut-off time for forwarding the file to
the Clearing, is reached.
Outward Clearing Framework is responsible for handling outgoing payments to
the Clearing. It is used to manage the sending of outward payment files to the
clearing and generation of the settlement entries.
Clearing Accounts for settlement entries can be configured in
PP.CLEARING.SETTING.
Credit Transfers are already pre-settled and booked by instructing and
instructed banks. Credit Transfers can be returned for the following
reasons –
Credit transfer cannot be executed successfully due to any
exceptions such as missing/invalid Beneficiary Account, account block,
restrictions prohibiting credit to the account, then the payment needs to
be returned by the instructed/receiving bank.
Cancellation Request received for a Credit Transfer and is
accepted.
Credit Transfers mentioned above, can be returned manually by an
operator or automatically by the system based on business rules
configured in the system. Returns which are successful, result in refund
of funds to the original debtor, less bank charges, if any.
Map Return Payment Order
In the first stage, when a payment is returned, system will create a new
Return payment, by mapping the information present in the original
payment that is being returned.
A Return transaction is created in the system based on the details of the
original transaction:
The Beneficiary party becomes the Ordering Party of the original transaction
The Ordering party becomes the Beneficiary party of the original transaction
The debit main account will be the Return suspense account related to the
originating clearing, currency and incoming message type
The credit main account will be the outward suspense account related to the
originating channel
Furthermore, the payment details (additional information) must indicate that it
is a return transaction.
The following additional values will be mapped to skip determination of
Direction and Routing Channel –
Output Channel – Mapped from Originating Source (Clearing) of the Credit
Transfer
Output Channel Imposed Flag – Y (This is set to yes, as the payment is
returned back to the same Source/Clearing from which it was received)
Own Account Indicator – N (This means that the payment is “Off Us”)
Direction – Mapped as “O” (Outgoing)
Original credit transfer payment is updated with the business state “Completed
with Return” (996).
Validate Payment Order
In this stage of the workflow, following validations will be carried out –
Debit account is valid – account is not missing, closed or inactive
Determine (Invoke Product Determination – Light) and arrive at the payment
products which will be used to calculate fees and book the payment.
Finalise Routing
In this stage, the following is handled –
Reachability check for the Imposed Clearing Channel is invoked.
Once it is confirmed that the beneficiary bank is reachable directly or through
an intermediary (Direct participant bank), channel validations are invoked.
Channel validations are configurable per Clearing.
Once channel validations are successful, the payment route/channel is
finalised.
Dates are calculated
If payment route cannot be finalised, then system routes the payment to
Repair for manual action. [Note- Normally no exceptions are expected at this
stage, the payment is returned back to the original source/channel from which
it was received.]

Approve or Reject Payment

Finalisation of the payment is done at this stage. Payment is checked for

duplicates and checked if it is within the allowed period for a Return. Allowed
period is arrived at by adding the “Return Period” (AcceptanceDays in
PP.CLEARING.SETTING) with original settlement date of the Credit Transfer.
Further, payments are screened against Sanctions list, Fees and FX is
calculated.
If the payment fails in any of the validations earlier in the workflow or while
performing the checks described here, payment will be moved to Manual
Repair queue for an operator to repair and return the payment manually.
Book Payment
When the payment is successfully finalised, accounting entries are generated,
as per the posting rules applicable for the payment. Posting/Booking rules are
configurable in the system.
Clear and Settle

For outgoing return payments, clearing and settlement is performed at this

stage.
Outgoing return payment message is generated for single (RTGS) payments if
“Send Date” of the payment matches the processing date.
For ACH return payments, which need to batched and sent, payments will be
parked in “Waiting Clearing” (706) status, until the Cut-off time for forwarding
the file to the Clearing, is reached.
Outward Clearing Framework is responsible for handling outgoing return
payments to the Clearing. It is used to manage the sending of outward
payment files to the clearing and generation of the settlement entries.
In this lesson I described Outward Framework
Credit Transfer
This workshop is to process Pain001 message via STEP2. This explains the
movement of funds from the customer to beneficiary via Instant channel.

Prerequisite

Instructions:
Install IIB software / Configure
Non ESB folders
Deploy BAR file / Configure Non
ESB folders
Place the message in
InstantInput folder
 IIB/Non ESB service picks up the
messages and push into TPH for
processing – All failed messages are
moved to mqsibackout queue
View Payment details
View Payment details
View Audit Trial