Integrating with the Core Banking System

Accounts information retrieval

In the Open Banking accounts flow, integration with the core banking system is utilized during account information retrieval requests.

In the Open Banking accounts flow, the WSO2 Open Banking solution manages the consent initiation and authorisation. When the TPP makes account information retrieval requests, the WSO2 Open Banking solution validates the consent request, and upon successful validation, the consent-related information is directed to the core banking system in the form of a header, Account-Request-Information.

This header is a signed JWT, which needs to be decoded by the core banking system. A sample decoded JSON is given below:

{
  "accountRequestIds": [
    {
      "accountId": [
        "30080012343456"
      ],
      "transactionFromDateTime": "2018-01-01T00:00:00+00:00",
      "transactionToDateTime": "2018-12-03T00:00:00+00:00",
      "permissions": [
        "ReadAccountsDetail",
        "ReadBalances",
        "ReadBeneficiariesDetail",
        "ReadDirectDebits",
        "ReadProducts",
        "ReadStandingOrdersDetail",
        "ReadTransactionsCredits",
        "ReadTransactionsDebits",
        "ReadTransactionsDetail",
        "ReadOffers",
        "ReadPAN",
        "ReadParty",
        "ReadPartyPSU",
        "ReadScheduledPaymentsDetail",
        "ReadStatementsDetail"
      ]
    }
  ]
}

In the core banking system, the required validations should be performed, and the response be built, according to the requirements of the Open Banking Accounts specification.

Payments submission

In the Open Banking payments flow, integration with the core banking system is utilised during payment submission requests.

In the Open Banking payments flow, the WSO2 Open Banking solution manages the consent initiation and authorisation. When the TPP makes a payment submission request, it is validated, and upon successful validation, the request is directed to the core banking system. The account ID selected by the Payment Service User (PSU), is sent in the form of an encoded header, Account-ID.

In the core banking system, the required validations should be performed, and the response be built, according to the requirements of the Open Banking Payments specification.

Use of idempotency key in payment submission

WSO2 Open Banking solution uses Idempotency key in payment initiation call to restrain the duplication of a resource, i.e., payment initiation request call.

1. A payment initiation request call is made by the PSU.
2. There can be two scenarios where TPP uses the idempotency key. Let’s consider the following two scenarios.

   1. TPP sends the same request call with the same idempotency key - WSO2 Open Banking solution sends the same consentId.

   2. TPP sends the same request call with a different idempotency key - WSO2 Open Banking solution sends a different consentId.

3.  If the step 2 is successfully executed, ASPSP sends HTTP 201 to TPP. If not, an error message is sent.

Refer to the diagram below to understand how idempotency key is used in the Payment Initiation API of WSO2 Open Banking.

Idempotency key in payment submission in the Core Banking system

Idempotency key restrains the chance for a payment to be duplicated. Idempotency key in payment submission should be governed by the ASPSP as it is the ASPSP that responds in the payment submission call. Therefore, ASPSP must be aware of the duplicity of idempotency key and respond accordingly. 

Funds confirmation

In the Open Banking confirmation of funds consent flow, integration of the core banking system is utilised during funds confirmation request.

In the Open Banking funds confirmation consent flow, the WSO2 Open Banking solution manages the fund's confirmation consent requests and authorisation. When the TPP makes a fund's confirmation request (POST /funds-confirmations), it is validated against the consent details, and directed to the core banking system. Similar to the payment's submission request, the account ID of the consent is sent in the request as an encoded header, Account-ID.

In the core banking system, the required validations should be performed, and the response be built, according to the requirements of the Open Banking Confirmation of Funds specification.

Payable Accounts API

The backend endpoint for the Payable Accounts API is used to get the payable accounts of the user during the authentication flow. If Third Party Application (TPP) has not provided any debtor account in payment initiation request, PSU is able to select one of these payable accounts when he provide the consent to the payment. If the TPP has sent the debtor account in the initiation request, this API is used to validate the provided account against actual payable accounts. consentId and userId (PSU ID) requires to be sent in the URL as query parameters when calling this API.

The backend endpoint for payable accounts retrieval can be configured in open-banking.xml file as below.

<!--Configure endpoint to retrieve payable accounts passing userId https://localhost:9443/as400/payable-accounts/{userId} -->
    <PayableAccountsRetriveEndpoint>http://APIM_HOSTNAME:9763/open-banking/services/bankaccounts/bankaccountservice/payable-accounts</PayableAccountsRetriveEndpoint>

<!--Configure endpoint to retrieve sharable accounts passing userId https://localhost:9443/as400/sharable-accounts/{userId} -->
    <SharableAccountsRetriveEndpoint>http://APIM_HOSTNAME:9763/open-banking/services/bankaccounts/bankaccountservice/sharable-accounts</SharableAccountsRetriveEndpoint>