Page Comparison

Open Banking is the secure way to give providers access to customer’s financial information. It opens the way to new products and services that could help customers and small to medium-sized businesses get a better deal. It could also give you a more detailed understanding of customer’s accounts, and help customers find new ways to make the most of their money.
Open banking also refers to sharing and leveraging of data (for which customer has consented) by banks with third party developers and firms to build applications and services. For example, third party providers (TPPs) provide real-time payments, greater financial transparency options for account holders, marketing and cross-selling opportunities.

Account Servicing Payment Service Providers (ASPSP) refers to the CBB licensees (include conventional retail bank licensees and Islamic retail bank licensees) who provide and maintain a payment account for a user/customer and, in the context of the Open Banking Ecosystem are entities that publish Read/Write APIs to permit, with customer consent, payments initiated by third party providers and/or make their customers’ account transaction data available to third party providers via their API end pointsendpoints.

Strong Customer Authentication or ‘SCA’ is an authentication based on the use of three elements categorized as knowledge (something only the user knows [for example, a password]), possession (something only the user possesses [for example, a particular cell phone and number]) and inherence (something the user is [or has, for example, a finger print fingerprint or iris pattern]) that are independent, so the breach of one does not compromise the others, and is designed in such a way as to protect the confidentiality of the authentication data.

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

Functionality, endpoints and fields marked as Conditional may be required in some cases for regulatory compliance (for example, if these are made available to the USER/CUSTOMER in the ASPSP's existing Online Channel, or if ASPSPs (or a subset of ASPSPs) have been mandated by a regulatory requirement).
For functionalities and endpoints:

• An ASPSP must implement functionality and endpoints marked as Conditional if these are required for regulatory compliance

For fields:

• All fields that are not marked as Mandatory are Conditional

• An AISP/PISP may specify the value of a Conditional field

• An ASPSP must process a Conditional field when provided by the AISP/PISP in an API request , and must respond with an error if it cannot support a particular value of a Conditional field

An ASPSP must include meaningful values for Conditional fields in an API response if these are required for regulatory compliance.

Functionality and endpoints marked as Optional are not necessarily required for regulatory compliance but may be implemented to enable desired customer outcomes.

For functionalities and endpoints:

• An ASPSP may implement ASPSP may implement an Optional endpoint

• An ASPSP may implement ASPSP may implement Optional functionality

For fields:

• There are no Optional fields

For any endpoints which are implemented by an ASPSP, the fields are either Mandatory or Conditional.

An idempotency key is used to guard against the creation of duplicate resources when using the POST API endpoints (where indicated).
If an idempotency key is required for an API endpoint:
The x-idempotency-key provided in the header must be at most 40 characters in size. If a larger x-idempotency-key length is provided, the ASPSP must reject the request with a status code is 400 (Bad Request).

• The AISP/PISP must not change the request body while using the same x-idempotency-key. If the AISP/PISP changes the request body, the ASPSP must not modify the end resource. The ASPSP may treat this as a fraudulent action.

• The ASPSP must treat a request as idempotent if it had received the first request with the same x-idempotency-key from the same AISP/PISP in the preceding 24 hours.

• The ASPSP must not create a new resource for a POST request if it is determined to be an idempotent request.

• The ASPSP must respond to the request with the current status of the resource (or a status which is at least as current as what is available on existing online channels) and a an HTTP status code of 201 (Created).

• The ASPSP may use the message signature, along with the x-idempotency-key to ensure that the request body has not changed.

If an idempotency key is not required for an API endpoint:

• The ASPSP must ignore the idempotency key if provided.

A number of resources in the specification include a section for Supplementary Data. This is intended to allow ASPSPs to accept or provide information in a request or response that is not catered for by other sections of the resource definition.
The Supplementary Data section is defined as an empty JSON object in the specification.
Wherever used, an ASPSP must define and document (on their developer portal) their own structure, usage and (mandatory/optional) requirements for Supplementary Data.
An ASPSP must not use Supplementary Data if an element already exists in the OBF standard that fulfils fulfills the requirement.