Introduction to Temenos Payments

Temenos Payments is an enterprise payment hub solution that provides the bank with a single solution to configure different payment types without any software changes. The payment management features enable the users to prioritise and specify date execution, override changes manually, and manage service level agreements through parameterisation.

It is designed to maximise Straight-Through Processing (STP) to configure automated actions for exceptions and minimise manual interventions to reduce risk and improve efficiency. It can also eliminate redundancies and help in consolidation of different payment systems in a single solution. This is performed when the solution is deployed as follows:

‘Embedded’ with Temenos Core Banking
‘Standalone’ with an external DDA or accounts system

This section is designed to help the Temenos Transact users to understand the application features, navigation and functionalities related to the Temenos Payments module in Temenos Transact. The user can process all payment types in a single system by using the following features:

Receive, process, and send cheque requests between same or different banks
Add a code word to the payment message to convey processing information that can help the financial institution
Execute dynamic routing between different payment types
Maximise STP by using automated exception handling
Handle large volumes of payment requests or transactions
Process instant payments with 24/7 processing and real time connectivity to clearing
Screen a payment before processing to monitor and control risk
Debit an account on regular basis based on the requirement
Support cross-border payments that involves fund transfer between customers and banks in different countries with different currencies
Allow manual intervention to continue the process of payment
Define a charge type based on the customer to apply on different transactions
Check an account for sufficient funds to perform a debit posting
Schedule future payments in advance
Transfer different or same currency between accounts within the bank
Investigate the status of the payment and generate a report
Identify a channel to send the payment to its customer
Support UTF8 character set that can be configured and linked to each clearing.

Temenos Payments is the central payment processing engine of the Temenos Payments suite that converges and processes all payments. It is designed as a back-office application, which receives payments simultaneously from multiple channels and processes them parallelly in large quantities in Straight-Through Processing (STP) mode. Payments can be initiated from the banks’ front office applications (such as branch systems) and back-office applications (such as Treasury, external clearings and settlement systems). Temenos Payments is a multi-company, multi-currency and multi-lingual system built for enterprise wide use by global banks. It processes the following:

Single and batch-based payments
Domestic and international payments
Variety of payment instruments

Additionally, it comprises of the following:

Scalable STP engine
Non-stop support that allows to enter payments any time in the day (even while close of business is in progress)
Processing of multiple payments at the same time
Payment processing workflows
Workflow orchestration manager to create and amend processing workflows
Business rules that define the characteristics of processing
Generic payment object with attributes that span universal messaging standards
Functional components to process different types of payments, with a set of configurable parameters that allow simple plug-and-play operation for an elaborate set of payment products and processing capabilities
Manual action screens to repair payments that fail STP processing
User interface for full-fledged support for R-processing and exception handing of payments (such as, reject, return, refund, and recall)
User interface to create payments orders
Intuitive monitoring dashboards and enquiries for effective management of the whole enterprise
User accessible security and user agent-based definition
Technical framework to configure new clearing systems and message mapping works using XSLT transformations
Interfaces to bank host systems and clearing gateways

This processes the request (automatically) end-to-end within the payments processor using a set of pre-defined static data configurations and business rules. If the payment destination is external (to an entity outside the bank), it distributes the payment outward. If the payment cannot be processed automatically due to errors, it moves the payments to manual processing (by dedicated users in operation roles).

Temenos Payments interacts with various banking systems that require an external interaction to supplement payment processing. It parks the payment in ‘Waiting’ queues within the processor for an external interaction. The payments processing resumes automatically when it receives a response.

System Context

Temenos Payments processes the payments in association with a set of bank host systems that are part of the suite:

System	Description
Channel	Path through which the message reaches Temenos Payments
Clearing and Settlement	Determines the channel through which an outgoing or redirected payment is sent to the intended customer
Sanction Screening	Offers watchlist screening, and a range of intelligent and flexible fraud checking modules to ensure highest detection rates at lowest costs
Payments Repair	Conducts payment transactions electronically without the need to re-enter or manual interventions
Liquidity Manager	Provides mechanisms to set business rules and processes, which allows the bank to implement strategies to satisfy its payment obligations
Analytics	Receives payment data published by Temenos Payments and generates analytical reports
Core Banking	Performs account authorisation (validation, funds check and reservation) and posting (debit and credit posting)
General Ledger	Receives general ledger bookings generated as part of payment processing
Mandate Management	Validates mandates associated with a direct debit, amends an existing mandate or registers new mandates
Data Warehousing and Reporting	Extracts payments data for data warehousing and MIS reporting

Temenos Payments is installed as a standalone product or an embedded module with Transact and Temenos core banking system. When it operates as a core banking system, all interactions with Transact are through internal interfaces, which offer faster turnaround times as all interfaces are supported out-of-the-box.

STP Flow in Temenos Payments

The following chart shows the Straight Through Processing flow from Temenos Payments. This flow is generally adopted for processing payments.

Key Functions

Temenos Payments performs the following important payment functions:

Feature	Description
Payment Order Manager (Front Office)	Allows bank users to manually input or electronically collate payment order capture and enquiries from various online channels using APIs or messages. Performs preliminary validations, such as, BIC validation, IBAN validation, clearing reachability check, funds check and fraud check. Sends the accepted orders to bank’s payment system for further processing. It also allows capture of single payments or bulk payments. NOTE: This feature is available as a standalone module. To know more, refer to Payment Initiation.
Payment Product	Allows banks to define payment processing products that cater to various business needs of banks (corresponding to business products in real world). It enables to configure various processing capabilities and characteristics in the payment workflow. Products can be defined based on following payment characteristics: Type of transfer (customer, bank, domestic or international) Payment direction Payment type Priority Message priority Single Batch Source of payment Payment amount currency Amount Charge type Code words Various other payment attributes
Agreements	Allows to set bank (correspondent bank) or client specific agreements and conditions as follows: Bank Conditions – Defines the way the payment engine processes a payment for a correspondent bank. It influences STP processing of the payment and allows to customise banks’ charge account, payment warehousing, statements and advices. Client Conditions – Allows the customer to choose their preferences from a pre-defined set of possible options. This provides customer flexibility to define their choices beforehand and agree to the services being availed from the bank. This helps the bank to profit from marketing and increased awareness among clients about their service offerings. Netting Agreements - Defines the business rules for processing payments received from an issuer or submitter, agreed upon between the sending bank, processing bank, and the customer.
Routing and Settlement	Determines the routing channel and settlement account by configuring business rules based on payment attributes. The routing channel can be a ledger (in-house), clearing house or RTGS, bilateral participant bank, preferred correspondent, or SSI correspondent through SWIFT.
Clearing	Supports various clearing schemes including RTGS, ACH and Instant. It allows the bank to configure and use clearings in plug-and-play model, with extensive capabilities for message transformations and clearing gateway interfaces.
Clearing Directory and Reachability	Allows upload and management of clearing directory file received from clearings, and performs reachability check during payment processing. NOTE: Each clearing directory has a separate license.
Warehouse	Allows the bank customer to schedule future dated payments. These payments are held in Temenos Payments, as the customer has requested for future date. The user can cancel the payment, amended or force released manually while in warehouse.
Business Dates	Calculates various business dates of a payment (such as value, execution, debit, payment send date) that are necessary to process the payment. The calculation varies based on characteristics and attribute of the payment. Temenos Payments provides banks with a provision for custom development that can influence the date calculation for local requirements.
Fees and Billing	Provides comprehensive and flexible fee definition functionality. It supports the following: Definition of fees for clients and correspondent banks Different calculation methods based on percentage and flat fees Fees based on amount bands, conditional and unconditional fee definitions Minimum and maximum banding Ability (for an operator) to impose fee that overrides fee configured in the system Fee functionality for external billing purpose
Tax	Supports tax calculation on principal and charge. Ability to define tax rules as part of client agreements and customer groups.
VAT	Supports VAT calculation on principal and charge. Ability to define VAT rules as part of client agreements and levy VAT on specific charges.
Sanction Screening	Sends payment information to sanction screening system for screening against OFAC or other screening lists. When operating with Temenos screen as the screening engine, Temenos Payments offers extended functionalities (including a standard out-of-the-box interface).
Risk Filtering	Supports risk filtering to monitor and control risks and limit exposure based on Country, Currency, and Counterparty before the payment is allowed to be booked successfully.
Investigations and Enquiries	Performs investigations on payments based on queries from customer or internal banking departments. It provides a set of enquiries and audit trails that helps users to investigate and report on status and reason for errors.
Funds Reservation	Performs funds reservation based on transaction amount (or amount plus charges) by interfacing with bank’s core banking system. If the funds are insufficient, it allows to perform the following: Manually authorise the payments Automatically retry reservation at defined intervals. NOTE: Temenos Payments can also skip reservation when a fund is pre-authorised for a payment.
R-Processing	Supports R-processing functions for payments (such as reject, return, reversal, refund and recall). It provides necessary pages for handling manual exception and processing workflow to process R-transactions.
Status Reporting	Generates debit or credit advice, payment confirmation notifications and alerts (as an SMS, e-mail, messages, fax) to customers on their payment order status.
Monitoring Dashboard	Provides an enterprise-wide dashboard for monitoring the payments that Temenos Payments processes as it passes through various components within the payment flow depending on the payment characteristics.
Agency Banking	Supports the bank to run agency banking service, and acts as an intermediary or correspondent to indirect participants in a clearing.
Direct Debits	Supports Direct Debit (DD) payments processing. IT also allows mandate validation and storage (if required) for DD processing.
Cheques and Drafts	Receives and processes cheques and drafts deposit requests, and supports inward and outward collection process.
Workflow Management	Allows to build, amend and maintain payment processing workflows.
Bulk Payments	Processes bulk files that are sent by corporate clients. The bulks are processed in-house or through a clearing using respective scheme guidelines. Temenos Payments also allows bulk file upload and manual capture functions for SME and corporate clients.
Manual Payment Capture	Provides a comprehensive set of payment capture options specifically designed for mid and back office requirements.
Posting	Performs debit and credit posting by interfacing with bank’s core banking system.
Security	Supports users and user agents, roles and rights configuration, and user authentications.
Duplicate check	Checks for technical duplicates while receiving files and at the individual payment level.
Mandate support	Receives mandate information, auto register mandates, and process recurring as well as one-off mandates.
Force Non-STP option	Forces Non-STP processing based on high-value payments, amount, customer or group of customers or correspondent banks and code words
Batch file processing	Supports receiving, debulking, and processing batch files (contains one or more credit transfers or direct debit bulks). Supports settlement per bulk or per individual payment within each bulk.
Code word support	Supports processing based on special agreements between banks using code words that are added as part of the payment message. Supports SWIFT code words, as well as bilaterally agreed codewords
SLA support	Supports Service Level Agreements (SLA) influenced payment processing by applying special bank agreements, warehousing rules, routing and settlement rules, special fees, and generating specific advice.
Claims processing	Supports processing of claims raised against a deficit in the charge to be received on processing incoming payments with OUR charge. Generates claims individually or grouped by correspondent BIC, at a pre-defined frequency during Close of Business.
PSD regulation support	Supports Payment Services Directive (PSD) compliance check for transactions where one of the Payment Service Providers (PSPs) is located outside the European Economic Area (EEA), all transactions that start or finish in the EEA and in any currency and non-member state currency payments that have both payer and payee in the EU or EEA.
FATF support	Supports the following: EU validations – Ordering and Beneficiary parties need to have account number and name (address is non-mandatory) Non-EU validations – Ordering and Beneficiary parties need to have an account number, name and address.
Holiday Logic	Supports processing based on the holiday calendar, which influences the processing date, value dates and settlement dates of the payment. Supports definition of country-wise, currency-wise, or clearing wise non-working days.
Standalone support	Functions as a standalone payments hub and connects to a DDA which can be another instance of Temenos Transact or external DDA. Holds frequently used non-customer accounts in the Temenos Transact instance of the payments system to avoid making calls to external DDA.
Close of Business	Supports processes to end the business transactions in a day and move to the next business date such as the release of payments from the warehouse, extracting data to be sent to Insight, Billing, and sending customer status reports for customers who have sent payment initiation messages and so on.
Archiving	Supports automatic archiving of all payment data and its related information as part of the close of business for a defined period, based on configuration.

