1

2
End of Day 1 – Learning objectives will be met.

3
SCOPE: TPH Clearing Framework business processes, transactions, rules for execution
and related messages for Credit Transfers, Direct Debits and Reversals from Customer
to Bank and between banks across an automated clearing house (ACH) and real time
gross settlement systems (RTGS).

Inward Framework – Framework to accept both XML and non XML messages. It is
also capable of accepting both bulk and single messages. It can be used with IIB as
the ESB, any other ESB other than IIB as well as without IIB.

Generic local clearing payment processing – Based on highly flexible configuration

process local clearing payments end to end. Can process both credit transfers as well
as direct debits including returns, refunds, reversals etc.

Outward Framework – Raise settlement entries and in-charge of outward file

generation.

4
Inward Clearing Framework is responsible for receiving and mapping payment
messages/files in ISO20022 message format or in the payment hub format. It
supports the following functionality –

Validate ISO20022 message against the Schema (XSD) and reject the message/file, if
it is invalid. Rejected file/message details will be recorded in TPH in
PPT.RECEIVEDFILEDETAILS with “REJECTED” status, along with the reason for
rejection.
Transform ISO20022 or other XML file to TPH internal format in the ESB. Provide
ability to accept and process any proprietary message formats of the bank.
Proprietary formats need to be transformed into ISO20022 or TPH internal format,
before they are fed to the Message Transformation service in the ESB.
Identify incoming business event/transaction type and invoke appropriate business
workflow. Default the “ClearingTransactionType” attribute based on the incoming
business event/transaction type.

5
XSD Validation - ISO published XSDs
pain.001,pain.008,pain.007,pacs.003,pacs.008,pacs.004,pacs.007,pacs.002,camt.056,
camt.029
XSLT Transformation – Transform to generic schema. Queue name is hardcoded at
this juncture. One queue per message
Check sum validation - Done only for pain.001 and pain.008 messages. This is
skipped for INST payments as they are single message. Skipping is done based on
queue name.
Debulk file – Debulk into single transactions. Each transaction will contain the file and
bulk header along with transaction information. Bulk number and transaction number
are assigned at this juncture.
Once debulked, messages are posted into a JMS queue from where it is consumed by
the OFS layer.

6
When a file is received by the payments hub, system provides flexibility to send an
ACKnowledgement or a Negative ACKnowledgement to the sender of the file.
This is configuration driven.
Configuration in PP.MSGACCEPTANCEPARAM defines the API to be used to send
ACK/NACK at file level.

7
• Perform additional validations for messages received by invoking a Validation API
attached to the Channel (Queue name) in PP.MSG.ACCEPTANCE.PARAM.
• Perform duplicate check based on Unique File Reference [Future Roadmap – To
provide ability to perform flexible Technical Duplicate check based on additional
attributes in the file/message]
• Accept or reject the file based on the above validations.

8
System does File Validations using this calculation.

9
System does Bulk Validations using this calculation.

10
File will have status REPAIR when

1. Underlying configuration data record – PP.MSGACCEPTANCEPARAM is not

available
2. Receiver BIC is present in the XML file, but based on the receiver BIC, company
could not be determined. Receiver BIC would always be the BIC of the process
company. If the Receiver BIC is Incorrect, then, file cannot be processed there on.
3. In case a file or bulk has the status ‘Repair’ then the file or individual bulk can be
resubmitted from the File / Received messages GUI. This should be done after the
configuration problem is solved in the system.

11
TPH supports processing of bulk payments otherwise called batch payments. This
framework enables handling of
Single debit and multiple credits (Credit Transfer Batches)
Single credit and multiple debits (Direct Debit Batches)
Each batch consists of a parent transaction and one or more child transactions.

