Standards v2.0-final-errata1

Limits and Constraints

Limits and Constants | Schedule Payments Time Window

B1 (Schedule Payments Time Window) currently has this definition:

The time window during which TPPs MUST submit their scheduled payments on the Requested Execution Date or any day that is defined in the Recurring Payment Schedule or the defined payment schedule. The time window is defined to be between 1am and 6am on the specified date.

However, there are instances when TPPs may need to submit payments, and when LFIs may need to execute such payments outside this window.

This definition will be updated as follows:

The time window during which TPPs SHOULD submit their scheduled payments on the Requested Execution Date or any day that is defined in the Recurring Payment Schedule or the defined payment schedule, UNLESS there is a proper user or technical rationale. The time window is defined to be between 1am and 8am on the specified date.

The API Hub will not enforce this time window, and LFIs MUST NOT reject any such payment requests if they are made outside this time window while continuing to apply the same rules and following relevant regulations for processing any genuine payment request.

Bulk and Batch Payments

Bulk and Batch Payments | Bulk or Batch Payment Consent

The business rules do not currently define that bulk or batch payments for SMEs must be of a single commercial payment type per bulk or batch payment file.

The following Business Rule will be added to this section:

For bulk or batch payment files when the Debtor is an SME, the User and associated TPPs must only include payments of the same commercial type within a single payment file, as per the payment types identified in the Commercial Model (e.g. Merchant Collection, Peer-to-Peer, Me-to-Me, Large Value Collection)

Confirmation of Payee

https://openfinanceuae.atlassian.net/wiki/x/7xWTFQ

Currently the Confirmation of Payee API requires the TPP to specify GivenName and LastName for personal beneficiary accounts. However, due to the inconsistency of how names are stored across LFIs, it is not always possible to get a match without the FullName.

Furthermore, the current matching algorithm only allows for a full match or no match.

In the Confirmation of Payee OpenAPI specifications the POST /confirmation endpoint will be updated as follows:

1. For personal accounts, FullName will be added as a mandatory field and both GivenName and LastName will be made optional, and

2. In the NameMatchIndicator response, the enum will be updated to include ConfirmationOfPayee.Partial.

The CX guidelines will also be updated to show how a partial match should be displayed to the User.

Furthermore, the API Hub will be updated to employ matching logic to support full match, partial match, and no match.

LendingRates - GET /accounts/{AccountId}/product

Bank Data OpenAPI

As set out here Future Functionality, we have defined a future requirement to ensure that Users can view and understand all charges, fees, interest charged on their financial credit based products (e.g. loans, mortgages, credit cards) through a TPP using Open Finance APIs — without granting the TPP access to the interest / profit rate charged data.

In the Pushed Authorization Request Endpoint OpenAPI specification, the POST /Par endpoint will be updated to allow the TPP to declare whether or not they will display LendingRates to the user as follows:

We will add an additional permission code, ReadProductLendingRates, that indicates the User wishes to share their product lending rates with the TPP.

In the Bank Data OpenAPI specification, the GET /accounts/{AccountId}/product endpoint will be updated to allow LFIs to provide one one of the following:

1. LendingRates as a JSON array, with properties encoded as JSON objects, without encryption. This will adhere to the current description of the LendingRates property.

2. LendingRates as a JWE, with the array and all child properties contained in the payload of the JWE.

Where LendingRates is returned as a JWE TPPs will be required to decrypt the data and parse it using the same Schema Object that describes the property in its unencrypted format.

The Business Rules will be expanded as follows:

If the TPP requests the LendingRates, the LFI MUST provide LendingRates either as a JSON array (without encryption) or a JWE.

If the LFI choses to provide a JWE, they MUST:

1. encrypt this object using a six digit OTP as the key,

2. immediately after responding to the API request, send the User the OTP (via either SMS and/or email) using standardized wording as defined in the CX Guidelines,

3. assign a strict expiry time of 30 minutes from the moment of encryption to the JWT, and

4. set the kid in the JWE header to the string "OTP".

If the TPP does not request the LendingRates, the LFI MUST NOT provide LendingRates in the API response and MUST NOT send an OTP to the User.

In the case where the LFI provides a JWE, and the TPP choses to display LendingRates to the User, the TPP MUST implement client side code (e.g. on the Users’s web or mobile device) which:

1. allows the User to enter the OTP (as provided by the LFI direct to the User) in the TPP’s web or mobile app interface,

2. uses this OTP to decrypt and display the rate to the User,

3. NOT transmit, store, or otherwise process the unencrypted LendingRates on their servers in any form or capacity,

4. ensures that the LendingRates do not persist in the User’s web or mobile application and expire at the end of the session and no later than 60 minutes after being displayed initially, and

5. present the decrypted LendingRates in a manner that is accurate, contextually appropriate, and faithfully represents the rates as provided by the LFI.

If the TPP wishes to re-display LendingRates to the User after this expiration, they will need to call the GET /accounts/{AccountId}/product endpoint again, which will require a new encryption/decryption process (including a new OTP).

The CX Guidelines (Customer Data) will be updated to include an example flow/screens for TPPs to display the rates and to show how the LFI should display the OTP to the User.

To use the ReadProductLendingRates permission, TPPs will need to have their architecture certified by Nebras as set out in ‘TPP decryption of product LendingRates’ in the Testing and Certification Framework.

These changes will only apply to LendingRates for Loans, Mortgages and Credit Cards.

Format of address blocks

All instances of the OpenAPI specs where a User’s address is defined

The User’s address has several different formats in the specifications throughout the standards. In order to simplify implementation for LFIs and TPPs, we are creating a single standard data model for this across all API specifications for banking and insurance.

The definition of Formatted Address definition will be changed in every occurrence to align with ISO20022 standard field names as follows:

• AddressType

• AddressLine (free formatted array of all address elements)

• BuildingNumber

• BuildingName

• Floor

• StreetName

• DistrictName

• PostBox

• TownName

• CountrySubDivision (will use the Emirates enumeration)

• Country (will use the CountryCode pattern)

All other field names (e.g. Formatted, BuildingType. Longitude, Latitude will be removed)

AddressLine and Country, will be mandatory. All other fields will be conditional.

The Business Rules will be updated to make CountrySubDivision (i.e. Emirate) mandatory for TPPs providing a User’s address through any POST operation (including Quotes).

FX and Remittance Quotes

FX & Remittance Quote & Service Initiation | Quote Generation

Currently FXRQT-4 - Quote Generation Business Rule 4.3 does not allow LFIs to display a lower FX rate via Open Finance versus their direct channels.

FXRQT-4 - Quote Generation Business Rule 4.3 will be amended as follows:

Quote the same or lower actual (deal) FX rate and charges as it would be offered to the User via the LFIs' equivalent direct channels such as mobile or online banking, for personalized and non-personalized quotes, when using the same quote parameters.

Parties Endpoint

Bank Data OpenAPI

The parties endpoint lacks critical information required by TPPs to effectively identify and link customers across Open Finance connections. Without these key fields, TPPs are unable to establish a reliable identity match.

Change the specification of the parties endpoint such that within the structure:

data[].verifiedClaims[].claims

where the schema is oneOf[1], the following data fields will now be mandatory:

• fullName

• givenName

• surname

• emiratesId

• emiratesIdExpiryDate

• residentialAddress (as discussed in Section 5 above)

Confirmation of Payee OpenAPI

tbc

tbc

Bank Data OpenAPI

tbc

tbc