Confirmation of Available Funds
A CBPIICard Based Payment Instrument Issuer – a payment services provider that issues card-based payment instruments and allows its customers to pay from bank accounts. performing as a TPPThird-Party Provider – an authorised online service provider introduced as part of Open Banking. TPPs exist outside of the account holder’s relationship with their bank but may be involved in transactions carried out by the user. must have the explicit consent of the PSUPayment Services User – an individual person or legal business entity making use of an Open Banking service as a payee, payer or both. (customer) prior to making a Confirmation of Funds (CAFConfirmation of Available Funds – A CBPII begins the Confirmation of Funds journey by registering a request to confirm funds of a PSU. The CBPII must then obtain consent from the PSU in order to authorise the request, enabling it to request the information. Once the request is authorised, the CBPII will be able to invoke Confirmation of Funds API to the confirm availability of funds in the PSU account.) request to the customer's bank. This means that the TPP must allow its customer to enter their bank account details in accordance OBIEOpen Banking Implementation Entity – organization created by the CMA (Competition and Markets Authority) to deiver APIs, data structures and security architectures that enable developers to harness technology, making it easy and safe for account holder's to share their financial information held by the banks with third parties. and PSD2PSD2 stands for Payment Services Directive 2 and is a new EU regulation in effect since September 14, 2019. It governs electronic and other non-cash payments. The main provision of PSD2 is for Strong Customer Authentication (SCA), a process that seeks to make online payments more secure and reduce fraud while increasing authorisation rates. The European Banking Authority (EBA) recently extended the deadline for PSD2 compliance until December 31, 2020. requirements. Essentially, the TPP initiates consent between the customer and the bank, which then allows the TPP to request whether or not sufficient funds are currently available in the customer's bank account to cover the payment amount specified.
In the context of the confirmation of funds queries discussed here, CBPII and TPP are one and the same.
The general request-response flow looks like this (hover to enlarge):
Hence, as a CBPII, you will need to create an AccessTokenRequest using the SDK's createConfirmationRequest() method. To do so, you will need to include the bankId and a BankAccount object. Please be aware that the bank will not prompt the user to select an account. Instead, the user must provide the account to the TPP, then give CAF consent to the bank for the user-specified account during redirect. The bank's response to the TPP will be a Boolean value — true if sufficient funds are available, false if not.
Important: The CBPII must be a legal entity operating with its own FCAFirms and individuals must be authorised by the Financial Conduct Authority (FCA) equivalent in each country to carry out regulated financial service activities and offer credit to consumers. For the list of FCA-equivalent regulators outside of the UK, please visit https://www.fca.org.uk/firms/passporting/regulators-eu-eea (or country-equivalent) licence.
Let's go through the request-response process step by step.
Briefly, you have to build an access token request and store it. At a minimum, it must contain the relevant details for the account you wish to access — bank, grantor (the account holder), your memberId, and the account, along with a description of why you are requesting the information and your callback URL, so you can redeem the token once it's issued. There are also a number of other, optional, data items you can include for your own tracking and control.
A RequestId is generated and returned with the token payload in response to your token request submission. This identifier references the stored TokenRequest and is used to validate the conditions of the request and to verify that these conditions remain unchanged. You must include the RequestId in the URL that redirects the customer to Token to obtain user authentication and authorisation.
Each token request submission has a time limit of 20 minutes. If you do not receive a response within the allotted timeframe, your token request expires and a new request will have to be created and submitted.
Tip: If you know the request-id, you can retrieve the result of any token request — even requests that have expired — with a call to getTokenRequestResult(tokenRequestId). An unauthenticated call can be made within the 20-minute expiration period. It looks like this:
// Get the token request result based on a token's tokenRequestId=
You can make an authenticated call to fetch the request result at any time if you are the TPP that created the original token request. The authenticated version of the call looks like this:
// Get the token request result based on a token's tokenRequestId
Most importantly, the TPP member creating the TokenRequest must match the TPP member redeeming the token or token redemption will fail and access will be denied.
Next, if you will be using your own bank-selection UI, rather than the Token Web App, let's briefly discuss the SDK's getBanks() method for filtering the list of Token-connected banks. Otherwise, if you will be using the Token Web App for bank selection, you can skip the getBanks() method discussion and move directly to these topics: