Confirmation of Available Funds
A performing as a must have the explicit consent of the PSU (customer) prior to making a Confirmation of Funds (CAF) request to the customer's bank. This means that the TPP must allow its customer to enter their bank account details in accordance and 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 (click 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 (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.io to obtain user authentication and authorization.
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
TokenRequestResult = tokenClient.getTokenRequestResultBlocking(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
TokenRequestResult = member.getTokenRequestResultBlocking(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.io Web App, let's briefly discuss the SDK's getBanks() method for filtering the list of Token.io-connected banks. Otherwise, if you will be using the Token.io Web App for bank selection, you can skip the getBanks() method discussion and move directly to these topics: