| Table of Contents | ||||
|---|---|---|---|---|
|
1. Introduction
2. CX Guidelines
2.1 User Journey
The AISP presents to the PSU a description of the data that it requires in order to support its service proposition. PSU selects the ASPSP(s) where their payment account(s) is held. The PSU 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 PSU has been authenticated, their ASPSP will be able to respond to the AISP’s request by providing the account information that has been requested.
...
2.2 CEG checklist and CX considerations
...
S. No.
...
Requirements and Considerations
...
Participant
...
Implementation Requirements
...
1
...
ASPSP selection
AISPs must ask the PSU 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 TPPs). ASPSP Implementation guides, which are located on the Open Banking Developer Zone will have information about the ASPSP’s data capabilities.
...
AISP
...
Required
...
2
...
AISPs must provide PSUs with sufficient information to enable PSUs 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 on-going or one-off)
AISPs must display the company’s trading name/brand name (i.e. the Client Name) to the PSU 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 PSU
If the AISP is not the user/customer-facing entity and there is an Agent who is acting on behalf of the AISP, then the Agent must make the PSU 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 user/customer-facing brand of the AISP
AISPs must also, populate the Agent company name in the ‘On behalf of’ field of the software statement, in order to inform the ASPSP about the agency relationship and allow the ASPSP to be able to display this information to the PSU (please refer to item #5). Only in instances where there is an Agent acting on behalf of the AISP, the ‘On Behalf of’ name must be displayed to the PSU. AISPs must not populate the ‘On behalf of’ field with the details of their TSP
For examples of what names should be displayed, please refer the section “Sample displays by TPP” below
...
AISP
...
Required
...
3
...
The AISP must provide the PSU with a description of the data being requested using the structure and language recommended by BOBF (see Data Cluster Structure & Language below) and ensure that this request is specific to only the information required for the provision of their account information service to the PSU
The AISP must present the data at a Data Cluster level and allow the PSU 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 PSUs to choose the type of data to be collected and used by the AISP. Once PSU has consented, the PSU will be directed to their ASPSP. Please refer section Effective use of redirection screens for relevant messaging
CX Considerations:
Take points from ACCC document
...
AISP
...
Required
...
4
CX consideration:
...
Account and Transaction Information Sharing allows the User/Customer post his/her consent to the AISPsto instruct his/her ASPSPsto share the User/Customers’ data. The AISPs can access the User/Customers 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, Account blocking by the regulator, Loan application/ initiation, Real time all account customer expense dashboard.
2. Customer Experience Guidelines
2.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 retrieve the necessary information consented by the user/customer.
...
2.2 Customer Experience Checklist and Customer Experience Considerations
S. No. | Requirements and Considerations | Participant | Implementation Requirements | ||||||||||
1 | ASPSP selection
|
AISP |
Required | ||||||||||
2 | Data Selection
AISP details
CX Considerations:
|
AISP |
Required | ||||||||||
3 | User/Customer consent
CX Considerations:
ASPSP allows PSUs to perform a SCA Authentication (including dynamic linking). The ASPSP authentication must have no more than the number of steps that the PSU would experience when directly accessing the ASPSP channel CX consideration: ASPs should provide messaging to inform PSUs that they
|
AISP |
Required | ||||||||||
5 | Information summary 4 | SCA - Strong Customer Authentication
|
AISP |
Required | |||||||||
5 | Information summary
| TPPs’
| in the software statement)
| PSU
| TPP
| If there is an Agent acting on behalf of the TPP, ASPSPs must also display the Agent company name (as captured in the ‘On behalf of’ field of the software statement) to the PSU. (Please note that ASPSPs can only show the Agency/On Behalf field only in cases where this information has been provided by AISPs).
For examples of what names should be displayed, please refer the section “Sample displays by | TPPAISP” | belowCX consideration:
| PSU
| BOBF
| PSU
|
ASPSP |
Required |
6 The AISP should | AISP confirmation
| PSU
| AISP | Required |
Note: “Agent” means a person or entity who acts on behalf of an authorised payment institution or a small payment institution in the provision of payment services including account information services. When an agent acts on behalf of the AISP, the PSU must in the case of requirement #2 and should in the case of requirement #5 be made aware of this within the consent journey.
2.3 Permission and Data Clusters
2.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 a 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 PSU. Details of the data elements within each permission are included in the API technical specifications.
2.3.2 Data Clusters
Grouping permissions together and adding another layer of description aided the PSU’s understanding of the data they were being asked to consent to share. This approach also allows a consistency of language across AISPs and ASPSPs to provide additional comfort to PSUs that they are sharing the data they intended to. If consistent language is used across all Participants this will drive PSU 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 PSU understanding.
2.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 PSU 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. ‘Jakes Household account’)
...
Accounts Detail
...
Your account name, number and sort-code
...
Account Name, Sort Code, Account Number, IBAN, Roll Number (used for Building Society) (plus all data provided in Accounts Basic)
...
Balances
...
Balances
...
Your account balance
...
Amount, Currency, Credit/Debit, Type of Balance, Date/Time
...
All where IBAN is available
...
IBAN
...
Your card number
...
IBAN masked or unmasked depending on how ASPSP displays online currently
...
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, Sort Code, Account) (plus all data provided in Beneficiaries Basic)
...
Standing Orders
...
Standing Order Basic
...
Your Standing Orders
...
SO Info, Frequency, Creditor Reference Info, First/Next/Final Payment info
...
Standing Order Detail
...
Details of your Standing Orders
...
Details of Creditor Account Information (Name, Sort Code, Account) (plus all data provided in Standing Order Basic)
...
Direct Debits
...
Direct Debits
...
Your Direct Debits
...
Mandate info, Status, Name, Previous payment information
...
Scheduled Payments
...
Scheduled Payments Basic
...
Recurring and future dated payments
...
Scheduled dates, amount, reference. Does not include information about the beneficiary
...
Scheduled 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/customer’s account (Reference, Amount, Status, Booking Data Info, Value Date info, Transaction Code(-M7] ). 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/customer’s account (Reference, Amount, Status, Booking Data Info, Value Date info, Transaction Code). Includes information about the entity that made the payment
...
Transactions Detailed Debits
...
Details of your outgoing transactions
...
Same as above but for debits
...
Transactions Basic
...
Your transactions
...
*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. |
2.3 Permission and Data Clusters
2.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 a 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 PSU. Details of the data elements within each permission are included in the API technical specifications.
2.3.2 Data Clusters
Grouping permissions together and adding another layer of description aided the user/customer’s understanding of the data they were being asked to consent to share. This approach also allows a consistency of language across AISPs and ASPSPs to provide additional comfort to user/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.
2.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 PSU 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. ‘John’s Household account’) | |
Accounts Detail | Your account name, number and sort-code | 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 IBAN is available | IBAN | 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, Sort Code, 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, Sort Code, Account) (plus all data provided in Standing Order Basic) | ||||
Direct Debits | Direct Debits | Your Direct Debits | Mandate info, Status, Name, Previous payment information | |||
Scheduled Payments | Scheduled Payments Basic | Recurring and future dated payments | Scheduled dates, amount, reference. Does not include information about the beneficiary | |||
Scheduled 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/customer’s account (Reference, Amount, Status, Booking Data Info, Value Date info, Transaction Code). Does not include information about the | payer/payeeentity 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 | both credits in and debits out of into the user/customer’s account (Reference, Amount, Status, Booking Data Info, Value Date info, Transaction Code). Includes information about | the payer/payee|||
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 | Products | Product | Product details – fees, charges, interest, benefits/rewards | Refers to Section Product details below (the fees, charges, interest, benefits/rewards). Applicable to PCA and BCA | |
Offers | Offers available on your account | Balance transfer, promotional rates, limit increases, start & end dates | ||||
6 | Contact and party details | Account specific:
| 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 PSU 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 PSU 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.
Optional Data: If an AISP requests additional information (e.g. Party) and the ASPSP chooses to provide this information to the AISP, both parties must ensure that they consider GDPR in the processing of this request i.e. both parties must ensure that they have a legal basis for processing
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.
2.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 (Banks) to the AISP upon users/customers consent and Authorisation.
...
S. No.
...
Product
...
Field Name
...
Description
...
1
...
Current account, savings account (including foreign currency account and cash management account)
...
Account Number
...
Bank Account number
...
Account Type
...
Type of account as classified by the ASPSP (eg. Savings Account, Current account)
...
Product type description
...
Full description of the product
...
Account Name
...
Full account name
...
Branch Name
...
Branch Name
...
Account status
...
One of ‘active’/’inactive’/'dormant'/’frozen’ (A/I/D/F)
...
Account Closed
...
Y or N
...
Account currency
...
Currency code
...
Available Balance
...
Withdrawable balance + funds in clearing
...
Effective available balance
...
Withdrawable balance
...
Lien Amount
...
Lien amount marked
...
IBAN
...
IBAN account number
...
ExchangeRate
...
Conversion rate in case of foreign currency (to BHD). In case the currency of the account is BHD, value will be 1.000
...
Account opening date
...
Account opening date
...
Account closing date
...
If the account is closed then Account closed date should be available.
...
Joint holders CPRs
...
List of joint account holder CPRs
...
2
...
Investment/Deposits accounts
...
Account Number
...
Bank Account number
...
Account Type
...
Type of account as classified by the ASPSP (eg. Savings Account, Current account)
...
Product type description
...
Full description of the product
...
Account Name
...
Full account name
...
Branch Name
...
Branch Name
...
Account status
...
One of ‘active’/’inactive’/'dormant'/’frozen’ (A/I/D/F)
...
Account Closed
...
Y or N
...
Account currency
...
Currency code
...
Rate
...
Interest rate / profit rate for islamic banks
...
Initial deposit amount
...
Initial deposit amount
...
Deposit terms- Months
...
Deposit terms in months (in case of years convert to months)
...
Deposit terms - Days
...
Deposit term in days
...
Maturity Amount
...
Maturity Amount
...
Maturity Date
...
Maturity Date
...
IBAN
...
IBAN account number
...
ExchangeRate
...
Conversion rate in case of foreign currency (to BHD). In case the currency of the account is BHD, value will be 1.000
...
Account opening date
...
Account opening date
...
Account closing date
...
If the account is closed then Account closed date should be available.
...
Joint holders CPRs
...
List of joint account holder CPRs
...
3
...
Loans (including financing products and overdraft facilities)
...
Account Number
...
Bank Account number
...
Account Type
...
Type of account as classified by the ASPSP (eg. Savings Account, Current account)
...
Product type description
...
Full description of the product
...
Account Name
...
Full account name
...
Branch Name
...
Branch Name
...
Account status
...
One of ‘active’/’inactive’/'dormant'/’frozen’ (A/I/D/F)
...
Account Closed
...
Y or N
...
Account currency
...
Currency code
...
Rate
...
Interest rate / profit rate for islamic banks
...
Loan Amount
...
Initial Loan Amount
...
Disbursed Amount
...
Disbursed Amount till date
...
Outstanding Loan Amount
...
Outstanding Loan Amount
...
No. of installments
...
Number of installments
...
Loan terms- Months
...
Deposit terms in months (in case of years convert to months)
...
Deposit terms - Days
...
Deposit term in days
...
IBAN
...
IBAN account number
...
ExchangeRate
...
Conversion rate in case of foreign currency (to BHD). In case the currency of the account is BHD, value will be 1.000
...
Account opening date
...
Account opening date
...
Account closing date
...
If the account is closed then Account closed date should be available.
...
Joint holders CPRs
...
List of joint account holder CPRs
...
4
...
Credit cards (including debit cards, prepaid cards and E Wallets)
...
Card Number
...
Card number (Masked card details)
...
Card Issuer
...
Card issuer (e.g VISA)
...
Card Type
...
Primary or Secondary
...
Product type description
...
Full description of the product
...
Card Name
...
Full name as on the Card
...
Branch Name
...
Branch Name
...
Card status
...
One of ‘active’/’inactive’/'dormant'/’frozen’ (A/I/D/F)
...
Card Closed
...
Y or N
...
Card currency
...
Currency code
...
Card Balance
...
Card Balance
...
Rate
...
Interest rate / profit rate for islamic banks
...
Card Limit
...
Card Limit
...
Minimum Due
...
Minimum Amount payable
...
Total Due
...
Total Amount payable
...
Payment Due date
...
Payment Due date
...
Add on cards
...
Number of add-on cards (supplementary cards)
...
ExchangeRate
...
Conversion rate in case of foreign currency (to BHD). In case the currency of the account is BHD, value will be 1.000
...
Card Issue date
...
Card Issue date
...
Card closing date
...
If the Card is closed then Account closed date should be available.
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/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/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 | Products | Product | Product details – fees, charges, interest, benefits/rewards | 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:
| 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.
2.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 user/customers consent and Authorisation.
Current account, Savings account (including foreign currency account, cash management account, etc.)
Investment/Deposits accounts
Loans (including financing products, mortgages, overdraft facilities, etc.)
Cards (including credit cards, prepaid cards, charge cards, E Wallets, etc.)