Introduction to Static Data
Temenos Payments module uses the following static data records for end-to-end processing of the payments received from customers, payment channels, PAYMENT.ORDER (PO) application or bank channels.
Company Properties
Financial institutions can process payments in their branches across different geographical locations. Temenos Payments refers these branches as companies and maps it to the PP.COMPANY.PROPERTIES table for any setup that can process payments. Company properties are defined for each company, which needs to be valid in the system table (COMPANY
) in Temenos Payments.
- To view the table, go to Admin Menu > Payments > Payment Hub > Bank System Administration > Static Data > Company Properties.
- Enter the required details in the following fields:
Currency
Temenos Payments allows payment transactions in different currencies. It refers to the PP.CURRENCY table in payments hub, which lists all currencies along with the conversion rates that can be transacted for each company. Currency needs to be a valid record defined in the PP.CURRENCY table. Additionally, other currency attributes are defined in the PP.CURRENCY table that are specific to Temenos Payments.
- To view the table, go to Admin Menu > Payment Hub > Static Data > Currency.
- Enter the required details in the following fields:
Region
Temenos Payments groups countries in different regions using the PP.REGION table in payments hub. It is used to differentiate the holidays applicable for different regions within a country to calculate different value dates. For example, regions within a country can have different holidays.
- To view the table, go to Admin Menu > Payment Hub > Static Data > Region.
Source
Temenos Payments can find the origin (internal or external) of a message in payments hub using the PP.SOURCE table. It is referred by components, such as product determination, client condition and client charges.
- To view the table, go to Admin Menu > Payment Hub > Static Data > Source.
- Enter the required details in the following fields:
Field Description Channel Name Channel through which messages are received Source Product Group to which the source belongs Source Type Source of payment for Temenos Payments, such as: - Client channel – Payments from customer channels or IP
- Non-client channel – Payments from Clearing
- Internal channel – Internal payment
Channel
Temenos Payments finds the origination channel through which incoming and outgoing payments are routed for processing using the PP.CHANNEL table. It is the logical name assigned to a physical queue, and more than one queue can be configured to a single channel.
- To view the table, go to Admin Menu > Payments > Payment Hub > Bank System Administration > Static Data > Channel.
Error Types
Temenos Payments triggers different error types when there is an error, warning or information during payment processing in payments hub.
- To view the table, go to Admin Menu > Payment Hub > Static Data > Error Types.
Clearing Non-Working Day
Temenos Payments determines clearing-specific holidays based on the region of a Country Code before clearing any payments using the PP.CLEARING.NONWORKINGDAY table. This table is referred during payment processing to determine various attributes of the payment such as Dates, Clearing Settlement process and Routing and Settlement.
- To view the table, go to Admin Menu > Payment Hub > Static Data > Clearing Non-Working Day.
Currency Non-Working Day
Temenos Payments determines the currency holidays while processing payments using the PP.CURRENCY.NONWORKINGDAY table. This is referred by Dates component while calculating various value dates in that particular currency.
- To view the table, go to Admin Menu > Payment Hub > Static Data > Currency Non-Working Day.
Party Role
Temenos Payments defines various debit and credit party roles for a payment based on the SWIFT or ISO20022 message tags by using the PP.PARTY.ROLE table.
- To view the table, go to Admin Menu > Payment Hub > Static Data > Party Role.
Status Code
Payments in Temenos Payments go through various stages during processing:
- Define three digit numerical status codes to identify each stage. These status codes are hardcoded.
- To find the current status of the payment, refer to the PP.STATUS.CODE table.
To view the table, go to Admin Menu > Payment Hub > Static Data > Status Code.
Program Characteristic
The PP.PROGRAM.CHARACTERISTIC table helps Temenos Payments to perform the following:
- Find the program invoked for monitoring payments.
- Check whether payments has reached the status defined for the record.
It is a client-specific table used to send status information to client’s TRIP
application (Track and Trace mechanism responsible for informing different client channels about the payments statuses).
To view the table, go to Admin Menu > Payment Hub > Static Data > Program Characteristic.
Weight Assignment
Temenos Payments can find the special processing rules applicable for a payment based on the high, medium or low weights assigned to it by using the WEIGHT ASSIGNMENT
table. Apart from these basic weights, there can be specific user-defined weight codes assigned to the payment (such as enabling or disabling certain functionalities to optimise its processing in payments hub).
- To view the table, go to Admin Menu > Payment Hub > Weight Assignment.
Programs Per Weight
Temenos Payments can decide whether the following components (such as balance check, bank condition, client condition, filtering, and duplicate check etc.) needs to be executed or not for a payment by using the PP.PROGRAMS.PER.WEIGHT table:
This helps in reducing or optimising the processing time of the payment.
- To view the table page, go to Admin Menu > Payment Hub > Static Data > Programs Per Weight.
Component API Hook
Temenos Payments can configure APIs that enable user-defined handling of restrictions on accounts and values dates using the PP.COMPONENT.API.HOOK table. This API hook can also be used to change the credit account of a payment based on a user-defined logic.
There are two types of API hooks:
- PRE API Hook – Performs the changes to the values as explained above
- POST API Hook – Validates the payment and triggers errors or warnings based on the user-defined rules.
To view the table, go to Admin Menu > Payment Hub > Static Data > Component API Hook.
Transaction Types
Temenos Payments can define different transaction types (such as Credit Transfers, Direct Debits, Credit Transfer Returns, Direct Debit Reversals, Clearing Status Report and Resolution of Investigation) to denote the exact flow of the payment or message. During the mapping exercise, each payment message type can be allocated to a specific transaction type, which is a valid record in the PP.TRANSACTION.TYPES table. These transaction types are used in different functionalities, such as Product Determination, Clearing Settings and Value Dates.
- To view the table, go to Admin Menu>Payment Hub>Static Data>Transaction Types.
In Channels
Temenos Payments can find the Inward Queue name from where the payment messages are received from clearing, client or internet banking by using the PP.IN.CHANNELS (inward framework component) table.
- To view the table, go to Admin Menu > Payment Hub > Static Data > In Channels.
Source Setting
Temenos Payments can find various non-clearing or client sources from which payments are received. Additionally, it checks whether the customer status report to be generated for the particular source of payment by using the PP.SOURCE.SETTING table.
- To view the table, go to Admin Menu > Payment Hub > Static Data > Source Setting.
- Enter the required details in the following fields:
Read Configuring Static Data for more information on how to configure enhance Beneficiary Name Comparison feature in TPH.
Authorisation Principle
Temenos Payments uses the PP.AUTHORIZATIONPRINCIPLE table to determine the levels of authorisation required (when manually authorising a payment). This table is viewed for the following scenarios:
- Cancelling a payment from a Warehouse queue
- Authorising a payment from the following:
- Order Entry (OE) page
- General Repair queue
- Direct Debit queue
- Cheque Debit queue
- To view the Authorisation Principle page, go to Admin Menu > Payment Hub > Authorisation Principle.
- Enter the required details in the following fields:
Field Description Status Payment status for which the authorisation principle record is created Direction Direction (Book, Incoming, Outgoing or Redirected) of the payment message for which authorisation principle record is created Authorisation Principle Number of authorisations required for a payment (for 4 or 6 eye authorisation)
BIC and NCC
Temenos Payments can store the BIC and NCC by using the centralised Reference Data module.
- BICs are stored in the Central Bank Directory
- NCCs are stored in Central Bank Directory and the IBAN Plus tables.

This table holds the following details:
- BIC (BIC 8 or BIC 11) of the correspondent banks
- National identifier code
- Address of the institutions
During payment processing, when the NoBicBkCdValidation checkbox is not selected in both the Company Properties table and Clearing Configuration table (used for configuring the channel through which the payment is routed), this RD.CENTRAL.BANK.DIR table is referred to perform the following:
- Validate the BIC and bank codes
- Derive the BIC from bank code and vice versa
Refer to the Centralised Reference Data guide in Banking Framework for more information.

This table has the following:
- Iban Bic
- Routing Bic
- Iban National Id of the correspondent
IBAN Structure Directory
The IN.IBAN.STRUCTURE record has the following:
- IBAN structure (IS Files) information downloaded from the Swift Directories
- Length of IBAN
- Position identifiers for bank, branch and BIC.
SWIFT Directory Create and Maintain
Refer to BIC and Bank Code to create and amend Central Bank Directory.
IBAN Plus Exclusion Directory
The IN.EXCLUSION.LIST displays the IBAN NATIONAL identifiers, which are not allowed in IBANs. To know more, refer to Product Features and Deal Processing in Banking Framework.
The upload mechanism to this directory is centralised in the common Reference Data (RD) module. To know more on the upload process, refer to Centralised Reference Data in Banking Framework. The below screenshot displays the IN.EXCLUSION.LIST table.
Multi Company and Multi Book Support
Temenos Payments provides a complete enterprise solution to support global banks with separated business rules and segregated data. A headquarter company is defined at the highest level with multiple country level companies and branches within the country (if required). All the payment transaction and static data within Temenos Payments are associated with a company. The company data is managed using the data visibility mechanism (restricts the user to view data for defined company or companies) and user application rights (restricts the user to use system functions). Companies can also be configured to share data with each other, which allows common set of users to manage payments for a group of companies.
Transfers initiated with debit and credit account that belongs to:
- Different companies is knows as inter-company transfers. For example, transfer from an account in branch 1 (MF2) of lead company MF1 to an account in lead company SG2.
- Different branches in the same company is known as inter-branch or multi-book transfers. A branch can also be a lead company itself. For example, transfer from an account in branch 1 (MF2) to branch 2 (MF3) in the same lead company MF2.
PP.ERRORTYPES
This application is used to configure error messages of type WARNINGS and INFORMATION in Payments Hub. An error can be configured as a warning or error in this application.
PI.ISO.EXTERNAL.CODE
This application is used to configure an ISO external code list published by ISO Registration Authority. The PP.ORDER.ENTRY,PAYMENT.ORDER and EB.QUERIES.ANSWERS (EBQA) application screen used for initiation of Investigation Request (camt.110) refers to this table to display the values for the below fields when the user initiates the ISO payment / investigation request from payment / investigation request initiation screens.
- Service Level Code
- Local Instrument Code
- Category Purpose Code
- Transaction Purpose Code
- Organization Other Identification Scheme Code
- Private Other Identification Scheme Code
- Referred Document Information Type (for structured Remittance Info)
- Clearing System Identification Code
- External Account Identification Code
- Investigation Type Code <InvstgtnTpCd>
- Investigation Sub Type Code <InvstgtnSubTpCd>
- Investigation Reason Sub Type Code <RsnSubTpCd>
The above codeset is the ID of the PI.ISO.EXTERNAL.CODE table.
Either the system can automatically or the user can manually upload the values for these codesets using Temenos Transact upload service (T24.UPLOAD.PROCESS). The user can also manually add, edit, or delete the values from this table. Any manual update for the codes in the table is overwritten during the next automatic or manual upload if there are any changes existing for that code in the latest file.
In this topic