Sharing Transaction History/ Account Information

Owned by CBB Admin
Oct 27, 2020
9 min read

1. Version Control

Version

Date

Description of Changes

Bahrain OBF v1.0.0

28th Oct 2020

Initial Release

2. Introduction

Account and Transaction Information Sharing allows the user/customer to post his/her consent to the AISPs to instruct his/her ASPSPs to share the users'/customers’ data. The AISPs can access the user/customer data to provide recommendations/ innovative financial products and services as per his/ her needs. This use case details out the customer experience guidelines and technical API specifications that are required to be developed and followed by both ASPSPs and AISPs. This use case is applicable to both retail and corporate customers.

Few sample Account and Transaction Information Sharing business opportunities may include Account aggregation, Price comparison match for the customer’s own products, Personal finance management, Ledger account: Reconciliation of ledgers, Cashflow management, Accounting and taxation calculation for SMEs, Loan application/ initiation, Real time all account customer expense dashboard.

3. Customer Experience Guidelines

3.1 Customer Experience Journey

The AISP presents to the user/customer a description of the data that it requires in order to support its service proposition. User/Customer selects the ASPSP(s) where their account is held. The user/customer is then directed to the domain of its ASPSP for authentication and to select the account(s) they want to give access to. Once the user/customer has been authenticated, their ASPSP will be able to respond to the AISP’s request by providing the account information that has been requested.

Once the journey gets completed, the AISP interacts with ASPSPs on a frequent basis and retrieves the necessary information consented by the user/customer.

 

3.2 Customer Experience Checklist and Customer Experience Considerations

S.No.

Customer Experience Checklist and Customer Experience Considerations 

 Participant

Implementation Requirements

1

ASPSP selection

  • AISPs must ask the user/customer to identify their ASPSP before requesting consent so that the consent request can be constructed in line with the ASPSP’s data capabilities (which the ASPSP must make available to all AISPs)

AISP

Required

 

 

 

 

 

 

2

Data Selection

  • The AISP must provide the user/customer with a description of the data being requested using the structure and language recommended by Bahrain OBF (refer section ‘Permission and Data Cluster Structure’ below) and ensure that this request is specific to only the information required for the provision of their account information service to the user/customer

  • The AISP must 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 AISP should only present those data clusters relevant for the product type in question. Where the request is for multiple product types then the detail shown in the data cluster should explain to the user/customer the product types to which it applies or state that it is shared across multiple product types

  • AISPs must allow the user/customers to choose the type of data to be collected and used by the AISP. AISPs must provide user/customers with sufficient information to enable user/customers 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

  • AISP must allow user/consumer to choose the period over which data will be collected and used by actively selecting or otherwise clearly indicating the period of that collection and use*

AISP details

  • 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

  • For examples of what names should be displayed, please refer the section “Sample displays by AISP” below

CX Considerations:

  • AISP may consider the use of various consent capture design patterns such as checkboxes, toggles, scales, and binary yes/no choices to enhance user/consumer experience

 

 

 

 

 

 

AISP

 

 

 

 

 

 

Required

 

 

3

User/Customer consent

  • Once users/customer has consented, the user/customer will be directed to their ASPSP. Please refer section Effective use of redirection screens for relevant messaging

CX Considerations:

  • AISP should make the user/customer aware on the inbound redirection screen that they will be taken to their ASPSP for authentication for account access. AISPs should provide messaging to inform the user/customer that they will be taken to their ASPSPs to complete the process. Example wording: "You will be securely transferred to your ASPSP to authenticate and choose the account for accessing information"

  • Generic AISP to ASPSP redirection screen and message

 

 

AISP

 

 

Required

4

CX Considerations:

  • Generic AISP to ASPSP redirection screen and message

SCA - Strong Customer Authentication

  • ASPSP must allow users/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

ASPSP

Required

 

 

 

 

5

Information summary

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

  • ASPSPs must allow user/customers to select the account for data sharing with AISP

  • ASPSPs must not seek confirmation of the consent that has already been provided by the user/customer to the AISP

  • Once the user/customer has selected the account(s), refer to section Effective use of redirection screens for redirection messaging

For examples of what names should be displayed, please refer the section “Sample displays by AISP”

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

 6

AISP confirmation

  • The AISP must confirm the successful completion of the account information request to the user/customer

AISP

Required

*A maximum of one year “rolling requirement” for sharing historical data Or the “maximum duration of data available in ASPSPs online channel" (i.e., the amount of historical data (in months/years) that should be provided from the date of a data request). If the user/customer choose to share <12 months historical data then ASPSPs has to send only the data for the requested period. For Example: If a user/customer request data on 1st June 2020 then the rolling data would include the data from 1st June 2019 till 31st May 2020.

Sample displays by AISP:

Customer-facing entity name /Trading Name (Client Name in Software Statement)

Registered Legal Entity Name (Company Name/ Organization Name)

What to display

XYZ Trades

XYZ Company Ltd.

XYZ Trades

XYZ Company Ltd.

XYZ Company Ltd.

XYZ Company Ltd.

3.3 Permission and Data Clusters

3.3.1 Permissions

In the Open Banking API design, data elements are logically grouped together into “permissions”. It is at this level that AISPs request data access. If they request access to specific permission they will have access to all the data elements in the permission. This provides a pragmatic approach, allowing AISPs to be selective but at the same time creating a consent process that is at an acceptable level of granularity for the user/customer. Details of the data elements within each permission are included in the API technical specifications.

3.3.2 Data Clusters

