Consent

Management

LFI Consent Management

1

none

N/A

2

We would like to seek clarification if a user with ‘SUSPENDED’ consent will be shown this status on the LFI consent dashboard for all TPP granted consent? If not, what will the status be?

Each consent has its own state. The SUSPENDED status is per each consent. So, if a given consent is in a SUSPENDED state other consents will not be unless they specifically placed in that state.

3

If LFI is expected to send-receive/interpret account ids in UUID/hashed form then a mapping of UUID to actual account has to be maintained by LFIs internally?

Bank Data Sharing API - Standards v1.0-draft2 - Confluence the sequence diagram on step 7001 substage it is extracting account ids from consent payload, this indicates that the consent stored and managed by OFP is persisting consent linked banking products/services? Kindly clarify.

The value of AccountId is not expected to be a hash of the account identifier. The value is expected to be a UUID that is used as a surrogate for the account value.

The correct step that relates to the activity of associating consent with given account identifiers is 5003, where an LFI confirms the accounts to the OFP. This step ensures that a given consent is associated with given accounts, as selected by the User.

4

FEEDBACK

N/A

5

Can an LFI create a flag on an account for a vulnerable user / PEP such that no open banking requests can be fulfilled? In this case, these would always fail at consent stage and an error message to TPP would say 'service is not supported'. This would be a business error not a technical error and used sparingly to protect vulnerable users (who can be tricked into OB consents) from doing so

Noted.

5

What is the maximum duration for a long lived consent? This was asked previously but not fully answered

The maximum duration for a long-lived consent is one year.

5

What is the limit on the number of historical consent records available for past connections. Theoretically it is all but in practice a system limit should be set (e.g. last 1,000 consents)

At this stage we will be suggesting past 2 years of connections available to the user.

6

Same as above

Feedback has been noted. More information on the Consent Manager will be provided in future iterations of the standards and during OFP onboarding.

7

FEEDBACK

N/A

8

FEEDBACK

N/A

9

So if a consent is revoked via the LFI CMI, what is the mechanism that that revocation is reflected back in the OFP and is there a possibility of a transaction occurring if consent is revoked on the LFI CMI but not reflected in the OFP? 

The LFI should immediately call the consent API at the Consent Manager on the OFP to reflect the removal of consent. If this change is not reflected correctly in the OFP by the LFI calling the Consent Manager then a transaction could occur.

10

1. What happens if there is a joint bank account?  Do both account holders / owners require to give consent, or one is sufficient?  If both need to give consent, then what is the flow?

2. How login live (fixed/variable) consent will work for business access with multiple authorizations?

• In case of multiple authentications with logical grouping (e.g.: - amount up to 1000 to be approved by 2 individuals from Group A and one person from Group B where both groups have at least 10 users) Do LFI need to communicate all user information to TPP and what happens in case of every approval stage?

     What happens if corporate/business opts for sequential flow for the auth matrix?

     What happens variable amount falls into multiple slabs of the auth matrix?

     What will happen to TPP instruction if any change authorization matrix, amount limit or entitlement to account for any user changes during the lifetime of long live consent?

1. For joint bank accounts, the BAU authorization process that each LFI has in place still holds. So, if the BAU process of an LFI is that both account holders of a joint bank account must authorize a payment, then this process will still be followed. Fo Bank Data Sharing, the principle is that, if a User has access to see the account information, using their login credentials, they will be able to authorize a Consent for Bank Data sharing.

