Credit Insight

Credit Insight

Introduction

Credit Insight, is an Open Banking Product which relies on an AIS collection of transaction data for the selected client.

The prerequisites to provide a Credit Insight analysis are :

  • At least one CHECKING account provided
  • At least 20 transactions within the last 90 days
  • Transactions must be in EURO
  • A callback URL must be provided beforehand.

The workflow goes as follows :

  1. The Initiating Party posts and initiates a registration for the client, and chooses the relevant product option.

  2. Worldline responds with the appropriate URL for the consent and AIS session, and the client is then redirected to the AIS Bank selection pages.

  3. Once the client has selected its bank(s) and accounts, Worldline collects the transactions and balances for the last three months from the bank(s).

  4. The Credit Insight analysis is performed, and once the results are available, they are sent to the Initiating Party's callback URL.

Details

For the Credit Insight usecase the relevant and usable endpoints are within the Account Information extended service:

  • POST /register : initiates the process
  • POST /register/{registrationId}/initialisation/{psuId} : used to retrieve the URL to the AIS consent page for the PSU (client)
  • GET /register/{registrationId}/status : allows the Initiating Party to know the status of the process (optional)

After the process is initiated and the client has consented to give access to his account(s), the processing begins on the Credit Insight engine.

Once it has completed, the Initiating Party receives the response on the callback URL they provided during the onboarding.

http://www.plantuml.com/plantuml/png/VLHXRzis4FskNt5pWStM6h1RzwcDWygoimapRC5oC0me433MsIP2am99kUj-_Owq54LAbcyYx-xTUu-d-s8TDwu-oUW7TyGJmbay6AvSv8IJ2EiA5SouUXJg0BdaRg_D2SRdZv1a1IHvPYTm1Qd1KZZ8b1M7euCxYv1oYnGfg8vWykAE3ki_OI_rjwYYZc8dAce38mgDW5kV4ZteVpmc0Jay6Ew4Ll1kwJ4VP8tzkam99xWBlEZ-EunJAL2vIK3Bydxsgpf2vdgMHwXAeDulY8KA62T5NkGNtF3Ppnk8NwY3K1YIqopo8DTNLpT423uDVLA89PP0L8BwwJJujC63iAvHFvr6VEV4cJlqcWY5i8WoWSLnlYwsm7ZjZjg8Vv4v_OWgZjz3KbKmzI_q7YwcqEbwYuhutho7hFJ7phzWNrRU43fnRT1do0qQ292ljZM19feuZdoWbVZ7Tfl3hnz-yLg9TFbcBRispyJUY_A6YK1B2Xkks7LbQty_w99gPRsi0gsbD0BUaBC6T-xEo3Y6posF3pHqhR5jqHMqsgcoG7CME_H61wOXyzCpm73Xz5ErlRGaGXHef4KbFd-bzZk4fDRLkx-EWewtsW0b7g4ThGj4Qy_JDP6IkFFqMj5Xx3hTpmH48TJoQ0vFCXWBU4aOaSRJy0_2E9w0H5xI-tjrHPemrX7tE2qQZQz78utzy91RijlfMZaBIs4T67H6u9dB7i6NWjioaBxAji87YOojAt_DfMzKbf0exOveWbqj16FXH_Q64xSt7tEuFBhNp7gFIJ2z_uycQJpdZjD3o8RfX4PdQCKWfMS1XRU6Ayj3oCBu8voqSaSBHt90c-yJ-AhWPr8ckTgX3Uk1IzbuWoNmnkYEJMuqPLgIqx6XRcdMSWb3GxenBAVeO7JT3kLblyvaZJsNUskeSDpL5dxqczqlzkQyQT-OiS5lpjZlYxV_SniW61lys8ozqdSAjqBvdK3YFpFsLJ7M9p8DbuGrJxR9VRfUBXVfDbklxkVhrIAE_o-ws6pMcpY6yTx3JzgqP9Ki_owoulusew-iMCnVvcIpP1L6ThXiBaCOfLatlOErRy5WfOsBvjsSfPb_p4suzqFPZLJMtvksbivIny7sJcb07lZkyMwp94D_0gK9rFXkT1YDUjMZ4Trvd_TXlm_OGV6D7muKsGk9OVQehA913OSJTunHEKaCFNhFthZm6wp2jdIeNFI5CkkJ_0y0

 

