Page Comparison

Authentication#1.4.2-Multi-factor-Authentication

151850897

210799644/

Limits

Payments+with+

and

Delegated+

Constants#A.-Limits67

4

Common Components

TPPs

The entry A17 Max FDP Payment Initiation Time Interval must be defined to be 10min instead of 5sec to align to the token validity period.

Entry A17 has been updated as follows:

ID: A17

Name: Max FDP Payment Initiation Time Interval

Description: This is the period of time that TPPs MUST submit the FDP Payment Initiation Request to the OFP. The value defined for this is period is currently 10min. The OFP will reject the Payment Initiation Request is submitted outside this time window.

Update to authentication factors that TPP can use for MFA.	User biometrics, dynamic tokens (using Authenticator apps Authy, Google Authenticator, and Microsoft Authenticator etc. or RFID), mobile phone, plastic card, and other User identification (e.g. Emirates ID).
75	4	Banking	https://openfinanceuae.atlassian.net/wiki/

spaces/standardsv1final/pages/151847164/User+Experience+Principles#11.-Other-Rules-for-User-Journeys

LFIs & TPPs

In Errata2, a rule was added to User Experience Principles to state that “LFIs and TPPs MUST implement their customer experience screens in line with what is provided in each Customer Experience section of the Standard for the relevant functionality. This includes colors, branding, spacing and component design.”, without provision of the necessary assets.

View file

name	Altareq.zip

The relevant logos and color codes are attached and are to be implemented in line with the customer experience screens provided in the Standard.

68

x/BYyQD	TPPs	Previous version incorrectly included a duplicate transaction scenario, stating that TPPs should detect where Users have triggered duplicate transactions and display error message to warn about this. However, there are no BRs requesting TPPs to detect transaction duplicates.	Page has been updated to remove this entry from the PIS scenarios.
76	4	Banking	https://openfinanceuae.atlassian.net/wiki/x/BYyQD	TPPs	Scenario trigger in first entry in the table is incorrectly stated to be Creditor LFI,	Removed Creditor LFI from the first entry scenario triggers.
77	4	Banking	https://openfinanceuae.atlassian.net/wiki/

spaces/standardsv1final/pages/151849156/International+Payments#3.2-Long-lived-International-Payment-Consents

Link to the Periodic Payment Schedule of Multi-Payments is incorrect.

Updated section 3.2 with the correct link, as follows:

“Long-lived multi-payment consents can be combined with International Payments to enable Service Initiation capabilities for recurring cross-border payments. The initial scope of the Standard will supporting Fixed Recurring IP Payments as follows:

Fixed Payment Amount: This can either be in account currency or payment currency, if FX is involved in the payment

Recurring Schedule: Fixed periodic payment schedule as defined in

x/BYyQD	TPPs	Table incorrectly includes PIS stage of Proxy Lookup which is currently out of scope of the Open Finance Standard.	Removed the Proxy Lookup entry from the table
78	4	Banking	https://openfinanceuae.atlassian.net/wiki/

spaces/standardsv1final/pages/151848909/Multi-Payments#8.2.1-Periodic-Payment-Schedule

Initiated from a User’s payment account held by the LFI in local or foreign currency

To a specific Creditor (Beneficiary) owning a payment account located abroad (cross-border)”

69

x/BYyQD	TPPs	Insufficient Funds entry is incorrectly stated as Beneficiary Add and/or Activation PIS stage, instead of Select Account & Confirmation.	Changed the PIS stage to Select Account & Confirmation for the Insufficient Funds scenario
79	4	Banking	https://openfinanceuae.atlassian.net/wiki/spaces/

standardsv1final

210800446/Common+Rules+and+Guidelines#9.3-Additional-TPP-Obligations

151849156/International+Payments#4.5-Payment-Charge-Model-for-International-Payments

TPPs

Rule 4.5.1 of https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151849156/International+Payments#4.5-Payment-Charge-Model-for-International-Payments requires mapping of the user language for the charge bearer model to the values used in the API Description.

Updated rule 4.5.1 as follows:

“TPPs MUST:

4.5.1 Either allow Users to select the charge model for the international payment order. This can be one of the following:

“SHA” or “Shared”:The sender User of the payment will pay fees to the sending LFI for the outgoing transfer charges. The receiving beneficiary will receive the amount transferred, minus the correspondent (intermediary) LFI charges. Thus, transaction charges on the receiver side are borne by the creditor by deducting these from the received amount. This value maps to the ISO 200022 code name “SHAR”.“OUR” or “Borne By Debtor”:All fees will be charged to the sender User of the payment – i.e. the receiving beneficiary gets the full amount sent by the sender of the payment. Any charges applied by the receiving LFI will be billed to the sender of the payment (usually sometime after sending the payment). This value maps to the ISO 200022 code name “DEBT”.“BEN” or “Borne By Creditor”:BEN (beneficiary) means that the sender User of the payments does not pay any charges. The receiver beneficiary of the payment receives the payment minus all transfer charges, including the sending LFI charges if any. This value maps to the ISO 200022 code name “CRED”.70

TPPs

Further clarification was required to indicate the TPP’s obligation to capture the User’s Emirates ID in certain scenarios.

TPPs MUST

“CRG-9.3.2.1 Capture a user's Emirates ID for all payments where a long-lived consent is required.

CRG-9.3.2.2 Capture a user's Emirates ID for all data sharing use cases where transaction data is shared, regardless of the consent type.

CRG-9.3.2.3 Capture the user’s Emirates ID prior to initiating the prescribed user journey for the relevant use case.

When a user is known to the TPP, the Emirates ID can be captured during onboarding.
When a user is unknown to the TPP, the Emirates ID can be captured prior to the consent customer journey.

Note: TPPs are not required to verify the Emirates ID.”

80

4

Banking

https://openfinanceuae.atlassian.net/wiki/spaces/

standardsv1final

210800446/Common+Rules+and+Guidelines#9.1-TPP-Obligations

151849156/International+Payments#4.7-External-Purpose-Code

TPPs

Links in the section are incorrectly displayed.

Updated section 4.7 with the correct links, as follows:

“TPPs MUST:

4.7.1 Support all category purpose codes including their descriptions as defined in the international https://www.iso20022.org/catalogue-messages/additional-content-messages/external-code-sets in order to be able to support the requirements for International Payments.

4.7.2 Either allow Users to select the available purpose of payment from a list or pre-populate it for Users.

4.7.3 Ensure and validate that the format of the payment purpose is according to the international https://www.iso20022.org/catalogue-messages/additional-content-messages/external-code-setsformat.”

71

TPPs

Further clarification was required to include additional data in the risk block, and specify which data is mandatory, conditional or optional.

The risk block table has been updated to include additional fields, as well as indicators of which fields are mandatory, conditional or optional.

81

4

Banking

https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1dot1final/pages/210798789/International+Payments#3.-Customer-Experience

TPPs

An additional rule was required to specify a payment limit for first-time payments to new beneficiaries.

TPPs MUST

“8.3 Impose a payment limit of 15000 AED for all first-time payments made to a new beneficiary.

8.3.1 Impose the limit for a duration of 48 hours
- This limit must apply to the sum of multiple payments within the 48 hour period
8.3.2 Revert to the channel limit thereafter.”

82

4

Banking

https://openfinanceuae.atlassian.net/wiki/

spaces/standardsv1final/pages/151850813/Common+Rules+and+Guidelines#1.-Supported-Accounts-%26-Payment-Rails

LFIs

Rule CRG-1.4.2 of

x/HIyQD

TPPs

Enhancement of the authentication method required for payments with Delegated SCA.

https://openfinanceuae.atlassian.net/wiki/spaces/

standardsv1final

spaces/standardsv1dot1final/pages/210800446/Common+Rules+and+Guidelines#1.-Supported-Accounts-%26-Payment-Rails

151850813

Common

Rules

and

Guidelines#1

Supported

Accounts

%26

Payment-Rails states that “In the scenario that IPP is unavailable,

Delegated-Authentication

1.4.1 The authentication methods are limited to the following:

User biometrics on a mobile device: such as fingerprint or facial recognition executed on the customer’s device, where a TPP app is also bound
Dynamic tokens on a mobile device: generated by authenticator apps (e.g.

maintenance) and planned downtime, the LFIs MUST NOT route the Open Finance payments via other payment systems. Instead, LFIs MUST keep the status of the payment to pending and process the payment as normal when IPP is available again.”
The rule will not change to require LFIs to reject the payments if IPP is unavailable.

Rule CRG-1.4.2 has been updated as follows:

“LFIs MUST:

CRG-1.4.2 In the scenario that IPP is unavailable, for example, it is going through maintenance and planned downtime, the LFIs MUST reject the payment and set the status of the payment to the Rejected terminal state.”

72

4

Banking

, Authy, Google Authenticator, Microsoft Authenticator) on the customer’s device, where a TPP app is also bound NFC-based trigger on a mobile device: used as a possession factor through Near Field Communication for secure, contactless verification, on the customer’s device, where a TPP app is bound and logged in NFC based trigger on another IoT device: The device holds credentials that can be used to verify the User identity, provisioned in conjunction with a TPP service. The device MUST have a biometric capability, a means to securely store a private key that is uniquely linked to the User, and can only be activated on presentment of a supported biometric gesture linked to the device.
83	4	Common Components	https://openfinanceuae.atlassian.net/wiki/

x/zQcNCQ

TPPs

Throughout the https://openfinanceuae.atlassian.net/wiki/x/zQcNCQreferences to Variable-defined consent has been changed to Fixed-defined consent. That is to allow a new type of predefined schedule with known dates but unknow values. This type was introduced as Variable-defined consent keeping in alignment with the wording structures of Fixed/Variable for payment amounts.

The

TPP & LFIs

Provide clarifications to ensure that channels and use cases are mutually supportive.

https://openfinanceuae.atlassian.net/wiki

/x/zQcNCQ page has been updated as follows:

All references to Variable-defined have been replaced with Fixed-defined.
A new consent type definition was introduced called Variable-defined. This was added to all the required places in the page.
A new variation entry was introduced https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1dot1final/pages/210798542/Multi-Payments#3.3.5-Variable-Recurring-Payments-(VRPs)---Variable-defined-Consent
Image Removed

New object to reflect `VariableOnDemand` payment type - which better reflect Business Rules

Errata version

Section

Subsection

Impacts

Description

Action

1

/spaces/standardsv1dot1final/pages/210800446/Common+Rules+and+Guidelines#1.-Supported-Accounts-%26-Payment-Rails

The inclusion of CRG-1.6, CRG-1.7 & CRG-1.8.

Technical Specifications

	Errata version	Section	Subsection	Impacts	Description	Action
1	1	Common Components	Pushed Authorization Request Endpoint OpenAPI	Updated in `errata4`	The `PeriodSchedule` shows all 3 schedule types - `DefinedSchedule`, `FixedPeriodicchedule` and `VariablePeriodicSchedule` as being as mandatory instead of `oneof`	Implementers should follow the specification as per `uae-bank-initiation-openapi.yaml`.
2	1	Common Components	Pushed Authorization Request Endpoint OpenAPI	Updated in `errata4`	The optional `Type` string field within the `VariablePeriodicSchedule` object (`MultiPayment`) is no longer applicable and should have been removed.	Implementers should follow the specification as per `uae-bank-initiation-openapi.yaml`.
3	1	Common Components	Pushed Authorization Request Endpoint OpenAPI	Updated in `errata4`	The `MultiPayment` object shows the `Amount` object as being as mandatory instead of optional.	Implementers should follow the specification as per `uae-bank-initiation-openapi.yaml`.
4	1	Common Components	Pushed Authorization Request Endpoint OpenAPI	Updated in `errata4`	The `MultiPayment` object shows the `MaximumIndividualPaymentAmount` object as being as mandatory instead of optional.	Implementers should follow the specification as per `uae-bank-initiation-openapi.yaml`.
5	1	Common Components	Pushed Authorization Request Endpoint OpenAPI

Chris Wood

TPPs

The

PeriodSchedule shows all 3 schedule types - DefinedSchedule, FixedPeriodicchedule and VariablePeriodicSchedule

Subscription object and the Webhook object are shown as being as mandatory instead of

“oneof”2

optional.

Implementers should follow the specification as per uae-bank-initiation-openapi.yaml.