2. Existing BAU mutli-atuhorization processes will be followed. The submitter of the Consent will login to provice the initial authorization and then subsequent authrozers will have to access their account to authorize the pending consent as per existing authroization matrices.

   • Yes, LFIs have to communicate certain information to TPPs in relation to Consents requiring multi-authorizations. This information is as follows:

     • The total number of Authorizers required to process the request

     • For each authorzer:

       • The Authorizer's Identifier

       • The Type of Authorizer. For example, Financial, Management, etc.

       • The DateTime of when the Authorization occurred.

       • The Status (Pending, Approved, Rejected) reflecting the Authorizer's final decision regarding the request

   • Sequential flow for the Authorization matrix is supported provided that there is enough time available in the Authorization Time Window set by the TPP.

   • In scenarios that a Multi_Payment Consent has Consent Control Parameters with variable amounts that fall into multiple slabs of the authorization matrix, the consent will need to be authorized based on the maximum payment amount specified by the Consent, or the maximum amount in Variable-defined payment schedule.

   • Changes to authorization matrix related to amounts, limits or entitlements must be handled in alignment to how these changes are reflected for other LFI services and mandates, for example Standing Orders or Direct Debits. If the BAU process of the LFI is that authorization matrix changes may trigger revocating and re-authorization of direct debit mandates or standing orders, then the same process is expected to be followed for the existing authorized long-lived Consents. However, experiences from other implementations state that changes to the authorization matrix does not trigger post-athorization changes to existing mandates or payment orders.

11

Section 3.1.3 describes a need for LFI to advise customer to contact TPP after revocation. We do not believe this action is valid as LFI after revocation will share this to OFP. TPP should query OFP regularly for valid up-to date consent status and it is TPP that should take any further actions with customer if needed. Customer already took action to revoke access at LFI it would be unnecessary step if same action should be taken at TPP side. We propose to remove this advice and describe clearly how synchronisation of consent changes will be managed between TPP ↔ OFP ↔ LFI.  

Q1: Are these statuses for consents aligned with ISO standard? 

Q2 (also asked above): Section "Consent Setup" – "4. Consent States" lists the following states: AwaitingAuthorization: Authorized, Rejected, Suspended, Consumed, Expired, Revoked.
However, "LFI Consent Management Interfaces" – "2.2 Rules and Guidelines" still lists the other set of states: Awaiting, Authorized, Rejected, Canceled, Finished.
The response to the feedback recommends referring to Consent States section but shouldn’t the "Rules and Guidelines" section be updated as well?

When Users intend to revoke Consent from the TPP, TPPs will present to them the consequences of their action before completing the revocation. For example, if a User is revoking a consent which is used to pay a loan installment, the TPP will present to them information about the consequences of doing this, before the user confirms and proceeds with the revocation. LFIs do not have the information in relaiton to the use of each consent and the consequences of revokign a consent. Thus, the BRs require that LFIs advise their Users to contact the TPP to be informed about the consequences of their actions and not to inform the TPPs about the revocation of consent. This is handled by the Standard by either polling of consent status or TPPs may have registered a webhook for consent revocation events.

Bank Data

Sharing

Overview

1

none

N/A

2

-

N/A

3

-

N/A

4

FEEDBACK

N/A

5

For business and non technical reviewers, we should extract the data fields from the swagger file format and place into a clear table in the business standard for review. In addition the fields are rendered poorly in Edge as below and the text is truncated and illegible.

We will provide an extract of the OpenAPI description documents in Excel spreadsheet format in future iterations of the standard.

6

More details sessions will be required before integration about data sharing from Insurance Provider

N/A

6

We need the OFH data dictionary to identify any data mapping gap, perform data quality readiness assessment and define relevant/appropriate resolutions.

We will provide an extract of the OpenAPI description documents in Excel spreadsheet format in future iterations of the standard. This will provide data attribute names and types by API.

7

Defining data accountability for TPPs and LFIs throughout the data sharing process and data lifecycle it vital. This ensures the responsible party is held accountable and clearly understands their responsibilities that flow from the process.

Data accountability for TPPs and LFIs will be defined by the Liability Model.

8

Is the account API specification final and required from LFI to support? Or will be different mapping between OFP and LFI?

The OpenAPI document provides the description of the API as deployed at the OFP and available for TPPs to call. The contract between the OFP and LFI will be defined by the Ozone Connect APIs.

9

In case a customer has more then one account with LFI, can he provide consent for sharing data for more then one account or each consent request should be mapped to one single account only?

How a LFI ensures that the TPP is asking only for the data relevant to the service he is providing and not additional data? Or we just take customer consent on face value, is there any provision for additional scrutiny by the LFI?

