Some ASPSPs do not provide paginated transactions response. In those cases it isn’t possible to predict the number of transactions to be received in response of a GET transactions request.
Even if the ASPSP is supporting paginated responses it might be possible that response on the GET transactions request contains a download link only and no transactions, if the number of transactions is considered too high. In this cases or if the bank isn’t giving the response instead of JSON in CAMT format for example, the TPP solution response on the GET transactions will have a download link instead of a set of transactions.
By calling that download link, the response will be given in a streamed JSON structure starting the stream of transactions already before all transactions are downloaded from the ASPSP. If the bank provides the transactions in a non-JSON format the transactions are converted to JSON on the fly by TPP solution.
Processing flow for this scenario is similar to described in “AIS with Redirect Authorisation + Accounts + Balances + Transactions (With Date filter only)” section with addition of GET /download/transactions API to be called by initiating party (user).
Step – 1 : Get the reach details :
Reach details provides list of APIs needs to be used for this scenario and mandatory fields needs to be passed for successful API call towards ASPSP mock.
Call the reach API – GET /aspsp. Get the ASPSP details with Name = “Account information redirect + Download transactions” and the ASPSP ID = “20102”, which has to be used to initiate the consent with redirect mode of authorisation and other further requests.
Remark : Details of reach information provided in developer portal are limited and informational purpose to give initiating party (user) an idea about how reach information looks like. Initiating party (user) can skip this step and use specified ASPSP ID for the scenario to try out. User can get the ASPSP ID for appropriate scenario from "Scenario Guideline" page or from the list of "Account Information Services Scenarios" page.
Step - 2 : Obtain customer's (PSU) consent to access accounts information :
Call the POST /consentextended API to obtain customer's (PSU) consent. In response of POST /consentextended, initiating party (user) will receive consent ID, ASPSP redirect link to authorise the consent and link to call GET /consent/status API to get the status of the consent.
Below are some consent related functionalities initiating party (user) can try out.
- Below consent permissions are supported to access customer's (PSU) details.
Permissions (Array)
{[
"Accounts",
"Balances",
"Transactions"
]}
Initiating party (user) can request permissions in below combination based on customer's (PSU) request.
- Request permissions for only "Accounts" - Initiating party (user) can only request list of accounts from customer's (PSU) bank. Balances and Transaction details cannot be requested.
- Request permissions for "Accounts", "Balances" - Initiating party can get requet of accounts and balances details for requested accounts from customer's (PSU) bank.
- Request permissions for "Accounts", "Tranacations" - Initiating party can request list of accounts and transaction details for requested accounts from customer's (PSU) bank.
- Request permissions for "Accounts", "Balances", "Transactions" - Initiating party can request list of accounts, balances and transaction details for requested accounts from customer's (PSU) bank.
- If there's no permissions provided in request, by default TPP soultion sends request to get the consent for "Accounts", "Balances", "Transactions" from ASPSP.
- If "OwnerName" indicator set to "true" in consentextended request, initiating party (user) can receive actual owner name (if supported and provided by ASPSP) in response of GET /accounts API.
- "TransactionFromDateTime" and "TransactionToDateTime" can be provided in POST /consentextended request, so that initiationg party (user) can access list of transactions within a specific time period only.
- Currently below fields are being ignored in POST /consentextended request in developer portal. We may introduce another scenario later on to include below fields functionalites.
- ValidUntilDate,
- FrequencyPerDay,
- RecurringIndicatior,
- CombinedServiceIndicator,
- PreferredScaMethod
If GET /consents/status endpoint has been called before user provides his / her approval, initiating party (user) will receive consent status = "Open" from the ASPSP Mock in response.
Step - 3 : Authorise or Cancel the consent at ASPSP Mock :
With ASPSP redirect link received in response of POST /consentextended, customer (PSU) will get redirect to ASPSP Mock GUI login page. On this login page, customer (PSU) can provide dummy credential details as ASPSP GUI page is example purpose only. Once customer (PSU) provides his / her dummy credentials, he / she will be rediereted to ASPSP Mock GUI page with "Approve" & "Deny" buttons to authorise or reject the consent.
If customer (PSU) "Approve" the consent, consent will be created with the ASPSP Mock and customer (PSU) will redirect back to initiating party (user).
If customer (PSU) "Deny" the consent, ASPSP Mock will reject the consent request and customer (PSU) will redirect back to initiating party (user).
Remark : GUI pages of ASPSP Mock for customer login and to authorise the consent is just a demo purpose. Actual ASPSP GUI pages may vary based on acutal ASPSP.
Step - 4 : Get the consent status :
Call the GET /consents/status API to get the latest consent status from ASPSP Mock.
If consent is authorised by customer (PSU), initiating party (user) will receive consent status = "Authorised".
If consent is deny by customer (PSU), initiating party (user) will receive consent status = "Rejected" as final consent status.
Remark : Consent status provided for this scenario is just to guide initiating party (user) for consent process. Actual consent status may vary based on scenario from actual ASPSP.
Step - 5 : Get the list of accounts :
Once consent is authorised by the customer (PSU), call the GET /accounts API to obtain list of accounts from ASPSP Mock.
Step - 6 : Get balances details for respective account :
Once initiating party (user) obtains list of accounts from ASPSP Mock, call GET /balances API to get the balance details of respective account from ASPSP Mock.
Remark : This is an optional step for this scenario. User can skip this step.
Step - 7 : Get the transaction details for respective account :
After getting list of customer's (PSU) accounts from ASPSP Mock, call the GET /transactions API to retrieve transactions details of respective account from ASPSP Mock. In response, initiating party (user) will receive GET /download/transactions API link.
Step - 8 : Call the GET /download/transactions API :
Call the GET /download/transactions API and in response initiating party (user) will receive streamed JSON structure.
Sequence Diagram :
