This section provides additional information and guidelines to TPPs and LFIs in relation to the status of the payment consent and the payment initiation process. The information covers both a) short-lived consents for Single Instant Payments (SIPs), Future Dated Payments (FDPs) and single International Payments and, b) long-lived consents for Multi-Payments including also Fixed Recurring International Payments. More specifically, the additional information will cover the following:

• The status any time after staging the payment Consent and the submission of payment Initiation request.

• The meaningful status messages and reason codes of why the staged payment Consent or submitted payment Initiation request is stopped in a particular stage of the process.

• The confirmation that the payment Initiation request has been received and executed.

• Enriched list of reasons for failures through the initiation, processing and execution stages. This includes the list of underlying payment system reasons for failure post execution at the Creditor LFI (such as for Aani payment system and the UAE Funds Transfer System, UAEFTS). 

The Open Finance Standard has the capability to allow LFIs to provide TPPs with the following payment status information: 

• The status any time after the submission of the payment initiation request for all supported payment types, including SIPS, FDPs, single International Payments (immediate and future-dated), Fixed Recurring International Payments and all types of domestic Multi-Payments.

• A meaningful status message to the TPP for each processing phase and particularly when settlement on the debtor’s account has been completed, thus providing the TPP with a sufficient status message that the payment will be sent to the receiving LFI.

• A confirmation that the payment has been executed and has been received by the Creditor LFI (e.g. provide the status message ‘ACWP’ which means ‘Accepted Without Posting’ or in some cases ‘ACCC’ which means ‘Accepted Settlement Completed Creditor Account’).

The below diagram depicts the whole process flow for a Single Payment based on a generic payment system. The Open Finance Standard has been designed to have the capability to be payment agnostic, without specific dependency on the underlying payment system used for the payment execution.

Open

The following timings are the timing periods involved in the payment initiation process of the Open Finance when using a generic payment system:

1. Payment Consent Response: The response time to the payment Consent POST /par endpoint call, as per the performance obligations as stated in https://openfinanceuae.atlassian.net/wiki/spaces/6af317645dd64444b360d51d5bfb6d46/pages/321230293/Availability+Performance+and+Usage+Benchmarks#4.-API-Performance. For the context of this page we refer to this as OFP SLA 1 (Please note that this is an average timing requirement).

2. Get Consent status: The response time to the payment Consent resource GET /payment-consents/{ConsentId} endpoint call, as per the performance obligations as stated in https://openfinanceuae.atlassian.net/wiki/spaces/6af317645dd64444b360d51d5bfb6d46/pages/321230293/Availability+Performance+and+Usage+Benchmarks#4.-API-Performance.For the context of this page we refer to this as OFP SLA 1 (Please note that this is an average timing requirement).

3. Consent Event Notification: This is the time taken for the event notification POST {WebhookUrl} endpoint call to be initiated and sent to the TPP by the API HUB, following a change of status of the Consent resource. For the context of this page we refer to this as OFP SLA 3. This timing is as defined in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv2dot0final/pages/361961770/Limits+and+Constants#Event-Notification-SLA-(OFP-SLA-3).

4. Payment Initiation Response: The response time to the payment Initiation request POST /payments endpoint call, is as per the performance obligations as stated in https://openfinanceuae.atlassian.net/wiki/spaces/6af317645dd64444b360d51d5bfb6d46/pages/321230293/Availability+Performance+and+Usage+Benchmarks#4.-API-Performance. For the context of this page we refer to this as OFP SLA 1 (Please note that this is an average timing requirement).

5. Get Payment status: The response time to the Payment resource GET /payments/{PaymentId} endpoint call, as per the performance obligations as stated in https://openfinanceuae.atlassian.net/wiki/spaces/6af317645dd64444b360d51d5bfb6d46/pages/321230293/Availability+Performance+and+Usage+Benchmarks#4.-API-Performance. For the context of this page we refer to this as OFP SLA 1 (Please note that this is an average timing requirement).

6. Payment Event Notification: This is the time taken for the event notification POST {WebhookUrl} endpoint call to be initiated and sent to the TPP by the API HUB, following a change of status of the Payment resource. For the context of this page we refer to this as OFP SLA 3. This timing is as defined in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv2dot0final/pages/361961770/Limits+and+Constants#Event-Notification-SLA-(OFP-SLA-3).

7. Payment Status Update: This is the time required by the LFI to update the Payment resource status, using a PATCH /payments/{PaymentId} endpoint, with the latest status update, immediately after receiving a response from the generic payment system, if any. For the context of this page we refer to this as OFP SLA 2. This timing is as defined in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv2dot0final/pages/361961770/Limits+and+Constants#Payment-Status-Update-(OFP-SLA-2).