There is a one-to-many relationship between a given consent and the User’s accounts at the LFI. A User will select the accounts they wish to share when they authorise consent.

Consent is an agreement between the User and the TPP. What is considered relevant is bounded by that agreement, with a conscious choice made by the User. Access is authorised by the User, and an LFI must honour the consent that has been authorised.

10

NIL FEEDBACK

N/A

11

In case of other Open Banking frameworks which include central API HUB there is end to end encryption performed by using TPP certificates shared with LFI/ASPSP. This secures that central HUB is not able to access data during data retrieval process. Currently OFP will have access to all data that is being shared as process does not define E2E encryption. TLS mechanism is not sufficient as TPP communicates with OFP and OFP communicates with LFI will leads to multiple TLS sessions terminations. Could you please provide information how E2E encryption process will look like so customer data is secured to be only accessed by TPPs to whom customer agreed to share data with. 

OFP is a trusted entity in the Trust Framework and therefore shares the same certificate chain. All mTLS connections are therefore established through same trust relationship.

The OFP itself operates as a passthrough. Data is never held at rest as a design principle of the Platform, and therefore not accessible to the OFP. Whenever data passes across a public network connection it is secured in-flight through mTLS.

The only exception to this is where a TPP is required to transmit customer (PII) data during consent setup, which is stored in the Consent Manager component. In this case the TPP encrypts the customer data using JSON Web Encryption, where the encryption is performed using the LFI public key. This data is therefore not accessible to the OFP, and can only be decrypted by the LFI using their private key.

In this context, the OFP acts as a Technology Service Provider to the LFI and processes data for the LFI. The arrangement and relationship can be seen to be similar to the relationship between a Data Processor and Data Controller in GDPR, where the OFP would be akin to a Data Processor and the LFI a Data Controller.

Bank Data

Sharing

Bank Data Sharing API Swagger

1

none

N/A

2

-

N/A

3

Subsequent to the Sequence diagram on the below link, the flows on below steps are unclear

Bank Data Sharing API - Standards v1.0-draft2

1. 2006 – What are the typical consent pre-validation steps that OFP expects/suggests for the LFIs to perform, please cite examples. From a general understanding perspective these may be following validations

• iss / client id (UUID v4)

• "Permissions": [ "ReadAccountsBasic", "ReadAccountsDetail", "ReadBalances",...

2. Why is the Auth code generation by LFI stage shown before the Authenticate user stage in the sequence diagram, general understanding is that unless the user authenticates with LFI and gives consent to a set of accounts federated under a Consent ID, the Auth code will have no structure or mapping.

3001 – Why there is a TPP to LFI direct interaction to get the AuthCode?,

7008 – – Does OFP request contains the exact details on account and other parameters necessary for LFI to fetch the response

Additional guidance will be provided to clarify pre-validation steps.

This is not the Authorization Code. It is an interaction ID, which is used as a reference for the interaction between OFP and the LFI during the consent authorization process.

This flow is indicative of the interaction between the TPP and the LFI, when the user is redirected to authenticate themselves and authorize consent. We will revisit the flow at future iterations of the standard to clarify this flow.

The requested details will mirror the consent properties, in that the accounts required will be retrieved from the Consent Manager store and applied to the request. The association between accounts and the consent is defined at step 5003.

4

FEEDBACK

N/A

5

As mentioned in previous feedback, the business context is required to validate the payload. API contract should be derived from the business requirements. The reference point should be in place

Unable to provide response due to insufficient information.

6

FEEDBACK

N/A

7

FEEDBACK

N/A

8

FEEDBACK

N/A

9

The payloads detailed in the API calls are sufficient for both upstream and downstream processes as described in this section of the document.

Feedback has been noted.

10

NIL FEEDBACK

N/A

11

Current swaggers define API model for TPP and OFP interaction but they do not define contracts for LFI ↔ OFP interaction.
Please provide clear swaggers divided as per below separation:
a) TPP ↔ OFP
b) OFP ↔ LFI

Full details of the OFP and Ozone Connect APIs will be provided at a future iteration of the standard and during OFP onboarding.