The initial POST /register call should be as follows:

POST /register
{
    "RegistrationId": "<registration_id>",
    "Psus": [
        {
            "PsuId": "<psu_id>"
        },
    ],
    "Parameter":[
        {
            "Key":"option",
            "Value":"NONE||CS||PS||CSPS"
        }
    ]
}

The Product options need to be specified, in the "Parameter" field. Depending on the items the Initiating party needs returned. In any case, the base response will comprise the Credit Insights, which are further detailed below. The Product options are :

  • CS : Credit Score
  • PS : Payment Score
  • CSPS : Both
  • NONE : No scores, only the insights

Credit Insights: The Credit Insights service takes the raw balance and transaction data from the bank and transforms this into an insightful financial report.

All of the transactions are categorized with a specific focus credit, important data is flagged (such as existing loans, payment rejections, etc…) and useful metrics are calculated.

All of this is delivered by API to provide you an instant analysis based on data retrieved directly from the consumer’s bank.

Credit Score: The Credit Score is a number score out of 1000 (a consumer with a score of 0 is the most risky and 1000 the least risky). This number provides a highly accurate predictive assessment of the risk of default within 12 months of the scoring.

Payment score: The payment score is designed for use with short-term credit (repayment period of around 3 months). This is provided as a score out of 10 (a consumer with a score of 0 is the most risky and 10 the least risky).

The second call (POST /register/<registration_id>/initialisation/<psu_id>) is meant to provide a base country for the initiation screens that will be shown to the client.