12
All transactions are staged in a staging table named PP.BATCHFILESTORE. It is from
this table that the parent is released first for processing.
In case of a credit transfer batch, the account belonging to the parent is the one to be
debited. Hence, system will perform balance reservation on the account (If
configured to do so). In case of a direct debit batch, balance reservation is not
required.
When processing a batch, it is possible for some of the child transactions to be ‘Book’
payments and some to be ‘Outgoing’ payments. Hence, it could be required to charge
a separate fee per transaction. This fee per transaction could also differ based on the
country/party to which the payment is being sent to. To enable this process, the
batch processing framework allows the following
Payments are staged in PP.BATCHFILESTORE
Parent is released and processed first and parked in 637
Children are released and processed
Once children cross fee calculation, parent is released
Children
Get parked in status 706 (Awaiting settlement) if they are to be sent via Clearing
Get sent out as SWIFT messages (If they are non local-clearing messages)
Get book and status moves to 999 if they are BOOK payments.
Fee for the children are calculated and recorded as informational fee
Parent’s fee is calculated. Informational fee is now transformed as real fee for the
parent and is debited from the parent. Parent completes processing and is set to

13
status 999 (As it is a book payment)
In certain cases, it would be required to charge a fee per batch (A fixed fee
irrespective of the number of transactions in a batch) or a fee based on number of
transactions in a batch (Irrespective of the type of transaction). To enable this, the
batch processing framework allows the following
Payments are staged in PP.BATCHFILESTORE
Parent is released and processed until payment finalisation in the STP process
Children are released
Children
Get parked in status 706 (Awaiting settlement) if they are to be sent via Clearing
Get sent out as SWIFT messages (If they are non local clearing messages)
Get book and status moves to 999 if they are BOOK payments.
Parent’s fee is calculated and parent completes processing and is set to status 999 (As
it is a book payment)

13
14
15
2nd screen print shows the de-bulked message.

This salary batch has 1 parent and 3 children

For two of the children – Beneficiary is not in out books. So, it will be an outgoing
payment and henec a SWIFT 103 will be generated.

16
17
Status 4 – Message Mapped

18
1. Screen print 1 - Children mapped
2. Screen print 2 – Children mapped and ready for Weight

19
20
21
22
23
24
25
26
27
28
29
30
FeeDeterminationService started and parent resumed.

31
Parent complete

32
33
Approve the request for funds and show overrides raised by the DDA

34
Authorise the request for funds

35
XSD Validation - ISO published XSDs
pain.001,pain.008,pain.007,pacs.003,pacs.008,pacs.004,pacs.007,pacs.002,camt.056,
camt.029
XSLT Transformation – Transform to generic schema. Queue name is hardcoded at
this juncture. One queue per message
Check sum validation - Done only for pain.001 and pain.008 messages. This is
skipped for INST payments as they are single message. Skipping is done based on
queue name.
Debulk file – Debulk into single transactions. Each transaction will contain the file and
bulk header along with transaction information. Bulk number and transaction number
are assigned at this juncture.
Once debulked, messages are posted into a JMS queue from where it is consumed by
the OFS layer.

36
Settlement Type – Type of settlement with the clearing house. All credit transfers are
always pre-settled.
A Settlement transaction is created only if the SettlementBookingIndicator is
configured in the Clearing Setting table for the respective clearing, message type
(bulk format) and clearing transaction type.
If SettlementBookingIndicator = Y or L then a clearing settlement transaction is
created (for value L a pending settlement transaction is created, which will be
executed on the settlement date).

The settlement transaction is created based on the information provided as part of

the file and bulk level information of the TPH generic format, such as the total bulk
amount, bulk currency and the BulkSchemeIndicator indicator.

