Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

1. Consent Management and Revocation 

1.1 Consent Revocation

AISPs must provide user/customers with a facility to view and revoke on-going consents that they have given to that AISP. They may have consented to share data from several ASPSPs with a single AISP. This section describes how these consents should be displayed and how the customer journey to revoke them should be constructed. 

 

...

1.1.1 Customer Experience Checklist and Customer Experience Considerations

AISP should offer functionality (e.g. search, sort, filter) to enable a search for . This will be of particular benefit as the number of consents for different ASPSPs/ accounts given by a user/customer to AISPs increases. AISP should provide user/customer with multiple selection options to manage/revocate consent

If the AISP is not the customer-facing entity and there is an Agent who is acting on behalf of the AISP, then the Agent must make the user/customer aware that they are acting as an agent on behalf of the AISP and must also, display the AISP’s full trading name/brand name or registered company name whichever is the customer-facing brand of the AISP.

The customer-facing entity must provide user/customers with sufficient information to enable them to make an informed decision. For example, detail the purpose for which the data will be used (including whether any other parties will have access to the information), the period over which it has been requested and when the consent for the account information will expire (consent could be ongoing or one-off).  BOBF and ensure this request is specific to only the information required for the provision of their account information service to the user/customer. 

AISPs should present the data at a Data Cluster level and allow the user/customer to expand the level of detail to show each Data Permission. 