POST /register/<registration_id>/initialisation/<psu_id>
{
  "PsuData":{
    "Country": "FR||DE||XY.."
  }
}

    After the client has consented to the AIS process, the transactions are fetched and processed in the WL Credit Insight engine.

     

    Once the analysis is performed, the following insights are sent within the response to the Initiating Party :

    Object name

    In Object

    Description of the items

    Balances

    balance

    balanceDate

    Balances of the client's accounts.

    Incomes

    totalAmount
    monthlyAmount

    incomesDetails (object)

    Summary of the client's sources of incomes. Details show a breakdown in types and temporality of incomes.

    Expenses

    totalAmount
    monthlyAmount

    expensesDetails (object)

    fixedCharges

    otherExpenses

    Summary of the client's expenses. Details show a breakdown of the expenses, notably the fixed charges.

    Loans

    loanRepaymentsCount

    loanRepayments (object)
    totalAmount

    monthlyAmount

    loanProviders

    drawdownsCount

    totalDrawdownAmount

    monthlyDrawdownAmount

    Summary of the loan repayment transactions on the client's account.

    Risks

    gamblingTotalAmount

    gamblingTransactionsCount

    gamblingTransactions

    paymentRejectionsCount

    paymentRejections

    paymentRejectionsTotalAmount

    checkRejectionsCount

    checkRejections

    checkRejectionsTotalAmount

    interventionFeesCount

    interventionFees

    interventionFeesTotalAmount

    overdraftReachedAmount

    overdraftDuration

    overdraftFeesCount

    overdraftFees

    wageAdvancesCount

    wageAdvances

    wageAdvancesTotalAmount

    directRecoveriesOfDebtCount

    directRecoveriesOfDebt

    directRecoveriesOfDebtTotalAmount

    bankAccountSeizuresCount

    bankAccountSeizures

    bankAccountSeizuresTotalAmount

    Detailed list of all identified transactions that fit a risky behavior.

    Account Information Overview

    Account Information overview

    What is Account Information Service and how do i get started?

    What is Account information?

    Account Information Service (AIS) is one of the services established by the Payment Services Directive 2 (PSD2) and aimed to simplify the retrieval of account information. The PSD2 allows Third Party Providers (TPPs) access to the bank's accounts to initiate a payment (PIS) or retrieve account information (AIS) after the account holder (PSU) has given his consent to the TPP.

    A payer (PSU) has to consent to a TPP for account information to initiate a AIS request. 

    Ready to connect?

    • Get in touch with our sales team: Send email
    • Using PSD2 requires a Third Party Provider certificate provide by the national authority. This certificate will be stored in our solution. So that we can connect to ASPSP's with the correct authentication. We will help with the ordering process.
    • We set you up on our backoffice, you will receive a username password to complete the registration process. Which includes providing a public key from the certificate you will be using to connect to us.
    • Call the post token api, to retrieve the token which you will use to connect to our other api's
    • Call the get aspsps api, to retrieve the list of banks you will be able to reach with our solution
    Enable "on this page" menu on doc section
    On

    AIS Delete Consents

    AIS Delete Consents

    Using this scenario initiating party (user) can request to revoke a consent given by customer (PSU). When this endpoint is called the TPP solution will also try to revoke the consent at ASPSP side.

    If this is successful the status of the consent will be changed to ‘Revoked’.

    If it’s not possible to revoke the status at the ASPSP side the status of the consent will be set to ‘RevokedAtTpp’, The consent might still be active on the ASPSP side bit will no longer be used by the TPP solution.

    For this scenario, it has been considered that consent has been revoked successfully at ASPSP Mock side.

    Take the following steps to complete this scenario.

     

    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 = “AIS Delete Consents” and the ASPSP ID = “20101”, 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 : Acquire customer’s (PSU) consent :

    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 initiated payment and link to call GET /consent/status API to get the status of the consent.

    If GET /consents/status endpoint has been called before user provides his / her approval, initiating party (user) will receive payment 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 (user) can enter any username and password as this is example purpose only. Once customer (PSU) provides his / her dummy credentials, he / she will be redirected 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 and customer (PSU) will redirect back to initiating party (user).

    Remark : GUI page of ASPSP Mock to approve or deny the consent is just a demo purpose. Actual ASPSP GUI page to approve or deny the consent may vary based on 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 : Delete the consent :

    If consent status = “Authorised”, call the Delete /consents API to revoke the consent.

     

    Step – 6 : Get the consent status :

    Call the GET /consents/status API to get the latest consent status from ASPSP Mock.

    If consent is revoked successfully by ASPSP Mock, initiating party (user) will receive consent status = “Revoked” 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.

     

    Sequence Diagram :

    AIS Delete consent
    Enable "on this page" menu on doc section
    On

    AIS Download Transactions

    AIS Download Transactions

    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 :

    AIS Download Transactions
    Enable "on this page" menu on doc section
    On

    AIS with Redirect Authorisation and Accounts, Balances & Transactions (With DateTime filter)

    AIS with Redirect Authorisation and Accounts, Balances & Transactions (With DateTime filter)

    Using this scenario, initiating party (user) can request transaction data from ASPSP Mock using date & time filter ("dateFrom" & "dateTo" query parameters). This is to let initiating party (user) know that some actual ASPSPs are provides requested transaction data based on date & time.

     

    Step - 1 : Get the reach details :

    Reach details provides list of APIs and mandatory fields needs to be used for successful request towards ASPSP mock.

    Call the reach API - GET /aspsp. Get the ASPSP details with Name = "Account Information redirect + Transaction datetime filter" and the ASPSP ID = "20116", 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.

     

    Step - 7 : Get the transaction details for respective account :

    Call the GET /transactions API to retrieve transactions details of respective account from ASPSP Mock. Initiating party (user) can try out below functionalites of GET /transactions API.

    • Initiating party (user) can request to get transaction data for specific date range using "dateFrom" & "dateTo" query parameters. Remark : For this filter if initiating party (user) provides date & time in "dateFrom" & "dateTo" fields, ASPSP Mock will return transaction data based on both date & time provided. This is to let initiating party (user) know that some actual ASPSPs are also behaves the same way to filter transaction data (Omit time part).
    • If ASPS Mock respond with large number of transactions, initiating party (user) may receive paginated transactions response.
    • In case of paginated response, initiating party (user) can retrieve appropriate transactions page using "first", "next", "previous", "last", "self" links provided in response.

     

    Sequence Diagram :

    AIS + Accounts + Balances + Transactions
    Enable "on this page" menu on doc section
    On

    AIS with Redirect Authorisation and Accounts, Balances & Transactions (With Date filter only)

    AIS with Redirect Authorisation and Accounts, Balances & Transactions (With Date filter only)

    Customer's (PSU) consent needs to be acquire first to access his / her bank's accounts details. In the Redirect Authorisation approach, the bowser session of the customer (PSU) is redirected from the Initiating Party (user) to the ASPSP Mock. In that case the ASPSP Mock provides all the pages required for authentication (usually username, password). After that the customer (PSU) is redircted to the TPP solution and frm ther back to the Initiating Party (user).

    Take the following steps to complete this scenario.

     

    Step - 1 : Get the reach details :

    Reach details provides list of APIs and mandatory fields needs to be used for successful request towards ASPSP mock.

    Call the reach API - GET /aspsp. Get the ASPSP details with Name = "Account Information redirect + Transaction Date filter" and the ASPSP ID = "20101", 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.Account Information Services Scenarios

     

    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.

     

    Step - 7 : Get the transaction details for respective account :

    Call the GET /transactions API to retrieve transactions details of respective account from ASPSP Mock. Initiating party (user) can try out below functionalites of GET /transactions API.

    • Initiating party (user) can request to get transaction data for specific date range using "dateFrom" & "dateTo" query parameters. Remark : For this filter if initiating party (user) provides date & time in "dateFrom" & "dateTo" fields, ASPSP Mock will return transaction data based on date only. It will omit time part to filter transaction data. This is to let initiating party (user) know that some actual ASPSPs are also behaves the same way to filter transaction data (Omit time part).
    • If ASPS Mock respond with large number of transactions, initiating party (user) may receive paginated transactions response.
    • In case of paginated response, initiating party (user) can retrieve appropriate transaction page using "first", "next", "previous", "last", "self" links provided in response.

     

    Sequence Diagram :

    AIS + Accounts + Balances + Transactions
    Enable "on this page" menu on doc section
    On

    Payment with Redirect and Embedded - Hybrid Authorisation

    Payment with Redirect and Embedded - Hybrid Authorisation

    Some ASPSP requires hybrid payment authorisation for payment processing.

    Take the following steps to complete this scenario.

     

    Step – 1 : Get the reach details :

    Call the reach API – GET /aspsp. Get the ASPSP details with Name = “Payment Redirect with Embedded – Hybrid flow” and the ASPSP ID = 20121, which has to be used to initiate the payment with hybrid mode of authorisation and other further payment related 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 "Payment Initiation Scenarios" page.

     

    Step – 2 : Payment initiation and customer authentication :

    • Initiate the payment : Call the POST /payments API without ASPSP PSU-ID and with other mandatory fields in request header and body. In response of POST /payments, initiating party (user) will receive Payment ID, “AspspRedirectUrl” URL for  customer (PSU) authentication at ASPSP Mock & GET /payments/status API link.

    • Customer Authentication : Customer (PSU) will be redirected to ASPSP Mock GUI page to provide his / her PSU-ID (Customer ID) which is known to the Bank. At this point, customer (PSU) can provide his / her authentication to ASPSP Mock or cancel the payment initiation.

    Remark : Customer can provide dummy PSU-ID (Customer ID) to ASPSP Mock.

    If GET /payments/status endpoint has been called, initiating party (user) will receive payment status = “Open” from the ASPSP Mock in response.

     

    Step – 3 : Get the payment status and select authentication method :

    • Get the payment status : Call the GET /payments/status API. If customer cancel the authentication process, ASPSP Mock will respond with payment status = “Cancelled” to initiating party (user). If customer (PSU) authenticated successfully at ASPSP Mock, Mock will respond with list of available SCA methods (if multiple SCA methods available at ASPSP) for the customer (PSU) to choose.

    • Select authentication method : For this scenario, customer (PSU) need to choose ‘SCARedirect’ method for payment authorisation and initiating party (user) need to call the PUT /payments/authorisations to update the selected SCA method to ASPSP Mock. In response, ASPSP Mock will respond with “ASPSPRedirectURL” for payment authorisation.

    Remark : Payment status provided for this scenario is just to guide initiating party (user) for payment initiation process. Actual payment status may vary based on scenario from actual ASPSP.

     

    Step – 4 : Authorise or Cancel the payment at ASPSP Mock :

    With ASPSP redirect link received in response of PUT /payments/authorisation, customer (PSU) will get redirect to ASPSP Mock GUI page with “Approve” & “Deny” buttons to authorise or cancel the payment.

    If customer (PSU) “Approve” the payment, payment will get initiated with the ASPSP Mock and customer (PSU) will redirect back to initiating party (user).

    If customer (PSU) “Deny” the payment, ASPSP Mock will reject the initiated payment and customer (PSU) will redirect back to initiating party (user).

    Remark : GUI page of ASPSP Mock to approve or deny the payment is just a demo purpose. Actual ASPSP GUI page to approve or deny the payment may vary based on ASPSP.

     

    Step – 5 : Get the payment status :

    Call the GET /payments/status API to get the latest payment status from ASPSP Mock.

    If payment is authorised by customer (PSU), initiating party (user) will receive payment status = “SettlementCompleted”.

    If payment is deny by customer (PSU), initiating party (user) will receive payment status = “Cancelled” as final payment status.

    Remark : Payment status provided for this scenario is just to guide initiating party (user) for payment initiation process. Actual payment status may vary based on scenario from actual ASPSP.

     

    Sequence Diagram :

    Payment with Redirect and Embedded - Hybrid Flow
    Enable "on this page" menu on doc section
    On

    Explicit PreAuth (in Embedded) Payment with Embedded Authorisation

    Explicit PreAuth (in Embedded) Payment with Embedded Authorisation

    For this scenario, explicit embedded Pre-Authentication is require with payment in embedded authorisation.

    Take the following steps to complete this scenario.

     

    Step – 1 : Get the reach details :

    Call the reach API – GET /aspsp. Get the ASPSP details with Name = “Payment embedded with Explicit PreAuth Embedded” and the ASPSP ID = “20120”, which has to be used to initiate the payment and other further payment related 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 "Payment Initiation Scenarios" page.

    Below is example of pre-authentication reach details for ASPSP.

    { 
    "AspspId": "<ASPSP ID>",
    "Name": [<ASPSP Name],
    "CountryCode": "XX",
    "CategoryLabel": [Retail],
    "Details": [{ 
                    "Api": "POST /pre-authentication",                
                    "Type": "SUPPORTED",
                    "ProtocolVersion": "XX_V_1_1"           
                },
                {
                    "Api": "POST /payments",                
                    "FieldName": "UsePreAuthentication",
                    "Type": "MANDATORY",
                    "Value": "true",
                    "ProtocolVersion": "XX_V_1_1"                  
                },
                {
                    :
                    :
                },
               ],
    "Options": [{
                    "Key1": "PREAUTH_MANDATORY",
                    "Value": "1",
                    "Level": "INFORMATIONAL"
                },
                { 
                    "Key1": "PREAUTH_EXPLICIT_REQUIRED",
                    "Value": "1",
                    "Level": "CRITICAL"
                },
                {
                    "Key1": "REACH_ASPSP_FOR_PRE_AUTH",
                    "Value": "1",
                    "Level": "CRITICAL"
                }
               ],
    "BIC": "XXPIS001"
    }

    In above example, POST /pre-authentication API is mentioned without FieldName and Type = “SUPPORTED” means, ASPSP is supporting pre-authentication.

    "Api": "POST /pre-authentication",                
    "Type": "SUPPORTED",
    "ProtocolVersion": "XX_V_1_1"    

    In POST /payments request, “UsePreAuthentication” flag value send to be “true” to reuse the pre-authentication token for further payment related requests.

    "Api": "POST /payments",                
    "FieldName": "UsePreAuthentication",
    "Type": "MANDATORY",
    "Value": "true",
    "ProtocolVersion": "XX_V_1_1"        

    The Options section is providing information regarding the way of using API endpoints for specific ASPSPs similar to the Details section. In example, the given ASPSP pre-authentication is mandatory because the value of PREAUTH_MANDATORY option is set to 1.

    "Key1": "PREAUTH_MANDATORY",
    "Value": "1",
    "Level": "INFORMATIONAL"

    In example, the given ASPSP, Pre-authentication has to be done explicitly by the POST /pre-authentication endpoint because the value of PREAUTH_EXPLICIT_REQUIRED option is set to 1.

    "Key1": "PREAUTH_EXPLICIT_REQUIRED",
    "Value": "1",
    "Level": "CRITICAL"

    In example, REACH_ASPSP_FOR_PRE_AUTH flag indicate that an explicit preAuth request must be sent to the ASPSP in the TPP preAuth API. Otherwise, the TPP preAuth API handles this request only internally.

    "Key1": "REACH_ASPSP_FOR_PRE_AUTH",
    "Value": "1",
    "Level": "CRITICAL"

     

    Step – 2 : Initiate the payment :

    To initiate the payments, below processes needs to be follow.

    • Explicit Pre-Authentication in Embedded
    • Payment authorisation in Embedded

     

    Step – 3 : Initiate Explicit Pre-Authentication in Embedded :

    Perform below steps to initiate explicit pre-authentication in embedded.

    • Initiate explicit pre-authentication : Call POST /pre-authentication to initiate explicit Pre-Authentication process. In response of POST /pre-authentication, initiating party (user) will receive PreAuthenticationId, link for “UpdatePsuCredentialsForPreAuthentication” API endpoint for customer (PSU) authentication and “GetPreAuthenticationStatus” API link to get the status of the PreAuth from ASPSP Mock.

    • Perform customer (PSU) authentication : Call the PUT /pre-authentication API with customer’s (PSU) credential details. Once ASPSP Mock identifies customer (PSU) successfully, it will response with list of available SCA methods with “SelectAuthenticationMethod” link (if multiple SCA methods available at ASPSP) for the customer (PSU) to choose.

    • Authorisation method selection : Once appropriate SCA method chosen to authorise the payment by customer (PSU), initiating party (user) need to call the PUT /pre-authentication API to inform ASPSP Mock.

    • Provide challenge data for selected SCA method : Based on selected SCA method by customer (PSU), ASPSP will response with Challenge Data for customer (PSU) for authentication. Once customer (PSU) respond with answer to Challenge Data, initiating party (user) need to call the PUT /pre-authentication API to inform ASPSP Mock. ASPSP Mock will verify the details.

    Remark : If initiating party (user) calls GET /pre-authentication/status API during pre-authentication process, ASPSP Mock will  respond back PreAuthenticationStatus = “Open”.

     

    Step – 4 : Get the pre-authentication status :

    Call the GET /pre-authentication/status API to get the pre-authentication status from ASPSP Mock.

    If pre-authentication is authorised by customer (PSU), initiating party (user) will receive PreAuth status = “Authorised”.

    If pre-authentication is deny by customer (PSU), initiating party (user) will receive PreAuth status = “Rejected” and payment cannot be initiated by initiating party (user).

    Remark : Pre-Authentication status provided for this scenario is just to guide initiating party (user) for pre-authentication process. Actual pre-authentication status may vary based on scenario from actual ASPSP.

     

    Step – 5 : Payment initiation and Authorisation steps :

    • Initiate the payment : Once customer (PSU) authenticated successfully with ASPSP and PreAuthenticationStatus = “Authorised”, Call the POST /payments API with mandatory fields in request header and body. In response of POST /payments, initiating party (user) will receive list of available SCA methods with “SelectAuthenticationMethod” link (if multiple SCA methods available at ASPSP) for the customer (PSU) to choose.

    • Authorisation method selection : Once appropriate SCA method chosen to authorise the payment by customer (PSU), initiating party (user) need to call the PUT /payments/authorisation API to inform ASPSP Mock. Based on selected SCA method by customer (PSU), ASPSP will response with Challenge Data for customer (PSU) to authorize the payment.

    • Provide challenge data for selected SCA method : Once customer (PSU) respond with answer to Challenge Data, initiating party (user) need to call the PUT /payments/authorisation API to inform ASPSP Mock. ASPSP will verify the details and starts payment settlement process.

    If GET /payments/status endpoint has been called before initiating party (user) provides his / her approval, initiating party (user) will receive payment status = “Open” from the ASPSP Mock in response.

     

    Step – 6 : Get the payment status :

    Call the GET /payments/status API to get the latest payment status from ASPSP Mock.

    If payment is authorised, initiating party (user) will receive payment status = “SettlementCompleted” as final payment status.

    If during any step in Embedded authorisation process, if customer (PSU) has not provided appropriate response, payment will be marked as “Cancelled” at ASPSP Mock and initiating party (user) will receive payment status = “Cancelled” as final payment status.

    Remark : Payment status provided for this scenario is just to guide initiating party (user) for payment initiation process. Actual payment status may vary based on scenario from actual ASPSP.

     

    Sequence Diagram :

    Explicit PreAuth Payment with Embedded Authorisation
    Enable "on this page" menu on doc section
    On

    Cancel Payment

    Cancel Payment

    Some ASPSPs supports payment cancellation. Customer (PSU) / Initiating party (user) can cancel the initiated payment with ASPSP if payment settlement process not started by the customer’s (PSU) bank.

    As a TPP solution provider, we are allowing to cancel the payment if payment status are as below,

    PaymentStatus
    {
           “Open”,
           “Pending”,
           “PartiallyAuthorised”,
           “Authorised” 
    }

    Remark : Payment cancellation is not allowed if payment status for initiated payment is apart from any other from mentioned above.

    For this scenario, we have considered that payment status = “Authorised” for the initiated payment.

    Take the following steps to complete this scenario.

     

    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 = “Payment Cancellation” and the ASPSP ID = “20114”, which has to be used to cancel the initiated payment and other further payment related 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 "Payment Initiation Scenarios" page.

     

    Step – 2 : Initiate the payment :

    Call the POST /payments API with mandatory fields in request header and body. In response of POST /payments, initiating party (user) will receive payment ID, ASPSP redirect link to authorise the initiated payment and link to call GET /payments/status API to get the status of the initiated payment.

    If GET /payments/status endpoint has been called before user provides his / her approval, initiating party (user) will receive payment status = “Open” from the ASPSP Mock in response.

     

    Step – 3 : Authorise or Cancel the payment at ASPSP Mock :

    With ASPSP redirect link received in response of POST /payments, customer (PSU) will get redirect to ASPSP Mock GUI login page. On this login page, customer (user) can provide dummy credential details as this is example purpose only. Once customer (PSU) provides his / her dummy credentials, he / she will be redirected to ASPSP Mock GUI page with “Approve” & “Deny” buttons to authorise or cancel the payment.

    If customer (PSU) “Approve” the payment, payment will get initiated with the ASPSP Mock and customer (PSU) will redirect back to initiating party (user).

    If customer (PSU) “Deny” the payment, ASPSP Mock will reject the initiated payment and customer (PSU) will redirect back to initiating party (user).

    Remark : GUI page of ASPSP Mock to approve or deny the payment is just a demo purpose. Actual ASPSP GUI page to approve or deny the payment may vary based on ASPSP.

     

    Step – 4 : Get the payment status :

    Call the GET /payments/status API to get the latest payment status from ASPSP Mock.

    If payment is authorised by customer (PSU), initiating party (user) will receive payment status = “Authorised.

    If payment is deny by customer (PSU), initiating party (user) will receive payment status = “Cancelled” as final payment status.

    Remark : Payment status provided for this scenario is just to guide initiating party (user) for payment initiation process. Actual payment status may vary based on scenario from actual ASPSP.

     

    Step – 5 : Cancel the payment :

    If payment status = “Authorised”, call DELETE /payments API to cancel the initiated payment.

     

    Step – 6 : Get the payment status :

    Call the GET /payments/status API to get the latest payment status from ASPSP Mock.

    If payment is cancelled by ASPSP Mock sucessfully, initiating party (user) will receive payment status = “Cancelled”.

     

    Sequence Diagram :

    Cancel Payment
    Enable "on this page" menu on doc section
    On

    Payment with Embedded Authorisation

    Payment with Embedded Authorisation

    For embedded authorisation approach, ASPSP process the payment authorisation through the PISP – ASPSP interface.

    Generally there are three steps involve in embedded payment authorisation process.

    • In first step, customer (PSU) need to authenticate himself / herself with ASPSP.
    • In second step, once PSU successfully authenticated with ASPSP, ASPSP provides list of SCA methods in case of the ASPSP supporting several SCA methods for the corresponding customer (PSU). Customer (PSU) need to choose the appropriate SCA method and need to inform ASPSP through PISP (TPP).
    • In third step, based on chosen SCA method by customer(PSU), ASPSP provide the challenge to PSU to authorise the payment and PSU need to provide challenge response through PISP (TPP) to ASPSP to verify.

    Once all these authorisation steps completed successfully, ASPSP starts payment settlement process.

    Take the following steps to complete this scenario.

     

    Step – 1 : Get the reach details :

    Call the reach API – GET /aspsp. Get the ASPSP details with Name = “Payment Embedded” and the ASPSP ID = “20105”, which has to be used to initiate the payment with embedded mode of authorisation and other further payment related 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 "Payment Initiation Scenarios" page.

     

    Step – 2 : Payment initiation and Authorisation steps :

    Perform below steps to initiate payment.

    • Initiate the payment : Call the POST /payments API with mandatory fields in request header and body. In response of POST /payments, initiating party (user) will receive “PostAuthorisationForEmbedded” API endpoint link customer (PSU) authentication.

    • Perform customer (PSU) authentication : Call the POST /payments/authorisation API with customer’s (PSU) credential details. Once ASPSP Mock identifies customer (PSU) successfully, it will response with list of available SCA methods (if multiple SCA methods available at ASPSP) for the customer (PSU) to choose.

    • Authorisation method selection : Once appropriate SCA method chosen to authorise the payment by customer (PSU), initiating party (user) need to call the PUT /payments/authorisation API to inform ASPSP Mock.

             Remark : Use currently we have populated request body with default selected "AuthenticationMethodId": "13"  for

             "PhotoOTP" SCA method in Put /authoirsations API.

             Request body:

            {
               "AuthenticationMethodId": "13"
            }

    • Provide challenge data for selected SCA method : Based on selected SCA method by customer (PSU), ASPSP will response with Challenge Data for customer (PSU) to authorize the payment. Once customer (PSU) respond with answer to Challenge Data, initiating party (user) need to call the PUT /payments/authorisation API to inform ASPSP Mock. ASPSP will verify the details and starts payment settlement process.

             Remark : Use Put /authorisations API with below request body parameters to provide challenge data to complete

             Embedded authorisation flow.

             Request body:

             {
                "ScaAuthenticationData":"123456"
             }

    If GET /payments/status endpoint has been called before initiating party (user) provides his / her approval, initiating party (user) will receive payment status = “Open” from the ASPSP Mock in response.

     

    Step – 3 : Get the payment status :

    Call the GET /payments/status API to get the latest payment status from ASPSP Mock.

    If payment is authorised, initiating party (user) will receive payment status = “SettlementCompleted” as final payment status.

    If during any step in Embedded authorisation process, if customer (PSU) has not provided appropriate response, payment will be marked as “Cancelled” at ASPSP Mock and initiating party (user) will receive payment status = “Cancelled” as final payment status.

    Remark : Payment status provided for this scenario is just to guide initiating party (user) for payment initiation process. Actual payment status may vary based on scenario from actual ASPSP.

     

    Sequence Diagram :

    Payment with Embedded Authorisation
    Enable "on this page" menu on doc section
    On