The below diagram depicts the whole process flow for a Single Instant Payment (SIP) with the Aani payment system.

Open

The following timings are the timing periods involved in the payment initiation process of the Open Finance when using the Aani payment system.

1. All timings 1 - 7 of the generic payment system, with definitions as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv2dot0final/pages/361960285/Payment+Status+Information#2.1.1-Timings-for-the-Payment-Initiation-using-a-Generic-Payment-System.

2. Aani T1: This is the time from the point in time the LFI received the payment Initiation request till the pacs008 Credit Transfer is received by the Aani Core system. This timing is as defined in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv2dot0final/pages/361961770/Limits+and+Constants#Aani-T1.

3. Aani T2: This is the time taken by the Aani System to validate the credit transfer and forward the Real Time Credit Transfer to the Creditor LFI or responds to the Debtor LFI with a negative response. This timing is as defined in Limits and Constants | Aani T2Preview.

4. Aani T4: This is the time taken by the Aani System to receive the response (Accepted or Rejected) to the Account Verification from the Creditor LFI. This timing is as defined in Limits and Constants | Aani T4Preview.

5. Aani T5: This is the time taken by the Aani System to sent the Transaction confirmation or the Transaction rejection messages to the Debtor LFI and the Creditor LFI. This timing is as defined in Limits and Constants | Aani T5Preview.

Open

<TBC>

<TBC>

Following the payment Consent staging by the TPP to the API HUB/LFI:

OFP MUST:

• PSI-3.1.1.1 Create a new payment Consent resource, if the new Consent request has been validated successfully. The status of the payment Consent at this point MUST be initialized to ‘Awaiting Authorization’. The API HUB/LFI MUST respond back to the TPP that the new Consent request has been successful (HTTP 201 status) and include the payment resource Consent status of ‘Awaiting Authorization’ and the Consent ID.

• PSI-3.1.1.2 Sent back to the TPP, a HTTP 4xx series response with a failure reason code(s), if the new Consent request failed to be validated by the API HUB or the LFI. There may be more than one reasons for failure. 

• A ‘GET’ status call by the TPP at this stage would also respond with status ‘Awaiting Authorization’. If the staging is unsuccessful, the TPP MUST rely on the error reason code(s) provided by the API HUB/LFI in the HTTP 4xx series response message to identify the issue. 

Open

Figure 1 : Staged Payment Consent

Note: The Consent may not move to its next natural stage of ‘Authorized’ or ‘Rejected’ by a User action at the authorization stage with the LFI. This may happen when the User is not redirected to the LFI for authentication, the User fails to complete authentication or various other reasons. In this case, the API HUB MUST move it to ‘Rejected’ state after timeout as per Limits and Constants | Max Submitter Authorization Time WindowPreview and populate the appropriate error reason code(s) (e.g. Authorization not completed). For example:

If the payment Consent is staged successfully, the User is redirected to the LFI for authentication and authorization of the Consent.

If, the User authenticates successfully, then: 

LFIs MUST:

• PSI-3.1.2.1 Move the status of the payment Consent to ‘Authorized', in case there is no additional call to action for the User after authentication, such as in Single Instant Payments | 3.2 Fast track JourneyPreview. This is because the authentication action is also considered to be the User’s authorization.

• PSI-3.1.2.2 Set the status of the payment Consent to ‘Authorized’, in case there is additional call to action for the User after authentication, such as in Single Instant Payments | 3.1 Standard JourneyPreview, and the User’s decision was to proceed with the payment (or the long-lived payment Consent). This is because the User’s decision to proceed is considered to be the User’s authorization. For example:

Status Code	Status Reason Code	Status Reason Description
Authorized	<empty>	<empty>

LFIs MUST:

• PSI-3.1.2.3 Set the status of the payment Consent to ‘Rejected', in case there is additional call to action for the User after authentication, such as in Single Instant Payments | 3.1 Standard JourneyPreview, and the User’s call to action leads to the User cancelling the payment (or the long-lived payment Consent).

• PSI-3.1.2.4 Set the status of the payment Consent to ‘Rejected', if the User fails to complete authentication (e.g. after x attempts), and the payment Consent may be rejected by the LFI.

• PSI-3.1.2.5 Set the status of the payment Consent to ‘Rejected', if there are further checks performed by the LFI and the staged payment Consent fails causing the LFI to reject the payment Consent. An example scenario would be a Fast track SIP where the User selected a payment account with insufficient funds for the payment. In this case, the LFI may reject the payment Consent, set the status to ‘Rejected' and provide the appropriate error reason code for the TPP.