The Consent Dashboard should (including whether any other parties will have access to the information)..The
  • The length of time for which this consent is valid (e.g. one-off use, for a set period of time e.g. one year, or with no end date and the date of expiry).

  • .

     

    The consent dashboard must allow a view or cancel the access they have given consent to. The functions “Cancel Permission” and “back” should be displayed with equal prominence to the user/customerCX consideration:customer   Delete .

    CX consideration:

    As the account-access-consent resource has been deleted, AISPs must update the consent dashboard as soon as practicable. This update should include:-

    An updated status of the user/customer’s sharing arrangementA statement indicating to the user/customer that the AISP is no longer collecting and using their data  CX consideration: should SHOULD

    ASPSPs should inform the user/customer that no further account information will be provided by the ASPSP to the AISP as the user/customer has withdrawn its access given to the AISP.

      Delete delete endpoint  

    S. No.

    Customer Experience Checklist and Customer Experience Considerations

    Participant

    Implementation Requirements

     1

    Consent Selection

    AISP must allow user/customer to

    select the relevant consent

    for revocation.

    AISPs must display the company’s trading name/brand name (i.e. the Client Name) to the user/customer during the setup and revocation of consent. If the AISP is only trading with its registered company name then it must display that name to the user/customer.

    CX consideration:

    AISP should provide user/customer with multiple selection options to manage/revocate consent.

    AISP should offer functionality (e.g. search, sort, filter) to enable a user/customer to search for the relevant consent. This will be of particular benefit as the number of consents for different ASPSPs/ accounts given by a user/customer to AISPs increases.

    AISP

     Required

    2

    Consent Details

    AISPs must describe the data being shared through each selected consent using the structure and language recommended by

    Bahrain OBF.

    The Consent must also describe:

    ·        A description of the account information service that is being provided

    ·        Where the request is for multiple product types, the detail should explain to the customer the product type to which it applies or state that it is shared across multiple product types

    ·        The date when consent was first granted

    ·        The period for which the account information has been requested (e.g. transactions for the last 12 months)

    AISP

    Required

    3

    CX consideration:

    AISPs should present the data at a Data Cluster level and allow the user/customer to

    expand the level of detail to show each Data Permission.

    AISP

    Required

    3

    The AISP must make the exact consequences of cancelling the consent clear to the user/customer – i.e. they will no longer be able to provide the specific service to the user/

    customer.

    AISP

    Required

    4

    Cancel the permission

    The consent dashboard must allow a user/customer to cancel the access they have given consent to. The functions “Cancel Permission” and “back” must be displayed with equal prominence to the user/customer.

    Once the user/customer confirms revocation, AISPs must inform the ASPSP that the user/customer has withdrawn consent by making a call ‘to PATCH’ the account-access-consent resource as soon as practically possible. This will ensure that no further account information is shared.

    ASPSPs must support the

    revocation process. (This is not visible to the user/customer but will ensure no further account information is provided by the ASPSP to the AISP)

    .

    AISP

    Required

    5

    AISP Confirmation

    AISPs

    must provide a message to consumers that revocation was successful. This message

    to be clearly visible on the dashboard and shown as soon as revocation has taken place.

    CX consideration:

    After the

    Patch endpoint is called by the AISP to remove the account-access-consent resource, the ASPSPs are advised to inform the user/customer via their own channels (for example via SMS or via a notification on their mobile phone) that the AISP will no longer have access to their account. This is an additional confirmation to the user/customer that the AISP has completed the

    revocation process correctly.

     

    AISP

    ASPSP

      

    Required

     

    Required

    6

    Post Customer revocation, AISPs must delete the entire customer data from their storage system

    AISP

    Required

     

    1.2 Consent Re-authentication / Refresh

    AISPs must provide user/customer with a facility to view and refesh the consents that they have given to that AISP. Consents provided to AISP are long lived and the AISP can access user/customers data till consent is valid (currently Bahrain OBF has defined the consent validity for a maximum period of 12 months).

    This section describes the customer journey when a user/customer needs to re-authenticate AISP consent, so that the AISP can continue to provide the service previously consented to by authenticating again at their ASPSP. All other elements of the consent (data permissions required, purpose for which the data will be used, transaction history period and consent expiration date) remain unchanged. (It should be noted that the API specification allows the AISP to inform the ASPSP that the request is a re-authentication/refresh rather than a new request).

    1.1.2 Customer Experience Checklist and Customer Experience Considerations

    S. No.

    Customer Experience Checklist and Customer Experience Considerations

    Participant

    Implementation Requirements

     1

     Notification by AISP

    AISPs must alert the user/customer when authentication needs to be performed to re-authenticate AISP access.

    CX consideration:

    ·        AISPs should make it clear that the user/customer is being asked to authenticate to extend the AISP access to their account data and that no other element of the consent (e.g. the data permissions required, the purpose for which it will be used etc.) will change

     

     

    AISP

     

    Required

    2

    Consent Selection

    ·        AISP must allow user/customer to select the relevant consents for re-authentication

    ·        The customer-facing entity must provide users/customers with sufficient information to enable them to make an informed decision. For example, detail the purpose for which the data will be used (including whether any other parties will have access to the information), the period over which it has been requested and when the consent for the account information will expire (consent could be ongoing or one-off)

    ·        AISPs must display the company’s trading name/brand name (i.e. the Client Name) to the user/customer. If the AISP is only trading with its registered company name then it must display that name to the user/customer

    CX consideration:

    ·        AISP should provide user/customer with multiple selection options to manage/re-authenticate consent

    ·        AISP should offer functionality (e.g. search, sort, filter) to enable a user/customer to search for the relevant consent. This will be of particular benefit as the number of consents for different ASPSPs/ accounts given by a user/customer to AISPs increases

     

    AISP

     

    Required

    3

    Consent Details

    AISPs must describe the data being shared through each selected consent using the structure and language recommended by Bahrain OBF.

    CX consideration:

    ·        AISPs should present the data at a Data Cluster level and allow the user/customer to expand the level of detail to show each Data Permission

    ·        Generic AISP to ASPSP redirection screen and message

    AISP

    Required

    4

    SCA - Strong Customer Authentication

    ·        ASPSP must allows user/customers to perform a SCA Authentication. The ASPSP authentication must have no more than the number of steps that the user/customer would experience when directly accessing the ASPSP channel

    ·        ASPSPs must not replay the data requested (as a default) or seek re-confirmation of consent

    ·        ASPSPs must display the AISPs’ trading name/brand name (i.e. the Client Name in the software statement) to the user/customer during authentication screens and on any Access Dashboards. They do not need to display the registered company name of the TPP even if it is different

    CX consideration:

    ·        If the ASPSP provides an option for the user/customer to view the data they have consented to share with the AISP as supplementary information, this must be done using the structure and language recommended by Bahrain OBF (see Data Cluster Structure & Language below). Display of such information must not be provided to the user/customer as a default

    ·        Generic ASPSP to AISP redirection screen and message

     

    ASPSP

     

    Required

    5

    AISP Confirmation

    AISPs must confirm the successful completion of the consent re-authentication to the user/customer.

    AISP

    Required

    2. Access Dashboard and Revocation

    ASPSPs must provide user/customers with a facility to view and revoke on-going access that they have given to any AISP for each account held at that ASPSP. This section describes how AISP’s access should be displayed and how the customer journey to revoke them should be constructed. 

    ...

    2.1 Customer Experience Checklist and Customer Experience Considerations

    CX consideration: during authentication screens and

    If there is an Agent acting on behalf of the AISP, ASPSPs must also, display the Agent company name (as captured in the ‘On behalf of’ field of the software statement) to the user/customer. (Please note that ASPSPs can only show the Agency/On Behalf field in cases where this information has been provided by AISPs).

    CX consideration:. This will be of particular benefit as the number of consents given by a user/customer to AISP increases

    ASPSPs SHOULD prioritize information that is important to user/customers. This MAY include using tabs (e.g. active, pending, archived), or presenting key details up front, such as when consent was granted.

     

    BOBF ASPSPs  The Access Dashboard should .... make available on all digital channels an access dashboard which allows to view access which has been previously granted and it must be easy and intuitive for user/customers to find and use.

    CX consideration:

    ASPSPs should make the status of AISP access clear by the use of emboldened words. The ASPSP should also make it clear, which party provided the AISP access, in the case of joint/ multiple account holders 34 advise user/customers that they should contact the associated AISP to them of cancellation of access and/or understand the consequences of doing so before the confirms the revocation of accessASPSPs should inform the user/customer

    S. No.

    Customer Experience Checklist and Customer Experience Considerations

    Participant

    Implementation Requirements

     1

    ASPSP must allow user/customer to view a list of connected AISP service providers and allow user/customer to select the AISP for access revocation.

    ASPSPs must display the AISPs trading name/brand name (i.e. the Client Name in the software statement) to the user/customer

    on any Access Dashboards. They do not need to display the registered company name of the AISP even if it is different.

    CX consideration:

    ·        ASPSP should provide user/customer with multiple selection options to manage/revocate access

    ASPSPs should offer a functionality (e.g. search, sort, filter) to enable a user/customer to search for the relevant access

     ASPSP

    Required

    2

    ASPSPs must describe the data being accessed for the selected AISP using the structure and language recommended by

    Bahrain OBF.

    ASPSPs should present the data at a Data Cluster level and allow the user/customer to expand the level of detail to show each Data Permission.

    ASPSPs must make available on all digital channels an access dashboard which allows user/customers to view access which has been previously granted and it must be easy and intuitive for user/customers to find and use.

    The Access Dashboard must also describe:

    ·        The status of the access e.g. Active/Inactive

    ·        When the AISP’s access to the account(s) will expire, if available

    ·        The date the authorisation was granted

    And may include the date of last access

    ASPSP

    Required

    3

    ASPSPs must

    advise user/customers

    that they should contact the associated AISP to inform them of the cancellation of access and/or understand the consequences of doing so before the user/customer confirms the revocation of access

    ASPSP

    Required

    4

    The access dashboard must allow a user/customer to view or cancel the access they have given consent to. These functions “cancel access” and “back” should be given equal prominence

    ASPSP

    Required

    5

    ASPSPs must

    inform

    the

    user/customer

    ASPSP

    Required

    5

    via their own channels (for example via SMS or via a notification on their mobile phone or via in screen messages) that AISP will no longer have access to their account

    ASPSP

     Required

     3.  Swagger Code

    The swagger code file for the Event Subscription, Real Time Notification and Aggregated Polling APIs can be accessed at this link.