Payment Instruments

The different payment instruments available in Temenos Payments are as follows:

Payment Instrument	Description
Credit Transfers (CT)	Initiating party is credited by the originating bank and a credit is passed to the counterparty bank where beneficiary party is held. Temenos Payments supports full life cycle of all available types of credit transfers including intra-bank transfers (within bank, also known as book transfers), inter-bank transfers within country and across borders, with its different flavours and schemes across countries and regions. It also supports many instant CT schemes that demands real time processing of credit transfers.
Direct Debits	Recurring or one-off request to collect money from a payer, based on a prior agreement (generally known as mandates). Direct debits are setup by corporate utility companies, who raise collection requests on a recurring basis to collect monies towards bills and invoices. Temenos Payments fully supports initiation and processing of DD with an external mandate management system holding mandate information.
Cheques and Drafts	Supports processing of cheque payment processing, including cheque deposit, outward collection and inward collection, manual return and repair of cheque payments. Supports banker’s draft or demand draft in local currency or foreign currency.
Request To Pay (RTP)	Allows payee to collect funds from a payer based on online authorisation (typically based on mobile devices). Temenos Payments supports processing of RTP requests that include generation, receipt and processing of the request at payer bank side based on consent provided by the payer.

Payment Types

The different types of payment in Temenos Payments are as follows:

Type	Description
Single	These payments are of high value, demanding gross settlement or international FX transactions. They can also be instant payments of low or high values. Temenos Payments supports single payments in all possible cases, including national and cross border payments.
Batch	To achieve cost effectiveness, transactions from corporate customers are combined into a batch and sent to their bank for processing. The batch transaction is an in-house transaction, while individual transactions in the batch are in-house or non-inhouse (off-us). Temenos Payments supports single-debit multiple-credit CT and single-credit multiple-debit DD batches. It also supports splitting of batches into single individual transactions and processing them as individual transactions.

Type

Description

Single

These payments are of high value, demanding gross settlement or international FX transactions. They can also be instant payments of low or high values. Temenos Payments supports single payments in all possible cases, including national and cross border payments.

Batch

To achieve cost effectiveness, transactions from corporate customers are combined into a batch and sent to their bank for processing. The batch transaction is an in-house transaction, while individual transactions in the batch are in-house or non-inhouse (off-us).
Temenos Payments supports single-debit multiple-credit CT and single-credit multiple-debit DD batches. It also supports splitting of batches into single individual transactions and processing them as individual transactions.

API Capabilities

Temenos Payments provides extensive capabilities around APIs. It provides functionalities that are exposed for consumption through its published APIs, API middleware, and powerful tools that allow banks to interface their systems with Temenos Payments with ease and effectiveness. The tools also allow on-the-fly creation and deployment of new APIs that a bank can develop to meet their specific channel and third-party requirements.

Multi-Function Capabilities

The multi-function capabilities of Temenos Payments are as follows:

Capabilities	Description
Multi-Company	Supports several banks with separated business rules and strictly segregated data. A company headquarter is defined at the highest level, under which multiple country level companies and branches within the country (if required) are defined. The payment transaction and static data within Temenos Payments are associated with a company. Data visibility mechanism restricts users from viewing the company data (for defined companies). User application rights restricts the user from using system functions. It also allows companies to share data with each other, which enables the common set of users to manage payments for a group of companies.
Multi-Currency	Allows to configure multiple currencies with full-fledged set of currency attributes (such as currency markets, exchange rates, holidays, and possibility) to maintain them through manual or automatic feeds. It also supports cross-currency transactions with externally or internally stored exchange rates.
Multi-Lingual	Supports multitude of languages and raises multi-lingual alerts, notifications, and processes payment transactions with multi-lingual fields.
Multi-Time Zone	Supports multi-time zone operations and assigns a time zone for each user and company. Users who belong to multiple companies can switch between time zones to operate effectively.

Instant Payments

Instant Payments processing framework is an extension of the Temenos Payments STP engine to meet the higher demands of instant processing payments. It offers the following features:

Receives, processes and responds to payments sent out in real-time (in milliseconds) in synchronous processing mode
24*7 processing throughout the year with no downtimes
Near real-time synchronous processing (in seconds) for slower instant payment instruments to cope to bank’s technical infrastructure
Lightweight processing flows to achieve quick turnaround time
Automated investigation messages based on the needs of the instant clearing schemes
Time stamping (before release to clearing) and validation of the timestamp (on receipt from clearing)
Immediate booking or booking on confirmation from clearing
Parallel processing capabilities to ensure maximum usage of time spent while waiting for external interfaces
Special R-processing functionality to meet instant payment schemes (for example, automatic scheme returns by instant clearing)
Real-time monitoring dashboard
Standby processing when bank hosts are offline due to (planned or unplanned) downtimes
Timeout and expiry mechanisms at integration layer
Send and receive clearing status reports
Working in standalone mode as well (DDA is external)

Illustrating Model Parameters

This section covers the high-level specifications required for the Temenos Payments module.

Table	Description
`PP.FEETYPE`	Configures various types of fee that are involved in processing a transaction Conditional fee – For example, non-STP fee Unconditional fee – For example, transaction fee
`PP.SWIFT.TRANS.TYPECODE`	Specifies the codes to be used for MT940 (Tag61:Subtag6) and is linked with booking code (identified in Payment Order) Once determined, the corresponding SWIFT transaction type code can be retrieved
`PP.CURRENCY`	Configures various currencies used in processing domestic or international transfers Select other information such as the country to which the currency belongs to, specify FX limit, configure weekend days and so on
`PP.PARTY.ROLE`	Determines the various parties involved in a SWIFT or SEPA transfer For example, ordering customer, sending institution, beneficiary
`PP.PROCESSING.SEQUENCE`	Defines a set of pre-defined steps that influences payment processing by setting various fields and indicators that are subsequently read and considered for payment processing.
`PP.STATUS.ACTION`	Stores the action to be performed for the corresponding status codes of the payment Has information about the error codes and status code
`PP.PROGRAM.CHARACTERISTIC`	Has information about programs executed in Temenos Payments Details include name of the program, type of the program, name of the component to which the program belongs and path where it needs to be executed
`PP.REJECT.RESPONSE.ACTION`	Defines parameters for determination of Reject Response Action field Allowed values are: R – Sent to repair C – Sent for cancellation
`PP.MANUAL.AUTH.REQUIRED`	Indicates whether manual authorisation is required by COA Officer to process the payment Allowed values are: N – Manual authorisation request cannot be requested Y - Manual authorisation request can be requested NOTE: If not defined, by default, manual authorisation request can be requested.
`PP.FILTERING.PRODUCT`	Configures the filtering products Used in `PP.FILTERING.PAYMENTS` table and derived as one of the output in product determination
`PP.FILTERING.PAYMENTS`	Defines different filtering payments
`PP.BANKCHARGES`	Maintains the bank charges where, inn case of OUR payments, the processing bank either receives charges from the sending bank or sends charges to the receiving bank as all charges are borne by the originating party
`PP.BANK.CONDITIONS`	Defines the way in which a payment should be processed in the payment engine for a correspondent bank Various bank conditions include STP flow, charge account, statements and advices with correspondent bank
`PP.BANKCLAIMSCONTROL`	Stores the configuration required for bank preferences for claims processing
`PP.MSGPAYMENTTYPE`	Defines various valid messages payment types such as 101, 103, 202, BACSCT, BACSDD supported by Temenos Payments
`PP.MSG.FORMAT`	Defines various message formats NOTE: Only when the message format is defined, other particulars of the message format can be defined in other tables of Temenos Payments.
`PP.CHANNEL`	Stores various channels using which a message is received from or sent to from Temenos Payments
`PP.SOURCEPRODUCTGROUP`	Configures the source product group, which is used to group different sources Every source in Temenos Payments is categorised in a source group As a result, source product group needs to be defined before defining a source
`PP.IN.CHANNELS`	Has configurations according to queue name specified with its folder path to receive messages
`PP.INBOUND.CODEWORD`	Stores inbound code word details for different types of incoming payments that alters the characteristics of the payment such as priority and processing indicator
`PP.BALANCE.CHECK.REQUIRED`	Configures Balance Check Required field based on certain characteristics of the payment Allowed values are: Y – Balance check required N – Balance Check not required
`PP.AUTHORIZATIONPRINCIPLE`	Holds the levels of authorisation of a manually processed payment or a cancelled warehouse payment. Allowed values are: 1 – 4 Eye Principle 2 – 6 Eye Principle
`PP.MSG.FORMAT.PER.CHANNEL`	Has various message formats in accordance with various channels available in Temenos Payments. There are many relationships between the message formats and channels.
`PP.MSGMAPPINGPARAMETER`	Defines parameters for mapping messages received in Temenos Payments using API
`PP.SOURCE`	Stores the details of various source from which a message is received in Temenos Payments A source can be defined only along with Channel Name, Source Product and Source product group
`PP.MSG.ACCEPTANCE.PARAM`	Configures parameters related to Message Acceptance process Specifies if duplicate check is to be performed for the incoming message
`PP.SPECIFIC.WEIGHT`	Stores specific weight to be used for payments to enforce special processing rules. Two types of weight are assigned to every payment: High level weight – Refers to an overall classification of the payment on a very broad level Specific weight – Refers to a detailed weight assigned to a payment to trigger different flavors of a component for certain groups of a payment
`PP.PROGRAMS.PER.WEIGHT`	Specifies physical programs to be invoked by each component according to weight and specific weight of the payments leading to reduction in processing time Defines whether a component needs to be skipped
`PP.NODA.LIST`	Defines list of message types that needs to skip debit authority check If a record is present in this table, the payment is authorised straightforward
`PP.MSGPAYMENTTYPECHANNEL`	Stores many-to-many relation between message payment type and channels
`PP.SOURCE.SETTING`	Defines whether a Customer Status Report needs to be generated for a particular source
`PP.CLEARING.RETURNCODE`	Configures clearing return code for the respective clearing
`PP.CLEARING.NATURE.CODE`	Defines clearing nature code along with description for all clearings defined in Temenos Payments Stores other details related to the clearing such as Cheque Type, DD Collection and so on
`PP.CLEARING.SETTING`	Defines generic settings for clearing such as Direction, Currency, Clearing Account Number and Automated Return Indicator
`PP.CHANNEL.CUTOFF`	Defines cut-off time for various channels used in Temenos Payments Ensures the time beyond which the channel cannot be used to route a normal payment to the recipient
`PP.CLEARING`	Stores the various clearing used for settlements in Temenos Payments based on currency and country code
`PP.CLEARING.FREQUENCY`	Configures the cut-off time on which a Nostro settlement process with clearing house is to be started
`PAYMENT.ORDER.PRODUCT`	Defines payment features specific to a product such as instant, domestic, SEPA and international
`PP.POSTING.PRODUCT`	Stores posting products that are used while generating posting entries in Temenos Payments Derived as one of the output of product determination
`PP.ROUTING.PRODUCT`	Defines routing products used in product determination process Product defined is used while configuring client conditions
`PP.CLIENTCOND.PRODUCT`	Configures a product related to client conditions One of the criteria for selection of a record based on peeling off logic in client conditions table
`PP.FEE.PRODUCT`	Defines the fee products in Temenos Payments Used in client charges table and derived as one of the output of product determination
`PP.LEDGER.PRODUCT.CODES`	Setup ledger product codes with product description for a processing company in different languages The ledger codes are used extensively while posting
`PP.STATEMENT.FORMAT`	Attaches statement lines to the statement format already configured in the posting set in Temenos Payments
`PP.RSCHANNEL.SELECTION`	Stores the information about routing and settlement channel selection list
`PP.CLIENT.CONDITIONRECORD`	Specifies special condition or possible options for the customers It can be defined very generic and specific to particular client
`PP.CLIENTCHARGES`	Defines the charges to be levied on a customer based on the product determined for the payment
`PP.POSTING.SET`	Defines the posting set to be selected based on Company Code, Posting Product and set of payment file fields that are updated based on client conditions
`PP.CONTRACT`	Stores the routing and settlement information based on credit party of a payment or for the destination country of a payment. The three contract types are: Party contract – Defined for credit party (most specific) Country contract – Defined for destination country(less specific) Bank contract – Defined for bank policy (least specific)
`PP.LIGHTWEIGHTPRODUCTCOND`	Defines various characteristics to determine a product for lightweight payment. The determined product is linked to various factors such as Fee, Ledger, Client Condition, Posting and Routing product NOTE: All incoming or re-direct domestic payments using Clearing channels are treated as light weight
`PP.HEAVYWEIGHTPRODUCTCOND`	Defines various characteristics to determine a product for heavy weight payment The determined product is linked to various factors such as Fee, Ledger, Client Condition, Posting and Routing product NOTE: Usually, all international domestic payments (outgoing or book) are categorised as heavy weight.
`PP.MEDIUMWEIGHTPRODUCTCOND`	Defines various characteristics to determine a product for medium weight payment The determined product is linked to various factors such as Fee, Ledger, Client Condition, Posting and Routing product NOTE: Medium weight is specifically meant for SEPA
`PP.COMPANY.PROPERTIES`	Defines each company that should participate in processing payments Also defines attributes such as Local Currency, Company BIC, Country and so on
`PP.REGION`	Stores different regions within a country A region can be used to differentiate between holidays applicable for different locations within a country If set as ALL, the setup is applicable for all regions of the country.
`PP.ERRORTYPES`	Configures error messages of type, Warnings and Information in Temenos Payments and they cannot be amended Information – Can be ignored in UI flows Warning – Needs to be accepted before payment authorisation
`PP.STATUS.CODE`	Stores the various status code in Temenos Payments along with the reason code and is only for informational purpose
`PP.COMPONENT.API.HOOK`	Configures APIs which enable user defined handling of restrictions on account and customer
`PP.TRANSACTION.TYPES`	Defines various types of transaction and its description in Temenos Payments Indicates the codification of the transaction type
`PP.PAYMENT.ROUTER.COMPANY`	Defines the companies, which support message received from payment router channel During validation, if the company code in the message does not match with table the message is available in Repair status.
`PP.BATCH.SUSPENSE.ACCOUNT`	Stores the suspense account per company or currency for batch messages in Temenos Payments
`PP.CLEARING.COMPANY`	Configures companies that support a specific clearing house along with other particulars such as National ID and so on NOTE: This table is referred during validation of a clearing file to determine the company ID.
`PP.TRANSACTION.TABLES`	Defines the list of tables to be retrieved, while invoking OutwardMappingFramework.getAllTransactionData method by an external system
`PP.RETURN.MAPPING.PARAM`	Configures values which should be mapped or override the values returned by Return API while generating return or reject payments and to attach a hook routine which defines specific logic (conditional mapping) required for populating values in return or reject payment
`PP.OUTBOUND.CDWRDGEN`	Stores code words to be added as outbound code words to be sent from Temenos Payments Specifies the receiver BIC, message payment type and transaction currency
`PP.INBOUND.OUTBOUND.CDWMP`	Helps the mapping of the inbound code words received in the incoming redirect payments to the outgoing redirect payment
`PP.SLA.PER.CODEWORD`	Maintains various Service Level Agreement (SLA) with correspondent banks for each company SLA is defined based on the Message Priority, CodeWord and the message tag in which the code word is specified
`PP.NETTING.AGREEMENT`	Stores netting agreement, which is a 3-party agreement between the sending bank, the processing bank and the customer Confirms whether the sender of the payment instruction has the authority to mention a third party as the debit party for the payment
`PP.CLIENTCOND.PRODUCT`	Configures a product related to client conditions This is one of the criteria for selection of a record based on peeling off logic in client conditions table
`PP.AGENT`	Holds the publicly known Head Office-Branch relationships between banks This is referred using a BIC and not NCC NOTE: If only NCC is available, BIC is derived out of NCC and then this table is referred.
`PP.LORO.NOSTRO.ACCOUNT`	Stores the accounts of the correspondent banks with which the bank shares a Loro and Nostro relationship Linked with BIC table and is also company specific
`PP.PREFERREDCORRESPONDENT`	Stores referred correspondents that a company uses to route a payment to specific country. More than one preferred correspondent for a country can be provided based on the currency of the transaction and routing group. Preferred Correspondents are also known as Country Correspondents
`PP.CLEARINGCORRESPONDENTS`	Supports processing or redirecting credit transfer files from Indirect Participant (IP) banks through an IP bulk channel Configures settlement account, BIC and NCC of each IP
`PP.RMA`	Has the list of correspondent banks to which the bank is authorised to send a SWIFT message The permissions on the RMA table are specific to the SWIFT NET service and message type SWIFT service now can only be SWIFT NET FIN service
`PP.NO.RMA`	Specifies the list of message types for which RMA check is not required to send a SWIFT Message from Temenos Payments
`PP.STANDINGSETTMNTINSTRUC`	Configures standing settlement instructions for correspondent banks. They are also known as currency correspondents similar to `PP.AGENT` Also refers to BIC and not NCC
`PP.EXCLUSION.LIST`	Validates the extracted bank code (IBAN national ID) from the IBAN against the exclusion list NOTE: In case of an invalid IBAN, the system must return a warning.
`PP.DEBIT.VALUE.DATE`	Configures setup parameters for calculation of debit value date, which can be processed by Temenos Payments using peeling logic
`PP.BOUNDARY.DATE`	Defines the interdependency between the various dates used in Temenos Payments so that the same can be processed using peeling logic
`PP.EXPOSURE.DATE`	Setup parameters for calculation of exposure date, which can be processed by Temenos Payments using peeling logic. NOTE: Exposure date is the date from which credited funds are available for use by the client.
`PP.HOLIDAY.LOGIC`	Configures parameters that decide the holidays to calculate the next business day NOTE: This is processed by Temenos Payments using peeling logic.
`PP.SEND.DATE`	Stores the parameters to be considered to derive the date when the output message is to be sent to the receiving bank or clearing
`PP.RISK.FILTER.CONDITIONS`	Defines the risk filtering conditions for correspondent banks, country and currency wise
`PP.FEETYPECREDITACCOUNT`	Stores the credit accounts linked with the fee types defined in Temenos Payments During the fee processing, a lookup is performed to identify the associated credit account (P&L account) This credit account along with the other charge details are used to post entries into the general ledger
`PP.OCP.ACCOUNT`	Defines open currency positions that are used in posting when currency conversion is involved. OCP accounts are currency specific. Temenos Payments selects the OCP account from the static table based on the currencies involved
`PP.CURRENCY.DEALER`	Defines the dealer desk code for different types of currencies available in Temenos Payments This code is required exclusively in posting the transaction entries
`PP.INSUFFOUTB.OUR.CHARGE`	Defines the details of the account to be debited for the outgoing payment with charges option as OUR (receiving bank 71G) if the sending bank has not sent the sufficient charges
`PP.POSTING.TOKENS`	Configures amount, account, date and statement text tokens used in posting lines generated in Temenos Payments.
`PP.CLAIMS`	Configures the expected claims account and the expected P&L account for a currency and company code combination
`PP.AUTO.REPAIR.INSTANCE`	Configures repair instances used in Temenos Payments. External repair tools are primarily designed to enhance straight-through-processing (STP) rate of the bank The output of the repair tool is the input for the fee processing
`PP.AUTO.REPAIR.RETURNCODE`	Configures the description and meaning of the return codes returned by a repair instance defined in Temenos Payments
`PP.RPSSCL.CLEARING.DIRECTORY`	Displays details from the files received by the payment system from clearing
`PP.IN.ENTRY.PARAM`	Configures fields to map the response details received from the external system
`PP.NON.CUSTOMER.ACCOUNTS`	If a bank’s core-banking system is external to Temenos Transact (that is customer accounts is not in Temenos Transact), the system can skip the interaction with the external system for account validation when non-customer accounts that are frequently used do not undergo much change.
`PP.CHAR.CONVERSION`	Stores the Source and Target fields with UTF characters. Replaces the Source UTF-8 into Target UTF-8 when any special characters are mentioned in SWIFT and SEPA transfers. In the below example, Ü is converted to AB wherever used in payment message. Source – U+0060 equivalent value is Ü Target1 – U+0041 equivalent value is A Target2 – U+0042 equivalent value is B
`LQ.LTA.QUALIFICATION`	This table is used to ascertain based on the payment characteristics to decide whether to process as LTA.
`LQ.ACCOUNT.MAPPING`	This table is used to return the account as an output parameter for the debit or credit legs.