37
38
This is the master table that list all the clearings (incoming and outgoing) that will be
used in in the payment system. Every clearing must have a record in this table. Even
clearings that are settled through SWIFT channel must be configured in this table (e.g.
CHATS, TARGET2 etc.)
• Company ID - The company to which the configuration belongs to
• Clearing Currency - The currency in which the payments can be cleared. This can
be multiple as well (In Hong Kong, 4 currencies are supported as part of the local
clearing)
• Clearing Country Code - The country of the clearing
• Clearing Name - Name of the clearing – This is just free text description
• File Transaction Indicator - Whether the clearing is a file based/bulk (F) clearing or
a Transaction/single (T) type of clearing
• RTGS Indicator - Whether the clearing is a RTGS based clearing (Y – RTGS based
clearing. N or Blank if it is not a RTGS based clearing
• RMA Check - Whether RMA check is required for messages. This could be required
for SWIFT format based clearings like TARGET2
• Bulking Criteria API - API to be used to bulk payments when settling with the
clearing house. Used only for file based clearings. These APIs are only released by
Product and cannot be user defined.
• File Generation Required - Whether an outgoing file to clearing is to be generated
by TPH or outside (example Country layer). If outgoing file generation is handled in
the country layer this would be set to ‘N’

39
• Max Tx/Bulk - Maximum number of transactions that can be placed in a bulk.
Applicable only or file based clearings
• Max Bulks/File - Maximum number of bulks that can be placed in a file. Applicable
only or file based clearings
• Max Files/Cycle - Maximum number of file that can be generated per clearing
cycle. Applicable only or file based clearings
• Physical File Name API – API to be used to determine the name of the file to be
generated. If no API is defined, the file reference generated would become the file
name.
• Mandate Validation API - API to be invoked to perform Direct Debit mandate
validations for the Clearing.

39
This table stores the configuration details about the clearings that will be used in
various steps of the processing flow which will influence the way the clearing
payment must be processed (accounts to be used, time of settlement creation,
possible messages types, manual verification, Settlement Cycle (shift) etc.)
Holds various information about the clearing such as -
• Company - Company to which the configuration belongs to
• Clearing ID - Clearing to which the configuration belongs to
• Currency - Currency of the clearing
• Clearing Nature Code - If you wish to have specific behaviour based on clearing
nature code, specify the clearing nature code. Else, can be set to *
• Clearing Transaction Type - If you wish to have specific behaviour based on clearing
transaction type, specify the clearing transaction type (CT,DD,RF etc). Else, can be
set to *
• Message Direction indicates
S – Send messages to clearing
R – Receive messages from clearing
If you wish to configure different suspense accounts for incoming and outgoing
payments, this can be used.
• Message Payment Type - If you wish to have specific behaviour based on message
type - like different suspense accounts for incoming and outgoing payments, this
can be used.
• Clearing Account Company, Clearing Account Number, Clearing Account Currency –

40
 Define the NOSTRO account with the clearing
• Suspense Account Company, Suspense Account Number, Suspense Account
Currency – Define the suspense that needs to be used while booking. This is used
for file based clearings. For instance when a credit bulk is processed,
• When the parent transaction is processed, the ordering party is debited and the
suspense account defined in PP.BATCHSUSPENSE is credited.
• When a child transaction is processed, the suspense account defined in
PP.BATCHSUSPENSE is debited and this suspense account is credited.
• Settlement Booking Indicator – To be set to ‘Y’, when net settlement is required. To
be set to Y for file based clearings. This will ensure that all child transactions
(which are outgoing) to be parked in status 706. At a scheduled time, based on the
clearing cut off, a time scheduled process will perform the settlement with the
clearing house and move these payments to their end status.
• Manual Verification Required – To be set to ‘Y’ only for incoming direct debit
payments where mandate verification is manual. Currently used by incoming direct
debits from BACS.
• Validation required – If set to ‘Y’, validations would be performed on the payment.
Validations are controlled by product and an API is attached to perform the same.
Related API should be configured. Validate API – API for validations to be
performed on the clearing payment.
• Automated return – When an incoming debit, credit or return comes to TPH, if it
contains incorrect information to process the payment, then, if this field is set to
‘Y’, the incoming payment will get automatically returned. Meaning, original
incoming payment will move to status “Completed with Return”(996) and a new
return payment will be created in status 4. This new payment will get processed
and will get parked in status 706 for settlement.
• Create return booking – Indicator that defines if the payment needs to be booked
to a return suspense account. In a post settlement clearing like SEPA, for direct
debits, when a direct debit is returned, a return message needs to be sent but
booking should not happen. Set this to ‘N’, when you do not want a return booking
to happen on a return message at the time of processing the outgoing return
message.
• Create return message - Specifies if a return message can be generated for a
clearing. If a clearing does not support return messages, set this to ‘N’
• Return Account Company, Return Account Number, Return Account Currency -
Define the suspense accounts to be used while booking return messages.
• Create reject message indicator - Create a reject message. Applicable for post
settlement clearings and clearings that support reject.
SEPA SCT : N
SEPA SDD : Y
• Acceptance days - Number of days before which the payment must be returned
if it supports return

40
41
The clearing nature code table holds the various payment products types that are
possible through a file based clearing .Clearing nature codes is an input to light
weight product determination. Based on the product, different client charges, client
agreements can be set up for the clearing product.
Example: Based on client requirement, cheque return payment in cheque credit file
may be required to be processed Non- STP (manual intervention) whereas cheque
credits in the file need to be processed STP.
For a file based clearing, clearing nature code is set in the payment order during
mapping process. Clearing payments from same clearing having same message
payment type can be differentiated based on clearing nature code (sub product type)
thereby influencing payment processing.
Example: For Direct Debit payments from BACS clearing, clearing nature code
indicates if it is Direct Debit First Collection, Direct Debit Last Collection, Cheque
Debit, Cheque Credit, Returned cheque etc.

42
This table is used to setup a participant to a clearing in the generic clearing directory.

Bic Code: This is the unique BIC related to the institution from the BIC Directory.
Receiver: BIC to be used in the header of the SWIFT message.
Account Holder : BIC identifying the settlement bank.
InstitutionName : Participant’s company name.
CityHeading: Participant’s establishment.
Participation Type: This field specifies the type of participation by the participants.
DP – Direct Participant IP – Indirect Participant
NationalClearingCode : The National identifier of the institution/branch.
CT Reachability: Defines the reachability for Credit Transfers
DD Reachability: Defines the reachability for Direct Debit Transfers
FastDD Reachability: Defines the reachability for CORE Direct Debit Transfers
B2B Reachability: Defines the reachability for B2B Direct Debit Transfers
Override through Upload: This field indicates if this directory can be uploaded or not

43
Automated Cancel Indicator : AutomatedCancelIndicator to “Y”, to cancel the
payment automatically, when the payment cannot be processed due to errors, such
as missing account, invalid debit authorisation, etc. If STP cancellation is not
configured, system will move the payment to Repair queue for manual exception
handling.
Maximum Hold Days: How many days in advance (for a DDI), can a collection be sent
out.
When payment is received from client, if it is not within max allowed days, if more
than the max allowed days, warehouse.
When calculating send date, check this field. Based on this arrive at send date. (DVD -
Max allowed days send date)

44
It supports the following Functionalities:
Flexible Bulking/Batching of Payments
Generation of Payment files at Clearing Cut-off
Settlement Entry generation

45
46
47
48
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.

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

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

50
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

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

51
52
53
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 configuration in “PP.CLEARING.SETTING”
field “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*

54
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

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

54
55
56
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

57
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

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

57
58
Workshop – Process an incoming 103

59
Select TPS_BROKER, right click and press Start to start the Broker.

60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
Workshop – Process an incoming PACS 008 from STEP2

76
Select TPS_BROKER, right click and press Start to start the Broker.

77
78
79
80
Currently in this Model Bank Version viewing the status of the file in PP.INPUT.FILE,
but in future check the status of the file in PPT.RECEIVEDFILEDETAILS.

81
Two transactions are created
• Settlement transaction
• Incoming Payment

82
83
84
85
86
87
88
89
90
91