Open

Figure 2 : Authenticated Payment Consent

Open

Figure 3 : Rejected Payment Consent

Examples rejections with error reason codes are shown below:

A TPP could make a call to the ‘GET’ status endpoint at this stage to find out if the payment Consent resource has been updated to ‘Authorised‘ or ‘Rejected’.

Moreover, a TPP that has subscribed to event notifications MUST receive notification from the API HUB, informing the updated status of the payment Consent resource to ‘Authorised‘ or ‘Rejected’ using the registered Webhook URL.

The Open Finance Payment Status model, as defined in Common Rules and Guidelines | GRC 15.10 Payment Status ModelPreview, is a simplified version of the ISO 20022 Payment Transaction Status model. The simplification was to reduce the intermediate statuses, and keep only the essential ones at the start, middle and end of the full payment lifecycle. The full ISO 20022 Payment Transaction Status model diagram and the statuses definitions can be found in Payment Status Information | 7.1 ISO 20022 Payment Transaction Status ModelPreview.

The mapping of the Open Finance Payment Status and the ISO 20022 Payment Transaction Status model is as follows:

Open

ISO 20022 Payment Transaction Status model vs Open Finance Payment Status model

In summary, Open Finance retains the following statuses:

• Pending (ISO 200022 PDNG): This is the initial state that the payment resource is set to when first created. This signifies that the payment initiation checks will be starting.

• Accepted Settlement Completed Debtor Account (ISO 200022 ACSC): This is the outcome of the payment processing stage. The Users account is debited (or funds are earmarked) for the amount of the payment. At this point, Technical validation, Customer Profile checks, Fund Checking, value date is adjusted (if applicable) and all settlement checks at the Debtor LFI have been completed successfully. The Debtor LFI has sent the required payment message to the Payment System and will wait for any responses, if applicable.

  • Note - For version 2.0 the status “AcceptedSettlementCompletedDebtorAccount” is replaced with the status “AcceptedSettlementCompleted”. For future versions the API and guidance have been aligned to ISO and use the status “AcceptedSettlementCompletedDebtorAccount”.

• Accepted Without Posting (ISO 200022 ACWP): This is either an intermediate or a terminal state for the payment. It signifies that the payment has been accepted by the Creditor LFI. Creditor LFI may also have performed the necessary verifications and validations (for example in Aani system). However, the credit has not been applied to the Creditor account yet. Note: For the Aani payment system, this is a terminal state for the payment, as the Debtor LFI does not receive any confirmation from the Aani Core system after the Creditor LFI has successfully applied the credit to the Creditor account.

• Accepted Settlement Completed Creditor Account (ISO 200022 ACCC): This is a terminal state for the payment. It signifies that the payment has been accepted by the Creditor LFI and settlement on the creditor's account has been completed.

• Rejected (ISO 200022 RJCT): This is the rejection status. Rejection can happen at any point during payment initiation, payment processing or payment execution. The rejection status will be coupled with an error code, identifying the reason of the failure.

Note - For version 2.0 any reference of “AcceptedSettlementCompletedDebtorAccount” within this guidance should be replaced with the status “AcceptedSettlementCompleted”. For future versions the API and guidance have been aligned with ISO to use the status “AcceptedSettlementCompletedDebtorAccount”.

Subject to the payment Consent being successfully authorized by the User, the TPP will submit the payment Initiation request to the API HUB/LFI.

• When the payment Initiation request is received by the the API HUB and/or the LFI, the payment Consent resource status MUST be set to ‘Consumed’. (Note: This is only applicable for single payments such as SIP, FDPs and single International Payments. For Multi-payments, the payment Consent will remain in the ‘Authorized’ state until it is fully consumed, expired or revoked).

• If the payment Initiation request has been successfully received and validated by the API HUB and/or the LFI, a new Payment resource is created. The status at this point, as per the ISO 20022 model, would be Received
(RCVD). However, as per the mapping of ISO 20022 model to the Open Finance Payment Status model, the status of the Payment resource at this point MUST be set to ‘Pending’, due to this being the initialization value for the Payment resource status. The API HUB/LFI MUST also respond back to the TPP that the payment Initiation request has been successful (HTTP 201 status response) including the Payment resource status of ‘Pending' and the Payment resource ID.

Status Code	Status Reason Code	Status Reason Description
Pending	<empty>	<empty>

