Definitions, Glossary and References (Draft Version 1.0)

1

CBK or ‘the Central Bank’

The Central Bank of Kuwait

2

Data Generator

Any entity, such as banks, that provides and maintains bank accounts for their customers and expose APIs to allow registered OBSPs to access customers data, after being granted a customer’s explicit consent.

3

Data Consumer

Any party that enables their customers to make better use of their data, and to make and receive fast, secure payments directly from a bank account such as Fintechs.

4

Local Banks

Kuwaiti banks and branches of the foreign banks registered with CBK.

5

Company

A shareholding company.

6

Activity

Open Banking Services including Account Information Services (AIS) or Payment Initiation Services (PIS).

7

Customer

The natural or legal person, who is a beneficiary of the provided Activity.

8

Consent

The authorization by the customer to share their account information data with an entity for a specific purpose, scope and duration.

9

Account Servicing Payment Service Provider (ASPSP)

Any entity that provides and maintains a payment account for a payer and enables the initiation of payments by Open Banking Service Providers (OBSP), and/or makes their customers’ account transaction data available to OBSPs with customer consent.

10

Account Information Service (AIS)

An online service to provide consolidated information on one or more payment accounts held by the payment service user with another payment service provider or with more than one payment service provider.

11

Account Information Service Provider (AISP)

Any entity registered to perform by CBK to provide Account Information Services in the State of Kuwait in accordance with these Instructions for Regulating Open Banking.

12

Payment Initiation Service (PIS)

An online service to initiate a payment order at the request of the payment service user with respect to a payment account held at another payment service provider.

13

Payment Initiation Service Provider (PISP)

Any entity registered to perform by CBK to provide Payment Initiation Services in the State of Kuwait in accordance with these Instructions for Regulating Open Banking.

14

Consent Dashboard

AISP facility to enable a user/customer to view and revoke consents given to that AISP to access account information from their ASPSP’s payment account(s)

15

Access Dashboard

ASPSP facility to enable a user/customer to view OBSPs that have access to their payment account(s) and revoke access if desired

16

RESTful APIs

The API adheres to RESTful API concepts where possible and sensible to do so.

However, the priority is to have an API that is simple to understand and easy to use. In instances where following RESTful principles would be convoluted and complex, the principles have not been followed.

17

ISO 20022

The principles we have applied to re-use of ISO message elements and components are:

Where relevant, the API payloads have been flattened so that they are more developer friendly. This has been a request from the developer community, and the stakeholders involved in the design workshop.

Only elements that are required for the functioning of the API endpoint will be included in the API payload. API endpoints are defined for specific use-cases (not to be generically extensible for all use-cases).

We will modify ISO 20022 elements where the existing standard does not cater for an API context (such as filtering, pagination etc.). An example is having latitude and longitude in decimal format, as this is how developers will work with latitude and longitude; or using simple types (e.g., a single date-time field) instead of a complex type (e.g., a choice field with a nesting of date and time).

#Extensibility

It is intended that the API flows will be extended to cater for more complex use-cases in subsequent releases, and we have kept this in mind during the design.

18

Extensibility

It is intended that the API flows will be extended to cater for more complex use-cases in subsequent releases, and we have kept this in mind during the design.

19

Idempotency

Idempotency is difficult to implement consistently and leverage consistently. As a result, idempotency is used sparingly in the Open Banking API specifications; with a preference to allow OBSPs to simply re-submit a request under failure conditions. APIs have been defined to be idempotent, where not doing so would cause a poor user/customer user-experience or increase false positive risk indicators.

20

Message Signing

Digital signatures will facilitate non-repudiation for Open Banking APIs. The approach for message signing is documented in Basics / Message Signing. The applicability of signatures to individual requests and responses is documented on the page for each of the resources. However, implementers of the standards can optionally add signatures to all response and request payloads.

21

Message Encryption

Message Encryption is an optional feature of the Open Banking APIs to facilitate additional protection of inflight data. The approach for message encryption is documented in Basics / Message Encryption. Applicability to individual requests and responses is not defined in the standards. Application will be based on agreement between implementors of the standards.

22

Agnostic to Payment Schemes

The API will be designed so that it is agnostic to the underlying payment scheme that is responsible for carrying out the payment. As a result, we will not design field lengths and payloads to only match the Faster Payments message and will instead rely on the field lengths and definitions in ISO 20022. Due diligence has been carried out to ensure that the API has the necessary fields to function with payments

We will provide further mapping guidance to ensure that differences are understood between the Open Banking Payment API standard where applicable

23

Status Codes

The API uses two status codes that serve two different purposes:

The HTTP Status Code reflects the outcome of the API call (the HTTP operation on the resource). Granular Functional Error Codes are specified as part of API Error Response Structure, after consultation with Security and Fraud Working Group.

A Status field in some of the resource payloads reflects the status of resources.

24

Unique Identifiers (Id Fields)

A REST resource should have a unique identifier (e.g. a primary key) that may be used to identify the resource. These unique identifiers are used to construct URLs to identify and address specific resources.

However, considering that some of the resources described in these specifications do not have a primary key in the system of record, the Id field will be optional for some resources.

An ASPSP that chooses to populate optional Id fields must ensure that the values are unique and immutable.

25

Regulator / Other Industry Bodies

Regulatory bodies and industry authorities of a jurisdiction providing governance and oversight to the Open Banking ecosystem and ensuring compliance to Open Banking Framework by other ecosystem participants. Apart from monitoring and supervision, the regulator may also assume the role of a data generator as well as of a data consumer, if deemed necessary. Through access to additional data sets, it can enhance monitoring and supervision

26

Data Sharing

Provides the approach for data flow across the participants in the Open Banking ecosystem. Data sharing can happen via three different routes which have been defined as under:

One way data sharing from Banks to OBSPs (where banks act only as a data generator)

Two-way data sharing between Banks (where banks act as both data generator and data consumer)

Reciprocal data sharing arrangements from OBSPs to Banks (where the OBSP act as data generator)

27

Read and Write Access

In the context of Open Banking,

Read access allows the data consumer to obtain copies of customers’ financial data from data generators and use it for such activities as data aggregation after valid consent from the user/customer (for example – PFM – Personal Finance Management)

Write access allows data consumer to initiate payments use cases on behalf of the user/customer after their valid consent (for example – Single Domestic Payments - Immediate)

28

Open Banking Service Providers (OBSPs)

CBK registered service providers to perform account information services (AIS) and/or payment initiation services (PIS).

29

Application Programming Interface (API)

A set of routines, protocols and tools for building software applications. An API specifies how software components should interact.

30

API Client

An API client is a development tool that makes it easier for producers and consumers to explore, test, and debug APIs

31

API Server

The API server is a tool that allows you to build, manage, and deploy REST APIs

32

Conditional

Functionality, endpoints and fields marked as Conditional may be required in some cases for meeting Open Banking requirements (for example, if these are made available to the User/Customer in the ASPSP’s existing Online Channel have been mandated by Open Banking requirement)

33

Mandatory

Functionality, endpoints and fields marked as Mandatory are required in all cases for Open Banking requirement and/or for the API to function and deliver essential customer outcomes

34

Optional

Functionality and endpoints marked as Optional are not necessarily required for Open Banking requirement but may be implemented to enable desired customer outcomes

35

Should/Recommended

There may exist valid reasons to ignore a particular point in this document, but the full implications need to be understood before choosing a different course

36

Should Not

There may exist valid reasons when the particular point is acceptable or even useful, but the full implications need to be understood before implementing any point described with this label

37

Must/Required

This is an absolute requirement of this document

38

Must not

This is an absolute prohibition of this document

39

May

This is an informed suggestion but that the point is optional

40

UML

The unified modeling language is a general-purpose modeling language that is intended to provide a standard way to visualize the design of a system UML diagrams can be used to depict various aspects of the API, such as its structure, behavior, and interactions. A class diagram in UML is used to represent the structure of an API by illustrating the classes, interfaces, and their relationships. A sequence diagram is used to illustrate how different API endpoints or methods interact with each other and the sequence of messages exchanged

