Skip to main content

TPP Journey through WSO2 Open Banking

Introduction


2018 is all set to be a game-changing year for European banking. The Revised Payment Services Directive (PSD2) has opened the door to new third party providers [TPPs] to connect with banks and manage finances of bank customers on behalf of them. The PSD2 regulation has mandated banks to expose their core-banking account data and payment services to authorized TPPs to consume. Thus as a bank it’s essential to have a solution which will securely expose their internal banking services to third party providers in a trusted manner. WSO2 Open Banking solution provides all required components to expose bank APIs in a well secured manner in order to become PSD2 compliant. This article explains about the importance of the TPP role in PSD2 domain, the requirements set that banks need to provide for TPPs by PSD2 regulations and how WSO2 Open Banking solution supports these requirements. 
From my last blog ,I have given an introduction for PSD2 and WSO2 Open Banking solution which will helps to understand basics first before going through this blog post.

TPP interactions with an Open Banking system 
As a bank it’s essential to make sure they have setup the Open Banking [OB] system according to above mentioned XS2A requirements set by EBA ,before opening the channel of data as APIs to external parties. 
To verify the bank’s OB solution’s capabilities are matched with PSD2 XS2A rule requirements, it’s essential to be aware how a TPP would engage with a bank in PSD2 domain. Following are the key steps which a TPP will interact with bank’s Open Banking system to consume exposed customer data APIs.


TPP Onboarding
Once a bank exposed their customer data as APIs,it’s essential to have a mechanism to only allow the APIs to be consumed by trusted third party payment service providers in a secured manner. For that, a proper TPP  registration process has to be integrated with bank’s Open Banking system. For example,there has to be mechanisms to validate whether the requested TPP is a real authorized entity through an authorized competent authority ,validate the TPP information and then only allow access to OB system. Additionally according to the Article 29 in Regulatory Standard on Strong Customer Authentication [1],it mandates on obtaining qualified certificates for TPPs for the purpose of identification and from bank side the TPP certificates need to be validated.

Establish Secure Communication
According to the Article 21, 27 and 29 in Regulatory Standard on Strong Customer Authentication [1], it has mentioned to ensure the security of the software, communication protocol between TPP and the Payment Service User and the communication between banks and the TPP. Such that both banks and TPP parties has to obtain trusted and qualified certificates and need to share the public certificates among each. And the transferring data between bank and TPP need to verify for integrity, authenticity and non-repudiation.

Sandbox Testing
According to the Article 27 in Regulatory Standard on Strong Customer Authentication [1],it has mandated banks to make available a testing environment facility, including support  for connection and functional testing by authorized Payment Service Providers that have applied for the relevant authorization, to test their software and applications used for offering a payment service to users while no sensitive data is transferred in testing environment. Such that once a trusted TPP on-boarded to bank’s OB system,it need to provide the sandbox testing access for bank’s exposed APIs.

Go live with the TPP [PISP /AISP] application
Once the TPP team developed and tested their third party application with sandbox environment of bank’s OB system,then they could request the production environment access for available APIs from banks. This can be through a custom approval process. Then banks will validate the application and provide the production access.

TPP Usage Analytics
Once the TPP application is live, TPP owner wants to see the usage of the bank’s APIs from the  application in order to understand how much traffic is getting for each used bank APIs through the application for monetization purposes. For example; how many end users have consumed the third party application, who are the top users, how many transactions happened during a specific time period, what’s the highest and lowest used bank APIs from the application. From an open banking solution there has to way to expose these data for TPP owners as dashboards or APIs to monitor the business statistics.

Get notifications on new versions /API life-cycle changes
According to the Article 27 in Regulatory Standard on Strong Customer Authentication [1],it has mandated to notify the TPPs about any change for the technical specification of the bank exposed interfaces except in emergency situations in advance as soon as possible and not less than 3 months before the change is implemented.
Thus there has to have a mechanism to acknowledge TPPs who are already consuming existing bank APIs to notify any version changes or functional changes of the APIs.

Acknowledge and act on Bank service downtime and backup situations
According to the Article 28 in Regulatory Standard on Strong Customer Authentication [1], banks need to include a strategy and plans for an unplanned unavailability of the interface and systems breakdown. The strategy need to include communication plans to inform TPPs making use of the dedicated interface in case of breakdown, measures to bring the system back to business as usual and a description of alternative options that TPPs may make use of during the unplanned downtime. This will ensure that third party applications will run even in a bank system breakdown with using bank fallback options provided.
It’s critical for a bank to select the best PSD2 compliant Open Banking solution which cater all above main requirements to connect  the bank with TPPs under PSD2 XS2A rule. 