Read the Temenos Payment (PP) and Payment Suite (PH) user guides for information on parameter setup for camt.055.

Inward/Outward Message Flow

Messaging Framework is a component of Temenos Payments that deals with validation, transformation, mapping and handling of the messages (XML, non-XML) in Temenos Payments, from and to the clearing or external systems.

Refer Messaging Framework and Configuring Message Framework for more information.

Illustrating Model Products

This section covers model products for Temenos Payments module.

Product Name	Features
International	Process incoming or redirect STP SWIFT message from SWIFT source Can be initiated in Order Entry and Payment Order screens Processed international transfers have a transaction record in Temenos Payments with detailed flow
Book Transfer	Transfer of funds from one account to another at the same financial institution Unlike interbank transfers, these require little or no wait time Can be initiated in Order Entry and Payment Order screens Processed book transfers have a transaction record in Temenos Payments with detailed flow
Cheque	A cheque orders a bank to pay a specific amount of money from an account to another (to which the cheque was issued) Initiated from Teller Financial Services screen Both incoming and outgoing cheques are processed in Temenos Payments
Draft	Payment on behalf of the payer, which is guaranteed by the issuing bank A draft is used when the payee wants a highly secure form of payment Initiated from Payment Order screens Processed drafts have a transaction record with its status code and description in Temenos Payments

Temenos Payments module provide the facility to receive customer cancellation message camt.055 for pain.001 message.

Dark Mode

Expand/Collapse

In this topic