41

PASP

Payment Account Service Provider (PASP) is a Payment Service Provider
(PSP) which provides and maintains a payment account for a Payment Service User, including licensed banks that provide and maintain payment accounts

42

Customer Experience Instructions

Customer Experience Instructions enable informed decision making, easy navigation, parity of experience, familiarity and trust are essential to successful implementation of the Open Banking framework.

At the heart of the Open Banking journey is the consent management process. The consent management process allows the user/customer to provide authorization to the Data consumers to access customer data via an authentication route.

43

API Standards

The Open Banking API standards help to define the various methods and the parameters for facilitating interactions between the different participants (ASPSPs, AISPs, PISPs) in the ecosystem

44

Operational Guidelines

Operational guidelines assists data generators (ASPSPs) to design an effective and high-performance dedicated interface while fulfilling the regulatory obligation. It ensures that data consumers (OBSPs) have access to a well designed, and a high performing interface. It provides positive experience for retail, SME and corporate customers using OBSP services and encourages them to continue consuming OB enabled services

45

Conformance

Conformance process is to help the OB ecosystem participants understand if they are in full compliance with the functional, technical and security
requirements as defined by the OB governing entity.

46

Conformance Test Suite (CTS)

The technical conformance of OBSP’s software using a range of test scenarios targeting specific areas.

47

Use Case

A possible set of interactions between a user and a system inside the Open Banking ecosystem which is related to achievement of a financial goal. A use case helps to drive collaborative business opportunities through standardization of API and customer experience guidelines.

48

Open Banking

The sharing and leveraging of data through APIs with OBSPs, who in Kuwait, are registered as AISPs or as PISPs based on customers’ explicit consent.

49

Decentralised Ecosystem for Data Sharing

In a decentralised model, data also remain at the source or point of service. However, participating members agree to share their data with other participants individually. Each participating organisation maintains ownership and control of the data within its source databases.

50

Certificate Signing Request (CSR)

A certificate provided by OBSPs which includes technical details of production environment before Conformance Test.

51

Complaint

Any oral or written expression of dissatisfaction from a Customer or a Participant to another Participant in connection with the provision of, or failure to provide, an Open Banking Service to the Customer or the other Participant

52

Complainant

A person raising a Complaint about the activities that a Participant provides

53

Participants

All Open Banking Participants including ASPSPs and OBSPs

54

Writing

The term applies to electronic, digital, or paper based document

55

Claims

Liability arising due to a Complaint

56

Dispute

A Complaint where Complainant disputes a transaction executed by a Participant

57

Service Operators

Any company registered to manage and operate the E-Payment systems infrastructure and its instruments in the State of Kuwait

58

Registry

CBK Register of the Open Banking Service Providers (OBSPs).

59

Registration

Enrollment in the CBK registry.

60

Competent Authority (CA)

The body which the State of Kuwait assigns to supervise the issuance of licenses necessary for carrying out services in the field of electronic transactions and information

61

Applicant

A Company that intends to or has submitted an application for licensing to CBK

1

AIS

Account Information Service

2

AISP

Account Information Service Provider

3

API

Application program interface

4

ASPSP

Account Servicing Payment Service Provider

5

CIBA

Client Initiated Backchannel Authentication

6

CSR

Certificate Signing Request

7

CTS

Conformance Test Suite

8

CX

Customer Experience

9

HTTP

Hypertext Transfer Protocol

10

HTTPS

Hypertext Transfer Protocol Secure

11

JSON

JavaScript Object Notation

12

KPI

Key Performance Indicator

13

LG

Letter of Guarantee

14

OB

Open Banking

15

OBF

Open Banking Framework

16

OBSP

Open Banking Service Providers

17

OG

Operational Guidelines

18

OIDC

OpenID Connect

19

PASP

Payment Aggregator Service Provider

20

PIS

Payment Initiation Service

21

PISP

Payment Initiation Service Provider

22

REST

Representational State Transfer

23

SCA

Strong Customer Authentication