Welcome to Payments Temenos Payments Hub, Lesson 2, Static Data

Configuration.
In this lesson I am going to describe
POR tables
Static Data Configuration
Order Entry
Payment Transaction related data capture table known as “POR” Tables
which are updated by TPH during the processing considering the Static Data
maintenance and Received Message data or User Input.
• POR Table (Transaction details captured by the system)
POR tables (payment order tables)
POR.TRANSACTION
POR.SUPPLEMENTARY.INFO
POR.POSTING.AND.CONFIRMATION
POR.AGREEMENT.AND.ADVICE
POR.AUDIT.TRIAL
• There are a set of basic tables that need to be configured for payments to
be processed in TPH.
• These tables are termed as static tables and are usually the first set of
tables to be defined during an implementation.
Each company which is defined in order to participate in processing messages
via TPH will possess number of attributes. These are defined per company.
Only a company defined in PP.COMPANY can have its properties set here.
Each company needs to have a BIC, a currency, a region to which it belongs
to etc. Such properties are defined per company.

Company ID - The company ID of the company. Should be defined in

PP.COMPANY
Home Country Code - The country code of the company.
Home Currency Code - The local currency of the company
Company Region – User can define the region to which the company belongs
Company BIC- User can specify the BIC of the company
Time Zone- User can define Time zone(Area: Continent/Location:City)
applicable for a Company.
Enable FATF Reg – User can enable ‘Financial Action Task Force (FAFT)
regulation’ for payment transactions
NationalClearingSystemCode - The National Clearing code used by TPH to
derive a BIC from an IBAN.
Company ID - Mnemonic of the company as defined in COMPANY
Currency Code – Unique code of Currency name in ISO format
Country of the Currency – Unique code of Country name in ISO format
Fractional digit – Number of decimals applicable for the currency
FX Limit - Specifies the limit in the foreign currency up to which a
payment can be processed STP
Weekend Day1 – Weekly non working day in the country of currency
Weekend Day2 – Weekly 2nd non working day in the country of
currency (if applicable)
Exotic Currency- User can mark the currency as thinly traded currency.
For example:
A payment-debiting customer in EUR and with transaction currency RSD
(Defined as exotic) will enable payment to be routed to a EUR correspondent
bank.
• Region is used to differentiate between the holidays applicable for different
regions within a country during calculation of different value dates (e.g.
regions within a country can have different holidays).
• Every country needs to belong to a region.
• This is for grouping countries in a region
• Source is the place from where the message originated. Channel is the
path through which the message reached TPH or the one which gives the
message to TPH.
• All payment order in TPH must have an originating source.
• Source maintenance identifies the channel through which payment
message will be received for processing in TPH.
• Source of the payment is one of the important field that influences selection
of payment product which in turn influences fees, client agreements etc.
• Channel Name - Specifies the channel through which messages from a
source can be received.
• Source Product - Indicates the group to which the source belongs
• Source Type – User can define Source of payment for TPH as Client
channel (Payments from customer channels or IP) or Non Client channel
(Payments from Clearing) or Internal channel (Internal payment)
• Channel is the path through which the message reached TPH or the one
which gives the message to TPH.
• A message can come through a channel from various different sources
• To sum it up, a channel can be used by multiple sources.
• SWIFT Channel is used by Sources like CHATS, TARGET, CHAPS etc.,
• This table stores all the status codes that a payment might pass through
during payment processing life cycle.
• Status code details the current stage of the payment transaction. Status
codes are assigned from the beginning of the transaction till payment
completion stage and also records to status passed through the stages of
transaction.
• Payment will pass through multiple status codes during its lifecycle and
each status code indicates payment’s position and current status in the
flow. Logical end of every stage is updated with status codes (Customer
validation, Balance verification, Product determination, Filtering completion,
message generation and payment completion etc.)
• Status code ‘999’ signifies that payment is completed.
• It acts as an input or selection criteria for payment workflow to process by
subsequent and appropriate payment components for payments
completion.
• The status codes of a payment transaction are fixed and cannot be
changed. The business logic behind the GUI will validate an entered status
code against the available values. The table Status Code does not have
Start Date and End Date for a record.
Various debit and credit “Party Roles” can be defined for a payment in TPH
based on the SWIFT message tags or based on the ISO20022 message tags.
TPH will refer to Party Role table to find out the debit party role and credit
party role in a payment request during payment processing.

Quick Reference Guide for party roles.

Contains party role name, description and tag from which value will be
retrieved for the party
INSPTY
Instructing Party
50 C or L
ORDPTY
Ordering Party
50 A, F, G, H or K
SNDINS
Sending Institution
51A
ASVINS
Account Servicing Institution
52A or C
ORDINS
Ordering Institution
52A or D
SNDCBK
Sender’s Correspondent Bank
53A, B or D
RCVCBK
Receiver’s Correspondent Bank
54A, B or D
Several “Transaction Types” can be defined in TPH to denote the exact
payment flow for the payment or message. For example Credit Transfers,
Direct Debits, Credit Transfer Returns, Direct Debit Reversals, Clearing Status
Report, Resolution of Investigation among others. During the mapping
exercise for each payment message type in TPH, it can be allocated to a
specific transaction type which needs to be a valid record in the “Transaction
Type” table.
These transaction types are used in various functionalities in TPH like Product
Determination, Clearing Settings, Value dates among others.
Different Error Types are hardcoded in TPH. The system can trigger these
Error types when there is an error or warning or information during payment
processing in payment hub.
The path to navigate to ErrorTypes GUI is Admin Menu-> Payment Hub -
>Static Data GUI ->Error Types
TPH will refer to Authorisation Principle table to find out the levels of
authorization required when manually authorising a payment in TPH. This
table is looked by in the following scenarios
* Cancelling a payment from a Warehouse queue.
* Authorising a payment from Order entry screen.
* Authorising a payment from General repair queue.
* Authorising a payment from Direct Debit queue.
* Authorising a payment from Cheque Debit queue.
Main fields that can be configured in this table are
Status – User can specify payment status for which the authorization principle
record is created.
Direction – User can define the direction
(Book/Incoming/Outgoing/Redirected) of the payment message for which this
authorization principle record is created
Authorization Principle- User can define the number of Authorizations required
for a payment for 4 eye or 6 eye authorisation.
In this lesson I described POR tables
Static Data Configuration
Process Flow
Thanks for listening. Enjoy the course.