Can a TPP request consent for payment and data in the same RAR request?

This is not currently in place in the current draft versions of the Standard, but it is something that is being considered.

Are beneficiaries in the data model linked to an account that is the primary identity?

Yes

Having a government-issued identifier in the API is important for risk-type use cases. It would be great to mandate that LFIs provide the EID or trade license so that they can ensure that the account belongs to the person.

This is not currently in place in the current draft versions of the Standard, but it is something that is being considered.

It would be good to have some form of business rules that, in some circumstances, mandate some fields as mandatory, in addition to tech requirements.

Mapping the data model to use cases is not something we considered, but we can explore it for the UAE.

Does LFI need to return all Standing orders \Scheduled payments created by LFI channels or return only TPP-created payments to OBF?

Standing orders and direct directs will be shared data from the LFI. However, TPP payment consents should be available in the other direction.

Would there be monitoring and alerting in OFP for fraud cases? If yes, what would the procedure be for alerting TPPs or LFIs? In addition, what action was taken?

OFP does not monitor transactions for fraud.

If OF considers a TPP high risk, will it reject the request received and inform LFIs?

High risk TPPs will be removed. OF will not allow any risky TPPs on the platform.

On the PIS flow, the actual payment initiation starts when the customer clicks on proceed on the LFI app?

Yes, the LFI submits the payment to the payment rails when the user clicks "proceed."

What data elements will be made available for the LFI - for payment requests originating through TPP (i.e. Beneficiary, LFI, etc.)? 

The data elements and data model for the LFIs will be provided as part of the interface of OFP with the LFIs. It will include all the information provided by the TPP for payment initiation.

Currently, LFIs display some information to the user before executing the payment, such as accepting T&C, estimate date, FX, transfer amount, etc. 

Do LFIs have the choice to display whatever they see as suitable for different transactions?

Yes, this additional information falls within what we mention in the Business Rules as supplementary information.

LFIs can present this to users where necessary and in parity with the existing LFI channels for payment initiation.

How does a TPP get payer and payee account details?

It depends on the use case and the role of the TPP. For example, if the TPP also has long-lived consent for account information, it can provide the user with a list of his accounts with the LFI. 

Alternatively, the user can provide their payment account and LFI or select the LFI and account at the LFI. 

For payees, the user may provide a proxy or bank account details for the beneficiary. Or if the TPP is offering payment services for a beneficiary, e.g. online shop checkout, then the TPP will have already onboarded the beneficiary and validated the bank account details.

If the consumer has multiple accounts across multiple banks, will the redirection to the bank of choice of the customer be done by TPP?

The TPP will identify the LFI for which the user has their payment account, or the user may have indicated which LFI they want to use to select an account. Then, the TPP will redirect the user to the appropriate redirection path for the LFI.

Why is long-lived consent needed for a Future Dated Payment? A single consent is sufficient.

It is single consent; however, it lasts as long as the future and covers only that payment value. This isn't for recurring payments.

Let's assume there are 2 TPPs (one is AISP, and the other is PISP).

If a user wants to initiate a payment request through PISP, then it needs to connect to AISP for user accounts.

What is the flow for consent, authentication, authorisation, communication, and OFP position?

In the case of a payment, no connection to another AISP is required. Account selection will happen after redirection as a first step of the payment authorization journey.

A user can initiate another consent for the AISP use case.

Can TPP tell the User that the chosen day is a holiday and to choose another date? Or can it inform the User that payment will be executed on Day+1/2?

Yes, suppose the TPP is aware that a payment is scheduled by the User on a known bank holiday date, and the payment falls within the limits of execution for a non-24/7 payment system. 

In that case, the TPP can advise the User that the payment will not be executed on the scheduled day and may ask the User to change the date to a valid date.

What controls exist to ensure the entire network will be fully compliant with regulatory requirements, including sanctions?

All existing BAU checks of LFIs for sanctions checking, AML etc will still be applicable for the LFIs and all the necessary data will be provided.

Can a TPP act as a payment aggregator and provide settlement to the merchant at a later date instead of real-time payment?

No

Is the modify payment consent call only for multi payment consents?

Yes

What is the duration of the payment consent?

For PIS, please refer to:

Future Dated Payment | Single Future Dated Payment Consent

Multi-Payments | Multi Payments Consent

For AIS, please refer to:

Customer Data | Data Sharing Consent

Will the OF platform maintain the enforcement of the Payment rules? 

Will the OF Platform track how much is consumed from the consent limit?

Yes, this will be handled by the OFP.

What is the recommended TotalNumberOfPayments?

Please refer to Multi-Payments | Processing of Payment Initiation Requests for further details.

What about user flexibility to change the date? TPP may ask me when I would like the payment to be made (e.g., a user-selected date in May). Where could I select to pay on the 25 May, at the TPP or LFI?

Please refer to Future Dated Payment | Single Future Dated Payment Consent for further details.

Is there a cap of consents requested by TPPs? 

At the moment, we don't have a cap on the number of consents a User can provide to a TPP. 

What's the value of the suspended state, and to what extent have other regions demonstrated that it is valuable (vs cancel consent then reinstate)?

This is based on feedback from TPPs in other regions that a suspended state would be helpful, e.g. for payment holidays on a VRP when an account is suspended for operational reasons. The suspended state can be driven by customer, TPP or LFI.

Is consent required for every transaction?

All transactions (payments and service initiations) must be done under consent. It's not a 1:1 relationship; a VRP could result in multiple payments under a single consent.

Moving the consent from Authorized to Consumed, would OFP do that after accepting the request from TPP, or is the LFI responsible for updating the status after fulfilling the API request?

Generally, yes. There may be some edge cases once we work through the details (where the OFP cannot identify that the consent has been consumed), but we will point these out (if any) when we work through each consent's detail.

Do communications run through OFP with a request to LFI from TPP and a response from LFI to TPP, which OFP could know that the consent and payment requests are over?

Yes - every message from OFP to LFI will indicate the consent under which this is being operated.

Can a TPP still request different resources even if the consent state is Consumed?

All the terminal states render the consent unusable for further operation.

Can Consumed and Expired states not be merged as a single state?

Having explicit separate states allows us to provide accurate reporting.

How does an LFI change a consent status?

The Consent Manager has an API to help LFIs change consent status.

Will consent expiry be configured by TPP?

The consent Expiration Date on the consent will drive this.

Should expired consent be controlled by LFI, and should LFI be responsible for reporting this to the OFP? In the previous explanations, we understand that the OFP will be responsible for the consent lifecycle.

Ozone has a housekeeping process that automatically moves consents to Expired.

In this situation, LFIs do not have integration requirements. We have now reorganized the standards to state explicitly what the LFIs and TPPs need to do.

Since the customer has given consent, shall any change made by TPP/LFI or OFP be in the customer's awareness?

Other than state changes that happen through the usage of consent and the passage of time.

Is the client credentials grant the only acceptable grant to access consent/data?

Client Credentials Grant and Auth Code Grant, depending on the API call. We will document this for each API endpoint in the OAS3 (swagger) documentation that we produce.

Any change in consent will require customer authorization, whether it is initiated from the TPP or LFI interface.

That is correct, except maybe suspension or natural expiry of consent.

If 365 days is the default max time for a long-lived consent, in case of data sharing requests, what if TPP starts populating this as the default? What can be possible negative fallouts?

TPPs are regulated entities, so it would be advantageous to minimize data and access to only the data required by their use case.

For API / H2H-initiated payments from clients' ERP, LFI offers a feature to reauthorize using mobile/web channels based on a mandate for client payments.

Can LFI offer reauthorization through mobile/web for TPP-originated payments? 

Please refer to https://openfinanceuae.atlassian.net/wiki/x/MgBAAw for authorisation methods supported by Open Finance.

If Open Finance ambitions to introduce international payments, the standards need to be in line with existing norms; otherwise, it will be another customization when International payments are rolled out.

We will start with ISO20022, but it's important to note that we're not limiting ourselves to SWIFT.

This flexibility allows us to explore other mechanisms offering cheaper and faster transactions.