Grouping permissions together and adding another layer of description aided the user’s/customer’s understanding of the data they were being asked to consent to share. This approach also allows consistency of language across AISPs and ASPSPs to provide additional comfort to users/customers that they are sharing the data they intended to. Consistent language across all Participants will facilitate user/customer familiarity and adoption. These groups of permissions are known as Data Clusters. Data Clusters are not reflected in the API specifications, they are purely a presentational layer on top of permissions to aid user/customer understanding.

3.3.3 Data Cluster Structure & Language

The following table describes how permissions should be grouped into Data Clusters and the language that must be used to describe the data at each of these levels. Both AISPs and ASPSPs must describe the data being shared at a Data Cluster level and allow the user/customer to “drill-down” to see the detail at Permission level using the permission language set-out in the table below. Where both Basic and Detail permissions are available from the same API end point, the Detail permission contains all data elements of the Basic permission plus the additional elements described in the table.

S. No.

Data Cluster Language

API End Points

Permissions

Description of the field

Information Available

 

 

1

Your Account Details

Accounts

Accounts Basic

Any other name by which you refer to this account and/or the currency of the account

Currency of the account, Nickname of account (E.g. ‘Abdulla's Household account’)

Accounts Detail

Your account name and account number

Account Name, Account Number (IBAN) (plus all data provided in Accounts Basic)

Balances

Balances

Your account balance

Amount, Currency, Credit/Debit, Type of Balance, Date/Time

All where PAN is available

PAN

Your card number

PAN in masked or unmasked form as currently  displayed on the ASPSP’s online channel

Note: Masking of PAN must be as per existing regulations in Bahrain

2

Your Regular Payments

Beneficiaries

Beneficiaries Basic

Payee agreements you have set up

List of Beneficiaries

Beneficiaries Detail

Details of Payee agreements you have set up

Details of Beneficiaries account information (Name, Account) (plus all data provided in Beneficiaries Basic)

Standing Orders

Standing Order Basic

Your Standing Orders

Standing Order Info, Frequency, Creditor Reference Info, First/Next/Final Payment info

Standing Order Detail

Details of your Standing Orders

Details of Creditor Account Information (Name, Account) (plus all data provided in Standing Order Basic)

Direct Debits

Direct Debits

Your Direct Debits

Mandate info, Status, Name, Previous payment information

Future Dated Payments

Future Dated Payments Basic

Recurring and future dated payments

Scheduled dates, amount, reference. Does not include information about the beneficiary

Future Dated Payments Detail

Details of recurring and future dated payments

Scheduled dates, amount, reference. Includes information about the beneficiary

3

Your Account Transactions

Transactions

Transactions Basic Credits

Your incoming transactions

Transaction Information on payments made into the user’s/customer’s account (Reference, Amount, Status, Booking Data Info, Value Date info, Transaction Code). Does not include information about the entity that made the payment

Transactions Basic Debits

Your outgoing transactions

Same as above, but for debits

Transactions Detail Credits

Details of your incoming transactions

Transaction Information on payments made into the user’s/customer’s account (Reference, Amount, Status, Booking Data Info, Value Date info, Transaction Code). Includes information about the entity that made the payment such as merchant code, merchant address, etc.

Transactions Detailed Debits

Details of your outgoing transactions

Same as above but for debits

Transactions Basic

Your transactions

Transaction Information on payments for both credits in and debits out of the user’s/customer’s account (Reference, Amount, Status, Booking Data Info, Value Date info, Transaction Code). Does not include information about the payer/payee

Transactions Detail

Details of your transactions

Transaction Information on payments made both credits in and debits out of the user’s/customer’s account (Reference, Amount, Status, Booking Data Info, Value Date info, Transaction Code). Includes information about the payer/payee such as code/ID, address, etc.

4

Your Statements

Statements

Statements Basic

Information contained in your statement

All statement information excluding specific amounts related to various balance types, payments due etc.

Statements Detail

Details of information contained in your statement

All statement information including specific amounts related to various balance types, payments due etc.

5

Your Account Features and Benefits

Supplementary Account Information

Supplementary Account Info

Product details – fees, charges, interest

Refers to Section supplementary Info below (the fees, charges, interest)

Offers

Offers available on your account

Balance transfer, promotional rates, limit increases, start & end dates

6

Contact and party details

Account specific:

·    Parties

·    Party

Party

The full legal name(s) of account holder(s)

Address(es), telephone number(s) and email address(es)

The name of the account. Full Legal Name(s), Account Role(s), Beneficial Ownership, Legal Structure, Address or addresses, telephone numbers and email address as held by the bank/card issuer and party type (sole/joint etc.)

NOTE:

  • With respect to the clusters and permissions language, ASPSPs should consider whether the language that is displayed to the user/customer is appropriate when the information being accessed relates to more than one party. For example, “Your data” may need to be adapted to just “data” to indicate to the user/customer that the account information being displayed may not be solely specific to them.  As is the case of joint accounts when the account information of both parties is requested

  • Relevance of data cluster against product type: The AISP must ensure they have business rules that manage the relationship between data cluster to product type and omit access to data clusters that are irrelevant to a product type, as well as their service offering. If an AISP requests a cluster of data that is irrelevant to the product type associated to the payment account e.g. Direct Debit cluster requested for a Savings Account product type, the ASPSP may provide that cluster as empty

  • Please refer the related data models for detailed breakdown of the data fields

3.4 List of Products and Services covered

For the purpose of Bahrain’s open banking the following list of products and services to be shared by the ASPSPs to the AISP upon users/customers consent and Authorisation:

  1. Current account, Savings account (including foreign currency account, cash management account, etc.)

  2. Investment/Deposits accounts

  3. Loans (including financing products, mortgages, overdraft facilities, etc.)

  4. Cards (including credit cards, prepaid cards, charge cards, E-Wallets, etc.)

 

 

CENTRAL BANK OF BAHRAIN © 2020