Introduction to PSD2

• Consent Framework for AIS calls (PZ module)
• Consent Validation
• Provider APIs – Temenos Transact enquiries and versions to support:
  • Consent Management (PZ module)
  • PSD2 Account Information flows (PZ module)
  • PSD2 Payment Initiation flows (PX module)

Dependencies

• SEPA module (for Payments)
• IBAN (for Payments)
• AA Framework (for Consent)
• Interaction Framework (IRIS) (for Published APIs)

In Scope of Temenos Products

• Temenos Transact Workflows – Supporting functionality within Temenos Transact to assist the processing of TPP requests.
• User Agent – Channels Delivery. Read the User Agent user guide for more information.
• Published APIs – IRIS and Interaction Framework Delivery. Read the IRIS user guide for more information.
• Policy Engine or Fraud Monitoring – Financial Crime Management Product Delivery. Read the FCM user guide for more information.
• Non-repudiation and traceability – Security Product Delivery. Read the Security user guide for more information.
  Temenos currently supports the Berlin Group workflows using REDIRECT mechanisms for Consent and Payments.

Not in Scope of Temenos Products

• API Gateway or Security Layer – Not provided by Temenos, but is mandatory in the bank’s architecture.
• Identity or Authentication Provider – Not provided by Temenos, but is mandatory in the bank’s architecture.
• PSD2 Hubs – Not provided by Temenos, but can be optionally interfaced.

Outside of Temenos Transact, IRIS holds an API Mapping that maps the incoming endpoint or request to a TPP role and consent type. This information is used during the TPP and consent validation processes.

This API linking is maintained as API definitions by IRIS for APIs for which consent availability must be checked.

For example, if a GET/{accounts}/{accountID}/balances request is made, the system identifies that the request is an AISP-related request and the customer must have ‘balances’ consent in place on the given account to return the account balances response.

TPP validation takes place at an external system. Please refer to the EXTERNAL flow for more information.

It is mandatory that TPPs are regulated to make PSD2- related requests.

• A first check must be made by the bank’s own API gateway to perform an eIDAS check. This check must be successful before the request reaches Temenos Transact.
• A second check then identifies if the TPP is regulated as per the role of the request. A validation process (to assist with this) is handled in the background and included here for informational purposes.

The routine that handles the validation is called ‘getTppValidateRequest’ and is automatically triggered when receiving a PSD2 request.

The underlying Temenos Transact enquiries for this include:

• PZ.API.VALIDATE.REQUEST.1.0.0
• PX.API.VALIDATE.REQUEST.1.0.0

External Flow

When the Obd Provider field in PZ.PARAMETER or PX.PARAMETER is set as EXTERNAL, the Open Banking Directory is handled externally by an external system or hub.

With this configuration, the system does not expect any values in PZ.OPEN.BANKING.DIR. Therefore, no validation is performed against this table. Instead, the system expects that the TPP Validation is performed before reaching Temenos Transact and that the TPP is regulated to make the request.

One validation is performed in Temenos Transact to check if the TPP is manually blocked by the bank. This is configured in the Block Tpp field in the PZ.PARAMETER and/or PX.PARAMETER applications.

The expected value in this field, if entered, is the Global URN of the TPP.

• If the Global URN of the TPP is included within this multi-value field, it highlights the TPP is blocked by the bank. The validation returns an error. The request is not accepted or processed.
• If the Global URN of the TPP is not included in this multi-value field, the TPP is not considered to be blocked and the TPP validation is successful. The technical response to this call would be ‘external’ to identify that the TPP validation is successful; however, it is checked mainly by an external system.

At this stage, the request can be partially accepted and the Consent Validation process is triggered.

If the TPP Validation is successful and it is identified that the TPP is allowed to make a particular request, the system performs a second check to identify if consent is required for the call.

The routine that handles the validation is called ‘getTppValidateRequest’ and is automatically triggered when receiving a PSD2 request.

The underlying Temenos Transact enquiries are:

• PZ.API.VALIDATE.REQUEST.1.0.0
• PX.API.VALIDATE.REQUEST.1.0.0

If consent is required for the call; Is consent available and is it valid.

This validation forms part of the getTppValidateRequest routine. The below workflow outlines the steps that occur within this process:

A check is made to identify if Consent Validation is handled within Temenos Transact.

This is defined in the Consent Mgmt field in PZ.PARAMETER.

Consent handled in bank’s External system

If the Consent Mgmt field in PZ.PARAMETER is set as EXTERNAL, the consent management process is handled by an external system and is not within Temenos Transact.

Consent handled internally in Temenos Transact

If the Consent Mgmt field in PZ.PARAMETER is set as INTERNAL, the consent management process is handled within Temenos Transact. The system performs a number of checks:

Is consent required for the request?

A check is made at the IRIS layer to identify the type of request that is being made. The IRIS layer holds an API Mapping, which identifies the following:

• Type of request that is being made
• If consent is required for the type of request
• If consent type is required for the request

For Berlin Group payment requests, consent is not required. Instead, a separate approval and authentication process is followed.

For Account Information requests, consent is required before accepting the request and sharing any account information to the TPP.

Does Consent ID exist (if given) and is it valid?

The Consent ID must be passed in the incoming request from the TPP.

The Consent ID in the request is compared with the consent arrangement for that customer and TPP combination.

The Consent ID is not considered to be valid when:

• The Consent ID cannot be found.
• The Consent ID is in history.
• The Consent ID does not link to the TPP/customer/account combination.
• The Consent ID has expired.

The Consent ID is considered to be valid when:

• The Consent ID exists.
• It has not expired (the expiry date has not passed).
• It links to the TPP/customer/account combination.

Has the customer given Consent on the account to process the request?

If the Consent ID is valid, a final check is made to check if the customer has given consent to the relevant consent type on the account.

The request is processed only if the customer has granted the consent type required for the request on the account.

The respective API is accepted and processed in the system after the above validations are successfully met. A response is provided to the incoming TPP request.

Temenos Transact can determine where the user’s online channels permissions are managed. This determines where validations against the user’s permissions are performed during PSD2 workflows. Permissions validation is managed within the Spotlight external system.

AISP Permissions

To configure the permissions validations for consent creation, the Permissions Check field in the PZ.PARAMETER application must be set as:

• EXTERNAL – The user’s permissions are managed within an external system, that is, Spotlight.

When the Permissions Check field in PZ.PARAMETER is set as EXTERNAL to configure permissions checks for subsequent AISP and fund requests, this is managed through the following configuration in the PSD2Accounts-config.properties configuration file.

This configuration is not available for non-Temenos permission management systems and consent management systems.

If the external_permission_check field is set as:

• False or Null – User’s permission validations are skipped.
• True – User’s permissions are validated within the external system, that is, Spotlight.

Valid external Kony cloud URLs are to be set in auth_kony_cloud and dbx_kony_cloud fields to which HTTP requests are sent to validate the user access permissions (Open Banking and Account Level access).

Primary App key and App Secret generated by the above defined Quatum fabric to initiate services to be set in the kony_app_key and kony_app_secret fields.

PISP Permissions

To configure the permissions validations for PSD2 payments, the Permissions Check field in PX.PARAMETER must be set as:

• EXTERNAL – The user’s permissions are managed within an external system, that is, Spotlight.

A housekeeping service can be configured to delete unauthenticated or unapproved PSD2 requests after bank-defined timeframes. This service applies, when a user has not successfully logged in, confirmed or cancelled the request.

• For consent, this service can be configured in the Retention Period field in the PZ.PARAMETER application.
• For payments, this service can be configured in the Retention Period field in the PX.PARAMETER application.

The housekeeping service is enabled, if a value is defined in the Retention Period field in the PZ.PARAMETER or PX.PARAMETER application. This value defines how long unprocessed records will remain in the system before being deleted or rejected.

The BNK/RT.CLEANUP.PSD2.RECORDS service that performs the housekeeping service, must be started to initiate the housekeeping process. When the service is run for the first time, any unauthorised PSD2 records (that is, in IHLD or INAU) exceeding the bank-defined timeframe are deleted from the system.

If this service is run on an ongoing basis, it deletes any eligible PSD2 records exceeding the bank-defined timeframe.

The housekeeping service applies to:

• Consent:
  • PSD2 Consent – Any records older than the retention period defined in PZ.PARAMETER are deleted.

• Payments:

  • Single Payments via PAYMENT.ORDER – Any records older than the retention period defined in PX.PARAMETER are deleted.
  • Recurring Payments via STANDING.ORDER – Any records older than the retention period defined in PX.PARAMETER are deleted.
  • Bulk Payments via FTBM and PAYMENT.ORDER – Any Funds Transfer Bulk Master (FTBM) records older than the retention period defined in PX.PARAMETER are marked as Discarded and the linked PAYMENT.ORDER records are deleted.

For each of the above-mentioned payment types, the housekeeping service additionally updates the Payment Status field value as RJCT in the PX.PYT.RESOURCE application.

If a bank wants to change the types of records for which this housekeeping service applies to, the bank can define a specific value in the Data field in the BATCH application. The following values can be defined in the Data field to specify which types of records this housekeeping service applies to:

• PRODUCT = PSD2.CONSENT (to enable housekeeping for consent)
• PAYMENT = PAYMENT.ORDER (to enable housekeeping for single payments)
• PAYMENT = STANDING.ORDER (to enable housekeeping for recurring payments)
• PAYMENT = BULK (to enable housekeeping for bulk payments)

In the below screenshot, the housekeeping service has only been enabled for PSD2.CONSENT and STANDING.ORDER records.