Scribd
Upload
19 views30 pages

Lesson 14 Other Features Part 1

This lesson covers PSD2, archiving, and expected receipts within the Temenos Payments Hub. PSD2 enhances payment services in the EU by allowing new players access to payment accounts, while the archiving process ensures transaction data is preserved and can be accessed later. The expected receipts feature automates the matching of incoming payment messages with expected receipts, facilitating efficient payment processing.

Uploaded by

Tunde Adagun
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
19 views30 pages

Lesson 14 Other Features Part 1

This lesson covers PSD2, archiving, and expected receipts within the Temenos Payments Hub. PSD2 enhances payment services in the EU by allowing new players access to payment accounts, while the archiving process ensures transaction data is preserved and can be accessed later. The expected receipts feature automates the matching of incoming payment messages with expected receipts, facilitating efficient payment processing.

Uploaded by

Tunde Adagun
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 30

Welcome to Payments Temenos Payments Hub, Lesson 14, Instant

Payments.
In this lesson I am going to describe PSD2, Archiving and Expected Receipts
PSD2 widens the scope of the PSD by covering new services and players as
well as by extending the scope of existing services (payment instruments
issued by payment service providers that do not manage the account of the
payment service user), enabling their access to payment accounts. It will
enable Payment service providers (PSPs) to launch innovative, safe and
easy-to-use digital payment services and to provide consumers and retailers
with effective, convenient and secure payment methods in the European
Union (EU) and European Economic Area (EEA).

In general PSD2 was introduced for the following reasons:


Fixing elements of PSD1
Extending elements of PSD1
Support of One-Leg-In Payments
System identifies the payment based on the originating bank and beneficiary
bank country.
If a payment is received from a non-member state, the following charge
options are applicable:
SHA
OUR – The application of charge code requires a specific request by the
payer. The payer needs to have full transparency on the cost associated with
the payment transaction (before entering).
BEN
Support of One-Leg-Out Payments
System identifies the payment based on the originating bank and receiving or
beneficiary bank country.
If a payment received is destined for a non-member state, the following charge
options are applicable:
SHA
OUR – The application of charge code requires a specific request by the
payer. The payer needs to have full transparency on the cost associated with
the payment transaction (before entering).
BEN
The product determination output parameter in TPH determines the product as
PSD compliant (one or two leg) based on the country of the originating and
beneficiary banks.
In a product determination table, the PSD Complaint Flag field (mandatory) in
the output parameter, determines whether the payment is PSD compliant or
not.
The available values are as follows:
C – Credit side is PSD compliant
D – Debit side is PSD compliant
I – Ignore
N – Payment is not PSD compliant
Y – Payment is PSD compliant
In product conditions record, the PSD Compliant Flag field in the output
parameter can be configured for the payment
Example: Processing the incoming MT103 USD payment before cut-off from a
US bank (charge option = SHA). In this, the system sets the PSD Compliant
Indicator field to C
Non-member state currency payments within the EU/EEA
The rules from the Payment Services Directive are extended to include non-
member state currency payments that have both payer and payee in the EU/
EEA.
The payment is processed only when the payer agrees to the above payment
information. This helps in ensuring transparency in the payment processing,
and is performed by simulating the payment instructions. If the user does not
agrees to the charges levied, the payment is not processed and is terminated.
Before submitting a payment, a payer gets the following details so that they
make an advance decision whether to proceed with the payment or not:
• Execution time of the payment
• Details of any payer’s charges and commissions that will be levied for
processing the payment
• Actual or reference (indicative) exchange rate
• A payment can be simulated multiple times from PO.
• If the payment is confirmed by the customer within the cut-off time of the
channel and within the acceptable time (time between validation and
execution must be acceptable )then the payment system cannot change the
payer’s charges during the life cycle of the payment.
• Before initiating a cross currency payment a payer should be informed of an
actual or reference (indicative) exchange rate so that they can make an
informed decision whether or not to proceed with the payment.
• Payment Order (PO) application will display to the Customer also the
Exchange rates
• After receiving a simulation request, in case of currency conversion on the
debit side ;TPH will return back to the PO the value of the actual debit
exchange rate or indicative rate (current date rate of exchange for future
execution dated payment or mid-rate for a FX limit breach) .
• In a simulation process flow, credit side FX rate will not be calculated . It
will performed after the payment is confirmed by the customer (Execute
mode).
If the customer confirms the payment within the channel cut-off and
acceptable time (time between validation and execution needs to be
acceptable):
Payment system cannot change the payer’s charges during the life cycle of
the payment.
The PO application sends the calculated exchange rate (if applicable). During
simulate mode, TPH returns the rate to the PO application. If an indicative rate
is passed to the PO application (FX breach or future dated payment), the
payment system calculates the debit rate during execute mode.
Temenos Transact performs the following:
Archives examines tables for records to be archived
Writes the selected records (and any associated records) to an archive table
Deletes these from the live tables
Deletes the data without archiving (if required)
For the payments module, records are not deleted from the live tables without
archiving.