• A TPP could make a call to the ‘GET’ payment Consent status endpoint at this stage to confirm that the payment Consent resource has been updated to ‘Consumed’ as part of the payment Initiation request. (Please note that this is only applicable for single payments such as SIP, FDPs and single International Payments). Moreover, a TPP that has subscribed to event notifications MUST receive notification from the API HUB, informing the updated status of the payment Consent resource to ‘Consumed‘ using the registered Webhook URL.

Status Code	Status Reason Code	Status Reason Description
Consumed	<empty>	<empty>

Open

Figure 5 : Payment Consent Consumed

Open

Figure 6 : Payment Initiation started

If the payment Initiation request fails to be successfully received and validated by the API HUB or the LFI, a HTTP 4xx series response message with status reason code(s) MUST be sent back to the TPP. In such situation, the TPP will have to rely on the status reason(s) provided in the error response message in order to identify any issues, as the Payment resource was not successfully created.

If the payment Initiation request is validated successfully by the API HUB/LFI and the Payment resource is created with ‘Pending' status, there are further checks and validations that will take place at the LFI as part of the payment initiation process.

• If the payment Initiation request cannot start to be processed immediately on receipt due to pending checks and validations needed to be done, the status as per the ISO 20022 model, would be Pending (PDNG). As per the mapping to the Open Finance Payment Status model, the Payment resource MUST remain in the ‘Pending’ status.

Status Code	Status Reason Code	Status Reason Description
Pending	<empty>	<empty>

Open

Figure 7 : Payment Initiation pending

• If the payment Initiation request cannot be processed immediately on receipt because it is a future-dated payment, the Payment resource MUST remain in the ‘Pending’ status. Future dated payments that are warehoused at the LFI until they are processed on the actual payment date, can be cancelled by the User at their LFI within agreed time limits allowed by the LFI. Once cancelled, the LFI MUST update the Payment resource status to ‘Rejected’ and provide the appropriate error code.

Otherwise, on the payment date, the LFI will processes the FDP payment and update the status of the Payment resource as per the Open Finance Payment status model.

• In the case that the technical validation performed by the LFI has been completed successfully, as per the ISO 20022 model, the status of the Payment resource would be Accepted Technical Validation (ACTC). However, as per the mapping of ISO 20022 model to the Open Finance Payment Status model, the status of the Payment resource at this point MUST remain in the ‘Pending’ status.

• Similarly, in the case that the Customer Profile checks performed by the LFI has been completed successfully, as per the ISO 20022 model, the status of the Payment resource would be Accepted Customer Profile (ACCP). However, as per the mapping of ISO 20022 model to the Open Finance Payment Status model, the status of the Payment resource at this point MUST remain in the ‘Pending’ status.

• Moreover, in the case that the Funds checking performed by the LFI has been completed successfully, as per the ISO 20022 model, the status of the Payment resource would be Accepted Funds Checked
(ACFC). Again, as per the mapping of ISO 20022 model to the Open Finance Payment Status model, the status of the Payment resource at this point MUST remain in the ‘Pending’ status.

• Subject to completing the previous validations and checks, the Payment resource, as per ISO 20022 model, would move in to the the status of Accepted Settlement In Process
(ACSP) to signify that all preceding checks were successful, the payment initiation was completed and the payment instruction has been accepted for further payment processing and execution. However, as per the mapping of ISO 20022 model to the Open Finance Payment Status model, the status of the Payment resource at this point MUST still remain in the ‘Pending’ status. The payment will then proceed to the next phase of payment processing.

Open

Figure 7 : Payment Initiation completed

Note: In several situations (such as in SIPs) the progress from the payment initiation phase to the next phase of payment processing will happen extremely quickly, depending on the various implementations by LFIs. Therefore, there was limited value of returning the granular state for the payment resource as defined by the the ISO 20022 model. Instead, the Open Finance Payment Status model simply returns the ‘Pending’ status to represents all these intermediate statuses between the payment initiation phase and the payment processing phase.

• If the payment fails any validation or other checks at any point during the payment initiation process, then the status of the Payment resource MUST be updated to ‘Rejected’. The LFI MUST provide all the appropriate error reason codes to inform the TPP about the reasons for the failure. For example:

A TPP could make a call to the ‘GET’ payment status endpoint at this stage to check if the the status of the payment has remained in the ‘Pending’ state or the payment initiation has failed and the Payment resource status has been set to ‘Rejected’. Moreover, a TPP that has subscribed to event notifications MUST receive notification from the API HUB, informing the changed status of the Payment resource to ‘Rejected‘ using the registered Webhook URL.

The Payment resource during payment processing may undergo further checks. If any of these checks fail, then the status of the Payment resource MUST be set to ‘Rejected’.

