Confirmation of Funds API

API Environment Icon
Development
Version
Average Rating
0
No votes yet

The Confirmation of Funds API Profile requires the flows and common functionality for the Confirmation of Funds API, which allows a Card Based Payment Instrument Issuer ('CBPII') to:

  • Register an intent to confirm funds by creating a "funds confirmation consent" resource with an ASPSP, for agreement between the PSU and ASPSP. This consent is a long lived consent, and contains the length of time (expiration date) the customer (PSU) would like to provide to the CBPII; and
  • Subsequently make a request to confirm funds are available.
    • Funds can only be confirmed against the currency of the account.

This profile should be read in conjunction with a compatible Read/Write Data API Profile which provides a description of the elements that are common across all the Read/Write Data APIs, and compatible individual resources.


 

Documentation
Funds Confirmation

Security & Access Control

Scopes

The access tokens required for accessing the Confirmation of Funds APIs must have at least the following scope:

fundsconfirmations: Funds confirmation entitlement

#Grants Types

CBPIIs must use a client credentials grant to obtain a token to make POST requests to the funds-confirmation-consent endpoint. In the specification, this grant type is referred to as "Client Credentials".

CBPIIs must use an authorization code grant using a redirect or decoupled flow to obtain a token to make POST requests to the funds-confirmation endpoint. When accessing, the intent-id in the token must match the ConsentId in the message payload. In the specification, this grant type is referred to as "Authorization Code".

CBPIIs must use a client credentials grant to obtain a token to make GET requests.

The CBPII must create a funds-confirmation-consent resource through a POST operation. This resource outlines the consent that the CBPII claims the PSU has committed to agreeing with the ASPSP, to retrieve confirmation of funds information. At this stage, the consent is not yet agreed between the PSU and the ASPSP.

The ASPSP responds with a ConsentId. This is the intent-id that is used when initiating the authorization code grant (as described in the Trust Framework).

As part of the authorization code grant:

  • The ASPSP authenticates the PSU.
  • The ASPSP plays back the consent (registered by the CBPII) back to the PSU - to agree the consent. The PSU may agree or decline the consent in its entirety (but not selectively).

Once these steps are complete, the consent is considered to have been agreed between the ASPSP and the PSU




POST

  • A CBPII must not create a consent on a newer version, and use it on a previous version.
    • E.g., ConsentId for a funds-confirmation-consent resource created in v4, must not be used to access v3 endpoints.
#GET
  • A CBPII must not access a funds-confirmation-consent on an older version, via the ConsentId created in a newer version.
    • E.g., a funds-confirmation-consent created in v3 accessed via v2.
  • An ASPSP must allow a funds-confirmation-consent to be accessed in a newer version.
  • An ASPSP must ensure details in the funds-confirmation-consent are unchanged when accessed via a newer version.
    • E.g., a ConsentId created in v3 will have the same details when accessed via v3 and v4.
  • An ASPSP may allow expired funds-confirmation-consents to be accessed in a newer version.
#DELETE
  • A CBPII must not delete a funds-confirmation-consent on an older version via a ConsentId created in a newer version.
    • E.g., A funds-confirmation-consent is created in v4, and request DELETE on v3.
  • An ASPSP must support deleting a funds-confirmation-consent from a previous version via a newer version.
    • E.g., A funds-confirmation-consent is created in v3, and request DELETE on v4.

#Funds Confirmation Resource

#POST
  • A CBPII may use a ConsentId created in a previous version to create a funds-confirmation resource in a newer version.
    • E.g., a ConsentId created in v3 can be used as a ConsentId in v4, to POST /funds-confirmations.
  • A CBPII must not use a ConsentId created in a newer version to create Funds Confirmation resource in a previous version.
    • E.g., a ConsentId created in v4, must not be used as a ConsentId in v3, to POST /funds-confirmations.
  • A CBPII may use a token that is bound to a funds-confirmation-consent in a previous version, to access an endpoint of a newer version.
  • An ASPSP must allow a ConsentId from previous version to create a funds-confirmation resource in a newer version, provided it has not expired.
  • An ASPSP must not allow a ConsentId from a newer version to create a funds-confirmation resource in a previous version.