Skip to main content

What's common in Openbanking UK,Berlin NextgenPSD2, STET Specifications

WSO2 Open Banking solution [https://wso2.com/solutions/financial/open-banking/] is a purpose built solution for regulatory compliance in global regions including EU,UK [https://openbanking.wso2.com/], Australia [https://wso2.com/solutions/financial/open-banking/australia/]and new emerging countries. It helps banks to align with the regulatory needs while catering technical requirements with regulatory expertise.We have been closely working with EU/UK PSD2 compliance effort during past year and have improved the solution to cater a set of emerging specification in UK/EU for open banking as;


While we are working on supporting above three specifications from WSO2 Open Banking solution,interestingly there are some common factors which have been defined from each of the specifications while there are differences as well.This blog post is to write down the common defined points in each of these specifications.

API Endpoints that banks [ASPSPs] should expose to clients [TPPs]

Overall each of the specification defines about three main flows as below. TPPs [Third Party Provider] apps need to call each of below API endpoints in a secured manner to get bank customer [PSU] data from bank specific Open Banking solution.

  1. Account Information Service Endpoint - To get bank customer's account data including basic account information,balances,transactions,standing orders,products,etc. 
  2. Payment Initiation Service Endpoint- To do real time payment as a direct account transfer which could be one time,periodic or a bulk payment
  3. Confirmation of Funds Service Endpoint- To check the funds availability of a bank customer's account or a credit card
Thus the Open Banking solution deployed in bank side need to expose above three endpoints as secured endpoints after connect with core banking legacy system with proper mediation level.
API Security

Each of the specifications describe two levels of security on exposed APIs by banks.

  • Transport Layer Security
Via Mutual TLS 
To check the TPP send an API request with a valid certificate.The certificate validation includes Online Certificate Status Protocol (OCSP) checks & Certified Revocation Lists (CRL) checks.


  • Application Layer Security
eiDAS certificate validation for TPP roles

To check the TPP has obtained the correct role [AISP/PISP/PIISP] to access the API.For example:If a TPP with the role of AISP [Accounts Information Service Provider] tries to access a Payment API endpoint from the bank,it has to fail from bank.To achieve that bank side need to read the certificate sent by TPP API request and find the role attribute value and validate it.
OAuth2 and OpenID Connect support

With PSD2/Open Banking the high level scenario is the TPP [third party provider] app will able to access bank customer data on behalf of bank customer from the bank. OAuth2 is the best matching standard security protocol to cater this scenario with 3-legged OAuth2 flow. The grant types of Authorization code, client credentials and refresh are been used with OpenID Connect support for bank customer authentication.

Request body/headers signature verification
There's optional requirement set by specifications to validate the request body and header to avoid man in the middle attacks.The common approach which is describing in each of the specification is to validate the signature of headers count.

Strong Customer Authentication [SCA]

TPPs will get bank customer's actual account data /do real time account payments after user granted the permissions to TPP on behalf of bank customer.To grant user consents,it's a must that bank customer should authenticate with bank and from PSD2,it has mandated embedding multi factor authentication which is also called as Strong Customer Authentication step into bank customer authentication flow. There are three ways of achieving SCA.


    • Redirect approach 
    In this approach the bank customer authentication will happen in a user interface exposed by the bank. The TPP will redirect the PSU to bank's UI page to continue user authentication steps with SCA step included. Advantage of this step is user authentication happens at bank side web interface which is properly secured and TPP will not aware PSU credentials inputs.

    • Decoupled approach
    In this approach the bank customer authentication will happen in bank side,but no redirection will happen.Rather the user authentication will happen through a dedicated bank mobile app which has back channel communication with bank's authentication framework. Similar to redirect approach,in this approach also user authentication will handle by bank side which is a security plus point.

    • Embedded approach
    In this approach bank customer authenticate and authorize through TPP’s web interface,thus the TPP app calls bank side endpoints from TPP's user interface.In this approach the bank customer authentication handle by TPP side. Thus this approach is more suitable for a bank owned TPP /trusted party [eg: partner] owned TPP app to give direct access to call authentication/authorization endpoints from bank.

    Consent Life Cycle

    From PSD2, it has mandated that prior to get access to bank customer data by TPP, the bank customer needs to provide his/her consent for the TPP. Thus the user consent management is a major feature in bank specific open banking solutions. The user consent it self has a life cycle through out the API flows for accounts and payments.For example;
    • Received -The consent receipt has received for bank
    • AcceptedCustomerProfile -The consent has granted by the bank customer for TPP.
    • Rejected -The consent has rejected by bank customer to use by TPP
    • Revoked -The consent has revoked by bank customer,thus TPP cannot use it.
    • Expired -The consent has expired.
    The bank hosted Open Banking solution should able to manage user consents through out above life cycle statuses with ensuring data protection mechanisms while storing and retrieving.Additionally when the TPP invoke actual accounts Get API call or actual payment settlement initiation call,the open banking solution need to validate the user given consent is in granted status,if only allow the API access.

    Conclusion

    The March 2019 deadline is coming soon which is for banks to expose the sandbox environment with secured Accounts/Payments endpoints to satisfy PSD2 requirements in EU/UK region. WSO2 Open Banking solution ensures providing required technical capabilities based on specification mentioned requirements and bank specific requirements in a short time.If you are a bank still looking for an Open Banking solution,please visit  https://wso2.com/solutions/financial/open-banking

    Comments

    1. NikishaDecember 19, 2019 at 10:44 PM

      Data Science with R and Python is a good concept to learn. You can click here and read more about the machine learning consultant. These articles contain a lot of information which helps to solve your doubts.

      ReplyDelete

    Post a Comment

    Popular posts from this blog

    Convert an InputStream to XML

    For that we can use DocumentBuilder class in java. By using the method parse(InputStream) ; A new DOM Document object will return. InputStream input; DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance(); DocumentBuilder parser = factory.newDocumentBuilder(); Document dc= parser.parse(input); In the above code segment,by using the created Document object,the corresponding XML file for the inputStream can be accessed. References: http://www.w3schools.com/dom/dom_intro.asp http:// download.oracle.com/javase/1.4.2/docs/api/javax/xml/parsers/DocumentBuilder.html
    2 comments
    Read more

    CORS support from WSO2 API Manager 2.0.0

    Cross-origin resource sharing (CORS) is a mechanism that allows restricted resources  on a web page to be requested from another domain outside the domain from which the first restricted resource was served. For example, an HTML page of a web application served from http://domain-a.com makes an <img src >  request for a different domain as 'domain-b.com' to get an image via an API request.  For security reasons, browsers restrict cross-origin HTTP requests initiated from within scripts as in above example and only allows to make HTTP requests to its own domain. To avoid this limitation modern browsers have been used CORS standard to allow cross domain requests. Modern browsers use CORS in an API container - such as  XMLHttpRequest  or Fetch - to mitigate risks of cross-origin HTTP requests.Thing to  note is it's not only sufficient that the browsers handle client side of cross-origin sharing,but also the servers from which these resources getting need to handl
    Post a Comment
    Read more

    [WSO2 AM] APIStore User Signup as an approval process

    In previous versions of WSO2 APIManager before 1.6.0, it was allowed any user who's accessible the running APIStore come and register to the app.But there will be requirement like,without allowing any user to signup by him/her self alone,first get an approve by a privileged user and then allow to complete app registration.Same requirement can be apply to application creation and subscription creation as well.To fulfill that,we have introduced workflow extension support for  WSO2 APIManager  and you can find the introductory post on this feature from my previous blog post on " workflow-extentions-with-wso2-am-160 " . From this blog-post,I'll explain how to achieve simple workflow integration with default shipped resources with  WSO2 APIManager 1.6.0 and WSO2 Business Process Server 3.1.0 with targeting "user-signup" process. Steps First download the WSO2 APIManager 1.6.0[AM] binary pack from product download page . Extract it and navigate to
    Post a Comment
    Read more