TPP Journey through WSO2 Open Banking

WSO2 Open Banking[OB] solution provides a comprehensive capabilities set to facilitate interactions between TPPs and banks in a well secured manner thus bank customers can utilize third party applications of TPPs which are connected to exposed APIs from banks.
TPP On-boarding
Provides a well defined user interface for TPP owners to register to Open Banking solution for consuming bank APIs. This user interface will allow TPPs to enter their authorized details as TPP identification number, Country of authorization, Contact details, etc based on the EU regional on-boarding requirements. In addition to that it can easily engage a bank specific customized on-boarding requests verification process including human interactions also to the TPP on-boarding process. For example - if a bank has a TPP on-boarding requirement of “A TPP on-boarding request need to approve by multiple officers in the bank”, this type of human interactions included approval process can integrate with WSO2 OB solution.
Establish Secure Communication
WSO2 Open Banking solution is capable of establishing a secured communication channel between the TPP and bank with verifying the exchanging digital certificates among the two parties with the capabilities of identity management and security features as asymmetric key encryption, OAuth2 Private Key JWT Authentication,mutual authentication support. Addition to that WSO2 OB supports, signing the transferring data with digital certificates for ensure integrity and non-repudiation.

Sandbox Testing
Once the TPP owner got approval for OB developer portal access ,he can view available APIs and first try out testing the APIs which are pointed to sandbox environments. The necessary API documentation including steps on API invocation flow will be displayed in OB developer portal. And to test the APIs inline, swagger based API console also embedded with OB developer portal. Thus a TPP owner could obtain sandbox environment specific access keys and try out invoking sandbox APIs to test out API functionalities.

Go live with the TPP [PISP /AISP] application
Once the TPP team is ready for getting live traffic to their custom application, they have to switch from integrating sandbox endpoints of APIs of banks to production ready endpoints of the APIs of the bank.  For that TPP can request for production access via WSO2 OB system and get the access once he got approval after the production access validation process. This production access validation process can be customized based on bank’s custom requirements and if need it can disable production access validation process and give TPPs automatic access to production without further validations. 

TPP Usage analytics
The developer portal of WSO2 Open Banking solution consists of business dashboard views which are important for a TPP owner. For example ,the available dashboards in developer portal provide the analysed data about API consumption from TPP application,who are the top users of the third party application, how many faulty API invocations have happened from TPP’s application,likewise. Thus the TPP owners can utilize these available dashboards for billing purposes and identify loyalty customers of their applications.If it further need, the available TPP specific data can be fetch through a REST endpoint,thus a third party analytics tool can be configured to provide custom business insights as TPP wants.

Get notifications on new versions /API lifecycle changes
WSO2 Open Banking solution provides comprehensive API Management capabilities including API versioning support. Addition to that,it’s possible to configure a notification to be alerted when a new API version created. The notification can be a email, sms or other output format according to bank’s requirement. This way it can achieve the requirement  mentioned in the Article 27 of Regulatory Standard on Strong Customer Authentication [1],of mandating notify the TPPs about changes of the technical specification, bank exposed interfaces in advance.

Acknowledge and act on Bank service downtime and backup situations
High availability and scalability factors are highly considered on WSO2 Open banking solution deployments and these factors are configured with solution’s inbuilt clustering support. Thus when a server goes down,it can route to another working server node via a load balancing rule easily without affecting the service up time. And the OB solution supports integrate with third party tools to monitor the server memory,cpu usage and other server specific information via inbuilt jmx monitoring capability. This way via third party tools,it can set alerts to notify the bank IT administrators when an abnormal behavior monitored in the running servers. Same way, WSO2 OB solution can be configured to send alerts, if  the  back-end system  [eg: core-banking system] is down.










Comments

  1. Onroadz offers an affordableself drive rental car in Coimbatore to all the major cities such as Coimbatore, Madurai, Trichy, Salem, Vizag, Vijayawada, Mysore, Theni etc in Tamil Nadu.

    ReplyDelete
  2. Looking for a best online casino? Then you are at the right place. We are here to help you to find best online casino India real money

    ReplyDelete
  3. solutions for open banking monetization
    Personalize products, offers, pricing and loyalty programs; prevent revenue leakage and ensure regulatory compliance with a billing solution.

    ReplyDelete
  4. If you are looking for the best iron removal plant manufacturer, we are the greatest option to buy your desired equipment. The manufactured filters are vastly known for their effective performance and long-lasting capability features.  

    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

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

[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