Payments
R24 AMR | Min(s) read
Related topics:

Introduction to Payment Initiation

PAYMENT.ORDER (PO) application is an integral part of the Temenos Payment Solution, which is part of the Temenos Transact core banking suite. This handles order capture and management functionality, and supplements the payments processing engine, Temenos Payments Hub. The key features of PO application are as follows:

  • Interfaces with a variety of payment initiation channels, both in interactive and Straight-Through Processing (STP) modes. Initiation channels include customer facing and electronic feeder channels (STP), bank’s branch or potentially in-house bank host systems that can raise a payment request.
  • Performs order validation, pre-processing and storage until processing date.
  • Performs manual repair and release for payments in exception.
  • Helps in routing of the orders to appropriate payment system based on payment characteristics.
  • Generates payment status reports, and customer advices and alert notifications
  • Supports the following:
    • Payment capture for different types of clearings (such as RTGS, Automated Clearing Houses (ACH), Cross-Border and Instant Payments Clearings).
    • Popular clearing systems (such asTARGET2, SEPA using EBA, SEPA using RPSSCL, SEPA Instant, EQUENS, UK CHAPS, UK Faster payments, Hungary Instant (RT1), UK BACS, and SWISS RTGS).
    • Credit transfer, single and bulk payments, and a variety of payment types within credit transfers.
    • Customer payments and bank-to-bank transfers.
  • Complies with ISO20022 payments messaging standards.
  • Has a submodule of TPH that is offered by Temenos. However, banks can choose to use PO application as an independent module without TPH. In such installations, PO application interacts with bank’s non-Temenos payment systems to process payments captured or aggregated in PO application.
  • Depends on Temenos Transact submodules to provide payment services. To know more, refer to PO application and associated Temenos Transact applications section.

PO Application in Business Context

The following are the payment processing infrastructure of the bank.

The functionalities of PO application are as follows:

  • Receives payments using standard Temenos Transact interfaces, validates, enriches, and routes them to appropriate destination payment system.
  • Sends the payment status back to initiating source in response to the acknowledgements received from the payment system.
  • Generates payment advices as customer notifications.

The payment processing system (such as TPH or bank’s non-Temenos Payment system) validates, books and routes the payment to an appropriate clearing system. Payment instruction exchanges are in embedded mode when PO application operates with TPH, whereas, uses the standard message formats and interfaces in an external system. In-house payment requests are settled within the bank’s core banking, instead of sending it to clearing.

PO application supports the capture of payments, which are cleared by the following clearing systems:

Clearing System Description
Domestic High-value RTGS payments, instant payments clearing systems or ACH that processes bulk payments
SWIFT International payment message interchange
Cross-Border Operate across borders, such as Pan European ACH

All systems in the bank that supplements payment processing, such as bank’s core banking system.

PO application can be accessed using APIs when deployed with Temenos Interaction Framework (IRIS) or third-party API gateway. This feature helps the bank to support PSD2 related open banking requirements, where the bank acts as a PISP or serves a PISP (as an account owning bank). The PO application supports the following APIs that supports both immediate and future dated payments:

Release API
Berlin Group Standards Release 1.3 Payment Initiation
Payment Status
Payment Cancellation
Payment Completion

STET Standards Release 1.4

 Payment Initiation
Payment Status
Payment Completion
Payment Cancellation

This feature requires Temenos Transact PI module (PX) to be installed (Dependent modules are PZ and CK for processing permissions and third-party payment initiator validation).

The PAYMENT.ORDER (PO) application can receive payments from various Temenos Transact systems such as RTP, Forex, and so on. After the payment is completed, the PO application can update the status of the payment to these source systems. This can be configured in Payment Order Ps Mapping Rule setup.

Configuring PO Application

PO application provides high level configuration with different aspects of payment capture.

This parameter allows the user to set characteristics of a PO application. The key parameters are as follows:

Parameter Description
Fraud Check To send request to fraud check system.
Payment System To process payments. The user can select the payment system to which the payment request needs to be sent.
Publish Special Events To receive notifications for the following scenarios (if configured):
  • Outward and inward payment status
  • Inward recall
  • Recall response
  • Recall rejected by clearing
  • Recall request overdue
  • Inward recall investigation

For example, inward recall notifies the client bank when Temenos Payments Hub (TPH) receives a recall from clearing.

This is applicable when running TPH as the payment system
Special Event Name To receive notifications for specific special events. This is a multi-value field that is enabled, when PublishSpecialEvents field is set as ‘Yes’.
  • If no events are selected in this field, the system sends notification for all special events.
  • If specific events are selected from the drop-down, the system sends notifications only for the selected special events.
The user needs to set the PublishSpecialEvents field as ‘Yes’ in both the scenarios.

The following special events (as multi-value) are available in the drop-down that notifies the client bank on:

  • Inward Recall – Receipt of a recall request
  • Recall Response – Receipt of a response for a recall request sent previously
  • Outward Payment Status – Status of an outward payment
  • Recall Rejected by Clearing – Rejection of a recall request by clearing
  • Recall Request Overdue – Recall request sent becomes overdue
  • Inward Payment Status – Status of an inward payment received
  • Inward Recall Investigation – Investigate an unanswered recall request
Pre-Approved Payment To skip balance check and fund reservation during payment processing.
Pre Validated Account

To skip account validation and restriction checks during payment processing.

The user can set this parameter as 'Yes' only when Temenos Payments is in standalone mode.

This scenario is applicable when accounts are maintained in an external DDA system and are not replicated in Temenos Payments. Pre-validated payments initiated in Temenos Payments must have their accounts validated externally prior to the payment initiation.
Pre Determined FX

To skip determining the FX rates in Temenos Payments.

The user must provide the exchange rate during payment initiation along with the payment amount and the currency equivalent amount. The user can set the parameter as 'Yes' only in Standalone mode.
Cancellable States To process the cancellation request, the user can configure the payment order states eligible for cancellation .

PO application are configured to adhere to payment rules that apply to payment identifiers of a given country (where the credit party holds an account). Following are the examples of country rules:

Rule Function
Allow or disallow IBAN Validates whether an IBAN is allowed or disallowed in a payment.
Allow or disallow BIC Validates whether a BIC of a beneficiary bank is allowed or disallowed in a payment.
Clearing code format Mentions the format of clearing code for a specific country. System validates the clearing code format when initiating a payment to a country.
Allowed currencies Inputs the list of currencies allowed to make a payment to a certain country.

Payment products configured in PO application can be common across countries. However, country rules takes precedence (if set) over rules set at product level.

Every order is assigned a product attribute that determines the characteristics of the payment and the manner in which the payment is processed. Some of the generic products available in PO application are:

User chooses the Payment Order Product (during manual capture) or PO application automatically assigns it (based on the criteria defined by payment attributes). PO application products can also be based on message type (if there are specific requirements). For example, application product is UKFPS-SIP (Single Immediate Payments in UK FPS) or SEPA CT (SEPA Credit Transfer). Payment Product of PO application allows to set characteristics on how to capture, validate and process a payment order. Some of the key functionalities are as follows:

Functionality Description
Holiday calendar Enables to check the holidays while making a payment request.
Usage of IBAN or BIC/Sort code Allows IBAN or BIC/Sort Code for a certain product or not. However, country rules take precedence while making a payment.
FX rules Allows FX for this product. If allowed, float is to be used.
Warehousing rules

Marks the future dated payment request to warehouse in the PO application.
Allowed currencies Inputs the list of currencies allowed to make a payment with the selected PO product.
Charging rules Lists all the charges that are charged for a particular PO product and configures fixed and conditional charges.
Reachability check Performs reachability check so that the payment is not rejected in the payment system.
Check transparency Simulates a payment order, which helps to avoid any rejections in the payment system.

PO application allows to hook bank specific APIs to determine its product.

API Description
Product Determination API Changes product dynamically based on payment information. For example, amount greater than 10,000 EUR is changed to TARGET2 payment product.
Charging Rule API Determines whether a configured fee is applied or not. For example, the bank can choose not to charge cross-border fee, when the country is non-EU.
External Account lookup Validates the account that is in a non-Temenos Transact database.
  • Online capture – PO application provisions synchronous call facility to account management system
  • Offline capture (STP) – PO application offers asynchronous interaction facility with account management system.
Payment Validation Allows custom validations that can be implemented during business validation stage of a payment order.
Connection API Creates logic to connect to a specific payment system based on payment characteristics. For example, bulk payments sent to bulk payments engine.
Fraud Routine API Allows local site-based API hooked to send payment information for fraud check.

To update the status of the payment to the source system, the user has to provide the following configurations:

Field Description

Source Mapping Api

The API defined in this field must have the logic for one to one mapping from the PO application to the source application.

Source Map Rule Api

The API defined in this field determines whether the PO application must be mapped to the source system or not. The output of the Source Map Rule API field is compared with Source Result Option field. If the values are same, then the mapping is done from the PO application to the source system. If the values are different, then mapping is skipped.

Illustrating Model Parameters

The high-level configurations available in the Model Bank are given below:

S.No. Parameter Description
1. PAYMENT.ORDER.PARAMETER This parameter table contains high-level payment order configuration at the company level. This application facilitates the definition of the Payment Connection method, whether Warehouse is supported and the number of days the Payment order needs to be maintained in live status before moving to history.
2. PAYMENT.ORDER.COUNTRY.RULES This parameter table defines any country specific rules checking for Beneficiary country for outward payments. This takes precedence over similar definition in Payment Order Product. It also has the provision to set rules if IBAN, BIC, Sort Code or Clearing channels are applicable for specific countries.
3. PAYMENT.ORDER.PRODUCT Payment features that are specific to a product are defined here.

Illustrating Model Products

Payment Initiation module captures the transaction details and forwards the instruction to the back office system configured in PAYMENT.ORDER.PARAMETER for further processing. It also applies some basic validations configured in the PAYMENT.ORDER.PRODUCT.

S.No. Product Description
1. Payment Initiation Payment Connection Method in PAYMENT.ORDER.PARAMETER is set as Tps, so that all the payment initiated from PAYMENT.ORDER gets routed to TPH for further processing.

Copyright © 2020- Temenos Headquarters SA

Contact Us

knowledge@temenos.com

Published on :
Tuesday, May 28, 2024 5:38:44 PM IST