The specification in uae-pushed-authorization-endpoint-openapi.yaml will be updated in the next version.

6

1

Common Components

The optional Type string field within the VariablePeriodicSchedule object (MultiPayment) is no longer applicable and should have been removed.3

LFIs

TPPs

The enumerations listed within the AccountSubType parameter reflect the legacy list of account sub types instead of CurrentAccount and Savings

Implementers should follow the specification as per uae-bank-initiation-openapi.yaml.

The specification in uae-pushed-authorization-endpoint-openapi.yaml will be updated in the next version.

7

1

Common Components

The MultiPayment object shows the Amount object as being as mandatory instead of optional.

LFIs

TPPs

Within the FilePayment object, the RequestedExecutionDateTime parameter should have been renamed to RequestedExecutionDate

Implementers should follow the specification as per uae-bank-initiation

-openapi.yaml.The specification in uae-pushed-authorization-endpoint

-openapi.yaml

will be updated in the next version

.

4

8

19

2

Common Components

LFIs

The MultiPayment object shows the MaximumIndividualPaymentAmount object as being as mandatory instead of optional.

Implementers should follow the specification as per uae-bank-initiation-openapi.yaml.

The specification in uae-pushed-authorization-endpoint-openapi.yaml will be updated in the next version.

5

1

Common Components

The Subscription object and the Webhook object are shown as being as mandatory instead of optional.

Implementers should follow the specification as per uae-bank-initiation-openapi.yaml.

The specification in uae-pushed-authorization-endpoint-openapi.yaml will be updated in the next version.

6

1

Common Components

The enumerations listed within the AccountSubType parameter reflect the legacy list of account sub types instead of CurrentAccount and Savings

Implementers should follow the specification as per uae-bank-initiation-openapi.yaml.

The specification in uae-pushed-authorization-endpoint-openapi.yaml will be updated in the next version.

7

1

Common Components

Within the FilePayment object, the RequestedExecutionDateTime parameter should have been renamed to RequestedExecutionDate

Implementers should follow the specification as per uae-bank-initiation-openapi.yaml.

The specification in uae-pushed-authorization-endpoint-openapi.yaml will be updated in the next version.

8

2

Common Components

The Open Finance Standards do not provide a mechanism for the TPP to transmit a User identifier to the LFI prior to Authentication taking place. Having the mechanism to do this, supported by the standards, has been highlighted by ecosystem participants as a very important enhancement.

The Pushed Authorization Request (PAR) OpenAPI description has been updated to include the login_hint parameter, which is an OpenID Connect parameter that allows a Relying Party to send an indicator (“hint”) of the End User.

The open finance framework implementation of this parameter allows a TPP to send the Emirates ID or Trade License Number, as appropriate, using an encrypted JSON Web Token (JSON Web Encryption - JWE). The mechanics of creating the login_hint parameter value are described in the PAR OpenAPI description.

The steps for creating and processing the JWE are as follows:

The TPP shall:
1. Implement support for providing the Emirates ID or Trade License Number based on customer and use cases requirements.
2. Create the payload based on the details found in the PAR OpenAPI description.
3. Discover the JWKS endpoint for the LFI that holds the Customer account, to which the request will be directed.
4. Retrieve the public encryption key for the LFI.
5. Encrypt the payload as a JWE using the public encryption key for the LFI, and include indicators such as kid that will allow the LFI to correlate the corresponding private key.
6. Set the login_hint parameter to the value of the JWE.
7. Send the PAR to the LFI endpoint at the API Hub.
The OFP shall:
1. Pass the value of the login_hint parameter to the LFI at the Ozone Connect Validate and/or Augment operation, depending on their configuration.
The LFI shall:
1. Based on their implementation, select the private encryption key that matches the public key used by the TPP.
2. Decrypt the value of the login_hint parameter and deserialise the payload value.
3. Use the Emirates ID or Trade License Number as required in the processing of the Validate or Augment operation.

Please note that the use of login_hint is optional and is intended to provide for enhanced customer experiences based on foresight of the customer identity. It is not a replacement for Authentication and Authorization.

TPPs and LFIs should follow the described mechanism to implement using the login_hint parameter to send either the Emirates ID or Trade License Number with a Pushed Authorization Request.

12

OFP TPPs	The Open Finance Standards do not provide a mechanism for the TPP to transmit a User identifier to the LFI prior to Authentication taking place. Having the mechanism to do this, supported by the standards, has been highlighted by ecosystem participants as a very important enhancement.	The Pushed Authorization Request (PAR) OpenAPI description has been updated to include the `login_hint` parameter, which is an OpenID Connect parameter that allows a Relying Party to send an indicator (“hint”) of the End User. The open finance framework implementation of this parameter allows a TPP to send the Emirates ID or Trade License Number, as appropriate, using an encrypted JSON Web Token (JSON Web Encryption - JWE). The mechanics of creating the `login_hint` parameter value are described in the PAR OpenAPI description. The steps for creating and processing the JWE are as follows: The TPP shall: Implement support for providing the Emirates ID or Trade License Number based on customer and use cases requirements. Create the payload based on the details found in the PAR OpenAPI description. Discover the JWKS endpoint for the LFI that holds the Customer account, to which the request will be directed. Retrieve the public encryption key for the LFI. Encrypt the payload as a JWE using the public encryption key for the LFI, and include indicators such as `kid` that will allow the LFI to correlate the corresponding private key. Set the `login_hint` parameter to the value of the JWE. Send the PAR to the LFI endpoint at the API Hub. The OFP shall: Pass the value of the `login_hint` parameter to the LFI at the Ozone Connect Validate and/or Augment operation, depending on their configuration. The LFI shall: Based on their implementation, select the private encryption key that matches the public key used by the TPP. Decrypt the value of the `login_hint` parameter and deserialise the payload value. Use the Emirates ID or Trade License Number as required in the processing of the Validate or Augment operation. Please note that the use of `login_hint` is optional and is intended to provide for enhanced customer experiences based on foresight of the customer identity. It is not a replacement for Authentication and Authorization. TPPs and LFIs should follow the described mechanism to implement using the `login_hint` parameter to send either the Emirates ID or Trade License Number with a Pushed Authorization Request.
9	2	Common Components	Pushed Authorization Request Endpoint OpenAPI	TPPs	Several arguments of the JWT-Secured Authorization Request (JAR) implemented in Pushed Authorizaton Request Endpoint OpenAPI did not offer detailed descriptions for their usage.	The PAR Endpoint have been updated to offer more extensive document. TPPs should review the `description` values provided in the PAR Endpoint OpenAPI description.
10	2	Bank Data Sharing	Bank Data OpenAPI	Updated in `errata3`	The `Purpose` property in the Consent response was incorrectly labelled as optional	`Purpose` is now mandatory in the Consent response, with the `minItems` property set to 1 to indicate the array must not be empty.
11	2	Bank Service Initiation	Bank Service Initiation OpenAPI	LFIs TPPs	`PaymentTransactionId` was incorrectly labelled as mandatory, but could not be populated until a valid payment reference had been created at the payment rails on which the payment instruction was transmitted.	`PaymentTransactionId` is now optional, with additional description that states: “The PaymentTransactionId must be populated if the payment is processed by the LFI.”
12	2	Common Components	Pushed Authorization Request Endpoint OpenAPI	Updated in `errata3`	The `Purpose` property of the `AEAccountAccessAuthorizationDetailConsentProperties` Schema Object was incorrectly defined as optional.	`Purpose` is now mandatory, with the `minItems` property set to 1 to indicate the array must not be empty.
13	2	Common Components	Pushed Authorization Request Endpoint OpenAPI	TPPs	The `Subscription` property of all consent request Schema Object was labelled as mandatory. This was incorrectly defined as TPPs do not have to implement Event Notifications over Webhooks.	`Subscription` updated to be optional.
14	2	Common Components	Pushed Authorization Request Endpoint OpenAPI	LFIs TPPs	`AEAccountSubTypeCode` does not match the enumeration values found in the Data Sharing OpenAPI description.	`AEAccountSubTypeCode` updated to only `CurrentAccount` and `Savings`.
15	2	Common Components	Pushed Authorization Request Endpoint OpenAPI	Updated in `errata4`	`AEServiceInitiationDefinedSchedule` does not match the Bank Service Initiation OpenAPI description as `maxItems` should be set to 50.	The `Schedule` array of the `AEServiceInitiationDefinedSchedule` has been amended with the `maxItems` property set to 50.
16	2	Common Components	Pushed Authorization Request Endpoint OpenAPI

Several arguments of the JWT-Secured Authorization Request (JAR) implemented in Pushed Authorizaton Request Endpoint OpenAPI did not offer detailed descriptions for their usage.

The PAR Endpoint have been updated to offer more extensive document.

TPPs should review the description values provided in the PAR Endpoint OpenAPI description.

10

2

Bank Data Sharing

The Purpose property in the Consent response was incorrectly labelled as optional

Purpose is now mandatory in the Consent response, with the minItems property set to 1 to indicate the array must not be empty.

11

2

Bank Service Initiation

PaymentTransactionId was incorrectly labelled as mandatory, but could not be populated until a valid payment reference had been created at the payment rails on which the payment instruction was transmitted.

PaymentTransactionId is now optional, with additional description that states: “The PaymentTransactionId must be populated if the payment is processed by the LFI.”

13

LFIs TPPs	`RequestedExecutionDateTime` does not match the Bank Service Initiation OpenAPI description as the property has been renamed `RequestedExecutionDate` with the `format` property set to `date`.	The Schema Object `AERequestedExecutionDateTime` has been renamed `AERequestedExecutionDate` and the `format` value set to `date`.
17	2	Common Components	Pushed Authorization Request Endpoint OpenAPI	Updated in `errata4`	`AEServiceInitiationLongLivedPaymentConsent` does not match the Bank Service Initiation OpenAPI description as `Amount`, `MaximumIndividualPaymentAmount`, and `PeriodicSchedule` are set to mandatory.	The Schema Object `AEServiceInitiationLongLivedPaymentConsent` has been updated to remove mandatory fields.
18	2	Common Components	Pushed Authorization Request Endpoint OpenAPI	Updated in `errata4`	`AEServiceInitiationLongLivedPaymentConsentPeriodicSchedule` does not match the Bank Service Initiation OpenAPI description as it implements named properties rather than a `oneOf`.	`AEServiceInitiationLongLivedPaymentConsentPeriodicSchedule` has been updated to implement a `oneOf`.
19	2	Common Components	Pushed Authorization Request Endpoint OpenAPI

The Purpose property of the AEAccountAccessAuthorizationDetailConsentProperties Schema Object was incorrectly defined as optional.

Purpose is now mandatory, with the minItems property set to 1 to indicate the array must not be empty.

14

2

Updated in `errata4`	`AEServiceInitiationVariablePeriodicSchedule` does not match the Bank Service Initiation OpenAPI description as `MaximumCumulativeValueOfPaymentsPerPeriodType` and `MaximumCumulativeNumberOfPaymentsPerPeriodType` are labelled as mandatory.	`AEServiceInitiationVariablePeriodicSchedule` has been updated to make `MaximumCumulativeValueOfPaymentsPerPeriodType` and `MaximumCumulativeNumberOfPaymentsPerPeriodType` optional.
20	2	Common Components	Pushed Authorization Request Endpoint OpenAPI

The Subscription property of all consent request Schema Object was labelled as mandatory. This was incorrectly defined as TPPs do not have to implement Event Notifications over Webhooks.

Subscription updated to be optional.

2

LFIs

TPPs

The Amount and CurrencySchema Objects are not consistent with the same Schema Object in the Bank Service Initiation OpenAPI description.

Amount Schema Object renamed to AEActiveOrHistoricAmount and properties updated to match Bank Service Initiation definition. CurrencyCode renamed to AEActiveOrHistoricCurrencyCode and updated to match Bank Service Initiation definition.

21

3

Common Components

AEAccountSubTypeCode does not match the enumeration values found in the Data Sharing OpenAPI description.

AEAccountSubTypeCode updated to only CurrentAccount and Savings.

15

2

Common Components

AEServiceInitiationDefinedSchedule does not match the Bank Service Initiation OpenAPI description as maxItems should be set to 50.