• In some instances, the LFI may process the payment with a change (e.g. the desired future date may be changed if, for example, it falls on a date payments cannot be sent, or the payment system might be changed e.g. from Aani to FTS). In this case, as per the ISO 20022 model, the status of the Payment resource would become Accepted with Change (ACWC). Again, as per the mapping of ISO 20022 model to the Open Finance Payment Status model, the status of the Payment resource at this point MUST remain in the ‘Pending’ status.

 

 

 

 

 

• In the case that the payment processing phase has completed successfully and the User's account has been debited (or funds have been earmarked) for the amount of the payment, as per the ISO 20022 model, the status of the Payment resource would be Accepted Settlement Completed Debitor Account
(ACSC). As per the mapping of ISO 20022 model to the Open Finance Payment Status model, the status of the Payment resource at this point MUST be set to ‘Accepted Settlement Completed Debitor Account
’ status. This state signifies the successful completion of the payment processing stage. At this point, Technical validation, Customer Profile checks, Fund Checking, value date is adjusted (if applicable) and all settlement checks at the LFI have been completed successfully. Finally, the LFI has sent the required payment message to the Payment System and will wait for any responses, if applicable. In this case, the payment has progressed to the payment execution phase.

• If the payment fails at any point during the payment processing phase, then the status of the Payment resource MUST be updated to ‘Rejected’. The LFI MUST provide all the appropriate error reason codes to inform the TPP about the reasons for the failure.

• A TPP could make a call to the ‘GET’ status endpoint at this stage to find out if the payment processing has been successful and the Payment resource status has become ‘AcceptedSettlementCompletedDebitorAccount’. Moreover, a TPP that has subscribed to event notifications MUST receive notification from the API HUB, informing the changed status of the Payment resource to ‘AcceptedSettlementCompletedDebitorAccount‘ or 'Rejected’ using the registered Webhook URL.

Status Code	Status Reason Code	Status Reason Description
AcceptedSettlementCompletedDebitorAccount	<empty>	<empty>

Open

Figure 8 : Payment Processing started

Open

Figure 9 : Payment Processing completed

Note: In several situations (such as in SIPs) the progress from the payment processing phase to the next phase of payment execution will happen extremely quickly, depending on the various implementations by LFIs. Therefore, there was limited value of returning the granular state for the payment resource as defined by the the ISO 20022 model. Instead, the Open Finance Payment Status model simply returns the ‘AcceptedSettlementCompletedDebitorAccount‘ status to represents the completion of the payment processing phase and the transition to the payment execution phase.

If the payment processing phase was successful and the payment is sent to the underlying payment system, the payment will undergo further checks by the payment system (or scheme, if applicable), the intermediary Financial Institutions and the receiving LFIs. These checks may include technical and business parameters/rules specific to the underlying payment system, fraud/sanctions and business rules checking at the intermediary or receiving LFIs and other checking and validations related to the payment execution (subject to various implementations by relevant parties). Further to these checks:

• If any of the checks fail, then the status of the Payment resource must become ‘Rejected’. For example:

Status Code	Status Reason Code	Status Reason Description
Rejected	AC07	Creditor account number closed

Open

Figure 9 : Payment Execution completed

• If for any reason, the Creditor LFI identifies that the beneficiary account is blocked or the funds need to be blocked, then as per the ISO 20022 model the status of the Payment resource would be ‘Blocked (BLCK). However, as per the mapping of ISO 20022 model to the Open Finance Payment Status model, the status of the Payment resource at this point MUST remain to its existing state of ‘AcceptedSettlementCompletedDebitorAccount’, until the blocking has been resolved to either a rejected payment or an accepted payment. This is because in majority of cases, Blocked in a transitional state and not a terminal state (exceptional). If the Blocked payment results to a rejected payments, then the Payment resource at this point MUST be set to ‘Rejected’ and the appropriate error reason code for the failure must be populated. For example:

• If all aspects of the payment execution are successful, then:

  • In case the Creditor LFI confirms that the payment has been received but has not credited the beneficiary account yet, then the Payment resource status MUST be set to ‘AcceptedWithoutPosting’ in alignment to the ISO 2002 model. Additionally, the Creditor LFI may provide a specific reason code in such instances to the Debtor LFI. The Debtor LFI MUST provide this information, if received, alongside the Payment resource status under the status reason code. For example:

• In case the Creditor LFI confirms that the payment has been received and has applied the credit to the beneficiary account, then the Payment resource status MUST be set to ‘Accepted Settlement Completed Creditor Account’ in alignment to the ISO 2002 model. For example: