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

In this lesson I am going to describe Posting Setup

Payment Generation
In payment engine, each payment processed will result in a number of debit or
credit entries to be posted. Depending on the payment characteristics, there
may be several entries that may have to be posted to customer, Profit and
Loss, and internal position accounts etc. for a single payment. Payment
engine should prepare the entries and pass it to the General Ledger system to
be posted into respective accounts. This is achieved through Posting scheme
and Posting Interface in TPH.
If a payment doesn’t meet any of the above conditions, then the payment
cannot be booked and the processing needs to start again to determine the
correct processing date and cut-off time using a new routing/output channel as
per setup. In short, payments not meeting the above criteria will be routed to
the start of STP module.
• Build posting lines and statement lines for a payment that need to be
booked in the General Ledger.
• Once the Payment is booked, booking is final and cannot be revoked or
cancelled. The only way to reverse the booking entry is to invoke a new
transaction with reversal entries.
• Whenever we post a debit or a credit entry to the ledger then there has to
be a corresponding counter credit or debit entry to balance the posting.
• So posting is always done in a group where there must be at least 1 debit
and 1 credit entry. This is called the posting set, which consists of 2 or more
posting lines.
• Each posting line can have more information in the form of statement lines
to provide additional details specific to that transactions.
A Posting set is made of posting lines for booking the following
1. Principal Debit and Credit transaction amount (always present)
2. Debit and Credit charges (optional)
3. P&L posting for the charges (optional)
4. VAT on Principal and Charges. They in turn will have special posting
accounts. (Optional)
5. OCP Posting lines (only if enabled for the company)
Account token List
DBT_ACT - Main Debit Account
CDT_ACT - Main Credit Account
DBT_CHG_ACT - Separate Charge Account requested by the debit party. If
not present, then charge account is same as the main debit account.
CDT_CHG_ACT - Separate Charge Account requested by the Credit party.
If not present, then charge account is same as the main credit account
DBT_PL_CHG_ACT - P&L account for the debit charges and VAT.
CDT_PL_CHG_ACT - P&L account for the credit charges and VAT.
OUT_OUR_CHG_ACT - Account to be debited for Outgoing our charges
(receiving bank 71G)
Amount token list
AMT_DBT
AMT_CDT
AMT_PAY
AMT_IN_OUR
AMT_LESS_OUR
AMT_OUT_OUR
AMT_CDT_NO_REAL
AMT_PLUS_OUR
AMT_DBT_TOT_CHG
AMT_CDT_TOT_CHG
AMT_DBT_DET_CHG
 AMT_CDT_DET_CHG
AMT_DBT_LESS_VAT
AMT_CDT_LESS_VAT
AMT_DBT_CHG_VAT
AMT_CDT_CHG_VAT
AMT_DBT_PRN_VAT
AMT_CDT_PRN_VAT
AMT_DBT_TOT_VAT
AMT_CDT_TOT_VAT
AMT_DBT_OUT_OUR_CHG
Date Account List
Credit_Value_Date
Debit_Value_Date
Post_Date
Exposure_Date
Building of Posting Lines

For the selected Posting Set ID, all the posting lines must be retrieved from
the Posting Line Table.

Booking Codes & SWIFT Transaction Type Codes

DebitBookCode
CreditBookCode
DebitChargeBookCode
CreditChargeBookCode
DebitVATBookCode
CreditVATBookCode

SWIFT Transaction Type Codes – These are the codes which will be used
for MT940 reporting.
• Channel cut off validation
Posting cannot book a payment if it’s being received after the cut-off time –
routed to start of STP
• Selection of Posting Set
The Company Code and the Posting product defined in this table must
match with company code and Posting product fields set in the payment file.
Along with the Posting Set ID, OCP Posting Flag output field should also be
retrieved. If the value of this flag is ‘Y’ then automated Open Currency
Postings must be generated for this posting set.

• Balance Local Currency Posting

Each Posting Line contains the local currency equivalent of the Posting
amount for that account (DebitMainAmountHome, CreditMainAmountHome).
The sum of the debit side postings in local currency must be equal to the
sum of the credit side posting in local currency.

• Selection of Statement format Name

Each Posting line will have a set of statement lines associated with it,
identified by statement format name.

• Informational charges

In certain cases Fee component will calculate the charges but set them as
informational charge.
Client has opted for billing instead of immediate charging, which means that we
will not book the charges immediately to the client account. These charges are billed
to client periodically (outside payment engine)
In case of Inbound/Redirect payment with Our charge option, we may receive
insufficient charges to cover our cost. In such cases we cannot book the complete
charges immediately but we may send a claim request(MT191) towards the sending
bank for insufficient charges.
When the payment engine has successfully processed and booked the
payment transaction in the DDA; final and very important part of the payment
flow is to send the messages out to the corresponding banks in case of
outbound payments, generate confirmations (if applicable) to the Debit/Credit
Banks & Customers involved in the payment and mark the payment as
complete once all the processing steps are complete. This is achieved by
Payment Generation.

Outbound message sent to corresponding bank can be an instruction to pay a

Customer/Bank or it can be a request to pay charges incurred when
processing a payment.
There are a number of approaches to convey payment instructions. Examples
are: SWIFT, Local Clearing etc

Confirmations are informational message (MT900/MT910) sent to

corresponding Banks that indicate that an account held with the processing
Bank has been debited or credited.
The information can take the form of
- An instruction to pay a customer/bank or
- An informational message to indicate the debit/credit of an account or
- A request to pay the charges for a processed payment.
Credit Transfer Message:
- A Credit transfer message would require the generation of a
message of type MT103, MT202 or MT202COV.
Confirmation Message:
- A Confirmation message would require the generation of a
message of type MT900 or MT910.
Request for Charge Message:
- A Request for charges message would require the generation
of a message of type MT191. The request for charges can also be sent
through with / without one / many free format messages – MT199.
In case of positive acknowledgement Ack Code is updated as 0 in PSM.BLOB
In case of negative acknowledgement Ack Code is updated as 1 in
PSM.BLOB
Status Code is incremented to 689

Payment Generation will picks up the records with status code as 689 and call
Swift Out with Service Name as ‘PAYMENT’.
If the Ack Code is 0 then Payment Generation service changes the status
code to 999 and mark the payment as completed.
If the Ack Code is 1 then Payment Generation service changes the status
code to 691.

Swift Out will read PSM.BLOB and get the Ack Code.

SWIFT ACK/NACK can be received by TPH with the following configuration:

Link the API DE.ALLIANCE.IN to the DE.INTERFACE table with ID as
MODEL. This will ensure that the incoming SWIFT ACK/NACK messages are
routed to TPH via Delivery IN.IF.ROUTINE. The IN.IF.ROUTINE will interpret
the messages and branch to TPH or Core Banking accordingly.
Processing an ACK/NACK
Process an ACK for an Outgoing payment using tSS SWIFTIN.
Run the Service DE.INTERFACE.UPDATE
Processing SWIFT ACK by executing tRun tSS SWIFTIN
Run the service SWIFT.OUT.LISTENER
The ACK indicator in the table PSM.BLOB is updated with the value 0
The Payment is picked up by Single Sub Flow Service
(PAYMENT.STPFLOW.HEAVY) and gets Updated to Status 999.Payment is
Complete.
When outgoing payments are sent from TPH to SAA, for some payments,
TPH does not receive an ACK or NACK. It might be due to the following
reasons:
• Rejected in SAA because of GFS filtering
• Payment sent from TPH do not reach SAA because of issues in MQ
• ACK sent from SAA do not reach TPH because of issues in MQ
In this lesson I described Posting Setup
Payment Generation
Core Banking Bank – Account with Institution / Beneficiary Customer
TPH – Payment Processing company / Branch
MT101 resulting in MT103 Generation
Incoming message received from SWIFT channel
1. Message is received in TPH
2. BNK/SWIFT.IN service interprets the SWIFT message to accept and maps
the message details into POR tables
Using menu option “Payment Hub -> Received Files, selected message’s
“view BLOB message” option can be used to check the received message
details.
Received Message has been mapped to the neutral format and Payment
transaction created.

Created Payment transaction current status and other details can be viewed
using “Pending and Processed Payments”.
POR table updates when message is mapped into TPH. Relevant debit and
credit parties are updated in POR.PARTYDEBIT and POR.PARTYCREDIT
respectively
Status 687 indicates that payment has been successfully processed and
message has been sent to SWIFT and awaits for ACK message from SWIFT.

Path: Payment Hub > Inquiry and Queue Management > Pending and
Process Payments > Pending and Processed Payments.
Specific Weight is assigned to the payment and weight is determined as
“Heavy Weight”
If a debit authority check is not skipped based on the conditions, debit
authority component must be able to trigger specific Debit Authority

The payment
version based on the payment weight.

needs to be validated against the

netting agreement.

Path: Payment Hub > Debit

Authority > Netting Agreement List
As incoming MT101 results in an Outgoing MT103, Direction for the Payment
is determined as O.

Product is determined for the payment based on Input parameters and output
parameters are arrived at which will be used for further payment processing
Routing and Settlement identifies the contract to be used for the payment,
arrives at the RS Option based on reachability check/ channel validations and
identifies credit account from PPL.LoroNostroAccount table.
Routing Product should be set on the basis of the list of Routing Products set
by Product Determination or * (Default is *).
Routing Contract – PTY, CTY, BNK specific maintenance varies depends on
the Business Line and Routing product
Routing Contract Category – Currency, SLA specific maintenance, Amount
and Charge bearer options perspective
Routing Options – Credit Account determination and depends on Serial or
Cover method.
All dates calculated for the payment are stored
Skip further processing based on weight

Path: Payment Hub > Static Data GUI > Programs Per Weight

This table stores the weight based components that will be invoked for a
payment with a specific weight and high level weight.
Every weight based component will look up this table to decide whether the
component must be executed for the payment or not. If yes, it will invoke the
program that is mentioned in this table. A component can have different
programs based on weights.

In this example, Filtering component is skipped for the weight code and audit
trail is updated accordingly.
ClientCharges are defined for Debit Side as 5USD for the payment and the
same are calculated by Fee Determination Component and included in the
Posting lines as per the Posting Set defined
Outgoing Message generated for the payment is stored is updated in
PSM.BLOB table
All events for the payment processing are logged and can be viewed in Audit
Trail