The Schedule array of the AEServiceInitiationDefinedSchedule has been amended with the maxItems property set to 50.

16

172

LFIs

TPPs

Additional elements required from TPP to facilitate Billing for Data Sharing

AEAccountAccessAuthorizationDetailConsentProperties updated to include OpenFinanceBilling object.
This object has two mandatory fields - UserType and Purpose

        UserType:
          description: Type of User
          enum:

Retail
Corporate

        Purpose:
          description: Purpose of data sharing request
          type: string
          enum:

AccountAggregation
RiskAssessment
TaxFiling
Onboarding
Verification
QuoteComparison
BudgetingAnalysis
FinancialAdvice
AuditReconciliation

22

3

Common Components

RequestedExecutionDateTime does not match the Bank Service Initiation OpenAPI description as the property has been renamed RequestedExecutionDate with the format property set to date.

The Schema Object AERequestedExecutionDateTime has been renamed AERequestedExecutionDate and the format value set to date.

LFIs

TPPs

Additional elements required from TPP to facilitate Billing for Data Sharing

Purpose field has been moved into the OpenFinanceBilling object

23

3

Common Components

AEServiceInitiationLongLivedPaymentConsent does not match the Bank Service Initiation OpenAPI description as Amount, MaximumIndividualPaymentAmount, and PeriodicSchedule are set to mandatory.

The Schema Object AEServiceInitiationLongLivedPaymentConsent has been updated to remove mandatory fields.

182

TPPs

OFP

Version and servers read v1.0

Version and servers in OpenAPI document changed to v1.1 for consistency with rest of specification

24

3

Common Components

AEServiceInitiationLongLivedPaymentConsentPeriodicSchedule does not match the Bank Service Initiation OpenAPI description as it implements named properties rather than a oneOf.

AEServiceInitiationLongLivedPaymentConsentPeriodicSchedule has been updated to implement a oneOf.

19

2

202

TPPs

OFP

AEAccountAccessAuthorizationDetailsConsent fields incorrectly updated in draft3 to be capitalised (Type and Consent) - this is not compliant with the RAR spec

AEAccountAccessAuthorizationDetailsConsent updated to "type", "consent" and "subscription"

25

3

Common Components

AEServiceInitiationVariablePeriodicSchedule does not match the Bank Service Initiation OpenAPI description as MaximumCumulativeValueOfPaymentsPerPeriodType and MaximumCumulativeNumberOfPaymentsPerPeriodType are labelled as mandatory.

AEServiceInitiationVariablePeriodicSchedule has been updated to make MaximumCumulativeValueOfPaymentsPerPeriodType and MaximumCumulativeNumberOfPaymentsPerPeriodType optional.

TPPs

OFP

AEAccountAccessAuthorizationDetailsConsent fields incorrectly updated in draft3 to be capitalised (Type and Consent) - this is not compliant with the RAR spec

AEAccountAccessAuthorizationDetailsConsent updated to "type", "consent" and "subscription"

26

3

Common Components

TPPs

OFP

AEInsuranceAuthorizationDetailsConsent fields incorrectly updated in draft3 to be capitalised (Type and Consent) - this is not compliant with the RAR spec

AEInsuranceAuthorizationDetailsConsent updated to "type", "consent" and "subscription"

27

3

Common Components

The Amount and CurrencySchema Objects are not consistent with the same Schema Object in the Bank Service Initiation OpenAPI description.

Amount Schema Object renamed to AEActiveOrHistoricAmount and properties updated to match Bank Service Initiation definition. CurrencyCode renamed to AEActiveOrHistoricCurrencyCode and updated to match Bank Service Initiation definition.

21

TPPs

OFP

AEServiceInitiationAuthorizationDetailConsent fields incorrectly updated in draft3 to be capitalised (Type and Consent) - this is not compliant with the RAR spec

AEServiceInitiationAuthorizationDetailConsent updated to "type", "consent" and "subscription"

28

3

Common Components

LFIs

TPPs

Additional elements required from TPP to facilitate Billing for

Data Sharing

Insurance

AEAccountAccessAuthorizationDetailConsentProperties

OBInsuranceAuthorizationDetailConsentProperties updated to include OpenFinanceBilling object.
This object has

two

one mandatory fields -

UserType and

Purpose

UserType:
description: Type of User
enum:

Retail
Corporate

Purpose:
          description: Purpose of data sharing request
          type: string
          enum:

AccountAggregation
RiskAssessment
PremiumHistory

TaxFiling

ClaimHistory
Onboarding
Verification
QuoteComparison

BudgetingAnalysis

FinancialAdvice

AuditReconciliation

22

3

Common Components

Additional elements required from TPP to facilitate Billing for Data Sharing

Purpose field has been moved into the OpenFinanceBilling object

23

3

Common Components

version and servers - incorrectly updated in errata2

version and servers in OpenAPI document reverted back to v1.0 for consistency with rest of specification

24

3

Common Components

AEAccountAccessAuthorizationDetailsConsent fields incorrectly updated in draft3 to be capitalised (Type and Consent) - this is not compliant with the RAR spec

AEAccountAccessAuthorizationDetailsConsent updated to "type", "consent" and "subscription"

25

3

Common Components

AEAccountAccessAuthorizationDetailsConsent fields incorrectly updated in draft3 to be capitalised (Type and Consent) - this is not compliant with the RAR spec

AEAccountAccessAuthorizationDetailsConsent updated to "type", "consent" and "subscription"

26

3

Common Components

AEInsuranceAuthorizationDetailsConsent fields incorrectly updated in draft3 to be capitalised (Type and Consent) - this is not compliant with the RAR spec

AEInsuranceAuthorizationDetailsConsent updated to "type", "consent" and "subscription"

27

3

Common Components

AEServiceInitiationAuthorizationDetailConsent fields incorrectly updated in draft3 to be capitalised (Type and Consent) - this is not compliant with the RAR spec

AEServiceInitiationAuthorizationDetailConsent updated to "type", "consent" and "subscription"

28

3

Common Components

FinancialAdvice
29	3	Bank Data Sharing	Bank Data OpenAPI	LFIs TPPs	Consent response updated to align with PAR updates	AEReadConsentResponse updated to include OpenFinanceBilling OpenFinanceBilling has two mandatory fields specified by the TPP (UserType and Purpose); and one optional field specified by the LFI (IsLargeCorporate)
30	3	Bank Data Sharing	Bank Data OpenAPI	LFIs TPPs	It has been identified that some LFIs display beneficiary CreditorAccounts that include Credit Card accounts, Proxy accounts, and Utilities This affects beneficiaries, standing orders and scheduled payments	AECashAccount5_0 has been updated to allow for additional enumerations enum: IBAN AccountNumber MaskedPAN MobileNumber UtilityName EWallet
31	3	Bank Service Initiation	Bank Service Initiation OpenAPI	LFIs TPPs	Additional elements required from TPP to facilitate Billing for Payments	New object in the AEPaymentConsentResponse with one optional field specified by the LFI (IsLargeCorporate)
32	3	Bank Service Initiation	Bank Service Initiation OpenAPI	LFIs TPPs	Additional elements required from TPP to facilitate Billing for Payments	New object in the AEPaymentRequest and AEPaymentIdResponse with one mandatory field Type, and one optional field for the MerchantId - both specified by the TPP at point of payment initiation Type: enum: Collection LargeValueCollection PushP2P PullP2P Me2Me description: The type payment for billing MerchantId: description: "MerchantId" type: "string" minLength: 8 maxLength: 20
33	3	Bank Service Initiation	Bank Service Initiation OpenAPI	LFIs TPPs	Additional elements required from TPP to facilitate Billing for

Insurance

OBInsuranceAuthorizationDetailConsentProperties updated to include OpenFinanceBilling object.
This object has one mandatory fields - Purpose

        Purpose:
          description: Purpose of data sharing request
          type: string
          enum:

AccountAggregation
RiskAssessment
PremiumHistory
ClaimHistory
Onboarding
Verification
QuoteComparison
FinancialAdvice

29

3

Bank Data Sharing

Consent response updated to align with PAR updates

AEReadConsentResponse updated to include OpenFinanceBilling

OpenFinanceBilling has two mandatory fields specified by the TPP (UserType and Purpose); and one optional field specified by the LFI (IsLargeCorporate)

3033

3

Bank Service Initiation

Additional elements required from TPP to facilitate Billing for File Payments

New object in the AEFilePaymentIdResponse with one optional field for the NumberOfSuccessfulTransactions - updated by the LFI after the file is fully processed

34

3

Common Components

The existing PersonalIdentifiableInformation object supports only 1 creditor being identified for a payment consent

In the AEPaymentPII example in the PersonalIdentifiableInformation field - have made the creditor identification details an array to support original business requirements

This has not been updated in the Bank Initiation spec (as each individual payment will only have 1 creditor)

353

File Payments	New object in the AEFilePaymentIdResponse with one optional field for the NumberOfSuccessfulTransactions - updated by the LFI after the file is fully processed
34	3	Common Components	Pushed Authorization Request Endpoint OpenAPI	OFP TPPs	The existing PersonalIdentifiableInformation object supports only 1 creditor being identified for a payment consent	In the AEPaymentPII example in the PersonalIdentifiableInformation field - have made the creditor identification details an array to support original business requirements This has not been updated in the Bank Initiation spec (as each individual payment will only have 1 creditor)
35	3	Bank Service Initiation	Pushed Authorization Request Endpoint OpenAPI	LFIs TPPs	The DebtorAccount and CreditorAccount will be taken from the consent, so that an additional check is no longer required if only one DebtorAccount or CreditorAccount is specified in the consent	Removed DebtorAccount from the AEPaymentPII example in the PersonalIdentifiableInformation field - as this will be taken from the consent
36	3	Bank Data Sharing	Bank Data OpenAPI

It has been identified that some LFIs display beneficiary CreditorAccounts that include Credit Card accounts, Proxy accounts, and Utilities

This affects beneficiaries, standing orders and scheduled payments

AECashAccount5_0 has been updated to allow for additional enumerations

enum:

IBAN
AccountNumber
MaskedPAN
MobileNumber
UtilityName
EWallet

31

3

Bank Service Initiation

Additional elements required from TPP to facilitate Billing for Payments

New object in the AEPaymentConsentResponse with one optional field specified by the LFI (IsLargeCorporate)

32

3

Bank Service Initiation

Additional elements required from TPP to facilitate Billing for Payments

New object in the AEPaymentRequest and AEPaymentIdResponse with one mandatory field Type, and one optional field for the MerchantId - both specified by the TPP at point of payment initiation

Type:
enum:

Collection
LargeValueCollection
PushP2P
PullP2P
Me2Me

          description: The type payment for billing
        MerchantId:
          description: "MerchantId"
          type: "string"
          minLength: 8
          maxLength: 20

37

4

Common Components

TPP

Business Rules state that consent cannot be more than a year

ExpirationDateTime updated to mandatory in:

AEAccountAccessAuthorizationDetailConsentProperties
AEServiceInitiationAuthorizationDetailProperties
OBInsuranceAuthorizationDetailConsentProperties

38

4

Common Components

TPP

Reconsent objects removed from standard, as this is not part of the existing Business Rules

RichAuthorizationRequestObjects have Reconsent objects removed

39

LFIs TPPs	The account statuses did not match the regulations for Inactive, Dormant, and Unclaimed provided by CBUAE.	`AEAccountStatusCode` has been changed as follows: `NotActive` has been moved to `Inactive` and now references the CBUAE guidance on inactive status. `Dormant` now references the CBUAE guidance on dormant account status. `Unclaimed` now references the CBUAE guidance on unclaimed account status. `Suspended` has been clarified with more description to improve understanding.
37	4	Common Components	Pushed Authorization Request Endpoint OpenAPI	TPPs	Business Rules state that consent cannot be more than a year	`ExpirationDateTime` updated to mandatory in: `AEAccountAccessAuthorizationDetailConsentProperties` `AEServiceInitiationAuthorizationDetailProperties` `OBInsuranceAuthorizationDetailConsentProperties`
38	4	Common Components	Pushed Authorization Request Endpoint OpenAPI	TPPs	Reconsent objects removed from standard, as this is not part of the existing Business Rules	`RichAuthorizationRequestObjects` have Reconsent objects removed
39	4	Bank Service Initiation	Pushed Authorization Request Endpoint OpenAPI Bank Service Initiation OpenAPI	TPPs	`ReadRefundAccount` field has been simplified to be an option in the `Permissions` array	`ReadRefundAccount` field has been simplified to be an option in the `Permissions` array
40	4	Bank Service Initiation	Pushed Authorization Request Endpoint OpenAPI Bank Service Initiation OpenAPI	TPPs	The TPP is no longer expected to send in the `ExpectedInitiationWindow`, based on updated Business Rules	Removed `ExpectedInitiationWindow`
41	4	Bank Service Initiation	Pushed Authorization Request Endpoint OpenAPI Bank Service Initiation OpenAPI	TPPs	`IsPayByAccount` flag is not in the Business Rules	Removed `IsPayByAccount` flag
42	4	Bank Service Initiation	Pushed Authorization Request Endpoint OpenAPI

The DebtorAccount and CreditorAccount will be taken from the consent, so that an additional check is no longer required if only one DebtorAccount or CreditorAccount is specified in the consent

Removed DebtorAccount from the AEPaymentPII example in the PersonalIdentifiableInformation field - as this will be taken from the consent

36

3

Bank Data Sharing

The account statuses did not match the regulations for Inactive, Dormant, and Unclaimed provided by CBUAE.

AEAccountStatusCode has been changed as follows:

NotActive has been moved to Inactive and now references the CBUAE guidance on inactive status.
Dormant now references the CBUAE guidance on dormant account status.
Unclaimed now references the CBUAE guidance on unclaimed account status.
- Suspended has been clarified with more description to improve understanding.

41

Bank Service Initiation OpenAPI	TPPs LFIs (very minimal impact to LFIs - as it is purely a different way of identifying existing functionality)	For explicitness have added `IsDelegatedAuthentication` to indicate a TPP Delegated SCA model - for more explicit schema validation and non-repudiation	Added `IsDelegatedAuthentication` boolean flag
43	4	Bank Service Initiation	Pushed Authorization Request Endpoint OpenAPI Bank Service Initiation OpenAPI	TPPs LFIs (very minimal impact to LFIs - as it is purely a different way of identifying existing functionality)	`DefinedSchedule` to be better aligned with Business Rules	To simplify implementation and better align with Business Rules we have created a: `FixedDefinedSchedule` `VariableDefinedSchedule` These are both arrays of up to 53 items. The `FixedDefinedSchedule` is a pair of `PaymentExecutionDate` and `Amount` The `VariableDefinedSchedule` is a pair of `PaymentExecutionDate` and `MaximumIndividualAmount`
44	4	Bank Service Initiation	Pushed Authorization Request Endpoint OpenAPI Bank Service Initiation OpenAPI	TPPs LFIs (very minimal impact to LFIs - as it is purely a different way of identifying existing functionality)	`FixedPeriodicSchedule` and `VariablePeriodicSchedule` to be better aligned with Business Rules - to have payments initiated on dates that are on the `PeriodStartDate` + the subsequent `PeriodType`	Both `FixedPeriodicSchedule` and `VariablePeriodicSchedule` to have mandatory fields only. `VariablePeriodicSchedule` updated to have as mandatory only: `Type` `PeriodType` `PeriodStartDate` `MaximumIndividualAmount`
45	4	Bank Service Initiation	Pushed Authorization Request Endpoint OpenAPI Bank Service Initiation OpenAPI

TPP

ReadRefundAccount field has been simplified to be an option in the Permissions array

40

4

Bank Service Initiation

TPP

Errata for ExpectedInitiationWindow which is

Removed ExpectedInitiationWindow

TPPs

LFIs (very minimal impact to LFIs - as it is purely a different way of identifying existing functionality)

New object to reflect FixedOnDemand payment type - which better reflect Business Rules

FixedOnDemand to have mandatory:

Type
PeriodType
PeriodStartDate
Amount
Controls

Where Controls is an object with at least one of the following properties specified:

MaximumCumulativeValueOfPaymentsPerPeriod
MaximumCumulativeNumberOfPaymentsPerPeriod

46

4

Bank Service Initiation

TPP

IsPayByAccount flag is not in the Business Rules

Removed IsPayByAccount flag

42

4

Bank Service Initiation

TPP

For explicitness have added IsDelegatedSCA to indicate a TPP Delegated SCA model - for schema validation and non-repudiation

Added IsDelegatedSCA boolean flag

43

4

Bank Service Initiation

TPP

DefinedSchedule to be better aligned with Business Rules

To simplify implementation and better align with Business Rules we have created a:

FixedDefinedSchedule
VariableDefinedSchedule

These are both arrays of up to 53 items.

The FixedDefinedSchedule is a pair of PaymentExecutionDate and Amount
The VariableDefinedSchedule is a pair of PaymentExecutionDate and MaximumIndividualAmount

44

4

Bank Service Initiation

TPP

FixedPeriodicSchedule and VariablePeriodicSchedule to be better aligned with Business Rules - to have payments initiated on dates that are on the PeriodStartDate + the subsequent PeriodType

Both FixedPeriodicSchedule and VariablePeriodicSchedule to have mandatory fields only.

VariablePeriodicSchedule updated to have as mandatory only:

Type
PeriodType
PeriodStartDate
MaximumIndividualAmount

45

4

Bank Service Initiation

TPP

New object to reflect FixedOnDemand payment type - which better reflect Business Rules

FixedOnDemand to have mandatory:

Type
PeriodType
PeriodStartDate
Amount
Controls

Where Controls is an object with at least one of the following properties specified:

MaximumCumulativeValueOfPaymentsPerPeriod
MaximumCumulativeNumberOfPaymentsPerPeriod

46

4

Bank Service Initiation

TPP

New object to reflect VariableOnDemand payment type - which better reflect Business Rules

VariableOnDemand to have mandatory:

Type
PeriodType
PeriodStartDate
Controls

Where Controls is an object with at least one of the following properties specified:

MaximumIndividualAmount
MaximumCumulativeValueOfPaymentsPerPeriod
MaximumCumulativeNumberOfPaymentsPerPeriod

47

4

Bank Service Initiation

TPP

Removed duplication of MaximumIndividualPaymentAmountand Amount at the MultiPayment consent top level - as is now duplication

Removed duplication of MaximumIndividualPaymentAmount and Amount at the MultiPayment consent top level

48

4

Bank Service Initiation

TPP and LFI

Errata for PaymentConsumption object as errata:

CumulativeValueOfPaymentsPerPeriod is not always relevant for a Long Lived Payment Consent - however, is marked as mandatory
CumulativeNumberOfPaymentsPerCurrentPeriodsuggests that this is the same value for all period - however, the intent is that this is only for the current period
CumulativeValueOfPaymentsPerCurrentPeriodsuggests that this is the same value for all period - however, the intent is that this is only for the current period
CumulativeNumberOfPaymentsPerCurrentPeriod and CumulativeValueOfPaymentsPerCurrentPeriod are intended to include all payments except for payments in a Rejected state

Updates:

CumulativeValueOfPaymentsPerPeriod updated from mandatory to optional
CumulativeNumberOfPaymentsPerCurrentPeriod renamed to CumulativeNumberOfPaymentsInCurrentPeriodsuggests
CumulativeValueOfPaymentsPerCurrentPeriodrenamed to CumulativeValueOfPaymentsInCurrentPeriod
CumulativeValueOfPaymentsPerCurrentPeriod, and CumulativeValueOfPaymentsInCurrentPeriod definitions updated to “The cumulative value of payment instructions in the current period initiated under the consent schedule, excluding instructions in a Rejected state.“

49

4

Bank Service Initiation

TPP

PersonalIdentifiableInformation object is now optional for the POST /payments action - as these details may be derived in most cases from the consent (after changes in v1.0-errata3)

PersonalIdentifiableInformation is optional in POST /payments request

50

4

Bank Service Initiation

TPP

ChargeBearer for International Payments does not need the FollowingServiceLevel option

Updated ChargeBearer to only

Code Block
- "BorneByCreditor" - "BorneByDebtor" - "Shared"

51

4

Bank Data Sharing

LFI

PartyType and AccountRole describe customer to account relationship - so are not relevant for the /parties endpoint

Removed PartyType and AccountRole from the GET /parties endpoint response

TPPs

LFIs (very minimal impact to LFIs - as it is purely a different way of identifying existing functionality))

New object to reflect VariableOnDemand payment type - which better reflect Business Rules

VariableOnDemand to have mandatory:

Type
PeriodType
PeriodStartDate
Controls

Where Controls is an object with at least one of the following properties specified:

MaximumIndividualAmount
MaximumCumulativeValueOfPaymentsPerPeriod
MaximumCumulativeNumberOfPaymentsPerPeriod

47

4

Bank Service Initiation

TPPs

LFIs (very minimal impact to LFIs - as it is purely a different way of identifying existing functionality)

Issues with MultiPayment consent top level:

Duplication of MaximumIndividualPaymentAmountand Amount
PeriodicSchedule is optional and should be mandatory to enforce payment type selection

Removed duplication of MaximumIndividualPaymentAmount and Amount at the MultiPayment consent top level

Updated PeriodicSchedule to mandatory

48

4

Bank Service Initiation

LFIs

TPPs

Errata for PaymentConsumption object as errata:

CumulativeValueOfPaymentsPerPeriod is not always relevant for a Long Lived Payment Consent - however, is marked as mandatory
CumulativeNumberOfPaymentsPerCurrentPeriodsuggests that this is the same value for all period - however, the intent is that this is only for the current period
CumulativeValueOfPaymentsPerCurrentPeriodsuggests that this is the same value for all period - however, the intent is that this is only for the current period
CumulativeNumberOfPaymentsPerCurrentPeriod and CumulativeValueOfPaymentsPerCurrentPeriod are intended to include all payments except for payments in a Rejected state

Updates:

CumulativeValueOfPaymentsPerPeriod updated from mandatory to optional
CumulativeNumberOfPaymentsPerCurrentPeriod renamed to CumulativeNumberOfPaymentsInCurrentPeriodsuggests
CumulativeValueOfPaymentsPerCurrentPeriodrenamed to CumulativeValueOfPaymentsInCurrentPeriod
CumulativeValueOfPaymentsPerCurrentPeriod, and CumulativeValueOfPaymentsInCurrentPeriod definitions updated to “The cumulative value of payment instructions in the current period initiated under the consent schedule, excluding instructions in a Rejected state.“

49

4

Bank Service Initiation

TPPs

PersonalIdentifiableInformation object is now optional for the POST /payments action - as these details may be derived in most cases from the consent (after changes in v1.0-errata3)

PersonalIdentifiableInformation is optional in POST /payments request

50

4

Bank Service Initiation

TPPs

ChargeBearer for International Payments does not need the FollowingServiceLevel option

Updated ChargeBearer to only

Code Block
- "BorneByCreditor" - "BorneByDebtor" - "Shared"

51

4

Bank Data Sharing

LFIs

PartyType and AccountRole describe customer to account relationship - so are not relevant for the /parties endpoint

Removed PartyType and AccountRole from the GET /parties endpoint response

52

4

Common Components

LFIs

TPPs

OpenAPI description did not convey the decoded version of the property, making it difficult for implementers to understand.

PII types (Payment, login_hint) now implement a oneOf to allow both the encoded and decoded property structure to be understood.

53

4

Insurance

Insurance OpenAPI

TPPs

API operations to retrieve policies were not differentiated by industry, which has been highlighted as being desirable in early industry sessions for the next insurance release.

API operations for motor insurance are now hosted at /motor-insurance-policies.

54

4

Bank Service Initiation

TPPs

The CreditorAgent does not have the option to select the BIC

Extended the enumeration to the CreditorAgent.SchemeName to include BICFI
Removed restriction to CreditorAgent.Identification of maxLength 6

55

4

Bank Service Initiation

TPPs

The PaymentSequenceNumber is legacy and there are no TPP or LFI Business Rules relating to its use

Removed PaymentSequenceNumber

56

4

Bank Service Initiation

TPPs

DebtorReference implements two Schema Objects with oneOf, each with a pattern property, which caused problems for tooling.

Merged two Schema Objects into one, with one pattern property supporting both Schema Objects from previous version.

57

4

Bank Service Initiation