• Transaction and static data can be archived in PP.


• At a company level, the user can specify in number of days the transaction
data needs to remain before archival (Refer to Days Active Payment in the
below screen shot). This value can be specified in the
PP.COMPANY.PROPERTIES table.
• Archival happens as a part of EOD or SOD and data are moved to a
separate archive file.
• Archive file can be placed in the same database or moved to a separate
database.
• Reports can be configured to fetch data from archive files.
• Interfaces can be built to send archived data to specific data warehouses.
• Archived payments can be viewed from Pending and Processed Archival
(PAY.PEN.PROCESS.ARCH) enquiry
14

TPH provides an ability to receive and process incoming MT103/ 202 payment
messages.
T24 ER module is used to reconcile notice to receive messages (MT210)
against the corresponding payments messages. The matching items are
stored in the AC.EXPECTED.RECS table.
MT210 is received by T24 ER Module and an AC.EXPECTED.RECS record
with Funds Type as ‘ER’ (Expected Receipt) is created.
When the payment is received inTPH, a request is sent to the ER module and
an AC.EXPECTED.RECS record with Funds Type as ‘Receipt’ is created.
15

When a new record is created in AC.EXPECTED.RECS, it considers the


unmatched items and auto-matches a record with Funds Type ‘Expected
Receipts’ against a record with Funds Type ‘Receipt’ based on the matching
criteria indicated in the ER.PARAMETER. If no matching item is found the
new AC.EXPECTED.RECS record is left as unmatched. A response is sent to
TPH with the matching status irrespective whether it is matched or not.
16

Audit Trail (POR.AUDIT.TRAIL) is updated as “Payment successfully matched


with MT210 and Value Date updated
17

The 'expected receipt’ information can be entered manually or automatically


created by incoming SWIFT MT210 which could later be matched with actual
receipt
18

The user can access the enquiry from: User Menu > Payment Hub >
Expected Receipts > Expected Receipts Enquiries > Expected Receipts
Matched Items
The user can access the enquiry from: User Menu > Payment Hub >
Expected Receipts > Expected Receipts Creation > Expected Receipts-
Manual
The user can access the enquiry from: User Menu > Payment Hub >
Expected Receipts > Expected Receipts Enquiries > Expected &
Receipts Unmatched Items

These enquiry displays the expected receipt matching items to the users with
following options:
View Details – Allows the user to view all the matching item details.
View MT210 – Allows the user to view the incoming SWIFT MT210.
Modify Expected Receipt – Allows the user to amend the details of the
expected receipt item.
Cancel Expected Receipt – Allows the user to reverse the expected receipt
item.
Book Expected Receipt – Allows the user to book the expected receipt item.
TPH application automatically creates a matching item, which will be
automatically matched with the expected receipt item.
Unmatch - This option is used to change the status of the AC.EXPECTED.RECS item
from MATCHED to WAITING.
In this lesson I described PSD2 Archiving and Expected receipts
Use User Menu > Payment > Payment Order Menu > Input Payment Order
> Payment Order – Domestic
Input a transaction
Debit Account 11215
Credit Account 11193
Payment Currency USD
Payment Amount 1015
Commit and Authorise the Record
Validate the record and view the simulation details
Authorise the record and view the transaction in TPH for the simulation values
View the simulation details for charges, cut off and simulation time
View the simulation details for exchange rate
Commit the record
Authorize the transaction
Payment successfully processed in TPH with the same values returned during
simulation

You might also like